迫切需要使我們的復(fù)雜應(yīng)用程序具有高可用性，可擴(kuò)展性，可移植性以及可在小模塊中獨(dú)立部署，這導(dǎo)致了Kubernetes的誕生。

今天我們將介紹：

• 什么是Kubernetes?
• 為什么選擇Kubernetes?
• Kubernetes體系結(jié)構(gòu)
• Kubernetes的關(guān)鍵組件

[[395780]]

什么是Kubernetes?

Kubernetes俗稱K8！

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

k8s自動執(zhí)行容器化映像的部署，并幫助其水平擴(kuò)展以支持高水平的應(yīng)用程序可用性。

為什么選擇K8s

K8S解決了什么問題?

K8之所以如此受歡迎的主要原因之一是對企業(yè)不斷增長的需求以支持其微服務(wù)驅(qū)動的架構(gòu)需求。

微服務(wù)架構(gòu)可幫助企業(yè)：

• 通過將它們分成小的可擴(kuò)展模塊，獨(dú)立開發(fā)和部署其復(fù)雜的應(yīng)用程序
• 幫助他們在支持單個應(yīng)用程序模塊的多個小型團(tuán)隊(duì)中工作，以所需的速度和敏捷性進(jìn)行開發(fā)和部署

公司從傳統(tǒng)的整體服務(wù)向微服務(wù)轉(zhuǎn)移的愿望導(dǎo)致了大型容器化應(yīng)用程序的創(chuàng)建。每個容器映像本身就是一個微服務(wù)，需要以較少的開銷有效地進(jìn)行管理和擴(kuò)展，這種處理成千上萬個容器的需求對于組織而言是一項(xiàng)繁瑣的任務(wù)。這個問題導(dǎo)致K8演變?yōu)榱餍械娜萜骶幣殴ぞ咧弧?/p>

該組織采用了諸如Kubernetes之類的容器編排工具，這具有以下主要優(yōu)點(diǎn)：

K8s提供什么功能?

• 確保高可用性，零停機(jī)時間
• 高性能和可擴(kuò)展性
• 可靠的基礎(chǔ)架構(gòu)可輕松支持?jǐn)?shù)據(jù)恢復(fù)

既然我們已經(jīng)了解了為什么必須使用K8，那么現(xiàn)在該對K8的基礎(chǔ)體系結(jié)構(gòu)進(jìn)行解碼了

Kubernetes集群的基本架構(gòu)：

Kubernetes集群的最基本架構(gòu)具有兩個主要節(jié)點(diǎn)：

• 主節(jié)點(diǎn)
• 輔助節(jié)點(diǎn)或從屬節(jié)點(diǎn)

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

首先，讓我們了解K8中的工作程序節(jié)點(diǎn)或從屬節(jié)點(diǎn)如何工作，以及工作程序節(jié)點(diǎn)的關(guān)鍵組成部分是什么

K8s集群中的工作節(jié)點(diǎn)：

圖：2.0：K8s集群中的工作節(jié)點(diǎn)組件

作為開發(fā)人員或K8s管理員，大多數(shù)時候您將要處理工作節(jié)點(diǎn)，無論是必須部署容器化的應(yīng)用程序還是必須對其進(jìn)行自動伸縮，還是必須在生產(chǎn)級服務(wù)器上推出任何新的應(yīng)用程序更新，通常會處理工作者節(jié)點(diǎn)。

由于此節(jié)點(diǎn)執(zhí)行集群管理員或開發(fā)人員所需的實(shí)際工作，因此稱為工作節(jié)點(diǎn)。工作節(jié)點(diǎn)可以具有一個或多個Pod，這些Pod是您對容器化應(yīng)用程序的抽象。如圖2.0所示，每個工作人員都運(yùn)行這3個關(guān)鍵過程：

• 容器運(yùn)行時
• kubelet
• Kube proxy

容器運(yùn)行時：

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

一些容器運(yùn)行時示例是：

• containerd
• CRI-O
• Docker

kubelet：

kubelet是工作程序節(jié)點(diǎn)的主要節(jié)點(diǎn)代理，它與節(jié)點(diǎn)和給定工作程序節(jié)點(diǎn)中的容器交互。

該kubelet負(fù)責(zé)：

• 在本地系統(tǒng)上維護(hù)一組由一個或多個容器組成的Pod。
• 用于向Kubernetes集群注冊節(jié)點(diǎn)，發(fā)送事件和Pod狀態(tài)以及報告資源利用率。

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

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

Kubelet是Kubernetes中的主要也是最重要的控制器。它負(fù)責(zé)驅(qū)動容器執(zhí)行層，通常是Docker。

Kube 代理：

K8集群可以有多個工作程序節(jié)點(diǎn)，并且每個節(jié)點(diǎn)有多個運(yùn)行的Pod，因此，如果必須訪問此Pod，則可以通過Kube-proxy進(jìn)行訪問。

kube-proxy是一個網(wǎng)絡(luò)代理，它在集群中的每個節(jié)點(diǎn)上運(yùn)行，實(shí)現(xiàn)了Kubernetes Service概念的一部分。

為了通過k8s服務(wù)訪問Pod，有一些網(wǎng)絡(luò)策略允許從群集內(nèi)部或外部的網(wǎng)絡(luò)會話到Pod進(jìn)行網(wǎng)絡(luò)通信。這些規(guī)則是通過kube-proxy處理的

kube-proxy具有智能算法，可轉(zhuǎn)發(fā)Pod訪問所需的網(wǎng)絡(luò)流量，從而最大程度地減少了開銷，并使服務(wù)通信更加高效

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

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

答案就在于“主節(jié)點(diǎn)”的概念，下面我們來探討一下。

K8s集群中的主節(jié)點(diǎn)：

圖：3.0 K8中的主節(jié)點(diǎn)進(jìn)程

所述主節(jié)點(diǎn)也被稱為一個控制平面，其負(fù)責(zé)有效地管理工人/從節(jié)點(diǎn)。他們與工作節(jié)點(diǎn)互動以

• 調(diào)度Pod
• 監(jiān)視工作節(jié)點(diǎn)/窗格
• 啟動/重啟Pod
• 管理加入集群的新工作節(jié)點(diǎn)

主節(jié)點(diǎn)流程：

K8s集群中的每個主節(jié)點(diǎn)都運(yùn)行以下關(guān)鍵過程：

• kube-apiserver
• kubectl：kube-controller-manager
• Kube Scheduler 調(diào)度器
• etcd

讓我們詳細(xì)研究每個流程。

kube-apiserver：

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

所以只要你想：

• 部署任何新應(yīng)用
• 調(diào)度任何Pod或
• 創(chuàng)建任何新服務(wù)
• 查詢狀態(tài)或工作節(jié)點(diǎn)的運(yùn)行狀況

您需要向主節(jié)點(diǎn)的API服務(wù)器發(fā)出請求，該服務(wù)器隨后會在訪問工作節(jié)點(diǎn)中的進(jìn)程之前驗(yàn)證您的請求。

kube-apiserver旨在水平擴(kuò)展-即，它通過部署更多實(shí)例進(jìn)行擴(kuò)展。您可以運(yùn)行kube-apiserver的多個實(shí)例并平衡這些實(shí)例之間的流量。

K8s主節(jié)點(diǎn)中的kube-scheduler：

每次作為K8s管理員/開發(fā)人員，如果您想在工作節(jié)點(diǎn)上安排新的Pod，您都需要將請求發(fā)送到主API服務(wù)器，該服務(wù)器隨后將調(diào)用Kube-scheduler進(jìn)程。此處的調(diào)度程序?qū)⒅悄艿貨Q定應(yīng)將此Pod放置在哪個工作程序節(jié)點(diǎn)上。

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

關(guān)鍵的控制平面組件，用于監(jiān)視沒有分配工作節(jié)點(diǎn)的新創(chuàng)建的Pod，并選擇一個工作節(jié)點(diǎn)以對其進(jìn)行調(diào)度和運(yùn)行。

基于每個節(jié)點(diǎn)的資源級別可用性，此決定應(yīng)將新創(chuàng)建的Pod容納在哪個工作節(jié)點(diǎn)上。調(diào)度程序進(jìn)行資源級別查詢并做出重要的調(diào)度決策。

調(diào)度程序級別決策的實(shí)際執(zhí)行是由給定工作節(jié)點(diǎn)中的kubelet進(jìn)程完成的

有關(guān)Pod調(diào)度的關(guān)鍵決定因素包括：

• 個體和集體資源需求
• 硬件/軟件/政策約束
• 節(jié)點(diǎn)親和力和反親和力規(guī)范，
• 數(shù)據(jù)局部性，工作負(fù)載間的干擾和期限。

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

kube-controller-manager(Kubectl)：

它是監(jiān)視任何工作節(jié)點(diǎn)級別故障狀態(tài)的主節(jié)點(diǎn)中的關(guān)鍵過程之一。它會密切關(guān)注像這樣的事件

工作節(jié)點(diǎn)中任何Pod的崩潰

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

• 主控制計(jì)劃器的這些控制管理器組件具有以下類型的控制器：
• 節(jié)點(diǎn)控制器：負(fù)責(zé)在任何工作節(jié)點(diǎn)出現(xiàn)故障時做出響應(yīng)
• 復(fù)制控制器：確保始終維護(hù)維護(hù)任何Pod部署的正確副本數(shù)的請求
• 端點(diǎn)控制器：填充“端點(diǎn)”對象。部署，服務(wù)和Pod
• 服務(wù)帳戶和令牌控制器：為在工作程序節(jié)點(diǎn)中創(chuàng)建的新名稱空間創(chuàng)建默認(rèn)帳戶和API訪問令牌。

K8s主節(jié)點(diǎn)中的etcd：

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

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

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

因此，數(shù)據(jù)與一些關(guān)鍵問題有關(guān)，例如：

• 節(jié)點(diǎn)中有哪些可用資源?
• 集群狀態(tài)是否由于任何節(jié)點(diǎn)故障而改變?
• 集群健康可以嗎?

實(shí)際存儲在此處，以確保我們的k8s集群意識到這一點(diǎn)，并據(jù)此采取明智的行動

注意!

諸如DB之類的應(yīng)用程序級別數(shù)據(jù)未存儲在etcd中。

Kubernetes組件：

現(xiàn)在我們已經(jīng)了解了K8s的體系結(jié)構(gòu)過程，是時候研究K8s的一些關(guān)鍵組件了，這些組件可以幫助您進(jìn)行產(chǎn)品級的容器編排。

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

“第2部分：Kubernetes的關(guān)鍵組件和概念介紹了“

K8s的一些關(guān)鍵組件是：

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

下一步是什么?

我們將研究上面列出的每個組件的概念，并將進(jìn)行一些小型動手練習(xí)，以了解每個概念的實(shí)現(xiàn)。

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

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