第21章. マルチクラスター・アプリケーションのデプロイ
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
本書を20章まで読んできて、Kubernetesが複雑なトピックであることは明らかだろう。もちろん、ここまで読んできたのであれば、以前より泥臭くなくなっていることを期待している。 1つのKubernetesクラスタでアプリケーションを構築し実行することの複雑さを考えると、なぜ複数のクラスタにアプリケーションを設計しデプロイする複雑さを追加しなければならないのだろうか?
実のところ、現実の世界では、ほとんどのアプリケーションでマルチクラスター・アプリケーション・デプロイが現実のものとなっている。これには多くの理由があり、あなたのアプリケーションはこれらの要件の少なくとも1つに当てはまる可能性が高い。
第一の要件は、冗長性とレジリエンスだ。 クラウドであろうとオンプレミスであろうと、一つのデータセンターは一般的に一つの障害領域となる。猟師が光ファイバーケーブルを使って射撃の練習をしたにせよ、氷嵐による停電にせよ、単にソフトウェアのロールアウトが失敗したにせよ、単一の場所にデプロイされたアプリケーションは完全に失敗し、ユーザを救済する手段を失う可能性がある。多くの場合、単一のKubernetesクラスタは単一の場所に結びついており、したがって単一の障害ドメインとなる。
場合によっては、特にクラウド環境では、Kubernetesクラスタはリージョナルに設計される。リージョナルクラスタは複数の独立したゾーンにまたがっているため、先に説明した基盤インフラの問題に対するレジリエンスが高い。そのようなリージョナルクラスタがレジリエンスに十分であると考えたくなるし、Kubernetes自体が単一障害点になり得るという事実を除けばそうかもしれない。 KubernetesクラスタはどれもKubernetesの特定のバージョン(例えば1.21.3)に縛られており、クラスタのアップグレードによってアプリケーションが壊れる可能性は大いにある。Kubernetesは時折、APIを廃止したり、APIの振る舞いを変更したりする。こうした変更は頻繁に行われるものではなく、Kubernetesコミュニティはこうした変更が事前に通知されるよう配慮している。さらに、多くのテストにもかかわらず、バグがリリースに忍び込むこともある。1つの問題があなたのアプリケーションに影響を与える可能性は低いとはいえ、ほとんどのアプリケーションの寿命(点)で見れば、あなたのアプリケーションがある時点で影響を受ける可能性は高い。 ほとんどのアプリケーションにとって、それは許容できるリスクではない。
マルチクラスターデプロイのもう一つの強力な推進力は、レジリエンス要件に加え、ビジネスやアプリケーションにおける地域的な親和性のニーズである。 例えば、ゲームサーバは、ネットワーク遅延を低減し、プレイ体験を向上させるために、プレイヤーの近くにあることが強く求められる。他のアプリケーションでは、特定の地域内にデータを配置することを要求する法律や規制の要件に従うことがある。どのKubernetesクラスタも特定の場所に縛られているため、特定の地域へのアプリケーションデプロイに対するこうしたニーズは、アプリケーションが複数のクラスタにまたがらなければならないことを意味する。
最後に、単一クラスタ内でユーザを分離する方法は数多くあるが(例えば、名前空間、RBAC、ノードプール(異なる機能やワークロード用に編成されたKubernetesノードの集合体))、Kubernetesクラスタは依然として大部分が単一の協調空間である。 ...