一、簡介

　　kubernetes是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

　　Kubernetes一個核心的特點就是能夠自主的管理容器來保證雲平臺中的容器按照使用者的期望狀態執行著（比如使用者想讓apache一直執行，使用者不需要關心怎麼去做，Kubernetes會自動去監控，然後去重啟，新建，總之，讓apache一直提供服務），管理員可以載入一個微型服務，讓規劃器來找到合適的位置，同時，Kubernetes也系統提升工具以及人性化方面，讓使用者能夠方便的部署自己的應用（就像canary deployments）。

二、設計架構

　　Kubernetes叢集包含有節點代理kubelet和Master元件(APIs, scheduler, etc)，一切都基於分散式的儲存系統。下面這張圖是Kubernetes的架構圖。

kuberrnetes節點

　　在這張系統架構圖中，我們把服務分為執行在工作節點上的服務和組成叢集級別控制板的服務。

　　Kubernetes節點有執行應用容器必備的服務，而這些都是受Master的控制。

　　每次個節點上當然都要執行Docker。Docker來負責所有具體的映像下載和容器執行。

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

• etcd儲存了整個叢集的狀態；
• apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
• controller manager負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等；
• scheduler負責資源的排程，按照預定的排程策略將Pod排程到相應的機器上；
• kubelet負責維護容器的生命週期，同時也負責Volume（CVI）和網路（CNI）的管理；
• Container runtime負責映象管理以及Pod和容器的真正執行（CRI）；
• kube-proxy負責為Service提供cluster內部的服務發現和負載均衡；

　　除了核心元件，還有一些推薦的Add-ons：

• kube-dns負責為整個叢集提供DNS服務
• Ingress Controller為服務提供外網入口
• Heapster提供資源監控
• Dashboard提供GUI
• Federation提供跨可用區的叢集
• Fluentd-elasticsearch提供叢集日誌採集、儲存與查詢

三、kubernetes的基本概念和API物件

API物件是K8s叢集中的管理操作單元。K8s集群系統每支援一項新功能，引入一項新技術，一定會新引入對應的API物件，支援對該功能的管理操作。例如副本集Replica Set對應的API物件是RS。

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

K8s中所有的配置都是通過API物件的spec去設定的，也就是使用者通過配置系統的理想狀態來改變系統，這是k8s重要設計理念之一，即所有的操作都是宣告式（Declarative）的而不是命令式（Imperative）的。宣告式操作在分散式系統中的好處是穩定，不怕丟操作或執行多次，例如設定副本數為3的操作執行多次也還是一個結果，而給副本數加1的操作就不是宣告式的，執行多次結果就錯了。

Pod

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

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

複製控制器（Replication Controller，RC）

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

副本集（Replica Set，RS）

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

部署(Deployment)

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

服務（Service）

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

任務（Job）

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

後臺支撐服務集（DaemonSet）

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

有狀態服務集（PetSet）

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

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

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

叢集聯邦（Federation）

K8s在1.3版本里釋出了beta版的Federation功能。在雲端計算環境中，服務的作用距離範圍從近到遠一般可以有：同主機（Host，Node）、跨主機同可用區（Available Zone）、跨可用區同地區（Region）、跨地區同服務商（Cloud Service Provider）、跨雲平臺。K8s的設計定位是單一叢集在同一個地域內，因為同一個地區的網路效能才能滿足K8s的排程和計算儲存連線要求。而聯合叢集服務就是為提供跨Region跨服務商K8s叢集服務而設計的。

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

所有的設計都儘量不影響K8s Cluster現有的工作機制，這樣對於每個子K8s叢集來說，並不需要更外層的有一個K8s Federation，也就是意味著所有現有的K8s程式碼和機制不需要因為Federation功能有任何變化。

儲存卷（Volume）

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

持久儲存卷（Persistent Volume，PV）和持久儲存卷宣告（Persistent Volume Claim，PVC）

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

節點（Node）

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

金鑰物件（Secret）

Secret是用來儲存和傳遞密碼、金鑰、認證憑證這些敏感資訊的物件。使用Secret的好處是可以避免把敏感資訊明文寫在配置檔案裡。在K8s叢集中配置和使用服務不可避免的要用到各種敏感資訊實現登入、認證等功能，例如訪問AWS儲存的使用者名稱密碼。為了避免將類似的敏感資訊明文寫在所有需要使用的配置檔案中，可以將這些資訊存入一個Secret物件，而在配置檔案中通過Secret物件引用這些敏感資訊。這種方式的好處包括：意圖明確，避免重複，減少暴漏機會。

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

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

名字空間（Namespace）

名字空間為K8s叢集提供虛擬的隔離作用，K8s叢集初始有兩個名字空間，分別是預設名字空間default和系統名字空間kube-system，除此以外，管理員可以可以建立新的名字空間滿足需要。

RBAC訪問授權

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

五、核心技術概念簡介

1、pod

　　一個Pod（就像一群鯨魚，或者一個豌豆夾）相當於一個共享context的配置組，在同一個context下，應用可能還會有獨立的cgroup隔離機制，一個Pod是一個容器環境下的“邏輯主機”，它可能包含一個或者多個緊密相連的應用，這些應用可能是在同一個物理主機或虛擬機器上。

　　Pod 的context可以理解成多個linux名稱空間的聯合

• PID 名稱空間（同一個Pod中應用可以看到其它程序）
• 網路 名稱空間（同一個Pod的中的應用對相同的IP地址和埠有許可權）
• IPC 名稱空間（同一個Pod中的應用可以通過VPC或者POSIX進行通訊）
• UTS 名稱空間（同一個Pod中的應用共享一個主機名稱）

　　同一個Pod中的應用可以共享磁碟，磁碟是Pod級的，應用可以通過檔案系統呼叫，額外的，一個Pod可能會定義頂級的cgroup隔離，這樣的話繫結到任何一個應用（好吧，這句是在沒怎麼看懂，就是說Pod，應用，隔離）

　　由於docker的架構，一個Pod是由多個相關的並且共享磁碟的容器組成，Pid的名稱空間共享還沒有應用到Docker中和相互獨立的容器一樣，Pod是一種相對短暫的存在，而不是持久存在的，正如我們在Pod的生命週期中提到的，Pod被安排到結點上，並且保持在這個節點上直到被終止（根據重啟的設定）或者被刪除，當一個節點死掉之後，上面的所有Pod均會被刪除。特殊的Pod永遠不會被轉移到的其他的節點，作為替代，他們必須被replace.

2、labels（標籤）

　　標籤其實就一對 key/value ，被關聯到物件上，比如Pod,標籤的使用我們傾向於能夠標示物件的特殊特點，並且對使用者而言是有意義的（就是一眼就看出了這個Pod是尼瑪資料庫），但是標籤對核心系統是沒有直接意義的。標籤可以用來劃分特定組的物件（比如，所有女的），標籤可以在建立一個物件的時候直接給與，也可以在後期隨時修改，每一個物件可以擁有多個標籤，但是，key值必須是唯一的。

3、namespace（名稱空間）

　　Namespace是對一組資源和物件的抽象集合，比如可以用來將系統內部的物件劃分為不同的專案組或使用者組。常見的pods, services, replication controllers和deployments等都是屬於某一個namespace的（預設是default），而node, persistentVolumes等則不屬於任何namespace。

　　Namespace常用來隔離不同的使用者，比如Kubernetes自帶的服務一般執行在kube-system namespace中。

4、replication controller

　　Replication Controller 保證了在所有時間內，都有特定數量的Pod副本正在執行，如果太多了，Replication Controller就殺死幾個，如果太少了，Replication Controller會新建幾個，和直接建立的pod不同的是，Replication Controller會替換掉那些刪除的或者被終止的pod，不管刪除的原因是什麼（維護阿，更新啊，Replication Controller都不關心）。基於這個理由，我們建議即使是隻建立一個pod，我們也要使用Replication Controller。Replication Controller 就像一個程序管理器，監管著不同node上的多個pod,而不是單單監控一個node上的pod,Replication Controller 會委派本地容器來啟動一些節點上服務（Kubelet ,Docker）。

　　正如我們在pod的生命週期中討論的，Replication Controller只會對那些RestartPolicy = Always的Pod的生效，（RestartPolicy的預設值就是Always）,Replication Controller 不會去管理那些有不同啟動策略pod如我們在issue #503討論的，我們希望在將來別的控制器被加入到Kubernete中來管理一些例如負載阿，測試等相關功能。

　　Replication Controller永遠不會自己關閉，但是，我們並不希望Replication Controller成為一個長久存在的服務。服務可能會有多個Pod組成，這些Pod又被多個Replication Controller控制著，我們希望Replication Controller 會在服務的生命週期中被刪除和新建（例如在這些pod中釋出一個更新），對於服務和使用者來說，Replication Controller是通過一種無形的方式來維持著服務的狀態。

5、node

　　Node是Pod真正執行的主機，可以物理機，也可以是虛擬機器。為了管理Pod，每個Node節點上至少要執行container runtime（比如docker或者rkt）、kubelet和kube-proxy服務。

6、replicaset

　　ReplicaSet是下一代複本控制器。ReplicaSet和 Replication Controller之間的唯一區別是現在的選擇器支援。Replication Controller只支援基於等式的selector（env=dev或environment!=qa），但ReplicaSet還支援新的，基於集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。在試用時官方推薦ReplicaSet。

　　大多數kubectl支援Replication Controller的命令也支援ReplicaSets。rolling-update命令有一個例外 。如果您想要滾動更新功能，請考慮使用Deployments。此外， rolling-update命令是必須的，而Deployments是宣告式的，因此我們建議通過rollout命令使用Deployments。

　　雖然ReplicaSets可以獨立使用，但是今天它主要被 Deployments 作為協調pod建立，刪除和更新的機制。當您使用Deployments時，您不必擔心管理他們建立的ReplicaSets。Deployments擁有並管理其ReplicaSets。

7、service

　　Kubernetes Pod是平凡的，它門會被建立，也會死掉（生老病死），並且他們是不可復活的。 ReplicationControllers動態的建立和銷燬Pods(比如規模擴大或者縮小，或者執行動態更新)。每個pod都由自己的ip，這些IP也隨著時間的變化也不能持續依賴。這樣就引發了一個問題：如果一些Pods（讓我們叫它作後臺，後端）提供了一些功能供其它的Pod使用（讓我們叫作前臺），在kubernete叢集中是如何實現讓這些前臺能夠持續的追蹤到這些後臺的？

答案是：Service

　　Kubernete Service 是一個定義了一組Pod的策略的抽象，我們也有時候叫做巨集觀服務。這些被服務標記的Pod都是（一般）通過label Selector決定的（下面我們會講到我們為什麼需要一個沒有label selector的服務）。舉個例子，我們假設後臺是一個圖形處理的後臺，並且由3個副本。這些副本是可以相互替代的，並且前臺不需要關心使用的哪一個後臺Pod，當這個承載前臺請求的pod發生變化時，前臺並不需要知道這些變化，或者追蹤後臺的這些副本，服務是這些pod的集合。

　　對於Kubernete原生的應用，Kubernete提供了一個簡單的Endpoints API，這個Endpoints api的作用就是當一個服務中的pod發生變化時，Endpoints API隨之變化，對於哪些不是原生的程式，Kubernetes提供了一個基於虛擬IP的網橋的服務，這個服務會將請求轉發到對應的後臺pod。

8、volume

　　容器中的磁碟的生命週期是短暫的，這就帶來了一系列的問題，第一，當一個容器損壞之後，kubelet 會重啟這個容器，但是檔案會丟失-這個容器會是一個全新的狀態，第二，當很多容器在同一Pod中執行的時候，很多時候需要資料檔案的共享。Kubernete Volume解決了這個問題。

9、pv&pvc&storageclass

　　PersistentVolume（PV）是叢集中已由管理員配置的一段網路儲存。 叢集中的資源就像一個節點是一個叢集資源。 PV是諸如卷之類的卷外掛，但是具有獨立於使用PV的任何單個pod的生命週期。 該API物件捕獲儲存的實現細節，即NFS，iSCSI或雲提供商特定的儲存系統。
　　PersistentVolumeClaim（PVC）是使用者儲存的請求。 它類似於pod。 Pod消耗節點資源，PVC消耗光伏資源。 莢可以請求特定級別的資源（CPU和記憶體）。 權利要求可以請求特定的大小和訪問模式（例如，可以一旦讀/寫或只讀許多次安裝）。
　　雖然PersistentVolumeClaims允許使用者使用抽象儲存資源，但是常見的是，使用者需要具有不同屬性（如效能）的PersistentVolumes，用於不同的問題。 群集管理員需要能夠提供多種不同於PersistentVolumes的PersistentVolumes，而不僅僅是大小和訪問模式，而不會使使用者瞭解這些卷的實現細節。 對於這些需求，存在StorageClass資源。

　　StorageClass為管理員提供了一種描述他們提供的儲存的“類”的方法。 不同的類可能對映到服務質量級別，或備份策略，或者由群集管理員確定的任意策略。 Kubernetes本身對於什麼類別代表是不言而喻的。 這個概念有時在其他儲存系統中稱為“配置檔案”。

10、deployment

　　Deployment為Pod和Replica Set（下一代Replication Controller）提供宣告式更新。

　　你只需要在Deployment中描述你想要的目標狀態是什麼，Deployment controller就會幫你將Pod和Replica Set的實際狀態改變到你的目標狀態。你可以定義一個全新的Deployment，也可以建立一個新的替換舊的Deployment。

　　一個典型的用例如下：

• 使用Deployment來建立ReplicaSet。ReplicaSet在後臺建立pod。檢查啟動狀態，看它是成功還是失敗。
• 然後，通過更新Deployment的PodTemplateSpec欄位來宣告Pod的新狀態。這會建立一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
• 如果當前狀態不穩定，回滾到之前的Deployment revision。每次回滾都會更新Deployment的revision。
• 擴容Deployment以滿足更高的負載。
• 暫停Deployment來應用PodTemplateSpec的多個修復，然後恢復上線。
• 根據Deployment 的狀態判斷上線是否hang住了。
• 清除舊的不必要的ReplicaSet。

11、statefulset

　　StatefulSet是為了解決有狀態服務的問題（對應Deployments和ReplicaSets是為無狀態服務而設計），其應用場景包括

• 穩定的持久化儲存，即Pod重新排程後還是能訪問到相同的持久化資料，基於PVC來實現
• 穩定的網路標誌，即Pod重新排程後其PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現
• 有序部署，有序擴充套件，即Pod是有順序的，在部署或者擴充套件的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod執行之前所有之前的Pod必須都是Running和Ready狀態），基於init containers來實現
• 有序收縮，有序刪除（即從N-1到0）

　　從上面的應用場景可以發現，StatefulSet由以下幾個部分組成：

• 用於定義網路標誌（DNS domain）的Headless Service
• 用於建立PersistentVolumes的volumeClaimTemplates
• 定義具體應用的StatefulSet

　　StatefulSet中每個Pod的DNS格式為statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local，其中

• serviceName為Headless Service的名字
• 0..N-1為Pod所在的序號，從0開始到N-1
• statefulSetName為StatefulSet的名字
• namespace為服務所在的namespace，Headless Servic和StatefulSet必須在相同的namespace
• .cluster.local為Cluster Domain，

12、daemonset

　　DaemonSet保證在每個Node上都執行一個容器副本，常用來部署一些叢集的日誌、監控或者其他系統管理應用。典型的應用包括：

• 日誌收集，比如fluentd，logstash等
• 系統監控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
• 系統程式，比如kube-proxy, kube-dns, glusterd, ceph等

13、job

　　Job負責批量處理短暫的一次性任務 (short lived one-off tasks)，即僅執行一次的任務，它保證批處理任務的一個或多個Pod成功結束。

　　Kubernetes支援以下幾種Job：

• 非並行Job：通常建立一個Pod直至其成功結束
• 固定結束次數的Job：設定.spec.completions，建立多個Pod，直到.spec.completions個Pod成功結束
• 帶有工作佇列的並行Job：設定.spec.Parallelism但不設定.spec.completions，當所有Pod結束並且至少一個成功時，Job就認為是成功

　　根據.spec.completions和.spec.Parallelism的設定，可以將Job劃分為以下幾種pattern：

14、ingress

　　通常情況下，service和pod的IP僅可在叢集內部訪問（四層）。叢集外部的請求需要通過負載均衡轉發到service在Node上暴露的NodePort上，然後再由kube-proxy將其轉發給相關的Pod。

而Ingress就是為進入叢集的請求提供路由規則的集合（七層）。

　　Ingress可以給service提供叢集外部訪問的URL、負載均衡、SSL終止、HTTP路由等。為了配置這些Ingress規則，叢集管理員需要部署一個Ingress controller，它監聽Ingress和service的變化，並根據規則配置負載均衡並提供訪問入口。

Ingress可以給service提供叢集外部訪問的URL、負載均衡、SSL終止、HTTP路由等。為了配置這些Ingress規則，叢集管理員需要部署一個Ingress controller，它監聽Ingress和service的變化，並根據規則配置負載均衡並提供訪問入口。