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源碼分析”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。