実験的なKubernetesクラスタ（ラップトップ上のいくつかのVM内）を「高可用性」として構成しようとしていたときに、keepalivedとhaproxyの組み合わせを使用してこれを行うというアドバイスを見つけました（https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing）。
私が読んだ設定を見ると
${STATE} は 1 つのホストでは MASTER で、他のすべてのホストでは BACKUP であるため、仮想 IP は最初は MASTER に割り当てられます。
${PRIORITY} は、マスターではバックアップよりも高く設定する必要があります。したがって、それぞれ 101 と 100 で十分です。
これらの設定には驚きました。どうやら、どのシステムを初期マスターにするかを選択し、ノード自体でこれを「ハード」構成する必要があるようです。
私にとって、この「高可用性」設定は、Kubernetes で見られる「ペット」と「牛」の類似性から逸脱しています。
たとえば HBase などの他のシステムも同様の設定 (1 つのアクティブ リーダーと複数のスタンバイ リーダー) があり、すべてが「同一」に構成されています (選出は ZooKeeper を介して行われます)。
すべてのノードが同じ構成を持ち、それでも正しく動作するように、Keepalived (Kubernetes で使用) を構成する方法はありますか?
答え1
Kubernetes 自体は、アプリケーションに「cattle」サービスを提供します。多くの「マスター」Kubernetes サービスは同じインフラストラクチャに基づいていますが、ある時点で、すべてを起動するために、より低いレベルの何かでサービスをブートストラップする必要があります。
キープアライブ設定されているリンクされた Kubernetes ドキュメント単一の仮想化マスター間で共有される高可用性エンドポイントとしての仮想 IP アドレス。
すべてのノードは同じ VRRP IP アドレス (または名前) を設定し、keepalived はそのアドレスをマスター間で移動します。「選出」は、keepalived ヘルスチェックとフェイルオーバー ロジックで完了します。
この方法の代替案は、負荷分散の決定を外部デバイスまたはクライアントに移すことです。各ノードでリバースプロキシを実行できます（haproxyのように) は、kube-api サーバーの重み付けを行い、ヘルスチェックを完了することができます。
答え2
これは古いスレッドだとはわかっていますが、すべてのノードで同一の設定で KeepaliveD を実行したので、とにかく参加しようと思いました。
Debian では、すべてのノードが最初に BACKUP に設定され、優先度を上げる何らかのヘルスチェックが行われます (例: KeepaliveD の実行時間や、HA が必要なローカル サービスのヘルスチェックなど)。
Debian 上で実行されている KeepaliveD (少なくとも私が使用したバージョン) である VRRP v2 には、タイブレーカー機能があり、複数のノードで優先度が同じ場合は、「最も高い IP」が優先されます。
すべてのノードが同時に起動すると、初期遅延が発生する可能性がありますが、これを使用する場合、これは許容範囲内です。
お役に立てれば幸いです。