Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

第33章 sysctl

33.1. 概要

sysctl 設定は Kubernetes 経由で公開され、ユーザーがコンテナー内の namespace の特定のカーネルパラメーターをランタイム時に変更できるようにします。 namespace を使用する sysctl のみを Pod 上で独立して設定できます。sysctl に namespace が使用されていない場合 (この状態は ノードレベル と呼ばれる)、OpenShift Container Platform 内でこれを設定することはできません。さらに 安全 とみなされる sysctl のみがデフォルトでホワイトリストに入れられます。他の 安全でない sysctl はノードで手動で有効にし、ユーザーが使用できるようにできます。

33.2. sysctl について

Linux では、管理者は sysctl インターフェースを使ってランタイム時にカーネルパラメーターを変更することができます。パラメーターは /proc/sys/ 仮想プロセスファイルシステムで利用できます。これらのパラメーターは以下を含む各種のサブシステムを対象とします。

  • カーネル (共通のプレフィックス: kernel.)
  • ネットワーク (共通のプレフィックス: net.)
  • 仮想メモリー (共通のプレフィックス: vm.)
  • MDADM (共通のプレフィックス: dev.)

追加のサブシステムについては、カーネルのドキュメントで説明されています。すてのパラメーターの一覧を取得するには、以下を実行できます。

$ sudo sysctl -a

33.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.* グループの大半の sysctl には namespace が使用されていることが知られています。それらの namespace の採用は、カーネルのバージョンおよびディストリビューターによって異なります。

システム上で namespace が使用されている net.* sysctl を確認するには、以下のコマンドを実行します。

$ podman run --rm -ti docker.io/fedora \
    /bin/sh -c "dnf install -y findutils && find /proc/sys/ \
    | grep -e /proc/sys/net"

namespace が使用されていない sysctl は ノードレベル と呼ばれており、クラスター管理者がノードの基礎となる Linux ディストリビューションを使用 (例: /etc/sysctls.conf ファイルを変更) するか、または特権付きコンテナーで DaemonSet を使用することによって手動で設定する必要があります。

注記

特殊な sysctl が設定されたノードにテイントのマークを付けることを検討してください。それらの sysctl 設定を必要とする Pod のみをそれらのノードにスケジュールします。テイントおよび容認 (Toleration) 機能を使用してノードにマークを付けます。

33.4. 安全 vs 安全でない sysctl

sysctl は 安全な および 安全でない sysctl に分類されます。適切な namespace の設定に加えて、安全な sysctl は同じノード上の Pod 間で適切に分離する必要があります。つまり、Pod ごとに安全な sysctl を設定することについて以下の点に留意する必要があります。

  • この設定はノードのその他の Pod に影響を与えないものである。
  • この設定はノードの正常性に負の影響を与えないものである。
  • この設定は Pod のリソース制限を超える CPU またはメモリーリソースを取得を許可しないものである。

namespace を使用した sysctl は必ずしも常に安全であると見なされる訳ではありません。

現時点で、OpenShift Container Platform は以下の sysctl を安全なセットでサポートするか、またはホワイトリスト化します。

  • kernel.shm_rmid_forced
  • net.ipv4.ip_local_port_range
  • net.ipv4.tcp_syncookies

この一覧は、kubelet による分離メカニズムのサポートを強化する今後のバージョンでさらに拡張される可能性があります。

すべての安全な sysctl はデフォルトで有効にされます。すべての安全でない sysctl はデフォルトで無効にされ、ノードごとにクラスター管理者によって手動で有効にされる必要があります。無効にされた安全でない sysctl が設定された Pod はスケジュールされますが、起動に失敗します。

33.5. 安全でない sysctl の有効化

クラスター管理者は、高パフォーマンスまたはリアルタイムのアプリケーション調整などの非常に特殊な状況で特定の安全でない sysctl を許可することができます。

安全でない sysctl を使用する必要がある場合、クラスター管理者はそれらをノードで個別に有効にする必要があります。それらは namespace を使用した sysctl のみを有効にできます。

SCC (Security Context Constraints) の forbiddenSysctls および allowedUnsafeSysctls フィールドで sysctl または sysctl パターンの一覧を指定することにより、Pod に設定できる sysctl をさらに制御できます。

  • forbiddenSysctls オプションは、特定の sysctl を除外します。
  • allowedUnsafeSysctls オプションは、高パフォーマンスやリアルタイムのアプリケーションチューニングなどの特定ニーズを管理します。
警告

安全でないという性質上、安全でない sysctl は各自の責任で使用されます。場合によっては、コンテナーの正しくない動作やリソース不足、またはノードの完全な破損などの深刻な問題が生じる可能性があります。

  1. 安全ではない sysctl を、「ノードリソースの設定」で説明されているように、ノード設定マップファイルの kubeletArguments\ パラメーターに追加します。

    例:

    $ oc edit cm node-config-compute -n openshift-node
    
    ...
        kubeletArguments:
          allowed-unsafe-sysctls: 1
          - "net.ipv4.tcp_keepalive_time"
          - "net.ipv4.tcp_keepalive_intvl"
          - "net.ipv4.tcp_keepalive_probes"
    1
    使用する必要のある安全でない sysctl を追加します。
  2. 制限付き SCC の内容を使用する新規 SCC を作成し、安全でない sysctl を追加します。

    ...
    allowHostDirVolumePlugin: false
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: true
    allowPrivilegedContainer: false
    allowedCapabilities: null
    allowedUnsafeSysctls: 1
    - net.ipv4.tcp_keepalive_time
    - net.ipv4.tcp_keepalive_intvl
    - net.ipv4.tcp_keepalive_probes
    ...
    metadata:
      name: restricted-sysctls 2
    ...
    1
    使用する必要のある安全でない sysctl を追加します。
    2
    SCC の新規の名前を指定します。
  3. 新規 SCC アクセスを Pod ServiceAccount に付与します。

    $ oc adm policy add-scc-to-user restricted-sysctls -z default -n your_project_name
  4. 安全でない sysctl を Pod の DeploymentConfig に追加します。

    kind: DeploymentConfig
    
    ...
      template:
        ...
        spec:
          containers:
          ...
          securityContext:
            sysctls:
            - name: net.ipv4.tcp_keepalive_time
              value: "300"
            - name: net.ipv4.tcp_keepalive_intvl
              value: "20"
            - name: net.ipv4.tcp_keepalive_probes
              value: "3"
  5. 変更を適用するためにノードサービスを再起動します。

    # systemctl restart atomic-openshift-node

33.6. Pod の sysctl 設定

sysctl は Pod の securityContext を使用して Pod に設定されます。securityContext は同じ Pod 内のすべてのコンテナーに適用されます。

以下の例では、Pod securityContext を使用して安全な sysctl kernel.shm_rmid_forced および 2 つの安全でない sysctl net.ipv4.route.min_pmtu および kernel.msgmax を設定します。仕様では 安全な sysctl と 安全でない sysctl は区別されません。

警告

オペレーティングシステムが不安定になるのを防ぐには、変更の影響を確認している場合にのみ sysctl パラメーターを変更します。

以下の例に示されるように、Pod を定義する YAML ファイルを変更し、securityContext 仕様を追加します。

apiVersion: v1
kind: Pod
metadata:
  name: sysctl-example
spec:
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.ipv4.route.min_pmtu
      value: "552"
    - name: kernel.msgmax
      value: "65536"
  ...
注記

上記の安全でない sysctl が指定された Pod は、管理者がそれらの 2 つの安全でない sysctl を明示的に有効にしていないノードでの起動に失敗します。ノードレベルの sysctl の場合のように、それらの Pod を正しいノードにスケジュールするには、テイントおよび容認機能またはノードのラベルを使用します。