Kubernetes ポッド リソースにアクセスする方法

トハドの報酬

Kubernetes を使い始めるときは、コンテナー リソースの設定を忘れがちです。 この時点では、Docker イメージが動作し、Kubernetes クラスターにデプロイできることを確認するだけで十分です。

ただし、後でアプリケーションを他のアプリケーションとともに実稼働クラスターにデプロイする必要があります。 これを行うには、コンテナにリソースを割り当て、アプリケーションを起動して実行するのに十分なリソースがあること、および実行中の他のアプリケーションに問題が発生しないことを確認する必要があります。

チーム Mail.ru の Kubernetes aaS コンテナリソース (CPU と MEM)、リクエスト、リソース制限に関する記事を翻訳しました。 これらの設定の利点と、設定しない場合に何が起こるかを学びます。

コンピューティング リソース

次の単位を持つ XNUMX 種類のリソースがあります。

• 中央処理装置 (CPU) - コア。
• メモリ (MEM) - バイト。

リソースはコンテナごとに指定されます。 次の Pod YAML ファイルには、要求されたリソースと制限リソースを含むリソース セクションが表示されます。

• 要求されたポッド リソース = すべてのコンテナーの要求されたリソースの合計。
• ポッドのリソース制限 = すべてのポッドのリソース制限の合計。

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

要求されたリソースと制限されたリソースの例

フィールド resources.requested 仕様より Pod は、目的のノードを見つけるために使用される要素の XNUMX つです。 ポッドのデプロイメントをすでに計画できます。 適切なノードをどのように見つけますか?

Kubernetes は、マスター ノードやマスター ノード (Kubernetes コントロール プレーン) などの複数のコンポーネントで構成されます。 マスター ノードには、kube-apiserver、kube-controller-manager、kube-scheduler という複数のプロセスがあります。

kube-scheduler プロセスは、新しく作成されたポッドを確認し、要求されたリソースの数を含むすべてのポッド リクエストに一致する可能性のあるワーカー ノードを見つける責任があります。 kube-scheduler によって検出されたノードのリストがランク付けされます。 ポッドは、スコアが最も高いノードにスケジュールされます。

紫色のポッドはどこに配置されますか?

この図では、kube-scheduler が新しい紫色の Pod をスケジュールする必要があることがわかります。 Kubernetes クラスターには A と B の 1 つのノードが含まれています。ご覧のとおり、kube-scheduler はノード A でポッドをスケジュールできません。利用可能な (要求されていない) リソースが紫色のポッドの要求と一致しません。 したがって、使用可能なメモリは 0,5 GB であるため、紫色のポッドによって要求された XNUMX GB のメモリはノード A には適合しません。 しかし、ノード B には十分なリソースがあります。 その結果、kube-scheduler は紫色の Pod の宛先がノード B であると決定します。

これで、要求されたリソースがポッドを実行するノードの選択にどのような影響を与えるかがわかりました。 しかし、限界資源はどのような影響を与えるのでしょうか?

リソース制限は、CPU/MEM が越えることのできない境界です。 ただし、CPU リソースは柔軟であるため、コンテナーが CPU 制限に達してもポッドが終了することはありません。 代わりに、CPU スロットルが開始されます。 MEM 使用制限に達すると、コンテナーは OOM-Killer により停止され、RestartPolicy 設定で許可されている場合は再起動されます。

要求されたリソースと最大リソースの詳細

Docker と Kubernetes 間のリソース通信

リソース リクエストとリソース制限がどのように機能するかを説明する最良の方法は、Kubernetes と Docker の関係を紹介することです。 上の画像では、Kubernetes フィールドと Docker 起動フラグがどのように関係しているかを示しています。

メモリ: 要求と制限

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

前述したように、メモリはバイト単位で測定されます。 に基づく Kubernetes ドキュメント、メモリを数値として指定できます。 通常、これは整数、たとえば 2678、つまり 2678 バイトです。 接尾辞も使用できます G и Gi、重要なことは、これらが同等ではないことを覚えておくことです。 8 つ目は XNUMX 進数、XNUMX つ目は XNUMX 進数です。 kXNUMXs ドキュメントで言及されている例のように: 128974848, 129e6, 129M, 123Mi - それらは実質的に同等です。

Kubernetes オプション limits.memory 旗と一致する --memory ドッカーから。 の場合には request.memory Docker はこのフィールドを使用しないため、Docker に矢印はありません。 これは本当に必要なのでしょうか?と疑問に思うかもしれません。 はい、必要です。 前に述べたように、Kubernetes にとってフィールドは重要です。 kube-scheduler は、そこからの情報に基づいて、どのノードで Pod をスケジュールするかを決定します。

リクエストに対して不十分なメモリを設定するとどうなりますか?

コンテナが要求されたメモリの制限に達した場合、そのポッドは、ノードに十分なメモリが不足すると停止するポッドのグループに配置されます。

メモリ制限の設定が低すぎるとどうなりますか?

コンテナーがメモリ制限を超えると、OOM-Killed によりコンテナーが終了します。 可能であれば RestartPolicy に基づいて再起動します。デフォルト値は次のとおりです。 Always.

要求されたメモリを指定しない場合はどうなりますか?

Kubernetes は制限値を取得し、それをデフォルト値として設定します。

メモリ制限を指定しないとどうなりますか?

コンテナーには制限がなく、必要なだけメモリを使用できます。 彼がノードの利用可能なメモリをすべて使用し始めると、OOM によって彼は強制終了されます。 その後、可能であれば RestartPolicy に基づいてコンテナーが再起動されます。

メモリ制限を指定しないとどうなりますか?

これは最悪のシナリオです。スケジューラーはコンテナーが必要とするリソースの数を認識しないため、ノード上で重大な問題が発生する可能性があります。 この場合、名前空間にデフォルトの制限 (LimitRange によって設定) があると便利です。 デフォルトの制限はありません。Pod には制限がなく、必要なだけのメモリを使用できます。

要求されたメモリがノードが提供できる量を超える場合、ポッドはスケジュールされません。 それを覚えておくことが重要です Requests.memory - 最小値ではありません。 これは、コンテナーを継続的に実行し続けるのに十分なメモリ量の説明です。

通常は同じ値を設定することをお勧めします。 request.memory и limit.memory。 これにより、Kubernetes は、ポッドを実行するのに十分なメモリはあるものの、実行するには十分ではないノードではポッドをスケジュールしなくなります。 留意事項: Kubernetes ポッドの計画ではのみ考慮されます。 requests.memoryと limits.memory は考慮しません。

CPU: リクエストと制限

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU を使用すると、すべてが少し複雑になります。 Kubernetes と Docker の関係の図に戻ると、次のことがわかります。 request.cpu 一致 --cpu-shares、 limit.cpu 旗と一致する cpus ドッカーで。

Kubernetes が要求する CPU は、CPU サイクルの比率である 1024 倍になります。 1 つの完全なコアをリクエストしたい場合は、以下を追加する必要があります cpu: 1上に示すように。

完全なカーネル (比率 = 1024) をリクエストしても、コンテナーがそれを受け取るとは限りません。 ホスト マシンにコアが XNUMX つしかなく、複数のコンテナを実行している場合は、すべてのコンテナがそれらの間で使用可能な CPU を共有する必要があります。 これはどうして起こるのでしょうか? 写真を見てみましょう。

CPU リクエスト - シングルコア システム

コンテナーを実行しているシングルコアのホスト システムがあると想像してみましょう。 お母さん (Kubernetes) はパイ (CPU) を焼き、それを子供たち (コンテナー) に分割したいと考えています。 1024 人の子供はパイ全体 (比率 = 512) を望み、別の子供はパイの半分 (XNUMX) を望んでいます。 お母さんは公平であることを望み、単純な計算をします。

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

計算に基づくと、28 人の子供はコア全体ではなく、コアの 14% を受け取ることになります。 XNUMX 番目の子は、カーネル全体の半分ではなく、XNUMX% を取得します。 ただし、マルチコア システムの場合は状況が異なります。

CPU リクエスト - マルチコア (4) システム

上の画像では、100 人の子供がパイ全体を望んでおり、XNUMX 人が半分を望んでいることがわかります。 お母さんはパイを XNUMX つ焼いたので、子供たちはそれぞれ好きなだけ食べることになります。 マルチコア システムでは、プロセッサ リソースは、使用可能なすべてのプロセッサ コアに分散されます。 コンテナーが XNUMX つの完全な CPU コア未満に制限されている場合でも、コンテナーはそれを XNUMX% で使用できます。

上記の計算は、CPU がコンテナー間でどのように分散されるかを理解するために簡略化されています。 もちろん、コンテナ自体以外にも、CPU リソースを使用する他のプロセスがあります。 XNUMX つのコンテナ内のプロセスがアイドル状態の場合、他のコンテナがそのリソースを使用できます。 CPU: "200m" 一致 CPU: 0,2、これは 20 つのコアの約 XNUMX% を意味します。

今、話しましょう limit.cpu。 Kubernetes が制限する CPU は 100 倍されます。その結果、コンテナーが 100 μs ごとに使用できる時間になります (cpu-period).

limit.cpu Docker フラグと一致します --cpus。 これは古いものの新しい組み合わせです --cpu-period и --cpu-quota。 これを設定することで、スロットリングが開始される前にコンテナーが最大に使用できる CPU リソースの数を示します。

• CPUの - 組み合わせ cpu-period и cpu-quota. cpus = 1.5 設定に相当 cpu-period = 100000 и cpu-quota = 150000;
• CPU周期 - 期間 CPU CFS スケジューラ、デフォルトは 100 マイクロ秒。
• CPUクォータ - 内部のマイクロ秒数 cpu-period、コンテナによって境界が定められています。

要求された CPU が不十分な場合はどうなりますか?

コンテナーがインストールされている以上のものが必要な場合、他のプロセスから CPU を奪います。

CPU 制限を低く設定しすぎるとどうなりますか?

CPU リソースは調整可能なため、スロットルがオンになります。

CPU リクエストを指定しない場合はどうなりますか?

メモリと同様に、要求値は制限と同じです。

CPU 制限を指定しない場合はどうなりますか?

コンテナーは必要なだけ CPU を使用します。 デフォルトの CPU ポリシー (LimitRange) が名前空間で定義されている場合、この制限はコンテナーにも使用されます。

リクエストまたは CPU 制限のいずれかを指定しない場合はどうなりますか?

メモリと同様に、これは最悪のシナリオです。 スケジューラーはコンテナーに必要なリソースの数を認識しないため、ノード上で重大な問題が発生する可能性があります。 これを回避するには、名前空間のデフォルト制限 (LimitRange) を設定する必要があります。

覚えておいてください: ノードが提供できる以上の CPU をリクエストすると、ポッドはスケジュールされません。 Requests.cpu - 最小値ではなく、Pod を起動して障害なく動作するのに十分な値です。 アプリケーションが複雑な計算を実行しない場合、最良のオプションは、 request.cpu <= 1 必要な数のレプリカを起動します。

要求されたリソースの理想的な量またはリソース制限

コンピューティング リソースの限界について学びました。 ここで、次の質問に答えます。「アプリケーションを問題なく実行するには、ポッドにどれくらいのリソースが必要ですか?」 理想的な量はどれくらいですか？

残念ながら、これらの質問に対する明確な答えはありません。 アプリケーションがどのように動作するか、必要な CPU やメモリの量がわからない場合、最善の選択肢は、アプリケーションに大量のメモリと CPU を与えてからパフォーマンス テストを実行することです。

パフォーマンス テストに加えて、XNUMX 週間の監視でアプリケーションの動作を監視します。 アプリケーションが要求したよりも少ないリソースを消費していることがグラフに示されている場合は、要求される CPU またはメモリの量を減らすことができます。

例としてこれを参照してください グラファナダッシュボード。 要求されたリソースまたはリソース制限と現在のリソース使用量の差が表示されます。

まとめ

リソースをリクエストして制限すると、Kubernetes クラスターを健全に保つことができます。 適切な制限構成により、コストが最小限に抑えられ、アプリケーションを常に実行し続けることができます。

つまり、留意すべき点がいくつかあります。

1. 要求されたリソースは、起動時 (Kubernetes がアプリケーションのホストを計画しているとき) に考慮される構成です。 対照的に、リソースを制限することは実行時、つまりアプリケーションがノード上ですでに実行されているときに重要です。
2. メモリと比較すると、CPU は規制されたリソースです。 十分な CPU がない場合、Pod はシャットダウンせず、スロットル メカニズムがオンになります。
3. 要求されたリソースとリソース制限が最小値と最大値ではありません。 要求されたリソースを定義することで、アプリケーションが問題なく実行されることが保証されます。
4. メモリ要求をメモリ制限と同じに設定することをお勧めします。
5. OK、インストールが要求されました CPU <=1、アプリケーションが複雑な計算を実行しない場合。
6. ノードで利用可能なリソースを超えるリソースをリクエストした場合、ポッドはそのノードにスケジュールされません。
7. 要求されたリソースの正しい量/リソース制限を決定するには、負荷テストと監視を使用します。

この記事がリソース制限の基本概念を理解するのに役立つことを願っています。 そして、この知識を仕事に応用できるようになります。

グッドラック！

他に読むべきこと：

1. SRE の可観測性: 名前空間とメトリック構造.
2. Kubernetes 用の 90 以上の便利なツール: デプロイメント、管理、モニタリング、セキュリティなど.
3. Telegram の Kubernetes に関する私たちのチャンネル.

出所： habr.com