클러스터 아키텍처

클러스터는 Google Kubernetes Engine(GKE)의 기초이며, 컨테이너식 애플리케이션을 나타내는 Kubernetes 객체가 모두 이 클러스터에서 실행됩니다.

GKE에서 클러스터는 1개 이상의 제어 영역노드라는 작업자 머신 여러 개로 구성됩니다. 이러한 제어 영역 및 노드 머신은 Kubernetes 클러스터 조정 시스템을 실행합니다.

다음 다이어그램은 GKE의 영역 클러스터에 대한 아키텍처 개요를 제공합니다.

GKE는 영역 제어 영역에서 모든 것을 프로비저닝, 유지, 작업하며 노드만 프로비저닝합니다.

제어 영역

제어 영역은 Kubernetes API 서버, 스케줄러, 코어 리소스 컨트롤러를 포함하여 제어 영역 프로세스를 실행합니다. 클러스터를 만들거나 삭제하면 제어 영역의 수명 주기는 GKE에서 관리됩니다. 여기에는 제어 영역에서 실행되는 Kubernetes 버전으로의 업그레이드가 포함됩니다. 업그레이드는 GKE가 자동으로 또는 자동 일정보다 빨리 업그레이드하기 위해 사용자 요청에 따라 수동으로 실시합니다.

제어 영역 및 Kubernetes API

제어 영역은 클러스터의 통합 엔드포인트입니다. 클러스터와의 모든 상호작용은 Kubernetes API 호출을 통해 수행되며 제어 영역은 Kubernetes API 서버 프로세스를 실행하여 이러한 요청을 처리합니다. HTTP 또는 gRPC를 통해 직접 또는 Kubernetes 명령줄 클라이언트(kubectl)에서 명령어를 실행하거나 Cloud Console에서 UI와 상호작용하여 간접적으로 Kubernetes API 호출을 수행할 수 있습니다.

API 서버 프로세스는 클러스터의 모든 통신을 위한 허브입니다. 모든 내부 클러스터 프로세스(예: 클러스터 노드, 시스템 및 구성요소, 애플리케이션 컨트롤러)는 API 서버 클라이언트로 작동합니다. API 서버는 전체 클러스터의 단일 '신뢰 소스'입니다.

제어 영역 및 노드 상호작용

제어 영역은 모든 클러스터 노드에서 실행할 항목을 결정해야 합니다. 여기에는 컨테이너식 애플리케이션과 같은 워크로드 예약, 워크로드의 수명 주기, 확장, 업그레이드 관리가 포함될 수 있습니다. 제어 영역은 또한 이러한 워크로드의 네트워크 및 스토리지 리소스를 관리합니다.

제어 영역 및 노드도 Kubernetes API를 사용하여 통신합니다.

gcr.io Container Registry와 제어 영역의 상호작용

클러스터를 만들거나 업데이트하면 제어 영역(및 노드)에서 실행되는 Kubernetes 소프트웨어의 컨테이너 이미지를 gcr.io Container Registry에서 가져옵니다. gcr.io 레지스트리에 영향을 미치는 서비스 중단으로 인해 다음과 같은 유형의 오류가 발생할 수 있습니다.

  • 서비스 중단 중에 새 클러스터 만들기에 실패합니다.
  • 서비스 중단 중에 클러스터 업그레이드에 실패합니다.
  • 서비스 중단의 특정 성격과 기간에 따라 사용자 간섭이 없는데도 워크로드 문제가 발생할 수 있습니다.

gcr.io 컨테이너 레지스트리가 특정 영역 또는 리전에서 중단된 경우 Google은 이러한 서비스 중단에 영향을 받지 않는 영역 또는 리전으로 요청을 리디렉션할 수 있습니다.

Google Cloud 서비스의 현재 상태를 확인하려면 Google Cloud 상태 대시보드로 이동하세요.

노드

클러스터는 일반적으로 하나 이상의 노드를 포함하며, 이러한 노드는 컨테이너식 애플리케이션 및 다른 워크로드를 실행하는 작업자 머신입니다. 개별 머신은 클러스터를 생성할 때 사용자를 대신해서 GKE가 생성하는 Compute Engine VM 인스턴스입니다.

각 노드는 각 노드의 자체 보고 상태에 대한 업데이트를 수신하는 제어 영역에서 관리됩니다. 노드 수명 주기를 어느 정도 수동으로 제어하거나, GKE가 클러스터 노드에서 자동 복구자동 업그레이드를 수행하도록 할 수 있습니다.

노드는 클러스터의 워크로드를 구성하는 Docker 컨테이너를 지원하는 데 필요한 서비스를 실행합니다. 여기에는 Docker 런타임 및 Kubernetes 노드 에이전트(kubelet)가 포함됩니다. 이 에이전트는 제어 영역과 통신하고, 해당 노드에 예약된 Docker 컨테이너를 시작하고 실행합니다.

GKE에는 또한 로그 수집 및 클러스터 내 네트워크 연결과 같은 기능을 제공하기 위해 노드별 에이전트로 실행되는 여러 특수 컨테이너가 있습니다.

노드 머신 유형

각 노드는 표준 Compute Engine 머신 유형입니다. 기본 유형은 e2-medium입니다. 클러스터를 만들 때 다른 머신 유형을 선택할 수 있습니다.

노드 OS 이미지

각 노드는 컨테이너 실행을 위해 특수한 OS 이미지를 실행합니다. 클러스터 및 노드 풀이 사용할 OS 이미지를 지정할 수 있습니다.

최소 CPU 플랫폼

클러스터 또는 노드 풀을 만들 때는 노드의 기본 최소 CPU 플랫폼을 지정할 수 있습니다. 특정 CPU 플랫폼을 사용하면 고급 또는 컴퓨팅 집약적 워크로드에 유리할 수 있습니다. 자세한 내용은 최소 CPU 플랫폼을 참조하세요.

노드 할당 가능 리소스

노드가 클러스터의 일부로 작동하도록 만들기 위해 필요한 GKE 및 Kubernetes 노드 구성요소를 실행하려면 노드 리소스 중 일부가 필요합니다. 따라서 노드의 총 리소스(머신 유형 문서에 지정됨)와 GKE에서 할당 가능한 노드의 리소스가 일치하지 않을 수 있습니다.

용량이 큰 머신 유형일수록 더 많은 컨테이너를 실행(및 확장되어 더 많은 pod 실행)하려 하므로, 용량이 큰 머신의 경우 GKE가 Kubernetes 구성요소에 예약하는 리소스 양이 확장됩니다. 또한 Windows Server 노드에는 일반적인 Linux 노드보다 더 많은 리소스가 필요합니다. Windows OS를 실행하고 컨테이너에서 실행할 수 없는 Windows Server 구성요소를 위해 노드에 추가 리소스가 필요합니다.

포드에 대한 리소스를 요청하거나 포드의 리소스 사용을 제한할 수 있습니다. pod의 리소스 사용을 요청하거나 제한하는 방법은 컨테이너의 리소스 관리를 참조하세요.

클러스터에서 제공되는 노드 할당 가능 리소스를 검사하려면 다음 명령어를 실행하세요.

kubectl describe node node-name | grep Allocatable -B 7 -A 6

여기서 node-name은 검사할 노드의 이름입니다.

반환된 출력에는 임시 스토리지, 메모리, CPU의 측정과 함께 CapacityAllocatable 필드가 포함됩니다.

제거 임계값

Pod에 사용할 수 있는 메모리 양을 확인하려면 제거 임계값도 고려해야 합니다. GKE는 kubelet 제거를 위해 각 노드에 메모리 100MiB를 추가로 예약합니다.

할당 가능한 메모리 및 CPU 리소스

할당 가능한 리소스는 다음 방법으로 계산됩니다.

Allocatable = Capacity - Reserved - Eviction Threshold

메모리 리소스의 경우 GKE는 다음과 같이 예약합니다.

  • 메모리가 1GB 미만인 머신의 경우 255MiB 메모리
  • 처음 4GB 메모리 중 25%
  • 다음 4GB 메모리 중 20%(최대 8GB)
  • 다음 8GB 메모리 중 10%(최대 16GB)
  • 다음 112GB 메모리 중 6%(최대 128GB)
  • 128GB 이상의 메모리 중 2%

CPU 리소스의 경우 GKE는 다음과 같이 예약합니다.

  • 첫 번째 코어의 6%
  • 다음 코어의 1%(최대 2개 코어)
  • 다음 2개 코어의 0.5%(최대 4개 코어)
  • 4개를 넘는 코어의 0.25%

다음 표에서는 각 표준 노드 머신 유형에서 클러스터의 Linux 워크로드를 예약하는 데 사용할 수 있는 할당 가능한 메모리 및 CPU 리소스의 양을 보여줍니다.

머신 유형 메모리 용량(GB) 할당 가능한 메모리(GB) CPU 용량(코어) 할당 가능한 CPU(코어)
c2-standard-4 16 13.3 4 3.92
c2-standard-8 32 28.6 8 7.91
c2-standard-16 64 58.7 16 15.89
c2-standard-30 120 111.2 30 29.89
c2-standard-60 240 228.4 60 59.85
e2-micro 1 0.62 2 0.941
e2-small 2 1.35 2 0.941
e2-medium(기본값) 4 2.76 2 0.941
e2-standard-2 8 6.1 2 1.93
e2-standard-4 16 13.3 4 3.92
e2-standard-8 32 28.6 8 7.91
e2-standard-16 64 58.7 16 15.89
e2-highmem-2 16 13.3 2 1.93
e2-highmem-4 32 28.6 4 3.92
e2-highmem-8 64 58.7 8 7.91
e2-highmem-16 128 118.6 16 15.89
e2-highcpu-2 2 1.5 2 1.93
e2-highcpu-4 4 2.9 4 3.92
e2-highcpu-8 8 6.1 8 7.91
e2-highcpu-16 16 13.3 16 15.89
g1-small 1.7 1.2 1 0.94
m1-megamem-96 1433.6 1414.7 96 95.69
m1-ultramem-40 961 942.1 40 39.85
m1-ultramem-80 1922 1903.1 80 79.77
m1-ultramem-160 3844 3825.1 160 159.69
m1-ultramem-208 5888 5869.1 208 207.69
m1-ultramem-416 11776 11757.1 416 415.69
n1-standard-1 3.75 2.7 1 0.94
n1-standard-2 7.5 5.7 2 1.93
n1-standard-4 15 12.3 4 3.92
n1-standard-8 30 26.6 8 7.91
n1-standard-16 60 54.7 16 15.89
n1-standard-32 120 111.2 32 31.85
n1-standard-64 240 228.4 64 63.77
n1-standard-96 360 346.4 96 95.69
n1-highmem-2 13 10.7 2 1.93
n1-highmem-4 26 22.8 4 3.92
n1-highmem-8 52 47.2 8 7.91
n1-highmem-16 104 96.0 16 15.89
n1-highmem-32 208 197.4 32 31.85
n1-highmem-64 416 400.8 64 63.77
n1-highmem-96 624 605.1 96 95.69
n1-highcpu-2 1.8 1.3 2 1.93
n1-highcpu-4 3.6 2.6 4 3.92
n1-highcpu-8 7.2 5.5 8 7.91
n1-highcpu-16 14.4 11.9 16 15.89
n1-highcpu-32 28.8 25.3 32 31.85
n1-highcpu-64 57.6 52.5 64 63.77
n1-highcpu-96 86.4 79.6 96 95.69
n2-standard-2 8 6.1 2 1.93
n2-standard-4 16 13.3 4 3.92
n2-standard-8 32 28.6 8 7.91
n2-standard-16 64 58.7 16 15.89
n2-standard-32 128 118.6 32 31.85
n2-standard-48 192 182.6 48 47.85
n2-standard-64 256 244.4 64 63.77
n2-standard-80 320 308.4 80 79.77
n2-highmem-2 16 13.3 2 1.93
n2-highmem-4 32 28.6 4 3.92
n2-highmem-8 64 58.7 8 7.91
n2-highmem-16 128 118.6 16 15.89
n2-highmem-32 256 244.4 32 31.85
n2-highmem-48 384 370.4 48 47.85
n2-highmem-64 512 496.8 64 63.77
n2-highmem-80 640 621.1 80 79.77
n2-highcpu-2 2 1.5 2 1.93
n2-highcpu-4 4 2.9 4 3.92
n2-highcpu-8 8 6.1 8 7.91
n2-highcpu-16 16 13.3 16 15.89
n2-highcpu-32 32 28.6 32 31.85
n2-highcpu-48 48 44.6 48 47.85
n2-highcpu-64 64 58.7 64 63.77
n2-highcpu-80 80 74.7 80 79.77
n2d-standard-2 8 6.1 2 1.93
n2d-standard-4 16 13.3 4 3.92
n2d-standard-8 32 28.6 8 7.91
n2d-standard-16 64 58.7 16 15.89
n2d-standard-32 128 118.6 32 31.85
n2d-standard-48 192 182.6 48 47.85
n2d-standard-64 256 244.4 64 63.77
n2d-standard-80 320 308.4 80 79.77
n2d-standard-96 384 370.4 96 95.69
n2d-standard-128 512 496.8 128 127.69
n2d-standard-224 896 877.1 224 223.69
n2d-highmem-2 16 13.3 2 1.93
n2d-highmem-4 32 28.6 4 3.92
n2d-highmem-8 64 58.7 8 7.91
n2d-highmem-16 128 118.6 16 15.89
n2d-highmem-32 256 244.4 32 31.85
n2d-highmem-48 384 370.4 48 47.85
n2d-highmem-64 512 496.8 64 63.77
n2d-highmem-80 640 621.1 80 79.77
n2d-highmem-96 780 761.1 96 95.69
n2d-highcpu-2 2 1.5 2 1.93
n2d-highcpu-4 4 2.9 4 3.92
n2d-highcpu-8 8 6.1 8 7.91
n2d-highcpu-16 16 13.3 16 15.89
n2d-highcpu-32 32 28.6 32 31.85
n2d-highcpu-48 48 44.6 48 47.85
n2d-highcpu-64 64 58.7 64 63.77
n2d-highcpu-80 80 74.7 80 79.77
n2d-highcpu-96 96 89.2 96 95.69
n2d-highcpu-128 128 118.6 128 127.69
n2d-highcpu-224 224 213.4 224 223.69

1 GKE에서는 e2-micro, e2-small, e2-medium 머신 유형에서 사용자 워크로드(노드 할당 가능 리소스라고 함)를 예약하는 데 사용할 수 있는 할당 가능한 CPU 리소스를 줄이기로 결정했습니다. 자세한 내용은 GKE 출시 노트를 참조하세요.

할당 가능한 로컬 임시 스토리지 리소스

GKE 버전 1.10부터는 CPU 및 메모리 리소스처럼 로컬 임시 스토리지 리소스도 관리할 수 있습니다. Pod가 임시 스토리지 요청 및 한도를 지정하도록 설정하고 작동 방법을 확인하려면 Kubernetes 문서의 로컬 임시 스토리지를 참조하세요.

GKE는 일반적으로 단일 파일 시스템 및 주기적인 검사로 노드를 구성합니다. 크기에 의존하는 부팅 디스크 부분이 시스템 용으로 예약됩니다.

임시 스토리지는 시스템 사용을 위해 예약된 부분 및 제거 임계값을 제외하고 부팅 디스크의 최대 용량까지 사용할 수 있습니다. 총 예약된 크기는 다음 공식에 따라 부팅 디스크의 크기에 의존합니다.

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

부팅 디스크 용량 증가에 따라 사용 가능한 할당 가능한 임시 스토리지 양을 대략적으로 확인하려면 다음 그래프를 참조하세요.

부팅 디스크 용량에 따라 임시 스토리지 양을 보여주는 그래프입니다. 이 관계는 대략적으로 선형적입니다.