<p>A legitimate example of multiple containers in a POD is hinted at in <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/" rel="nofollow noreferrer">the official docs</a>:</p>

<blockquote>
  <p>These co-located containers might form a single cohesive unit of
  service–one container serving files from a shared volume to the
  public, while a separate “sidecar” container refreshes or updates
  those files.</p>
</blockquote>

<p>So you can use an nginx container that serves content out of the pod disk and another container that runs “git pull” in a loop with a short pause to refresh the html content on the pod disk. </p>

<p>Of course people would typically build an image containing the latest html using “FROM nginx” at the top of the dockerfile so they wouldn’t normally do things the way I described. </p>

<p>So the real answer is that most folks can and should avoid running multiple containers in a pod. If your starting from scratch building a typical new system you can keep things clean. </p>

<p>Yet more and more people are moving legacy workloads onto kubernetes. Then you don’t have a choice about the actual application architecture. In which case you may find you need to run two or more processes that share resources wiring a pod. That’s a total anti-pattern for modern “share nothing” microservices but legacy code doesn’t follow modern best practices.</p>

CC BY-SA 4.0
2018-11-11T19:10:09.887Z
2018-11-11T19:10:09.887Z
simbo1905
<p>All of them would have to be up for the pod to be completely up. Instead of running multiple processes within the same container, use sidecar containers. For now they share network namespace and emptyDir filesystem, but not pid namespace (pid namespace sharing is available in beta, <a href="https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/</a>).</p>

<p>A typical sidecar use case is utility containers. What I commonly see it one for logging, such as a splunk forwarder or syslog daemon. </p>

<p>There's also those that setup an app stack as a Deployment (which materializes in one or more replicas of a pod), instead of multiple deployments. </p>

CC BY-SA 4.0
2018-11-03T19:22:28.303Z
2018-11-03T19:22:28.303Z
3molo
<p>Few questions here:</p>

<ol>
<li><p>What does the concept of object Pod satisfy? A paused container containing the namespace for the actual app area (s) will be added later and use that namespace. So what activities in real life qualify to have more than one container running in a pod? Can you give examples of points? What is considered sidecar operation after all?</p></li>
<li><p>What is the threshold, for example: N container in the Pod that the master will be able to say that Pod is not healthy? So basically, how many containers in a pod need to down to the POD mark down?</p></li>
</ol>

CC BY-SA 4.0
2018-11-03T19:20:46.257Z
This doesn't seem like a well-formed question. There are several questions rolled into one. Could you give some indication of what the main question is?
Bruce Becker
CC BY-SA 4.0
2018-11-11T19:25:36.150Z
@DouglasCunningham thanks for the question and sorry that it has been voted down as I think it's a legitimate question so I posted an answer. here is a suggestion of how you might rephrase your question to have it voted up https://gist.github.com/simbo1905/6238a817769646770b22f71f7a3c1121
simbo1905
<kubernetes>
Pod & pod's health
DouglasCunningham
# Pod & pod's health

(Asked by: username_0 on 2018-11-03)

Few questions here:

1. What does the concept of object Pod satisfy? A paused container containing the namespace for the actual app area (s) will be added later and use that namespace. So what activities in real life qualify to have more than one container running in a pod? Can you give examples of points? What is considered sidecar operation after all?
2. What is the threshold, for example: N container in the Pod that the master will be able to say that Pod is not healthy? So basically, how many containers in a pod need to down to the POD mark down?

**Tags:** kubernetes

> **Comments:**
> **username_1**: This doesn't seem like a well-formed question. There are several questions rolled into one. Could you give some indication of what the main question is?  
> **username_2**: @username_0 thanks for the question and sorry that it has been voted down as I think it's a legitimate question so I posted an answer. here is a suggestion of how you might rephrase your question to have it voted up https://gist.github.com/username_2/6238a817769646770b22f71f7a3c1121  

---

## 2 answers

### Answer by username_2 on 2018-11-11. Score: 1

A legitimate example of multiple containers in a POD is hinted at in [the official docs](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/):

> These co-located containers might form a single cohesive unit of
> service–one container serving files from a shared volume to the
> public, while a separate “sidecar” container refreshes or updates
> those files.

So you can use an nginx container that serves content out of the pod disk and another container that runs “git pull” in a loop with a short pause to refresh the html content on the pod disk.

Of course people would typically build an image containing the latest html using “FROM nginx” at the top of the dockerfile so they wouldn’t normally do things the way I described.

So the real answer is that most folks can and should avoid running multiple containers in a pod. If your starting from scratch building a typical new system you can keep things clean.

Yet more and more people are moving legacy workloads onto kubernetes. Then you don’t have a choice about the actual application architecture. In which case you may find you need to run two or more processes that share resources wiring a pod. That’s a total anti-pattern for modern “share nothing” microservices but legacy code doesn’t follow modern best practices.


---

### Answer by username_3 on 2018-11-03. Score: 0

All of them would have to be up for the pod to be completely up. Instead of running multiple processes within the same container, use sidecar containers. For now they share network namespace and emptyDir filesystem, but not pid namespace (pid namespace sharing is available in beta, <https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/>).

A typical sidecar use case is utility containers. What I commonly see it one for logging, such as a splunk forwarder or syslog daemon.

There's also those that setup an app stack as a Deployment (which materializes in one or more replicas of a pod), instead of multiple deployments.


---

