この記事では、Azure Kubernetes Fleet Manager を使用して、ハブ クラスターをコントロール プレーンとして使用する Kubernetes リソース管理の概念について説明します。
概要
複数のクラスター間で Kubernetes リソースを管理することは、プラットフォーム管理者とアプリケーション開発者の両方にとって大きな課題となります。 組織が 1 つのクラスターを超えて Kubernetes インフラストラクチャをスケーリングする場合、多くの場合、リソースの分散、整合性のメンテナンス、手動管理のオーバーヘッドに関連する複雑さが発生します。 各クラスターを個別に管理する従来のアプローチでは、運用サイロが作成され、フリートのサイズが大きくなるにつれて保守がますます困難になります。
マルチクラスター管理の課題
いくつかのクラスターから複数クラスターの Kubernetes インフラストラクチャへの移行により、従来のコンテナー オーケストレーションを超える新しいカテゴリの運用上の課題が導入されています。 これらの課題は、組織内のさまざまな利害関係者グループに対して異なる方法で現れ、それぞれ要件と制約が異なります。
プラットフォーム管理者は、 多くの場合、次のようなさまざまな理由で、Kubernetes リソースを複数のクラスターにデプロイする必要があります。
- インフラストラクチャ アプリケーションの実行: 運用上の可視性とコンプライアンスを維持するには、監視ソリューション (Prometheus、Grafana)、継続的配置ツール (Flux、ArgoCD)、ネットワーク ポリシー、セキュリティ スキャナー、ログ アグリゲーターなどの重要なシステム コンポーネントをすべてのクラスターに一貫してデプロイする必要があります。
- リソースの最適化: 組織は、さまざまなコスト プロファイル (スポット インスタンスとオンデマンド)、特殊なハードウェア機能 (GPU 対応ノード、高メモリ インスタンス)、パフォーマンス レベルなど、さまざまな特性を持つクラスターの使用率を向上させ、要件と予算の制約に基づいてワークロードの配置を最適化したいと考えています。
- コンプライアンスとガバナンス: 規制フレームワークでは、特定のデータ所在地の要件、セキュリティ制御、および監査機能が必要であり、クラスターの選択とリソースの配置戦略を慎重に行う必要があります。
同様に、 アプリケーション開発者 は、多くの場合、次のようなさまざまな理由で、Kubernetes リソースを複数のクラスターにデプロイする必要があります。
- 地理的分散: 最新のアプリケーションでは、待機時間を最小限に抑え、データ主権の要件に準拠し、最適なユーザー エクスペリエンスを提供するために、エンド ユーザーとの近接性を好むことがよくあります。 近接優先では、一貫性と調整を維持しながら、複数の地理的リージョンにアプリケーション コンポーネントをデプロイする必要があります。
- 高可用性: ビジネスクリティカルなアプリケーションでは、リージョンの障害、インフラストラクチャの障害、または計画メンテナンス期間中でも、サービスの可用性を維持する必要があります。 自動フェールオーバー機能を備えたリージョン間デプロイにより、ビジネス継続性が確保され、厳格なサービス レベル アグリーメント (SLA) 要件が満たされます。
組織が複数のクラスターを超えてスケーリングしようとすると、手動のマルチクラスター管理の複雑さが明らかになります。 小規模なクラスターフリートに対して機能する手動プロセスは、インフラストラクチャの拡大に伴ってすぐにボトルネックになります。
手動によるマルチクラスター管理の課題
- 運用の複雑さ: 複数のクラスター間でリソースを個別に作成、更新、追跡する管理上の負担は、フリート のサイズに伴って指数関数的に増加します。 各クラスターには個別の認証、コンテキストの切り替え、手動検証が必要であり、時間の投資が増加し、人為的ミスの可能性が高くなります。
- 構成の誤差: 一元的な制御メカニズムがないと、手動プロセスによって、時間の経過と伴うクラスター間の不整合が必然的に発生します。 これらの不整合は、異なるリソース バージョン、さまざまな構成、または不足しているコンポーネントとして現れる可能性があり、予期しない動作とデバッグの課題が生じる可能性があります。
- スケーラビリティの制限: 小規模なフリートに対して適切に機能する手動プロセスは、組織が数十または数百のクラスターにスケーリングするにつれて、ますます実用的ではなくなります。 管理オーバーヘッドの線形増加は、最終的に使用可能な管理容量を超えます。
- 可視性の欠如: 複数のクラスターにわたるリソース バージョン、リソース正常性、運用メトリックの包括的な追跡には、大幅な調整とカスタム ツールが必要です。 チームは、一元的な可観測性がなければ、状況認識を維持し、問題に効果的に対応するために苦労します。
マルチクラスター リソース管理の全体的なアーキテクチャ
Azure Kubernetes Fleet Manager は、 オープン ソースのクラウドネイティブ プロジェクト と Kubernetes ネイティブ API に基づいて構築された包括的なプラットフォームを通じて、マルチクラスター リソース管理の基本的な課題に対処します。 このソリューションでは、カスタム リソース定義 (CRD) の能力と柔軟性を利用して、Kubernetes の宣言型モデルをマルチクラスター シナリオに拡張します。 このアプローチでは、使い慣れたKubernetesの運用モデルを維持しつつ、スケールの大きなフリート運用を処理する能力を拡張します。 ソリューションの主な原則と利点を次に示します。
ハブアンドスポーク コントロール プレーン
ハブアンドスポーク アーキテクチャでは、一元化されたハブ クラスターをコントロール プレーンとして指定するため、各クラスターを個別に管理する必要がなくなります。 このアーキテクチャ パターンでは、次の機能が提供されます。
- 一元管理: フリート全体の運用に対する単一の制御ポイントで、管理オーバーヘッドを削減します。
- 一貫性のある API エクスペリエンス: インフラストラクチャ全体で均一な対話を行い、使いやすさを確保します。
- 監視機能の強化: 一元的な監視と管理機能により、状況認識を向上させ、問題の解決を迅速化します。
Kubernetes ネイティブ拡張機能モデル
CNCF プロジェクト上に構築されたこのソリューションは、Kubernetes の宣言型モデルを置き換えるのではなく、カスタム リソース定義 (CRD) を使用して拡張します。 これにより、次の内容が保証されます。
- 知識: Kubernetes の実践者は、既存の知識とツールを活用できます。
- 互換性: 既存の Kubernetes ワークフローとツールとのシームレスな統合。
- Cloud-Native アラインメント: クラウドネイティブの原則への準拠と CNCF エコシステムとの互換性。
高度なスケジュール設定とロールアウト戦略
このソリューションには、高度なスケジューリング メカニズムとプログレッシブ ロールアウト戦略が組み込まれており、次の機能を実現します。
- 宣言型配置ポリシー: コスト、リソースの可用性、地理的な場所などのクラスター特性に基づくワークロードの配置。
- プログレッシブ ロールアウト: リスクを最小限に抑えるために、安全メカニズムを使用して更新プログラムの展開を制御します。
- ドリフト管理: クラスター間で一貫したリソース バージョンと構成を確保し、運用上の不整合を軽減します。
主な利点
Azure Kubernetes Fleet Manager を採用することで、組織は以下を実現できます。
- スケーラビリティ: 数個のクラスターから数百個まで、あらゆる規模のフリートを効率的に管理できます。
- 運用効率: 自動化と一元的な制御により、手作業と人為的ミスを減らします。
- 回復性: インテリジェントなリソース配置とフェールオーバー戦略を使用して、高可用性とディザスター リカバリーを確保します。
Azure Kubernetes Fleet Manager API を使用してマルチクラスター ワークロードを管理する方法の YAML ファイルの例を次の図に示します。
