Knative serving 서비스를 Cloud Run으로 마이그레이션

이 가이드를 따르면 워크로드를 Cloud Run으로 마이그레이션할 수 있습니다. 일반적으로 워크로드를 마이그레이션하려면 Kubernetes 기반 기능을 포팅한 다음 각 기존 서비스를 Cloud Run에 다시 배포해야 합니다.

Cloud Run으로 마이그레이션할 때의 주요 이점:

  • Knative Serving API 사양을 구현하고 컨테이너 계약을 준수하는 완전 관리형 서버리스 제품입니다.

  • Cloud Run의 v1 Admin API는 Knative serving를 사용하여 이동성을 극대화하도록 설계되었습니다.

  • 사용자 환경은 Cloud Run과 Knative serving에서 비슷합니다.

    • gcloud run 명령어 그룹은 두 제품 모두에서 사용됩니다.
    • 사용자 인터페이스 레이아웃 및 동작이 Google Cloud Console과 유사합니다.

시작하기 전에

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

마이그레이션 고려사항

모든 종속 항목 및 요구사항을 포팅할 수 있도록 제품 간의 다음 차이점을 검토하고 이해해야 합니다.

보안 비밀

Cloud Run에서는 보안 비밀을 환경 변수 또는 볼륨으로 마운트할 수 있지만 민감한 정보가 있는 보안 비밀은 Secret Manager에 저장해야 합니다.

Secret Manager의 보안 비밀과 Kubernetes 보안 비밀 간의 중요한 차이점:

기능 Secret Manager 보안 비밀 Kubernetes 보안 비밀
이름에 허용되는 문자 [a-zA-Z0-9_-]{1,255} [a-z0-9-.]{1,253}
버전 관리 보안 비밀이 버전 관리됨 지원되지 않음
보안 비밀 페이로드 단일 []byte 지도: <string, string>

Secret Manager를 사용하여 Knative serving 서비스의 보안 비밀 키에 대해 버전 관리 보안 비밀을 만드는 방법을 알아보세요.

네트워킹

다음 정보를 사용하여 기존 네트워크 구성을 Cloud Run으로 포팅할 수 있습니다.

서비스 엔드포인트
Knative serving 서비스의 Kubernetes 엔드포인트는 Cloud Run에서 지원되지 않습니다. Cloud Run의 고유 엔드포인트 자세히 알아보기
도메인 매핑
Cloud Run DomainMapping API는 Knative serving과 호환됩니다. 하지만 Cloud Run은 사용 가능한 Cloud Run 위치의 하위 집합에서 도메인 매핑을 제공합니다. 권장 옵션은 커스텀 도메인에 전역 HTTP(S) 부하 분산기를 활용하는 것입니다.
VPC 연결
Cloud Run 서비스는 VPC 외부에 있습니다. VPC 내의 리소스와 통신하려면 서버리스 VPC 액세스 커넥터를 사용해야 합니다.
인그레스 제어
Knative serving 서비스가 비공개 내부 네트워크에 대해 구성되고 내부 부하 분산기(ILB)를 사용하는 경우 Cloud Run 서비스를 Ingress = Internal로 구성할 수 있습니다. 서비스를 internal로 구성하면 VPC 또는 다른 Cloud Run 서비스 내부에 대한 액세스가 제한됩니다. 서비스 간 통신 자세히 알아보기

서비스 마이그레이션

서비스를 마이그레이션하려면 Knative serving 서비스를 내보내고, 내보낸 YAML 파일을 수정하고, 재구성된 서비스를 Cloud Run에 배포해야 합니다.

  1. 다음 명령어를 실행하여 Knative serving 서비스를 로컬 YAML 파일로 내보냅니다.

    gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml

    다음과 같이 바꿉니다.

    • SERVICE를 Knative serving 서비스의 이름으로 바꿉니다.
    • NAMESPACE를 서비스가 실행되는 네임스페이스로 바꿉니다.
    • CLUSTER를 서비스가 실행되는 클러스터의 이름으로 바꿉니다.
    • FILENAME을 원하는 고유한 파일 이름으로 바꿉니다.

  2. Cloud Run용으로 내보낸 FILENAME.yaml 파일을 수정합니다.

    • Kubernetes 네임스페이스를 검색하여 Google Cloud 프로젝트의 ID로 바꿔야 합니다. 예를 들어 namespace:default는 namespace:my-unique-id로 바꿔야 합니다.
    • 지원되지 않는 기능의 모든 구성을 업데이트해야 합니다.

    • 다음 속성 및 값을 삭제해야 합니다.

      • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
      • metadata.managedFields
      • spec.template.spec.containers.readinessProbes
      • spec.template.spec.enableServiceLinks

      예를 들어 spec: > template: > spec: > containers: 속성에서 다음 구성을 삭제해야 할 수 있습니다.

      ...
 readinessProbe:
   successThreshold: 1
   tcpSocket: {}
...

  3. --platform managed 플래그를 사용하여 수정된 .yaml 파일을 Cloud Run에 배포합니다. 배포 자세히 알아보기

    Cloud Run에 동일한 Google Cloud 프로젝트를 사용할 수 있습니다.

    gcloud run services replace FILENAME.yaml --platform managed --region REGION

    다음과 같이 바꿉니다.

    • FILENAME을 만들어서 내보낸 구성 파일의 이름으로 바꿉니다.
    • REGION을 지원되는 Cloud Run 위치로 바꿉니다. 예를 들면 us-central1입니다.

  4. Cloud Run 서비스에 대한 액세스를 구성합니다.

    • 기본적으로 Cloud Run 서비스는 외부에서 액세스할 수 없습니다. 서비스를 인터넷에 공개적으로 노출하고 인증되지 않은 요청을 허용하려면 공개(인증되지 않은) 액세스를 허용해야 합니다.

    • Cloud Run 서비스 간과 같이 비공개 내부 전용 액세스에 대해 이 서비스를 구성하려면 서비스 간 인증을 참조하세요.

  5. Google Cloud Console의 서비스 페이지에서 표시된 URL 링크를 클릭하여 배포된 서비스의 고유하고 안정적인 엔드포인트를 열 수 있습니다.

    Cloud Run으로 이동

서비스로 트래픽 마이그레이션

새로 배포된 서비스를 테스트하고 모든 프로덕션 트래픽을 마이그레이션할 준비가 되면 커스텀 도메인을 구성하고 등록기관에서 DNS 레코드를 업데이트할 수 있습니다. 커스텀 도메인 매핑의 안내를 따르세요.