애플리케이션 전송으로 애플리케이션 관리


이 페이지에서는 애플리케이션 전송을 통해 NGINX 배포를 구성하는 과정을 안내합니다. 배포는 stagingprod라는 두 가지 환경에서 실행됩니다. prod 환경은 일반 구성을 사용하고 staging 환경은 약간 수정된 구성을 사용합니다.

요구사항

이 가이드를 완료하려면 다음이 필요합니다.

  • 로컬에 설치된 Git 2.19.2 이상.
  • 비공개 저장소를 만들 수 있는 권한이 있는 GitHub 또는 GitLab 계정. 애플리케이션 전송은 GitHub 및 GitLab 저장소만 지원합니다.
  • GKE 버전 1.15 이상을 실행하는 클러스터
  • clusterAdmin 권한이 있는 사용자
  • 로컬에 설치된 Kustomize. 이 설치 가이드를 참고할 수 있습니다.
  • 배포 저장소에서 Kubernetes 구성 파일 유효성을 검사하려면 Docker를 설치해야 합니다.

시작하기 전에

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

다음 방법 중 하나를 사용하여 기본 gcloud 설정을 진행합니다.

  • gcloud init를 사용하여 기본값 설정 과정을 진행합니다.
  • gcloud config를 사용하여 프로젝트 ID, 영역, 리전을 개별적으로 설정합니다.

gcloud init 사용

One of [--zone, --region] must be supplied: Please specify location 오류가 표시되면 이 섹션을 완료합니다.

  1. gcloud init를 실행하고 다음 안내를 따르세요.

    gcloud init

    원격 서버에서 SSH를 사용하는 경우 --console-only 플래그를 사용하여 다음 명령어로 브라우저를 실행하지 못하게 할 수 있습니다.

    gcloud init --console-only
  2. 안내를 따라 gcloud에서 Google Cloud 계정을 사용하도록 승인합니다.
  3. 새 구성을 만들거나 기존 구성을 선택합니다.
  4. Google Cloud 프로젝트를 선택합니다.
  5. 영역 클러스터의 기본 Compute Engine 영역이나 리전 또는 Autopilot 클러스터의 리전을 선택합니다.

gcloud config 사용

  • 기본 프로젝트 ID를 설정합니다.
    gcloud config set project PROJECT_ID
  • 영역 클러스터를 사용하는 경우 기본 컴퓨팅 영역을 설정합니다.
    gcloud config set compute/zone COMPUTE_ZONE
  • Autopilot 또는 리전 클러스터를 사용하는 경우 기본 컴퓨팅 리전을 설정합니다.
    gcloud config set compute/region COMPUTE_REGION
  • gcloud를 최신 버전으로 업데이트합니다.
    gcloud components update
  • GitHub 또는 GitLab 계정에 SSH 키를 추가합니다.
  • 키를 ssh로 테스트합니다.

    GitHub

    sh ssh -T git@github.com

    GitLab

    sh ssh -T git@gitlab.com

    연결 세부정보 또는 키 암호를 확인하라는 메시지가 표시될 수 있습니다. 연결에 성공하면 터미널에 메시지가 출력됩니다.

애플리케이션 전송 설정

애플리케이션 전송을 사용하려면 다음을 수행해야 합니다.

  1. 애플리케이션 전송이 사용 설정된 새 클러스터를 만들거나 버전 1.15 이상을 실행하는 기존 GKE 클러스터에서 새 클러스터를 사용 설정합니다.
  2. 애플리케이션 전송 명령줄 도구인 appctl을 설치합니다.

애플리케이션 전송을 사용하여 새 클러스터 만들기

gcloud 도구 또는 Cloud Console을 사용하여 애플리케이션 전송이 사용 설정된 새 클러스터를 만들 수 있습니다.

gcloud

클러스터 만들기:

gcloud beta container clusters create CLUSTER_NAME \
      --cluster-version CLUSTER_VERSION\
      --addons ApplicationManager

다음을 바꿉니다.

  • CLUSTER_NAME: 새 클러스터의 이름입니다.
  • CLUSTER_VERSION: 새 클러스터의 버전입니다. GKE 1.15 이상이어야 합니다.

콘솔

  1. Cloud Console에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine으로 이동

  2. 만들기를 클릭합니다.

  3. 표준 섹션에서 구성을 클릭합니다.

  4. 클러스터의 이름을 지정합니다.

  5. 1.15.x 이상의 제어 영역 버전을 선택합니다.

  6. 원하는 대로 클러스터를 구성합니다.

  7. 탐색창의 클러스터에서 기능을 클릭합니다.

  8. 애플리케이션 관리자 사용 설정 체크박스를 선택합니다.

  9. 만들기를 클릭합니다.

기존 클러스터에 애플리케이션 전송 사용 설정

gcloud 도구 또는 Cloud Console을 사용하여 기존 클러스터에서 애플리케이션 전송을 사용 설정할 수 있습니다.

gcloud

기존 클러스터에서 애플리케이션 전송을 사용 설정하려면 다음 명령어를 실행합니다.

gcloud beta container clusters update CLUSTER_NAME \
      --update-addons ApplicationManager=ENABLED

CLUSTER_NAME을 기존 클러스터 이름으로 바꿉니다.

콘솔

  1. Cloud Console에서 Google Kubernetes Engine 페이지로 이동합니다.

    Google Kubernetes Engine으로 이동

  2. 클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.

  3. 기능에서 애플리케이션 관리자 필드 옆에 있는 애플리케이션 관리자 수정을 클릭합니다.

  4. 애플리케이션 관리자 사용 설정 체크박스를 선택합니다.

  5. 변경사항 저장을 클릭합니다.

설치 확인

애플리케이션 전송 설치 상태를 확인하려면 다음을 수행하세요.

  1. 배포 상태를 확인합니다.

    kubectl get deployment application-controller-manager -n application-system
    

    출력은 다음과 비슷합니다.

    NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
    application-controller-manager   2/2     2            2           1h
    

    application-controller-manager 배포에는 사용 가능한 pod가 2개 있어야 합니다.

  2. StatefulSet 상태를 확인합니다.

    kubectl get statefulset kalm-controller-manager -n kalm-system
    

    출력은 다음과 비슷합니다.

    NAME                      READY   AGE
    kalm-controller-manager   1/1     1h
    

    kalm-controller-manager StatefulSet에는 준비된 pod가 1개 있어야 합니다.

appctl 설치

애플리케이션 전송 명령줄 도구 appctl을 설치하려면 gcloud 도구를 사용하여 pkg를 설치합니다.

gcloud components install pkg

클러스터에 애플리케이션 전송을 사용 설정하고 pkg를 설치한 후 첫 번째 애플리케이션을 배포할 수 있습니다.

애플리케이션 배포

애플리케이션을 배포하려면 다음 단계를 따르세요.

  1. 새 Git 저장소를 만들거나 기존 저장소를 초기화합니다.
  2. 기본 구성 만들기
  3. 배포 환경을 하나 이상 만듭니다.
  4. 필요한 경우 애플리케이션 저장소의 환경에 구성 오버레이를 적용합니다.
  5. pull 요청 또는 병합 요청 형식으로 출시 후보를 만듭니다.
  6. 출시 버전을 배포합니다.

새 저장소 만들기

appctl을 사용하여 GitHub 또는 GitLab에서 애플리케이션 전송을 위한 저장소를 만듭니다.

  1. 애플리케이션 디렉터리를 만들려는 디렉터리로 변경합니다.
  2. appctl을 사용하여 애플리케이션 전송 저장소를 만듭니다.

    GitHub

    다음 명령어를 실행합니다.

    appctl init APP_NAME \
        --app-config-repo=github.com/USERNAME/APP_NAME
    

    다음을 바꿉니다.

    • APP_NAME: 애플리케이션의 이름입니다.
    • USERNAME: GitHub 사용자 이름입니다.

    예를 들어 GitHub 사용자 이름이 octocat이고 myapp이라는 애플리케이션을 만들려면 다음을 실행합니다.

    appctl init myapp \
        --app-config-repo=github.com/octocat/myapp
    

    GitLab

    다음 명령어를 실행합니다.

    appctl init APP_NAME \
        --app-config-repo=gitlab.com/USERNAME/APP_NAME
    

    다음을 바꿉니다.

    • APP_NAME: 애플리케이션의 이름입니다.
    • USERNAME: GitLab 사용자 이름입니다.

    예를 들어 GitLab 사용자 이름이 alice이고 myapp이라는 애플리케이션을 만들려면 다음을 실행합니다.

    appctl init myapp \
        --app-config-repo=gitlab.com/alice/myapp
    
  3. appctl에서 새 비공개 저장소를 확인하라는 메시지를 표시합니다.

appctl은 원격 비공개 Git 저장소 두 개를 만듭니다.

  • 애플리케이션 저장소 github.com/USERNAME/APP_NAME. 이 저장소는 현재 디렉터리에 클론됩니다.
  • 배포 저장소 github.com/USERNAME/APP_NAME-deployment. 로컬 배포 저장소는 ./APP_NAME/.deployment에 저장됩니다.

이러한 저장소의 콘텐츠와 구조에 대한 자세한 내용은 애플리케이션 전송 개념 가이드를 참조하세요.

기존 저장소 초기화

기존 저장소가 있는 경우 appctl을 사용하여 GitHub 또는 GitLab에서 애플리케이션 전송 저장소를 초기화할 수 있습니다.

  1. 애플리케이션 디렉터리를 만들려는 디렉터리로 변경합니다.

  2. appctl init 명령어를 실행합니다. 이 명령어는 APP_NAME이라는 디렉터리를 만들고 여기에 저장소를 클론합니다.

    appctl init 명령어는 저장소의 ./config 디렉터리에 저장된 구성 파일에서 Kustomize 기본 레이어를 초기화합니다. --config-path 플래그를 사용하여 다른 구성 경로를 지정할 수 있습니다.

    기본적으로 appctl initgithub.com/USERNAME/APP_NAME-deployment를 배포 저장소의 URL로 사용합니다. --deployment-repo 플래그를 사용하여 다른 URL을 지정할 수 있습니다. 배포 저장소가 없으면 appctl 명령어가 배포 저장소를 만듭니다.

    GitHub

    appctl init APP_NAME \
          --app-config-repo=github.com/USERNAME/APP_NAME \
          [--config-path=CONFIG_PATH]
    

    다음을 바꿉니다.

    • APP_NAME: 애플리케이션의 이름입니다.
    • USERNAME: GitHub 사용자 이름입니다.
    • CONFIG_PATH: 저장소의 구성 디렉터리에 대한 선택적 경로입니다. 생략하면 기본값은 ./config입니다.

    예를 들어 기존 애플리케이션 구성 저장소가 https://github.com/octocat/myapp이고 배포 저장소를 https://github.com/octocat/myapp-deploy로 예상하는 경우 다음을 실행합니다.

    appctl init myapp \
        --app-config-repo=github.com/octocat/myapp
    

    GitLab

    appctl init APP_NAME \
        --app-config-repo=gitlab.com/USERNAME/APP_NAME \
        [--config-path=CONFIG_PATH]
    

    다음을 바꿉니다.

    • APP_NAME: 애플리케이션의 이름입니다.
    • USERNAME: GitLab 사용자 이름입니다.
    • CONFIG_PATH: 저장소의 구성 디렉터리에 대한 선택적 경로입니다. 생략하면 기본값은 ./config입니다.

    예를 들어 기존 애플리케이션 구성 저장소가 gitlab.com/alice/myapp이면 다음을 실행합니다.

    appctl init myapp --app-config-repo=gitlab.com/alice/myapp
    

기본 구성 만들기

  1. 작업 디렉터리를 애플리케이션 저장소로 변경합니다.

  2. Kubernetes 워크로드의 구성을 만듭니다. 유효한 Kubernetes 배포면 됩니다.

    다음 구성은 nginx 컨테이너의 복제본 3개를 배포하는 nginx라는 애플리케이션을 정의합니다. 이 구성을 config/base/myapp.yaml 파일에 복사합니다. LoadBalancer를 사용 설정하려면 type: LoadBalancer 줄의 주석 처리를 삭제합니다.

    #myapp/config/base/myapp.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      # if your cluster supports it, uncomment the following to automatically create
      # an external load-balanced IP for the frontend service.
      # type: LoadBalancer
      ports:
        - port: 80
      selector:
        app: nginx
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9
            ports:
            - containerPort: 80
    
  3. 이 구성을 기본 구성에 적용하도록 애플리케이션 전송을 구성합니다. config/base/kustomization.yaml에 다음을 붙여넣습니다.

    #config/base/kustomization.yaml
    
    resources:
      - myapp.yaml
    

구성 테스트 및 푸시

  1. 애플리케이션 저장소 디렉터리에서 kustomize build를 사용하여 구성을 테스트합니다.

    kustomize build config/base/
    

    구성이 유효하다면 kustomize는 적용될 때 클러스터에 배포될 YAML을 출력합니다.

  2. YAML의 유효성을 검사한 후 커밋을 만들어 애플리케이션 저장소에 푸시합니다.

    git add .
    git commit -m "Creating APP_NAME"
    git push origin master
    

출시 환경 추가

애플리케이션 전송은 애플리케이션을 환경에 배포합니다. appctl을 사용하여 출시 환경을 추가합니다.

  1. 애플리케이션 저장소 루트 디렉터리로 변경합니다.

  2. appctl을 사용하여 환경을 만듭니다.

    appctl env add ENVIRONMENT_NAME \
        --cluster=CLUSTER_NAME
    

    다음을 바꿉니다.

    • ENVIRONMENT_NAME: 새 환경 이름입니다.
    • CLUSTER_NAME: 클러스터 이름입니다.

    appctl은 스캐폴드된 Kustomize 구성이 포함된 git 커밋을 만듭니다.

    --namespace를 사용하여 이 애플리케이션의 출시 환경에 대한 네임스페이스의 이름을 지정할 수 있습니다. 그렇지 않은 경우 기본 네임스페이스 이름은 APP_NAME-ENVIRONMENT_NAME입니다.

    예를 들어 기본 네임스페이스 이름을 사용하여 stagingprod 환경을 클러스터 application-cluster에 추가하려면 다음 명령어를 실행합니다.

    appctl env add staging --cluster=application-cluster
    appctl env add prod --cluster=application-cluster
    

    test 네임스페이스의 test 환경을 클러스터 application-cluster에 추가하려면 다음 명령어를 실행합니다.

    appctl env add test --cluster=application-cluster --namespace=test
    

    환경을 추가할 때 이 환경의 배포 저장소에 pull 요청 및 코드 검토가 필요한지 고려해야 합니다. 기본적으로 pull 요청이 생성됩니다. 프로덕션이 중요한 환경이 아니고 코드 검토가 필요하지 않은 경우 --review-required=false를 사용하여 pull 요청 생성을 건너뛸 수 있습니다.

    예를 들어 pull 요청이 필요 없는 test 환경을 추가하려면 다음 명령어를 실행합니다.

    appctl env add test \
        --cluster=application-cluster \
        --review-required=false
    
  3. 필요한 경우 git log를 사용하여 애플리케이션 전송에 따른 Git 저장소의 변경사항을 확인합니다.

    git log -p *
    
  4. 구성을 애플리케이션 저장소로 푸시합니다.

    git push origin master
    

선택사항: 배포 저장소 확인

배포 저장소의 GitHub 또는 GitLab 페이지를 엽니다. 예를 들어 GitHub 사용자 이름이 octocat이고 myapp이라는 애플리케이션을 만들었다면 URL은 https://github.com/octocat/myapp-deployment입니다. 이 페이지에서 각 환경에 생성된 분기를 확인할 수 있습니다.

환경 배포

애플리케이션 전송으로 환경을 배포하려면 다음을 수행합니다.

  1. git tag로 버전을 만들고 태그를 푸시합니다.

    git tag VERSION
    git push origin VERSION
    

    VERSION을 애플리케이션의 버전 번호로 바꿉니다.

    예를 들어 v0.1.0 버전을 푸시하려면 다음 명령어를 실행합니다.

    git tag v0.1.0
    git push origin v0.1.0
    ```
    
  2. appctl prepare를 사용하여 현재 태그가 지정된 버전을 지정하고 배포 저장소에 검토용 pull 요청을 생성합니다.

    appctl prepare ENVIRONMENT_NAME
    

    예를 들어 staging 환경을 사용하려면 다음 명령어를 실행합니다.

    appctl prepare staging \
        --validate=true
    

    이 명령어는 kpt 검증 함수 gcr.io/kustomize-functions/example-validator를 트리거하여 배포 저장소에 푸시되는 변경사항을 검증합니다.

    kptgcloud components install pkg에 의해 설치됩니다. 이 검증 함수는 Kubernetes OpenAPI 사양의 스키마를 사용하여 Kubernetes 구성 파일을 검증하는 kubeval을 내부적으로 실행합니다.

    kpt prepare staging --validate를 실행하려면 머신에 Docker를 설치해야 합니다.

    기본적으로 --validate 플래그는 사용 중지되어 있습니다.

    appctl은 배포 저장소에 대한 커밋을 완료한 경우 다음과 같이 URL을 출력하여 pull 요청을 만듭니다.

    Created a "Pull Request": "https://github.com/octocat/myapp-deployment/pull/[Pull_Request_ID]"
    
  3. GitHub 또는 GitLab을 사용하여 pull 요청을 검토 및 승인합니다.

  4. pull 요청이 승인되었으면 appctl apply를 사용하여 배포를 완료합니다.

    appctl apply ENVIRONMENT_NAME
    

    ENVIRONMENT_NAME을 환경의 이름으로 바꿉니다.

    예를 들어 staging 환경에 변경사항을 배포하려면 다음 명령어를 실행합니다.

    appctl apply staging
    
  5. 애플리케이션이 kubectl을 사용하거나 Cloud Console에서 실행 중인지 확인합니다.

    kubectl

    kubectl describe를 사용하여 애플리케이션 상태를 봅니다.

    kubectl get releasetracks.app.gke.io APP_NAME \
        --n NAMESPACE \
        -w
    

    다음을 바꿉니다.

    • APP_NAME: 애플리케이션 저장소의 이름입니다.
    • NAMESPACE: 환경을 만들 때 지정한 네임스페이스 이름입니다. 네임스페이스 이름을 지정하지 않은 경우 기본값은 APP_NAME-ENVIRONMENT_NAME입니다.

    예를 들어 myapp이라는 애플리케이션의 staging 환경 상태를 확인하려면 다음 명령어를 실행합니다.

    kubectl get releasetracks.app.gke.io myapp -n myapp-staging
    

    이전에 env add --namespace test에서 추가한 test 환경의 상태를 확인하려면 다음 명령어를 실행합니다.

    kubectl get releasetracks.app.gke.io myapp -n test
    

    Console

    애플리케이션 전송을 통해 배포된 애플리케이션의 상태 및 버전 정보를 확인하려면 Cloud Console의 GKE 애플리케이션 페이지를 참조하세요.

출시 버전 승격

  1. 한 환경에서 다른 환경으로 출시 후보를 승격하려면 다음 명령어를 실행합니다.

    appctl prepare TARGET_ENVIRONMENT \
        --from-env=SOURCE_ENVIRONMENT
    

    다음을 바꿉니다.

    • TARGET_ENVIRONMENT: 출시 후보를 배포할 환경의 이름입니다.
    • SOURCE_ENVIRONMENT: 현재 환경의 이름입니다.

    예를 들어 stagingprod로 승격하려면 다음을 실행합니다.

    appctl prepare prod --from-env=staging
    
  2. GitHub 또는 GitLab을 사용하여 pull 요청을 검토 및 승인합니다.

  3. 출시 후보를 대상 환경에 배포하려면 다음 명령어를 실행합니다.

    appctl apply TARGET_ENVIRONMENT
    

    예를 들어 prod 환경에 배포하려면 다음 명령어를 실행합니다.

    appctl apply prod
    

Cloud Console에서 환경 보기

환경의 애플리케이션이 배포되면 GKE 애플리케이션 페이지에서 볼 수 있습니다. 이 페이지에는 괄호 안에 환경이 표시된 애플리케이션 목록이 포함되어 있습니다. 다음은 stagingprod 환경이 있는 애플리케이션 myapp의 스크린샷입니다. 각 환경의 네임 스페이스, 클러스터, 버전도 이 페이지에 표시됩니다.

애플리케이션 페이지의 스크린샷

git 태그, 구성요소, 환경 목록과 같은 애플리케이션의 세부정보를 보려면 애플리케이션 이름을 클릭합니다. 다음 스크린샷은 myapp의 세부정보입니다.

애플리케이션 세부정보 페이지의 스크린샷

환경 구성 변경

이 섹션에서는 이전 단계와 같이 staging 환경이 구성되어 있다고 가정합니다. 다음 안내를 상황에 맞게 조정해야 할 수도 있습니다.

이 섹션에서는 kustomize overlay를 사용하여 staging 환경의 매개변수를 변경합니다. 변경한 후 git에서 변경사항을 푸시하고 태그를 지정합니다. 애플리케이션 전송이 클러스터를 업데이트합니다.

  1. config/envs/staging/patch-replicas.yaml이라는 파일을 만들고 이 파일에 다음 텍스트를 복사합니다. 이렇게 하면 복제본 세 개 대신 복제본 하나를 실행하도록 staging 환경의 구성이 업데이트됩니다.

    #config/envs/staging/patch-replicas.yaml
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
    
  2. config/envs/staging/kustomization.yaml 파일을 수정하고 이름이 patchesStrategicMerge인 새 컬렉션에 patch-replicas.yaml을 추가합니다.

    #config/envs/staging/kustomization.yaml
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    

    이 오버레이에 환경별 주석을 추가할 수도 있습니다. 다음 예시에서는 oncall-team이라는 주석을 추가하여 이 환경의 모든 리소스를 추가합니다. 자세한 내용은 Kustomize 파일 필드를 참조하세요.

    #config/envs/staging/kustomization.yaml
    
    #Don't change the namespace field
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    commonAnnotations:
      oncall-team: staging-oncall@foo.bar
    
  3. kustomize build를 사용하여 구성을 테스트합니다.

    kustomize build config/envs/staging/
    
  4. 변경사항을 추가하고 커밋합니다.

    git add .
    git commit -m "<var>COMMIT_MESSAGE</var>"
    git push origin master
    

    COMMIT_MESSAGE를 변경사항을 설명하는 메시지로 바꿉니다.

  5. git tag로 버전을 만들고 푸시합니다.

    git tag VERSION
    git push origin VERSION
    

    VERSION을 원하는 버전 번호로 바꿉니다.

  6. appctl prepare를 사용하여 배포 저장소에서 검토용 pull 요청을 생성합니다.

    appctl prepare ENVIRONMENT_NAME
    
  7. 링크를 따라 GitHub 또는 GitLab pull 요청을 만듭니다.

  8. pull 요청의 콘텐츠를 살펴봅니다. 애플리케이션 전송은 한 줄만 변경하여 replicas 값을 1로 설정합니다.

  9. GitHub 또는 GitLab에 대한 pull 요청을 승인합니다.

  10. appctl apply을 사용하여 변경사항을 적용합니다.

    appctl apply staging
    

구성 변경사항 롤백

이전 출시로 롤백하려면 다음 명령어를 실행합니다.

appctl apply TARGET_ENVIRONMENT \
    --from-tag GIT_TAG

다음을 바꿉니다.

  • TARGET_ENVIRONMENT: 출시를 배포할 환경의 이름입니다.
  • GIT_TAG: 출시의 태그 이름입니다.

스크립트에서 appctl 사용

appctl 도구는 대화형이며 기본적으로 사용자 입력이 필요합니다. 스크립트, 컨테이너 또는 파이프라인에서 appctl을 실행하려면 환경 변수 APPCTL_INTERACTIVEfalse로 설정합니다.

예를 들어 bash 셸에서 다음 명령어를 실행합니다.

export APPCTL_INTERACTIVE=false

특정 appctl 명령어 관련 정보는 appctl help command를 통해 제공됩니다. 예를 들어 appctl prepare에 대한 도움말을 보려면 appctl help prepare를 실행합니다.

애플리케이션 관리자 제거

클러스터에서 실행 중인 애플리케이션을 삭제하려면 새 환경과 함께 만든 모든 네임스페이스를 삭제합니다.

모든 환경과 클러스터에 다음 명령어를 반복합니다.

  1. 지정된 환경의 클러스터로 전환합니다.

    kubectl config use-context ENVIRONMENT_CLUSTER_NAME
    

    ENVIRONMENT_CLUSTER_NAME을 선택한 환경의 클러스터 이름으로 바꿉니다.

  2. 이 환경의 애플리케이션이 실행 중인 네임스페이스를 삭제합니다.

    kubectl delete ns NAMESPACE
    

    NAMESPACE를 삭제할 네임스페이스 이름으로 바꿉니다. 기본값은 APP_NAME-ENVIRONMENT_NAME입니다.

  3. GitHub 또는 GitLab에서 appctl이 만든 Git 저장소 두 개를 삭제합니다.

  4. 로컬 애플리케이션 디렉터리를 삭제합니다.

    rm -rf myapp/
    
  5. gcloud 또는 Cloud Console에서 클러스터의 애플리케이션 전송을 중지할 수 있습니다.

    gcloud

    gcloud beta container clusters update CLUSTER_NAME \
        --update-addons ApplicationManager=DISABLED
    

    콘솔

    1. Cloud Console에서 Google Kubernetes Engine 페이지로 이동합니다.

      Google Kubernetes Engine으로 이동

    2. 클러스터 목록에서 수정하려는 클러스터 이름을 클릭합니다.

    3. 기능에서 애플리케이션 관리자 필드 옆에 있는 애플리케이션 관리자 수정을 클릭합니다.

    4. 애플리케이션 관리자 사용 설정 체크박스를 선택 취소합니다.

    5. 변경사항 저장을 클릭합니다.

다음 단계

Kustomize에 대해 자세히 알아보기