II ‐ Containers Orchestration: Kubernetes
The Container Orchestration landscape has evolved significantly in recent years, with Kubernetes emerging as the de facto standard for managing containerized applications at scale. This chapter will explore the key concepts and components of Kubernetes, as well as its lightweight counterpart, K3s, and other related technologies.
The word "Kubernetes" originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014.
Kubernetes is an open-source container orchestration platform designed to automate the deployment, scaling, and management of containerized applications. It provides a robust framework for managing clusters of hosts running Linux containers, allowing users to easily deploy and manage applications in a highly available and scalable manner. The Overview of the official documentation describes extremely well the capabilities of Kubernetes.
"Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn't it be easier if this behavior was handled by a system?
That's how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more. For example: Kubernetes can easily manage a canary deployment for your system.". Go read the official documentation, it's aS tierdocumentation.
Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Learn about the Kubernetes object model and how to work with these objects. Again the Official Documentation of Kubernetes - Working with objects is very helpful. You provide the information to kubectl in a file known as manifest. It can be write int YAML or JSON format, exemple of a manifest for an Object called Deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80An object in Kubernetes is a persistent entity that represents the desired state and configuration of resources within a cluster, such as deployments, services, or pods.
A workload is an application running on Kubernetes. Whether your workload is a single component or several that work together, on Kubernetes you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster.
Kubernetes pods have a defined lifecycle. For example, once a pod is running in your cluster (we defined that later) then a critical fault on the node (same we defined that later) where that pod is running means that all the pods on that node fail. Kubernetes treats that level of failure as final: you would need to create a new Pod to recover, even if the node later becomes healthy.
However, to make life considerably easier, you don't need to manage each Pod directly. Instead, you can use workload resources that manage a set of pods on your behalf. These resources configure controllers that make sure the right number of the right kind of pod are running, to match the state you specified.
In summary, workload resources in Kubernetes automate the management of pods, ensuring the desired state of your applications is maintained without manual intervention. Official Documentation of Kubernetes - Workloads Resources
A Deployment manages a set of Pods to run an application workload, usually one that doesn't maintain its own state. Deployments are responsible for creating and updating instances of your application, ensuring that the desired number of replicas are running at all times. A Deployment provides declarative updates for Pods and ReplicaSets (we'll see that later), and do Rollbacks.
You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
A Deployment is a Kubernetes object that provides declarative updates to applications, allowing you to manage the desired state of your application easily.
Official Documentation of Kubernetes - Deployments
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. Usually, you define a Deployment and let that Deployment manage ReplicaSets automatically.
It is often used to ensure the high availability and reliability of an application. It manages permanently the current number of running Pods and ensures that the desired state (the desired number of Pods) is maintained.
If a Pod fails or is deleted, the ReplicaSet automatically creates a new Pod to replace it, maintaining the desired number of replicas.
What is a replica?
A replica is a copy of a Pod that is running in the cluster. ReplicaSets ensure that a specified number of replicas are running at all times, providing high availability and fault tolerance for applications.
ReplicaSet is a Kubernetes object that ensures a specified number of pod replicas are running at all times, providing high availability and fault tolerance.
Official Documentation of Kubernetes - ReplicaSets
A Kubernetes cluster consists of a control plane plus a set of worker machines, called nodes, that run containerized applications. Every cluster needs at least one worker node in order to run Pods. The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
A cluster is a set of machines (nodes) running containerized applications, managed by a control plane that orchestrates workloads and resources for high availability and scalability. Official Documentation of Kubernetes - Cluster Architecture
The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a Deployment's replicas field is unsatisfied).
-
kube-apiserver: The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.kube-apiserveris designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances. -
etcd: Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. Official Documentation ofetcd. -
kube-scheduler: Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on. The scheduler ranks available nodes for the pod and places it on the best one. -
kube-controller-manager: The controller manager runs controllers that monitor the state of the cluster and make adjustments as needed to maintain the desired state. There are many different types of controllers: Node Controller, Job Controller, EndpointSlice controller, and more.
The control plane is responsible for managing the overall state of the cluster, including scheduling pods, maintaining desired replicas, and responding to failures.
Official Documentation of Kubernetes - Control Plane
A worker node is a physical or virtual machine in a Kubernetes cluster that runs containerized applications. Each worker node hosts one or more Pods, and is managed by the control plane. Worker nodes communicate with the control plane to receive instructions and report on their status. Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node.
The components on a node include the kubelet, a container runtime, and the kube-proxy (we see later what is all these components, particulary the kubelet. For now, imagine the kubelet as the primary "node agent" that communicates with the control plane).
Two main ways to have Nodes added to the API server:
- The kubelet on a node self-registers to the control plane
- You (or another human user) manually add a Node object
After you create a Node object, or the kubelet on a node self-registers, the control plane checks whether the new Node object is valid. If it is not (a not valid node is called unhealthy, which means all necessary services are not running, instead it called healthy), the control plane will mark the Node as unhealthy and may take action to remediate the issue.
A Node (or Worker Node) is a physical or virtual machine in a Kubernetes cluster that runs containerized applications.
Official Documentation of Kubernetes - Nodes
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
-
kubelet: The primary "node agent" that communicates with the control plane. It is responsible for managing the lifecycle of containers on the node, including starting, stopping, and monitoring them. The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes. - Container runtime: A fundamental component that empowers Kubernetes to run containers effectively. It is responsible for managing the execution and lifecycle of containers within the Kubernetes environment.
-
kube-proxy(optional): A network proxy that runs on each node and is responsible for maintaining network rules on the node. It enables network communication to your Pods from network sessions inside or outside of your cluster.
A Node Component is a core element that contributes to the functionality and management of a node within a Kubernetes cluster. kubelet is the primary component responsible for managing the lifecycle of containers on the node.
Official Documentation of Kubernetes - Node Components
Controllers are control loops that watch the state of your cluster, then make or request a changes where needed. They help to ensure that the desired state of the system matches the actual state. If there is a discrepancy, the controller takes action to bring the actual state closer to the desired state.
"Control loop" means a feedback mechanism that continuously monitors the state of a system and makes adjustments as necessary to achieve the desired outcome. It monitors permanently the state of the system and takes corrective actions when needed.
Example: You define a Deployment that specifies three replicas of a specific Pod. If, for any reason, one of the Pods fails, the Deployment controller detects that only two Pods are running (while three are desired) and creates a new Pod to restore the desired state.
Controllers play a crucial role in maintaining the desired state of applications running in a Kubernetes cluster.
Official Documentation of Kubernetes - Controllers
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. A Namespace is created in a Node.
"Users" refers to individuals or groups who interact with the Kubernetes cluster, such as developers, operators, and automated systems. For example, an organization can have multiple teams working on different projects, each within its own namespace, with their own set of resources and access controls: environments.
The resources who can be isolated within a namespace include Pods, Services, and other Kubernetes objects.
Each resource in Kubernetes (such as Pods, Services, etc.) belongs to a Namespace, and resource names must be unique within a given Namespace, but not necessarily across different Namespaces.
Why using Namespaces?
Two exemples:
- A big multinational is on multiple project. Each project can have its own namespace, allowing teams to work independently without interfering with each other's resources, inside the same Node, inside the same cluster. It can be a Namespace for development, testing, or production, or even a Namespace for literally another project like it says juste before.
- A small startup is developing only a new application. Namespaces can be not necessary if the Node has less than a tens of users who work on the same application.
Namespaces provide a way to divide cluster resources between multiple users (via resource quota) and to manage access to these resources (via role-based access control). They help in organizing resources and can be used to apply policies at a granular level.
Official Documentation of Kubernetes - Namespaces
A Pod is the smallest deployable unit in Kubernetes, representing a single instance of a running process in your cluster. Pods can contain one or more containers, and they share the same network namespace, allowing them to communicate with each other easily. Pods are designed to run a single application or service, and they can be scaled up or down based on demand. They also provide a way to manage the lifecycle of containers, including starting, stopping, and restarting them as needed.
A Pod is similar to a set of containers with shared namespaces and shared filesystem volumes.
Pods in a Kubernetes cluster are used in two main ways:
- Single-container Pods: The "one-container-per-Pod" model is the most common Kubernetes use case. In this case, you can think of a Pod as a wrapper around a single container; Kubernetes manages Pods rather than managing the containers directly.
- Multi-container Pods: A Pod can encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers form a single cohesive unit.
Grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled.
Exemple of a single-container Pod manifest which consists of a container running the image nginx:1.14.2: Official Documentation of Kubernetes - Pod
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80Very useful Documentation about Nodes and Pods: Viewing Pods and Nodes
Another illustration of what is a Pod:
Expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends. A Service is a Kubernetes object that exposes an application running on a set of Pods as a network service. Services provide an abstraction that defines a policy for accessing a group of Pods.
-
Stability: Even though Pods are ephemeral and can be created or destroyed dynamically, a Service provides a stable access point to those Pods via a stable IP address and DNS name.
-
Load balancing: A Service can balance network traffic across the Pods that match its selectors, distributing incoming requests evenly among the available backends.
-
Service discovery: Services enable applications inside the cluster to discover and communicate with each other.
There are several types of Services in Kubernetes, each designed for different use cases:
-
ClusterIP: The default type. The Service is exposed on an internal IP within the cluster, making it accessible only from inside the cluster. -
NodePort: Exposes the Service on each node’s IP at a static port, allowing access from outside the cluster using the node’s IP and that port. -
LoadBalancer: Exposes the Service externally using a load balancer provided by the cloud provider (e.g., AWS, GCP). It automatically creates a load balancer that routes traffic to the Service. -
ExternalName: Maps the Service to an external DNS name, allowing use of external services as if they were part of the cluster.
Exemple:
Suppose you have a web application running across multiple pods. You can create a Service of type ClusterIP to allow other applications inside the cluster to access your web application. If you want your application to be accessible from outside the cluster, you could use a Service of type LoadBalancer.
Here's an exemple of a Service of type ClusterIP:
apiVersion: v1
kind: Service
metadata:
name: my-clusterip-service
spec:
type: ClusterIP # It's optional as ClusterIP is the default type
selector:
app: MyApp # This selector must match the labels of the pods you want to include in this service
ports:
- protocol: TCP
port: 80 # The port that the service will expose
targetPort: 9376 # The port on which the pods are listeningIn this example, the Service named my-clusterip-service listens on port 80 and routes traffic to the pods with the label app: MyApp on port 9376.
Services are used to expose applications running on a set of Pods as a network service, providing stable endpoints for communication, load balancing, service discovery and more.
Official Documentation of Kubernetes - Services
An Ingress is a collection of rules that allow inbound connections to reach the cluster services. It provides HTTP and HTTPS routing to services based on the request host and path. Ingress can also provide load balancing, SSL termination, and name-based virtual hosting.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80It's an API object that manages external access to services in a cluster, typically via HTTP/HTTPS. It acts as an entry point for incoming network traffic and lets you define rules to route that traffic to different services within the Kubernetes cluster.
Ingress can also provide load balancing, SSL termination, and name-based virtual hosting.
It's a little more complicated than that, but that's the gist of it. It's strongly recommended to check the official documentation for more details.
Official Documentation of Kubernetes - Ingress
Here's a very comprehensive schema of how Kubernetes works to finish this chapter:
