Kubernetes is a technology plenty of features to manage containers. In this series of posts we will explore which I consider the 4 key concepts to understand whenever we want to deploy a simple application.

Source code of examples on GitHub

Brief Architectural Overview

Kubernetes is based on a master-worker architecture to make sure high availability of the applications deployed in a cluster, where workers are the servers or nodes (physical machines) where applications run, and master is a node responsible for monitoring and updating the status of workers, so in case a worker gets down the master is able to start a new one.

• The Control Plane: This is the controller node (master) which provides a set of functionalities to manage the Kubernetes cluster.

• API Server: This is a super set of REST API's which allow to perform CRUD operations to resources in the cluster.

• Nodes: Physical machines (servers) where applications run and scale.

• Kubelet: This is an agent (endless process) that runs in every node, being responsible for registering a node in the control plane so it can monitor it, and given a pod specification, kubelet starts the containers making sure they keep running until the control plane decides to stop, recreate or delete them.

• Container runtime: Kubernetes is agnostic of the technology to create containers, so it can be docker, container.d or whatever.

• kubectl: This is a command line application we can use to perform actions into the cluster. This is just a wrapper of the REST APIs provided by the API server.

Objects Versioning

Resources exposed by the REST APIs are called objects which are under version control. A complete list of objects we can manage in a cluster can be found here.

Objects can be described with .yaml files, and we can instruct the control plane to create or update them by running:

$ kubectl apply -f object-descriptor.yaml 

Let's review now how to describe Pods, ReplicaSet, Deployments and Services which is the purpose of this post.

Getting Started with a Pod

This is the basic unit of deployment in Kubernetes, a pod is deployed into a node and can start from 1 to many containers, along with other objects like volumes.

Pods are assigned a static IP address for internal communication, it means that we cannot ping pods from outside the cluster.

Describing a Pod

pod-nginx.yaml

1. apiVersion: v1
2. kind: Pod
3. metadata:
4.   name: nginx-yaml
5. spec:
6.   containers:
7.     - image: nginx
8.       name: nginx
9.       ports:
10.        - containerPort: 80
11.          name: http

Line 1: The version of the object we want to describe.
Line 7: Create a nginex container.
Line 10: Starts the container in the port 80.

Let's create and inspect the Pod

$ kubectl apply -f pod-nginx.yaml
$ kubectl describe pods nginx-yaml

Port Forwarding

There are many ways we can see containers from outside the cluster (we will talk about services further). By the moment, we can use port forwarding to see the nginx container running by:

$ kubectl port-forward --address 0.0.0.0 nginx-yaml 80:80

So if we go to the browser on http://localhost:80, we should see:

Scaling With A ReplicaSet

Whenever a pod gets down, the ReplicaSet object will start up a new one making sure always a fixed number of available pods. Have a look at the following descriptor, where we have told the ReplicaSet to keep 3 pods running:

replica-set-nginx.yaml

1. apiVersion: apps/v1
2. kind: ReplicaSet
3. metadata:
4.   name: nginx-replica-yaml
5.   labels:
6.     color: blue
7.     version: "1"
8. spec:
9.   replicas: 3
10.  selector:
11.    matchLabels:
12.      color: blue      
13.  template:
14.    metadata:
15.      labels:
16.        color: blue
17.    spec:
18.      containers:
19.        - image: nginx
20.          name: nginx
21.          ports:
22.            - containerPort: 80
23.              name: http

Line 9: The number of pods to keep alive.

Let's create and inspect the ReplicaSet

$ kubectl apply -f replica-set-nginx.yaml
$ kubectl describe  nginx-replica.yaml