调整性能

如果您具有特定的性能优化需求，那么可以在 Red Hat® OpenShift® on IBM Cloud® 中更改某些集群组件的缺省设置。

如果选择更改缺省设置，由此带来的风险由您自行承担。对任何已更改的设置运行测试是您的责任，并且对环境中因更改的设置而导致的任何潜在中断也由您负责。

您可以使用 daemonset 文件来修改主机，而不是使用 Red Hat OpenShift中的 MachineConfig 文件来调整工作程序节点性能。有关更多信息，请参阅更改 Calico MTU 或调整 Red Hat CoreOS 工作程序节点的性能。

缺省工作程序节点设置

默认情况下，您的 Worker 节点具有您在创建 Worker 池时选择的 Worker 节点类型的操作系统和计算硬件。

定制操作系统

您可以在 Red Hat OpenShift on IBM Cloud 版本信息中按集群版本查找受支持操作系统的列表。集群无法混合使用操作系统或使用不同的操作系统。

要优化工作程序节点，请考虑以下信息。

映像和版本更新: IBM 为您提供了工作程序节点更新，例如映像的安全补丁或 Red Hat OpenShift 版本。但是，您可以选择何时将更新应用于工作程序节点。有关更多信息，请参阅更新集群，工作程序节点和集群组件。
临时修改: 如果登录到 pod 或使用其他过程来修改工作程序节点设置，那么这些修改是临时的。工作程序节点生命周期操作 (例如自动恢复，重新装入，更新或替换工作程序节点) 将任何修改更改回缺省设置。
持久修改: 要使修改在工作程序节点生命周期操作之间持久存在，请创建使用 init 容器的守护程序集。有关更多信息，请参阅修改缺省工作程序节点设置以优化性能。

不支持对操作系统的修改。如果修改缺省设置，那么您负责调试和解决可能发生的问题。

硬件更改

要更改计算硬件 (例如，每个工作程序节点的 CPU 和内存)，请在以下选项中进行选择。

创建工作程序池。根据集群的基础结构类型 (例如，经典，VPC 或 Satellite)，指示信息有所不同。有关更多信息，请参阅将工作程序节点添加到经典集群或将工作程序节点添加到 VPC 集群。
通过创建工作程序池并除去先前的工作程序池，更新集群中的类型模板。

修改工作程序节点内核设置以优化性能

集群工作程序节点配置为具有期望满足大多数工作负载需求的稳定性，优化和性能级别。通常，不建议更改工作程序节点内核设置，因为此类更改可能会产生异常和意外的问题。但是，如果工作负载具有需要更改内核设置的高度唯一的性能优化需求，那么可以应用定制 Kubernetes daemonset 来更改内核配置。了解这些更改可能会产生严重的负面后果，并且您 在自行承担风险的情况下实施对内核设置配置的更改。

如果更改内核设置的配置，请确保记录并保存所做的准确更改。如果针对与集群相关的任何问题开具支持凭单，那么必须指定这些更改。这些配置更改可能对问题负责，并且可能会要求您在问题调查过程中还原这些更改。在这种情况下，您将负责还原您实现的任何内核配置更改。

更改缺省内核设置可能会对集群产生负面影响。请自行进行这些更改。

您可以通过将具有 init 容器的定制 Kubernetes DaemonSet 应用于集群来更改缺省内核设置。守护进程集会修改所有现有工作站的设置，并将这些设置应用到群集中配置的任何新工作站。 init 容器确保在工作程序节点上调度其他 pod 之前进行这些修改。这不会影响任何 pod。

您必须拥有所有命名空间的 Manager 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 :

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

部署以下示例 initContainer。请记住将 containers: 部分更改为您自己的应用程序容器。然后，initContainer 将为 pod 中的所有常规容器设置 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 字节。在大多数情况下，Calico默认 MTU 值足以防止数据包丢弃和分片。由于大多数主机使用 1500 的 MTU 值，这些默认值为Satellite集群的 VXLAN 标头提供了 50 个额外字节，并为非Satellite集群的 IP 标头提供了 20 个额外字节，这些标头用于某些 pod 到 pod 的集群网络流量。请注意，群集中的所有工作节点必须使用相同的CalicoMTU 值。

请查看以下可能需要修改缺省 Calico MTU 的情况：

如果需要提高 pod 到 pod 的网络吞吐量，而且集群节点能够使用更高的主机 MTU，那么可以同时增加主机和Calico的 MTU。这就是所谓的使用“巨型帧”。典型的巨型帧 MTU 为 9000。在这种情况下，可以将主机专用网络接口的 MTU 设置为 9000，将CalicoMTU 设置为稍低的值--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 Gen 2 工作程序节点: ip link set dev ens3 mtu 9000;

运行以下命令登录集群工作节点，并在节点之间ping。由于您的节点 MTU 只设置为 1500 或 1480，因此这次尝试预计会失败。在接下来的步骤中，您可以再次运行这些命令来验证更改是否成功。
1. 列出集群中的节点。保存两个健康节点的名称和 IP 地址。
```
oc get nodes -o wide
```
2. 登录到其中一个节点。指定节点名称。
```
oc debug node/<NODE_NAME>
```
3. 运行命令从一个节点 ping 到另一个节点。指定上一步中未引用的节点的 IP 地址。
```
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

应用守护进程更改节点 MTU 值。
```
  oc apply -f <file_name>
```
重新运行命令登录节点，并使用较大的数据包大小从一台主机 ping 到另一台主机。现在您已经增加了节点 MTU 值，"ping 命令有望成功执行。
```
oc debug node/<NODE_NAME>
```
```
ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
```
使用新的节点 MTU 值测试群集。在继续更改CalicoMTU 值之前，建议您检查一下，以确保您的应用程序仍能按预期运行。
运行该命令更新CalicoMTU 值，以便 pod 之间的流量也能使用较大的 MTU。对于SatelliteCore OS 群集，CalicoMTU 值应比节点 MTU 值少 50 字节。对于所有其他集群，CalicoMTU 值应小于 20 字节。例如，如果指定 9000 为节点 MTU，则“CalicoMTU 应为”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 直接编辑资源。
小心重启所有节点，将这些更改应用到所有节点。在继续执行此步骤之前，请确保已在开发集群上测试了此过程，因为这些更改可能会导致工作负载中断。要重启节点，建议您逐个封锁、排空和重启节点。

如果要在生产群集上完成这些步骤，则应使用与更新或替换生产节点相同的流程。强烈建议您先在测试群集上测试整个过程，然后再在生产群集上完成这些步骤。

在重启过程中，有些 pod 使用新的较大 MTU，有些 pod 仍使用原来的较小 MTU。通常情况下，这种情况不会造成问题，因为双方会协商正确的最大数据包大小。但是，如果阻止 ICMP 数据包，协商可能无法进行，集群可能会出现 pod 连接问题，直到所有重启完成。至关重要的是，首先要在开发集群上对这一过程进行测试。

禁用端口映射插件

Calico 容器网络接口 (CNI) 的 portmap 插件使您能够使用 hostPort 在工作程序节点上的特定端口上公开应用程序 pod。通过从集群的 Calico CNI 配置中除去端口映射插件来防止 iptables 性能问题。

当集群中有许多服务 (例如，超过 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: registry.ng.bluemix.net/armada-master/
  variant: Calico
status:
  variant: Calico

保存并关闭该文件。您的更改将自动应用。