Google Kubernetes Engine 클러스터 크기 및 범위 선택

이 문서에서는 공유 Google Kubernetes Engine 클러스터에서 실행할 작업 부하를 결정하고 올바른 클러스터 크기를 결정할 때 고려해야 할 기준을 제시합니다.

가상 머신 대신 컨테이너를 사용하면 동일한 인프라에 더 많은 작업 부하를 패키징할 수 있으며 작업 부하 간에 격리를 제공할 수 있습니다.

애플리케이션과 애플리케이션이 실행되는 컨테이너는 CPU 및 메모리 요구사항이 다릅니다. 컨테이너 조정 플랫폼인 Kubernetes는 여러 머신에서 컨테이너의 일정을 조정하여 CPU 및 메모리 요구사항을 수용합니다. 머신 활용도 최적화 정도는 작업 부하와 작업 부하를 조정할 수 있는 머신에 따라 달라집니다.

다수의 작업 부하를 실행하는 대규모 클러스터는 소수의 작업 부하만 실행하는 작은 클러스터보다 더 효율적이라고 예상할 수 있습니다. 그러나 여러 작업 부하 간에 클러스터를 공유하면 공유의 잠재적인 이점을 넘어서는 더 많은 복잡성과 제약이 생길 수 있습니다.

Google Kubernetes Engine은 다양한 클러스터 크기를 지원하도록 설계되었습니다. 클러스터의 최소 크기는 클러스터가 미치는 영역 수(영역 클러스터 1개와 지역 클러스터 3개)에 의해 정의됩니다. Google Kubernetes Engine 클러스터의 최대 크기는 다음과 같이 정의됩니다.

  • 영역당 클러스터 50개
  • 클러스터당 노드 5,000개
  • 노드당 포드 100개
  • 컨테이너 30만 개

이러한 제한에서 클러스터의 적절한 크기를 결정합니다. 다음 섹션에서는 고려해야 할 기준과 절충점에 대한 개요를 제공합니다.

Google Kubernetes Engine 클러스터 크기 조정

작업 부하 이동성

Kubernetes는 사용 가능한 리소스를 최대한 활용하는 방식으로 노드 간에 포드를 예약하려고 시도합니다. 예약 시에는 처음으로 포드를 실행하는 머신을 선택하는 것뿐만 아니라 포드 중단 예산도 고려해야 합니다. Kubernetes는 사용률을 최적화하기 위해 실행 중인 포드를 다시 예약할 수도 있습니다. 그러나 작업 부하가 다음 특정 기능을 사용하는 경우 최적화가 제한됩니다.

많은 작업 부하가 이러한 방식으로 제한되면 노드 간의 포드 할당이 크게 정체됩니다. 포드를 자유롭게 예약할 수 없다면 사용률이 최적화되지 않을 뿐만 아니라 클러스터 자동 확장의 효과도 저하됩니다. 최악의 경우 노드 장애가 발생하면 Kubernetes가 컴퓨팅 용량을 사용할 수 있다 하더라도 포드를 다시 예약할 수 없는 일이 발생할 수 있습니다.

높은 사용률을 위해서는 Kubernetes가 포드를 자유롭게 예약하도록 하세요. 그렇게 할 수 없다면 보다 작은 작업 부하별 클러스터를 사용해 보세요. 포드의 제약조건을 고려하여 노드 간에 포드를 할당하는 방법을 예상할 수 있다면 컨테이너의 CPU 및 메모리 크기 요구사항과 일치하는 머신 크기를 선택할 수 있습니다. 중복성을 보장하려면 노드 또는 영역에 장애가 발생해도 작업 부하가 제약조건을 위반하지 않고 다른 노드로 이전할 수 있도록 노드 풀을 구성합니다.

작업 부하 균일성

작업 부하가 완벽하게 균일하고 모든 컨테이너에 동일한 양의 CPU 및 메모리가 필요한 경우 Kubernetes는 노드 간에 작업 부하를 원활하게 예약할 수 있습니다. 그러나 작업 부하가 다양할수록 파편화로 인해 리소스를 낭비하지 않는 할당을 찾는 것이 더 어려워집니다. 다양한 작업 부하의 경우 클러스터가 클수록 리소스 사용률이 향상되는 경향이 있습니다.

작업 부하 탄력성

대부분의 경우 클러스터 작업 부하는 정적이지 않습니다. 배포가 추가되거나 삭제될 수 있으며 가장 중요하게는 수평형 포드 자동 확장의 사용으로 인해 실행 중인 포드의 수가 변경될 수 있습니다.

작업 부하가 다양한 경우 클러스터 자동 확장 기능을 사용 설정하세요. 이 기능이 활성화되면 Google Kubernetes Engine은 기본 노드 풀에서 노드를 동적으로 추가하거나 삭제하여 필요한 용량을 대략적으로 계산합니다. 머신의 용량이 필요한 추가 용량보다 훨씬 더 큰 경우 노드 풀에 추가된 머신은 초기에 낮은 사용률을 나타낼 수 있습니다. 큰 클러스터의 경우 무시할 수 있는 정도의 영향이지만 보다 작은 클러스터의 경우 오버헤드가 커질 수 있습니다. 오버헤드 및 비용을 최소화하려면 더 큰 클러스터 또는 더 작은 머신을 사용하세요.

Google Kubernetes Engine 클러스터 범위 지정

작업 부하 지역성

지연 시간을 최소화하거나, 가용성을 향상시키거나, 규정을 준수하려면 특정 지역 또는 여러 지역에서 작업 부하를 실행해야 할 수 있습니다. Google Kubernetes Engine 클러스터는 단일 지역 또는 단일 영역 내에서 실행됩니다. 따라서 작업 부하를 실행하는 데 필요한 지역의 수는 필요한 Google Kubernetes 클러스터의 최소 수를 지정합니다.

작업 부하 중요도

사고가 발생하여 중요 업무 작업 부하에 영향을 줄 때마다 운영자에게 알려 문제를 해결할 수 있도록 해야 합니다. 그러나 클러스터가 중요 업무 작업 부하와 중요하지 않은 작업 부하를 모두 실행한다면 어떨까요? 사고가 발생한 경우 중요하지 않은 작업 부하만 영향을 받는지 중요 업무 작업 부하도 영향을 받는지의 여부가 즉시 명확하게 드러나지 않을 수 있습니다. Kubernetes를 사용하면 작업 부하를 우선순위별로 분류할 수 있지만 동일한 클러스터에서 비슷한 중요도를 가진 작업 부하만 실행하는 것이 좋습니다.

서비스 검색 및 통신

동일한 클러스터에서 실행되는 작업 부하는 Kubernetes의 서비스 검색 및 부하 분산 기능을 사용할 수 있습니다. 그러나 작업 부하가 클러스터 간에 통신해야 하는 경우 외부 서비스 레지스트리 또는 부하 분산기를 사용하여 해당 작업 부하가 서로를 검색하고 연결할 수 있도록 해야 합니다.

서비스 발견 및 통신 측면에서 볼 때 일반적으로 프런트엔드 및 백엔드 애플리케이션과 같은 종속적인 작업 부하를 관리하는 경우 전용 소형 클러스터보다는 단일 대형 클러스터로 관리하는 것이 더 쉽습니다.

ID 및 액세스 관리

Google Cloud Platform(GCP)에서 액세스 관리는 프로젝트 범위 내에서 처리됩니다. 따라서 조직의 팀 구조를 따라 프로젝트를 모델링하는 것이 일반적이며 권장됩니다.

Google Kubernetes Engine 클러스터는 프로젝트의 일부이므로 여러 프로젝트 간에 공유할 수 없습니다. 따라서 Google Kubernetes Engine 클러스터 또한 프로젝트의 Cloud ID 및 액세스 관리(IAM) 구성이 적용됩니다.

클러스터, 팀, 프로젝트를 정렬하면 역할 및 권한을 간단하게 관리할 수 있습니다. 대부분의 경우 Cloud IAM은 Kubernetes에 대한 액세스를 관리하는 데 필요한 세부사항을 제공하며 Kubernetes 자체에서 추가 역할 기반 액세스 제어(RBAC)를 구성할 필요가 없습니다.

그러나 팀 간에 클러스터를 공유해야 하는 경우 클러스터의 상위 GCP 프로젝트 또한 여러 팀을 포괄해야 합니다. 이 경우 Cloud IAM이 Google Kubernetes Engine 액세스를 관리하기 위해 제공하는 역할이 충분히 구체적이지 않아 Kubernetes 자체 내에서 관리되는 추가적인(네임스페이스 수준) RBAC 구성이 필요할 수 있습니다. Cloud IAM 및 Kubernetes의 두 위치에서 RBAC 구성을 관리하려면 관리 복잡성이 증가하므로 Cloud IAM에서 모든 액세스 제어를 관리할 수 있도록 클러스터의 범위를 선택하는 것이 좋습니다.

유지관리

Google Kubernetes Engine은 완전 관리형 서비스이지만 몇 가지 유지관리 활동을 고려해야 합니다.

  • Kubernetes 버전 선택
  • 업그레이드 모델(수동 또는 예약) 및 유지관리 기간 선택
  • 업그레이드 시작
  • 노드 풀 설정 변경

이러한 모든 활동은 클러스터에서 실행 중인 작업 부하에 영향을 줄 수 있습니다. 클러스터를 여러 팀에서 공유하는 경우 언제 이러한 작업을 수행할지에 대해 여러 팀이 동의하는 것은 어려울 수 있습니다. 일정 문제를 방지하려면 클러스터의 유지관리 활동에 이해관계가 있는 팀의 수를 제한하세요.

네트워킹

Google Kubernetes Engine 클러스터는 사용하는 노드 풀 수에 관계없이 단일 가상 사설 클라우드(VPC) 및 서브넷에 속합니다. 연결 요구사항에 따라 작업 부하를 다른 VPC 또는 서브넷에서 실행해야 하는 경우 VPC 또는 서브넷당 하나 이상의 별도 클러스터를 만들어야 합니다.

모니터링 및 로깅

Google Kubernetes Engine 클러스터의 모니터링 및 로깅 구성은 전역이므로 로깅 및 모니터링 요구사항이 일치하는 경우 단일 클러스터에서 여러 작업 부하를 실행할 수 있습니다.

결제

GCP는 프로젝트별로 결제를 처리합니다. 단일 클러스터와 단일 GCP 프로젝트를 공유하는 작업 부하의 경우 어떤 작업 부하가 전체 비용의 어느 부분에 해당하는지 결정하기 어렵습니다. 작업 부하 단위 결제가 필요한 경우 전용 Google Kubernetes Engine 클러스터 및 GCP 프로젝트를 사용하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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