調整效能

如果您具有特定的效能最佳化需求，則可以在 Red Hat® OpenShift® on IBM Cloud® 中變更部分叢集元件的預設值。

如果您選擇變更預設值，則必須自行承擔風險。您負責針對任何變更的設定執行測試，以及負責處理環境中因變更的設定而造成的任何可能中斷情況。

與其透過中的 MachineConfig 檔案來調整 Red Hat OpenShift 工作節點的效能，您也可以使用檔案 daemonset 來修改主機設定。如需更多資訊，請參閱《變更 MTU Calico 或調整 CoreOSRed Hat 工作節點效能》。

預設工作者節點設定

預設情況下，您的工作程序節點具有您在建立工作程序集區時選擇的工作程序節點風格的作業系統和計算硬體。

自訂作業系統

您可在版本 Red Hat OpenShift on IBM Cloud 資訊中查閱各叢集版本所支援的作業系統清單。您的叢集無法混合作業系統或使用不同的作業系統。

若要最佳化工作者節點，請考量下列資訊。

映像檔及版本更新: 工作者節點更新項目 (例如映像檔的安全修補程式或 Red Hat OpenShift 版本) 由 IBM 提供。不過，您可以選擇何時將更新項目套用至工作者節點。如需相關資訊，請參閱更新叢集、工作者節點及叢集元件。
暫時修改: 如果您登入 Pod 或使用其他處理程序來修改工作者節點設定，則修改是暫時的。工作者節點生命週期作業 (例如自動回復、重新載入、更新或取代工作者節點) 會將任何修改變更回預設值。
持續性修改: 若要在工作者節點生命週期作業之間持續進行修改，請建立使用 init 儲存器的常駐程式集。如需相關資訊，請參閱修改預設工作者節點設定以最佳化效能。

不支援修改作業系統。如果您修改預設值，則您負責除錯及解決可能發生的問題。

硬體變更

若要變更運算硬體 (例如每個工作者節點的 CPU 及記憶體)，請在下列選項中進行選擇。

建立工作者節點儲存區。指示視叢集的基礎架構類型而定，例如標準、VPC 或 Satellite。如需相關資訊，請參閱將工作者節點新增至標準叢集或將工作者節點新增至 VPC 叢集。
透過建立工作者節點儲存區並移除先前的工作者節點儲存區，在叢集裡更新特性。

修改工作者節點核心設定以最佳化效能

叢集工作者節點是針對預期符合大部分工作負載需求的穩定性、最佳化及效能層次所配置。通常不建議變更工作者節點核心設定，因為這類變更可能會產生異常及非預期的問題。不過，如果工作負載具有高度獨特的效能最佳化需求，需要對核心設定進行變更，則可以套用自訂 Kubernetes daemonset 來變更核心配置。請瞭解這些變更可能有重大負面影響，且您 自行承擔風險實作核心程式設定配置的變更。

如果您變更了核心設定的組態，請務必記錄並儲存您所做的確切變更。如果您針對與叢集相關的任何問題開立支援問題單，則必須指定這些變更。這些配置變更可能負責問題，在問題調查中可能會要求您回復變更。在此情況下，您負責回復您實作的任何核心配置變更。

變更預設核心設定可能會對叢集產生負面影響。請自行承擔這些變更的風險。

您可以將具有 init 儲存器的自訂 Kubernetes DaemonSet 套用至叢集，以變更預設核心設定。此 DaemonSet 會修改所有現有工作節點的設定，並將這些設定套用至叢集中所配置的任何新工作節點。 init 儲存器確保在工作者節點上排定其他 Pod 之前進行這些修改。不影響任何 Pod。

您必須對所有命名空間擁有「經理 IBM Cloud IAM 服務存取角色」權限，才能執行此範例：initContainer。在起始設定用於部署的容器之後，就會捨棄這些專用權。

開始之前: 存取 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` 設定

如果 pod 有長時間運行的 TCP 連線，而這些連線在閒置一段時間後偶爾會斷線，那麼變更 pod 的 sysctl keepalive 設定可能會有所幫助。

依預設，目前無法在叢集裡的所有 Pod 上設定這些 sysctl 保留作用中設定。修改所有 Pod 上的設定的最佳方式是使用特許 initContainer。請檢閱下列範例，以瞭解如何為 test-ns 名稱空間中的部署設定 initContainer。

在 test-ns 名稱空間中容許特許 initContainers:

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

部署下列範例 initContainer。請記得將 containers: 區段變更為您自己的應用程式儲存器。然後，initContainer 會為 Pod 中的所有一般容器設定 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 位元組。對於大多數情況，此預設Calico MTU 值足以防止封包遺失和碎片。由於大多數主機使用 1500 的 MTU 值，因此這些預設值為Satellite叢集提供 50 個額外位元組用於 VXLAN 標頭，並為非Satellite叢集提供20 個額外位元組用於某些Pod 到Pod 叢集網路流量中使用的IP 標頭。請注意，叢集中的所有工作節點必須使用相同的Calico MTU 值。

請檢閱下列可能需要修改預設 Calico MTU 的情況：

如果您需要提高 Pod 到 Pod 的網路吞吐量，並且叢集節點能夠使用更高的主機 MTU，那麼您可以同時增加主機和Calico MTU。這稱為使用“巨型幀”。典型的巨型幀 MTU 為 9000。在這種情況下，您可以將主機專用網路介面的 MTU 值設定為 9000，將Calico MTU 設定為稍低的值 — 對於Satellite叢集為 8950，對於非Satellite叢集為 8980。請注意，某些雲端供應商硬體或資源（例如Azure虛擬機）可能不支援巨型幀，或者可能僅支援最大 4000 的 MTU 值。
如果為叢集設定了 VPN 連線，則某些 VPN 連線需要的 Calico MTU 小於預設。請向 VPN 服務供應商確認，是否需要將「Calico」的 MTU 值設定得更小。

開始之前

如果工作者節點仍執行預設 MTU 值，請先增加工作者節點的 MTU 值，然後再增加 Calico 外掛程式的 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;

執行下列指令以登入群集 Worker 節點，並從一個節點 ping 到另一個節點。由於您的節點 MTU 僅設定為 1500 或 1480，因此此嘗試預計會失敗。在以下步驟中，您可以再次執行這些命令以驗證變更是否成功。
1. 列出叢集裡的節點。保存兩個健康節點的名稱和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>
    ```
```

使用以下範例 daemonset 變更節點 MTU。此 MTU 值適用於節點到節點的流量。修改 - ip link set dev ens3 mtu <MTU_VALUE> 行，加入您的 MTU 值（範例中使用的 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

應用 daemonset 來更改節點 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 值，以便 Pod 到 Pod 的流量也可以使用更大的 MTU。對於Satellite Core OS 集群，Calico MTU 值應比節點 MTU 值小 50 個位元組。對於所有其他集群，Calico MTU 值應少 20 個位元組。例如，如果您為節點 MTU 指定 9000，則您的Calico MTU 對於Satellite Core 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 直接編輯資源。
透過小心地重新啟動所有節點，將這些變更套用到所有節點。在繼續此步驟之前，請確定您已在開發群集上測試過此程序，因為這些變更可能會導致工作負載中斷。若要重新啟動節點，建議您逐一鎖、排空並重新啟動節點。

如果您在生產叢集上完成這些步驟，則應使用與更新或替換生產節點相同的流程。強烈建議您在生產叢集上完成這些步驟之前在測試叢集上測試整個流程。

在重新啟動過程中，某些 Pod 使用新的較大 MTU，而某些 Pod 仍具有原始的較小 MTU。通常，這種情況不會導致問題，因為雙方協商正確的最大資料包大小。但是，如果您封鎖 ICMP 封包，則協商可能無法進行，並且您的叢集可能會遇到 Pod 連線問題，直到所有重新啟動完成為止。至關重要的是，這個過程首先要在開發叢集上進行測試。

在 Calico

容器網路 Calico 介面（CNI）的 portmap 插件可讓您使用特定端口 hostPort，將應用程式 Pod 暴露於工作節點上。為避免 iptables 效能問題，請從叢集的 Calico CNI 設定中移除 port map 插件。

當叢集裡有許多服務 (例如超過 500 個服務) 或服務上的許多埠 (例如 10 個以上服務的每個服務超過 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: us.icr.io/armada-master/
  variant: Calico
status:
  variant: Calico

儲存並關閉檔案。您的變更已自動套用。

調整效能

調整效能

預設工作者節點設定

自訂作業系統

硬體變更

修改工作者節點核心設定以最佳化效能

最佳化網路保持作用中 sysctl 設定

變更群集使用的最大傳輸單位 (MTU) Calico

在 Calico

最佳化網路保持作用中 `sysctl` 設定