Cloud Service Mesh 컨트롤 플레인 버전

이 페이지에서는 제어 영역의 버전 작동 방식에 대해 설명하고 안전한 서비스 메시 업그레이드(및 롤백)에 이를 사용하는 이점에 대해 보여줍니다.

서비스 메시 설치 기초

대략적으로 Cloud Service Mesh 설치는 두 가지 주요 단계로 구성됩니다.

먼저 asmcli 도구를 사용하여 클러스터 내 제어 영역을 설치하거나 관리형 제어 영역을 구성합니다. 제어 영역은 메시 구성을 관리하는 시스템 서비스 집합으로 구성됩니다.
다음으로 각 워크로드 간에 네트워크 통신을 가로채는 특수 사이드카 프록시를 환경에 배포합니다. 프록시는 제어 영역과 통신하여 구성을 가져오므로, 워크로드를 변경하지 않고도 메시 주변의 트래픽(데이터 영역 트래픽)을 직접 연결하고 제어할 수 있습니다.

프록시를 배포하려면 자동 사이드카 삽입(자동 삽입)이라는 프로세스를 사용하여 각 워크로드 포드에서 추가 사이드카 컨테이너로 프록시를 실행합니다. 워크로드를 배포하는 데 사용하는 Kubernetes 매니페스트를 수정할 필요는 없지만 네임스페이스에 라벨을 추가하고 포드를 다시 시작해야 합니다.

버전을 사용하여 메시를 안전하게 업그레이드

트래픽 제어 기능은 서비스 메시를 사용할 때의 주요 이점 중 하나입니다. 예를 들어 애플리케이션을 프로덕션에 처음 배포할 때 애플리케이션의 새 버전으로 트래픽을 점진적으로 전환할 수 있습니다. 업그레이드 중에 문제가 발견되더라도 트래픽을 원래 버전으로 다시 전환할 수 있어 간단하고 위험도가 낮은 롤백이 지원됩니다. 이 절차는 카나리아 릴리스라고 부르며 새 배포와 관련된 위험을 크게 줄여줍니다.

참고: 대체 업그레이드 유형은 새 버전의 제어 영역을 설치하여 업그레이드하는 인플레이스 업그레이드입니다. 이전 버전이 새 제어 영역 버전으로 즉시 대체됩니다. 인플레이스 업그레이드는 오류가 있을 때 롤백이 어려울 수 있기 때문에 위험할 수 있습니다. 프록시를 다시 삽입하고 새로운 제어 영역 버전과 통신하도록 하려면 모든 네임스페이스에서 모든 워크로드를 다시 시작해야 합니다. 메시의 워크로드 및 네임스페이스 수에 따라 전체 업그레이드 프로세스를 완료하는 데 1시간이 넘게 걸릴 수도 있습니다. 인플레이스 업그레이드는 다운타임을 초래할 수 있으며 유지보수 기간에 예약해야 합니다.

카나리아 업그레이드에서 제어 영역 버전을 사용하면 기존 제어 영역과 함께 새로운 개별 제어 영역 및 구성을 설치합니다. 설치 프로그램은 버전이라는 문자열을 할당하여 새 제어 영역을 식별합니다. 처음에는 사이드카 프록시가 이전 버전의 제어 영역에서 구성을 계속 수신합니다. 네임스페이스 또는 포드에 새 제어 영역 버전의 라벨을 지정하여 워크로드를 새 제어 영역과 점진적으로 연결합니다. 네임스페이스 또는 포드에 새 버전의 라벨을 지정한 후에는 새 사이드카가 자동 삽입되고 새 제어 영역에서 구성을 받을 수 있도록 워크로드 포드를 다시 시작합니다. 문제가 발생하면 워크로드를 원래 제어 영역과 연결하여 쉽게 롤백할 수 있습니다.

자동 삽입은 어떻게 작동되나요?

자동 삽입은 허용 제어라고 부르는 Kubernetes 기능을 사용합니다. 새로 생성된 포드를 확인하도록 허용 웹훅 변형이 등록됩니다. 웹훅은 네임스페이스 선택기를 사용해 특정 라벨이 있는 네임스페이스에 배포되는 포드와만 일치하도록 구성됩니다. 포드가 일치하면 웹훅이 제어 영역에서 제공하는 삽입 서비스를 참조하여 사이드카를 실행하는 데 필요한 컨테이너와 볼륨이 포함된 포드의 새로운 변형 구성을 가져옵니다.

사이드카 인젝터

설치 중에 웹훅 구성이 생성됩니다. 웹훅은 Kubernetes API 서버에 등록됩니다.
Kubernetes API 서버는 웹훅 namespaceSelector와 일치하는 네임스페이스의 포드 배포를 감시합니다.
네임스페이스는 namespaceSelector와 일치하도록 라벨이 지정됩니다.
네임스페이스에 배포된 포드는 웹훅을 트리거합니다.
제어 영역에서 제공하는 inject 서비스는 사이드카를 자동 삽입하도록 포드 사양을 변경합니다.

버전이란?

자동 삽입에 사용되는 라벨은 다른 사용자 정의 Kubernetes 라벨과 유사합니다. 라벨은 기본적으로 라벨 지정이라는 개념을 지원하는 데 사용할 수 있는 키-값 쌍입니다. 라벨은 태깅 및 버전 관리에 광범위하게 사용됩니다. 예를 들면 Git 태그, Docker 태그, Knative 버전입니다.

현재의 Cloud Service Mesh 설치 프로세스를 사용하면 설치된 컨트롤 플레인에 버전 문자열로 라벨을 지정할 수 있습니다. 설치 프로그램은 모든 제어 영역 객체에 버전을 라벨로 지정합니다. 키-값 쌍의 키는 istio.io/rev이지만 관리형 제어 영역과 클러스터 내 제어 영역의 버전 라벨 값은 다릅니다.

클러스터 내 컨트롤 플레인의 경우 istiod 서비스와 배포에는 일반적으로 istio.io/rev=asm-1187-26과 유사한 버전 라벨이 있습니다. 여기서 asm-1187-26는 Cloud Service Mesh 버전을 식별합니다. 버전은 서비스 이름의 일부가 됩니다(예: istiod-asm-1187-26.istio-system).
관리형 제어 영역의 경우 버전 라벨은 출시 채널에 해당합니다.

버전 라벨 채널

istio.io/rev=asm-managed 일반

istio.io/rev=asm-managed-rapid 신속

istio.io/rev=asm-managed-stable 정식

버전 라벨	채널
`istio.io/rev=asm-managed`	일반
`istio.io/rev=asm-managed-rapid`	신속
`istio.io/rev=asm-managed-stable`	정식

또한 기본 삽입 라벨을 사용하는 옵션이 있습니다(예: istio-injection=enabled).

자동 삽입을 사용 설정하려면 제어 영역의 버전 라벨과 일치하는 버전 라벨을 네임스페이스에 추가합니다. 예를 들어 버전 istio.io/rev=asm-1187-26가 있는 제어 영역은 라벨이 istio.io/rev=asm-1187-26인 네임스페이스의 pod를 선택하고 사이드카를 삽입합니다.

카나리아 업그레이드 절차

버전 라벨을 사용하면 카나리아 업그레이드와 클러스터 내 제어 영역의 롤백을 손쉽게 수행할 수 있습니다. 관리형 제어는 유사한 프로세스를 사용하지만 클러스터는 자동으로 해당 채널 내 최신 버전으로 업그레이드됩니다.

카나리아 업그레이드

다음 절차는 프로세스의 작동 방법을 설명합니다.

기존 Cloud Service Mesh 또는 오픈소스 Istio 설치를 사용해 시작합니다. 네임스페이스에서 버전 라벨 또는 istio-injection=enabled 라벨을 사용하는지 여부는 중요하지 않습니다.
새 버전의 제어 영역을 설치할 때 버전 문자열을 사용합니다. 버전 문자열 덕분에 새 제어 영역이 기존 버전과 함께 설치됩니다. 새 설치에는 이 특정한 버전 라벨이 포함된 네임스페이스를 확인하도록 namespaceSelector가 구성된 새로운 웹훅 구성이 포함됩니다.
네임스페이스에서 이전 라벨을 삭제하고 새 버전 라벨을 추가한 후 포드를 다시 시작하여 사이드카 프록시를 새 제어 영역으로 마이그레이션합니다. Cloud 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-1187-26

선택기는 실행 중인 Cloud Service Mesh 또는 Istio 버전에 따라 달라질 수 있습니다. 이 선택기는 istio-injection 라벨도 없는 한 특정 버전 라벨이 있는 네임스페이스와 일치합니다.

포드가 선택기와 일치하는 네임스페이스에 배포되면 포드 사양이 변형의 인젝터 서비스에 제출됩니다. 호출되는 인젝터 서비스는 다음과 같이 지정됩니다.

     service:
        name: istiod-asm-1187-26
        namespace: istio-system
        path: /inject
        port: 443

서비스는 inject URL 경로의 포트 443에서 제어 영역에 의해 노출됩니다.

rules 섹션은 웹훅이 포드 생성에 적용되어야 한다고 지정합니다.

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'