如何更“優雅”地部署Kubernetes叢集

前言：Kubernet es的出現使得容器系統的排程管理變得簡便易行，但是它自身所帶的“部署難”又另千萬開發者望而卻步，是以該技術的推廣也在一定程度上受到了限制。10月21日，在七牛雲&K8S技術社群聯合舉辦的架構師實踐日上，七牛雲容器雲團隊開發工程師 趙梓旗，由淺入深，從kubernetes本身架構出發，為大家講解了如何從零開始部署一個完整的kubernetes工作叢集，并對官方部署工具kubeadm的基本原理進行解析。結合部署時所遇到的難題，分享了解決心得。最後還分享了叢集搭建經驗，幫助大家更快更好的實作叢集的高可用以及一鍵更新。以下是對他演講内容的整理。

今天分享的主題是《如何更“優雅”地部 署Kubernetes叢集》，我主要針對這些方面給大家介紹：

1、介紹Kubernetes部署方案的發展曆史；

2、Kubeadm部署工具如何部署Kubernetes叢集；

3、解析Kubeadm背後做的事情；

4、我們在使用Kubeadm部署叢集的時候遇到的常見問題；

5、使用Kubeadm的技巧。

我們主要是針對Kubeadm為大家做介紹，後面會給大家介紹我們為什麼要選擇這個工具。

K8S是非常出名的容器排程平台，很多人都在想使用它，對新手 來說想要搭建一個完整的K8S叢集還是比較難的，至少我們在使用過程中還是比較難的，這也是K8S的曆史遺留問題。追溯K8S曆史，它的第一個部署方案是現在在它的官方 repo上還存在的kube-up.sh腳本檔案，它 聲稱能夠一鍵部署一個K8S叢集，但是在使用過程中 我們發現還是有很多問題。比如對它進行初始化的流程就很複雜，而且對使用者不友好。另外它的功能随着K8S不斷疊代變得很龐雜。最重要的一點是 通過shell進行編寫，對shell不太熟的小朋友，在部署的時候會非常麻煩，出現問題定位也很困難。正是由于這個問題，社群當中也湧現出來非常多自研的部署方案。

圖 1

這是我截的K8S官方的文檔收錄自研部署方案的數量，可以看到它部署難的現狀。 當然經過這麼長時間的疊代，還是湧現出來一些比較成熟的方案，直到現在我也是非常推薦給大家使用的，這裡給大家列了比較出名的三個：

https://github.com/coreos/tectonic-installer

https://github.com/kubernetes-incubator/kubespray (Ex Kargo)

https://github.com/apprenda/kismatic

即便是這些方案經過了時間的考驗，他們也有各自的問題。我認為他們有三點問題：一是有些部署方案的使用學習曲線高。二是有些部署方案的靈活性非常有限，如果想針對我的叢集，有些特殊的地方想自定義的配置，他們可能無法實作。三是社群力量有限， 對于新功能的支援，他們開發的速度和支援的成熟度都不是特别可觀。

在這裡為大家介紹 Kubeadm 這樣一個工具。主要基于以下幾點原因推薦：

1、它是K8S官方推薦的下一代部署管理工具，通過K8S官方對這個工具的定位可以看出整個社群對K8S的部署有些新的思考。K8S叢集對底層實體機的提供方式不做任何假設，隻要滿足我們的要求，無論是實體機還是虛拟機都是可以的。 是以K8S的部署工具應該更加關注K8S元件的部署，而不是所有的事情都涵蓋進去，包括怎麼提供主機。Kubeadm出現的目标是隻專注于K8S元件的部署。是以官方也說Kubeadm不是kube-up.sh的2.0版本，而是更 專注于K8S元件的部署。正是由于它定位更加清晰，是以它的發展更加健康。

2、正是由于它功能更清晰才使使用方式更加友好，至于有多友好，一會兒給大家介紹。

3、配置的靈活性很高，可以針對不同的叢集需求，無論測試叢集、生産叢集還是虛拟機、雲主機，都能提供非常豐富的配置。一套部署方案适用于你任何一個環境。

4、Kubeadm背後的社群力量非常雄厚，我們都知道K8S社群是分為很多的興趣小組，叫SIG，每個興趣小組都有自己針對研究的主題，Kubeadm背後也有一個專門的興趣小組是專門針對這個 工具進行維護和開發，他們有非常嚴格的開發流程和開發規範，而且這個興趣小組的開發人員都是K8S的核心人員，是以他們對于整個K8S的底層、架構、機制都是非常了解的，由他們開發出來的部署工具在很大程度是非常可靠的。

5、Kubeadm被K8S官方全面的e2e測試涵蓋進去，這個工具 會經過嚴格的測試。

6、Kubeadm 的話語權，Kubeadm是K8S官方 推薦，也就是他的親兒子，它可以針對自己的要求向K8S提要求，K8S社群也會讨論他的需求是否合理，也會針對這些需求對自己的特性進行改變或者研發新的特性。這種 話語權，也是它領先其他社群方案的重要一點。

正是由于這些原因，基本上所有的第三方知名的社群方案都已經承認了Kubeadm的重要性，也想辦法以Kubeadm作為自己的基礎部署工具，進行上層的二次開發。 另外，我個人認為Kubeadm的代碼邏輯非常清楚，我在使用它的過程中，通過它的代碼了解了很多K8S部署和K8S内部機制的知識，既能夠提升我們對K8S的了解，也友善我們出現問題的時候定位是什麼問題。

說了很多我選擇這個工具的理由，下面介紹一下它是如何部署K8S的。在介紹部署流程之前先為大家簡述下K8S的架構，K8S的叢集大家都知道是有兩種角色，Master節點和Workers節點。Master節點主要是負責叢集的排程、叢集的管理，Workers負責啟動各種各樣的容器。無論你是什麼樣的節點，你隻要想啟動容器，都必須安裝Kubelet元件，當然你在底層要啟動容器，還要安裝Docker這個元件。

圖 2

在Master的節點上還要運作叢集排程的元件，主要是這四個（上圖藍色的四個部分），他們分别是APIServer、Etcd、Scheduler、Controller-Manager。APIServer的功能就是作為整個叢集的伺服器，接收來自兩方面的請求，一方面是來自叢集内部的，包括這些元件，Scheduler、Controller-manager發送給它的請求。另一方面也接收來自外部使用者通過Kubectl向它發出的請求。這些請求都是對K8S裡面的對象的增删改查。最後這些對象的資訊都是存儲在ETCD當中的。還有一個元件是Controller-Manager，Controller-Manager主要是用來管理K8S當中各種各樣的對象。下一個 元件是Scheduler，它負責對Pod進行排程，當建立一個新的Pod的時候，Scheduler會根據叢集資源消耗的狀态選擇最合适的實體節點把它排程上去，排程上去之後，就由那個節點上的Kubelet來啟動這個Pod。這些是跟Master相關的元件。另外還有一個元件非常關鍵，是 Kube-proxy，它實作的是K8S的service的概念，service是對功能類似的Pod的封裝，我想要通路功能類似的三個Pod，我可以管理他們的service就可以了。如果想要實作這個，我們的 Kube-proxy會在每個實體節點上都部署一個，為每個實體節點書寫一系列的iptables規則，這個節點上的Pod如果想要通路service的IP，他的請求會被這些規則修改，把請求的目的地從service的IP修改Pod的IP。還有一個比較關鍵的元件是網絡元件，為了實作叢集Pod和Pod為之間的網絡通信，網絡之間的選擇方案有很多，相信大家了解過。這樣就構成了整個K8S的叢集。

介紹完架構之後，我們看一下Kubeadm這個工具到底如何部署可用的K8S叢集的。它大概分為五個步驟：

1、準備正确配置的機器，K8S對底層機器隻有三點要求：一是正确的作業系統，Ubuntu 16.04 / Debian9/CentOS 7/RHEL7/Fedora 25 / HypriotOS v1.0.1 其中一個都可以。比較常見的是Ubuntu或者CentOs。二是硬體配置要求你至少有1GB的記憶體。三是網絡上要求叢集裡的節點之間網絡互通。隻要滿足這三個要求，無論是虛拟機、實體機還是雲主機都是可以的。

2、準備好機器之後要安裝必要的軟體，這裡主要都是通過deb包或者rpm包來進行安裝的。主要包括這幾個比較重要的軟體：一是Docker，K8S官方給出的推薦，如果叢集是1.8版本之前的，建議你采用1.12.06 Docker版本，如果K8S叢集是1.8版本或者1.8版本之後的就采用比較新的1.17.03這個版本。安裝Docker之後還要安裝Kubelet元件，安裝之後，它通過作業系統的systemd程序管理軟體來進行管理的，并且設計成開機自啟動，在一定程度上保證 Kubelet元件的可用性。自然，要用Kubeadm來部署，在每個機器上還要安裝Kubeadm，Kubectl也是，我們也會把它進行安裝。這步完成之後就可以保證每個節點安裝這幾個元件。

3、啟動Master節點， 在Master節點的機器上運作這樣一條指令，kubeadm init，這個指令幫助你啟動跟Master相關的元件，還有剛才介紹的四個APIServer、Etcd、Scheduler、Controller-Manager，而且還會順便啟動Kube-proxy這個元件，還有Kube-DNS，它不是工作叢集的必備元件，但是有這個 元件就可以讓叢集具備DNS的服務。這步完成之後，标準輸出會輸出這樣一條指令，叫做kubeadm join -- token xxxxxx master _ip;master _port，這個token比較關鍵，是我們後面為了安全的添加一個節點到叢集當中必要的資訊，而且會提示你這個資訊一定要儲存好，隻有信任的人才能拿到。它會告訴你，如果你想加一個新的機器在叢集當中，隻要在這個機器上運作這條指令就好。

4、我們的下一步就是到worker節點上去運作這樣一條指令，這樣就構成了基礎的叢集。但是這個叢集現在是殘廢的叢集，因為沒有網絡元件，你是無法真正工作的。這時候你看它的狀态，所有的節點都是處于沒有準備好的狀态。

5、下一步我們要部署整個網絡。這是K ubeadm比較局限性的地方，它不關心使用者到底采用什麼樣的網絡方案，這是經過思考做出的決定。 社群認為關于網絡方案的選擇，以及網絡元件的部署應該交由使用者決定，是以kubeadm不會做任何支援。比較幸運的是這些比較知名的網絡方案都已經能夠跑在K8S上，跑在K8S上就代表可以把他們寫成一個yaml檔案部署到叢集中。比較典型的是calico這樣的方案，官方已經提供了完全不用修改的配置，可以直接放到叢集當中，最後構成完整的叢集。

這是Kubeadm部署K8S叢集的大緻流程。它整個隻需要五步，而且這些指令和他要做的事情都是相對應的，比如我要初始化一個叢集那就是kubeadm init，是以我說這個工具是非常友好工具非常重要的原因。

部署好的這個叢集具備什麼樣的特性呢？1、這個叢集工作在安全模式下，安全模式含義是所有元件之間的通訊都是通過TLS加密，任何想和這個叢集通訊的使用者或者元件都必須配置一個kubeconfig認證才可以。2、這個叢集所有的重要元件，包括Master相關的元件都是容器化部署的。3、叢集隻有單個Master節點。4、自帶Kube-dns元件。

上面為大家介紹了如何通過Kubeadm來部署一個叢集。下面為大家介紹的是 Kubeadm背後到底做了什麼？

我們看Kubeadm搭建整個叢集好像很容易，但是使用過程中可能還是會遇到一些問題，有些問題是因為我們在中國，有些問題是我們叢集的配置有些不太對。當時我也是研究了Kubeadm到底背後做了什麼，這讓我收獲很多，對排查問題很有幫助。

主要是兩個步驟：一是kubeadm init，還有一個是k ubeadm join。init是初始化一個叢集，首先它會對機器進行前期檢查，比如我們要啟動K8S的元件，它的端口是否被其他程序占用，有些cgroups特性是否正确配置等等。有些錯誤會導緻Kubeadm無法繼續執行，需要手動修複才能繼續運作。檢查通過之後就會生成token，token是說後來加入的新節點要輸入的token，它到底怎麼完成呢？工作原理是怎麼樣呢？這個後面為大家介紹。

圖 3

到底如何實作安全的K8S環境？這是很多社群方案沒有為大家很好解決的事情。K8S工作的模式有點類似于CS的模式，可以看到圖中打領帶的小人代表為整個APIServer，它是作為整個叢集的伺服器來為不同的用戶端服務的，包括左下角的叢集内部的元件，比如Kubelet、Control-manage r這種元件，對他們提供服務，還有叢集外部使用Kubectl的使用者來提供服務。如果想實作K8S的安全叢集，首先用戶端通路服務端的時候，要對服務端要進行認證，所采用的方案是最經典的伺服器認證機制，要求我們的服務端要去一個比較知名的證書中心頒發證書給我，這些用戶端才用這些證書中心的根證書來驗證伺服器證書，才知道伺服器是否是真實可信的伺服器。這種方案從成本上肯定不可行，公司肯定有幾個叢集，而且我筆記本還有一個叢集，不可能給每個叢集買證書。Kubeadm也考慮到這個問題，它采用的方案是自簽名的證書中心，它創造虛拟的證書中心，隻在叢集内部可用，這個證書中心會給APIServer簽發證書，并且把根證書通過kubeconfig檔案的方式分發到想和 APIServer通訊的用戶端這裡。這個用戶端如果想要和Server通訊的時候，他會通過手中握有的證書來驗證APIServer的證書，驗證通過，就代表APIServer是真實可信的，大概是這樣的流程。建立好認證的過程，我們後續就會采用比較經典對稱加密的機制來加密他們之間的資料傳輸。這步要做的事情是建立用戶端對服務端的信任，安全包括兩方面，建立用戶端到服務端的信任。

圖 4

用戶端信任服務端，服務端也要信任用戶端。這要給目前想給APIServer通訊的元件都頒發一個Kubeconfig檔案，這就涉及K8S認證鑒權機制，我不知道大家對這個機制是否有深入的了解，你要真正搭建起生産上能用的叢集，這是你必須考慮的一部分。K8S認證鑒權機制是分為三個步驟，可以在上圖中看到，這三個步驟有列出來，任何用戶端想發送請求在APIServer的時候，在這之前它一定會經過三重檢查，這重檢查分别是：認證、 鑒權和通路控制。這三個檢查做的事情我分别用一句話為它總結一下，相當于這個用戶端想要發送請求就要回答這三個問題，一是用戶端是誰，是否是我認識的人；二是你這個人是否有在請求當中想要做的事情的權利，是否有權利做你想要請求的事情；三是你要請求做的這件事情肯定要設定一些參數，設定的參數是否合理， Kubeadm 在第四步要給每個用戶端簽發kubeconfig就是為了用戶端回答你是誰的問題。這一步和上一步的機制很像，我們上一步構造虛拟的證書中心，不僅給APIServer頒發伺服器的證書，還給每個用戶端頒發用戶端的證書，這個證書可以讓 APIServer認證你這個人是誰，這建立起從服務端到用戶端的信任。這塊需要頒發證書的用戶端，包括Kubelet、Controller-Manager、Scheduler ，還包括我們後面自己要用Kubectl建立叢集，我們還會給管理者去建立kubeconfig的檔案。

啟動和Master相關的元件，圖中看到的Etcd、APIServer、Controller-Manager、Scheduler。它啟動的方式是基于static pod的方式，這種方式是把這些元件的yaml檔案寫到 /etc/kubernetes/manifests目錄下，Kubelet會周期性輪巡這個目錄下面的檔案，如果這個目錄下面建立新檔案 ，就根據檔案的要求在這個節點上啟動一個Pod。跟Master相關的元件都是通過static pod來啟動的。它啟動完這個檔案之後，Kubeadm就會不停的輪巡api server的健康接口，直到健康接口傳回200才會認為這個叢集的重要元件都已經啟動了。這是我們在使用過程中經常出現問題的一個地方，大家運作到這個地方就卡住了，一直在等。我們後面會具體探讨這塊經常出現哪些問題。

圖 5

上一步如果通過的話，我們就會對叢集進行後續的初始化工作，包括給Master節點加上一些Label和Taint，保證和Master相關的pod 才會部署到這個節點上。

建立Kube-proxy和Kube-dns這兩個元件。

為了後續添加新 的節點，并且是以一種更安全的方式進行添加。 Kubeadm希望建立一種雙向的信任，像圖中表示的一樣，左邊表示的是現在已有的叢集，右邊代表的是新添加的節點，建立雙向的信任代表已有的叢集要信任新添加的節點，是可信的、真實的。另外新添加的節點也要相信自己加入的叢集是可信的叢集，這種建構雙向信任的基礎是我們剛才的token，是以token一定要儲存好， 保證隻有可信的人才能知道token，因為它是建構雙向信任的基礎。由于它和後面Kube adm join的指令非常相關，是以我一起為大家介紹。

建立第一個方向的信任， 即新添加的節點如何相信自己加入的叢集是可信的叢集？這個方向的建立是通過Kubeadm建立的Cluster-info的公共資訊，Cluster-info其實就是一個configmap的對象，這裡面主要存放 三個資訊。第一個資訊是虛拟證書中心的根證書，第二個是和叢集相關的資訊，比如APIServer的位址在哪裡。 第三個資訊需要我們把這兩個資訊放在一起，通過隻有我們信任的人知道的token對這個資訊做一下哈希，把這三個放在一起構成Cluster -info，Cluster-info是完全對外暴露的，也就是說任何人不用提供任何認證資訊就可以拿到這個東西。與之相應的，Kubeadm join指令是先擷取 Cluster-info資訊，隻有我們相信的人知道token，它可以用token驗證Cluster -info是否可信，這樣建構從新添加的節點到叢集方向的信任。

第二個方向，如何讓叢集信任我添加的節點是真實的節點？ 也是基于剛才說的token機制。它實作方式是會把token通過一種方式儲存到叢集中，并且開啟認證機制，最後的效果是任何用戶端在發送請求給APIServer，如果請求的頭部帶了token資訊，都會被 APIServer認證為有效使用者，這樣其實就建構了叢集對于worker的信任。這種雙向的信任建立成功之後，Master節點就會給新添加的節點頒發一個可用的kubeconfig檔案，新添加的節點可以用這個檔案把自己加入叢集中了。

使用Kubeadm工具中遇到的問題

1、安裝包無法翻牆的問題，個人使用者可能都會遇到。剛才我們介紹的工具Kubeadm、Kubelet、Kubectl都是通過deb包和rpm包安裝的，但是官網隻提供了Google安裝源來進行安裝，在我們國内是無法安裝到的。給大家推薦中科大鏡像源，這個源裡面提供了和Google官方同步的安裝 源，是以可以在裡面體驗到最新的K8S版本。

2、Docker鏡像源無法下載下傳的問題，這也是我們國内使用者會遇到的。在Kubeadm初始化叢集過程當中，它會下載下傳很多的鏡像，如果你不對它進行任何配置，它都是對Google官方鏡像源進行下載下傳，我們國内使用者又是無法體驗的。是以我們需要做兩件事：一是找到國内和官方保持同步的源，這裡為大家推薦阿裡雲的源。二是告訴Kubeadm到這個源下載下傳 。通過給Kubeadm配置環境變量 KUBE_REPO_PREFIX，可以讓它在這個源裡下載下傳所有的鏡像。但是有一個例外是pause鏡像， 當K8S每啟動一個pod，不僅啟動使用者指定的鏡像，還會啟動一個pause鏡像， 為使用者鏡像做初始化工作，它預設的下載下傳位址是Google官方的位址。而且這個位址即便配置了Kubeadm的環境變量也不會對它産生影響，還是在這裡進行下載下傳。因為它其實是Kubelet的一個參數，是以我們需要修改Kubelet的參數才能讓它從國内的鏡像源下載下傳，這個參數就是 。如果大家想在國内體驗，一定要注意這點。這點沒有修改成功，會導緻叢集無法啟動。

3、APIServer參數 --advertise-address判定的問題，這個參數是用來指定APIServer 和其他元件之間通訊的位址或者它的監聽位址。它預設的判定方法會選取機器預設的網卡ip位址，這 一點有時并不合适，因為我們在自己使用過程中會有這樣的場景，我們有些機器可能預設網卡是 公網網卡，我們希望叢集内部元件互相通訊的東西走内網流量，是以這個時候，我們還是采用這種預設的判定方法，就會讓APIServer 綁定公網網卡。如果你的環境是這樣的配置，建議你用這樣的方式綁定到内網網卡。Kubelet也有這樣的參數，叫做--node-ip ，在這樣的場景下也會預設綁定在公網網卡上，如果你的環境也是這樣子的，建議你用指令行的方式把内網位址 配置進去。這個問題的發現源于我們自己的使用實際場景，我們想通過虛拟機管理 軟體Vagrant來部署叢集的時候會出現一些問題，因為它為每個虛拟機創造一個nat網卡作為預設網卡，它的ip位址固定，如果建立兩個虛拟機，這兩個虛拟機預設網卡都是一個位址 。如果這個時候還是采用這種方式來指定，采用預設政策就會導緻所有pod位址都是那個nat 網卡位址。K8S官方也給出一個方案，如果大家用這個部署叢集的需求，要注意這個問題。

4、DNS Service IP和Kubelet --cluster-dns參數不比對的問題。Kubeadm預設建立兩個service，一個service是用來暴露 APIServer服務的，另外一個service是用來暴露Kube DNS的服務的，這兩個服務位址不是随機生成的，是有一定規則的。Kubeadm 首先會指定一個service ip的範圍，預設值是10.96 .0.0/16，根據這個範圍就可以按照一定的規則生成兩個位址。APIServer 服務的位址會取這個網段的第一個位址，也就是10.96.0.1，Kube dns更加死闆，會把最後0前面加一個1，就作為service ip， 即10.96.0.10，而且不能修改配置方式。是以這是一個預設的規則。Kubelet還有一個參數叫-- cluster-dns，每當Kubelet啟動一個pod的時候，利用這個參數昨 為這個容器的nameserver。也就是說這個容器如果它想要解析域名 的時候，它的DNS服務的nameserver是 什麼。如果你想采用叢集裡面DNS服務，必須指定為Kube DNS 的 server ip，預設的情況，它配置的就是10.96.0.10，如果采用預設配置不會發現任何問題，叢集工作好好的。但是一旦在生産環境中，比如你的環境，需要更換service ip 的範圍，它會新生成新的Kube- DNS的ip，如果不及時同步，會導緻你啟動的pod無法使用這個DNS 的服務。這是我們當時遇到的問題，希望大家之後避免。

最後介紹使用Kubeadm的技巧：

圖 6

Kubeadm 帶有一個參數—config參數，我們可以給它傳遞一個yaml檔案，yaml檔案中描述了K8S裡面的一種對象，叫做MasterConfiguration。 上圖中我隻是截了這種對象的描述資訊的一部分，它提供了對叢集非常豐富的 自定義配置項，你可以針對這個叢集，這個叢集的情況對它進行自定義的配置，比如想安裝的 K8S版本，service ip的範圍等等。如果大家使用這個工具，要靈活使用這樣的檔案。 下面介紹兩個常見的使用執行個體。

1、有時候使用者想體驗K8S的新特性，一般采用新特性需要修改像APIServer等這種Master元件的啟動的指令行參數，但是用Kubeadm啟動的 Master元件預設情況有可能不會加上 我們想要的參數，那麼如果我想 用的話，可以在MasterConfiguration裡面去找a piServerExtraArgs參數，可以把對APIServer 額外的參數寫到裡面，這樣啟動的叢集就把這些參數會帶進去。同理Controller –manager和Scheduler也提供你想要的參數。

2、通常情況下，我們的叢集都是内網叢集，隻暴露一個公網ip，我希望通過本地通路這個叢集，這時候隻能通過公網ip通路。 這時候應該怎麼配置呢？我們一步一步的思考，剛才我們說了，Kubeadm在初始化的時候會為管理者生成一個 Kubeconfig檔案，把它下載下傳下來 是不是就可以？事實證明這樣不行， 因為這個叢集是内網叢集，Kubeconfig檔案 中APIServer的位址是内網ip。是以無法通路到。那麼我把内網ip改成 APIServer公網ip是不是就可以了 呢？經過實驗發現也是不可以的，會報 出認證無法通過的錯誤。為什麼認證無法通過？這要回顧我們剛剛講過的服務端認證的流程，剛才說一個用戶端想跟APIServer通路 時，要拿伺服器證書，進行解析，去看APIServer都有哪些别名，再把用戶端通路APIServer時所采用的ip 或者域名和别名相比較，看是否已經涵蓋在别名裡面了。如果涵蓋進去，我就認為這個server是可認證的。由于我們在這個場景部署出來的叢集Kubeadm生成 APIServer證書不會把公網ip寫到證書裡，是以 導緻用公網ip通路不通過驗證。解決方案很簡單，把公網ip簽到證書裡面就可以，是以這個yaml檔案也給我們提供了這樣一個選項，叫apiServerCertSANs這個選項，隻要把公網IP寫到這裡，再啟動這個叢集的時候，這個證書就可以有這個公網ip，我就可以使用剛才我說的流程，把檔案下載下傳下來把APIServer的位址改成公網ip，然後就可以通路了。這是我工作當中非常常見的需求，這樣會讓你的開發工作更加友善一些。

3､下面我們再考慮一個常見的需求，剛才我們說的Master元件是通過static pod形式來建立的，如果現在一個叢集正在運作中，我不能重新部署叢集。還希望給Master元件，比如APIServer添加一個指令行參數，怎麼辦？隻能對它進行動态更新。我們嘗試了很多種方式，發現隻有這樣一種流程才能成功更新：首先先把APIServer的yaml檔案從/etc/kubernetes/manifests目錄下移出去，然後改好再移回來，才能實作更新。我們調研了K8S官方的說法，這是由于Kubelet的代碼邏輯導緻的，但是K8S官方認為static pod并不是會長期存在的形式，以後會越來越少用這種特性，是以也不會針對這種問題修改代碼。如果大家還使用static pod的方式管理你的容器，就隻能使用這種方案，沒有辦法解決。

本文轉自掘金-

如何更“優雅”地部署Kubernetes叢集