有關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-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

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/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之間的客戶端請求。

到此，關于“有關Kubernetes的詳細介紹”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！