GKE에 배포

이 페이지에서는 Cloud Build를 사용하여 Kubernetes에 애플리케이션을 배포하는 방법을 설명합니다.

Cloud Build는 컨테이너식 애플리케이션을 GKE 클러스터에 배포 할 수 있는 gke-deploy 빌더를 제공합니다.

gke-deploy는 Kubernetes용 명령줄 인터페이스인 kubectl을 둘러싼 래퍼입니다. 다음과 같이 Google의 권장사항을 적용하여 Kubernetes에 애플리케이션을 배포합니다.

• 태그 대신 컨테이너 이미지의 다이제스트를 사용하도록 애플리케이션의 Kubernetes 리소스 파일을 업데이트합니다.

• Kubernetes 리소스 파일에 권장 라벨을 추가합니다.

• 이미지를 배포할 GKE 클러스터의 사용자 인증 정보를 검색합니다.

• 준비를 위해 제출된 Kubernetes 리소스 파일을 기다립니다.

kubectl을 사용하여 직접 애플리케이션을 배포하려고 하며 다른 기능은 필요하지 않다면 Cloud Build에서 제공하는 kubectl 빌더를 사용하여 GKE 클러스터에 애플리케이션을 배포할 수 있습니다.

시작하기 전에

• GKE 클러스터를 아직 만들지 않았다면 만듭니다.

• 소스 코드 형태의 컨테이너식 애플리케이션과 Dockerfile을 준비합니다. 소스 코드는 Cloud Source Repositories, GitHub 또는 Bitbucket과 같은 저장소에 저장되어야 합니다.

• 애플리케이션을 실행하는 데 사용되는 Kubernetes 리소스를 설명하는 Kubernetes 리소스 파일이 하나 이상 있어야 합니다. Kubernetes 리소스 파일이 없다면 다음 단계를 사용하여 애플리케이션을 위한 파일을 생성합니다.

  1. Google Cloud Console에서 Kubernetes Engine 클러스터 페이지를 엽니다.
  2. Kubernetes Engine 클러스터 페이지에서 배포를 클릭합니다.
  3. 컨테이너를 선택하고 계속을 클릭합니다. 구성 섹션이 표시됩니다.
  4. 구성 YAML에서 YAML보기를 클릭하여 샘플 Kubernetes 리소스 파일을 가져옵니다.
  참고: 이미 Helm 차트 또는 Kustomize 형식의 리소스와 같은 다른 템플릿 양식의 Kubernetes 리소스 파일이 이미 있으면 helm 빌더 또는 kustomize 빌더에서 배포에 사용할 수 있는 빌드 구성 예시를 참조하세요.

필수 IAM 권한

계정에 Google Kubernetes Engine 개발자 역할을 추가합니다.

1. Cloud Build 설정 페이지를 엽니다.

   Cloud Build 설정 페이지 열기

   서비스 계정 권한 페이지가 표시됩니다.

   

2. Kubernetes Engine 개발자 역할의 상태를 사용 설정됨으로 설정합니다.

사전 빌드된 컨테이너 이미지 배포

gke-deploy로 특정 버전의 애플리케이션을 배포하려면 다음 안내를 따르세요.

1. Kubernetes 리소스 파일이 올바른 컨테이너 이미지 태그 또는 다이제스트를 참조하는지 확인합니다.

2. 빌드 구성 파일에 gke-deploy 단계를 추가합니다.

   YAML

   steps:
   ...
   # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=kubernetes-resource-file
     - --location=location
     - --cluster=cluster
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=kubernetes-resource-file",
           "--location=location",
           "--cluster=cluster"
         ]
       }
     ]
   }
   

   각 항목의 의미는 다음과 같습니다.

   • kubernetes-resource-file은 Kubernetes 리소스 파일 또는 Kubernetes 리소스 파일이 포함된 디렉터리 경로입니다.
   • cluster는 애플리케이션이 배포될 GKE 클러스터의 이름입니다.
   • location은 클러스터의 리전/영역입니다.

   사용 가능한 플래그에 대한 자세한 내용은 gke-deploy run 플래그를 참조하세요.

   참고:kubectl 여러 GKE 클러스터에 배포할 때 Cloud Build는 빌드 단계 전반에서 홈 디렉터리를 유지하므로 이전 단계의 컨텍스트가 기본적으로 후속 단계에서 사용됩니다. 이를 피하려면 빌드 구성 파일의 각 단계에 KUBECONFIG=/tmp/kubeconfig 환경 변수 선언을 추가합니다.

3. 빌드를 시작합니다.

   gcloud builds submit --region=REGION --project=project-id --config build-config
   

   각 항목의 의미는 다음과 같습니다.

   • project-id는 프로젝트의 ID입니다.
   • build-config은 구성 파일의 이름입니다.
   • REGION은 지원되는 빌드 리전 중 하나입니다.

새 컨테이너 이미지 빌드 및 배포

새 컨테이너 이미지를 만들고 새 컨테이너 이미지를 배포하려면 다음 안내를 따르세요.

1. --image 속성을 사용하여 Kubernetes 리소스 파일을 새 컨테이너 이미지로 업데이트합니다.

   YAML

   steps:
     # build the container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["build", "-t", "gcr.io/project-id/image:tag", "."]
     # push container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["push", "gcr.io/project-id/image:tag"]
     # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=kubernetes-resource-file
     - --image=gcr.io/project-id/image:tag
     - --location=location
     - --cluster=cluster
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "build",
           "-t",
           "gcr.io/project-id/image:tag",
           "."
         ]
       },
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "push",
           "gcr.io/project-id/image:tag"
         ]
       },
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=kubernetes-resource-file",
           "--image=gcr.io/project-id/image:tag",
           "--location=location",
           "--cluster=cluster"
         ]
       }
     ]
   }
   

   각 항목의 의미는 다음과 같습니다.

   • project-id는 프로젝트의 ID입니다.
   • image는 일반적으로 애플리케이션 이름인 컨테이너 이미지에 사용할 이름입니다.
   • tag는 컨테이너 이미지의 태그입니다.
     • 각 커밋으로 새 컨테이너 이미지를 빌드한다면 커밋된 단축 SHA를 태그로 사용하면 좋습니다. Cloud Build에서는 기본 대체, $SHORT_SHA로 사용할 수 있습니다.
   • kubernetes-resource-file은 Kubernetes 리소스 파일 또는 Kubernetes 리소스 파일이 포함된 디렉터리 경로입니다.
   • cluster는 애플리케이션이 배포될 GKE 클러스터의 이름입니다.
   • location: 애플리케이션이 배포되는 클러스터의 리전/영역입니다.
   참고: gke-deploy는 빌드 구성 파일에서 하나의 이미지만 참조할 수 있습니다. Kubernetes 리소스 파일에 여러 개의 이미지 참조가 포함된 경우 gcr/project-id/image로 시작하는 이미지만 지정된 태그를 참조하도록 업데이트됩니다.

2. 빌드를 시작합니다.

   gcloud builds submit --region=REGION --project=project-id --config build-config
   

   각 항목의 의미는 다음과 같습니다.

   • project-id는 프로젝트의 ID입니다.
   • build-config은 구성 파일의 이름입니다.
   • REGION은 지원되는 빌드 리전 중 하나입니다.

배포 자동화

Cloud Build에서 트리거를 만들어 GKE에 애플리케이션을 자동으로 배포할 수 있습니다. 코드에 변경사항을 푸시할 때마다 이미지를 빌드하고 배포하도록 트리거를 구성할 수 있습니다.

빌드 트리거를 만들려면 다음 안내를 따르세요.

1. Google Cloud Console에서 트리거 페이지를 엽니다.

   트리거 페이지 열기

2. 페이지 상단의 프로젝트 선택기 드롭다운 메뉴에서 프로젝트를 선택합니다.

3. 열기를 클릭합니다.

4. 트리거 만들기를 클릭합니다.

   트리거 만들기 페이지에서 다음 설정을 입력합니다.

   1. 트리거 이름을 입력합니다.

   2. 트리거를 시작할 저장소 이벤트를 선택합니다.

   3. 소스 코드와 빌드 구성 파일이 포함된 저장소를 선택합니다.

   4. 트리거를 시작할 브랜치 또는 태그 이름의 정규식을 지정합니다.

   5. 트리거에 대해 구성을 선택합니다.

      Cloud Build 구성 파일을 선택하면 변수 이름과 해당 변수와 연결할 값을 제공하여 대체 변수를 지정할 수 있습니다. 아래 예시에서 사용자 정의 대체 변수 _CLOUDSDK_CONTAINER_CLUSTER는 배포할 클러스터를 지정하고 사용자 정의 대체 변수 _CLOUDSDK_COMPUTE_ZONE은 위치를 지정합니다. 다른 클러스터에 배포하려면 동일한 빌드 구성을 사용하고 대체 변수의 값만 변경하면 됩니다.

      YAML

      steps:
      ...
      # deploy container image to GKE
      - name: "gcr.io/cloud-builders/gke-deploy"
        args:
        - run
        - --filename=kubernetes-resource-file
        - --image=gcr.io/project-id/image:tag
        - --location=${_CLOUDSDK_COMPUTE_ZONE}
        - --cluster=${_CLOUDSDK_CONTAINER_CLUSTER}
      

      JSON

      {
        "steps": [
          {
            "name": "gcr.io/cloud-builders/gke-deploy",
            "args": [
              "run",
              "--filename=kubernetes-resource-file",
              "--image=gcr.io/project-id/image:tag",
              "--location=${_CLOUDSDK_COMPUTE_ZONE}",
              "--cluster=${_CLOUDSDK_CONTAINER_CLUSTER}"
            ]
          }
        ]
      }
      

      각 항목의 의미는 다음과 같습니다.

      • kubernetes-resource-file은 Kubernetes 구성 파일의 파일 경로 또는 Kubernetes 리소스 파일이 포함된 디렉터리 경로입니다.
      • project-id는 프로젝트의 ID입니다.
      • image는 일반적으로 애플리케이션 이름인 컨테이너 이미지에 사용할 이름입니다.
      • tag는 컨테이너 이미지의 태그입니다.

      빌드 구성 파일의 대체를 정의하는 방법에 대한 자세한 내용은 사용자 정의 대체 사용을 참조하세요.

5. 만들기를 클릭하여 빌드 트리거를 저장합니다.

코드를 저장소로 푸시하면 Cloud Build가 자동으로 빌드를 트리거합니다. 빌드 트리거에 대한 자세한 내용은 빌드 트리거 생성 및 관리를 참조하세요.

다음 단계

• GKE의 워크로드에 대한 자동 배포 구성 방법 알아보기
• Cloud Build로 GKE에 배포하는 GitOps 스타일 CI/CD 파이프라인을 만드는 방법 알아보기
• 추가 gke-deploy 옵션 알아보기
• Compute Engine에서 블루/그린 배포를 수행하는 방법 알아보기
• 다른 Cloud 빌더 알아보기
• 빌드 오류 문제 해결 방법 알아보기