업그레이드 계획

미리보기 — asmcli

이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

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

카나리아 업그레이드 정보

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

그런 다음 네임스페이스에 동일한 revision 라벨을 설정하고 순차적 재시작을 수행하여 워크로드를 새 제어 영역으로 마이그레이션합니다. 재시작하면 프록시가 새 제어 영역을 사용하도록 사이드카 프록시가 포드에 다시 삽입됩니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션 테스트가 완료되면 모든 트래픽을 새 제어 영역으로 마이그레이션하거나 이전 제어 영역으로 롤백할 수 있습니다. 이 방식은 새로운 제어 영역이 이전 제어 영역을 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다.

이 초기 미리보기의 경우 asmcli는 기본적으로 버전 라벨을 사용하여 istio-ingressgateway를 설치합니다. 이렇게 하면 제어 영역뿐만 아니라 istio-ingressgateway의 카나리아 업그레이드를 수행할 수 있습니다.

제어 영역 맞춤설정

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

주의: 오버레이 파일을 생략해도 설치가 성공합니다. 하지만 제어 영역 및 인그레스 게이트웨이가 다시 배포될 때 생략된 값이 기본값으로 재설정되기 때문에 서비스 메시에 의도한 것과 다른 구성이 포함됩니다.

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

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

인증 기관 선택

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

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

현재 Anthos Service Mesh 설치에서 Istio CA(이전의 'Citadel')를 사용하는 경우 업그레이드할 때 Mesh CA로 전환할 수 있지만 다운타임을 예약해야 합니다. 업그레이드 중에는 모든 워크로드가 Mesh CA와 함께 새 제어 영역을 사용하도록 전환될 때까지 mTLS 트래픽이 중단됩니다.

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

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

중요: Mesh CA에서 발급한 인증서는 서비스 메시 내에서 보안 서비스 간 통신을 사용 설정하는 데만 사용해야 하며 다른 용도로 사용되지 않아야 합니다. 이러한 인증서는 서비스가 상호 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
   

   Mesh CA가 네임스페이스에서 사용 설정되면 다음 출력이 표시됩니다.

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

   게이트웨이 구성 준비

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

기본적으로 asmcli는 istio-ingressgateway를 설치하지 않습니다. 제어 영역과 게이트웨이를 개별적으로 배포하고 관리하는 것이 좋습니다. 자세한 내용은 게이트웨이 설치 및 업그레이드를 참조하세요. 클러스터 내 제어 영역과 함께 기본 istio-ingressgateway를 설치해야 하는 경우에는 --option legacy-default-ingressgateway 인수를 포함합니다.

다음 단계

• 시작하기