<p>I have a multi-container application: app + sidecar. Both containers suppose to be alive all the time but sidecar is not really that important.
Sidecar depends on external resource, if this resource is not available - sidecar crashes. And it takes entire pod down. Kubernetes tries to recreate pod and fails because sidecar now won't start.
But from my business logic perspective - crash of sidecar is absolutely normal. Having that sidecar is nice but not mandatory.
I don't want sidecar to take main app with it when it crashes.
What would be best Kubernetes-native way to achieve that?
Is it possible to tell kubernetes ignore failure of sidecar as a &quot;false positive&quot; event which is absolutely fine?</p>
<p>I can't find anything in pod specification what controls that behaviour.</p>
<p>My yaml:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: myapp
    spec:
      volumes:
      - name: logs-dir
        emptyDir: {}
      containers:
      - name: myapp
        image: ${IMAGE}
        ports:
        - containerPort: 9009
        volumeMounts:
        - name: logs-dir
          mountPath: /usr/src/app/logs
        resources:
          limits:
            cpu: &quot;1&quot;
            memory: &quot;512Mi&quot;
        readinessProbe:
          initialDelaySeconds: 60 
          failureThreshold: 8 
          timeoutSeconds: 1
          periodSeconds: 8 
          httpGet:
            scheme: HTTP
            path: /myapp/v1/admin-service/git-info
            port: 9009
      - name: graylog-sidecar
        image: digiapulssi/graylog-sidecar:latest
        volumeMounts:
        - name: logs-dir
          mountPath: /log
        env:
        - name: GS_TAGS
          value: &quot;[\&quot;myapp\&quot;]&quot;
        - name: GS_NODE_ID
          value: &quot;nodeid&quot;
        - name: GS_SERVER_URL
          value: &quot;${GRAYLOG_URL}&quot;
        - name: GS_LIST_LOG_FILES
          value: &quot;[\&quot;/ctwf\&quot;]&quot;
        - name: GS_UPDATE_INTERVAL
          value: &quot;10&quot;
        resources:
          limits:
            memory: &quot;128Mi&quot;
            cpu: &quot;0.1&quot;
</code></pre>

Stqs
<p><strong>Warning:</strong> the answer that was flagged as &quot;correct&quot; does not appear to work.</p>
<p>Adding a Liveness Probe to the application container and setting Restart Policy to &quot;Never&quot;, will lead to the Pod being stopped and <strong>never restarted</strong> in a scenario where  the sidecar container has stopped and the application container has failed its Liveness Probe. This is a problem, since you DO want the restarts for the application container.</p>
<p>The problem should be solved as follows:</p>
<ul>
<li>Tweak your sidecar container in the startup command to keep the main process running on failure of the application process. This could be done with an extra piece of scripting, e.g. by appending <code>| tail -f /dev/null</code> to the startup command.</li>
<li>Adding a Liveness Probe to the application container is in general a good idea. Keep in mind though that it only protects you against a scenario where your application process keeps running without your application being in a correct state. It will certainly not overwrite the restartPolicy:</li>
</ul>
<blockquote>
<p>livenessProbe: Indicates whether the container is running. If the liveness probe fails, the kubelet kills the container, and the container is subjected to its restart policy. If a Container does not provide a liveness probe, the default state is Success.
<a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes" rel="nofollow noreferrer">Container Probes</a></p>
</blockquote>
