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