初識 kubernetes

1、簡介

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

　　Kubernetes一個核心的特色就是可以自主的管理容器來保證雲平臺中的容器按照用戶的指望狀態運行着（好比用戶想讓apache一直運行，用戶不須要關心怎麼去作，Kubernetes會自動去監控，而後去重啓，新建，總之，讓apache一直提供服務），管理員能夠加載一個微型服務，讓規劃器來找到合適的位置，同時，Kubernetes也系統提高工具以及人性化方面，讓用戶可以方便的部署本身的應用（就像canary deployments）。

2、設計架構

　　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提供集羣日誌採集、存儲與查詢

 

 

3、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對象，從而引入新的概念抽象，而這一新的概念抽象必定會使集羣服務管理和使用更容易擴展和重用。

 

5、核心技術概念簡介

一、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.

二、labels（標籤）

　　標籤其實就一對 key/value ，被關聯到對象上，好比Pod,標籤的使用咱們傾向於可以標示對象的特殊特色，而且對用戶而言是有意義的（就是一眼就看出了這個Pod是尼瑪數據庫），可是標籤對內核系統是沒有直接意義的。標籤能夠用來劃分特定組的對象（好比，全部女的），標籤能夠在建立一個對象的時候直接給與，也能夠在後期隨時修改，每個對象能夠擁有多個標籤，可是，key值必須是惟一的。

三、namespace（名稱空間）

　　Namespace是對一組資源和對象的抽象集合，好比能夠用來將系統內部的對象劃分爲不一樣的項目組或用戶組。常見的pods, services, replication controllers和deployments等都是屬於某一個namespace的（默認是default），而node, persistentVolumes等則不屬於任何namespace。

　　Namespace經常使用來隔離不一樣的用戶，好比Kubernetes自帶的服務通常運行在kube-system namespace中。

四、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是經過一種無形的方式來維持着服務的狀態。

五、node

　　Node是Pod真正運行的主機，能夠物理機，也能夠是虛擬機。爲了管理Pod，每一個Node節點上至少要運行container runtime（好比docker或者rkt）、kubelet和kube-proxy服務。

六、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。

七、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。

八、volume

　　容器中的磁盤的生命週期是短暫的，這就帶來了一系列的問題，第一，當一個容器損壞以後，kubelet 會重啓這個容器，可是文件會丟失-這個容器會是一個全新的狀態，第二，當不少容器在同一Pod中運行的時候，不少時候須要數據文件的共享。Kubernete Volume解決了這個問題。

九、pv&pvc&storageclass

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

　　StorageClass爲管理員提供了一種描述他們提供的存儲的「類」的方法。 不一樣的類可能映射到服務質量級別，或備份策略，或者由羣集管理員肯定的任意策略。 Kubernetes自己對於什麼類別表明是不言而喻的。 這個概念有時在其餘存儲系統中稱爲「配置文件」。

十、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。

十一、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，

十二、daemonset

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

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

1三、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：

Job類型	使用示例	行爲	completions	Parallelism
一次性Job	數據庫遷移	建立一個Pod直至其成功結束	1	1
固定結束次數的Job	處理工做隊列的Pod	依次建立一個Pod運行直至completions個成功結束	2+	1
固定結束次數的並行Job	多個Pod同時處理工做隊列	依次建立多個Pod運行直至completions個成功結束	2+	2+
並行Job	多個Pod同時處理工做隊列	建立一個或多個Pod直至有一個成功結束	1	2+

 

 

1四、ingress

　　一般狀況下，service和pod的IP僅可在集羣內部訪問（四層）。集羣外部的請求須要經過負載均衡轉發到service在Node上暴露的NodePort上，而後再由kube-proxy將其轉發給相關的Pod。

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

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