6

Somebody, please, explain me (or direct to a detailed resource) why kubernetes uses this wrapper (pod) to work with containers. Every resource I go across just quotes same words - "it is the smallest unit in k8s". What I am looking for is the reason for it from engineering perspective. I do understand that it provides namespace for storage and networking for containers inside, but best practice is keeping a single container in a pod anyways.

I've used docker-compose a lot before I familiarized myself with k8s, and have hard times to understand the need for this additional layer (wrapper) around pretty straightforward entity, container.

wise-Kaa
  • 63
  • 5

1 Answers1

3

The reason for this decision is simply because a Pod may contain more than one container, doing different things.

First of all, A pod may have an init-container which is responsible to do some starting operations to ensure that the main container / containers work properly. I could have an init-container load some configuration and preparing it for the main application, or do some basic operations such as restoring a backup or similar things.

I can basically inject a series of operations to exec before starting the main application without building again the main application container image.

Second, even if the majority of applications are perfectly fine having only one container for Pod, there are several situations where more than one container in the same Pod may be useful.

An example could be having the main application running, and then a side-car container doing a proxy in front of the main application, maybe being the responsible for checking JWT tokens.. or another example could be a secondary application extracting metrics from the main application or similar things.

Last, let me quote Kubernetes documentation (https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)

The primary reason that Pods can have multiple containers is to support helper applications that assist a primary application. Typical examples of helper applications are data pullers, data pushers, and proxies. Helper and primary applications often need to communicate with each other. Typically this is done through a shared filesystem, as shown in this exercise, or through the loopback network interface, localhost. An example of this pattern is a web server along with a helper program that polls a Git repository for new updates.

Update

Like you said, init containers.. or multiple containers in the same Pod are not a must, all the functionalities that I listed can also be obtained in other ways, such as en entrypoints or two separate Pods communicating with each other instead of two containers in the same Pod.

There are several benefits in using those functionalities tho, let me quote the Kubernetes documentation once more (https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)

Because init containers have separate images from app containers, they have some advantages for start-up related code:

Init containers can contain utilities or custom code for setup that are not present in an app image. For example, there is no need to make an image FROM another image just to use a tool like sed, awk, python, or dig during setup.

The application image builder and deployer roles can work independently without the need to jointly build a single app image.

Init containers can run with a different view of the filesystem than app containers in the same Pod. Consequently, they can be given access to Secrets that app containers cannot access.

Because init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met. Once preconditions are met, all of the app containers in a Pod can start in parallel.

Init containers can securely run utilities or custom code that would otherwise make an app container image less secure. By keeping unnecessary tools separate you can limit the attack surface of your app container image

The same applies to multiple containers running in the same Pod, they can communicate safely with each other, without exposing that communication to other on the cluster, because they keep it local.

AndD
  • 2,281
  • 1
  • 8
  • 22
  • thank you very much for your thorough answer! I did understand the use cases, but it still seems as an overcomplication to me. The initialization job is pretty much an ENTRYPOINT command in docker world, where I can supply prepared script among other things. Of course it wouldn't work, if initialization is done for multiple containers (but I don't really see a "no other way to do that" case, to put many in one). In case of side helper container, it makes more sense to me to make it as a separate service. I would appreciate additional thoughts :) – wise-Kaa Feb 04 '21 at 11:32
  • 1
    "In case of side helper container, it makes more sense to me to make it as a separate service" - two containers in one pod are guarenteed to always get scheduled together on a node and thus can share the same volume (which is not possible when pods get schedule on different nodes). They also share the same network interface and can communicate using loopback interface, and this makes communication between containers much faster (which you may want in some cases). In k8s docs there is written that you should think of a pod like of a VM that has its own processes, net interfaces and disk volumes – Matt Feb 04 '21 at 13:12
  • In addition to what @Matt said, I've also updated my answer with some more pros of the functionalities. – AndD Feb 04 '21 at 13:22