Kubernetes アーキテクチャに関する 8 つの質問

Kubernetes のアーキテクチャは大規模な組織には適していますが、中小規模の組織にとっては複雑すぎる可能性があります。

[[338491]]

オープンソースのコンテナ オーケストレーターである Kubernetes は、組織がコンテナ化されたアプリケーションを展開するための事実上のソリューションとなっています。これには、Kubernetes が高度な信頼性、自動化、スケーラビリティを提供するという事実など、いくつかの理由があります。それにもかかわらず、業界の中には、Kubernetes アーキテクチャは複雑すぎると考える人もいます。 6年以上使用されていますが、まだ多くの欠点があります。これらの欠点の一部は Kubernetes 自体に固有のものですが、その他の欠点はプラットフォームを中心に成長したエコシステムの産物です。

Kubernetes を導入する前に、企業は次のオープンソース コンテナ オーケストレーターに関するいくつかの問題を考慮する必要があります。

1. Kubernetesは大規模企業向けに設計されている

まず、Kubernetes アーキテクチャは常に、非常に大規模なアプリケーション環境を管理する必要がある組織向けに構築されています。 Kubernetes は Google にとって素晴らしいツールです (Borg オーケストレーターは、オープンソースの Kubernetes プロジェクトの基礎を形成しました)。 Netflix、Facebook、AWS など、数十のデータセンターと、それらに分散された数千のアプリケーションやサービスを持つ大規模企業でも同様です。

しかし、単一のデータセンターを持ち、そこに数十個のアプリケーションしか導入されていない小規模な組織の場合、Kubernetes アーキテクチャは間違いなく過剰であり、裏庭の庭の土を掘り返すためにブルドーザーを運転するようなものかもしれません。大規模に使用されない限り、設定と管理には多くの問題を解決する必要があります。

2. Kubernetesには多くのディストリビューションがある

Kubernetes アーキテクチャのもう 1 つの問題は、Kubernetes のディストリビューションが多数存在し、それに関連するさまざまなツール、哲学、および視点が多数存在することです。

もちろん、ある程度、どのオープンソース エコシステムでも断片化は発生します。たとえば、RedHat Linux と Ubuntu Linux ではパッケージ マネージャーや管理ツールなどが異なります。ただし、RedHat と Ubuntu の類似点は相違点をはるかに上回ります。 Red Hat システムを使用している管理者は、Ubuntu に移行する場合、新しいツールの使い方を習得するために 6 か月を費やす必要はありません。

業界の専門家は、Kubernetes については同じことは当てはまらないと考えています。現在 OpenShift を使用していて、VMware Tanzu に切り替えたい場合、学習曲線は非常に困難になります。どちらの Kubernetes ディストリビューションも同じ基盤プラットフォームである Kubernetes を使用していますが、追加するアプローチとツールはまったく異なります。

クラウドベースの Kubernetes サービスでも同様の分裂が見られます。 Google Kubernetes Engine (GKE) は、Amazon EKS (AWS クラウドに相当) などのプラットフォームとはまったく異なるユーザー エクスペリエンスと管理ツール スイートを備えています。

もちろん、これは Kubernetes アーキテクチャ自体のせいではなく、さまざまなベンダーが自社の Kubernetes 製品を差別化しようとした結果です。しかし、Kubernetes ユーザーの観点から見ると、これは依然として大きな問題です。

3. Kubernetesは複数の部分からなるプラットフォームです

Kubernetes はプラットフォームとして考えられていますが、実際には 6 つ以上の異なるコンポーネントで構成されています。つまり、Kubernetes をインストールまたは更新するときには、各コンポーネントを個別に処理する必要があります。そして、ほとんどの Kubernetes ディストリビューションには、これらの操作を実行するための自動化ソリューションが欠けています。

もちろん、Kubernetes は多くの部分が連携して動作する必要がある複雑なプラットフォームです。しかし、他の複雑なプラットフォームと比較すると、Kubernetes はさまざまな部分を簡単に管理できる全体に統合する機能が特に不十分です。一般的な Linux ディストリビューションには、さまざまなソフトウェアも含まれています。しかし、ユーザーはそれらを集中的かつ簡素化された方法でインストールし、管理できます。 Kubernetes アーキテクチャの場合はそうではありません。

4. Kubernetesは自動的に高可用性を保証するものではない

Kubernetes を使用する理由として最もよく挙げられるのは、Kubernetes がアプリケーションを魔法のような方法で管理し、インフラストラクチャの一部に障害が発生してもアプリケーションが決して失敗しないことを保証することです。

実際、Kubernetes アーキテクチャは、クラスター内のどこにワークロードを配置するかについてインテリジェントかつ自動化された決定を下すことができます。ただし、Kubernetes は高可用性を実現するための万能薬ではありません。たとえば、マスター ノードが 1 つだけの本番環境で実行され、クラスター全体をシャットダウンする方法になります (プライマリ サーバーがダウンすると、基本的にクラスター全体の機能が停止します)。

また、Kubernetes は、クラスター内で実行されているさまざまなワークロード間でのリソースの正しい割り当てを自動的に保証することもできません。これを設定するには、ユーザーがリソース クォータを手動で設定する必要があります。

5. Kubernetesを手動で制御するのは難しい

Kubernetes では、高可用性を実現するためにかなりの手動介入が必要ですが、手動での制御が必要な場合、手動制御が非常に困難になります。

確かに、コンテナが正常かどうかを判断したり、クラスター内の特定のサーバーでワークロードを強制的に実行したりするために Kubernetes が実行するプローブのタイミングを変更する方法はあります。ただし、Kubernetes アーキテクチャは、管理者がこれらの変更を手動で行うことを想定して設計されていません。

前述のように、Kubernetes は何よりもまず Web スケールのデプロイメントを目的としており、それは理にかなっています。何千ものサーバーと何百ものワークロードがある場合、多くのことは手動で構成されません。しかし、小規模な企業で、クラスター内でのワークロードの構造をより細かく制御したい場合、Kubernetes ではそれを実現するのは難しい場合があります。

6. Kubernetesの監視とパフォーマンスの最適化には課題がある

Kubernetes は、ワークロードを稼働状態に保つよう努めます (ただし、前述のように、その能力は、ユーザーが設定するマネージャーの数やリソース割り当ての構成方法などの要因によって異なります)。

しかし、Kubernetes アーキテクチャは、ユーザーがワークロードを監視したり、最適なパフォーマンスを確保したりするのに役立ちません。問題が発生してもユーザーに警告されず、クラスターから監視データを収集することも容易ではありません。 Kubernetes ディストリビューションに付属するほとんどの監視ダッシュボードも、環境の詳細な可視性を提供できません。サードパーティのツールを導入すると可視性は高まりますが、Kubernetes を実行するには、これらのツールをセットアップ、学習、管理する必要があります。

同様に、Kubernetes はユーザーがコストを最適化するのを支援するのが得意ではありません。クラスター内のサーバーが 20% の容量しか使用されていない場合は通知されません。これは、過剰にプロビジョニングされたインフラストラクチャにお金を無駄にしている可能性があることを意味します。繰り返しになりますが、サードパーティのツールはユーザーがこのような課題に対処するのに役立ちますが、複雑さが増す可能性があります。

7. Kubernetesはすべてをコードに集約する

Kubernetes では、ほぼすべてのタスクでユーザーがコードを記述する必要があります。通常、このコードは YAML ファイルの形式をとり、Kubernetes コマンドラインで適用する必要があります。

多くの人は、Kubernetes アーキテクチャのオールコード要件をバグではなく機能と見なすでしょう。ただし、単一のアプローチとツール (YAML ファイルなど) を使用してプラットフォーム全体を管理することは可能ですが、Kubernetes では、必要とするユーザー向けに他のオプションも提供されるのは事実です。

場合によっては、ユーザーは、単純なワークロードをデプロイするために、長い YAML ファイルを作成したり (または GitHub からファイルを取得して、環境に合わせてランダ​​ムな部分を手動で調整したり) したくないことがあります。ユーザーは、ボタンを押したり、簡単なコマンドを実行したりしたいと考えています (ここでは、多数のパラメーターを必要としない kubectl コマンド (その多くは、コピーして貼り付ける必要のあるデータの文字列で構成されます))。 Kubernetes で実行する必要がある簡単なことがいくつかあります。しかし、これはめったに起こりません。

8. Kubernetesはすべてを制御したい

Kubernetes の最後の問題は、他の種類のシステムとうまく連携するように設計されていないことです。ユーザーがアプリケーションを展開および管理するために使用する唯一のプラットフォームになることを目指しています。

すべてのワークロードがコンテナ化されており、Kubernetes によってオーケストレーションできる場合、これは素晴らしい結果となります。しかし、コンテナとして実行できないレガシー アプリケーションがある場合はどうなるでしょうか?あるいは、ワークロードの一部を Kubernetes クラスターで実行し、残りの一部を外部で実行したい場合はどうすればよいでしょうか? Kubernetes は、これらのことを行うためのネイティブ機能を提供していません。すべてを常にコンテナ内で実行したいという前提で設計されています。

結論は

Kubernetes は、大規模なコンテナ化されたアプリケーションをオーケストレーションするための強力なツールです。 Kubernetes が適しているユースケースは数多くあります。

しかし、Kubernetes アーキテクチャにはいくつかの欠点もあります。全体的に、管理すべきレガシー ワークロードがある場合や、Kubernetes がもたらす複雑さを正当化するほどの規模で展開されていない場合は、これは最適なソリューションではありません。 Kubernetes がその価値を完全に証明するには、IT エコシステムの特定の領域で享受している評判に完全に匹敵するように、これらの問題に対処する必要があります。