調整效能

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

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

預設工作者節點設定

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

自訂作業系統

您可以在 Kubernetes 版本資訊中找到依叢集版本劃分的支援作業系統清單。您的叢集無法混合作業系統或使用不同的作業系統。

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

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

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

硬體變更

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

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

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

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

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

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

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

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

開始之前：請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

將下列常駐程式集儲存在名為 worker-node-kernel-settings.yaml 的檔案中。在 spec.template.spec.initContainers 區段中，新增您要調整的 sysctl 參數的欄位和值。此範例常駐程式集會透過 net.core.somaxconn 設定來變更環境中允許的預設連線數上限，以及透過 net.ipv4.ip_local_port_range 設定來變更暫時埠範圍。

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

將常駐程式集套用至工作者節點。會立即套用變更。
```
kubectl apply -f worker-node-kernel-settings.yaml
```

若要將工作節點的 sysctl 參數重設為預設值，請依照以下步驟操作。

刪除常駐程式集。即會移除套用自訂設定的 initContainers。
```
kubectl delete ds kernel-optimization
```
將叢集裡的所有工作者節點重新開機。工作者節點已回到線上，並已套用預設值。

將 Pod 效能最佳化

如果您具有特定的效能工作負載需求，則可以變更 Pod 網路名稱空間上 Linux Kernel sysctl 參數的預設值。

若要針對應用程式 Pod 優化核心設定，您可以將一個 initContainer patch 到每個部署的 pod/ds/rs/deployment YAML 檔案中。 initContainer 會新增至您要將效能最佳化的 Pod 網路名稱空間中的每個應用程式部署。

開始之前，請確保您已為所有命名空間取得「經理 IBM Cloud IAM 服務存取角色」，以便執行此特權範例：initContainer。在起始設定用於部署的容器之後，就會捨棄這些專用權。

將下列 initContainer 修補程式儲存在名為 pod-patch.yaml 的檔案中，並新增您要調整的 sysctl 參數的欄位和值。此範例 initContainer 會透過 net.core.somaxconn 設定來變更環境中允許的預設連線數上限，以及透過 net.ipv4.ip_local_port_range 設定來變更暫時埠範圍。

spec:
  template:
    spec:
      initContainers:
        - command:
            - sh
            - -c
            - sysctl -e -w net.core.somaxconn=32768;  sysctl -e -w net.ipv4.ip_local_port_range="1025 65535";
          image: alpine:3.6
          imagePullPolicy: IfNotPresent
          name: sysctl
          resources: {}
          securityContext:
            privileged: true

修補每一個部署。

kubectl patch deployment <deployment_name> --patch pod-patch.yaml

如果您變更了核心設定中的 net.core.somaxconn 值，大部分應用程式都可以自動使用更新的值。然而，有些應用程式可能需要您手動變更應用程式碼中的對應值，以符合核心值。例如，如果您要調整 NGINX 應用程式執行所在的 Pod 的效能，則必須變更 NGINX 應用程式碼中的 backlog 欄位的值，使其相符。如需更多資訊，請參閱這篇 NGINX 部落格文章。

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

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

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

部署下列範例 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

調整叢集度量提供者資源

您的叢集在 kube-system 名稱空間中具有 metrics-server 部署所提供的度量服務。 metrics-server 資源要求基於叢集裡的節點數目，並針對每個工作者節點具有 30 個或更少 Pod 的叢集進行最佳化。度量服務符合資源要求的記憶體及 CPU 限制。

如果記憶體要求太低，則會「記憶體不足」結束度量值服務容器。如果 CPU 要求太低，由於 CPU 節流控制，它們可能會回應非常緩慢或失敗的存活性及就緒性探測。

記憶體用量是由叢集中的 Pod 數目所驅動。 CPU 使用率是由度量值 (HPA、kubectl top nodes / pods 等) 的要求數及 API 探索要求所驅動。 metrics-server 提供 Kubernetes API，因此使用 API 探索的用戶端 (例如 kubectl ) 會在 metrics-server 上產生一些負載，即使它們未使用度量值也一樣。

下列症狀可能指出需要調整 metrics-server 資源:

這 metrics-server 經常重啟。
刪除命名空間會導致命名空間陷入困境 Terminating 狀態和 kubectl describe namespace 包括報告指標 API 發現錯誤的條件。
kubectl top pods, kubectl top nodes，其他 kubectl 命令或使用 Kubernetes API 記錄 Kubernetes 錯誤的應用程序，例如：

The server is currently unable to handle the request (get pods.metrics.k8s.io)

Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

HorizontalPodAutoscalers (HPA) 不會擴展部署。
跑步 kubectl get apiservices v1beta1.metrics.k8s.io 結果是這樣的狀態：

NAME                     SERVICE                      AVAILABLE                      AGE
v1beta1.metrics.k8s.io   kube-system/metrics-server   False (FailedDiscoveryCheck)   139d

修改 `metrics-server-config` 配置對映

CPU 和記憶體都有可調整的「基本」和「每個節點」設定，用來計算要求總數。

baseCPU
cpuPerNode
baseMemory
memoryPerNode

其中：

cpuRequest = baseCPU + cpuPerNode * number_of_nodes
memoryRequest = baseMemory + memoryPerNode * number_of_nodes

這些計算中的節點數目來自一組「儲存區大小」，且大小下限為 16 個節點。

以核心來要求 CPU，其值如 1 或小數值如 100m (100 millicore)。

以位元組為單位來要求記憶體，選用字尾為:

基數 2（ 1Ki = 1024）：Ki （千字節），Mi （兆位元組），Gi （千兆位元組）。
公制（ 1k = 1000）：k, M, G。

如果預期叢集中的節點數目會隨著時間而增加 (或只是變更)，您可能想要調整「每個節點」設定。如果節點數目是靜態的，請調整「基本」設定。最後，在 metrics-server 部署資源要求中設定 CPU 和記憶體總計值。

您可以藉由編輯度量提供者的 ConfigMap 來變更預設資源。請勿直接在 metrics-server 部署中修改資源要求或限制，metrics-server-nanny 儲存器會改寫這些值。

預設 metrics-server-config configmap 為:

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration

此範例顯示已定義所有值的 ConfigMap。

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    kubernetes.io/cluster-service: "true"
  name: metrics-server-config
  namespace: kube-system
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    baseCPU: 200m
    cpuPerNode: 1m
    baseMemory: 40Mi
    memoryPerNode: 6Mi

預設值為：

baseCPU: 200m
cpuPerNode: 1m
baseMemory: 40Mi
memoryPerNode: 6Mi

編輯配置對映

您可以使用 kubectl edit 指令來編輯 ConfigMap:

kubectl edit cm metrics-server-config -n kube-system

新增或編輯您要變更的欄位，然後儲存 ConfigMap 並結束編輯器。

IBM Cloud提供的 metrics-server 會監視 ConfigMap 是否有變更，並自動更新部署資源要求。 metrics-server 最多可能需要 10 分鐘來偵測變更，並根據更新的設定來推出一組新的 Pod。

還原預設值

若要將 metrics-server 還原為預設值，請刪除配置對映。它會在幾分鐘內重建。

kubectl delete cm metrics-server-config -n kube-system

決定要調整哪些資源

使用 kubectl describe pod 指令，以取得 Pod 定義、狀態資訊及最近的事件:

kubectl get pod -n kube-system -l k8s-app=metrics-server
NAME                             READY   STATUS    RESTARTS   AGE
metrics-server-9fb4947d6-s6sgl   3/3     Running   0          2d4h
kubectl describe pod -n kube-system metrics-server-9fb4947d6-s6sgl

輸出範例

Containers:
  metrics-server:
    Container ID:  containerd://fe3d07c9a2541242d36da8097de3896f740c1363f6d2bfd01b8d96a641192b1b
    Image:         us.icr.io/armada-master/metrics-server:v0.4.4
    Image ID:      us.icr.io/armada-master/metrics-server@sha256:c2c63900d0e080c2413b5f35c5a59b5ed3b809099355728cf47527aa3f35477c
    Port:          4443/TCP
    Host Port:     0/TCP
    Command:
      /metrics-server
      --metric-resolution=45s
      --secure-port=4443
      --tls-cert-file=/etc/metrics-server-certs/tls.crt
      --tls-private-key-file=/etc/metrics-server-certs/tls.key
    State:          Running
      Started:      Fri, 10 Sep 2021 17:31:39 +0000
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Fri, 10 Sep 2021 05:59:51 +0000
      Finished:     Fri, 10 Sep 2021 17:31:37 +0000
    Ready:          True
    Restart Count:  36

如果 Last State 顯示 Reason 為 OOMKilled，請以 100Mi 增量或更大的方式增加 metrics-server-config ConfigMap 中的記憶體要求，直到度量伺服器穩定且在沒有 OOMkilled 的情況下執行數小時或更長時間為止。

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

如果 Last state 顯示 Reason Error 及「事件」(例如下列範例中的事件)，請增加 metrics-server-config ConfigMap 中的 CPU 要求 (以 100m 增量或更大)，直到度量值伺服器穩定且執行數小時或更長時間，而不會因探測逾時而結束。

Last State:     Terminated
  Reason: Error
  Exit Code: 137

Events:
Warning Unhealthy 46m (x5 over 80m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 26m (x65 over 89m) kubelet Liveness probe failed: Get "https://198.18.68.236:4443/livez": net/http: TLS handshake timeout
Warning Unhealthy 21m (x10 over 76m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy 115s (x93 over 90m) kubelet Readiness probe failed: Get "https://198.18.68.236:4443/readyz": net/http: TLS handshake timeout

您可能需要重複此處理程序幾次，以達到穩定的配置，方法是先調整記憶體要求，然後調整 CPU 要求。

啟用巨型分頁

經典基礎架構虛擬私有雲

您可以在執行 Kubernetes 1.19 或更新版本的群集中啟用 Kubernetes HugePages 排程。唯一支援的頁面大小是每頁 2 MB，這是 Kubernetes 功能閘道的預設大小。

巨頁排程是 IBM Cloud Kubernetes Service 的測試版功能，可能會變更。

依預設，工作者節點的 CPU 會以 4 KB 的區塊或頁面來配置 RAM。當您的應用程式需要更多 RAM 時，系統必須繼續查閱更多頁面，這可能會減緩處理速度。使用巨型分頁，您可以將頁面大小增加至 2 MB，以增加 RAM 密集應用程式的效能，例如人工智慧 (AI) 資料庫、物聯網 (IoT) 或機器學習工作負載。如需巨型分頁的相關資訊，請參閱 Linux 核心文件。

您可以將工作者節點重新開機，而且巨型分頁配置會持續保存。但是，大頁面配置不會在任何其他工作節點生命週期操作中持續存在。每次更新、重新載入、取代或新增工作者節點時，都必須重複啟用步驟。

IBM Cloud IAM 中叢集的 操作員 平台存取角色及 管理員 服務存取角色

開始之前：請登入您的帳戶。適用的話，請將適當的資源群組設為目標。設定叢集的環境定義。

建立 hugepages-ds.yaml 配置檔以啟用巨型分頁。下列範例 YAML 使用常駐程式集，在叢集裡的每個工作者節點上執行 Pod。您可以使用 vm.nr_hugepages 參數來設定工作者節點上可用的巨型分頁配置。此範例會以每頁 2 MB 的速度配置 512 個頁面，針對 1 GB 專門配置給巨型分頁的 RAM 總計。

想要僅針對特定工作者節點啟用巨型分頁，例如用於 RAM 密集應用程式的工作者節點儲存區? 標籤及污染工作者節點儲存區，然後將親緣性規則新增至常駐程式集，以便 Pod 僅部署至您指定之工作者節點儲存區中的工作者節點。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hugepages-enablement
  namespace: kube-system
  labels:
    tier: management
    app: hugepages-enablement
spec:
  selector:
    matchLabels:
      name: hugepages-enablement
  template:
    metadata:
      labels:
        name: hugepages-enablement
    spec:
      hostPID: true
      initContainers:
        - command:
            - sh
            - -c
            # Customize allocated Hugepages by providing the value
            - "echo vm.nr_hugepages=512 > /etc/sysctl.d/90-hugepages.conf"
          image: alpine:3.6
          imagePullPolicy: IfNotPresent
          name: sysctl
          resources: {}
          securityContext:
            privileged: true
          volumeMounts:
            - name: modify-sysctld
              mountPath: /etc/sysctl.d
      containers:
        - resources:
            requests:
              cpu: 0.01
          image: alpine:3.6
          # once the init container completes, keep the pod running for worker node changes
          name: sleepforever
          command: ["/bin/sh", "-c"]
          args:
            - >
              while true; do
                  sleep 100000;
              done
      volumes:
        - name: modify-sysctld
          hostPath:
            path: /etc/sysctl.d

套用您先前建立的檔案。
```
kubectl apply -f hugepages-ds.yaml
```
請確認這些 Pod 是否處於「Running」狀態。
```
kubectl get pods
```

透過重新啟動工作者節點，重新啟動在每一個工作者節點上執行的 kubelet。不要重新載入工作者節點以重新啟動 kubelet。在 kubelet 在巨型分頁啟用上挑選之前重新載入工作者節點會導致啟用失敗。

列出叢集裡的工作者節點。

    ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
    ```
2. 將工作者節點重新開機。 您可以透過包括多個 `-w` 選項，將多個工作者節點重新開機，但確保同時保持足夠的工作者節點執行，以讓應用程式避免中斷。
```sh {: pre}
    ibmcloud ks worker reboot -c CLUSTER_NAME_OR_ID -w WORKER1_ID -w WORKER2_ID
    ```

建立 hugepages-test.yaml 測試 Pod，將巨型分頁裝載為磁區，並使用資源限制及要求來設定 Pod 使用的巨型分頁資源數量。附註: 如果您使用標籤、污點及親緣性規則只在選取的工作者節點上啟用巨型分頁，請在測試 Pod 中包含這些相同的規則。

apiVersion: v1
kind: Pod
metadata:
  name: hugepages-example
spec:
  containers:
    - name: hugepages-example
      image: fedora:34
      command:
        - sleep
        - inf
      volumeMounts:
        - mountPath: /hugepages-2Mi
          name: hugepage-2mi
      resources:
        limits:
          hugepages-2Mi: 100Mi
          memory: 100Mi
        requests:
          memory: 100Mi
  volumes:
    - name: hugepage-2mi
      emptyDir:
        medium: HugePages-2Mi

套用您先前建立的 pod 檔案。
```
kubectl apply -f hugepages-pod.yaml
```

驗證 Pod 是否使用巨型分頁資源。

檢查您的 Pod 是否 執行中。如果沒有具有巨型分頁的工作者節點可用，則 Pod 不會執行。

    kubectl get pods
    ```
2. 登入該 pod。
```sh {: pre}
    kubectl exec -it <pod> /bin/sh
    ```
3. 驗證 Pod 可以檢視巨型分頁的大小。
```sh {: pre}
    ls /sys/kernel/mm/hugepages
    ```
    輸出範例
    ```sh {: screen}
    hugepages-1048576kB  hugepages-2048kB
    ```

選用: 移除啟用常駐程式集。請記住，如果您稍後需要更新、重新載入、取代或新增具有巨型分頁的工作者節點，則必須重建常駐程式集。
```
kubectl -n kube-system delete daemonset hugepages-enablement
```
每當您更新、重新載入、取代或新增工作者節點時，請重複這些步驟。

若要對具有巨型分頁的工作者節點進行疑難排解，您只能將工作者節點重新開機。巨型分頁配置不會在任何其他工作者節點生命週期作業中持續保存，例如更新、重新載入、取代或新增工作者節點。若要從叢集中移除巨型分頁配置，您可以更新、重新載入或取代所有工作者節點。

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

您可以增加或減少工作節點及 Calico 外掛程式的最大傳輸單位 (MTU)，以符合您環境的網路吞吐量需求。

所有 VPC 工作節點最高支援 9000 MTU，傳統裸機工作節點也最高支援 9000 MTU。經典虛擬伺服器只支援標準的 1500 MTU，因此如果您的群集有任何經典虛擬伺服器工作節點，請勿增加工作節點或 Calico MTU。

更改最大傳輸單元 (MTU) 值可能會產生意外結果，尤其是在複雜的網路環境中。為了避免干擾您的工作流程，強烈建議您在對生產集群進行任何更改之前在開發集群上測試這些更改。

預設情況下，IBM Cloud Kubernetes Service叢集中的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，因此此嘗試預計會失敗。在以下步驟中，您可以再次執行這些命令以驗證變更是否成功。

列出叢集裡的節點。保存兩個健康節點的名稱和IP位址。

    kubectl get nodes -o wide
    ```
1. 登入其中一個節點。 指定節點的名稱。



```sh {: pre}
    kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
    ```


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 值。
```
  kubectl apply -f <file_name>
```
重新運行命令以登入節點並使用大數據包從一台主機 ping 到另一台主機。現在您已經增加了節點 MTU 值，ping 指令預計會成功。
```
kubectl debug --image=us.icr.io/armada-master/network-alpine -it node/<NODE_NAME> -- sh
```
```
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。
```
kubectl patch installation.operator.tigera.io default --type='merge' -p '{"spec":{"calicoNetwork":{"mtu":<MTU_VALUE>}}}'
```
您也可以透過執行 kubectl edit installation.operator.tigera.io default 直接編輯資源。
透過小心地重新啟動所有節點，將這些變更套用到所有節點。在繼續此步驟之前，請確定您已在開發群集上測試過此程序，因為這些變更可能會導致工作負載中斷。若要重新啟動節點，建議您逐一封鎖、排空並重新啟動節點。

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

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

在 Calico

portmap 外掛程式適用於 Calico container network interface (CNI)，可讓您使用 hostPort 在工作節點上的特定連接埠揭露您的應用程式 Pod。從叢集的 Calico CNI 設定中移除連接埠映射外掛程式，以防止出現 iptables 效能問題。

當叢集裡有許多服務 (例如超過 500 個服務) 或服務上的許多埠 (例如 10 個以上服務的每個服務超過 50 個埠) 時，會針對這些服務的 Calico 及 Kubernetes 網路原則產生許多 iptables 規則。使用許多 iptables 規則可能會導致埠對映外掛程式的效能問題，並且可能會阻止未來更新 iptables 規則，或者在未收到鎖定以在指定時間內進行 iptables 規則更新時，導致 calico-node 儲存器重新啟動。若要防止這些效能問題，您可以從叢集的 Calico CNI 配置中移除埠對映外掛程式，以停用埠對映外掛程式。

如果您必須使用 hostPorts，請勿停用埠對映外掛程式。

編輯 default Calico 安裝資源。

kubectl 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

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

調整效能

調整效能

預設工作者節點設定

自訂作業系統

硬體變更

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

將 Pod 效能最佳化

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

調整叢集度量提供者資源

修改 metrics-server-config 配置對映

編輯配置對映

還原預設值

決定要調整哪些資源

啟用巨型分頁

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

在 Calico

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

修改 `metrics-server-config` 配置對映