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

Tohadによる報酬



Kubernetesを使い始めるとき、コンテナリソースの構成を忘れることがよくあります。この時点で、Dockerイメージが機能していて、Kubernetesクラスターにデプロイできることを確認する必要があります。



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



のKubernetesaaSチームは、コンテナリソース（CPUとMEM）、リクエスト、およびリソース制限に関する記事を翻訳しました。これらの設定の利点と、それらをインストールしないとどうなるかを学びます。

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

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

• 中央処理装置（CPU）-コア;
• メモリ（MEM）-バイト。

リソースはコンテナごとに指定されます。次の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は、目的のノードを見つけるために使用される要素の1つです。すでにその上で、ポッドの展開をスケジュールできます。適切なノードをどのように見つけますか？



Kubernetesは、マスターノードまたはマスターノード（Kubernetes Control Plane）を含むいくつかのコンポーネントで構成されています。マスターノードには、kube-apiserver、kube-controller-manager、およびkube-schedulerといういくつかのプロセスがあります。



kube-schedulerプロセスは、新しく作成されたモジュールを調べ、要求されたリソースの数を含め、すべてのモジュール要求に一致する可能性のあるワーカーノードを探す役割を果たします。 kube-schedulerによって検出されたノードのリストがランク付けされます。ポッドは、スコアが最も高いサイト用に計画されています。



^{紫色のポッドはどこに配置されますか？}



写真は、kube-schedulerが新しい紫色のポッドをスケジュールする必要があることを示しています。 Kubernetesクラスターには、AとBの2つのノードが含まれています。ご覧のとおり、kube-schedulerはポッドをノードAにスケジュールできません。使用可能な（未承諾の）リソースが紫色のポッドの要求と一致しません。たとえば、使用可能なメモリは0.5GBであるため、紫色のポッドによって要求された1GBのメモリはノードAに適合しません。しかし、ノードBには十分なリソースがあります。その結果、kube-schedulerは、紫色のポッドの宛先がノードBであると判断します。



これで、要求されたリソースがポッドを開始するノードの選択にどのように影響するかがわかりました。しかし、限界リソースはどのように影響しますか？



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

要求され、リソースを詳細に制限する

_{DockerとKubernetes間のリソースの関係}



要求されたリソースと制限されたリソースがどのように機能するかを説明する最良の方法は、KubernetesとDockerの間の関係を表すことです。上の図では、KubernetesフィールドとDocker起動フラグがどのように関連しているかを確認できます。

メモリ：リクエストと制限

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

上記のように、メモリはバイト単位で測定されます。Kubernetesのドキュメントに基づいて、メモリを数値として指定できます。通常、これは整数です。たとえば、2678、つまり2678バイトです。接尾辞Gを使用することもできますがGi、最も重要なことは、それらが同等ではないことを忘れないでください。 1つ目は10進数で、2つ目はバイナリです。一例として、文書K8Sで述べた：128974848、129e6、129M、123Mi-彼らは事実上等価です。



KubernetesパラメーターはDockerからlimits.memoryのフラグと一致します--memory。の場合にはrequest.memoryDockerはこのフィールドを使用しないため、Dockerの矢印はありません。これが必要かどうか尋ねてもよいですか？はい、必要です。前に言ったように、フィールドはKubernetesにとって重要です。 kube-schedulerは、そこからの情報に基づいて、ポッドをスケジュールするノードを決定します。



クエリに十分なメモリがインストールされていない場合はどうなりますか？



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



メモリ制限を低く設定しすぎるとどうなりますか？



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



要求されたメモリを指定しないとどうなりますか？



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



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



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



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



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



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



通常のために同じ値を設定することをお勧めしますrequest.memoryと、limit.memory..。これにより、Kubernetesは、ポッドを実行するのに十分なメモリがあるが、実行するのに十分ではないノードでポッドをスケジュールすることができなくなります。注意：ポッドをスケジュールする場合、Kubernetesはカウントするだけで、カウントrequests.memoryしlimits.memoryません。

CPU：リクエストと制限

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

CPUを使用すると、すべてがもう少し複雑になります。バックKubernetesとドッカーとの間の関係の絵に行く、あなたはそれがあることがわかりますrequest.cpu一致し--cpu-shares、それは一方で、limit.cpuフラグが一致しcpusドッカーで。



Kubernetesが要求するCPUには、CPUサイクルの割合である1024が掛けられます。フルコアを1つリクエストする場合は、cpu: 1上記のように追加する必要があります。



完全なカーネル（比率= 1024）を要求しても、コンテナーがそれを受け取ることを意味するわけではありません。ホストマシンにコアが1つしかなく、複数のコンテナを使用している場合は、すべてのコンテナが使用可能なCPUをコンテナ間で共有する必要があります。これはどのように起こりますか？写真を見てみましょう。





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



コンテナを実行しているシングルコアホストシステムがあるとします。Mom（Kubernetes）はケーキ（CPU）を焼き、子供（コンテナ）間で共有したいと考えています。3人の子供はケーキ全体（比率= 1024）を望んでおり、別の子供はケーキの半分（512）を望んでいます。ママは公平になりたいと思って、簡単な計算をします。

#    ?
# 3           
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
#   :
3 (/) * 1 ( / ) + 1 (/) * 0.5 ( / )
#   ?
availableCakesNumber = 1
#   ()    ?
newMaxRequest = 1 / 3.5 =~ 28%

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





_{CPUリクエスト-マルチコア（4）システム}



上の画像では、3人の子供がパイ全体を望んでおり、1人が半分を望んでいることがわかります。ママは4つのケーキを焼いたので、彼女の子供たちのそれぞれは彼らが望むだけ多くを得るでしょう。マルチコアシステムでは、プロセッサリソースは利用可能なすべてのプロセッサコアに分散されます。コンテナがフルCPUコアの1つ未満に制限されている場合でも、100％使用できます。



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



それでは話しましょうlimit.cpu..。Kubernetesを制限するCPUに100を掛けます。その結果、コンテナが100μsごとに使用できる時間になります（cpu-period）。



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

• cpusは、設定と;の組み合わせでcpu-periodあり、cpu-quota. cpus = 1.5同等です。cpu-period = 100000cpu-quota = 150000
• cpu-period - CPU CFSスケジューラー期間、デフォルトでは100マイクロ秒。
• cpu-quota-cpu-periodコンテナが制限されている内部のマイクロ秒数。

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



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



不十分なCPU制限を設定するとどうなりますか？



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



CPUリクエストを指定しないとどうなりますか？



メモリと同様に、要求値は制限に等しくなります。



CPU制限を指定しないとどうなりますか？



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



リクエストもCPU制限も指定しないとどうなりますか？



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



ノードが供給できるよりも多くのCPUを要求した場合、ポッドはスケジュールされないことに注意してください。Requests.cpu-最小値ではありませんが、ポッドを起動して障害なく動作するのに十分な値です。アプリケーションが複雑な計算を実行しない場合、最良のオプションはrequest.cpu <= 1、必要な数のレプリカをインストールして実行することです。

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

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



残念ながら、これらの質問に対する明確な答えはありません。アプリケーションのパフォーマンス、必要なCPUまたはメモリの量がわからない場合は、アプリケーションに大量のメモリとCPUを割り当ててから、ベンチマークを実行するのが最善の方法です。



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



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

結論

リソースのクエリと制限は、Kubernetesクラスターを正常に保つのに役立ちます。制限を正しく構成すると、コストが最小限に抑えられ、アプリケーションが常に実行され続けます。



要するに、覚えておくべきことがいくつかあります。

1. 要求されたリソースは、起動時（Kubernetesがアプリケーションをホストする予定の場合）に考慮される構成です。対照的に、リソースを制限することは、アプリケーションがすでにノードで実行されている実行時に重要です。
2. メモリと比較して、CPUは規制されたリソースです。CPUが不足している場合、ポッドはシャットダウンせず、スロットルを開始します。
3. 要求されたリソースとリソース制限は最小値と最大値ではありません！要求されたリソースを特定することにより、アプリケーションがスムーズに実行されるようにします。
4. メモリ要求をメモリ制限と等しく設定することをお勧めします。
5. CPU <=1アプリケーションが複雑な計算を実行しない場合は、要求に応じてインストールすることをお勧めします。
6. ノードが持っているよりも多くのリソースを要求した場合、ポッドはそのノードに対してスケジュールされません。
7. 負荷テストと監視を使用して、要求されたリソース/リソース制限の正しい量を決定します。

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



幸運を！



他に読むべきこと：

1. SREの可観測性：名前名とメトリック構造。
2. 90+ Kubernetes: , , , .
3. Kubernetes .