Autopilot 개요


이 페이지에서는 Google Kubernetes Engine(GKE)의 Autopilot 작업 모드를 설명하고 클러스터를 계획, 설정, 관리하는 데 사용할 수 있는 리소스를 제공합니다.

Autopilot이란?

GKE Autopilot은 Google에서 노드, 확장, 보안, 기타 사전 구성된 설정을 포함한 클러스터 구성을 관리하는 GKE의 작동 모드입니다. Autopilot 클러스터는 대부분의 프로덕션 워크로드를 실행하고Kubernetes 매니페스트에 따라 컴퓨팅 리소스를 프로비저닝하도록 최적화되어 있습니다. 간소화된 구성은 클러스터 및 워크로드 설정, 확장성, 보안에 대한 GKE 권장사항을 따릅니다. 기본 제공되는 설정 목록은 Autopilot 및 표준 비교 표를 참조하세요.

가격 책정

대부분의 경우 GKE Autopilot에서 실행되는 동안 워크로드가 요청하는 CPU, 메모리, 스토리지에 대한 비용만 지불하면 됩니다. GKE에서 노드를 관리하므로 사용하지 않은 노드 용량에 대한 비용은 청구되지 않습니다.

시스템 포드, 운영체제 비용 또는 예약되지 않은 워크로드에 대한 비용이 청구되지 않습니다. 자세한 가격 책정 정보는 Autopilot 가격 책정을 참조하세요.

이점

  • 앱에 집중: Google에서 인프라를 관리하므로 애플리케이션 빌드와 배포에 집중할 수 있습니다.
  • 보안: 클러스터에는 기본 강화 구성이 있으며 기본적으로 여러 보안 설정이 사용 설정되어 있습니다. GKE는 사용 가능한 경우 구성된 유지보수 일정을 준수하여 노드에 보안 패치를 자동으로 적용합니다.
  • 가격 책정: Autopilot 가격 책정 모델은 청구 예측 및 기여 분석을 간소화합니다.
  • 노드 관리: Google에서 워커 노드를 관리하므로 워크로드를 수용하기 위해 새 노드를 만들거나 자동 업그레이드와 복구를 구성할 필요가 없습니다.
  • 확장: 워크로드에서 로드가 많이 발생하고 Kubernetes 수평형 포드 자동 확장과 같이 트래픽을 수용하기 위해 포드를 더 추가하면 GKE는 해당 포드의 새 노드를 자동으로 프로비저닝하며 필요에 따라 기존 노드의 리소스를 자동으로 확장합니다.
  • 예약: Autopilot에서 자동으로 포드 빈 패킹을 관리하므로 각 노드에서 실행 중인 포드 수를 고려할 필요가 없습니다. 어피니티 및 포드 분산 토폴로지와 같은 Kubernetes 메커니즘을 사용하여 포드 배치를 추가로 제어할 수 있습니다.
  • 리소스 관리: CPU 및 메모리와 같은 리소스 값을 설정하지 않고 워크로드를 배포하면 Autopilot에서 사전 구성된 기본값을 자동으로 설정하고 워크로드 수준에서 리소스 요청을 수정합니다.
  • 네트워킹: Autopilot은 트래픽이 클러스터의 다른 포드로 이동하더라도 모든 포드 네트워크 트래픽이 Virtual Private Cloud 방화벽 규칙을 통과하도록 하는 등 기본적으로 일부 네트워킹 보안 기능을 사용 설정합니다.
  • 출시 관리: 모든 Autopilot 클러스터는 GKE 출시 채널에 등록되므로 제어 영역과 노드가 해당 채널의 최신 검증 버전에서 실행됩니다.
  • 관리형 유연성: 워크로드에 높은 CPU 또는 메모리와 같은 특정 하드웨어 요구사항이나 리소스 요구사항이 있으면 Autopilot에서 해당 워크로드에 빌드된 사전 구성된 컴퓨팅 클래스를 제공합니다. 맞춤설정된 머신 유형과 하드웨어에서 지원하는 새 노드를 수동으로 만들 필요 없이 배포에서 컴퓨팅 클래스를 요청합니다. 또한 GPU를 선택하여 일괄 또는 AI/ML 애플리케이션과 같은 워크로드를 가속화할 수 있습니다.
  • 운영 복잡성 감소: Autopilot은 노드, 확장, 예약 작업을 지속적으로 모니터링할 필요성을 제거하여 플랫폼 관리 오버헤드를 줄입니다.

Autopilot은 포드에서 사용하는 제어 영역과 컴퓨팅 용량을 모두 포함하는 SLA와 함께 제공됩니다.

Autopilot 클러스터 계획

클러스터를 만들기 전에 Google Cloud 아키텍처를 계획하고 설계합니다. Autopilot의 워크로드 사양에서 하드웨어를 요청합니다. GKE는 이러한 워크로드를 실행하기 위해 해당 인프라를 프로비저닝하고 관리합니다. 예를 들어 머신러닝 워크로드를 실행하는 경우 하드웨어 가속기를 요청합니다. Android 앱을 개발하는 경우 Arm CPU를 요청합니다.

워크로드 규모에 따라 Google Cloud 프로젝트 또는 조직의 할당량을 계획하고 요청합니다. GKE는 해당 하드웨어에 충분한 할당량이 프로젝트에 포함된 경우에만 워크로드에 대한 인프라를 프로비저닝할 수 있습니다.

계획 시 다음 요소를 고려하세요.

  • 예상 클러스터 크기 및 규모
  • 워크로드 유형
  • 클러스터 레이아웃 및 사용량
  • 네트워킹 레이아웃 및 구성
  • 보안 구성
  • 클러스터 관리 및 유지보수
  • 워크로드 배포 및 관리
  • 로그 기록 및 모니터링

다음 섹션에서는 이러한 고려사항에 대한 정보와 유용한 리소스를 제공합니다.

네트워킹

공개 네트워킹으로 Autopilot 클러스터를 만들면 클러스터의 워크로드가 서로 그리고 인터넷과 통신할 수 있습니다. 이는 기본 네트워킹 모드입니다. Google Cloud 및 Kubernetes는 사용 사례에 따라 활용할 수 있는 다양한 추가 네트워킹 기능(예: 비공개 네트워킹이 있는 클러스터)을 제공합니다.

Kubernetes 및 클라우드의 네트워킹은 복잡합니다. Google Cloud에서 자동으로 설정된 기본값을 변경하기 전에 네트워킹의 기본 개념을 이해해야 합니다. 다음 표에서는 사용 사례에 따른 GKE의 네트워킹을 자세히 알아볼 수 있는 리소스를 제공합니다.

사용 사례 리소스
Kubernetes 및 GKE에서 네트워킹의 작동 방식 이해

네트워킹 모델을 학습한 후에는 조직의 네트워킹 및 네트워크 보안 요구사항을 고려합니다. 이러한 기준을 충족하는 GKE 및 Google Cloud 네트워킹 기능을 선택합니다.

GKE 네트워킹 구성 계획

서비스당 엔드포인트 및 API 요청 한도와 같은 GKE의 네트워킹 할당량을 이해하는 것이 좋습니다. 다음 리소스는 네트워킹 설정의 특정 측면을 계획하는 데 도움이 됩니다.

워크로드 노출
  • 앱을 인터넷에 노출하려면 포드 그룹에서 실행되는 앱을 단일 네트워크 서비스로 노출할 수 있는 서비스를 사용합니다.
  • 워크로드가 Google Cloud API와 안전하게 통신하도록 구성하려면 GKE용 워크로드 아이덴티티 제휴를 사용합니다.
여러 클러스터에서 가용성이 높은 연결된 서비스 실행 멀티 클러스터 서비스(MCS)를 사용합니다.
수신 트래픽 부하 분산
클러스터 네트워크 보안 구성
  • 공개 인터넷에서 클러스터에 대한 액세스를 제어하거나 방지하려면 비공개 클러스터를 만듭니다.
  • 특정 IP 주소 범위로 제어 영역 액세스를 제한하려면 제어 영역 승인 네트워크를 사용합니다.
  • IP 주소 또는 포트 수준에서 포드 트래픽을 제어하려면 네트워크 정책을 사용합니다. Autopilot 클러스터는 GKE Dataplane V2를 사용하여 eBPF를 통해 지연 시간이 짧은 패킷을 라우팅합니다.
Kubernetes 네트워크 트래픽 관찰
  • GKE Dataplane V2 측정항목을 수집하려면 Google Managed Service for Prometheus를 구성합니다. 기본적으로 GKE Dataplane V2 측정항목은 GKE Autopilot에 노출됩니다.
  • 시각화, 네트워크 정책 결과, 흐름 덤프에 액세스하려면 GKE Dataplane V2 관측 가능성을 사용하여 추가 문제 해결 도구를 구성합니다.

확장

대규모 플랫폼을 효과적으로 운영하려면 계획과 신중한 고려가 필요합니다. 서비스 수준 목표(SLO) 내에서 클러스터를 확장시킬 수 있도록 설계의 확장성을 고려해야 합니다. 플랫폼 관리자와 개발자 모두를 대상으로 한 자세한 안내는 확장 가능한 클러스터 생성 가이드라인을 참조하세요.

특히 수천 개의 포드가 포함된 대규모 클러스터를 실행하려는 경우 GKE 할당량 및 한도도 고려해야 합니다.

Autopilot 워크로드 확장

Autopilot에서 GKE는 클러스터의 포드 수를 기준으로 노드를 자동으로 확장합니다. 클러스터에 실행 중인 워크로드가 없으면 Autopilot이 자동으로 클러스터를 0개 노드로 축소할 수 있습니다. 새로 생성된 대부분의 Autopilot 클러스터에서는 배포하는 첫 번째 워크로드의 예약 시간이 더 오래 걸릴 수 있습니다. 이는 새 Autopilot 클러스터가 생성 시 사용 가능한 노드 0개로 시작하고 워크로드를 배포하여 추가 노드를 프로비저닝할 때까지 대기하기 때문입니다.

클러스터의 포드 수를 자동으로 확장하려면 기본 제공되는 CPU 또는 메모리 측정항목이나 Cloud Monitoring의 커스텀 측정항목을 기준으로 포드를 확장할 수 있는 Kubernetes 수평형 포드 자동 확장과 같은 메커니즘을 사용하는 것이 좋습니다. 다양한 측정항목을 기반으로 확장을 구성하는 방법은 측정항목을 기준으로 포드 자동 확장 최적화를 참조하세요.

보안

Autopilot 클러스터는 기본적으로 클러스터 보안 강화GKE 보안 개요의 여러 권장사항을 포함한 보안 권장사항과 설정을 사용 설정하고 적용합니다.

Autopilot 강화 조치와 특정 보안 요구사항을 구현하는 방법에 대해 자세히 알아보려면 Autopilot의 보안 조치를 참조하세요.

클러스터 만들기

환경을 계획하고 요구사항을 파악한 후 Autopilot 클러스터를 만듭니다. 새 Autopilot 클러스터는 공개적으로 액세스할 수 있는 IP 주소가 있는 리전 클러스터입니다. 각 클러스터에는 자동 확장 및 기타 기능과 함께 기준 강화 조치가 적용됩니다. 사전 구성된 기능의 전체 목록은 GKE Autopilot과 Standard 비교를 참조하세요.

공개 IP 주소가 없는 클러스터를 만들려면 비공개 클러스터를 만듭니다.

Autopilot에 워크로드 배포

실행 중인 Autopilot 클러스터에 워크로드를 배포하려면 Kubernetes 매니페스트를 작성하고 클러스터에 적용합니다. 기본적으로 Autopilot 클러스터는 대부분의 프로덕션 워크로드를 실행하도록 최적화되어 있습니다.

앱 배포 및 노출을 위한 Google Cloud 콘솔의 대화형 가이드를 보려면 둘러보기를 클릭합니다.

둘러보기

일부 워크로드에는 하드웨어 가속기가 필요한 ML 워크로드 또는 ARM 아키텍처가 필요한 모바일 앱 테스트와 같은 특수한 하드웨어 요구사항이 있을 수 있습니다. Autopilot에는 특수한 컴퓨팅 요구사항이 있는 워크로드를 실행하도록 Google Cloud에서 구성한 컴퓨팅 클래스가 있습니다. 이러한 워크로드를 배포할 때는 매니페스트에서 컴퓨팅 클래스를 요청합니다. Autopilot은 자동으로 특수 머신의 지원을 받는 노드를 프로비저닝하고, 예약을 관리하고, 하드웨어를 할당합니다.

다음 표에서는 몇 가지 일반적인 요구사항 및 사용자에게 요구되는 조치에 관한 권장사항을 설명합니다.

사용 사례 리소스
ARM 워크로드 실행 매니페스트에서 Scale-Out 컴퓨팅 클래스와 arm64 아키텍처를 요청합니다. 자세한 안내는 ARM 아키텍처에 Autopilot 워크로드 배포를 참조하세요.
가속화된 AI/ML 워크로드 실행 매니페스트에서 GPU를 요청합니다. 자세한 내용은 Autopilot에서 GPU 워크로드 배포를 참조하세요.
높은 컴퓨팅 또는 메모리 용량이 필요한 워크로드 실행 Balanced 컴퓨팅 클래스를 요청합니다. 자세한 내용은 Autopilot 포드의 컴퓨팅 클래스 선택을 참조하세요.
더 효율적인 CPU 용량 수평 확장 및 단일 코어당 스레드 컴퓨팅이 필요한 워크로드 실행 Scale-Out 컴퓨팅 클래스를 요청합니다. 자세한 내용은 Autopilot 포드의 컴퓨팅 클래스 선택을 참조하세요.
일괄 작업과 같은 내결함성 워크로드를 저렴한 비용으로 실행 매니페스트에서 Spot 포드를 지정합니다. 자세한 내용은 Spot 포드에서 더 저렴한 비용으로 내결함성 워크로드 실행을 참조하세요. Spot 포드에서 모든 컴퓨팅 클래스 또는 하드웨어 구성을 사용할 수 있습니다.
게임 서버 또는 작업 대기열 등 중단을 최소화해야 하는 워크로드 실행 포드 사양에 cluster-autoscaler.kubernetes.io/safe-to-evict=false 주석을 지정합니다. 최대 7일 동안 노드 자동 업그레이드 또는 축소 이벤트로 인한 제거로부터 포드를 보호합니다. 자세한 내용은 Autopilot 포드의 실행 시간 연장을 참조하세요.
노드의 포드 리소스 요청 합계에서 사용되지 않은 리소스가 있는 경우 워크로드가 요청을 초과하여 버스팅되도록 합니다. 리소스 limitsrequests보다 높게 설정하거나 리소스 한도를 설정하지 않습니다. 자세한 내용은 GKE에서 포드 버스팅 구성을 참조하세요.

Autopilot을 사용하면 워크로드의 CPU, 메모리, 임시 스토리지 리소스를 요청할 수 있습니다. 허용되는 범위는 포드를 기본 범용 컴퓨팅 플랫폼에서 실행할지 아니면 컴퓨팅 클래스에서 실행할지에 따라 다릅니다.

기본 컨테이너 리소스 요청과 허용되는 리소스 범위에 대한 자세한 내용은 Autopilot의 리소스 요청을 참조하세요.

워크로드 분리

Autopilot 클러스터는 노드 선택기 및 노드 어피니티를 사용하여 워크로드 분리를 구성할 수 있습니다. 워크로드 분리는 커스텀 노드 라벨과 같은 특정 기준을 충족하는 노드에 워크로드를 배치하도록 GKE에 지시해야 할 때 유용합니다. 예를 들어 game-server 라벨을 사용해서 노드에 게임 서버 포드를 예약하고 해당 노드에 다른 포드가 예약되지 않도록 GKE에 지시할 수 있습니다.

자세한 내용은 GKE에서 워크로드 분리 구성을 참조하세요.

영역 토폴로지를 사용하여 특정 영역에서 포드 예약

영역 특정 Compute Engine 영구 디스크의 정보 액세스와 같은 목적으로 Google Cloud 영역에 포드를 배치하려면 특정 영역에 GKE 포드 배치를 참조하세요.

포드 어피니티 및 안티어피니티

포드 어피니티 및 안티어피니티를 사용하여 단일 노드에 포드를 같은 위치에 배치하거나 일부 포드가 다른 포드를 방지하도록 합니다. 포드 어피니티 및 안티어피니티는 특정 리전 또는 영역과 같은 특정 토폴로지 도메인의 노드에서 실행되는 포드의 라벨을 기준으로 예약 결정을 내리도록 Kubernetes에 지시합니다. 예를 들어 중단 시 가용성을 향상시키기 위해 동일한 노드에서 다른 프런트엔드 포드와 함께 프런트엔드 포드를 예약하지 않도록 GKE에 지시할 수 있습니다.

자세한 내용 및 안내는 포드 어피니티 및 안티-어피니티를 참조하세요.

GKE에서는 topologyKey의 다음 라벨과 함께 포드 어피니티 및 안티어피니티를 사용할 수 있습니다.

  • topology.kubernetes.io/zone
  • kubernetes.io/hostname

포드 토폴로지 분산 제약조건

Kubernetes가 포드 수를 확장 및 축소할 때 워크로드의 가용성을 향상시키려면 포드 토폴로지 분산 제약조건을 설정하면 됩니다. 이는 Kubernetes가 리전과 같은 토폴로지 도메인 내의 노드 간에 포드를 분산하는 방법을 제어합니다. 예를 들어 Kubernetes에 us-central1 리전에 있는 3개의 Google Cloud 영역 각각에 특정 수의 게임 서버 포드를 배치하도록 지시할 수 있습니다.

예시, 상세 내용, 안내는 포드 토폴로지 분산 제약조건을 참조하세요.

Autopilot 클러스터 관리 및 모니터링

Autopilot에서 GKE는 제어 영역 및 워커 노드 모두에 대해 클러스터 업그레이드 및 유지보수를 자동으로 관리합니다. Autopilot 클러스터에는 또한 클러스터 및 워크로드를 모니터링할 수 있는 기본 제공 기능이 포함됩니다.

GKE 버전 업그레이드

모든 Autopilot 클러스터는 GKE 출시 채널에 등록됩니다. 출시 채널에서 GKE는 Kubernetes 클러스터 버전을 관리하여 채널에 따라 기능 가용성과 버전 안정성 사이의 균형을 조정합니다. 기본적으로 Autopilot 클러스터는 일반 출시 채널에 등록되지만 안정성 및 기능 요구를 충족하는 다른 채널을 선택할 수 있습니다. 출시 채널에 대한 자세한 내용은 출시 채널 정보를 참조하세요.

GKE는 업그레이드를 자동으로 시작하고, 진행 상황을 모니터링하고, 문제가 발생하면 작업을 일시중지합니다. 다음과 같은 방법으로 업그레이드 프로세스를 수동으로 제어할 수 있습니다.

  • GKE가 자동 업그레이드를 수행할 수 있는 시간을 제어하려면 유지보수 기간을 생성합니다. 예를 들어 플레이어가 방해 받지 않고 리셋 시 로그인할 수 있도록 멀티플레이어 게임의 주간 리셋을 수행하기 전에 유지보수 기간을 야간으로 설정할 수 있습니다.
  • 특정 시간 범위 동안 GKE가 자동 업그레이드를 시작할 수 없으면 유지보수 제외를 사용합니다. 예를 들어 블랙 프라이데이와 사이버 먼데이 할인과 같은 기간 중에는 고객이 문제 없이 쇼핑을 계속할 수 있도록 유지보수 제외를 설정할 수 있습니다.
  • 자동 업그레이드 시작 전 새 버전을 가져오려면 제어 영역을 수동으로 업그레이드합니다. GKE는 시간 경과에 따라 제어 영역 버전에 맞게 노드 버전을 조정합니다.
  • 새 출시 채널에서만 사용할 수 있는 패치 버전을 가져오려면 새 채널에서 패치 버전 실행을 참조하세요. 예를 들어 최근에 알려진 취약점을 해결하려면 특정 패치 버전이 필요할 수 있습니다.

Autopilot 클러스터 모니터링

Autopilot 클러스터에는 Cloud Logging, Cloud Monitoring, Google Cloud Managed Service for Prometheus가 이미 사용 설정되어 있습니다.

Autopilot 클러스터는 원격 분석 수집에 대한 Google 권장사항에 따라 다음 유형의 로그 및 측정항목을 자동으로 수집합니다.

Cloud Logging 로그

  • 시스템 로그
  • 워크로드 로그
  • 관리자 활동 감사 로그
  • 데이터 액세스 감사 로그

Cloud Monitoring 측정항목

  • 시스템 측정항목
  • 워크로드 측정항목(Managed Service for Prometheus)

로깅 및 모니터링을 사용 설정하는 데에는 추가 구성이 필요하지 않습니다. 다음 표에서는 요구사항에 따라 수집된 원격 분석을 사용하는 방법을 보여줍니다.

사용 사례 리소스
GKE 로그 이해 및 액세스
  • 자동으로 수집되는 로그 유형에 대해 알아보려면 수집되는 로그를 참조하세요.
  • 로그에 액세스하고 Google Cloud 콘솔에서 Cloud Logging 사용자 인터페이스를 사용하려면 GKE 로그 보기를 참조하세요.
  • Kubernetes 시스템 및 워크로드 로그를 필터링하는 데 사용할 수 있는 샘플 쿼리는 Kubernetes 관련 쿼리를 참조하세요.
  • 관리자 활동 및 데이터 액세스 감사 로그를 필터링하는 데 사용할 수 있는 샘플 쿼리는 GKE 감사 로깅 정보를 참조하세요.
  • 단일 GKE 클러스터에 특정 네임스페이스가 있지만 각 팀에 자체 Google Cloud 프로젝트가 포함된 경우와 같이 멀티 테넌트 환경에 맞게 로그를 구성하려면 GKE의 멀티 테넌트 로깅을 참조하세요.
GKE 클러스터의 성능 관찰

클러스터 성능을 효과적으로 모니터링하면 클러스터와 워크로드의 운영 비용을 최적화할 수 있습니다.

  • Monitoring의 GKE 대시보드를 사용하여 클러스터 상태를 시각화합니다. 자세한 내용은 GKE 클러스터 관찰을 참조하세요.
  • GKE는 Google Cloud 콘솔에서 관측 가능성 대시보드도 제공합니다. 자세한 내용은 관측 가능성 측정항목 보기를 참조하세요.
클러스터의 보안 상황 모니터링 보안 상황 대시보드를 사용하여 GKE 권장사항에 따라 실행 중인 워크로드를 감사하고, 컨테이너 운영체제 및 언어 패키지에서 취약점을 스캔하고, 실행 가능한 해결 권장사항을 얻을 수 있습니다. 자세한 내용은 보안 상황 대시보드 정보를 참조하세요.

문제 해결

문제 해결 단계는 Autopilot 클러스터 문제 해결을 참조하세요.

다음 단계