開場
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，並且此套方案已經行之有年，已經可被視為非常成熟可靠的方案。