Kubernetes架構

Kubernetes

Kubernetes架構

Kubernetes最初源於谷歌內部的Borg，提供了面向應用的容器集羣部署和管理系統。Kubernetes的目標旨在消除編排物理/虛擬計算，網絡和存儲基礎設施的負擔，並使應用程序運營商和開發人員完全將重點放在以容器爲中心的原語上進行自助運營。Kubernetes 也提供穩定、兼容的基礎（平臺），用於構建定製化的workflows 和更高級的自動化任務。 Kubernetes 具備完善的集羣管理能力，包括多層次的安全防護和准入機制、多租戶應用支撐能力、透明的服務註冊和服務發現機制、內建負載均衡器、故障發現和自我修復能力、服務滾動升級和在線擴容、可擴展的資源自動調度機制、多粒度的資源配額管理能力。 Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。

• 容器

• Pod：命名空間的隔離，共享網絡，每個Pod都有獨立IP，使用Service Account爲Pod賦予賬戶

• Sandbox：是對最小資源調度單位的抽象，甚至可以是虛擬機

• Node：網絡隔離，每個節點間網絡是隔離的，每個節點都有單獨的IP地址

• Cluster：元數據的隔離，使用Federation可以將不同的集羣聯合在一起

Kubernetes中的基本資源類型分成了三類：

• 部署：Deploymnt、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob

• 服務：Service、Ingress

• 存儲：PV、PVC、ConfigMap、Secret

Kubernetes主要由以下幾個核心組件組成：

• etcd保存了整個集羣的狀態；

• apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；

• controller manager負責維護集羣的狀態，比如故障檢測、自動擴展、滾動更新等；

• scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；

• kubelet負責維護容器的生命週期，同時也負責Volume（CSI）和網絡（CNI）的管理；

• Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；

• kube-proxy負責爲Service提供cluster內部的服務發現和負載均衡；

除了核心組件，還有一些推薦的插件，其中有的已經成爲CNCF中的託管項目：

• CoreDNS負責爲整個集羣提供DNS服務

• Ingress Controller爲服務提供外網入口

• Prometheus提供資源監控

• Dashboard提供GUI

• Federation提供跨可用區的集羣

   

Kubernetes架構示意圖

整體架構

下圖清晰表明了Kubernetes的架構設計以及組件之間的通信協議。

• Kubernetes設計理念與分佈式系統

  分析和理解Kubernetes的設計理念可以使我們更深入地瞭解Kubernetes系統，更好地利用它管理分佈式部署的雲原生應用，另一方面也可以讓我們借鑑其在分佈式系統設計方面的經驗。

  分層架構

  Kubernetes設計理念和功能其實就是一個類似Linux的分層架構，如下圖所示

  圖片 - Kubernetes 分層架構示意圖

  • 核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供插件式應用執行環境

  • 應用層：部署（無狀態應用、有狀態應用、批處理任務、集羣應用等）和路由（服務發現、DNS解析等）

  • 管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴展、動態Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）

  • 接口層：kubectl命令行工具、客戶端SDK以及集羣聯邦

  • 生態系統：在接口層之上的龐大容器集羣管理調度的生態系統，可以劃分爲兩個範疇

    • Kubernetes外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等

    • Kubernetes內部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、集羣自身的配置和管理等

Kubernetes的核心技術概念和API對象

API對象是Kubernetes集羣中的管理操作單元。Kubernetes集羣系統每支持一項新功能，引入一項新技術，一定會新引入對應的API對象，支持對該功能的管理操作。例如副本集Replica Set對應的API對象是RS。

每個API對象都有3大類屬性：元數據metadata、規範spec和狀態status。元數據是用來標識API對象的，每個對象都至少有3個元數據：namespace，name和uid；除此以外還有各種各樣的標籤labels用來標識和匹配不同的對象，例如用戶可以用標籤env來標識區分不同的服務部署環境，分別用env=dev、env=testing、env=production來標識開發、測試、生產的不同服務。規範描述了用戶期望Kubernetes集羣中的分佈式系統達到的理想狀態（Desired State），例如用戶可以通過複製控制器Replication Controller設置期望的Pod副本數爲3；status描述了系統實際當前達到的狀態（Status），例如系統當前實際的Pod副本數爲2；那麼複製控制器當前的程序邏輯就是自動啓動新的Pod，爭取達到副本數爲3。

Kubernetes中所有的配置都是通過API對象的spec去設置的，也就是用戶通過配置系統的理想狀態來改變系統，這是Kubernetes重要設計理念之一，即所有的操作都是聲明式（Declarative）的而不是命令式（Imperative）的。聲明式操作在分佈式系統中的好處是穩定，不怕丟操作或運行多次，例如設置副本數爲3的操作運行多次也還是一個結果，而給副本數加1的操作就不是聲明式的，運行多次結果就錯了。

Pod

Kubernetes有很多技術概念，同時對應很多API對象，最重要的也是最基礎的是Pod。Pod是在Kubernetes集羣中運行部署應用或服務的最小單元，它是可以支持多容器的。Pod的設計理念是支持多個容器在一個Pod中共享網絡地址和文件系統，可以通過進程間通信和文件共享這種簡單高效的方式組合完成服務。Pod對多容器的支持是K8最基礎的設計理念。比如你運行一個操作系統發行版的軟件倉庫，一個Nginx容器用來發布軟件，另一個容器專門用來從源倉庫做同步，這兩個容器的鏡像不太可能是一個團隊開發的，但是他們一塊兒工作才能提供一個微服務；這種情況下，不同的團隊各自開發構建自己的容器鏡像，在部署的時候組合成一個微服務對外提供服務。

Pod是Kubernetes集羣中所有業務類型的基礎，可以看作運行在Kubernetes集羣中的小機器人，不同類型的業務就需要不同類型的小機器人去執行。目前Kubernetes中的業務主要可以分爲長期伺服型（long-running）、批處理型（batch）、節點後臺支撐型（node-daemon）和有狀態應用型（stateful application）；分別對應的小機器人控制器爲Deployment、Job、DaemonSet和StatefulSet，本文後面會一一介紹。

副本控制器（Replication Controller，RC）

RC是Kubernetes集羣中最早的保證Pod高可用的API對象。通過監控運行中的Pod來保證集羣中運行指定數目的Pod副本。指定的數目可以是多個也可以是1個；少於指定數目，RC就會啓動運行新的Pod副本；多於指定數目，RC就會殺死多餘的Pod副本。即使在指定數目爲1的情況下，通過RC運行Pod也比直接運行Pod更明智，因爲RC也可以發揮它高可用的能力，保證永遠有1個Pod在運行。RC是Kubernetes較早期的技術概念，只適用於長期伺服型的業務類型，比如控制小機器人提供高可用的Web服務。

副本集（Replica Set，RS）

RS是新一代RC，提供同樣的高可用能力，區別主要在於RS後來居上，能支持更多種類的匹配模式。副本集對象一般不單獨使用，而是作爲Deployment的理想狀態參數使用。

部署（Deployment）

部署表示用戶對Kubernetes集羣的一次更新操作。部署是一個比RS應用模式更廣的API對象，可以是創建一個新的服務，更新一個新的服務，也可以是滾動升級一個服務。滾動升級一個服務，實際是創建一個新的RS，然後逐漸將新RS中副本數增加到理想狀態，將舊RS中的副本數減小到0的複合操作；這樣一個複合操作用一個RS是不太好描述的，所以用一個更通用的Deployment來描述。以Kubernetes的發展方向，未來對所有長期伺服型的的業務的管理，都會通過Deployment來管理。

服務（Service）

RC、RS和Deployment只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的問題。一個Pod只是一個運行服務的實例，隨時可能在一個節點上停止，在另一個節點以一個新的IP啓動一個新的Pod，因此不能以確定的IP和端口號提供服務。要穩定地提供服務需要服務發現和負載均衡能力。服務發現完成的工作，是針對客戶端訪問的服務，找到對應的的後端服務實例。在K8集羣中，客戶端需要訪問的服務就是Service對象。每個Service會對應一個集羣內部有效的虛擬IP，集羣內部通過虛擬IP訪問一個服務。在Kubernetes集羣中微服務的負載均衡是由Kube-proxy實現的。Kube-proxy是Kubernetes集羣內部的負載均衡器。它是一個分佈式代理服務器，在Kubernetes的每個節點上都有一個；這一設計體現了它的伸縮性優勢，需要訪問服務的節點越多，提供負載均衡能力的Kube-proxy就越多，高可用節點也隨之增多。與之相比，我們平時在服務器端做個反向代理做負載均衡，還要進一步解決反向代理的負載均衡和高可用問題。

任務（Job）

Job是Kubernetes用來控制批處理型任務的API對象。批處理業務與長期伺服業務的主要區別是批處理業務的運行有頭有尾，而長期伺服業務在用戶不停止的情況下永遠運行。Job管理的Pod根據用戶的設置把任務成功完成就自動退出了。成功完成的標誌根據不同的spec.completions策略而不同：單Pod型任務有一個Pod成功就標誌完成；定數成功型任務保證有N個任務全部成功；工作隊列型任務根據應用確認的全局成功而標誌成功。

後臺支撐服務集（DaemonSet）

長期伺服型和批處理型服務的核心在業務應用，可能有些節點運行多個同類業務的Pod，有些節點上又沒有這類Pod運行；而後臺支撐型服務的核心關注點在Kubernetes集羣中的節點（物理機或虛擬機），要保證每個節點上都有一個此類Pod運行。節點可能是所有集羣節點也可能是通過nodeSelector選定的一些特定節點。典型的後臺支撐型服務包括，存儲，日誌和監控等在每個節點上支持Kubernetes集羣運行的服務。

有狀態服務集（StatefulSet）

Kubernetes在1.3版本里發佈了Alpha版的PetSet功能，在1.5版本里將PetSet功能升級到了Beta版本，並重新命名爲StatefulSet，最終在1.9版本里成爲正式GA版本。在雲原生應用的體系裏，有下面兩組近義詞；第一組是無狀態（stateless）、牲畜（cattle）、無名（nameless）、可丟棄（disposable）；第二組是有狀態（stateful）、寵物（pet）、有名（having name）、不可丟棄（non-disposable）。RC和RS主要是控制提供無狀態服務的，其所控制的Pod的名字是隨機設置的，一個Pod出故障了就被丟棄掉，在另一個地方重啓一個新的Pod，名字變了。名字和啓動在哪兒都不重要，重要的只是Pod總數；而StatefulSet是用來控制有狀態服務，StatefulSet中的每個Pod的名字都是事先確定的，不能更改。StatefulSet中Pod的名字的作用，並不是《千與千尋》的人性原因，而是關聯與該Pod對應的狀態。

對於RC和RS中的Pod，一般不掛載存儲或者掛載共享存儲，保存的是所有Pod共享的狀態，Pod像牲畜一樣沒有分別（這似乎也確實意味着失去了人性特徵）；對於StatefulSet中的Pod，每個Pod掛載自己獨立的存儲，如果一個Pod出現故障，從其他節點啓動一個同樣名字的Pod，要掛載上原來Pod的存儲繼續以它的狀態提供服務。

適合於StatefulSet的業務包括數據庫服務MySQL和PostgreSQL，集羣化管理服務ZooKeeper、etcd等有狀態服務。StatefulSet的另一種典型應用場景是作爲一種比普通容器更穩定可靠的模擬虛擬機的機制。傳統的虛擬機正是一種有狀態的寵物，運維人員需要不斷地維護它，容器剛開始流行時，我們用容器來模擬虛擬機使用，所有狀態都保存在容器裏，而這已被證明是非常不安全、不可靠的。使用StatefulSet，Pod仍然可以通過漂移到不同節點提供高可用，而存儲也可以通過外掛的存儲來提供高可靠性，StatefulSet做的只是將確定的Pod與確定的存儲關聯起來保證狀態的連續性。

集羣聯邦（Federation）

Kubernetes在1.3版本里發佈了beta版的Federation功能。在雲計算環境中，服務的作用距離範圍從近到遠一般可以有：同主機（Host，Node）、跨主機同可用區（Available Zone）、跨可用區同地區（Region）、跨地區同服務商（Cloud Service Provider）、跨雲平臺。Kubernetes的設計定位是單一集羣在同一個地域內，因爲同一個地區的網絡性能才能滿足Kubernetes的調度和計算存儲連接要求。而聯合集羣服務就是爲提供跨Region跨服務商Kubernetes集羣服務而設計的。

每個Kubernetes Federation有自己的分佈式存儲、API Server和Controller Manager。用戶可以通過Federation的API Server註冊該Federation的成員Kubernetes Cluster。當用戶通過Federation的API Server創建、更改API對象時，Federation API Server會在自己所有註冊的子Kubernetes Cluster都創建一份對應的API對象。在提供業務請求服務時，Kubernetes Federation會先在自己的各個子Cluster之間做負載均衡，而對於發送到某個具體Kubernetes Cluster的業務請求，會依照這個Kubernetes Cluster獨立提供服務時一樣的調度模式去做Kubernetes Cluster內部的負載均衡。而Cluster之間的負載均衡是通過域名服務的負載均衡來實現的。

Federation V1的設計是儘量不影響Kubernetes Cluster現有的工作機制，這樣對於每個子Kubernetes集羣來說，並不需要更外層的有一個Kubernetes Federation，也就是意味着所有現有的Kubernetes代碼和機制不需要因爲Federation功能有任何變化。

目前正在開發的Federation V2，在保留現有Kubernetes API的同時，會開發新的Federation專用的API接口，詳細內容可以在這裏找到。

存儲卷（Volume）

Kubernetes集羣中的存儲卷跟Docker的存儲卷有些類似，只不過Docker的存儲卷作用範圍爲一個容器，而Kubernetes的存儲卷的生命週期和作用範圍是一個Pod。每個Pod中聲明的存儲卷由Pod中的所有容器共享。Kubernetes支持非常多的存儲卷類型，特別的，支持多種公有云平臺的存儲，包括AWS，Google和Azure雲；支持多種分佈式存儲包括GlusterFS和Ceph；也支持較容易使用的主機本地目錄emptyDir, hostPath和NFS。Kubernetes還支持使用Persistent Volume Claim即PVC這種邏輯存儲，使用這種存儲，使得存儲的使用者可以忽略後臺的實際存儲技術（例如AWS，Google或GlusterFS和Ceph），而將有關存儲實際技術的配置交給存儲管理員通過Persistent Volume來配置。

持久存儲卷（Persistent Volume，PV）和持久存儲卷聲明（Persistent Volume Claim，PVC）

PV和PVC使得Kubernetes集羣具備了存儲的邏輯抽象能力，使得在配置Pod的邏輯裏可以忽略對實際後臺存儲技術的配置，而把這項配置的工作交給PV的配置者，即集羣的管理者。存儲的PV和PVC的這種關係，跟計算的Node和Pod的關係是非常類似的；PV和Node是資源的提供者，根據集羣的基礎設施變化而變化，由Kubernetes集羣管理員配置；而PVC和Pod是資源的使用者，根據業務服務的需求變化而變化，有Kubernetes集羣的使用者即服務的管理員來配置。

節點（Node）

Kubernetes集羣中的計算能力由Node提供，最初Node稱爲服務節點Minion，後來改名爲Node。Kubernetes集羣中的Node也就等同於Mesos集羣中的Slave節點，是所有Pod運行所在的工作主機，可以是物理機也可以是虛擬機。不論是物理機還是虛擬機，工作主機的統一特徵是上面要運行kubelet管理節點上運行的容器。

密鑰對象（Secret）

Secret是用來保存和傳遞密碼、密鑰、認證憑證這些敏感信息的對象。使用Secret的好處是可以避免把敏感信息明文寫在配置文件裏。在Kubernetes集羣中配置和使用服務不可避免的要用到各種敏感信息實現登錄、認證等功能，例如訪問AWS存儲的用戶名密碼。爲了避免將類似的敏感信息明文寫在所有需要使用的配置文件中，可以將這些信息存入一個Secret對象，而在配置文件中通過Secret對象引用這些敏感信息。這種方式的好處包括：意圖明確，避免重複，減少暴漏機會。

用戶帳戶（User Account）和服務帳戶（Service Account）

顧名思義，用戶帳戶爲人提供賬戶標識，而服務賬戶爲計算機進程和Kubernetes集羣中運行的Pod提供賬戶標識。用戶帳戶和服務帳戶的一個區別是作用範圍；用戶帳戶對應的是人的身份，人的身份與服務的namespace無關，所以用戶賬戶是跨namespace的；而服務帳戶對應的是一個運行中程序的身份，與特定namespace是相關的。

命名空間（Namespace）

命名空間爲Kubernetes集羣提供虛擬的隔離作用，Kubernetes集羣初始有兩個命名空間，分別是默認命名空間default和系統命名空間kube-system，除此以外，管理員可以可以創建新的命名空間滿足需要。

RBAC訪問授權

Kubernetes在1.3版本中發佈了alpha版的基於角色的訪問控制（Role-based Access Control，RBAC）的授權模式。相對於基於屬性的訪問控制（Attribute-based Access Control，ABAC），RBAC主要是引入了角色（Role）和角色綁定（RoleBinding）的抽象概念。在ABAC中，Kubernetes集羣中的訪問策略只能跟用戶直接關聯；而在RBAC中，訪問策略可以跟某個角色關聯，具體的用戶在跟一個或多個角色相關聯。顯然，RBAC像其他新功能一樣，每次引入新功能，都會引入新的API對象，從而引入新的概念抽象，而這一新的概念抽象一定會使集羣服務管理和使用更容易擴展和重用。

總結

從Kubernetes的系統架構、技術概念和設計理念，我們可以看到Kubernetes系統最核心的兩個設計理念：一個是容錯性，一個是易擴展性。容錯性實際是保證Kubernetes系統穩定性和安全性的基礎，易擴展性是保證Kubernetes對變更友好，可以快速迭代增加新功能的基礎。

Pod概覽

理解Pod

Pod是kubernetes中你可以創建和部署的最小也是最簡的單位。Pod代表着集羣中運行的進程。

Pod中封裝着應用的容器（有的情況下是好幾個容器），存儲、獨立的網絡IP，管理容器如何運行的策略選項。Pod代表着部署的一個單位：kubernetes中應用的一個實例，可能由一個或者多個容器組合在一起共享資源。

Docker是kubernetes中最常用的容器運行時，但是Pod也支持其他容器運行時。

在Kubernetes集羣中Pod有如下兩種使用方式：

• 一個Pod中運行一個容器。“每個Pod中一個容器”的模式是最常見的用法；在這種使用方式中，你可以把Pod想象成是單個容器的封裝，kuberentes管理的是Pod而不是直接管理容器。

• 在一個Pod中同時運行多個容器。一個Pod中也可以同時封裝幾個需要緊密耦合互相協作的容器，它們之間共享資源。這些在同一個Pod中的容器可以互相協作成爲一個service單位——一個容器共享文件，另一個“sidecar”容器來更新這些文件。Pod將這些容器的存儲資源作爲一個實體來管理。

Kubernetes Blog 有關於Pod用例的詳細信息，查看：

• The Distributed System Toolkit: Patterns for Composite Containers

• Container Design Patterns

每個Pod都是應用的一個實例。如果你想平行擴展應用的話（運行多個實例），你應該運行多個Pod，每個Pod都是一個應用實例。在Kubernetes中，這通常被稱爲replication。

Pod中如何管理多個容器

Pod中可以同時運行多個進程（作爲容器運行）協同工作。同一個Pod中的容器會自動的分配到同一個 node 上。同一個Pod中的容器共享資源、網絡環境和依賴，它們總是被同時調度。

注意在一個Pod中同時運行多個容器是一種比較高級的用法。只有當你的容器需要緊密配合協作的時候才考慮用這種模式。例如，你有一個容器作爲web服務器運行，需要用到共享的volume，有另一個“sidecar”容器來從遠端獲取資源更新這些文件，如下圖所示：

圖片 - pod diagram

Pod中可以共享兩種資源：網絡和存儲。

網絡

每個Pod都會被分配一個唯一的IP地址。Pod中的所有容器共享網絡空間，包括IP地址和端口。Pod內部的容器可以使用localhost互相通信。Pod中的容器與外界通信時，必須分配共享網絡資源（例如使用宿主機的端口映射）。

存儲

可以爲一個Pod指定多個共享的Volume。Pod中的所有容器都可以訪問共享的volume。Volume也可以用來持久化Pod中的存儲資源，以防容器重啓後文件丟失。

使用Pod

你很少會直接在kubernetes中創建單個Pod。因爲Pod的生命週期是短暫的，用後即焚的實體。當Pod被創建後（不論是由你直接創建還是被其他Controller），都會被Kubernetes調度到集羣的Node上。直到Pod的進程終止、被刪掉、因爲缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。

注意：重啓Pod中的容器跟重啓Pod不是一回事。Pod只提供容器的運行環境並保持容器的運行狀態，重啓容器不會造成Pod重啓。

Pod不會自愈。如果Pod運行的Node故障，或者是調度器本身故障，這個Pod就會被刪除。同樣的，如果Pod所在Node缺少資源或者Pod處於維護狀態，Pod也會被驅逐。Kubernetes使用更高級的稱爲Controller的抽象層，來管理Pod實例。雖然可以直接使用Pod，但是在Kubernetes中通常是使用Controller來管理Pod的。

Pod和Controller

Controller可以創建和管理多個Pod，提供副本管理、滾動升級和集羣級別的自愈能力。例如，如果一個Node故障，Controller就能自動將該節點上的Pod調度到其他健康的Node上。

包含一個或者多個Pod的Controller示例：

• Deployment

• StatefulSet

• DaemonSet

通常，Controller會用你提供的Pod Template來創建相應的Pod。

Pod Templates

Pod模版是包含了其他object的Pod定義，例如Replication Controllers，Jobs和 DaemonSets。Controller根據Pod模板來創建實際的Pod。

Pod 的生命週期

Pod phase

Pod 的 status 字段是一個 PodStatus 對象，PodStatus中有一個 phase 字段。

Pod 的相位（phase）是 Pod 在其生命週期中的簡單宏觀概述。該階段並不是對容器或 Pod 的綜合彙總，也不是爲了做爲綜合狀態機。

Pod 相位的數量和含義是嚴格指定的。除了本文檔中列舉的狀態外，不應該再假定 Pod 有其他的 phase 值。

下面是 phase 可能的值：

• 掛起（Pending）：Pod 已被 Kubernetes 系統接受，但有一個或者多個容器鏡像尚未創建。等待時間包括調度 Pod 的時間和通過網絡下載鏡像的時間，這可能需要花點時間。

• 運行中（Running）：該 Pod 已經綁定到了一個節點上，Pod 中所有的容器都已被創建。至少有一個容器正在運行，或者正處於啓動或重啓狀態。

• 成功（Succeeded）：Pod 中的所有容器都被成功終止，並且不會再重啓。

• 失敗（Failed）：Pod 中的所有容器都已終止了，並且至少有一個容器是因爲失敗終止。也就是說，容器以非0狀態退出或者被系統終止。

• 未知（Unknown）：因爲某些原因無法取得 Pod 的狀態，通常是因爲與 Pod 所在主機通信失敗。

下圖是Pod的生命週期示意圖，從圖中可以看到Pod狀態的變化。

圖片 - Pod的生命週期示意圖（圖片來自網絡）

Pod 狀態

Pod 有一個 PodStatus 對象，其中包含一個 PodCondition 數組。 PodCondition 數組的每個元素都有一個 type 字段和一個 status 字段。type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized、Unschedulable和ContainersReady。status 字段是一個字符串，可能的值有 True、False 和 Unknown。

服務滾動升級

當有鏡像發佈新版本，新版本服務上線時如何實現服務的滾動和平滑升級？

如果你使用ReplicationController創建的pod可以使用kubectl rollingupdate命令滾動升級，如果使用的是Deployment創建的Pod可以直接修改yaml文件後執行kubectl apply即可。

Deployment已經內置了RollingUpdate strategy，因此不用再調用kubectl rollingupdate命令，升級的過程是先創建新版的pod將流量導入到新pod上後銷燬原來的舊的pod。

Rolling Update適用於Deployment、Replication Controller，官方推薦使用Deployment而不再使用Replication Controller。

使用ReplicationController時的滾動升級請參考官網說明：https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/

ReplicationController與Deployment的關係

ReplicationController和Deployment的RollingUpdate命令有些不同，但是實現的機制是一樣的，關於這兩個kind的關係我引用了ReplicationController與Deployment的區別中的部分內容如下，詳細區別請查看原文。

ReplicationController

Replication Controller爲Kubernetes的一個核心內容，應用託管到Kubernetes之後，需要保證應用能夠持續的運行，Replication Controller就是這個保證的key，主要的功能如下：

• 確保pod數量：它會確保Kubernetes中有指定數量的Pod在運行。如果少於指定數量的pod，Replication Controller會創建新的，反之則會刪除掉多餘的以保證Pod數量不變。

• 確保pod健康：當pod不健康，運行出錯或者無法提供服務時，Replication Controller也會殺死不健康的pod，重新創建新的。

• 彈性伸縮 ：在業務高峯或者低峯期的時候，可以通過Replication Controller動態的調整pod的數量來提高資源的利用率。同時，配置相應的監控功能（Hroizontal Pod Autoscaler），會定時自動從監控平臺獲取Replication Controller關聯pod的整體資源使用情況，做到自動伸縮。

• 滾動升級：滾動升級爲一種平滑的升級方式，通過逐步替換的策略，保證整體系統的穩定，在初始化升級的時候就可以及時發現和解決問題，避免問題不斷擴大。

Deployment

Deployment同樣爲Kubernetes的一個核心內容，主要職責同樣是爲了保證pod的數量和健康，90%的功能與Replication Controller完全一樣，可以看做新一代的Replication Controller。但是，它又具備了Replication Controller之外的新特性：

• Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能。

• 事件和狀態查看：可以查看Deployment的升級詳細進度和狀態。

• 回滾：當升級pod鏡像或者相關參數的時候發現問題，可以使用回滾操作回滾到上一個穩定的版本或者指定的版本。

• 版本記錄: 每一次對Deployment的操作，都能保存下來，給予後續可能的回滾使用。

• 暫停和啓動：對於每一次升級，都能夠隨時暫停和啓動。

• 多種升級方案：Recreate：刪除所有已存在的pod,重新創建新的; RollingUpdate：滾動升級，逐步替換的策略，同時滾動升級時，支持更多的附加參數，例如設置最大不可用pod數量，最小升級間隔時間等等。