이 페이지에서는 대규모 클러스터를 계획하고 설계할 때 따를 수 있는 권장사항을 설명합니다.
대규모 GKE 클러스터를 계획하는 이유
Kubernetes를 포함한 모든 컴퓨터 시스템에는 아키텍처상의 몇 가지 한도가 있습니다. 이 한도를 초과하면 클러스터 성능에 영향을 주거나 다운타임이 발생할 수도 있습니다. 권장사항에 따라 권장 조치를 실행하여 클러스터가 규모에 맞춰 안정적으로 워크로드를 실행하도록 합니다.
여러 클러스터 간 워크로드 분할 권장사항
하나의 큰 클러스터에서 워크로드를 실행할 수 있습니다. 이 접근 방식은 여러 클러스터를 사용할 때보다 관리하기 쉽고 비용 효율적이며 리소스 사용률도 더 우수합니다. 하지만 워크로드를 여러 클러스터로 분할해야 하는 경우도 있습니다.
- 멀티 클러스터 사용 사례를 검토하여 여러 클러스터를 사용하는 경우의 일반적인 요구사항과 시나리오를 자세히 알아보세요.
- 또한 확장성 관점에서 아래 섹션에 설명된 한도 중 하나 또는 GKE 할당량 중 하나를 초과할 가능성이 있는 경우 클러스터를 분할합니다. GKE 한도에 도달할 위험을 낮추면 다운타임 또는 기타 안정성 문제의 위험을 줄일 수 있습니다.
클러스터를 분할하기로 결정한 경우 Fleet 관리를 사용하여 멀티 클러스터 Fleet 관리를 간소화합니다.
한도 및 권장사항
아키텍처에서 대규모 GKE 클러스터를 지원하도록 하려면 다음 한도 및 관련 권장사항을 검토하세요. 이러한 한도를 초과하면 클러스터 성능 저하 또는 안정성 문제가 발생할 수 있습니다.
이러한 권장사항은 설치된 확장 프로그램이 없는 모든 기본 Kubernetes 클러스터에 적용됩니다. 웹훅 또는 커스텀 리소스 정의(CRD)를 사용하여 Kubernetes 클러스터를 확장하는 것이 일반적이지만 클러스터 확장성을 제한할 수 있습니다.
다음 표는 기본 GKE 할당량 및 한도를 확장합니다. 또한 대규모 클러스터에 대한 오픈소스 Kubernetes 한도에 익숙해져야 합니다.
표에 나온 GKE 버전 요구사항은 노드와 제어 영역 모두에 적용됩니다.
| GKE 한도 | 설명 | 권장사항 |
|---|---|---|
| etcd 데이터베이스 크기 | etcd 데이터베이스의 최대 크기는 6GB입니다. 수만 개의 리소스가 포함된 초대형 클러스터를 실행하는 경우 etcd 인스턴스가 이 한도를 초과할 수 있습니다. Google Cloud 콘솔에서 클러스터의 사용률 수준을 확인할 수 있습니다. | 이 한도를 초과하면 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) 미만으로 유지합니다. |
|
| 모든 서비스 엔드포인트 수 | 모든 서비스의 엔드포인트 수가 한도에 도달할 수 있습니다. 이로 인해 프로그래밍 지연 시간이 늘거나 새 엔드포인트를 아예 프로그래밍하지 못할 수 있습니다. |
모든 서비스의 모든 엔드포인트 수를 64,000개 미만으로 유지합니다. GKE의 기본 데이터 영역인 GKE Dataplane V2는 현재 모든 서비스에서 엔드포인트가 64,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와 지나치게 긴 종료 시간 유예 기간을 피하는 것이 좋습니다. 와일드 카드 톨러레이션(toleration)도 삭제 중인 노드에 워크로드를 예약할 수 있으므로 권장하지 않습니다. |
| 열려 있는 감시 수 | 노드는 포드에 대해 구성하는 모든 보안 비밀 및 ConfigMaps에 대해 감시를 만듭니다. 모든 노드에서 생성되는 감시 조합의 총량에 따라 클러스터 제어 영역에 상당한 부하가 발생할 수 있습니다. 클러스터당 감시 수를 200,000개 넘게 설정하면 클러스터의 초기화 시간에 영향을 줄 수 있습니다. 이 문제로 인해 제어 영역이 자주 재시작될 수 있습니다. |
많은 수의 감시로 인해 발생하는 문제 가능성 및 심각도를 낮추도록 노드를 더 크게 정의하세요. 포드 밀도가 높을수록(노드를 더 크게 하고 개수를 줄일수록) 감시 수가 줄어들고 문제 심각도가 완화될 수 있습니다. 자세한 내용은 머신 시리즈 비교를 참조하세요. |
| 애플리케이션 레이어 보안 비밀 암호화가 사용 설정된 경우의 클러스터당 보안 비밀 수 | 애플리케이션 레이어 보안 비밀 암호화가 사용 설정되었으면 클러스터 시작 중 클러스터가 모든 보안 비밀을 복호화해야 합니다. 보안 비밀을 30,000개 넘게 저장하면 시작 또는 업그레이드 중 클러스터가 불안정해져 워크로드가 중단될 수 있습니다. | 애플리케이션 레이어 보안 비밀 암호화를 사용할 때 보안 비밀을 30,000개 미만으로 저장하세요. 자세한 내용은 애플리케이션 레이어에서 보안 비밀 암호화를 참조하세요. |
| 노드당 로그 대역폭 |
각 노드에서 Cloud Logging API로 전송되는 최대 로그 양에는 한도가 있습니다. 기본 한도는 부하에 따라 100Kbps에서 500Kbps 사이입니다. 대용량 Logging 에이전트 구성을 배포하여 10Mbps로 한도를 늘릴 수 있습니다. 이 한도를 초과하면 로그 항목이 삭제될 수 있습니다. |
기본 한도 이내로 유지되도록 Logging을 구성하거나 처리량이 높은 Logging 에이전트를 구성합니다. 자세한 내용은 Logging 에이전트 처리량 증가를 참조하세요. |
| Backup for GKE 한도 |
Backup for GKE를 사용하여 GKE 워크로드를 백업 및 복원할 수 있습니다. Backup for GKE에는 백업 계획을 정의할 때 주의해야 하는 한도가 적용됩니다. |
Backup for GKE 한도를 검토하세요. 워크로드가 이러한 한도를 초과할 가능성이 있는 경우 백업을 여러 개 만들어 파티션을 나누고 한도를 초과하지 않게 하는 것이 좋습니다. |
| 구성 커넥터 한도 |
구성 커넥터를 사용하여 Kubernetes를 통해 Google Cloud 리소스를 관리할 수 있습니다. 구성 커넥터에는 두 가지 작업 모드가 있습니다. 모드마다 확장성 특성 및 제한사항이 다릅니다. |
각 구성 커넥터 인스턴스에는 CPU 요청 0.1개와 메모리 한도 512MB가 있습니다. 따라서 다수의 관리형 리소스까지 제대로 확장되지 않습니다. 단일 구성 커넥터 인스턴스당 Google Cloud 리소스는 25,000개를 초과하지 않는 것이 좋습니다. 이 제한은 리소스 유형 및 특정 사용 사례에 따라 사용되는 메모리 양이 달라지기 때문에 참조용으로만 사용됩니다. 다수의 관리형 리소스를 관리할 때는 네임스페이스 모드를 사용하여 각 구성 커넥터 인스턴스에서 처리되는 리소스 수를 제한하는 것이 좋습니다. 네임스페이스 모드에서 구성 커넥터로 최대 500개까지 네임스페이스를 사용하는 것이 좋습니다.
각 구성 커넥터 인스턴스는 kube-apiserver에 대한 다수의 watch 연결을 엽니다. 이러한 인스턴스가 많으면 watch 연결을 다시 초기화해야 하는 경우 특히 제어 영역 업그레이드 중 GKE 클러스터 제어 영역에 과부하가 발생할 수 있습니다. 다수의 GKE 클러스터를 사용하여 위에 지정된 한도에 맞게 나눌 수 없는 리소스 수를 관리하는 것이 좋습니다. 자세한 내용은 구성 컨트롤러 확장성 가이드라인을 참조하세요. |