社内のオンプレミス スタック HA Kubernetes を、3 つのコントロール プレーン、3 つのオフィス ロケーションにまたがる 3 つのワーカー ノード クラスターで拡張したいと考えています。各コントロール プレーンと 1 人のワーカーが各オフィスに存在します。各コントロール プレーンには独自の静的 IP があります。
たとえば、オフィス 1 で停電が発生した場合、ロード バランサー (metallb を使用しています) がどのように機能するのか理解できません。トラフィックはどのようにしてオフィス 2 と 3 にリダイレクトされるのでしょうか。
たとえば、office-1-node で実行されている nextcloud にアクセスする外部のパブリック ユーザーは、office-1-node の静的 IP に関連付けられた fqdn cloud.company.com を使用している可能性があります。(ただし、nextcloud は office-2-node または office-3-node のワーカーまたはマスターで実行されている可能性がありますが、ユーザーにとっては問題ではありません。)
office-1-node で停電が発生した場合、cloud.company.com を office-2-node または office-3-node の静的 IP に誘導するにはどうすればよいでしょうか?
私もまだ勉強中ですので、回答する際にはその点を念頭に置いてください。
答え1
Metal LBが展開されているのがわかりました（https://metallb.universe.tf/インストール/）をコントローラー（IP割り当てを処理）とデーモンセット（コンポーネント - スピーカー -> これは、外部アナウンスを処理するものだと思いますhttps://metallb.universe.tf/concepts/）。したがって、この LB は基本的に Kubernetes リソースとしてデプロイされます。
さて、あなたの質問ですが、office-1-node が停止した場合、他のノードのデーモンセット内のポッドは必要に応じて機能し (外部にアナウンスしてサービスにアクセスできるようにします)、他のマスター ノードのコントローラーは IP 割り当てを引き続き処理します。
リソース：
- Kubernetes コントローラーhttps://kubernetes.io/docs/concepts/architecture/controller/
- Kubernetes デーモンセットhttps://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
- Kubernetes Metallb マニフェスト -https://github.com/metallb/metallb/blob/main/manifests/metallb.yaml
編集: 2番目のコメントで質問に答えます。まず、ドメイン名を購入する必要があります(godaddy、bigrock、AWS Route53などから)。次に、そのドメイン名をロードバランサーのIP(オプションでポート付き)にポイントするCNAMEを作成します(あなたの場合、稼働時間を確保するために、office-1、2、3のIPをラウンドロビン方式で使用できます)。このラウンドロビン方式は、DNS 負荷分散または、実装することもできますDNSフェイルオーバーAWS Route53 のように、ロードバランサーにヘルスチェックを実装します。完了すると、外部ユーザーは引き続き kubernetes のサービスにアクセスできるようになります (office-2 および 3 から)