問題タブ [cgroups]

ユーザー「foo」として実行するアプリケーションがあります。このアプリケーションが実行時に使用できる CPU とメモリに制限を設定したいと考えています。このアプリケーションはサービスではなく、ユーザーが選択して開始できるアプリケーションであるため、「systemctl」や「set-property」などのsystemdツールを使用してこれを実現する方法を理解できません。
どなたかガイダンスをお願いできますか？

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

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

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

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

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

アップデート

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

更新 2

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

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

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

アップデート 3

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

結果は次のとおりです。

リソースチェックに関する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を待っています!

libcgroup がインストールされているUbuntu 14とSUSE Linux Enterprise Server 11 (x86_64)の両方で、ルートを使用して次のことを行いました。

cgcreate -t​​ ngam:home -a ngam:home -g cpuset:/nadav2ndCpuSet

cgset -r cpuset.cpus=1 nadav2ndCpuSet

その後、/sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.cpusを cat すると、次のようになります。

どっちがいい！動作するはずです。

次に、ユーザーngamから、次のコマンドを実行しました。

cgexec -g cpuset:nadav2ndCpuSet ~/whileLoop

whileLoopは、 sqrtを実行するループで実行される単純なプログラムです。

その後、次のエラー メッセージが表示されました。

cgroup グループの変更に失敗しました

なぜそれが起こっているのですか？ありがとう！

cgroup が有効になっている場合、Mesos の細粒度モードでの Spark の動作はどうなるのだろうと思っていました。

1 つの懸念事項は次のとおりです。cgroup なしで Mesos+spark を使用すると、実際の spark エグゼキュータ プロセスが、Mesos に約束したよりも少なくとも 10% 多くのメモリを使用することが既に示されています。cgroup を有効にすると、Spark 実行プログラムが強制終了されますか?

次に、ファイルキャッシュはどのように処理されますか? Spark はファイルキャッシュに大きく依存しています。ファイルキャッシュはMesosのメモリ量に含まれていますか? おそらくそうではありませんが、これに影響を与えることができますか? たとえば、理想的には、Spark で合計 8GB を使用し、そのうちの 5GB を Java プロセスに使用する必要があります (Spark が適切に動作し、5GB を超えて拡大しないと仮定すると)。3GB はファイルキャッシュとして使用する必要があります (最大）。

cgroup はある時点で root 資格情報に依存しているため、これらのことを自分でテストするには、クラスターのシステム管理者から多くのサポート要求を受けなければならないため、誰かがこれを経験したことを願っています。他の人に尋ねずに無駄に。