DEV Community: Pratik Jagrut

Kubernetes: Deployments (Part-1)

Pratik Jagrut — Tue, 08 Oct 2024 20:08:24 +0000

Introduction

In the previous blog, we explored ReplicaSets and their importance in maintaining multiple identical pods for high application availability. However, in Kubernetes, we typically don't create ReplicaSets directly. Instead, we create higher-level objects such as Deployments, DaemonSets, or StatefulSets, which in turn manage ReplicaSets for us. In this blog, we'll delve into Deployments

Deployments are a crucial higher-level resource in Kubernetes, designed to manage the deployment and scaling of ReplicaSets, ensuring applications are always running in the desired state. We describe the desired state in the deployment configuration, and then the Deployment controller works to make the current state match the desired state.

Difference Between Deployments and ReplicaSets

Deployments and ReplicaSets have different roles in Kubernetes. A ReplicaSet ensures a specified number of pod replicas are always running, but it lacks advanced update features. Deployments, however, allow for easy updates and rollbacks for pods and ReplicaSets. They support rolling updates and rollbacks. While ReplicaSets keeps the right number of pods running, Deployments help manage application lifecycles, updates, and scaling without downtime, making them the better choice for managing stateless applications in Kubernetes.

Configuring a Deployment

Configuring a Deployment involves defining a YAML file that specifies the desired state of the application. This includes details such as the application's image, the number of replicas, any necessary secrets and ConfigMaps, and a strategy for updating the application, ensuring smooth transitions with minimal downtime. Once the configuration file is applied, the Deployment controller works to ensure that the actual state matches the desired state.

Below is a sample YAML configuration for a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Breakdown of the YAML File

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

apiVersion:
```
apiVersion: apps/v1
```
This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster. In this case, it uses apps/v1.
kind:
```
kind: Deployment
```
This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a Deployment.

metadata:

metadata:
  name: nginx-deployment
  labels:
    app: nginx

This section provides essential information about the Deployment:

name: This uniquely identifies the Deployment within its namespace (nginx-deployment). This is the only required field in metadata.
labels: Key-value pairs used to organize and select resources (app: nginx).

spec:

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

The spec section defines the desired state of the Deployment, including its pods and their configurations:

replicas: Specifies the number of pod replicas that the Deployment should maintain (3 in this case).
selector: Defines how the Deployment identifies the pods it manages.
- matchLabels: A set of key-value pairs used to match the pods (app: nginx). This should be the same as the labels in template.metadata.labels.
template: Describes the pod's configuration to be created.
- metadata: Includes labels to be applied to the pods.
- spec: Defines the pod's configuration.
  - containers: Lists the containers within the pod.
    - name: Identifies the container (nginx).
    - image: Specifies the Docker image to use (nginx:latest).
    - ports: Indicates which ports should be exposed by the container (containerPort: 80).
strategy: Defines the strategy for updating the Deployment.
- type: Specifies the update strategy. In this case, it is RollingUpdate, which updates pods in a rolling fashion with minimal downtime.
  - rollingUpdate: Specifies parameters for the rolling update strategy, such as maxUnavailable and maxSurge.

Creating a Deployment

To create a Deployment using the above YAML configuration, save the configuration to a file named nginx-deployment.yaml and apply it to the Kubernetes cluster using the following command:

kubectl apply -f nginx-deployment.yaml

Managing a Deployment

You can list the Deployments using the kubectl get deployments command:

kubectl get deployments

Output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           10s

You can use the kubectl describe command to check the state of the Deployment:

❯ kubectl describe deployments.apps/nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Mon, 15 Jul 2024 20:04:25 +0530
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 1 max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-57d84f57dc (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  54s   deployment-controller  Scaled up replica set nginx-deployment-57d84f57dc to 3

List the ReplicaSets:

❯ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-57d84f57dc   3         3         3       93s

List the pods:

❯ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-57d84f57dc-w5n9r   1/1     Running   0          2m11s
nginx-deployment-57d84f57dc-8mf7x   1/1     Running   0          2m11s
nginx-deployment-57d84f57dc-gv24t   1/1     Running   0          2m11s

Scaling the Deployment

You can scale the Deployment to a different number of replicas using the kubectl scale command:

❯ kubectl scale --replicas=5 deployment nginx-deployment
deployment.apps/nginx-deployment scaled

❯ kubectl get deployments
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   5/5     5            5           4m11s

❯ kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-57d84f57dc-w5n9r   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-8mf7x   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-gv24t   1/1     Running   0          4m24s
nginx-deployment-57d84f57dc-9gjph   1/1     Running   0          27s
nginx-deployment-57d84f57dc-t47qd   1/1     Running   0          27s

Deleting the Deployment

To delete the Deployment, use the following command:

kubectl delete deployment nginx-deployment

Deleting the Deployment will terminate all the pods it manages. If you want to keep the pods running after deleting the Deployment, use the --cascade=orphan flag:

kubectl delete deployment nginx-deployment --cascade=orphan

Conclusion

In summary, Deployments play a crucial role in managing the desired state of your applications by ensuring a specified number of pod replicas are running at all times. This not only enhances the availability and reliability of your applications but also simplifies the management of pods in a Kubernetes environment.

By defining a Deployment through a YAML file, you can easily control the number of replicas, monitor their status, and scale them as needed, ensuring your applications remain resilient and performant.

Thank you for reading this blog; your interest is greatly appreciated. I hope this information helps you on your Kubernetes journey. In the next part, we'll explore updating and rolling back Kubernetes deployments.

Kubernetes: ReplicaSet

Pratik Jagrut — Sun, 07 Jul 2024 12:59:14 +0000

In the last blog, we explored Pods and how they encapsulate containers to run workloads on Kubernetes. While Pods provide useful features for running workloads, they also have inherent issues due to their ephemeral nature—they can be terminated at any time. When this happens, the user application will no longer be available.

To avoid such situations and ensure the user application is always available, Kubernetes uses ReplicaSets (RS). A ReplicaSet creates multiple identical replicas of a pod and ensures a specific number of pods are running at all times—neither fewer nor more.

A ReplicaSet controller continuously monitors the pods to ensure that the number of desired pods equals the number of available pods at all times. If a pod fails, the ReplicaSet automatically creates more pods. Conversely, if new pods with the same label are added and there are more pods than needed, the ReplicaSet will reduce the number by stopping the extra pods.

Configuring a ReplicaSet

Configuring a ReplicaSet involves defining a YAML file that specifies the desired state for the ReplicaSet. This YAML file includes crucial details such as the number of replicas, the selector to identify the pods managed by the ReplicaSet, and the pod template that defines the pods to be created.

Below is a sample YAML configuration for a ReplicaSet using an Nginx container:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pods
  template:
    metadata:
      labels:
        app: nginx-pods
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Breakdown of the YAML File

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

apiVersion:
```
apiVersion: apps/v1
```
This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster. In this case, it uses apps/v1.
kind:
```
kind: ReplicaSet
```
This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a ReplicaSet.

metadata:

metadata:
  name: nginx-replicaset
  labels:
    app: nginx-rs

This section provides essential information about the ReplicaSet:

name: This uniquely identifies the ReplicaSet within its namespace (nginx-replicaset). This is the only field in metadata that is required.
namespace: Assigns a specific namespace for resource isolation (optional).
labels: Key-value pairs used to organize and select resources (app: nginx-rs).
annotations: These key-value pairs offer additional details about the Pod, useful for documentation, debugging, or monitoring (optional).
ownerReferences: Specifies the controller managing the Pod, establishing a relationship hierarchy among Kubernetes resources (optional).

spec:

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-pods
  template:
    metadata:
      labels:
        app: nginx-pods
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

The spec section defines the desired state of the ReplicaSet, including its pods and their configurations:

replicas: Specifies the number of pod replicas that the ReplicaSet should maintain (3 in this case).
selector: Defines how the ReplicaSet identifies the pods it manages.
matchLabels: A set of key-value pairs used to match the pods (app: nginx-pods). This should be the same as the labels in template.metadata.labels.
- template: Describes the pod's configuration to be created.
  - metadata: Includes labels to be applied to the pods.
  - spec: Defines the pod's configuration.
    - containers: Lists the containers within the pod.
    - name: Identifies the container (nginx).
    - image: Specifies the Docker image to use (nginx:latest).
    - ports: Indicates which ports should be exposed by the container (containerPort: 80).
  Additional optional fields for advanced configurations within the spec section include:
  - resources: Manages the pod's resource requests and limits.
  - volumeMounts: Specifies volumes to be mounted into the container's filesystem.
  - env: Defines environment variables accessible to the container.
  - volumes: Describes persistent storage volumes available to the pod.

Creating a ReplicaSet

To create a ReplicaSet using the above YAML configuration, save the configuration to a file named nginx-replicaset.yaml and apply it to the Kubernetes cluster using the following command:

kubectl apply -f nginx-replicaset.yaml

Managing ReplicaSet

You can list the replica sets using kubectl get replicaset command.

❯ kubectl get replicasets
NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   3         3         3       2m17s

You can use the kubectl describe command to check the state of the replica set.

❯ kubectl describe replicasets.apps/nginx-replicaset
Name:         nginx-replicaset
Namespace:    default
Selector:     app=nginx-pods
Labels:       app=nginx-rs
Annotations:  <none>
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  app=nginx-pods
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-rgxzx
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-prddh
  Normal  SuccessfulCreate  13s   replicaset-controller  Created pod: nginx-replicaset-rwvpn

You can list the pods using kubectl get pods command.

❯ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-xqcjm   1/1     Running   0          10s
nginx-replicaset-pzzhh   1/1     Running   0          10s
nginx-replicaset-k4lp4   1/1     Running   0          10s/

Scaling the ReplicaSet

You can scale the ReplicaSet to a different number of replicas using the kubectl scale command:

❯ kubectl scale --replicas=5 replicaset nginx-replicaset
replicaset.apps/nginx-replicaset scaled

❯ kubectl get replicasets
NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset   5         5         3       17m

❯ kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-replicaset-xqcjm   1/1     Running   0          17m
nginx-replicaset-pzzhh   1/1     Running   0          17m
nginx-replicaset-k4lp4   1/1     Running   0          17m
nginx-replicaset-79d96   1/1     Running   0          16s
nginx-replicaset-sdb5g   1/1     Running   0          16s

Updating the ReplicaSet

To update the ReplicaSet, such as changing the container image, you can modify the YAML file and apply the changes using:

kubectl apply -f nginx-replicaset.yaml

Alternatively, use the kubectl set image command to update the image directly:

kubectl set image replicaset/nginx-replicaset nginx=nginx:1.19

Deleting the ReplicaSet

To delete the ReplicaSet, use the following command:

kubectl delete rs nginx-replicaset

Deleting the ReplicaSet will terminate all the pods it manages. If you want to keep the pods running after deleting the ReplicaSet, use the --cascade=orphan flag:

kubectl delete rs nginx-replicaset --cascade=orphan

Scenarios Where RSs are Particularly Useful

High Availability: ReplicaSets ensure that a specified number of pod replicas are always running, which is crucial for applications requiring high availability.
Load Balancing: By maintaining multiple replicas of a pod, ReplicaSets help distribute the load evenly across all replicas, improving performance and reliability.
Fault Tolerance: If a pod fails, the ReplicaSet automatically replaces it, ensuring continuous availability of the application.
Rolling Updates: ReplicaSets can be used to perform rolling updates to applications, allowing updates without downtime by incrementally replacing old pods with new ones.
Scalability: Easily scale the number of pod replicas up or down based on demand, ensuring efficient use of resources.

Conclusion

In summary, ReplicaSets play a crucial role in maintaining the desired state of your applications by ensuring a specified number of pod replicas are running at all times. This not only enhances the availability and reliability of your applications but also simplifies the management of pods in a Kubernetes environment.

Benefits of Using ReplicaSets:

Enhanced Reliability: Ensures continuous application availability by maintaining multiple pod replicas.
Improved Uptime: Automatically replaces failed pods to maintain the desired number of running pods.
Simplified Scaling: Allows easy scaling of applications by adjusting the number of replicas.
Consistent Performance: Distributes the load evenly across replicas, maintaining application performance.

By defining a ReplicaSet through a YAML file, you can easily control the number of replicas, monitor their status, and scale them as needed, ensuring your applications remain resilient and performant.

Thank you for reading this blog; your interest is greatly appreciated. I hope this information helps you on your Kubernetes journey. In the next blog, we'll explore Kubernetes deployments.

Kubernetes Pod 101

Pratik Jagrut — Thu, 27 Jun 2024 15:26:14 +0000

With Kubernetes, our main goal is to run our application in a container. However, Kubernetes does not run the container directly on the cluster. Instead, it creates a Pod that encapsulates the container.

A Pod is the smallest object that you create and manage in Kubernetes. A Pod consists of one or more containers that share storage and network resources, all running within a shared context. This shared context includes Linux namespaces, cgroups, and other isolation mechanisms, similar to those used for individual containers.

In a Kubernetes cluster, Pods use two models to run containers.:

One-container-per-Pod model: This is the common use case in Kubernetes. A Pod acts as a wrapper for a container, with Kubernetes managing the Pod instead of the individual container. Refer to diagram POD-A.
Multi-containers Pod model: Pods can run multiple containers that work closely together. These Pods hold applications made up of several containers that need to share resources and work closely. These containers operate as a single unit within the Pod. Refer to diagram POD-B.

Anatomy of a Pod

Containers

Main Container

Primary Role: This is the application's primary container.
Example: If you have a web application, the main container will run the web server that serves your application.

Sidecar Containers

Supporting Role: These auxiliary containers support the main container, often used for logging, monitoring, or proxying tasks.
Example: For the same web application, a sidecar container might handle logging by collecting and storing log data generated by the web server.

Storage (Volumes)

Pods can include storage resources known as volumes, which enable data persistence across container restarts. Volumes in a Pod are shared among all containers in that Pod, allowing for data exchange between them.

Types of Volumes:
- emptyDir: A temporary directory that is created when a Pod is assigned to a node and deleted when the Pod is removed.
- hostPath: Maps a file or directory from the host node’s filesystem into a Pod.
- persistentVolumeClaim: A request for storage by a user that binds to a PersistentVolume (PV) in the cluster.
- configMap: Provides configuration data, command-line arguments, environment variables, or container files.
- secret: Used to store sensitive data such as passwords, OAuth tokens, and SSH keys.

Network

Each Pod is assigned a unique IP address. Containers within the same Pod share the network namespace, which means they can communicate with each other using localhost. Pods can communicate with each other using their assigned IP addresses.

Pod IP: A unique IP address assigned to each Pod.
DNS: Kubernetes automatically assigns DNS names to Pods and services, facilitating network communication within the cluster.

Pod Lifecycle

Like individual application containers, Pods are considered to be relatively temporary (rather than permanent) entities. Understanding the lifecycle of a Pod is crucial for effective management and troubleshooting.

Pods can be in one of several phases during their lifecycle. A Pod's status field is a PodStatus object, which has a phase field. The phase of a Pod is a simple, high-level summary of where the Pod is in its lifecycle.

Pending: The Pod has been accepted by the Kubernetes system but one or more container images have not been created.
Running: The Pod has been bound to a node, and all of the containers have been created. At least one container is still running or is in the process of starting or restarting.
Succeeded: All containers in the Pod have terminated successfully, and the Pod will not be restarted.
Failed: All containers in the Pod have terminated, and at least one container has terminated in failure.
Unknown: The state of the Pod cannot be obtained, typically due to an error in communicating with the node where the Pod resides.

Pod Conditions

Pods have a set of conditions that describe their current state. These conditions are used to diagnose and troubleshoot the status of Pods.

PodScheduled: Indicates whether the Pod has been scheduled to a node.
Initialized: All init containers have been completed successfully.
Ready: The Pod can serve requests and should be added to the load-balancer pools of all matching Services.
ContainersReady: All containers in the Pod are ready.
PodReadyToStartContainers: (beta feature; enabled by default) The Pod sandbox has been successfully created and networking configured.

Pod creation

A Pod can be created using two methods. The first method is by using the kubectl run command.

kubectl run --image nginx nginx-pod

The second method is declarative. In this approach, you create a Pod configuration file in YAML and apply it using the kubectl create or kubectl apply command. This method is widely used because it allows you to manage multiple versions of an application easily.

Create a configuration file named nginx-pod.yaml with the following content.

apiVersion: 
kind: 
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

kubectl apply -f nginx-pod.yaml

You can list the pods using kubectl get pods command.

❯ kubectl get pods
NAME        READY   STATUS    RESTARTS      AGE
nginx-pod   1/1     Running   0             5s

Let's break down the definition of a Pod in Kubernetes.

When writing any object in Kubernetes, you need to include certain required fields: apiVersion, kind, metadata, and spec.

apiVersion

This field specifies the version of the Kubernetes API that your object adheres to, ensuring compatibility with your Kubernetes cluster (e.g., v1).

kind: This field defines the type of Kubernetes object being created. In our YAML file, it indicates that we are creating a Pod.

metadata

This section provides essential information about the Pod:

name: This uniquely identifies the Pod within its namespace (e.g., nginx-pod).
namespace: Assigns a specific namespace to the Pod for resource isolation.
labels: These are key-value pairs used to organize and select resources (e.g., app: nginx).
annotations: These key-value pairs offer additional details about the Pod, useful for documentation, debugging, or monitoring.
ownerReferences: Specifies the controller managing the Pod, establishing a relationship hierarchy among Kubernetes resources.

spec

The spec section defines the desired state of the Pod, including its containers and their configurations:

containers: This list defines each container within the Pod.
- name: Identifies the container (e.g., nginx-container).
- image: Specifies the Docker image to use (e.g., nginx:latest).
- ports: Indicates which ports should be exposed by the container (e.g., port 80).

Additional Optional Fields: For more advanced setups, you can include additional fields within the spec section:

resources: Manages the Pod's resource requests and limits.
volumeMounts: Specifies volumes to be mounted into the container's filesystem.
env: Defines environment variables accessible to the container.
volumes: Describes persistent storage volumes available to the Pod.

Static pods

In Kubernetes, Static Pods offer a way to directly manage Pods on a node without the need for the Kubernetes control plane. Unlike regular Pods that are managed by the Kubernetes API server, Static Pods are managed directly by the Kubelet daemon on a specific node.

How Static Pods Work

Static Pods are defined by creating Pod manifest files on the node itself. These manifest files are usually located in a directory monitored by the Kubelet, such as /etc/kubernetes/manifests, or a directory specified in the Kubelet's configuration (kubelet.conf).

Key Characteristics of Static Pods

Node-Specific Management: Each node runs its instance of the Kubelet, which monitors a designated directory for Pod manifests. When a manifest file is detected or updated, the Kubelet creates, updates, or deletes the corresponding Pod on that node.
No Kubernetes API Interaction: Unlike regular Pods that are part of the Kubernetes API and etcd datastore, Static Pods are not managed via the API server. They do not appear in Kubernetes API responses and are not visible through tools like kubectl.
Use Cases: Static Pods are useful in scenarios where Pods need to run directly on a node, independent of the Kubernetes control plane. This can include bootstrapping components required for Kubernetes itself, or running critical system daemons that must be available even if the control plane is offline.

Creating Static Pods

To create a Static Pod:

Create a Manifest File: Write a Pod manifest YAML file specifying the Pod's metadata and spec, similar to how you define regular Pods.
Place in Watched Directory: Save the manifest file in the directory monitored by the Kubelet (/etc/kubernetes/manifests by default). This directory can be configured in the Kubelet configuration file by setting staticPodPath to the pod manifests path. Alternatively, it can also be passed to Kubelet through the --pod-manifest-path flag, but this flag is deprecated.'
If needed restart the kubelet:
```
systemctl restart kubelet
```

Static Pods in Kubernetes are managed directly by the Kubelet and are automatically restarted if they fail. The Kubelet ensures that each Static Pod's state aligns with its specified manifest file. Despite this direct management, Kubelet also attempts to create a mirror Pod on the API server for each Static Pod. This makes the static pod visible to the API server, however, the API server cannot control the pod.

Conclusion

Pods are the core units in Kubernetes, encapsulating containers with shared storage and network resources. They can run single or multiple containers, providing flexibility in application deployment. Understanding Pods' anatomy, lifecycle, and creation methods, including static Pods, is crucial for efficient and scalable application management in Kubernetes environments.

Pods in Kubernetes are inherently ephemeral and can be terminated at any time. Kubernetes uses controllers to effectively manage Pods, ensuring their desired state is maintained. ReplicationSet controllers ensure a specified number of Pod replicas are running. Other controllers like Deployments, StatefulSets, and DaemonSets cater to different use cases.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey. In the next blog, we'll explore Kubernetes controllers that are used to manage Pods.

Creating a Kubernetes Cluster with Kubeadm and Containerd: A Comprehensive Step-by-Step Guide

Pratik Jagrut — Sun, 23 Jun 2024 14:44:07 +0000

Kubeadm is a tool designed to simplify the process of creating Kubernetes clusters by providing kubeadm init and kubeadm join commands as best-practice "fast paths." - Kubernetes documentation

In this blog, we'll go through the step-by-step process of installing a Kubernetes cluster using Kubeadm.

Prerequisites

Before you begin, ensure you have the following:

Ensure you have a compatible Linux host (e.g., Debian-based and Red Hat-based distributions). In this blog, we're using Ubuntu which is a Debian-based OS.
At least 2 GB of RAM and 2 CPUs per machine.
Full network connectivity between all machines in the cluster.
Unique hostname, MAC address, and product_uuid for every node.
Ensure all the required ports are open for the control plane and the worker nodes. You can refer to Ports and Protocols or see the screenshot below.

Disable swap on all the nodes.

sudo swapoff -a
# disable swap on startup in /etc/fstab
sudo sed -i '/ swap / s/^/#/' /etc/fstab

Setup container runtime(Containerd)

To run containers in Pods, Kubernetes uses a container runtime. By default, Kubernetes employs the Container Runtime Interface (CRI) to interact with your selected container runtime. Each node needs to have container runtime installed. In this blog, we'll use containerd.

Run these instructions on all the nodes. I am using Ubuntu on all the nodes.

Enable IPv4 packet forwarding:

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# Apply sysctl params without reboot
sudo sysctl --system

Run sudo sysctl net.ipv4.ip_forward to verify that net.ipv4.ip_forward is set to 1

Specify and load the following kernel module dependencies:

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

Install containerd:

Add Docker's official GPG key:

sudo apt-get update
sudo apt-get -y install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Add the repository to Apt sources:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install containerd

sudo apt-get update
sudo apt-get -y install containerd.io

For more details, refer to the Official installation documentation

Configure systemd cgroup driver for containerd

First, we need to create a containerd configuration file at the location /etc/containerd/config.toml
```
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
```
Now, we enable the systemd cgroup driver for the CRI in /etc/containerd/config.toml at section [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] set SystemCgroup = true

OR we can just run
```
sudo sed -i "s/SystemdCgroup = false/SystemdCgroup = true/g" "/etc/containerd/config.toml"
```
Restart containerd
```
sudo systemctl restart containerd
```
Containerd should be running, check the status using:
```
sudo systemctl status containerd
```

Install kubeadm, kubelet and kubectl

Run these commands on all nodes. These instructions are for Kubernetes v1.30.

Installapt-transport-https, ca-certificates, curl, gpgpackages

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

Download the public signing key for the Kubernetes package repositories

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

Add theaptrepository for Kubernetes 1.30

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

Install kubelet, kubeadm and kubectl

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

This is optional, Enable the kubelet service before running kubeadm
```
sudo systemctl enable --now kubelet
```

Initialize the k8s control plane

Run these instructions only on the control plane node

kubeadm init

To initialize the control plane, run the kubeadm init command. You also need to choose a pod network add-on and deploy a Container Network Interface (CNI) so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start until a network is installed.

We will use Calico CNI, so set the --pod-network-cidr=192.168.0.0/16.
```
sudo kubeadm init --pod-network-cidr=192.168.0.0/16
```
Now, at the end of the kubeadm init command, you'll see kubeadm join command

sudo kubeadm join <control-plane-ip>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash <hash> copy it and keep it safe.
Run the following commands to set kubeconfig to access the cluster using kubectl
```
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
```
Now, check the node using
```
$ kubectl get nodes
NAME             STATUS     ROLES           AGE    VERSION
ip-zzz-zz-z-zz   NotReady   control-plane   114s   v1.30.2
```
The node is in NotReady state because message: 'container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized' reason: KubeletNotReady . After setting up the CNI, the node should be in a Ready state.

Set Up a Pod Network

We must deploy a Container Network Interface (CNI) based Pod network add-on so that Pods can communicate with each other.

Install the calico operator on the cluster.

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

Download the custom resources necessary to configure Calico.

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/custom-resources.yaml

Verify all the Calico pods are in running state.

$ kubectl get pods -n calico-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-6f459db86d-mg657   1/1     Running   0          3m36s
calico-node-ctc9q                          1/1     Running   0          3m36s
calico-typha-774d5fbdb7-s7qsg              1/1     Running   0          3m36s
csi-node-driver-bblm8                      2/2     Running   0          3m3

Verify that the node is in a running state

$ kubectl get nodes
NAME             STATUS   ROLES           AGE     VERSION
ip-xxx-xx-x-xx   Ready    control-plane   2m46s   v1.30.2

Join the worker nodes

Ensure containerd, kubeadm, kubectl, and kubelet are installed on all worker nodes, then run sudo kubeadm join <control-plane-ip>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash <hash>, which you can find at the end of the kubeadm init command's output.

Check the cluster state

Run these commands on the control-plane node since the worker nodes do not have the kubeconfig file.

Check if the worker nodes are joined to the cluster.

$ kubectl get nodes
NAME               STATUS   ROLES           AGE    VERSION
ip-xxx-xx-xx-xx    Ready    <none>          9m9s   v1.30.2
ip-yyy-yy-yy-yy    Ready    <none>          23s    v1.30.2
ip-zzz-zz-z-zz     Ready    control-plane   27m    v1.30.2

To add a worker role to the worker node we can use kubectl label node <node-name> node-role.kubernetes.io/worker=worker command.

$ kubectl get nodes
NAME               STATUS   ROLES           AGE     VERSION
ip-xxx-xx-xx-xx    Ready    worker          12m     v1.30.2
ip-yyy-yy-yy-yy    Ready    worker          3m51s   v1.30.2
ip-zzz-zz-z-zz     Ready    control-plane   31m     v1.30.2

Check the workload running on the cluster

$ kubectl get pods -A
NAMESPACE          NAME                                       READY   STATUS    RESTARTS   AGE
calico-apiserver   calico-apiserver-6fcb65fbd5-n4wsn          1/1     Running   0          35m
calico-apiserver   calico-apiserver-6fcb65fbd5-nnggl          1/1     Running   0          35m
calico-system      calico-kube-controllers-6f459db86d-mg657   1/1     Running   0          35m
calico-system      calico-node-ctc9q                          1/1     Running   0          35m
calico-system      calico-node-dmgt2                          1/1     Running   0          18m
calico-system      calico-node-nw4t5                          1/1     Running   0          9m49s
calico-system      calico-typha-774d5fbdb7-s7qsg              1/1     Running   0          35m
calico-system      calico-typha-774d5fbdb7-sxb5c              1/1     Running   0          9m39s
calico-system      csi-node-driver-bblm8                      2/2     Running   0          35m
calico-system      csi-node-driver-jk4sz                      2/2     Running   0          18m
calico-system      csi-node-driver-tbrrj                      2/2     Running   0          9m49s
kube-system        coredns-7db6d8ff4d-5f7s5                   1/1     Running   0          37m
kube-system        coredns-7db6d8ff4d-qj9r8                   1/1     Running   0          37m
kube-system        etcd-ip-zzz-zz-z-zz                        1/1     Running   0          37m
kube-system        kube-apiserver-ip-zzz-zz-z-zz              1/1     Running   0          37m
kube-system        kube-controller-manager-ip-zzz-zz-z-zz     1/1     Running   0          37m
kube-system        kube-proxy-dq8k4                           1/1     Running   0          9m49s
kube-system        kube-proxy-t2sw9                           1/1     Running   0          18m
kube-system        kube-proxy-xd6nn                           1/1     Running   0          37m
kube-system        kube-scheduler-ip-zzz-zz-z-zz              1/1     Running   0          37m
tigera-operator    tigera-operator-76ff79f7fd-jj4kf           1/1     Running   0          35m

Conclusion

Setting up a Kubernetes cluster with Kubeadm involves a clear and structured process. You can create a functional cluster by meeting all prerequisites, configuring the container runtime, and installing Kubernetes components. Using Calico for networking ensures seamless pod communication. With the control plane and worker nodes properly configured and joined, you can efficiently manage and deploy workloads across your Kubernetes cluster.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next article, we'll explore running workloads in the Kubernetes cluster.

Introduction to Kubernetes

Pratik Jagrut — Wed, 19 Jun 2024 19:24:20 +0000

What is Kubernetes?

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. - From Kubernetes Docs

In simpler terms, Kubernetes, also known as an orchestrator, is an open-source platform that automates the management of containers. Originally developed by Google as an internal container management project named Borg, Kubernetes was made open-source on June 7, 2014. In July 2015, it was donated to the Cloud Native Computing Foundation (CNCF).

Kubernetes means helmsman or pilot in Greek, reflecting its role in guiding containerized applications. It is also known as k8s, a shorthand that represents the 8 letters between the 'k' and the 's' .

Key Features

Kubernetes offers a robust set of features, including:

Automatic Bin Packing: Schedules containers automatically based on resource needs and constraints, ensuring efficient utilization without compromising availability.
Self-Healing: Replaces and reschedules containers from failed nodes, restarts unresponsive containers, and prevents traffic from being routed to them.
Horizontal Scaling: Scales applications manually or automatically based on CPU or custom metrics utilization.
Service Discovery and Load Balancing: Assigns IP addresses to containers and provides a single DNS name for a set of containers to facilitate load balancing.
Automated Rollouts and Rollbacks: Manages seamless rollouts and rollbacks of application updates and configuration changes, continuously monitoring application health to prevent downtime.
Secret and Config Management: Manages secrets and configuration details separately from container images, avoiding the need to rebuild images.
Storage Orchestration: Automatically mounts storage solutions to containers from local storage, cloud providers, or network storage systems.
Batch Execution: Supports batch execution and long-running jobs, and replaces failed containers as needed.
Role-Based Access Control (RBAC): Regulates access to cluster resources based on user roles within an enterprise.
Extensibility: Extends functionality through Custom Resource Definitions (CRDs), operators, custom APIs, and more.

With its extensive array of capabilities, Kubernetes simplifies the management of containerized applications, ensuring optimal efficiency and performance, while also providing scalability, resilience, and flexibility for diverse workloads.

Cluster Architecture

Kubernetes cluster has a straightforward yet elegant and efficient architecture, consisting of at least one master node, also known as a control-plane node, and at least one worker node. The diagram below illustrates the cluster architecture.

Control-plane node

The control plane is responsible for maintaining the overall state of the cluster. The control plane includes components like the API server, scheduler, controller manager, and etcd, which coordinate and manage the cluster operations.

kube-api-server

The Kubernetes API server serves as the core of the control plane. It exposes an HTTP API through which users, external components, and cluster components securely interact to manage the state of Kubernetes objects. It validates incoming requests before storing them and supports the incorporation of custom API servers to expand its functionality. Highly configurable, it accommodates diverse configurations and extensions to suit specific cluster requirements.

Scheduler

The Kubernetes scheduler watches for newly created pods without assigned nodes and selects suitable nodes for them. It retrieves resource usage data for each worker node from etcd via the API server. Additionally, it incorporates scheduling requirements specified in the pod's configuration, such as the preference to run on nodes labelled with specific attributes like "disk==ssd".

So basically, the scheduler is responsible for assigning a node to a pod based on available resources and scheduling constraints.

kube-controller-manager

The kube-controller-manager is a collection of different Kubernetes controllers, running as a single binary. It ensures that the actual state of objects matches their desired state. Each controller watches over its objects, maintains their state, and plays a specific role in maintaining the health and desired configuration of the cluster. Key controllers within kube-controller-manager include the ReplicaSet controller, Deployment controller, Namespace controller, ServiceAccount controller, Endpoint controller, and Persistent Volume controller.

cloud-controller-manager

The cloud-controller-manager includes the Node controller, Route controller, Service controller, and Volume controller. These controllers are responsible for interfacing with the cloud infrastructure to manage nodes, storage volumes, load balancing, and routing. They ensure seamless integration and management of cloud resources within the Kubernetes cluster.

ETCD

ETCD is a distributed key-value store used to persist the state of a Kubernetes cluster. New data is always appended, never replaced, and obsolete data is compacted periodically to reduce the data store size. Only the Kubernetes API server can communicate directly with ETCD to ensure consistency and security. The ETCD CLI management tool provides capabilities for backup, snapshot, and restore.

Worker node

A worker node in Kubernetes executes application workloads by hosting and managing containers, providing essential computational resources within the cluster. It consists of components such as the Kubelet, kube-proxy, and a container runtime interface(CRI) like Docker or containerd.

Kubelet

The kubelet operates as an agent on each node within the Kubernetes cluster, maintaining communication with the control plane components. It receives pod definitions from the API server and coordinates with the container runtime to instantiate and manage containers associated with those pods. The kubelet also monitors the health and lifecycle of containers and manages resources as per pod specifications.

kube-proxy

The kube-proxy is a network agent running on each node in the Kubernetes cluster. It dynamically updates and maintains the network rules on the node to facilitate communication between pods and external traffic. It abstracts the complexities of pod networking by managing services and routing connections to the appropriate pods based on IP address and port number.

Container Runtime

In Kubernetes, a container runtime is essential for each node to handle the lifecycle of containers. Some of the known container runtimes are Docker, CRI-O, containerd, and rkt. These runtimes interface with Kubernetes using the Container Runtime Interface (CRI), ensuring that containers are created, managed, and terminated as needed within the cluster.

Pod

In Kubernetes, you cannot directly run containers as you would with Docker. Instead, containers are grouped into units called pods. A pod can host multiple containers and is the smallest deployable object in Kubernetes.

How does all of this come together?

Let's see this with an example of pod creation:

First, define the pod by creating a YAML or JSON file that specifies its configuration, including container images, resource requirements, environment variables, storage volumes etc. This file acts as the pod's blueprint.

Once you have the pod definition file ready, you submit it to the Kubernetes API server using the kubectl command-line tool. For instance, you can apply the configuration with a command like kubectl apply -f pod-definition.yaml. Alternatively, you can create the pod directly with a command such as kubectl run my-pod --image=my-image.

The Kubernetes API server receives and validates the pod creation request, ensuring it meets all criteria. Once validated, it stores the pod definition in etcd, the cluster's key-value store.

The Kubernetes scheduler watches for newly created pods without assigned nodes. It interacts with the API server to get the pod configuration, evaluates the resource requirements and constraints, and then selects a suitable worker node for the pod, updating the pod configuration with the nodeName.

On the assigned node, the kubelet receives the pod definition from the API server. It manages pods and their containers, retrieves container images from a registry if needed, and uses the container runtime (like Docker or containerd) to create and start containers as specified and also set up storage as required. It monitors container health and can restart them based on defined policies. Meanwhile, kube-proxy configures networking rules for pod communication. When all containers are running and ready, the pod can accept traffic, showcasing Kubernetes' orchestration in maintaining application states.

Conclusion

Kubernetes is a robust platform for managing containerized applications, offering features that simplify deployment, scaling, and maintenance. This article covered its origins, core functionalities, and architecture. Leveraging Kubernetes enhances efficiency, resilience, and flexibility, making it essential for modern cloud-native environments.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next article, we'll explore how to install Kubernetes using the Kubeadm tool.

Introduction to Container Orchestration

Pratik Jagrut — Mon, 17 Jun 2024 06:06:03 +0000

Containerization has revolutionized how we develop and deploy software, streamlining processes and enhancing scalability. It all began modestly in 1979 with the introduction of chroot, a Unix feature that allowed applications to operate within a confined directory subset. This breakthrough laid the groundwork for application isolation, a crucial concept for modern containerization.

Building upon chroot, FreeBSD's introduction of jails in 2000 marked a significant advancement. Jails provided a more robust form of isolation within a FreeBSD environment, enabling multiple applications to run securely on the same host without interference. This development was pivotal in demonstrating the practicality of isolating software environments for enhanced security and efficiency.

Following FreeBSD, Solaris Containers (2004), also known as Zones refined containerization by introducing sophisticated resource management capabilities. Zones allowed administrators to allocate specific CPU, memory, and storage resources to each container, optimizing hardware utilization and paving the way for efficient data centre management.

Google's control group(cgroup), integrated into the Linux kernel in 2007, brought fine-grained resource control to Linux-based containers. This innovation enabled administrators to manage and isolate resource usage among groups of processes, enhancing predictability and performance in containerized environments.

The culmination of these advancements led to the creation of Linux Containers (LXC) in 2008, which provided a user-friendly interface for leveraging Linux kernel features like cgroups and namespaces. LXC enabled the creation and management of lightweight, isolated Linux environments, marking a significant milestone towards the widespread adoption of container technology.

In 2013, Docker revolutionized containerization with its user-friendly platform for creating, deploying, and managing containers. Initially built upon LXC, Docker later introduced its container runtime and libcontainer, which leveraged Linux namespaces, control groups, and other kernel features. Docker's standardized container format and tooling simplified application packaging and deployment, accelerating the adoption of containers in both development and production environments.

Around the same time, the technological landscape experienced a major shift in software architecture. It moved from monolithic applications, where all modules run on a single machine and are tightly coupled, to a more decentralized and scalable model known as microservices architecture. In the 2000s, the rise of microservices architecture and the adoption of cloud computing rapidly accelerated the use of containerization. However, efficiently managing and orchestrating these containers remains a significant challenge.

Challenges in Container Management

Efficiently managing and orchestrating these containers at scale remains a formidable task, presenting challenges such as:

Deployment: Deploying numerous containers across diverse environments requires meticulous handling of versions, dependencies, and configurations to ensure consistency and reliability.
Scaling: Applications must scale dynamically to meet varying demands, necessitating automated mechanisms that optimize resource usage without manual intervention.
Networking: Effective networking is essential for seamless service discovery, load balancing, and secure communication among containers, demanding robust management policies.
Resource Management: Efficient allocation of CPU, memory, and storage resources is critical to prevent performance bottlenecks and control operational costs effectively.
Security: Ensuring container security requires implementing strict access controls, secure configurations, and isolation strategies to mitigate risks of breaches.
High Availability: Maintaining application availability involves proactive management of container failures, load balancing, and resilient failover strategies to minimize downtime.

Addressing these challenges is crucial for leveraging the full potential of containerization, enabling agility, scalability, and efficiency in software development and deployment.

Container Orchestration

While containerization has revolutionized software deployment, efficiently managing and scaling containerized applications across complex environments remains a daunting task. Container orchestration addresses these challenges by automating deployment, scaling, and management processes, ensuring applications run seamlessly from development through to production.

Container Orchestrators

Container orchestrators are tools that group systems together to form clusters where container deployment and management are automated at scale while meeting the production requirements.

They provide essential functionalities such as:

Automated Deployment: Simplifying the deployment process with declarative configurations and automated rollouts.
Scalability: Enabling horizontal scaling of applications based on resource demands, ensuring performance and efficiency.
Networking Automation: Facilitating efficient networking by managing service discovery, load balancing, and network security policies.
Resource Optimization: Optimizing resource allocation and utilization to enhance performance and reduce operational costs.
Security Enhancements: Implementing security best practices, including isolation mechanisms, encryption, and access controls.
High Availability Strategies: Ensuring continuous application availability through automated failover, load distribution, and recovery mechanisms.

Popular Container Orchestrators are:

Kubernetes:

Developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).
Features: Automatic bin packing, self-healing, horizontal scaling, service discovery, load balancing, and automated rollouts and rollbacks.

Docker Swarm:

Native clustering and orchestration solution for Docker containers.
Features: Easy setup, Docker CLI compatibility, service discovery, load balancing, scaling, and rolling updates.

Apache Mesos:

An open-source project that abstracts CPU, memory, storage, and other compute resources away from machines.
Features: Highly scalable, supports multiple frameworks, resource isolation, fault tolerance, and elasticity.

Nomad:

Developed by HashiCorp, it is a flexible and simple workload orchestrator.
Features: Multi-region, multi-cloud deployment, integrates with Consul for service discovery and Vault for secrets management, easy to use, and supports multiple workloads (Docker, non-containerized, Windows, etc.).

OpenShift:

Developed by Red Hat, built on top of Kubernetes with additional features.
Features: Developer and operational tools, automated installation, upgrade management, monitoring, logging, and security policies.

Rancher:

An open-source platform for managing Kubernetes at scale.
Features: Multi-cluster management, integrated monitoring and logging, centralized RBAC, and supports any Kubernetes distribution.

Amazon Elastic Kubernetes Service (EKS):

Managed Kubernetes service by Amazon Web Services.
Features: Fully managed, integrated with AWS services, auto-scaling, security, and compliance.

Google Kubernetes Engine (GKE):

Managed Kubernetes service by Google Cloud.
Features: Fully managed, integrated with Google Cloud services, auto-scaling, security, and compliance.

Azure Kubernetes Service (AKS):

Managed Kubernetes service by Microsoft Azure.
Features: Fully managed, integrated with Azure services, auto-scaling, security, and compliance.

IBM Cloud Kubernetes Service:

Managed Kubernetes service by IBM Cloud.
Features: Fully managed, integrated with IBM Cloud services, auto-scaling, security, and compliance.

Alibaba Cloud Container Service for Kubernetes (ACK):

Managed Kubernetes service by Alibaba Cloud.
Features: Fully managed, integrated with Alibaba Cloud services, auto-scaling, security, and compliance.

Conclusion and Future Articles

In conclusion, containerization has revolutionized software development and deployment, offering scalability, efficiency, and agility crucial in today's dynamic landscape. As we've explored the evolution from chroot to Docker and the challenges of managing containerized environments, it's clear that container orchestration is pivotal.

Thank you for reading this blog; your interest is greatly appreciated, and I hope it helps you on your Kubernetes journey; in the next blog, we'll explore Kubernetes, covering its features, architecture and core components.

Kubernetes: Hello World

Pratik Jagrut — Sun, 09 Jun 2024 12:14:45 +0000

Introduction

Deploying software can be a daunting and unpredictable task. Kubernetes, often referred to as K8s, serves as a proficient navigator in this complex landscape. It is an open-source container orchestration platform, that automates the deployment, scaling, and management of applications within containers. These containers are compact, self-sufficient units that house everything an application needs, ensuring consistency across diverse environments.

Prepare the application

Clone the Repository

In this guide, we're using hello-Kubernetes, a simple web-based application written in Go. You can find the source code here.

git clone https://github.com/pratikjagrut/hello-kubernetes.git
cd hello-kubernetes

Understanding the Code

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"
)

func handler(w http.ResponseWriter, r *http.Request) {
    log.Printf("Received request from %s", r.RemoteAddr)
    fmt.Fprintf(w, "Hello, Kubernetes!")
}

func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    http.HandleFunc("/", handler)

    go func() {
        log.Printf("Server listening on port %s...", port)
        err := http.ListenAndServe(":"+port, nil)
        if err != nil {
            log.Fatal("Failed to start the server")
        }
    }()

    log.Printf("Click on http://localhost:%s", port)

    done := make(chan bool)
    <-done
}

This Go application sets up an HTTP server that responds with "Hello, Kubernetes!" and logs request details. It runs the server concurrently, keeping the main function active.

The Dockerfile

The Dockerfile uses a multi-stage build to create a minimal container:

Builds the Go application.
Creates a minimal final image using scratch.
Exposes port 8080 and sets the command to run the Go application.

# Builder Stage
FROM cgr.dev/chainguard/go:latest as builder
# Set the working directory inside the container
WORKDIR /app
# Copy the application source code into the container
COPY . .
# Download dependencies using Go modules
RUN go mod download
# Build the Go application
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
# Final Stage
FROM scratch
# Copy the compiled application binary from the builder stage to the final image
COPY --from=builder /app/main /app/main
# Expose port 8080 to the outside world
EXPOSE 8080
# Command to run the executable
CMD ["/app/main"]

Building the Container Image

Docker: Install Docker to create container images for your application. Refer to the official Docker documentation for installation instructions.
Image Registry Account: Sign up for an account on GitHub, DockerHub, or any other container image registry. You'll use this account to store and manage your container images.
Open the terminal and navigate to the repository directory.
Build the container image using the following command:
```
docker build -t ghcr.io/pratikjagrut/hello-kubernetes .
```
This command builds the container image using the Dockerfile current directory. The -t flag specifies the image name.

Testing application image

Once the image is built, run a Docker container from the image:

➜ docker run -p 8080:8080 ghcr.io/pratikjagrut/hello-kubernetes
2023/08/08 13:25:24 Click on the link http://localhost:8080
2023/08/08 13:25:24 Server listening on port 8080...

This command maps port 8080 of your host machine to port 8080 in the container.

Open a web browser and navigate to http://localhost:8080. You should see the Hello, Kubernetes! message.

Pushing the image to the container registry

Here we've opted for the GitHub container registry. However, feel free to select a registry that aligns with your preferences.

Log in to Docker using the GitHub Container Registry:
```
docker login ghcr.io
```
When you run the command, it will ask for your username and password. Enter these credentials to log into your container registry.
Push the tagged image to the GitHub Container Registry:
```
docker push ghcr.io/pratikjagrut/hello-kubernetes
```
Verify that the image is in your GitHub Container Registry by visiting the Packages section of your GitHub repository.

Next, we'll set up a Kubernetes cluster to deploy our containerized application.

Setup Kubernetes cluster

Here we'll use KIND (Kubernetes in Docker) as our local k8s cluster.

Installing KIND and Kubectl

Before we dive into setting up the Kubernetes cluster, you'll need to install both KIND and kubectl on your machine.

KIND (Kubernetes in Docker): KIND allows you to run Kubernetes clusters as Docker containers, making it perfect for local development. Follow the official KIND installation guide to install it on your system.
kubectl: This command-line tool is essential for interacting with your Kubernetes cluster. Follow the Kubernetes documentation to install kubectl on your machine.

Creating Your KIND Cluster

Once KIND and Kubectl are set up, let's create your local Kubernetes cluster:

Open your terminal.
Run the following command to create a basic KIND cluster:
```
kind create cluster
```

Check if the cluster is properly up and running using kubectl get ns

It should get all the namespaces present in the cluster.

➜ kubectl get ns
NAME                 STATUS   AGE
default              Active   3m13s
kube-node-lease      Active   3m14s
kube-public          Active   3m14s
kube-system          Active   3m14s
local-path-storage   Active   3m9s

Alternative Setup Options:

Minikube: If you prefer another local option, Minikube provides a hassle-free way to run a single-node Kubernetes cluster on your local machine.
Docker Desktop: For macOS and Windows users, Docker Desktop offers a simple way to set up a Kubernetes cluster.
Rancher Desktop: Rancher Desktop is another choice for a local development cluster that integrates with Kubernetes, Docker, and other tools.
Cloud Clusters: If you'd rather work in a cloud environment, consider platforms like Google Kubernetes Engine (GKE) or Amazon EKS for managed Kubernetes clusters.

With your Kubernetes cluster up and running, you're ready to sail ahead with deploying your first application.

Deploy application on Kubernetes

Now, we'll deploy our application onto the Kubernetes cluster.

Create a Kubernetes Deployment

A Deployment in Kubernetes serves as a manager for your application's components, known as Pods. Think of it like a supervisor ensuring that the right number of Pods are running and matching your desired configuration.

In more technical terms, a Deployment lets you define how many Pods you want and how they should be set up. If a Pod fails or needs an update, the Deployment Controller steps in to replace it. This ensures that your application remains available and runs smoothly.

To put it simply, a Deployment takes care of keeping our application consistent and reliable, even when Pods face issues. It's a fundamental tool for maintaining the health of your application in a Kubernetes cluster.

Here's how we can create a Deployment for our application:

Create a YAML file named app-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-k8s-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-k8s
  template:
    metadata:
      labels:
        app: hello-k8s
    spec:
      containers:
        - name: hello-k8s-container
          image: ghcr.io/pratikjagrut/hello-kubernetes
          ports:
            - containerPort: 8080

This YAML defines a Deployment named hello-k8s-deployment that runs two replicas of our application.

Apply the Deployment to your Kubernetes cluster:

kubectl apply -f hello-k8s-deployment.yaml

Now, if you're using a GitHub registry just like me then you'll see an error(ImagePullBackOff or ErrImagePull)(failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized) in deploying your application. By default the images on the GitHub container registry are private.

When you describe the pods you'll see warning messages in the events section such as Failed to pull image "ghcr.io/pratikjagrut/hello-kubernetes".

➜ kubectl describe pods hello-k8s-deployment-54889c9777-549rn
...
Events:
  Type     Reason     Age                  From               Message
  ----     ------     ----                 ----               -------
  Normal   Scheduled  2m40s                default-scheduler  Successfully assigned default/hello-k8s-deployment-54889c9777-549rn to kind-control-plane
  Normal   Pulling    75s (x4 over 2m39s)  kubelet            Pulling image "ghcr.io/pratikjagrut/hello-kubernetes"
  Warning  Failed     74s (x4 over 2m39s)  kubelet            Failed to pull image "ghcr.io/pratikjagrut/hello-kubernetes": rpc error: code = Unknown desc = failed to pull and unpack image "ghcr.io/pratikjagrut/hello-kubernetes:latest": failed to resolve reference "ghcr.io/pratikjagrut/hello-kubernetes:latest": failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized
  Warning  Failed     74s (x4 over 2m39s)  kubelet            Error: ErrImagePull
  Warning  Failed     50s (x6 over 2m39s)  kubelet            Error: ImagePullBackOff
  Normal   BackOff    36s (x7 over 2m39s)  kubelet            Back-off pulling image "ghcr.io/pratikjagrut/hello-kubernetes"

This happened because Kubernetes is trying to pull the private image and it does not have permission to do so.

When a container image is hosted in a private registry, we need to provide Kubernetes with credentials to pull the image via Image Pull Secrets.

Create a Docker registry secret:

kubectl create secret docker-registry my-registry-secret \
  --docker-username=<your-username> \
  --docker-password=<your-password> \
  --docker-server=<your-registry-server>

Attach the secret to your Deployment:

spec:
  template:
    spec:
      imagePullSecrets:
        - name: my-registry-secret

Apply the changes::

kubectl apply -f hello-k8s-deployment.yaml

After applying the updated deployment you can see that all the pods are running.

➜ kubectl get pods
NAME                                    READY   STATUS    RESTARTS   AGE
hello-k8s-deployment-669788ccd6-4dbb6   1/1     Running   0          22s
hello-k8s-deployment-669788ccd6-k5gfg   1/1     Running   0          37s

Access Your Application

With the Deployment in place, we can access our application externally. Since we're using KIND, we can use port-forwarding to access the application:

Find the name of one of the deployed Pods:

kubectl get pods -l app=hello-k8s

Forward local port 8080 to the Pod:

kubectl port-forward <pod-name> 8080:8080

Now, if you open a web browser and navigate to http://localhost:8080 or use curl http://localhost:8080 you should see "Hello, Kubernetes!" displayed, indicating your application is running successfully.

➜ curl http://localhost:8080
Hello, Kubernetes!%

NOTE: For production, use a Kubernetes service and Ingress for optimal traffic handling.

Conclusion

In conclusion, this beginner's guide has walked you through deploying your first application on Kubernetes. But remember, this is just the start. Kubernetes offers vast opportunities for optimizing your application's performance, scalability, and resilience. With features like advanced networking, load balancing, automated scaling, and self-healing, Kubernetes ensures seamless application operation in any environment. So, while this guide ends here, your journey with Kubernetes is only beginning.

Thank you for reading! Hope you find this helpful!