Kubernetesの問題点と限界について話す

[[394224]]

2014 年にリリースされた Kubernetes は、コンテナ オーケストレーションの分野で事実上の標準となっています。 Kubernetes について語る開発者は、上記の現象を何度も繰り返すことになると思います。下の図に示すように、現在、ほとんどの個人またはチームはコンテナの管理に Kubernetes を選択しており、75% の人が本番環境で Kubernetes を使用しています。

図1 - Kubernetesコンテナオーケストレーション[^1]

誰もが Kubernetes を学習し、使用するという状況では、Kubernetes の制限についても明確に理解しておく必要があります。 Kubernetes はコンテナ オーケストレーションの分野でほとんどの問題を解決できますが、処理が困難または不可能なシナリオもまだいくつかあります。これらの潜在的なリスクを明確に理解することによってのみ、このテクノロジーをより良く習得することができます。この記事では、クラスター管理とアプリケーション シナリオという 2 つの側面から、Kubernetes コミュニティの現在の開発といくつかの制限について説明します。

クラスター管理

クラスターは連携して動作できるコンピューターのグループです。クラスター内のすべてのコンピューターを全体として見ることができます。すべてのリソース スケジューリング システムはクラスターに基づいて管理されます。クラスター内のすべてのマシンがリソース プールを構成します。この巨大なリソース プールは、コンピューティング タスクを実行するために実行されるコンテナーにリソースを提供します。ここでは、Kubernetes クラスター管理が直面するいくつかの複雑な問題について簡単に説明します。

水平スケーラビリティ

クラスター サイズは、リソース管理システムを評価する際に注意する必要がある重要な指標の 1 つです。ただし、Kubernetes が管理できるクラスターのサイズは、業界の他のリソース管理システムよりもはるかに小さくなります。クラスターのサイズが重要なのはなぜですか?まず、同様に重要なもう 1 つの指標であるリソース使用率について見てみましょう。多くのエンジニアは、パブリック クラウド プラットフォーム上のリソースを申請したことがないかもしれません。これらのリソースは非常に高価です。 AWS上のホストと同様の構成（8CPU、16GB）の仮想マシンインスタンスを申請する場合、月額約150ドル、つまり約1,000人民元かかります[^2]。

図2 - AWS EC2の価格

ほとんどのクラスターでは、クラスター内のノードとして 48 CPU または 64 CPU の物理マシンまたは仮想マシンを使用します。クラスターに 5,000 個のノードを含める必要がある場合、これらのノードのコストは月額約 8,000,000 米ドル、つまり約 50,000,000 人民元になります。このようなクラスターでは、リソース使用率を 1% 増加させることは、1 か月あたり 50 万人民元の節約に相当します。

ほとんどのオンライン タスクのリソース使用率は非常に低いです。クラスターが大きいほど、より多くのワークロードを実行でき、ピーク期間と谷期間のあるさまざまな負荷を同時に展開することでオーバーセリングを実現でき、クラスターのリソース使用率を大幅に向上できます。単一クラスター内のノード数が十分に多い場合、異なるタイプのタスクを展開するときに、より合理的な組み合わせが得られ、さまざまなサービスのピーク期間を完全にずらすことができます。

Kubernetesコミュニティは、単一のクラスターが最大5,000ノードをサポートし、ポッドの総数は150,000を超えず、コンテナの総数は300,000を超えず、ノードあたりのポッドの数は100を超えないと主張しています[^3]。数万ノードのApache Mesosクラスターや5万ノードのMicrosoft YARNクラスター[^4]と比較すると、Kubernetesのクラスターサイズは桁違いに小さくなります。 Alibaba CloudのエンジニアはKubernetesのさまざまなコンポーネントを最適化することで5桁のクラスターサイズを実現していますが、他のリソース管理方法と比較するとまだ大きな差があります[^5]。

図 3 - Apache Mesos と Hadoop YARN

Kubernetesコミュニティは、単一のクラスターで5,000ノードをサポートできると主張しており、コミュニティではさまざまな統合テストを行って、あらゆる変更がスケーラビリティに影響を与えないことを確認していますが[^6]、Kubernetesは非常に複雑であり、使用するすべての機能で拡張プロセス中に問題が発生しないことを保証する方法はないことに注意することが重要です。実稼働環境では、クラスターを 1,000 ～ 1,500 ノードに拡張するとボトルネックが発生する可能性もあります。

すべての大企業は、より大規模な Kubernetes クラスターを実装したいと考えていますが、これは数行のコードを変更するだけで解決できる単純な問題ではありません。 Kubernetes の一部の機能の使用を制限する必要があるかもしれません。拡張プロセス中に、etcd、API サーバー、スケジューラ、コントローラのすべてに問題が発生する可能性があります。コミュニティの一部の開発者はすでにこれらの問題のいくつかに気付いており、例えばAPIサーバーの負荷を軽減するためにノードにキャッシュを追加するなど[^7]、同様の変更を推進するのは依然として困難です。高い理想を持つ人々は、コミュニティ内で同様のプロジェクトを推進しようと試みることができます。

マルチクラスタ管理

単一クラスターの容量がどれだけ大きくても、企業が直面する問題を解決することはできません。 Kubernetes クラスターが将来 50,000 ノードの規模に到達したとしても、複数のクラスターを管理する必要があります。マルチクラスター管理も、Kubernetes コミュニティが現在検討している方向性です。コミュニティ内のマルチクラスター関心グループ（SIG マルチクラスター）は現在、関連作業を完了させているところです[^8]。著者の意見では、Kubernetes のマルチクラスター アプローチは、リソースの不均衡、クラスター間のアクセスの難しさ、運用および管理コストの増加という 3 つの大きな問題につながります。ここでは、オープンソース コミュニティと業界で現在参照および選択できるいくつかのソリューションについて説明します。

kubefed

まず最初に紹介するのは、Kubernetes コミュニティが提供するソリューションである kubefed です。また、クラスター間のリソースおよびネットワーク管理機能も提供します。コミュニティのマルチクラスター インタレスト グループ (SIG Multi-Cluster) がこのプロジェクトの開発を担当しています。

図4 - Kubernetesフェデレーション

kubefed は、集中化されたフェデレーション コントロール パネルを通じて複数のクラスター内のメタデータを管理します。上位レベルのコントロール パネルは、マネージャー グループ内のリソースに対応するフェデレーション オブジェクトを作成します。例: FederatedDeployment:

種類: フェデレーテッドデプロイメント
...
仕様:
  ...
  上書き:
  #クラスター1にオーバーライドを適用する
    - クラスター名: クラスター1
      クラスターオーバーライド:
        #レプリカフィールドを5に設定する
        - パス: "/spec/replicas"  
          値: 5
        #最初のコンテナのイメージを設定する
        - パス: "/spec/template/spec/containers/0/image"  
          値: "nginx:1.17.0-alpine"  
        # アノテーション「foo: bar」が存在することを確認する
        - パス: "/metadata/annotations"  
          op: 「追加」  
          価値：
            foo: バー
        # 注釈を確実に付ける 鍵  「foo」は存在しません
        - パス: "/metadata/annotations/foo"  
          op: 「削除」  
        # 引数`-q`を追加します 引数リストのインデックス0
        # 既存の引数があれば、当然シフトします 
        - パス: "/spec/template/spec/containers/0/args/0"  
          op: 「追加」  
          値: "-q"  

上部のコントロール パネルは、フェデレーション オブジェクト FederatedDeployment の仕様ファイルに従って対応するデプロイメントを生成し、それを下部のクラスターにプッシュします。下位クラスターは、デプロイメントの定義に従って、特定の数のレプリカを作成できます。

図5 - 連合オブジェクトから通常のオブジェクトへ

FederatedDeployment は、最もシンプルな配布戦略です。実稼働環境では、フェデレーション クラスターを通じて災害復旧などの複雑な機能を実現したいと考えています。この場合、ReplicaSchedulingPreference を使用して、異なるクラスターでよりインテリジェントな分散戦略を実装できます。

 APIバージョン: scheduling.kubefed.io/v1alpha1
種類: レプリカスケジュール設定
メタデータ:
名前: テストデプロイメント
  名前空間: test-ns
仕様:
  ターゲット種別: フェデレーテッドデプロイメント
  合計レプリカ数: 9
  クラスター:
    答え:
      最小レプリカ数: 4
      最大レプリカ数: 6
      重量: 1
    バ：
      最小レプリカ数: 4
      最大レプリカ数: 8
      重量: 2

上記のスケジューリング戦略により、異なるクラスター間のワークロードの重み付けを実現し、クラスターのリソースが不足している場合や問題が発生した場合にインスタンスを他のクラスターに移行できます。これにより、サービス展開の柔軟性と可用性が向上するだけでなく、インフラストラクチャ エンジニアは複数のクラスターの負荷をより適切に分散できるようになります。

kubefed の主な機能は、複数の緩いクラスターを強力に結合された連合クラスターに結合し、より高度なネットワークおよびデプロイメント機能を提供することで、クラスター間のリソースの不均衡や接続性の問題をより簡単に解決できるようにすることだと考えられます。ただし、このプロジェクトの焦点にはクラスターのライフサイクル管理は含まれていません。

クラスターインターフェース

Cluster API は、Kubernetes コミュニティにおけるマルチクラスター管理関連のプロジェクトでもあります。このプロジェクトは、Cluster Lifecycle Group (SIG Cluster-Lifecycle) によって開発されています。その主な目的は、宣言型 API を通じて複数のクラスターの準備、更新、および操作を簡素化することです。その責任範囲はプロジェクトの設計提案書に記載されています[^9]。

図6 - クラスターAPIの概念

このプロジェクトで最も重要なリソースは、Kubernetes クラスター内のノードを表す Machine です。リソースが作成されると、プロバイダー固有のコントローラーは、マシン定義に基づいて新しいノードを初期化してクラスターに登録し、リソースが更新または削除されたときにユーザーの状態を実現するための操作も実行します。

この戦略は、Alibaba のマルチクラスター管理アプローチに多少似ています。どちらも宣言型 API を使用してマシンとクラスターのステータスを定義し、Kubernetes ネイティブの Operator モデルを使用して上位レベルのクラスター内の下位レベルのクラスターを管理します。これにより、クラスタの運用・保守コストが大幅に削減され、クラスタの運用効率が向上します[^10]。ただし、同様のプロジェクトでは、クラスター間のリソース管理とネットワーク管理は考慮されていません。

アプリケーションシナリオ

このセクションでは、アプリケーション配布方法の現状、バッチ スケジューリング タスク、クラスターでのハード マルチテナンシーのサポートなど、Kubernetes の興味深いアプリケーション シナリオについて説明します。これらはコミュニティの懸念事項であり、Kubernetes の現在の盲点でもあります。

アプリケーションの配布

Kubernetes メイン プロジェクトでは、Deployment、StatefulSet、DaemonSet など、アプリケーションをデプロイするための基本的な方法がいくつか提供されています。これらのリソースは、それぞれ、ノード上のステートレス サービス、ステートフル サービス、デーモンに適しています。これらのリソースは最も基本的な戦略を提供できますが、より複雑なアプリケーションを処理することはできません。

図7 - Kubernetesアプリケーション管理

CRD の導入により、コミュニティのアプリケーション管理グループ (SIG Apps) は基本的に Kubernetes メイン リポジトリに大きな変更を導入しません。ほとんどの変更は既存のリソースに対するパッチです。一度だけ実行される DaemonSet[^11]や、カナリアデプロイメントやブルーグリーンデプロイメントなどの機能など、多くの一般的なシナリオでは、StatefulSetが初期化コンテナ内でスタックし、ロールバックや更新ができなくなるなど、現在のリソースに関する多くの問題もあります[^12]。

コミュニティが Kubernetes でより基本的なリソースを維持したくないのは理解できます。いくつかの基本的なリソースでシナリオの 90% をカバーでき、残りの複雑なシナリオは CRD を通じて他のコミュニティによって実装できます。しかし、著者は、コミュニティが上流でより高品質なコンポーネントを実装できれば、これはエコシステム全体にとって価値があり重要なものになると考えています。読者が Kubernetes プロジェクトの貢献者になりたい場合、SIG Apps は適切な選択肢ではない可能性があることに注意してください。

バッチスケジューリング

機械学習、バッチ処理タスク、ストリーミングタスクなどのワークロードの運用は、Kubernetes の誕生以来の強みではありませんでした。ほとんどの企業は、Kubernetes を使用してオンライン サービスを実行し、ユーザー リクエストを処理し、Yarn によって管理されるクラスターを使用してバッチ処理負荷を実行します。

hadoop-ヤーン

図 8 - Hadoop Yarn

オンラインタスクとオフラインタスクは、多くの場合、まったく異なる仕事です。ほとんどのオンライン タスクは、異なるマシンに移行できるステートレス サービスであり、相互に強い依存関係を持つことはほとんどありません。ただし、多くのオフライン タスクのトポロジは非常に複雑です。一部のタスクでは複数のジョブを一緒に実行する必要がありますが、一部のタスクは依存関係に従って順番に実行する必要があります。この複雑なスケジューリング シナリオは、Kubernetes では処理が困難です。

Kubernetes スケジューラがスケジューリング フレームワークを導入する前は、すべての Pod はスケジューラによって互いに無関係であるとみなされていました。しかし、スケジューリングフレームワークを使用すると、PodGroup[^13]などのより複雑なスケジューリング戦略をスケジューリングシステムに実装でき、これにより、Podのグループが同時にスケジュールされることが保証されます。これは、Spark および TensorFlow タスクに非常に役立ちます。

 # PodGroup CRD 仕様
APIバージョン: scheduling.sigs.k8s.io/v1alpha1
種類: PodGroup
メタデータ:
名前: nginx
仕様:
  スケジュールタイムアウト秒数: 10
  最小メンバー: 3
 ---  
 #ポッドがグループに属していることを示すために、ラベル `pod- group .scheduling.sigs.k8s.io`を追加します。  
ラベル:
  ポッドグループ.scheduling.sigs.k8s.io: nginx

VolcanoもKubernetes上に構築されたバッチタスク管理システムです[^14]。機械学習、ディープラーニング、その他のビッグデータ アプリケーションを処理でき、TensorFlow、Spark、PyTorch、MPI などの複数のフレームワークをサポートします。

図9 - 火山

Kubernetes はいくつかのバッチ処理タスクを実行できますが、この分野で Yarn などの古いリソース管理システムを置き換えるにはまだ遠い道のりです。長い間、ほとんどの企業は、異なるタイプのワークロードをそれぞれ管理および実行するために、Kubernetes と Yarn の両方のテクノロジー スタックを維持することになると思います。

ハードマルチテナント

マルチテナントとは、同じソフトウェア インスタンスが異なるユーザー グループにサービスを提供できることを意味します。 Kubernetes マルチテナントとは、複数のユーザーまたはユーザー グループが同じ Kubernetes クラスターを使用することを意味します。現在、Kubernetes がハード マルチテナント サポート (つまり、同じクラスター内の複数のテナントが互いに影響を及ぼさず、互いの存在を認識できない) を実現することは依然として困難です。

ハードマルチテナンシーは、Kubernetes において非常に重要かつ難しいトピックです。シェアアパートは、複数の入居者が家のインフラストラクチャを共有する典型的なマルチテナントシナリオです。ハードマルチテナンシーでは、複数のゲストが互いに影響を及ぼさないことが求められます。これがどれほど難しいかは想像できるでしょう。 Kubernetesコミュニティには、関連する問題について議論し、調査するためのワーキンググループもあります[^15]。しかし、これに興味を持つエンジニアは多いものの、成果は非常に限られています。

図10 - マルチテナント

Kubernetes は名前空間を使用して仮想マシン グループを分割しますが、真のマルチテナントを実現することは困難です。マルチテナントサポートは具体的に何を行うのでしょうか?マルチテナントの利点は次のとおりです。

Kubernetes によってもたらされる追加の展開コストは、小規模なクラスターでは非常に高くなります。安定した Kubernetes クラスターには通常、etcd を実行するマスターノードが少なくとも 3 つ必要です。ほとんどのクラスターが小規模なクラスターである場合、これらの追加マシンは高い追加コストをもたらします。

Kubernetes で実行されるコンテナでは、物理マシンと仮想マシンを共有する必要がある場合があります。開発者の中には、社内の他の事業によって自社のサービスが影響を受けているという経験をした人もいるかもしれません。これは、ホスト上のコンテナーが CPU とメモリのリソースを分離できるが、I/O、ネットワーク、CPU キャッシュなどのリソースを分離できないためです。これらのリソースを分離するのは比較的困難です。

Kubernetes がハードマルチテナンシーを実現できれば、クラウド サービス プロバイダーや小規模クラスターのユーザーにとってメリットになるだけでなく、異なるコンテナー間の影響を分離し、潜在的なセキュリティ問題を防ぐこともできます。しかし、現段階ではこれを達成するのはまだ困難です。

要約する

それぞれのテクノロジーには独自のライフサイクルがあります。技術レベルが低いほどライフサイクルは長くなり、技術レベルが高いほどライフサイクルは短くなります。 Kubernetes は現在コンテナの世界をリードしていますが、将来を予測できる人は誰もいません。私たちは、手元にあるツールの長所と短所を常に認識し、Kubernetes の設計の本質を学ぶために時間を費やす必要があります。しかし、将来 Kubernetes が過去のものになったとしても、それを置き換えるより優れたツールが登場するので、私たちは喜ぶべきです。

[^1]: Kubernetes とコンテナのセキュリティと採用動向 https://www.stackrox.com/kubernetes-adoption-security-and-market-share-for-containers/

[^2]: AWS 料金計算ツール https://calculator.aws/#/createCalculator/EC2

[^3]: 大規模クラスターに関する考慮事項 https://kubernetes.io/docs/setup/best-practices/cluster-large/

[^4]: Microsoft が世界最大の YARN クラスターでエクサバイト分析を推進する方法 https://azure.microsoft.com/en-us/blog/how-microsoft-drives-exabyte-analytics-on-the-world-s-largest-yarn-cluster/

[^5]: ダブル11に向けて準備中！ Ant Financial 向けの 10,000 規模の K8s クラスター管理システムを設計するにはどうすればよいでしょうか? https://www.sofastack.tech/blog/ant-financial-managing-large-scale-kubernetes-clusters/

[^6]: sig-scalability-kubemark ダッシュボード https://testgrid.k8s.io/sig-scalability-kubemark#kubemark-5000

[^7]: ノードローカル API キャッシュ #84248 https://github.com/kubernetes/kubernetes/issues/84248

[^8]: マルチクラスタ特別興味グループ https://github.com/kubernetes/community/tree/master/sig-multicluster

[^9]: クラスター API の範囲と目的 https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/scope-and-objectives.md

[^10]: Kubernetes as a Service の謎を解く – Alibaba Cloud が 10,000 の Kubernetes クラスターを管理する方法 https://www.cncf.io/blog/2019/12/12/demystifying-kubernetes-as-a-service-how-does-alibaba-cloud-manage-10000s-of-kubernetes-clusters/

[^11]: セットアップを容易にするために、各ノードでジョブを 1 回実行します #64623 https://github.com/kubernetes/kubernetes/issues/64623

[^12]: StatefulSet はマニフェストの新しいバージョンにアップグレードされません #78007 https://github.com/kubernetes/kubernetes/issues/78007

[^13]: PodGroup CRD に基づくコスケジューリング https://github.com/kubernetes-sigs/scheduler-plugins/tree/master/kep/42-podgroup-coscheduling

[^14]: Volcano · Kubernetesネイティブバッチシステム https://github.com/volcano-sh/volcano

[^15]: Kubernetes マルチテナントワーキンググループ https://github.com/kubernetes-sigs/multi-tenancy