kubelet源码解析-启动流程与POD处理(上)

kubelet介绍

在k8s集群中的每个节点上都运行着一个kubelet服务进程,其主要负责向apiserver注册节点、管理pod及pod中的容器,并通过 cAdvisor 监控节点和容器的资源。

  • 节点管理:节点注册、节点状态更新(定期心跳)
  • pod管理:接受来自apiserver、file、http等PodSpec,并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好
  • 容器健康检查:通过ReadinessProbe、LivenessProbe两种探针检查容器健康状态
  • 资源监控:通过 cAdvisor 获取其所在节点及容器的监控数据

kubelet组件模块

在这里插入图片描述

kubelet组件模块如上图所示,下面先对几个比较重要的几个模块进行简单说明:

  • Pleg(Pod Lifecycle Event Generator) 是kubelet 的核心模块,PLEG周期性调用container runtime获取本节点containers/sandboxes的信息(像docker ps),并与自身维护的pods cache信息进行对比,生成对应的 PodLifecycleEvent并发送到plegCh中,在kubelet syncLoop中对plegCh进行消费处理,最终达到用户的期望状态,相关设计可以看这里
  • podManager提供存储、访问Pod信息的接口,维护static pod和mirror pod的映射关系
  • containerManager 管理容器的各种资源,比如 CGroups、QoS、cpuset、device 等
  • KubeletGenericRuntimeManager是容器运行时的管理者,负责于 CRI 交互,完成容器和镜像的管理;关于client/server container runtime 设计可以看这里
  • statusManager负责维护pod状态信息并负责同步到apiserver
  • probeManager负责探测pod状态,依赖statusManager、statusManager、livenessManager、startupManager
  • cAdvisor是google开源的容器监控工具,集成在kubelet中,收集节点与容器的监控信息,对外提供查询接口
  • volumeManager 管理容器的存储卷,比如格式化资盘、挂载到 Node 本地、最后再将挂载路径传给容器

深入kubelet工作原理

在这里插入图片描述

从上图可以看出kubelet的主要工作逻辑在SyncLoop控制循环中,处理pod更新事件、pod生命周期变化、周期sync事件、定时清理事件;SyncLoop旁还有处理其他逻辑的控制循环,例如处理pod状态同步的statusManager,处理健康检查的probeManager等。

下面将从kubelet源码来分析各个环节的处理逻辑。

kubelet代码(版本1.19)主要位于cmd/kubelet与pkg/kubelet下,首先看下kubelet启动流程与初始化

1 cmd/kubelet/kubelet.go:34

func main() {
	rand.Seed(time.Now().UnixNano())

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

	if err := command.Execute(); err != nil {
		os.Exit(1)
	}
}

main 入口函数,kubelet依赖cobra命令行库,创建kubelet command并执行

2 cmd/kubelet/app/server.go:113

func NewKubeletCommand() *cobra.Command {
	cleanFlagSet := pflag.NewFlagSet(componentKubelet, pflag.ContinueOnError)
	cleanFlagSet.SetNormalizeFunc(cliflag.WordSepNormalizeFunc)
	// kubelet包含两部分配置
	// kubeletFlags是不能在运行时修改的配置或不在node间共享的配置
	// kubeletConfig可以在node间共享的配置,可以动态配置
	kubeletFlags := options.NewKubeletFlags()
	kubeletConfig, err := options.NewKubeletConfiguration()
	if err != nil {
		klog.Fatal(err)
	}

	cmd := &cobra.Command{
		Use: componentKubelet,
		...
		Run: func(cmd *cobra.Command, args []string) {
			// 命令行参数解析
			if err := cleanFlagSet.Parse(args); err != nil {
				cmd.Usage()
				klog.Fatal(err)
			}
			...
			// 验证参数
			if err := options.ValidateKubeletFlags(kubeletFlags); err != nil {
				klog.Fatal(err)
			}
			// 加载kubelet配置文件
			if configFile := kubeletFlags.KubeletConfigFile; len(configFile) > 0 {
				kubeletConfig, err = loadConfigFile(configFile)
				...
			}
			// 验证配置文件
			if err := kubeletconfigvalidation.ValidateKubeletConfiguration(kubeletConfig); err != nil {
				klog.Fatal(err)
			}
			// 构建KubeletServer
			kubeletServer := &options.KubeletServer{
				KubeletFlags:         *kubeletFlags,
				KubeletConfiguration: *kubeletConfig,
			}
			// 创建KubeletDeps
			kubeletDeps, err := UnsecuredDependencies(kubeletServer, utilfeature.DefaultFeatureGate)
			if err != nil {
				klog.Fatal(err)
			}
			// 设置信号处理
			ctx := genericapiserver.SetupSignalContext()
			// 执行Run
			klog.V(5).Infof("KubeletConfiguration: %#v", kubeletServer.KubeletConfiguration)
			if err := Run(ctx, kubeletServer, kubeletDeps, utilfeature.DefaultFeatureGate); err != nil {
				klog.Fatal(err)
			}
		},
	}
    ......
    return cmd
}

NewKubeletCommand创建kubelet cobra.Command结构体,Run函数主要解析参数、配置文件,构建KubeletServer、KubeletDependencies,设置信号处理函数,最后执行Run

3 cmd/kubelet/app/server.go:472

func run(ctx context.Context, s *options.KubeletServer, kubeDeps *kubelet.Dependencies, featureGate featuregate.FeatureGate) (err error) {
    ......
	// 验证KubeletServer中flags、configs参数
	if err := options.ValidateKubeletServer(s); err != nil {
		return err
	}
	// 获得Kubelet Lock File,feature
	if s.ExitOnLockContention && s.LockFilePath == "" {
		return errors.New("cannot exit on lock file contention: no lock file specified")
	}
	done := make(chan struct{})
	if s.LockFilePath != "" {
		klog.Infof("acquiring file lock on %q", s.LockFilePath)
		if err := flock.Acquire(s.LockFilePath); err != nil {
			return fmt.Errorf("unable to acquire file lock on %q: %v", s.LockFilePath, err)
		}
		if s.ExitOnLockContention {
			klog.Infof("watching for inotify events for: %v", s.LockFilePath)
			if err := watchForLockfileContention(s.LockFilePath, done); err != nil {
				return err
			}
		}
	}
	// 将当前配置注册到http server /configz URL
	err = initConfigz(&s.KubeletConfiguration)
	if err != nil {
		klog.Errorf("unable to register KubeletConfiguration with configz, error: %v", err)
	}
	......
	// 如果是standalone mode将所有client设置为nil
	switch {
	case standaloneMode:
		kubeDeps.KubeClient = nil
		kubeDeps.EventClient = nil
		kubeDeps.HeartbeatClient = nil
		klog.Warningf("standalone mode, no API client")
	// 根据配置创建各个clientset
	case kubeDeps.KubeClient == nil, kubeDeps.EventClient == nil, kubeDeps.HeartbeatClient == nil:
		clientConfig, closeAllConns, err := buildKubeletClientConfig(ctx, s, nodeName)
		if err != nil {
			return err
		}
		if closeAllConns == nil {
			return errors.New("closeAllConns must be a valid function other than nil")
		}
		kubeDeps.OnHeartbeatFailure = closeAllConns

		kubeDeps.KubeClient, err = clientset.NewForConfig(clientConfig)
		if err != nil {
			return fmt.Errorf("failed to initialize kubelet client: %v", err)
		}

		// make a separate client for events
		eventClientConfig := *clientConfig
		eventClientConfig.QPS = float32(s.EventRecordQPS)
		eventClientConfig.Burst = int(s.EventBurst)
		kubeDeps.EventClient, err = v1core.NewForConfig(&eventClientConfig)
		if err != nil {
			return fmt.Errorf("failed to initialize kubelet event client: %v", err)
		}

		// make a separate client for heartbeat with throttling disabled and a timeout attached
		heartbeatClientConfig := *clientConfig
		heartbeatClientConfig.Timeout = s.KubeletConfiguration.NodeStatusUpdateFrequency.Duration
		// The timeout is the minimum of the lease duration and status update frequency
		leaseTimeout :
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当你看到类似于 "Warning BackOff" 的错误消息,并且容器在一段时间后重新启动失败,这可能意味着容器无法正常启动并且在重试后仍然失败。以下是一些可能的处理方法: 1. 检查容器日志:使用命令 `kubectl logs <pod-name>` 查看容器的日志输出。这将提供有关容器启动失败的更多详细信息,可能会有一些错误提示。 2. 检查资限制:确保容器所需的资限制(如 CPU 和内存)与集群的可用资匹配。如果容器需要比集群可用的资更多,则可能导致重试失败。 3. 检查容器镜像:验证容器镜像是否存在,并且可以被正确拉取。你可以尝试手动拉取该镜像并验证是否成功。 4. 检查容器配置:检查容器的配置文件,确保没有任何错误或缺失的配置。特别注意容器所需的环境变量、挂载卷和端口映射等。 5. 检查容器依赖:如果容器有依赖其他服务或资,确保这些依赖项可用并且配置正确。例如,如果容器需要连接到数据库,请确保数据库可访问并且具有正确的连接配置。 6. 查看调度限制:检查 Pod 的调度限制是否与集群的调度策略相匹配。可能是由于调度策略限制而导致容器无法启动。 7. 联系集群管理员:如果以上步骤都无法解决问题,最好联系你的集群管理员,提供他们详细的错误日志和步骤,以便他们能够帮助你进一步调查和解决问题。 请注意,具体的处理方法可能因集群和应用程序配置而异。对于更复杂的问题,可能需要进行更深入的调查和诊断。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值