当前位置：网站首页>Implementation and usage analysis of static pod

Implementation and usage analysis of static pod

2022-06-24 07:07:00 【User 1360858】

Prerequisite knowledge

Kubernetes Clustered Basic framework and Function of each component
Pod The basic concepts and principles of
Kubernetes Medium Deployment and Daemonset The basic principle

Static pod brief introduction

ordinary Pod

Pod yes kubernets The most basic unit of work in , One Pod Can contain a set of containers . General situation ,Pod The creation process of is as follows （ With Bare Pod For example ）：

The user first requests Kube-apiserver establish Pod, When Pod After being accepted by the system ,Pod As a resource object, it is persisted in Etcd in , Status as Pending. Control components Kube-scheduler adopt Kube-apiserver Listen to the... Of this unspecified scheduling node Pod after , According to certain strategies , modify Pod Of status Field , Mark this Pod Should be assigned to a node . On all nodes Kubelet Also by listening Kube-apiserver The incoming sender is dispatched to this node first Pod, here Kubelet In the real sense, it is based on Pod Defined information , To start on its own node Pod.

Static pod

Follow Kubernetes Other common Pod Dissimilarity ,Static pod It is directly controlled by the Kubelet Managed . Just put Pod The definition declaration file of is placed in Kubelet Under the specified path of the node , Or some designated URL Address ,Kubelet It will read Pod The definition file for , And start this Pod, It will also be managed according to the defined configuration Static pod Life cycle of .Static pod You can start without a cluster , Only nodes have Kubelet And the corresponding container .

Quick to use Static pod Example

Static pod It's easy to use , Let's give it a quick try .

Step 1： Prepare a server as a node ;
Step 2： Install the container runtime on the node ： Click here for my reference ;
Step 3： Install... On the node Kubelet： Click here for my reference ;
Step 4： Specify manually Kubelet Launch parameters ： kubelet --cgroup-driver=systemd --pod-manifest-path=/etc/kubernetes/manifests/ --fail-swap-on=false --pod-infra-container-image=kubernetes/pause > /tmp/kubelet.log 2>&1
Step 5： Observe Pod The defined container group has been Kubelet Start correctly , Included in Management : cat > /etc/kubernetes/manifests/pod.yaml <<EOF{ "kind":"Pod", "apiVersion":"v1", "metadata":{ "name":"static-pod-demo", "namespace":"default", "uid":"114b565b-fbe0-4301-a7bd-89598ce86a7a" }, "spec":{ "containers":[ { "name":"nginx-container", "image":"nginx:latest" } ], "restartPolicy":"Always" }}EOF

Step 6： stop it Static pod, Only need to Pod.yaml File removal /etc/kubernetes/manifests/ directory

Why Static pod

Kubernetes Official documents , Introducing Static pod when , In particular, the following notes are made ：

Note: If you are running clustered Kubernetes and are using static Pods to run a Pod on every node, you should probably be using a DaemonSet instead.

in other words , If you are using Static pod To achieve kubernetes Each of the clusters Node Start on Pod, Then you should use DaemonSet, instead of Static pod.

Since the official documents are recommended DaemonSet 了 , Why does it still exist static pod Such mechanism ？

In the early Kubernetes, To start, for example, log collection on each node of the cluster （fluentd）、 Network components (kube-proxy) Etc , Used Static pod The mechanism of . Later, it was proposed DaemonSet The concept of , So these services that need to be started on each node , It's all gradually being ignored DaemonSet Replace , The official documents also suggest that DaemonSet.

Static pod The mechanism remains , On the one hand, in order to be compatible with the majority of developers, we have adopted Static pod Usage scenarios of ; On the other hand Static pod have DaemonSet Irreplaceable features ： Unwanted Kubernetes Cluster to start directly 、 management Pod.Static pod The biggest feature is that there is no need to call Kube-apiserver Quick start Pod, in other words , You don't need a complete kubernetes colony , Once installed kubelet、 Container runtime , You can quickly make kubelet To take over your yaml File defined Pod. The previous chapter also briefly introduced how to use this feature quickly .Static pod The advantage is that there is no need for clustering , The disadvantages are also corresponding , There is no cluster level management 、 Scheduling function . and Static pod The most classic usage scenario , It's for Bootstrap One Kubernetes colony .

Let's start with a simple analysis Static pod Mechanism in kubernetes Source code implementation in , Then analyze and use Static pod Come on Bootstrap Kubernetes The process of clustering .

Static pod Implementation analysis of

Based on Kubernetes v1.21.2 Code for , Main analysis Kubelet In dealing with Static pod The logic of . If you are not interested in the source code implementation, you can skip this part .

Be careful ： I won't go into detail here Kubelet The startup has various other capabilities , You can refer to ：

Kubernetes/cmd/kubelet/app/server.go:

func run(ctx context.Context, s *options.KubeletServer, kubeDeps *kubelet.Dependencies, featureGate featuregate.FeatureGate) (err error) {
  ...
  // About to get clients and such, detect standaloneMode
    standaloneMode := true
    if len(s.KubeConfig) > 0 {
      standaloneMode = false
    }
  ...
  // if in standalone mode, indicate as much by setting all clients to nil
    switch {
    case standaloneMode:
      kubeDeps.KubeClient = nil
      kubeDeps.EventClient = nil
      kubeDeps.HeartbeatClient = nil
      klog.InfoS("Standalone mode, no API client")
  ...
    }
  ...
  if err := RunKubelet(s, kubeDeps, s.RunOnce); err != nil {
    return err
  }
  ...
}

First find Kubelet The start-up entrance , Will determine whether to pass in kubeConfig, without , It is Stand alone Pattern , That is, no cluster mode , Because no kubeConfig Of Kubelet Unable to access the... Of a cluster Kube-apiserver.KubeClient, EeventClient, HeartClient All are set for nil, No incidents will be reported 、 heartbeat .

Kubernetes/cmd/kubelet/app/server.go:

// RunKubelet is responsible for setting up and running a kubelet.  It is used in three different applications:
//   1 Integration tests
//   2 Kubelet binary
//   3 Standalone 'kubernetes' binary
// Eventually, #2 will be replaced with instances of #3
func RunKubelet(kubeServer *options.KubeletServer, kubeDeps *kubelet.Dependencies, runOnce bool) error {
  ...
  k, err := createAndInitKubelet(
    ...
  )
  ...
    startKubelet(k, podCfg, &kubeServer.KubeletConfiguration, kubeDeps, kubeServer.EnableServer)
  ...
}

func createAndInitKubelet(
  ...
){
  ...
  k, err = kubelet.NewMainKubelet(
    ...
}

// NewMainKubelet instantiates a new Kubelet object along with all the required internal modules.
// No initialization of Kubelet and its modules should happen here.
func NewMainKubelet(
  ...
){
  ...
    kubeDeps.PodConfig, err = makePodSourceConfig(kubeCfg, kubeDeps, nodeName, nodeHasSynced)
   ...
}

RunKubelet -> createAndInitKubelet -> NewMainKubelet. stay NewMainKubelet in , call makePodSourceConfig According to kubeletConfiguration, Generate PodConfig, One struct, Be able to obtain a variety of Pod Configuration source （StaticPodPath/StaticPodURL/Kube-apisever), And can be distributed to those who don't understand Listener Handle .PodConfig The original notes in the source code are as follows ：

// PodConfig is a configuration mux that merges many sources of pod configuration into a single
// consistent structure, and then delivers incremental change notifications to listeners
// in order.

Kubernetes/pkg/kubelet/kubelet.go

// makePodSourceConfig creates a config.PodConfig from the given
// KubeletConfiguration or returns an error.
func makePodSourceConfig(kubeCfg *kubeletconfiginternal.KubeletConfiguration, kubeDeps *Dependencies, nodeName types.NodeName, nodeHasSynced func() bool) (*config.PodConfig, error) {
  ...
  // define file config source
  if kubeCfg.StaticPodPath != "" {
    klog.InfoS("Adding static pod path", "path", kubeCfg.StaticPodPath)
    config.NewSourceFile(kubeCfg.StaticPodPath, nodeName, kubeCfg.FileCheckFrequency.Duration, cfg.Channel(kubetypes.FileSource))
  }

  // define url config source
  if kubeCfg.StaticPodURL != "" {
    klog.InfoS("Adding pod URL with HTTP header", "URL", kubeCfg.StaticPodURL, "header", manifestURLHeader)
    config.NewSourceURL(kubeCfg.StaticPodURL, manifestURLHeader, nodeName, kubeCfg.HTTPCheckFrequency.Duration, cfg.Channel(kubetypes.HTTPSource))
  }

  if kubeDeps.KubeClient != nil {
    klog.InfoS("Adding apiserver pod source")
    config.NewSourceApiserver(kubeDeps.KubeClient, nodeName, nodeHasSynced, cfg.Channel(kubetypes.ApiserverSource))
  }
  ...
}

I want to see others makePodSourceConfig In the function , There are three sources Pod Defining information , Namely StaticPodPath、StaticPodURL and kubeClient.

Then directly view kubernetes/pkg/kubelet/config/file.go：

...
func (s *sourceFile) run() {
  listTicker := time.NewTicker(s.period)
  go func() {
    ...
    for {
      select {
      case <-listTicker.C:
        if err := s.listConfig(); err != nil {
          klog.ErrorS(err, "Unable to read config path", "path", s.path)
        }
      ...
      }
    }
  }()

  s.startWatch()
}
...
func (s *sourceFile) listConfig() error {
  ...
  switch {
  case statInfo.Mode().IsDir():
    ...
  case statInfo.Mode().IsRegular():
    ...
  }
}

You can see if StaticPodPath If it's configured ,kubelet Will start a collaborative process , timing watch All files in this path , If it is consistent with Pod Documents of definition , Then deserialize the Pod Objects are distributed to PodConfig Of Listener To deal with .

Stuct PodConfig Members of updates chan kubetypes.PodUpdate It is a distribution that needs to be handled Pod The event Channel.

Kubernetes/pkg/kubelet/kubelet.go

func (kl *Kubelet) syncLoopIteration(configCh <-chan kubetypes.PodUpdate, handler SyncHandler,
  syncCh <-chan time.Time, housekeepingCh <-chan time.Time, plegCh <-chan *pleg.PodLifecycleEvent) bool {
  ...
}

In function syncLoopIteration in , By reading the PodConfig Of updates This Channel, To send out events for processing , Mainly from Kubelet according to Pod The definition of , Call the underlying container runtime to run the container . Of course , When Kubelet watch To the specified path Pod The definition file is removed , Then it will also stop the original operation Static pod. The implementation code in the later part has a long margin and will not be listed in detail .

Static pod Typical application scenarios

Static pod Currently the most widely used scenario , Is in Kubeadm Use this mechanism to Bootstrap One Kubernetes colony .

Use Kubernetes Before cluster , The components of the control surface need to be deployed first . These control components can be deployed in binary , You can also deploy in containers . Binary deployment is a little cumbersome , And easy to make mistakes , Upgrading is also inconvenient , The benefits of deploying these managed components in containers are obvious .

This is the most typical chicken or egg problem . In the absence of Kubernetes In clusters , How do we start these control components in the form of containers ？ Official deployment tools Kubeadm The solution given is to use Static pod.

In the use of Kubeadm When deploying a cluster , First you need to install kubelet、 Components such as container runtime ,Kubeadm According to the specified configuration file , Generate Kube-apiserver, Kube-controller-manager, Kube-proxy Components such as Pod The definition file , Put in Master Node assignment Static Pod path Next , Give Way Kubelet Take over these Static pod Life cycle management of .

summary

This article first introduces Kubernetes in Static pod The principle of mechanism , And with “ The conventional ” Running in a cluster Pod Compared with . Then it explains how to use it quickly Kubelet To deploy and start 、 Restart and stop Static pod To implement the lifecycle management of a group of business containers . If we need to Kubernetes Specifies that each node starts a specific Pod, Then it is suggested to use the official DaemonSet To achieve the purpose .Static pod The usage scenario of is when there is no cluster , How can it be convenient 、 Stably manage containers running on this node .Static pod At present, the most widely used scenario is Kubeadm Using this mechanism to start Kubernetes Clustered Control Plane The components of the layer .

Static pod It only depends on the of the node Kubelet You can start , No need for clustering , But it also lacks resource scheduling at the cluster level 、 Automatic expansion and other functions .