Sidecar Containers documentation is incorrect

[3wweiweiwu]

It seems like the document does not contains a valid example of sidecar container.

Following yaml file only contains an init container. It does not serve the purpose of sidecar container.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.

[stmcginnis]

Hey! That example actually is correct. An init container with a restartPolicy of "Always" is a sidecar container.

Please see the explanation here: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/#sidecar-containers-and-pod-lifecycle

[3wweiweiwu]

@stmcginnis Thank you so much for the prompt response. I am a little bit confused. I thought init container will run before actual container kick-in. If we use init container as a side car container, will that cause working pod to wait forever?

[iheartNathan]

A sidecar container shared the same lifecycle as the main app container. This should help - https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy Regular initcontainer honours the restartPolicy on the pod level, while sidecar containers honours the restartPolicy on the initContainers level.

[sftim]

/retitle Sidecar Containers documentation is incorrect /kind bug /priority awaiting-more-evidence /triage not-reproducible

[sftim]

Usually when people see this they are running a very old (maybe unsupported) version of Kubernetes. The documentation for sidecar containers doesn't make the problem clear.

What Kubernetes version did you see this with @3wweiweiwu? Maybe my guess about "very old" is incorrect; I'd like to know for sure.