Table of Contents
In this article, we will see 30 most frequently asked questions about kubernetes pods. Now a days, Kubernetes has becomes a single most hot topic due to its wide range of applicability and features. As more and more folks started working on kubernetes cluster, people coming from docker container background often have lot of questions about kubernetes pods in mind. Until all those questions are answered, it is almost difficult to grasp the idea of having kubernetes and understanding how it solves the problem of traditional applications. So here we will look into all those frequently asked questions.
30 Most Frequently Asked Questions about Kubernetes Pods
1. What is a Pod ?
Ans. A pod is a simplest and smallest deployable unit in Kubernetes which contain one or more than one containers that share storage, network, and specifications on how to run the containers.
2. How kubernetes pod is different from docker container ?
Ans. Kubernetes pods and Docker containers are different in several key aspects:-
a) Scope and Functionality
- Docker Container: A container is a standard unit of software that packages up code and all its dependencies, allowing the application to run quickly and reliably in different computing environments. Docker is a platform that enables developers to develop, ship, and run applications as containers.
- Kubernetes Pod: A pod in Kubernetes is the smallest deployable unit that can be created and managed. It represents a single instance of an application. A pod can contain one or more containers (such as Docker containers), which share storage, network, and other specifications on how to run the containers.
b) Resource Sharing
Containers within a pod share the same network IP, port space, and storage, allowing them to communicate more efficiently.
c) Use Case
- Containers are ideal for isolating applications and maintaining consistency across multiple development, testing, and production environments.
- Pods are used for orchestrating and managing a group of one or more containers on a cluster in Kubernetes, including their networking and storage needs.
- Containers have a lifecycle (create, run, stop, delete).
- Pods have a more complex lifecycle because they are managed by Kubernetes, which automates deploying, scaling, and operating containerized applications.
3. How many minimum container can be created inside a pod ?
Ans. You have to create atleast one container in a pod. Without that a pod cannot be brought up.
4. How many maximum containers can be created inside a pod ?
Ans. You can create as many containers as you like in a pod. There is no such limitation.
5. What is the basic rule for creating container in a pod ?
Ans. It is always recommended to create one container in one pod. So it should be one to one mapping to safeguard your applications.
6. Can we shutdown or restart a pod ?
Ans. While there is no direct command to shutdown or restart a pod in Kubernetes but you can certainly do the needful by removing or restarting deployment or statefulset which manages the pod. If you are looking to shutdown a pod then you can follow below method depending on your requirement and use cases:-
- To shutdown a pod, you can simply delete it by using
kubectl delete pod <pod_name>, however please note that replication controller will bring up new set of pods depending on the number of replicas set.
- Another way to shutdown or remove the pod is by scaling down the replica to 0 using
kubectl scale --replicas=0 deployment/<deployment_name>command.
- Finally, you can always remove all the pods permanently by removing the deployment or statefulset itself using
kubectl delete deployment <deployment_name>or
kubectl delete statefulsets <statefulset_name>command.
Similarly, if you are looking to restart a pod then you can do it through below different ways:-
- To restart a pod, you can perform rollout restart of deployment using
kubectl rollout restart deployment <deployment_name>command. It will terminate old pods and create new ones in a controlled manner.
- You can simply delete the pod using
kubectl delete pod <pod_name>and then based on your configuration replication controller will bring up new pods.
7. Can we shutdown or restart a container inside a pod without affecting other containers ?
Ans. It is not possible to shutdown or restart a container inside a pod as pod is the smallest deployable unit in Kubernetes, not the individual containers within it. However, you can indirectly caused a container to restart by updating its image or configuration. Kubernetes will terminate the old pod and start a new one with the updated configuration.
8. Does crashing of one container have any affect on pod ?
Ans. Yes, crashing of any one container inside a pod will crash the pod itself, hence it is always recommended to run one container in one pod.
9. How does containers in a pod communicate with each other ?
Ans. Containers in the same pod communicate with each other using localhost as they share the same network namespace. This means they can communicate over any port the application in the containers is listening on.
10. How does two pods in a namespace communicate with each other ?
Ans. Pods within the same namespace can communicate using Kubernetes services. A service provides a single, stable IP address and DNS name by which pods can communicate. The service routes traffic to the appropriate pod based on its label selector.
11. How does two pods in different namespace communicate with each other ?
Ans. For pods in different namespaces to communicate, you typically use Kubernetes services. You need to reference the service with its fully qualified domain name (FQDN) in the format
service-name.namespace.svc.cluster.local. This ensures that the traffic is correctly routed to the service in the other namespace. Additionally, network policies need to be configured to allow traffic between namespaces if such restrictions are in place.
12. How to delete a pod ?
Ans. To delete a pod, you can use
kubectl delete pod <pod_name> command.
13. How to check logs of a pod ?
Ans. To check the logs of a pod, you can use
kubectl logs <pod_name> command.
14. How to check the description of a pod ?
Ans. To check the description of a running pod, you can use
kubectl describe pod <pod_name> command.
15. How to execute a command against a container in a pod ?
Ans. You can use
kubectl exec <pod_name> -c <container_name> <command> coommand.
16. How to create a pod ?
Ans. You can create a manifest file and then create pod using that file by applying it on a cluster using
kubectl apply -f <manifest_file> command.
17. What is sidecar container in a pod ?
Ans. Sidecar container is basically a container supporting the main container inside a Kubernetes pod. So for example, if you need an application and a log collector container in a pod then you can run your application as main or primary container and log collector as sidecar container.
18. How to troubleshoot a failing Kubernetes pods ?
Ans. To troubleshoot failing pods, you can use below commands:-
- To check and verify the problematic pods, you have to run
kubectl get pods -o wideto check the status of pods.
- If the pod is in running state but not yet ready then you can check the logs of pod using
kubectl logs -f <pod_name>command to understand the reasons for pod not going into ready state.
- You can also check the description of pod using
kubectl describe pod <pod_name>to understand the reason for failure in container creation.
- Additionally, you can also check all the events using
kubectl get eventscommand.
- If the problem in pod is happening due to node, then check the node status by running
kubectl get nodescommand.
- Similarly pod problem may happen due to issue in deployment or statefulset or replicaset. For that you can run
kubectl get <deployments/statefulset/rs> -o yamlcommand depending on your issue. You can also check Kubernetes pod stuck in terminating state for long to know more about fixing other types of pod related error.
19. What is a static pod in Kubernetes ?
Ans. Static pod is a pod which is managed directly by the kubelet daemon on a specific node, without the api server observing them.
20. Can a pod belong to multiple ReplicaSets or Deployments?
Ans. In Kubernetes, a pod typically cannot belong to multiple ReplicaSets or Deployments simultaneously. When you create a Deployment, it automatically creates a ReplicaSet to ensure that the specified number of pod replicas are running at all times. The ReplicaSet then creates the pods. Each pod is labeled with unique identifiers that tie it to its ReplicaSet and, by extension, to the Deployment.
If you were to try to manually assign a pod to multiple ReplicaSets or Deployments, it would lead to conflicts and undefined behavior. Kubernetes is designed to maintain clear ownership and lifecycle management of pods through these controllers, and the design does not support a pod being controlled by multiple ReplicaSets or Deployments.
21. What is a pod manifest in Kubernetes ?
Ans. A pod manifest is a YAML or JSON file which defines the pod properties and configurations which has to be applied in a namespace or context in a Kubernetes cluster.
22. Can you scale pods in Kubernetes ?
Ans. Yes, you can scale pod using Deployment or replication controller.
23. What is pod affinity and anti-affinity?
Ans. Pod affinity and anti-affinity are policies that allow you to specify how pods should be placed relative to other pods:-
- Pod Affinity: It is used to attract pods to nodes with certain labels or pods already running on those nodes. For example, you might want certain pods to run on the same or nearby nodes for performance reasons.
- Pod Anti-affinity: It is used to repel pods from certain nodes or other pods. This is useful for spreading pods across nodes for high availability or fault tolerance.
24. Is it possible to update a running pod in Kubernetes?
Ans. It is not possible to directly update a running pod in Kubernetes because pods are considered to be immutable, ephemeral and disposable entities. To update a pod, you typically update the Deployment, ReplicaSet, or another controller that manages the pod. The controller then automatically handles the process of creating new pods with the updated configuration and terminating the old ones. This process can be managed to achieve a rolling update, ensuring that the application remains available during the update process.
25. How to monitor the health of a Pod ?
Ans. In general, the health of a pod can be monitored by using probes to check if the pods are running as expected. There are different types of probes that you can make use of :-
- Liveness Probes: This probe is used to check if the application in a pod is running. If a liveness probe fails, Kubernetes restarts the container in the pod.
- Readiness Probes: Determine if a pod is ready to accept traffic. If a pod is not ready, it's removed from the service load balancer.
- Startup Probes: Used to know when a container application has started. If such a probe is configured, other probes are disabled until it succeeds, ensuring that applications with longer startup times aren't killed prematurely by Kubernetes.
These probes can be configured in the pod's specification and can use various methods, such as HTTP GET requests, TCP socket checks, or executing a command inside the container. Additionally, Kubernetes provides metrics and logs that can be monitored using tools like Prometheus for metrics and Elasticsearch for logs, which can give insights into the health and performance of pods.
26. What are init containers in a pod ?
Ans. Init containers are specialized containers that run before app containers and are used for setup scripts or utilities that are not part of the main application.
27. How does service discovery work for pods in Kubernetes ?
Ans. Service discovery in Kubernetes works primarily through Services and DNS. The combination of Services and DNS provides a powerful, flexible method for services to discover and communicate with each other in a Kubernetes environment. A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services are assigned a unique IP address and DNS name.
When a Service is created, it gets a DNS entry. Pods within the same cluster can communicate with each other by using the DNS name of the Service. This DNS-based service discovery allows pods to easily locate one another and the services they need to interact with. Kubernetes also supports service discovery through environment variables, but this method is less dynamic compared to DNS.
28. How to inject configuration data into running application pod in Kubernetes ?
Ans. To inject configuration data into a running application pod in Kubernetes, you typically use ConfigMaps or Secrets:-
- ConfigMaps: It allows you to decouple configuration artifacts from image content to keep containerized applications portable. You can create a ConfigMap containing the configuration data and mount it as a volume in the pod specification. Alternatively, you can expose ConfigMap data as environment variables.
- Secrets: Although it is very similar to ConfigMaps but it is used for sensitive and confidential data. You can mount Secrets into your pods as files in a volume or expose them as environment variables.
In both cases, the application in the pod can access this data as if it were part of its filesystem or as environment variables.
29. How to check the resource utilization of a pod in Kubernetes ?
Ans. You can use
kubectl top pod <pod_name> to check the resource utilization of a pod in Kubernetes.
30. How to compare the running configuration of two pods from two different namespaces ?
Ans. To compare the running configuration of two pods from different namespaces in Kubernetes, you can perform below steps:-
- Retrieve Pod Configurations: Use
kubectl get pod <pod-name> -n <namespace> -o yamlto get the configuration of each pod in its respective namespace. This command outputs the complete configuration and current state of the pod in YAML format.
- Save Configurations to Files: Then save each output to a separate file for easier comparison.
- Compare Files: Use a file comparison tool or a diff tool like the
diffcommand in Linux to compare the two configuration files. This will highlight the differences in configuration between the two pods.