This page provides an overview of init containers: specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. You can specify init containers in the Pod specification alongside the containers array (which describes app containers). In Kubernetes, a sidecar container is a container that starts before the main application container and continues to run. This document is about init containers: containers that run to completion during Pod initialization.

FEATURE STATE: Kubernetes v1.23 [stable] Your Kubernetes cluster includes dual-stack networking, which means that cluster networking lets you use either address family. In a cluster, the control plane can assign both an IPv4 address and an IPv6 address to a single Pod or a Service. Before you begin You need to have installed the kubeadm tool, following the steps from Installing kubeadm. For each server that you want to use as a node, make sure it allows IPv6 forwarding.

In Kubernetes, Services are an abstract way to expose an application running on a set of Pods. Services can have a cluster-scoped virtual IP address (using a Service of type: ClusterIP). Clients can connect using that virtual IP address, and Kubernetes then load-balances traffic to that Service across the different backing Pods. How Service ClusterIPs are allocated? When Kubernetes needs to assign a virtual IP address for a Service, that assignment happens one of two ways:

Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory.

FEATURE STATE: Kubernetes v1.29 [stable] Controlling the behavior of the Kubernetes API server in an overload situation is a key task for cluster administrators. The kube-apiserver has some controls available (i.e. the --max-requests-inflight and --max-mutating-requests-inflight command-line flags) to limit the amount of outstanding work that will be accepted, preventing a flood of inbound requests from overloading and potentially crashing the API server, but these flags are not enough to ensure that the most important requests get through in a period of high traffic.

This page explains how to configure the kubelet's cgroup driver to match the container runtime cgroup driver for kubeadm clusters. Before you begin You should be familiar with the Kubernetes container runtime requirements. Configuring the container runtime cgroup driver The Container runtimes page explains that the systemd driver is recommended for kubeadm based setups instead of the kubelet's default cgroupfs driver, because kubeadm manages the kubelet as a systemd service.

FEATURE STATE: Kubernetes v1.25 [alpha] (enabled by default: false) This page shows how to migrate nodes to use event based updates for container status. The event-based implementation reduces node resource consumption by the kubelet, compared to the legacy approach that relies on polling. You may know this feature as evented Pod lifecycle event generator (PLEG). That's the name used internally within the Kubernetes project for a key implementation detail.

Define a default CPU resource limits for a namespace, so that every new Pod in that namespace has a CPU resource limit configured.

Define a default memory resource limit for a namespace, so that every new Pod in that namespace has a memory resource limit configured.

FEATURE STATE: Kubernetes v1.29 [beta] Sidecar containers are the secondary containers that run along with the main application container within the same Pod. These containers are used to enhance or to extend the functionality of the primary app container by providing additional services, or functionality such as logging, monitoring, security, or data synchronization, without directly altering the primary application code. Typically, you only have one app container in a Pod.