Kubernetesでスワップを無効にする理由
Kubernetes 1.8以降、ノードのスワップを無効にする（または--fail-swap-on to false）。
Kubernetesがスワップの無効化を主張する技術的な理由はわかりません。これはパフォーマンス上の理由ですか？セキュリティ上の理由は？この理由が文書化されていないのはなぜですか？
Kubernetesのアイデアは、インスタンスをできる限り100％使用するように密にパックすることです。すべての展開は、CPU /メモリ制限で固定する必要があります。したがって、スケジューラがポッドをマシンに送信する場合は、スワップをまったく使用しないでください。物事が遅くなるので、交換したくないでしょう。
主にパフォーマンスのために。
TL; DRがスワップを適切に使用しないのは、メモリサブシステムの理解が不十分であり、基本的なシステム管理スキルが不足していることを示す、怠惰なハックにすぎません。インフラストラクチャサービスを設計し、これらのシステムを理解しないと、失敗に終わります。
だから、私はこれについていくつかの解説を持っています、これは機能や要件というよりは私にとって怠惰のように見えます。スワップを適切に処理し、メモリを分析し、スワップを行わずにメモリサブシステムを適切に利用する方法を決定することは、絶対に可能です。これを中心に構築された非常に多くのツールがあり、プロセスがスワップを容易に利用しないことを保証できるため、パフォーマンスのポイントが正しくありません。このインストルメンテーションを組み込まないのは単純な遅延コーディングであり、スワップを完全に削除すると、システムパフォーマンスが低下します。ここでの鍵は、それを適切に使用することです。ポッドをディスクにスワップアウトするとパフォーマンスに影響を与えることに同意しますが、すべきがディスクにスワップアウトされることはたくさんあります。
さらに、Linuxカーネルはスワップを利用するように設計されており、完全に無効にするとマイナスの影響があります。これを処理するためのより良い方法は、ポッドをメインメモリに固定し、ディスクにスワップできないようにすることです。絶対に必要な場合を除いてスワップしないように、vfsキャッシュの圧力を下げます。メインメモリが使い果たされた場合、MALLOCに失敗します。
コンテナー内のプロセスによっては、コンテナーに重大な障害が発生したり、OOMキラーによって強制終了されたりすると、かなり悲惨な結果になる可能性があります。しかし、これらのコンテナーで実行されるプロセスは、理想的にはステートレスで短命である必要があることを理解していますが、20年間のシステムの実行では、誰もが意図した設計を100％文字どおりに実行したことは一度もありません。
さらに、これは、不揮発性メモリや、ハイブリッドディスク/メモリシステムを使用してメインメモリを大幅に拡張するために使用できるintel xpointなどの新しいメモリシステムなどの将来のテクノロジーを考慮していません。これらのタイプのシステムでは、補助的なメインメモリとして直接使用したり、スワップファイルを利用してパフォーマンスへの影響を無視してメインメモリを拡張したりできます。
私が理解しているように、この理由は、kubeletがスワップの状況を処理するように設計されておらず、Kubernetesチームはポッドがホストのメモリ内に収まることが目標であるため、これを実装する予定がないためです。
から この問題
スワップのサポートは重要です。保証されたポッドはスワップを必要としません。バースト可能なポッドは、スワップを必要とせずにリクエストを満たします。 BestEffortポッドに保証はありません。現在、kubeletには、ポッド全体で予測可能な動作の適切な量を提供するためのスマート機能がありません。
そして、kubernetesをローカルにデスクトップマシンにインストールして、それをいじってみようとしたらどうなるでしょうか。このシナリオでは、プリフライトルールを無視して、警告を無視してとにかく続行すると思いますか？