Introduction to Minikube
Recently, since the publication of my first book, Containerization with Ansible 2, (Have I mentioned you should buy a copy? :-D) I have been focusing on taking some time off and shutting off my laptop when I’m not at work. However, not unlike most geeks, I can only leave my laptop closed for so long. Most recently, I have been leading a Kubernetes initiative at work, demonstrating the migration of application workloads away from standard Docker into Kubernetes clusters.
This work has involved a lot of trial and error to really nail down a comprehensive migration strategy that is simple to adopt across the organization in phases. To demo some of my ideas, I have been using a local Kubernetes cluster on my laptop using MiniKube. MiniKube is an absolutely fantastic project that completely removes many of the barriers of entry to quickly get started learning and developing using Kubernetes. In a matter of minutes, you can spin up a single node Kubernetes cluster on your laptop, with direct access using the KubeCTL command line tool. Although, it is difficult to test features like high availability of your applications across multiple Kubernetes nodes, you can simply and accurately test the core functionality of your applications deployed in a Kubernetes environment.
Installing MiniKube in Ubuntu
Installing Minikube in Ubuntu (or other Unix-like operating systems) is relatively simple. In essence, MiniKube is a self-contained VM that gets launched on your laptop using a simplified command line interface, much like a Vagrant box. Before beginning, you must first install a hypervisor on your laptop (I perfer VirtualBox).
Once you have VirutalBox installed and ready to go, you can use the
curl command to install the MiniKube and KubeCTL binaries:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.24.1/minikube-linux-amd64 curl -Lo kubectl https://storage.googleapis.com/kubernetes-release/release/v1.8.0/bin/linux/amd64/kubectl
Once the binaries have been downloaded, copy them /usr/local/bin and give them executable permissions:
sudo cp minikube /usr/local/bin/ sudo chmod +x /usr/local/bin/minikube sudo cp kubectl /usr/local/bin/ sudo chmod +x /usr/local/bin/kubectl
Once the MiniKube and KubeCTL binaries are in the respective locations, you can easily start MiniKube by using by aptly named,
minikube start command.
minikube start will download the MiniKube ISO file, make any required VirtualBox configurations, and copy your the Kubernetes API certificate manager certificates to the
~/.minikube/ directory in your laptop:
[email protected]:~$ minikube start Starting local Kubernetes v1.8.0 cluster... Starting VM... Downloading Minikube ISO 140.01 MB / 140.01 MB [============================================] 100.00% 0s Getting VM IP address... Moving files into cluster... Downloading localkube binary 148.25 MB / 148.25 MB [============================================] 100.00% 0s 0 B / 65 B [----------------------------------------------------------] 0.00% 65 B / 65 B [======================================================] 100.00% 0sSetting up certs... Connecting to cluster... Setting up kubeconfig... Starting cluster components... Kubectl is now configured to use the cluster. Loading cached images from config file.
Wait there’s more: It will even configure your Kubernetes credentials in the
~/.kube/ directory so you can immediately access your Kubernetes environment. As soon as MiniKube has finished launching, you can start using the KubeCTL CLI interface right away. Execute the
kubectl cluster-info command to see some basic cluster details:
[email protected]:~$ kubectl cluster-info Kubernetes master is running at https://192.168.99.100:8443 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Deploying an Application in MiniKube
Finally, we can create a simple deployment and service resource we can use to validate the functionality of Kubernetes. Let’s create a simple NGINX server deployment called, “test” using the
kubectl run command. We will tell Kubernetes to run a single replica, and listen for traffic coming into the pod on port 80:
[email protected]:~$ kubectl run test --image nginx:latest --replicas=1 --port=80 deployment "test" created
To test reachability for our service, we can expose it on a high-numbered NodePort to validate we have network reachability into our cluster:
[email protected]:~$ kubectl expose deployment test --type NodePort service "test" exposed
A randomly assigned NodePort will be exposed listening on the VM IP address we noted from the
kubectl cluster-info command we ran earlier. To see which port has been exposed, we can describe the service we just created using the
[email protected]:~$ kubectl describe svc test Name: test Namespace: default Labels: run=test Annotations: <none> Selector: run=test Type: NodePort IP: 10.108.89.122 Port: <unset> 80/TCP TargetPort: 80/TCP NodePort: <unset> 32243/TCP Endpoints: 172.17.0.4:80 Session Affinity: None External Traffic Policy: Cluster Events: <none>
In this example, port number 32243 has been exposed on the IP address: 192.168.99.100 (not be confused with the internal Kubernetes service address:
10.108.89.122.) This address should be accessible from your local web browser:
Now that we have validated that Kubernetes is running and able to start and run pods, we can proceed to working with slightly more advanced concepts: Ingress, Helm, and resources oh my!