Kubernetes characteristic research: sidecar containers

This article excerpts from Kubernetes Learning notes

background

K8S in Pod If there are more than one container, Normally, it will be started or destroyed at the same time , However, some scenarios depend on the order in which containers are started or destroyed , There may be some problems , For example istio Scene :

• Pod Startup time : Business container ratio istio-proxy First ready. Application of containerization transition , When the business container starts, it needs to call other services ( For example, pull the configuration from the configuration center ), If you fail, quit , There is no retry logic , And when envoy When starting slower , The business container failed to call other services , Lead to pod Boot failure , So circular ( Reference resources k8s issue #65502 , Solution reference istio common problem : Sidecar Start sequence problem ) .
• Pod At the time of destruction : Business containers and envoy Received at the same time SIGTERM,envoy No more incremental connections , But the business container is graceful shutdown You may need to call another service during the process （ For example, notify other cleaners to clean up ), Now envoy Just reject the new request , Cause the call to fail ( Reference resources istio issue #7136 , Solution reference istio common problem : Sidecar Stop sequence problem ).

Initiate a proposal

Many people in the community have encountered similar problems , It was first suggested that Proposal To solve :

• stay 2018-05, Joseph Irving launch Sidecar Containers Of KEP
• Later on 2018-11 KEP By Accept .
• And then 2019-01 The author has opened a new issue #753 To follow up on this feature .

The proposal was abandoned

After two years of design and development , stay 2020-10 The community is divided , Finally announce the KEP Abandoned , See the author's Comment on .

There are also articles that have caused trouble , call 1.18 Will support sidecar characteristic : [Sidecar container lifecycle changes in Kubernetes 1.18

](https://banzaicloud.com/blog/k8s-sidecars/) , But it turned out that in the end , And it was abandoned .

The reason summary

To sum up, the reason is , Many related questions are related to pod Life cycle management , There are many scenarios involved , It's not just limited to oneortwo scenarios . We can't create a feature for every scenario to solve , It needs to be solved by a new proposal that can solve all problems from a higher level .

Discuss new proposals

And then , The community launched sidecar Collection of relevant scenarios and requirements Sidecar use cases/requirements , I was impressed by :

• Job Exit after running , but istio sidecar Will not quit , Lead to Job Never quit (Job Need to wait for all container Stop is exit )
• upgrade sidecar Version will restart all Pod, Not friendly to large clusters , Can support a single container Just upgrade

And then in 2020-11,Tim Hockin (K8S chief ) Launch a new Proposal draft .

Latest progress

And then there's no then , I haven't found anything related to this feature recently , It may cover many scenes , More complex designs are needed , I can't think about it so quickly ...