Kubernetes: Kubelet / Kubernetesはスワップ対応で動作するはずです

スワップのサポートは重要です。 保証されたポッドは決して交換を必要とすべきではありません。 バースト可能なポッドは、スワップを必要とせずに要求を満たす必要があります。 BestEffortポッドには保証がありません。 現在、kubeletには、ポッド全体で適切な量の予測可能な動作を提供するためのスマートさが欠けています。

このトピックについては、今年初めにリソース管理で対面で話し合いました。 私たちは、実現できる利益と比較して、短期的にこれに取り組むことにあまり関心がありません。 スワップの最適化を試みる前に、圧力検出に関する信頼性を向上させ、遅延に関する問題を最適化することをお勧めしますが、これが優先度が高い場合は、ぜひご協力ください。

/種類の機能

@derekwaynecarr説明ありがとうございます！ kubernetesのスワップを無効にする必要がある理由に関する情報/ドキュメントを取得するのは困難でした。 これが私がこのトピックを開いた主な理由でした。 現時点では、この問題の優先度は高くありません。ただ、話し合うことができる場所があることを確認したかっただけです。

https://github.com/kubernetes/kubernetes/issues/7294 –スワップを利用できるようにすると、メモリ制限との相互作用が非常に奇妙で悪くなります。 たとえば、メモリ制限に達したコンテナは、スワップにスピルオーバーし始めます（f4edaf2b8c32463d6485e2c12b7fd776aef948bc以降、これは修正されているようです。スワップがあるかどうかに関係なく、スワップの使用は許可されません）。

これは私たちにとっても重要なユースケースです。 時々高いメモリ使用量（> 30GB）に遭遇するcronジョブがあり、40GB以上のノードを永続的に割り当てたくありません。 また、3つのゾーン（GKE）で実行している場合、このようなマシンは3つ（各ゾーンに1つ）割り当てられます。 また、この構成は3つ以上の本番インスタンスと10以上のテストインスタンスで繰り返す必要があるため、K8を使用するには非常にコストがかかります。 25以上の48GBノードが必要になり、莫大なコストがかかります。
スワップを有効にしてください！。

本当にスワップが必要な人のための回避策。 もし、あんたが

• --fail-swap-on=false kubeletを開始します
• ノードにスワップを追加します
• メモリ要件を指定しないコンテナは、デフォルトで、スワップを含むすべてのマシンメモリを使用できます。

それが私たちがしていることです。 または、少なくとも、私は実際にそれを個人的に実装しなかったと確信していますが、それが私が収集したものです。

これは、どのコンテナも明示的なメモリ要件を指定していない場合にのみ、実際に実行可能な戦略になる可能性があります...

私たちはGKEで実行していますが、これらのオプションを設定する方法がわかりません。

誰かがkubeletでの記憶の排除への影響を評価できれば、zswapの採用を検討することを歓迎します。

ローカルのUbuntuラップトップでKubernetesを実行しており、再起動するたびにスワップをオフにする必要があります。 また、スワップがオフになっているため、メモリ制限に近づかないように心配する必要があります。

再起動するたびに、既存のインストールでの構成ファイルの変更のようにスワップをオフにする必要がない方法はありますか？

クラスターで実行されているノードでスワップは必要ありません。

Kubernetes Local Devクラスター以外のラップトップ上の他のアプリケーションで、スワップをオンにする必要があります。

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

現在、フラグは機能していません。

# systemctl restart kubelet --fail-swap-on=false
systemctl: unrecognized option '--fail-swap-on=false'

次のKubeletフラグを設定します： --fail-swap-on=false

1：59 PMで火、2018年1月30日には、icewheel [email protected]は書きました：

ローカルのUbuntuラップトップでKubernetesを実行していて、再起動するたびに
スワップをオフにする必要があります。 また、私は記憶に近づかないように心配する必要があります
オフの場合はスワップする場合は制限します。

再起動するたびに、スワップをオフにする必要がない方法はありますか？
既存のインストールで構成ファイルを変更しますか？

クラスターで実行されているノードでスワップは必要ありません。

Kubernetes LocalDev以外のラップトップ上の他のアプリケーション
スワップをオンにする必要があるクラスター。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-361748518 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA3JwQdj2skL2dSqEVyV46iCllzT-sOVks5tP5DSgaJpZM4PwnD5
。

-
マイケル・タウフェン
Google SWE

ありがとう@mtaufen

クラスタをブートストラップするシステム（テラフォームなど）の場合、サービスファイルを変更する必要がある場合があります

これは私のために働いた

sudo sed -i '/kubelet-wrapper/a \ --fail-swap-on=false \\\' /etc/systemd/system/kubelet.service

デフォルトとしてスワップをサポートしていませんか？ これを聞いて驚きました-Kubernetesはプライムタイムの準備ができていると思いましたか？ スワップはそれらの機能の1つです。

これは、ほとんどのオープンユースケースでは実際にはオプションではありません。これは、VMMが非アクティブなページを切り替えることで、Unixエコシステムが実行されるように設計されている方法です。

スワップなしまたはメモリ制限なしを選択する場合は、いつでもスワップを維持することを選択し、ページングを開始するときにホストをさらに起動するだけで、コストを節約できます。

誰かが明確にすることができます-ポッド定義でメモリ制限を使用している場合にのみ、メモリ排除の問題が問題になりますが、それ以外の場合は問題ありませんか？

アプリケーションメモリの動作を制御できる世界で作業するのは良いことです。メモリ使用量の低下を心配する必要はありませんが、ほとんどのアプリケーションには非アクティブなメモリスペースがたくさんあります。

正直なところ、スワップなしでサーバーを実行するというこの最近の動きは、約40年のメモリ管理設計を無視しながら、人々をより大きなメモリインスタンスに強制しようとするPaaSプロバイダーによって推進されていると思います。 現実には、カーネルはどのメモリページがアクティブであるかを知ることについて本当に優れています-それがその仕事をするようにします。

これには、ノードでメモリが使い果たされると、完全にロックアップされる可能性があるという効果もあります。しばらくして速度を落とし、回復するのではなく、ノードを再起動する必要があります。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

クラスタノードに多数のディスク読み取りがあります（ K8s Version - v1.11.2 ）。 スワップメモリ​​を無効にしていることが原因である可能性がありますか？

https://stackoverflow.com/questions/51988566/high-number-of-disk-reads-in-kubernetes-nodes

@srevenantクラスターの世界では、他のノードのRAMが新しいスワップです。 そうは言っても、スワップが理にかなっている2つの1ノードK8sインスタンスを実行します。 ただし、これはK8の一般的な使用例ではありません。

@srevenant私はあなたに完全に同意します
Linuxディストリビューションをインストールすると、SWAPの問題はデフォルトで常にオンになっているため、K8sをインストールする前に、SWAPをオフに設定する必要があります。これは驚きでした。
Linuxカーネルは、サーバーがRAMの制限に達しようとしているときに、サーバーのパフォーマンスを特別に一時的に向上させるためにSWAPを管理する方法をよく知っています。
これは、K8が正常に機能するためにSWAPをオフにする必要があることを意味しますか？

私はこの作品を作ることに興味があり、テストするスキルと多くのマシンを持っています。 貢献したい場合、どこから始めればよいですか？

@superdaveは、スワップをサポートする方法を説明するKEPをkubernetes / communityにまとめて、sig-nodeに提示してください。 どうぞよろしくお願いいたします。

Kuberneteのポッドでスワップを適切に有効にすることを意味します。 ほとんどすべてのコンテナはカスタムLinuxインスタンスであり、デフォルトでスワップをサポートしているため、スワップを使用しないことは実際には意味がありません。
この機能の実装が複雑であることは理解できますが、それが私たちの前進を妨げたのはいつからですか？

スワップを無効にするとノードのメモリが不足するとノード障害が発生するため、スワップの問題はKubernetesで解決する必要があることに同意する必要があります。 たとえば、3つのワーカーノード（それぞれ20GBのRAM）があり、RAMの制限に達したために1つのノードがダウンした場合、その間にすべてのポッドを転送した後、他の2つのワーカーノードもダウンします。

実際のメモリ要求に応じてメモリ要求を設定することでこれを防ぐことができます
アプリケーションの必要性。

アプリケーションのメモリの3分の1が2桁の場合
遅いストレージ、それは何か有用な仕事をすることができますか？

6:51の水、2018年9月26日にvasicvuk [email protected]書きました：

スワップの問題はKubernetesで解決する必要があることに同意する必要があります。
スワップを無効にすると、ノードのメモリが不足するとノード障害が発生します。 にとって
たとえば、3つのワーカーノード（それぞれ20GBのRAM）があり、1つのノードが
RAMの制限に達したため、他の2つのワーカーノードもダウンします
その間にすべてのポッドをそれらに転送した後、ダウンします。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-424604731 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAICBqZApBscFl5aNA4IcYvlxcvPA88Tks5ueyPlgaJpZM4PwnD5
。

@matthiasr 10〜50のサービスがある場合にそれを行うことができます。 しかし、クラスターで200を超えるサービスを実行していて、それらの半分が公式のHelmチャートを使用してデプロイされており、メモリ要求がない場合は、手が離せません。

しかし、それでは、メモリが不足していると、問題に対処する必要がありませんか？

多くの場合、 @ matthiasrは、プロセスに一度マップされたメモリが1回だけ使用されるか、実際には使用されませんでした。 これらは有効なケースであり、メモリリークではありません。 スワップすると、それらのページは最終的にスワップされ、二度とスワップインされない可能性がありますが、より適切に使用するために高速RAMを解放します。

また、応答性を確保するための良い方法としてスワップをオフにすることもありません。 ファイルをメモリに固定しない限り（少なくとも実行可能ファイルに対してK8が持つ必要のある機能）、カーネルは、メモリ不足、または単に使用不足に応じて、ファイルにバックアップされたすべてのページをスワップアウトします。

スワップを有効にしても、カーネルの動作は大きく変わりません。 匿名ページ、またはCOWマップファイルからロードされた変更済みページをスワップアウトするためのスペースを提供するだけです。

スワッピングを完全にオフにすることはできないため、匿名メモリスワッピングの特殊なケースが有効になっているかどうかに関係なく、K8sはその存在を存続させる必要があります。

これがバグになります。実際にオフにできないカーネル機能をサポートできていません。

@ボーン

カーネルは、メモリ不足、または単に使用の欠如に応じて、ファイルにバックアップされたすべてのページをスワップアウトします。 スワップを有効にしても、カーネルの動作は大きく変わりません。

スワッピングを完全にオフにすることはできません。

私が自分自身を教育できるように、これについていくつかの参考資料を提供できますか？

ファイルをメモリに固定しない限り（少なくとも実行可能ファイルに対してK8が持つ必要のある機能）、

k8sに使用させたい機能は何ですか？ バイナリが静的である場合は、ポッド上のtmpfsにコピーするだけで、ページングの待ち時間が短縮されます。

@adityakaliスワップがオフになっている場合の、カーネルでのスワップの影響について何か考えはありますか？

私が自分自身を教育できるように、これについていくつかの参考資料を提供できますか？

最新のすべての仮想メモリOSと同様に、Linuxは実行可能ファイルをディスクからメモリにページングすることを要求します。 メモリプレッシャーの下で、カーネルは他のメモリページと同じように「スワップを無効にする」ことによって無効にする_only_スワップは、「匿名メモリ」 、つまりファイルに関連付けられていないメモリです（最良の例は「スタック」および「ヒープ」データ構造です）。

もちろん、上記の説明ではスキップしている詳細がたくさんあります。 特に、自分のメモリ空間の、実行可能ファイルができる「ロック」部分をRAMに使用してmlock家族システムコールのを介して巧妙なことを行うmadvise()同じページを複数のプロセスで共有されている場合、それが複雑になります、 （例：libc.so）など。これらのマンページ、または教科書やLinuxカーネルのsource / docs / mailing-listなどの一般的なもの以外を読むためのより便利なポインタがないのではないかと思います。

したがって、上記の実際的な効果は、プロセスがメモリ制限に近づくと、カーネルがRAMから_code_部分と定数を強制的に削除することです。 次にそのビットのコードまたは定数値が必要になると、プログラムは一時停止し、ディスクからフェッチするのを待ちます（そして何か他のものを削除します）。 したがって、「スワップが無効」の場合でも、ワーキングセットが使用可能なメモリを超えると同じ劣化が発生します。

人々が上記を読んで、すべてをメモリにmlockするか、アンチスワップ魔女狩りの一部としてすべてをRAMドライブにコピーするように呼び出す前に、ここで関心のある実際のリソースは、合計サイズではなく、ワーキングセットサイズであることを繰り返したいと思い

そのようなものの私の最新の個人的な実例は、kubernetes実行可能ファイルをリンクしています。 ワーキングセットがはるかに小さいにもかかわらず、go linkステージには数ギガバイトの（匿名の）仮想メモリが必要なため、現在（皮肉なことに）kubernetesクラスターでkubernetesをコンパイルできません。

「仮想メモリではなく、ワーキングセットに関するもの」のポイントを実際に理解するために、通常のファイルI / Oを大量に実行し、mmapとは関係のないプログラムを検討してください。 十分なRAMがある場合、カーネルは繰り返し使用されるディレクトリ構造とファイルデータをRAMにキャッシュし、ディスクへの移動を回避し、ディスクの書き込みを最適化するために書き込みを一時的にRAMにバーストできるようにします。 このような「ナイーブな」プログラムでさえ、ワーキングセットのサイズと使用可能なRAMに応じて、RAM速度からディスク速度に低下します。 何かをRAMに不必要に固定すると（たとえば、mlockを使用するか、スワップを無効にする）、カーネルが実際に役立つ何かのために物理RAMのそのページを使用するのを防ぎ、（ワーキングセットに十分なRAMがない場合）ディスクI / Oをさらに高価な場所に移動しました。

@superdave ：私も現状を改善することに興味があります。 別の目でドキュメントを確認したり、キーボードを手にしたりする場合は、私を含めてください。

そのようなものの私の最新の個人的な実例は、kubernetes実行可能ファイルをリンクしています。 ワーキングセットがはるかに小さいにもかかわらず、go linkステージには数ギガバイトの（匿名の）仮想メモリが必要なため、現在（皮肉なことに）kubernetesクラスターでkubernetesをコンパイルできません。

@superdave ：私も現状を改善することに興味があります。 別の目でドキュメントを確認したり、キーボードを手にしたりする場合は、私を含めてください。

手元にある問題の良い要約！ スワップスラッシングは、確かにここでの重要な問題です。 それは私が合理的に対処したいと思っていることです。 十分に検討する時間がなかったとはいえ、スワッピングアクティビティのある種のメトリック（特定の時間枠でのページイン/アウト、おそらくパーセンタイルルールを使用して、プロセスが一時的に突然急上昇する）スワップが有効になっている場合、エビクションについて評価するのに良い方法かもしれません。 いくつかの指標がありますが、考えられるユースケースを注意深く評価するだけでなく、いじくり回すための多くのノブを提供したいと思います。 また、仮想メモリの相互作用のためにポッドを計測できることは、人々がより良く調整するのに役立つはずだと思います。 私は、現在何が存在するかを言うためにすでに提供されているものに十分に精通していませんが、私はそれを見つけるつもりだと思います。

また、個々のポッド/コンテナーでのスワッピング動作をどれだけうまく制御できるかを知る必要がある制御についても十分に理解していません。 保持または交換のために物事を「解放」できると便利ですが、開発者は、物事がとにかく常駐することを絶対に保証する必要がある場合は、明らかにいつでも自由にmlock（）を試すことができます。

いずれにせよ、はい、私は絶対にこれを前進させたいと思います。 私は最近仕事に忙殺されています（誰かが不注意に大きくしない限り、99％の時間はRAMのギグを必要としないため、負荷がかかった状態でスワップできることで恩恵を受けた、k8sでの独自のマイクロサービスでいくつかのOOMの問題を処理しますリクエスト）、しかしそれについて私に遠慮なく続けてください。 私はこれまでKEPプロセスに参加したことがないので、かなり環境に配慮するつもりですが、最近は、ポーリングよりも割り込みベースではるかにうまく機能しています。 :-)

zramはスワップに便乗することで機能することを指摘したいと思います。 k8にスワップがない場合、メモリ圧縮はありません。これは、ほとんどの非Linux OSがデフォルトで有効にしているものです（キューWindows、MacOS）。

k8にはUbuntuインスタンスがあり、毎晩大量のバッチジョブを実行し、大量のメモリを消費します。 ワークロードは事前に決定されていないため、OOMを回避するために、実際のメモリ消費量に関係なく、ノードに16GBを（高価に）割り当てる必要があります。 ローカル開発サーバーでのメモリ圧縮により、ジョブはわずか3GBでピークに達します。 それ以外の場合、日中は1GBのメモリしか必要としません。 スワップを禁止し、メモリ圧縮を禁止するのは非常にばかげた動きです。

ここでの主な関心事はおそらく孤立だと思います。 一般的なマシンは大量のポッドをホストでき、メモリが不足すると、それらはスワッピングを開始し、相互のパフォーマンスを完全に破壊する可能性があります。 スワップがない場合、分離ははるかに簡単です。

ここでの主な関心事はおそらく孤立だと思います。 一般的なマシンは大量のポッドをホストでき、メモリが不足すると、それらはスワッピングを開始し、相互のパフォーマンスを完全に破壊する可能性があります。 スワップがない場合、分離ははるかに簡単です。

ただし、前に説明したように、スワップを無効にしても、ここでは何も購入されません。 実際、全体的にメモリの負荷が高まるため、未使用のデータをスワップアウトする可能性がある場合に、カーネルがワーキングセットの一部を削除することを余儀なくされる可能性があります。そのため、状況はさらに悪化します。

スワップを有効にすること自体で、実際には分離が改善されるはずです。

しかし、想定どおりに（そしてGoogleがBorgで物事を実行する方法で）実行する場合は、多くの費用がかかります。すべてのコンテナーでメモリの上限を指定する必要があります。 ボーグはGoogleインフラストラクチャを利用して、必要に応じて制限を学習します（過去のリソース使用量とOOMの動作から）が、それでも制限があります。

私は実際、K8Sの人々がメモリ制限をオプションにすることを許可したことに少し戸惑っています。 CPUとは異なり、スワッピングが原因でシステムが完全にロックアップするのを見た人は誰でも証明するように、メモリの負荷はシステムのパフォーマンスに非常に非線形の影響を及ぼします。 デフォルトで実際に必要であり、無効にすることを選択した場合は警告が表示されます。

しかし、想定どおりに（そしてGoogleがBorgで物事を実行する方法で）実行する場合は、多くの費用がかかります。すべてのコンテナーでメモリの上限を指定する必要があります。 ボーグはGoogleインフラストラクチャを利用して、必要に応じて制限を学習します（過去のリソース使用量とOOMの動作から）が、それでも制限があります。

私は実際、K8Sの人々がメモリ制限をオプションにすることを許可したことに少し戸惑っています。 CPUとは異なり、スワッピングが原因でシステムが完全にロックアップするのを見た人は誰でも証明するように、メモリの負荷はシステムのパフォーマンスに非常に非線形の影響を及ぼします。 デフォルトで実際に必要であり、無効にすることを選択した場合は警告が表示されます。

これで対処できない問題は、上限が可変であり、一部のプロセスで常に認識されているとは限らないことだと思います。 私が扱っている問題は、特にk8sを使用して3Dモデルレンダラーノードを管理することに焦点を当てています。 レンダリングされるモデルとシーンのアセットに応じて、必要なRAMの量はかなり異なる可能性があり、ほとんどのレンダリングは小さくなりますが、_some_が巨大になる可能性があるという事実は、リクエストと制限がはるかに多くのメモリを予約する必要があることを意味しますポッドが設定された制限を超えてスワップスペースに波及する可能性があるのではなく、実際にはOOMを回避するために90％の時間が必要です。

はい。その場合は、上限を「なし」などに設定します。 私のポイントは、それがデフォルトであってはならないということです。 マスターが「アイテム」（ジョブ）のサイズを知らないため、「ナップサック」（クベレット）に入れようとしているため、何も設定しないと、あらゆる種類のインテリジェントなワークロードスケジューリングが完全に無効になります。

ここでの問題は、ジョブがスワップに流出することではなく、そのノードで実行されている他のすべてのジョブもスワップに流出することです。 そして、それらのいくつか（ほとんど？）は、まったくそれを気に入らないでしょう。

Borgのプログラムは、データの整合性に影響を与えることなく、いつでもプリエンプティブ（専門用語に精通していない人にとっては殺すことができる）になるように作成されています。 これは実際には私がグーグルの外ではあまり見ないものであり、あなたのプログラムの潜在的な突然の死亡を認めることは、はるかに信頼性の高いソフトウェアを書くことにつながります。 しかし、私は逸脱します。

そのようなプログラムで構築されたシステムは、オーバーサブスクライブされたノードで苦しみ続けるよりも、それらのプログラムが死んでセルの他の場所（Borgクラスター）に生まれ変わることをはるかに好むでしょう。 それ以外の場合、特にジョブ内のタスクの数が多い場合、テールレイテンシは非常に問題になる可能性があります。

誤解しないでください。これが物事を実行する唯一の「正しい」方法だと言っているわけではありません。 私は、設計に含まれる可能性のある理論的根拠を解明しようとしています。

免責事項：私は元Google社員であり、ボーグを使用していくつかの非常に大規模なサービスを実行していたので、それをよく知っています。その知識は主にKubernetesに変換されます。 私は現在Googleを利用していません。ここに書いたものはすべて、私自身の考えです。

@ 1e100 ：「VMの合計」サイズと「ワーキングセット」のサイズを

（私は元Google-SREでもあり、これらの一般的なGoogleの神話が、k8sでもスワップを無効にしても問題ない（または望ましい）と判断した理由であることに同意します。いくつかのGoogleチームが行くのを見ました。スワップを無効にしてもスワッピングが無効にならないこと、およびメモリの「ハード」（oom-kill）制限を説明するだけで発生するメモリの浪費の総計は、k8sで改善したいことの一部です。は、borgリソースモデルが最初に設計されたときに持っていなかったcgroup / swap調整可能なノブの数であり、このようなお風呂で赤ちゃんを投げるアプローチなしで、望ましい結果を達成できると確信しています。 。また、Googleのトレードオフは、より良い/既知の最悪の場合の時間（つまり、リアルタイムの動作）を達成するために、平均して効率が低下することがよくあり、これはGoogle以外の望ましい選択ではないことが多いことにも注意します-小さい/ホストの数が減り、SLOが緩和され、予算が減り、定義が不十分になります edバッチジョブ、コンパイルされていないヒープの使用の増加-非効率的な言語など）

匿名メモリの交換は発生しません。 メモリがマップされているもの（プログラムコードとデータを含む）は、メモリが不足している場合でもスワップできます。そのため、デフォルトでRAMの制限が必要であると提案しました。そもそも、メモリが不足する可能性を低くするためです。 さらに厳しい保証が必要なワークロードには、 mlockall()と低いswappiness値もあります。

以前のGoogleSREとして、RAMの上限を指定しないこと、またはタスクが気まぐれで好きなものを交換できるようにすることは、単に反対者になりたい場合を除いて、良いことだと主張することはできません。 メモリマップトファイルの交換は十分に悪いことであり、さらに多くの潜在的なパフォーマンスの崖をミックスに導入することは良いことではありません。

これらは設計上共有環境であり、プログラムが新しいパフォーマンスを追加するのではなく、互いのパフォーマンスを予測不可能にする方法を排除したいと考えています。 Google SREが言うように、「希望は戦略ではありません」。 スワップスラッシングは、SSDにスワップしている場合でも、Linuxマシンを完全かつ回復不能にロックするための最も簡単な方法です。 マシン上で1つのワークロードを実行しているだけでも、数十は言うまでもなく、それは良いことではありません。 相関する障害は、タスク/ポッドが少ない小さなクラスターでは特に問題になる可能性があります。

必要に応じて、今日でもスワップチェックを無視することができますが、その場合はすべての賭けがオフになっていることを明確に理解しています。

はい、スケジューリングに使用する「サイズ」が必要であり、（意図しない）オーバーコミットを回避する必要があることに完全に同意します。 また、Linuxは回復に時間がかかるため、グローバルVMスラッシュを回避したいと考えています。 私たちが望んでいるのは、カーネルが匿名メモリを交換し、そのRAMを他の何かに再利用できるようにすることです。これは、それができないシステムよりも厳密に優れているためです。 理想的には、個々のコンテナーがRAMとディスクのトレードオフを管理できるようにし、他のコンテナーへの影響を最小限に抑えながら、独自のリソース（割り当て超過/割り当て不足）の選択の結果に直面できるようにします。

私がこれでどこに行くのかを示すために、私の現在のストローマンの提案は次のとおりです。

• 比喩は、各コンテナは、一定量のRAM（ limits.memory ）とスワップを備えたマシン上にあるように動作するというものです。
• 他のリソースと同じ： requests.memoryに基づいてスケジュールし、 limits.memory基づいて制限を課します。 この場合の「メモリ」は「RAM」を意味します-スワップの使用は無料です。
• 具体的には、k8s requests.memory -> cgroup memory.low （オーバーコミット係数によって縮小されます）。 k8s limits.memory -> cgroup memory.high 。
• コンテナが設定されたメモリ制限を超えると、使用可能な空きRAMの量に関係なくスワップを開始します。 cgroupsのおかげで、これはVMの使用だけでなく、コンテナに起因するブロックキャッシュ、ソケットバッファなども含まれます。 これにより、他のコンテナ（またはホストプロセス）にメモリを圧迫することを防ぎます。 削除するページを探すとき、カーネルはメモリ要求サイズを超えているコンテナを探します。
• k8sがホストへの新しいポッドのスケジュールを停止する合計スワップ使用量のkubeletソフト制限を導入します（imagefsなどの他の「共有ファイルシステム」とまったく同じです）。
• 合計スワップ使用量のハード制限に達した場合は、qos-class / priorityと「リクエスト」より上のVMサイズに基づいてポッドの削除を開始します（imagefsなどの他の「共有ファイルシステム」とまったく同じです）。
• コンテナがワーキングセット（ requests.memory ）を大幅に超えると、スラッシュする可能性があります（ limits.memoryを超えるか、ホストで使用できるRAMが十分でない場合）。 リソースメカニズムを通じて、これについて明示的には何もしません。 コンテナがスワップスラッシングの場合、（おそらく）ライブネス/準備プローブチェックに失敗し、そのメカニズムによって強制終了されます（つまり、応答性SLAが構成されていない場合はスワップスラッシングで問題ありません）。

最終的な結果として、管理者は各システムで「十分な」スワップを構成する責任があります。 アプリケーションは、設定する必要がありますlimits.memory彼らがこれまで使用したいRAM、および_max_でrequests.memory （ETCカーネルバッファを含む）、それらの意図されたワーキングセットで。 他のリソースと同様に、保証されたqosクラス（limit == request）、バースト可能（limit undefinedまたは！= request）、ベストエフォート（limitまたはrequestなし）が引き続き適用されます。 特に、これにより、バースト可能なプロセスが意図したワーキングセットの近くで宣言するようになり（大きな安全バッファーがない）、効率的な割り当て（理想的にはワーキングセットに割り当てられたRAMの正確に100％）が可能になり、コンテナーがそれを超えるとスムーズなパフォーマンスの低下が生じます- CPUのような他の「寛容な」リソースと同じように。

これはLinuxcgroup内で実装可能であり、分離の懸念に対処し、他のk8sリソースによって設定された概念的な先例を継続し、スワップが無効になっている場合は既存の動作に低下すると思います（移行が容易になります）。 私が持っている唯一の未解決の質問は、これが実装されているものであるかどうかです（「swapfs」kubeletのソフト/ハード制限を除く）-具体的な提案とアクションアイテムを書く前に、実際のkubelet / CRICgroupsコードを読む必要があります。

上記に関するコメント/ディスカッションは、このgithubの問題ではおそらく適切ではありません（これは貧弱なディスカッションフォーラムです）。 上記にひどい問題がある場合は、k8s slackに関するgusleesへのフィードバックを歓迎します。それ以外の場合は、適切なドキュメントを作成し、ある時点で通常の設計に関するディスカッションを行います。

議論のためのより良いフォーラムを持つことができるように、正式なドキュメントを作成することをお勧めします。

同意しました。 私はこれについていくつかの明確なアイデアを持っているので、KEPを書くのを手伝ってうれしいですが、私はこれまで一度もやったことがなく、むしろ舵にもっと経験豊富な手を持っていたいです。

しかし、また、暇なときにSlackチャネルに追いつくための帯域幅がありません。 より非同期的な調整方法がある場合は、お知らせください。

物事を存続させるためだけに：私はまだKEPやこのための実装に取り​​組むことに非常に興味があります。 物事が落ち着いたら（次の週末に備えてワークショップがあります）、Slackチャネルに参加してみます。

こんにちは、現在起こっているこの問題についての公開討論はありますか？ （k8sのたるみは、現時点ではすべての人に公開されているわけではなく、しばらくは公開されないと思います）。

@leonavesは、現在AFAIKで行われているスラックについての議論はありません。 @gusleesからの最後のコメントは、ディスカッションの最後です。 開始するには、kubernetes / Enhancementsリポジトリに詳細が記載されたKEPが必要であり、おそらくメーリングリストのスレッドも必要であることに注意してください。

たるみを再開するためのトンネルの終わりもすぐにあるようです。 私の指を交差させます。

結局のところ、私にはまだ別のSlackチャネルに参加するための精神的な帯域幅がありません。 私はまだこれについて電子メールで共同作業をしていると思います。

本当にスワップが必要な人のための回避策。 もし、あんたが

• --fail-swap-on=false kubeletを開始します
• ノードにスワップを追加します
• メモリ要件を指定しないコンテナは、デフォルトで、スワップを含むすべてのマシンメモリを使用できます。

それが私たちがしていることです。 または、少なくとも、私は実際にそれを個人的に実装しなかったと確信していますが、それが私が収集したものです。

これは、どのコンテナも明示的なメモリ要件を指定していない場合にのみ、実際に実行可能な戦略になる可能性があります...

この方法はもう機能しませんか！？ スワップをオンにして、メモリ設定なしでポッドをデプロイし、このコンテナを取得しました

$ docker inspect <dockerID> | grep Memory
            "Memory": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1

MemorySwapは「0」です。これは、このコンテナがスワップにアクセスできないことを意味します:(

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-ライフサイクルが古くなっています。

/ remove-lifecyclestale

この問題の読者のための別のリファレンスとして、これをここにドロップします： https ：

関連先： https ：

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

この機能は、いくつかのユースケースで本当に必要です。 現在、機械学習にk8sを使用しており、大きなモデルをメモリにロードする必要がある場合があり（この場合、APIリクエストごとに500MBになることもあります）、物理メモリの制限が深刻な問題を引き起こしています。 スケールアウトは技術的なPOVからは機能しますが、コストは高額になります。オプションとして仮想メモリがあれば、それは素晴らしいことです。

このチケットが再びロードマップに戻る可能性はありますか？

mmapの場合のように聞こえます。

私もこの機能に非常に興味があります。 これに関するニュースはありますか？

現在不足している時間があれば、これを調べ始めたいと思いますが、問題を悪化させる標準的なケースを1つか2つ用意して、より完全に特徴付けられるようにするとよいでしょう。スラッシングを開始し、すべてが地獄に行きます」）そして究極のアプローチと修正が検証されました。

将来のソリューションでは、スワップのセキュリティへの影響も考慮する必要があります。 これは明らかに、Unix環境で実行されているものすべてに当てはまりますが、スワップなしの疑似保証でk8sポッドを実行することに慣れていて、メモリの規律について怠惰になっている場合、これが有効になっていると、かなり失礼な驚きになる可能性があります。ディフォルト。

問題を悪化させる標準的なケースを1つか2つ持っておくと、より完全に特徴付けることができます。

それはKEPのように聞こえます。

将来のソリューションでは、スワップのセキュリティへの影響も考慮する必要があります。 これは明らかに、Unix環境で実行されているものすべてに当てはまりますが、スワップなしの疑似保証でk8sポッドを実行することに慣れていて、メモリの規律について怠惰になっている場合、これが有効になっていると、かなり失礼な驚きになる可能性があります。ディフォルト。

このロジックは、Kubernetesが使用されているかどうかに関係なく、コンテナが混在して実行されているすべてのプロセスに適用されます。

同意しました！ ただし、Dockerはすでにスワップを使用した実行を明示的にサポートしています。 Kubernetesは明示的には行いません（強制することはできますが）。 私の主張は、それは少なくとも声を上げるべきだということです。なぜなら、それはすべての人の脅威モデルに含まれているわけではないからです。特に、以前にそれについて考える必要がなかった場合はそうです。

また、はい、 @ sftim 、そうです。 :-)私が言っているのは、KEPを作成/貢献したいということだと思いますが、冒険する前に、特定のテストシステムで問題を確実に実行する最小限のテストケースを1つか2つ見たいと思います。適切な問題を解決していることを確認できます。

@superdaveどのようなテストケースを考えていますか？

これが簡単なテストです：

1. 1ノード、16 GiBのRAM、64GiBのページファイルでクラスターをセットアップします。
2. それぞれが1GiBのメモリ要求と1GiBのメモリ制限を持つ20個のポッドをスケジュールしてみてください。
3. すべてがスケジュールされているわけではないことに注意してください。

ここに別のものがあります：

1. それぞれが16GiBのRAMと64GiBのページファイルを備えた6台のマシンをセットアップします。
2. デフォルトのオプションでkubeadmを使用して、これらのマシンをKubernetesクラスターとして構成してみてください。
3. kubeadmは、スワップが使用されていることに満足していないことに注意してください。

現在、最も立派なクラウドプラットフォームでSSDに大きな変化があり、LinuxがSSDでのスワッピング専用の最適化を備えていることを考えるとhttps://lwn.net/Articles/704478/圧縮の可能性が追加されているため、この状況はスワップを利用するまったく新しい機会になります。メモリが不足した場合の追加RAM用の予測可能で高速なリソース。
無効にされたスワップは、I / Oバッファに使用されない場合に未使用のRAMが無駄になるのと同じように、無駄なリソースになります。

@superdave

同意しました！ ただし、Dockerはすでにスワップを使用した実行を明示的にサポートしています。 Kubernetesは明示的には行いません（強制することはできますが）。 私の主張は、それは少なくとも声を上げるべきだということです。なぜなら、それはすべての人の脅威モデルに含まれているわけではないからです。特に、以前にそれについて考える必要がなかった場合はそうです。

その場合、 kubeletがそのメモリスペースをmlock()すると想定し、スワップアウトまたはOOMキルを回避するためにOOMキル優先度を低く設定し、 swapinessでcgroup内のすべてのコンテナを実行するのが妥当です。 0に設定されています。 誰かがフォームスワッピングの恩恵を受けたい場合は、ポッド内の特定のコンテナにenableSwapiness: 50オプションを使用してオプトインできます。
驚きはありません、電池が含まれています。

@sftimこれらは、a）Kubeletがコンテナーをスケジュールすることを望まず、b）Kubeletがデフォルトでスワップをオンにして実行されないことを示します。 私が行使しようとしているのは、 @ derekwaynecarrによる、スレッドの一番上にある状況

スワップのサポートは重要です。 保証されたポッドは決して交換を必要とすべきではありません。 バースト可能なポッドは、スワップを必要とせずに要求を満たす必要があります。 BestEffortポッドには保証がありません。 現在、kubeletには、ポッド全体で適切な量の予測可能な動作を提供するためのスマートさが欠けています。

このトピックについては、今年初めにリソース管理で対面で話し合いました。 私たちは、実現できる利益と比較して、短期的にこれに取り組むことにあまり関心がありません。 スワップの最適化を試みる前に、圧力検出に関する信頼性を向上させ、遅延に関する問題を最適化することをお勧めしますが、これが優先度が高い場合は、ぜひご協力ください。

また、そのすぐ下、 @ matthiasrから：

ここでの説明には、さらに多くのコンテキストがあります。＃7294 –スワップを使用できるようにすると、メモリ制限との相互作用が非常に奇妙で悪くなります。 たとえば、メモリ制限に達したコンテナは、スワップにスピルオーバーし始めます（これは、 f4edaf2以降

これらは両方とも、すでに見られた問題についての良い見解を示していますが、問題を悪化させる可能性のある既知の再現可能なシナリオを理解することは良いことです。 私は自分でそれらを思いつくことができますが、他の誰かがすでにそれをしているなら、それは私が再発明しないことを気にしない車輪です。

@superdave

同意しました！ ただし、Dockerはすでにスワップを使用した実行を明示的にサポートしています。 Kubernetesは明示的には行いません（強制することはできますが）。 私の主張は、それは少なくとも声を上げるべきだということです。なぜなら、それはすべての人の脅威モデルに含まれているわけではないからです。特に、以前にそれについて考える必要がなかった場合はそうです。

その場合、 kubeletがそのメモリスペースをmlock()すると想定し、スワップアウトまたはOOMキルを回避するためにOOMキル優先度を低く設定し、 swapinessでcgroup内のすべてのコンテナを実行するのが妥当です。 0に設定されています。 誰かがフォームスワッピングの恩恵を受けたい場合は、ポッド内の特定のコンテナにenableSwapiness: 50オプションを使用してオプトインできます。
驚きはありません、電池が含まれています。

私はここのすべてに同意すると思います。 不快な驚きを避けるために、デフォルトで現在の動作になります。

これは、単純なアプリケーションがどのように見えるかの例です。ここでは、何らかの理由でメモリの大部分が割り当てられていますが、二度とアクセスされることはありません。 使用可能なすべてのメモリがいっぱいになると、アプリケーションはハングするか、無限ループに陥り、基本的にリソースをブロックするか、メモリ不足のキラーを強制します。

#include <iostream>
#include <vector>
#include <unistd.h>
int main() {
  std::vector<int> data;
  try
    {
        while(true) { data.resize(data.size() + 200); };
    }
    catch (const std::bad_alloc& ex)
    {
        std::cerr << "Now we filled up memory, so assume we never access that stuff again and just moved on, or we're stuck in an endless loop of some sort...";
        while(true) { usleep(20000); };
    }
  return 0;
}

本当にスワップが必要な人のための回避策。 もし、あんたが

• --fail-swap-on=false kubeletを開始します
• ノードにスワップを追加します
• メモリ要件を指定しないコンテナは、デフォルトで、スワップを含むすべてのマシンメモリを使用できます。

それが私たちがしていることです。 または、少なくとも、私は実際にそれを個人的に実装しなかったと確信していますが、それが私が収集したものです。

これは、どのコンテナも明示的なメモリ要件を指定していない場合にのみ、実際に実行可能な戦略になる可能性があります...

こんにちは@hjwp 、あなたの情報をありがとう。 それは本当に大いに役立ちます！

これに続いて質問してもいいですか？

あなたが言ったようにすべてを設定した後、コンテナによるスワップメモリ​​使用量の使用を制限する方法はありますか？

Dockerの--memory-swapパラメータを設定することを考えていました
https://docs.docker.com/config/containers/resource_constraints/# --memory-swap-details
現在、私のコンテナにはスワップの使用に制限はありません（ "MemorySwap"：-1 ）

sudo docker inspect 482d70f73c7c | grep Memory
            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

しかし、k8sで公開されているこのパラメータを見つけることができませんでした。

ちなみに、ポッドメモリの制限もスワップの使用を制限しますか？

私のvm関連の設定

vm.overcommit_kbytes = 0
vm.overcommit_memory = 1
vm.overcommit_ratio = 50
vm.swappiness = 20
vm.vfs_cache_pressure = 1000

ありがとうございました！

@ pai911それは不可能だと思います、

現在、CRIはそれをサポートしていません。これを参照してください。dockerには--memory-swapようなオプションはありません。

これはCRIの制限ですが、OCI仕様はこのオプションをサポートし

考えられる（理論的に）解決策の1つは、特権DaemonSetを作成し、それがポッドから注釈データを読み取り、DaemonSetがcgroup値を手動で編集することです。

cgroup

こんにちは@ win-t、

フィードバックありがとうございます！

だから今のところ、このオプションは内部使用のみですか？

この--memory-swapオプションにマップされているcgroup値を知っていますか？

だから今のところ、このオプションは内部使用のみですか？

はい、k8sで公開されていないため、このオプションを設定することはできません

ところで、docker inspectのMemorySwapは、これによるとMemoryと同じである必要があります。dockerinspectで-1を取得する方法がわかりません。

この--memory-swapオプションにマップされているcgroup値を知っていますか？

• --memoryドッキングウィンドウのマップ内にmemory.limit_in_bytesのcgroup v1の中
• --memory-swapドッキングウィンドウのマップ内にmemory.memsw.limit_in_bytesのcgroup v1の中

@ win-tどうもありがとうございました！

私は次のバージョンを使用しています

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"1bea6c00a7055edef03f1d4bb58b773fa8917f11", GitTreeState:"clean", BuildDate:"2020-02-11T20:05:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

そして私は歴史を見ました。 このコミットで修正が追加された

多分それは私が実行しているバージョンに含まれていませんか？

だから今のところ、このオプションは内部使用のみですか？

はい、k8sで公開されていないため、このオプションを設定することはできません

ところで、docker inspectのMemorySwapは、これによるとMemoryと同じである必要があります。dockerinspectで-1を取得する方法がわかりません。

この--memory-swapオプションにマップされているcgroup値を知っていますか？

• --memoryドッキングウィンドウのマップ内にmemory.limit_in_bytesのcgroup v1の中
• --memory-swapドッキングウィンドウのマップ内にmemory.memsw.limit_in_bytesのcgroup v1の中

これは奇妙です。

kops + Debianを使用していましたが、Dockerの検査でスワップメモリ​​に制限がないことが示されています
（Dockerは以前に投稿した情報を検査します）

しかし、その後、Amazon Linuxイメージに切り替えました。これが、私が得たものです。

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

さらに調査を行い、これがバグかどうかを確認します

だから今のところ、このオプションは内部使用のみですか？

はい、k8sで公開されていないため、このオプションを設定することはできません
ところで、docker inspectのMemorySwapは、これによるとMemoryと同じである必要があります。dockerinspectで-1を取得する方法がわかりません。

この--memory-swapオプションにマップされているcgroup値を知っていますか？

• --memoryドッキングウィンドウのマップ内にmemory.limit_in_bytesのcgroup v1の中
• --memory-swapドッキングウィンドウのマップ内にmemory.memsw.limit_in_bytesのcgroup v1の中

これは奇妙です。

kops + Debianを使用していましたが、Dockerの検査でスワップメモリ​​に制限がないことが示されています
（Dockerは以前に投稿した情報を検査します）

しかし、その後、Amazon Linuxイメージに切り替えました。これが、私が得たものです。

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

さらに調査を行い、これがバグかどうかを確認します

kopsによる公式Debianイメージに存在する問題を再現できるようになりました

このkopsの公式イメージはスワップメモリ​​を無制限にするようです
kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17

複製手順：

私のkopsインスタンスグループは次のように定義されています。

apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
  creationTimestamp: "2020-03-12T06:33:09Z"
  generation: 5
  labels:
    kops.k8s.io/cluster: solrcluster.k8s.local
  name: node-2
spec:
  additionalUserData:
  - content: |
      #!/bin/sh
      sudo cp /etc/fstab /etc/fstab.bak
      sudo mkfs -t ext4 /dev/nvme1n1
      sudo mkdir /data
      sudo mount /dev/nvme1n1 /data
      echo '/dev/nvme1n1       /data   ext4    defaults,nofail        0       2' | sudo tee -a /etc/fstab
      sudo fallocate -l 2G /data/swapfile
      sudo chmod 600 /data/swapfile
      sudo mkswap /data/swapfile
      sudo swapon /data/swapfile
      echo '/data/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
      sudo sysctl vm.swappiness=10
      sudo sysctl vm.overcommit_memory=1
      echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
      echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf
    name: myscript.sh
    type: text/x-shellscript
  image: kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  instanceProtection: true
  kubelet:
    failSwapOn: false
  machineType: t3.micro

手順：

1. クラスターが稼働した後。

2. 次のリソース設定を使用してSolrHelmチャートをデプロイします

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

**他のポッドも機能するはずです

1. コンテナを一覧表示してコンテナIDを検索します
   sudo docker container ls

2. コンテナのメモリパラメータを検査します
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

問題をどこかに提出する必要がありますか？ k8sまたはkops？

手順：

1. クラスターが稼働した後。
2. 次のリソース設定を使用してSolrHelmチャートをデプロイします

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

**他のポッドも機能するはずです

1. コンテナを一覧表示してコンテナIDを検索します
   sudo docker container ls
2. コンテナのメモリパラメータを検査します
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

問題をどこかに提出する必要がありますか？ k8sまたはkops？

AmazonLinuxでのみ正しい動作を確認できることを確認できます
ami-0cbc6aae997c6538a ：amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2

            "Memory": 671088640,
            "CpusetMems": "",
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

つまり、「MemorySwap」== "メモリ"

他の2つのイメージは両方とも同じ設定です： "MemorySwap": -1 、これは無制限のスワップ使用につながります。

• Debian
  
  
  
  • ami-075e61ad77b1269a7 ：k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  
  
• Ubuntu
  
  
  
  • ami-09a4a9ce71ff3f20b ：ubuntu / images / hvm-ssd / ubuntu-bionic-18.04-amd64-server-20200112
  
  

それで、それはk8sの問題かもしれないと思いますか？

ユーザーストーリー：

（1）ベンダー提供のプログラムは、プログラムコードのソースへのアクセスを義務付ける言語ランタイムを使用しています。 このため、初期化中、すべてのプログラムソースコードは別のメモリ領域に配置されます。 プログラムが初期化され、コンテナがReadyになると、このメモリはアクセスされません（これを証明することはできませんが、証明することはできません）。 さらに、プログラムは、カスタムOOM処理用に予約するために数ページを割り当てます。 このメモリはスワップアウトできます。 この「デッドメモリ」が他のクラスタアプリケーションを混雑させたくありません。 死んでしまうメモリの量を正確に計算し、それをポッド仕様のスワップ要求としてリストすることができます。

（2）機械学習またはデータ分析のワークロードを実行していて、メモリ使用量が突然膨らんだり後退したりする可能性があります。 これらのアプリケーションが終了せず、最終的に終了しない限り、これらのアプリケーションの速度が低下しても問題ありません。 これらのメモリバルーンが発生したときのエビクションを軽減するために、スワップを使用してクラスターをプロビジョニングしたいと思います。 これらのポッドでは、メモリとスワップの要求が少なく、中程度のメモリ制限（おそらく、ベースラインと1つのワーキングセットで十分）、および大きなスワップ制限があります。

（3）時々fork + execが必要なインタープリター（Ruby on Railsなど）でWebサーバーを実行しています。 厳密なメモリアカウンティングはフォークの障害を引き起こしますが、これは許容できません。 カーネルがfork呼び出しとexec呼び出しの間のプロセス動作をカバーするための保証されたメモリヘッドルームを持つように、スワップをプロビジョニングしたいと思います。 vm.swappiness値は、スワップを非常に阻止するように設定できます。また、本番環境でスワップが実際に使用されているかどうかを操作に通知するアラートを設定しました。 ポッド仕様は、スワップ要求と制限を同じ値に設定します。

最近、すべてのDockerベースのサービスをKubernetesに移行しようとしましたが、スワップがサポートされていないため、プロジェクトを中止する必要がありました。

スワップを有効にして現在実行しているのとまったく同じ数のコンテナーをサポートするには、3倍の量のハードウェアをプロビジョニングする必要があることがわかりました。

主な問題は、ワークロードが最大1Gb程度のメモリ（またはスワップ）を使用できる多数のコンテナーで構成されていることですが、通常の動作では通常約50Mb程度を使用します。

スワップできないということは、大きな「ジョブ」を処理する必要があるときにスワップのブロックを使用できるようにするのではなく、処理する必要がある可能性のある最大の負荷に対してすべてを設計する必要があることを意味しました。

最終的にKubernetesへの移行を中止し、スワップが将来サポートされることを期待して、当面はすべてを一時的にSwarmに移動しました。

主な問題は、ワークロードが最大1Gb程度のメモリ（またはスワップ）を使用できる多数のコンテナーで構成されていることですが、通常の動作では通常約50Mb程度を使用します。

これらのコンテナで実行されているアプリケーションは、非常に貧弱に書かれていると言う人もいるかもしれません。

これらのコンテナで実行されているアプリケーションは、非常に貧弱に書かれていると言う人もいるかもしれません。

これは一種の無関係であり、指さしが建設的なことはめったにありません。 Kubernetesエコシステムは、幅広いアプリケーションプロファイルをサポートするように構築されており、このようにそのうちの1つを選択することはあまり意味がありません。

主な問題は、ワークロードが最大1Gb程度のメモリ（またはスワップ）を使用できる多数のコンテナーで構成されていることですが、通常の動作では通常約50Mb程度を使用します。

これらのコンテナで実行されているアプリケーションは、非常に貧弱に書かれていると言う人もいるかもしれません。

笑、これはカーネル機能です。アプリケーションはshmファイルでmadvise(2)を使用でき、madvisesyscallをブロックしません。
そのため、ユーザーはこの機能をデザインに活用する資格があります。「非常に貧弱に書かれている」とは言えません。

主な問題は、ワークロードが最大1Gb程度のメモリ（またはスワップ）を使用できる多数のコンテナーで構成されていることですが、通常の動作では通常約50Mb程度を使用します。

これらのコンテナで実行されているアプリケーションは、非常に貧弱に書かれていると言う人もいるかもしれません。

あなたの返信は、多くの開発者が取り組んでいるワークロードを理解していないことを示しています。

私が言及したワークロードは、ユーザーによって提供されるさまざまなサイズのデータ​​セットを処理するため、リソース要件が広範囲に及ぶ可能性があります。

もちろん、メモリマップファイルを使用して、メモリ使用量の一貫性を保つことができます。 次に、メモリマッピング自体を使用するようにライブラリを書き直す必要があります。これには、多かれ少なかれ既存のすべてのライブラリが含まれます。

しかし、その後、本質的にアプリケーション固有のページファイルを作成しました。これは、カーネルによって管理されるページファイルよりもほぼ確実にパフォーマンスが低下します。

一部のKubernetesデプロイメントにはスワップが必要です

私には有効なユースケースがあります-kubeadmに含まれているオンプレミス製品であるlinuxディストリビューションを開発しています。 設計による水平スケーリングはありません。 日和見的なメモリのピークを乗り越えて機能する（ただし遅い）には、間違いなくスワップが必要です。

スワップを有効にしてkubeadmをインストールするに

1. /etc/systemd/system/kubelet.service.d/20-allow-swap.confに次の内容のファイルを作成します。

   [Service]
   Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
   

2. 走る

   sudo systemctl daemon-reload
   

3. フラグ--ignore-preflight-errors=Swap kubeadmを初期化します

   kubeadm init --ignore-preflight-errors=Swap
   

https://stackoverflow.com/a/62158455/3191896

素朴なソフトウェア開発者として、時間に敏感なワークロードを持つシステムポッドが非スワップ動作を要求し、他のワークロード（デフォルト）がベストエフォートカテゴリにプッシュされることは私には完全に合理的であるように思われます。 それはすべての懸念を解決しませんか？

私自身のニーズのために、私のアプリの多くはキャッシュの恩恵を受けています。 とはいえ、アプリが突然大量のメモリを必要とする場合、それらのアプリが新しいワークロードのメモリを使い果たすよりもメモリ圧力を下げる要求に応答しない場合は、最も古いキャッシュをディスクにプッシュすることをお勧めします。物理メモリでバーストをバックアップする+ローリング展開用にさらに+潜在的なノード障害のためにさらに。

@metatickは言った：

もちろん、メモリマップファイルを使用して、メモリ使用量の一貫性を保つことができます。 次に、メモリマッピング自体を使用するようにライブラリを書き直す必要があります。これには、多かれ少なかれ既存のすべてのライブラリが含まれます。

Linux標準Cライブラリは、メモリアロケータを置き換えるように設計されています。 malloc 、 realloc 、およびfreeは、その目的のためにポインターを介して呼び出されます。 したがって、ライブラリをLD_PRELOADするだけで、それらをオーバーライドして、マップされたファイルから割り当てることができます。

しかし、その後、本質的にアプリケーション固有のページファイルを作成しました。これは、カーネルによって管理されるページファイルよりもほぼ確実にパフォーマンスが低下します。

カーネル内のまったく同じコードによって管理されるため、実際には通常のスワップとまったく同じように実行されます。 唯一の違いは、優先度を調整するためのswappinessパラメーターがないことです。

私が持っている唯一の未解決の質問は、これがすでに実装されているかどうかです（「swapfs」kubeletのソフト/ハード制限を除く）-具体的な提案とアクションアイテムを書く前に、実際のkubelet / CRICgroupsコードを読む必要があります。

@anguslees 、
行動をチェックするために移動したことはありますか。 もしそうなら、あなたはいくつかの解決策やそれにリンクを追加できますか？

ありがとう、
1月

行動をチェックするために移動したことはありますか。 もしそうなら、あなたはいくつかの解決策やそれにリンクを追加できますか？

私はしませんでした。 （私はDockerコードを少し掘り下げましたが、今ではそれについてすべて忘れており、もう一度やり直す必要があります）

他のボランティアも大歓迎です！ 私はこれに取り組むと言って誰かから酸素を盗んだのではなく、フォロースルーに失敗したことを願っています:(

@metatickのストーリーに追加するには：

現在、Kubernetes上で実行されているGigalixirをホストとして使用しています。 それはウェブアプリです。 時々、クライアントが写真のバッチをアップロードするので、私のアプリはそれらのサイズを変更するために一連の（難しい）ImageMagickプロセスを起動します。 メモリ使用量が急増し、OOMキラーがトリガーされ、アプリが（簡単に）ダウンしてアップロードが台無しになります。

使用量が急増したために、Gigalixirに必要以上に多くのお金を払わなければならなくなりました。 他の人が述べたように。

設計の観点からスワップを好まないかもしれませんが、あなたの決定はビジネスマンにお金をかけています...そしてそれは無駄です。

修正してください。 :)

これも私にとって非常に大きな問題です。 私のユースケースでは、ほとんどの場合100MBを使用するポッドを実行する必要がありますが、ユーザーが特定のイベントをトリガーすると、ドロップバックする前に数分間で最大2GBのRAMがバーストする可能性があります（いいえ、それは不十分に書かれているからではなく、ワークロードの現実です）。
私は、スワップを使用して16GBのマシンで一度に100近くのそのようなワークロードを実行します。 そのワークロードをKubernetesに移動することはできません。それは、まったく機能しないためです。 そのため、現在、メインアプリがKubernetesで実行されているときに、これらのワークロードをkubernetes以外のシステムで実行する独自のオーケストレーターがあり、k8sへの移行の目的が損なわれています。 スワップがないと、それが強制終了されるか、アプリがバーストする（またはバーストしない）可能性がある数分間、使用可能なRAMを常に大量に浪費する必要があります。

ポッドのCPUを制限するCPU制限を設定できる場合は、ポッドが使用するメモリを制限するメモリ制限を設定できるはずです。 メモリ制限に達したときにポッドを強制終了することは、設定されたCPU制限よりも多くのCPUリソースを使用する場合にポッドを強制終了することと同じくらいばかげています（申し訳ありませんが、すべてのポッドがレプリカであり、結果なしに停止できるわけではありません）。

Kubernetesは、クラスター全体のパフォーマンス全体に影響を与える可能性があるため、ノードに設定されたスワップを処理できません（ただし、これは有効な引数ではないと思います）。 理想的には、ポッド自体にポッドレベルのスワップファイルがあり、それらのコンテナ内のプロセスのみがスワップされる必要があります。 これにより、理論的には、CPU制限がポッドを抑制するのと同じように、メモリ制限を超えるポッドのRAM使用量とパフォーマンス（スワッピングによる）が抑制されます。
残念ながら、cgroupsがスワップファイルを指定できるようには見えず、swappinessのみが指定できます。また、カーネルに「memの使用量がこの制限を超えている場合はスワップする」ように指示することはできません。代わりに、最後に基づいてスワップするタイミングを決定するようです。アクセスおよびその他のメトリック。

ただし、それまでの間、ノードにswapを存在させ、制限が設定されていないポッドのswappinessを0に設定し、制限が設定されている場合（または「swapInsteadOfKill」と言う他の仕様フィールド）に設定します。ゼロ以外の値へのswappiness？

「スワップするかしないか」についての議論のほかに、 @ pai911によって記述された動作がk8sチームによってさらに対処されなかったことに

docker deamonのメモリ設定に関して、kubeletの動作が異なるように見えることを確認できます（一部のOSでは、上記のコードに従わない）。 私たちのクラスターはSUSElinuxで実行されており、 https： //github.com/kubernetes/kubernetes/issues/53533#issuecomment-598056151に記載されているのと同じ無制限のスワップ使用が発生してい

OSの詳細： SUSE Linux Enterprise Server 12 SP4 - Linux 4.12.14-95.45-default

とにかくk8sでのスワップの適切なサポートがなければ、少なくともkubeletが基盤となるOSに関係なくDockerメモリ設定を一貫して処理することを望みます。

私は、1.21でこれを推進するのを支援するコミュニティの食欲やボランティアがいるかどうかを確認するために、議題にスワップを置きました。 2017年に述べたように、スワップをサポートすることに異論はありません。kubeletの排除、ポッドの優先度、ポッドのサービス品質を混同しないようにする必要があります。重要なことに、ポッドはスワップを許容するかどうかを判断できる必要があります。 これらすべてのことは、ポッドがポータブルであることを保証するために重要です。

最近、NUMAに合わせたメモリなどを機能させることに多くのエネルギーが注がれていますが、パフォーマンスにあまり敏感でなく、このスペースを前進させるために同じように動機付けられている人々がいる場合は、このスペースの詳細なKEP。

最近はとても忙しいので、最近はコミュニティのプロセスにあまり追いついていないのですが、もう少し落ち着くはずです。 Slackチャンネルに参加せずに参加できる方法はありますか？