Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
K
k3s
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Registry
Registry
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Jacklull
k3s
Commits
f9354bf6
Commit
f9354bf6
authored
May 17, 2017
by
Ryan Hallisey
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add a README to the pre-existing provdier
parent
82e1d208
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
54 additions
and
0 deletions
+54
-0
README.md
test/kubemark/pre-existing/README.md
+54
-0
No files found.
test/kubemark/pre-existing/README.md
0 → 100644
View file @
f9354bf6
# Kubemark Pre-existing Provider Guide
**Kubemark Master**
-
A set of Kubernetes control plane components running in a VM
**Kubernetes Cluster**
-
A real Kubernetes Cluster that has master and minions. The hollow-node pods
are run in this cluster, but appear as nodes to the Kubemark Master
## Introduction
Every running Kubemark setup looks like the following:
1) A running Kubernetes cluster pointed to by the local kubeconfig
2) A separate VM where the kubemark master is running
3) Some hollow-nodes that run on the Kubernetes Cluster from #1
4) The hollow-nodes are configured to talk with the kubemark master at #2
When using the pre-existing provider, the developer is responsible for creating
#1 and #2. Therefore, the kubemark scripts will not create any infrastructure
or start a kubemark master like in other providers. Instead, the existing
resources provided by the VM at $MASTER_IP will serve as the kubemark master.
## Use Case
The goal of the pre-existing provider is to use the kubemark tools with an
existing kubermark master. It's meant to provide the developer with
additional flexibility to customize the cluster infrastructure and still use
the kubemark setup tools. The pre-existing provider is an
**advanced**
use
case that requires the developer to have knowledge of setting up a kubemark
master.
## Requirements
To use the pre-existing provider, the expectation is that there's a kubemark
master that is rechable at $MASTER_IP. The machine that the kubemark master is
on has to be ssh able from the host that's executing the kubemark scripts. And
the user on that machine has to be 'kubernetes'.
Requirement checklist:
-
Set MASTER_IP to ip address to the kubemark master
-
The host where you execute the kubemark scripts must be able to ssh to
kubernetes@$MASTER_IP
## Example Configuration
_test/kubemark/cloud-provider-config.sh_
```
CLOUD_PROVIDER="pre-existing"
KUBEMARK_IMAGE_MAKE_TARGET="push"
CONTAINER_REGISTRY=docker.io
PROJECT="rthallisey"
MASTER_IP="192.168.121.29:6443"
```
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment