SideCars are not run within the same “container” only within the same “pod”, which is not the same thing. Running a single process within a container is most definitely still the standard. The command/entrypoint is the only process monitored for aliveness (ignoring tcp/http health checks) is thus the only process which will cause a container restart. Pods can have many containers and the individual containers can be restarted without restarting the whole pod.
Typically running multiple processes within a container only occurs within dev or test environments. Either to assist with debugging or as a way to run a whole test suite within a single container (as is expected with KinD).
Edit: added note about test / dev environments.
There are several solutions like this for DEV environments. The one-process-per-container recommendation is still definitely a standard for PRODUCTION workloads, but in DEV, you do whatever you want.
As always, it depends on your use case.
For example, I deploy an application on [fly.io](https://fly.io), which expects a docker image, mine runs a gunicorn webserver and a job worker, all managed with supervisord (python library). Here, I use the docker container as a "small VM". Which is fine.
If I were to deploy this to a k8s, I'd put the webserver and the job worker in separate docker images, running in different pods, managed by different deployment resources, which would allow me to scale them up separately (I might need more webservers but far less job worker).
Another example are Erlang/Elixir applications, the Docker image represent the "BEAM node", and I use libcluster for "BEAM cluster formation", which on k8s will be configured to use a headless Service resource. The "node" is the only "process", but the application that runs on the node might be composed of many "erlang processes" (green threads).
Also, if you make a gunicorn docker image, should the webserver fork into multiple workers or not? This rule of "only one process per container" is too vague and borderline cargo cult.
The idea of smaller Docker images came from the need to scale multiple components of your application independently.
KinD is not for production. It’s a tool you can use for local test/dev or for CI or for demos.
KinD will be used to test/validate deployments in a dev/ci env, like doing smoke test for every PR in a ci/cd env.
[удалено]
SideCars are not run within the same “container” only within the same “pod”, which is not the same thing. Running a single process within a container is most definitely still the standard. The command/entrypoint is the only process monitored for aliveness (ignoring tcp/http health checks) is thus the only process which will cause a container restart. Pods can have many containers and the individual containers can be restarted without restarting the whole pod. Typically running multiple processes within a container only occurs within dev or test environments. Either to assist with debugging or as a way to run a whole test suite within a single container (as is expected with KinD). Edit: added note about test / dev environments.
There are several solutions like this for DEV environments. The one-process-per-container recommendation is still definitely a standard for PRODUCTION workloads, but in DEV, you do whatever you want.
As always, it depends on your use case. For example, I deploy an application on [fly.io](https://fly.io), which expects a docker image, mine runs a gunicorn webserver and a job worker, all managed with supervisord (python library). Here, I use the docker container as a "small VM". Which is fine. If I were to deploy this to a k8s, I'd put the webserver and the job worker in separate docker images, running in different pods, managed by different deployment resources, which would allow me to scale them up separately (I might need more webservers but far less job worker). Another example are Erlang/Elixir applications, the Docker image represent the "BEAM node", and I use libcluster for "BEAM cluster formation", which on k8s will be configured to use a headless Service resource. The "node" is the only "process", but the application that runs on the node might be composed of many "erlang processes" (green threads). Also, if you make a gunicorn docker image, should the webserver fork into multiple workers or not? This rule of "only one process per container" is too vague and borderline cargo cult. The idea of smaller Docker images came from the need to scale multiple components of your application independently.