[再投稿] Tencentの自己開発ビジネスがクラウドに移行：Kubernetesクラスターの負荷を最適化する技術的ソリューション

https：// my.oschina.net/jxcdwangtao/blog/3105341

作者： [email protected]

要約：Kubernetesリソーススケジューリングは静的スケジューリングを使用します。ポッド要求リソースとノード割り当て可能リソースを比較して、ノードにポッドを収容するのに十分なリソースがあるかどうかを判断します。静的スケジューリングによって引き起こされる問題は、クラスターリソースがビジネスコンテナーによってすばやく割り当てられるが、クラスターの全体的な負荷が非常に低く、各ノードの負荷も不均一であることです。この記事では、Kubernetesクラスターの負荷を最適化するためのさまざまな技術ソリューションを紹介します。

Kubernetesが静的スケジューリングを使用する理由

静的スケジューリングとは、ノードの実際の負荷を考慮せずに、コンテナーによって要求されたリソースに基づくパッキングスケジューリングを指します。静的スケジューリングの最大の利点は、スケジューリングが単純で効率的であり、クラスターリソース管理が便利であることです。最大の欠点も明らかです。ノードの実際の負荷に関係なく、クラスターの負荷を低くするのは簡単です。

Kubernetesが静的スケジューリングを使用するのはなぜですか？一般的な動的スケジューリングを実行することはほとんど不可能であるため、はい、一般的な動的スケジューリングがさまざまな企業やさまざまなビジネスの要求を満たすことは難しく、結果は逆効果になる場合があります。動的スケジューリングに行って技術的な試みを行う必要はありませんか？必ずしもそうではありません！プラットフォームは、スケジューラエクステンダーを介してKubernetesスケジューラを適切に拡張し、ホスティングのビジネス属性に従って特定の重みで動的なスケジューリングを決定できます。

クラスターリソースの構成

CPUリソースを例にとると、大規模なKubernetesクラスタのリソース構成構造は、おおよそ次のようになります。

次の部分で構成されています。

各ノードの予約済みリソースは、kubeletのシステム予約済み、kube-reserved、およびeviction-hardによって構成されたリソースの合計に対応します。Kubernetesがノードの割り当て可能なリソースを計算すると、予約済みリソースのこの部分が差し引かれます。
現在、クラスターの平均リソース断片化は約5％から10％です。これは、CVMモデルの仕様によってわずかに異なります。これらのリソースフラグメントは、クラスター内のノード（主に1c1g、2c2g、3cxg）全体に散在しています。プラットフォームによって提供されるコンテナー仕様は、これらのフラグメントと一致することが困難です。この状況はしばしば存在します：ポッドがスケジュールされると、それが見つかります特定のノードのCPUで十分ですが、メモリが不足しているか、またはその逆です。
残りは、ビジネスポッドが実際に使用できるリソースです。ビジネスには、コンテナの仕様を選択する際に特定の主観性と盲目性があるため、ビジネスコンテナの負荷が低くなります。このような大きな割合のビジネスは、簡単にクラスタにつながります。低負荷ですが、Kubernetes静的スケジューリング戦略に従って、クラスターはこれ以上のビジネスコンテナーに対応できません。上の図に示すように、クラスター割り当てのCPU水位は非常に高くなっていますが、実際のCPU使用率は高くありません。

クラスターの負荷を増やすためのスキーム

強力なコンテナモニタリングデータを使用して、特定の重みで動的スケジューリングの決定を行うことに加えて、静的スケジューリングによって引き起こされる低クラスター負荷の問題を解決するために使用できる他のソリューションはありますか？以下では、複数の技術的側面からKubernetesクラスターの負荷を増加させるための完全な技術ソリューションセットを示します。

ポッド割り当てリソースの圧縮

前述のように、R＆Dの学生は一定の盲目を伴うコンテナリソース仕様を選択するサービスを展開し、Kubernetesはコンテナ仕様のリアルタイムかつ非知覚的な変更をネイティブでサポートしていません（これは静的VPAソリューションによって解決できます）。その結果、ビジネスコンテナの負荷が低くなります。。この問題を解決するために、特定の割合のポッド要求リソースを圧縮できます（ポッド制限リソースは圧縮されません）。ポッド要求リソースの圧縮は、ポッドが作成または再構築された場合にのみ発生することに注意してください。たとえば、ビジネスが変更およびリリースした場合、通常の操作ではポッドに対してこのアクションを実行できません。それ以外の場合は、対応するワークロードコントローラーがポッドを再構築する可能性があります（ワークロードのUpdateStrategyによって異なります）。ビジネスへの影響。

次のことに注意してください。

ワークロードごとに異なる負荷変動ルールがあるため、ポッドに割り当てられたリソースの圧縮率も異なります。各ワークロードのカスタム構成をサポートする必要があり、これはユーザーにはわかりません。この圧縮率は、Annotationに対応するCPUリソースの圧縮など、ワークロードの注釈に設定し stke.platform/cpu-requests-ratioます。
誰が圧縮率を設定しますか？自己開発コンポーネント（Pod-Resource-Compress-Ratio-Reconciler）は、ワークロードの履歴監視データに基づいており、動的に/定期的に圧縮率を調整します。たとえば、継続的な7d / 1M負荷のワークロードは非常に低いままなので、圧縮率を大きく設定できるため、クラスターはより多くのリソースを割り当て、より多くのビジネスコンテナーに対応できます。もちろん、圧縮率の調整戦略は実際にはそれほど単純ではなく、支援するためにより多くの監視データが必要です。
ポッド配布の圧縮機能をオフにして復元できるようにする必要があります。ワークstke.platform/enable-resource-compress: "n"ロードレベルでワークロードアノテーションを無効にでき、圧縮率を1に設定することで圧縮を復元できます。
ポッド仕様のリクエストリソースを圧縮率で調整するタイミング Kubernetesが現在の段階に発展するにつれ、Kubernetesコードを直接変更することは最も愚かな方法であり、Kubernetes拡張メソッドを最大限に活用する必要があります。ここではMutating Admission Webhook、kube-apiserver 、自己開発Webhook（pod-resource-compress-webhook）を介してポッド作成イベントをインターセプトし、圧縮機能がポッドアノテーションで有効になっているかどうかを確認し、構成されている場合は圧縮率を構成します。圧縮率は、ポッドとAPIServerへのパッチのリクエストリソースを再計算します。

売られ過ぎたノードリソース

ポッドリソース圧縮スキームは、各ワークロードレベルのリソースの動的調整スキームです。利点は、各ワークロードをターゲットにでき、ターゲットを設定できることです。欠点は、ビジネスが変更を行わず、効果がないことです。

ノードリソースオーバーセルプログラムは、ノードレベルのリソースの動的調整プログラムであり、各ノードの実際の負荷履歴データに従って、さまざまな比率のリソースオーバーセルが実行されます。

各ノードのリソースオーバーセル率。ノードのアノテーションに設定しstke.platform/cpu-oversale-ratioます。たとえば、cpu oversoldはAnnotationに対応します。
各ノードの売られ過ぎ率を設定するのは誰ですか？自己開発コンポーネント（Node-Resource-Oversale-Ratio-Reconciler）は、ノードの履歴監視データに基づいて、売られすぎ比率を動的に/定期的に調整します。たとえば、ノードの負荷が7d / 1Mの間継続的に低く、ノードに割り当てられたリソースレベルが高い場合、ノードがより多くのビジネスポッドに対応できるようにオーバーセル率を適切に調整できます。
ノードのオーバーセル機能はオフにして復元できる必要があります。ノードのオーバーセルはノードアノテーション stke.platform/mutate: "false"でオフになり、ノードは次のハートビートでリソースの回復を完了します。
ノードステータスの割り当て可能リソースと容量リソースを圧縮率で調整するタイミング同様に、Mutating Admission WebhookノードのCreateおよびStatus Updateイベントをkube-apiserver 、自社開発のWebhook（node-resource-oversale-webhook）を介してインターセプトし、ノードアノテーションでオーバーセルが有効になっているか、オーバーセル比率が構成されているかどうかを確認します（構成されている場合）次に、ノードの割り当て可能リソースと容量リソースが、Anchaoの販売比率に従って再計算され、パッチがAPIServerに送信されます。

ノードのリソースは売られすぎて、表面的にはシンプルに見えますが、実際には考慮すべき多くの詳細があります。

Kubelet Register Node to ApiServerの詳細な原則は何ですか？webhookを介してノードステータスに直接パッチを適用することは可能ですか？
ノードリソースが売られ過ぎた場合、Kubernetesに対応するCgroup動的調整メカニズムは引き続き正常に機能しますか？
ノードステータスの更新が頻繁に行われます。ステータスの更新ごとにWebhookがトリガーされます。大規模なクラスタは、apiserverのパフォーマンスの問題を引き起こす可能性があります。解決方法
売られ過ぎたノードリソースは、Kubelet Evictionの構成に過剰なプロビジョニング効果をもたらしますか、それとも実際のノード構成と負荷に応じて削除されますか？Evictに影響する場合、どのように解決する必要がありますか？
売られ過ぎの比率が大きくなったときから小さくなったとき、ノードにSumがあります(pods' request resource) > node's allocatableが、ここでリスクはありますか？対処方法は？
監視システムによるノードの監視は、ノードの割り当て可能および容量リソースに関連しています。オーバーセル後、監視システムによるノードの監視はもはや正しくありません。ある程度修正する必要があります。監視システムにデータの売られ過ぎの比率を動的に認識させる方法ビューの修正？
ノードの割り当て可能容量と容量はどのように売られすぎますか？ノードの予約済みリソースに対するオーバーセルの影響は何ですか？

ここには、Kubernetesの技術的な詳細がたくさんあります。次の記事で詳しく説明します。

AutoScale機能の最適化

Kubernetesの柔軟なスケーリングと言えば、誰もがHPAとHNAに慣れています。1つはワークロードポッドをスケーリングし、もう1つはクラスター内のノードをスケーリングします。コミュニティにはポッドリソースを調整するためのVPAプロジェクトもありますが、ポッドを再構築して有効にする必要があります。VPAの重要性は、容量をすばやく拡張することです。HPAのように、アプリケーションを開始して容量を拡張するためにポッドを再構築する必要がある場合、実際には失われます価値。

Kube-controller-managerに組み込まれたHPA-Controllerには、次の問題があります。

パフォーマンスの問題：goroutineはクラスター内のすべてのHPAオブジェクトをループし、各HPAオブジェクトの対応するポッドモニタリングデータを取得して、新しいレプリカを計算します。これは、大規模なビジネスでは時間がかかります。
コア構成はワークロードのカスタマイズをサポートしていません：HPAスケーリングの応答時間はビジネスごとに異なる場合があります。5秒間で応答することを期待する企業もあれば、60年代で十分と考える企業もあります。組み込みのHPAコントローラーは、応答時間制御でグローバル起動パラメーターのみを構成できますhorizontal-pod-autoscaler-sync-period。さらに、ビジネスごとに負荷ジッターに対する許容度が異なり、組み込みのHPAコントローラーではhorizontal-pod-autoscaler-toleranceグローバルにのみ構成でき、サービスレベルのカスタマイズを提供できません。
Kubernetesは現在カスタム指標をサポートしています。登録できるバックエンドモニタリングサービスは1つだけです。クラスタ内の一部のサービスがprometheusを介してアプリケーションカスタムインジケーターを公開し、一部のサービスがMonitorを介してアプリケーションカスタムインジケーターを監視する場合、この時間は実行できません。すべてで、これは自社開発のクラウドシーンで必ず存在しなければならないシーンです。

HPAPlus-Controllerコンポーネントを自己開発しました。

各HPAオブジェクトは、HPAオブジェクトの管理と計算を担当するgoroutineコルーチンを開始します。各コルーチンは並列に実行され、パフォーマンスを大幅に最適化します。HPAPlus-Controllerは独立してデプロイされ、そのリソース要件はクラスターのサイズとHPAの数によって合理的に調整できます。元の組み込みHPA-Controllerと比較すると、柔軟性が高くなります。
HPAPlus-Controllerは、各HPAオブジェクトのカスタマイズされたスケーリング応答時間をサポートし、サービスが解放されているかどうかの自動検知をサポートし、HPAを無効にするかどうかを決定します（一部のサービスにはそのような要件があります：アップグレード時にエラスティックスケーリングをトリガーすることは禁止されています）。カーディナリティは、拡張および縮小後に予想されるレプリカを導出するために、ポッドリソースの使用率を計算するために使用されます。これは、ノードの売られ過ぎおよびポッドリソース圧縮クラスターにとって非常に重要です。
サービスレベルのパーソナライズされた構成をサポートして、ジッタ耐性をロードします。
ポッド履歴7d / 1M CPU負荷など、より多くのディメンションのモニタリングデータに基づくスケール決定をサポートします。
CronHPAをサポートして、定期的な拡張と縮小のビジネス要求に対応します。
Extension APIServerを介して会社のMonitorモニタリングに接続し、Prometheus-Adaptorメソッドを保持して、Prometheusベースのアプリケーションモニタリングをサポートし、複数のアプリケーションモニタリングシステムに基づくカスタムメトリックのHPAを満たします。

注：HPAPlus-ControllerとKubernetes buit-in HPA-Controllerの間には機能的な競合があります。オンラインになる前に、kube-controller-managerのHPA-Controllerコントローラーを無効にしてください。

HPAの最適化と拡張に加えて、動的VPAテクノロジーも開発しています。これは、後で別の記事で紹介されます。

その他の技術的ソリューション

さらに、スケジューラーエクステンダーを使用して、動的スケジューラー、ビジネスレベルのクォータ動的管理コンポーネント、ビジネスの優先順位とクォータ管理に基づくオンラインとオフラインのビジネスミキシング機能を開発し、ノードリソースの断片化情報をアクティブに検出して、ポッドのコントローラーに報告しますリソースフラグメント管理およびその他のソリューションを再駆動することも、私たちの継続的な実践の方向性です。対応するソリューションと実装はより複雑であり、将来、別の記事で紹介される予定です。

まとめ

この記事では、Kubernetesの静的スケジューリングによってもたらされる、クラスターリソース割り当ての水位は高いがクラスターの実際の負荷は低いという問題の技術的ソリューションを紹介し、ポッドリソースの動的圧縮、ノードリソースの動的オーバーセル、AutoScaleを最適化する機能について詳しく説明しますこの方式については、動的スケジューリング、動的ビジネスクォータ管理、オンラインとオフラインのビジネスミキシングの観点から後で説明します。これらのすべてのクラスター負荷改善スキームは、動的であるため、強力なコンテナー監視システムに強く依存しています。Tencentのクラウドモニタリング製品チームと綿密に連携して、クラウドでのTencentの自己開発ビジネスにより適切に対応しています。