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

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 사양을 구현하지만 일부 Kubernetes 워크로드를 Cloud Run으로 마이그레이션하기 위해 기존 Kubernetes 클러스터에서 Knative를 사용할 필요가 없습니다.

Cloud Run의 기본 리소스는 서비스입니다. Cloud Run 서비스는 기본 제공되는 포드 자동 확장 처리와 고유한 엔드포인트가 포함된 Kubernetes 배포와 같은 대략적인 추상화라고 생각할 수 있습니다. Kubernetes의 '포드'는 Cloud Run의 '인스턴스'에 해당합니다. Kubernetes 배포를 Cloud Run 서비스로 전환할 때는 한 번에 하나씩 전환하는 것이 좋습니다. 또한 Kubernetes 수평형 포드 자동 확장 처리 및 Kubernetes 서비스의 일부 구성을 Cloud Run 서비스로 병합할 수 있습니다.

Cloud Run에는 네임스페이스라는 개념이 없습니다. 대신 Google Cloud 프로젝트가 리소스 간 격리 경계로 사용됩니다. Kubernetes에서 Cloud Run으로 마이그레이션할 때는 각 네임스페이스에 대해 하나의 Google Cloud 프로젝트를 만드는 것이 좋습니다. Cloud Run 서비스 YAML에서 네임스페이스 값은 Google Cloud 프로젝트 번호입니다.

Cloud Run에는 기본 제공되는 영역 중복성이 있습니다. 즉, 선택한 Google Cloud 리전에서 영역별 중단이 발생할 때 서비스 복원력을 위한 복제본을 프로비저닝할 필요가 없습니다.

빠른 시작

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

간단한 리소스 비교

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

blue 부분이 다르고 이를 변경해야 합니다. red 부분은 Cloud Run에 기본 제공되는 자동 확장 처리가 있기 때문에 삭제해야 합니다.

Kubernetes 배포	Cloud Run 서비스
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	apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world

Kubernetes 배포

Cloud Run 서비스


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


apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
  namespace: 'PROJECT_NUMBER'
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

간단한 Kubernetes 배포를 Cloud Run으로 마이그레이션

다음과 같이 현재 디렉터리에 배포에 대한 YAML 파일을 다운로드합니다.
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
Cloud Run 서비스에 맞게 YAML을 수정합니다. my-app.yaml 파일을 업데이트합니다.
- 'kind' 속성의 경우 'Deployment' 값을 'Service'로 바꿉니다.
- 'apiVersion' 속성의 경우 'apps/v1' 값을 'serving.knative.dev/v1'로 바꿉니다.
- metadata.namespace 속성을 삭제하거나 Google Cloud 프로젝트 번호에 맞게 값을 변경합니다.
- spec.replicas 및 spec.selector 삭제
다음 명령어를 사용하여 my-app.yaml 파일을 Cloud Run에 배포하고 REGION을 원하는 Google Cloud 리전(예: us-central1)으로 바꿉니다.
```
gcloud run services replace my-app.yaml --region REGION
```

Cloud Run 서비스 호출은 IAM 권한으로 보호됩니다. 새 Cloud Run 서비스를 인터넷에 공개적으로 노출하고 인증되지 않은 호출을 허용하려면 다음 명령어를 실행합니다.

gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION

Cloud Run에서 지원하지 않는 기능

Cloud Run에 적합한 워크로드만 마이그레이션할 수 있습니다.

특히 다음 Kubernetes 기능은 Cloud Run에서 지원되지 않습니다.

고정된 수의 replicas(해결 방법은 동일한 개수의 최소 및 최대 인스턴스를 사용하는 것입니다.)
구성 맵(사용 가능한 해결 방법)
커스텀 수평형 포드 자동 확장 처리 전략
서비스 검색

Kubernetes 배포에서 Cloud Run 서비스로 YAML 파일을 마이그레이션할 때 gcloud run services replace 명령어는 Cloud Run에서 지원되지 않는 속성에 대해 명확한 오류 메시지를 반환합니다. 이러한 속성을 삭제하거나 업데이트한 후 성공할 때까지 명령어를 반복합니다.

Cloud Run에서 지원되는 전체 속성 목록은 YAML 참조를 확인하세요.

Kubernetes 리소스 마이그레이션

Kubernetes 보안 비밀 마이그레이션

Kubernetes와 같이 Cloud Run은 보안 비밀을 환경 변수 또는 볼륨으로 마운트하도록 지원하지만 보안 비밀을 Secret Manager에 저장해야 합니다.

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>이 포함됩니다.

Secret Manager 문서에 따라 보안 비밀을 만들고 Kubernetes 앱에 사용되는 모든 보안 비밀 키에 대해 새 보안 비밀 버전을 추가합니다.

Kubernetes ConfigMap 마이그레이션

Cloud Run에는 Kubernetes ConfigMaps와 상응하는 것이 없지만, ConfigMaps가 암호화되지 않은 보안 비밀로 보일 수 있기 때문에 대신 ConfigMaps를 Secret Manager에서 보안 비밀로 변환할 수 있습니다. Kubernetes 보안 비밀 마이그레이션의 안내를 참조하세요.

Kubernetes 배포 마이그레이션

Kubernetes 배포는 Cloud Run 서비스와 가장 가까운 리소스입니다. Kubernetes 배포의 YAML에서 시작하여 Cloud Run 서비스로 변환하도록 수정하는 것이 좋습니다.

주요 필수 변경사항은 다음과 같습니다.

namespace를 Google Cloud 프로젝트 번호로 바꿔야 합니다.
라벨(metadata.labels 및 spec.template.metadata.labels)은 유효한 Google Cloud 라벨이어야 합니다.
컨테이너는 지원되는 Container Registry에 저장되어야 합니다.
CPU 및 메모리 한도를 조정해야 할 수 있습니다.
보안 비밀을 참조할 때는 'key' 속성을 사용하여 최신 버전의 보안 비밀을 나타내는 'latest'로 Secret Manager에서 버전을 캡처합니다.
serviceAccountName은 현재 Google Cloud 프로젝트의 서비스 계정을 참조합니다.
ConfigMaps(configMapKeyRef) 참조를 보안 비밀(secretKeyRef)에 대한 참조로 바꿔야 합니다.

Kubernetes 배포가 Kubernetes 클러스터의 다른 리소스 또는 VPC의 리소스에 액세스하는 경우 Cloud Run 서비스를 적합한 VPC에 연결해야 합니다.

Kubernetes 서비스 마이그레이션

Cloud Run 서비스는 containerPort로 트래픽을 컨테이너로 라우팅하는 고유한 엔드포인트를 자동으로 노출합니다. Kubernetes 배포를 Cloud Run 서비스로 마이그레이션한 후에는 트래픽을 이 배포로 라우팅하던 Kubernetes 서비스를 마이그레이션할 필요가 없습니다.

Kubernetes HorizontalPodAutoscaler 마이그레이션

Cloud Run 서비스에는 기본 제공되는 수평형 자동 확장 처리가 있습니다. Cloud Run은 정의된 최소 및 최대 인스턴스 수의 경계 내에서 요소 조합을 사용하여 포드('인스턴스'라고 부름)를 자동으로 확장합니다.

HorizontalPodAutoscaler의 minReplicas 및 maxReplicas 속성을 Cloud Run 서비스의 autoscaling.knative.dev/minScale 및 autoscaling.knative.dev/maxScale 주석으로 마이그레이션합니다. 최소 인스턴스 및 최대 인스턴스 구성에 대한 문서를 참조하세요.

Kubernetes 작업 마이그레이션

Kubernetes 작업은 Cloud Run 작업 실행과 유사하기 때문에 Cloud Run 작업으로 마이그레이션하고 작업을 실행할 수 있습니다.

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

Kubernetes 작업	Cloud Run 작업
apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job	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

Kubernetes 작업

Cloud Run 작업


apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - image: us-docker.pkg.dev/cloudrun/container/job


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

마이그레이션 전략

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