零基礎入門│帶你理解Kubernetes

09-13

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

這就是

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-studies/

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

是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

確保一次運行指定數量的pod副本。換句話說，

ReplicaSet

確保pod或同類pod組始終可用。但是，

Deployment

是一個更高級別的概念，它可以管理

ReplicaSets

，並為Pods提供聲明性更新以及許多其他有用的功能。因此，除非您需要自定義更新編排或根本不需要更新，否則我建議您使用

Deployments

而不是直接使用

ReplicaSets

。

這實際上意味著您可能永遠不需要直接操縱

ReplicaSet

對象，而是可以使用

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

確保所有（或某些）節點運行

Pod

的副本。隨著節點添加到群集中，Pod會隨之添加。當將節點從集群中刪除後，

Pods

就成為了垃圾。此時，刪除一個

DaemonSet

就將清理它所創建的

Pods

。

DaemonSet的一些典型用途有：

在每個節點上運行集群存儲daemon，例如
glusterd
、
ceph
。
在每個節點上運行日誌收集daemon，例如
fluent
d或
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/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/

啟動集群後，您應該在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唾手可得。

拓展閱讀：

《

Rancher中的K8S認證和RBAC》

《

Bare Metal K8S集群在美國快餐連鎖Chick-fil-A 的大規模使用》

《

媒體服務巨頭Sling TV構建生產級K8S集群，服務400萬付費用戶》

「

Rancher Labs由矽谷雲計算泰斗、CloudStack之父梁勝創建，致力於打造創新的開源軟體，幫助企業在生產環境中運行容器與Kubernetes。旗艦產品Rancher是一個開源的企業級Kubernetes平台，是業界首個且唯一可以管理所有雲上、所有發行版、所有Kubernetes集群的平台。解決了生產環境中企業用戶可能面臨的基礎設施不同的困境，改善Kubernetes原生UI易用性不佳以及學習曲線陡峭的問題，是企業落地Kubernetes的不二之選。

Rancher在全球已有9000萬次下載和超過20000個生產節點部署，且在全球範圍內已經擁有包含迪斯尼、IBM、樂高、美國農業部、SONY、中國平安、海航集團在內數百家大中型政府及企業客戶。

」

Rancher北上深招聘進行時

TAG:理解 | 零基礎 | Kubernetes | 基礎 | 入門 |