Understanding Kubernetes Architecture: A Beginner’s Guide

Updated: January 30, 2024 By: Guest Contributor Post a comment

Introduction

Kubernetes, also known as K8s, has emerged as the go-to container orchestration platform, automating the deployment, scaling, and operations of application containers across clusters of hosts. Created by Google and now maintained by the Cloud Native Computing Foundation, Kubernetes simplifies cloud-native application development and deployment. In this tutorial, we will explore Kubernetes architecture and fundamentals, ideal for those just starting on their Kubernetes journey.

Kubernetes Architecture

At a high level, Kubernetes follows a client-server architecture. The primary components include the control plane (or master node), worker nodes, and a command-line interface typically kubectl. Let’s break down each component.

  • Control Plane: The brain of the Kubernetes cluster that makes global decisions about the cluster (e.g., scheduling), as well as detecting and responding to cluster events (e.g., starting up a new pod when a deployment’s replicas field is unsatisfied).
  • Worker Nodes: These machines perform the requested, assigned tasks. Each worker node has a Kubelet, which is an agent that communicates with the control plane, and containers that are managed by Kubernetes.
  • Pods: The smallest deployable units of computing that can be created and managed in Kubernetes. A pod is a collection of one or more containers.

Core Components of the Control Plane

The control plane’s components include the API server, etcd, scheduler, controller manager, and cloud controller manager. Let’s dive into each of these:

  • API Server (kube-apiserver): The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. It is the front end for the Kubernetes control plane.
  • etcd: A consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.
  • Scheduler (kube-scheduler): Watches for newly created pods with no assigned node, and selects a node for them to run on.
  • Controller Manager (kube-controller-manager): Runs controller processes. These controllers include:
    • Node Controller: Responsible for noticing and responding when nodes go down.
    • Replication Controller: Responsible for maintaining the correct number of pods for every replication controller object in the system.
    • Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
    • Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
  • Cloud Controller Manager (cloud-controller-manager): Lets you link your cluster into your cloud provider’s API, and separates out the components that interact with that cloud platform from components that just interact with your cluster.

Node Components

The nodes bear the services necessary to run pods and are managed by the control plane. Each node has the services necessary to run pods and is managed by the master components. The services on a node include docker, kubelet, kube-proxy, and Container Runtime Interface (CRI) which is responsible for running containers.

Kubelet

Manages pods and the containers running on a machine. It connects to the Docker daemon to launch containers. Here’s how you can view the status of the Kubelet:

systemctl status kubelet.service

Container Runtime

The software responsible for running containers. Docker is a popular option, but you also have other choices like containerd, CRI-O, rkt, etc.

kube-proxy

Maintains network rules on nodes. These network rules allow network communication to your pods from network sessions inside or outside of your cluster.

Using kubectl to Interact with the Cluster

The kubectl command-line tool is used to deploy applications, inspect and manage cluster resources, and view logs. Below are some common kubectl commands:

Getting cluster information:

kubectl cluster-info

Listing Pods in the default namespace:

kubectl get pods

Listing all nodes in the cluster:

kubectl get nodes

Deploying Your First Application

Applications in Kubernetes are deployed as pods. Here’s an example deployment of an nginx server pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Save the above yaml to a file named nginx-pod.yml and run the following command:

kubectl apply -f nginx-pod.yml

Check the status of your pod with:

kubectl get pods

Scaling Your Application

To handle increasing load on your application, you need to scale your deployment. This can be this easily with the kubectl scale command:

kubectl scale --replicas=3 deployment/nginx-deployment

Updating Your Application

With Kubernetes, you can perform a rolling update to your application, ensuring no downtime:

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

Persistent Storage

In Kubernetes, persistent storage is provided by PersistentVolumes (PV) and PersistentVolumeClaims (PVC). Here is an example to claim a PV:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

Volume can then be used by a pod by referencing this claim:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - mountPath: "/var/www/html"
      name: my-volume
  volumes:
  - name: my-volume
    persistentVolumeClaim:
      claimName: my-pvc

Networking in Kubernetes

Every pod is assigned a unique IP address. Pods can communicate with all other pods connected to the same node, while services manage to load balancing across different pods and expose them to the external world.

Conclusion

In this guide, we’ve laid down the foundations of Kubernetes architecture, showing you basic to moderately advanced topics. With the examples provided, you have the essential knowledge needed to get started on your Kubernetes journey. It’s crucial to practice with real scenarios, explore more complex objects like services and deployments, and customize configurations for your specific needs.