Kubernetesのマルチクラスタについて

投稿日: 2020年12月1日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

Kubernetes環境を単一クラスタで構成するのか、複数クラスタで構成するのかは、それぞれの企業が置かれた状況やニーズに応じていろいろなパターンが考えらます。もちろん単一クラスタには、リソースやコスト面、管理の単純さなど、単一クラスタならではの利点があります。

しかし、Kubernetesはそもそも複数クラスタ デプロイメントへの柔軟な対応を得意としたシステムです。それに応じて、マルチクラスタを採用する企業も増加傾向にあります。VMwareのレポート「The State of Kubernetes, 2020」によれば、Kubernetesを本番環境で使用する企業の20%が50以上ものクラスタを使用しているそうです。

クラスタはCattle

クラウドネイティブの理念としても、いわゆる「Cattle vs. Pet」の考え方をクラスタに適用する流れがあるようです。 クラスタを「ペット」みたいに大事にして、病気になったら治療して、きちんと最期まで面倒を見ましょう、という考え方に対して、家族の一員のように大事にするのではなく「社畜」としてこき使って、使えなくなったらさっさと切り捨てましょう、という考え方です。いや、ペットと比べているのだから「家畜」ですね。企業システムの例えだから、つい社畜と書いてしまいました。いずれにしろ、調子が悪くなったら、しっかりケアして回復させるのではなく、さっさと切り捨てて取り換えましょう、という意味でクラスタをCattleに例えています。クラウドの世界も現実社会のように世知辛くなっています。「きみの代わりは幾らでもいるだよ」と、マスタークラスタから嫌みを言われながら、クラスタは日夜、可用性の実現に励んでいるのです。

しかし、単なるペットと家畜の扱いの違いだけでなく、その数量も重要です。ペットは1、2匹を大事に育てるけれど、家畜は沢山いるという点です。一匹一匹に愛着を持たず、名前も付けず、大量生産、大量消費するのが、クラウドネイティブの理念にもとづく合理性です。書いていて、なんだか段々悲しくなってきました。

そんなわけで、クラスタも大量消費する傾向が、クラウドネイティブの理念上も、Kubernetesの特性上も、自然な流れとなっています。

もちろん、マルチクラスタには、単一クラスタにはない利点がいろいろあります。たとえば、以下のような利点が考えられます。

  • プロセスの隔離 ― クラスタやアプリケーションのアップグレードなどを単独で行え、プロセスが効率化される
  • 潜在的問題の隔離 ― クラスタの障害を孤立化させ、他への影響を回避できる。障害耐性を確立できる
  • 可用性の確保 ― 複数のアベイラビリティゾーン、地域にまたがる可用性を実現できる
  • コンプライアンス ― 各種規制やポリシーの適用範囲を限定させ、コンプライアンス対応を効率化できる（複雑化が避けられる）
  • ユーザーの限定（セキュリティ強化）― 単一クラスタでの全員アクセスに比べると、アクセスを必要とするユーザーを限定でき、セキュリティ管理が容易になる
  • 運用手順の標準化 ― 単一クラスタですべてを賄うのに比べ、個々のクラスタが単純化され、運用手順を標準化できる。よって効率化が進む
  • 特定ベンダーに縛られない ― いわゆるベンダーロックインが回避でき、将来的なスケーリングも容易になる

以上の利点から、Kubernetesのマルチクラスタ化への潮流は今後ますます強まるものと思われます。

Kubernetesの運用を管理するツールも、マルチクラスタをサポートしていることが必須条件になります。たとえば、Kubernetesのバックアップやポータビリティを容易にするKastenのK10も、最新バージョンv3.0で複数クラスタのサポートを強化しています。K10 v3.0では、複数クラスタに対するグローバルな処理、特定クラスタに対する個別処理、独自にグループ分けしたクラスタの論理集合（ディストリビューション）へのカスタム処理など、Kubernetesのマルチクラスタ・マルチテナント環境の多様化に柔軟に対応でき、企業が独自のニーズに合わせて使用できるようになっています。

Kubernetesの運用が多様化する中、それをサポートする適切なツール選択は、企業がKubernetes導入を成功させる重要な鍵となっています。

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。