이 페이지에서는 대규모 클러스터를 계획하고 설계할 때 따를 수 있는 권장사항을 설명합니다.
대규모 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) 미만으로 유지합니다. |
|
| 모든 서비스 엔드포인트 수 | 모든 서비스의 엔드포인트 수가 한도에 도달할 수 있습니다. 이로 인해 프로그래밍 지연 시간이 늘거나 새 엔드포인트를 아예 프로그래밍하지 못할 수 있습니다. |
모든 서비스의 모든 엔드포인트 수를 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 사이입니다. 대용량 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 클러스터를 사용하여 위에 지정된 한도에 맞게 나눌 수 없는 리소스 수를 관리하는 것이 좋습니다. 자세한 내용은 구성 컨트롤러 확장성 가이드라인을 참고하세요. |