이 페이지에서는 Kubernetes 확장성 한도에 접근하는 워크로드를 수용하도록 Google Distributed Cloud 클러스터를 생성, 구성, 운영하기 위한 권장사항을 설명합니다.
클러스터 이름 규칙
Google Cloud 프로젝트별로 다음과 같은 조건이 있습니다.
- 각 사용자 클러스터의 이름은 단일 Google Cloud 프로젝트 내에 있는 모든 관리 클러스터에서 고유해야 합니다.
확장성 한도
VMware용 GKE에서 애플리케이션을 설계할 때 다음 한도를 고려합니다.
각 관리자 클러스터는 번들 부하 분산 모드(Seesaw 또는 MetalLB) 또는 통합 부하 분산 모드(F5)를 사용하여 고가용성(HA) 및 비HA 사용자 클러스터를 포함하여 최대 100개의 사용자 클러스터를 지원합니다.
각 사용자 클러스터가 지원하는 최대 한도는 다음과 같습니다.
번들 부하 분산 모드(Seesaw 또는 MetalLB)를 사용하는 노드 500개 또는 통합 부하 분산 모드(F5)를 사용하는 노드 250개
포드 15,000개
번들 부하 분산 모드(Seesaw 또는 MetalLB)를 사용하는 LoadBalancer 서비스 500개 또는 통합 부하 분산 모드(F5)를 사용하는 LoadBalancer 서비스 250개
노드별로 최대 110개의 포드를 만들 수 있습니다(각 포드는 1~2개의 컨테이너로 구성 가능). 여기에는 부가기능 서비스를 실행하는 포드가 포함됩니다.
한도 이해하기
VMware용 GKE는 통합 표면이 넓은 복잡한 시스템이므로 클러스터 확장성에는 서로 연관된 여러 측정기준이 포함됩니다. 예를 들어 VMware용 GKE는 노드나 포드, 서비스의 수를 통해 확장될 수 있습니다. 한 번에 2개 이상의 측정기준을 늘리면 소규모 클러스터에서도 부담으로 작용해 문제를 일으킬 수 있습니다. 예를 들어 500 노드 클러스터에서 노드당 110개의 포드 수를 예약하면 포드 수, 노드당 포드 수, 노드 수를 늘릴 수 있습니다.
자세한 내용은 Kubernetes 확장성 기준점을 참조하세요.
확장성 한도는 클러스터가 실행 중인 vSphere 구성 및 하드웨어에도 민감합니다. 이 한도는 개발자 환경과 다를 수 있는 환경에서 확인됩니다. 따라서 기본 환경이 제한 요인인 경우 정확한 숫자를 재현하지 않을 수 있습니다.
확장 준비
관리자 클러스터 또는 사용자 클러스터 확장을 준비할 때 다음 요구사항 및 제한사항을 고려하세요.
CPU, 메모리, 스토리지 요구사항
각 개별 VM의 CPU, RAM, 스토리지 요구사항을 참조하세요.
디스크 및 네트워크 I/O 요구사항
데이터 집약적 워크로드 및 특정 제어 영역 구성요소는 디스크 및 네트워크 I/O 지연 시간에 민감합니다. 예를 들어 500개의 순차적 IOPS(예: 일반 로컬 SSD 또는 고성능 가상 블록 기기)는 일반적으로 수십 개의 노드와 수천 개의 포드가 있는 클러스터에서 etcd의 성능과 안정성에 필요합니다.
노드 IP 주소
각 VMware용 GKE 노드에는 DHCP 또는 정적으로 할당된 IP 주소가 하나 필요합니다.
예를 들어 노드가 50개인 비 HA 사용자 클러스터 1개와 노드가 250개인 HA 사용자 클러스터 1개로 구성된 설정에는 307개의 IP 주소가 필요합니다.
다음 표에서는 IP 주소의 분석을 보여줍니다.
| 노드 유형 | IP 주소 수 |
|---|---|
| 관리자 클러스터 제어 영역 VM | 3 |
| 사용자 클러스터 1(비 HA) 제어 영역 VM | 1 |
| 사용자 클러스터 1 워커 노드 VM | 50 |
| 사용자 클러스터 2(HA) 제어 영역 VM | 3 |
| 사용자 클러스터 2 워커 노드 VM | 250 |
| 합계 | 307 |
하나의 관리자 클러스터에서 많은 사용자 클러스터 실행
관리자 클러스터에서 많은 사용자 클러스터의 실행을 준비하므로 관리자 클러스터를 만들 때 다음 단계를 수행합니다.
관리자 클러스터의 포드 CIDR 블록
포드 CIDR 블록은 관리자 클러스터의 모든 포드에 대한 CIDR 블록입니다. 이는 admin-cluster.yaml의 network.podCIDR 필드를 통해 구성됩니다.
이 범위에서 노드당 더 작은 /24 블록이 할당됩니다. 모든 사용자 클러스터에 Controlplane V2가 사용 설정되었으면 관리자 클러스터에는 3개의 노드만 포함되며 사용 가능한 포드 IP 주소가 충분합니다. 하지만 Controlplane V2 대신 kubeception을 사용하는 사용자 클러스터를 만들 때마다 하나 또는 세 개의 노드가 관리자 클러스터에 추가됩니다.
각 고가용성(HA) kubeception 사용자 클러스터는 관리자 클러스터에 노드 3개를 추가합니다.
HA가 아닌 각 kubeception 사용자 클러스터는 관리자 클러스터에 노드 하나를 추가합니다.
N개의 노드 클러스터가 필요한 경우 포드 CIDR 블록이 N개의 /24 블록을 지원할 만큼 커야 합니다.
다음 표에서는 서로 다른 포드 CIDR 블록 크기에서 지원되는 최대 노드 수를 설명합니다.
| 포드 CIDR 블록 크기 | 지원되는 최대 노드 수 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
관리자 클러스터의 기본 포드 CIDR 블록은 256개의 노드를 지원하는 192.168.0.0/16입니다.
HA kubeception 사용자 클러스터 100개가 있는 관리자 클러스터에는 관리자 클러스터 제어 영역 노드 3개와 사용자 클러스터 제어 영역 노드 300개가 있습니다. 총 노드 수는 256개를 넘는 303개입니다. 따라서 최대 100개의 HA kubeception 사용자 클러스터를 지원하려면 포드 CIDR 블록을 /15로 업데이트해야 합니다.
포드 CIDR 블록을 구성하려면 관리자 클러스터 구성 파일에서 network.podCIDR 필드를 설정합니다.
관리자 클러스터의 서비스 CIDR 블록
서비스 CIDR 블록은 관리자 클러스터의 모든 서비스에 대한 CIDR 블록입니다.
이는 admin-cluster.yaml의 network.serviceCIDR 필드를 통해 구성됩니다.
다음 표에서는 서로 다른 서비스 CIDR 블록 크기에서 지원하는 최대 서비스 수를 설명합니다.
| 서비스 CIDR 블록 크기 | 지원되는 최대 서비스 수 |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
기본값은 10.96.232.0/24이며 256개의 서비스를 지원합니다.
각 kubeception 사용자 클러스터는 6개의 서비스를 사용하고 관리자 클러스터 제어 영역은 14개의 서비스를 사용합니다. 따라서 kubeception 사용자 클러스터 100개를 실행하려면 /22 범위를 사용하도록 관리자 클러스터의 서비스 CIDR 블록을 변경해야 합니다.
Cloud Logging 및 Cloud Monitoring
Cloud Logging 및 Cloud Monitoring은 리소스를 추적하는 데 유용합니다.
관리자 클러스터에 배포된 Logging 및 Monitoring 구성요소의 CPU 및 메모리 사용량은 kubeception 사용자 클러스터 수에 따라 확장됩니다.
다음 표에서는 많은 수의 kubeception 사용자 클러스터를 실행하는 데 필요한 관리자 클러스터 노드 CPU 및 메모리 양을 설명합니다.
| kubeception 사용자 클러스터 수 | 관리자 클러스터 노드 CPU | 관리자 클러스터 노드 메모리 |
|---|---|---|
| 0 ~ 10 | CPU 4개 | 16GB |
| 11 ~ 20 | CPU 4개 | 32GB |
| 20 ~ 100 | CPU 4개 | 90GB |
예를 들어 관리자 클러스터 노드가 2개이고 각각 4개의 CPU와 16GB의 메모리가 있는 경우 0~10개의 kubeception 사용자 클러스터를 실행할 수 있습니다. 20개가 넘는 kubeception 사용자 클러스터를 만들려면 먼저 관리자 클러스터 노드 메모리의 크기를 16GB에서 90GB로 조정해야 합니다.
GKE 허브
기본적으로 최대 15개의 사용자 클러스터를 등록할 수 있습니다.
GKE 허브에 클러스터를 추가로 등록하려면 Google Cloud Console에서 할당량 상향 요청을 제출하세요.
사용자 클러스터에서 여러 노드 및 포드 실행
사용자 클러스터에서 여러 노드와 포드의 실행을 준비하므로 사용자 클러스터를 만들 때 다음 단계를 수행하세요.
사용자 클러스터의 포드 CIDR 블록
포드 CIDR 블록은 사용자 클러스터의 모든 포드에 대한 CIDR 블록입니다. 이는 user-cluster.yaml의 network.podCIDR 필드를 통해 구성됩니다.
이 범위에서는 각 노드에 더 작은 /24 블록이 할당됩니다. N개의 노드 클러스터가 필요한 경우 /C가 N개의 /24 블록을 지원할 만큼 큰지 확인해야 합니다.
다음 표에서는 서로 다른 포드 CIDR 블록 크기에서 지원되는 최대 노드 수를 설명합니다.
| 포드 CIDR 블록 크기 | 지원되는 최대 노드 수 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
기본 포드 CIDR 블록은 256개의 노드를 지원하는 192.168.0.0/16입니다. 예를 들어 노드가 500개인 클러스터를 만들려면 사용자 클러스터의 포드 CIDR 블록을 /15 범위를 사용하도록 변경해야 합니다.
사용자 클러스터의 서비스 CIDR 블록
서비스 CIDR 블록은 사용자 클러스터의 모든 서비스에 대한 CIDR 블록입니다. 이는 user-cluster.yaml의 network.serviceCIDR 필드를 통해 구성됩니다.
다음 표에서는 서로 다른 서비스 CIDR 블록 크기에서 지원하는 최대 서비스 수를 설명합니다.
| 서비스 CIDR 블록 크기 | 지원되는 최대 서비스 수 |
|---|---|
| /21 | 2,048 |
| /20 | 4,096 |
| /19 | 8,192 |
| /18 | 16,384 |
사용자 클러스터 제어 영역 노드
사용자 클러스터 제어 영역 구성요소의 메모리 사용량은 사용자 클러스터의 노드 수에 따라 확장됩니다.
다음 표에서는 사용자 클러스터 크기에 따라 사용자 클러스터 제어 영역 노드에 필요한 CPU와 메모리를 보여줍니다.
| 사용자 클러스터 노드 수 | 제어 영역 노드 CPU | 제어 영역 노드 메모리 |
|---|---|---|
| 0~20 | CPU 3개 | 5GB |
| 21~75 | CPU 3개 | 6GB |
| 76~250 | CPU 4개 | 8GB |
| 251~500 | CPU 4개 | 16GB |
예를 들어 사용자 클러스터에서 250개가 넘는 노드를 만들려면 최소 16GB의 메모리를 사용하는 사용자 클러스터 제어 영역 노드를 사용해야 합니다.
사용자 클러스터 제어 영역 노드 사양은 user-cluster.yaml의 masterNode 필드를 통해 변경할 수 있습니다.
Dataplane v2
Dataplans V2를 사용하는 500-노드 사용자 클러스터의 경우 사용자 클러스터 제어 영역 노드에 120GB의 메모리와 32개의 CPU 코어를 사용하는 것이 좋습니다.
Cloud Logging 및 Cloud Monitoring
Cloud Logging 및 Cloud Monitoring은 리소스를 추적하는 데 유용합니다.
사용자 클러스터에 배포된 클러스터 내 에이전트의 CPU 및 메모리 사용량은 사용자 클러스터의 노드 및 포드 수에 따라 확장됩니다.
prometheus-server, stackdriver-prometheus-sidecar와 같은 Cloud Logging 및 모니터링 구성요소는 노드 수와 포드 수에 따라 CPU 및 메모리 리소스 사용량이 다릅니다. 클러스터를 수직 확장하기 전 이러한 구성요소의 예상 평균 사용량에 따라 리소스 요청 및 한도를 설정합니다. 다음 표에서는 각 구성요소의 예상 평균 사용량을 보여줍니다.
| 노드 수 | 컨테이너 이름 | 예상 CPU 사용량 | 예상 메모리 사용량 | ||
|---|---|---|---|---|---|
| 노드당 포드 0개 | 노드당 포드 30개 | 노드당 포드 0개 | 노드당 포드 30개 | ||
| 3 ~ 50 | prometheus-server | 100m | 390m | 650M | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 340m | 1.5G | 1.6G | |
| 51 ~ 100 | prometheus-server | 160m | 500m | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200m | 500m | 1.9G | 5.7G | |
| 101 ~ 250 | prometheus-server | 400m | 2500m | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400m | 1300m | 7.5G | 12G | |
| 250 ~ 500 | prometheus-server | 1200m | 2600m | 22G | 25G |
| stackdriver-prometheus-sidecar | 400m | 2250m | 65G | 78G | |
Cloud Logging 및 Cloud Monitoring 구성요소를 예약할 수 있는 노드가 충분한지 확인하세요. 먼저 작은 클러스터를 만든 후 위 표에 따라 Cloud Logging 및 Cloud Monitoring 구성요소 리소스를 수정하고 구성요소를 수용하도록 노드 풀을 만든 다음에 클러스터를 더 큰 크기로 점진적으로 확장합니다.
다른 포드가 노드 풀에 예약되지 않도록 Logging 및 Monitoring 구성요소에 충분한 노드 풀을 유지하도록 선택할 수 있습니다. 이렇게 하려면 다음 taint를 노드 풀에 추가해야 합니다.
taints:
- effect: NoSchedule
key: node-role.gke.io/observability이렇게 하면 다른 구성요소가 노드 풀에 예약되지 않고 Monitoring 구성요소의 리소스 소비로 인해 사용자 워크로드가 삭제되지 않습니다.
부하 분산기
이 섹션에서 설명하는 서비스는 LoadBalancer 유형의 Kubernetes 서비스를 참조합니다.
클러스터의 노드 수와 부하 분산기에서 구성할 수 있는 서비스 수에 제한이 있습니다.
번들 부하 분산 (Seesaw)의 경우 상태 확인 수에도 제한이 있습니다. 상태 확인 수는 노드 수와 트래픽 로컬 서비스 수에 따라 다릅니다. 트래픽 로컬 서비스는 externalTrafficPolicy가 Local로 설정된 서비스입니다.
다음 표에서는 번들 부하 분산(Seesaw) 및 통합 부하 분산(F5)의 서비스, 노드, 상태 확인의 최대 수에 대해 설명합니다.
| 번들 부하 분산(Seesaw) | 통합 부하 분산(F5) | |
|---|---|---|
| 최대 서비스 수 | 500 | 250 2 |
| 최대 노드 수 | 500 | 250 2 |
| 최대 상태 확인 | N + (L * N) <= 10K, 여기서 N은 노드 수, L은 트래픽 로컬 서비스 수 1 | 해당 사항 없음 2 |
1 예를 들어 노드가 100개이고 트래픽 로컬 서비스가 99개라고 가정합시다. 그러면 상태 확인 수는 100 + 99 * 100 = 10,000개이며, 이는 10K 한도 이내입니다.
2 자세한 내용은 F5를 참조하세요. 이 수는 F5 하드웨어 모델 번호, 가상 인스턴스 CPU/메모리, 라이선스 등과 같은 요인의 영향을 받습니다.
자동 확장 시스템 구성요소
VMware용 GKE는 구성을 변경할 필요 없이 노드 수에 따라 사용자 클러스터의 시스템 구성요소를 자동으로 확장합니다. 이 섹션의 정보를 리소스 계획용으로 사용할 수 있습니다.
VMware용 GKE는 addon-resizer를 사용하여 다음 시스템 구성요소의 CPU 및 메모리 요청/한도를 확장하여 수직 확장을 자동으로 수행합니다.
kube-state-metrics는 Kubernetes API 서버를 리슨하고 객체 상태에 대한 측정항목을 생성하는 클러스터 워커 노드에서 실행되는 배포입니다. CPU 및 메모리 요청 및 한도는 노드 수에 따라 확장됩니다.
다음 표에서는 클러스터의 노드 수를 기준으로 시스템에서 설정한 리소스 요청/한도를 설명합니다.
노드 수 대략적인1 CPU 요청/한도(밀리) 대략적인1 메모리 요청/한도(Mi) 3 ~ 5 105 110 6 ~ 500 100 + num_nodes 100 + (2 * num_nodes) 1 크기 조정 도중 구성요소 재시작 수를 줄이기 위해 +-5% 의 여백이 있습니다.
예를 들어 노드가 50개인 클러스터에서 CPU 요청/한도는 150m/150m으로 설정되고 메모리 요청/한도는 200Mi/200Mi로 설정됩니다. 노드가 250개인 클러스터에서 CPU 요청/한도는 350m/350m으로 설정되고 메모리 요청/한도는 600Mi로 설정됩니다.
metrics-server는 Kubernetes 기본 제공 자동 확장 파이프라인에서 사용하는 클러스터 워커 노드에서 실행되는 배포입니다. CPU 및 메모리 요청 및 한도는 노드 수에 따라 확장됩니다.
VMware용 GKE는 다음 시스템 구성요소의 복제본 수를 확장하여 관리자 클러스터와 사용자 클러스터 모두에서 수평 확장을 자동으로 수행합니다.
core-dns는 VMware용 GKE에서 서비스 검색에 사용되는 DNS 솔루션입니다. 이는 사용자 클러스터 워커 노드에서 배포로 실행됩니다. VMware용 GKE는 클러스터의 노드 수와 CPU 코어 수에 따라 복제본 수를 자동으로 확장합니다. 노드 16개 또는 코어 256개가 추가/삭제될 때마다 복제본 1개가 증가/감소됩니다. 클러스터의 노드가
N개이고 코어가C개 있다면max(N/16, C/256)개의 복제본을 예상할 수 있습니다.calico-typha는 VMware용 GKE에서 포드 네트워킹을 지원하는 구성요소입니다. 이는 사용자 클러스터 워커 노드에서 배포로 실행됩니다. VMware용 GKE는 클러스터의 노드 수를 기준으로 calico-typha 복제본 수를 자동으로 확장합니다.
노드 수(N) calico-typha 복제본 수 N = 1 1 1 < N < 200 2 N >= 200 3개 이상 Istio 인그레스-게이트웨이는 클러스터 인그레스를 지원하는 구성요소이며 사용자 클러스터 워커 노드에서 배포로 실행됩니다. 인그레스-게이트웨이에서 처리하는 트래픽 양에 따라 VMware용 GKE는 수평형 포드 자동 확장 처리를 사용하여 CPU 사용량을 기준으로 복제본 수를 최소 2개에서 최대 5개까지 확장합니다.
konnectivity 네트워크 프록시(KNP)는 외부 클러스터 제어 영역 노드로부터 이그레스에 대한 TCP 수준 프록시를 제공합니다. 사용자 클러스터 노드에 도달하는 사용자 kube-apiserver 이그레싱 트래픽을 터널링합니다. Konnectivity 에이전트는 사용자 클러스터 작업자 노드에서 배포로 실행됩니다. Google Distributed Cloud는 클러스터의 노드 수를 기준으로 konnectivity 에이전트 복제본 수를 자동으로 확장합니다.
노드 수(N) konnectivity 에이전트 복제본 수 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12개 이상
권장사항
이 섹션에서는 리소스 확장을 위한 권장사항을 설명합니다.
단계별로 클러스터 확장
Kubernetes 노드를 만들려면 노드 OS 이미지 템플릿을 I/O 집약적 vSphere 작업인 새 디스크 파일로 클론해야 합니다. 클론 작업과 워크로드 I/O 작업 간에 I/O 격리가 없습니다. 동시에 생성되는 노드가 너무 많으면 클론 작업은 완료하는 데 시간이 오래 걸리고 클러스터 및 기존 워크로드의 성능과 안정성에 영향을 줄 수 있습니다.
vSphere 리소스에 따라 클러스터의 스테이지가 단계적으로 조정되었는지 확인하세요. 예를 들어 클러스터 크기를 노드 3개에서 500개로 늘리려면 150 ~ 350 ~ 500개로 단계별로 확장해 vSphere 인프라에서의 부하를 줄이는 것이 좋습니다.
etcd 디스크 I/O 성능 최적화
etcd는 모든 클러스터 데이터의 Kubernetes 보조 기억장치로 사용되는 키-값 저장소입니다. 성능 및 안정성은 클러스터의 상태에 매우 중요하며 디스크 및 네트워크 I/O 지연 시간에 민감합니다.
다음 권장사항에 따라 제어 영역 VM에 사용되는 vSphere Datastore의 I/O 성능을 최적화하세요.
- etcd 하드웨어 요구사항을 따릅니다.
- SSD 또는 모든 플래시 스토리지를 사용합니다.
수백 밀리초의 지연 시간은 디스크 또는 네트워크 I/O의 병목 현상을 나타내며 비정상적인 클러스터로 이어질 수 있습니다. 다음과 같은 etcd I/O 지연 시간 측정항목의 알림 임곗값을 모니터링하고 설정합니다.
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
노드 부팅 디스크 I/O 성능 최적화
포드는 임시 파일 저장과 같은 내부 작업에 임시 스토리지를 사용합니다. 임시 저장소는 컨테이너의 쓰기 가능한 레이어, 로그 디렉터리, emptyDir 볼륨에서 사용됩니다. 임시 스토리지는 노드의 부팅 디스크에서 지원하는 VMware용 GKE 노드의 파일 시스템에서 제공됩니다.
Kubernetes 노드에는 저장소 I/O 격리가 없으므로 임시 스토리지에서 극도로 높은 I/O를 소비하는 애플리케이션은 Kubelet나 docker 데몬 같은 시스템 구성요소가 리소스를 받지 못하게 되어 노드 불안정성을 야기할 가능성이 있습니다.
부팅 디스크가 프로비저닝되는 Datastore의 I/O 성능 특성이 애플리케이션의 임시 스토리지 및 로깅 트래픽 사용에 적합한 성능을 제공할 수 있도록 하세요.
물리적 리소스 경합 모니터링
vCPU-pCPU 비율 및 메모리 오버커밋에 유의해야 합니다. 물리적 호스트의 최적화되지 않은 비율 또는 메모리 경합은 VM 성능 저하를 초래할 수 있습니다. 호스트 수준에서 물리적 리소스 사용률을 모니터링하고 대규모 클러스터를 실행하기에 충분한 리소스를 할당해야 합니다.