☸️ Kubernetes - Pods
Kubernetes pod represents a running process on your cluster. Pod usually wraps a single container, but can also be a small group of tightly coupled containers that share resources on the same node.
Pod is the smallest deployable object in Kubernetes. You rarely create individual pods by hand, you use higher-level controllers to handle that.
But which controller to use to manage my pods?
Deploymentcontroller for persistent services.
DaemonSetcontroller for background processes that should run on each node.
Jobcontroller for batch workloads that are executed to termination.
Docker is the most common pod container runtime. Kubernetes pods do support other container runtimes as well.
Each pod is meant to run a single instance of a given application. Similar concept where you have one or multiple workers for your web application.
You scale with pod replication. To horizontally scale the behavior, you would add more pods of the same type to the cluster. This is referred as replication.
Replicated pods are usually managed as a group by an abstraction called a controller. Controller has desired state that it wants to maintain and replicating pods is one of the ways controller can drive towards the desired state.
Pods running on unreachable nodes are in
You can control pod-to-node scheduling with node labels. Allows constrain a pod to only eligible to run on a subset of nodes.
Each pod is assigned a unique IP address. All containers in a pod also share the IP and ports. Containers in the pod can communicate using
Multi-container pods can use shared volumes for storage. Then restarting one container won't affect the volume.
Controllers use pod templates to create the actual pods. The pod templates used by common controllers are pretty much the same as creating a pod manually but you don't specify
# apiVersion: v1
# kind: Pod
- name: myapp-container
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
Pods don't self-heal or reallocate themselves. Controllers handle that behavior, pod only controls the containers inside of it.
restartPolicy: Always|OnFailure|Never tells should a pod restart its containers.
Always is the default.
Pods maintain no reference to the templates they were created from. Changes to the template or replacing the template doesn't affect already started pods. You need to either modify the higher level controller that is currently managing the pod, or the pod definition itself.
Containers in separate pods usually communicate with pod IP and DNS addresses. These are internal to the cluster.
Default grace period for pod deletion is 30 seconds. Grace period gives time to pod to quit safely and other services such as load balancer to remove the pod from the fleet.
kubelet notices the status change and triggers
Pod status field is an instance of
pending: pod has been accepted and is preparing e.g. downloading the images
running: pod has been assigned to a node and all the containers are running
succeeded: all pod containers have terminated in success
failed: all pod containers have terminated, and at least one of them was fail
unknown: pod status could not be obtained, most likely an issue with the node
- array of
- array of
You can define probes to customize health checks of your pods:
liveness probeto customize when the pod is considered to be alive.
readiness probeto customize when to send traffic to the pod.
Example liveness proble:
# when "host" is not defined, "PodIP" will be used
# host: my-host
# when "scheme" is not defined, "HTTP" scheme will be used.
# Only "HTTP" and "HTTPS" are allowed
# scheme: HTTPS
- name: X-Custom-Header