K8s クラスター容量 - kluster capacity

K8s クラスター容量 - kluster capacity

背景

コンテナ プラットフォームの 3 つの価値、つまり安定性、効率性、コストはすべて容量管理に依存します。容量管理は、Kubernetes クラスター管理の非常に重要な部分です。システム内のリソースが適切に割り当て、使用されることを保証し、リソース不足や無駄によるシステム動作の異常や非効率を回避します。容量管理により、システム リソースの使用をより適切に制御および最適化し、Kubernetes クラスターの安定性と信頼性を確保できます。容量管理により、管理者はシステムをより適切に計画および予測できるようになり、リソース不足による緊急の容量拡張の必要性を回避できるため、システムの保守性と信頼性が向上します。

問題点

K8s クラスター管理者は、多かれ少なかれ次のような問題に悩まされています。

  • 現在のクラスター リソースの使用状況または残りの容量が不明です。
  • クラスター リソースがどれだけ浪費されているかは不明です。
  • クラスター リソースの断片化の現在のレベルがどの程度であるかは不明です。
  • リソース利用効率を向上させるためにスケジューリングポリシー構成値をどのように設定すればよいかが不明です。
  • ...

リソースは典型的な定量化可能な指標です。上記の問題はすべて定量化できます。私たちに欠けているのは便利なツールです。

プロジェクト紹介

kluster-capacity[1]は、実際のオンラインスケジューラの機能をシミュレートすることで上記の問題を解決することを目指しています。現在、容量評価、スケジューリング シミュレーション、クラスター圧縮の 3 つの機能がサポートされています。

能力評価

導入

クラスター内のノードに新しいポッドがスケジュールされると、消費されるリソースはますます多くなります。すべてのリソースを使い果たすことを避けるために、オペレーターが現在のリソースを適時に増やすことができるように、クラスターで使用可能なリソースを監視することが非常に重要です。あるいは、利用可能なリソースを増やすために別の手順を実行します。

クラスター容量には、単一のクラスター ノードの容量が含まれます。容量には、CPU、メモリ、ディスク容量、その他のリソースが含まれます。

残りの割り当て可能な容量全体は推定値です。目標は、残りの割り当て可能なリソースを分析し、使用可能な容量、つまりリソー​​ス要件を考慮してクラスターでスケジュールできる Pod インスタンスの数を見積もることです。

強化

元のクラスター容量に対するいくつかの強化点を次に示します。

  • 既存の Pod をクラスターから直接 Pod テンプレートとして使用するためのサポート。
  • さまざまな Pod テンプレートのバッチ シミュレーションをサポートします。

走る

# 直接使用指定的pod 模板$ ./kluster-capacity ce --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --pods-from-template <path to pod templates> # 使用集群中指定的pod 作为模板$ ./kluster-capacity ce --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --pods-from-cluster <namespace/name key of the pod>

詳細な操作パラメータと機能については、次のコマンドを実行してください。

 $ ./kluster-capacity ce --help

デモ

クラスターが 4 つのノードと 1 つのマスター ノードで実行され、各ノードに 2 つの CPU と 4 GB のメモリがあると仮定します。各ポッドに必要なリソースは、150m CPU と 100Mi メモリです。

 $ ./kluster-capacity ce --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --pods-from-template <path to pod templates> --verbose Pod requirements: - cpu: 150m - memory: 100Mi The cluster can schedule 52 instance(s) of the pod. Termination reason: FailedScheduling: pod (small-pod-52) failed to fit in any node fit failure on node (kube-node-1): Insufficient cpu fit failure on node (kube-node-4): Insufficient cpu fit failure on node (kube-node-2): Insufficient cpu fit failure on node (kube-node-3): Insufficient cpu Pod distribution among nodes: - kube-node-1: 13 instance(s) - kube-node-4: 13 instance(s) - kube-node-2: 13 instance(s) - kube-node-3: 13 instance(s)

クラスター内で実行されているポッドの数が増えると、分析を再度実行したときにスケジュールできるポッドの数は減少します。

 $ ./kluster-capacity ce --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --pods-from-template <path to pod templates> --verbose Pod requirements: - cpu: 150m - memory: 100Mi The cluster can schedule 46 instance(s) of the pod. Termination reason: FailedScheduling: pod (small-pod-46) failed to fit in any node fit failure on node (kube-node-1): Insufficient cpu fit failure on node (kube-node-4): Insufficient cpu fit failure on node (kube-node-2): Insufficient cpu fit failure on node (kube-node-3): Insufficient cpu Pod distribution among nodes: - kube-node-1: 11 instance(s) - kube-node-4: 12 instance(s) - kube-node-2: 11 instance(s) - kube-node-3: 12 instance(s)

出力フォーマット

ce コマンドには、出力を json または yaml としてフォーマットする --output (-o) フラグがあります。

 $ ./kluster-capacity ce --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --pods-from-template <path to pod templates> -o json|yaml

スケジュールシミュレーション

導入

スケジューラ シミュレーションは、現在のクラスター内のすべてのノード、ポッド、およびその他の関連リソースを入力として受け取り、ポッドがない状態からすべてのポッドを作成してスケジュールするまでのプロセスをシミュレートします。これを使用して、クラスター圧縮率を計算し、スケジューリングの有効性を評価したり、スケジューリング アルゴリズムの品質を測定したりすることができます。

結果は、クラスター圧縮に比べて、より積極的かつ理想的です。

走る

./kluster-capacity ss --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig>

詳細な操作パラメータと機能については、次のコマンドを実行してください。

 $ ./kluster-capacity ss --help

AllSucceed と AllScheduled の 2 つの終了条件をサポートします。前者は、すべてのポッドが正常にスケジュールされた後にプログラムが終了することを意味し、後者は、すべてのポッドが少なくとも 1 回スケジュールされた後にプログラムが終了することを意味します。デフォルト値は AllSucceed です。終了条件は --exit-condition フラグを使用して設定できます。

デモ

クラスターが 4 つのノードと 1 つのマスター ノードで実行され、各ノードに 2 つの CPU と 4 GB のメモリがあると仮定します。スケジュールする必要がある、リソース要件が 100m CPU と 200Mi メモリであるポッドが 40 個あります。

スケジューラが LeastAllocated 戦略を使用する場合、スケジューリングの結果は次のようになります。

 $ ./kluster-capacity ss --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> Termination reason: AllSucceed: 40 pod(s) have been scheduled successfully. Pod distribution among nodes: - kube-node-1: 10 instance(s) - kube-node-2: 10 instance(s) - kube-node-3: 10 instance(s) - kube-node-4: 10 instance(s)

MostAllocated ポリシーを使用するようにスケジューラを調整すると、スケジューリングの結果は次のようになります。

 $ ./kluster-capacity ss --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> Termination reason: AllSucceed: 40 pod(s) have been scheduled successfully. Pod distribution among nodes: - kube-node-1: 20 instance(s) - kube-node-2: 20 instance(s)

上記のスケジューリング結果を分析することで、スケジューリング戦略の有効性とクラスター容量圧縮率を評価できます。たとえば、上記の結果はクラスター圧縮率が 2 であることを示しています。これは、理想的な状況ではリソースの 50% が無駄になっていることを意味します。

クラスター圧縮

導入

クラスターの圧縮では、すべてのノード、ポッド、その他の関連リソースを含むクラスターの現在の状態を入力として受け取り、ノードを削除してクラスターを圧縮するプロセスをシミュレートします。これを使用して、リソースがどれだけ効率的に使用されているかの尺度であるクラスターの圧縮率を計算できます。

シミュレートされたスケジュールと比較すると、クラスター圧縮の結果は通常、より目に見えやすく、より実用的なものになります。

走る

./kluster-capacity cc --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --verbose

詳細な操作パラメータと機能については、次のコマンドを実行してください。

 $ ./kluster-capacity cc --help

デモ

クラスターが 4 つのノードと 1 つのマスター ノードで実行され、各ノードに 2 つの CPU と 4 GB のメモリがあると仮定します。 100m CPU と 200Mi メモリのリソース要件で実行されている Pod は 40 個あります。

 ./kluster-capacity cc --kubeconfig <path to kubeconfig> --schedulerconfig= <path to schedulerconfig> --verbose 2 node(s) in the cluster can be scaled down. Termination reason: FailedSelectNode: could not find a node that satisfies the condition, 1 master node(s); 2 node(s) can't be scale down because of insufficient resource in other nodes; nodes selected to be scaled down: - kube-node-1 - kube-node-3

上記の結果は、40 個のポッドのリソース要件を考慮すると、クラスターは 2 つのノードを削除しながらすべてのポッドをスケジュールできることを示しており、圧縮率は 2 です。つまり、リソースの 50% が無駄になります。

進化

現在、上記の3つの機能がサポートされており、今後は容量やリソース管理に関するその他の機能も改善される予定です。

  • スナップショットベースのシミュレーション
  • リソースの断片化分析

特定の時点のクラスターの状態に基づいて操作をシミュレートし、リソースの断片化などを分析するお手伝いをいたします。ぜひご体験いただき、貴重なご提案をお寄せください。ありがとうございます!

参考文献

[1]kluster-capacity: https://github.com/k-cloud-labs/kluster-capacity

<<:  クラウドネイティブアーキテクチャ、DevOps入門

>>:  クラウド コンピューティングは製造業にどのように役立ちますか?

推薦する

IDCの最新レポート:中国のビデオクラウドは力強い成長を遂げ、アリババクラウドは「3連覇」を達成

最近、権威ある情報機関IDCは「中国ビデオクラウド市場追跡(2020年下半期)」レポートを発表しまし...

UCloud 人工知能と Intel の背後にある技術的なストーリーを分析する (パート 1)

「企業が独自のAIオンラインサービスシステムを構築するのは簡単ではありません。ITインフラストラクチ...

BaiduのSEOの組み合わせは、

2013 年に入ってわずか 1 四半期で、Baidu は一連の複合攻撃を開始し、私たち草の根ウェブマ...

ストームに基づく分散リアルタイム処理アプリケーションの構築に関する予備的研究

最近、空き時間を利用して『Storm』を読み返しました。 Hadoop と慎重に比較すると、前者はリ...

紫禁城の戦いはコンテンツの質によってウェブサイトの重量を急速に改善します

ホームページにキーワードを素早く安定して掲載することは、すべての SEO 担当者の夢ですが、この待機...

医療業界は、Baidu 入札ランディング ページのコンバージョン率をどのように向上できるでしょうか?

多くの医療業界では、一般的に SEO ルートまたは Baidu 入札を採用しています。入札ランディン...

6.28百度Kステーション事件から、サイトタイトルは自然に書くべきだと学んだ

最近、Baidu K Stationは私に大きな影響を与えました。昨日、2つの新しいドメイン名を登録...

ウェブサイトの SEO 最適化と入札プロモーションの違いは何ですか?

2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っています多くの企業...

データの急流はクラウドからエッジへと流れています。クラウドとエッジのコラボレーションの新たな方向性をどう捉えればよいのでしょうか?

業界にとって、データの流れは大きな変化を遂げています。変化の背景には、5Gやモノのインターネットの潮...

ウェブサイトデザイン分析: UI が従うべき 3 つの主要なウェブサイトデザイン原則

テクノロジーが進化するにつれて、Web デザインの技術も進化します。新しいテクノロジーは新しい課題を...

究極の SEO 戦略: 安定性 + 関連性

最近、SEO とは何なのかという疑問について考えていました。本当に、毎日さまざまなブログやフォーラム...

データセンターにおける VxLAN テクノロジーについての簡単な説明

[[250106]]ネットワーク技術の発展に伴い、クラウドコンピューティングは、システム利用率の高さ...

モバイル エッジ コンピューティング: 5G の真の未来

5G の約束はまだ果たされていないが、失敗と断言するのは時期尚早だ。 DataBank の CEO ...

Google、Amazon、Alibaba がいずれもこの市場に参入しました。エッジコンピューティングの可能性は何でしょうか?

注: CBinsights は最近、エッジ コンピューティング レポートをリリースしました。著者はい...