集群內部的外觀
一個典型的Kubernetes集群將包含:
· 一個或多個主節點。
· 一個或多個節點。
同樣,這些只是計算機的常見種類。 有時它們可能是大型物理伺服器,有時甚至可以是Raspberry Pi。 但就Google的Kubernetes引擎和Elastic Kubernetes服務而言,它們是虛擬機。
主節點
大師們運行著幾個組件,這些組件為我們提供了稱為控制平面的東西。 他們做出有關集群的決定,例如在哪裡安排特定的工作負載等。
主伺服器負責集群的狀態。 它會持續關注所有事物,以確保一切正常。
節點運行提供運行時環境的組件(它們基本上是具有容器運行時的工作程序)。 這些節點為群集提供資源,例如CPU,RAM等。
在Kubernetes上部署容器時,主伺服器將選擇一個節點在其上運行。
這是Kubernetes Master節點的示意圖。
API伺服器
API伺服器是控制平面的前端; 它公開了所有主要功能的API。
每次您與Master進行通訊或其他任何與Master進行交互(GCP中的Cloud shell)時,都會通過此API伺服器進行。
ETCD
Etcd是Kubernetes自己的資料庫。 它存儲所有Kubernetes的配置和狀態。 我稱它為資料庫,但是Etcd只是一個鍵值存儲。
Schedule 排程器
調度程序負責調度工作負載。 這意味著當您要部署容器時,調度程序將選擇一個節點在其上運行該容器。
它選擇的節點可能會受到許多因素的影響,例如每個可用節點上的當前負載,容器的要求以及其他一些可自定義的約束。
Cloud Controller Manager 雲控制器管理器
Cloud Controller Manager允許Kubernetes與雲平台一起使用。 請記住,Kubernetes本身是一個開源項目,由大公司(不僅是Google)提供捐助,因此它本身並不包含僅適用於GCP的功能。
該經理負責管理網絡和負載平衡之類的事情,因為它轉化為特定雲平台的產品和服務。
Kube Control Manager 控制管理員
Kube Control Manager的工作是管理集群中的少數控制器。 控制器本身負責照管節點和其他一些對象。
現在,可能需要消化很多信息,但是當您啟動集群時,您將主要使用API伺服器。
工作節點
現在,讓我們看一下Kubernetes的節點(Worker)。 他們比大師更直接。
這是Worker節點的示意圖。
Kubelet
Kubelet是Kubernetes的代理。 它與控制平面進行通訊,並在接到通知後接受部署容器等說明。
Kube代理
Kube代理負責節點內外的網絡連接。
容器運行時
該節點將Docker作為容器運行時運行,以使其能夠運行容器。
創建一個Kubernetes集群
有兩種創建Kubernetes集群的方法。
· 艱難的方式。
· 簡單的方法。
艱難的道路
以困難的方式,您啟動了虛擬機並配置了Worker節點和Master節點。
我們需要安裝Kubernetes軟體並配置網絡覆蓋並設置證書,以便內部組件可以相互通信。
簡單的方法
為了簡便,我們可以使用幾乎所有雲提供商所提供的預定義服務,例如Google Cloud Platform的GKE。
GKE自動配置和管理所有基礎雲資源。 它會為您創建Master節點和Worker節點,您甚至都無需觸摸Master控制面板。 為您完全管理。
您可以將GKE的架構與下面的架構進行比較。
(本文翻譯自Vivek Sonar的文章《The Anatomy of a Kubernetes Cluster》,參考:https://medium.com/better-programming/anatomy-of-kubernetes-cluster-24d88f77cf27)