K8s クラスター容量 - kluster capacity

K8s クラスター容量 - kluster capacity

背景

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

問題点

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

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

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

プロジェクト紹介

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

能力評価

導入

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

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

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

強化

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

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

走る

 # 指定されたポッドテンプレートを直接使用する
$ ./kluster-capacity ce --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --pods-from-template <ポッド テンプレートへのパス>
# クラスターで指定されたポッドをテンプレートとして使用します
$ ./kluster - capacity ce --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --pods-from-cluster <ポッドの名前空間/名前キー>

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

 $ ./kluster-capacity ce --help

デモ

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

 $ ./kluster-capacity ce --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --pods-from-template <ポッドテンプレートへのパス> --verbose
ポッドの要件:
- CPU : 150m
-メモリ: 100 Mi

クラスターはポッドのインスタンス52 個スケジュールできます。
終了理由:失敗スケジューリング:ポッド( small - pod - 52 )がどのノードにも適合しませんでした
ノード( kube - node - 1 )適合失敗: CPU 不足
ノード( kube - node - 4 )適合失敗: CPU 不足
ノード( kube - node - 2 )適合失敗: CPU 不足
ノード( kube - node - 3 )適合失敗: CPU 不足


ノード間のポッド分散:
-kube -ノード- 1 : 13インスタンス
-kube -ノード- 4 : 13インスタンス
-kube -ノード- 2 : 13インスタンス
-kube -ノード- 3 : 13インスタンス

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

 $ ./kluster-capacity ce --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --pods-from-template <ポッドテンプレートへのパス> --verbose
ポッドの要件:
- CPU : 150m
-メモリ: 100 Mi

クラスターはポッドのインスタンス46 個スケジュールできます。
終了理由:失敗スケジューリング:ポッド( small - pod - 46 )がどのノードにも適合しませんでした
ノード( kube - node - 1 )適合失敗: CPU 不足
ノード( kube - node - 4 )適合失敗: CPU 不足
ノード( kube - node - 2 )適合失敗: CPU 不足
ノード( kube - node - 3 )適合失敗: CPU 不足


ノード間のポッド分散:
-kube -ノード- 1 : 11インスタンス
-kube -ノード- 4 : 12インスタンス
-kube -ノード- 2 : 11インスタンス
-kube -ノード- 3 : 12インスタンス

出力フォーマット

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

 $ ./kluster - capacity ce --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --pods-from-template <pod テンプレートへのパス> -o json|yaml

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

導入

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

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

走る

 ./kluster-capacity ss --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス>

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

 $ ./kluster-capacity ss --help

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

デモ

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

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

 $ ./kluster-capacity ss --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス>
終了理由: AllSucceed : 40 個のポッドが正常にスケジュールされました。

ノード間のポッド分散:
-kube -ノード- 1 : 10インスタンス
-kube -ノード- 2 : 10インスタンス
-kube -ノード- 3 : 10インスタンス
-kube -ノード- 4 : 10インスタンス

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

 $ ./kluster-capacity ss --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス>
終了理由: AllSucceed : 40 個のポッドが正常にスケジュールされました。

ノード間のポッド分散:
-kube -ノード- 1 : 20インスタンス
-kube -ノード- 2 : 20インスタンス

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

クラスター圧縮

導入

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

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

走る

 ./kluster-capacity cc --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --verbose

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

 $ ./kluster-capacity cc --help

デモ

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

 ./kluster-capacity cc --kubeconfig <kubeconfig へのパス> --schedulerconfig= <schedulerconfig へのパス> --verbose
クラスター内の2 つのノードスケールダウンできます。

終了理由: FailedSelectNode :条件を満たすノードが見つかりませんでしたマスター ノード1です他のノードのリソースが不足しているため、 2 つのノードスケールダウンできません。

スケールダウン対象として選択されたノード:
- kube-node-1
- kube-node-3

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

進化

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

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

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

参考文献

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

<<:  マイクロソフトカンロン:回復力と革新への熱意で、マイクロソフトはAzure OpenAIサービスの新機能をリリース

>>:  純粋なアップストリームKubernetesは最高のKubernetesです

推薦する

分析:検索エンジンのアルゴリズムは変わったが、基本的な考え方は変わっていない

検索エンジンのアルゴリズムはリンクをランク付けします。値が高いほど、ランクが高くなります。キーワード...

既存製品の再設計にユーザーデータをどのように適用するかをデータから学ぶ

導入通常、ユーザーインタビューを通じてユーザーのニーズを把握することができます。実際、デザイナーはユ...

Zhihu、Douban、Hupuがライブストリーミングに注目

多様化するユーザーのニーズに応えるため、さまざまなインターネットプラットフォームが常に新しい事業分野...

ウェブサイトのコンテンツを更新するための3つのヒントをご存知ですか?

月収10万元の起業の夢を実現するミニプログラム起業支援プランアップデートのヒント?それはきっと嘘です...

企業ウェブサイトの SEO 診断プランの書き方

みなさんこんにちは。私はShi Touです。昨日の記事「企業ウェブサイトの SEO 診断におけるいく...

クラウドネイティブデータベースがデジタルイノベーションの力を発揮

人類が誕生して以来、データの記録と処理能力の探求は止まることはありませんでした。たとえば、古代におけ...

検索エンジンに頼る以外に、最初のユーザー集団を獲得するにはどうすればよいでしょうか?

新しいウェブマスターは、最初のユーザー集団をどうやって獲得するかという主要な問題に直面します。最も一...

ベタの頭に3本のナイフ

企業の市場価値の上昇と下降を決定する要因は何ですか?簡単に言えば、持続可能性、上限、収益性の 3 つ...

同僚はDockerとK8Sを知らなかったため、会社のグループチャットから削除されました

Docker はコンテナと同義であり、K8S はコンテナ オーケストレーションと同義です。これら 2...

Baidu の新しいアルゴリズムは「破壊的な変化」をもたらすのでしょうか?あなたは隠れたマスターですか?

最近、バイドゥは何のようなものかを推測していますそれはあらゆる種類の憶測に備えて、誰もが自分の意見を...

#新学期特別セール# DWIDC: 湖北省コンピュータ室、200G防御、VPSは68元から(4G/4C/50G/10M帯域幅)、専用サーバーは385元から(32G/32C/480gSSD/50M帯域幅)

9月は新学期の始まりであり、Dwidcは学生とネットユーザー向けに新学期特別セールを開始しました。湖...

ネットワークマーケティングの実行を改善するための4つの重要なポイント

時々、人々は絶望的な状況に追い込まれたときに初めて本当に注意を払い、行動を起こします。そのため、私が...

Kubernetes のスケジュール管理を 1 つの記事で学ぶ

基本的な紹介日常業務では、すべての空港に航空機の着陸場所や駐機場所を管理するためのディスパッチルーム...

#値下げ+アップグレード: Vultr - 20% オフ/10G ポート/14 データセンターへのアップグレード

朗報です。Vultr は、スタッフが過去数年にわたって製品の大規模なアップグレードに取り組んできたこ...