Cloud Run에서 Google Kubernetes Engine으로 마이그레이션

Cloud Run 및 Kubernetes에는 모두 표준 컨테이너 이미지가 배포 아티팩트로 사용되고, 둘 다 동일한 표준 구조로 YAML 파일에 표시할 수 있는 선언적 API 모델이 사용됩니다.

소개

Cloud Run Admin API v1은 Kubernetes로 이동성을 극대화하도록 설계되었습니다. 예를 들어 Cloud Run Admin API 리소스는 Kubernetes 리소스와 동일한 구조 규칙 및 속성 이름을 공유합니다. Cloud Run 서비스 YAML 참조를 확인하세요.

Cloud Run Admin API v1은 Knative Serving API 사양을 구현하지만 Cloud Run 워크로드를 GKE와 같은 Kubernetes 클러스터로 이동하기 위해 Knative 로 마이그레이션할 필요가 없습니다.

빠른 시작

이 빠른 시작은 간단한 마이그레이션 예시를 보여줍니다.

간단한 리소스 비교

my-app이라는 간단한 다음 Cloud Run 서비스를 상응하는 Kubernetes 배포와 비교합니다. YAML 파일이 거의 동일한 것에 주의하세요.

그러나 blue 부분이 다르고 이를 변경해야 합니다. green 부분을 추가해야 합니다.

Cloud Run 서비스	Kubernetes 배포
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' spec: template: spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world	apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: default labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world replicas: 3 selector: matchLabels: app: my-app

간단한 Cloud Run 서비스를 GKE로 마이그레이션

1. 서비스 YAML 파일을 현재 디렉터리에 다운로드합니다.

   gcloud run services describe my-app --format export > my-app.yaml

2. Kubernetes 배포와 일치하도록 YAML을 수정합니다.

   • 'kind' 속성의 경우 'Service' 값을 'Deployment'로 바꿉니다.
   • 'apiVersion' 속성의 경우 'serving.knative.dev/v1' 값을 'apps/v1'로 바꿉니다.
   • metadata.namespace를 배포하려는 GKE 클러스터의 네임스페이스로 바꿉니다(예: default).
   • metadata 및 spec.template.metadata 아래에 새 레이블을 추가합니다.
   • spec.template.spec.replicas를 사용하여 고정된 인터페이스 수('복제본')를 설정하고 spec.template.spec.selector에서 라벨 선택기를 설정합니다.

3. 설치하고 kubectl 명령줄 도구를 사용하여 my-app.yaml 파일을 GKE 클러스터에 배포합니다.

   kubectl apply -f ./my-app.yaml

4. 배포를 서비스로 노출합니다.

   kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080

Cloud Run에서 GKE로 마이그레이션할 때 고려사항

클러스터:

• Cloud Run은 완전 관리형 플랫폼이고 GKE는 플랫폼 관리가 더 많이 필요합니다. 아직 GKE 클러스터를 만들지 않았으면 GKE Autopilot을 사용합니다.

• GKE 워크로드 확장성은 클러스터 크기로 제한됩니다. Autopilot 클러스터를 사용하지 않는 경우 노드 자동 프로비저닝 및 클러스터 자동 확장 처리를 사용해서 클러스터 크기를 조정하는 것이 좋습니다.

• Cloud Run에는 기본 제공되는 영역 중복성이 있습니다. 따라서 선택한 Google Cloud 리전에서 영역별 중단이 발생할 때 서비스가 복원될 수 있도록 리전별 클러스터로 마이그레이션하고 충분한 복제본을 프로비저닝합니다.

가격 책정

Cloud Run에는 사용된 리소스에 따라 비용이 부과되고 GKE에는 프로비저닝된 리소스에 따라 비용이 부과됩니다.

보안:

• Cloud Run과 달리 GKE 서비스 호출에는 IAM 호출자 권한이 적용되지 않습니다.

• GKE는 컨테이너 간에 강력한 격리를 제공하지 않으므로 알 수 없거나 신뢰할 수 없는 코드를 실행해야 할 경우에는 GKE Sandbox를 사용하는 것이 좋습니다.

네트워킹

Cloud Run은 VPC의 다른 리소스에 액세스하기 위해 서버리스 VPC 액세스 커넥터가 필요합니다. GKE 워크로드는 VPC에 직접 포함되어 있고 커넥터가 필요하지 않습니다.

Google Kubernetes Engine에서 지원되지 않는 기능

다음 Cloud Run 기능은 GKE에서 제공되지 않습니다.

• 버전을 통한 구성 버전 관리
• 점진적 출시 및 버전 롤백을 위한 트래픽 분할
• 요청 처리 중에만 할당되는 CPU
• CPU 부스트
• 세션 어피니티
• GKE 워크로드의 라벨은 Google Cloud 라벨이 아닙니다.
• 워크로드의 태그

Cloud Run 리소스 마이그레이션

다음 섹션에서는 Cloud Run 서비스, 작업, 보안 비밀과 같이 Cloud Run에서 사용되는 리소스 마이그레이션에 대해 설명합니다.

Cloud Run 서비스 마이그레이션

GKE의 다음 리소스로 Cloud Run 서비스를 마이그레이션할 수 있습니다.

1. 인스턴스를 만들기 위한 Kubernetes 배포(Kubernetes의 '포드')
2. 특정 엔드포인트에서 배포를 노출하기 위한 Kubernetes 서비스
3. 배포 자동 확장을 위한 Kubernetes 수평형 포드 자동 확장 처리

Kubernetes 배포 속성은 Cloud Run 서비스 속성의 상위 집합입니다. 빠른 시작에 표시된 것처럼 apiVersion 및 kind 속성을 apps/v1 및 Deployment로 변경한 후 다음 항목도 변경해야 합니다.

• namespace를 배포할 GKE 클러스터 네임스페이스로 바꿉니다(예: default).
• serviceAccountName은 선택적으로 GKE용 워크로드 아이덴티티 제휴를 사용해서 IAM 서비스 계정으로 작동할 수 있는 Kubernetes 서비스 계정을 참조합니다.
• metadata.labels 및 spec.template.metadata.labels에서 배포 및 포드를 선택하는 데 사용되는 LABEL을 추가합니다. 예를 들면 app: NAME입니다.
• spec.template 아래에서 다음 안내를 따르세요.
  • replicas 속성을 추가하여 '인스턴스' 수를 지정합니다.
  • LABEL 라벨에서 선택되는 selector.matchLabels 속성을 추가합니다.
• Cloud Run 서비스가 보안 비밀을 마운트하는 경우 보안 비밀 마이그레이션을 참조하세요.
• 마이그레이션된 Cloud Run 서비스가 Virtual Private Cloud의 리소스에 액세스하는 경우 서버리스 VPC 액세스 커넥터를 사용할 필요가 없습니다.

Kubernetes 배포를 만든 후 이를 노출할 Kubernetes 서비스를 만듭니다.

apiVersion: v1
kind: Service
metadata:
  name: NAME
spec:
  selector:
    LABEL
  ports:
    - protocol: TCP
      port: 80
      targetPort: PORT

다음과 같이 바꿉니다.

• NAME을 서비스 이름으로 바꿉니다.
• LABEL을 배포에 정의된 라벨로 바꿉니다. 예를 들면 app: NAME입니다.
• PORT를 Cloud Run 서비스에서 요청을 수신하는 컨테이너의 containerPort로 바꿉니다(기본값: 8080).

그런 다음 포드 수를 자동으로 확장하기 위해 선택적으로 Kubernetes 수평형 포드 자동 확장 처리를 만들 수 있습니다. Kubernetes 수평형 포드 자동 확장 문서에 따라 HorizontalPodAutoscaler를 만듭니다. Cloud Run 서비스의 최소 인스턴스(autoscaling.knative.dev/minScale) 및 최대 인스턴스(autoscaling.knative.dev/maxScale) 값을 minReplicas 및 maxReplicas 속성 HorizontalPodAutoscaler의 값으로 사용합니다.

Cloud Run 작업 마이그레이션

GKE에서 Cloud Run 작업을 Kubernetes 작업으로 마이그레이션할 수 있습니다.

Cloud Run 작업과 달리 Kubernetes 작업은 생성될 때 실행됩니다. 작업을 다시 실행하려면 새 작업을 만들어야 합니다.

다음 샘플은 Cloud Run 작업과 Kubernetes 작업 사이의 구조적 차이를 보여줍니다.

Cloud Run 작업	Kubernetes 작업
apiVersion: run.googleapis.com/v1 kind: Job metadata: name: my-job spec: template: spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job	apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job

보안 비밀 마이그레이션

Secret Manager에서 기존 보안 비밀을 유지하거나 이를 Kubernetes 보안 비밀로 마이그레이션할 수 있습니다.

Secret Manager에서 보안 비밀을 유지하도록 선택하는 경우 GKE에서 이를 사용하는 방법을 업데이트해야 합니다.

Secret Manager에서 Kubernetes 보안 비밀로 마이그레이션하도록 선택하는 경우 Secret Manager 보안 비밀과 Kubernetes 보안 비밀 사이에서 다음과 같은 차이점을 고려해야 합니다.

• 이름에 허용되는 문자:
  • Kubernetes 보안 비밀: [a-z0-9-.]{1,253}
  • Secret Manager 보안 비밀: [a-zA-Z0-9_-]{1,255}
• 버전 관리: Secret Manager의 보안 비밀은 버전 관리되지만 Kubernetes 보안 비밀은 그렇지 않습니다.
• 페이로드: Secret Manager의 보안 비밀에는 단일 []byte가 포함되고 Kubernetes 보안 비밀에는 map<string, string>이 포함됩니다.

마이그레이션 전략

동일한 리소스를 만든 후 전역 외부 애플리케이션 부하 분산기 뒤에서 외부 엔드포인트를 노출하면 Cloud Run과 Google Kubernetes Engine(GKE) 사이에 점진적으로 트래픽을 마이그레이션할 수 있습니다.