Kubernetes Pod
Sanyogita WangePOD:
A Kubernetes pod is a collection of one or more linux container with shared storage and network resources, and a specification for how to run the containers, and is the smallest unit of a Kubernetes application. They are ephemeral(something which last for small time).
You can run anything in pod like shell, python
POD COMMANDS
kubernetes run pod_name --image nginx --sleep 1d (creates new pod pod_name)
kubernetes describe po/pod_name (gives pod spec)
kuberenetes get pods -o wide (tells name,status,restarts,age,ip,node etc)
kubernetes edit pod pod_name (by default open vi editor to edit pod)
kubernetes apply -f abc.yaml (creates pod from a yaml file, -f means you
are passing a file)
kubectl delete pod_name (deletes pod)
kubernetes get pod/pod_name -o yaml> pod_name.yaml (it creates yaml file
of a pod)
pods are created using yaml file. Below is basic yaml file creating a pod onsists of a container running the nginx image
apiVersion: v1 ---api group of initial level components of k8s creation
kind: Pod --- type of object/resource(pod,volume, storage class etc)
metadata: --- details of pod
name: nginx --- name of pod(should be proper name)
spec: ---specification of conatiners
containers:
-name: nginx --- (- means list is started, name of container)
image: nginx:1.0.1 --- (image used to create container)
ports:
-containerPort: 80 ---(ports through which container can be accessed)
Static Pod:
Components such as etcd, kube scheduler, kube-contoller-manager are running as static pod and corresponding yaml files can be found at
cd /etc/kubernetes/manifests
Now this should be described in config.yaml in /var/lib/kubelet
Internally code is defined in a way that files mentioned here become static pod.
Daemon Set: If there is any functionality (logging) which should be done on every node, it can be done with k8s object k/as daemon set. The daemon set object is designed to ensure that a single pod runs on each worker node. This means you cannot scale daemon set pods in a node. And for some reason, if the daemon set pod gets deleted from the node, the daemon set controller creates it again.
Types of containers wrt k8s(Pods)
Ephemeral containers:
A special type of container that runs temporarily in an existing pod or create a copy of pod to accomplish user-initiated actions such as troubleshooting.
how to make ephemeral containers?
Using debug
kubernetes debug -it pod_name --image nginx --target pod_name
more info: Debug Running Pods | Kubernetes
debug containers cannot be killed, you need to kill main container for it, therefore they are not in use.
init container:
In production, we can run multiple containers in a pod. in that, init containers run before application containers. init container run as pre requisites( eg to fetch secrets, pre config file, git clone etc) for application container. init container are created using distorless image.
init containers are the 1st one to run, once it returns 0 code(successful), then only application containers run, if non-0 code is returned it wont run.
Multiple init containers can run in a pod sequentially.
Sidecar containers:
It is exactly same as init container, except that init containers are flushed once task is done, but side car containers monitor application container till it runs, it can be used for observability, security etc. i.e. restart policy is always in sidecar pod's yaml.
If you set restart policy in init container it by default becomes sidecar container.
restart policy is of 3 types
1. never : means never start pod once deleted
2. on failure: if pod fails create it
3. always: it will keep running always till main container runs (feature introduced in k8s 1.29)
Termination of Pods:
once you run kubectl delete pod, req goes to api server ->etcd -> controller -> api server -> kubelet .
Once req comes to kubelet-> it sends sig term signal(unix signal + grace time out period to CRT to delete pod in 30 sec. After 30 sec sig kill signal comes which deletes pod if not already deleted.
In grace time pod release IP, pv, internal directory etc.
Lifecycle:
Pending: The Pod is created but not yet running. it may be still downloading images, container is still getting created.
Succeed: All Containers in the Pod have terminated in success, and will not be restarted.
Failed: At least one Container has terminated in failure. That is, the Container either exited with non-zero status or was terminated by the system.
Running: The pod is bound to a node, all containers are created and at least one container is running or is in the process of starting or restarting
Unknown: For some reason state of pod couldn't be obtained, probably due to error in communication.
EXEC:
Execute a command in a container (running container).
kubectl exec -it pod_name -- command
kubectl exec -it nginx -- bash
-- cat/more/less( any linux command can be given)
-it = i is to take standard input, t is tty(terminal), so it is input based terminal.
-- bash = opens bash terminal
now you can do any debugging required.
Do we do exec in prod?
Mostly we don't use, because ephemeral containers may loose data etc.
Dry run:
it tells what spec will a pod have when it is actually created and runs.
kubernetes run pod_name nginx --dry-run=client -o yaml
Interview Questions
Q1. Difference between apply and create?
Ans. No major difference at high level, both create pods.
Examples
kubectl create -f pod.yaml creates pod
kubectl apply -f pod.yaml creates pod
kubectl delete -f pod.yaml deletes pod
Q2. Can we re run same apply command?
Ans: It wont make sense unless spec file have any changes, applying same file will give output unchanged.
--Apply does not make changes if anything above spec is changed in yaml file, it applies changes and re run only when spec config is changed in yaml file.
Q3. How to edit a pod?
Ans. Using edit command
kubectl edit pod pod-name
Subscribe to my newsletter
Read articles from Sanyogita Wange directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by