K8s クラスタの安定性を向上させる方法を紹介する記事

リソース利用率の向上

1. 資源浪費シナリオ

1. リソース予約は通常50%以上無駄になる

Kubernetes の Request フィールドは、コンテナの CPU およびメモリ リソースの予約を管理するために使用され、コンテナが少なくとも必要なリソース量に到達できること、およびこれらのリソースが他のコンテナによってプリエンプトされないことが保証されます。詳細については、(https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) を参照してください。リクエスト値が小さすぎると、サービス リソースが保証されません。サービス負荷が増加すると、サービスをサポートできなくなります。したがって、ユーザーは通常、サービスの信頼性を確保するために、リクエスト値を非常に高く設定します。

しかし、実際には、ほとんどの期間においてビジネス負荷はそれほど高くありません。 CPU を例にとると、次の図は実際のビジネス シナリオにおけるコンテナーのリソース予約 (Request) と実際の使用量 (CPU_Usage) の関係図です。リソース予約は実際の使用量よりもはるかに大きく、両者の差に相当するリソースは他の負荷で使用できません。したがって、リクエストを大きく設定しすぎると、必然的にリソースが大量に浪費されることになります。

この問題を解決するにはどうすればいいでしょうか?この段階では、ユーザーは実際の負荷状況に応じてより合理的なリクエストを設定し、特定のビジネスによってリソースが過剰に占有されることを防ぐために、ビジネスによるリソースの無制限のリクエストを制限する必要があります。次のテキストのリクエストクォータと制限範囲の設定を参照してください。

2. ビジネスリソースには、ピークと谷という共通の現象があります。通常、谷間の時間はピークの時間よりも長いため、明らかにリソースが無駄になります。

ほとんどのビジネスには、ピークと谷があります。たとえば、バスシステムでは通常、日中は負荷が増加し、夜間は負荷が減少します。ゲームビジネスは通常、金曜日の夜にピークを迎え、日曜日の夜に底を打つようになります。

次の図に示すように、同じサービスでも期間によって要求されるリソースの量は異なります。ユーザーが固定のリクエストを設定すると、負荷が低いときにサービスの利用率が非常に低くなります。

このとき、リソース使用率の高いビジネスのピークと谷に対応するために、レプリカの数を動的に調整できます。 k8s が提供する HPA をネイティブに参照できます。

3. 事業の種類によってリソースの利用方法に大きな違いが生じる

オンライン サービスは通常、日中の負荷が高く、レイテンシ要件も高くなるため、スケジュールを設定して優先的に実行する必要があります。ただし、オフライン コンピューティング サービスは通常、動作期間と待ち時間に関する要件が比較的低く、理論的にはオンライン サービスの谷間でも実行できます。さらに、一部のビジネスは計算集約型で CPU リソースを大量に消費しますが、一部のビジネスはメモリ集約型でメモリを大量に消費します。

上の図に示すように、オフライン コロケーションでは、オフライン サービスとオンライン サービスを動的にスケジュールできるため、異なる種類のサービスを異なる期間に実行して、リソースの使用率を向上させることができます。コンピューティング集約型およびメモリ集約型のビジネスでは、アフィニティ スケジューリングを使用してビジネスに適したノードを割り当て、テイント/許容戦略を使用して特定のノードを特定のビジネス シナリオで使用するために分離し、リソース使用率を効果的に向上させることができます。

2. リソース利用率を向上させる方法

主なアプローチは 2 つあります。1 つは、ネイティブの Kubernetes 機能を使用してリソースを手動で分割および制限することです。もう 1 つは、ビジネス特性を組み合わせた自動化ソリューションを使用することです。ここでは、k8s のネイティブ機能を使用してリソースを分割および制限する方法を暫定的に紹介します。

1. リソースを分割して制限する方法

あなたがクラスター管理者であり、4 つのビジネス部門が同じクラスターを使用していると想像してください。あなたの責任は、ビジネスの安定性を確保しながら、ビジネスがオンデマンドでリソースを使用できるようにすることです。クラスター全体のリソース使用率を効果的に向上させるためには、各業務のリソース使用量の上限を制限し、いくつかのデフォルト値を通じて業務の過剰な使用を防ぐ必要があります。

理想的には、企業は実際の状況に基づいて合理的な要求と制限を設定する必要があります。 (リクエストはリソースを予約するために使用され、コンテナが取得できる最小リソースを示します。制限はリソースを制限するために使用され、コンテナが取得できる最大リソースを示します。) これにより、コンテナの正常な動作とリソースの完全な使用が促進されます。しかし、実際には、ユーザーはコンテナのリソースの要求と制限を設定することを忘れることがよくあります。さらに、クラスターを共有するチーム/プロジェクトでは、通常、サービスの安定性を確保するために、コンテナのリクエストと制限を非常に高く設定します。

リソースをより細かく分割して管理するために、名前空間レベルでリソース クォータと制限範囲を設定できます。

2. リソースクォータを使用してリソースを分割する

4 つのビジネスを含むクラスターを管理する場合は、名前空間とリソース クォータを使用してビジネスを分離し、リソースを制限できます。

リソース クォータは、名前空間リソースの使用クォータを設定するために使用されます。名前空間は、Kubernetes クラスター内の分離されたパーティションです。クラスターには通常、複数の名前空間が含まれます。たとえば、Kubernetes ユーザーは通常、異なるビジネスを異なる名前空間に配置します。異なる名前空間に異なるリソース クォータを設定することで、クラスター リソース全体に対する名前空間の使用を制限し、事前割り当てと制限の効果を実現できます。リソース クォータは主に次の側面に影響します。詳細については、（https://kubernetes.io/docs/concepts/policy/resource-quotas/）を参照してください。

• コンピューティング リソース:すべてのコンテナーのリクエストと CPU およびメモリの制限の合計。
• ストレージ リソース:すべての PVC の合計ストレージ リソース要求。
• オブジェクト数: PVC/サービス/Configmap/デプロイメントなどのリソース オブジェクトの合計数。

リソースクォータの使用シナリオ

• 異なるプロジェクト/チーム/ビジネスに異なる名前空間を割り当て、各名前空間リソースのリソース クォータを設定することでリソース割り当てを実現します。
• 名前空間が使用できるリソースの数に上限を設定すると、クラスターの安定性が向上し、名前空間がリソースを過剰に占有して消費するのを防ぐことができます。

以下は、クラスター内の各名前空間の初期リソース クォータを設定するスクリプトです。

「説明」: このスクリプトは、kubectl-view-allocations プラグインを使用して、クラスターの各名前空間内のすべてのポッドに設定されている合計要求と制限を取得し、合計を 30% 増やして、名前空間の要求と制限のリソース クォータを設定します。

クラスターの具体的な状況に応じて、後で対応する構成を調整できます。

使用方法:

 https://my-repo-1255440668.cos.ap-chengdu.myqcloud.com/ops/ResourceQuota-install.tar.gz ​ を実行します。
 tar - xvf ResourceQuota - をインストールします。 タール。 日本語
cd ResourceQuota - install && bash install .sh

実行後、現在のディレクトリに resourceQuota ディレクトリと limitrange ディレクトリが生成され、各名前空間の ResourceQuota.yaml ファイルが含まれるため、クラスターの実際の状況に基づいて対応する調整を行い、必要に応じて適用できます。

[注意]:名前空間のリクエストと制限の合計が設定された resourceQuota を超える場合、新しいポッドを作成できません。 resourceQuota を設定した後、ポッドを「limits.cpu、limits.memory、requests.cpu、requests.memory」で構成する必要があります。そうしないと、正常にデプロイできません。イベントを確認すると、次のエラーが表示されます。

同時に、ns のリソース使用量が適切かどうかを監視し、各ポッドの元のリクエストと制限を調整し、状況に応じて設定された resourceQuota を調整することができます。

CI はリクエストと制限を次のように構成します。

yaml レンダリング構成は次のとおりです (リソース フィールドを含む)。

推奨構成:

Java サービス: リクエストと制限は同じ値で構成されています。

golang/python サービス: リクエストと制限は 1:2 に設定されています。

 #推奨構成:
 #java サービス: リクエストと制限は同じ値に設定されます
#golang / python サービス: リクエストと制限は 1:2 に設定されます
リソース：
 CPU : 500 / 1000 m
 メモリ: 500 / 1000 Mi

3. 制限範囲を使用してリソースを制限する

ユーザーがリソースのリクエストと制限の設定を忘れたり、値を高く設定しすぎたりすることが多い場合はどうすればよいでしょうか?管理者として、業務ごとに異なるリソースのデフォルト値や範囲を設定できれば、業務作成時の作業負荷を効果的に軽減し、業務によるリソースの過剰な占有を制限できます。

名前空間全体のリソースを制限するリソース クォータとは異なり、制限範囲は名前空間内の単一のコンテナーに適用されます。これにより、ユーザーが名前空間内でリソース要求が小さすぎる、または大きすぎるコンテナを作成することを防ぎ、コンテナの要求と制限の設定を忘れることを防ぐことができます。制限範囲は主に以下の点で機能します。詳細については、(https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/) を参照してください。

1. コンピューティング リソース:すべてのコンテナの CPU とメモリの使用量の範囲を設定します。
2. ストレージ リソース:すべての PVC に適用できるストレージ スペースの範囲。
3. 比率設定:リソースのリクエストと制限の比率を制御します。
4. デフォルト値:すべてのコンテナのデフォルトのリクエスト/制限を設定します。コンテナが独自のメモリ要求と制限を指定しない場合は、デフォルトのメモリ要求と制限が指定されます。

制限範囲の使用シナリオ

ユーザーが忘れないように、また QoS によって重要な Pod が排除されないように、リソース使用量のデフォルト値を設定します。

通常、異なるビジネスは異なる名前空間で実行されます。通常、ビジネスによってリソースの使用方法は異なります。異なる名前空間に異なるリクエスト/制限を設定すると、リソースの使用率が向上します。

コンテナによるリソース使用量の上限と下限を制限して、コンテナが正常に実行され、過剰なリソースが要求されるのを防ぎます。

4. スケジュール戦略

Kubernetes スケジューリング メカニズムは、Kubernetes によってネイティブに提供される効率的でエレガントなリソース割り当てメカニズムです。その主な機能は、各ポッドに最も適したノードを見つけることです。 Kubernetes が提供するスケジューリング機能を合理的に活用し、ビジネス特性に応じて適切なスケジューリング戦略を構成することで、クラスター内のリソース利用率も効果的に向上できます。

4.1 ノードアフィニティ

例示する

業務の 1 つが CPU を大量に消費し、Kubernetes スケジューラによってメモリを大量に消費するノードに誤ってスケジュールされた場合、メモリを大量に消費する CPU は完全に占有されますが、メモリはほとんど使用されないため、リソースが大幅に浪費されます。ノードに CPU を集中的に使用するノードであることを示すマークを設定し、ビジネス ロードの作成時にこのロードが CPU を集中的に使用するロードであることを示すマークを設定すると、Kubernetes スケジューラはこのロードを CPU を集中的に使用するノードにスケジュールします。最も適切なノードを見つけるこの方法により、リソースの使用率が効果的に向上します。

Pod を作成するときに、ノード アフィニティを設定できます。つまり、Pod をスケジュールするノードを指定します (これらのノードは K8s ラベルを通じて指定されます)。

ノードアフィニティの使用シナリオ

ノード アフィニティは、リソース要件が異なるワークロードがクラスター内で同時に実行されるシナリオに適しています。たとえば、k8s クラスター ノードには、CPU を集中的に使用するマシンとメモリを集中的に使用するマシンが含まれます。一部のビジネスではメモリよりもはるかに多くの CPU が必要な場合、通常のノード マシンを使用すると、必然的にメモリの大きな無駄が発生します。この時点で、CPU を集中的に使用するノードのバッチをクラスターに追加し、CPU 要件の高いポッドをこれらのノードにスケジュールすることで、ノード リソースの全体的な使用率を向上させることができます。同様に、クラスター内の異種ノード (GPU マシンなど) を管理し、GPU リソースを必要とするワークロードで必要な GPU リソースの量を指定することもできます。また、スケジューリング メカニズムによって、これらのワークロードを実行するのに適したノードを見つけることができます。

4.2 汚染と許容

例示する

前述の NodeAffinity はポッド上で定義されるプロパティであり、これによりポッドを特定のノードで実行するようにスケジュールできるようになります。汚染は正反対で、ノードがポッドの実行を拒否するようにします。

ポッドが不適切なノードを回避できるようにするには、Taint を Toleration と一緒に使用する必要があります。ノードに 1 つ以上のテイントを設定した後、ポッドは、これらのテイントを許容できることを明示的に宣言しない限り、それらのノードで実行できません。 Toleration は、Taint でマークされたノード上でポッドを実行できるようにする (有効にするだけで、必須ではないことに注意) ポッドのプロパティです。

ポッドを作成するときに、Taint と Tolerations を設定して、特定のノードが特定のポッドのみを許可できるようにすることができます。

汚点と寛容のシーン

ノード限定

特定のアプリケーションにいくつかのノードを使用する場合は、次のような Taint をノードに追加できます。

 kubectl taint ノードノード名専用= グループ名: NoSchedule

次に、これらのアプリケーションのポッドに対応する許容値を追加すると、適切な許容値を持つポッドは、他のノードと同様に汚染されたノードを使用できるようになります。次に、これらのノードには指定されたラベルが付けられ、nodeSelector またはアフィニティ スケジューリングを通じて、これらのポッドは指定されたラベルを持つノード上で実行する必要があります。

特殊なハードウェアを備えたノード

クラスターでは、少数のノードに GPU チップなどの特殊なハードウェア デバイスがインストールされている場合があります。ユーザーは当然、このタイプのハードウェアを占有する必要のないポッドを除外したいと考えるでしょう。これにより、このタイプのハードウェアを必要とするポッドをこれらのノードに正常にスケジュールできるようになります。次のコマンドを使用して、ノードに汚染を設定できます。

 kubectl taint ノードノード名special = true : NoSchedule
 kubectl taint ノードノード名special = true : PreferNoSchedule

次に、ポッド内の対応する許容値を使用して、特定のポッドが特定のハードウェアを使用できるようにします。同様に、ラベルやその他の機能を使用してこれらのポッドを識別し、特定のハードウェアを備えたサーバーにスケジュールすることもできます。

ノード障害への対処

ノードに障害が発生した場合、TaintBasedEvictions 関数を使用して、ノードを自動的に Taint に設定し、ポッドを排除することができます。ただし、ネットワーク障害によってマスターがノードとの接続を失い、ノードが多数のローカル状態アプリケーションを実行している場合など、一部のシナリオでは、ネットワークに障害が発生しても、ノード上での実行を継続し、ネットワークが迅速に復旧してノードから排除されないようにすることが期待されます。ポッドの許容範囲は次のように定義できます。

 許容範囲:
 - キー: "node.alpha.kubernetes.io/unreachable"
 演算子: "存在する"
 効果: "NoExecute"
 許容秒数: 6000

K8s クラスターの安定性を向上させる方法は多数あります。リソース利用率の向上はその 1 つにすぎません。今後も他の手法の応用も展開してまいります。