一、引言

       本文將基於 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."