Autopilot 개요


소개

Autopilot은 Google Kubernetes Engine(GKE)의 새로운 작업 모드로, 클러스터 관리 작업 비용을 줄이고 클러스터를 프로덕션에 최적화하고 가용성이 더 높은 워크로드를 얻도록 설계되었습니다. 작업 모드는 클러스터에 대한 유연성, 책임, 제어의 수준을 나타냅니다. 완전 관리형 제어 영역과 노드 자동화라는 이점 외에도 GKE는 다음 두 가지 작업 모드를 제공합니다.

  • Autopilot: GKE는 노드와 노드 풀을 포함한 클러스터의 기본 인프라를 프로비저닝 및 관리하여 핸드오프 환경을 갖춘 최적화된 클러스터를 제공합니다.
  • 표준: 클러스터의 기본 인프라를 관리하여 노드 구성 유연성을 제공합니다.

Autopilot을 사용하면 더 이상 노드 상태를 모니터링하거나 워크로드에 필요한 컴퓨팅 용량을 계산하지 않아도 됩니다. Autopilot은 대부분의 Kubernetes API, 도구, 풍부한 생태계를 지원합니다. Compute Engine을 통해 노드에 액세스할 수 없으므로 표준 모드에서와 같이 Compute Engine API, CLI 또는 UI와 상호작용할 필요 없이 GKE 내에 상주합니다. pod가 실행 중인 상태에서 요청한 CPU, 메모리, 스토리지에 대해서만 비용을 지불합니다.

Autopilot 클러스터는 프로덕션 워크로드에 사용할 수 있는 최적화된 클러스터 구성으로 사전 구성됩니다. 간소화된 이 구성은 클러스터, 워크로드 설정, 보안에 대한 GKE 권장사항을 따릅니다. 이러한 기본 제공 설정 중 일부(아래 표에서 자세히 설명)를 변경할 수 없으며 기타 선택적 설정을 사용 설정하거나 중지할 수 있습니다.

Autopilot에는 제어 영역과 pod 모두에 적용되는 SLA가 포함됩니다. Autopilot을 사용하면 기본 인프라가 추상화되므로 Kubernetes API 및 배포에 집중할 수 있습니다. Autopilot은 PodSpec에서 정의한 리소스 요구사항을 사용하고 CPU, 메모리, 영구 디스크와 같은 배포 리소스를 프로비저닝합니다.

Autopilot 대신 표준 작업 모드를 사용하는 두 가지 주요 이유는 다음과 같습니다.

  • 더 높은 수준으로 클러스터 구성을 제어해야 합니다.
  • 클러스터에서 Autopilot 제약조건을 충족하지 않는 워크로드를 실행해야 합니다.

Autopilot 모드와 표준 모드 비교

Autopilot을 사용하면 GKE는 클러스터 수명 주기의 다양한 복잡성을 관리합니다. 다음 표에서는 클러스터 작업 모드에 따라 사용할 수 있는 옵션을 보여줍니다.

  • 사전 구성됨: 이 설정은 기본 제공되며 변경할 수 없습니다.
  • 기본값: 이 설정은 사용 설정되어 있지만 재정의할 수 있습니다.
  • 선택사항: 이 설정은 중지되어 있지만 사용 설정할 수 있습니다.
옵션 Autopilot 모드 표준 모드
기본 클러스터 유형 가용성 및 버전:

사전 구성됨: 리전
기본값: 정기 출시 채널
가용성 및 버전:

선택사항:
노드 및 노드 풀 GKE에서 관리합니다. 사용자가 관리, 구성, 지정합니다.
리소스 프로비저닝 GKE는 pod 사양에 따라 리소스를 동적으로 프로비저닝합니다. 추가 리소스를 수동으로 프로비저닝하고 전체 클러스터 크기를 설정합니다. 프로세스를 자동화하는 데 유용하도록 클러스터 자동 확장과 노드 자동 프로비저닝을 구성합니다.
이미지 유형 사전 구성됨: Containerd가 포함된 Container-Optimized OS 다음 중 하나를 선택합니다.
결제 pod 리소스 요청(CPU, 메모리, 임시 스토리지)별로 비용 지불 노드(CPU, 메모리, 부팅 디스크)별로 비용 지불
보안 사전 구성됨:
선택사항:
네트워킹 사전 구성됨:
기본값:
  • 공개 클러스터
  • 자동 CIDR 범위
  • 네트워크 이름/서브넷
선택사항:
선택사항:
업그레이드, 복구, 유지보수 사전 구성됨:
선택사항:
사용자 인증 정보 사전 구성됨: 워크로드 아이덴티티 선택사항:
확장 사전 구성됨: Autopilot은 노드의 모든 확장과 구성을 처리합니다.

기본값:
선택사항:
모니터링 및 로깅 사전 구성됨: Cloud Operations for GKE

기본값: 시스템 및 워크로드 로깅

선택사항: 시스템 전용 로깅
기본값:
선택사항: 시스템 전용 로깅
라우팅 사전 구성됨: pod 기반 라우팅입니다. 네트워크 엔드포인트 그룹(NEG)이 사용 설정됩니다. 노드 기반 패킷 라우팅(기본값) 또는 pod 기반 라우팅을 선택합니다.
클러스터 부가기능 사전 구성됨:
기본값:
선택사항:

1클러스터에서 Cloud NAT를 사용 설정하려면 추가 구성이 필요합니다.

지원되지 않는 클러스터 기능

다음 GKE 클러스터 기능은 Autopilot 클러스터에 지원되지 않습니다.

Compute Engine 인스턴스

보안

부가기능 및 통합

확장

Autopilot은 pod 사양에 따라 클러스터 리소스를 자동으로 확장하므로 pod에 집중할 수 있습니다. pod 수를 자동으로 늘리거나 줄이려면 표준 Kubernetes CPU나 메모리 측정항목을 사용하거나 Cloud Monitoring을 통해 커스텀 측정항목을 사용하여 수평형 pod 자동 확장을 구현하면 됩니다.

허용 가능한 리소스 범위

다음 표에는 Autopilot pod에 허용되는 리소스 범위가 나와 있습니다. 별도로 언급되지 않는 경우 모든 값은 pod의 모든 컨테이너 리소스 요청 합계에 적용됩니다. pod vCPU는 vCPU 0.25개 단위로 제공됩니다. 최솟값 외에도 CPU:메모리 비율은 1 vCPU:1 GiB ~ 1 vCPU:6.5 GiB 범위 이내여야 합니다. 허용 가능한 비율 범위를 벗어나는 리소스는 확장됩니다. 자세한 내용은 리소스 범위 및 비율 관리리소스 제한사항 예시를 참조하세요.

리소스 최소 리소스 최대 리소스
일반 pod DaemonSet pod 모든 pod
CPU 250 mCPU 10 mCPU vCPU 28 개2
메모리 512 MiB 10 MiB 80 GiB2
임시 스토리지 10 MiB(컨테이너당) 10 MiB(컨테이너당) 10 GiB

2일반 pod의 최대 CPU와 메모리 한도는 모든 DaemonSet pod의 리소스 요청 합계에 의해 더욱 줄어듭니다.

기본 컨테이너 리소스 요청

Autopilot은 배포 구성에서 지정한 항목을 사용하여 리소스를 프로비저닝합니다. pod의 컨테이너에 리소스 요청을 지정하지 않으면 Autopilot은 기본값을 적용합니다. 이러한 기본값은 pod의 컨테이너에 리소스 평균량을 제공하도록 설계되었으며 다수의 더 작은 워크로드에 적합합니다.

Autopilot은 pod 사양에 정의되지 않은 리소스에 이러한 기본값을 적용합니다.

리소스 일반 pod의 컨테이너 DaemonSet의 컨테이너
CPU 500 mCPU 50 mCPU
메모리 2 GiB 100 MiB
임시 스토리지 1 GiB 100 MiB

Autopilot 클러스터 한도에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

워크로드 제한사항

Autopilot은 애플리케이션을 실행하는 대부분의 워크로드를 지원합니다. GKE에서 노드 관리와 더욱 간소화된 운영 환경을 제공하기 위해 GKE Standard에 비해 몇 가지 제한사항이 있습니다. 이러한 제한사항의 일부는 보안 권장사항이지만 다른 제한사항을 사용하면 Autopilot 클러스터를 안전하게 관리할 수 있습니다. 워크로드 제한사항은 배포, DaemonSet, ReplicaSet, ReplicationController, StatefulSet, 작업, CronJob에 의해 시작된 pod 등 모든 pod에 적용됩니다.

호스트 옵션 제한사항

GKE에서 노드를 관리하므로 HostPort와 hostNetwork는 허용되지 않습니다. 쓰기 모드에서 hostPath 볼륨을 사용할 수 없지만 읽기 모드에서는 /var/log/ 경로 프리픽스에만 hostPath 볼륨을 사용할 수 있습니다. 워크로드에서는 호스트 네임스페이스를 사용할 수 없습니다.

Linux 워크로드 제한사항

Autopilot은 워크로드에 다음 Linux 기능만 지원합니다.

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

노드 선택기 및 노드 어피니티

영역 어피니티 토폴로지가 지원됩니다. 노드 어피니티노드 선택기topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, cloud.google.com/gke-os-distribution, kubernetes.io/os, kubernetes.io/arch 키에서만 사용되도록 제한됩니다. OS 및 arch의 모든 값은 Autopilot에서 지원되지 않습니다.

Container Threat Detection 없음

Autopilot은 Container Threat Detection을 지원하지 않습니다.

권한이 있는 pod 없음

워크로드의 컨테이너에 대한 권한 모드는 주로 kubelet 또는 네트워킹 설정 변경과 같은 노드를 변경하는 데 사용됩니다. Autopilot 클러스터를 사용하면 노드가 변경되지 않으므로 이러한 유형의 pod도 허용되지 않습니다. 이러한 제한사항은 일부 관리 워크로드에 영향을 미칠 수 있습니다.

pod 어피니티 및 안티어피니티

GKE에서 자동으로 Autopilot의 노드를 관리하지만 pod를 계속 예약할 수 있습니다. Autopilot은 pod 어피니티를 지원하므로 네트워크 효율성을 위해 단일 노드에 pod를 함께 배치할 수 있습니다 예를 들어 pod 어피니티를 사용하여 백엔드 pod가 있는 노드에 프런트엔드 pod를 배포할 수 있습니다. pod 어피니티는 topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone 키에서만 사용되도록 제한됩니다.

또한 Autopilot은 안티어피니티를 지원하므로 단일 장애점이 방지되도록 pod를 여러 노드에 분산할 수 있습니다. 예를 들어 pod 안티어피니티를 사용하여 프런트엔드 pod가 백엔드 pod와 함께 배치되지 않도록 할 수 있습니다.

pod 안티어피니티 사용 시 기본값 및 리소스 제한사항

Autopilot은 pod 안티어피니티를 지원하므로 pod 두 개가 같은 노드에 함께 배치되지 않도록 할 수 있습니다. 안티어피니티를 사용하는 경우 Autopilot은 PodSpec에서 정의한 대로 pod가 올바르게 분리되도록 추가 컴퓨팅 리소스를 할당해야 합니다. pod 안티어피니티를 사용하면 기본값과 최소 리소스 한도가 증가합니다. PodSpec에 나와 있는 모든 컨테이너의 경우:

리소스 기본값
CPU vCPU 0.75 개
메모리 2 GiB
임시 스토리지 1 GiB

pod 안티어피니티를 사용하는 경우 동일한 리소스 제한사항 규칙과 로직이 적용되지만 vCPU가 증가합니다. pod vCPU는 vCPU 최소 0.5개와 vCPU 0.5개 단위(가장 가까운 단위로 올림)로 제공됩니다. 예를 들어 총 vCPU 0.66개를 요청하면(안티어피니티를 사용하는 모든 컨테이너 간에) PodSpec은 허용 중에 수정되어 vCPU 1개로 설정됩니다. pod에는 상위 리소스에 대한 전체 액세스 권한이 있으며 추가 리소스는 모든 컨테이너의 리소스 요청 간에 구분됩니다.

워크로드 분리에만 지원되는 톨러레이션(toleration)

톨러레이션(toleration)은 워크로드 분리에만 지원됩니다. taint는 필요에 따라 노드 자동 프로비저닝에 의해 자동으로 추가됩니다.

리소스 범위 및 비율 관리

  • pod vCPU 단위: pod vCPU는 vCPU 0.25개 단위(올림)로 제공됩니다. 예를 들어 총 vCPU 0.66 개를 요청하면(모든 컨테이너 간에) PodSpec은 허용 중에 수정되어 0.75개로 설정됩니다. pod에는 상위 리소스에 대한 전체 액세스 권한이 있으며 추가 리소스는 모든 컨테이너의 리소스 요청 간에 구분됩니다. 최솟값은 250 milliCPU(mCPU)입니다. DaemonSet vCPU는 10 mCPU 단위로 제공됩니다(가장 가까운 단위로 올림).

  • 메모리와 CPU 비율 범위: vCPU에 대한 메모리 비율 (GiB 단위)은 vCPU 1~6.5 개 범위 이내에 있어야 합니다. 예를 들어 vCPU 1 개, 1 GiB 메모리 또는 vCPU 1 개, 6.5 GiB 메모리인 pod가 있을 수 있지만 vCPU 1 개, 7 GiB 메모리인 pod는 없습니다. GKE는 리소스 요청을 전송하기 위해 너무 낮은 리소스를 확장합니다. 예를 들어 vCPU 1 개와 7 GiB 메모리를 요청하면 PodSpec이 허용 시 vCPU 1.25 개와 7 GiB 메모리로 수정됩니다. 마찬가지로 vCPU 1 개와 800 MiB 메모리를 요청하면 PodSpec은 vCPU 1 개와 1 GiB RAM으로 수정되고 추가 리소스는 컨테이너 간에 분배됩니다.

CPU와 메모리 단위 및 비율 요구사항, 잠재적 리소스 요청 수직 확장은 리소스 요청이 누락된 컨테이너에 기본값이 적용된 후에 계산됩니다.

리소스 요청이 없는 컨테이너의 기본값은 표준 최솟값인 500 mCPU와 1 GiB 메모리입니다. CPU와 메모리의 경우 GKE에서 리소스 요청을 확장하는 경우(예를 들어 최소 요구사항이나 비율 요구사항을 충족하기 위해) 추가 리소스가 컨테이너 간에 균등하게 할당됩니다. 올림값은 컨테이너에 고르게 분산됩니다. 예를 들어 다른 컨테이너보다 메모리가 두 배 많은 컨테이너는 추가 메모리 두 배를 받습니다.

  • 임시 스토리지: 사용 가능한 범위는 10 MiB~10 GiB입니다. 이는 컨테이너 쓰기 가능한 레이어와 emptyDir 마운트에 영향을 미칩니다.

임시 스토리지에는 컨테이너당 최소 요청이 있으므로 컨테이너의 임시 스토리지 요청이 최솟값보다 적으면 Autopilot은 요청을 최소로 증가시킵니다. 임시 스토리지에는 pod당 최소 요청이 없습니다. 임시 스토리지에는 모든 컨테이너에서 누적되는 pod당 최대 요청이 있습니다. 누적값이 최댓값보다 크면 Autopilot은 요청을 다시 최댓값으로 확장하지만 컨테이너 간 요청 비율은 동일하게 유지됩니다.

리소스 제한사항 예시

예시 1: 최소 250 mCPU 미만인 단일 컨테이너의 경우:

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 180 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 250 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
총 pod 리소스 CPU: 250 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB

예시 2: 총 최소 250 mCPU 미만인 여러 컨테이너의 경우 Autopilot은 나머지 리소스를 pod의 모든 컨테이너 간에 균등하게 배포합니다(최대 vCPU 250 개).

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 70 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 84 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
2 CPU: 70 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 83 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
3 CPU: 70 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 83 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
총 pod 리소스 CPU: 250 mCPU
메모리: 1.5 GiB
임시 스토리지: 30 MiB

예시 3: 총 리소스가 250 mCPU 이상인 여러 컨테이너의 경우 CPU는 250 mCPU 배수로 반올림되고 추가 CPU는 원래 요청의 비율에 따라 모든 컨테이너에 분산됩니다. 이 예시에서 원래 누적 CPU는 320 mCPU이며 총 500 mCPU로 수정됩니다. 추가 180 mCPU는 컨테이너 전체에 분산됩니다.

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 170 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 266 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
2 CPU: 80 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 125 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
3 CPU: 70 mCPU
메모리: 0.5 GiB
임시 스토리지: 10 MiB
CPU: 109 mCPU
메모리: 0.5 GiB
임시 스토리지: 10MiB
4 init 컨테이너, 리소스가 정의되지 않음 pod 리소스 수신
총 pod 리소스 CPU: 500 mCPU
메모리: 1.5 GiB
임시 스토리지: 30 MiB

예시 4: CPU가 메모리 양에 비해 너무 낮은 단일 컨테이너의 경우(vCPU 1 개에 최대 6.5 GiB). CPU와 메모리의 최대 허용 비율은 1:6.5입니다. 비율이 이보다 크면 CPU 요청이 증가한 후 필요한 경우 반올림됩니다.

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 250 mCPU
메모리: 4 GiB
임시 스토리지: 10 MiB
CPU: 750 mCPU
메모리: 4 GiB
임시 스토리지: 10 MiB
총 pod 리소스 CPU: 750 mCPU
메모리: 4 GiB
임시 스토리지: 10 MiB

예시 5: 메모리가 CPU 양에 비해 너무 낮은 단일 컨테이너의 경우(vCPU 1 개:최소 1 GiB) CPU와 메모리의 최소 허용 비율은 1:1입니다. 비율이 이보다 낮으면 메모리 요청이 증가합니다.

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: vCPU 4 개
메모리: 1 GiB
임시 스토리지: 10 MiB
CPU: vCPU 4 개
메모리: 4 GiB
임시 스토리지: 10 MiB
총 pod 리소스 CPU: 4 mCPU
메모리: 4 GiB
임시 스토리지: 10 MiB

예시 6: 조정 후 CPU가 메모리 양에 비해 너무 낮은 최소 250 mCPU 미만인 단일 컨테이너의 경우(vCPU 1 개:최대 6.5 GiB)

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 100 mCPU
메모리: 50 MiB
임시 스토리지: 10 MiB
CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 10 MiB
총 pod 리소스 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 10 MiB

예시 7: 임시 스토리지 요청이 10 GiB를 초과하는 단일 컨테이너의 경우 최대 허용 임시 스토리지 요청은 10 GiB입니다. 요청이 최댓값보다 크면 요청은 10 GiB로 줄어듭니다.

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 11 GiB
CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 10 GiB
총 pod 리소스 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 10 GiB

예시 8: 임시 스토리지 요청이 10 GiB를 초과하는 여러 컨테이너의 경우 모든 컨테이너 임시 스토리지 요청이 줄어들어 최종 누적 스토리지 요청 10 GiB를 만듭니다.

컨테이너 번호 원래 리소스 요청 수정된 요청
1 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 5 GiB
CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 2.94 GiB
2 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 6 GiB
CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 3.53 GiB
3 CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 6 GiB
CPU: 250 mCPU
메모리: 256 MiB
임시 스토리지: 3.53 GiB
총 pod 리소스 CPU: 750 mCPU
메모리: 768 MiB
임시 스토리지: 10 GiB

보안 제한사항

컨테이너 격리

Autopilot은 향상된 보안 격리 기능을 제공하며 컨테이너 이스케이프 취약점이 클러스터에 미치는 영향을 제한하는 데 유용한 pod의 강화 구성을 적용합니다.

  • 컨테이너 런타임 기본 seccomp 프로필은 기본적으로 클러스터의 모든 pod에 적용됩니다.
  • CAP_NET_RAW 컨테이너 권한은 모든 컨테이너에서 삭제됩니다. CAP_NET_RAW 권한은 일반적으로 사용되지 않으며 여러 컨테이너 이스케이프 취약점의 주제였습니다. CAP_NET_RAW가 없으면 컨테이너 내부에서 ping을 사용할 수 없습니다.
  • 워크로드 아이덴티티가 적용되며 기본 Compute Engine 서비스 계정과 기타 민감한 노드 메타데이터에 대한 pod 액세스를 방지합니다.
  • spec.ExternalIP가 설정된 서비스는 CVE-2020-8554로부터 보호하기 위해 차단됩니다. 이러한 서비스는 거의 사용되지 않습니다.
  • 다음 StorageType을 사용할 수 있습니다. 다른 StorageType은 노드에 대한 권한이 필요하므로 차단됩니다.

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
    "nfs", "persistentVolumeClaim", "projected", "secret"
    

pod 보안 정책

Autopilot은 컨테이너에 향상된 격리 기능을 제공하는 설정을 적용합니다. Autopilot 클러스터에서는 Kubernetes PodSecurityPolicy, OPA Gatekeeper, 정책 컨트롤러가 지원되지 않습니다.

Autopilot의 보안 경계

Kubernetes 레이어에서 GKE Autopilot 모드는 Kubernetes API를 제공하지만 노드 가상 머신(VM)에 대한 액세스, 수정, 직접 제어 기능을 제한하기 위한 목적으로 높은 권한을 가진 일부 Kubernetes 기본 요소(예: 권한이 있는 pod)를 사용할 권한을 제거합니다.

이러한 제한사항은 GKE Autopilot 모드에 적용되어 워크로드가 노드 VM에 대한 낮은 수준의 액세스 권한을 갖지 못하도록 제한하여 Google Cloud가 노드에 대한 전체 관리 및 pod 수준의 SLA를 제공할 수 있도록 합니다.

Google의 목표는 노드 가상 머신에 대한 의도하지 않은 액세스를 방지하는 것입니다. Google은 Google 취약성 발견 보상 프로그램(VRP)을 통해 해당 취지의 제출을 접수하며 Google VRP 보상 패널 재량에 따라 보고서를 제공합니다.

클러스터 관리자와 같이 권한이 있는 사용자는 기본적으로 GKE 클러스터를 완전히 제어할 수 있습니다. 보안 권장사항에 따라 강력한 GKE/Kubernetes 권한을 광범위하게 부여하지 않고 대신 멀티테넌시 가이드에 설명된 대로 가능한 경우 네임스페이스 관리자 위임을 사용하는 것이 좋습니다.

Autopilot의 워크로드는 GKE Standard 모드와 동일한 보안 기능을 계속 유지하며 단일 테넌트 VM은 독점적으로 사용하기 위해 사용자의 프로젝트에서 프로비저닝됩니다. 또한 Standard와 마찬가지로 각 개별 VM에서 클러스터 내의 Autopilot 워크로드는 보안이 강화되었지만 공유되는 커널이 있는 VM에서 함께 실행될 수 있습니다.

공유 커널은 단일 보안 경계를 나타내므로 고위험 또는 신뢰할 수 없는 워크로드와 같이 강력한 격리가 필요한 경우 멀티 레이어 보안 보호를 제공하는 GKE Sandbox를 사용하여 GKE Standard 클러스터에서 워크로드를 실행하는 것이 좋습니다.

기타 제한사항

인증서 서명 요청

Autopilot 내에 인증서 서명 요청을 만들 수 없습니다.

외부 모니터링 도구

대부분의 외부 모니터링 도구는 제한된 액세스를 요구합니다. Autopilot에서 일부 Google Cloud 파트너의 솔루션을 사용할 수 있습니다. 하지만 모든 솔루션이 지원되지 않으며 Autopilot 클러스터에 커스텀 모니터링 도구를 설치할 수 없습니다.

외부 서비스

외부 IP 서비스는 Autopilot 클러스터에서 허용되지 않습니다. 서비스에 외부 IP를 제공하려면 LoadBalancer 유형의 서비스를 사용하거나 인그레스를 사용하여 서비스를 여러 서비스 간에 공유되는 외부 IP에 추가하면 됩니다.

Init 컨테이너

init 컨테이너는 애플리케이션 컨테이너가 시작되기 전에 순차적으로 실행됩니다. 기본적으로 GKE는 pod에서 사용할 수 있는 전체 리소스를 각 init 컨테이너에 할당합니다.

다른 컨테이너와 달리 컨테이너에 전체 리소스가 포함되도록 init 컨테이너에 리소스 요청을 지정하지 않은 상태로 두는 것이 좋습니다. 더 낮은 리소스를 설정하면 init 컨테이너가 불필요하게 제한되며 더 높은 리소스를 설정하면 pod의 전체 기간에 대한 요금이 증가할 수 있습니다.

관리형 네임스페이스

kube-system 네임스페이스는 관리형입니다. 즉, 이 네임스페이스의 모든 리소스를 변경할 수 없으며 새 리소스를 만들 수 없습니다.

노드 변경사항 없음

GKE는 자동으로 Autopilot 클러스터의 노드를 관리하므로 노드를 변경할 수 없습니다.

변환 없음

표준 클러스터를 Autopilot 모드로 변환하고 Autopilot 클러스터를 표준 모드로 변환할 수 없습니다.

비공개 클러스터의 직접 외부 인바운드 연결 없음

비공개 노드가 있는 Autopilot 클러스터에는 외부 IP가 없으며 인바운드 연결을 직접 수락할 수 없습니다. NodePort에 서비스를 배포하면 인터넷과 같은 VPC 외부에서 이러한 서비스에 액세스할 수 없습니다. Autopilot 클러스터 외부에 애플리케이션을 노출하려면 서비스를 사용합니다. 자세한 내용은 서비스를 사용하여 애플리케이션 노출을 참조하세요.

pod 버스팅 없음

표준 클러스터의 경우 pod를 구성하여 노드에서 사용하지 않는 용량으로 버스트할 수 있습니다. Autopilot 클러스터의 경우 모든 pod에는 요청에 대해 설정된 한도가 있으므로 리소스 버스팅이 불가능합니다. pod 사양에서 리소스 요청에 적절한 리소스를 정의하고 버스팅을 사용하지 않는지 확인하는 것이 중요합니다.

포트 전달 없음

Autopilot 클러스터는 kubectl port-forward 명령어를 지원하지 않습니다.

SSH 없음

더 이상 Autopilot에서 노드를 프로비저닝하거나 관리하지 않으므로 SSH 액세스 권한이 없습니다. GKE는 노드 상태와 노드에서 실행되는 모든 Kubernetes 구성요소 등 노드의 모든 운영 측면을 처리합니다.

리소스 한도

Autopilot 클러스터에서 각 pod는 요청과 동일한 한도가 있는 보장된 QoS 클래스 pod로 취급됩니다. 리소스 한도가 지정되어 있지 않으면 Autopilot은 자동으로 요청과 동일한 리소스 한도를 설정합니다. 리소스 한도를 지정하면 한도가 재정의되어 요청과 동일하도록 설정됩니다.

웹훅 제한사항

Autopilot 클러스터용 커스텀 변형 허용 웹훅을 만들 수 없지만 커스텀 검증 웹훅을 만들 수 있습니다.

문제 해결

클러스터를 만들 수 없음: 등록된 노드 0개

Autopilot 클러스터를 만들 때 다음 오류가 발생하면서 실패합니다.

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

이 문제를 해결하려면 기본 Compute Engine 서비스 계정이 사용 중지되지 않았는지 확인합니다. 다음 명령어를 실행하여 확인합니다.

   gcloud iam service-accounts describe SERVICE_ACCOUNT

SERVICE_ACCOUNT를 숫자로 된 서비스 계정 ID 또는 서비스 계정 이메일 주소(예: 123456789876543212345 또는 my-iam-account@somedomain.com)로 바꿉니다.

다음 단계