您好,登錄后才能下訂單哦!
今天小編給大家分享一下kubeadm init快速搭建k8s源碼分析的相關(guān)知識點,內(nèi)容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
我們都知道,從頭搭建k8s集群是個非常棘手的事情,所以在更多的情況下大家通常會選擇通過 kubeadm 工具來搭建 k8s 集群。當(dāng)我們執(zhí)行 kubeadm init
命令后就可以進行 k8s 的快速搭建
根據(jù)k8s的官方文檔以及源碼,我們可以對整個 init 命令的工作原理做個了解,官方文檔地址:
kubernetes.io/zh-cn/docs/…
進入 app/cmd 目錄可以看到 init.go
文件,其中的方法:func newCmdInit(out io.Writer, initOptions *initOptions) *cobra.Command
就是 init 的入口函數(shù)
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 庫的一個應(yīng)用, Use 來規(guī)定子命令,Short 來做簡短描述,RunE用來將執(zhí)行中的錯誤捕獲并返回給調(diào)用者
下面的代碼就都是為 init 命令綁定和添加一些標(biāo)志:
// 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
為例,他的作用是將綁定到配置的初始化標(biāo)志添加到指定的標(biāo)志集:
// 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
指令,可以看到相應(yīng)的標(biāo)志應(yīng)用,例如服務(wù)地址,端口號等基本配置:
通過上面的 help 命令我們也可以看到,在 init 命令中就已經(jīng)告訴了我們工作的幾個流程階段:
從源碼中來看,綁定完一系列標(biāo)志位后,init 命令正式開始綁定工作流程的執(zhí)行,正好對應(yīng)上圖中的幾個執(zhí)行階段:(集群的環(huán)境和源碼的版本不是完全一致,集群的環(huán)境較為老舊一些,例如源碼中的最后一個階段 NewShowJoinCommandPhase
在集群命令中沒有打印出來,因為老版本的最后一個階段是放在命令綁定時的 RunE 中沒有錯誤時最后執(zhí)行的,最新的源碼已經(jīng)提取出來單獨作為一個階段了,基本邏輯還是沒有變化的,調(diào)整后結(jié)構(gòu)更加清晰合理了)
// 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 的執(zhí)行共經(jīng)歷了14個階段,分別是:
NewPreflightPhase:在做出變更前運行一系列的預(yù)檢項來驗證系統(tǒng)狀態(tài),可以通過指定 --ignore-preflight-errors=<錯誤列表>
參數(shù)來忽略錯誤
NewCertsPhase:生成一個自簽名的 CA 證書來為集群中的每一個組件建立身份標(biāo)識
NewKubeConfigPhase:建立配置目錄及默認或指定的配置文件,以便 kubelet、控制器管理器和調(diào)度器用來連接到 API 服務(wù)器
NewKubeletStartPhase:在一個節(jié)點上啟動 kubelet
NewControlPlanePhase:用來引導(dǎo)創(chuàng)建控制面節(jié)點,生成 apiserver、controller-manager、scheduler 靜態(tài)pod描述文件
NewEtcdPhase:實現(xiàn)對 etcd 的處理,沒有提供外部的 etcd 時,會生成一份 etcd 的靜態(tài)資源文件
NewWaitControlPlanePhase:是在控制平面和 etcd 階段之后運行的隱藏階段,作用是等待控制面節(jié)點任務(wù)的執(zhí)行,如果 kubelet 啟動異常或者控制面節(jié)點崩潰將會停止后面的流程
NewUploadConfigPhase:上傳配置
NewUploadCertsPhase:上傳證書
NewMarkControlPlanePhase:為 master 做標(biāo)記,即添加污點
NewBootstrapTokenPhase:生成bootstrap token和ca證書configmap,后續(xù) node 可以通過生成的 token join加入集群
NewKubeletFinalizePhase:在 TLS 引導(dǎo)后更新與 kubelet 相關(guān)的設(shè)置,其實就是將kubelet與kube-apiserver通信的kubeconfig文件中的證書替換成由kube-controller-manager簽發(fā)返回的證書
NewAddonPhase:通過 API 服務(wù)器安裝一個 DNS 服務(wù)器 (CoreDNS) 和 kube-proxy 附加組件
NewShowJoinCommandPhase:打印初始化成功的命令,同時為用戶提供后續(xù)的操作指導(dǎo),例如工作節(jié)點的加入等
14個執(zhí)行階段都成功執(zhí)行后,kubeadm 的任務(wù)也就完成了,k8s 集群部署成功!
以上就是“kubeadm init快速搭建k8s源碼分析”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學(xué)習(xí)更多的知識,請關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。