在嘗試將實驗性 Kubernetes 叢集（在我筆記型電腦上的幾個虛擬機器中）配置為「高可用」時，我發現建議使用 keepalived 和 haproxy 的組合來執行此操作（https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing）。
查看我讀到的配置設定
${STATE} 對於一台主機來說是 MASTER，對於所有其他主機來說是 BACKUP，因此虛擬 IP 最初將分配給 MASTER。
主伺服器上的 ${PRIORITY} 應高於備份伺服器上的 ${PRIORITY}。因此 101 和 100 分別就足夠了。
這些設定讓我感到驚訝。看來我必須選擇其中哪個系統作為初始主系統，並且我必須在節點本身中「硬」配置它。
對我來說，這種“高可用”設定偏離了我在 Kubernetes 中找到的“寵物”/“牛”類比。
其他系統（例如 HBase）具有類似的設定（一個活動領導者和多個備用領導者），並且所有系統都「相同」配置（透過 ZooKeeper 完成選舉）。
有沒有一種方法可以配置 Keepalived（用於 Kubernetes），使所有節點都具有相同的配置並且仍然可以正常工作？
答案1
Kubernetes 本身向應用程式提供「牛」服務。儘管許多「主」kubernetes 服務都基於相同的基礎設施，但在某些時候，您需要使用較低級別的服務來引導服務以使其全部啟動。
保持活動狀態如配置中的連結的 kubernetes docco提供單一VRRP虛擬 IP 位址作為主設備之間共用的高可用端點。
所有節點都配置相同的 VRRP IP 位址（或名稱），而 keepalived 會在主節點周圍移動該位址。 「選舉」是在keepalived的健康檢查和故障轉移邏輯中完成的。
此方法的替代方法是將負載平衡決策移至外部設備或用戶端。您可以在每個節點上運行反向代理（像haproxy）可以對 kube-api 伺服器進行加權並完成健康檢查。
答案2
我意識到這是一個過時的線程，但我想無論如何我都會插話，因為我在所有節點上使用相同的配置運行了 KeepaliveD。
在 Debian 上，我們將所有節點初始設定為 BACKUP，並進行某種會提高優先順序的運行狀況檢查（例如 KeepaliveD 運行了多長時間或對您希望 HA 的本地服務進行運行狀況檢查...）
VRRP v2 是 KeepaliveD（至少是我使用過的版本）在 Debian 上運行的版本，它具有決勝局功能，如果多個節點上的優先級相同，則「最高 IP」獲勝。
如果所有節點同時啟動，這可能會導致初始延遲，但在我們使用它的地方這是可以接受的。
希望有幫助。