Kembali ke perkhidmatan mikro dengan Istio. Bahagian 1

Catatan. terjemah: Jaringan perkhidmatan sudah pasti menjadi penyelesaian yang relevan dalam infrastruktur moden untuk aplikasi berikutan seni bina perkhidmatan mikro. Walaupun Istio mungkin berada di bibir ramai jurutera DevOps, ia adalah produk yang agak baru yang, walaupun komprehensif dari segi keupayaan yang disediakannya, mungkin memerlukan banyak masa untuk membiasakan diri. Jurutera Jerman Rinor Maloku, yang bertanggungjawab untuk pengkomputeran awan untuk pelanggan besar di syarikat telekomunikasi Orange Networks, telah menulis satu siri bahan yang menarik yang membolehkan anda menyelami Istio dengan cepat dan mendalam. Dia memulakan ceritanya dengan perkara yang boleh dilakukan oleh Istio secara umum dan cara anda boleh melihatnya dengan mata anda sendiri dengan cepat.

Istio — Projek Sumber Terbuka dibangunkan dengan kerjasama pasukan daripada Google, IBM dan Lyft. Ia menyelesaikan kerumitan yang timbul dalam aplikasi berasaskan perkhidmatan mikro, seperti:

• Pengurusan Trafik: tamat masa, percubaan semula, pengimbangan beban;
• keselamatan: pengesahan dan kebenaran pengguna akhir;
• Kebolehlihatan: pengesanan, pemantauan, pembalakan.

Semua ini boleh diselesaikan di peringkat aplikasi, tetapi selepas itu perkhidmatan anda tidak lagi menjadi "mikro". Segala usaha tambahan untuk menyelesaikan masalah ini adalah pembaziran sumber syarikat yang boleh digunakan secara langsung untuk nilai perniagaan. Mari lihat contoh:

Pengurus Projek: Berapa lama masa yang diambil untuk menambah ciri maklum balas?
Pemaju: Dua larian pecut.

MP: Apa?.. Ia hanya CRUD!
R: Melakukan CRUD adalah bahagian yang mudah, tetapi kami masih perlu mengesahkan dan membenarkan pengguna dan perkhidmatan. Oleh kerana rangkaian tidak boleh dipercayai, anda perlu melaksanakan permintaan berulang, serta corak pemutus litar dalam klien. Selain itu, untuk memastikan keseluruhan sistem tidak ranap, anda memerlukan tamat masa dan sekat (untuk butiran lanjut tentang kedua-dua corak yang disebut, lihat kemudian dalam artikel - lebih kurang terjemah), dan untuk mengesan masalah, pemantauan, pengesanan, […]

MP: Oh, mari masukkan saja ciri ini ke dalam perkhidmatan Produk.

Saya rasa idea itu jelas: jumlah langkah dan usaha yang diperlukan untuk menambah satu perkhidmatan adalah sangat besar. Dalam artikel ini, kita akan melihat cara Istio mengalih keluar semua kerumitan yang dinyatakan di atas (yang tidak bertujuan untuk menjadi logik perniagaan) daripada perkhidmatan.

Nota: Artikel ini menganggap bahawa anda mempunyai pengetahuan tentang Kubernetes. Jika tidak, saya mengesyorkan membaca pengenalan saya kepada Kubernetes dan hanya selepas itu teruskan membaca bahan ini.

Istio idea

Dalam dunia tanpa Istio, satu perkhidmatan membuat permintaan terus kepada yang lain, dan sekiranya berlaku kegagalan, perkhidmatan itu mesti mengendalikannya sendiri: membuat percubaan baharu, menyediakan tamat masa, membuka pemutus litar, dsb.

Trafik rangkaian dalam Kubernetes

Istio menawarkan penyelesaian khusus, dipisahkan sepenuhnya daripada perkhidmatan dan berfungsi dengan mengganggu komunikasi rangkaian. Dan dengan itu ia melaksanakan:

• toleransi kesalahan: Berdasarkan kod status dalam respons, ia memahami sama ada permintaan itu gagal dan melaksanakannya semula.
• Pelancaran kenari: mengubah hala hanya peratusan tetap permintaan ke versi baharu perkhidmatan.
• Pemantauan dan metrik: Berapa lama masa yang diambil untuk perkhidmatan bertindak balas?
• Pengesanan dan Kebolehmerhatian: Menambah pengepala khas pada setiap permintaan dan menjejakinya merentasi kluster.
• keselamatan: Mengambil token JWT, mengesahkan dan membenarkan pengguna.

Ini hanyalah beberapa kemungkinan (benar-benar hanya beberapa!) untuk menarik minat anda. Sekarang mari kita selami butiran teknikal!

Seni bina Istio

Istio memintas semua trafik rangkaian dan menggunakan satu set peraturan padanya, memasukkan proksi pintar dalam bentuk bekas kereta sampingan ke dalam setiap pod. Proksi yang mengaktifkan semua keupayaan membentuk a Satah Data, dan ia boleh dikonfigurasikan secara dinamik menggunakan Pesawat Kawalan.

Satah Data

Proksi yang dimasukkan ke dalam pod membolehkan Istio memenuhi keperluan yang kami perlukan dengan mudah. Sebagai contoh, mari kita semak fungsi cuba semula dan pemutus litar.

Cara percubaan semula dan pemutus litar dilaksanakan dalam Utusan

Menyusun:

1. duta (kita bercakap tentang proksi yang terletak dalam bekas kereta sampingan, yang diedarkan sebagai produk berasingan - lebih kurang terjemah.) menghantar permintaan kepada contoh pertama perkhidmatan B dan gagal.
2. Envoy Sidecar cuba lagi (cuba semula). (1)
3. Permintaan gagal dan dikembalikan kepada proksi yang memanggilnya.
4. Ini membuka Pemutus Litar dan memanggil perkhidmatan seterusnya untuk permintaan seterusnya. (2)

Ini bermakna anda tidak perlu menggunakan perpustakaan Cuba Semula yang lain, anda tidak perlu membuat pelaksanaan sendiri Pemutus Litar dan Penemuan Perkhidmatan dalam bahasa pengaturcaraan X, Y atau Z. Semua ini dan banyak lagi tersedia di luar kotak dalam Istio dan tidak memerlukan tidak perubahan dalam kod.

Hebat! Sekarang anda mungkin mahu pergi pelayaran dengan Istio, tetapi anda masih mempunyai beberapa keraguan, soalan terbuka. Jika ini adalah penyelesaian universal untuk semua keadaan dalam kehidupan, maka anda mempunyai kecurigaan semula jadi: selepas semua, semua penyelesaian sedemikian pada hakikatnya ternyata tidak sesuai untuk sebarang kes.

Dan akhirnya anda bertanya: "Adakah ia boleh disesuaikan?"

Sekarang anda sudah bersedia untuk pelayaran laut, mari kita berkenalan dengan Kapal Kawalan.

Pesawat Kawalan

Ia terdiri daripada tiga komponen: Pilot, Mixer и Citadel, yang bekerjasama untuk mengkonfigurasi Utusan untuk menghalakan trafik, menguatkuasakan dasar dan mengumpul data telemetri. Secara skematik semuanya kelihatan seperti ini:

Interaksi Satah Kawalan dengan Satah Data

Utusan (iaitu satah data) dikonfigurasikan menggunakan Kubernetes CRD (Definisi Sumber Tersuai) yang ditakrifkan oleh Istio dan bertujuan khusus untuk tujuan ini. Maksudnya kepada anda ialah ia kelihatan seperti sumber lain dalam Kubernetes dengan sintaks yang biasa. Setelah dibuat, sumber ini akan diambil oleh pesawat kawalan dan digunakan untuk Utusan.

Hubungan perkhidmatan kepada Istio

Kami telah menerangkan hubungan Istio dengan perkhidmatan, tetapi bukan sebaliknya: bagaimanakah kaitan perkhidmatan dengan Istio?

Sejujurnya, perkhidmatan menyedari kehadiran Istio sebagaimana ikan adalah air apabila mereka bertanya kepada diri mereka sendiri, "Apakah air itu?"

Ilustrasi Victoria Dimitrakopoulos: - Bagaimana anda suka air? - Apa itu air?

Oleh itu, anda boleh mengambil kluster yang berfungsi dan selepas menggunakan komponen Istio, perkhidmatan yang terletak di dalamnya akan terus berfungsi, dan selepas mengalih keluar komponen ini, semuanya akan baik semula. Adalah jelas bahawa dalam kes ini anda akan kehilangan keupayaan yang disediakan oleh Istio.

Cukup teori - mari amalkan ilmu ini!

Istio dalam amalan

Istio memerlukan gugusan Kubernetes dengan sekurang-kurangnya 4 vCPU dan 8 GB RAM tersedia. Untuk menyediakan kluster dengan cepat dan mengikut arahan daripada artikel, saya mengesyorkan menggunakan Google Cloud Platform, yang menawarkan pengguna baharu percuma $300.

Selepas membuat kluster dan mengkonfigurasi akses kepada Kubernetes melalui utiliti konsol, anda boleh memasang Istio melalui pengurus pakej Helm.

Pemasangan helm

Pasang klien Helm pada komputer anda, seperti yang diterangkan dalam dokumentasi rasmi. Kami akan menggunakan ini untuk menjana templat untuk memasang Istio dalam bahagian seterusnya.

Memasang Istio

Muat turun sumber Istio daripada keluaran terbaru (pautan pengarang asal ke versi 1.0.5 telah ditukar kepada yang semasa, iaitu 1.0.6 - lebih kurang transl.), ekstrak kandungan ke dalam satu direktori, yang akan saya panggil selepas ini [istio-resources].

Untuk mengenal pasti sumber Istio dengan mudah, cipta ruang nama dalam gugusan K8s istio-system:

$ kubectl create namespace istio-system

Lengkapkan pemasangan dengan pergi ke direktori [istio-resources] dan menjalankan arahan:

$ 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 mengeluarkan komponen utama Istio kepada fail istio.yaml. Kami mengubah suai templat standard untuk disesuaikan dengan diri kami sendiri, dengan menyatakan parameter berikut:

• global.mtls.enabled dipasang di false (iaitu pengesahan mTLS dilumpuhkan - lebih kurang)untuk memudahkan proses temu janji kami;
• tracing.enabled termasuk pengesanan permintaan menggunakan Jaeger;
• kiali.enabled memasang Kiali ke dalam kelompok untuk menggambarkan perkhidmatan dan trafik;
• grafana.enabled memasang Grafana untuk menggambarkan metrik yang dikumpul.

Mari gunakan sumber yang dihasilkan dengan arahan:

$ kubectl apply -f istio.yaml

Pemasangan Istio pada kluster telah selesai! Tunggu sehingga semua pod berada dalam ruang nama istio-system akan dapat Running atau Completeddengan menjalankan arahan di bawah:

$ kubectl get pods -n istio-system

Kini kami bersedia untuk meneruskan di bahagian seterusnya, di mana kami akan menyediakan dan menjalankan aplikasi.

Seni bina aplikasi Analisis Sentimen

Mari kita gunakan contoh aplikasi perkhidmatan mikro Analisis Sentimen yang digunakan dalam yang telah disebutkan Artikel pengenalan kepada Kubernetes. Ia cukup rumit untuk menunjukkan keupayaan Istio dalam amalan.

Aplikasi ini terdiri daripada empat perkhidmatan mikro:

1. Perkhidmatan SA-Frontend, yang menyediakan bahagian hadapan aplikasi Reactjs;
2. Perkhidmatan SA-WebApp, yang menyediakan pertanyaan Analisis Sentimen;
3. Perkhidmatan SA-Logik, yang berfungsi sendiri analisis sentimen;
4. Perkhidmatan SA-Maklum Balas, yang menerima maklum balas daripada pengguna tentang ketepatan analisis.

Dalam rajah ini, sebagai tambahan kepada perkhidmatan, kami juga melihat Pengawal Ingress, yang dalam Kubernetes mengarahkan permintaan masuk kepada perkhidmatan yang sesuai. Istio menggunakan konsep serupa dalam Gerbang Ingressnya, butiran lanjut akan menyusul.

Menjalankan aplikasi dengan proksi daripada Istio

Untuk operasi selanjutnya yang disebut dalam artikel, klon repositori anda istio-penguasaan. Ia mengandungi aplikasi dan manifes untuk Kubernetes dan Istio.

Memasukkan sidecars

Penyisipan boleh dilakukan secara automatik atau dengan tangan. Untuk memasukkan bekas kereta sisi secara automatik, anda perlu menetapkan label pada ruang nama istio-injection=enabled, yang dilakukan dengan arahan berikut:

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

Kini setiap pod yang akan digunakan dalam ruang nama lalai (default) akan menerima bekas kereta sampingannya. Untuk mengesahkan ini, mari gunakan aplikasi ujian dengan pergi ke direktori akar repositori [istio-mastery] dan jalankan arahan 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 menggunakan perkhidmatan, mari semak sama ada pod mempunyai dua bekas (dengan perkhidmatan itu sendiri dan kereta sampingannya) dengan menjalankan arahan kubectl get pods dan memastikan bahawa di bawah lajur READY nilai yang ditentukan 2/2, melambangkan bahawa kedua-dua bekas 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 ia kelihatan seperti ini:

Proksi utusan dalam salah satu pod

Memandangkan aplikasi sedang berjalan dan berjalan, kami perlu membenarkan trafik masuk masuk ke dalam aplikasi.

Gerbang Ingress

Amalan terbaik untuk mencapai ini (benarkan trafik dalam kelompok) adalah melalui Gerbang Ingress dalam Istio, yang terletak di "tepi" kluster dan membolehkan anda mendayakan ciri Istio seperti penghalaan, pengimbangan beban, keselamatan dan pemantauan untuk trafik masuk.

Komponen Ingress Gateway dan perkhidmatan yang memajukannya secara luaran telah dipasang dalam kelompok semasa pemasangan Istio. Untuk mengetahui alamat IP luaran perkhidmatan, 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 merujuknya sebagai EXTERNAL-IP), jadi untuk kemudahan kami akan menulis nilai ke dalam pembolehubah:

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

Jika anda cuba mengakses IP ini melalui penyemak imbas sekarang, anda akan menerima ralat Perkhidmatan Tidak Tersedia, kerana secara lalai Istio menyekat semua trafik masuk, Gateway masih belum ditentukan.

Sumber gerbang

Gateway ialah CRD (Definisi Sumber Tersuai) dalam Kubernetes, ditakrifkan selepas memasang Istio dalam kluster dan membolehkan keupayaan untuk menentukan port, protokol dan hos yang kami ingin benarkan trafik masuk.

Dalam kes kami, kami mahu membenarkan trafik HTTP pada port 80 untuk semua hos. Tugas dilaksanakan mengikut 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 untuk pemilih istio: ingressgateway. Dengan pemilih ini, kami boleh menentukan Gerbang Ingress untuk menggunakan konfigurasi. Dalam kes kami, ini ialah pengawal Ingress Gateway, yang dipasang secara lalai dalam Istio.

Konfigurasi digunakan dengan memanggil arahan berikut:

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

Gerbang itu kini membenarkan akses ke port 80, tetapi tidak tahu ke mana hendak menghalakan permintaan. Untuk ini anda perlukan Perkhidmatan Maya.

Sumber Perkhidmatan Maya

Perkhidmatan Maya memberitahu Gerbang Ingress cara menghalakan permintaan yang dibenarkan dalam kluster.

Permintaan kepada aplikasi kami yang datang melalui http-gateway mesti dihantar ke sa-frontend, sa-web-app dan perkhidmatan maklum balas selamat:

Laluan yang perlu dikonfigurasikan dengan VirtualServices

Mari lihat permintaan yang harus dihantar kepada SA-Frontend:

• Perlawanan tepat sepanjang perjalanan / hendaklah dihantar ke SA-Frontend untuk mendapatkan index.html;
• Laluan awalan /static/* mesti dihantar ke SA-Frontend untuk menerima fail statik yang digunakan dalam bahagian hadapan, seperti CSS dan JavaScript;
• Laluan dipadankan dengan ungkapan biasa '^.*.(ico|png|jpg)$', mesti dihantar ke SA-Frontend, kerana Ini adalah gambar-gambar yang dipaparkan pada halaman.

Pelaksanaan 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

perkara penting:

 Perkhidmatan Maya ini merujuk kepada permintaan yang datang http-gerbang;
 В destination Perkhidmatan yang permintaan dihantar ditentukan.

Nota: Konfigurasi di atas disimpan dalam fail sa-virtualservice-external.yaml, yang juga mengandungi tetapan untuk penghalaan dalam SA-WebApp dan SA-Maklum Balas, tetapi telah dipendekkan di sini dalam artikel untuk ringkas.
Mari gunakan Perkhidmatan Maya dengan menghubungi:

Nota: Apabila kami menggunakan sumber Istio, Pelayan API Kubernetes mencipta acara yang diterima oleh Satah Kawalan Istio, dan selepas itu konfigurasi baharu digunakan pada setiap proksi Utusan pod. Dan pengawal Ingress Gateway nampaknya adalah Utusan lain yang dikonfigurasikan dalam Pesawat Kawalan. Semua ini kelihatan seperti ini dalam rajah:


Konfigurasi Istio-IngressGateway untuk penghalaan permintaan
Aplikasi Analisis Sentimen kini tersedia di http://{EXTERNAL-IP}/. Jangan risau jika anda mendapat status Tidak Ditemui: Kadangkala ia mengambil masa lebih lama untuk konfigurasi berkuat kuasa dan cache Envoy untuk dikemas kini.
Sebelum meneruskan, bermain dengan apl itu sedikit untuk menjana trafik. (kehadirannya adalah perlu untuk kejelasan dalam tindakan seterusnya - lebih kurang transl.).
Kiali: kebolehmerhatian
Untuk pergi ke antara muka pentadbiran Kiali, jalankan arahan berikut:

... dan buka http://localhost:20001/, log masuk sebagai pentadbir/pentadbir. Di sini anda akan menemui banyak ciri berguna, contohnya, untuk menyemak konfigurasi komponen Istio, memvisualisasikan perkhidmatan menggunakan maklumat yang dikumpul daripada memintas permintaan rangkaian, mendapatkan jawapan kepada soalan "Siapa yang menghubungi siapa?", "Versi perkhidmatan yang manakah mengalami. kegagalan?” dan sebagainya. Secara umum, terokai keupayaan Kiali sebelum beralih kepada menggambarkan metrik dengan Grafana.

Grafana: visualisasi metrik
Metrik yang dikumpul di Istio pergi ke Prometheus dan divisualisasikan dengan Grafana. Untuk pergi ke antara muka pentadbiran Grafana, jalankan arahan di bawah dan kemudian buka http://localhost:3000/:

Mengklik pada menu Laman Utama kiri atas dan memilih Papan Pemuka Perkhidmatan Istio di penjuru kiri sebelah atas, mulakan dengan perkhidmatan sa-web-appuntuk melihat metrik yang dikumpul:

Apa yang menanti kami di sini ialah prestasi yang kosong dan membosankan - pihak pengurusan tidak akan sekali-kali bersetuju dengan perkara ini. Mari buat beban kecil dengan arahan berikut:

Kini kami mempunyai graf yang lebih bagus, dan sebagai tambahan kepada mereka, alat Prometheus yang hebat untuk pemantauan dan Grafana untuk memvisualisasikan metrik yang akan membolehkan kami mempelajari tentang prestasi, kesihatan, peningkatan / kemerosotan dalam perkhidmatan dari semasa ke semasa.
Akhir sekali, mari kita lihat permintaan pengesanan dalam perkhidmatan.
Jaeger: mengesan
Kami memerlukan pengesanan kerana lebih banyak perkhidmatan yang kami ada, lebih sukar untuk mendapatkan punca kegagalan. Mari lihat kes mudah dari gambar di bawah:


Contoh biasa permintaan gagal rawak
Permintaan datang, jatuh - apa sebabnya? Perkhidmatan pertama? Atau yang kedua? Terdapat pengecualian dalam kedua-duanya - mari kita lihat log setiap satu. Berapa kerapkah anda mendapati diri anda melakukan ini? Kerja kami lebih seperti pengesan perisian berbanding pembangun...
Ini adalah masalah biasa dalam perkhidmatan mikro dan diselesaikan dengan sistem pengesanan teragih, di mana perkhidmatan menghantar pengepala unik antara satu sama lain, selepas itu maklumat ini dimajukan ke sistem pengesanan, di mana ia dibandingkan dengan data permintaan. Berikut adalah ilustrasi:


TraceId digunakan untuk mengenal pasti permintaan
Istio menggunakan Jaeger Tracer, yang melaksanakan rangka kerja API OpenTracing bebas vendor. Anda boleh mengakses antara muka pengguna Jaeger dengan arahan berikut:

Sekarang pergi ke http://localhost:16686/ dan pilih perkhidmatan sa-web-app. Jika perkhidmatan tidak ditunjukkan dalam menu lungsur, tunjukkan/jana aktiviti pada halaman dan kemas kini antara muka. Selepas itu, klik pada butang Cari Jejak, yang akan menunjukkan jejak terkini - pilih mana-mana - maklumat terperinci tentang semua jejak akan muncul:

Jejak ini menunjukkan:

 Permintaan itu masuk istio-ingressgateway (ini ialah interaksi pertama dengan salah satu perkhidmatan dan ID Trace dijana untuk permintaan), selepas itu get laluan menghantar permintaan kepada perkhidmatan sa-web-app.
 Dalam perkhidmatan sa-web-app permintaan itu diambil oleh sidecar Utusan, "kanak-kanak" dibuat dalam rentang (itu sebabnya kita melihatnya dalam jejak) dan dihalakan semula ke bekas sa-web-app. (Span - unit kerja logik di Jaeger, yang mempunyai nama, masa mula operasi dan tempohnya. Span boleh bersarang dan dipesan. Graf asiklik berarah bagi rentang membentuk surih. - lebih kurang terjemah.)
 Di sini permintaan diproses dengan kaedah sentimenAnalisis. Jejak ini sudah dijana oleh aplikasi, i.e. mereka memerlukan perubahan kod.
 Mulai saat ini, permintaan POST dimulakan dalam sa-logik. ID jejak mesti dimajukan daripada sa-web-app.
 ...

Nota: Dalam langkah 4, aplikasi harus melihat pengepala yang dijana oleh Istio dan menyerahkannya kepada permintaan seterusnya seperti yang ditunjukkan dalam imej di bawah:


(A) Istio bertanggungjawab untuk memajukan pengepala; (B) Perkhidmatan bertanggungjawab untuk pengepala
Istio melakukan kebanyakan kerja kerana... menjana pengepala untuk permintaan masuk, mencipta rentang baharu dalam setiap penjagaan sisi dan memajukannya. Walau bagaimanapun, tanpa menggunakan pengepala dalam perkhidmatan, laluan jejak permintaan penuh akan hilang.
Tajuk berikut mesti diambil kira:

Ini bukan tugas yang sukar, tetapi untuk memudahkan pelaksanaannya sudah ada banyak perpustakaan - contohnya, dalam perkhidmatan sa-web-app, klien RestTemplate memajukan pengepala ini jika anda hanya menambah perpustakaan Jaeger dan OpenTracing ke ketagihannya.
Ambil perhatian bahawa aplikasi Analisis Sentimen menunjukkan pelaksanaan dalam Flask, Spring dan ASP.NET Core.
Memandangkan sudah jelas apa yang kita dapat daripada kotak (atau hampir keluar dari kotak), mari kita lihat pada penghalaan yang diperhalusi, pengurusan trafik rangkaian, keselamatan, dsb.!
Catatan. terjemah: Baca tentang ini di bahagian seterusnya bahan di Istio daripada Rinor Maloku, terjemahannya akan menyusul di blog kami dalam masa terdekat. UPDATE (14 Mac): Bahagian kedua telah pun diterbitkan.
PS daripada penterjemah
Baca juga di blog kami:

 "Kembali ke perkhidmatan mikro dengan Istio": bahagian 2 (laluan, kawalan trafik), bahagian 3 (pengesahan dan kebenaran);
 «Konduit - jaringan perkhidmatan ringan untuk Kubernetes»;
 «Apakah mesh perkhidmatan dan mengapa saya memerlukannya [untuk aplikasi awan dengan perkhidmatan mikro]?»;
 «Panduan bergambar untuk rangkaian dalam Kubernetes. Bahagian 1 dan 2»;
 «Bagaimanakah bekas kereta sampingan ini berakhir di sini [di Kubernetes]?'.

Sumber: www.habr.com