12

Pod のリソース制限は次のように設定されています。

resource
  limit
    cpu: 500m
    memory: 5Gi

ノードに10Gは mem が残っています。

短時間でポッドを正常に作成しまし5たが、ノードにはまだメモリが残っている可能性があります8G。

メモリの使用量は時間の経過とともに増加し、制限 ( 5G x 5 = 25G > 10G) に達すると、ノードは応答しなくなります。

ユーザビリティを確保するために、ノードにリソース制限を設定する方法はありますか?

アップデート

中心的な問題は、ポッドのメモリ使用量が常に制限と同じであるとは限らないことです。特に、開始直後はそうです。そのため、できるだけ早く無制限の Pod を作成してから、すべてのノードを全負荷にすることができます。それは良いことではありません。制限を設けるのではなく、リソースを割り当てる何かがあるかもしれません。

更新 2

制限とリソースについて再度テストしました。

resources:
  limits:
    cpu: 500m
    memory: 5Gi
  requests:
    cpu: 500m
    memory: 5Gi

合計メモリは 15G で残りは 14G ですが、3 つのポッドがスケジュールされ、正常に実行されています。

> free -mh
              total        used        free      shared  buff/cache   available
Mem:            15G        1.1G        8.3G        3.4M        6.2G         14G
Swap:            0B          0B          0B

> docker stats

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O
44eaa3e2d68c        0.63%               1.939 GB / 5.369 GB   36.11%              0 B / 0 B           47.84 MB / 0 B
87099000037c        0.58%               2.187 GB / 5.369 GB   40.74%              0 B / 0 B           48.01 MB / 0 B
d5954ab37642        0.58%               1.936 GB / 5.369 GB   36.07%              0 B / 0 B           47.81 MB / 0 B

ノードはすぐに潰れそうです XD

アップデート 3

ここで、リソースの制限、 request 5G、および limitを変更し8Gます。

resources:
  limits:
    cpu: 500m
    memory: 5Gi
  requests:
    cpu: 500m
    memory: 8Gi

結果は次のとおりです。 ここに画像の説明を入力

リソースチェックに関するk8sソースコードによると：

ここに画像の説明を入力

合計メモリは のみ15Gで、すべての Pod が を必要24Gとするため、すべての Pod が強制終了される可能性があります。16G(私の単一のコンテナは、制限されていない場合、通常よりも費用がかかります.)

これは、ポッドの強制終了やノードのクラッシュを避けるために、を とrequests 正確に等しく保つ方がよいことを意味します。値が指定されていないlimitsかのように、 as defaultに設定されますが、正確には何に使用されますか? K8sが主張したこととは反対に、IMOだけで完全に十分だと思います.ノードの使いやすさを確保するために、リソースリクエストを制限よりも大きく設定するのが好きです.requestslimitrequestslimits

更新 4

Kubernetes 1.1は、次の式でポッドのメモリ リクエストをスケジュールします。

(capacity - memoryRequested) >= podRequest.memory

Vishnu Kannanが言ったように、kubernetes はメモリ使用量を気にしていないようです。そのため、メモリが他のアプリによって多く使用されている場合、ノードはクラッシュします。

幸いなことに、コミットe64fe822から、式は次のように変更されました。

(allocatable - memoryRequested) >= podRequest.memory

k8s v1.2を待っています!

4

2 に答える 2

19

Kubernetes リソース仕様には、 と の 2 つのフィールドがrequestありlimitます。

limitsコンテナが使用できるリソースの量に上限を設けます。メモリの場合、コンテナーがその制限を超えると、OOM で強制終了されます。CPU の場合、その使用量が抑制される場合があります。

requestsPod が配置されているノードに、少なくともその容量を使用できるようにするという点で異なります。ノードのリソースが不足することなく Pod を特定のサイズまで拡張できるようにする場合は、そのサイズのリクエストを指定します。ただし、これにより、スケジュールできるポッドの数が制限されます。10G ノードは、5G メモリ要求で 2 つのポッドしか適合できません。

于 2016-02-25T17:35:48.773 に答える
8

Kubernetes はサービスの品質をサポートしています。Pod がlimits設定されている場合、Pod はそのクラスに属しており、Guaranteedシステム メモリのプレッシャーが原因で Pod が強制終了される可能性は非常に低くなります。ノード上で実行する docker デーモンまたはその他のデーモンが大量のメモリを消費する場合、保証された Pod が強制終了される可能性があります。

Kube スケジューラーは、スケジューリング中にメモリー容量と割り当てられたメモリーを考慮に入れます。たとえば、10 GB ノードでそれぞれ 5 GB を要求する 2 つを超えるポッドをスケジュールすることはできません。

現時点では、スケジューリングの目的で Kubernetes によってメモリ使用量が消費されることはありません。

于 2016-02-25T21:24:35.630 に答える