集群高可用
Kubernetes具有自愈能力,當它跟蹤到某工作節點發生故障時,控制平面可以將離線節點上的Pod對象重新編排至其他可用的工作節點上運行.若主API服務器出現故障(由於其主機出現故障或網絡分區將其從集群中隔離)則其將無法再跟蹤和控制集群.
一般來說高可用控制平面至少需要三個Master節點來承受最多一個Master節點的丟失,才能保證等待狀態的Master節點能夠保持半數以上.以滿足節點選舉時的法定票數
利用haproxy和keepalived的VIP功能來實現高可用的方案
kube-scheduler和kube-controller-manager使用一主多從的高可用方案,在同一時刻只允許一個服務處以具體的任務.Kubernetes中自身實現了一套簡單的選主邏輯,依賴Etcd實現 scheduler和controller-manager的選主功能,所以這兩個組件不需要我們手動去實現高可用
Kubernetes組件中僅etcd需要復雜邏輯完成集群功能,其他組件間的松耦合特性使得系統能夠通過多種方式實現Master節點的高可用性
利用etcd自身提供的分布式存儲集群為Kubernetes構建一個可靠的存儲層
apiserver組件
將無狀態的apiserver運行為多副本,並在其前端使用負載均衡器調度請求.需要注意的是負載均衡器本身也需要是高可用的
controller-manager組件
多副本的控制器管理器,通過其自帶的leader選舉功能(--leader-election) 選舉出主角色,余下的副本在主角色發生故障時自動啟動新一輪的選舉操作
scheduler組件
多副本的調度器,通過其自帶的leader選舉功能(--leader-election)選舉出主 角色,余下的副本在主角色發生故障時自動啟動新一輪的選舉操作
etcd高可用
etcd內部采用raft協議作為共識算法進行分布式協作,將數據同步存儲在多個獨立的服務實例上以提高數據的可靠性,從而避免了單點故障所導致的數據丟失。Raft協議通過選舉出的leader節點來實現數據的一致性，由leader節點負責所有的寫入請求並同步給集群中的所有節點,在取決半數以上follower節點的確認后予以持久存儲
Controller Manager高可用
Controller Manager通過監控API Server上的資源狀態變動並按需分別執行相應的操作,於是,多實例運行的kube-controller-manager 進程可能會導致同一操作行為被每一個實例分別執行一次.例如,某一Pod對象創建的請求被3個控制器實例分別執行一次進而創建出一個Pod對象副本來.因此在某一時刻,僅能有一個kube- controller-manager實例處於正常工作狀態,余下的均處於備用狀態,或者稱為等待狀態
多個kube-controller-manager實例要同時啟用“--leader-elect=true”選項以自 動實現leader選舉,選舉過程完成后,僅leader實例處於活動狀態,余下的其他實例均轉入等待模式,它們會在探測到leader故障時進行新一輪的選舉.與etcd集群基於raft協議進行leader選舉不同的是kube-controller-manager集群各自的選舉操作僅是通過在kube-system名稱空間中創建一個與程序同名的Endpoints資源對象來實現
這種leader選舉操作是分布式鎖機制的一種應用,它通過創建和維護Kubernetes資源對象來維護鎖狀態,目前Kubernetes支持ConfigMap和Endpoints兩種類型的資源鎖.初始狀態時,各kube-controller-manager實例通過競爭的方式去搶占指定的 Endpoints資源鎖。勝利者將成為leader它通過更新相應的Endpoints資源的注解 control-plane.alpha.kubernetes.io/leader中的“holderIdentity” 為其 節點名稱,從而將自己設置為鎖的持有者,並基於周期性更新同一注解中的“renewTime” 以聲明自己對鎖資源的持有狀態從而避免等待狀態的實例進行爭搶於是一旦某leader不再更新renewTime了,等待狀態的各實例就將一哄而上進行新一輪的競爭
kubectl describe endpoints kube-controller-manager -n kube-system
kube-scheduler高可用
kube-scheduler的實現方式與此類似,只不過它使用的是自己專用的 Endpoints資源kube-scheduler