이 페이지에서는 제어 영역의 버전 작동 방식에 대해 설명하고 안전한 서비스 메시 업그레이드(및 롤백)에 이를 사용하는 이점에 대해 보여줍니다. Anthos Service Mesh의 기본 설치 프로세스는 버전 1.6.8까지는 제어 영역 버전을 사용하지 않았습니다. 버전을 도입하면 설치 절차에 약간의 노력과 수정이 필요할 수 있지만, 버전 사용에는 상당한 이점이 따르므로 이를 사용하는 것을 권장합니다.
서비스 메시 기초
Anthos Service Mesh 설치는 두 가지 주요 부분으로 이루어집니다. 먼저 istioctl 명령줄 도구 또는 install_asm 스크립트를 사용하여 클러스터 내 제어 영역을 설치하거나 Google 관리형 제어 영역을 구성합니다. 제어 영역은 메시 구성을 관리하는 시스템 서비스 집합으로 구성됩니다. 다음으로 각 워크로드 간에 네트워크 통신을 가로채는 특수 사이드카 프록시를 환경에 배포합니다. 프록시는 제어 영역과 통신하여 구성을 가져오므로, 워크로드를 변경하지 않고도 메시 주변의 트래픽(데이터 영역 트래픽)을 직접 연결하고 제어할 수 있습니다.
프록시를 배포하려면 자동 사이드카 삽입(자동 삽입)이라는 프로세스를 사용하여 각 워크로드 pod에서 추가 사이드카 컨테이너로 프록시를 실행합니다. 워크로드를 배포하는 데 사용하는 Kubernetes 매니페스트를 수정할 필요는 없지만 네임스페이스에 라벨을 추가하고 pod를 다시 시작해야 합니다.
Anthos Service Mesh 1.6 이전에는 이전 버전을 즉시 대체하는 제어 영역의 새 버전을 설치하는 방식으로 업그레이드했습니다. 이 절차를 인플레이스(In-Place) 업그레이드라고 부르는데 이러한 방식은 장애가 발생하면 롤백하기가 어려울 수 있으므로 위험합니다. 프록시를 다시 삽입하고 새로운 제어 영역 버전과 통신하도록 하려면 모든 네임스페이스에서 모든 워크로드를 다시 시작해야 했습니다. 메시의 워크로드 및 네임스페이스 수에 따라 전체 업그레이드 프로세스를 완료하는 데 1시간이 넘게 걸릴 수도 있습니다. 인플레이스(In-Place) 업그레이드는 다운타임을 초래할 수 있으며 유지보수 기간에 예약해야 합니다.
버전을 사용하여 메시를 안전하게 업그레이드
트래픽 제어 기능은 서비스 메시를 사용할 때의 주요 이점 중 하나입니다. 예를 들어 애플리케이션을 프로덕션에 처음 배포할 때 애플리케이션의 새 버전으로 트래픽을 점진적으로 전환할 수 있습니다. 업그레이드 중에 문제가 발견되더라도 트래픽을 원래 버전으로 다시 전환할 수 있어 간단하고 위험도가 낮은 롤백이 지원됩니다. 이 절차는 카나리아 릴리스라고 부르며 새 배포와 관련된 위험을 크게 줄여줍니다.
마찬가지로 서비스 메시 자체의 업그레이드 관련 위험을 최소화할 수 있습니다. Anthos Service Mesh 1.6 이상에서는 제어 영역 버전을 사용하여 카나리아 업그레이드를 지원합니다. 카나리아 업그레이드를 통해 기존 제어 영역과 함께 새로운 별도의 제어 영역 및 구성을 설치합니다. 설치 프로그램은 버전이라는 문자열을 할당하여 새 제어 영역을 식별합니다. 처음에는 사이드카 프록시가 이전 버전의 제어 영역에서 구성을 계속 수신합니다. 네임스페이스에 새 제어 영역 버전의 라벨을 지정하여 워크로드를 새 제어 영역과 점진적으로 연결합니다. 네임스페이스에 새 버전의 라벨을 지정한 후에는 새 사이드카가 삽입되고 새 제어 영역에서 구성을 받을 수 있도록 워크로드 pod를 다시 시작합니다. 문제가 발생하면 워크로드를 원래 제어 영역과 연결하여 쉽게 롤백할 수 있습니다.
자동 삽입은 어떻게 작동되나요?
자동 삽입은 허용 제어라고 부르는 Kubernetes 기능을 사용합니다. 새로 생성된 포드를 확인하도록 허용 웹훅 변형이 등록됩니다. 웹훅은 네임스페이스 선택기를 사용해 특정 라벨이 있는 네임스페이스에 배포되는 포드와만 일치하도록 구성됩니다. 포드가 일치하면 웹훅이 제어 영역에서 제공하는 삽입 서비스를 참조하여 사이드카를 실행하는 데 필요한 컨테이너와 볼륨이 포함된 포드의 새로운 변형 구성을 가져옵니다.
- 설치 중에 웹훅 구성이 생성됩니다. Kubernetes API 서버에 웹훅을 등록합니다.
- Kubernetes API 서버는 웹훅
namespaceSelector와 일치하는 네임스페이스의 pod 배포를 감시합니다. - 네임스페이스는
namespaceSelector와 일치하도록 라벨이 지정됩니다. - 네임스페이스에 배포된 pod는 웹훅을 트리거합니다.
- 제어 영역에서 제공하는
inject서비스는 사이드카를 삽입하도록 pod 사양을 변경합니다.
버전이란?
자동 삽입에 사용되는 라벨은 다른 사용자 정의 Kubernetes 라벨과 유사합니다. 라벨은 기본적으로 태깅이라는 개념을 지원하는 데 사용할 수 있는 키-값 쌍입니다. 라벨은 태깅 및 버전 관리에 광범위하게 사용됩니다(예: Git 태그, Docker 태그, Knative 버전).
Anthos Service Mesh 버전 1.6.8까지 기본 설치 절차에서는 웹훅에서 istio-injection=enabled 라벨을 사용하도록 네임스페이스 선택기를 구성하는 규칙이 설정되었습니다.
현재의 Anthos Service Mesh 설치 프로세스를 사용하면 설치된 제어 영역에 버전 문자열로 태그를 지정할 수 있습니다. 설치 프로그램은 모든 제어 영역 객체에 버전을 라벨로 지정합니다. 키-값 쌍의 키는 istio.io/rev이지만 버전 라벨의 값은 Google 관리 제어 영역 및 클러스터 내 제어 영역에 대해 다릅니다.
클러스터 내 제어 영역의 경우
istiod서비스 및 배포에는 일반적으로istio.io/rev=asm-1106-2과 유사한 버전 라벨이 있습니다. 여기서asm-1106-2은 Anthos Service Mesh 버전을 식별합니다. 버전은 서비스 이름의 일부가 됩니다(예:istiod-asm-1106-2.istio-system).Google 관리형 제어 영역의 경우 버전 라벨은 출시 채널에 해당합니다.
버전 라벨 채널 istio.io/rev=asm-managed일반 istio.io/rev=asm-managed-rapid신속 istio.io/rev=asm-managed-stable정식
자동 주입을 사용 설정하려면 제어 영역의 버전 라벨과 일치하는 버전 라벨을 네임스페이스에 추가합니다. 예를 들어 버전 istio.io/rev=asm-1106-2이 있는 제어 영역은 라벨이 istio.io/rev=asm-1106-2인 네임스페이스의 포드를 선택하고 사이드카를 삽입합니다.
카나리아 업그레이드 절차
버전 라벨을 사용하면 카나리아 업그레이드와 클러스터 내 제어 영역의 롤백을 손쉽게 수행할 수 있습니다. Google 관리형 제어는 유사한 프로세스를 사용하지만 클러스터는 해당 채널 내의 최신 버전으로 자동 업그레이드됩니다.
다음 절차는 프로세스의 작동 방법을 설명합니다.
- 기존 Anthos Service Mesh 또는 오픈소스 Istio 설치를 사용해 시작합니다. 네임스페이스에서 버전 라벨 또는
istio-injection=enabled라벨을 사용하는지 여부는 중요하지 않습니다. - 새 버전의 제어 영역을 설치할 때 버전 문자열을 사용합니다. 버전 문자열 덕분에 새 제어 영역이 기존 버전과 함께 설치됩니다. 새 설치에는 이 특정한 버전 라벨이 포함된 네임스페이스를 확인하도록
namespaceSelector가 구성된 새로운 웹훅 구성이 포함됩니다. - 네임스페이스에서 이전 라벨을 삭제하고 새 버전 라벨을 추가한 후 포드를 다시 시작하여 사이드카 프록시를 새 제어 영역으로 마이그레이션합니다. Anthos Service Mesh로 버전을 사용하는 경우
istio-injection=enabled라벨 사용을 중지해야 합니다. 버전이 있는 제어 영역은 버전 라벨이 있는 경우에도istio-injection라벨이 있는 네임스페이스의 포드를 선택하지 않습니다. 새 제어 영역의 웹훅은 사이드카를 포드에 삽입합니다. - 업그레이드된 제어 영역과 연결된 워크로드를 신중하게 테스트하고 계속 업그레이드를 출시하거나 원래의 제어 영역으로 롤백합니다.
포드를 새 제어 영역과 연결한 후에도 기존 제어 영역과 웹훅은 계속 설치됩니다. 이전 웹훅은 새 제어 영역으로 마이그레이션된 네임스페이스의 포드에는 영향을 미치지 않습니다. 새 버전 라벨을 삭제하고 기존 라벨을 다시 추가한 후에 포드를 재시작하면 기존 제어 영역으로 네임스페이스의 포드를 롤백할 수 있습니다. 업그레이드가 성공적으로 완료되었다는 확신이 생기면 이전 제어 영역을 삭제할 수 있습니다.
버전을 사용한 업그레이드에 대한 자세한 단계는 업그레이드 가이드를 참조하세요.
변형된 웹훅 구성 자세히 살펴보기
자동 사이드카 삽입을 위한 변형 웹훅을 이해하는 가장 좋은 방법은 구성을 직접 검사하는 것입니다. 다음 명령어를 사용하세요.
kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml
설치한 각 제어 영역마다 별도의 구성이 표시됩니다. 버전 기반 제어 영역의 네임스페이스 선택기는 다음과 같습니다.
namespaceSelector:
matchExpressions:
- key: istio-injection
operator: DoesNotExist
- key: istio.io/rev
operator: In
values:
- asm-173-6
선택기는 실행 중인 Anthos Service Mesh 또는 Istio 버전에 따라 달라질 수 있습니다. 이 선택기는 istio-injection 라벨도 없는 한 특정 버전 라벨이 있는 네임스페이스와 일치합니다.
pod가 선택기와 일치하는 네임스페이스에 배포되면 pod 사양이 변형의 인젝터 서비스에 제출됩니다. 호출되는 인젝터 서비스는 다음과 같이 지정됩니다.
service:
name: istiod-asm-173-6
namespace: istio-system
path: /inject
port: 443
서비스는 inject URL 경로의 포트 443에서 제어 영역에 의해 노출됩니다.
rules 섹션은 웹훅이 pod 생성에 적용되어야 한다고 지정합니다.
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'
요약
네임스페이스에서 버전 라벨을 사용하여 자동 삽입을 사용 설정하는 변경은 익숙해지기 위해 어느 정도 수고가 필요하지만, 버전 라벨이 안전한 카나리아 업그레이드에 제공하는 이점은 충분히 그런 수고를 무릅쓸 가치가 있습니다.