이 페이지에서는 Google Kubernetes Engine(GKE) Standard 노드 풀의 노드 크기를 계획하여 워크로드 중단 및 리소스 부족으로 인한 종료의 위험을 줄이는 방법을 설명합니다. Google에서 노드를 관리하므로 GKE Autopilot에서는 이 계획이 필요하지 않습니다.
적절한 크기의 노드의 이점
워크로드를 수용하고 사용량 급증을 처리하도록 노드 크기를 올바르게 설정하면 다음과 같은 이점이 있습니다.
- 리소스 부족으로 인한 제거 위험이 줄어들어 워크로드 신뢰성이 향상됩니다.
- 트래픽이 많은 기간에 걸쳐 워크로드를 확장할 수 있는 확장성이 개선됩니다.
- 노드의 크기가 필요 이상으로 크지 않아 리소스 낭비가 없으므로 비용이 절감됩니다.
노드 할당 가능 리소스
GKE 노드는 노드가 클러스터의 일부로 작동할 수 있게 해주는 시스템 구성요소를 실행합니다. 이러한 구성요소는 CPU 및 메모리와 같은 노드 리소스를 사용합니다. 기본 Compute Engine 가상 머신(VM)의 크기를 기반으로 하는 노드의 총 리소스와 GKE에 사용 가능한 리소스에 차이가 있을 수 있습니다. 이러한 차이는 GKE가 시스템 기능 및 노드 신뢰성을 위해 사전 정의된 리소스 수량을 예약하기 때문입니다. GKE가 시스템 리소스에 대해 예약하는 디스크 공간은 노드 이미지에 따라 다릅니다. 워크로드에 사용 가능한 남은 리소스를 할당 가능한 리소스라고 부릅니다.
매니페스트에 포드를 정의할 때 포드 사양에 리소스 요청 및 한도를 지정할 수 있습니다. GKE가 노드에 포드를 배치할 때 포드는 노드에 있는 할당 가능한 리소스로부터 이렇게 지정된 리소스를 요청합니다. 노드 풀의 노드 크기를 계획할 때는 워크로드의 올바른 작동을 위해 필요한 리소스 크기를 고려해야 합니다.
노드에서 할당 가능한 리소스 확인
기존 노드에서 할당 가능한 리소스를 조사하려면 다음 명령어를 실행합니다.
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
NODE_NAME을 허브 이름으로 바꿉니다.
출력은 다음과 비슷합니다.
allocatable:
attachable-volumes-gce-pd: "127"
cpu: 3920m
ephemeral-storage: "47060071478"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 13498416Ki
pods: "110"
capacity:
attachable-volumes-gce-pd: "127"
cpu: "4"
ephemeral-storage: 98831908Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16393264Ki
pods: "110"
이 출력에서 allocatable 섹션의 값은 노드에 있는 할당 가능한 리소스입니다. capacity 섹션의 값은 노드의 총 리소스입니다. 임시 스토리지의 단위는 바이트입니다.
GKE 리소스 예약
GKE는 노드에서 사용 가능한 총 리소스 크기에 따라 노드에 특정 크기의 메모리 및 CPU 리소스를 예약합니다. 더 큰 머신 유형은 더 많은 컨테이너 및 포드를 실행하므로 더 큰 머신의 경우 GKE가 예약하는 리소스 양이 수직 확장됩니다. 또한 Windows Server 노드에는 Windows OS 실행과 컨테이너에서 실행될 수 없는 Windows Server 구성요소에 대해 상응하는 Linux 노드보다 많은 리소스가 필요합니다.
메모리 및 CPU 예약
다음 섹션에서는 머신 유형 기반의 기본 메모리와 CPU 예약에 대해 설명합니다.
메모리 예약
메모리 리소스의 경우 GKE는 다음과 같이 예약합니다.
- 메모리가 1GiB 미만인 머신의 경우 255MiB 메모리
- 처음 4GiB 메모리 중 25%
- 다음 4GiB 메모리 중 20%(최대 8GiB)
- 다음 8GiB 메모리 중 10%(최대 16GiB)
- 다음 112GiB 메모리 중 6%(최대 128GiB)
- 128GiB 이상의 메모리 중 2%
또한 GKE는 포드 제거를 처리하기 위해 모든 노드에서 추가로 100MiB 메모리를 예약합니다.
CPU 예약
CPU 리소스의 경우 GKE는 다음과 같이 예약합니다.
- 첫 번째 코어의 6%
- 다음 코어의 1%(최대 2개 코어)
- 다음 2개 코어의 0.5%(최대 4개 코어)
- 4개를 넘는 코어의 0.25%
공유 코어 E2 머신 유형의 경우 GKE가 총 1,060 밀리코어를 예약합니다.
로컬 임시 스토리지 예약
GKE는 노드의 부팅 디스크 또는 로컬 SSD와 같은 로컬 연결 기기로 지원되는 로컬 임시 스토리지가 있는 노드를 제공합니다. 임시 스토리지에는 가용성이 보장되지 않으며 노드가 실패하거나 삭제될 경우 임시 스토리지의 데이터가 손실될 수 있습니다.
GKE는 노드의 총 임시 스토리지 중 일부를 단일 파일 시스템으로 예약합니다. 이는 포드 제거 중 kubelet에 사용되고 해당 노드에서 실행되는 다른 시스템 구성요소에 사용됩니다. 남은 임시 스토리지는 로그와 같은 목적으로 사용하기 위해 포드에 할당할 수 있습니다. 포드에서 임시 스토리지 요청 및 한도를 지정하는 방법은 로컬 임시 스토리지를 참조하세요.
GKE는 다음과 같이 로컬 임시 스토리지 예약을 계산합니다.
EVICTION_THRESHOLD + SYSTEM_RESERVATION
실제 값은 스토리지를 지원하는 기기 크기 및 유형에 따라 달라집니다.
노드 부팅 디스크를 기반으로 하는 임시 스토리지
기본적으로 임시 스토리지는 노드 부팅 디스크를 기반으로 합니다. 이 경우 GKE는 다음과 같이 제거 기준점의 값을 결정합니다.
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
제거 기준점은 항상 총 부팅 디스크 용량의 10%입니다.
GKE는 다음과 같이 시스템 예약 값을 결정합니다.
SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)
시스템 예약 금액은 다음 중 가장 낮은 값입니다.
- 부팅 디스크 용량의 50%
- 부팅 디스크 용량의 35% + 6GiB
- 100GiB
예를 들어 부팅 디스크가 300GiB이면 다음 값이 적용됩니다.
- 용량의 50%: 150GiB
- 용량의 35% + 6GiB: 111GiB
- 100GiB
GKE가 다음을 예약합니다.
- 시스템 예약: 100GiB(최저 값)
- 제거 기준점: 30GiB
예약된 총 임시 스토리지는 130GiB입니다. 남은 용량인 170GiB는 할당 가능한 임시 스토리지입니다.
로컬 SSD를 기반으로 하는 임시 스토리지
임시 스토리지가 로컬 SSD로 지원되는 경우 GKE가 다음과 같이 제거 기준점을 계산합니다.
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GB
이 계산에서 SSD_NUMBER는 연결된 로컬 SSD의 개수입니다. 모든 로컬 SSD는 크기가 375GB이므로 제거 기준점은 총 임시 스토리지 용량의 10%입니다.
GKE는 다음과 같이 연결된 SSD 개수에 따라 시스템 예약을 계산합니다.
| 로컬 SSD 수 | 시스템 예약(GiB) |
|---|---|
| 1 | 50GiB |
| 2 | 75GiB |
| 3개 이상 | 100GiB |
리소스 예약을 사용하여 노드 크기 계획
배포 시 그리고 부하 시 워크로드의 리소스 요구사항을 고려하세요. 여기에는 수직 확장을 수용하기 위한 오버헤드는 물론 워크로드에 대한 요청 및 계획된 한도가 포함됩니다.
워크로드 실행을 위해 큰 노드를 소량으로 사용할지 아니면 작은 노드를 대량으로 사용할지 고려합니다.
- 큰 노드를 소량으로 사용하는 방식은 고가용성이 필요하지 않은 리소스 집약적인 워크로드에 적합합니다. 축소하기 위해 더 많은 포드가 제거되어야 하므로 노드 자동 확장은 민첩성이 낮습니다.
- 작은 노드를 대량으로 사용하는 방식은 리소스 집약적이지 않은 고가용성 워크로드에 적합합니다. 축소를 위해 포드가 더 적게 제거되어야 하므로 노드 자동 확장은 민첩성이 높습니다.
Compute Engine 머신 계열 비교 가이드를 사용하여 노드에 사용하려는 머신 시리즈 및 계열을 결정합니다.
워크로드의 임시 스토리지 요구사항을 고려합니다. 노드 부팅 디스크가 충분한가요? 로컬 SSD가 필요한가요?
이전 섹션의 정보를 사용해서 선택한 머신 유형의 할당 가능한 리소스를 계산합니다. 이를 필요한 리소스 및 오버헤드와 비교합니다.
- 선택한 머신 유형이 너무 크면 추가 리소스 비용을 방지하기 위해 더 작은 머신을 고려합니다.
- 선택한 머신 유형이 너무 작으면 워크로드 중단 위험을 줄이기 위해 더 큰 머신을 고려합니다.