Kubernetes에서 실행되는 대부분의 서비스는 명령줄 또는 구성 재정의에서 확장할 수 있습니다. overrides.yaml 파일에서 Apigee Hybrid 런타임 서비스에 대한 확장 매개변수를 설정할 수 있습니다.
| 서비스 | 구현 방식 | 확장 |
|---|---|---|
| Cassandra | ApigeeDatastore(CRD) | Cassandra 확장을 참조하세요. |
| 인그레스/LoadBalancer | 배포 | Anthos Service Mesh는 수평형 포드 자동 확장(HPA)을 사용합니다. |
| Logger | DaemonSet | DaemonSets는 모든 노드에서 포드의 복제본을 관리하므로 포드 자체를 확장할 때 포드가 확장됩니다. |
| MART Apigee Connect Watcher |
ApigeeOrganization(CRD) | 구성을 통해 확장하려면 mart: replicaCountMax: 2 replicaCountMin: 1 watcher: replicaCountMax: 2 replicaCountMin: 1 connectAgent: replicaCountMax: 2 replicaCountMin: 1 이 배포는 자동 확장에 수평형 포드 자동 확장 처리를 사용합니다. 배포 객체의 구성 속성 설정에 대한 자세한 내용은 런타임 영역 구성요소 관리를 참조하세요. |
| 런타임 동기화 담당자 UDCA |
ApigeeEnvironment(CRD) | 구성을 통해 확장하려면 재정의 파일에서 udca, synchronizer, runtime 스탠자에 대한 replicaCountMin 속성 값을 늘립니다. 예를 들면 다음과 같습니다.
synchronizer: replicaCountMax: 10 replicaCountMin: 1 runtime: replicaCountMax: 10 replicaCountMin: 1 udca: replicaCountMax: 10 replicaCountMin: 1 참고: 이 변경사항은 재정의 파일의 모든 환경에 적용됩니다. 각 환경의 확장을 맞춤설정하려면 아래의 고급 구성을 참조하세요. 이 배포는 자동 확장에 수평형 포드 자동 확장 처리를 사용합니다. 배포 객체의 구성 속성 설정에 대한 자세한 내용은 런타임 영역 구성요소 관리를 참조하세요. |
고급 구성
일부 시나리오에서는 고급 확장 옵션을 사용해야 할 수도 있습니다. 시나리오의 예시는 다음과 같습니다.
- 환경별로 서로 다른 확장 옵션 설정. 예를 들어 env1의
minReplica가 5이고 env2의minReplica가 2인 경우입니다. - 환경 내의 각 구성요소에 서로 다른 확장 옵션 설정. 예를 들어
udca구성요소의maxReplica가 5이고synchronizer구성요소의maxReplica가 2인 경우입니다.
다음 예시에서는 kubernetes patch 명령어를 사용하여 runtime 구성요소의 maxReplicas 속성을 변경하는 방법을 보여줍니다.
- 다음 명령어와 함께 사용할 환경 변수를 만듭니다.
export ENV=my-environment-name export NAMESPACE=apigee #the namespace where apigee is deployed export COMPONENT=runtime #can be udca or synchronizer export MAX_REPLICAS=2 export MIN_REPLICAS=1
- 패치를 적용합니다. 이 예시에서는
kubectl이PATH에 있다고 가정합니다.kubectl patch apigeeenvironment -n $NAMESPACE \ $(kubectl get apigeeenvironments -n $NAMESPACE -o jsonpath='{.items[?(@.spec.name == "'$ENV'" )]..metadata.name}') \ --patch "$(echo -e "spec:\n components:\n $COMPONENT:\n autoScaler:\n maxReplicas: $MAX_REPLICAS\n minReplicas: $MIN_REPLICAS")" \ --type merge - 변경된 것을 확인합니다.
kubectl get hpa -n $NAMESPACE
측정항목 기반 확장
측정항목 기반 확장을 사용하면 런타임에서 CPU와 애플리케이션 측정항목을 사용하여 apigee-runtime 포드를 확장할 수 있습니다.
Kubernetes 수평형 포드 자동 확장 처리(HPA) API는 hpaBehavior 필드를 사용하여 대상 서비스의 수직 확장 동작과 축소 동작을 구성합니다.
하이브리드 배포의 다른 구성요소에는 측정항목 기반 확장을 사용할 수 없습니다.
다음 측정항목을 기준으로 확장을 조정할 수 있습니다.
| 측정항목 | 측정 | 고려사항 |
|---|---|---|
| serverNioTaskWaitTime | http 레이어에서 프록시 요청의 런타임 인스턴스에서 처리하는 큐의 평균 대기 시간(밀리초)입니다. | 이 측정항목은 프록시 요청 및 응답의 수와 페이로드 크기의 영향을 측정합니다. |
| serverMainTaskWaitTime | 프록시 요청이 정책을 처리할 수 있도록 런타임 인스턴스에서 처리하는 큐의 평균 대기 시간(밀리초)입니다. | 이 측정항목은 프록시 요청 흐름에 연결된 정책에서 복잡성의 영향을 측정합니다. |
overrides.yaml의 runtime 스탠자의 다음 예시에서는 하이브리드 구현에서 apigee-runtime 포드를 확장할 수 있는 표준 매개변수(및 허용 범위)를 보여줍니다.
hpaMetrics:
serverMainTaskWaitTime: 400M (300M to 450M)
serverNioTaskWaitTime: 400M (300M to 450M)
targetCPUUtilizationPercentage: 75
hpaBehavior:
scaleDown:
percent:
periodSeconds: 60 (30 - 180)
value: 20 (5 - 50)
pods:
periodSeconds: 60 (30 - 180)
value: 2 (1 - 15)
selectPolicy: Min
stabilizationWindowSeconds: 120 (60 - 300)
scaleUp:
percent:
periodSeconds: 60 (30 - 120)
value: 20 (5 - 100)
pods:
periodSeconds: 60 (30 - 120)
value: 4 (2 - 15)
selectPolicy: Max
stabilizationWindowSeconds: 30 (30 - 120)
더욱 적극적인 확장 구성
수직 확장 정책의 percent 값과 pods 값을 늘리면 더욱 적극적인 수직 확장 정책이 됩니다. 마찬가지로 scaleDown에서 percent 값과 pods 값을 늘리면 적극적인 축소 정책이 적용됩니다. 예를 들면 다음과 같습니다.
hpaMetrics:
serverMainTaskWaitTime: 400M
serverNioTaskWaitTime: 400M
targetCPUUtilizationPercentage: 75
hpaBehavior:
scaleDown:
percent:
periodSeconds: 60
value: 20
pods:
periodSeconds: 60
value: 4
selectPolicy: Min
stabilizationWindowSeconds: 120
scaleUp:
percent:
periodSeconds: 60
value: 30
pods:
periodSeconds: 60
value: 5
selectPolicy: Max
stabilizationWindowSeconds: 30
위 예시에서 scaleDown.pods.value는 5로, scaleUp.percent.value 는 30으로, scaleUp.pods.value는 5로 증가됩니다.
덜 적극적인 확장 구성
hpaBehavior 구성 값을 줄여 덜 적극적인 수직 확장 정책과 축소 정책을 구현할 수도 있습니다. 예를 들면 다음과 같습니다.
hpaMetrics:
serverMainTaskWaitTime: 400M
serverNioTaskWaitTime: 400M
targetCPUUtilizationPercentage: 75
hpaBehavior:
scaleDown:
percent:
periodSeconds: 60
value: 10
pods:
periodSeconds: 60
value: 1
selectPolicy: Min
stabilizationWindowSeconds: 180
scaleUp:
percent:
periodSeconds: 60
value: 20
pods:
periodSeconds: 60
value: 4
selectPolicy: Max
stabilizationWindowSeconds: 30
위 예시에서 scaleDown.percent.value는 10으로, scaleDown.pods.value는 1로, scaleUp.stablizationWindowSeconds는 180으로 감소됩니다.
hpaBehavior 필드를 사용하는 측정항목 기반 확장에 대한 자세한 내용은 확장 정책을 참조하세요.
측정항목 기반 확장 중지
기본적으로 측정항목 기반 확장은 사용 설정되어 있으며 완전히 중지할 수 없지만 측정항목 기반 확장이 트리거되지 않는 수준에서 측정항목 기준점을 구성할 수 있습니다. 결과 확장 동작은 CPU 기반 확장과 동일합니다. 예를 들어 다음 구성을 사용하여 측정항목 기반 확장을 트리거할 수 없습니다.
hpaMetrics:
serverMainTaskWaitTime: 4000M
serverNioTaskWaitTime: 4000M
targetCPUUtilizationPercentage: 75
hpaBehavior:
scaleDown:
percent:
periodSeconds: 60
value: 10
pods:
periodSeconds: 60
value: 1
selectPolicy: Min
stabilizationWindowSeconds: 180
scaleUp:
percent:
periodSeconds: 60
value: 20
pods:
periodSeconds: 60
value: 4
selectPolicy: Max
stabilizationWindowSeconds: 30
문제 해결
이 섹션에서는 확장과 자동 확장을 구성하는 동안 발생할 수 있는 일반적인 오류에 대한 문제 해결 방법을 설명합니다.
HPA에서는 측정항목 값에 unknown 표시
측정항목 기반 확장이 작동하지 않고 HPA에서 측정항목 값에 unknown을 표시하면 다음 명령어를 사용하여 HPA 출력을 확인합니다.
kubectl describe hpa HPA_NAME
명령어를 실행할 때 HPA_NAME을 보려는 HPA의 이름으로 바꿉니다.
출력에는 CPU 목표와 서비스 사용률이 표시되어 측정항목 기반 확장이 없을 때 CPU 확장이 작동할 것임을 나타냅니다. 여러 매개변수를 사용하는 HPA 동작은 여러 측정항목으로 확장을 참조하세요.