Kubernetesベストプラクティス第2版

第12章 複数のクラスタを管理する 複数のクラスタを管理する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、 、複数のKubernetesクラスタを管理するためのベストプラクティスについて議論する。マルチクラスタ管理とフェデレーションの違い、複数クラスタを管理するためのツール、複数クラスタを管理するための演算パターンなどの詳細に踏み込む。

なぜ複数のKubernetesクラスタが必要なのかと思うかもしれない。Kubernetesクラスタは、多くのワークロードを単一のクラスタに統合するために構築されたのだろう？これは事実だが、地域をまたぐワークロード、爆風半径の懸念、規制遵守、特殊化したワークロードなど、複数のクラスタが必要になるシナリオもある。

これらのシナリオについて議論し、Kubernetesで複数のクラスタを管理するためのツールとテクニックを探る。

なぜ複数のクラスターなのか？

Kubernetesを採用する場合、おそらく複数のクラスタを持つことになるだろうし、ステージング、ユーザ受け入れテスト（UAT）、または開発から本番を切り離すために複数のクラスタで始めることもあるだろう。Kubernetesは、クラスタをより小さな論理構成に分割する論理的な方法である名前空間によって、いくつかのマルチテナント機能を提供する。名前空間では、ロールベースアクセスコントロール（RBAC）、クォータ、Podセキュリティポリシー、ネットワークポリシーを定義し、ワークロードを分離できる。これは、複数のチームやプロジェクトを分離するのに最適な方法だが、マルチクラスターアーキテクチャを構築しなければならないかもしれない他の懸念事項もある。 マルチクラスターと単一クラスターアーキテクチャの使用を決定する際に考えるべき懸念事項：

• 爆発半径

• コンプライアンス

• セキュリティ

• ハード・マルチテナント

• 地域別ワークロード

• 特殊化ワークロード

アーキテクチャを考える際、ブラスト半径は最重要課題である。これは、マルチクラスターアーキテクチャを設計するユーザが抱える主な懸念事項の1つである。マイクロサービスアーキテクチャでは、サーキットブレーカー、再試行、バルクヘッド、レート制限を採用して、システムへのダメージの範囲を抑制している。インフラレイヤーにも同様の設計をすべきであり、複数のクラスタはソフトウェアの問題による障害の連鎖の影響を防ぐのに役立つ。例えば、500のアプリケーションに対応するクラスタが1つあり、プラットフォームに問題が発生した場合、500のアプリケーションの100％が停止する。その500のアプリケーションを提供する5つのクラスタでプラットフォームの問題が発生した場合、アプリケーションの20%にしか影響が及ばない。この欠点は、5つのクラスタを管理する必要があること、そして単一クラスタほどコンソリデーション率が良くないことだ。Dan Woods氏は、本番Kubernetes環境における実際のカスケード障害について素晴らしい記事を書いている。大規模な環境でマルチクラスターアーキテクチャを検討したくなる理由の素晴らしい例だ。

PCI（Payment Card Industry）、HIPAA（Health Insurance Portability and Accountability）、その他のワークロードに対する特殊化があるため、コンプライアンスは ...