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")
上記のコードから、バイナリ導入時にnetwork-pluginパラメータが構成されていないことがわかります.すなわち、コードにはNoopNetworkPlugginブランチが入ります.
/var/log/messageからもkubeletのログ「Docker cri networking managed by kubernetes.io/no-op」が見えます.
一言:dockershimは伝達されたnetwork-pluginパラメータを判断し、どのように処理し、どのように処理したかを判断します.
次のコードはkubeletのデフォルトパラメータがどのように定義されているかを見ます.
(一)kubeletの起動入口:
app.NewKubeletCommand()
以上のコードではoptions.NewKubeletFlags、そして次のkubeletFlays.AddFlagsは構成パラメータのデフォルト値を設定する場所です
ここだNewKubeletFlagsでは、kubeletのさまざまな構成が初期化されます.
ここではlinux環境でRemoteRuntimeEndpointの定義があります.ContaineRuntimeOptionsの初期化もあります
=================================
上のものがあるのは、バイナリ配置時に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つ目の質問を見てみましょう.
実は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はcniの中でcalicoなどの第三者のcniに対して比較的に特殊なプラグインで、特殊はどこにありますか?https://github.com/containernetworking/pluginsにも記載されていますが、flannelはMeta:other pluginsクラスに属し、独立して作業することはできません.Mainクラスのサポートが必要です.flannelの本質はMainクラスのbridgeを呼び出すことであり、dockerのデフォルトのNetworkModeと一致しています.そのためバイナリ配置の場合、kubeletはflannel関連の構成を指定しておらず、podのネットワークも配置されており、docker自身が構成しているに違いない.
(二)2つ目の質問を見てみましょう.