이 페이지에서는 대규모 클러스터를 계획하고 설계할 때 따를 수 있는 권장사항을 설명합니다.
대규모 GKE 클러스터를 계획하는 이유
Kubernetes를 포함한 모든 컴퓨터 시스템에는 아키텍처상의 몇 가지 한도가 있습니다. 이 한도를 초과하면 클러스터 성능에 영향을 주거나 다운타임이 발생할 수도 있습니다. 권장사항에 따라 권장 조치를 실행하여 클러스터가 규모에 맞춰 안정적으로 워크로드를 실행하도록 합니다.
대규모 GKE 클러스터의 제한사항
GKE가 클러스터를 다수의 노드로 확장할 때 GKE는 서비스 수준 목표(SLO)를 준수하면서 시스템 요구사항에 맞게 사용 가능한 리소스 양을 변경하기 위해 노력합니다.Google Cloud 는 대규모 클러스터를 지원합니다. 그러나 사용 사례에 따라 인프라 규모 요구사항에 더 효과적으로 대응하려면 대규모 클러스터의 제한사항을 고려해야 합니다.
이 섹션에서는 예상 노드 수를 기반으로 대규모 GKE 클러스터를 설계할 때의 제한사항과 고려사항을 설명합니다.
노드가 최대 5,000개인 클러스터
최대 5,000개 노드로 확장할 수 있는 클러스터 아키텍처를 설계할 때는 다음 조건을 고려하세요.
- 리전 클러스터에서만 사용할 수 있습니다.
- Private Service Connect를 사용하는 클러스터에서만 사용할 수 있습니다.
- 영역 클러스터에서 리전 클러스터로 마이그레이션하려면 클러스터를 다시 만들어야 더 높은 노드 할당량 수준을 이용할 수 있습니다.
클러스터를 5,000개 노드 이상으로 확장할 것으로 예상되면 Cloud Customer Care에 문의하여 클러스터 크기와 할당량 한도를 늘리세요.
노드가 5,000개 넘는 클러스터
GKE는 최대 15,000개 노드의 대규모 표준 클러스터를 지원합니다. 버전 1.31 이상에서 GKE는 최대 65,000개의 노드로 구성된 대규모 클러스터를 지원합니다. 65,000개의 한도는 대규모 AI 워크로드를 실행하는 데 사용됩니다.
클러스터를 15,000개 또는 65,000개 노드로 확장할 것으로 예상되는 경우 다음 태스크를 완료합니다.
다음 제한사항을 고려하세요.
- 클러스터 자동 확장 처리는 지원되지 않습니다. 대신 GKE API를 사용하여 노드 풀을 확장 또는 축소하세요.
- 멀티 네트워크는 지원되지 않습니다.
- 포드가 100개를 초과하는 서비스는 헤드리스여야 합니다.
- 모든 포드는 시스템 DaemonSet를 제외하고 자체 노드에서 실행되어야 합니다. 특정 노드에서 포드 예약을 정의하려면 Kubernetes 포드 어피니티 또는 안티어피니티를 사용하면 됩니다.
- 영역 클러스터에서 리전 클러스터로 마이그레이션하려면 클러스터를 다시 만들어야 더 높은 노드 할당량 수준을 이용할 수 있습니다.
- Private Service Connect를 사용하는 클러스터로 마이그레이션하려면 클러스터를 다시 만들어야 더 높은 노드 할당량 수준을 이용할 수 있습니다.
확장 요구사항에 따라 클러스터 크기 및 할당량 한도를 15,000개 노드 또는 65,000개 노드로 늘리려면 Cloud Customer Care에 문의하세요.
여러 클러스터 간에 워크로드를 분할하기 위한 권장사항
단일 대규모 클러스터에서 워크로드를 실행할 수 있습니다. 이 접근 방식은 여러 클러스터를 사용할 때보다 관리하기 쉽고 비용 효율적이며 리소스 사용률도 더 우수합니다. 하지만 워크로드를 여러 클러스터로 분할해야 하는 경우도 있습니다.
- 멀티 클러스터 사용 사례를 검토하여 여러 클러스터를 사용하는 경우의 일반적인 요구사항과 시나리오를 자세히 알아보세요.
- 또한 확장성 관점에서 아래 섹션에 설명된 한도 중 하나 또는 GKE 할당량 중 하나를 초과할 가능성이 있는 경우 클러스터를 분할합니다. GKE 한도에 도달할 수 있는 위험을 줄이면 다운타임이나 기타 신뢰성 문제가 발생할 위험이 줄어듭니다.
클러스터를 분할하기로 결정한 경우 Fleet 관리를 사용하여 멀티 클러스터 Fleet 관리를 간소화합니다.
한도 및 권장사항
아키텍처에서 대규모 GKE 클러스터를 지원하도록 하려면 다음 한도 및 관련 권장사항을 검토하세요. 이러한 한도를 초과하면 클러스터 성능 저하 또는 안정성 문제가 발생할 수 있습니다.
이러한 권장사항은 설치된 확장 프로그램이 없는 모든 기본 Kubernetes 클러스터에 적용됩니다. 웹훅이나 커스텀 리소스 정의(CRD)를 사용하여 Kubernetes 클러스터를 확장하는 것이 일반적이지만 클러스터 확장성이 제한될 수 있습니다.
다음 표는 기본 GKE 할당량 및 한도를 확장합니다. 또한 대규모 클러스터에 대한 오픈소스 Kubernetes 한도에 익숙해져야 합니다.
표에 나온 GKE 버전 요구사항은 노드와 제어 영역 모두에 적용됩니다.
| GKE 한도 | 설명 | 권장사항 |
|---|---|---|
| etcd 데이터베이스 크기 | etcd 데이터베이스의 최대 크기는 6GB입니다. 수만 개의 리소스가 포함된 초대형 클러스터를 실행하는 경우 etcd 인스턴스가 이 한도를 초과할 수 있습니다. Google Cloud 콘솔에서 클러스터의 사용률 수준을 확인할 수 있습니다. 한도에 도달한 후 24시간 이내에 특정 클러스터에 대한 권장사항이 표시됩니다. 자세한 내용은 etcd 사용량이 한도에 도달한 클러스터 식별을 참조하세요. | 이 한도를 초과하면 GKE에서 해당 etcd 인스턴스가 비정상으로 표시될 수 있습니다. 그 결과 클러스터 제어 영역이 응답하지 않습니다.
이 한도를 초과하면 Google Cloud 지원팀에 문의하세요. |
| 유형별 etcd 객체의 총 크기 | 제공된 리소스 유형의 모든 객체의 총 크기는 800MB를 초과해서는 안 됩니다. 예를 들어 750MB의 포드 인스턴스와 750MB의 보안 비밀을 만들 수 있지만 850MB의 보안 비밀은 만들 수 없습니다. 800MB 넘게 객체를 만들면 Kubernetes 또는 맞춤설정된 컨트롤러가 초기화되지 않아 중단이 발생할 수 있습니다. |
etcd에 저장되는 각 유형의 모든 객체의 총 크기를 800MB 아래로 유지하세요. 이러한 제한은 특히 많은 수의 크기가 큰 보안 비밀 또는 ConfigMap 또는 대용량 CRD를 사용하는 클러스터에 적용될 수 있습니다. |
| GKE Dataplane V2가 사용 설정되지 않은 클러스터의 서비스 수 | 다음 중 하나가 발생하면 kube-proxy에 사용되는 iptable 성능이 저하됩니다.
GKE Dataplane V2를 사용 설정하면 이 한도는 사라집니다. |
클러스터에서 서비스 수를 10,000 아래로 유지하세요. 자세한 내용은 서비스를 사용하여 애플리케이션 노출을 참조하세요. |
| 네임스페이스당 서비스 수 | 서비스에 대해 생성되는 환경 변수 수가 셸 한도를 초과할 수 있습니다. 이로 인해 시작 시 포드가 다운됩니다. |
네임스페이스당 서비스 수를 5,000 아래로 유지하세요. 환경 변수를 채우지 않도록 선택할 수 있습니다. PodSpec에서 자세한 내용은 서비스를 사용하여 애플리케이션 노출을 참조하세요. |
| GKE Dataplane V2가 사용 설정되지 않은 클러스터의 단일 서비스 이면의 포드 수 |
모든 노드에서 서비스 변경사항을 모니터링하기 위해 감시를 사용하는 kube-proxy가 실행됩니다. 클러스터가 클수록 에이전트에서 처리하는 변경 관련 데이터가 많습니다. 특히 노드가 500개를 초과하는 클러스터에서 볼 수 있습니다. 엔드포인트에 대한 정보는 개별 엔드포인트 객체는 계속 구성요소에 사용할 수 있지만 포드 1,000개를 초과하는 엔드포인트는 자동으로 잘립니다. |
단일 서비스 이면의 포드 수를 10,000개 미만으로 유지합니다. 자세한 내용은 서비스를 사용하여 애플리케이션 노출을 참조하세요. |
| GKE Dataplane V2가 사용 설정된 클러스터의 단일 서비스 이면의 포드 수 |
GKE Dataplane V2에는 단일 서비스에서 노출되는 포드 수에 대한 한도가 포함됩니다. GKE Dataplane V2를 사용할 때와 동일한 한도가 Autopilot 클러스터에 적용됩니다. |
GKE 1.23 이하에서는 단일 서비스 이면의 포드 수를 1,000개 미만으로 유지합니다. GKE 1.24 이상에서는 단일 서비스 이면의 포드 수를 10,000개 미만으로 유지합니다. 자세한 내용은 서비스를 사용하여 애플리케이션 노출을 참조하세요. |
| 헤드리스 서비스당 DNS 레코드 수 |
헤드리스 서비스당 DNS 레코드 수를 kube-dns의 경우 1,000개 미만, Cloud DNS의 경우 3,500개/2,000개(IPv4/IPv6) 미만으로 유지합니다. |
|
| 모든 서비스 엔드포인트 수 | 모든 서비스의 엔드포인트 수가 한도에 도달할 수 있습니다. 이로 인해 프로그래밍 지연 시간이 늘거나 새 엔드포인트를 아예 프로그래밍하지 못할 수 있습니다. |
모든 서비스의 모든 엔드포인트 수를 260,000개 미만으로 유지합니다. GKE Autopilot의 기본 데이터 영역인 GKE Dataplane V2는 현재 모든 서비스에서 엔드포인트가 260,000개로 제한된 eBPF 맵을 사용합니다. |
| 클러스터당 수평형 포드 자동 확장 처리 객체 수 |
각 수평형 포드 자동 확장 처리(HPA)는 15초마다 처리됩니다. HPA 객체가 300개를 초과하면 성능이 선형적으로 저하될 수 있습니다. |
HPA 객체 수를 이 한도 이내로 유지하세요. 그렇지 않으면 HPA 처리 빈도가 선형적으로 저하될 수 있습니다. 예를 들어 GKE 1.22에서 2,000개의 HPA가 있으면 단일 HPA가 1분 40초마다 다시 처리됩니다. 자세한 내용은 리소스 사용률에 따른 자동 확장 및 수평형 포드 자동 확장 확장성을 참조하세요. |
| 노드당 포드 수 | GKE에는 노드당 포드 256개라는 하드 한도가 있습니다. 단, 포드당 평균 컨테이너가 2개 이하인 것으로 가정합니다. 포드당 컨테이너 수를 늘리면 GKE가 컨테이너당 리소스를 더 할당하므로 이 한도가 줄어들 수 있습니다. |
10개의 포드당 vCPU가 최소 하나 이상인 워커 노드를 사용하는 것이 좋습니다. 자세한 내용은 클러스터 또는 노드 풀 수동 업그레이드를 참조하세요. |
| 포드 변경 비율 |
Kubernetes에는 확장 요청에 대한 응답으로 포드(포드 제거)를 만들거나 삭제하는 비율에 영향을 주는 내부 한도가 있습니다. 서비스의 일부인 포드 삭제와 같은 추가 요소도 이러한 포드 제거 비율에 영향을 줄 수 있습니다. 노드 수가 최대 500개인 클러스터의 경우 평균적으로 초당 포드 생성 비율은 20개, 초당 포드 삭제 비율은 20개입니다. 노드 수가 500개를 초과할 경우 평균적으로 초당 포드 생성 비율은 100개, 초당 포드 삭제 비율은 100개입니다. |
워크로드 확장 방법을 계획할 때 포드 생성 및 삭제 비율 한도를 고려하세요. 포드는 다른 리소스 유형과 동일한 삭제 처리량을 공유합니다(예: EndpointSlices). 서비스의 일부로 포드를 정의할 때 삭제 처리량을 줄일 수 있습니다. 클러스터 자동 확장 처리가 활용률이 낮은 노드에서 포드를 효과적으로 삭제할 수 있도록 하려면 PodDisruptionBudgets와 지나치게 긴 종료 시간 유예 기간을 피하는 것이 좋습니다. 와일드 카드 톨러레이션도 권장하지 않습니다. 삭제 중인 노드에 워크로드가 예약될 수 있기 때문입니다. |
| 열려 있는 감시 수 | 노드는 포드에 대해 구성하는 모든 보안 비밀 및 ConfigMaps에 대해 감시를 만듭니다. 모든 노드에서 생성되는 감시 조합의 총량에 따라 클러스터 컨트롤 플레인에 상당한 부하가 발생할 수 있습니다. 클러스터당 감시 수를 200,000개 넘게 설정하면 클러스터의 초기화 시간에 영향을 줄 수 있습니다. 이 문제로 인해 컨트롤 플레인이 자주 재시작될 수 있습니다. |
많은 수의 감시로 인해 발생하는 문제 가능성 및 심각도를 낮추도록 노드를 더 크게 정의하세요. 포드 밀도가 높을수록(노드를 더 크게 하고 개수를 줄일수록) 감시 수가 줄어들고 문제 심각도가 완화될 수 있습니다. 자세한 내용은 머신 시리즈 비교를 참조하세요. |
| 애플리케이션 레이어 보안 비밀 암호화가 사용 설정된 경우의 클러스터당 보안 비밀 수 | 애플리케이션 레이어 보안 비밀 암호화가 사용 설정되었으면 클러스터 시작 중 클러스터가 모든 보안 비밀을 복호화해야 합니다. 보안 비밀을 30,000개 넘게 저장하면 시작 또는 업그레이드 중 클러스터가 불안정해져 워크로드가 중단될 수 있습니다. | 애플리케이션 레이어 보안 비밀 암호화를 사용할 때 보안 비밀을 30,000개 미만으로 저장하세요. 자세한 내용은 애플리케이션 레이어에서 보안 비밀 암호화를 참조하세요. |
| 노드당 로그 대역폭 |
각 노드에서 Cloud Logging API로 전송되는 최대 로그 양에는 한도가 있습니다. 기본 한도는 부하에 따라 100Kbps에서 500Kbps 사이입니다. Standard 클러스터의 경우 높은 처리량의 Logging 에이전트 구성을 배포하여 한도를 10MiB로 늘릴 수 있습니다. 이 한도를 초과하면 로그 항목이 삭제될 수 있습니다. |
기본 한도 이내로 유지되도록 Logging을 구성하거나 처리량이 높은 Logging 에이전트를 구성합니다. 자세한 내용은 로그 처리량 조정을 참조하세요. |
| Backup for GKE 한도 |
Backup for GKE를 사용하여 GKE 워크로드를 백업 및 복원할 수 있습니다. Backup for GKE에는 백업 계획을 정의할 때 주의해야 하는 한도가 적용됩니다. |
Backup for GKE 한도를 검토하세요. 워크로드가 이러한 한도를 초과할 가능성이 있는 경우 백업을 여러 개 만들어 파티션을 나누고 한도를 초과하지 않게 하는 것이 좋습니다. |
| 구성 커넥터 한도 |
구성 커넥터를 사용하여 Kubernetes를 통해 Google Cloud 리소스를 관리할 수 있습니다. 구성 커넥터에는 두 가지 작업 모드가 있습니다. 모드마다 확장성 특성 및 제한사항이 다릅니다. |
리소스 한도에 대한 자세한 내용은 구성 컨트롤러 확장성 가이드라인을 참조하세요. 다수의 리소스를 관리하는 방법은 구성 커넥터 권장사항을 참조하세요. |