Istio를 사용한 마이크로서비스로 돌아갑니다. 2 부

메모. 번역: 첫 번째 부분 이 시리즈는 Istio 기능을 소개하고 실제로 이를 시연하는 데 전념했습니다. 이제 이 서비스 메시의 구성 및 사용에 대한 보다 복잡한 측면, 특히 미세 조정된 라우팅 및 네트워크 트래픽 관리에 대해 설명하겠습니다.

또한 이 기사에서는 저장소의 구성(Kubernetes 및 Istio에 대한 매니페스트)을 사용한다는 점을 상기시켜 드립니다. istio-mastery.

교통 관리

Istio를 사용하면 다음을 제공하는 새로운 기능이 클러스터에 나타납니다.

• 동적 요청 라우팅: 카나리아 출시, A/B 테스트
• 로드 밸런싱: 해시를 기반으로 단순하고 일관적입니다.
• 낙상 후 회복: 시간 초과, 재시도, 회로 차단기;
• 결함 삽입: 지연, 요청 중단 등

기사가 계속되면서 선택한 애플리케이션을 예로 사용하여 이러한 기능을 설명하고 그 과정에서 새로운 개념을 소개할 것입니다. 그러한 첫 번째 개념은 다음과 같습니다. DestinationRules (즉, 트래픽/요청 수신자에 대한 규칙 - 대략적인 번역), 이를 통해 A/B 테스트를 활성화합니다.

A/B 테스트: 실제로 DestinationRules

A/B 테스트는 두 가지 버전의 애플리케이션(보통 시각적으로 다름)이 있고 어떤 버전이 사용자 경험을 향상시킬지 100% 확신할 수 없는 경우에 사용됩니다. 따라서 우리는 두 버전을 동시에 실행하고 지표를 수집합니다.

A/B 테스트 시연에 필요한 두 번째 버전의 프런트엔드를 배포하려면 다음 명령을 실행하세요.

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

"그린 버전"의 배포 매니페스트는 두 가지 위치에서 다릅니다.

1. 이미지는 다른 태그를 기반으로 합니다. istio-green,
2. 포드에는 라벨이 있습니다. version: green.

두 배포 모두 라벨이 있으므로 app: sa-frontend,가상 서비스로 라우팅된 요청 sa-external-services 서비스를 위해 sa-frontend, 모든 인스턴스로 리디렉션되고 로드는 다음을 통해 분산됩니다. 라운드 로빈 알고리즘, 이는 다음과 같은 상황으로 이어질 것입니다:

요청한 파일을 찾을 수 없습니다

이러한 파일은 응용 프로그램 버전에 따라 이름이 다르기 때문에 찾을 수 없습니다. 이것을 확인해 봅시다:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

즉, index.html한 버전의 정적 파일을 요청하는 는 로드 밸런서에 의해 다른 버전이 있는 포드로 전송될 수 있습니다. 여기서는 분명한 이유로 그러한 파일이 존재하지 않습니다. 따라서 애플리케이션이 작동하려면 다음과 같은 제한 사항을 설정해야 합니다.index.html을 제공한 동일한 버전의 애플리케이션이 후속 요청을 제공해야 합니다.".

일관된 해시 기반 로드 밸런싱을 통해 목표를 달성하겠습니다. (일관적인 해시 로드 밸런싱). 이 경우 동일한 클라이언트의 요청이 동일한 백엔드 인스턴스로 전송됩니다., 사전 정의된 속성(예: HTTP 헤더)이 사용됩니다. DestinationRules를 사용하여 구현되었습니다.

목적지규칙

후 가상서비스 원하는 서비스에 요청을 보냈습니다. DestinationRules를 사용하여 이 서비스의 인스턴스로 향하는 트래픽에 적용될 정책을 정의할 수 있습니다.

Istio 리소스를 사용한 트래픽 관리

주의: 여기에서는 네트워크 트래픽에 대한 Istio 리소스의 영향을 이해하기 쉬운 방식으로 제시합니다. 정확하게 말하면 요청을 보낼 인스턴스에 대한 결정은 CRD에 구성된 Ingress 게이트웨이의 Envoy에 의해 이루어집니다.

대상 규칙을 사용하면 일관된 해시를 사용하고 동일한 서비스 인스턴스가 동일한 사용자에게 응답하도록 로드 밸런싱을 구성할 수 있습니다. 다음 구성을 사용하면 이를 달성할 수 있습니다(Destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP 헤더의 내용을 기반으로 해시가 생성됩니다. version.

다음 명령을 사용하여 구성을 적용합니다.

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

이제 아래 명령을 실행하고 헤더를 지정할 때 올바른 파일을 얻었는지 확인하십시오. version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

주의: 헤더에 다른 값을 추가하고 브라우저에서 직접 결과를 테스트하려면 다음을 사용할 수 있습니다. 이 확장 크롬으로 (또는 이것으로 Firefox의 경우 - 약. 번역).

일반적으로 DestinationRules는 로드 밸런싱 영역에서 더 많은 기능을 제공합니다. 자세한 내용은 다음을 참조하세요. 공식 문서.

VirtualService를 더 자세히 연구하기 전에 다음 명령을 실행하여 애플리케이션의 "그린 버전"과 해당 트래픽 방향 규칙을 삭제해 보겠습니다.

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

미러링: 실제 가상 서비스

그림자 (“차폐”) 또는 미러링 (“미러링”) 최종 사용자에게 영향을 주지 않고 프로덕션 변경 사항을 테스트하려는 경우에 사용됩니다. 이를 위해 원하는 변경 사항이 적용된 두 번째 인스턴스에 요청을 복제(“미러링”)하고 결과를 살펴봅니다. 간단히 말해서, 이는 동료가 가장 중요한 문제를 선택하고 누구도 실제로 검토할 수 없을 정도로 거대한 먼지 덩어리 형태로 끌어오기 요청을 하는 때입니다.

이 시나리오를 실제로 테스트하기 위해 버그가 있는 SA-Logic의 두 번째 인스턴스를 만들어 보겠습니다(buggy) 다음 명령을 실행하여:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

이제 명령을 실행하여 모든 인스턴스가 다음과 같은지 확인하겠습니다. app=sa-logic 또한 해당 버전의 라벨이 있습니다.

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

서비스 sa-logic 라벨이 있는 포드를 대상으로 함 app=sa-logic, 따라서 모든 요청은 모든 인스턴스에 분산됩니다.

...하지만 우리는 요청이 v1 인스턴스로 전송되고 v2 인스턴스로 미러링되기를 원합니다.

우리는 VirtualService를 DestinationRule과 결합하여 이를 달성할 것입니다. 여기서 규칙은 VirtualService의 하위 집합과 특정 하위 집합에 대한 경로를 결정합니다.

대상 규칙에서 하위 집합 정의

하위 집합 (하위 집합) 다음 구성에 의해 결정됩니다(sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. 주인 (host) 이 규칙은 경로가 서비스를 향하는 경우에만 적용되도록 정의합니다. sa-logic;
2. 제목(name) 하위 집합은 하위 집합 인스턴스로 라우팅할 때 사용됩니다.
3. 라벨(label)는 인스턴스가 하위 집합의 일부가 되기 위해 일치해야 하는 키-값 쌍을 정의합니다.

다음 명령을 사용하여 구성을 적용합니다.

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

이제 하위 집합이 정의되었으므로 다음과 같이 sa-logic에 대한 요청에 규칙을 적용하도록 VirtualService를 구성할 수 있습니다.

1. 하위 집합으로 라우팅됨 v1,
2. 하위 집합으로 미러링됨 v2.

다음 선언문을 사용하면 계획을 달성할 수 있습니다(sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

여기에는 설명이 필요하지 않으므로 실제로 작동하는 모습을 살펴보겠습니다.

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

다음 명령을 호출하여 로드를 추가해 보겠습니다.

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Grafana의 결과를 보면 버그가 있는 버전(buggy)은 요청의 ~60%에 대해 실패를 초래하지만 실행 중인 서비스에서 응답할 때 이러한 실패 중 어느 것도 최종 사용자에게 영향을 미치지 않습니다.

다양한 버전의 sa-logic 서비스에 대한 성공적인 응답

여기서는 먼저 VirtualService가 서비스의 Envoy에 어떻게 적용되는지 살펴보았습니다. sa-web-app 요청을 한다 sa-logic, VirtualService를 통해 요청을 v1 하위 집합으로 라우팅하고 요청을 서비스의 v2 하위 집합으로 미러링하도록 구성된 사이드카 Envoy를 통과합니다. sa-logic.

여러분은 이미 가상 서비스가 단순하다고 생각할 수도 있습니다. 다음 섹션에서는 이 제품이 정말 훌륭하다는 점을 더 자세히 설명하겠습니다.

카나리아 출시

Canary 배포는 소수의 사용자에게 새 버전의 애플리케이션을 출시하는 프로세스입니다. 릴리스에 문제가 없는지 확인하고 그 후에야 이미 해당 (릴리스의) 품질에 확신을 갖고 다른 사용자에게 배포하는 데 사용됩니다.о더 많은 청중.

카나리아 롤아웃을 시연하기 위해 우리는 계속해서 하위 세트로 작업할 것입니다. buggy у sa-logic.

사소한 일로 시간을 낭비하지 말고 사용자의 20%를 버그가 있는 버전으로 즉시 보내고(이는 카나리아 출시를 나타냄) 나머지 80%는 일반 서비스로 보내도록 합시다. 이렇게 하려면 다음 VirtualService(sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1은 무게(weight) - 수신자 또는 수신자의 하위 집합으로 전달되는 요청의 비율을 지정합니다.

이전 VirtualService 구성을 업데이트해 보겠습니다. sa-logic 다음 명령을 사용하십시오.

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... 그러면 일부 요청이 실패로 이어지는 것을 즉시 확인할 수 있습니다.

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices는 카나리아 롤아웃을 가능하게 합니다. 이 경우 문제의 잠재적 영향을 사용자 기반의 20%로 좁혔습니다. 아주 멋진! 이제 코드가 확실하지 않은 경우(즉, 항상...) 미러링 및 카나리아 롤아웃을 사용할 수 있습니다.

시간 초과 및 재시도

그러나 버그가 항상 코드에서 끝나는 것은 아닙니다. "의 목록에서분산 컴퓨팅에 대한 8가지 오해"첫 번째는 '네트워크가 신뢰할 수 있다'는 잘못된 믿음입니다. 실제로는 네트워크 아니 신뢰할 수 있으며 이러한 이유로 타임아웃이 필요합니다. (시간 초과) 그리고 재시도 (재시도).

데모를 위해 동일한 문제 버전을 계속 사용할 것입니다. sa-logic (buggy), 무작위 오류로 네트워크의 불안정성을 시뮬레이션합니다.

버그가 있는 서비스가 응답하는 데 너무 오래 걸릴 확률이 1/3이고, 내부 서버 오류로 끝날 확률이 1/3이며, 페이지가 성공적으로 반환될 확률이 1/3입니다.

이러한 문제의 영향을 완화하고 사용자의 삶을 더 좋게 만들기 위해 우리는 다음을 수행할 수 있습니다.

1. 서비스가 응답하는 데 8초 이상 걸리는 경우 시간 초과를 추가합니다.
2. 요청이 실패하면 다시 시도하세요.

구현을 위해 다음 리소스 정의를 사용합니다(sa-logic-재시도-시간 초과-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. 요청 시간 초과는 8초로 설정됩니다.
2. 요청은 3번 재시도됩니다.
3. 그리고 응답 시간이 3초를 초과하면 각 시도는 실패한 것으로 간주됩니다.

이는 사용자가 8초 이상 기다릴 필요가 없고 실패한 경우 응답을 얻기 위해 XNUMX번의 새로운 시도를 하여 성공적인 응답 가능성을 높이기 때문에 최적화된 것입니다.

다음 명령을 사용하여 업데이트된 구성을 적용합니다.

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

그리고 성공적인 응답 수가 위에서 증가했음을 Grafana 그래프에서 확인하십시오.

시간 초과 및 재시도 추가 후 성공적인 응답 통계 개선

다음 섹션으로 넘어가기 전에 (또는 오히려 기사의 다음 부분으로 이동합니다. 왜냐하면 여기에는 더 이상 실제 실험이 없기 때문입니다. 대략 번역입니다.), 삭제 sa-logic-buggy 다음 명령을 실행하여 VirtualService를 실행합니다.

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

회로 차단기 및 격벽 패턴

우리는 자체 복구를 달성할 수 있는 마이크로서비스 아키텍처의 두 가지 중요한 패턴에 대해 이야기하고 있습니다. (자가 치유) 서비스.

회로 차단기 ("회로 차단기") 비정상으로 간주되는 서비스 인스턴스로 들어오는 요청을 종료하고 클라이언트 요청이 해당 서비스의 정상 인스턴스로 리디렉션되는 동안 이를 복원하는 데 사용됩니다(성공적인 응답 비율이 증가함). (참고: 패턴에 대한 더 자세한 설명은 다음과 같습니다. 여기에.)

칸막이 ("분할") 서비스 장애가 전체 시스템에 영향을 미치지 않도록 격리합니다. 예를 들어, 서비스 B가 중단되고 다른 서비스(서비스 B의 클라이언트)가 서비스 B에 요청을 하여 스레드 풀이 소진되고 다른 요청을 서비스할 수 없게 됩니다(서비스 B의 요청이 아니더라도). (참고: 패턴에 대한 더 자세한 설명은 다음과 같습니다. 여기에.)

이러한 패턴의 구현 세부 사항은 찾기 쉽기 때문에 생략하겠습니다. 공식 문서, 또한 기사의 다음 부분에서 논의될 인증 및 승인을 보여주고 싶습니다.

번역가의 추신

블로그에서도 읽어보세요.

• "Istio를 사용한 마이크로서비스로 돌아가기": 1부(주요 기능 소개), 파트 3(인증 및 권한 부여);
• «Conduit - Kubernetes용 경량 서비스 메시";
• «서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?".

출처 : habr.com