Kubernetes is a platform for container orchestration created to simplify application deployment, scaling, and administration. Suppose you have a big package of LEGO parts and you want to use them to make something very spectacular. But as your LEGO creation becomes larger, it becomes harder to organize and keep track of every component. This is where Kubernetes comes into play. Kubernetes is like a really smart LEGO manager. It helps you maintain control over an organization over all the different parts of your LEGO creation, making sure that everything is working and placed correctly.

Not LEGO blocks, but software programs and the real-world devices they run on, are the subject of our discussion. To ensure correct operation, scalability in response to changing conditions, and availability in the case of a computer breakdown, Kubernetes helps with the administration of these applications.

Kubernetes Architecture

The architecture of K8s consists of several essential parts, each of which is essential to enabling smooth operations:

Kubernetes Master Node

The Kubernetes cluster’s master node acts as a control plane, supervising all of its activities and facilitating communication between different parts. Important parts of the master node consist of:

• API Server: Makes the Kubernetes API accessible, enabling communication between users and other components and the cluster.
• Scheduler: Assigns pods to nodes in accordance with workload limitations and resource availability.
• Controller Manager: Oversees several controllers that are in charge of things like replication and node management, ensuring that the cluster remains in the proper condition.
• etcd: A distributed key-value store that holds configuration information and state for the cluster.

Kubenetes Worker Node

Worker nodes, sometimes referred to as minions, are in charge of managing workloads and running containers. Every worker node is made up of the following parts:

• Kubelet: An agent that interacts with the master node to oversee and maintain the health and functionality of pods.
• Container Runtime: Docker or CRI-O are examples of software that runs containers.
• Kube Proxy: Oversees load balancing and manages network connection between pods and external clients.

Knowing How to Use Kubernetes Pods

A pod is the basic API object in Kubernetes and is the smallest scheduling unit in the system. It basically depicts an application process that is active within a cluster. A pod consists of one or more containers as well as the shared resources, such as network and storage settings, that each container uses. The Pod’s Lifecycle Stages:

A pod goes through five distinct stages in its lifecycle:

• Pending: This phase denotes the absence of at least one container in the pod from the creation process.
• Operating: The pod is connected to a Node and all containers have been formed. Either containers are operating, or they are starting, stopping, or restarting.
• Succeeded: There are no intentions to restart once all of the pod’s containers have terminated successfully.
• Failed: One or more containers have failed, usually as a result of a non-zero exit status. All containers have terminated.
• Unknown: It is impossible to ascertain the pod’s current state.

Why would one need to restart a container?

• Restarting a pod which consists a container becomes essential in a few different scenarios:
• Lack of resources or unforeseen programme behaviour that results in termination.
• Pods stay in a terminating state when unanticipated difficulties with cluster nodes arise.
• Timeouts, incorrect deployments, unfixable issues, or unavailable persistent volumes.

Ways to Use kubectl to Restart Kubernetes Container

In the Docker process, you can restart a container using docker restart {container_id}; however, Kubernetes does not have a restart command. Put otherwise, there isn’t a kubectl restart {podname}.

Occasionally, an issue with your pod may cause it to abruptly shut down, requiring you to restart it. However, there is no reliable way to restart it—especially in the event that the YAML file is missing. Do not be alarmed; we will go over a few ways to use kubectl to restart a Kubernetes pod.

Note: You need to restart the pod that has the container inside it to be able to restart the container. Check the FAQs section for more details.

Method 1: kubectl scale

Step 1: Using kubectl scale to scale replicas: If a YAML file is not available, restarting the pod may be achieved by scaling the replica count to zero and back to one. One way to do this is by using:

kubectl scale deployment <deployment_name> --replicas=0 -n <namespace>
kubectl scale deployment <deployment_name> --replicas=1 -n <namespace>

Step 2: After running these commands, we want to check if the containers were actually restarted. To do this, run the following commands:

kubectl get pods -n <namespace>                                   //To get the pod associated with your deployment
                                                                                                // here the namespace is default

Step 3: Now inspect the pod events using the command:

kubectl describe pod <pod_name> -n <namespace>

//here pod name is my-app-deployment-5c7d674b97-fdp8q and namespace is default

This command will describe all the associated with it including the restart event. Example is,
Although the pulled and created events are also part of normal lifecycle, here it indicates that the container was restarted.

To get the list of all namespaces, run the following command:

kubectl get namespaces

From this list identify the namespace where your deployment is resides.

Method 2: kubectl rollout restart

Although method 1 is a faster approach, the rollout restart command is the easiest way to restart Kubernetes pods.

Step 1: Using the ReplicaSet to scale up additional pods until they are all younger than when the controller restarted, the controller kills one pod at a time. Since your application won’t be impacted or crash, rolling out restart is the best way to restart your pods.

Step 2: To initiate a restart, use the subsequent command:

kubectl rollout restart deployment <deployment_name> -n <namespace>

Step 3: Here, in our example the deployment name is my-app-deployment and namespace is default

As shown in the example, the output of the command is that the container was restarted.

Method 3: kubectl delete pod

Step 1: Since Kubernetes is a declarative API, removing the pod API object with the command kubectl delete pod <pod_name> -n <namespace> will result in an object that differs from what was anticipated.

Step 2: To maintain consistency with the intended pod, it will automatically recreate it; but, if the ReplicaSet maintains a large number of pod objects, it will be quite laborious to manually remove each one individually. To remove the ReplicaSet, execute the following command:

kubectl delete pod <pod_name> -n <namespace>

This has deleted the container.

Step 3: Now let’s check if container was automatically recreated to maintain consistency by using the command, kubectl get pods -n default

Here, we can see that a new container was automatically recreated.

Method 4: kubectl get pod

Step 1: Forcing Restart without YAML File: If there isn’t a YAML file, you may use the following command to force a restart of the pod:

kubectl get pod <pod_name> -n <namespace> -o yaml | kubectl replace --force -f -

Step 2: Here the pod name was my-app-deployment-5f9b5db9cc-nks7g and namespace was default

As shown, the container was firstly forcefully deleted and then replaced.

Note: Use command kubectl get pods -n default to get all the pods in default namespace and command kubectl get namespaces to get a list of all namespaces.

Restart container in kubernetes – FAQ’s

What is the Kubernetes hierarchy for nodes, clusters, pods, and containers?

Cluster: A group of Kubernetes-managed nodes that includes worker nodes and a control plane.

Nodes: The individual computers that make up the Kubernetes cluster that run containers.

Pods: The smallest units that may be deployed, comprising one or more containers.

Containers are executable units that are enclosed and executed inside pods.

Can’t I just restart a single container inside a pod?

Pods are usually used in Kubernetes to manage containers. In Kubernetes, a pod is the smallest deployable unit that can hold one or more containers.

Restarting a container is equivalent to restarting the process that is currently operating inside of it. However, you usually deal with pods instead of individual containers when dealing directly with Kubernetes.

What is a YAML file?

Software applications utilise YAML files as a human-readable data serialisation format for configuration files and data interchange. It uses key-value pairs and indentation to express data structures. YAML files, which include settings for variables like container images, resource requests, and networking rules, are used by Kubernetes to specify the intended state of resources like pods, deployments, and services inside a cluster. They make deployments easier to automate and more repeatable.

Do I need to install kubectl separately if I’m using Azure?

The Kubernetes command-line client, kubectl, is used to administer Kubernetes clusters. kubectl is already installed if you use Azure Cloud Shell.

What are some basic kubectl commands?

//configure kubectl to connect to your Kubernetes Cluster

az aks get-credentials –resource-group myResourceGroup –name myAKSCluster

//verify the connection

kubectl get nodes