Playing with Kubernetes locally with Minikube

I want to start using Kubernetes to manage my services. Before I go all-in I will do some playing around with their easy-to-install version that can run on a single machine.

Requirements

Before we can run Minikube locally we need to have a virtualization solution installed in our host. Since my computer supports KVM, I decided to go with it. You can check if your computer supports KVM with this command:

1

egrep -c '(vmx|svm)' /proc/cpuinfo

If your system supports KVM, you will get a 1 or higher number.

I’m running Ubuntu, so I can use apt-get to install KVM:

1

sudo apt-get install qemu-kvm libvirt-bin bridge-utils

The next step is to install kubectl. On Linux you can use these command to download the binary and put it in your path:

The cluster doesn’t have any containers running yet, but it has the kubernetes client installed so it is ready to start running services.

Vocabulary

Before we start, it is necessary to define some terms that are common when working with Kubernetes.

Pod – Is a group of 1 or more containers with configurations on how to run those containers. They are always co-located (deployed in the same data center) and co-scheduled (deployed at the same time). It is basically a single application. Containers within a pod can find each other via localhost. Applications in different pods have different IP addresses. Users will generally not create Pods directly, but rather use Deployments.

Replica set – A ReplicaSet ensures that a specified number of replicas (of a Pod) are running at any given time.

Deployment – Provides a way to issue updates on Pods or Replica Sets.

Service – A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. Although Pods each have a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic.

This command will create a new Deployment that consists of running the echoserver:1.4 image. We have given the name echo-server to this deploy. The –port modifier serves to indicate which port we want this container to expose. In this case it exposes 8080 because the service inside the container runs on that port.

But even though we are now running a container that exposes port 8080, it is not really available to us yet (because the container is running inside Minikube). We can verify this by asking minikube to give us the URL of our service:

1
2

minikube service echo-server --url
Error opening service: Could not find finalized endpoint being pointed to by echo-server: Error validating service: Error getting service echo-server: services "echo-server" not found

This command will make your Deployment publicly available. The most important thing to notice is –type=NodePort, which tells Kubernetes how we want to expose the Deploy. The possible type values are: ClusterIP, NodePort or LoadBalancer.

ClusterIP – Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. This is the default value.

NodePort – Exposes the service on each Node’s IP at a static port (the NodePort). A ClusterIP service, to which the NodePort service will route, is automatically created. You’ll be able to contact the NodePort service, from outside the cluster, by requesting :.

LoadBalancer – Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.

minikube service echo-server --url
Error opening service: Could not find finalized endpoint being pointed to by echo-server: Error validating service: Error getting service echo-server: services "echo-server" not found

Now that we know a service is what exposes the application, the error message also becomes easier to understand.

Kubernetes will then 1 by 1 update all your pods to the new version. You can verify the status of the update with the describe command:

1

kubectl describe pods

For the example above there should be a line like this one:

1

Image: gcr.io/google_containers/echoserver:1.6

For each one of the pods.

Conclusion

This post shows the most basic uses of Kubernetes. Most importantly, we now understand the vocabulary that will allow us to dive deeper into the documentation and other articles in the subject. There are a lot of questions left unanswered that I’m going to look into in future posts.