성능 튜닝

특정 성능 최적화 요구사항이 있는 경우, Red Hat® OpenShift® on IBM Cloud®의 일부 클러스터 컴포넌트에 대한 기본 설정을 변경할 수 있습니다.

기본 설정을 변경하도록 선택한 경우 사용자가 직접 위험을 감수해야 합니다. 사용자 환경의 변경된 설정으로 인해 발생하는 잠재적 중단에 대해, 그리고 변경된 설정에 대한 테스트의 실행에 대해 사용자가 직접 책임을 져야 합니다.

작업자 노드 성능을 파일로 MachineConfig 조정하는 Red Hat OpenShift 대신, 파일을 daemonset 사용하여 호스트를 수정할 수 있습니다. 자세한 내용은 작업자 Red HatCoreOS 노드의 MTU Calico 변경 또는 성능 조정을 참조하십시오.

기본 작업자 노드 설정

기본적으로 워커 노드는 워커 풀을 생성할 때 선택한 워커 노드 플레버의 운영 체제와 컴퓨팅 하드웨어를 갖습니다.

운영 체제 사용자 정의

클러스터 버전에 따른 지원 운영 체제 목록은 버전 Red Hat OpenShift on IBM Cloud 정보에서 확인할 수 있습니다. 클러스터에서 운영 체제를 혼합하거나 다른 운영 체제를 사용할 수는 없습니다.

작업자 노드를 최적화하려면 다음 정보를 고려하십시오.

  • 이미지 및 버전 업데이트: 이미지 또는 Red Hat OpenShift 버전에 대한 보안 패치와 같은 작업자 노드 업데이트가 IBM에서 제공됩니다. 하지만, 작업자 노드에 업데이트를 적용하는 시기를 선택합니다. 자세한 정보는 클러스터, 작업자 노드, 클러스터 컴포넌트 업데이트를 참조하십시오.
  • 임시 수정사항: 팟(Pod)에 로그인하거나 다른 프로세스를 사용하여 작업자 노드 설정을 수정하는 경우 수정사항은 일시적입니다. 작업자 노드 라이프사이클 오퍼레이션(예: 자동 복구, 다시 로드, 업데이트 또는 작업자 노드 대체)은 수정사항을 기본 설정으로 다시 변경합니다.
  • 변경 사항의 영구 저장 : 작업자 노드의 수명 주기 작업 전반에 걸쳐 변경 사항을 영구적으로 유지하려면, init 컨테이너를 사용하는 데몬 세트를 생성하십시오. 자세한 정보는 기본 작업자 노드 설정을 수정하여 성능 최적화를 참조하십시오.

운영 체제에 대한 수정은 지원되지 않습니다. 기본 설정을 수정하는 경우 발생하는 문제를 디버그하고 해결하는 작업은 사용자의 책임입니다.

하드웨어 변경사항

작업자 노드당 CPU 및 메모리와 같은 컴퓨팅 하드웨어를 변경하려면 다음 옵션 중에서 선택하십시오.

성능 최적화를 위한 워커 노드 커널 설정 수정

클러스터 작업자 노드는 대부분의 워크로드의 요구사항을 충족할 것으로 예상되는 안정성, 최적화 및 성능 레벨에 맞게 구성됩니다. 일반적으로 작업자 노드 커널 설정을 변경하면 비정상적이고 의도하지 않은 문제가 발생할 수 있으므로 이를 변경하지 않는 것이 좋습니다. 그러나 워크로드에 커널 설정을 변경해야 하는 매우 고유한 성능 최적화 요구사항이 있는 경우 사용자 정의 Kubernetes 디먼 세트를 적용하여 커널 구성을 변경할 수 있습니다. 이러한 변경사항은 심각한 부정적인 결과를 초래할 수 있으며 사용자 자신의 위험으로커널 설정 구성에 대한 변경사항을 구현해야 합니다.

커널 설정 구성을 변경하는 경우 정확한 변경 내용을 문서화하여 저장해야 합니다. 클러스터와 관련된 문제에 대한 지원 티켓을 여는 경우 이러한 변경사항을 지정해야 합니다. 이러한 구성 변경으로 인해 문제가 발생할 수 있으며 문제 조사의 일부로 변경사항을 되돌리도록 요청을 받을 수 있습니다. 이 경우, 사용자는 사용자가 구현하는 커널 구성 변경사항을 되돌릴 책임이 있습니다.

기본 커널 설정을 변경하면 클러스터에 부정적인 영향을 미칠 수 있습니다. 이러한 변경은 사용자가 직접 수행해야 하는 위험이 있습니다.

init 컨테이너 가 있는 사용자 정의 Kubernetes DaemonSet 를 클러스터에 적용하여 기본 커널 설정을 변경할 수 있습니다. 디먼 세트는 기존 모든 작업자 노드에 대한 설정을 수정하고 설정을 클러스터에 프로비저닝된 새 작업자 노드에 적용합니다. init 컨테이너는 다른 파드가 워커 노드에 스케줄링되기 전에 이러한 변경 사항이 적용되도록 보장합니다. 팟(Pod)은 영향을 받지 않습니다.

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. 클러스터의 모든 작업자 노드를 재부팅하십시오. 작업자 노드는 기본값이 적용되어 다시 온라인 상태가 됩니다.

네트워크 활성 유지 (keepalive) sysctl 설정 최적화

파드가 일정 시간 동안 유휴 상태일 때 가끔 연결이 끊어지는 TCP 연결을 오래 실행하는 경우, 파드의 sysctl 킵얼라이브 설정을 변경하는 것이 도움이 될 수 있습니다.

현재 클러스터의 모든 팟 (Pod) 에서 이러한 sysctl 활성 유지 (keepalive) 설정을 기본적으로 설정하는 방법은 없습니다. 모든 팟 (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 클러스터에 VXLAN 헤더에 50바이트의 추가 바이트를 제공하고 Satellite 클러스터에는 일부 포드-포드 클러스터 네트워크 트래픽에 사용되는 IP 헤더에 20바이트의 추가 바이트를 제공합니다. 클러스터의 모든 워커 노드는 동일한 Calico MTU 값을 사용해야 한다는 점에 유의하세요.

기본 Calico MTU를 수정해야 하는 다음과 같은 경우를 검토하십시오.

  • 포드-포드 네트워크 처리량을 개선해야 하고 클러스터 노드가 더 높은 호스트 MTU를 사용할 수 있는 경우, 호스트와 Calico MTU를 모두 늘릴 수 있습니다. 이를 "점보 프레임" 사용이라고 합니다. 일반적인 점보 프레임 MTU는 9000입니다. 이 경우 호스트 사설 네트워크 인터페이스를 9000의 MTU 값으로 설정하고 Calico MTU는 약간 낮은 값( Satellite 클러스터의 경우 8950, Satellite 클러스터의 경우 8980)으로 설정할 수 있습니다. Azure 가상 머신과 같은 일부 클라우드 공급자 하드웨어 또는 리소스는 점보 프레임을 지원하지 않거나 최대 4000의 MTU 값만 지원할 수 있습니다.
  • 클러스터에 대한 VPN 연결이 설정되어 있는 경우 일부 VPN 연결에서는 기본값보다 적은 수의 Calico MTU가 필요합니다. 더 작은 Calico MTU가 필요한지 여부를 VPN 서비스 제공자에게 확인하십시오.
시작하기 전에
워커 노드가 여전히 기본 MTU 값을 사용하고 있다면, ‘ Calico ’ 플러그인의 MTU 값을 늘리기 전에 먼저 워커 노드의 MTU 값을 늘리십시오. 예를 들어, 다음 데몬 세트를 적용하여 워커 노드의 MTU를 9000바이트로 변경할 수 있습니다. ip link 명령에서 사용되는 인터페이스 이름은 작업자 노드의 유형에 따라 다릅니다.
  • Bare Metal 작업자 노드에 대한 예제 명령: ip link set dev bond0 mtu 9000;ip link set dev bond1 mtu 9000;
  • 명령 VPC 워커 노드 예시: ip link set dev ens3 mtu 9000;

  1. 다음 명령을 실행하여 클러스터 작업자 노드에 로그인하고 한 노드에서 다른 노드로 ping을 보냅니다. 노드 MTU가 1500 또는 1480으로만 설정되어 있으므로 이 시도는 실패할 것으로 예상됩니다. 다음 단계에서는 이러한 명령을 다시 실행하여 변경이 성공적으로 이루어졌는지 확인할 수 있습니다.

    1. 클러스터의 노드를 나열하십시오. 두 개의 정상 노드의 이름과 IP 주소를 저장합니다.
        oc get nodes -o wide
    ```
1. 노드 중 하나에 로그인합니다. 노드 이름을 지정합니다.


```sh {: pre}
    oc debug node/<NODE_NAME>
    ```



1. 명령을 실행하여 한 노드에서 다른 노드로 핑합니다. 이전 단계에서 참조하지 않은 노드의 IP 주소를 지정합니다.
```sh {: pre}
    ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>
    ```

  2. 다음 예제 데몬셋을 사용하여 노드 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

  3. 데몬셋을 적용하여 노드 MTU 값을 변경합니다.

      oc apply -f <file_name>

  4. 명령을 다시 실행하여 큰 패킷 크기를 사용하여 노드에 로그인하고 한 호스트에서 다른 호스트로 핑하는 명령을 실행합니다. 이제 노드 MTU 값을 늘렸으므로 ' ping ' 명령이 성공할 것으로 예상됩니다.

    oc debug node/<NODE_NAME>

    ping -c1 -Mdo -s 8972 <OTHER_HOST_IP>

  5. 시간을 내어 새 노드 MTU 값으로 클러스터를 테스트하세요. Calico MTU 값 변경을 계속하기 전에 애플리케이션이 여전히 예상대로 작동하는지 확인하는 것이 좋습니다.

  6. 명령을 실행하여 Calico MTU 값을 업데이트하여 파드 간 트래픽도 더 큰 MTU를 사용할 수 있도록 합니다. Satellite 코어 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'을 실행하여 리소스를 직접 편집할 수도 있습니다.

  7. 모든 노드를 신중하게 재부팅하여 이러한 변경 사항을 모든 노드에 적용합니다. 이러한 변경으로 인해 워크로드에 중단이 발생할 수 있으므로 이 단계를 계속하기 전에 개발 클러스터에서 이 프로세스를 테스트했는지 확인하세요. 노드를 재부팅하려면 노드를 하나씩 연결 해제하고 전원을 차단한 후 재부팅하는 것이 좋습니다.

프로덕션 클러스터에서 이러한 단계를 완료하는 경우 프로덕션 노드를 업데이트하거나 교체할 때 사용하는 것과 동일한 프로세스를 사용해야 합니다. 프로덕션 클러스터에서 이 단계를 완료하기 전에 테스트 클러스터에서 이 전체 프로세스를 테스트하는 것이 좋습니다.

재부팅 프로세스 중에 일부 파드는 새로운 더 큰 MTU를 사용하고 일부 파드는 여전히 원래의 더 작은 MTU를 사용합니다. 일반적으로 이 시나리오에서는 양측이 정확한 최대 패킷 크기를 협상하기 때문에 문제가 발생하지 않습니다. 그러나 ICMP 패킷을 차단하면 협상이 작동하지 않을 수 있으며 모든 재부팅이 완료될 때까지 클러스터에 파드 연결 문제가 발생할 수 있습니다. 이 프로세스는 먼저 개발 클러스터에서 테스트하는 것이 중요합니다.

포트 맵 플러그인 비활성화하기 Calico

Calico 컨테이너 네트워크 인터페이스(CNI)의 portmap 플러그인은 작업자 노드의 특정 포트에서 앱 팟(Pod)을 노출시키기 위해 hostPort를 사용할 수 있도록 합니다. 포트 맵 플러그인을 Calico CNI 구성에서 제거하여 iptables 성능 문제를 방지하십시오.

클러스터에 많은 서비스가 있거나(예: 500개 이상의 서비스) 서비스에 많은 포트가 있는 경우(예: 10개 이상의 서비스에 대한 서비스당 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: us.icr.io/armada-master/
  variant: Calico
status:
  variant: Calico

  3. 파일을 저장한 후 닫으십시오. 변경사항이 자동으로 적용됩니다.