2.3. OpenShift Serverless Serving의 확장 및 성능

• 170 Knative 서비스
• Knative 서비스당 1-2 버전
• 89 테스트 시나리오는 주로 컨트롤 플레인 테스트에 중점을 두고 있습니다.
• 48 Knative 서비스가 삭제되고 다시 생성되는 시나리오
• 41 안정적인 시나리오: 요청이 느리지만 지속적으로 시스템으로 전송됨

프로세스

• KnativeServing 사용자 정의 리소스(CR)를 사용하여 최소 워크로드에 대해 Knative Serving 을 구성할 수 있습니다.

  KnativeServing CR의 최소 워크로드 구성

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 1 1
    workloads:
      - name: activator
        replicas: 2 2
        resources:
          - container: activator
            requests:
              cpu: 250m 3
              memory: 60Mi 4
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 5
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 6
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 7
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 8
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  1

  이 값을 1 로 설정하면 모든 시스템 구성 요소가 하나의 복제본으로 확장됩니다.

  2

  다운타임을 방지하려면 활성기를 항상 최소 2 개의 인스턴스로 스케일링해야 합니다.

  3

  HorizontalPodAutoscaler 는 이를 확장 및 축소하기 위한 참조로 사용하므로 활성화기 CPU 요청을 250m 미만으로 설정해야 합니다.

  4

  이전 표의 유휴 값으로 메모리 요청을 조정합니다. 또한 예상 로드에 따라 메모리 제한을 조정합니다(최고의 값을 찾으려면 사용자 지정 테스트가 필요할 수 있음).

  5

  하나의 Webhook와 하나의 컨트롤러가 최소 워크로드 시나리오에 충분합니다.

  6

  이러한 제한은 최소 워크로드 시나리오에는 충분하지만 구체적인 워크로드에 따라 조정이 필요할 수 있습니다.

  7

  HorizontalPodAutoscaler는 이를 확장 및 축소하기 위한 참조로 사용하므로 Webhook CPU 요청을 100m 미만으로 설정하지 않아야 합니다.

  8

  노드 유지보수 중 문제를 방지하기 위해 PodDistruptionBudgets 를 복제본 보다 낮은 값으로 조정합니다.

• 모든 데이터 플레인 구성 요소는 높은 요청 및 페이로드 시나리오에서 CPU 사용량이 크게 증가하므로 CPU 요청 및 제한을 테스트해야 하며 잠재적으로 증가할 수 있습니다.
• 또한 활성화 구성 요소에 더 많은 요청 페이로드를 버퍼링해야 하는 경우 더 많은 메모리가 필요할 수 있으므로 메모리 요청 및 제한도 늘려야 할 수 있습니다.
• 하나의 activator Pod는 대기 시간을 늘리기 전에 초당 약 2500 건의 요청을 처리할 수 있으며 어느 시점에서 오류가 발생합니다.
• 1개의 3scale-kourier-gateway 또는 istio-ingressgateway Pod는 대기 시간을 늘리기 전에 초당 약 2500개의 요청을 처리할 수 있으며 어느 시점에서 오류가 발생할 수도 있습니다.
• 각 데이터 플레인 구성 요소는 초당 2500개의 요청을 처리하기 위해 최대 1개의 CPU vCPU를 사용합니다. 이는 Knative 서비스 백엔드의 페이로드 크기 및 응답 시간에 따라 달라집니다.

프로세스

• 설치를 미세 조정하려면 자체 테스트 결과와 결합된 이전 결과를 사용하여 KnativeServing 사용자 정의 리소스를 구성합니다.

  KnativeServing CR의 높은 워크로드 구성

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 2 1
    workloads:
      - name: component-name 2
        replicas: 2 3
        resources:
          - container: container-name
            requests:
              cpu: 4
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 5
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  1

  이 매개변수를 최소 2 개로 설정하여 모든 구성 요소의 인스턴스가 항상 두 개 이상 실행되고 있는지 확인합니다. 워크로드를 사용하여 특정 구성 요소의 복제본을 덮어쓸 수도 있습니다.

  2

  워크로드 목록을 사용하여 특정 구성 요소를 구성합니다. 구성 요소의 배포 이름을 사용하고 replicas 필드를 설정합니다.

  3

  HPA(수평 Pod 자동 스케일러)를 사용하는 activator,webhook, 3scale-kourier-gateway 구성 요소의 경우 replicas 필드는 최소 복제본 수를 설정합니다. 실제 복제본 수는 HPA에서 수행하는 CPU 로드 및 스케일링에 따라 다릅니다.

  4

  이전 결과 및 자체 테스트 결과를 고려하여 최소한 유휴 사용량에 따라 요청된 CPU 및 메모리를 설정합니다.

  5

  노드 유지보수 중 문제를 방지하려면 PodDistruptionBudgets 를 복제본 보다 낮은 값으로 조정합니다. 기본 minAvailable 은 1 로 설정되어 있으므로 필요한 복제본을 늘리는 경우 minAvailable 도 늘려야 합니다.