Kubernetes Federation

Kubernetes Federation は、フェデレーションコントロールプレーンから複数クラスター にまたがるワークロードを管理する初期の試みでした。Federation v1 は非推奨となり、 CRD ベースの後継である KubeFed または Federation v2 と呼ばれるものも、現在は Kubernetes のアクティブなプロジェクトではありません。新しいプラットフォームの 基盤ではなく、歴史的な技術として扱う必要があります。

Federation が解決しようとした問題 #

このモデルではメンバークラスターを登録し、選択したリソースをメンバークラスターへ 伝播しました。独立したクラスターを維持しながら、配置、レプリカ分散、サービス ディスカバリー、設定を一元化することを目指していました。難しい点は、競合処理、 クラスター障害、ネットワーク、ID、バージョンのずれ、そして単一のグローバル API が別の可用性依存要因になり得ることでした。

初期実装では、独立したフェデレーション API サーバーを使用していました。その後の 取り組みでは、フェデレーションの動作をカスタムリソースとコントローラーへ移し、 拡張しやすくなりましたが、クラスター間の状態を運用する複雑さは解消されませんでした。

現行の代替手段を使用する #

問題に応じて代替手段を選択します。

• GitOps フリート: Argo CD ApplicationSet と Flux は、登録された多数のクラスター にアプリケーションをレンダリングして調整できます。
• ワークロードスケジューリング: Karmada はマルチクラスターのスケジューリングと 伝播 API を提供します。
• フリート管理: Open Cluster Management は、管理対象クラスターの登録、ポリシー、 配置のプリミティブを提供します。
• クラスター間ネットワーク: Cilium Cluster Mesh、Submariner、サービスメッシュの マルチクラスター機能は接続性を扱いますが、デプロイオーケストレーションを置き 換えるものではありません。

これらのツールは異なるコントロールプレーンと障害モードを持ちます。マルチクラスター デプロイメントマネージャーを選択すれば、グローバルなサービスディスカバリー、 ネットワーク到達性、共有 ID も提供されると想定しないでください。

独立したクラスター向けに設計する #

各クラスターを、独立して運用可能な障害ドメインとして扱います。認証情報をどのように ローテーションするか、コントロールプレーン切断中にアプリケーションがどのように 動作するか、ワークロードを 1 つのクラスターでアクティブにするか複数でアクティブに するかを定義します。データストア自体に検証済みのレプリケーションとフェイルオーバー 設計がある場合を除き、クラスターごとの永続データを優先します。中央管理プレーンは、 ローカル復旧を不可能にすることなく、一貫性と可視性を向上させる必要があります。