Kubernetes の運用と保守 コンテナ アプリケーション リソースの運用と管理

[[416424]]

この記事はWeChat公開アカウント「匠心独运维妙维效」から転載したもので、著者は匠心独运维妙维效です。この記事を転載する場合は、Jingxinduyun Weimiaoweixiaoの公式アカウントにご連絡ください。

最終的には、テクノロジーは業務に役立つ必要があります。推進できるあらゆる新しいテクノロジーの出現は、元の運用モデルの改善でもあります。コストを削減し、リソースの使用率を向上させる方法は、すべてのリソース管理者が直面しなければならない問題です。この記事では、G Bank のコンテナ クラウド プラットフォームの実践的な結果と合わせて、クラウド ネイティブ エコシステムでコンテナ テクノロジ リソースを割り当て、管理する方法を紹介し、共有します。

記事の冒頭では、まず3つの疑問を提起し、それについて議論しました。

Q: VM アプリケーションとコンテナ アプリケーションのリソース割り当ての違いは何ですか?

Q: コンテナ サービスのリソース使用率を向上させるにはどうすればよいですか?

Q: コンテナ プラットフォーム リソースを管理するにはどうすればよいですか?

まず、仮想マシン アプリケーション リソースについて説明します。システム管理者が物理マシンを分割する場合、通常は 4C8G、16C32G などの標準リソース割り当てテンプレートのセットが複数あります。プロジェクト マネージャーがアプリケーション リソース評価に基づいて対応する仮想マシン イメージを申請すると、初期のアプリケーション リソースがフレーム化されます。プロジェクトの開発が完了し、非機能テストが実行されると、20% や 40% などのさまざまな安定した CPU 使用率が得られます。次に、仮想マシン拡張の複雑さとリソース縮小の管理メカニズムを考慮すると、実稼働時に期待されるリソース使用率は、最終的には一定の範囲内で変動することになります。このリソース割り当てモデルを要約すると、リソースをテンプレート（固定値）として使用し、アプリケーションを適応（可変値）として使用するリソース割り当て方法です。このモードでは、いくつかの問題が発生する可能性があります。たとえば、ダウングレードしきい値は、さまざまなタイプのアプリケーションに応じて決定する豊富な経験が必要です。たとえば、最小リソース テンプレートを使用してもアプリケーションがダウングレードしきい値を下回ると、リソースが無駄になります。たとえば、アプリケーションでリソース テンプレートを調整する必要がある場合は、非機能テストを再度実行する必要があります。このモデルでは、金融機関の現在の平均 CPU リソース使用率は 10% ～ 20% であり、改善の余地があります。

では、コンテナ アプリケーションの場合、リソースはどのように割り当てればよいのでしょうか?まず、宣言メカニズムにおける k8s コンテナのリソース パラメータを理解しましょう。

リクエスト（リソース要求量）は、コンテナ起動時の最小リソース割り当て値です。クラスターがリソース要求を満たさない場合、コンテナ サービスを開始できません。

制限 (リソース制約) コンテナが要求できる最大リソース。

図1

CPU タイムスライス メカニズム、k8s スケジューリング戦略、およびコンテナの迅速な拡張機能を組み合わせます。アプリケーション リソースの理想的な使用シナリオは、安定した TPS 使用量が要求値と制限値の間であり、ピーク TPS 使用量が制限値未満であるというものです。次に、CPU を集中的に使用するアプリケーションと集中的に使用しないアプリケーションをカテゴリに分類した後、ノード リソースをある程度まで細分化して、リソース共有の目標を達成することもできます。そして、この理想的なシナリオでは、実用的なリソース割り当て戦略には、優れた非機能テスト チームと、合理的なリソース計算および割り当てモデルが必要です。このタイプのメカニズムは、アプリケーションの要件に基づいてリソース (変数値) を適応させるリソース割り当て方法として要約できます。このモデルで実行されるアプリケーションの平均 CPU リソース使用率は、運用の安定性を確保しながら 20% ～ 40% に達すると予想されます。

では、この効率的なリソース割り当て方法をどのように実装するのでしょうか?まず、コンテナ プラットフォームの構築の初期段階では、需要側が考え方を変えるのに時間が必要であり、プラットフォーム側がアプリケーションのコンテナ化戦略の推進を加速する必要があり、必ずリソースの無駄が生じると考えています。ある日、私たちの素敵なプラットフォーム管理者が検査中に、クラスター リソースがすでに逼迫しているものの、上記のアプリケーションの CPU 使用率は 10% 未満であることに気付くかもしれません。この問題を解決する方法を見つける必要があります。 G 銀行はコンテナ技術と組み合わせて多くの実践を行い、非機能テストから始めることにしました。まず、固定リソース テンプレートを放棄し、アプリケーション サービスに十分に大きな制限値を用意します。今後数年間、安定した TPS 下でのリソース使用量をテストし、実際の使用量 (現在) を取得します。次に、さまざまなアプリケーション タイプと特定の冗長性の値に基づいて、運用環境でのリソースの最大割り当ての推奨値 (制限) を計算します。リクエスト値は、アプリケーションの災害復旧レベル (k8s 削除戦略を含む) に応じて、制限の 25% から 100% の範囲になります。同時に、仮想マシンの変曲点をテストする手法も廃止し、安定したTPSを基準とした段階的な調整を推進しました。さまざまな倍数で実際のリソース使用量をテストしました。この使用量は、一定の比率で POD 数に変換でき、実稼働アプリケーション管理者に容量予測データを提供できます。このモードで起動されるシステム リソースの利用率が大幅に向上し、ノード上で実行できるサービスの数も理想的なシナリオに達しました。同時に、理想的な状況では、安定した TPS に到達した後のアプリケーション サービスのリソース使用率は一定値となり、リスクが制御されます。最後に、容量予測データに基づいて、POD サービスの数やコンテナ制限値をすばやく調整することもできます。

図2

もちろん、リソース割り当て戦略を導入した後は、それに合わせたリソース管理戦略も必要です。著者はいくつかの同僚の管理方法を調査した。より一般的な方法は、使用率に基づいて一定量のリクエスト値を削減し、制限値を変更しないことです。これは、自社開発またはオープンソースのスケジューラと優れたスケジューリング戦略に基づいた移行的または長期的なソリューションです。もちろん、デメリットについても考えることができます。一方の端（リクエスト）は制限されますが、もう一方の端（制限）は解放されます。将来、予期しない乱暴なアプリケーションが実行されると、クラスターが過負荷になり、雪崩などの異常な状況が発生する可能性があります。優れたリソース管理戦略の策定は、プラットフォーム管理者が考え、実践しなければならないことです。

G 銀行は実践的な経験を組み合わせ、アプリケーション レベルの分類から始めて、コンテナ プラットフォームのリソース運用と管理戦略を継続的に改善しています。アプリケーションシステムの災害復旧レベルに応じて制限と要求比率を標準化し、重要なシステムには保守的な戦略を採用し、一般的なシステムには効率的な戦略を採用します。アプリケーション サービスの CPU 使用タイプに応じてサービス スケジューリング戦略を最適化し、リスクの高いシナリオを回避します。アプリケーションサービスの特殊なニーズに応じて専用ノードを分割し、関連する障害などの発生を軽減し、プラットフォーム容量の週次レポート、分割超過しきい値、サービス量などを組み合わせ、さまざまなアプリケーションシステムを継続的に実行し、リソース運用戦略を継続的に最適化します。もちろん、優れた経営戦略には、継続的に強化される技術力と実現可能な実行計画も必要です。テクノロジー、計画、管理を組み合わせることによってのみ、リソースの利用率を真に高め、コストを削減することができます。

図3

要約する

最後に、リソースの活用は、業界における継続的な研究の方向性として常に存在してきました。同時に、コンテナ リソースの管理は、PaaS レイヤーの最適化だけではありません。ノードのリソース割り当て比率、ネットワーク帯域幅の制限などの要因は、最終的にはリソース管理戦略に影響を与え、リソース調整の難しさにもつながります。この記事は、3 つの質問から始まり、G バンクの実践的な経験を組み合わせて、PaaS レイヤーでの CPU のリソース操作戦略に焦点を当てています。この記事が皆さんの心に何らかのアイデアを喚起するきっかけになれば幸いです。読んでくださった読者の皆様、ありがとうございます。