업그레이드 계획

참고: 이 가이드는 Istio API가 포함된 Cloud Service Mesh만 지원하고 Google Cloud API를 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 페이지에서는 Cloud Service Mesh 업그레이드를 계획하는 데 도움이 되는 정보를 제공합니다. Istio 업그레이드 노트를 검토하는 것도 좋습니다.

카나리아 업그레이드 정보

먼저 새로운 컨트롤 플레인의 카나리아 배포를 실행하여 Cloud Service Mesh를 업그레이드하는 것이 좋습니다. 카나리아를 업그레이드하면 asmcli는 이전 컨트롤 플레인과 함께 컨트롤 플레인의 새 버전을 설치합니다. 이전 컨트롤 플레인과 새 컨트롤 플레인 모두 revision 라벨이 지정되며 이 라벨은 컨트롤 플레인의 식별자 역할을 합니다.

새 컨트롤 플레인으로 워크로드를 마이그레이션하려면 다음 안내를 따르세요.

1. 새 컨트롤 플레인의 revision 라벨을 네임스페이스 중 하나에 설정합니다.

2. 지속적 재시작을 수행합니다. 재시작하면 프록시가 새 컨트롤 플레인을 사용하도록 사이드카 프록시가 포드에 다시 삽입됩니다.

3. 업그레이드가 워크로드에 미치는 영향을 모니터링합니다. 애플리케이션 테스트에 필요하면 이전 단계를 반복합니다.

4. 애플리케이션 테스트가 완료되면 모든 트래픽을 새 컨트롤 플레인으로 마이그레이션하거나 이전 컨트롤 플레인으로 롤백할 수 있습니다.

카나리아 업그레이드는 새로운 컨트롤 플레인이 이전 컨트롤 플레인을 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다. 자세한 단계는 새로운 컨트롤 플레인으로 전환을 참조하세요.

컨트롤 플레인 맞춤설정

이전 설치를 맞춤설정한 경우 Cloud Service Mesh를 업그레이드할 때 동일한 맞춤설정이 필요합니다. --set values 플래그를 istioctl install에 추가하여 설치를 맞춤설정한 경우 오버레이 파일이라고 부르는 IstioOperator YAML 파일에 이러한 설정을 추가해야 합니다. asmcli를 실행할 때 해당 파일 이름으로 --custom_overlay 옵션을 사용해서 오버레이 파일을 지정합니다.

주의: 오버레이 파일을 생략해도 설치가 성공합니다. 하지만 컨트롤 플레인이 다시 배포될 때 생략된 값이 기본값으로 다시 재설정되기 때문에 서비스 메시의 구성이 의도한 것과 다릅니다.

GitHub의 asmcli 디렉터리에는 다양한 오버레이 파일이 포함되어 있습니다. 이러한 파일에는 기본 구성에 대한 일반적인 맞춤설정이 포함되어 있습니다. 이 파일은 그대로 사용하거나 필요에 따라 추가로 변경할 수 있습니다. 선택적 Cloud Service Mesh 기능을 사용 설정하려면 일부 파일이 필요합니다. asmcli를 실행하여 프로젝트와 클러스터의 유효성을 검사하면 anthos-service-mesh 패키지가 다운로드됩니다.

asmcli install을 사용하여 Cloud Service Mesh를 설치할 때 --option 또는 --custom_overlay로 하나 이상의 오버레이 파일을 지정할 수 있습니다. anthos-service-mesh 저장소의 파일을 변경할 필요가 없는 경우 --option을 사용할 수 있으며 스크립트가 자동으로 GitHub에서 파일을 가져옵니다. 그렇지 않으면 오버레이 파일을 변경한 후 --custom_overlay 옵션을 사용하여 asmcli에 전달할 수 있습니다.

인증 기관 선택

현재 Cloud Service Mesh 설치에서 Cloud Service Mesh 인증 기관을 상호 TLS(mTLS) 인증서 발급을 위한 인증 기관(CA)으로 사용하는 경우 Cloud Service Mesh 인증 기관을 계속 사용하는 것이 좋습니다. 그 이유는 다음과 같습니다.

• Cloud Service Mesh 인증 기관은 동적으로 확장된 워크로드에 최적화된 안정성과 확장성이 뛰어난 서비스입니다.
• Google은 Cloud Service Mesh 인증 기관을 통해 CA 백엔드의 보안 및 가용성을 관리합니다.
• Cloud Service Mesh 인증 기관을 사용하면 여러 클러스터에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다.

현재 Cloud Service Mesh 설치에서 Istio CA(이전의 'Citadel')를 사용하는 경우 업그레이드할 때 Cloud Service Mesh 인증 기관으로 전환할 수 있지만 다운타임 일정이 필요합니다. 업그레이드 중에는 모든 워크로드가 Cloud Service Mesh 인증 기관과 함께 새 컨트롤 플레인을 사용하도록 전환될 때까지 mTLS 트래픽이 중단됩니다.

플랫폼 참고 사항: CA 서비스는 Google Cloud 기반 GKE 클러스터, Google Distributed Cloud(소프트웨어만 해당), Distributed Cloud 플랫폼에서만 지원됩니다. asmcli install을 실행하고 다른 플랫폼에서 --ca gcp_cas를 지정하면 설치가 성공한 것으로 보이지만 워크로드가 시작되지 않습니다.

Cloud Service Mesh 인증 기관의 인증서에는 애플리케이션 서비스에 대한 다음 데이터가 포함됩니다.

• Google Cloud 프로젝트 ID
• GKE 네임스페이스
• GKE 서비스 계정 이름

중요: Cloud Service Mesh 인증 기관에서 발급한 인증서는 서비스 메시 내에서 보안 서비스 간 통신을 사용 설정하는 데만 사용해야 하며 다른 용도로 사용되지 않아야 합니다. 이러한 인증서는 서비스가 상호 TLS를 사용하여 서로 통신하려고 시도할 때마다 전송됩니다. 서비스 메시 외부에서 통신할 때 이러한 인증서를 사용하여 기밀 정보를 실수로 노출하지 않도록 해야 합니다.

CA 확인

asmcli install을 실행하여 업그레이드할 때는 asmcli가 새 컨트롤 플레인에서 사용 설정해야 하는 CA를 지정합니다.

CA를 변경하면 새 컨트롤 플레인에 워크로드를 배포할 때 다운타임이 발생합니다. 다운타임을 예약할 수 없으면 새 컨트롤 플레인에 대해 이전 컨트롤 플레인에 사용되는 것과 동일한 CA를 지정합니다. 메시에 사용 설정된 CA가 확실하지 않으면 다음 명령어를 실행합니다.

1. 네임스페이스 중 하나에서 포드 목록을 가져옵니다.

   kubectl get pods -n NAMESPACE
   

2. 다음 명령어에서 POD_NAME을 포드 중 하나의 이름으로 바꿉니다.

   kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
   

   Cloud Service Mesh 인증 기관이 네임스페이스에서 사용 설정되면 다음 출력이 표시됩니다.

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

게이트웨이 구성 준비

Cloud Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 들어오거나 나가는 HTTP/TCP 연결을 수신하는 메시지의 에지에서 작동하는 부하 분산기를 설명합니다. 게이트웨이는 메시로 들어오고 나가는 트래픽을 미세하게 제어할 수 있는 Envoy 프록시입니다.

asmcli는 istio-ingressgateway를 설치하지 않습니다. 컨트롤 플레인과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요.

플랫폼 업그레이드(선택사항)

Cloud Service Mesh를 현재 플랫폼도 지원하는 지원되는 최신 버전으로 업그레이드하는 것이 좋습니다. 그런 다음 지원되는 플랫폼 및 Kubernetes 버전 범위 내에 있도록 환경을 업그레이드합니다. 마지막으로 필요한 경우 Cloud Service Mesh를 최신 지원 버전으로 업그레이드합니다.

다음 단계

• 종속 도구 설치 및 클러스터 검증