本番環境でKubernetesのリソース割り当てを最適化する方法

[51CTO.com クイック翻訳] Kubernetes を使い始めた初日に、アプリケーションを Docker 化し、本番環境のクラスターにデプロイしました。 Buffer の最もスループットが高く (リスクが低い) エンドポイントの 1 つをモノリシック アプリケーションから移行しました。このエンドポイントは問題の増加を引き起こし、優先度の高い他のトラフィックに影響を及ぼすことがありました。

[[252635]]

curl を使用して手動でテストを行った後、Kubernetes 上の新しいサービスにトラフィックを移行することにしました。 1% の負荷では、すべてが良好に見えました。 10% でも、まだ素晴らしかったです。その後、50% になった時点で、サービスが突然クラッシュ ループを開始しました。私の最初の反応は、サービスを 4 つのレプリカから 20 に増やすことでした。これは少し役立ち、サービスはトラフィックを処理しますが、ポッドは依然としてクラッシュ ループに陥っています。

kubectl describe を使用して調査したところ、Kubelet が OOMKilled、つまりメモリ不足のためにポッドを強制終了していることがわかりました。さらに詳しく調べてみると、別のデプロイメントから YAML をコピーして貼り付けたときに、過度に厳しいメモリ制限を設定していたことに気付きました。この経験から、リクエストと制限を効果的に設定する方法を考えるようになりました。

1. リクエストと制限

Kubernetes では、CPU、メモリ、ローカル一時ストレージなどのリソースに対して構成可能なリクエストと制限を設定できます (v1.12 のベータ機能)。 CPU などのリソースは圧縮可能であるため、CPU 管理ポリシーを使用してコンテナーを調整できます。メモリなどの他のリソースは Kubelet によって監視され、制限を超えた場合は終了します。リクエストと制限のさまざまな構成を使用することで、ワークロードごとに異なるサービス品質を実現できます。

1. 制限事項

制限は、ワークロードが消費できる上限です。要求された制限しきい値を超えると、Kubelet はポッドを終了します。制限が設定されていない場合、ワークロードはノード上のすべてのリソースを消費します。複数のワークロードが制限なく実行されている場合、リソースはベストエフォート方式で割り当てられます。

2. リクエスト

スケジューラはリクエストを使用してワークロードにリソースを割り当てます。ワークロードは、Kubernetes からの介入なしに、要求されたすべてのリソースを使用できます。制限が設定されておらず、要求しきい値を超えた場合、コンテナーは要求されたリソースのみを使用するように制限されます。制限が設定されているが要求が設定されていない場合、要求されたリソースは要求された制限と一致します。

3. サービス品質

リソースと制限を通じて実現できる基本的なサービス品質 (QoS) は 3 つあります。最適な QoS 構成は、ワークロードの要件によって異なります。

図1

4. 保証されたQoS

制限を設定するだけで、保証された QoS を実現できます。これは、コンテナがスケジューラによって構成されたすべてのリソースを使用できることを意味します。これは、Web サーバーによるリクエストの処理など、CPU に依存し、比較的予測可能なワークロードに適した QoS です。

図2

5. バースト可能なQoS

バースト可能な QoS は、要求と制限の両方 (要求が制限より低い) を設定することによって構成されます。これは、コンテナが要求するように構成されたリソースを最大限使用するか、ノード上で使用可能な場合は構成されたリソースの制限全体を使用することが保証されることを意味します。これは、リソースを短時間使用したり、集中的な初期化プロセスを必要とするワークロードに役立ちます。例としては、Docker コンテナのワーカー ノードや、最適化されていない JVM プロセスを実行するコンテナの構築が挙げられます。

図3

6. ベストエフォートQoS

ベストエフォート QoS は、要求も制限も設定せずに構成されます。これは、コンテナーがコンピューター上の利用可能なリソースをすべて使用できることを意味します。スケジューラの観点から見ると、これは最も優先度の高いタスクであり、バースト可能な QoS および保証された QoS 構成の前に強制終了されます。これは、反復的に実行されるべき等最適化手順など、中断可能な低優先度のワークロードに役立ちます。

図4

2. リクエストと制限の設定

適切なリクエストと制限を設定するための鍵は、単一のポッドの限界点を見つけることです。いくつかの異なる負荷テスト方法を使用することで、アプリケーションを本番環境に移行する前に、アプリケーションのさまざまな障害モードを把握できます。ほとんどすべてのアプリケーションには、限界に達したときに独自の障害モードのセットがあります。

テストを準備するには、レプリカ数を 1 に設定し、次のような控えめな制限セットから始めるようにしてください。

 # 制限は次のようになります   
レプリカ: 1  
 ...  
 CPU: 100m #コアの約1/10  
メモリ: 50Mi # 50 メビバイト

結果を明確に確認するには、このプロセス中に制限を使用することが重要であることに注意してください (メモリ使用量が高い場合に CPU を調整し、ポッドを強制終了します)。テストの反復が完了したら、リソース制限 (CPU またはメモリ) を 1 つずつ変更します。

1. ランプアップテスト

ランプアップ テストでは、負荷がかかった状態でサービスが失敗するか、テストが完了するまで、負荷を徐々に増加させます。

図5

ランプアップ テストが突然失敗した場合は、リソースの制約が厳しすぎることを示しています。パフォーマンスに突然の変化が見られた場合は、リソース制限を 2 倍にして、テストが正常に完了するまでテストを繰り返します。

図6

リソース制限が最大に近づくにつれて (少なくとも Web スタイルのサービスの場合)、パフォーマンスは徐々に着実に低下します。

図7

負荷が増加してもパフォーマンスが変化しない場合は、ワークロードに割り当てられたリソースが多すぎる可能性があります。

2. 持続テスト

ランプアップ テストを実行し、制限を調整したら、持続時間テストを実行します。持続時間テストでは、一定した負荷を一定期間（少なくとも 10 分、長いほど良い）加えますが、限界点よりわずかに低い時間だけ加えます。

図8

このテストの目的は、短いランプアップ テストでは検出されない可能性のあるメモリ リークと隠しキュー メカニズムを特定することです。この段階で調整を行う場合は、調整は小さくする必要があります (変更 > 105)。良い結果は、テスト期間中パフォーマンスが安定していることを示します。

図9

3. 有効期限ログを保存する

テストフェーズでは、サービスが失敗したときにサービスがどのように実行されるかを記録することが重要です。実行ブックやドキュメントに障害モードを追加できます。これは、運用環境での問題のトラブルシューティングを行うときに役立ちます。テスト中に観察された障害モードがいくつかあります。

• 記憶はゆっくりと増加する
• CPUは100%に固定されています
• 500番台
• 応答時間が長い
• 破棄をリクエスト
• 応答時間に大きな差がある

ログは、今後の参照用に保存してください。問題のトラブルシューティングを行う際に、あなたや同僚にとって非常に役立つ場合があります。

3. 実用的なツール

Apache Bench などのツールを使用して負荷を追加したり、cAdvisor などのツールを使用してリソース使用率を視覚化したりできますが、リソース制限を設定するのに適したツールもあります。

1. ローダーIO

Loader.io はホスト型の負荷テスト サービスです。これにより、ランプアップ テストと期間テストを構成し、テスト実行中のアプリケーションのパフォーマンスと負荷を視覚化し、テストをすばやく開始および停止できます。テスト結果は履歴として保存されるため、リソース制限が変更された場合でも結果を簡単に比較できます。

図10

2. Kubescope CLI

Kubescope CLI は、Kubernetes (またはローカル) で実行され、Docker から直接コンテナ メトリックを収集して視覚化するツールです。 cAdvisor などのツールや別のクラスター メトリック収集サービスを使用して、10 ～ 15 秒ごとではなく 1 秒ごとにメトリックを収集します。 10 ～ 15 秒間隔であれば、テスト中にボトルネックを見逃す十分な時間があります。 cAdvisor では、リソース制限を超えると Kubernetes がポッドを終了するため、テストごとに新しいポッドを探す必要があります。 Kubescope CLI は、Docker から直接メトリックを収集し (独自の間隔を設定できます)、正規表現を使用して視覚化するコンテナを選択およびフィルタリングすることで、この問題を解決します。

図11

結論は

いつ、どのようにサービスが壊れるかがわかって初めて、そのサービスは本番環境に適した状態になるということを私は身をもって学びました。私の失敗から学び、これらのテクニックのいくつかを使用して、デプロイされた環境にリソース制限とリクエストを設定していただければ幸いです。これにより、システムの回復力と予測可能性が向上し、顧客の満足が維持され、あなたも安心して眠れるようになります。

原題: 本番環境での Kubernetes リソース割り当ての最適化、著者: Harrison Harnisch

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。