五個熱愛Kubernetes的原因（下）_Kubernetes中文社群
在上一篇文章裡，我講述了讓我熱愛Kubernetes前5個理由（上）。2015年7月Kubernetes被捐贈給Cloud Native Computing Foundation，並開始接受數十個包括Canonical，CoreOS，Red Hat等公司的開發。
我的前五個理由主要來自Kubernetes專案的歷史、易於使用的特點和強大的功能。後面的五個理由將更”乾貨“。在上篇文章裡提到：選擇一個要在資料中心中執行任務的分散式系統不像是在一個電子表格裡尋找效能或特徵那樣簡單。你應該按照團隊的需求靈活決定。然而要注意，我所說的這個十個理由是我的觀點，並且我正以此使用、測試和開發系統。
6. 滾動升級和回滾
滾動升級和回滾對於應用管理來說毫無疑問是必需品，尤其是當我們擁抱快速迭代的開發週期和持續改進的時候。一個擁有這些特性的系統，它的設計和執行往往很複雜。
部署資源在Kubernetes裡被重新定義–起初Kubernetes擁有Replication Controller(RC)，它定義了Pods的宣告式狀態–例如哪個容器、我在我的系統裡想要多少個容器等。但是通過RC實現的滾動升級發生在客戶端，客戶端關閉經常會導致錯誤。
所以，Kubernetes引入了Deployment這個資源，使用Replica Sets（多種資源重新命名中的一部分）替換掉了Replication Controllers。每次一個deployment被使用者定義之後，系統就會建立一個新replica set。對replica set的擴容和縮容造就了滾動升級和回滾的能力。確實，舊的replica set並沒有被除，而是保留在系統中，作為Deployment歷史的一部分。
Deployment的擴容和部署策略可以在顯式的定義中進行修改。
這些所有的功能，都是被一個基於REST API的HTTP請求觸發。
讓我們看看一個簡單的deployment歷史：
$ kubectl rollout history deploymetn ghost deployments "ghost": REVISION CHANGE-CAUSE 1 kubectl run ghost --image=ghost --record 2 kubectl edit deployment/ghost
這裡演示一下升級。我們可以通過`rollout undo`來進行回滾。它將增加歷史中的修訂（Revise）
$ kubectl rollout undo deployment ghost deployment "ghost" rolled back $ kubectl rollout history deployment ghost deployments "ghost": REVISION CHANGE-CAUSE 2 kubectl edit deployment/ghost 3 kubectl run ghost --image=ghost --record
底下的一行經過編輯一個Deployment，你執行了滾動升級。回滾是一個rollout undo，嗯，是這樣，你可以回滾到一個特定的版本。
7. 配額
開源世界裡過去的15年湧現了大量的業務模型（及變體），它們其中有些一直是某個商業元件（外掛）的形式出現。
在Kubernetes裡內建了配額。它們可以被用來限制API資源的數量，或限制例如CPU和記憶體的物理資源的使用。與Pods和Deployments相似，配額也是K8s裡的API資源。你可以通過yaml或json檔案進行定義，並且在你的叢集裡利用kubectl進行建立。
例如，為了限制在一個特定名稱空間裡Pods的數量為1，你可以定義如下的資源配額：
apiVersion: v1kind: ResourceQuotametadata: name: object-counts namespace: defaultspec: hard: pods: "1"
就像對其他資源一樣，你可以通過kubectl get和 kubectl edit通過下面的兩條命令檢視和修改配額:
$ kubectl get resourcequota NAME AGE object-counts 15s
現在是單Pod執行，如果這時你繼續建立新的Pod，K8s就會返回一個錯誤，告訴你超過了配額：
$ kubectl create -f redis.yaml Error from server: error when creating "redis.yaml": pods "redis"
配額是內建的一級K8s API。這真令人驚奇!
8. 第三方資源
這在大多數系統中是一個難以理解的新概念。
Kubernetes的設計哲學是它包含了一組用來管理容器化應用的API。可以預料到，在一段時間內這個核心將相對穩定。使用者可能使用到的任何另外的API資源可能不會被加入到核心中，而是會被動態地建立。Kubernetes將管理它們，並客戶端將動態地使用它們。這個技術曾被Pearson用來管理資料庫。
這個例子我在LinuxCon上講過，用來建立一個叫做pinguin的新的API物件。你可以通過第三方資源物件（ThirdParty Resource Object）進行建立。就像其他的K8s資源一樣，它同樣擁有metadata、apiversion、kind和一組versions的屬性。metadata包含了一個用來定義新的資源組的名字：
metadata:
name: pin-guin.k8s.linuxcon.comapiVersion: extensions/v1beta1kind: ThirdPartyResourcedescription: “A crazy pinguin at Linuxcon”versions:- name: v1
讓我們建立這個新資源：
$ kubectl create -f pinguins.yml $ kubectl get thirdpartyresources NAME DESCRIPTION VERSION(S) pin-guin.k8s.linuxcon.com A crazy pinguin at Linuxcon v1
通過這種方式，你可以自由地建立一個pinguin（保持LinuxCon主題）：
$ cat pinguins.yml apiVersion: k8s.linuxcon.com/v1 kind: PinGuin metadata: name: crazy labels: linuxcon: rocks $ kubectl create -f pinguin.yml
並且動態地，kubectl現在意識到了你建立的pinguin。注意這個特性僅在k8s:v1.4.0中可用。
$ kubeclt get pinguin
NAME LABELS DATA
crazy linuxcon=rocks {"apiVersion":"k8s.linuxcon.com/v1", "kind":"PinGui...
現在你可以想象能用它做點什麼了，結果是你需要編寫一個控制器，用一段程式碼來監控pinguins，當它被建立、刪除或修改時做出某些動作。
這個特性意味著Kubernetes的API Server現在可以被每個使用者任意地進行擴充套件，棒呆了！
9. 基於角色的訪問控制（RBAC)
除了配額之外，基於角色的訪問控制也是一個企業級系統的必須。類似於配額，在資料中心解決方案裡，它通常是一個經過考慮之後的想法，而不是一個商業元件。
對於Kubernetes，我們擁有細粒度的訪問控制，它基於角色，並且最好的部分當然是，100%的API驅動。通過這個，我意思是角色和繫結都是API資源了，管理員可以在叢集上編寫和建立這些資源，就像使用者建立Pods和Deployments一樣。
它最初在v1.3.0版本里引入，它是一個alpha版本的API，仍被認為是實驗的。但是多個釋出版之後，我完全認為它是穩定的API了。
大致來說，你建立角色——API資源型別role，定義一些規則：
kind: RoleapiVersion: rbac.authorization.k8s.io/v1alpha1metadata: namespace: default name: pod-readerrules: - apiGroups: ["api/v1"] resource: ["pods"] verbs: ["get", "watch", "list"] nonResourceURLs: []
然後你將使用者和角色進行關聯，通過建立繫結資源RoleBinding完成。一個繫結，就是一組使用者，將他們和角色結合。一旦你建立了繫結，系統任何使用者都會繼承來自這個角色的訪問規則。
kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1alpha1metadata: name: admin namespace: defaultsubjects: - kind: ServiceAccount name: defaultroleRef: kind: Role namespace: default name: admin apiVersion: rbac.authoziation.k8s.io/v1alpha1
對於這點，來自CoreOS的Eric Chiang有段非常精彩的視訊。 內建RBAC，完全API驅動，簡直了！
10. 叢集聯邦
最後但不是唯一的是叢集聯邦。 回到Borg論文裡，我們熱愛Kubernetes的第一個原因，你可能已經注意到了一個單獨的K8s叢集實際上等價於單個Borg的“Cell”，或者可用域。現在在Kubernetes 1.4.0裡，已經擁有了將多個叢集聯邦起來並通過一個控制檯進行管理的功能。這意味著我們擁有了Borg lite。
這是熱愛Kubernetes的一個關鍵原因，因為它帶來了混合容器雲的解決方案。想象一下，擁有K8s叢集前置和一個公有云（例如：AWS，GKE，Azure)。通過這個聯邦控制檯，你可以執行跨多個叢集的微服務。擴容會自動平衡叢集間的副本，並且提供一個單獨的DNS端點，同時負載均衡也是聯邦的。
這個讓我非常激動，因為我們應該可以更快地在已有的叢集和公有云上進行應用的遷移。是，你聽對了，這全部都是內建的，而不是商業元件。
開始聯邦吧，Kelsey Hightower寫了一篇非常詳細的教程，值得一試。
其它
以上就是我熱愛Kubernetes的前十個原因。我非常確定別人也有其他的原因，這個系統的可以熱愛的地方太多了。我一直使用、測試和開發資料中心解決方案，我感覺到Kubernetes是一個經過深度考慮的系統，它極其穩定，可擴充套件，和擁有一些我們本以為會是商業元件的關鍵特性。Kubernetes真的改變了遊戲。