20230911170851.md

title
Pods

Pods

What are Pods?

• A Pod is where deployed apps run
• Run kubectl explain pods --recursive to find out more information

Pod features

• Labels - attach identifying data, can be used to group Pods and associate them with other objects
• Annotations - attach non-identifying data, used by tools and libraries
• Probes - used to test the health and status of Pods and the applications running in them
• Affinity and non-affinity rules - provides control over where Pods are allowed to run
• Termination control - lets you gracefully terminate Pods and the applications running within them
• Security policies - enforce security features
• Resources requests and limits - allows you to specify minimum and maximum values for resources

Shared resources

• Pods allow containers to share resources e.g. filesystem, network stack, memory, and volumes

Static Pods

• Static Pods are deployed via a Pod manifest

apiVersion: v1
kind: Pods
metadata:
  name: hello-pod
  labels:
    zone: prod
    version: v1
  spec:
    containers:
    - name: hello-ctr
    - image: nginx:1.25.2
    ports:
    - containerPort: 80

• They don't come with the benefits of being managed by a controller i.e. no self healing
• Directly managed by a kubelet daemon on a single node

Controller Pods

• Have the benefits of being managed by a controller
• The generally used way of managing Pods

Deploying a Pod

1. Define a manifest
2. POST the YAML to the API server
3. API server authenticates and authorises the request
4. The manifest is validated
5. Scheduler deploys the Pod to a worker node
6. The local kubelet daemon monitors it

• Pod deployments are atomic

Pod anatomy

• Pods share the same namespaces:
  • net namespace - virtualised network stack
  • pid namespace - indepentent set of process IDs
  • mnt namespace - volumes
  • UTS (UNIX Time-Sharing) namespace - unique hostnames and domain names
  • IPC (Inter-process Communication) namespace - manages shared memory

Pod network

• All Pods get a unique IP address that is fully routable on an internal kubernetes network
• Allows all Pods to communicate with each other via a flat overlay network regardless of the physical network that they exist within (assumming connectivity of the physical networks)
• Default pod network is not secure and should be tightened with Kubernetes Network Policies

Types of Pod workloads

• Long-lived Pods are ones which should stay running indefinitely, the kubelet should attempt to restart them should they fail - restart policy permitting (Always, OnFailure, Never)
• Short-lived Pods only run until a task is complete e.g. a batch job, once all the containers in a Pod successfully terminates, the Pod will
• Long-lived workload controllers include Deployments, StatefulSets, and DaemonSets
• Short-lived workload controllers include Jobs, and CronJobs

Scaling

• Since Pods run a single application container instance, they scale horizontally i.e. new Pods are added or removed

Multicontainer Pods

• Multiple containers should be used to 'seperate concerns'
• Multicontainer Pods can be used to ensure tightly coupled process can run together in a shared execution environment - particularly important for service meshes
• There are multiple patterns for multicontainer Pods:
  • Sidecar - a primary application container and secondary 'sidecar' container to carry out tasks for the primary container
  • Adapter - variation of the sidecar pattern to reformat non-standard output from the primary container to one required elsewhere
  • Ambassador - variation of the sidecar pattern where the primary container exposes data to a port that the ambassador is listening to, the ambassador then sends that data elsewhere
  • Init - A secondary container that runs only once to initialise the environment for the primary container, the primary container won't start until the init container completes