The folks behind Minikube made creating a cluster as easy as it can get. All we need to do is to execute a single command. Minikube will start a virtual machine locally and deploy the necessary Kubernetes components into it. The VM will get configured with Docker and Kubernetes via a single binary called localkube.
1 minikube start --vm-driver=virtualbox
You might experience problems with virtualbox. If that's the case, you might want to use hyperv instead. Open a Powershell Admin Window and execute the Get-NetAdapter command, noting the name of your network connection. Create a hyperv virtual switch New-VMSwitch -name NonDockerSwitch -NetAdapterName Ethernet -AllowManagementOS $true replacing Ethernet with your network connection name. Then create the Minikube vm: minikube start --vm-driver=hyperv --hyperv-virtual-switch "NonDockerSwitch" --memory=4096. Other minikube commands such as minikube start, minikube stop and minikube delete all work the same whether you're using VirutalBox or Hyper-V.
A few moments later, a new Minikube VM will be created and set up, and a cluster will be ready for use.
When we executed the minikube start command, it created a new VM based on the Minikube image. That image contains a few binaries. It has both Docker (https://www.docker.com/) and rkt (https://coreos.com/rkt/) container engines as well as localkube library. The library includes all the components necessary for running Kubernetes. We'll go into details of all those components later. For now, the important thing is that localkube provides everything we need to run a Kubernetes cluster locally.
Remember that this is a single-node cluster. While that is unfortunate, it is still the easiest way (as far as I know) to "play" with Kubernetes locally. It should do, for now. Later on, we'll explore ways to create a multi-node cluster that will be much closer to a production setup.
Let's take a look at the status of the cluster.
1 minikube status
The output is as follows.
minikube: Running cluster: Running kubectl: Correctly Configured: pointing to minikube-vm at 192.168.99.100
Minikube is running, and it initialized a Kubernetes cluster. It even configured kubectl so that it points to the newly created VM.
You won't see much UI in this book. I believe that a terminal is the best way to operate a cluster. More importantly, I am convinced that one should master a tool through its commands first. Later on, once we feel comfortable and understand how the tool works, we can choose to use a UI on top of it. We'll explore the Kubernetes UI in one of the later chapters. For now, I'll let you have a quick glimpse of it.
1 minikube dashboard
Feel free to explore the UI but don't take too long. You'll only get confused with concepts that we did not yet study. Once we learn about pods, replica-sets, services, and a myriad of other Kubernetes components, the UI will start making much more sense.
Another useful Minikube command is docker-env.
1 minikube docker-env
The output is as follows.
export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.99.100:2376" export DOCKER_CERT_PATH="/Users/vfarcic/.minikube/certs" export DOCKER_API_VERSION="1.23" # Run this command to configure your shell: # eval $(minikube docker-env)
If you worked with Docker Machine, you'll notice that the output is the same. Both docker-machine env and minikube docker-env serve the same purpose. They output the environment variables required for a local Docker client to communicate with a remote Docker server. In this case, that Docker server is the one inside a VM created by Minikube. I assume that you already have Docker installed on your laptop. If that's not the case, please go to the Install Docker (https://docs.docker.com/install/) page and follow the instructions for your operating system. Once Docker is installed, we can connect the client running on your laptop with the server in the Minikube VM.
1 eval $(minikube docker-env)
We evaluated (created) the environment variables provided through the minikube docker-env command. As a result, every command we send to our local Docker client will be executed on the Minikube VM. We can test that easily by, for example, listing all the running containers on that VM.
1 docker container ls
The containers listed in the output are those required by Kubernetes. We can, in a way, consider them system containers. We won't discuss each of them. As a matter of fact, we won't discuss any of them. At least, not right away. All you need to know, at this point, is that they make Kubernetes work.
Since almost everything in that VM is a container, pointing the local Docker client to the service inside it should be all you need (besides kubectl). Still, in some cases, you might want to SSH into the VM.
1 minikube ssh 2 3 docker container ls 4 5 exit
We entered into the Minikube VM, listed containers, and got out. There's no reason to do anything else beyond showing that SSH is possible, even though you probably won't use it.
What else is there to verify? We can, for example, confirm that kubectl is also pointing to the Minikube VM.
1 kubectl config current-context
The output should be a single word, minikube, indicating that kubectl is configured to talk to Kubernetes inside the newly created cluster.
As an additional verification, we can list all the nodes of the cluster.
1 kubectl get nodes
The output is as follows.
NAME STATUS ROLES AGE VERSION minikube Ready <none> 31m v1.8.0
It should come as no surprise that there is only one node, conveniently called minikube.
If you are experienced with Docker Machine or Vagrant, you probably noticed the similar pattern. Minikube commands are almost exactly the same as those from Docker Machine which, on the other hand, are similar to those from Vagrant.
We can do all the common things we would expect from a virtual machine. For example, we can stop it.
1 minikube stop
We can start it again.
1 minikube start
We can delete it.
1 minikube delete
One interesting feature is the ability to specify which Kubernetes version we'd like to use.
Since Kubernetes is still a young project, we can expect quite a lot of changes at a rapid pace. That will often mean that our production cluster might not be running the latest version. On the other hand, we should strive to have our local environment as close to production as possible (within reason).
We can list all the available versions with the command that follows.
1 minikube get-k8s-versions
The output, limited to the first few lines, is as follows.
The following Kubernetes versions are available:
- v1.9.0
- v1.8.0
- v1.7.5
- v1.7.4
- v1.7.3
- v1.7.2
- v1.7.0
...
Now that we know which versions are available, we can create a new cluster based on, let's say, Kubernetes v1.7.0.
1 minikube start 2 --vm-driver=virtualbox 3 --kubernetes-version="v1.7.0"
4 5 kubectl version --output=yaml
We created a new cluster and output versions of the client and the server.
The output of the latter command is as follows.
clientVersion: buildDate: 2017-10-24T19:48:57Z compiler: gc gitCommit: bdaeafa71f6c7c04636251031f93464384d54963 gitTreeState: clean gitVersion: v1.8.2 goVersion: go1.8.3 major: "1" minor: "8" platform: darwin/amd64 serverVersion: buildDate: 2017-10-04T09:25:40Z compiler: gc gitCommit: d3ada0119e776222f11ec7945e6d860061339aad gitTreeState: dirty gitVersion: v1.7.0 goVersion: go1.8.3 major: "1" minor: "7" platform: linux/amd64
If you focus on the serverVersion section, you'll notice that the major version is 1 and the minor is 7.