0

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?

  • 2
    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 Nov 3 '18 at 19:20
  • @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 gist.github.com/simbo1905/6238a817769646770b22f71f7a3c1121 – simbo1905 Nov 11 '18 at 19:25
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.

0

A legitimate example of multiple containers in a POD is hinted at in the official docs:

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.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.