클러스터 아키텍처

Google Kubernetes Engine에서 클러스터는 최소 한 개 이상의 클러스터 마스터노드라는 작업자 머신 여러 개로 구성됩니다. 이러한 마스터 및 노드 머신은 Kubernetes 클러스터 조정 시스템을 실행합니다.

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

클러스터 마스터

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

클러스터 마스터 및 Kubernetes API

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

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

마스터 및 노드 상호작용

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

마스터 및 노드도 Kubernetes API를 사용하여 통신합니다.

gcr.io 컨테이너 레지스트리와 마스터의 상호작용

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

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

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

GCP 서비스의 현재 상태를 확인하려면 GCP 상태 대시보드를 참조하세요.

노드

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

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

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

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

노드 머신 유형

각 노드는 표준 Compute Engine 머신 유형입니다. 기본 유형은 1개의 가상 CPU와 3.75GB 메모리가 포함된 n1-standard-1입니다. 클러스터를 만들 때, 다른 머신 유형을 선택할 수 있습니다.

노드 OS 이미지

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

최소 CPU 플랫폼

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

노드 할당 가능 리소스

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

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

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

kubectl describe node [NODE_NAME] | grep Allocatable -B 4 -A 3

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

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

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

Allocatable = Capacity - Reserved - Eviction Threshold

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

  • 처음 4GB 메모리 중 25%
  • 다음 4GB 메모리 중 20%(최대 8GB)
  • 다음 8GB 메모리 중 10%(최대 16GB)
  • 다음 112GB 메모리 중 6%(최대 128GB)
  • 128GB 이상의 메모리 중 2%

GKE는 kubelet 축출을 위해 각 노드에 메모리 100 MiB를 추가로 예약합니다.

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

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

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

머신 유형 메모리 용량(GB) 할당 가능한 메모리(GB) CPU 용량(코어) 할당 가능한 CPU(코어)
f1-micro(메모리에서 제외) 0.6 0.6 1 0.94
g1-small 1.7 1.2 1 0.94
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

할당 가능한 로컬 임시 저장소 리소스

GKE 버전 1.10부터는 CPU 및 메모리 리소스처럼 로컬 임시 저장소 리소스도 관리할 수 있습니다. 로컬 저장소를 위한 시스템 예약은 주로 컨테이너 이미지에서 사용되는 디스크 공간에 사용됩니다.

노드가 모든 예약된 저장소를 소비하지 않을 경우 포드가 계속 해당 공간을 사용할 수 있습니다. 이렇게 해도 디스크 공간이 다른 시나리오에서 사용되는 것을 방지하지 않습니다.

할당 가능한 로컬 임시 저장소 리소스는 다음 공식을 사용해서 계산되며, 축출 임계값은 저장소 용량의 10%입니다.

Allocatable = Capacity - Reserved - Eviction Threshold
디스크 용량(GB) 예약(GB) 할당 가능(GB)
8 4 3.2
16 8 6.4
32 16 12.8
64 28.4 29.2
128 50.8 64.4
256 95.6 134.8
512 100 360.8
1024 100 821.6
2048 100 1743.2
4096 100 3586.4
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Kubernetes Engine 문서