GKE에 에이전트 Substrate 설치

GKE의 Agent Substrate는 GKE 클러스터에서 에이전트 워크로드를 효율적으로 실행합니다. 애플리케이션은 유휴 에이전트를 정지하고, 시스템은 에이전트가 다시 작동해야 할 때 에이전트를 복원합니다. GKE 기반 Agent Substrate는 GKE Standard 클러스터에 설치할 수 있는 오픈소스 소프트웨어입니다. GKE의 Agent Substrate와 GKE의 Agent Sandbox를 비교하고 AI 에이전트 워크로드에 적합한 아키텍처를 선택하려면 GKE에서 AI 에이전트 워크로드 아키텍처 계획을 참조하세요.

이 문서는 GKE의 Agent Substrate를 위해 Google Cloud 프로젝트와 GKE 클러스터를 준비하는 데 도움이 되며, 설치 프로그램을 실행하는 방법을 설명하고 설치 시 생성되는 리소스를 설명합니다.

가격 책정

GKE의 Agent Substrate는 추가 비용 없이 제공됩니다. GKE 가격 책정은 사용자가 만드는 리소스에 적용됩니다.

제한사항

GKE의 Agent Substrate에는 다음과 같은 설치 제한사항이 있습니다.

  • Cloud Shell: Cloud Shell은 5GB의 영구 디스크 스토리지를 제공하므로 설치에 충분하지 않기 때문에 Cloud Shell의 GKE에 에이전트 기판을 설치할 수 없습니다. 로컬 머신에서 설치 프로그램을 실행해야 합니다.
  • 클러스터 모드: GKE Standard 클러스터에서만 GKE에 Agent Substrate를 설치할 수 있습니다. Autopilot 클러스터는 지원되지 않습니다.
  • 클러스터 버전: 클러스터의 컨트롤 플레인과 노드 풀 모두 GKE 버전 1.37 이상을 실행해야 합니다. 1.37 이전 버전은 지원되지 않습니다.
  • 출시 채널: 확장 출시 채널에 등록된 클러스터의 GKE에는 Agent Substrate를 설치할 수 없습니다. 설치 프로그램은 클러스터에서 Kubernetes 베타 API를 사용 설정하며 확장 채널은 명시적으로 사용 설정된 베타 API를 지원하지 않습니다.
  • 머신 유형: 혼합 CPU 아키텍처에서 실행되는 머신 시리즈(예: E2 머신 유형)를 사용할 수 없습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
    • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
  • gcloud CLI에 다음 구성요소를 설치합니다.
    • kubectl
    • gke-gcloud-auth-plugin
  • 로컬 머신에 다음 도구가 설치되어 있는지 확인합니다.
    • Git: Agent Substrate 저장소를 클론합니다.
    • 소스 코드로 배포되는 설치 프로그램의 프로그램을 실행하는 Go
    • make를 입력하여 설치 프로그램을 시작합니다.
    • GKE의 Agent Substrate 컨테이너 이미지를 빌드하기 위한 Docker 및 Buildx 플러그인
    • sha256sum, zstd, unzip, jq: microVM 런타임을 사용하려는 경우 이를 설정합니다. 이러한 도구 중 하나라도 누락된 경우 설치 프로그램은 마이크로VM 런타임을 제공하지 않습니다.

  • 설치 프로그램이 빌드하는 이미지를 푸시할 수 있도록 클러스터 리전의 Artifact Registry에 인증하도록 Docker를 구성합니다.

    gcloud auth configure-docker REGION-docker.pkg.dev

    REGION을 클러스터의 리전으로 바꿉니다(예: us-west1). 자세한 내용은 Docker용 Artifact Registry에 대한 인증 구성을 참조하세요.

  • 설치 프로그램은 사용자를 대신하여 API를 사용 설정하고 리소스를 프로비저닝하므로 다음 명령어를 실행하여 애플리케이션 기본 사용자 인증 정보(ADC)를 설정합니다.

    gcloud auth application-default login

    ADC 인증에 대한 자세한 내용은 애플리케이션 기본 사용자 인증 정보 설정을 참조하세요.

필요한 역할

GKE에 Agent Substrate를 설치하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요.

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

클러스터 요구사항

설치 프로그램에서 클러스터를 만들도록 허용하면 GKE용 Agent Substrate의 모든 요구사항을 충족하는 클러스터가 자동으로 구성됩니다.

기존 클러스터의 GKE에 Agent Substrate를 설치하는 경우 해당 클러스터는 다음 요구사항을 충족해야 합니다.

  • GKE Standard에서 실행됩니다(GKE의 Agent Substrate는 Standard 클러스터에서만 지원됨).
  • 컨트롤 플레인과 노드 풀 모두에서 GKE 버전 1.37 이상을 실행합니다. 컨트롤 플레인이 이전 버전을 실행하는 경우 먼저 컨트롤 플레인을 업그레이드합니다. 그런 다음 노드가 포드 인증서를 포드에 마운트할 수 있도록 이전 버전을 실행하는 노드 풀을 업그레이드합니다.
  • 확장 출시 채널에 등록되지 않음 자세한 내용은 제한사항을 참조하세요.
  • GKE Dataplane V2를 사용합니다.
  • 노드에 c3-standard-4 이상의 머신 유형을 사용합니다.

  • 노드당 약 800개 이상의 동시 샌드박스를 실행하려는 경우 클러스터는 Linux 커널에서 파일 시스템 모니터링(inotify) 및 주소 결정 프로토콜(ARP)의 인접 테이블에 대해 더 높은 한도를 가진 노드를 사용합니다. 이러한 높은 한도가 없으면 샌드박스가 시작되지 않고 네트워킹이 중단될 수 있습니다. 노드에는 다음 커널 설정이 필요합니다.

    • net.ipv4.neigh.default.gc_thresh1: 4096
    • net.ipv4.neigh.default.gc_thresh2: 16384
    • net.ipv4.neigh.default.gc_thresh3: 32768
    • fs.inotify.max_user_instances: 65536
    • fs.inotify.max_user_watches: 1048576

    설치 프로그램은 생성하는 클러스터에만 이러한 설정을 자동으로 적용합니다. 기존 클러스터의 노드 풀에 이러한 설정을 적용하려면 노드 시스템 구성을 사용합니다. 자세한 내용은 Sysctl 구성 옵션을 참조하세요.

GKE에 Agent Substrate 설치

GKE에 Agent Substrate를 설치하려면 로컬 터미널에서 다음 명령어 중 하나를 실행합니다.

  • 자체 워크로드에 설치하려면 다음 명령어를 실행합니다.

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash

  • 카운터 데모를 설치하고 사용해 보려면 다음 명령어를 실행합니다.

    curl -sSL https://raw.githubusercontent.com/ai-on-gke/substrate-gke/main/install.sh | bash -s -- --demo

대화형 설치 프로그램은 컨테이너 이미지와 프로젝트, 클러스터, 스토리지, 인그레스 설정을 입력하라는 메시지를 표시합니다. 설치 프로그램은 가능한 경우 권장되는 기본값을 제안하며, 이를 수락하거나 맞춤설정할 수 있습니다.

  • 컨테이너 이미지(필수): 설치 프로그램에서 이미지를 선택하라는 메시지가 표시되면 소스에서 빌드를 선택합니다. 설치 프로그램은 업스트림 에이전트 기판 저장소에서 이미지를 빌드하고 프로젝트의 Artifact Registry 저장소에 푸시합니다. 기본적으로 설치 프로그램은 최신 버전의 Agent Substrate를 빌드합니다. 다른 버전을 빌드하려면 업스트림 저장소에서 브랜치, 태그 또는 전체 커밋 SHA를 입력합니다.
  • 프로젝트 ID(필수): 리소스가 프로비저닝될 Google Cloud 프로젝트를 지정합니다. gcloud CLI에 기본 프로젝트를 구성한 경우 설치 프로그램에서 해당 프로젝트 ID를 사용합니다.
  • 클러스터(필수): 설치 프로그램에서 권장 기본값으로 새 GKE 클러스터를 만들도록 할지 또는 기존 클러스터의 GKE에 Agent Substrate를 설치할지 선택합니다. 기존 클러스터에 설치하도록 선택하는 경우 클러스터 요구사항 섹션의 요구사항을 충족하는지 확인합니다.
  • 스냅샷 버킷(선택사항): 커스텀 Cloud Storage 버킷 이름을 지정하거나 설치 프로그램이 ate-snapshots-<project>-<cluster>-<zone>이라는 기본 버킷을 만들도록 비워둡니다. 기본 이름에는 클러스터 이름이 포함되므로 동일한 프로젝트 및 영역의 클러스터는 버킷을 공유하지 않습니다. 설치 프로그램은 이름에 -assets 서픽스를 추가하여 애셋 버킷을 만들고 버킷 이름은 최대 63자(영문 기준)까지 가능하므로 커스텀 이름은 최대 56자(영문 기준)까지 가능합니다. 기본 이름이 56자(영문 기준)를 초과하면 설치 프로그램이 이름을 줄이고 해시를 추가합니다.
  • 인그레스 클라이언트(필수): 애플리케이션의 프런트엔드 또는 백엔드 서비스와 같이 액터에 요청을 전송하는 워크로드의 SPIFFE ID를 입력합니다. SPIFFE ID는 네임스페이스와 포드가 실행되는 Kubernetes 서비스 계정으로 워크로드를 식별합니다. 예를 들어 shop 네임스페이스에서 frontend 서비스 계정으로 실행되는 포드에는 SPIFFE ID spiffe://cluster.local/ns/shop/sa/frontend가 있습니다. ID는 네임스페이스와 서비스 계정에만 종속되므로 아직 배포하지 않은 클라이언트의 ID를 입력할 수 있습니다. 여러 ID를 입력하는 경우 쉼표로 구분하세요. 요청은 인그레스 라우터를 통해 Actor에 도달하며, 이 라우터는 SPIFFE ID가 이 목록에 있는 포드 인증서를 제시하는 클라이언트만 허용합니다. 목록에 있는 모든 클라이언트는 모든 Actor에 연결할 수 있습니다. --demo 플래그를 포함하면 설치 프로그램은 ID를 요청하는 대신 카운터 데모의 포드만 허용합니다. 설치 후 클라이언트를 추가하려면 substrate-gke README의 인그레스 라우터를 통해 액터에 도달을 참조하세요.

설치 프로그램의 역할

설치 프로그램은 사용자를 대신하여 다음 프로그램을 실행합니다.

  • setup-gcp: 필요한 Google Cloud 리소스를 만들거나 확인하고, API를 사용 설정하고, GKE 클러스터(기존 클러스터를 사용하지 않기로 선택한 경우) 및 Cloud Storage 버킷을 만들고, IAM 정책을 구성합니다.
  • ate-setup: GKE의 Agent Substrate 컨테이너 이미지와 컨트롤러를 GKE 클러스터에 배포합니다.

먼저 설치 프로그램은 Google Cloud 프로젝트를 다음과 같이 변경합니다.

  1. GKE의 에이전트 기판에 필요한 Google Cloud API를 사용 설정합니다.
  2. 버전 1.37 이상을 실행하고 다음 설정이 있는 GKE Standard 클러스터(기존 클러스터를 사용하지 않는 경우)를 만듭니다.
    • GKE용 워크로드 아이덴티티 제휴: GKE의 에이전트 기판이 노드에 키를 저장하지 않고도 Cloud Storage에 액세스할 수 있습니다.
    • GKE Dataplane V2: 수신 요청을 에이전트로 라우팅하는 데 필요한 네트워킹을 처리합니다.
    • 관리형 OpenTelemetry: 클러스터에서 측정항목과 trace를 수집합니다.
  3. GKE 기반 Agent Substrate에서 사용하는 Cloud Storage 버킷을 만듭니다. 하나는 스냅샷용이고 다른 하나는 마이크로 VM 런타임에 필요한 파일용입니다. 두 번째 버킷의 이름은 스냅샷 버킷 이름 뒤에 -assets 서픽스가 붙은 형태입니다.
  4. 설치 프로그램이 빌드하는 컨테이너 이미지에 대해 ate-images라는 Artifact Registry 저장소를 만듭니다.
  5. GKE 기반 Agent Substrate에서 스냅샷을 전송하는 데 사용하는 ate-snapshot-transfer라는 서비스 계정을 만듭니다.
  6. GKE 노드, GKE 구성요소의 에이전트 기판, ate-snapshot-transfer 서비스 계정에 버킷 및 컨테이너 이미지에 액세스하는 데 필요한 IAM 권한을 부여합니다.
  7. GKE 기반 Agent Substrate 라우팅 지연 시간, 스냅샷 크기, gRPC 트래픽을 차트로 표시하는 Cloud Monitoring 대시보드를 만듭니다.

그런 다음 설치 프로그램은 클러스터를 다음과 같이 변경합니다.

  1. GKE의 Agent Substrate Kubernetes 커스텀 리소스를 클러스터에 추가합니다. 예를 들어 WorkerPool(유휴 샌드박스가 준비 상태로 유지되는 수 정의) 및 SandboxConfig(샌드박스 런타임 정의)가 있습니다. 에이전트가 사용하는 컨테이너 이미지와 리소스를 정의하는 ActorTemplate 및 작업 수행자와 같은 GKE의 다른 Agent Substrate 리소스는 Kubernetes 리소스가 아닙니다. 액터와 워커를 관리하기 위한 kubectl 플러그인인 kubectl ate 플러그인을 사용하여 GKE API의 Agent Substrate를 통해 이를 관리합니다. 플러그인을 설치하려면 kubectl ate 플러그인 설치를 참고하세요.
  2. GKE의 Agent Substrate 구성요소와 Actor를 식별하는 인증서를 발급하는 인증 기관을 설정합니다. 구성요소는 mTLS를 사용하여 서로 인증하기 위해 이러한 인증서를 제공합니다.
  3. GKE의 Agent Substrate 구성요소를 클러스터에 배포하고, 액터 및 작업자의 상태를 추적하는 PostgreSQL 데이터베이스도 함께 배포합니다. 데이터베이스는 500GiB 영구 디스크에 데이터를 저장합니다. 설치 프로그램은 데이터베이스와 모든 컨트롤 플레인 포드가 준비될 때까지 기다립니다. 프로덕션 클러스터의 경우 설치 프로그램을 실행하기 전에 PostgreSQL 데이터베이스 및 시스템 인프라 구성요소를 전용 노드 풀로 격리할 수 있습니다. 자세한 내용은 시스템 인프라 및 워커 노드 풀 격리를 참조하세요.

GKE의 Agent Substrate는 구성요소를 ate-system 및 podcertificate-controller-system 네임스페이스 내에서 일반 워크로드로 배포합니다. 기존 클러스터에 설치하는 경우 설치 프로그램은 GKE용 워크로드 아이덴티티 제휴, 관리형 OpenTelemetry, podcertificaterequests 및 clustertrustbundles Kubernetes API의 베타 버전과 같은 기능이 사용 중지되어 있으면 이를 사용 설정하도록 클러스터를 업데이트합니다. 베타 API를 사용 설정하면 GKE 컨트롤 플레인이 업데이트되며 약 10분이 소요됩니다.

배포되는 구성요소에는 GKE의 Agent Substrate가 기본적으로 각 에이전트를 실행 중인 노드에서 격리하는 데 사용하는 gVisor 기반 런타임이 포함됩니다. 선택적 단계 중에 마이크로VM 런타임을 선택하면 설치 프로그램은 마이크로VM 런타임에 필요한 파일을 Cloud Storage에 업로드하고 해당 파일을 가리키는 microvm라는 클러스터 전체 SandboxConfig 리소스를 적용합니다.

마이크로 VM 런타임을 사용하는 작업자에게는 가상 머신을 실행할 수 있는 노드가 필요합니다. 설치 프로그램이 클러스터를 만들면 생성되는 노드 풀에 중첩된 가상화가 사용 설정됩니다. 고급 설정을 선택하고 머신 유형을 변경하는 경우 C3, C4, N2, N4와 같이 중첩 가상화를 지원하는 머신 시리즈를 선택합니다.

기존 클러스터의 GKE에 Agent Substrate를 설치하는 경우 설치 프로그램은 클러스터에 노드 풀을 추가하지 않습니다. microVM 런타임을 사용하려면 클러스터에 중첩된 가상화가 사용 설정되어 있거나 x86 베어메탈 머신 유형을 사용하는 노드 풀이 필요합니다. 노드 풀을 만들 때만 중첩된 가상화를 사용 설정할 수 있습니다. 클러스터에 이러한 노드 풀이 없으면 마이크로VM 런타임을 선택할 때 설치 프로그램에서 경고를 표시합니다. 계속하면 마이크로VM 작업자가 Pending 상태로 유지됩니다. taint를 포함하여 이러한 노드 풀을 구성하는 방법에 대한 자세한 내용은 substrate-gke 리드미의 샌드박스 런타임을 참조하세요.

일시적인 네트워크 오류 또는 토큰 만료 등으로 인해 설치가 실패하면 명령어를 다시 실행합니다. 설치 프로그램은 기존 리소스를 보존하고 중단된 지점부터 다시 시작합니다.

GKE의 기존 Agent Substrate 설치를 업그레이드하려면 설치 프로그램을 실행하고 설치된 클러스터 업그레이드를 선택합니다. 이 옵션은 클러스터를 변경하지 않습니다. 대신 설치 프로그램은 설치된 버전과 업그레이드할 버전의 소스 코드를 다운로드하고 업그레이드 Runbook에서 사용하는 ~/ate-upgrade 디렉터리를 준비합니다. 업그레이드를 수행하려면 설치 프로그램이 출력하는 명령어를 실행한 후 첫 번째 단계부터 업스트림 에이전트 기판 저장소의 업그레이드 런북을 따릅니다. 런북은 동일한 마이너 버전의 이후 패치 출시 버전으로의 업그레이드와 버전 1.0 이상의 경우 다음 마이너 버전으로의 업그레이드를 지원합니다. 1.0 이전 버전의 경우 이후 부 버전으로 이동하려면 다시 설치해야 합니다. 자세한 내용은 substrate-gke README의 설치된 클러스터 업그레이드를 참조하세요.

추가 단계(선택 사항)

핵심 구성요소를 배포한 후 설치 프로그램은 다음과 같은 선택적 단계를 제공합니다.

  • Filestore CSI 드라이버: GKE의 Agent Substrate에 구성된 Filestore CSI 드라이버를 설치합니다. 에이전트가 다른 노드에서 재개될 때 사용할 수 있는 영구 스토리지가 필요한 경우 이 옵션을 선택합니다. 각 에이전트는 자체 스토리지를 가지며 다른 에이전트와 공유되지 않습니다. Filestore 에이전트 볼륨에 대한 프로덕션 지원은 제한된 정식 버전이므로 액세스를 요청해야 합니다. 자세한 내용은 GKE에서 Agent Substrate와 함께 Filestore 에이전트 볼륨 사용을 참조하세요. 클러스터에 관리형 GKE Filestore 부가기능이 사용 설정된 경우 설치 프로그램은 드라이버를 배포하기 전에 이를 사용 중지합니다. 설치 프로그램은 gcp-filestore-csi-driver 네임스페이스에 드라이버를 배포하고 드라이버에 필요한 IAM 권한이 있는 substrate-filestore-csi라는 서비스 계정을 만듭니다.
  • 노드 풀 자동 확장: 노드 풀에서 GKE 클러스터 자동 확장을 사용 설정합니다. 풀의 최소 및 최대 노드 수를 지정합니다. 수요가 급증할 때 GKE가 자동으로 노드를 추가하고 에이전트가 정지될 때 노드를 삭제하도록 하려면 이 옵션을 선택합니다. 예측 가능한 컴퓨팅 비용으로 고정 노드 수를 선호하는 경우 이 옵션을 건너뜁니다. 커스텀 ComputeClass, 대기 용량 버퍼, 활성 액터의 축소 보호를 사용하여 자동 하드웨어 대체 기능을 구성하려면 GKE의 Agent Substrate를 위한 인프라 설계를 참고하세요.
  • 샌드박스 런타임: 에이전트를 격리하는 런타임을 선택할 수 있습니다. 설치 프로그램은 핵심 구성요소의 일부로 gVisor 런타임을 설치하므로 gVisor 런타임에는 추가 구성이 필요하지 않습니다. 하드웨어 가상화를 사용하는 격리를 원하는 경우 microVM 런타임을 선택합니다. 기존 클러스터에 이 옵션을 선택하기 전에 클러스터에 중첩 가상화가 사용 설정되었거나 x86 베어메탈 머신 유형을 사용하는 노드 풀이 있는지 확인하세요. 자세한 내용은 설치 프로그램의 역할을 참고하세요.
  • 카운터 데모: 에이전트 정지 및 복원을 보여주는 예시 워크로드를 배포합니다. 이 단계는 설치 프로그램을 시작할 때 --demo 플래그를 포함하는 경우에만 표시됩니다. 설치 후 클러스터를 테스트하려면 이 옵션을 선택합니다. 자세한 내용은 카운터 데모 사용해 보기를 참고하세요.

설치 확인

설치가 성공했고 핵심 구성요소가 실행 중인지 확인하려면 다음 명령어를 실행하고 모든 포드의 상태가 Running인지 확인합니다.

kubectl get pods -n ate-system
kubectl get pods -n podcertificate-controller-system

kubectl ate 플러그인 설치:

Actor 및 ActorTemplate 리소스를 관리하려면 설치한 Agent Substrate 버전의 소스 코드에서 kubectl ate 플러그인을 설치합니다.

git clone --depth 1 --branch VERSION https://github.com/agent-substrate/substrate.git
cd substrate
go install ./cmd/kubectl-ate

VERSION를 설치한 Agent Substrate 버전(예: 설치 프로그램의 기본 버전인 v1.0.0)으로 바꿉니다.

go install 명령어는 플러그인을 Go 작업공간의 bin 디렉터리에 배치합니다. kubectl 도구는 해당 디렉터리가 PATH 환경 변수에 있는 경우에만 플러그인을 찾습니다. PATH 환경 변수에 해당 디렉터리가 포함되어 있지 않으면 kubectl ate 명령어를 실행하기 전에 추가합니다.

export PATH="$PATH:$(go env GOPATH)/bin"

카운터 데모 사용해 보기

설치 프로그램을 실행할 때 --demo 플래그를 포함하고 카운터 데모를 배포하도록 선택한 경우 설치 프로그램은 메모리 및 파일의 요청을 계산하는 웹 서버에 대해 WorkerPool 및 ActorTemplate를 배포합니다. GKE의 Agent Substrate는 서버를 실행하는 Actor를 정지하고 복원할 때 두 개수를 모두 보존합니다.

설치가 완료되면 설치 프로그램은 데모의 다음 단계, 즉 kubectl ate 플러그인을 설치하는 명령어와 ActorTemplate에서 Actor를 만드는 명령어를 출력합니다. kubectl ate 명령어를 실행하기 전에 kubectl ate 플러그인 설치에 설명된 대로 플러그인이 PATH 환경 변수에 있는지 확인합니다.

설치 프로그램은 Actor에 요청을 전송하는 명령어를 출력하지 않습니다. 인그레스 라우터는 SPIFFE ID가 허용 목록에 있는 포드 인증서를 제공하는 클라이언트만 허용하므로 로컬 머신에서 직접 전송하는 요청을 거부합니다. 데모에 대한 자세한 내용은 설치 프로그램이 기본적으로 배포하는 Agent Substrate 버전 1.0.0의 카운터 데모 리드미를 참조하세요. 설치 프로그램이 설정한 클러스터에서 포트 전달을 통해 요청을 전송하는 README 단계는 동일한 이유로 작동하지 않습니다.

GKE에서 Agent Substrate 제거

설치가 완료되고 종료되면 설치 프로그램은 환경에 맞춤설정된 정리 명령어를 출력합니다.

설치 중에 생성된 리소스를 삭제하려면 다음 옵션 중 하나를 선택합니다.

  • 기존 클러스터에서 GKE의 Agent Substrate 삭제: 기존 클러스터에 설치했으며 클러스터와 다른 워크로드를 유지하려면 설치 프로그램에서 출력하는 ate-setup delete ate-system 명령어를 실행하여 GKE의 Agent Substrate 구성요소만 삭제합니다. 설치 프로그램은 설치 중에 구성된 프로젝트, 클러스터, 위치 값으로 이 명령어를 자동 입력합니다.

  • 모든 리소스(클러스터 포함) 삭제: GKE 클러스터, 스냅샷 및 애셋 버킷, ate-snapshot-transfer 서비스 계정, IAM 바인딩, 대시보드, ate-images Artifact Registry 저장소를 삭제하려면 설치 프로그램이 출력하는 cleanup-gcp 명령어를 실행합니다. 설치 프로그램은 설치 중에 구성된 프로젝트, 클러스터, 위치, 버킷 값으로 이 명령어를 자동 입력합니다. 이 명령어는 상대 경로를 사용하여 tools/cleanup-gcp 스크립트를 실행하므로 설치 프로그램이 substrate-gke 저장소를 클론한 디렉터리에서 명령어를 실행합니다. 기본적으로 설치 프로그램은 저장소를 ~/.substrate-gke 디렉터리에 클론합니다.

    프로젝트의 다른 클러스터가 GKE에서 Agent Substrate를 실행하는 경우 명령어에 --cluster-scoped 플래그를 추가합니다. 이 플래그는 해당 클러스터가 공유하는 대시보드, ate-snapshot-transfer 서비스 계정, 프로젝트 수준 IAM 바인딩을 유지합니다. --cluster-scoped 플래그는 ate-images 저장소를 유지하지 않습니다. 동일한 리전의 다른 클러스터에서 ate-images 저장소를 사용하는 경우 명령어 끝에 --keep-repository 플래그를 추가합니다. 자세한 내용은 substrate-gke 리드미의 '해체' 섹션을 참조하세요.

cleanup-gcp 명령어는 다음 리소스를 삭제하지 않습니다.

  • PostgreSQL 데이터베이스의 영구 디스크: GKE는 클러스터를 삭제할 때 영구 디스크를 유지하므로 500GiB 디스크에 대한 요금이 계속 청구됩니다. 디스크를 삭제하려면 설치 프로그램이 출력하는 ate-setup delete ate-system 명령어를 실행합니다. 그런 다음 kubectl get pv 명령어가 더 이상 ate-system/data-postgres-0 클레임의 볼륨을 나열하지 않을 때까지 기다린 후 cleanup-gcp를 실행합니다. 클러스터를 이미 삭제한 경우 다음 명령어를 실행하여 디스크를 찾은 후 gcloud compute disks delete 명령어를 실행하여 디스크를 삭제합니다.

    gcloud compute disks list --filter="description~data-postgres-0"

  • substrate-filestore-csi 서비스 계정: Filestore CSI 드라이버를 실행하는 프로젝트의 모든 클러스터가 이 서비스 계정을 공유합니다. 드라이버를 설치했고 프로젝트의 다른 클러스터에서 드라이버를 실행하지 않는 경우 다음 명령어를 실행하여 서비스 계정을 삭제합니다.

    gcloud iam service-accounts delete substrate-filestore-csi@PROJECT_ID.

    PROJECT_ID를 프로젝트 ID로 바꿉니다.

다음 단계