一、引言

       本文将基于 Kubernetes 1.12 版本，分析 kubeadm  upgrade apply 的执行流程，希望对读者理解 k8s 有帮助！

       关于 init  流程请参考： K8S 源码探秘 之 kubeadm init 执行流程分析

       关于 join 流程请参考： K8S 源码探秘 之 kubeadm join 执行流程分析

二、流程介绍

2.1  首先，上一张整体执行流程图（可以点击看大图！！！）：

       像往常一样，kubeadm upgrade apply 首先会加载参数，并对参数配置进行相关的一些检查，以确保配置无误。

       紧接着，升级程序会读取 /etc/kubernetes/admin.conf 配置创建一个 client，连接 k8s Api Server，检查 server 是否健康，以及 master 是否为 ready 状态。检查全部通过后，再通过 client 拉取 InitConfiguration（实际就是读取一个 ConfigMap，该 ConfigMap 会在集群初始化的时候被创建），然后根据升级参数配置对该 InitConfiguration 进行相应的调整（比如更新 k8s 版本号等），为之后的升级做好准备。

       之后，升级工具会拉取升级对应版本的容器镜像，不过这次的镜像拉取与 init 过程不同，不是通过 cri 调用（不是直接通过调用 docker 服务）实现的，而是向 Api Server 发送请求，要求创建一些 DaemonSet，而这些 DaemonSet 依赖的镜像就是升级服务需要下载的镜像。这样等到 DaemonSet 运行起来的时候，相应的镜像必然就已经下载完毕了。通过阅读源码，这些 DaemonSet 运行的命令是 sleep 3600，没有实际意义，只是为了下载镜像而已。

       镜像下载好后，就开始真正执行升级了。根据运行模式的不同，升级路径有两条。如果是通过 Self-Hosted 模式运行的，则通过临时创建一个备份的 Control Plane（复制原来的 Control Plane），由备份的 Control Plane 临时接管集群，将旧 Control Plane 升级为新 Control Plane，再把控制权交给新的 Control Plane ，销毁临时的备份 Control Plane；如果是通过 Static Pod 模式运行的，则通过替换相关服务的 manifest 文件实现升级（需要首先升级 etcd 确保 etcd 正常）。

       升级完的配置与 init 过程类似，但不包含标记节点为 master 以及 token 创建过程。

       以上就是 kubeadm upgrade apply 的过程介绍了！

======

       经过深入探究，1.12 版本其实已经不再支持 self-hosted 模式部署了，只是代码还没有移除干净，可以忽略 self-hosted 流程

var selfHostingDeprecationMessage = "featureGates:SelfHosting has been removed in v1.12"

var storeCertsInSecretsDeprecationMessage = "featureGates:StoreCertsInSecrets has been removed in v1.12"

var highAvailabilityMessage = "featureGates:HighAvailability has been removed in v1.12\n" +
    "\tThis feature has been replaced by the kubeadm join --control-plane workflow."