Content

• Pod Fundamentals
• Creating a Pod in Kubernetes
• Working with Pods
• What is YAML?
• Create a Pod with YAML
• Understanding Pod Health
• Different Probes

Pod Fundamentals

In Kubernetes, a pod is a smallest and simplest unit in the object model for deploying applications. A pod represents a single instance of a running process in a cluster.

A pod can contain one or more containers, and all containers in a pod run on the same node and share the same network namespace. This means that the containers can communicate with each other using localhost and share the same file system.

Pods provide a way to group containers that should be deployed together on the same node. For example, you might deploy a web server and a database server as separate containers within the same pod, so that they can communicate with each other over localhost.

Pods are created and managed by higher-level abstractions, such as deployments and replicasets, which provide features such as scaling, rolling updates, and self-healing. The Kubernetes control plane is responsible for ensuring that the desired state of the cluster, as specified by the higher-level abstractions, is maintained.

Pods can also be exposed to the network using services, which provide network communication and load balancing for pods. Services can be used to expose pods to the network so that they can be accessed by external clients.

In summary, pods in Kubernetes are the smallest and simplest unit in the object model for deploying applications. Pods represent a single instance of a running process in a cluster and provide a way to group containers that should be deployed together on the same node. Pods are created and managed by higher-level abstractions and can be exposed to the network using services.

Creating a Pod In Kubernetes

There are three ways to create Pods in Kubernetes.

kubectl run [pod-name] –image [image-details]

kubectl create -f [file-name]

kubectl apply -f [file-name]

The difference between create and apply is that –

Create will create the Pod where Apply command will create as well as apply changes to the existing pod. You can always go with kubectl apply command, but if your initial pod is created with kubectl create command and now you want to use kubectl apply command on this existing pod, you can only do that if the initial pod was created with save-config like below –

kubectl create -f [file_name] –save-config 

Working With Pods

To list down all pods, the command is

kubectl get pods

To expose a pod, the command is:

kubectl port-forward [pod-name] 8080:80

To delete a pod, the command is:

kubectl delete pod [pod-name]

To delete deployment that manages the pod, the command is:

kubectl delete deployment [deployment-name]

What is YAML?

YAML is a human-readable data serialization format that is often used for configuration files. It stands for “YAML Ain’t Markup Language”. YAML files are commonly used in Kubernetes for defining and managing objects such as Pods, Deployments, Services, ConfigMaps, and Secrets.

In Kubernetes, a Pod is the smallest deployable unit that can be created and managed. A Pod is a logical host for one or more containers, and it provides a shared network namespace and storage volumes. To create a Pod in Kubernetes using YAML, you would typically start by creating a YAML file that describes the desired state of the Pod.

The YAML file for a Pod typically includes a few key sections, including:

1. metadata: This section includes the name and labels of the Pod, as well as any annotations or other metadata.
2. spec: This section includes the Pod’s specifications, such as the container images to run, the ports to expose, and any environment variables or volumes to use.

Creating a Pod With YAML

Here’s an example of a YAML file for a simple Pod with one container:

With the above YAML file, we can run the below command to perform dry run and validate the YAML file.

kubectl create -f my-pod.yaml –dry-run=client –validate=true

If all looks good, we can just run the below command to create the pod in real.

kubectl apply -f my-pod.yaml –save-config

Apply changes to an existing Pod, the command is:

kubectl apply -f my-pod.yaml

Also, we can delete the pod by running the below command

kubectl delete -f my-pod.yaml

Understanding Pod Health

In Kubernetes, pod health can be checked using a variety of mechanisms, including:

1. Liveness probes: These are used to check whether the container in a pod is still running. A liveness probe is a command or HTTP request that is executed periodically. If the command fails or the HTTP request returns an error, the container is considered to have failed and Kubernetes will restart it.

2. Readiness probes: These are used to check whether the container in a pod is ready to start accepting traffic. A readiness probe is a command or HTTP request that is executed periodically. If the command succeeds or the HTTP request returns a success code, the container is considered ready to start accepting traffic.

3. Startup probes: These are used to check whether the container in a pod has started up correctly. A startup probe is a command or HTTP request that is executed once after the container has started up. If the command fails or the HTTP request returns an error, Kubernetes will restart the container.

These probes can be configured in the pod specification using the livenessProbe, readinessProbe, and startupProbe fields. Each probe can be customized to use a different command or HTTP request, and to specify the frequency and timeout for the probe.

Kubernetes also supports other mechanisms for monitoring pod health, such as container logging, event monitoring, and custom metrics. However, liveness, readiness, and startup probes are the most common mechanisms used to monitor pod health in Kubernetes.

Liveness Probe Configuration

Below is an example of a liveness probe in a Kubernetes YAML file:

The liveness probe is configured to check for a file on the server. The liveness probe will start 5 seconds after the container starts (initialDelaySeconds: 5), and will be repeated every 5 seconds (periodSeconds: 5). If the file is not found, Kubernetes will assume that the container has failed and will restart it.

Readiness Probe Configuration

Below is an example of a readiness probe in a Kubernetes YAML file:

The readiness probe is configured to check for a file on the server. The readiness probe will start 5 seconds after the container starts (initialDelaySeconds: 5), and will be repeated every 5 seconds (periodSeconds: 5). If the file is not present, Kubernetes will consider the container to be ready to receive traffic. If failed, it will not be restarted.

Startup Probe Configuration

Below is an example of a startup probe in a Kubernetes YAML file:

The startup probe is configured to check whether a file present on the server. The startup probe will start as soon as the container starts and will perform 5 checks (failureThreshold) with 5 seconds (periodSeconds) in between. So total 25 seconds to make that file available. The container will be restarted if the probe still doesn’t succeed after this time.

Conclusion

In this blog post, so far I have explored how to create pods in Kubernetes and check their health through probes. This blog post provides a comprehensive introduction to creating pods in Kubernetes and using probes to check their health, which is essential for ensuring the reliability and availability of containerized applications running on the platform.

In my next blog post, I will be doing deep dive into different probes. Please subscribe to my blog and Youtube channel – Technical Potpourri to get updates about all my upcoming blogs/videos.

Disclaimer

This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.