パフォーマンスのチューニング
特定のパフォーマンス最適化要件がある場合は、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 やメモリーなどのコンピュート・ハードウェアを変更する場合、以下のオプションから選択します。
- ワーカー・プールを作成します。 手順は、クラシカル、VPC、 Satellite など、クラスタのインフラストラクチャのタイプによって異なります。 詳しくは、 クラシック・クラスターへのワーカー・ノードの追加 または VPC クラスターへのワーカー・ノードの追加 を参照してください。
- ワーカー・プールを作成して前のワーカー・プールを削除することで、クラスターのフレーバーを更新します。
ワーカーノードのカーネル設定を変更してパフォーマンスを最適化する
クラスター・ワーカー・ノードは、ほとんどのワークロードのニーズを満たすことが期待される安定性、最適化、およびパフォーマンスのレベルで構成されます。 通常、ワーカー・ノードのカーネル設定を変更することはお勧めしません。そのような変更を行うと、異常な問題や意図しない問題が発生する可能性があります。 ただし、ワークロードに、カーネル設定の変更を必要とする非常に固有のパフォーマンス最適化要件がある場合は、カスタム Kubernetes デーモン・セットを適用してカーネル構成を変更することができます。 これらの変更は重大な悪影響を及ぼす可能性があること、および お客様自身の責任でカーネル設定構成に対する変更を実装することを理解してください。
カーネル設定の構成を変更する場合は、必ず、行った変更を正確に文書化して保存してください。 クラスターに関連する問題のサポート・チケットをオープンする場合は、これらの変更を指定する必要があります。 これらの構成変更が問題の原因となっている可能性があり、問題調査の一環として変更を元に戻すように求められる場合があります。 この場合、実装したカーネル構成変更を元に戻す必要があります。
デフォルトのカーネル設定を変更すると、クラスターに悪影響を及ぼす可能性があります。 これらの変更は、お客様の責任で行ってください。
デフォルトのカーネル設定を変更するには、 init
コンテナー を使用してカスタム Kubernetes DaemonSet
をクラスターに適用します。 デーモン・セットは、既存のすべてのワーカー・ノードの設定を変更し、クラスター内でプロビジョンされる新しいワーカー・ノードにこの設定を適用します。 init
コンテナは、ワーカーノードで他のポッドがスケジュールされる前に、これらの変更が行われるようにする。 ポッドは影響を受けません。
サンプルの特権 initContainer
を実行するには、すべてのネームスペースの Manager IBM Cloud IAM サービスアクセスロールが 必要です。 デプロイメントのコンテナーが初期化された後、特権は除去されます。
始める前に、Red Hat OpenShift クラスターにアクセスします。
-
以下のデーモン・セットを
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
-
ワーカー・ノードにデーモン・セットを適用します。 この変更はすぐに適用されます。
oc apply -f worker-node-kernel-settings.yaml
ワーカーノードの sysctl
パラメータをデフォルト値に戻すには、以下の手順に従ってください。
- デーモン・セットを削除します。 カスタム設定を適用した
initContainers
が削除されます。oc delete ds kernel-optimization
- クラスター内のすべてのワーカー・ノードをリブートします。 ワーカー・ノードは、デフォルト値が適用された状態でオンラインに戻ります。
ネットワーク・キープアライブ 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;
- ベア・メタル・ワーカー・ノードのコマンド例:
-
クラスタのワーカーノードにログインし、ノード間でpingを実行するには、以下のコマンドを実行します。 ノードのMTUは1500または1480にしか設定されていないため、この試みは失敗すると予想される。 次のステップでは、これらのコマンドを再度実行して、変更が成功したことを確認します。
-
クラスター内のノードをリストします。 健全な2つのノードの名前とIPアドレスを保存する。
oc get nodes -o wide
-
いずれかのノードにログインします。 ノードの名前を指定する。
oc debug node/<NODE_NAME>
-
一方のノードから他方のノードにpingを打つコマンドを実行する。 前のステップで参照しなかったノードのIPアドレスを指定します。
ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
-
-
以下の例のデーモンセットでノードの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
-
デーモンセットを適用してノードのMTU値を変更する。
oc apply -f <file_name>
-
ノードにログインし、あるホストから別のホストへ、大きなパケットサイズを使ってpingを打つコマンドを再実行する。 ノードのMTU値を増やしたので、'
ping
コマンドは成功すると思われる。oc debug node/<NODE_NAME>
ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
-
新しいノードMTU値でクラスタをテストするのに時間をかけてください。 CalicoのMTU値の変更を続ける前に、アプリケーションが期待通りに機能するか確認することをお勧めします。
-
コマンドを実行して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
を実行して直接リソースを編集することもできる。 -
すべてのノードを注意深く再起動して、これらの変更をすべてのノードに適用します。 これらの変更によってワークロードが中断される可能性があるため、このステップを続行する前に、開発クラスタ上でこのプロセスをテストしていることを確認してください。 ノードをリブートするには、ノードの コード化、排水、リブート を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
を使用する必要がある場合は、ポート・マップ・プラグインを無効にしないでください。
default
Calico インストール・リソースを編集します。oc edit installation default -n calico-system
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
- ファイルを保存して閉じます。 変更が自動的に適用されます。