Pod is the basic building block of Kubernetes, the smallest deployable unit in the Kubernetes that can be created and managed.
A pod is a group of one or more containers (such as Docker containers) with shared storage/network, and a specification for how to run the containers.
A pod represents a single instance of an application in Kubernetes.
Here is the manifest for a Pod:
Create a manifest file for pod creation
| $ sudo vim nginx.yaml |
Enter the following manifest
| apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: – name: nginx image: nginx:latest imagePullPolicy: IfNotPresent ports: – containerPort: 80 |
Create a pod:
| $ kubectl create -f nginx.yaml |
pod “nginx” created
Verify the pod is running:
| $ kubectl get pod nginx |
Expected Output:
| NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 89s |
Check the pod created in the which node
| kubectl get pod -o wide |
Expected Output: :
| NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx 1/1 Running 0 2m50s 192.168.230.9 k8s-worker-1 <none> <none> |
Edit pod configuration:
| $ kubectl edit pod nginx |
You can edit the Pod-YAML using this command
Expose this pod using service, Let’s create a service
Note: we will learn more about the server on the next page
Create a service manifest file
| $ sudo vim nginx-svc.yaml |
Enter the following manifest
| apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: – protocol: TCP port: 80 targetPort: 80 nodePort: 31423 type: NodePort |
In this configuration, the label of the Pod is specified within the Service’s selector section. This allows the Service to identify and expose the Pod associated with that specific label.
Check whether the Service was Created or not
| $ kubectl get svc -n default |
Expected Output:
| NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-service NodePort 10.108.209.184 <none> 80:31423/TCP 14s |
Service has been created, now let’s Verify the Nginx from the browser http://Node-IP:31423
Delete a pod
| $ kubectl delete -f nginx.yaml |
Expected Output:
| pod “nginx” deleted |
— or —
| $ kubectl delete pod nginx |
pod “nginx” deleted
Delete the service
| $ kubectl delete -f nginx-svc.yaml |
Pod Lifecycle
Here are the possible values for STATUS:
- Pending State
The Pod has been accepted by the Kubernetes system, but one or more of the Container images has not been created. This includes time before being scheduled as well as time spent downloading images over the network, which could take a while.
- Running State
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 State
All Containers in the Pod have terminated in success, and will not be restarted.
- Failed State
All Containers in the Pod have terminated, and at least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
- Unknown State
For some reason, the state of the Pod could not be obtained, typically due to an error in communicating with the host of the Pod.
- Completed State
The pod has run to completion as there is nothing to keep it running eg. Completed Jobs.
- CrashLoopBackOff State
This means that one of the containers in the pod has exited unexpectedly, and perhaps with a non-zero error code even after restarting due to the restart policy.
Multi-Container Pods
- Pods are designed to support multiple containers. The containers in a Pod are automatically co-located and co-scheduled on the same node in the cluster.
- The containers can share resources and dependencies, communicate with one another, and coordinate when and how they are terminated.
- The “one container per Pod” model is the most common use case and Kubernetes manages the Pods rather than the containers directly.
Here is an example of a multi-container pod
| apiVersion: v1 kind: Pod metadata: name: nginx-web spec: volumes: – name: shared-files emptyDir: {} – name: nginx-config-volume configMap: name: nginx-config containers: – name: app image: php-app:1.0 volumeMounts: – name: shared-files mountPath: /var/www/html – name: nginx image: nginx:latest volumeMounts: – name: shared-files mountPath: /var/www/html – name: nginx-config-volume mountPath: /etc/nginx/nginx.conf subPath: nginx.conf |
Init Containers
Like multiple containers in a pod, it can also have one or more init containers, which are run before the application containers are started.
- Init containers always run to completion.
- Each init container must be completed successfully before the next one starts.
Here is an example of init containers
| apiVersion: v1 kind: Pod metadata: name: wordpress spec: containers: – image: wordpress:latest name: wordpress ports: – containerPort: 80 name: wordpress initContainers: – name: change-permissions image: busybox command: [‘sh’, ‘-c’, ‘chown www-data:www-data /var/www/html && chmod -R 755 /var/www/html’] |
