パフォーマンスのチューニング

特定のパフォーマンス最適化要件がある場合は、Red Hat® OpenShift® on IBM Cloud® の 一部のクラスター・コンポーネント用のデフォルト設定を変更できます。

デフォルトの設定を変更する場合は、お客様自身の責任で行ってください。 変更された設定に対してテストを実行すること、および環境内の設定変更が原因で発生する可能性がある障害についてはお客様が責任を持ちます。

ワーカーノードのパフォーマンスを /etc/systemd/system/ 内の systemd.conf MachineConfig ファイルで調整する代わりに、 Red Hat OpenShift /etc/systemd/system/ 内の systemd.conf daemonset ファイルでホストを変更できます。 詳細については、 「MTU Calico の変更」 または 「 Red HatCoreOS ワーカーノードのパフォーマンス調整」 を参照してください。

ワーカー・ノードのデフォルト設定

デフォルトでは、ワーカーノードには、ワーカープールを作成する際に選択したワーカーノードフレーバーのオペレーティングシステムと演算用ハードウェアが搭載されています。

オペレーティング・システムのカスタマイズ

クラスタバージョンごとのサポート対象オペレーティングシステムのリストは、 バージョン Red Hat OpenShift on IBM Cloud 情報で確認できます。 クラスターでオペレーティング・システムを混用したり、異なるオペレーティング・システムを使用したりすることはできません。

ワーカー・ノードを最適化する場合は、以下の情報を検討してください。

  • イメージおよびバージョンの更新: ワーカー・ノードの更新 (イメージまたは Red Hat OpenShift のバージョンへのセキュリティー・パッチなど) は、IBM から自動的に提供されます。 ただし、ワーカー・ノードに更新を適用するタイミングはユーザーが選択します。 詳しくは、クラスター、ワーカー・ノード、クラスター・コンポーネントの更新を参照してください。
  • 一時的な変更: ポッドにログインするか他のプロセスを使用してワーカー・ノード設定を変更した場合、変更は一時的になります。 ワーカー・ノードのライフサイクル操作 (ワーカー・ノードの自動リカバリー、再ロード、更新、置換など) を行うと、それまでの変更内容がデフォルト設定に戻ります。
  • 永続的な変更 ：変更内容をワーカーノードのライフサイクル操作を通じて維持するには、 init コンテナを使用するデーモンセットを作成してください。 詳しくは、パフォーマンスを最適化するためのデフォルト・ワーカー・ノード設定の変更を参照してください。

オペレーティング・システムへの変更はサポートされていません。 デフォルト設定を変更する場合、問題が発生したときにお客様の責任でデバッグおよび解決する必要があります。

ハードウェアの変更

ワーカー・ノードごとに CPU やメモリーなどのコンピュート・ハードウェアを変更する場合、以下のオプションから選択します。

パフォーマンスを最適化するためのワーカーノードのカーネル設定の変更

クラスター・ワーカー・ノードは、ほとんどのワークロードのニーズを満たすことが期待される安定性、最適化、およびパフォーマンスのレベルで構成されます。 通常、ワーカー・ノードのカーネル設定を変更することはお勧めしません。そのような変更を行うと、異常な問題や意図しない問題が発生する可能性があります。 ただし、ワークロードに、カーネル設定の変更を必要とする非常に固有のパフォーマンス最適化要件がある場合は、カスタム Kubernetes デーモン・セットを適用してカーネル構成を変更することができます。 これらの変更は重大な悪影響を及ぼす可能性があること、および お客様自身の責任でカーネル設定構成に対する変更を実装することを理解してください。

カーネル設定のコンフィギュレーションを変更した場合は、変更内容を正確に文書化して保存してください。 クラスターに関連する問題のサポート・チケットをオープンする場合は、これらの変更を指定する必要があります。 これらの構成変更が問題の原因となっている可能性があり、問題調査の一環として変更を元に戻すように求められる場合があります。 この場合、実装したカーネル構成変更を元に戻す必要があります。

デフォルトのカーネル設定を変更すると、クラスターに悪影響を及ぼす可能性があります。 これらの変更は、お客様の責任で行ってください。

デフォルトのカーネル設定を変更するには、 init コンテナー を使用してカスタム Kubernetes DaemonSet をクラスターに適用します。 デーモン・セットは、既存のすべてのワーカー・ノードの設定を変更し、クラスター内でプロビジョンされる新しいワーカー・ノードにこの設定を適用します。 init コンテナは、ワーカーノード上で他のポッドがスケジューリングされる前に、これらの変更が確実に実行されるようにします。 ポッドは影響を受けません。

サンプルスクリプト initContainer`` を実行するには、すべてのネームスペースに対して「 Manager IBM Cloud IAM サービスアクセスロール 」が割り当てられている必要があります。 デプロイメントのコンテナーが初期化された後、特権は除去されます。

始める前に、Red Hat OpenShift クラスターにアクセスします。

  1. 以下のデーモン・セットを worker-node-kernel-settings.yaml という名前のファイルに保存します。 spec.template.spec.initContainers セクションで、調整する sysctl パラメーターのフィールドと値を追加します。 このサンプルのデーモン・セットでは、環境に許可するデフォルトの最大接続数を net.core.somaxconn 設定を使用して変更し、一時ポート範囲を net.ipv4.ip_local_port_range 設定を使用して変更しています。

    変更する systctl 設定によっては、セキュリティー・コンテキストの構成が必要になる場合があります。 詳細については、『 Red Hat OpenShift 』のドキュメントを参照してください。

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kernel-optimization
  namespace: kube-system
  labels:
    tier: management
    app: kernel-optimization
spec:
  selector:
    matchLabels:
      name: kernel-optimization
  template:
    metadata:
      labels:
        name: kernel-optimization
    spec:
      hostNetwork: true
      hostPID: true
      hostIPC: true
      initContainers:
        - command:
            - sh
            - -c
            - sysctl -w net.ipv4.tcp_syn_retries="5"; sysctl -w net.ipv4.tcp_fin_timeout="15";
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: Always
          name: sysctl
          resources: {}
          securityContext:
            privileged: true
            capabilities:
              add:
                - NET_ADMIN
          volumeMounts:
            - name: modifysys
              mountPath: /sys
      containers:
        - resources:
            requests:
              cpu: 0.01
          image: us.icr.io/armada-master/network-alpine:latest
          name: sleepforever
          command: ["/bin/sh", "-c"]
          args:
            - >
              while true; do
                sleep 100000;
              done
      volumes:
        - name: modifysys
          hostPath:
            path: /sys

  2. ワーカー・ノードにデーモン・セットを適用します。 この変更はすぐに適用されます。

    oc apply -f worker-node-kernel-settings.yaml

ワーカーノードの sysctl パラメータをデフォルト値に戻すには、以下の手順に従ってください。

  1. デーモン・セットを削除します。 カスタム設定を適用した initContainers が削除されます。
    oc delete ds kernel-optimization
  2. クラスター内のすべてのワーカー・ノードをリブートします。 ワーカー・ノードは、デフォルト値が適用された状態でオンラインに戻ります。

ネットワーク・キープアライブ sysctl 設定の最適化

あるポッドに長時間 TCP 接続があり、一定時間アイドル状態になると切断されることがある場合、そのポッドの sysctl keepalive設定を変更するとよいでしょう。

現在、クラスター内のすべてのポッドでこれらの sysctl キープアライブ設定をデフォルトで設定する方法はありません。 すべてのポッドの設定を変更する最善の方法は、特権 initContainer を使用することです。 test-ns 名前空間でデプロイメント用に initContainer をセットアップする方法については、以下の例を参照してください。

test-ns 名前空間で特権 initContainers を許可します。

oc adm policy add-scc-to-group privileged system:serviceaccounts:test-ns

以下のサンプル initContainer をデプロイします。 containers: セクションは、必ず独自のアプリケーション・コンテナーに変更してください。 次に、 initContainer は、ポッド内のすべての通常コンテナーに対して sysctl 設定を設定します。これらのコンテナーはすべて同じネットワーク名前空間を共有するためです。

kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
	name: test-sysctl
	namespace: test-ns
	labels:
	run: test-sysctl
spec:
	replicas: 2
	selector:
	matchLabels:
		run: test-sysctl
	template:
	metadata:
		labels:
		run: test-sysctl
	spec:
		initContainers:
		- command:
		- sh
		- -c
		- sysctl -e -w net.ipv4.tcp_keepalive_time=40; sysctl -e -w net.ipv4.tcp_keepalive_intvl=15; sysctl -e -w net.ipv4.tcp_keepalive_probes=6;
		image: us.icr.io/armada-master/alpine:latest
		imagePullPolicy: IfNotPresent
		name: sysctl-init
		resources: {}
		securityContext:
			privileged: true
		containers:
		- name: test-sysctl
		image: us.icr.io/armada-master/alpine:latest
		command: ["sleep", "2592000"]
	EOF

を使用するクラスタの最大伝送単位（MTU）を変更する。 Calico

環境のネットワークスループット要件に合わせて、ワーカーノードおよび Calico プラグインの最大伝送単位（MTU）を増減させることができます。

すべての VPC ワーカーノードは最大 9000 MTU をサポートし、クラシックなベアメタルワーカーノードも最大 9000 MTU をサポートします。 クラシック仮想サーバーは標準の1500 MTUしかサポートしないため、クラスタにクラシック仮想サーバーのワーカーノードがある場合は、ワーカーノードまたは Calico MTUを増やさないでください。

最大伝送単位（MTU）値を変更すると、特に複雑なネットワーク環境では、予期せぬ結果を招くことがある。 ワークフローの中断を避けるため、本番クラスタに変更を加える前に、開発クラスタでこれらの変更をテストすることを強くお勧めします。

デフォルトでは、Red Hat OpenShift on IBM CloudクラスタのCalicoネットワーク・プラグインのMTUは、Satelliteクラスタでは1450バイト、Satellite・クラスタでは1480バイトです。 ほとんどの場合、パケットのドロップやフラグメンテーションを防ぐには、このデフォルトのCalicoMTU値で十分です。 ほとんどのホストは1500のMTU値を使用するため、これらのデフォルト値ではSatelliteクラスタにVXLANヘッダ用に50バイトの追加バイトが提供され、Satelliteクラスタ以外のクラスタに一部のポッド間クラスタネットワークトラフィックで使用されるIPヘッダ用に20バイトの追加バイトが提供されます。 クラスタ内のすべてのワーカーノードが同じCalicoMTU値を使用しなければならないことに注意してください。

デフォルトの Calico MTU の変更が必要になる状況としては、次のような状況があります。

  • ポッド間ネットワークのスループットを向上させる必要があり、クラスタノードがより高いホストMTUを使用できる場合は、ホストとCalicoのMTUの両方を増やすことができます。 これを「ジャンボフレーム」の使用と呼ぶ。 一般的なジャンボフレームのMTUは9000である。 この場合、ホストのプライベート・ネットワーク・インタフェースのMTU値を9000に設定し、CalicoのMTUを少し低い値（Satelliteクラスタでは8950、Satelliteクラスタでは8980）に設定することができます。 Azure仮想マシンなど、クラウドプロバイダーのハードウェアやリソースによっては、ジャンボフレームをサポートしていなかったり、最大4000のMTU値しかサポートしていなかったりする場合があることに注意してください。
  • クラスターにセットアップした VPN 接続に、デフォルトよりも小さい Calico MTU を必要とするものがある場合。 デフォルトより小さい Calico MTU が必要かどうかは、VPN サービス・プロバイダーに確認してください。
開始前に
ワーカーノードでまだデフォルトのMTU値が使用されている場合は、 Calico プラグインのMTU値を増やす前に、まずワーカーノードのMTU値を増やしてください。 たとえば、次のデーモンセットを適用することで、ワーカーノードのMTUを9000バイトに変更できます。 ip link コマンドで使用されるインターフェース名は、ワーカー・ノードのタイプによって異なることに注意してください。
  • ベア・メタル・ワーカー・ノードのコマンド例: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
  • コマンド例 VPCワーカーノード： ip link set dev ens3 mtu 9000;

  1. クラスタのワーカーノードにログインし、ノード間でpingを実行するには、以下のコマンドを実行します。 ノードのMTUは1500または1480にしか設定されていないため、この試みは失敗すると予想される。 次のステップでは、これらのコマンドを再度実行して、変更が成功したことを確認します。

    1. クラスター内のノードをリストします。 健全な2つのノードの名前とIPアドレスを保存する。
        oc get nodes -o wide
    ```
1. いずれかのノードにログインします。 ノードの名前を指定する。


```sh {: pre}
    oc debug node/<NODE_NAME>
    ```



1. 一方のノードから他方のノードにpingを打つコマンドを実行する。 前のステップで参照しなかったノードのIPアドレスを指定します。
```sh {: pre}
    ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
    ```

  2. 以下の例のデーモンセットでノードのMTUを変更する。 このMTU値はノード間トラフィックに適用される。 MTU値を含めるために - ip link set dev ens3 mtu <MTU_VALUE> 行を修正する（例ではMTU値9000を使用）。 ens3があなたのノードに適切でない場合は、「ens3 インターフェース名も変更する必要があるかもしれないことに注意してください。

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: set-host-mtu
  name: set-host-mtu
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: set-host-mtu
  template:
    metadata:
      labels:
        name: set-host-mtu
    spec:
      containers:
        - args:
            - |
              while true; do
                sleep 100000;
              done
          command:
            - /bin/sh
            - -c
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: IfNotPresent
          name: sleepforever
          resources:
            requests:
              cpu: 10m
      hostNetwork: true
      initContainers:
        - command:
            - sh
            - -c
            - ip link set dev ens3 mtu 9000
          image: us.icr.io/armada-master/network-alpine:latest
          imagePullPolicy: IfNotPresent
          name: set-host-mtu
          securityContext:
            capabilities:
              add:
                - NET_ADMIN
            privileged: true
          volumeMounts:
            - mountPath: /sys
              name: modifysys
      restartPolicy: Always
      terminationGracePeriodSeconds: 2
      tolerations:
        - operator: Exists
      volumes:
        - hostPath:
            path: /sys
            type: ""
          name: modifysys
  updateStrategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate

  3. デーモンセットを適用してノードのMTU値を変更する。

      oc apply -f <file_name>

  4. ノードにログインし、あるホストから別のホストへ、大きなパケットサイズを使ってpingを打つコマンドを再実行する。 ノードのMTU値を増やしたので、'ping コマンドは成功すると思われる。

    oc debug node/<NODE_NAME>

    ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>

  5. 新しいノードMTU値でクラスタをテストするのに時間をかけてください。 Calico MTU値の変更を続行する前に、アプリケーションが期待通りに機能することを確認することをお勧めします。

  6. コマンドを実行してCalicoのMTU値を更新し、ポッド間のトラフィックもより大きなMTUを使用できるようにします。 SatelliteCore OSクラスタの場合、CalicoのMTU値はノードのMTU値より50バイト少なくする必要があります。 それ以外のクラスタでは、CalicoのMTU値を20バイト少なくする必要があります。 たとえば、ノードのMTUに9000を指定した場合、CalicoのMTUはSatelliteCore OSクラスタでは8950、その他のクラスタでは8980になるはずです。

    oc patch installation.operator.tigera.io default --type='merge' -p '{"spec":{"calicoNetwork":{"mtu":<MTU_VALUE>}}}'

    また、'oc edit installation.operator.tigera.io default を実行して直接リソースを編集することもできる。

  7. すべてのノードを注意深く再起動して、これらの変更をすべてのノードに適用します。 これらの変更によってワークロードが中断される可能性があるため、このステップを続行する前に、開発クラスタ上でこのプロセスをテストしていることを確認してください。 ノードをリブートするには、ノードの コード化、排水、リブート を1つずつ行うことをお勧めします。

本番クラスタ上でこれらの手順を完了する場合は、本番ノードの更新または交換に使用するのと同じプロセスを使用する必要があります。 本番クラスタでこれらの手順を完了する前に、テストクラスタでこのプロセス全体をテストすることを強くお勧めします。

リブート処理中、一部のポッドは新しい大きいMTUを使用し、一部のポッドは元の小さいMTUのままです。 通常、このシナリオでは、双方が正しい最大パケットサイズをネゴシエートするため、問題は発生しない。 ただし、ICMPパケットをブロックすると、ネゴシエーションがうまくいかず、すべての再起動が完了するまでクラスタにポッド接続の問題が発生する可能性があります。 このプロセスは、まず開発クラスタでテストすることが重要である。

のポートマップ・プラグインを無効にする。 Calico

Calico のコンテナー・ネットワーク・インターフェース (CNI) 用の portmap プラグインは、hostPort を使用して、ワーカー・ノードの特定のポートでアプリ・ポッドを公開できるようにするものです。 このポート・マップ・プラグインをクラスターの Calico CNI 構成から削除すると、iptables のパフォーマンスの問題を防止できます。

クラスター内に 500 以上のサービスなど多くのサービスがある場合や、10 以上のサービスに対して 1 サービスあたり 50 以上のポートがあるなどサービス上のポートが多い場合、これらのサービスの Calico ネットワーク・ポリシーおよび Kubernetes ネットワーク・ポリシーに対して多数の iptables ルールが生成されます。 iptables ルールを多数使用すると、port map プラグインのパフォーマンスに問題が生じる可能性があります。また、iptables ルールの今後の更新が行えなくなったり、指定された時間内に iptables ルールの更新を行うためのロックが取得できなかった場合に、 calico-node コンテナが再起動したりする原因となる可能性があります。 このようなパフォーマンスの問題を防止するために、ポート・マップ・プラグインをクラスターの Calico CNI 構成から削除して無効にすることができます。

hostPortsを使用する必要がある場合は、ポート・マップ・プラグインを無効にしないでください。

  1. default Calico インストール・リソースを編集します。

    oc edit installation default -n calico-system

  2. spec.calicoNetwork セクションで、hostPorts の値を Disabled に変更します。

    ...
spec:
  calicoNetwork:
    hostPorts: Disabled
    ipPools:
      - cidr: 172.30.0.0/16
        encapsulation: IPIPCrossSubnet
        natOutgoing: Enabled
        nodeSelector: all()
    mtu: 1480
    nodeAddressAutodetectionV4:
      interface: (^bond0$|^eth0$|^ens6$|^ens3$)
  kubernetesProvider: OpenShift
  registry: us.icr.io/armada-master/
  variant: Calico
status:
  variant: Calico

  3. ファイルを保存して閉じます。 変更が自動的に適用されます。