Kubernetes Overview

Kubernetes Concepts

There are many additional concepts—beyond that of architecture—that you must understand before you can fluently run your applications on Kubernetes. The Kubernetes API exposes various resources in the cluster as objects. For example, when you deploy (verb) an application, you’re creating a deployment (noun). Here is a high-level list of the most important resources that you’ll work with throughout the rest of the chapter:

As you can see, Kubernetes is an extremely powerful and malleable tool for deploying application containers. Kubernetes supports many primitives out of the box. There are often many ways to do the same thing in Kubernetes. For example, different environments can be simulated using either namespaces or labels. An application can be deployed using one or more replica sets. Many complex and opinionated patterns can be adopted for deploying to Kubernetes, yet only a subset of these features are required to get a distributed application running in production.

This list contains the most important concepts for an application developer to worry about. That said, it doesn’t even include everything required to get Kubernetes running in a high-throughput production environment! For example, Kubernetes also depends on the Etcd service. Instead of configuring several complex services to get Kubernetes running locally, you’ll instead depend on the much simpler Minikube. Minikube sacrifices some features, like the ability to run multiple nodes, but simplifies other things, like not having to configure Etcd and combining the master node with a worker node.

Starting Kubernetes

Kubectl Subcommands

To create your very first deployment, run the following commands. Try to run them quickly so that you can view the status of the Kubernetes cluster while the deployment is in progress:

$ kubectl create deployment hello-minikube \
  --image=k8s.gcr.io/echoserver:1.10
$ kubectl get deployments
$ kubectl get pods
$ kubectl get rs

The first command is what creates your deployment. The actual creation of the deployment resource is pretty quick, and the command should exit almost immediately. However, it still needs to do a bunch of background work before it’s truly complete. For example, the echoserver image needs to be downloaded and a container needs to be instantiated.

If you were able to run the subsequent commands quickly enough, you should see the status of the Kubernetes cluster while it’s trying to get things into the desired state. On my machine, I see the following command output:

$ kubectl get deployments
  NAME             READY   UP-TO-DATE   AVAILABLE   AGE
  hello-minikube   0/1     1            0           3s
$ kubectl get pods
  NAME                            READY STATUS            RESTARTS AGE
  hello-minikube-6f5579b8bf-rxhfl 0/1   ContainerCreating 0        4s
$ kubectl get rs
  NAME                        DESIRED   CURRENT   READY   AGE
  hello-minikube-64b64df8c9   1         1         0       0s

As you can see, the creation of the resources is immediate. In this case, a pod resource named hello-minikube-6f5579b8bf-rxhfl was immediately created. However, the actual pod isn’t up and ready yet. The READY column lists the value for that pod as 0/1. This means that zero of the desired one pods have been created. Note that in this case the deployment “owns” the replica set, and the replica set “owns” the pod. While you technically only requested that a deployment be created when you ran the command, it implicitly creates dependent resources of other types.

Once a minute or two passes, the cluster will most likely have finished creating the other resources. So, run those three kubectl get commands again. When I run those commands a second time, I get these results—though this time I’ve added the -L app flag to show the pod’s app label:

$ kubectl get deployments
  NAME             READY   UP-TO-DATE   AVAILABLE   AGE
  hello-minikube   1/1     1            1           7m19s
$ kubectl get pods -L app
  NAME                READY  STATUS   RESTARTS  AGE    APP
  hello-minikube-123  1/1    Running  0         7m24s  hello-minikube
$ kubectl get rs
  NAME                        DESIRED   CURRENT   READY   AGE
  hello-minikube-64b64df8c9   1         1         1       7m25s

Recall that a service is like a reverse proxy for containers matching a certain selector. Run the following commands to create a new service and then to list the services:

$ kubectl expose deployment hello-minikube \
  --type=NodePort --port=8080
$ kubectl get services -o wide

Here is the list of services available on my machine:

NAME           TYPE      ... PORT(S)        AGE  SELECTOR
hello-minikube NodePort  ... 8080:31710/TCP 6s   app=hello-minikube
kubernetes     ClusterIP ... 443/TCP        7d3h <none>

The SELECTOR column for this service lists the selectors that are used to target pods. In this case, the selector was implicitly created and it targets pods with an app label set to hello-minikube. As you saw previously, a label of app was implicitly set to hello-minikube on the pods when you created the deployment. These are operations provided by Kubectl to make interacting with the API easier.

The service that you created is ready almost immediately. With it created, you’re now ready to send it an HTTP request. But what URL should you request? In this case, you’ll need a bit of help from the minikube CLI to get the URL of the hello-minikube service. Run the following commands—the first one will display the service’s URL, and the second will make an HTTP request:

$ minikube service hello-minikube --url
$ curl `minikube service hello-minikube --url`

In my case, I see that the URL to the service is http://172.17.0.3:31710. The hello-minikube HTTP service provides a bunch of information when you make the request. Assuming you didn’t receive an error, the request was a success!

Note that in this case there is no concept of ownership between the service and the other resources. The service is only loosely related to the pods since only their selector and labels happen to match. The service could technically match other pods as well, if any existed.

At this point it’s worth visiting the Kubernetes dashboard once again and viewing the resources that you’ve created. Check out the Deployments, Pods, and Replica Sets screens in the Workloads section, as well as the Services screen in the Discovery and Load Balancing sections of the dashboard.

Now that you’re done with the hello-minikube service, it’s time to tear it down. Run the following commands to delete the service and deployment resources that you previously created:

$ kubectl delete services hello-minikube
$ kubectl delete deployment hello-minikube

When you delete the deployment, it will automatically delete the resources that it owns (in this case, the pods and the replica set). Once that’s done, run these commands to get a list of resources one final time:

$ kubectl get deployments
$ kubectl get pods
$ kubectl get rs

Depending on how quickly you run the commands, you may see that the pod still exists. But if you do see it, the status of the pod should be listed as Terminating. Run the command a few more times and you should then see that the pod has disappeared entirely. Most of the interactions you have with Kubernetes will require time before the cluster can change from the existing state to your desired state.

Kubectl Configuration Files

When you ran the other Kubectl commands, you were mostly working with a single resource at a time, like when you created the service, or sometimes multiple resources, like when the pod and replica set were created when you made a deployment. When working with configuration files, several potentially unrelated resources can be created at the same time.

• You’ll run five redundant replicas of the application at once.

• A Kubernetes service will point to the instances.

• Kubernetes will automatically restart unhealthy application replicas.

But first, you’ll need to build a Docker image and push it to the Kubernetes Docker service. Visit your recipe-api directory and build a new version of the image by running the following commands:

$ cd recipe-api
$ eval $(minikube -p minikube docker-env) # ensure Minikube docker
$ docker build -t recipe-api:v1 .

A Docker image tagged as recipe-api:v1 is now available in your Kubernetes Docker daemon.

Apply the changes represented in this configuration file the same way you did for the previous one, by running this command with a new filename:

$ kubectl apply -f recipe-api/recipe-api-network.yml

Once that’s done, run the kubectl get services -o wide command again. You should see an entry just like you saw when previously defining a service using the kubectl expose command, except this time the name of the service is a little longer.

Scaling Application Instances

You’re currently running five replicas of the recipe-api application. Run the following commands to get a list of your pods, to scale the number of replicas to 10, and to get the new list of pods:

$ kubectl get pods -l app=recipe-api
$ kubectl scale deployment.apps/recipe-api --replicas=10
$ kubectl get pods -l app=recipe-api

In this case, you should see that Kubernetes creates the five new pods, and depending on how quickly you ran the final command, some of them will have a status of ContainerCreating. Wait some time and run the final command again, and their statuses should have changed to Running.

You could modify that command to set the number of replicas back down to five, but there’s another way to modify a deployment. The recipe-api/recipe-api-deployment.yml file that was used to first create the deployment can also be used to modify it. Specifically, when you run the kubectl apply command, it’s not just limited to creating resources. Really, it instructs the Kubernetes cluster to make whatever changes are necessary to then resemble the resource definitions in the specified configuration file.

In this case, the state of the cluster is currently different than that of the configuration file. Specifically, the file wants a replica count of 5, but the cluster has a replica count of 10. To scale the number of replicas back down to five, run the same kubectl apply command again:

$ kubectl apply -f recipe-api/recipe-api-deployment.yml

The output for the apply command can take on three forms:

deployment.apps/recipe-api created
deployment.apps/recipe-api configured
deployment.apps/recipe-api unchanged

The first line is what you had encountered previously when running kubectl apply. This line states that a new resource has been created. This time, however, you should have received the second line of output. This line means that the resource represented in the configuration file was found—using the resource’s name—and that the resource was modified. The final line is what you’ll see if the cluster currently resembles the state desired by the file and no action is necessary. Go ahead and run that kubectl apply command one more time. This time you should get the unchanged line in response.

Deploying New Application Versions

When you deploy a new version of an application, you don’t want to kill off the old deployment resource and create a new one. Instead, you want to piggy back on it and replace the pods that belong to that deployment.

Before you can deploy a new version of the application, you first need to create it. For the sake of illustration, you can do this by simply adding a new endpoint to the existing application code. Run the following commands to add a new endpoint and to build a web-api:v2 version of your application:

$ cd web-api
$ echo "server.get('/hello', async () => 'Hello');" \
  >> consumer-http-basic.js
$ eval $(minikube -p minikube docker-env) # ensure Minikube docker
$ docker build -t web-api:v2 .

Next, edit the web-api/web-api-deployment.yml file. Once inside, modify the spec.template.spec.container.image property and change it from image: web-api:v1 to image: web-api:v2. Once you’ve made that change, run the following command to deploy the changes and to watch the pods deploy:

$ kubectl apply -f web-api-deployment.yml
$ kubectl get pods -w -l app=web-api

The -w flag tells Kubectl to watch the changes being made to the Kubernetes cluster, and it will keep drawing output as changes are made to the web-api pods in your cluster. Once the process is finally complete you can kill the watch operation with Ctrl + C.

Rolling Back Application Deployments

Luckily for you and me, Kubernetes retains information about previous deployments. This allows you to roll back to a previous deployment by executing a few commands.

But first, it’s time to release a broken application. This version of the application adds a new endpoint /kill that causes the process to immediately exit. Run the following commands to amend the web-api service with the new route and to build a new version of the container:

$ cd web-api
$ echo "server.get('/kill', async () => { process.exit(42); });" \
  >> consumer-http-basic.js
$ eval $(minikube -p minikube docker-env) # ensure Minikube docker
$ docker build -t web-api:v3 .

Once your image has been built, you’re ready to perform another deployment. Edit the web-api-deployment.yml file again, this time changing the image line from web-api:v2 to web-api:v3. Once that’s done, run the following command to perform another deployment:

$ kubectl apply -f web-api-deployment.yml --record=true

Note that this time the --record=true flag has been added. You’ll see what this flag is used for in a moment. Once the new version of the application deploys, you’re ready to test the new endpoint. Make the following request:

$ curl `minikube service web-api-service --url`/kill

Once you run that command, you should get an error back that curl received an empty reply from the server. Next, run the command kubectl get pods -l app=web-api to get a list of your pods again. When I run this command, I get the following results:

NAME                       READY   STATUS    RESTARTS   AGE
web-api-6bdcb55856-b6rtw   1/1     Running   0          6m3s
web-api-6bdcb55856-ctqmr   1/1     Running   1          6m7s
web-api-6bdcb55856-zfscv   1/1     Running   0          6m5s

Notice how the second entry has a restart count of one, while the others have a restart count of zero. This is because the container had crashed and Kubernetes automatically restarted it for me. Depending on how quickly you ran the command, you might either see the restart count set to one or the count set to zero but with a status of Error—an indication that Kubernetes hasn’t yet restarted the container.