What Is Pod In Kubernetes
Hello Everyone
Welcome to CloudAffaire and this is Debjeet.
In the last blog post, we have discussed how to install the Kubernetes cluster in Linux.
https://cloudaffaire.com/how-to-install-kubernetes-cluster-in-linux/
In this blog post, we will discuss Pod in Kubernetes.
What is a Pod?
A Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents processes running on your Cluster. A Pod encapsulates an application’s container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: a single instance of an application in Kubernetes, which might consist of either a single container or a small number of containers that are tightly coupled and that share resources. Docker is the most common container runtime used in a Kubernetes Pod, but Pods support other container runtimes as well.
You’ll rarely create individual Pods directly in Kubernetes–even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the Pod is evicted for lack of resources, or the Node fails.
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won’t survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a Controller, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it’s far more common in Kubernetes to manage your pods using a Controller.
Pods controllers:
A Controller can create and manage multiple Pods for you, handling replication and rollout and providing self-healing capabilities at cluster scope. For example, if a Node fails, the Controller might automatically replace the Pod by scheduling an identical replacement on a different Node. In general, Controllers use a Pod Template that you provide to create the Pods for which it is responsible. Some examples of Controllers that contain one or more pods include:
- Deployment
- StatefulSet
- DaemonSet
- ReplicaSet
- ReplicationController
- CronJob
- Job
Pod Networking:
Each Pod is assigned a unique IP address. Every container in a Pod shares the network namespace, including the IP address and network ports. Containers inside a Pod can communicate with one another using localhost. When containers in a Pod communicate with entities outside the Pod, they must coordinate how they use the shared network resources (such as ports).
Pod Storage:
A Pod can specify a set of shared storage Volumes. All containers in the Pod can access the shared volumes, allowing those containers to share data. Volumes also allow persistent data in a Pod to survive in case one of the containers within needs to be restarted. See Volumes for more information on how Kubernetes implements shared storage in a Pod.
Pod Templates:
Pod templates are pod specifications which are included in other objects, such as Replication Controllers, Jobs, and DaemonSets. Controllers use Pod Templates to make actual pods. Pod template can be defined using yaml or json format.
Pod manifest file syntax:
|
1 2 3 4 5 6 7 8 9 10 |
## --------------- ## Pod YAML syntax ## --------------- apiVersion: v1 kind: Pod metadata: spec: |
podMetadata attributes:
- annotations: Key value map stored with a resource for arbitrary metadata.
- clusterName: The name of the cluster which the object belongs to.
- creationTimestamp: Timestamp representing the server time when this object was created.
- deletionGracePeriodSeconds: Seconds allowed for gracefully terminate before forcefully removed from the system.
- deletionTimestamp: RFC 3339 date and time at which this resource will be deleted. Is not directly settable by a client.
- finalizers: Must be empty before the object is deleted from the registry.
- generateName: Optional prefix, used by the server, to generate a unique name ONLY IF the Name field has not been provided.
- generation: A sequence number representing a specific generation of the desired state. Populated by the system. Read-only.
- initializers: An initializer is a controller which enforces some system invariant at object creation time.
- labels: Map of string keys and values that can be used to organize and categorize (scope and select) objects.
- name: Name must be unique within a namespace.
- namespace: Namespace defines the space within each name must be unique, default namespace is default.
- ownerReferences: List of objects depended by this object.
- resourceVersion: An opaque value that represents the internal version of this object used to determine when objects have changed.
- selfLink: SelfLink is a URL representing this object. Populated by the system. Read-only.
- uid: UID is the unique in time and space value for this object
podSpec attributes:
- activeDeadlineSeconds: Seconds the pod may be active on the node relative to StartTime before killed by system.
- affinity: If specified, the pod”s scheduling constraints
- containers: List of containers belonging to the pod.
- dnsConfig: DNS parameters of a pod.
- dnsPolicy: DNS policy for the pod.
- hostAliases: List of hosts and IPs that will be injected into the pod’s hosts file if specified.
- hostIPC: Use the host’s ipc namespace. Optional: Default to false.
- hostNetwork: Host networking requested for this pod.
- hostPID: Use the host’s pid namespace. Optional: Default to false.
- hostname: Hostname of the Pod If not specified, the pod’s hostname will be set to a system-defined value.
- imagePullSecrets: List of references to secrets used for pulling any of the images used by this PodSpec.
- initContainers: List of initialization containers belonging to the pod.
- nodeName: NodeName is a request to schedule this pod onto a specific node.
- nodeSelector: NodeSelector is a selector which must be true for the pod to fit on a node.
- priority: The priority value. Various system components use this field to find the priority of the pod.
- priorityClassName: Indicates the pod’s priority.
- readinessGates: If specified, all readiness gates will be evaluated for pod readiness.
- restartPolicy: Restart policy for all containers within the pod. One of Always, OnFailure, Never. Default to Always.
- schedulerName: Scheduler used for pod scheduling.
- serviceAccountName: ServiceAccountName is the name of the ServiceAccount to use to run this pod.
- shareProcessNamespace: Share a single process namespace between all of the containers in a pod.
- subdomain: If specified, the fully qualified Pod hostname will be “<hostname>.<subdomain>.<pod namespace>.svc.<cluster domain>”.
- terminationGracePeriodSeconds: Optional duration in seconds the pod needs to terminate gracefully.
- tolerations: If specified, the pod’s tolerations.
- volumes: List of volumes that can be mounted by containers belonging to the pod.
Pod demo:
Step 1: Create a pod template in yaml format.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
####################### ## Pod In Kubernetes ## ####################### ## Prerequisites ## One Kubernetes Cluster with atleast one node ## You can install your own or use online versions using below links ## https://cloudaffaire.com/how-to-install-kubernetes-cluster-in-linux/ ## https://www.katacoda.com/courses/kubernetes/playground ## http://labs.play-with-k8s.com/ ## Create the pod definition mkdir myapp && vi myapp/mypodv1.yaml -------------------- apiVersion: v1 kind: Pod metadata: name: mypod labels: app: myapp spec: containers: - image: nginx name: mycontainer ports: - containerPort: 80 name: http --------------------- :wq |
Step 2: Validate the pod template.
|
1 2 |
## Validate the yaml configuration file kubectl create --dry-run --validate -f myapp/mypodv1.yaml |
Step 3: Deploy the pod using pod template.
|
1 2 |
## Create the pod kubectl apply -f myapp/mypodv1.yaml |
Step 4: Get pod details using kubectl commands.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
## View the pod kubectl get pod #list all pods in default namespace kubectl get pod mypod ##list specific pod kubectl get pod -l app=myapp##list pod by lebel kubectl get pod -o wide ##get detailed output ## View pod configuration kubectl get pod mypod -o yaml ## View pod details kubectl describe pod mypod ## View pod lebels kubectl get pods --show-labels ## Get pod container kubectl get pods mypod -o='custom-columns=PODS:.metadata.name,CONTAINERS:.spec.containers[*].name' ## Watch your pod kubectl get pods -n mypod --watch # cntrl + c ## View pod logs kubectl logs mypod --all-containers=true ## Get inside the pod\container shell kubectl exec -it mypod -- /bin/sh kubectl exec -it mypod --container mycontainer -- /bin/sh ## hostname ## mypod ## exit |
Step 5: Make a connection to your pod.
|
1 2 3 4 5 6 7 8 9 10 11 |
## Expose your pod kubectl expose pod mypod --type=NodePort --port=80 ## Get pod ip address kubectl get pod -o wide ## NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES ## mypod 1/1 Running 0 108s 10.244.1.12 system3 ## Call your pod uisng pod ip address (nginx web server) curl 10.244.1.12:80 |
Step 6: Cleanup.
|
1 2 3 4 5 6 7 8 9 10 |
## Cleanup ## Delete the nodeport service kubectl delete service mypod ## delete the pod kubectl delete pod mypod ## Delete myapp directory rm -rf myapp |
Hope you enjoyed this article. In the real world Kubernetes deployment, we hardly deploy a pod directly. Instead, pods are deployed using a pod controller. In the next blog post, we will discuss one of the pod controller ReplicationController.
To get more details on Kubernetes you can follow the below link.
https://kubernetes.io/docs/home/
To get more details on Docker you can follow the below links.
https://cloudaffaire.com/category/devops/docker/