Kubernetes is an open source system used to automate management of containerized applications. A containerized application, simply means an application that runs inside a container. The management part refers, among other things to:

  • Deployment of changes
  • Rollbacks
  • Load balancing and discoverability
  • Secret and configuration management
  • Container placement
  • Scaling applications

Kubernetes clusters

A Kubernetes cluster is a set of machines that are configured in a way that allows us to tell Kubernetes that we need to run our application without having to worry about exactly where it runs. A Kubernetes cluster consists of two things:

  • Control Plane
  • Nodes

The Control Plane refers to hosts that are responsible for managing the cluster, while the Nodes are the hosts where applications are run.

Kubernetes Nodes need to have a container management system (Docker, for example) as well as an agent used for communicating with the Control Plane. The name of this agent is Kubelet.

When we need to perform and operation on the Kubernetes cluster (For example, deploy an application), we tell the Control Plane that we want to deploy the application. The Control Plane will then decide in which Nodes it should run the application and communicate with those nodes to get the application to the desired state.

Creating a cluster

Creating a cluster from scratch it’s not a simple task. Instead, we are going to create a cluster in Google Cloud. This cluster might incur some costs (Less than 1 USD if we run it for one day), but we are going it to tear it down at the end of this article.

I assume that you have a Google Cloud account and gcloud cli set up. You can take a look at my introduction to Google Cloud CLI, if you need help setting it up.

We can use this command to verify we are connected to the right account:

1
gcloud auth list

To list all our Kubernetes clusters we can use this command:

1
gcloud container clusters list

If we don’t have any clusters running, the command won’t return any output.

Before we create a cluster we need to install kubectl, which is a command line utility to interact with our Kubernetes cluster.

In Linux, we can download it:

1
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

And then install it:

1
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

To keep costs at a minimum, we are going to be creating a cluster with only 1 node:

1
gcloud container clusters create our-test-cluster --zone us-central1-a --num-nodes 1

After some time, our cluster will be ready. We can see the status of the cluster using gcloud:

1
2
3
gcloud container clusters list
NAME              LOCATION     MASTER_VERSION   MASTER_IP       MACHINE_TYPE  NODE_VERSION     NUM_NODES  STATUS
our-test-cluster  us-central1  1.20.10-gke.301  104.197.87.172  e2-medium     1.20.10-gke.301  9          RUNNING

Configuring kubectl

Now that we have our cluster running, we need to configure kubectl so it can manage this cluster. kubectl, has the concept of context, which basically means the cluster the tool will talk to if no other cluster is specified with the --cluster flag.

To get the current context:

1
kubectl config current-context

If a context hasn’t been set, we will recieve a message saying so. To set our context we can:

1
gcloud container clusters get-credentials our-test-cluster --zone us-central1-a

After doing that, the context will be set:

1
2
kubectl config current-context
gke_test-123456_us-central1_our-test-cluster

The information kubectl uses to connect to a cluster is stored under ~/.kube/config.

Deploying an application

Now that we have kubectl set up, we can use it to deploy applications in our cluster.

Before we deploy our application we need to get familiar with some concepts. First of all, I’ll assume you are familiar with what an image and a container are in the Docker world. On top of these concepts, Kubernetes introduces the concept of pod. A pod is a group of one or more containers with shared storage and network resources. These containers always run together in a single node.

Basically, a pod contains a group of application containers that always need to run together.

Pods are the unit of deployment in Kubernetes. We don’t deploy containers, we deploy pods. We can deploy a pod that consists of a single container with this command:

1
kubectl create deployment echo-server-deployment --image=ealen/echo-server --replicas=1

echo-server-deployment is the name of our deployment. ealen/echo-server is the name of the docker image we are deploying, --replicas=1 means that we only want one instance of this pod to run.

We can see our deployments:

1
2
3
kubectl get deployments
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
echo-server-deployment   1/1     1            1           2m10s

The READY column tells us how many of our replicas are ready to be used by our end users. It follows the format <ready>/<desired>.

UP-TO-DATE tells us how many replicas have been updated to the latest desired state. Currently it shows that all our pods are UP-TO-DATE, but during a rolling deployment this number might be lower than our total replicas for some time.

AVAILABLE tells us how many replicas are available to our users.

We can also see our pods:

1
2
3
kubectl get pods
NAME                                     READY   STATUS    RESTARTS   AGE
echo-server-deployment-c4dd99ffc-2kmkh   1/1     Running   0          2m34s

We can see the name of the pod starts with the name of our deployment. In this case, READY means how many containers of our pod are available to our users. Since our pod has only one container, it only shows 1/1.

Let’s scale our deployment so we are running two pods instead of just one:

1
kubectl scale deployment/echo-server-deployment --replicas=2

If we check our deployment, we will see that we now have 2 replicas:

1
2
3
kubectl get deployments
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
echo-server-deployment   2/2     2            2           9m53s

If we inspect the pods, we’ll see that both of them are running in the same node because we only have one:

1
2
3
4
kubectl get pods -o wide
NAME                                     READY   STATUS    RESTARTS   AGE     IP          NODE                                              NOMINATED NODE   READINESS GATES
echo-server-deployment-c4dd99ffc-q52bj   1/1     Running   0          3m40s   10.0.0.12   gke-our-test-cluster-default-pool-ad01764f-trn6   <none>           <none>
echo-server-deployment-c4dd99ffc-s8g6t   1/1     Running   0          13m     10.0.0.10   gke-our-test-cluster-default-pool-ad01764f-trn6   <none>           <none>

If we describe the deployment we can see the change we made in the events:

1
2
3
4
5
6
7
8
9
10
kubectl describe deployment/echo-server-deployment

...

Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  17m   deployment-controller  Scaled up replica set echo-server-deployment-c4dd99ffc to 1
  Normal  ScalingReplicaSet  8m5s  deployment-controller  Scaled up replica set echo-server-deployment-c4dd99ffc to 2

We successfully scaled our application.

Troubleshooting

Kubernetes provides a set of tools that can be used to diagnose problems if they arise. Let’s look at some of them.

If we want to see all the pods in our cluster we can use:

1
kubectl describe pods

This will output a lot of information if we have a lot of pods in a cluster. If we only care about a single pod, we can use:

1
kubectl describe pods/<pod id>

The output of the describe command contains a lot of useful information. Some of it is the id of the node where the pod is running, information about the containers and their state, and the last events that have happened in the pod. If there are issues starting containers, or passing health checks, these will be visible in the events.

Another way to troubleshoot problems with a pod is to look at the logs:

1
kubectl logs <pod id>

If this is not enough, we can get a shell to a container:

1
kubectl exec -it <pod id> -- sh

If our pod has more than one container, we need to specify which container we want to connect to:

1
kubectl exec -it <pod id> -c <container name> -- sh

Services

When we deploy an application in Kubernetes, all pods are given a private IP address that allows them to communicate with other pods in the same cluster.

The problem with is that pods can come and go, so it’s hard to keep track of the IPs we need to call to reach a service. We need something like a load balancer where pods can register so it’s easy to find a specific service. This is what services do.

The simplest service type is the ClusterIP (which is the default). This creates an IP address in the private network and acts as a load balancer that will redirect requests to that IP to the desired pods.

By default, there is a service called kubernetes:

1
2
3
kubectl get services
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.3.240.1   <none>        443/TCP   31m

This service is used by pods to find the control plane host. To expose our own service, we can use the following command:

1
kubectl expose deployment/echo-server-deployment --port 80

We can now see our service:

1
2
3
4
kubectl get services
NAME                     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
echo-server-deployment   ClusterIP   10.3.248.92   <none>        80/TCP    34s
kubernetes               ClusterIP   10.3.240.1    <none>        443/TCP   6m29s

Since the IP assigned to the service is internal to the cluster (10.3.248.92), we need to get in the cluster to test that it’s doing what we want. We can do this by getting a shell into a pod:

1
kubectl exec -it <pod id> -- sh

From inside the pod, we can use wget to make a request:

1
wget 10.3.248.92?query=test -O output

If we then check the pod logs, we are going to see that requests are balanced between both pods:

1
kubectl logs <pod id>

Cleaning up

Now that we are done playing around, we can destroy our cluster so we are not charged for it anymore:

1
gcloud container clusters delete our-test-cluster --zone us-central1-a

Conclusion

In this article we scratched the surface of what can be done with Kubernetes. We created a cluster and deployed some pods using a docker image. We also learned some debugging tools that will be used to diagnose problems in our future clusters.

[ architecture  docker  gcp  ]
GKE - Insufficient regional quota to satisfy request: resource "IN_USE_ADDRESSES"
Introduction to Google Cloud Run
Introduction to Google App Engine
Introduction to Google Firestore
Introduction to Google Cloud Functions