第31章 sysctl
31.1. 概要
sysctl 設定は Kubernetes 経由で公開され、ユーザーがコンテナー内の namespace の特定のカーネルパラメーターをランタイム時に変更できるようにします。 namespace を使用する sysctl のみを Pod 上で独立して設定できます。sysctl に namespace が使用されていない場合 (この状態は ノードレベル と呼ばれる)、OpenShift Container Platform 内で設定することはできません。さらに 安全 とみなされる sysctl のみがデフォルトでホワイトリストに入れられます。他の 安全でない sysctl はノードで手動で有効にし、ユーザーが使用できるようにできます。
31.2. sysctl について
Linux では、管理者は sysctl インターフェースを使ってランタイム時にカーネルパラメーターを変更することができます。パラメーターは /proc/sys/ 仮想プロセスファイルシステムで利用できます。これらのパラメーターは以下を含む各種のサブシステムを対象とします。
- カーネル (共通のプレフィックス: kernel.)
- ネットワーク (共通のプレフィックス: net.)
- 仮想メモリー (共通のプレフィックス: vm.)
- MDADM (共通のプレフィックス: dev.)
追加のサブシステムについては、カーネルのドキュメントで説明されています。すてのパラメーターの一覧を取得するには、以下を実行できます。
$ sudo sysctl -a
31.3. namespace を使用した sysctl vs ノードレベルの sysctl
現時点の Linux カーネルでは、数多くの sysctl に namespace が使用 されています。これは、それらをノードの各 Pod に対して個別に設定できることを意味します。 namespace の使用は、sysctl を Kubernetes 内の Pod 環境でアクセス可能にするための要件になります。
以下の sysctl は namespace を使用するものとして知られている sysctl です。
- kernel.shm*
- kernel.msg*
- kernel.sem
- fs.mqueue.*
- net.*
namespace が使用されていない sysctl は ノードレベル と呼ばれており、クラスター管理者がノードの基礎となる Linux ディストリビューションを使用 (例: /etc/sysctls.conf を使用) するか、または特権付きコンテナーで DaemonSet を使用することによって手動で設定する必要があります。
特殊な sysctl が設定されたノードにテイントのマークを付けることを検討してください。それらの sysctl 設定を必要とする Pod のみをそれらのノードにスケジュールします。Kubernetes の テイントおよび容認 (Toleration) 機能を使用してこれを実施します。
31.4. 安全 vs 安全でない sysctl
sysctl は 安全な および 安全でない sysctl に分類されます。適切な namespace の設定に加えて、安全な sysctl は同じノード上の Pod 間で適切に分離する必要があります。つまり、Pod ごとに安全な sysctl を設定することにについて以下を留意する必要があります。
- この設定はノード上の他の Pod に影響を与えないものである。
- この設定はノードの正常性に与えることを許可しないものである。
- この設定は Pod のリソース制限を超える CPU またはメモリーリソースの取得を許可しないものである。
namespace を使用した sysctl は必ずしも常に安全であると見なされる訳ではありません。
OpenShift Container Platform 3.3.1 の場合、以下の sysctl が安全なセットでサポートされています (ホワイトリスト化されています)。
- kernel.shm_rmid_forced
- net.ipv4.ip_local_port_range
この一覧は、kubelet が分離メカニズムのサポートを強化する今後のバージョンでさらに拡張されます。
すべての安全な sysctl はデフォルトで有効にされます。すべての安全でない sysctl はデフォルトで無効にされ、ノードごとにクラスター管理者によって手動で許可される必要があります。無効にされた安全でない sysctl が設定された Pod はスケジュールされますが、起動に失敗します。
安全でないという性質上、安全でない sysctl は各自の責任で使用されます。場合によっては、コンテナーの正しくない動作やリソース不足、またはノードの完全な破損などの深刻な問題が生じる可能性があります。
31.5. 安全でない sysctl の有効化
上記の警告を念頭に置いた上で、クラスター管理者は、高パフォーマンスまたはリアルタイムのアプリケーション調整などの非常に特殊な状況で特定の安全でない sysctl を許可することができます。
安全でない sysctl を使用する必要がある場合、クラスター管理者はノードでそれらを個別に有効にする必要があります。 namespace を使用した sysctl のみをこの方法で有効にできます。
「ノードリソースの設定」で説明されているように、必要な安全でない sysctl を設定するには /etc/origin/node/node-config.yaml ファイルの
kubeletArgumentsフィールドを使用します。kubeletArguments: experimental-allowed-unsafe-sysctls: - "kernel.msg*,net.ipv4.route.min_pmtu"変更を適用するためにノードサービスを再起動します。
# systemctl restart atomic-openshift-node
31.6. Pod 用の sysctl の設定
sysctl はアノテーションを使用して Pod に設定されます。それらは同じ Pod のすべてのコンテナーに適用されます。
以下は、安全な sysctl および安全でない sysctl の各種のアノテーションを使用した例です。
apiVersion: v1
kind: Pod
metadata:
name: sysctl-example
annotations:
security.alpha.kubernetes.io/sysctls: kernel.shm_rmid_forced=1
security.alpha.kubernetes.io/unsafe-sysctls: net.ipv4.route.min_pmtu=1000,kernel.msgmax=1 2 3
spec:
...安全でない sysctl が指定された Pod は、それらの 2 つの安全でない sysctl を明示的に有効にしていないノードでの起動に失敗します。ノードレベルの sysctl の場合のようにそれらを Pod を正しいノードにスケジュールするには、テイントおよび容認機能またはノードのラベルを使用します。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.