摘要：的核心是以容器為中心的管理環境。命名空間提供了名稱范圍。換句話說，確保或同類組始終可用。用于管理有狀態應用程序，它管理一組的部署和擴展，并提供有關這些的排序和唯一性的保證。

條分縷析帶你充分理解Kubernetes的各個細節與部分：它是什么，它如何解決容器編排問題，它包含哪些你必須掌握的關鍵對象，以及如何快速上手部署使用Kubernetes。

容器的好處不勝枚舉：一致的運行時環境、節省磁盤空間、低開銷、良好的隔離性，等等。了解完這些優勢，您以及您的同事可能都開始躍躍欲試要把應用程序打包到容器中并準備運行它。然后突然之間或許您會發現，容器運行起來之后有一些問題也接踵而來，您需要一種方法來管理所有正在運行的容器及其生命周期：它們如何相互連接，它們應該運行在什么硬件之上，它們如何獲取數據存儲，容器因各種原因停止運行的話您該如何處理錯誤······

這就是Kubernetes大顯身手的地方了。

在本文中，我們將了解Kubernetes是什么，它如何解決容器編排問題，它背后是由哪些理論支撐，如何將該理論直接與實際操作綁定，最終幫助您充分理解Kubernetes的各個細節與部分。

Kubernetes: 歷史

Kubernetes，也被稱為k8s（k... 8個字母...和s）或kube，是希臘語中的單詞，意為州長、舵手或船長。拿真正的航海的情景來理解，大型船舶裝載著大量現實生活的容器，而船長或舵手則是負責船舶的人。因此，在信息技術的語境下，Kubernetes就是Docker容器的船長、編排者。

Kubernetes最初是谷歌公司在內部使用的，基于谷歌運行容器15年的經驗，Kubernetes于2014年開始作為Google的開源項目提供給社區。四年過去，Kubernetes飛速發展，下載及使用量驚人，被大量的中小型企業用戶用于開發或生產環境，并已成為業界公認的容器編排管理的標準框架。

Kubernetes的發展勢頭

Kubernetes的增長態勢驚人，在GitHub上擁有超過40,000顆星，在2018年擁有超過60,000個commit，并且比GitHub上的任何其他項目都有更多的pull request和issue。其增長背后的部分原因是其不凡的可擴展性和強大的設計模式，這些我們將在后文中進一步解讀。您可以在此鏈接了解一些大型軟件公司的Kubernetes應用案例：

https://kubernetes.io/case-st...

Kubernetes提供的服務

讓我們來看看是什么功能及特性讓Kubernetes吸引到業界的如此關注。

Kubernetes的核心是以容器為中心的管理環境。它代表用戶的工作負載來編排計算、網絡和存儲基礎架構。這提供了平臺即服務（PaaS）的簡單性和基礎架構即服務（IaaS）的靈活性，并實現了跨基礎架構提供商的可移植性。Kubernetes不僅僅是一個編排系統。實際上，它讓用戶不再需要“編排”。“編排”的技術定義是“執行定義的工作流程”：首先執行A，然后運行B，然后運行C。而有了Kubernetes之后，Kubernetes由一組獨立的、可組合的控制流程組成，這些流程可將當前狀態持續推向所需狀態。而你是如何從A進行到C的，在此無關緊要。而且，用戶也不再需要集中控制，整個系統也變得更易于使用、功能更強大、可擴展性更佳。

Kubernetes的基本概念

要使用Kubernetes，您可以使用Kubernetes API對象來描述集群的所需狀態：您想要運行的應用程序或服務，它們使用的容器鏡像、副本數量，您希望提供的網絡和磁盤資源等等。您可以通過使用Kubernetes API——kubectl（通常通過命令行界面）創建對象來設置所需的狀態。您還可以直接使用Kubernetes API與集群交互，并設置或修改所需的狀態。

設置完所需狀態后，Kubernetes控制面板會讓集群的當前狀態與所需狀態相匹配。為此，Kubernetes會自動執行各種任務，例如啟動或重新啟動容器、擴展給定應用程序的副本數量等等。

基本的Kubernetes對象包括： - 節點 - Pod - 服務 - 卷 - 命名空間

此外，Kubernetes包含許多稱為controller的高級抽象。controller基于基本對象構建，并提供其他功能和便利的特性。它們包括：

ReplicaSet

Deployment

StatefulSet

DaemonSet

Job

下文中我們會逐個介紹這些概念，然后再嘗試一些動手練習。

節 點

節點（ Node）是Kubernetes中的worker machine，以前稱為minion。節點可以是虛擬機（VM）或物理機（具體取決于集群）。每個節點都包含運行pod所需的服務，并由主組件管理。你可以這樣理解節點：節點對于pod就像是Hypervisor對于虛擬機。

Pod

Pod是Kubernetes的基本構建塊，它是您創建或部署的Kubernetes對象模型中最小和最簡單的單元。一個Pod代表著一個部署單元：Kubernetes中的單個應用程序實例，可能包含單個容器或少量緊密組合并共享資源的容器。

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

Kubernetes集群中的Pod主要以兩種方式使用：第一種是運行單個容器的Pod 。“one-container-per-Pod”模式是最常見的Kubernetes用例; 在這種情況下，您可以將Pod視為單個容器的打包，由Kubernetes而非容器來管理 Pods。第二種是運行多個需要協同工作的容器的Pod。一個Pod可能包含了一個應用程序，這個應用程序是由多個緊密耦合并且需要共享資源的容器組成的。這些共存的容器可能形成一個單一的內聚服務單元——一個容器負責從共享卷將文件公開，而另一個多帶帶的“sidecar”容器負責刷新或更新這些文件。該Pod 將這些容器和存儲資源一起封裝為一個可管理的實體。

Pod為其組成容器提供兩種共享資源：網絡和存儲。

網絡：每個Pod都分配了一個唯一的IP地址。一個Pod中的所有容器都共享網絡命名空間，包括IP地址和網絡端口。Pod內的容器可以使用localhost相互通信。當Pod內的容器與Pod外的實體通信時，它們必須協調如何使用共享網絡資源（例如端口）。

存儲：Pod可以指定一組共享存儲卷。Pod中的所有容器都可以訪問共享卷，允許這些容器共享數據。如果需要重新啟動其中一個容器，卷還可以讓Pod中的持久數據一直保存著。

服 務

Kubernetes Pods不是不變的，它們被創建又被殺死后并不會重生。即使每個Pod都有自己的IP地址，你也不能完全指望它會隨著時間推移卻永不改變。這會產生一個問題，如果一組Pods（比如說后端）為Kubernetes集群中的另一組Pods（比如說前端）提供了功能，那些前端pod如何能夠與后端pod保持可靠的通信？

這就是服務發揮作用的地方。

Kubernetes服務定義了一個邏輯集Pods和訪問它們的策略（有時稱為微服務），通常由Label Selector確定。

例如，如果你有一個帶有3個Pod的后端應用程序，那些pod是可替代的，前端并不關心它們使用哪個后端。雖然Pods組成后端集的實際情況可能會發生變化，但前端客戶端不應該知道這一點，也不需要跟蹤后端列表本身。該Service抽象可實現這種分離。

對那些處于同樣的Kubernetes集群中的應用，Kubernetes提供了一個簡單的Endpoints API，每當服務中的一套Pods改變時，API就會相應地更新。對于集群外的應用程序，Kubernetes提供基于虛擬IP的橋接器，Services可將其重定向到后端Pods。

卷

容器中的磁盤文件是不是永久的，這會給運行在容器中的應用程序帶來一些問題。首先，當容器崩潰時，它將由Kubernetes重新啟動，但文件會丟失，因為容器總是以干凈狀態啟動的。其次，當在一個pod中運行多個容器時，通常需要在這些容器之間共享文件。Kubernetes Volume就是來解決這兩個問題的。

從本質上講，卷只是一個目錄，可能包含一些數據，在Pod中，它可以訪問容器。該目錄是如何形成的、支持它的介質是什么以及它的內容，是由所使用的特定卷類型決定的。

Kubernetes卷具有明確的生命周期，與創建它的Pod的生命周期相同。總而言之，一個卷超過了在Pod中運行的任何容器，并且在容器重啟時保留了數據。通常，當一個Pod不再存在時，卷也將不復存在。Kubernetes支持多種類型的卷，并且Pod可以同時使用任意數量的卷。

命名空間

Kubernetes支持由同一物理集群支持的多個虛擬集群。這些虛擬集群稱為命名空間。

命名空間提供了名稱范圍。在一個命名空間內，每個資源名稱都需要是唯一的，不過跨命名空間時就沒有這種要求了。

沒有必要只是為了分離略有不同的資源而使用多個命名空間，比如說同一軟件的不同版本：可以用標簽來區分同一命名空間內的不同資源。

ReplicaSet

ReplicaSet確保一次運行指定數量的pod副本。換句話說，ReplicaSet確保pod或同類pod組始終可用。但是，Deployment是一個更高級別的概念，它可以管理ReplicaSets，并為Pods提供聲明性更新以及許多其他有用的功能。因此，除非您需要自定義更新編排或根本不需要更新，否則我建議您使用Deployments而不是直接使用ReplicaSets。

這實際上意味著您可能永遠不需要直接操縱ReplicaSet對象，而是可以使用Deployment作為替代。

Deployment

Deployment controller為Pods和ReplicaSets提供聲明性更新。

您在Deployment對象中描述了所需狀態，Deployment controller就將以受控速率將現階段實際狀態更改為所需狀態。您可以定義Deployments來創建新的ReplicaSets，或刪除現有的Deployments并使用新的Deployments來使用所有資源。

StatefulSets

StatefulSet用于管理有狀態應用程序，它管理一組Pods的部署和擴展，并提供有關這些Pod 的排序和唯一性的保證。

StatefulSet的運行模式和controller相同。您可以在StatefulSet對象中定義所需的狀態，StatefulSet controller就會進行各種必要的更新以從當前狀態到達更新為所需狀態。和Deployment類似，StatefulSet管理那些基于相同容器規范的Pods。與Deployment不同的是，StatefulSet為每個Pods保留一個粘性身份。這些Pods是根據相同的規范創建的，但不可互換：每個都有一個永久的標識符，不論如何重新調度，這個標識都保持不變。

DaemonSet

DaemonSet確保所有（或某些）節點運行Pod的副本。隨著節點添加到群集中，Pod會隨之添加。當將節點從集群中刪除后，Pods就成為了垃圾。此時，刪除一個DaemonSet就將清理它所創建的Pods。

DaemonSet的一些典型用途有：

在每個節點上運行集群存儲daemon，例如glusterd、ceph。

在每個節點上運行日志收集daemon，例如fluentd或logstash。

在每個節點上運行節點監控daemon，例如Prometheus Node Exporter或collectd。

Job

job創建一個或多個pod，并確保在需要的時候成功終止指定數量的pod。Pods成功完成后，job會追蹤順利完成的情況。當達到指定數量時，job本身的任務就完成了。刪除Job將清除它所創建的Pods。

一個簡單的例子是創建一個Job對象，以便可靠地運行一個對象Pod。如果第一個Pod失敗或被刪除（例如由于節點硬件故障或節點重啟），那么該Job對象將啟動一個新Pod。

實際操作中的挑戰

現在您已經了解了Kubernetes中的關鍵對象及概念了，很明顯，想要玩轉Kubernetes需要了解大量的信息。當你嘗試使用Kubernetes時，可能會遇到如下挑戰：

如何在不同的基礎架構中一致地部署？

如何跨多個集群（和名稱空間）實現和管理訪問控制？

如何與中央身份驗證系統集成？

如何分區集群以更有效地使用資源？

如何管理多租戶、多個專用和共享集群？

如何創建高可用集群？

如何跨集群/命名空間實施安全策略？

如何良好地進行監控，以確保有足夠的可見性來檢測和解決問題？

如何跟上Kubernetes快速發展的步伐？

這就是Rancher可以幫助您的地方。Rancher是一個100%開源的容器管理平臺，用于在生產中運行Kubernetes。通過Rancher，你可以：

擁有易于使用的kubernetes配置和部署界面;

跨多個集群和云的基礎架構管理;

自動部署最新的kubernetes版本;

工作負載、RBAC、政策和項目管理;

24x7企業級支持。

Rancher可以成為一個單一控制點，而您可以在多種、多個基礎架構上運行多個Kubernetes集群：

上手Rancher和Kubernetes

現在讓我們看看如何在Rancher的幫助下輕松使用前文描述的Kubernetes對象。首先，您需要一個Rancher實例。按照本指南，在幾分鐘之內即可啟動一個Rancher實例并使用它創建一個Kubernetes集群：

https://rancher.com/docs/ranc...

啟動集群后，您應該在Rancher中看到Kubernetes集群的資源：

要從第一個Kubernetes對象——節點開始，請單擊頂部菜單上的Nodes。你應該可以組成了你的Kubernetes集群的Nodes的整體情況：

在那里，您還可以看到已從Kubernetes集群部署到每個節點的pod的數量。這些pod由Kubernetes和Rancher內部系統使用。通常情況下你不需要處理那些。

下面讓我們繼續Pod的例子。要做到這一點，轉到Kubernetes集群的Default項目，然后進入Workloads選項卡。下面讓我們部署一個工作負載。點擊Deploy并將Name和Docker image設置為nginx，剩下的一切都使用默認值，然后點擊Launch。

創建后，Workloads選項卡會顯示nginx工作負載。

如果單擊nginx工作負載，您將會看到Rancher實際創建了一個Deployment，就像Kubernetes推薦的那樣用來管理ReplicaSet，您還將看到該ReplicaSet創建的Pod：

現在你有一個Deployment，它將確保我們所需的狀態在集群中正確顯示。現在，點擊Scale附近+號，將此Workload擴容到3。一旦你這樣做，你應該能立即看到另外2個Pods被創建出來，另外還多了2個ReplicaSet來縮放事件。使用Pod右側菜單，嘗試刪除其中一個pod，并注意ReplicaSet是如何重新創建它以匹配所需狀態的。

現在，您的應用程序已啟動并運行，并且已經擴展到3個實例。下一個問題是，您如何訪問它？在這里，我們將嘗試使用下一個Kubernetes對象——服務。為了暴露我們的nginx工作負載，我們需要先編輯它，從Workload右側菜單中選擇Edit。您將看到Deploy Workload頁面，且已填好了您的nginx工作負載的詳細信息：

請注意，現在您有3個pod在Scalable Deployment旁邊，但是當您啟動時，默認值為1。這是因為你的擴展工作剛完成不久。

現在單擊Add Port，并按如下所示填充值：

將Publish the container port值設置為80;

Protocol仍為TCP;

將As a值設置為Layer-4 Load Balancer;

將On listening port值設置為80。

然后自信地點擊Upgrade吧！這將在您的云提供商中創建一個外部負載均衡器，并將流量引至您的Kubernetes集群內的nginx Pods中。要對此進行測試，請再次訪問nginx工作負載概述頁面，現在您應該看到Endpoints旁的80/tcp鏈接：

如果點擊80/tcp，它會導向您剛剛創建的負載均衡器的外部IP，并且向您展示一個默認的nginx頁面，確認一切都按預期正常工作。

至此，你已經搞定了上半篇文章中介紹的大多數Kubernetes對象。你可以在Rancher中好好玩玩卷和命名空間，相信您一定能很快掌握如何通過Rancher更簡單快捷地使用它們。至于StatefulSet、DaemonSet和Job，它們和Deployments非常類似，你同樣可以在Workloads選項卡中通過選擇Workload type來創建它們。

結 語

讓我們回顧一下你在上面的動手練習中所做的一切。你已經創建了我們描述的大多數Kubernetes對象：

1、最開始，你在Rancher中創建了kubernetes集群；

2、然后你瀏覽了集群的Nodes；

3、你創造了一個Workload；

4、你已經看到了一個Workload實際上創建了3個獨立的Kubernetes對象：一個Deployment管理著 ReplicaSet，同時按需保持著所需數量的Pods正常運行；

5、在那之后你擴展了你的Deployment數量，并觀察它是如何改變了ReplicaSet并相應地擴展Pods的數量的；

6、最后你創建了一個Load Balancer類型的Service類型，用于平衡Pods之間的客戶端請求。

所有這些都可以通過Rancher輕松完成，您只需進行一些點擊的操作，無需在本地安裝任何軟件來復制身份驗證配置或在終端中運行命令行。您只需一個瀏覽器，玩轉Kubernetes唾手可得。