버전 1.6. 이 버전은 Anthos 버전 지원 정책에 설명된 대로 지원되며 VMware용 Anthos 클러스터(GKE On-Prem)에 영향을 미치는 보안 취약점, 노출, 문제에 대한 최신 패치와 업데이트를 제공합니다. 자세한 내용은 출시 노트를 참조하세요. 이 버전은 최신 버전이 아닙니다.

확장성

이 페이지에서는 Kubernetes 확장성 한도에 접근하는 워크로드를 수용하기 위해 Anthos clusters on VMware(GKE On-Prem) 클러스터를 만들고 구성하고 관리하기 위한 권장사항에 대해 설명합니다.

확장성 한도

Anthos clusters on VMware에서 애플리케이션을 설계할 때 다음 한도를 고려하세요.

  • 각 관리자 클러스터는 고가용성(HA) 및 비 HA 사용자 클러스터를 포함하여 최대 20개의 사용자 클러스터를 지원합니다.

  • 각 사용자 클러스터가 지원하는 최대 한도는 다음과 같습니다.

  • 노드별로 최대 110개의 Pod를 만들 수 있습니다(각 Pod는 1~2개의 컨테이너로 구성 가능). 여기에는 부가기능 서비스를 실행하는 Pod가 포함됩니다.

한도 이해하기

Anthos clusters on VMware는 대규모 통합 영역이 있는 복잡한 시스템이므로 클러스터 확장성에는 서로 연관된 여러 측정기준이 포함됩니다. 예를 들어 Anthos clusters on VMware는 노드 수, Pod 수 또는 서비스 수를 통해 확장할 수 있습니다. 한 번에 2개 이상의 측정기준을 늘리면 소규모 클러스터에서도 부담으로 작용해 문제를 일으킬 수 있습니다. 예를 들어 250 노드 클러스터에서 노드당 110개의 Pod 수를 예약하면 Pod 수, 노드당 Pod 수, 노드 수를 늘릴 수 있습니다.

자세한 내용은 Kubernetes 확장성 기준점을 참조하세요.

확장성 한도는 클러스터가 실행 중인 vSphere 구성 및 하드웨어에도 민감합니다. 이 한도는 개발자 환경과 다를 수 있는 환경에서 확인됩니다. 따라서 기본 환경이 제한 요인인 경우 정확한 숫자를 재현하지 않을 수 있습니다.

확장 준비

확장을 준비할 때 vSphere 인프라, Kubernetes 네트워킹, GKE 허브, Cloud Logging 및 Cloud Monitoring의 요구사항과 제한사항을 고려하세요.

vSphere 인프라

이 섹션에서는 노드 IP 주소뿐 아니라 CPU, 메모리, 스토리지, 디스크, 네트워크 I/O 요구사항의 확장성 고려사항을 설명합니다.

CPU, 메모리, 스토리지 요구사항

제어 영역 VM에는 다음 요구사항이 적용됩니다.

  • 관리 클러스터 제어 영역과 부가기능 노드는 HA 및 비 HA 사용자 클러스터를 포함하여 최대 20개의 사용자 클러스터를 지원할 수 있습니다. 따라서 관리자 클러스터에 대한 미세 조정은 필요하지 않습니다.

  • 기본 사용자 클러스터 제어 영역 VM 구성(CPU 4개, 메모리 8GB, 40GB 스토리지)은 사용자 클러스터에서 최대 250개의 노드를 실행하는 데 필요한 최소 설정입니다.

각 개별 VM의 CPU, RAM, 스토리지 요구사항을 참조하세요.

디스크 및 네트워크 I/O 요구사항

데이터 집약적 워크로드 및 특정 제어 영역 구성요소는 디스크 및 네트워크 I/O 지연 시간에 민감합니다. 예를 들어 500개의 순차적 IOPS(예: 일반 로컬 SSD 또는 고성능 가상 블록 기기)는 일반적으로 수십 개의 노드와 수천 개의 Pod가 있는 클러스터에서 etcd의 성능과 안정성에 필요합니다.

노드 IP 주소

각 Anthos clusters on VMware 노드에는 DHCP 또는 고정으로 할당된 IP 주소가 1개 필요합니다.

예를 들어 노드가 50개인 비 HA 사용자 클러스터 1개와 노드가 250개인 HA 사용자 클러스터 1개로 구성된 설정에는 308개의 IP 주소가 필요합니다. 다음 표에서는 IP 주소의 분석을 보여줍니다.

노드 유형 IP 주소 수
관리자 클러스터 제어 영역 VM 1
관리자 클러스터 부가기능 노드 VM 3
사용자 클러스터 1(비 HA) 제어 영역 VM 1
사용자 클러스터 1 노드 VM 50
사용자 클러스터 2(HA) 제어 영역 VM 3
사용자 클러스터 2 노드 VM 250
합계 308

Kubernetes 네트워킹

이 섹션에서는 pod CIDR 블록과 Kubernetes 서비스의 확장성 고려사항을 설명합니다.

pod CIDR 블록

pod CIDR 블록은 사용자 클러스터의 모든 pod에 대한 CIDR 블록입니다. 이 범위에서 노드당 더 작은 /24 블록이 할당됩니다. N개의 노드 클러스터가 필요한 경우 /C가 N개의 /24 블록을 지원할 만큼 큰지 확인해야 합니다.

다음 표에서는 서로 다른 pod CIDR 블록 크기에서 지원되는 최대 노드 수를 설명합니다.

pod CIDR 블록 크기 지원되는 최대 노드 수
/19 32
/18 64
/17 128
/16 256

기본 pod CIDR 블록은 256개의 노드를 지원하는 192.168.0.0/16입니다. 기본 Pod CIDR 블록을 사용하면 노드가 250개인 클러스터를 만들 수 있습니다. 이는 Anthos clusters on VMware가 사용자 클러스터에서 지원하는 최대 노드 수입니다.

Kubernetes 서비스

이 섹션에서는 서비스 CIDR 블록과 부하 분산기의 확장성 고려사항을 설명합니다.

서비스 CIDR 블록

서비스 CIDR 블록은 사용자 클러스터의 모든 서비스에 대한 CIDR 블록입니다. 이 섹션에서 설명하는 서비스는 LoadBalancer 유형의 Kubernetes 서비스를 참조합니다.

다음 표에서는 서로 다른 서비스 CIDR 블록 크기에서 지원하는 최대 서비스 수를 설명합니다.

서비스 CIDR 블록 크기 지원되는 최대 서비스 수
/20 4,096
/19 8,192
/18 16,384

기본값은 10.96.0.0/12, 1,048,576 서비스를 지원합니다. 기본 서비스 CIDR 블록을 사용하면 500개의 서비스가 포함된 클러스터를 만들 수 있습니다. 이는 Anthos clusters on VMware가 사용자 클러스터에서 지원하는 최대 서비스 수입니다.

부하 분산기

클러스터의 노드 수와 부하 분산기에서 구성할 수 있는 서비스 수에 제한이 있습니다.

번들 부하 분산 (Seesaw)의 경우 상태 확인 수에도 제한이 있습니다. 상태 확인 수는 노드 수와 트래픽 로컬 서비스 수에 따라 다릅니다. 트래픽 로컬 서비스는 externalTrafficPolicy가 Local로 설정된 서비스입니다.

다음 표에서는 번들 부하 분산(Seesaw) 및 통합 부하 분산(F5)의 서비스, 노드, 상태 확인의 최대 수에 대해 설명합니다.

번들 부하 분산(Seesaw) 통합 부하 분산(F5)
최대 서비스 수 500 250 2
최대 노드 수 250 250 2
최대 상태 확인 N + (L * N) <= 10K, 여기서 N은 노드 수, L은 트래픽 로컬 서비스 수 1 해당 사항 없음 2

1 예를 들어 노드가 100개이고 트래픽 로컬 서비스가 99개라고 가정합시다. 그러면 상태 확인 수는 100 + 99 * 100 = 10,000개이며, 이는 10K 한도 이내입니다.

2 자세한 내용은 F5를 참조하세요. 이 수는 F5 하드웨어 모델 번호, 가상 인스턴스 CPU/메모리, 라이선스 등과 같은 요인의 영향을 받습니다.

GKE 허브

기본적으로 최대 15개의 사용자 클러스터를 등록할 수 있습니다. GKE 허브에 클러스터를 추가로 등록하려면 Cloud Console에서 할당량 상향 요청을 제출하세요.

Cloud Logging 및 Cloud Monitoring

Cloud LoggingCloud Monitoring은 리소스를 추적하는 데 유용합니다.

하나의 사용자 클러스터에서 많은 노드 실행

사용자 클러스터에 배포된 클러스터 내 에이전트의 CPU 및 메모리 사용량은 사용자 클러스터의 노드 및 pod 수에 따라 확장됩니다.

prometheus-server, stackdriver-prometheus-sidecar, stackdriver-log-aggregator 같은 Cloud Logging 및 모니터링 구성요소는 노드 수와 Pod 수에 따라 CPU 및 메모리 리소스 사용량이 서로 다릅니다. 클러스터를 수직 확장하기 전 이러한 구성요소의 예상 평균 사용량에 따라 리소스 요청 및 한도를 설정합니다. 다음 표에서는 각 구성요소의 예상 평균 사용량을 보여줍니다.

노드 수 컨테이너 이름 예상 CPU 사용량 예상 메모리 사용량
노드당 Pod 0개 노드당 Pod 30개 노드당 Pod 0개 노드당 Pod 30개
3 ~ 50 stackdriver-log-aggregator 150m 170m 1.6G 1.7G
prometheus-server 100m 390m 650M 1.3G
stackdriver-prometheus-sidecar 100m 340m 1.5G 1.6G
51 ~ 100 stackdriver-log-aggregator 220m 1100m 1.6G 1.8G
prometheus-server 160m 500m 1.8G 5.5G
stackdriver-prometheus-sidecar 200m 500m 1.9G 5.7G
101 ~ 250 stackdriver-log-aggregator 450m 1800m 1.7G 1.9G
prometheus-server 400m 2500m 6.5G 16G
stackdriver-prometheus-sidecar 400m 1300m 7.5G 12G

Cloud Logging 및 Cloud Monitoring 구성요소를 예약할 수 있는 노드가 충분한지 확인하세요. 먼저 작은 클러스터를 만든 후 위 표에 따라 Cloud Logging 및 Cloud Monitoring 구성요소 리소스를 수정하고 구성요소를 수용하도록 노드 풀을 만든 다음에 클러스터를 더 큰 크기로 점진적으로 확장합니다.

다른 Pod가 노드 풀에 예약되지 않도록 Logging 및 Monitoring 구성요소에 충분한 노드 풀을 유지하도록 선택할 수 있습니다. 이렇게 하려면 다음 taint를 노드 풀에 추가해야 합니다.

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

이렇게 하면 다른 구성요소가 노드 풀에 예약되지 않고 Monitoring 구성요소의 리소스 소비로 인해 사용자 워크로드가 삭제되지 않습니다.

하나의 관리자 클러스터에서 많은 사용자 클러스터 실행

관리자 클러스터에 배포된 Logging 및 Monitoring 구성요소의 CPU 및 메모리 사용량은 사용자 클러스터 수에 따라 확장됩니다.

다음 표에서는 많은 수의 사용자 클러스터를 실행하는 데 필요한 관리자 클러스터 노드 CPU 및 메모리 양을 설명합니다.

사용자 클러스터 수 관리자 클러스터 노드 CPU 관리자 클러스터 노드 메모리
0 ~ 10 CPU 4개 16GB
11 ~ 20 CPU 4개 32GB

예를 들어 관리자 클러스터 노드가 2개이고 각각 4개의 CPU와 16GB의 메모리가 있는 경우 0~10개의 사용자 클러스터를 실행할 수 있습니다. 10개 초과의 사용자 클러스터를 만들려면 먼저 관리 클러스터 노드 메모리의 크기를 16GB에서 32GB로 조정해야 합니다.

관리자 클러스터 노드의 메모리를 변경하려면 MachineDeployment 구성을 수정하세요.

  1. 다음 명령어를 실행합니다.

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    여기서 ADMIN_CLUSTER_KUBECONFIG는 관리자 클러스터의 kubeconfig 파일 경로입니다.

  2. spec.template.spec.providerSpec.value.machineVariables.memory 필드를 32768로 변경합니다.

  3. 수정사항을 저장합니다. 관리 클러스터 노드는 32GB 메모리를 사용하여 다시 생성됩니다.

Dataplane V2

Dataplane V2를 사용하는 500 노드 클러스터의 경우 제어 영역에 대해 120GB 메모리, 32개 CPU 코어가 권장됩니다.

자동 확장 시스템 구성요소

Anthos clusters on VMware는 구성을 변경할 필요 없이 노드 수에 따라 클러스터의 시스템 구성요소를 자동으로 확장합니다. 이 섹션의 정보를 리소스 계획용으로 사용할 수 있습니다.

  • Anthos clusters on VMware는 addon-resizer를 사용하여 다음 시스템 구성요소의 CPU 및 메모리 요청/한도를 확장하여 수직 확장을 자동으로 수행합니다.

    • kube-state-metrics는 Kubernetes API 서버를 리슨하고 객체 상태에 대한 측정항목을 생성하는 클러스터 워커 노드에서 실행되는 배포입니다. CPU 및 메모리 요청 및 한도는 노드 수에 따라 확장됩니다.

      다음 표에서는 클러스터의 노드 수를 기준으로 시스템에서 설정한 리소스 요청/한도를 설명합니다.

      노드 수 대략적인1 CPU 요청/한도(밀리) 대략적인1 메모리 요청/한도(Mi)
      3 ~ 5 105 110
      6 ~ 250 100 + num_nodes 100 + (2 * num_nodes)

      1 크기 조정 도중 구성요소 재시작 수를 줄이기 위해 +-5% 의 여백이 있습니다.

      예를 들어 노드가 50개인 클러스터에서 CPU 요청/한도는 150m/150m으로 설정되고 메모리 요청/한도는 200Mi/200Mi로 설정됩니다. 노드가 250개인 클러스터에서 CPU 요청/한도는 350m/350m으로 설정되고 메모리 요청/한도는 600Mi로 설정됩니다.

    • metrics-server는 Kubernetes 기본 제공 자동 확장 파이프라인에서 사용하는 클러스터 워커 노드에서 실행되는 배포입니다.

  • Anthos clusters on VMware는 다음 시스템 구성요소의 복제본 수를 확장하여 수평 확장을 자동으로 수행합니다.

    • kube-dns는 Anthos clusters on VMware에서 서비스 검색에 사용되는 DNS 솔루션입니다. 이는 사용자 클러스터 워커 노드에서 배포로 실행됩니다. Anthos clusters on VMware는 클러스터의 노드 수와 CPU 코어 수에 따라 복제본 수를 자동으로 확장합니다. 노드 16개 또는 코어 256개가 추가/삭제될 때마다 복제본 1개가 증가/감소됩니다. 노드가 N개이고 코어가 C개인 클러스터가 있는 경우 최대(N/16, C/256) 복제본을 예상할 수 있습니다. kube-dns는 초당 1500개의 동시 요청 수를 지원하기 위해 Anthos clusters on VMware 1.4 이후로 업데이트되었습니다.

    • calico-typha는 Anthos clusters on VMware에서 Pod 네트워킹을 지원하는 구성요소입니다. 이는 사용자 클러스터 워커 노드에서 배포로 실행됩니다. Anthos clusters on VMware는 클러스터의 노드 수에 따라 복제본 수를 자동으로 확장합니다. 노드가 200개 미만인 클러스터에는 calico-typha 복제본 1개가 있고 노드가 200개 이상인 클러스터에는 복제본 2개가 있습니다.

    • ingress-gateway/istio-pilot은 클러스터 인그레스를 지원하는 구성요소이며 사용자 클러스터 워커 노드에서 배포로 실행됩니다. 인그레스 게이트웨이가 처리하는 트래픽 양에 따라 Anthos clusters on VMware는 수평형 Pod 자동 확장 처리를 사용하여 CPU 사용량에 따라 복제본 수를 최소 2개, 최대 5개로 확장합니다.

권장사항

이 섹션에서는 리소스 확장을 위한 권장사항을 설명합니다.

단계별로 클러스터 확장

Kubernetes 노드를 만들려면 노드 OS 이미지 템플릿을 I/O 집약적 vSphere 작업인 새 디스크 파일로 클론해야 합니다. 클론 작업과 워크로드 I/O 작업 간에 I/O 격리가 없습니다. 동시에 생성되는 노드가 너무 많으면 클론 작업은 완료하는 데 시간이 오래 걸리고 클러스터 및 기존 워크로드의 성능과 안정성에 영향을 줄 수 있습니다.

vSphere 리소스에 따라 클러스터의 스테이지가 단계적으로 조정되었는지 확인하세요. 예를 들어 클러스터 크기를 노드 3개에서 250개로 늘리려면 vSphere에서 80 ~ 160 ~ 250개로 단계별로 확장해 vSphere 인프라에서의 부하를 줄이는 것이 좋습니다.

etcd 디스크 I/O 성능 최적화

etcd는 모든 클러스터 데이터의 Kubernetes 보조 기억장치로 사용되는 키-값 저장소입니다. 성능 및 안정성은 클러스터의 상태에 매우 중요하며 디스크 및 네트워크 I/O 지연 시간에 민감합니다.

  • 다음 권장사항에 따라 제어 영역 VM에 사용되는 vSphere Datastore의 I/O 성능을 최적화하세요.

  • 수백 밀리초의 지연 시간은 디스크 또는 네트워크 I/O의 병목 현상을 나타내며 비정상적인 클러스터로 이어질 수 있습니다. 다음과 같은 etcd I/O 지연 시간 측정항목의 알림 임곗값을 모니터링하고 설정합니다.

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

노드 부팅 디스크 I/O 성능 최적화

pod는 임시 파일 저장과 같은 내부 작업에 임시 스토리지를 사용합니다. 임시 저장소는 컨테이너의 쓰기 가능한 레이어, 로그 디렉터리, emptyDir 볼륨에서 사용됩니다. 임시 스토리지는 노드의 부팅 디스크에서 지원하는 Anthos clusters on VMware 노드의 파일 시스템에서 제공됩니다.

Kubernetes 노드에는 저장소 I/O 격리가 없으므로 임시 스토리지에서 극도로 높은 I/O를 소비하는 애플리케이션은 Kubelet나 docker 데몬 같은 시스템 구성요소가 리소스를 받지 못하게 되어 노드 불안정성을 야기할 가능성이 있습니다.

부팅 디스크가 프로비저닝되는 Datastore의 I/O 성능 특성이 애플리케이션의 임시 스토리지 및 로깅 트래픽 사용에 적합한 성능을 제공할 수 있도록 하세요.

물리적 리소스 경합 모니터링

vCPU-pCPU 비율메모리 오버커밋에 유의해야 합니다. 물리적 호스트의 최적화되지 않은 비율 또는 메모리 경합은 VM 성능 저하를 초래할 수 있습니다. 호스트 수준에서 물리적 리소스 사용률을 모니터링하고 대규모 클러스터를 실행하기에 충분한 리소스를 할당해야 합니다.