Change:
<del> id: blog-pod </del> <ins> apiVersion: v1beta3 </ins> kind: Pod <del> apiVersion: v1beta1 desiredState: manifest: version: v1beta1 containers: - name: git-sync image: proppy/git-sync imagePullPolicy: PullAlways env: - name: GIT_SYNC_REPO value: https://github.com/GoogleCloudPlatform/kubernetes.git - name: GIT_SYNC_DEST value: /git volumeMounts: - name: markdown mountPath: /git - name: hugo image: proppy/hugo imagePullPolicy: PullAlways env: - name: HUGO_SRC value: /src/contrib/git-sync/demo/blog - name: HUGO_BUILD_DRAFT value: 'true' - name: HUGO_BASE_URL value: example.com volumeMounts: - name: markdown mountPath: /src - name: html mountPath: /dest - name: nginx image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/html ports: - name: http-server containerPort: 80 volumes: </del> <ins> metadata: labels: name: blog name: blog-pod spec: containers: - name: git-sync image: gcr.io/google_containers/git-sync imagePullPolicy: Always volumeMounts: </ins> - name: markdown <del> source: emptyDir: {} </del> <ins> mountPath: /git env: - name: GIT_SYNC_REPO value: https://github.com/GoogleCloudPlatform/kubernetes.git - name: GIT_SYNC_DEST value: /git - name: hugo image: gcr.io/google_containers/hugo imagePullPolicy: Always volumeMounts: - name: markdown mountPath: /src - name: html mountPath: /dest env: - name: HUGO_SRC value: /src/contrib/git-sync/demo/blog - name: HUGO_BUILD_DRAFT value: "true" - name: HUGO_BASE_URL value: example.com - name: nginx image: nginx volumeMounts: </ins> - name: html <del> source: emptyDir: {} labels: name: blog </del> <ins> mountPath: /usr/share/nginx/html ports: - containerPort: 80 volumes: - name: markdown emptyDir: {} - name: html emptyDir: {} </ins>

Discussion:
This causes . In contrib/git-sync demo, the container voluntarily exits and gets recreated to "periodically" sync the git repo, but the pod is then reported as not ready, The end result is that the service targets at this pod does not get endpoints and thus not working. Thanks to for helping with the debugging.
The container was not running when kubelet reported the status, hence it was considered not ready. Because the containers in a pod share the same fate, the pod was not perceived as not ready. Having short-lived containers as a service endpoint may encounter problems like this. I am not really convinced that this is kubelet's problem. It sounds like should be a cron job...
Forgot to cc
Is it alright if I modify git-sync to make it run a for-loop?
sure, but it would still be nice to able to have a way to have background containers restarting periodically in a pod w/o failing the service.
, will it be useful if we let the user to config which containers will be considered by kubelet when it reports the readiness of the pod?
I am not sure kubelet restart is the right mechanism to run periodic tasks, and in this case, recreating the container isn't particularly efficient. FYI, there is a discussion for adding a controller for cron jobs in .
Thanks Let's forget about letting kubelet restart periodic tasks. In general, if some containers are not critical to a service, ignoring the status of these containers and keeping the service alive will increase the availability of the service.
we'd like to have sidecar containers that aren't critical to a pod's overall functioning. i.e. a sidecar which can crash or become unavailable without pulling the pod from the load balancer. In our case it is a sidecar which delivers some configuration to disk from a notoriously flakey service. We'd like the pod to stay up, the conf it needs is on disk. Should I file a separate issue for this?