An Introduction to Kubernetes

Control Plane

The control plane refers to the set of components responsible for managing the cluster. It makes decisions about the cluster, such as scheduling, scaling and managing the state of applications. In a way, it is the 'brain' residing in the master node. These components are:

1. API server (kube-apiserver)

   The API server is the component which exposes the Kubernetes API. It is the interface for managing RESTful API commands, such as requests from users, administrators, and other Kubernetes components.

2. Controller manager (kube-controller-manager)

   The controller manager monitors the cluster and makes changes to maintain the desired state, such as the creation of new pods if required. It is the 'decision-maker' of Kubernetes.

3. Scheduler (kube-scheduler)

   It watches for newly created pods with no assigned node, and selects a node for them to run on.

4. etcd

   Consistent and highly-available key value store used as Kubernetes' underlying storage system (backing store) for all cluster data. It holds the desired state of the cluster and persists information like the configuration of deployments, services and nodes.

5. (Cloud) controller-manager

   The cloud controller manager links the cluster into the cloud provider's API. It only runs controllers that are specific to the cloud provider. The cluster does not have a cloud controller manager if Kubernetes is run only in the local machine.

Node components

Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment. These components are:

1. kubelet

   The kubelet is an agent that runs on each node in the cluster. It communicates with the API server to check the current state of the cluster. It also makes sure that containers are running in a pod.

2. Container runtime

   It enables Kubernetes to run containers effectively. It is responsible for managing the execution and lifecycle of containers within the Kubernetes environment. Kubernetes supports container runtimes such as containerd, CRI-O, and any other implementation of the Kubernetes CRI (Container Runtime Interface).

3. kube-proxy

   The kube-proxy maintains network rules on nodes. It enables pod-to-pod communication, load balancing, and service discovery across the cluster.

1. Pod

   A Pod is the smallest and simplest unit in Kubernetes. The containers in a Pod share the same network, storage, and namespace. Kubernetes pods have a defined lifecycle, meaning that if the node where the Pod is running becomes faulty, the Pod will not be automatically rescheduled; instead, a new Pod needs to be created. However, Pods do not need to be managed manually. Kubernetes provides workload resources, such as Deployments, StatefulSets, and DaemonSets, to automatically create and manage Pods, ensuring availability and scalability.

2. ReplicaSet

   A ReplicaSet ensures that a specified number of Pod replicas are running at any given time. It is primarily used by Deployments to manage scaling and Pod replacement during updates.

3. Deployment

   Although ReplicaSets would seem to meet the requirements for high availability, it is rarely used on its own. Instead a Deployment is used. It improves on the features provided by ReplicaSets. For example, a Deployment allows rolling updates, meaning a new version of the application can be rolled out gradually without downtime. In addition, a Deployment provide easy rollbacks to a previous stable version in the event of an update failure. Finally, a Deployment can be scaled easily. Kubernetes automatically creates a ReplicaSet to manage the Pods when a Deployment is created.

4. Service

   A Service is an abstraction that exposes groups of Pods over a network. It groups a set of pods and defines a stable network endpoint with policies for accessing them. Since Pods are ephemeral and can be replaced, their IP addresses can change dynamically. A Service ensures consistent access to these Pods using label selectors. Common types of services include ClusterIP (default), NodePort, LoadBalancer, and ExternalName.

5. StatefulSet and DaemonSet

   StatefulSets and DaemonSets are Kubernetes workload controllers used for specific use cases. StatefulSets are used to manage stateful applications such as databases, where each pod in a set must have a unique identity and persistent storage. DaemonSets ensure that a single instance of a pod runs on every node in a cluster. They are useful for running system-level services such as logging, monitoring and backups.

6. ConfigMap and Secrets

   ConfigMaps store configuration data that can be accessed by containers in the form of environment variables or files. Secrets store sensitive data, such as passwords, tokens, or keys, securely. Secrets are encrypted and can be mounted into containers as environment variables or volumes.

7. Namespaces

   Similar to Docker, Namespaces provide a way to partition resources in the cluster.

1. Deployment configuration

   The YAML file below shows a configuration for a Deployment. It deploys the nginx app.

   
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: my-app
       spec:
         replicas: 3
         selector:
           matchLabels:
             app: my-app
         template:
           metadata:
             labels:
               app: my-app
           spec:
             containers:
               - name: my-container
                 image: nginx:latest
               

   
   

   The ReplicaSet and Pod information are configured within the Deployment YAML file under spec. The ReplicaSet is created automatically by the Deployment configuration (in yellow). It ensures that 3 Pods are always running. The selector ensures that the ReplicaSet manages Pods with this label (i.e. my-app).

   The Pod is defined inside the template section (in red). The label (i.e. my-app) must match the selector for the ReplicaSet to manage these Pods. The template defines the Pod's structure, including metadata and container specifications.

       spec:
         replicas: 3
         selector:
           matchLabels:
             app: my-app
         template:
           metadata:
             labels:
               app: my-app
           spec:
             containers:
               - name: my-container
                 image: nginx:latest
               

   
   

2. Apply the Deployment configuration

   
       kubectl apply -f deployment-file.yaml
               

   
   

3. Expose the workload

   Create a NodePort Service to expose the Pods. Apply it.

   
       apiVersion: v1
       kind: Service
       metadata:
         name: my-app-service
       spec:
         selector:
           app: my-app
         ports:
           - protocol: TCP
             port: 80              # the port the Service listens on
             targetPort: 80        # The port on the container 
             nodePort: 30001       # The port on the node (for external access)
         type: NodePort
               

   
   

   
       kubectl apply -f service-file.yaml
               

   
   

4. Verify the deployment

   The commands below will list all pods, deployments and services which have been created in the current namespace. The Nginx application can be verified by visiting http://localhost:30001 at the browser.

   
       kubectl get pods
       kubectl get deployments
       kubectl get services