kubernetes 的架構與組件

kubernetes 架構目標

kubernetes 是生產級的,用於跨主機部署,擴展,管理和組合應用程序容器的基礎設施。kubernetes 不僅僅是 “容器編排”,他更加主要的解決方向是消除協調計算資源,網絡和存儲的負擔,使開發人員以容器爲中心,實現自己出發主導資源操作流程。kubernetes 還提供了一個穩定的,可移植的,用於構建定製的工作流和更高級別自動化的平臺。

kubernetes 主要針對多個容器構成的應用程序。因此 kubernetes 使用 pod 和 label 來構建鬆散或緊密的容器編隊,以便管理和發現。

kubernetes 在架構上包含哪些功能呢?

首先必須是可擴展的,可插入式的。因此在架構上,kubernetes 被構建成爲一個可插入組件和層的集合,能夠替代日常開發中的調度程序,控制器,存儲系統和分發機制。如果設計的足夠好的話,在使用更高級別的 Paas 功能或者多層集羣時,就無需改動源碼。由於上述原因他在設計的 api 的時候不僅針對最終使用 kubernetes 的用戶,而且還針對工具和擴展開發人員。kubernetes 的 API 旨在作爲工具,自動化系統和更高 API 層面的開放生態系統。這種插件化的構造方式,使得 kubernetes 沒有 “內部” 組件 API 這種東西。所有的 API 都是可見的和可用的,包括調度器 scheduler,節點控制器 node controller,副本控制器 replication-controller 和 kubectl 控制器。爲了實現更加複雜的功能,完全可以通過組合訪問這些低級別的 API 來實現。

kubernetes 在架構上想達到哪些目標呢?

首先是 “到處運行”,無論是共有云,還是私有云,裸金屬機器或者筆記本電腦,kubernetes 都會具有相同的功能。基於這個目標,kubernetes 相關組件和工具在整個生態系統以及開發和生產環境之間都是可移植的。

其次是 “一般性用途”,kubernetes 具有可以承載所有類型工作負載的能力。包含有狀態,無狀態,微服務或者單體服務,批處理,前沿服務或者傳統應用。

然後是 “無需全部遷移”,kubernetes 不僅適合純原生的雲應用,也能適合所有的用戶需求。kubernetes 專注微服務和雲原生,但是提供一些機制來促進單體應用和遺留的傳統程序的靈活遷移。kubernetes 的衆多功能可以按順序來加入到工作中,而且可以靈活使用自定義的方案來替換內置的功能。

還有 “可擴展”,kubernetes 通過提供和內置功能相同的接口來添加所需的附加功能。

以及 “自動化”,kubernetes 的目標是大大減少手工操作的負擔。通過 API 指定用戶所需的意圖來支持聲明式控制,同時還支持高級編排和自動化的命令式控制。聲明性方法是系統自愈和自主功能的關鍵。

最後是 “更加前沿”,kubernetes 希望支持非雲原生的應用程序,同時也希望提高雲原生和 DevOps 相關的技術水平,例如讓應用程序參與到 kubernetes 自己本身的管理當中。但是也不會強迫應用程序綁定到 API 中,因爲比起兼容 api,其實更好的方案是約定配置。

kubernetes 架構細節

kubernetes 包含節點代理(kubectl)和集羣控制平面(aka master),集羣狀態由 etcd 支撐。

Kubernetes 控制平面被分割成一組組件,這些組件可以在單個主節點上運行,也可以複製以支持高可用性集羣,甚至可以在 Kubernetes 本身(也稱爲自託管)上運行。

Kubernetes 提供了 REST API,它主要支持持久性資源上的 CRUD 操作,而持久性資源是其控制平面的中心。Kubernetes 的 API 提供了類似 IaaS 的以容器爲中心的原語,如 pod、服務和入口,以及生命週期 API,以支持常見類型工作負載的編排(自愈、縮放、更新、終止),如 ReplicaSet(簡單的可替換或者無狀態的 app-manager),部署(編排無狀態應用的更新),作業(批處理)、cron Job(cron)、守護程序(羣集服務)和 StatefulSet(有狀態應用程序)。我們故意將服務命名 / 發現和負載平衡從應用程序實現中分離出來,因爲後者是多樣的、開放的。

用戶客戶端和包含異步控制器的組件都與相同的 API 資源交互,API 資源充當協調點、公共中間表示和共享狀態。大多數資源都包含元數據,包括標籤和註釋、詳細闡述的所需狀態(spec),包括默認值和觀察到的狀態(status)。

控制器持續工作,將實際狀態驅動到所需狀態,同時爲用戶和其他控制器報告當前觀察到的狀態。

雖然控制器是基於基礎級別的,以最大限度地提高容錯性,但它們通常會監視相關資源的更改,以最小化反應延遲和冗餘工作。這使得無需消息總線就可以進行分散和分離的編排式協調。

API 服務器提供 Kubernetes API。它旨在成爲一個相對簡單的服務器,大多數業務邏輯都在單獨的組件或插件中實現。它主要處理 REST 操作,驗證它們,並更新 etcd 中的相應對象(可能最終更新其他存儲)。注意,出於許多原因,Kubernetes 故意不支持跨多個資源的原子事務。

如果沒有這個基本的 API 機制,Kubernetes 將無法運行,它包括:

此外,API 服務器充當集羣的網關。根據定義,API 服務器必須由集羣外部的客戶機訪問,而節點(當然還有容器)可能不可訪問。客戶機對 API 服務器進行身份驗證,並將其用作節點和 pod(和服務)的堡壘和代理 / 隧道。

所有持久集羣狀態都存儲在 etcd 的一個實例中。這提供了一種可靠地存儲配置數據的方法。有了 watch 支持,協調組件可以很快地收到更改通知。

大多數其他集羣級功能,目前由一個單獨的進程執行,稱爲控制器管理器。它執行生命週期功能(例如,命名空間創建和生命週期、事件垃圾收集、終止的 pod 垃圾收集、級聯刪除垃圾收集、節點垃圾收集)和 API 業務邏輯(例如,由複製集控制的 pod 縮放)。

應用程序管理和組合層,提供自愈、擴展、應用程序生命週期管理、服務發現、路由以及服務綁定和供應。

這些功能最終可能被分割成不同的組件,以使它們更容易擴展或替換。

Kubernetes 允許用戶請求集羣運行一組容器。調度程序組件自動選擇要在其上運行這些容器的主機

調度器根據請求資源的可用性、服務質量要求、關聯和反關聯規範以及其他約束,監視未計劃的 pod 並通過 / binding pod 子資源 API 將其綁定到節點。

Kubernetes 支持用戶提供的調度程序和多個併發集羣調度程序,使用 Omega 首創的共享狀態方法。除了 Omega 論文所描述的悲觀併發的缺點之外,兩級調度模型對上層調度程序隱藏信息,需要在下層調度程序中實現所有上層調度程序所需的相同功能,以確保它們的調度請求能夠被所需的可用資源滿足。

kubernetes 節點

Kubernetes 節點具有運行應用程序容器和從主系統進行管理所必需的服務。

Kubernetes 中最重要和最突出的控制器是 Kubelet,它是驅動容器執行層的 Pod 和節點 api 的主要實現者。如果沒有這些 API,Kubernetes 將只是一個由鍵值存儲支持的面向 CRUD 的 REST 應用程序框架(也許 API 機器最終將作爲一個獨立的項目剝離出來)。

Kubernetes 執行獨立的應用程序容器作爲其默認的本地執行模式,而不是進程和傳統的操作系統包。應用程序容器不僅彼此隔離,而且還與它們在其上執行的主機隔離,這對於將單個應用程序的管理彼此分離以及與底層羣集物理 / 虛擬基礎設施的管理分離是至關重要的。

Kubernetes 提供的 pod 可以承載多個容器和存儲卷,作爲其基本的執行原語,以便爲每個容器打包單個應用程序、將部署時間關注點與構建時間關注點分離以及從物理 / 虛擬機遷移提供便利。Pod 原語是收集在現代雲平臺(如 Kubernetes)上部署的主要好處的關鍵。

API 許可控制可以拒絕 pod 或向 pod 添加額外的調度約束,但是 Kubelet 是 pod 可以和不能在給定節點上運行的最終仲裁者,而不是調度器或守護程序。

Kubelet 目前也鏈接在 cAdvisor 資源監控代理中。

每個節點運行一個容器運行時,該運行時負責下載圖像和運行容器。

Kubelet 不在基本容器運行時中鏈接。相反,我們定義了一個容器運行時接口來控制底層運行時並促進該層的可插入性。爲了保持清晰的組件邊界、方便測試和促進可插入性,需要這種分離。目前支持的運行時,無論是上游運行還是 forks 運行,至少包括 docker(用於 Linux 和 Windows)、rkt、cri-o 和 frakti。

服務抽象提供了一種在公共訪問策略(如負載平衡)下對 pod 進行分組的方法。這個實現創建了一個虛擬 IP,客戶端可以訪問它,並且它透明地代理到服務中的 pods。每個節點運行一個 kube 代理進程,該進程對 iptables 規則進行編程,以捕獲對服務 ip 的訪問並將其重定向到正確的後端。這提供了一個高可用的負載平衡解決方案,通過平衡來自同一節點上某個節點的客戶端流量,從而降低了性能開銷。

服務終結點主要通過 DNS 找到。

以上就是 kubernetes 的架構。下面是簡化總結:

kubernetes 各個組件的核心功能:

作者:seymour

來源:juejin.cn/post/6931747243821105159

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/IPgnMxqaNqeYcxEbOmbV9w