This guide walks a deployer through launching a multi-node Kubernetes cluster using Vagrant and CoreOS. After completing this guide, a deployer will be able to interact with the Kubernetes API from their workstation using the kubectl CLI tool.
Navigate to the Vagrant downloads page and grab the appropriate package for your system. Install the Vagrant software before continuing.
kubectl is the main program for interacting with the Kubernetes API. Download kubectl from the Kubernetes release artifact site with the curl tool.
The linux kubectl binary can be fetched with a command like:
$ curl -O https://storage.googleapis.com/kubernetes-release/release/v1.2.4/bin/linux/amd64/kubectlOn an OS X workstation, replace linux in the URL above with darwin:
$ curl -O https://storage.googleapis.com/kubernetes-release/release/v1.2.4/bin/darwin/amd64/kubectlAfter downloading the binary, ensure it is executable and move it into your PATH:
$ chmod +x kubectl
$ mv kubectl /usr/local/bin/kubectlThe following commands will clone a repository that contains a "Vagrantfile", which describes the set of virtual machines that will run Kubernetes on top of CoreOS.
$ git clone https://github.com/coreos/coreos-kubernetes.git
$ cd coreos-kubernetes/multi-node/vagrantThe default cluster configuration is to start a virtual machine for each role — master node, worker node, and etcd server. However, you can modify the default cluster settings by copying config.rb.sample to config.rb and modifying configuration values.
#$update_channel="alpha"
#$controller_count=1
#$controller_vm_memory=512
#$worker_count=1
#$worker_vm_memory=512
#$etcd_count=1
#$etcd_vm_memory=512
By default, Calico network policy is disabled. To enable it, change the line export USE_CALICO=false to export USE_CALICO=true in both the ../generic/controller-install.sh and the ../generic/worker-install.sh scripts. With Calico enabled, ensure that the K8S_VER variable in both of those files refers to a version of the hyperkube image that bundles the CNI binaries, e.g. export K8S_VER=v1.2.4_coreos.cni.1. This is not the default, and must be manually changed when using Calico.
Ensure the latest CoreOS vagrant image will be used by running vagrant box update.
Then run vagrant up and wait for Vagrant to provision and boot the virtual machines.
Choose one of the two following ways to configure kubectl to connect to the new cluster:
$ export KUBECONFIG="${KUBECONFIG}:$(pwd)/kubeconfig"
$ kubectl config use-context vagrant-multiConfigure your local Kubernetes client using the following commands:
$ kubectl config set-cluster vagrant-multi-cluster --server=https://172.17.4.101:443 --certificate-authority=${PWD}/ssl/ca.pem
$ kubectl config set-credentials vagrant-multi-admin --certificate-authority=${PWD}/ssl/ca.pem --client-key=${PWD}/ssl/admin-key.pem --client-certificate=${PWD}/ssl/admin.pem
$ kubectl config set-context vagrant-multi --cluster=vagrant-multi-cluster --user=vagrant-multi-admin
$ kubectl config use-context vagrant-multiCheck that kubectl is configured properly by inspecting the cluster:
$ kubectl get nodes
NAME LABELS STATUS
172.17.4.201 kubernetes.io/hostname=172.17.4.201 ReadyNOTE: When the cluster is first launched, it must download all container images for the cluster components (Kubernetes, dns, heapster, etc). Depending on the speed of your connection, it can take a few minutes before the Kubernetes api-server is available. Before the api-server is running, the kubectl command above may show output similar to:
The connection to the server 172.17.4.101:443 was refused - did you specify the right host or port?
Is kubectl working correctly?
Now that you've got a working Kubernetes cluster with a functional CLI tool, you are free to deploy Kubernetes-ready applications. Start with a multi-tier web application from the official Kubernetes documentation to visualize how the various Kubernetes components fit together.
View the Guestbook example app