adding Sidecar Containers alpha feature

Signed-off-by: Matthias Bertschy <matthias.bertschy@gmail.com>

content/en/blog/_posts/2015-06-00-The-Distributed-System-Toolkit-Patterns.md

@@ -24,6 +24,7 @@ When you start thinking in terms of Pods, there are naturally some general patte
 
 ## Example #1: Sidecar containers
 
+// TODO add Sidecars KEP
 Sidecar containers extend and enhance the "main" container, they take existing containers and make them better.  As an example, consider a container that runs the Nginx web server.  Add a different container that syncs the file system with a git repository, share the file system between the containers and you have built Git push-to-deploy.  But you’ve done it in a modular manner where the git synchronizer can be built by a different team, and can be reused across many different web servers (Apache, Python, Tomcat, etc).  Because of this modularity, you only have to write and test your git synchronizer once and reuse it across numerous apps. And if someone else writes it, you don’t even need to do that.
 
 ![Sidecar Containers](/images/blog/2015-06-00-The-Distributed-System-Toolkit-Patterns/sidecar-containers.png)
@@ -43,4 +44,4 @@ Adapter containers standardize and normalize output.  Consider the task of
 
 In all of these cases, we've used the container boundary as an encapsulation/abstraction boundary that allows us to build modular, reusable components that we combine to build out applications.  This reuse enables us to more effectively share containers between different developers, reuse our code across multiple applications, and generally build more reliable, robust distributed systems more quickly.  I hope you’ve seen how Pods and composite container patterns can enable you to build robust distributed systems more quickly, and achieve container code re-use.  To try these patterns out yourself in your own applications. I encourage you to go check out open source Kubernetes or Google Container Engine. 
 
- - Brendan Burns, Software Engineer at Google
+ - Brendan Burns, Software Engineer at Google

content/en/docs/concepts/workloads/pods/_index.md

@@ -112,11 +112,15 @@ that updates those files from a remote source, as in the following diagram:
 
 {{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}}
 
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. By default, init containers run and complete before the app containers are started.
 
 Pods natively provide two kinds of shared resources for their constituent containers:
 [networking](#pod-networking) and [storage](#pod-storage).
 
+{{< feature-state for_k8s_version="v1.28" state="alpha" >}}
+
+Enabling the [SidecarContainers feature gate](/docs/reference/command-line-tools-reference/feature-gates/) allows specifying a <code>restartPolicy=Always</code> to init containers, making sure they are restarted when they fail. This is useful for containers that are needed by the main application during its lifetime, for example to provide network connectivity or log forwarding capabilities.
+
 ## Working with Pods
 
 You'll rarely create individual Pods directly in Kubernetes—even singleton Pods. This
@@ -366,4 +370,4 @@ To understand the context for why Kubernetes wraps a common Pod API in other res
 * [Borg](https://research.google.com/pubs/pub43438.html)
 * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html)
 * [Omega](https://research.google/pubs/pub41684/)
-* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).
+* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).

content/en/docs/concepts/workloads/pods/init-containers.md

@@ -6,6 +6,8 @@ content_type: concept
 weight: 40
 ---
 
+// TODO add Sidecars KEP
+
 <!-- overview -->
 This page provides an overview of init containers: specialized containers that run
 before app containers in a {{< glossary_tooltip text="Pod" term_id="pod" >}}.
@@ -332,5 +334,4 @@ Kubernetes, consult the documentation for the version you are using.
 ## {{% heading "whatsnext" %}}
 
 * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
-* Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/)
-
+* Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/)

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -168,7 +168,7 @@ PodConditions:
  Pod sandbox has been successfully created and networking configured.
 * `ContainersReady`: all containers in the Pod are ready.
 * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
- have completed successfully.
+ have completed successfully. // TODO add ready for sidecars
 * `Ready`: the Pod is able to serve requests and should be added to the load
  balancing pools of all matching Services.
 
@@ -275,7 +275,7 @@ For a Pod with init containers, the kubelet sets the `Initialized` condition to
 `True` after the init containers have successfully completed (which happens
 after successful sandbox creation and network configuration by the runtime
 plugin). For a Pod without init containers, the kubelet sets the `Initialized`
-condition to `True` before sandbox creation and network configuration starts.
+condition to `True` before sandbox creation and network configuration starts. // TODO add ready for sidecars
 
 ### Pod scheduling readiness {#pod-scheduling-readiness-gate}
 
@@ -573,4 +573,4 @@ pod (see also:
 
 * For detailed information about Pod and container status in the API, see
  the API reference documentation covering
- [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
+ [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.

content/en/docs/reference/command-line-tools-reference/feature-gates.md

@@ -192,6 +192,7 @@ For a reference to old feature gates that are removed, please refer to
 | `SecurityContextDeny` | `false` | Alpha | 1.27 | |
 | `ServiceNodePortStaticSubrange` | `false` | Alpha | 1.27 | 1.27 |
 | `ServiceNodePortStaticSubrange` | `true` | Beta | 1.28 | |
+| `SidecarContainers` | `false` | Alpha | 1.28 | |
 | `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 |
 | `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | |
 | `StableLoadBalancerNodeGet` | `true` | Beta | 1.27 | |
@@ -753,4 +754,4 @@ Each feature gate is designed for enabling/disabling a specific feature:
  feature, you will also need to enable any associated API resources.
  For example, to enable a particular resource like
  `storage.k8s.io/v1beta1/csistoragecapacities`, set `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`.
- See [API Versioning](/docs/reference/using-api/#api-versioning) for more details on the command line flags.
+ See [API Versioning](/docs/reference/using-api/#api-versioning) for more details on the command line flags.