My colleague asked a question I never thought about. Why did kubernetes' superfluous' launch the static pod concept?

My colleague asked me a question I had never thought about , Why? Kubernetes want " carry coals to newcastle " Launch static Pod Concept ？

We know k8s in Pod It can be said that he is a qualified container housekeeper ,Pod Designed to support multiple containers that can be scheduled together , Between containers can Shared resources and dependencies 、 Communicate with each other 、 Coordinate when and how to run or terminate itself .

I don't know if you noticed our housekeeper's Static twin Pod?

Why? k8s Will launch static Pod Concept ？

Embarrassing fat nonsense, class starts

static state Pod What's special ？

Under normal circumstances Pod Is in Master On the unified management , Appoint , Distribute . Static Pod Just don't accept Master Management of , At the designated node Fall for it kubelet Startup time , Meeting Auto start All defined static Pod.

static state Pod Directly by the On a particular node kubelet process To manage , Not through master nodes apiserver .⽆ Law and we often ⽤ The controller Deployment perhaps DaemonSet Into the ⾏ relation ,kubelet Direct monitoring of each Pod, And in Restart and self-healing in case of failure .

static state Pod Always bound to ⼀ individual kubelet , also Always run ⾏ At the same time ⼀ Nodes On .

Now that you find out API Unable to manage , Why can “ See ” Running static Pod？

kubelet Will manage static for each of it Pod, call api-server stay Kubernetes Of apiserver To create a ⼀ A mirror image Pod（Mirror Pod）. So we can apiserver The... Was found in the query Pod, Can also pass through kubectl Etc , But not through apiserver Into the ⾏ control （ For example, you cannot delete ）.

Ordinary Pod Failure self-healing and static Pod What's the difference? ？

routine Pod use The workload Resources to create and manage multiple Pod. The controller of the resource can handle the management of the replica 、 go online , And in Pod Provide self-healing capability in case of failure .

The node itself can try Restart or completely replace operation ,kubernetes The default self-healing mechanism is when Pod Exit time Pod To restart .

If the restart fails , You can pull it again Pod, Realize the replacement of doubles ：

for example , If a node fails , The controller notices that Pod Has stopped working , You can create alternative double Pod. The dispatcher will take the stand in Pod Schedule to a healthy node to execute .

Here are some examples of managing one or more Pod Examples of workload resources for ：

• Deployment
• StatefulSet
• DaemonSet

static state Pod Is specified to run on a specific node Pod, Completely to kubelet Supervise self-healing , Restart will also be performed on the same specified node . static state Pod Always bound to ⼀ individual kubelet , And always carry ⾏ At the same time ⼀ A node .

If kubectl Stop or delete static Pod What will happen ？

If you try to delete or stop , static state Pod Will enter **Pending** state , And will soon be kubelet restart .

What if I have to delete it ？

kubelet Startup time , from –Pod-manifest-path= or –manifest-url= Parameter specified ⽬ Record all the defined Pod Will automatically create .

Delete only in The configuration directory Delete the corresponding yaml The configuration file .

Running kubelet The configured directory will be scanned regularly , And according to what appears or disappears in the file Pod Configuration file to create or delete Pod.

static state Pod What's the role ？ What are the built-in static Pod？

static state Pod Usually bound to kubelet. Its main use is Run the self managed control surface .

Because using static Pod Can effectively prevent the passage of kubectl、 Or MIS deletion of management tool operation , It can be used to deploy some core component applications , Ensure that application services always run in a stable number and provide stable services .

In a self hosting scenario , Use kubelet To manage individual control surface components . for example ：

• The scheduling component kube-scheduler
• Secretary assembly kube-apiserver
• Core brain components kube-controller-manager
• Data warehouse components etcd

《Kubernetes- Enterprise container application hosting 》- Keep talking nonsense

The first paragraph ： Recommended reading ： 【 Cloud primordial new era trendsetter k8s Why is it unique in containerization ？】

The second paragraph ： Recommended reading ： 【 Sneak in while colleagues play games k8s A family makes up lessons 】

The third paragraph ： Recommended reading ： 【Kubernetes Family container housekeeper Pod Answer questions online 】

The fourth paragraph ： Recommended reading ： 【 My colleague asked me a question I had never thought about , Why? Kubernetes want " carry coals to newcastle " Launch static Pod Concept ？】

The fifth paragraph ： To be updated ？ Casual reading is recommended ： 【 I'm sorry 】