🥇Quay lại microservice với Istio. Phần 1

Ghi chú. bản dịch.: Lưới dịch vụ chắc chắn đã trở thành một giải pháp phù hợp trong cơ sở hạ tầng hiện đại cho các ứng dụng theo kiến trúc microservice. Mặc dù Istio có thể được nhiều kỹ sư DevOps nhắc tới nhưng đây là một sản phẩm khá mới, mặc dù toàn diện về các khả năng mà nó cung cấp nhưng có thể cần một khoảng thời gian đáng kể để làm quen. Kỹ sư người Đức Rinor Maloku, người chịu trách nhiệm về điện toán đám mây cho các khách hàng lớn tại công ty viễn thông Orange Networks, đã viết một loạt tài liệu tuyệt vời cho phép bạn tìm hiểu sâu về Istio một cách nhanh chóng và sâu sắc. Anh ấy bắt đầu câu chuyện của mình bằng những gì Istio có thể làm nói chung và cách bạn có thể nhanh chóng nhìn thấy nó bằng chính mắt mình.

Istio — Một dự án Nguồn mở được phát triển với sự cộng tác của các nhóm từ Google, IBM và Lyft. Nó giải quyết những vấn đề phức tạp phát sinh trong các ứng dụng dựa trên microservice, chẳng hạn như:

Quản lý giao thông: hết thời gian chờ, thử lại, cân bằng tải;
Безопасность: xác thực và ủy quyền của người dùng cuối;
Khả năng quan sát: truy tìm, giám sát, ghi nhật ký.

Tất cả những điều này có thể được giải quyết ở cấp độ ứng dụng, nhưng sau đó các dịch vụ của bạn sẽ không còn là “vi mô” nữa. Mọi nỗ lực tăng thêm để giải quyết những vấn đề này đều là sự lãng phí nguồn lực của công ty mà lẽ ra có thể được sử dụng trực tiếp cho giá trị kinh doanh. Hãy xem một ví dụ:

Người quản lý dự án: Mất bao lâu để thêm tính năng phản hồi?
Nhà phát triển: Hai lần chạy nước rút.
MP: Cái gì?.. Chỉ là CRUD thôi!
R: Thực hiện CRUD là phần dễ dàng, nhưng chúng tôi vẫn cần xác thực và ủy quyền cho người dùng cũng như dịch vụ. Vì mạng không đáng tin cậy nên bạn sẽ cần phải thực hiện các yêu cầu lặp đi lặp lại, cũng như mô hình ngắt mạch ở khách hàng. Ngoài ra, để đảm bảo toàn bộ hệ thống không gặp sự cố, bạn sẽ cần thời gian chờ và vách ngăn (để biết thêm chi tiết về cả hai mẫu được đề cập, hãy xem phần sau của bài viết - bản dịch xấp xỉ)và để phát hiện vấn đề, giám sát, truy tìm, […]
MP: Ồ, vậy chúng ta hãy đưa tính năng này vào dịch vụ Sản phẩm.

Tôi nghĩ ý tưởng rất rõ ràng: số bước và nỗ lực cần thiết để thêm một dịch vụ là rất lớn. Trong bài viết này, chúng ta sẽ xem cách Istio loại bỏ tất cả sự phức tạp được đề cập ở trên (không nhằm mục đích logic kinh doanh) khỏi các dịch vụ.

Ghi: Bài viết này giả định rằng bạn có kiến thức làm việc về Kubernetes. Nếu không, tôi khuyên bạn nên đọc lời giới thiệu của tôi về Kubernetes và chỉ sau đó hãy tiếp tục đọc tài liệu này.

Ý tưởng Istio

Trong một thế giới không có Istio, một dịch vụ sẽ gửi yêu cầu trực tiếp đến dịch vụ khác và trong trường hợp xảy ra lỗi, dịch vụ đó phải tự xử lý: thực hiện một lần thử mới, cung cấp thời gian chờ, mở bộ ngắt mạch, v.v.

Lưu lượng mạng trong Kubernetes

Istio cung cấp một giải pháp chuyên biệt, tách biệt hoàn toàn với các dịch vụ và hoạt động bằng cách can thiệp vào giao tiếp mạng. Và do đó nó thực hiện:

khả năng chịu lỗi: Dựa vào mã trạng thái trong phản hồi, nó hiểu được yêu cầu có thất bại hay không và thực hiện lại yêu cầu đó.
Triển khai Canary: chỉ chuyển hướng một tỷ lệ phần trăm yêu cầu cố định sang phiên bản mới của dịch vụ.
Giám sát và đo lường: Mất bao lâu để dịch vụ phản hồi?
Truy tìm và quan sát: Thêm các tiêu đề đặc biệt vào từng yêu cầu và theo dõi chúng trên toàn cụm.
Безопасность: Truy xuất mã thông báo JWT, xác thực và ủy quyền cho người dùng.

Đây chỉ là một số khả năng (thực sự chỉ là một số ít!) có thể gây tò mò cho bạn. Bây giờ chúng ta hãy đi sâu vào các chi tiết kỹ thuật!

Kiến trúc Istio

Istio chặn tất cả lưu lượng truy cập mạng và áp dụng một bộ quy tắc cho nó, chèn một proxy thông minh dưới dạng thùng chứa sidecar vào mỗi nhóm. Proxy kích hoạt tất cả các khả năng tạo thành một Mặt phẳng dữ liệuvà chúng có thể được cấu hình động bằng cách sử dụng Máy bay điều khiển.

Mặt phẳng dữ liệu

Proxy được chèn vào nhóm cho phép Istio dễ dàng đáp ứng các yêu cầu mà chúng tôi cần. Ví dụ: hãy kiểm tra chức năng thử lại và ngắt mạch.

Cách thực hiện thử lại và ngắt mạch trong Envoy

Tổng hợp:

Đặc phái viên (chúng ta đang nói về một proxy nằm trong thùng chứa sidecar, được phân phối dưới dạng sản phẩm riêng biệt - khoảng. dịch.) gửi yêu cầu đến phiên bản đầu tiên của dịch vụ B và không thành công.
Đặc phái viên Sidecar thử lại (thử lại). (1)
Yêu cầu không thành công và được trả về proxy đã gọi nó.
Thao tác này sẽ mở Circuit Breaker và gọi dịch vụ tiếp theo cho các yêu cầu tiếp theo. (2)

Điều này có nghĩa là bạn không phải sử dụng thư viện Thử lại khác, bạn không phải tự mình triển khai Ngắt mạch và Khám phá dịch vụ bằng ngôn ngữ lập trình X, Y hoặc Z. Tất cả những tính năng này và nhiều tính năng khác đều có sẵn ngay lập tức ở Istio và không yêu cầu không những thay đổi trong mã.

Tuyệt vời! Bây giờ bạn có thể muốn thực hiện chuyến hành trình cùng Istio, nhưng bạn vẫn còn một số nghi ngờ, những câu hỏi còn bỏ ngỏ. Nếu đây là một giải pháp phổ biến cho mọi tình huống trong cuộc sống, thì tự nhiên bạn sẽ nghi ngờ: xét cho cùng, tất cả những giải pháp như vậy trên thực tế đều không phù hợp với bất kỳ trường hợp nào.

Và cuối cùng bạn hỏi: “Nó có thể tùy chỉnh được không?”

Bây giờ bạn đã sẵn sàng cho chuyến hành trình trên biển, hãy làm quen với Máy bay điều khiển.

Máy bay điều khiển

Nó bao gồm ba thành phần: Phi công, Mixer и Citadel, hoạt động cùng nhau để định cấu hình Đặc phái viên nhằm định tuyến lưu lượng truy cập, thực thi chính sách và thu thập dữ liệu đo từ xa. Về mặt sơ đồ, tất cả trông như thế này:

Tương tác của mặt phẳng điều khiển với mặt phẳng dữ liệu

Đặc phái viên (tức là mặt phẳng dữ liệu) được cấu hình bằng cách sử dụng Kubernetes CRD (Định nghĩa tài nguyên tùy chỉnh) do Istio xác định và dành riêng cho mục đích này. Điều này có ý nghĩa với bạn là chúng dường như chỉ là một tài nguyên khác trong Kubernetes với cú pháp quen thuộc. Sau khi được tạo, tài nguyên này sẽ được máy bay điều khiển lấy và áp dụng cho Đặc phái viên.

Mối quan hệ của dịch vụ với Istio

Chúng tôi đã mô tả mối quan hệ của Istio với các dịch vụ, nhưng không mô tả ngược lại: các dịch vụ liên quan đến Istio như thế nào?

Thành thật mà nói, các dịch vụ nhận thức được sự hiện diện của Istio như cá là nước khi họ tự hỏi: "Mà nước là gì?"

Hình minh họa Victoria Dimitrakopoulos: - Bạn thích nước như thế nào? - Rốt cuộc nước là gì?

Do đó, bạn có thể lấy một cụm làm việc và sau khi triển khai các thành phần Istio, các dịch vụ trong đó sẽ tiếp tục hoạt động và sau khi loại bỏ các thành phần này, mọi thứ sẽ ổn trở lại. Rõ ràng là trong trường hợp này bạn sẽ mất đi những khả năng do Istio cung cấp.

Lý thuyết đủ rồi - hãy áp dụng kiến thức này vào thực tế!

Istio trong thực tế

Istio yêu cầu cụm Kubernetes có ít nhất 4 vCPU và 8 GB RAM khả dụng. Để nhanh chóng thiết lập một cụm và làm theo hướng dẫn trong bài viết, tôi khuyên bạn nên sử dụng Google Cloud Platform, nền tảng cung cấp cho người dùng mới 300 USD miễn phí.

Sau khi tạo cụm và định cấu hình quyền truy cập vào Kubernetes thông qua tiện ích bảng điều khiển, bạn có thể cài đặt Istio thông qua trình quản lý gói Helm.

Lắp đặt mũ bảo hiểm

Cài đặt ứng dụng khách Helm trên máy tính của bạn, như được mô tả trong tài liệu chính thức. Chúng tôi sẽ sử dụng điều này để tạo mẫu để cài đặt Istio trong phần tiếp theo.

Cài đặt Istio

Tải xuống tài nguyên Istio từ bản phát hành mới nhất (Liên kết của tác giả ban đầu tới phiên bản 1.0.5 đã được thay đổi thành phiên bản hiện tại, tức là 1.0.6 - bản dịch xấp xỉ.), trích xuất nội dung vào một thư mục mà sau này tôi sẽ gọi [istio-resources].

Để dễ dàng xác định tài nguyên Istio, hãy tạo một namespace trong cụm K8s istio-system:

$ kubectl create namespace istio-system

Hoàn tất cài đặt bằng cách vào thư mục [istio-resources] và chạy lệnh:

$ 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

Lệnh này sẽ xuất các thành phần chính của Istio thành một tệp istio.yaml. Chúng tôi đã sửa đổi mẫu tiêu chuẩn cho phù hợp với mình, chỉ định các tham số sau:

global.mtls.enabled cài đặt trong false (tức là xác thực mTLS bị vô hiệu hóa - ước chừng)để đơn giản hóa quá trình hẹn hò của chúng tôi;
tracing.enabled bao gồm theo dõi yêu cầu bằng Jaeger;
kiali.enabled cài đặt Kiali vào một cụm để trực quan hóa các dịch vụ và lưu lượng truy cập;
grafana.enabled cài đặt Grafana để trực quan hóa các số liệu được thu thập.

Hãy sử dụng các tài nguyên được tạo bằng lệnh:

$ kubectl apply -f istio.yaml

Quá trình cài đặt Istio trên cluster đã hoàn tất! Đợi cho đến khi tất cả các nhóm nằm trong không gian tên istio-system sẽ có thể Running hoặc Completedbằng cách chạy lệnh dưới đây:

$ kubectl get pods -n istio-system

Bây giờ chúng ta đã sẵn sàng để tiếp tục trong phần tiếp theo, nơi chúng ta sẽ thiết lập và chạy ứng dụng.

Kiến trúc của ứng dụng Phân tích tình cảm

Hãy sử dụng ví dụ về ứng dụng microservice Phân tích tình cảm được sử dụng trong Bài viết giới thiệu về Kubernetes. Nó đủ phức tạp để thể hiện khả năng của Istio trong thực tế.

Ứng dụng này bao gồm bốn microservice:

Dịch vụ SA-Giao diện người dùng, phục vụ giao diện người dùng của ứng dụng Reactjs;
Dịch vụ SA-WebApp, phục vụ các truy vấn Phân tích tình cảm;
Dịch vụ SA-Logic, nó tự thực hiện phân tích tình cảm;
Dịch vụ SA-Phản hồi, nhận phản hồi từ người dùng về tính chính xác của phân tích.

Trong sơ đồ này, ngoài các dịch vụ, chúng ta còn thấy Bộ điều khiển Ingress, trong Kubernetes định tuyến các yêu cầu đến các dịch vụ thích hợp. Istio sử dụng một khái niệm tương tự trong Cổng Ingress của mình, chi tiết hơn sẽ được trình bày sau.

Chạy một ứng dụng có proxy từ Istio

Đối với các hoạt động tiếp theo được đề cập trong bài viết, hãy sao chép kho lưu trữ của bạn làm chủ istio. Nó chứa ứng dụng và bảng kê khai cho Kubernetes và Istio.

Chèn sidecar

Việc chèn có thể được thực hiện tự động hoặc bằng tay. Để tự động chèn thùng chứa sidecar, bạn sẽ cần đặt nhãn cho không gian tên istio-injection=enabled, được thực hiện bằng lệnh sau:

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

Bây giờ mỗi nhóm sẽ được triển khai trong không gian tên mặc định (default) sẽ nhận được thùng chứa sidecar của nó. Để xác minh điều này, hãy triển khai ứng dụng thử nghiệm bằng cách vào thư mục gốc của kho lưu trữ [istio-mastery] và chạy lệnh sau:

$ 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

Sau khi triển khai các dịch vụ, hãy kiểm tra xem các nhóm có hai thùng chứa (với chính dịch vụ đó và sidecar của nó) hay không bằng cách chạy lệnh kubectl get pods và đảm bảo rằng dưới cột READY giá trị được chỉ định 2/2, tượng trưng cho cả hai container đang chạy:

$ 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

Nhìn bề ngoài nó trông như thế này:

Đại sứ ủy quyền ở một trong các nhóm

Bây giờ ứng dụng đã thiết lập và đang chạy, chúng ta sẽ cần cho phép lưu lượng truy cập đến vào ứng dụng.

Cổng vào

Cách tốt nhất để đạt được điều này (cho phép lưu lượng truy cập trong cụm) là thông qua Cổng vào trong Istio, nằm ở “cạnh” của cụm và cho phép bạn kích hoạt các tính năng của Istio như định tuyến, cân bằng tải, bảo mật và giám sát lưu lượng truy cập đến.

Thành phần Ingress Gateway và dịch vụ chuyển tiếp nó ra bên ngoài đã được cài đặt trong cụm trong quá trình cài đặt Istio. Để tìm địa chỉ IP bên ngoài của dịch vụ, hãy chạy:

$ 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

Chúng ta sẽ tiếp tục truy cập ứng dụng bằng IP này (tôi sẽ gọi nó là EXTERNAL-IP), vì vậy để thuận tiện, chúng ta sẽ ghi giá trị vào một biến:

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

Nếu bây giờ bạn cố gắng truy cập IP này thông qua trình duyệt, bạn sẽ nhận được lỗi Dịch vụ không khả dụng, bởi vì theo mặc định Istio chặn tất cả lưu lượng truy cập đến, Cổng vẫn chưa được xác định.

Tài nguyên cổng

Gateway là CRD (Định nghĩa tài nguyên tùy chỉnh) trong Kubernetes, được xác định sau khi cài đặt Istio trong cụm và cho phép khả năng chỉ định cổng, giao thức và máy chủ mà chúng ta muốn cho phép lưu lượng truy cập đến.

Trong trường hợp của chúng tôi, chúng tôi muốn cho phép lưu lượng HTTP trên cổng 80 cho tất cả máy chủ. Nhiệm vụ được thực hiện theo định nghĩa sau (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:
- "*"

Cấu hình này không cần giải thích ngoại trừ bộ chọn istio: ingressgateway. Với bộ chọn này, chúng ta có thể chỉ định Cổng Ingress nào sẽ áp dụng cấu hình. Trong trường hợp của chúng tôi, đây là bộ điều khiển Ingress Gateway, được cài đặt mặc định trong Istio.

Cấu hình được áp dụng bằng cách gọi lệnh sau:

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

Cổng hiện cho phép truy cập vào cổng 80, nhưng không biết định tuyến yêu cầu ở đâu. Đối với điều này bạn sẽ cần Dịch vụ ảo.

Tài nguyên dịch vụ ảo

VirtualService cho Ingress Gateway biết cách định tuyến các yêu cầu được phép trong cụm.

Các yêu cầu tới ứng dụng của chúng tôi thông qua http-gateway phải được gửi đến các dịch vụ sa-frontend, sa-web-app và sa-feedback:

Các tuyến cần được cấu hình với VirtualServices

Hãy xem các yêu cầu sẽ được gửi tới SA-Frontend:

Kết hợp chính xác trên đường đi / phải được gửi tới SA-Frontend để lấy index.html;
Đường dẫn có tiền tố /static/* phải được gửi tới SA-Frontend để nhận các tệp tĩnh được sử dụng trong giao diện người dùng, chẳng hạn như CSS và JavaScript;
Đường dẫn khớp với biểu thức chính quy '^.*.(ico|png|jpg)$', phải được gửi tới SA-Frontend, bởi vì Đây là những hình ảnh được hiển thị trên trang.

Việc thực hiện đạt được bằng cấu hình sau (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
Những điểm quan trọng:

Dịch vụ ảo này đề cập đến các yêu cầu đến từ cổng http;
В destination Dịch vụ mà yêu cầu được gửi tới sẽ được xác định.

Ghi: Cấu hình trên được lưu trữ trong một tập tin sa-virtualservice-external.yaml, cũng chứa các cài đặt định tuyến trong SA-WebApp và SA-Feedback, nhưng đã được rút ngắn ở đây trong bài viết để cho ngắn gọn.

Hãy áp dụng VirtualService bằng cách gọi:

Ghi: Khi chúng tôi sử dụng tài nguyên Istio, Máy chủ API Kubernetes sẽ tạo một sự kiện được Mặt phẳng điều khiển Istio nhận và sau đó, cấu hình mới sẽ được áp dụng cho proxy Envoy của mỗi nhóm. Và bộ điều khiển Ingress Gateway dường như là một Envoy khác được cấu hình trong Control Plane. Tất cả điều này trông như thế này trong sơ đồ:

Cấu hình Istio-IngressGateway để định tuyến yêu cầu

Ứng dụng Phân tích tình cảm hiện có sẵn trên http://{EXTERNAL-IP}/. Đừng lo lắng nếu bạn nhận được trạng thái Không tìm thấy: Đôi khi phải mất một chút thời gian để cấu hình có hiệu lực và bộ đệm Envoy cập nhật.

Trước khi tiếp tục, hãy thử nghiệm ứng dụng một chút để tạo lưu lượng truy cập. (sự hiện diện của nó là cần thiết để làm rõ các hành động tiếp theo - khoảng. bản dịch.).

Kiali: khả năng quan sát

Để truy cập giao diện quản trị Kiali, hãy chạy lệnh sau:

... và mở ra http://localhost:20001/, đăng nhập với tư cách quản trị viên/quản trị viên. Tại đây, bạn sẽ tìm thấy nhiều tính năng hữu ích, chẳng hạn như kiểm tra cấu hình của các thành phần Istio, trực quan hóa các dịch vụ bằng cách sử dụng thông tin được thu thập từ việc chặn các yêu cầu mạng, nhận câu trả lời cho các câu hỏi “Ai đang liên hệ với ai?”, “Phiên bản dịch vụ nào đang gặp phải”. thất bại?” và như thế. Nói chung, hãy khám phá các khả năng của Kiali trước khi chuyển sang trực quan hóa các số liệu bằng Grafana.

Grafana: trực quan hóa số liệu

Các số liệu được thu thập trong Istio sẽ được đưa vào Prometheus và được hiển thị bằng Grafana. Để đến giao diện quản trị Grafana, hãy chạy lệnh bên dưới rồi mở http://localhost:3000/:

Bấm vào thực đơn Trang chủ trên cùng bên trái và chọn Bảng điều khiển dịch vụ Istio ở góc trên bên trái, bắt đầu với dịch vụ sa-web-appđể xem các số liệu được thu thập:

Điều đang chờ đợi chúng ta ở đây là một buổi biểu diễn trống rỗng và hoàn toàn nhàm chán - ban quản lý sẽ không bao giờ chấp nhận điều này. Hãy tạo một tải nhỏ bằng lệnh sau:

Giờ đây, chúng tôi có các biểu đồ đẹp hơn nhiều và ngoài chúng còn có các công cụ Prometheus tuyệt vời để theo dõi và Grafana để trực quan hóa các số liệu sẽ cho phép chúng tôi tìm hiểu về hiệu suất, tình trạng, sự cải thiện/suy thoái dịch vụ theo thời gian.

Cuối cùng, hãy xem xét các yêu cầu theo dõi trong services.

Jaeger: truy tìm

Chúng ta sẽ cần truy tìm vì càng có nhiều dịch vụ thì việc tìm ra nguyên nhân thất bại càng khó. Chúng ta hãy xem xét một trường hợp đơn giản từ hình ảnh dưới đây:

Ví dụ điển hình về một yêu cầu thất bại ngẫu nhiên

Yêu cầu đến, rơi - lý do là gì? Dịch vụ đầu tiên? Hoặc cái thứ hai? Có những trường hợp ngoại lệ trong cả hai - hãy xem nhật ký của từng trường hợp. Bạn có thường xuyên bắt gặp mình làm điều này không? Công việc của chúng tôi giống thám tử phần mềm hơn là nhà phát triển...

Đây là sự cố thường gặp trong vi dịch vụ và được giải quyết bằng hệ thống theo dõi phân tán, trong đó các dịch vụ chuyển một tiêu đề duy nhất cho nhau, sau đó thông tin này được chuyển tiếp đến hệ thống theo dõi để so sánh với dữ liệu yêu cầu. Đây là một minh họa:

TraceId được sử dụng để xác định yêu cầu

Istio sử dụng Jaeger Tracer, triển khai khung API OpenTracing độc lập với nhà cung cấp. Bạn có thể truy cập giao diện người dùng Jaeger bằng lệnh sau:

Bây giờ đi đến http://localhost:16686/ và chọn một dịch vụ sa-web-app. Nếu dịch vụ không được hiển thị trong menu thả xuống, hãy hiển thị/tạo hoạt động trên trang và cập nhật giao diện. Sau đó, bấm vào nút Tìm dấu vết, sẽ hiển thị dấu vết mới nhất - chọn bất kỳ - thông tin chi tiết về tất cả dấu vết sẽ xuất hiện:

Dấu vết này cho thấy:

Yêu cầu đến istio-ingressgateway (đây là lần tương tác đầu tiên với một trong các dịch vụ và ID theo dõi được tạo cho yêu cầu), sau đó cổng sẽ gửi yêu cầu đến dịch vụ sa-web-app.
Phục vụ sa-web-app yêu cầu được nhận bởi sidecar Envoy, một "con" được tạo trong span (đó là lý do tại sao chúng ta nhìn thấy nó trong dấu vết) và được chuyển hướng đến vùng chứa sa-web-app. (nhịp cầu - một đơn vị công việc hợp lý trong Jaeger, có tên, thời gian bắt đầu hoạt động và thời lượng của nó. Các nhịp có thể được lồng vào nhau và sắp xếp theo thứ tự. Một đồ thị tuần hoàn có hướng của các nhịp tạo thành một đường. - khoảng. dịch.)
Ở đây yêu cầu được xử lý bằng phương thức phân tích tình cảm. Những dấu vết này đã được ứng dụng tạo ra, tức là. họ yêu cầu thay đổi mã.
Từ thời điểm này trở đi, một yêu cầu POST được bắt đầu trong sa-logic. ID dấu vết phải được chuyển tiếp từ sa-web-app.
...

Ghi: Ở bước 4, ứng dụng sẽ thấy các tiêu đề do Istio tạo và chuyển chúng đến các yêu cầu tiếp theo như trong hình bên dưới:

(A) Istio chịu trách nhiệm chuyển tiếp các tiêu đề; (B) Dịch vụ chịu trách nhiệm về tiêu đề

Istio thực hiện hầu hết công việc vì... tạo tiêu đề cho các yêu cầu đến, tạo các nhịp mới trong mỗi sidecare và chuyển tiếp chúng. Tuy nhiên, nếu không làm việc với các tiêu đề bên trong dịch vụ, đường dẫn theo dõi yêu cầu đầy đủ sẽ bị mất.

Các tiêu đề sau phải được tính đến:

Đây không phải là một nhiệm vụ khó khăn, nhưng để đơn giản hóa việc thực hiện nó đã có sẵn nhiều thư viện - ví dụ: trong dịch vụ sa-web-app, ứng dụng khách RestTemplate sẽ chuyển tiếp các tiêu đề này nếu bạn chỉ cần thêm thư viện Jaeger và OpenTracing vào chứng nghiện của anh ấy.

Lưu ý rằng ứng dụng Phân tích tình cảm thể hiện việc triển khai trong Flask, Spring và ASP.NET Core.

Bây giờ chúng ta đã rõ những gì chúng ta nhận được (hoặc gần như đã hoàn tất), hãy xem xét việc tinh chỉnh định tuyến, quản lý lưu lượng mạng, bảo mật, v.v.!

Ghi chú. bản dịch.: Đọc về điều này trong phần tiếp theo của tài liệu về Istio từ Rinor Maloku, bản dịch của chúng sẽ xuất hiện trên blog của chúng tôi trong tương lai gần. CẬP NHẬT (ngày 14 tháng XNUMX): Phần thứ hai đã được xuất bản.

Tái bút từ người dịch

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com