kubeadm init快速搭建k8s源码分析
今天小编给大家分享一下kubeadm init快速搭建k8s源码分析的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。
引言
我们都知道,从头搭建k8s集群是个非常棘手的事情,所以在更多的情况下大家通常会选择通过 kubeadm 工具来搭建 k8s 集群。当我们执行 kubeadm init
命令后就可以进行 k8s 的快速搭建
根据k8s的官方文档以及源码,我们可以对整个 init 命令的工作原理做个了解,官方文档地址:
kubernetes.io/zh-cn/docs/…
进入 app/cmd 目录可以看到 init.go
文件,其中的方法:func newCmdInit(out io.Writer, initOptions *initOptions) *cobra.Command
就是 init 的入口函数
cmd := &cobra.Command{ Use: "init", Short: "Run this command in order to set up the Kubernetes control plane", RunE: func(cmd *cobra.Command, args []string) error { c, err := initRunner.InitData(args) if err != nil { return err } data := c.(*initData) fmt.Printf("[init] Using Kubernetes version: %s\n", data.cfg.KubernetesVersion) return initRunner.Run(args) }, Args: cobra.NoArgs, }
依然是对 cobra 库的一个应用, Use 来规定子命令,Short 来做简短描述,RunE用来将执行中的错误捕获并返回给调用者
下面的代码就都是为 init 命令绑定和添加一些标志:
// add flags to the init command. // init command local flags could be eventually inherited by the sub-commands automatically generated for phases AddInitConfigFlags(cmd.Flags(), initOptions.externalInitCfg) AddClusterConfigFlags(cmd.Flags(), initOptions.externalClusterCfg, &initOptions.featureGatesString) AddInitOtherFlags(cmd.Flags(), initOptions) initOptions.bto.AddTokenFlag(cmd.Flags()) initOptions.bto.AddTTLFlag(cmd.Flags()) options.AddImageMetaFlags(cmd.Flags(), &initOptions.externalClusterCfg.ImageRepository) // defines additional flag that are not used by the init command but that could be eventually used // by the sub-commands automatically generated for phases initRunner.SetAdditionalFlags(func(flags *flag.FlagSet) { options.AddKubeConfigFlag(flags, &initOptions.kubeconfigPath) options.AddKubeConfigDirFlag(flags, &initOptions.kubeconfigDir) options.AddControlPlanExtraArgsFlags(flags, &initOptions.externalClusterCfg.APIServer.ExtraArgs, &initOptions.externalClusterCfg.ControllerManager.ExtraArgs, &initOptions.externalClusterCfg.Scheduler.ExtraArgs) })
以方法 AddInitConfigFlags
为例,他的作用是将绑定到配置的初始化标志添加到指定的标志集:
// AddInitConfigFlags adds init flags bound to the config to the specified flagset func AddInitConfigFlags(flagSet *flag.FlagSet, cfg *kubeadmapiv1.InitConfiguration) { flagSet.StringVar( &cfg.LocalAPIEndpoint.AdvertiseAddress, options.APIServerAdvertiseAddress, cfg.LocalAPIEndpoint.AdvertiseAddress, "The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.", ) flagSet.Int32Var( &cfg.LocalAPIEndpoint.BindPort, options.APIServerBindPort, cfg.LocalAPIEndpoint.BindPort, "Port for the API Server to bind to.", ) flagSet.StringVar( &cfg.NodeRegistration.Name, options.NodeName, cfg.NodeRegistration.Name, `Specify the node name.`, ) flagSet.StringVar( &cfg.CertificateKey, options.CertificateKey, "", "Key used to encrypt the control-plane certificates in the kubeadm-certs Secret.", ) cmdutil.AddCRISocketFlag(flagSet, &cfg.NodeRegistration.CRISocket) }
通过 kubeadm init --help
指令,可以看到相应的标志应用,例如服务地址,端口号等基本配置:
通过上面的 help 命令我们也可以看到,在 init 命令中就已经告诉了我们工作的几个流程阶段:
从源码中来看,绑定完一系列标志位后,init 命令正式开始绑定工作流程的执行,正好对应上图中的几个执行阶段:(集群的环境和源码的版本不是完全一致,集群的环境较为老旧一些,例如源码中的最后一个阶段 NewShowJoinCommandPhase
在集群命令中没有打印出来,因为老版本的最后一个阶段是放在命令绑定时的 RunE 中没有错误时最后执行的,最新的源码已经提取出来单独作为一个阶段了,基本逻辑还是没有变化的,调整后结构更加清晰合理了)
// initialize the workflow runner with the list of phases initRunner.AppendPhase(phases.NewPreflightPhase()) initRunner.AppendPhase(phases.NewCertsPhase()) initRunner.AppendPhase(phases.NewKubeConfigPhase()) initRunner.AppendPhase(phases.NewKubeletStartPhase()) initRunner.AppendPhase(phases.NewControlPlanePhase()) initRunner.AppendPhase(phases.NewEtcdPhase()) initRunner.AppendPhase(phases.NewWaitControlPlanePhase()) initRunner.AppendPhase(phases.NewUploadConfigPhase()) initRunner.AppendPhase(phases.NewUploadCertsPhase()) initRunner.AppendPhase(phases.NewMarkControlPlanePhase()) initRunner.AppendPhase(phases.NewBootstrapTokenPhase()) initRunner.AppendPhase(phases.NewKubeletFinalizePhase()) initRunner.AppendPhase(phases.NewAddonPhase()) initRunner.AppendPhase(phases.NewShowJoinCommandPhase())
也就是说,kubeadm init 的执行共经历了14个阶段,分别是:
NewPreflightPhase:在做出变更前运行一系列的预检项来验证系统状态,可以通过指定
--ignore-preflight-errors=<错误列表>
参数来忽略错误NewCertsPhase:生成一个自签名的 CA 证书来为集群中的每一个组件建立身份标识
NewKubeConfigPhase:建立配置目录及默认或指定的配置文件,以便 kubelet、控制器管理器和调度器用来连接到 API 服务器
NewKubeletStartPhase:在一个节点上启动 kubelet
NewControlPlanePhase:用来引导创建控制面节点,生成 apiserver、controller-manager、scheduler 静态pod描述文件
NewEtcdPhase:实现对 etcd 的处理,没有提供外部的 etcd 时,会生成一份 etcd 的静态资源文件
NewWaitControlPlanePhase:是在控制平面和 etcd 阶段之后运行的隐藏阶段,作用是等待控制面节点任务的执行,如果 kubelet 启动异常或者控制面节点崩溃将会停止后面的流程
NewUploadConfigPhase:上传配置
NewUploadCertsPhase:上传证书
NewMarkControlPlanePhase:为 master 做标记,即添加污点
NewBootstrapTokenPhase:生成bootstrap token和ca证书configmap,后续 node 可以通过生成的 token join加入集群
NewKubeletFinalizePhase:在 TLS 引导后更新与 kubelet 相关的设置,其实就是将kubelet与kube-apiserver通信的kubeconfig文件中的证书替换成由kube-controller-manager签发返回的证书
NewAddonPhase:通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件
NewShowJoinCommandPhase:打印初始化成功的命令,同时为用户提供后续的操作指导,例如工作节点的加入等
14个执行阶段都成功执行后,kubeadm 的任务也就完成了,k8s 集群部署成功!
以上就是“kubeadm init快速搭建k8s源码分析”这篇文章的所有内容,感谢各位的阅读!相信大家阅读完这篇文章都有很大的收获,小编每天都会为大家更新不同的知识,如果还想学习更多的知识,请关注蜗牛博客行业资讯频道。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:niceseo99@gmail.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。
评论