Istio에서 Anthos Service Mesh로 마이그레이션하려면 몇 가지 계획이 필요합니다. 이 페이지에서는 마이그레이션을 준비하는 데 도움이 되는 정보를 제공합니다.
프로필 검토
Anthos Service Mesh가 제공하는 구성 프로필은 오픈소스 Istio와 다릅니다. Anthos Service Mesh를 설치할 때는 환경에 적합한 구성 프로필을 사용합니다.
asm-gcp
: 동일한 Google Cloud 프로젝트에 있는 단일 클러스터 또는 여러 클러스터를 포함하는 메시에서 GKE에 설치하는 경우 이 프로필을 사용합니다.asm-gcp-multiproject
베타: 클러스터가 다른 Google Cloud 프로젝트에 있는 GKE에 설치하는 경우 이 프로필을 사용합니다.asm-multicloud
: 이 프로필을 사용하여 다음 환경에 설치합니다.- VMware용 GKE
- AWS용 GKE
- Amazon Elastic Kubernetes Service(Amazon EKS)
- Microsoft Azure Kubernetes Service(Microsoft AKS)
지원되는 Anthos Service Mesh 기능은 프로필마다 다릅니다. 구성에 적합한 프로필의 지원되는 기능을 검토합니다.
프로필 비교
Istio를 설치하는 데 사용한 구성 프로필을 사용할 Anthos Service Mesh 프로필과 비교할 수 있습니다.
설치 파일 다운로드의 단계에 따라 설치 및 서명 파일을 다운로드하고 콘텐츠를 추출하고 다운로드 파일에서
istioctl
버전을 사용하기 위한 경로를 설정합니다.사용하려는 Anthos Service Mesh 프로필의 매니페스트를 생성합니다.
istioctl manifest generate -f manifests/profiles/ASM_PROFLE > a.yaml
Istio를 설치할 때 사용한 프로필을 찾습니다. 프로필은 Istio 버전 간에 변경될 수 있으므로 Istio 버전과 일치하는 설치 패키지의 프로필이 필요합니다.
Istio를 설치하는 데 사용한 프로필의 매니페스트를 생성합니다.
istioctl manifest generate -f ISTIO_PROFILE > b.yaml
매니페스트를 비교합니다.
istioctl manifest diff a.yaml b.yaml
구성 파일 준비
Istio 설치를 맞춤설정한 경우에는 Anthos Service Mesh로 마이그레이션할 때 동일한 맞춤설정이 필요합니다. --set values
플래그를 추가하여 설치를 맞춤설정한 경우 해당 설정을 IstioOperator
구성 파일에 추가하는 것이 좋습니다. istioctl install
명령어를 실행할 때 구성 파일에 -f
플래그를 사용하여 구성 파일을 지정합니다.
인증 기관 선택
상호 TLS(mTLS) 인증서 발급을 위해 인증 기관(CA)으로 Citadel(이제 istiod
에 통합됨)을 계속 사용하거나 Anthos Service Mesh 인증 기관(Mesh CA)으로 마이그레이션하는 것을 선택할 수 있습니다.
일반적으로 다음과 같은 이유로 Mesh CA를 사용하는 것이 좋습니다.
- Mesh CA는 Google Cloud에서 동적으로 확장되는 워크로드에 최적화된 안정성과 확장성이 뛰어난 서비스입니다.
- Google은 Mesh CA를 사용하여 CA 백엔드의 보안과 가용성을 관리합니다.
- Mesh CA를 사용하면 여러 클러스터에서 신뢰할 수 있는 단일 루트를 사용할 수 있습니다.
하지만 다음과 같은 경우에는 Citadel을 사용하는 것이 좋을 수도 있습니다.
- 커스텀 CA가 있는 경우
- Mesh CA로 마이그레이션할 때 다운타임 시간을 예약할 수 없습니다. Mesh CA를 사용하는 것이 좋지만 모든 네임스페이스에서 모든 Pod를 다시 시작할 때까지 mTLS 트래픽은 실패하므로 마이그레이션을 위한 다운타임을 예약해야 합니다.
마이그레이션 프로세스 검토
Istio에서 마이그레이션하려면 이중 제어 영역 업그레이드 프로세스(Istio 문서에서는 카나리아 업그레이드라고 함)를 따릅니다. 이중 제어 영역 업그레이드를 사용하는 경우 기존 제어 영역과 함께 새 버전의 제어 영역을 설치합니다. 새 버전을 설치할 때 새 제어 영역의 버전을 식별하는 revision
라벨을 포함합니다. 각 버전은 자체 배포 및 서비스로 구현된 전체 Anthos Service Mesh 제어 영역입니다.
그런 다음 워크로드의 동일한 revision
라벨이 새 제어 영역을 가리키도록 설정하고 순차적 재시작을 수행하여 새 Anthos Service Mesh 버전으로 프록시를 다시 삽입합니다. 이 방식을 사용하면 일부 워크로드에서 업그레이드의 효과를 모니터링할 수 있습니다. 애플리케이션을 테스트한 후 모든 트래픽을 새 버전으로 마이그레이션할 수 있습니다. 이 방식은 새로운 제어 영역이 이전 버전의 제어 영역을 즉시 대체하는 인플레이스(In-Place) 업그레이드보다 훨씬 안전합니다.
블루-그린 배포용으로 부하 분산기 또는 라우터가 설정되어 있지 않으면 스테이징 환경에서 pod 재시작을 테스트하여 서비스에서 잠재적인 트래픽 중단을 처리할 수 있는지 확인하는 것이 좋습니다.