迫切需要使我們的復雜應用程序具有高可用性，可擴展性，可移植性以及可在小模塊中獨立部署，這導致了Kubernetes的誕生。

今天我們將介紹：

• 什么是Kubernetes?
• 為什么選擇Kubernetes?
• Kubernetes體系結構
• Kubernetes的關鍵組件

[[395780]]

什么是Kubernetes?

Kubernetes俗稱K8！

K8s是Google開發的生產級開源容器編排工具，可幫助您管理支持多個部署環境(例如本地，云或虛擬機)的容器化/泊塢窗化應用程序。

k8s自動執行容器化映像的部署，并幫助其水平擴展以支持高水平的應用程序可用性。

為什么選擇K8s

K8S解決了什么問題?

K8之所以如此受歡迎的主要原因之一是對企業不斷增長的需求以支持其微服務驅動的架構需求。

微服務架構可幫助企業：

• 通過將它們分成小的可擴展模塊，獨立開發和部署其復雜的應用程序
• 幫助他們在支持單個應用程序模塊的多個小型團隊中工作，以所需的速度和敏捷性進行開發和部署

公司從傳統的整體服務向微服務轉移的愿望導致了大型容器化應用程序的創建。每個容器映像本身就是一個微服務，需要以較少的開銷有效地進行管理和擴展，這種處理成千上萬個容器的需求對于組織而言是一項繁瑣的任務。這個問題導致K8演變為流行的容器編排工具之一。

該組織采用了諸如Kubernetes之類的容器編排工具，這具有以下主要優點：

K8s提供什么功能?

• 確保高可用性，零停機時間
• 高性能和可擴展性
• 可靠的基礎架構可輕松支持數據恢復

既然我們已經了解了為什么必須使用K8，那么現在該對K8的基礎體系結構進行解碼了

Kubernetes集群的基本架構：

Kubernetes集群的最基本架構具有兩個主要節點：

• 主節點
• 輔助節點或從屬節點

如果遵循Kubernetes的官方文檔，那么掌握它們的概念將變得非常壓倒性的。因此，我們將嘗試通過必要的簡化來理解相同的內容。

首先，讓我們了解K8中的工作程序節點或從屬節點如何工作，以及工作程序節點的關鍵組成部分是什么

K8s集群中的工作節點：

圖：2.0：K8s集群中的工作節點組件

作為開發人員或K8s管理員，大多數時候您將要處理工作節點，無論是必須部署容器化的應用程序還是必須對其進行自動伸縮，還是必須在生產級服務器上推出任何新的應用程序更新，通常會處理工作者節點。

由于此節點執行集群管理員或開發人員所需的實際工作，因此稱為工作節點。工作節點可以具有一個或多個Pod，這些Pod是您對容器化應用程序的抽象。如圖2.0所示，每個工作人員都運行這3個關鍵過程：

• 容器運行時
• kubelet
• Kube proxy

容器運行時：

您部署的每個微服務模塊(micro-app)都打包到一個單獨的容器中，該容器具有自己的容器運行時。需要將容器運行時安裝到群集中的每個工作程序節點中，以便Pod可以在其中運行。

一些容器運行時示例是：

• containerd
• CRI-O
• Docker

kubelet：

kubelet是工作程序節點的主要節點代理，它與節點和給定工作程序節點中的容器交互。

該kubelet負責：

• 在本地系統上維護一組由一個或多個容器組成的Pod。
• 用于向Kubernetes集群注冊節點，發送事件和Pod狀態以及報告資源利用率。

在一個Kubernetes集群中，kubelet手表PodSpecs通過Kubernetes API服務器。

PodSpec是一個描述Pod的YAML或JSON對象。所述kubelet采用一組通過各種機制(主要是通過提供的PodSpecs的API服務器)，并確保在那些PodSpecs描述的容器正在運行和健康。

Kubelet是Kubernetes中的主要也是最重要的控制器。它負責驅動容器執行層，通常是Docker。

Kube 代理：

K8集群可以有多個工作程序節點，并且每個節點有多個運行的Pod，因此，如果必須訪問此Pod，則可以通過Kube-proxy進行訪問。

kube-proxy是一個網絡代理，它在集群中的每個節點上運行，實現了Kubernetes Service概念的一部分。

為了通過k8s服務訪問Pod，有一些網絡策略允許從群集內部或外部的網絡會話到Pod進行網絡通信。這些規則是通過kube-proxy處理的

kube-proxy具有智能算法，可轉發Pod訪問所需的網絡流量，從而最大程度地減少了開銷，并使服務通信更加高效

到目前為止，我們已經看到這三個進程需要在您的工作程序節點中成功安裝并運行，以便有效地管理您的容器化應用程序，但是更大的問題是

• 誰來管理這些工作程序節點，以確保它們始終處于運行狀態?
• K8s集群如何知道應該安排哪些Pod，以及應該丟棄或重啟哪些Pod?
• k8s集群如何知道每個容器應用程序的資源級別要求?

答案就在于“主節點”的概念，下面我們來探討一下。

K8s集群中的主節點：

圖：3.0 K8中的主節點進程

所述主節點也被稱為一個控制平面，其負責有效地管理工人/從節點。他們與工作節點互動以

• 調度Pod
• 監視工作節點/窗格
• 啟動/重啟Pod
• 管理加入集群的新工作節點

主節點流程：

K8s集群中的每個主節點都運行以下關鍵過程：

• kube-apiserver
• kubectl：kube-controller-manager
• Kube Scheduler 調度器
• etcd

讓我們詳細研究每個流程。

kube-apiserver：

它是訪問k8s集群并充當客戶端級別身份驗證的主要網守的主要網關，或者我們可以說kube-apiserve r是Kubernetes控制平面的前端。

所以只要你想：

• 部署任何新應用
• 調度任何Pod或
• 創建任何新服務
• 查詢狀態或工作節點的運行狀況

您需要向主節點的API服務器發出請求，該服務器隨后會在訪問工作節點中的進程之前驗證您的請求。

kube-apiserver旨在水平擴展-即，它通過部署更多實例進行擴展。您可以運行kube-apiserver的多個實例并平衡這些實例之間的流量。

K8s主節點中的kube-scheduler：

每次作為K8s管理員/開發人員，如果您想在工作節點上安排新的Pod，您都需要將請求發送到主API服務器，該服務器隨后將調用Kube-scheduler進程。此處的調度程序將智能地決定應將此Pod放置在哪個工作程序節點上。

因此，我們可以將kube-scheduler定義為：

關鍵的控制平面組件，用于監視沒有分配工作節點的新創建的Pod，并選擇一個工作節點以對其進行調度和運行。

基于每個節點的資源級別可用性，此決定應將新創建的Pod容納在哪個工作節點上。調度程序進行資源級別查詢并做出重要的調度決策。

調度程序級別決策的實際執行是由給定工作節點中的kubelet進程完成的

有關Pod調度的關鍵決定因素包括：

• 個體和集體資源需求
• 硬件/軟件/政策約束
• 節點親和力和反親和力規范，
• 數據局部性，工作負載間的干擾和期限。

稍后我們將更詳細地介紹k8，我們將了解上述限制和政策。

kube-controller-manager(Kubectl)：

它是監視任何工作節點級別故障狀態的主節點中的關鍵過程之一。它會密切關注像這樣的事件

工作節點中任何Pod的崩潰

并且，在檢測到此類事件后，請求調度程序重新啟動或重新計劃任何已失效/失敗的Pod。

• 主控制計劃器的這些控制管理器組件具有以下類型的控制器：
• 節點控制器：負責在任何工作節點出現故障時做出響應
• 復制控制器：確保始終維護維護任何Pod部署的正確副本數的請求
• 端點控制器：填充“端點”對象。部署，服務和Pod
• 服務帳戶和令牌控制器：為在工作程序節點中創建的新名稱空間創建默認帳戶和API訪問令牌。

K8s主節點中的etcd：

主控平面中的etcd負責以鍵值對的形式存儲各種集群級別的更改。

可以很容易地將其視為k8s集群的大腦，它記錄著集群中發生的變化的每分鐘細節。

例如，如果任何Pod在工作節點中崩潰，并且必須對其進行重新調度，則將其作為鍵值對存儲在etcd中，并且節點上的Pod重新調度的事件也將記錄在此處。

因此，數據與一些關鍵問題有關，例如：

• 節點中有哪些可用資源?
• 集群狀態是否由于任何節點故障而改變?
• 集群健康可以嗎?

實際存儲在此處，以確保我們的k8s集群意識到這一點，并據此采取明智的行動

注意!

諸如DB之類的應用程序級別數據未存儲在etcd中。

Kubernetes組件：

現在我們已經了解了K8s的體系結構過程，是時候研究K8s的一些關鍵組件了，這些組件可以幫助您進行產品級的容器編排。

我們將在這里列出這些組件，并在第二部分中詳細介紹每個組件。

“第2部分：Kubernetes的關鍵組件和概念介紹了“

K8s的一些關鍵組件是：

• Pods：k8的最小單位，是容器應用程序的抽象
• 服務和入口：管理節點之間的外部通信和內部Pod級通信
• ConfigMaps：管理pod / DB所需的端點URL
• Secret：使用based64編碼安全地保存應用程序級密碼和機密密鑰
• Volumn：用于永久數據存儲
• 部署Deployment：部署創建副本并管理無狀態應用
• Statefulsets：用于有狀態的應用程序和數據庫

下一步是什么?

我們將研究上面列出的每個組件的概念，并將進行一些小型動手練習，以了解每個概念的實現。

因此，來考慮一下這個想法：

“如果您知道如何將它們分解為較小的模塊，那么任何復雜的系統都可以輕松理解，這種簡化事物的藝術一直是復雜的微服務架構背后的核心思想。”