diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index f21c8f825d42f..4b8f10e9fc818 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -51,8 +51,9 @@ including resource limits, [volumes](/docs/concepts/storage/volumes/), and secur resource requests and limits for an init container are handled differently, as documented in [Resource sharing within containers](#resource-sharing-within-containers). -Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or -`startupProbe` because they must run to completion before the Pod can be ready. +Also, init containers(except `sidecar init containers`) do not support `lifecycle`, +`livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion +before the Pod can be ready. If you specify multiple init containers for a Pod, kubelet runs each init container sequentially. Each init container must succeed before the next can run. @@ -68,9 +69,12 @@ init containers are not continuously running alongside the main containers. Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed. -Init containers share the same resources (CPU, memory, network) with the main containers -but do not interact directly with them. They can, however, use shared volumes for data -exchange. +init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or +`startupProbe` whereas sidecar containers support all these [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. + +Init containers share the same resources (CPU, memory, network) with the main application +containers but do not interact directly with them. They can, however, use shared volumes +for data exchange. ## Using init containers @@ -328,6 +332,10 @@ limit. Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler. +{{< note >}} +This section also present under [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) page. +{{< /note >}} + ### Pod restart reasons A Pod can restart, causing re-execution of init containers, for the following diff --git a/content/en/docs/concepts/workloads/pods/sidecar-containers.md b/content/en/docs/concepts/workloads/pods/sidecar-containers.md index 58836814c4d15..bb7b88b11d6b2 100644 --- a/content/en/docs/concepts/workloads/pods/sidecar-containers.md +++ b/content/en/docs/concepts/workloads/pods/sidecar-containers.md @@ -1,5 +1,5 @@ --- -title: API for sidecar containers +title: sidecar containers content_type: concept weight: 50 --- @@ -7,25 +7,22 @@ weight: 50 {{< feature-state for_k8s_version="v1.28" state="alpha" >}} -Sidecar containers are the secondary containers that runs along with the main +Sidecar containers are the secondary containers that run along with the main application container within the same {{< glossary_tooltip text="Pod" term_id="pod" >}}. -These containers are used to enhance or extend the functionality of the primary container -by providing additional services, or functionality such as logging, monitoring, security, -or data synchronization, without directly altering the primary application code. +These containers are used to enhance or to extend the functionality of the main application +container by providing additional services, or functionality such as logging, monitoring, +security, or data synchronization, without directly altering the primary application code. -Starting with Kubernetes 1.28 in alpha, a feature gate named `SidecarContainers` -allows you to specify a `restartPolicy` for containers listed with a Pod's `initContainers` -field. These restartable _sidecar_ containers are independent of other -[init containers](/docs/concepts/workloads/pods/init-containers/) and main application -container within the same pod. These can be started, stopped, or restarted independently -of the main container and other init containers. -Container [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) -can also be added to control their lifecycle. +Starting with Kubernetes 1.28, a feature gate named `SidecarContainers` allows you to +specify a `restartPolicy` for containers listed in a Pod's `initContainers` field. These +restartable _sidecar_ containers are independent with other [init containers](/docs/concepts/workloads/pods/init-containers/) and main application container within +the same pod. These can be started, stopped, or restarted without effecting the main +application container and other init containers. If an init container is created with its `restartPolicy` set to `Always`, it will -start and remain running during the entire life of the Pod, which is useful for +start and remain running during the entire life of the Pod. This can be helpful for running supporting services separated from the main application containers. If a `readinessProbe` is specified for this init container, its result will be used @@ -56,9 +53,8 @@ has finished. Here's an example of a Job with two containers, one of which is a sidecar: {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}} -By default, this feature is not available in Kubernetes. To avail this feature, -we need to enable the feature gate `SidecarContainers` by setting the value **true** -to it. +By default, this feature is not available in Kubernetes. To avail this feature, you +need to enable the feature gate named `SidecarContainers` by setting the value **true** to it. ## Differences from regular containers @@ -80,7 +76,8 @@ providing additional services. Sidecar containers run concurrently with the main application container. They are active throughout the lifecycle of the pod and can be started and stopped independently of the -main container. +main container. Unlike [init containers](/docs/concepts/workloads/pods/init-containers/), +sidecar containers support [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. These containers can interact directly with the main application containers, sharing the same network namespace, filesystem, and environment variables. They work closely @@ -88,9 +85,30 @@ together to provide additional functionality. ## Resource sharing within containers -Given the ordering and execution for init containers, there are certain rules -for resource usage apply. [Resource sharing within containers](/docs/concepts/workloads/pods/init-containers/#resource-sharing-within-containers) under init -containers page explains more details on this. +Given the ordering and execution for init containers, the following rules +for resource usage apply: + +* The highest of any particular resource request or limit defined on all init + containers is the *effective init request/limit*. If any resource has no + resource limit specified this is considered as the highest limit. +* The Pod's *effective request/limit* for a resource is the higher of: + * the sum of all app containers request/limit for a resource + * the effective init request/limit for a resource +* Scheduling is done based on effective requests/limits, which means + init containers can reserve resources for initialization that are not used + during the life of the Pod. +* The QoS (quality of service) tier of the Pod's *effective QoS tier* is the + QoS tier for init containers and app containers alike. + +Quota and limits are applied based on the effective Pod request and +limit. + +Pod level control groups (cgroups) are based on the effective Pod request and +limit, the same as the scheduler. + +{{< note >}} +This section also present under [init containers](/docs/concepts/workloads/pods/init-containers/) page. +{{< /note >}} ## {{% heading "whatsnext" %}}