up:: [[Kubernetes MOC]] tags:: #note/boat #note/develop #on/kubernetes # Kubernetes Pods In [[Kubernetes]], a **Pod** is a group of one or more containers. These containers share storage and network resources, along with a specification for how to run the containers. - Models an application-specific "logical host" - Contains one or more application containers that are tightly coupled - Applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host - Can contain "init containers" and "ephemeral containers" as well - Similar to a set of containers with shared namespaces and shared filesystem volumes - Used in two main ways - Pods that run a single container (most common use case) - Pods that run multiple containers that need to work together - Co-located containers that need to share resources - Containers form a single cohesive unit - Grouping multiple co-located containers in a single Pod is an advanced use case - **Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disk** - Generally not created directly; created using workload resources such as a Deployment or a Job - Each Pod is meant to run a single instance of a given application - To scale horizontally, use multiple Pods (one for each instance); in Kubernetes this is referred to as *replication* - Replicated Pods are usually created and managed as a group by a workload resource and its controller - Pods are the atomic unit of Kubernetes ## Working With Pods - You'll rarely create individual Pods directly in Kubernetes - Pods are designed as ephemeral, disposable entities - After creation, a Pod is scheduled to run on a Node in your cluster and remains on that node until either: - The Pod finishes execution - The Pod object is deleted - The Pod is evicted for lack of resources - The node fails - Restarting a container is not the same are restarting a Pod - A Pod is not a process, it is an environment for running containers - The name of a Pod must be a valid DNS subdomain - For best compatibility, follow RFC 1123 or RFC 1035 - Pods can run either Windows or Linux - You can create workload resources to create and manage multiple Pods for you - Controller for the resource handles replication and rollout and automatic healing in case of Pod failure (eg., if a Node fails, then the controller will notice that and create a replacement Pod on a healthy Node) - Controllers for workload resources create Pods from Pod Templates - Editing a template doesn't affect existing Pods ## Resource Sharing and Communication ### Storage - A Pod can specify a set of shared storage volumes - All containers in a Pod can access the shared volumes - Volumes allow persistent data in a Pod to survive in case one of the containers within needs to be restarted - See the [Kubernetes Storage Documentation](https://kubernetes.io/docs/concepts/storage/) for more info ### Networking - Each Pod is assigned a unique IP address for each address family - Every container in a Pod shares the network namespace, including the IP address and network ports - Within a Pod, containers can communicate with each other using `localhost` - Containers share an IP address and port space - Containers within a Pod can also communicate using standard IPCs like semaphores or POSIX shared memory - Containers in different Pods have distinct IP addresses and cannot communicate by OS-level IPC without special configuration - When containers in a Pod try to communicate with something outside the Pod, they must coordinate how they use the shared network resources (such as ports) - Containers that want to interact with a container running in a different Pod can use IP networking to communicate - Containers within a Pod see the system hostname as being the same as the configured `name` for the Pod ## Static Pods - Managed directly by the kubelet daemon on a specific node, without the API server observing - Most Pods are managed by the control plane (for example, a Deployment), but kubelet directly supervises each static Pod - Always bound to one Kubelet on a specific node - Main use is to run a self-hosted control plane - The Kubelet automatically tries to create a mirror Pod on the Kubernetes API server for each static Pod - Allows the Pods to be visible on the API server, though they cannot be controlled from there ## Pod Lifecycle - Pods follow a defined lifecycle - While a Pod is running, the kubelet is able to restart containers to handle faults - Within a Pod, Kubernetes tracks different container states and determines what action to take to make the Pod healthy again - Pods have both a specification and an actual status - Status consists of a set of Pod conditions - You can inject custom readiness information into the condition data for a Pod, if that is useful to you - Pods are only scheduled once in their lifetime - Once scheduled (assigned) to a Node, the Pod runs on that Node until it stops or is terminated - Pod lifetime - Pods are considered to be ephemeral - If a Node dies, the Pods scheduled to that Node is scheduled for deletion after a timeout period - Pods do not, by themselves, self-heal - If a Pod is scheduled to a Node that fails, it is deleted - Kubernetes uses controllers to handle the work of managing Pod instances - Pods are never "rescheduled" to a different node - Instead, a Pod can be replaced by a new, near-identical Pod - The new Pod can even have the same name as the old one - The UID will be different - If something is said to have the same lifetime as a Pod, such as a volume, that means that the thing exists as long as that specific Pod (with that exact UID) exists - If the Pod is deleted, the related thing is also deleted (even if an identical replacement Pod is created) ### Pod Phases - A Pod's `status` field is a `PodStatus` object, which has a `phase` field - The phase is a simple, high-level summary of where the Pod is in its lifecycle - Not a comprehensive rollup of observations of container or Pod state - Possible values for `phase` - *Pending*: The Pod has been accepted by the cluster, but one or more of the containers has not been set up and made ready to run - *Running*: Pod has been bound to a Node and all of the containers have been created; at least one container is still running, starting, or restarting - *Succeeded*: All containers in the Pod have terminated in success and will not be restarted - *Failed*: All containers in the Pod have terminated, and at least one terminated in failure - *Unknown*: State of the Pod could not be obtained. ## References - [Kubernetes Documentation](https://kubernetes.io/docs/concepts/workloads/pods/)