kubelet起動パラメータデフォルト


クbelet起動コードを見ることについては、CNI、バイナリ配置についてflannelグループネットワークを使用して、クbletを起動するときにnetwork-pluginパラメータが渡されていないことを知りたいのですが、必然的にデフォルト値があります.
実はflannelの本質もbrigde方式でpodのネットワークインタフェース構成操作を行うことであり、これはdocker自体のデフォルトのdocker 0と一致するが、ここではkubeletのnetwork-pluginのパラメータが最後にdockershimに渡されて処理されることを理解する必要があるので、dockershimはdocker自身を使うかcniプラグインを使うかを判断する.dockerが自分でやるにしてもflannelがやるにしても、dockershimが決めたのです.どうやって決めたの?
そのため、2つのパラメータを深く検討する必要があります.
クbeletからの起動パラメータ
--network-plugin
The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker.
--container-runtime
The container runtime to use. Possible values: 'docker', 'remote', 'rkt (deprecated)'. (default "docker")
//pkg/kubelet/dockershim/docker_service.go

func NewDockerService(config *ClientConfig, podSandboxImage string, streamingConfig *streaming.Config, pluginSettings *NetworkPluginSettings,
	
    ...
	// dockershim currently only supports CNI plugins.
	pluginSettings.PluginBinDirs = cni.SplitDirs(pluginSettings.PluginBinDirString)
	cniPlugins := cni.ProbeNetworkPlugins(pluginSettings.PluginConfDir, pluginSettings.PluginBinDirs)
	cniPlugins = append(cniPlugins, kubenet.NewPlugin(pluginSettings.PluginBinDirs))
	netHost := &dockerNetworkHost{
		&namespaceGetter{ds},
		&portMappingGetter{ds},
	}
	plug, err := network.InitNetworkPlugin(cniPlugins, pluginSettings.PluginName, netHost, pluginSettings.HairpinMode, pluginSettings.NonMasqueradeCIDR, pluginSettings.MTU)
	if err != nil {
		return nil, fmt.Errorf("didn't find compatible CNI plugin with given settings %+v: %v", pluginSettings, err)
	}
	ds.network = network.NewPluginManager(plug)
	glog.Infof("Docker cri networking managed by %v", plug.Name())
...
}

// pkg/kubelet/dockershim/network/plugin.go
// InitNetworkPlugin inits the plugin that matches networkPluginName. Plugins must have unique names.
func InitNetworkPlugin(plugins []NetworkPlugin, networkPluginName string, host Host, hairpinMode kubeletconfig.HairpinMode, nonMasqueradeCIDR string, mtu int) (NetworkPlugin, error) {
	if networkPluginName == "" {
		// default to the no_op plugin
		plug := &NoopNetworkPlugin{}
		plug.Sysctl = utilsysctl.New()
		if err := plug.Init(host, hairpinMode, nonMasqueradeCIDR, mtu); err != nil {
			return nil, err
		}
		return plug, nil
	}

	pluginMap := map[string]NetworkPlugin{}


上記のコードから、バイナリ導入時にnetwork-pluginパラメータが構成されていないことがわかります.すなわち、コードにはNoopNetworkPlugginブランチが入ります.
/var/log/messageからもkubeletのログ「Docker cri networking managed by kubernetes.io/no-op」が見えます.
 
一言:dockershimは伝達されたnetwork-pluginパラメータを判断し、どのように処理し、どのように処理したかを判断します.
 
 
次のコードはkubeletのデフォルトパラメータがどのように定義されているかを見ます.
(一)kubeletの起動入口:
 app.NewKubeletCommand()
#kubernets/cmd/kubelet/kubelet.go
func main() {
	rand.Seed(time.Now().UTC().UnixNano())

	command := app.NewKubeletCommand(server.SetupSignalHandler())
	logs.InitLogs()
	defer logs.FlushLogs()

	if err := command.Execute(); err != nil {
		fmt.Fprintf(os.Stderr, "%v
", err) os.Exit(1) } }
# kubernetes/cmd/app/server.go
func NewKubeletCommand(stopCh 

以上のコードではoptions.NewKubeletFlags、そして次のkubeletFlays.AddFlagsは構成パラメータのデフォルト値を設定する場所です
 
ここだNewKubeletFlagsでは、kubeletのさまざまな構成が初期化されます.
func NewKubeletFlags() *KubeletFlags {
	remoteRuntimeEndpoint := ""
	if runtime.GOOS == "linux" {
		remoteRuntimeEndpoint = "unix:///var/run/dockershim.sock"
	} else if runtime.GOOS == "windows" {
		remoteRuntimeEndpoint = "tcp://localhost:3735"
	}

	return &KubeletFlags{
		EnableServer:                        true,
		ContainerRuntimeOptions:             *NewContainerRuntimeOptions(),
		CertDirectory:                       "/var/lib/kubelet/pki",
		RootDirectory:                       defaultRootDir,
		MasterServiceNamespace:              metav1.NamespaceDefault,
		MaxContainerCount:                   -1,
		MaxPerPodContainerCount:             1,
		MinimumGCAge:                        metav1.Duration{Duration: 0},
		NonMasqueradeCIDR:                   "10.0.0.0/8",
		RegisterSchedulable:                 true,
		ExperimentalKernelMemcgNotification: false,
		RemoteRuntimeEndpoint:               remoteRuntimeEndpoint,
		NodeLabels:                          make(map[string]string),
		VolumePluginDir:                     "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/",
		RegisterNode:                        true,
		SeccompProfileRoot:                  filepath.Join(defaultRootDir, "seccomp"),
		HostNetworkSources:                  []string{kubetypes.AllSource},
		HostPIDSources:                      []string{kubetypes.AllSource},
		HostIPCSources:                      []string{kubetypes.AllSource},
		// TODO(#58010:v1.13.0): Remove --allow-privileged, it is deprecated
		AllowPrivileged: true,
		// prior to the introduction of this flag, there was a hardcoded cap of 50 images
		NodeStatusMaxImages: 50,
	}
}

 
ここではlinux環境でRemoteRuntimeEndpointの定義があります.ContaineRuntimeOptionsの初期化もあります
func NewContainerRuntimeOptions() *config.ContainerRuntimeOptions {
	dockerEndpoint := ""
	if runtime.GOOS != "windows" {
		dockerEndpoint = "unix:///var/run/docker.sock"
	}

	return &config.ContainerRuntimeOptions{
		ContainerRuntime:           kubetypes.DockerContainerRuntime,
		RedirectContainerStreaming: false,
		DockerEndpoint:             dockerEndpoint,
		DockershimRootDirectory:    "/var/lib/dockershim",
		PodSandboxImage:            defaultPodSandboxImage,
		ImagePullProgressDeadline:  metav1.Duration{Duration: 1 * time.Minute},
		ExperimentalDockershim:     false,

		//Alpha feature
		CNIBinDir:  "/opt/cni/bin",
		CNIConfDir: "/etc/cni/net.d",
	}
}

=================================
上のものがあるのは、バイナリ配置時にnetwork-pluginが構成されていない以上、kubeletがpodを作成する際に、コンテナのネットワークがどのように作成されているのかを知りたいからです.
構成から分かるのはflannel起動時に、このノードのセグメントをdocker起動パラメータに渡します.dockerが起動すると、docker 0ブリッジのセグメントが設定されます.
いくつかの疑問があります
  • flannelというプラグインの動作原理は、なぜnetwork-pluginがflannelを体現していないのか、flannelは最終的にノード間pod通信を実現しているのか.
  • kubelet network-pluginパラメータのデフォルト値はいくらですか?この構成に対してpodのネットワークプロセスに与える影響は?

  • (一)まず最初の質問に答えます.
    flannelはcniの中でcalicoなどの第三者のcniに対して比較的に特殊なプラグインで、特殊はどこにありますか?https://github.com/containernetworking/pluginsにも記載されていますが、flannelはMeta:other pluginsクラスに属し、独立して作業することはできません.Mainクラスのサポートが必要です.flannelの本質はMainクラスのbridgeを呼び出すことであり、dockerのデフォルトのNetworkModeと一致しています.そのためバイナリ配置の場合、kubeletはflannel関連の構成を指定しておらず、podのネットワークも配置されており、docker自身が構成しているに違いない.
    (二)2つ目の質問を見てみましょう.