Pods are a group of one or more containers. Conventionally they'll contain one primary container that provides a service and sidecars that help with metrics collection and logging in a producer-consumer model.
Pods are short-lived, and their containers are removed from the node at termination time.
apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mycontainer image: hello-world
A pod can be attached to any number of Volumes, and a container can mount any number of Volumes at different paths.
# Inside a Pod.spec volumes: - name: data persistentVolumeClaim: claimName: my-pvc containers: - name: app volumeMounts: - name: data mountPath: /data
Each container can have:
- Resource limits that govern what resources they'll reserve at startup and upper limits of what they can request.
- Health probes that can determine liveness and readiness, determining whether traffic is directed to these pods.
- Volume mounts enabling access to storage.
Note the different names given to the configuration for containers' start commands:
commandrefers to Docker's
argsmaps to Docker's
Containers specified in the
initContainers field of the pod specification will run to completion before the application containers will start.
Liveness probes are used to determine when the pod needs to be restarted.
Readiness probes determine when the pod is considered ready, and is used to determine when endpoints should be created to back services.
All Containers in a Pod share a network namespace, initialised by the
pause container. This means:
- they both share a loopback adapter (
localhost), IP address and source port range.
- they cannot both expose the same ports.
Communication between pods on the same Node takes place via a local software bridge adapter, via their own IP addresses.
hostNetwork setting allows pods to see the host node's network interfaces, and thus can listen on the host's network interfaces. In this configuration, binding to all network interfaces will also bind to the host's NICs.
hostPort lets a pod request a port on the host node.
dnsPolicy determines how a Pod performs name resolution:
"ClusterFirst"is the default behaviour if left unconfigured; any query for a name outside of the cluster's name suffix is forwarded to the upstream nameserver inherited from the node.
"ClusterFirstWithHostNet"must be used for Pods running in a
"None"allows us to configure a custom
dnsConfig, which sets the Pod's nameservers and search suffixes.
"Default"inherits the Node's configuration.
Using a ServiceAccount
Specify the name of a Kubernetes ServiceAccount in the
Pod.spec.serviceAccountName field to authenticate as it rather than the
pause container serves as the parent container for all other containers in the pod. It's started by Kubernetes ahead of the pod's other workloads.
Transient failures (e.g. a node going offline) will result in the Kubelet on the node restarting the pod.
Permanent failures (where the pod eviction timeout is exhausted) result in termination and recreation of the pod.
- Continuous Delivery (public)
- ACI (public)
- Kubernetes (public)
- API Server (public)
- DaemonSets (public)
- Deployments (public)
- HPA (public)
- Jobs (public)
- Kubelet (public)
- kube-proxy (public)
- Node (public)
- PersistentVolumes (public)
- PersistentVolumeClaim (public)
- ReplicaSets (public)
- ReplicationControllers (public)
- Scheduler (public)
- Selectors (public)
- Services (public)
- ServiceAccounts (public)
- Storage (public)
- Volumes (public)
- 2022-01-13 (internal) (Private)