Pods

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

Storage

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

Containers

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:

command refers to Docker's entrypoint
args maps to Docker's command

Initialisation containers

Containers specified in the initContainers field of the pod specification will run to completion before the application containers will start.

Liveness probes

Liveness probes are used to determine when the pod needs to be restarted.

Readiness probes

Readiness probes determine when the pod is considered ready, and is used to determine when endpoints should be created to back services.

Networking

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.

Host NICs

The 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.

Similarly, hostPort lets a pod request a port on the host node.

DNS resolution

A Pod's 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 hostNetwork.
"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 default.

Pause container

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.