이 페이지에서는 Google Cloud 프로젝트, 클러스터, 노드에 대한 베어메탈용 GKE 출시 버전 1.16 할당량과 한도를 설명합니다.
한도
다음 섹션에서는 클러스터의 몇 가지 기본 한도를 간략히 설명합니다. 베어메탈용 GKE에서 실행되도록 애플리케이션을 설계할 때 이러한 한도를 고려하세요.
관리자 클러스터당 최대 사용자 클러스터
관리자 클러스터는 사용자 클러스터 및 연결된 노드의 수명 주기를 관리합니다. 관리자 클러스터는 클러스터 만들기, 클러스터 또는 노드 재설정, 클러스터 업그레이드, 클러스터 업데이트와 같은 중요한 사용자 클러스터 작업을 제어합니다. 사용자 클러스터 노드의 총 수는 성능과 안정성을 제한하는 기본 요소 중 하나입니다.
지속적인 테스트를 기반으로 관리자 클러스터는 노드 10개를 사용하는 최대 100개의 사용자 클러스터를 지원할 수 있어 총 1,000개의 노드를 안정적으로 지원할 수 있습니다.
사용자 클러스터당 최대 포드 수
사용자 클러스터당 포드 수는 15,000개 이하로 제한하는 것이 좋습니다. 예를 들어 클러스터에 노드가 200개 있으면 노드당 포드 수를 75개 이하로 제한해야 합니다. 마찬가지로 노드당 포드를 110개 실행하려면 클러스터의 노드 수를 136개 이하로 제한해야 합니다. 다음 표에서는 권장되거나 권장되지 않는 구성의 예시를 보여줍니다.
| 노드당 포드 | 클러스터당 노드 | 클러스터당 포드 | 결과 |
|---|---|---|---|
| 110 | 200 | 22,000 | 포드가 너무 많음, 권장되지 않음 |
| 110 | 136 | 14,960 | 한도 내 |
| 100 | 150 | 15,000 | 한도 내 |
| 75 | 200 | 15,000 | 한도 내 |
다음 섹션에서는 사용자 클러스터당 최대 포드 수 권장사항이 노드당 포드 수 권장사항과 사용자 클러스터당 노드 수 권장사항보다 우선 적용됩니다.
사용자 클러스터당 최대 노드 수
베어메탈용 GKE를 테스트하여 노드가 최대 500개 있는 워크로드를 실행합니다. 그러나 최적의 성능과 안정성을 보장하려면 프로덕션에서 워크로드를 실행할 때 클러스터당 노드가 200개를 초과하지 않는 것이 좋습니다.
| 클러스터 유형 | 최소 노드 | 권장 최대 노드 수 | 절대 최대 노드 수 |
|---|---|---|---|
| 사용자, 독립형 또는 하이브리드 | 1 | 200 | 500 |
단일 노드 클러스터의 경우 노드에서 워크로드를 실행하려면 node-role.kubernetes.io/master:NoSchedule taint를 삭제해야 합니다.
자세한 내용은 Kubernetes taint 및 톨러레이션(toleration)을 참조하세요.
노드당 최대 포드 수
베어메탈용 GKE는 클러스터 구성 파일의 nodeConfig.PodDensity.MaxPodsPerNode 설정에서 노드당 최대 포드 수를 구성할 수 있습니다. 다음 표에서는 부가기능 서비스를 실행하는 포드가 포함된 MaxPodsPerNode에 지원되는 최댓값과 최솟값을 보여줍니다.
| 클러스터 유형 | 최소 허용 값 | 권장 최댓값 | 최대 허용 값 |
|---|---|---|---|
| 모든 HA 클러스터 및 비 HA 사용자 클러스터 | 32 | 110 | 250 |
| 기타 모든 비 HA 클러스터 | 64 | 110 | 250 |
최대 엔드포인트 수
RHEL 및 CentOS에서는 클러스터 수준 제한이 엔드포인트 100,000개로 제한됩니다.
이 숫자는 Kubernetes 서비스에서 참조하는 모든 포드의 합계입니다.
두 서비스가 같은 포드 집합을 참조하는 경우 이 상황은 개별 엔드포인트 집합 두 개로 계산됩니다. RHEL 및 CentOS의 기본 nftable 구현으로 인해 이러한 제한이 발생합니다. 베어메탈용 GKE에 내재된 제한이 아닙니다.
위험 완화
RHEL 및 CentOS의 경우 완화가 없습니다. Ubuntu 및 Debian 시스템의 경우 대규모 클러스터의 기본 nftables에서 기존 iptables로 전환하는 것이 좋습니다.
Dataplane V2 eBPF 한도
Dataplane V2의 BPF lbmap에서 최대 항목 수는 65,536개입니다. 다음 영역에서 증가하면 총 항목 수가 증가할 수 있습니다.
- 서비스 수
- 서비스당 포트 수
- 서비스당 백엔드 수
한도를 초과하지 않도록 클러스터에서 사용하는 실제 항목 수를 모니터링하는 것이 좋습니다. 다음 명령어를 사용하여 현재 항목을 가져옵니다.
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
또한 자체 모니터링 파이프라인을 사용하여 anetd DaemonSet에서 측정항목을 수집하는 것이 좋습니다. 다음 조건을 모니터링하여 항목 수로 인해 문제가 발생하는 시기를 식별합니다.
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
LoadBalancer 및 NodePort 서비스 포트 한도
LoadBalancer 및 NodePort 서비스의 포트 한도는 2,768입니다. 기본 포트 범위는 30,000~32,767입니다. 이 한도를 초과하면 새 LoadBalancer 또는 NodePort 서비스를 만들 수 없으며 기존 서비스에 새 노드 포트를 추가할 수 없습니다.
기본적으로 Kubernetes는 노드 포트를 LoadBalancer 유형의 서비스에 할당합니다.
이러한 할당은 클러스터에 할당된 2,768개의 사용 가능한 노드 포트를 빠르게 소진할 수 있습니다. 노드 포트를 저장하려면 LoadBalancer 서비스 사양에서 allocateLoadBalancerNodePorts 필드를 false로 설정하여 부하 분산기 노드 포트 할당을 중지합니다. 이렇게 설정하면 Kubernetes에서 노드 포트를 LoadBalancer 서비스에 할당할 수 없습니다. 자세한 내용은 Kubernetes 문서의 부하 분산기 NodePort 할당 중지를 참조하세요.
다음 명령어를 사용하여 할당된 포트 수를 확인합니다.
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
번들 부하 분산기 노드 연결 한도
번들 부하 분산(MetalLB)에 사용되는 각 노드에 허용되는 연결 수는 28,000개입니다. 이러한 연결의 기본 임시 포트 범위는 32,768~60,999입니다. 연결 한도를 초과하면 LoadBalancer 서비스에 대한 요청이 실패할 수 있습니다.
상당한 연결 수(예: 인그레스)를 처리할 수 있는 부하 분산기 서비스를 노출해야 하는 경우 MetalLB에서 이러한 제한을 피하도록 대체 부하 분산 방법을 사용하는 것이 좋습니다.
클러스터 할당량
기본적으로 최대 15개의 클러스터를 등록할 수 있습니다. GKE 허브에 클러스터를 추가로 등록하려면 Google Cloud 콘솔에서 할당량 상향 요청을 제출하면 됩니다.
확장 문제
이 섹션에서는 클러스터를 확장할 때 주의해야 하는 몇 가지 문제에 대해 설명합니다.
시스템 데몬용으로 예약된 리소스
버전 1.14부터 베어메탈용 GKE는 sshd 또는 udev와 같이 시스템 데몬용으로 노드에서 리소스를 자동으로 예약합니다. CPU 및 메모리 리소스는 이러한 데몬에 필요한 리소스가 포함되도록 시스템 데몬용으로 노드에 예약됩니다. 기본적으로 사용 설정되는 이 기능을 사용하지 않으면 포드가 노드에서 잠재적으로 대부분의 리소스를 소비하여 시스템 데몬이 태스크를 완료하지 못할 수 있습니다.
특히 베어메탈용 GKE는 시스템 데몬용으로 각 노드에서 50밀리코어 CPU(50mCPU) 및 280메비바이트(280MiB) 메모리를 예약합니다. CPU 단위인 'mCPU'는 '코어의 1/1000'을 의미하므로, 각 노드에서 코어의 50/1000 또는 5%가 시스템 데몬용으로 예약됩니다. 예약된 리소스 양은 적으며 포드 성능에 큰 영향을 주지 않습니다. 그러나 해당 CPU 또는 메모리 사용이 할당된 양을 초과하면 노드에서 kubelet이 포드를 제거할 수 있습니다.
etcd 성능
디스크 속도는 etcd 성능과 안정성에서 매우 중요합니다. 느린 디스크에서는 etcd 요청 지연 시간이 증가하여 클러스터 안정성 문제가 발생할 수 있습니다. 클러스터 성능을 향상시키기 위해 베어메탈용 GKE는 이벤트 객체를 별도의 전용 etcd 인스턴스에 저장합니다. 표준 etcd 인스턴스는 /var/lib/etcd를 데이터 디렉터리로 사용하고 클라이언트 요청에 포트 2379를 사용합니다. etcd 이벤트 인스턴스는 /var/lib/etcd-events를 데이터 디렉터리로 사용하고 클라이언트 요청의 포트 2382를 사용합니다.
etcd 저장소에는 솔리드 스테이트 디스크(SSD)를 사용하는 것이 좋습니다. 최적의 성능을 위해 별도의 디스크를 /var/lib/etcd와 /var/lib/etcd-events에 마운트합니다. 전용 디스크를 사용하면 두 etcd 인스턴스가 디스크 IO를 공유하지 않습니다.
etcd 문서는 프로덕션에서 클러스터를 실행할 때 최상의 etcd 성능을 보장하는 추가 하드웨어 권장사항을 제공합니다.
etcd 및 디스크 성능을 확인하려면 측정항목 탐색기에서 다음 etcd I/O 지연 시간 측정항목을 사용합니다.
etcd_disk_backend_commit_duration_seconds: 기간이 99번째 백분위수(p99)에 대해 25밀리초 이내여야 합니다.etcd_disk_wal_fsync_duration_seconds: 기간이 99번째 백분위수(p99)에 대해 10밀리초 이내여야 합니다.
etcd 성능에 대한 자세한 내용은 etcd 경고 '항목 적용이 너무 오래 걸림'은 무슨 의미인가요? 및 etcd 경고 '정시에 하트비트를 전송하지 못함'은 무슨 의미인가요?를 참조하세요.
원하는 정보를 아직 못 찾으셨나요? 의견 보내기를 클릭하여 필요한 정보가 무엇인지 알려 주세요.