開場
kubernetes本身架構屬於主從模式(Master/Slave),本篇是第一篇筆記,所以在此先分享並順便紀錄一下,kubernetes裡主從節點如何分工。
Kubernetes中主從節點的功能以及元件
Master Node (Control Plane)
此節點類型為kubernetes集群的大腦,負責容器的調度以及資源的管理,節點內包含以下元件
- kube-apiserver
提供API介面,用於當作集群中各個節點的溝通橋樑,以及接收來自使用者使用API呼叫或者kubectl工具下達的命令,是集群中的關鍵應用,若此元件故障,將導致整個集群無法操作
每個 Node 之間的溝通一定要透過此元件,彼此之間無法直接互相溝通
- etcd
CNCF畢業的專案之一,負責存放整個存放整個集群的狀態及資料的資料庫,也是當集群故障時恢復集群最重要的關鍵
- kube-scheduler
負責集群的資源調配,未指定運行節點的容器將被此元件協調後指派至最符合的Worker Node運行
- kube-controller-manager
負責管理並運行各類kubernetes controller的元件,例如Node Controller、Replication Controller或ServiceAccounts Controller
此元件的操作也都需要仰賴kube-apiserver,必須通過kube-apiserver完成
Worker Node
此節點類型為kubernetes集群的四肢,負責執行容器負載,節點內包含以下元件
- kubelet
Worker Node的管理進程,負責管理此節點上所有Pods的狀態並負責與Master Node溝通
- kube-proxy
負責更新此Woker Node上的iptables,以反映Master Node上service與endpoint的設定,使得流量得以與Pod溝通
- Container Runtime
負責容器的執行,使用符合container runtime interface(CRI)的引擎來執行容器,例如Docker Engine、Containerd以及CRI-O
在此架構上kubernetes集群會有至少一個Master Node(Control Plane)負責容器的調度以及資源的管理,以及至少一個Worker Node負責執行容器負載。
在上述的介紹中,有提到Master Node裡的kube-apiserver元件對整個kubernetes集群至關重要。若集群內只有一個Master Node,那在此Master Node故障時,將失去對整個kubernetes集群的控制,所以希望在集群中有多個Master Node做備援,避免Master Node成為SPOF。
但若集群裡有多個Master Node時,就會需要設定Load Balancer做為單一入口來將控制流量分配到各個Master Node上,並且為了避免Load Balancer本身成為SPOF,此Load Balancer本身也必須處於高可用的狀態。
此篇筆記主要是關於HAProxy與KeepAlived這兩個套件的設定,這兩個套件可以互相搭配來搭建出一套高可用的Load Balancer,並且此套方案已經行之有年,已經可被視為非常成熟可靠的方案。