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

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

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

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

Red Hat OpenShift内の MachineConfig ファイルを使用してワーカー・ノードのパフォーマンスを調整する代わりに、 daemonset ファイルを使用してホストを変更できます。 詳しくは、 Calico MTU の変更 または Red Hat CoreOS ワーカー・ノードのパフォーマンスのチューニング を参照してください。

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

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

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

クラスター・バージョン別のサポート対象オペレーティング・システムのリストについては、 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 キープアライブ設定を変更すると役立つ可能性があります。

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

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

```sh {: pre}
oc adm policy add-scc-to-groupl privileged system:serviceaccounts:test-ns
```

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

```sh {: pre}
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
```

Calico 最大伝送単位 (MTU) の変更

Calico プラグインの最大伝送単位 (MTU) を増減して環境のネットワーク・スループット要件を満たすことができます。

すべてのVPCワーカーノードはジャンボフレームをサポートしていますが、クラシックインフラはベアメタルワーカーでのみジャンボフレームをサポートしています。

最大伝送単位(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 第 2 世代ワーカー・ノードのコマンド例: ip link set dev ens3 mtu 9000;
  1. クラスタのワーカーノードにログインし、ノード間でpingを実行するには、以下のコマンドを実行します。 ノードのMTUは1500または1480にしか設定されていないため、この試みは失敗すると予想される。 次のステップでは、これらのコマンドを再度実行して、変更が成功したことを確認します。

    1. クラスター内のノードをリストします。 健全な2つのノードの名前とIPアドレスを保存する。

      oc get nodes -o wide
      
    2. いずれかのノードにログインします。 ノードの名前を指定する。

      oc debug node/<NODE_NAME>
      
    3. 一方のノードから他方のノードにpingを打つコマンドを実行する。 前のステップで参照しなかったノードのIPアドレスを指定します。

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

クラスター内に 500 以上のサービスなど多くのサービスがある場合や、10 以上のサービスに対して 1 サービスあたり 50 以上のポートがあるなどサービス上のポートが多い場合、これらのサービスの Calico ネットワーク・ポリシーおよび Kubernetes ネットワーク・ポリシーに対して多数の iptables ルールが生成されます。 多数の iptables ルールを使用すると、ポートマッププラグインのパフォーマンスに問題が発生する可能性があります。また、指定した時間内に 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: registry.ng.bluemix.net/armada-master/
      variant: Calico
    status:
      variant: Calico
    
  3. ファイルを保存して閉じます。 変更が自動的に適用されます。