Kembali ke layanan mikro dengan Istio. Bagian 1

Catatan. terjemahan: Jejaring layanan telah menjadi topik hangat dalam infrastruktur saat ini untuk aplikasi yang mengikuti arsitektur layanan mikro. Meskipun Istio mungkin menarik perhatian banyak insinyur DevOps, ini adalah produk yang cukup baru, meskipun kompleks dalam hal fitur yang disediakannya, namun memerlukan banyak waktu untuk mengenalnya. Insinyur Jerman Rinor Maloku, yang bertanggung jawab atas komputasi awan untuk klien besar di perusahaan telekomunikasi Orange Networks, telah menulis serangkaian materi luar biasa yang memungkinkan Anda menyelami Istio dengan cepat dan mendalam. Dia memulai ceritanya dengan apa yang dapat dilakukan Istio dan bagaimana Anda dapat dengan cepat melihatnya dengan mata kepala sendiri.

Istio — Proyek Sumber Terbuka, dikembangkan bekerja sama dengan tim dari Google, IBM, dan Lyft. Ini memecahkan kompleksitas yang muncul dalam aplikasi berbasis layanan mikro, misalnya seperti:

• manajemen lalu lintas: batas waktu, percobaan ulang, penyeimbangan beban;
• keamanan: otentikasi dan otorisasi pengguna akhir;
• kemampuan observasi: penelusuran, pemantauan, pencatatan.

Semuanya bisa diselesaikan di level aplikasi, namun setelah itu layanan Anda tidak lagi bersifat "mikro". Segala upaya ekstra untuk mengatasi masalah ini merupakan pemborosan sumber daya perusahaan yang sebenarnya dapat digunakan secara langsung untuk nilai bisnis. Perhatikan sebuah contoh:

Manajer Proyek: Berapa lama waktu yang dibutuhkan untuk menambahkan fitur umpan balik?
Pengembang: Dua sprint.

MP: Apa?.. Cuma CRUD!
R: Melakukan CRUD adalah bagian tugas yang mudah, namun kita masih perlu mengautentikasi dan mengotorisasi pengguna dan layanan. Karena jaringan tidak dapat diandalkan, Anda juga perlu menerapkan permintaan berulang pola pemutus sirkuit pada klien. Juga, untuk memastikan bahwa seluruh sistem tidak crash, timeout dan sekat (Untuk informasi lebih lanjut tentang kedua pola yang disebutkan, lihat artikel selanjutnya - kira-kira terjemahan), dan untuk mendeteksi masalah, memantau, menelusuri, […]

MP: Oh, kalau begitu, mari kita masukkan fitur ini ke dalam layanan Produk.

Saya pikir idenya jelas: jumlah langkah dan upaya yang diperlukan untuk menambahkan satu layanan sangatlah besar. Pada artikel ini, kita akan melihat bagaimana Istio menghilangkan semua kompleksitas yang disebutkan di atas (tidak ditargetkan oleh logika bisnis) dari layanan.

Catatan: Artikel ini mengasumsikan bahwa Anda memiliki pengetahuan tentang Kubernetes. Jika tidak, saya sarankan membaca perkenalan saya dengan Kubernetes dan baru kemudian melanjutkan membaca materi ini.

Ide istio

Di dunia tanpa Istio, satu layanan membuat permintaan langsung ke layanan lain, dan jika terjadi kegagalan, layanan harus menanganinya sendiri: melakukan upaya baru, memberikan waktu tunggu, membuka pemutus sirkuit, dll.

Lalu lintas jaringan di Kubernetes

Istio, di sisi lain, menawarkan solusi khusus yang sepenuhnya terpisah dari layanan dan fungsi dengan mengganggu interaksi jaringan. Dan dengan demikian ia mengimplementasikan:

• toleransi kesalahan: berdasarkan kode status dalam respons, ia memahami jika permintaan gagal dan mengirimkannya kembali.
• Peluncuran Canary: hanya mengalihkan persentase permintaan yang tetap ke versi layanan yang baru.
• Pemantauan dan Metrik: berapa lama waktu yang dibutuhkan hingga layanan merespons?
• Penelusuran dan observasi: Menambahkan header khusus ke setiap permintaan dan melacaknya di seluruh cluster.
• keamanan: Mengambil token JWT, mengautentikasi dan memberi otorisasi kepada pengguna.

Ini hanyalah beberapa kemungkinan (sebenarnya hanya beberapa!) yang membuat Anda penasaran. Sekarang mari selami detail teknisnya!

Arsitektur

Istio mencegat semua lalu lintas jaringan dan menerapkan serangkaian aturan padanya, memasukkan proxy cerdas dalam bentuk wadah sespan ke dalam setiap pod. Proxy yang mengaktifkan semua kemungkinan membentuk a Pesawat Data, dan dapat disesuaikan secara dinamis Kontrol Pesawat.

Pesawat Data

Proxy yang dimasukkan ke dalam pod memungkinkan Istio dengan mudah mencapai persyaratan yang kita butuhkan. Misalnya, mari kita periksa fungsi percobaan ulang dan pemutus sirkuit.

Bagaimana percobaan ulang dan pemutusan sirkuit diterapkan di Envoy

Untuk meringkas:

1. Utusan (kita berbicara tentang proxy yang terletak di wadah sespan, yang didistribusikan dan bagaimana caranya produk terpisah - kira-kira. terjemahkan) mengirimkan permintaan ke instance pertama layanan B dan gagal.
2. Utusan Sidecar mencoba lagi (mencoba kembali). (1)
3. Permintaan yang gagal dikembalikan ke proksi yang memanggilnya.
4. Ini membuka Pemutus Sirkuit dan memanggil layanan berikutnya untuk permintaan berikutnya. (2)

Ini berarti Anda tidak perlu menggunakan perpustakaan Retry berikutnya, Anda tidak perlu membuat implementasi Circuit Breaking dan Service Discovery Anda sendiri dalam bahasa pemrograman X, Y atau Z. Semua ini dan lebih banyak lagi tersedia dari kotak di Istio dan tidak memerlukan tidak perubahan kode.

Besar! Sekarang Anda mungkin ingin melakukan perjalanan dengan Istio, tetapi masih ada keraguan, pertanyaan terbuka. Jika ini adalah solusi universal untuk semua kesempatan dalam hidup, maka Anda memiliki kecurigaan yang sah: bagaimanapun juga, semua solusi tersebut sebenarnya tidak cocok untuk kasus apa pun.

Dan akhirnya Anda bertanya: “Apakah ini dapat disesuaikan?”

Sekarang Anda siap untuk perjalanan laut - dan mari berkenalan dengan Control Plane.

Kontrol Pesawat

Ini terdiri dari tiga komponen: Pilot, Pengaduk и Benteng, yang bersama-sama mengonfigurasi Utusan untuk merutekan lalu lintas, menerapkan kebijakan, dan mengumpulkan data telemetri. Secara skematis, semuanya terlihat seperti ini:

Interaksi Control Plane dengan Data Plane

Utusan (yaitu bidang data) dikonfigurasi dengan CRD Kubernetes (Definisi Sumber Daya Kustom) yang ditentukan oleh Istio dan dirancang khusus untuk tujuan ini. Artinya bagi Anda adalah bahwa mereka hanyalah sumber daya lain di Kubernetes dengan sintaksis yang familier. Setelah dibuat, sumber daya ini akan diambil oleh bidang kendali dan diterapkan ke Utusan.

Hubungan layanan dengan Istio

Kami telah menjelaskan hubungan Istio dengan layanan, namun tidak sebaliknya: bagaimana hubungan layanan dengan Istio?

Jujur saja, pihak jasa mengetahui keberadaan Istio seperti halnya ikan mengetahui tentang air, ketika mereka bertanya pada diri sendiri: “Apa itu air?”.

Ilustrasi Victoria Dimitrakopoulos: Bagaimana kamu menyukai air? - Apa sebenarnya air itu?

Dengan demikian, Anda dapat mengambil cluster yang berfungsi dan setelah menerapkan komponen Istio, layanan di dalamnya akan terus berfungsi, dan setelah menghapus komponen ini, semuanya akan baik-baik saja kembali. Jelas dalam hal ini Anda akan kehilangan peluang yang diberikan oleh Istio.

Cukup teorinya - mari kita praktikkan pengetahuan ini!

Istio dalam praktek

Istio memerlukan cluster Kubernetes dengan setidaknya 4 vCPU dan RAM 8 GB. Untuk meningkatkan cluster dengan cepat dan mengikuti petunjuk dari artikel, saya sarankan menggunakan Google Cloud Platform, yang menawarkan pengguna baru gratis $300.

Setelah membuat cluster dan mengatur akses ke Kubernetes melalui utilitas konsol, Anda dapat menginstal Istio melalui manajer paket Helm.

Pemasangan Helm

Instal klien Helm di komputer Anda seperti yang dijelaskan di dokumentasi resmi. Kami akan menggunakannya untuk menghasilkan template untuk menginstal Istio di bagian selanjutnya.

Instalasi

Unduh sumber daya Istio dari rilis terbaru (tautan penulis asli ke versi 1.0.5 telah diubah ke versi sekarang, yaitu 1.0.6 - kira-kira terjemahan), ekstrak isinya ke satu direktori, yang akan saya sebut sebagai [istio-resources].

Untuk memudahkan identifikasi sumber daya Istio, buat namespace di kluster K8s istio-system:

$ kubectl create namespace istio-system

Selesaikan instalasi dengan menavigasi ke direktori [istio-resources] dan menjalankan perintah:

$ 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

Perintah ini akan menampilkan komponen kunci Istio ke sebuah file istio.yaml. Kami telah memodifikasi template standar untuk diri kami sendiri dengan menentukan parameter berikut:

• global.mtls.enabled dipasang di false (yaitu otentikasi mTLS dinonaktifkan - kira-kira terjemahan)untuk menyederhanakan proses kencan kami;
• tracing.enabled mengaktifkan penelusuran permintaan dengan Jaeger;
• kiali.enabled menginstal Kiali ke dalam cluster untuk memvisualisasikan layanan dan lalu lintas;
• grafana.enabled menginstal Grafana untuk memvisualisasikan metrik yang dikumpulkan.

Terapkan sumber daya yang dihasilkan dengan perintah:

$ kubectl apply -f istio.yaml

Instalasi Istio di cluster selesai! Tunggu hingga semua pod di namespace istio-system akan dapat Running или Completeddengan menjalankan perintah di bawah ini:

$ kubectl get pods -n istio-system

Kami sekarang siap untuk melanjutkan ke bagian berikutnya, di mana kami akan menaikkan dan menjalankan aplikasi.

Arsitektur Aplikasi Analisis Sentimen

Mari kita gunakan contoh aplikasi layanan mikro Analisis Sentimen yang digunakan di atas Artikel pengantar Kubernetes. Ini cukup kompleks untuk menunjukkan kemungkinan Istio dalam praktiknya.

Aplikasi ini terdiri dari empat layanan mikro:

1. Layanan SA-Depan, yang melayani aplikasi front-end di Reactjs;
2. Layanan Aplikasi Web SA, yang melayani kueri Analisis Sentimen;
3. Layanan Logika SAyang melakukan dirinya sendiri analisis sentimen;
4. Layanan Umpan Balik SA, yang menerima umpan balik dari pengguna mengenai keakuratan analisis yang dilakukan.

Dalam diagram ini, selain layanan, kita juga melihat Ingress Controller, yang di Kubernetes merutekan permintaan masuk ke layanan terkait. Istio menggunakan konsep serupa sebagai bagian dari Ingress Gateway, rinciannya akan menyusul.

Meluncurkan aplikasi dengan proxy dari Istio

Untuk operasi lebih lanjut yang disebutkan dalam artikel, kloning repositori Anda penguasaan istio. Ini berisi aplikasi dan manifes untuk Kubernetes dan Istio.

Memasukkan sespan

Penyisipan dapat dilakukan автоматически или dengan tangan. Untuk menyisipkan kontainer sespan secara otomatis, Anda perlu menyetel label ke namespace istio-injection=enabled, yang dilakukan dengan perintah berikut:

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

Sekarang setiap pod yang akan di-deploy di namespace default (default) akan mendapatkan wadah sespannya. Untuk memverifikasi ini, mari terapkan aplikasi pengujian dengan masuk ke direktori root repositori [istio-mastery] dan menjalankan perintah berikut:

$ 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

Setelah men-deploy layanan, periksa apakah pod masing-masing memiliki dua kontainer (dengan layanan itu sendiri dan sespannya) dengan menjalankan perintah kubectl get pods dan memastikannya di bawah kolom READY nilai yang ditentukan 2/2, melambangkan bahwa kedua container sedang berjalan:

$ 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

Secara visual terlihat seperti ini:

Proksi utusan di salah satu pod

Sekarang aplikasi sudah aktif dan berjalan, kita perlu mengizinkan lalu lintas masuk untuk masuk ke aplikasi.

Gerbang Masuk

Praktik terbaik untuk mencapai hal ini (mengizinkan lalu lintas di cluster) adalah melalui Gerbang Masuk di Istio, yang terletak di “tepi” cluster dan memungkinkan Anda mengaktifkan fitur Istio seperti perutean, penyeimbangan beban, keamanan, dan pemantauan lalu lintas masuk.

Komponen Ingress Gateway dan layanan yang meneruskannya ke luar diinstal pada cluster selama instalasi Istio. Untuk mengetahui alamat IP eksternal suatu layanan, jalankan:

$ 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

Kami akan terus mengakses aplikasi menggunakan IP ini (saya akan menyebutnya sebagai IP EKSTERNAL), jadi untuk kenyamanan, kami akan menulis nilainya ke variabel:

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

Jika Anda mencoba mengakses IP ini melalui browser sekarang, Anda akan mendapatkan kesalahan Layanan Tidak Tersedia, karena secara default Istio memblokir semua lalu lintas masuksampai Gateway ditentukan.

Sumber daya gerbang

Gateway adalah CRD (Custom Resource Definition) di Kubernetes, yang ditentukan setelah menginstal Istio di sebuah cluster dan mengaktifkan kemampuan untuk menentukan port, protokol, dan host yang ingin kita izinkan lalu lintas masuknya.

Dalam kasus kami, kami ingin mengizinkan lalu lintas HTTP pada port 80 untuk semua host. Masalahnya diwujudkan dengan definisi berikut (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:
- "*"

Konfigurasi ini tidak memerlukan penjelasan kecuali pemilihnya istio: ingressgateway. Dengan pemilih ini, kita dapat menentukan Ingress Gateway mana yang akan diterapkan konfigurasinya. Dalam kasus kami, ini adalah pengontrol Ingress Gateway, yang diinstal secara default di Istio.

Konfigurasi diterapkan dengan memanggil perintah berikut:

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

Gateway sekarang mengizinkan akses ke port 80 tetapi tidak tahu ke mana harus merutekan permintaan. Untuk ini, Anda perlu Layanan Virtual.

Sumber daya Layanan Virtual

VirtualService memberi tahu Ingress Gateway cara merutekan permintaan yang diizinkan dalam klaster.

Permintaan ke aplikasi kami yang datang melalui http-gateway harus dikirim ke layanan sa-frontend, sa-web-app, dan sa-feedback:

Rute yang akan dikonfigurasi dengan VirtualServices

Pertimbangkan permintaan yang harus dikirim ke SA-Frontend:

• Pencocokan persis di sepanjang jalan / harus dikirim ke SA-Frontend untuk mendapatkan index.html;
• Jalur dengan awalan /static/* harus dikirim ke SA-Frontend untuk mendapatkan file statis yang digunakan di frontend, seperti CSS dan JavaScript;
• Jalur yang cocok dengan ekspresi reguler '^.*.(ico|png|jpg)$', harus dikirim ke SA-Frontend, karena Ini adalah gambar-gambar yang ditampilkan di halaman.

Implementasinya dicapai dengan konfigurasi berikut (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

poin penting:

 Layanan Virtual ini mengacu pada permintaan yang masuk http-gateway;
 В destination mendefinisikan layanan ke mana permintaan dikirim.

Catatan: Konfigurasi di atas disimpan dalam sebuah file sa-virtualservice-external.yaml, yang juga berisi pengaturan untuk perutean ke SA-WebApp dan SA-Feedback, tetapi telah dipersingkat di artikel ini agar lebih singkat.
Terapkan Layanan Virtual dengan menelepon:

Catatan: Saat kami menerapkan sumber daya Istio, Server API Kubernetes memicu peristiwa yang diterima oleh Bidang Kontrol Istio, dan setelah itu, konfigurasi baru diterapkan ke proksi Envoy setiap pod. Dan pengontrol Ingress Gateway tampaknya merupakan Utusan lain yang dikonfigurasi di Control Plane. Semua ini terlihat seperti ini pada diagram:


Konfigurasi Istio-IngressGateway untuk perutean permintaan
Analisis Sentimen kini tersedia di http://{EXTERNAL-IP}/. Jangan khawatir jika Anda mendapatkan status Tidak Ditemukan: terkadang diperlukan waktu lebih lama agar konfigurasi diterapkan dan cache Utusan diperbarui.
Sebelum melanjutkan, mainkan aplikasi sebentar untuk menghasilkan lalu lintas. (kehadirannya diperlukan untuk kejelasan dalam tindakan selanjutnya - kira-kira terjemahan).
Kiali: observabilitas
Untuk masuk ke antarmuka admin Kiali, jalankan perintah berikut:

…dan terbuka http://localhost:20001/dengan login sebagai admin/admin. Di sini Anda akan menemukan banyak fitur berguna, misalnya, untuk memeriksa konfigurasi komponen Istio, memvisualisasikan layanan dari informasi yang dikumpulkan dengan mencegat permintaan jaringan, mendapatkan jawaban atas pertanyaan “Siapa yang menghubungi siapa?”, “Versi layanan mana yang mengalami kegagalan?” dan seterusnya. Secara umum, jelajahi kemungkinan Kiali sebelum melanjutkan memvisualisasikan metrik dengan Grafana.

Grafana: visualisasi metrik
Metrik yang dikumpulkan di Istio berakhir di Prometheus dan divisualisasikan dengan Grafana. Untuk masuk ke antarmuka admin Grafana, jalankan perintah di bawah ini, lalu buka http://localhost:3000/:

Dengan mengklik menu Beranda kiri atas dan pilih Dasbor Layanan Istio di pojok kiri atas, mulai dengan servis sa-web-appuntuk melihat metrik yang dikumpulkan:

Di sini kita menunggu pertunjukan yang kosong dan benar-benar membosankan - manajemen tidak akan pernah menyetujuinya. Mari buat beban kecil dengan perintah berikut:

Sekarang kami memiliki grafik yang jauh lebih cantik, dan selain itu, alat luar biasa Prometheus untuk pemantauan dan Grafana untuk memvisualisasikan metrik, yang memungkinkan kami mempelajari tentang kinerja, status kesehatan, peningkatan/penurunan layanan dari waktu ke waktu.
Terakhir, mari kita lihat penelusuran permintaan dalam layanan.
Jaeger: menelusuri
Kita perlu melakukan penelusuran, karena semakin banyak layanan yang kita miliki, semakin sulit untuk mengetahui penyebab kegagalannya. Mari kita lihat kasus sederhana dari gambar di bawah ini:


Contoh umum dari permintaan acak yang gagal
Permintaan datang, jatuh - apa alasannya? Layanan pertama? Atau kedua? Ada pengecualian pada keduanya - mari kita lihat log masing-masing. Seberapa sering Anda mendapati diri Anda melakukan hal ini? Pekerjaan kami lebih seperti detektif perangkat lunak daripada pengembang…
Ini adalah masalah yang tersebar luas di layanan mikro dan diselesaikan dengan sistem penelusuran terdistribusi, di mana layanan meneruskan header unik satu sama lain, setelah itu informasi ini dialihkan ke sistem penelusuran, untuk dibandingkan dengan data permintaan. Berikut ilustrasinya:


TraceId digunakan untuk mengidentifikasi permintaan
Istio menggunakan Jaeger Tracer, yang mengimplementasikan kerangka kerja OpenTracing API yang tidak bergantung pada vendor. Anda dapat mengakses antarmuka pengguna Jaeger dengan perintah berikut:

Sekarang pergi ke http://localhost:16686/ dan pilih layanan sa-web-app. Jika layanan tidak ditampilkan di menu tarik-turun, tampilkan/hasilkan aktivitas di halaman dan perbarui antarmuka. Setelah itu klik tombolnya Temukan jejak, yang akan menampilkan jejak terbaru - pilih salah satu - informasi terperinci tentang semua jejak akan muncul:

Jejak ini menunjukkan:

 Permintaan itu masuk istio-ingressgateway (ini adalah interaksi pertama dengan salah satu layanan, dan ID Jejak dibuat untuk permintaan tersebut), setelah itu gateway mengirimkan permintaan ke layanan sa-web-app.
 Dalam pelayanan sa-web-app permintaan diambil oleh sespan Utusan, "anak" dibuat dalam rentang tersebut (itulah sebabnya kita melihatnya di jejak) dan diarahkan ke wadah sa-web-app. (Menjangkau - unit kerja logis di Jaeger, yang memiliki nama, waktu mulai operasi, dan durasinya. Rentang dapat disarangkan dan dipesan. Grafik bentang asiklik terarah membentuk jejak. - kira-kira. terjemahan.)
 Di sini permintaan diproses dengan metode analisis sentimen. Jejak ini sudah dihasilkan oleh aplikasi, mis. mereka memerlukan perubahan kode.
 Mulai saat ini, permintaan POST dimulai sa-logika. ID Jejak harus diteruskan dari sa-web-app.
 ...

Catatan: Pada langkah 4, aplikasi akan melihat header yang dihasilkan oleh Istio dan meneruskannya ke permintaan berikutnya, seperti yang ditunjukkan pada gambar di bawah:


(A) Penerusan header adalah tanggung jawab Istio; (B) Layanan bertanggung jawab atas header
Istio melakukan sebagian besar pekerjaan karena menghasilkan header untuk permintaan masuk, membuat span baru di setiap sidecare dan meneruskannya. Namun, tanpa bekerja dengan header di dalam layanan, jalur pelacakan permintaan secara lengkap akan hilang.
Header berikut harus diperhatikan (diteruskan):

Ini adalah tugas yang sederhana, tetapi untuk menyederhanakan implementasinya, sudah ada banyak perpustakaan - misalnya, di layanan sa-web-app, klien RestTemplate meneruskan header ini jika Anda cukup menambahkan pustaka Jaeger dan OpenTracing ke ketergantungannya.
Perhatikan bahwa aplikasi Analisis Sentimen mendemonstrasikan implementasi di Flask, Spring, dan ASP.NET Core.
Kini setelah jelas apa yang akan kita dapatkan (atau hampir keluar dari kotak), mari kita lihat penyempurnaan perutean, manajemen lalu lintas jaringan, keamanan, dan banyak lagi!
Catatan. terjemahan: baca tentang itu di bagian selanjutnya materi Istio dari Rinor Maloku, yang terjemahannya akan menyusul di blog kami dalam waktu dekat. UPDATE (14 Maret): Bagian kedua sudah diterbitkan.
PS dari penerjemah
Baca juga di blog kami:

 "Kembali ke layanan mikro dengan Istio": bagian 2 (perutean, kontrol lalu lintas), bagian 3 (otentikasi dan otorisasi);
 «Conduit - mesh layanan ringan untuk Kubernetes»;
 «Apa itu mesh layanan dan mengapa saya memerlukannya [untuk aplikasi cloud dengan layanan mikro]?»;
 «Panduan bergambar tentang jaringan di Kubernetes. Bagian 1 dan 2»;
 «Bagaimana kontainer sespan ini bisa sampai di sini [di Kubernetes]?'.

Sumber: www.habr.com