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

메모. 번역: 서비스 메시는 확실히 마이크로서비스 아키텍처를 따르는 애플리케이션을 위한 최신 인프라에서 관련 솔루션이 되었습니다. Istio는 많은 DevOps 엔지니어들의 입에 오르내릴 수 있지만, 제공하는 기능 측면에서 포괄적이기는 하지만 익숙해지는 데 상당한 시간이 필요할 수 있는 상당히 새로운 제품입니다. 통신 회사 Orange Networks에서 대규모 클라이언트를 위한 클라우드 컴퓨팅을 담당하고 있는 독일 엔지니어 Rinor Maloku는 Istio에 대해 빠르고 깊이 있게 알아볼 수 있는 훌륭한 자료 시리즈를 작성했습니다. 그는 Istio가 일반적으로 수행할 수 있는 작업과 이를 직접 눈으로 빠르게 확인할 수 있는 방법에 대해 이야기를 시작합니다.

이스 티오 — Google, IBM 및 Lyft 팀과 협력하여 개발된 오픈 소스 프로젝트입니다. 이는 다음과 같은 마이크로서비스 기반 애플리케이션에서 발생하는 복잡성을 해결합니다.

• 교통 관리: 시간 초과, 재시도, 로드 밸런싱;
• Безопасность: 최종 사용자 인증 및 승인;
• 관찰 가능성: 추적, 모니터링, 로깅.

이 모든 것은 애플리케이션 수준에서 해결될 수 있지만 그 이후에는 서비스가 더 이상 "마이크로" 수준이 아닙니다. 이러한 문제를 해결하기 위한 모든 추가적인 노력은 비즈니스 가치를 위해 직접적으로 사용될 수 있는 회사 자원의 낭비입니다. 예를 살펴보겠습니다:

프로젝트 관리자: 피드백 기능을 추가하는 데 얼마나 걸리나요?
개발자: 두 번의 스프린트.

MP: 뭐?.. 그냥 CRUD일 뿐이에요!
R: CRUD를 수행하는 것은 쉬운 부분이지만 여전히 사용자와 서비스를 인증하고 권한을 부여해야 합니다. 네트워크가 불안정하기 때문에 반복적인 요청을 구현해야 할 뿐만 아니라 회로 차단기 패턴 클라이언트에서. 또한 전체 시스템이 충돌하지 않도록 하려면 시간 초과 및 격벽 (언급된 두 패턴에 대한 자세한 내용은 기사 뒷부분을 참조하세요. 대략적인 번역입니다.), 그리고 문제를 탐지하기 위해 모니터링, 추적, [...]

MP: 아, 그러면 이 기능을 제품 서비스에 삽입해 보겠습니다.

아이디어는 분명하다고 생각합니다. 하나의 서비스를 추가하는 데 필요한 단계와 노력의 양은 엄청납니다. 이 기사에서는 Istio가 위에서 언급한 모든 복잡성(비즈니스 로직으로 의도되지 않음)을 서비스에서 제거하는 방법을 살펴보겠습니다.

주의: 이 문서에서는 귀하가 Kubernetes에 대한 실무 지식을 가지고 있다고 가정합니다. 그렇지 않으면 읽는 것이 좋습니다. Kubernetes에 대한 나의 소개 그 후에야 이 자료를 계속 읽으십시오.

이스티오 아이디어

Istio가 없는 세상에서는 한 서비스가 다른 서비스에 직접 요청을 하고, 오류가 발생하면 서비스가 자체적으로 이를 처리해야 합니다. 즉, 새로운 시도를 하고, 시간 초과를 제공하고, 회로 차단기를 여는 등의 작업을 수행해야 합니다.

Kubernetes의 네트워크 트래픽

Istio는 서비스와 완전히 분리되어 네트워크 통신을 방해하여 작동하는 특화된 솔루션을 제공합니다. 따라서 다음을 구현합니다.

• 결함 허용: 응답에 포함된 상태 코드를 기반으로 요청 실패 여부를 파악하고 이를 다시 실행합니다.
• 카나리아 출시: 고정된 비율의 요청만 새 버전의 서비스로 리디렉션합니다.
• 모니터링 및 측정항목: 서비스가 응답하는 데 얼마나 걸렸나요?
• 추적 및 관찰 가능성: 각 요청에 특수 헤더를 추가하고 클러스터 전체에서 이를 추적합니다.
• Безопасность: JWT 토큰을 검색하고 사용자를 인증하고 권한을 부여합니다.

이것들은 당신의 흥미를 끌 수 있는 몇 가지 가능성(실제로는 몇 가지에 불과합니다!)입니다. 이제 기술적인 세부 사항을 살펴보겠습니다!

Istio 아키텍처

Istio는 모든 네트워크 트래픽을 가로채고 여기에 일련의 규칙을 적용하여 사이드카 컨테이너 형태의 스마트 프록시를 각 포드에 삽입합니다. 모든 기능을 활성화하는 프록시는 데이터 플레인, 다음을 사용하여 동적으로 구성할 수 있습니다. 컨트롤 플레인.

데이터 플레인

포드에 삽입된 프록시를 통해 Istio는 필요한 요구 사항을 쉽게 충족할 수 있습니다. 예를 들어 재시도 및 회로 차단기 기능을 확인해 보겠습니다.

Envoy에서 재시도 및 회로 차단이 구현되는 방법

요약하면 다음과 같습니다.

1. 사절 (우리는 다음과 같이 배포되는 사이드카 컨테이너에 있는 프록시에 대해 이야기하고 있습니다. 별도의 제품 - 대략. 번역) 서비스 B의 첫 번째 인스턴스에 요청을 보내고 실패합니다.
2. 특사 사이드카가 다시 시도합니다. (다시 해 보다). (1)
3. 요청이 실패하고 이를 호출한 프록시로 반환됩니다.
4. 그러면 회로 차단기가 열리고 후속 요청에 대해 다음 서비스가 호출됩니다. (2)

즉, 다른 Retry 라이브러리를 사용할 필요가 없으며 프로그래밍 언어 X, Y 또는 Z로 회로 차단 및 서비스 검색을 직접 구현할 필요가 없습니다. 이 모든 기능과 훨씬 더 많은 기능을 즉시 사용할 수 있습니다. Istio에서는 필요하지 않습니다. 아니 코드 변경.

엄청난! 이제 Istio로 여행을 떠나고 싶을 수도 있지만 여전히 의심스럽고 열려 있는 질문이 있습니다. 이것이 인생의 모든 경우에 대한 보편적인 솔루션이라면 자연스러운 의심을 갖게 됩니다. 결국 실제로 그러한 모든 솔루션은 어떤 경우에도 적합하지 않은 것으로 판명됩니다.

그리고 마지막으로 "맞춤 설정이 가능한가요?"라고 묻습니다.

이제 바다 항해를 떠날 준비가 되었습니다. 제어 평면에 대해 알아 보겠습니다.

컨트롤 플레인

이는 세 가지 구성 요소로 구성됩니다. 조종사, 믹서 и 성, 트래픽을 라우팅하고, 정책을 시행하고, 원격 측정 데이터를 수집하도록 Envoy를 구성하기 위해 함께 작동합니다. 개략적으로 모든 것은 다음과 같습니다.

컨트롤 플레인과 데이터 플레인의 상호 작용

특사(예: 데이터 플레인)는 다음을 사용하여 구성됩니다. 쿠버네티스 CRD (사용자 정의 리소스 정의)는 Istio에서 정의하고 특별히 이 목적을 위해 고안되었습니다. 이것이 의미하는 바는 익숙한 구문을 사용하는 Kubernetes의 또 다른 리소스로 보인다는 것입니다. 일단 생성되면 이 리소스는 컨트롤 플레인에 의해 선택되어 Envoy에 적용됩니다.

Istio에 대한 서비스의 관계

우리는 Istio와 서비스의 관계를 설명했지만 그 반대는 아닙니다. 서비스가 Istio와 어떤 관련이 있습니까?

솔직히 말해서, 서비스는 "어차피 물이란 무엇인가?"라고 스스로에게 물을 때 물고기가 물과 마찬가지로 Istio의 존재를 인식하고 있습니다.

일러스트레이션 빅토리아 디미트라코풀로스: - 물은 어때요? - 물이란 도대체 무엇인가?

따라서 작동 중인 클러스터를 가져오고 Istio 구성 요소를 배포한 후에도 클러스터에 있는 서비스는 계속 작동하며 이러한 구성 요소를 제거한 후에도 모든 것이 다시 정상이 됩니다. 이 경우 Istio에서 제공하는 기능을 잃게 됩니다.

이론은 충분합니다. 이 지식을 실제로 적용해 보겠습니다!

실제로 Istio

Istio에는 최소 4개의 vCPU와 8GB RAM을 사용할 수 있는 Kubernetes 클러스터가 필요합니다. 클러스터를 빠르게 설정하고 기사의 지침을 따르려면 신규 사용자에게 다음을 제공하는 Google Cloud Platform을 사용하는 것이 좋습니다. 무료 $300.

콘솔 유틸리티를 통해 클러스터를 생성하고 Kubernetes에 대한 액세스를 구성한 후 Helm 패키지 관리자를 통해 Istio를 설치할 수 있습니다.

투구 설치

에 설명된 대로 컴퓨터에 Helm 클라이언트를 설치합니다. 공식 문서. 다음 섹션에서는 이를 사용하여 Istio 설치를 위한 템플릿을 생성할 것입니다.

Istio 설치

다음에서 Istio 리소스를 다운로드하세요. 최신 릴리스 (버전 1.0.5에 대한 원저자의 링크가 현재 버전으로 변경되었습니다. 즉, 1.0.6 - 대략적인 번역입니다.), 내용을 하나의 디렉토리에 추출합니다. 이후에는 이 디렉토리를 호출하겠습니다. [istio-resources].

Istio 리소스를 쉽게 식별하려면 K8s 클러스터에 네임스페이스를 만듭니다. istio-system:

$ kubectl create namespace istio-system

해당 디렉토리로 이동하여 설치를 완료하세요. [istio-resources] 그리고 다음 명령을 실행합니다.

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

이 명령은 Istio의 주요 구성 요소를 파일로 출력합니다. istio.yaml. 우리는 다음 매개변수를 지정하여 표준 템플릿을 자신에게 맞게 수정했습니다.

• global.mtls.enabled 에 설치됨 false (즉, mTLS 인증이 비활성화되었습니다. - 대략)데이트 과정을 단순화하기 위해;
• tracing.enabled Jaeger를 사용한 요청 추적이 포함됩니다.
• kiali.enabled 서비스와 트래픽을 시각화하기 위해 Kiali를 클러스터에 설치합니다.
• grafana.enabled 수집된 측정항목을 시각화하기 위해 Grafana를 설치합니다.

생성된 리소스를 다음 명령으로 사용해 보겠습니다.

$ kubectl apply -f istio.yaml

클러스터에 Istio 설치가 완료되었습니다! 모든 포드가 네임스페이스에 포함될 때까지 기다립니다. istio-system 수있을 것입니다 Running 또는 Completed아래 명령을 실행하여 :

$ kubectl get pods -n istio-system

이제 애플리케이션을 시작하고 실행하는 다음 섹션을 계속할 준비가 되었습니다.

감정 분석 애플리케이션의 아키텍처

이미 언급한 예제에서 사용된 감정 분석 마이크로서비스 애플리케이션의 예를 사용해 보겠습니다. Kubernetes 소개 기사. 실제로 Istio의 기능을 보여주기에 충분히 복잡합니다.

애플리케이션은 XNUMX개의 마이크로서비스로 구성됩니다.

1. 서비스 SA-프런트엔드, Reactjs 애플리케이션의 프런트엔드 역할을 합니다.
2. 서비스 SA-웹앱, 감정 분석 쿼리를 제공합니다.
3. 서비스 SA-로직, 자체적으로 수행되는 감정 분석;
4. 서비스 SA-피드백, 분석의 정확성에 대한 사용자로부터 피드백을 받습니다.

이 다이어그램에는 서비스 외에도 Kubernetes에서 들어오는 요청을 적절한 서비스로 라우팅하는 수신 컨트롤러도 표시됩니다. Istio는 Ingress Gateway 내에서 유사한 개념을 사용하며 이에 대한 자세한 내용은 다음과 같습니다.

Istio의 프록시를 사용하여 애플리케이션 실행

기사에 언급된 추가 작업을 위해서는 저장소를 복제하세요. istio-mastery. 여기에는 Kubernetes 및 Istio용 애플리케이션과 매니페스트가 포함되어 있습니다.

사이드카 삽입

삽입이 가능합니다 자동으로 또는 수동으로. 사이드카 컨테이너를 자동으로 삽입하려면 네임스페이스에 레이블을 설정해야 합니다. istio-injection=enabled, 이는 다음 명령으로 수행됩니다.

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

이제 기본 네임스페이스(default)는 사이드카 컨테이너를 받습니다. 이를 확인하기 위해 저장소의 루트 디렉터리로 이동하여 테스트 애플리케이션을 배포해 보겠습니다. [istio-mastery] 다음 명령을 실행합니다.

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

서비스를 배포한 후 다음 명령을 실행하여 Pod에 두 개의 컨테이너(서비스 자체와 사이드카 포함)가 있는지 확인해 보겠습니다. kubectl get pods 열 아래에 있는지 확인하세요. READY 지정된 값 2/2, 두 컨테이너가 모두 실행 중임을 나타냅니다.

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

시각적으로 다음과 같습니다.

Pod 중 하나의 Envoy 프록시

이제 애플리케이션이 실행되고 있으므로 수신 트래픽이 애플리케이션으로 들어오도록 허용해야 합니다.

인그레스 게이트웨이

이를 달성하기 위한 모범 사례(클러스터에서 트래픽 허용)는 다음과 같습니다. 인그레스 게이트웨이 Istio에서는 클러스터의 "가장자리"에 위치하며 라우팅, 로드 밸런싱, 보안, 수신 트래픽 모니터링과 같은 Istio 기능을 활성화할 수 있습니다.

Ingress Gateway 구성 요소와 이를 외부로 전달하는 서비스는 Istio 설치 중에 클러스터에 설치되었습니다. 서비스의 외부 IP 주소를 찾으려면 다음을 실행하세요.

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

우리는 이 IP(EXTERNAL-IP라고 칭함)를 사용하여 애플리케이션에 계속 액세스할 것이므로 편의상 값을 변수에 기록하겠습니다.

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

지금 브라우저를 통해 이 IP에 접속하려고 하면 Service Unavailable 오류가 발생합니다. 기본적으로 Istio는 들어오는 모든 트래픽을 차단합니다., 게이트웨이가 아직 정의되지 않았습니다.

게이트웨이 리소스

게이트웨이는 클러스터에 Istio를 설치하고 수신 트래픽을 허용하려는 포트, 프로토콜 및 호스트를 지정하는 기능을 활성화한 후 정의되는 Kubernetes의 CRD(사용자 정의 리소스 정의)입니다.

우리의 경우 모든 호스트에 대해 포트 80에서 HTTP 트래픽을 허용하려고 합니다. 작업은 다음 정의에 의해 구현됩니다. (http-gateway.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

이 구성은 선택기 외에는 설명이 필요하지 않습니다. istio: ingressgateway. 이 선택기를 사용하면 구성을 적용할 Ingress 게이트웨이를 지정할 수 있습니다. 우리의 경우 이는 Istio에 기본적으로 설치되는 Ingress Gateway 컨트롤러입니다.

구성은 다음 명령을 호출하여 적용됩니다.

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

이제 게이트웨이는 포트 80에 대한 액세스를 허용하지만 요청을 어디로 라우팅해야 할지 모릅니다. 이를 위해서는 당신이 필요합니다 가상 서비스.

가상서비스 리소스

VirtualService는 클러스터 내에서 허용되는 요청을 라우팅하는 방법을 Ingress Gateway에 알려줍니다.

http-gateway를 통해 들어오는 애플리케이션에 대한 요청은 sa-frontend, sa-web-app 및 sa-feedback 서비스로 전송되어야 합니다.

VirtualServices로 구성해야 하는 경로

SA-Frontend로 전송되어야 하는 요청을 살펴보겠습니다.

• 도중에 정확히 일치함 / index.html을 얻으려면 SA-Frontend로 전송되어야 합니다.
• 접두사가 붙은 경로 /static/* CSS 및 JavaScript와 같이 프런트엔드에서 사용되는 정적 파일을 수신하려면 SA-Frontend로 전송되어야 합니다.
• 정규식과 일치하는 경로 '^.*.(ico|png|jpg)$', SA-Frontend로 전송되어야 합니다. 페이지에 표시되는 사진들입니다.

구현은 다음 구성으로 이루어집니다. (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/:
$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

중요 포인트 :

 이 VirtualService는 다음을 통해 들어오는 요청을 나타냅니다. http-게이트웨이;
 В destination 요청이 전송되는 서비스가 결정됩니다.

주의: 위의 구성은 파일에 저장됩니다. sa-virtualservice-external.yaml, 여기에는 SA-WebApp 및 SA-Feedback의 라우팅에 대한 설정도 포함되어 있지만 여기서는 간결성을 위해 이 문서에서 단축되었습니다.
다음을 호출하여 VirtualService를 적용해 보겠습니다.

주의: Istio 리소스를 소비하면 Kubernetes API 서버는 Istio Control Plane에서 수신되는 이벤트를 생성한 후 새 구성이 각 Pod의 Envoy 프록시에 적용됩니다. 그리고 Ingress Gateway 컨트롤러는 Control Plane에 구성된 또 다른 Envoy로 보입니다. 이 모든 것은 다이어그램에서 다음과 같습니다.


요청 라우팅을 위한 Istio-IngressGateway 구성
이제 감정 분석 애플리케이션을 사용할 수 있습니다. http://{EXTERNAL-IP}/. 찾을 수 없음 상태가 되어도 걱정하지 마세요. 구성이 적용되고 Envoy 캐시가 업데이트되는 데 시간이 조금 더 걸리는 경우도 있습니다..
계속하기 전에 앱을 조금 사용해 트래픽을 생성해 보세요. (후속 작업의 명확성을 위해 해당 존재가 필요합니다. - 대략 번역).
Kiali: 관찰 가능성
Kiali 관리 인터페이스로 이동하려면 다음 명령을 실행하십시오.

... 그리고 열다 http://localhost:20001/, admin/admin으로 로그인합니다. 여기서는 Istio 구성 요소의 구성을 확인하고, 네트워크 요청을 가로채서 수집한 정보를 사용하여 서비스를 시각화하고, "누가 누구에게 연락하고 있습니까?", "어떤 서비스 버전에서 문제가 발생하고 있습니까?"라는 질문에 대한 답변을 얻는 등 많은 유용한 기능을 찾을 수 있습니다. 실패?” 등등. 일반적으로 Grafana를 사용하여 측정항목 시각화로 이동하기 전에 Kiali의 기능을 살펴보세요.

Grafana: 측정항목 시각화
Istio에서 수집된 측정항목은 Prometheus로 이동하고 Grafana를 통해 시각화됩니다. Grafana 관리 인터페이스로 이동하려면 아래 명령을 실행한 후 엽니다. http://localhost:3000/:

메뉴를 클릭하면 홈 왼쪽 상단 및 선택 Istio 서비스 대시보드 왼쪽 상단에서 서비스로 시작하세요. sa-웹-앱수집된 측정항목을 보려면 다음을 수행하세요.

여기서 우리를 기다리는 것은 공허하고 완전히 지루한 성능입니다. 경영진은 이것을 결코 승인하지 않을 것입니다. 다음 명령을 사용하여 작은 로드를 생성해 보겠습니다.

이제 우리는 훨씬 더 멋진 그래프를 갖게 되었으며, 그 외에도 모니터링을 위한 훌륭한 Prometheus 도구와 시간 경과에 따른 서비스의 성능, 상태, 개선/저하를 학습할 수 있는 지표 시각화를 위한 Grafana가 있습니다.
마지막으로 서비스의 요청 추적을 살펴보겠습니다.
예거: 추적
서비스가 많아질수록 오류의 원인을 파악하기가 더 어려워지기 때문에 추적이 필요합니다. 아래 그림에서 간단한 사례를 살펴보겠습니다.


무작위로 실패한 요청의 일반적인 예
요청이 왔다가 떨어졌습니다. 이유는 무엇입니까? 첫 번째 서비스? 아니면 두 번째? 두 가지 모두 예외가 있습니다. 각각의 로그를 살펴보겠습니다. 이런 일을 하고 있는 자신을 얼마나 자주 발견했습니까? 우리 일은 개발자라기보다는 소프트웨어 탐정에 가깝습니다.
이는 마이크로서비스의 일반적인 문제이며 서비스가 서로 고유한 헤더를 전달한 후 이 정보가 추적 시스템으로 전달되어 요청 데이터와 비교되는 분산 추적 시스템에 의해 해결됩니다. 다음은 예시입니다.


TraceId는 요청을 식별하는 데 사용됩니다.
Istio는 공급업체 독립적인 OpenTracing API 프레임워크를 구현하는 Jaeger Tracer를 사용합니다. 다음 명령을 사용하여 Jaeger 사용자 인터페이스에 액세스할 수 있습니다.

이제 이동 http://localhost:16686/ 그리고 서비스를 선택하세요 sa-웹-앱. 서비스가 드롭다운 메뉴에 표시되지 않으면 페이지에 활동을 표시/생성하고 인터페이스를 업데이트하세요. 그 후 버튼을 클릭하세요. 흔적 찾기, 최신 추적이 표시됩니다. 아무 항목이나 선택하면 모든 추적에 대한 자세한 정보가 표시됩니다.

이 추적은 다음을 보여줍니다.

 요청이 들어오네요 istio-ingressgateway (이것은 서비스 중 하나와의 첫 번째 상호 작용이며 요청에 대해 추적 ID가 생성됩니다.) 그 후 게이트웨이가 서비스에 요청을 보냅니다. sa-웹-앱.
 서비스 중 sa-웹-앱 Envoy 사이드카가 요청을 선택하고 범위에 "하위"가 생성되어(그래서 추적에서 볼 수 있음) 컨테이너로 리디렉션됩니다. sa-웹-앱. (스팬 - 이름, 작업 시작 시간 및 기간이 포함된 Jaeger의 논리적 작업 단위입니다. 스팬은 중첩되고 정렬될 수 있습니다. 범위의 방향성 비순환 그래프가 트레이스를 형성합니다. — 대략. 번역)
 여기서 요청은 메소드에 의해 처리됩니다. 감성분석. 이러한 추적은 이미 애플리케이션에 의해 생성되었습니다. 코드 변경이 필요했습니다.
 이 순간부터 POST 요청이 시작됩니다. sa 논리. 추적 ID는 다음에서 전달되어야 합니다. sa-웹-앱.
 ...

주의: 4단계에서 애플리케이션은 Istio에서 생성된 헤더를 확인하고 아래 이미지와 같이 후속 요청에 전달해야 합니다.


(A) Istio는 헤더 전달을 담당합니다. (B) 서비스는 헤더를 담당합니다.
Istio가 대부분의 작업을 수행하는 이유는... 들어오는 요청에 대한 헤더를 생성하고 각 사이드케어에 새 범위를 생성하여 전달합니다. 그러나 서비스 내부의 헤더를 사용하지 않으면 전체 요청 추적 경로가 손실됩니다.
다음 헤더를 고려해야 합니다.

이는 어려운 작업은 아니지만 구현을 단순화하기 위해 이미 많은 도서관 - 예를 들어 sa-web-app 서비스에서 Jaeger 및 OpenTracing 라이브러리만 추가하면 RestTemplate 클라이언트는 이러한 헤더를 전달합니다. 그의 중독.
감정 분석 애플리케이션은 Flask, Spring 및 ASP.NET Core의 구현을 보여줍니다.
이제 우리가 기본적으로 무엇을 얻을 수 있는지(또는 거의 기본적으로) 명확해졌으므로 미세 조정된 라우팅, 네트워크 트래픽 관리, 보안 등에 대해 살펴보겠습니다.
메모. 번역: Rinor Maloku가 제공하는 Istio 관련 자료의 다음 부분에서 이에 대해 읽어보세요. 번역본은 가까운 시일 내에 블로그에 게재될 예정입니다. UPDATE (14월 XNUMX일): 두 번째 부분 이미 출판되었습니다.
번역가의 추신
블로그에서도 읽어보세요.

 "Istio를 사용한 마이크로서비스로 돌아가기": 파트 2(라우팅, 트래픽 제어), 파트 3(인증 및 권한 부여);
 «Conduit - Kubernetes용 경량 서비스 메시";
 «서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?";
 «Kubernetes의 네트워킹에 대한 그림 가이드입니다. 파트 1과 2";
 «이 사이드카 컨테이너는 어떻게 여기[Kubernetes]에 있게 되었나요?".

출처 : habr.com