Kubernetes #3의 카나리아 배포: Istio

Istio+Kiali를 사용하여 Canary 배포 시작 및 시각화

이 시리즈의 기사

1. Kubernetes #1의 카나리아 배포: Gitlab CI
2. Kubernetes의 카나리아 배포 #2: Argo 롤아웃
3. (이 기사)
4. Jenkins-X Istio Flagger를 사용한 카나리아 배포

카나리아 배포

우리는 당신이 읽기를 바랍니다 제 부여기서는 Canary 배포가 무엇인지 간략하게 설명하고 표준 Kubernetes 리소스를 사용하여 이를 구현하는 방법을 보여주었습니다.

이스 티오

그리고 이 기사를 읽으면 Istio가 무엇인지 이미 알고 있다고 가정합니다. 그렇지 않다면 그것에 대해 읽을 수 있습니다. 여기에.

테스트 신청

각 포드에는 애플리케이션과 istio-proxy라는 두 개의 컨테이너가 포함되어 있습니다.

frontend-nginx 및 백엔드 Python Pod와 함께 간단한 테스트 애플리케이션을 사용합니다. nginx 포드는 각 요청을 백엔드 포드로 리디렉션하고 프록시로 작동합니다. 세부정보는 다음 yaml에서 확인할 수 있습니다.

• 프론트엔드.yaml
• 백엔드.yaml
• istio.yaml

테스트 애플리케이션 직접 실행

내 예를 따라 이 테스트 애플리케이션을 직접 사용하려면 다음을 참조하세요. 프로젝트 읽어보기.

초기 배포

첫 번째 배포를 시작하면 애플리케이션의 포드에 컨테이너가 2개만 있는 것을 볼 수 있습니다. 즉, Istio 사이드카가 이제 막 구현되고 있는 것입니다.

그리고 네임스페이스에 Istio Gateway Loadbalancer도 표시됩니다. istio-system:

트래픽 생성

다음 IP를 사용하여 프런트엔드 포드에서 수신하고 백엔드 포드로 전달할 트래픽을 생성합니다.

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

우리는 또한 추가할 것입니다 frontend.istio-test 호스트 파일에.

Kiali를 통해 메시 보기

Tracing, Grafana, Prometheus 및 Kiali와 함께 테스트 애플리케이션과 Istio를 설치했습니다(자세한 내용은 아래 참조). 프로젝트 읽어보기). 따라서 다음을 통해 Kiali를 사용할 수 있습니다.

istioctl dashboard kiali # admin:admin

Kiali는 메시를 통해 현재 트래픽을 시각화합니다.

보시다시피 트래픽의 100%가 프런트엔드 서비스로 이동한 다음 v1 라벨이 있는 프런트엔드 포드로 이동합니다. 요청을 백엔드 서비스로 리디렉션하고 다시 백엔드 포드로 리디렉션하는 간단한 nginx 프록시를 사용하고 있기 때문입니다. v1이라는 라벨을 사용하세요.

Kiali는 Istio와 잘 작동하며 박스형 메시 렌더링 솔루션을 제공합니다. 정말 좋아요.

카나리아 배포

우리 백엔드에는 이미 두 개의 k8s 배포가 있습니다. 하나는 v1용이고 다른 하나는 v2용입니다. 이제 Istio에게 특정 비율의 요청을 v2로 전달하도록 지시하면 됩니다.

1단계: 10%

그리고 우리가 해야 할 일은 VirtualService의 가중치를 조정하는 것뿐입니다. istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

요청의 10%가 v2로 리디렉션되는 것을 볼 수 있습니다.

2단계: 50%

이제 50%까지만 늘리면 충분합니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

3단계: 100%

이제 Canary 배포가 완료된 것으로 간주될 수 있으며 모든 트래픽이 v2로 리디렉션됩니다.

카나리아를 수동으로 테스트하기

이제 모든 요청의 2%를 v10 백엔드로 보낸다고 가정해 보겠습니다. v2를 수동으로 테스트하여 모든 것이 예상대로 작동하는지 확인하려면 어떻게 해야 합니까?

HTTP 헤더를 기반으로 특별한 일치 규칙을 추가할 수 있습니다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

이제 컬을 사용하여 헤더를 전송하여 v2 요청을 강제할 수 있습니다.

헤더가 없는 요청은 여전히 ​​1/10 비율로 구동됩니다.

두 가지 종속 버전에 대한 카나리아

이제 프런트엔드와 백엔드 모두에 대해 버전 v2가 있는 옵션을 고려해 보겠습니다. 두 경우 모두 트래픽의 10%가 v2로 이동하도록 지정했습니다.

프런트엔드 v1과 v2는 모두 백엔드 v1과 v10에 대해 1/2의 비율로 트래픽을 전달하는 것을 볼 수 있습니다.

v2과 호환되지 않기 때문에 frontend-v2의 트래픽을 backend-v1로만 전달해야 한다면 어떻게 해야 합니까? 이를 위해 협상을 통해 backend-v1에 도달하는 트래픽을 제어하는 ​​프런트엔드에 10/2 비율을 설정합니다. sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

결과적으로 우리는 필요한 것을 얻습니다.

수동 Canary 접근 방식과의 차이점

В 첫 번째 부분 두 개의 k8s 배포를 사용하여 Canary 배포를 수동으로 수행했습니다. 여기서 우리는 복제본 수를 변경하여 요청 비율을 제어했습니다. 이 접근 방식은 효과적이지만 심각한 단점이 있습니다.

Istio를 사용하면 복제본 수에 관계없이 요청 비율을 결정할 수 있습니다. 이는 예를 들어 HPA(Horizontal Pod Autoscalers)를 사용할 수 있으며 Canary 배포의 현재 상태에 따라 구성할 필요가 없음을 의미합니다.

합계

Istio는 훌륭하게 작동하며 Kiali와 함께 사용하면 매우 강력한 조합이 됩니다. 다음 관심 목록은 자동화 및 Canary 분석을 위해 Spinnaker와 Istio를 결합하는 것입니다.

출처 : habr.com