If you need to collect log and stats of a container, you will be wanting to create generic app which will be agnostic of the container. This will help to reuse this logging product along with various types of apps. If you are kubernetes user, then you will know that this container runs as POD and their can be new containers created at run time (due to scale). So, you will like to run your logging app together alongwith this container in same POD. This approach is called side-car pattern.
Now what if the container goes down. Do you still want your logging app to be running. If your logging app doesn't goes down alongwith this container, then your app need to perform some extra work like checking of container heath, re-configuring itself when container is recreated. Do you like to avoid these extra work? This document discusses about this
Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. These peripheral tasks can be implemented as side-car pattern.
In the sidecar pattern, the sidecar is attached to a parent application and provides supporting features for the application. The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent.
Current Kubernetes(refer here) recreates the container in multi-container environment instead of rebooting the whole POD. In this case, life-cycle of helper container is not linked to main container which is not aligned with requirement of side-car pattern like below
"The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent. "
To support side-car pattern, K8s can provide the configuration option to user. With this option, user will instruct K8s to recreate the whole POD in case a specific container dies.
I see one such request at https://github.com/kubernetes/kubernetes/issues/70569
Currently, all containers in a POD are created without any ordering (however, there are Kubernetes Init Containers). So, helper container in side-car needs to wait until main container comes up.
In the same line as above, this primary container should be given preference while creating containers. This can reduce the wait time for the helper containers. However, this will cause problem to proxy container which is used to proxy all networking related to primary container.
In summary, POD creation ordering needs much careful thought before any change.
https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
https://linchpiner.github.io/k8s-multi-container-pods.html
https://github.com/kubernetes/enhancements/issues/753