Shulou(Shulou.com)06/01 Report--

What this article shares to you is about how to upgrade the container in place in Kubernetes. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Why do you need to upgrade the container in place?

In the world of Docker, container image, as an immutable infrastructure, solves the problem of environment dependence, but Kubernetes promotes this to the height of Pod. It is a very good idea that every application is updated through ReCreate Pod, so that every ReCreate is a new and clean application environment. For the deployment of micro-services, this method does not bring much burden. For the deployment of traditional applications, a Pod may include a main business container, an inseparable dependent business container, and SideCar component containers. At this time, the Pod appears to be very bloated. If you continue to rebuild the entire SideCar Container in the way of ReCreate Pod because you want to update one of the Pod, the burden is still great, as reflected in:

Elegant end time of Pod (default is 30s)

It takes a long time to download multiple container images that may exist after Pod rescheduling.

Application startup time

Therefore, because updating a lightweight SideCar results in a minute-level reconstruction of a single Pod, if the number of copies of the application is as high as hundreds of thousands, then the overall time-consuming is conceivable, and if you are updating with StatefulSet OrderedReady PodManagementPolicy, the price is unacceptable.

Therefore, we are eager to upgrade only one Container in the Pod without rebuilding the entire Pod, which is what we call the container upgrade capability.

Whether Kubernetes already supports Container in-place upgrade

The answer is: yes! In fact, as early as two years ago, Kubernetes v1.5 version has the corresponding code logic, this article uses Kubernetes 1.12 version of the code to interpret.

Many students must feel suspicious, Kubernetes does not even have the real ReStart, it is ReCreate Pod, how can only update Container? Yes, in the logic of many built-in Workload's Controller, this is true. Kubernetes only does the container upgrade in Kubelet layer, and is not exposed to Deployment, StatefulSet and other Controller to provide directly to users. The reason is very simple. It is recommended that you use Pod as a complete deployment unit.

After Kubelet starts, it enters the main loop to deal with Pod Changes events on Node through syncLoop, listens to events from three types of file,apiserver,http and aggregates them into kubetypes.PodUpdate Channel (Config Channel), and syncLoopIteration continues to consume from kubetypes.PodUpdate Channel.

In order to upgrade the container in place, if we change the Image of the corresponding container in Pod.Spec, an event of type kubetypes.UPDATE will be generated and HandlePodUpdates will be called in syncLoopIteration to handle it.

Pkg/kubelet/kubelet.go:1870func (kl * Kubelet) syncLoopIteration (configCh

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.