이 페이지에서는 여러 GKE 클러스터에서 대규모 워크로드를 관리할 때 따를 수 있는 권장사항에 대해 설명합니다. 이 권장사항에서는 여러 프로젝트에 워크로드를 분산하고 필요한 할당량을 조정할 때의 고려사항을 다룹니다.
여러 Google Cloud 프로젝트에 GKE 워크로드를 분산하기 위한 권장사항
Google Cloud 프로젝트 구조와 GKE 워크로드 분산을 효과적으로 정의하려면 비즈니스 요구사항에 따라 다음과 같은 설계 및 계획 작업을 고려하는 것이 좋습니다.
- 클라우드 리소스 관리 권장사항에 따라 조직의 폴더 및 프로젝트 구조에 대한 초기 결정을 내립니다. Google Cloud에서는 폴더 및 프로젝트와 같은 리소스 계층 구조 요소를 사용하여 자체 조직 경계 또는 액세스 정책을 기반으로 워크로드를 분할할 것을 권장합니다.
- 프로젝트 할당량으로 인해 워크로드를 분할해야 하는지 고려합니다. Google Cloud는 프로젝트별 할당량을 사용해서 공유 리소스 사용을 제한합니다. 아래 설명된 권장사항을 따라 대규모 워크로드의 프로젝트 할당량을 조정해야 합니다. 대부분의 워크로드는 단일 프로젝트에서 필요한 더 많은 할당량을 받아야 합니다. 즉, 할당량이 워크로드를 여러 프로젝트 간에 분할하기 위한 주요 동인이 아니어야 합니다. 워크로드를 소규모 프로젝트 개수로 유지하면 할당량 및 워크로드 관리가 간소화됩니다.
- 대규모 워크로드(CPU 수십만 개 이상의 규모)를 실행할 계획인지 고려합니다. 이 경우 워크로드를 여러 프로젝트로 분할하면 클라우드 리소스(예: CPU 또는 GPU)의 가용성이 향상될 수 있습니다. 이는 영역 가상화의 최적화된 구성을 사용하기 때문입니다. 이러한 경우 계정 관리자에게 문의해서 특수 지원 및 권장사항을 확인합니다.
대규모 GKE 워크로드의 할당량 조정 권장사항
이 섹션에서는 GKE 워크로드에 사용되는 Google Cloud에 대해 할당량을 조정하기 위한 가이드라인을 설명합니다. 다음 가이드라인에 따라 프로젝트 할당량을 조정하세요. Google Cloud 콘솔을 사용하여 할당량을 관리하는 방법은 할당량 작업을 참조하세요.
Compute Engine 할당량 및 권장사항
Autopilot 및 표준 모드에서 실행되는 GKE 클러스터는 Compute Engine 리소스를 사용하여 워크로드를 실행합니다. Google Cloud에서 내부적으로 관리되는 Kubernetes 제어 영역 리소스와 반대로 워크플로에 사용되는 Compute Engine 할당량을 관리하고 평가할 수 있습니다.
리소스 및 API 모두 Compute Engine 할당량은 동일 프로젝트 또는 리전에 호스팅된 모든 GKE 클러스터에서 공유됩니다. 동일한 할당량이 다른(GKE와 관련되지 않은) Compute Engine 리소스(독립형 VM 인스턴스 또는 인스턴스 그룹)와도 공유됩니다.
기본 할당량 값은 수백 개의 워커 노드를 지원할 수 있고 큰 워크로드의 경우 조정이 필요합니다. 그러나 플랫폼 관리자는 GKE 클러스터에 충분한 리소스가 포함되도록 Compute Engine 할당량을 사전에 조정할 수 있습니다. 또한 할당량 값을 평가 또는 조정할 때 이후의 리소스 니즈도 고려해야 합니다.
GKE 워커 노드에 사용되는 Compute Engine 리소스 할당량
다음 표에서는 GKE 워커 노드에 사용되는 가장 일반적인 Compute Engine 리소스에 대한 리소스 할당량을 보여줍니다. 이러한 할당량은 프로젝트 및 리전별로 구성됩니다. 할당량에는 워크로드에 사용되는 GKE 워커 노드의 최대 조합 크기 및 GKE와 관련되지 않은 기타 Compute Engine 리소스가 포함되어야 합니다.
| 리소스 할당량 | 설명 |
|---|---|
| CPU | 모든 클러스터의 모든 워커 노드에 사용되는 CPU 수입니다. |
| CPU 유형 | 모든 클러스터의 모든 워커 노드에 사용되는 각 특정 유형의 CPU 수입니다. |
| VM 인스턴스 | 모든 워커 노드의 수입니다. 이 할당량은 자동으로 CPU 수의 10배로 계산됩니다. |
| VPC 네트워크당 인스턴스 | VPC 네트워크에 연결된 모든 워커 노드 수입니다. |
| Persistent Disk 표준(GB) | 모든 워커 노드에 연결된 표준 영구 부팅 디스크의 총 크기입니다. |
| Persistent Disk SSD(GB) | 모든 워커 노드에 연결된 SSD 영구 부팅 디스크의 총 크기입니다. |
| 로컬 SSD(GB) | 모든 워커 노드에 연결된 로컬 SSD 이페머럴 디스크의 총 크기입니다. |
또한 GPU, IP 주소, 선점형 리소스와 같이 워크로드에 필요할 수 있는 리소스에 사용되는 할당량을 조정해야 합니다.
Compute Engine API 호출 할당량
대규모 또는 확장 가능한 클러스터에는 더 많은 수의 Compute Engine API 호출이 필요합니다. GKE는 다음과 같은 활동 중에 이러한 Compute Engine API 호출을 수행합니다.
- 컴퓨팅 리소스의 상태 확인
- 클러스터에 대한 새 노드 추가 또는 삭제
- 새 노드 풀 추가 또는 삭제
- 정기적인 리소스 라벨 지정
대규모 클러스터 아키텍처를 계획할 때는 다음을 수행하는 것이 좋습니다.
- 이전 할당량 소비를 관측합니다.
- 합리적인 버퍼 수준을 유지하면서 필요에 따라 할당량을 조정합니다. 다음 권장사항을 시작 지점으로 참조해서 워크로드 니즈에 맞게 할당량을 조정할 수 있습니다.
- 할당량은 리전별로 구성되므로 대규모 워크로드를 실행하려는 리전에서만 할당량을 조정하세요.
다음 표에서는 Compute Engine API 호출의 할당량을 보여줍니다. 이러한 할당량은 각 리전과 독립적으로 프로젝트별로 구성됩니다. 할당량은 동일한 프로젝트 및 동일한 리전에 호스팅된 모든 GKE 클러스터에서 공유됩니다.
| API 할당량 | 설명 | 권장사항 |
|---|---|---|
| 리전별 분당 쿼리 | 이러한 호출은 GKE에서 다양한 컴퓨팅 리소스 상태에 대해 다양한 검사를 수행하는 데 사용됩니다. |
수백 개의 동적 노드가 있는 프로젝트 및 리전의 경우 이 값을 3,500으로 조정합니다. 수천 개의 매우 동적인 노드가 있는 프로젝트 및 리전의 경우 이 값을 6,000으로 조정합니다. |
| 리전별 분당 읽기 요청 | 이러한 호출은 GKE에서 VM 인스턴스(노드)의 상태를 모니터링하는 데 사용됩니다. |
수백 개의 노드가 있는 프로젝트 및 리전의 경우 이 값을 12,000으로 조정하세요. 수천 개의 노드가 있는 프로젝트 및 리전의 경우 이 값을 20,000으로 조정하세요. |
| 리전별 분당 List 요청 수 | 이러한 호출은 GKE에서 인스턴스 그룹(노드 풀)의 상태를 모니터링하는 데 사용됩니다. |
수백 개의 동적 노드가 있는 프로젝트 및 리전의 경우 기본값이면 충분하므로 변경하지 마세요. 매우 동적인 노드가 수천 개 있는 프로젝트 및 리전의 경우 여러 노드 풀에서 이 값을 2,500으로 조정하세요. |
| 리전별 분당 인스턴스 목록 리퍼러 요청 | 이러한 호출은 GKE에서 VM 인스턴스(노드) 실행에 대한 정보를 얻기 위해 사용됩니다. |
수천 개의 동적 노드가 있는 프로젝트 및 리전의 경우 이 값을 6,000으로 조정하세요. |
| 리전별 분당 작업 읽기 요청 수 | 이러한 호출은 GKE에서 진행 중인 Compute Engine API 작업에 대한 정보를 가져오는 데 사용됩니다. |
고도로 동적 노드가 수천 개 있는 프로젝트와 리전의 경우 이 값을 3,000으로 조정하세요. |
Cloud Logging API 및 Cloud Monitoring API 할당량 및 권장사항
클러스터 구성에 따라 GKE 클러스터에서 실행되는 대규모 워크로드는 많은 양의 진단 정보를 발생시킬 수 있습니다. Cloud Logging API 또는 Cloud Monitoring API 할당량을 초과하면 로깅 및 모니터링 데이터가 손실될 수 있습니다. 로그의 세부정보 수준을 구성하고 생성된 진단 정보를 캡처하도록 Cloud Logging API 및 Cloud Monitoring API 할당량을 조정하는 것이 좋습니다. Prometheus용 관리형 서비스가 Cloud Monitoring 할당량을 사용합니다.
모든 워크로드가 서로 다르기 때문에 다음을 수행하는 것이 좋습니다.
- 이전 할당량 소비를 관측합니다.
- 필요에 따라 할당량 또는 로깅 및 모니터링 구성을 조정합니다. 예기치 않은 문제에 대비해 버퍼를 합리적으로 유지합니다.
다음 표에서는 Cloud Logging API 및 Cloud Monitoring API 호출의 할당량을 보여줍니다. 이러한 할당량은 프로젝트별로 구성되고 동일 프로젝트에서 호스팅되는 모든 GKE 클러스터에서 공유됩니다.
| 서비스 | 할당량 | 설명 | 권장사항 |
|---|---|---|---|
| Cloud Logging API | 분당 쓰기 요청 | GKE는 Cloud Logging에 저장된 로그 파일에 항목을 추가할 때 이 할당량을 사용합니다. |
로그 삽입 비율은 클러스터의 포드로 생성되는 로그 양에 따라 달라집니다. 포드 수, 애플리케이션 로깅의 세부정보 수준, 로깅 구성에 따라 할당량을 늘립니다. 자세한 내용은 GKE 로그 관리를 참조하세요. |
| Cloud Monitoring API | 분당 시계열 수집 요청 |
GKE는 Prometheus 측정항목을 Cloud Monitoring으로 전송할 때 이 할당량을 사용합니다.
|
이 할당량을 적절하게 모니터링하고 조정하세요. 자세한 내용은 GKE 측정항목 관리를 참조하세요. |
GKE 노드 할당량 및 권장사항
GKE에서는 기본 할당량이 5,000개 노드로 설정된 단일 클러스터에서 노드를 최대 15,000개까지 지원합니다. 이 할당량은 프로젝트마다 다른 할당량이 아닌 GKE 클러스터마다 개별적으로 설정됩니다. 클러스터를 노드 5,000개 이상으로 확장하려면 다음 단계를 수행합니다.
- 노드 5,000개 이상으로 확장할 클러스터를 식별합니다.
- 확장 후 워크로드가 클러스터 한도와 GKE 할당량 내에 있는지 확인합니다.
- 확장한 워크로드에 필요한 Compute Engine 할당량을 상향 조정해야 합니다.
- 클러스터의 가용성 유형이 리전이고 네트워크 격리가 비공개인지 확인합니다.
- 지원 티켓을 만들어 클러스터당 노드 수의 할당량 상향 조정을 요청합니다.
GKE팀에서 워크로드가 확장성 권장사항을 따르고 단일 클러스터에서 노드를 5,000개 이상 확장할 수 있는지 확인하기 위해 연락합니다.
대규모 워크로드의 다른 한도 방지를 위한 권장사항
위치당 네트워크당 VPC 네트워크 피어링을 사용하는 클러스터 수 제한
각 위치에 대해 동일한 VPC 네트워크에서 VPC 네트워크 피어링을 사용하는 비공개 클러스터를 최대 75개까지 만들 수 있습니다(영역과 리전은 별도의 위치로 취급됨). 한도를 초과하는 추가 클러스터를 만들려고 하면 다음과 비슷한 오류가 발생합니다.
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
GKE 비공개 클러스터는 VPC 네트워크 피어링을 사용하여 Kubernetes API 서버(Google에서 관리)와 내부 주소만 있는 비공개 노드 간의 내부 통신을 제공합니다.
이 문제를 해결하려면 Private Service Connect(PSC) 연결을 사용하는 클러스터를 사용하면 됩니다. PSC 연결이 있는 클러스터는 클러스터 75개 제한이 없는 비공개 클러스터와 동일한 격리를 제공합니다. PSC를 기반으로 하는 클러스터는 VPC 네트워크 피어링을 사용하지 않으며 VPC 피어링 수 제한의 영향을 받지 않습니다.
VPC 네트워크 피어링 재사용에 제공된 안내에 따라 클러스터에서 VPC 네트워크 피어링을 사용하는지 확인할 수 있습니다.
새 클러스터를 만드는 동안 한도에 도달하지 않도록 다음 단계를 수행합니다.
- 클러스터 생성 중에
no-enable-private-nodes매개변수를 사용하여 PSC 클러스터를 만듭니다. - 각 노드 풀에
enable-private-nodes매개변수를 사용하여 노드 풀의 격리를 구성합니다. - 필요한 경우 클러스터 수준에서
enable-private-endpoint매개변수를 사용하여 제어 영역의 격리를 구성합니다. 자세한 내용은 클러스터 격리 변경을 참조하세요.
또는 Google Cloud 지원팀에 문의하여 VPC 네트워크 피어링을 사용하여 비공개 클러스터 한도를 75개로 늘립니다. 이러한 요청은 사례별로 평가되며 한도를 늘릴 수 있으면 한 자릿수 증가가 적용됩니다.
다음 단계
- 대규모 GKE 클러스터 빌드에 대한 에피소드를 참조하세요.