8.14 Kubernetes Application Container Usage

Kubernetes Application Container Usage is the set of practices and configuration options governing how the primary, long-running workload containers within a Pod are defined, started, monitored, and terminated, as distinct from init containers or sidecars.

Defining Application Containers

Container Specification

Each application container is declared under a Pod's spec.containers list with an image, command, arguments, ports, environment variables, and resource requirements. Unlike init containers, all application containers in a Pod start concurrently and are expected to run for the lifetime of the Pod.

Image and Command Overrides

An application container can override the image's default ENTRYPOINT and CMD using the Pod spec's command and args fields, allowing the same image to be reused for different roles without rebuilding it.

Multi-Container Pods

When a Pod defines more than one application container, those containers share the same network namespace and can share volumes, but each has its own filesystem, process space, and resource limits. This pattern is used for tightly coupled helper processes, such as a log shipper running alongside a main server process.

Lifecycle Management

Restart Policy

The Pod-level restartPolicy (Always, OnFailure, or Never) determines whether the kubelet restarts an application container after it exits. Always is standard for long-running services managed by a Deployment, while OnFailure or Never are typical for Jobs that are expected to run to completion.

Probes

Application containers commonly define liveness, readiness, and startup probes. A liveness probe determines whether the container should be restarted because it has entered an unrecoverable state; a readiness probe determines whether the container should receive traffic from a Service; a startup probe delays the other two probes until a slow-starting application has finished initializing.

Lifecycle Hooks

The postStart and preStop lifecycle hooks let an application container run a command or HTTP request immediately after creation or immediately before termination. preStop is frequently used to drain in-flight connections gracefully before the container receives its termination signal.

Resource Management

Requests and Limits

Each application container can declare CPU and memory requests, used by the scheduler to place the Pod on a node with sufficient capacity, and limits, enforced by the container runtime to cap actual usage. Exceeding a memory limit results in the container being terminated by the out-of-memory killer, while exceeding a CPU limit results in throttling rather than termination.

Quality of Service Classes

The combination of requests and limits across all containers in a Pod determines its Quality of Service class: Guaranteed when every container's requests equal its limits, Burstable when at least one container defines requests or limits without full equality, and BestEffort when no container defines either. This classification affects which Pods are evicted first under node memory pressure.

Communication and Isolation

Shared Network Namespace

All application containers in a Pod share a single IP address and port space, meaning two containers in the same Pod cannot bind to the same port and communicate with each other over localhost.

Container-Level Security Context

Each application container can define its own securityContext, controlling settings such as running as a non-root user, dropping Linux capabilities, or making the root filesystem read-only, independent of the Pod-level security context.