Istio ile mikro hizmetlere geri dönelim. Bölüm 1

Not. tercüme: Hizmet ağları, mikro hizmet mimarisini takip eden uygulamalar için modern altyapıda kesinlikle uygun bir çözüm haline gelmiştir. Istio, birçok DevOps mühendisinin ağzında olsa da sağladığı yetenekler açısından kapsamlı olmasına rağmen alışması önemli miktarda zaman gerektirebilecek oldukça yeni bir üründür. Telekomünikasyon şirketi Orange Networks'ün büyük müşterileri için bulut bilişimden sorumlu olan Alman mühendis Rinor Maloku, Istio'ya hızlı ve derinlemesine dalmanıza olanak tanıyan harika bir dizi materyal yazdı. Hikayesine Istio'nun genel olarak neler yapabileceğini ve bunları kendi gözlerinizle nasıl hızlı bir şekilde görebileceğinizi anlatarak başlıyor.

Istio — Google, IBM ve Lyft ekiplerinin işbirliğiyle geliştirilen bir Açık Kaynak projesi. Mikro hizmet tabanlı uygulamalarda ortaya çıkan aşağıdaki gibi karmaşıklıkları çözer:

• Trafik Yönetimi: zaman aşımları, yeniden denemeler, yük dengeleme;
• güvenlik: son kullanıcı kimlik doğrulaması ve yetkilendirmesi;
• Gözlenebilirlik: izleme, izleme, günlüğe kaydetme.

Bunların hepsi uygulama düzeyinde çözülebilir ancak bundan sonra hizmetleriniz artık “mikro” olmayacaktır. Bu sorunları çözmeye yönelik tüm ekstra çabalar, doğrudan iş değeri için kullanılabilecek şirket kaynaklarının israfıdır. Bir örneğe bakalım:

Proje Yöneticisi: Geri bildirim özelliğinin eklenmesi ne kadar sürer?
Geliştirici: İki sprint.

MP: Ne?.. Bu sadece CRUD!
R: CRUD yapmak işin kolay kısmı ama yine de kullanıcıların ve hizmetlerin kimliğini doğrulamamız ve yetkilendirmemiz gerekiyor. Ağ güvenilmez olduğundan, tekrarlanan isteklerin yanı sıra tekrarlanan istekleri de uygulamanız gerekecektir. devre kesici düzeni Müşterilerde. Ayrıca tüm sistemin çökmediğinden emin olmak için zaman aşımlarına ve bölmeleri (bahsedilen her iki model hakkında daha fazla ayrıntı için makalenin ilerleyen bölümlerine bakın - yaklaşık çeviri)ve sorunları tespit etmek, izlemek, takip etmek, […]

MP: Ah, o zaman bu özelliği Ürün hizmetine ekleyelim.

Bence fikir açık: bir hizmeti eklemek için gereken adımların ve çabanın miktarı çok büyük. Bu makalede, Istio'nun yukarıda bahsedilen (iş mantığı olması amaçlanmayan) tüm karmaşıklığı hizmetlerden nasıl kaldırdığına bakacağız.

Dikkat: Bu makale, Kubernetes hakkında çalışma bilgisine sahip olduğunuzu varsaymaktadır. Aksi takdirde okumanızı tavsiye ederim Kubernetes'le tanışmam ve ancak bundan sonra bu materyali okumaya devam edin.

Istio fikri

Istio'nun olmadığı bir dünyada, bir hizmet diğerine doğrudan istekte bulunur ve bir arıza durumunda hizmetin bunu kendisi halletmesi gerekir: yeni bir deneme yapmak, zaman aşımı sağlamak, devre kesiciyi açmak vb.

Kubernetes'te ağ trafiği

Istio, hizmetlerden tamamen ayrılmış ve ağ iletişimine müdahale ederek çalışan özel bir çözüm sunar. Ve böylece şunu uygular:

• hata toleransı: Yanıttaki durum koduna göre isteğin başarısız olup olmadığını anlar ve yeniden çalıştırır.
• Kanarya sunumları: isteklerin yalnızca sabit bir yüzdesini hizmetin yeni sürümüne yönlendirir.
• İzleme ve ölçümler: Hizmetin yanıt vermesi ne kadar sürdü?
• İzleme ve Gözlemlenebilirlik: Her isteğe özel başlıklar ekler ve bunları küme genelinde izler.
• güvenlik: JWT belirtecini alır, kullanıcıların kimliğini doğrular ve yetkilendirir.

Bunlar ilginizi çekebilecek olasılıklardan sadece birkaçı (aslında sadece birkaçı!). Şimdi gelelim teknik detaylara!

Istio mimarisi

Istio, tüm ağ trafiğini keser ve buna bir dizi kural uygulayarak her bölmeye sepet konteyneri biçiminde akıllı bir proxy ekler. Tüm yetenekleri etkinleştiren proxy'ler bir Veri Düzlemikullanılarak dinamik olarak yapılandırılabilirler. Kontrol Paneli.

Veri Düzlemi

Pod'lara eklenen proxy'ler, Istio'nun ihtiyacımız olan gereksinimleri kolayca karşılamasını sağlıyor. Örneğin yeniden deneme ve devre kesici fonksiyonlarını kontrol edelim.

Envoy'da yeniden denemeler ve devre kesme nasıl uygulanır?

Özetlemek gerekirse:

1. elçi (bir sepet konteynerinde bulunan ve şu şekilde dağıtılan bir proxy'den bahsediyoruz: ayrı ürün - yaklaşık. çeviri.) B hizmetinin ilk örneğine bir istek gönderir ve başarısız olur.
2. Elçi Sepeti tekrar denedi (yeniden dene). (1)
3. İstek başarısız olur ve onu çağıran proxy'ye geri gönderilir.
4. Bu, Circuit Breaker'ı açar ve sonraki istekler için sonraki hizmeti çağırır. (2)

Bu, başka bir Yeniden Deneme kitaplığı kullanmanıza gerek olmadığı, X, Y veya Z programlama dilinde kendi Devre Kesme ve Hizmet Keşif uygulamanızı yapmanız gerekmediği anlamına gelir. Tüm bunlar ve çok daha fazlası kutudan çıktığı anda mevcuttur. Istio'da ve gerektirmez hayır koddaki değişiklikler.

Harika! Şimdi Istio ile bir yolculuğa çıkmak isteyebilirsiniz ama hâlâ bazı şüpheleriniz, açık sorularınız var. Bu, yaşamdaki tüm durumlar için evrensel bir çözümse, o zaman doğal bir şüpheniz vardır: Sonuçta, bu tür çözümlerin tümü gerçekte her durum için uygun değildir.

Ve sonunda şunu soruyorsunuz: “Özelleştirilebilir mi?”

Artık deniz yolculuğuna hazırsınız, gelin Kontrol Uçağı'nı tanıyalım.

Kontrol Paneli

Üç bileşenden oluşur: Pilot, mikser и KaleElçiler'i trafiği yönlendirmek, politikaları uygulamak ve telemetri verilerini toplamak üzere yapılandırmak için birlikte çalışır. Şematik olarak her şey şöyle görünüyor:

Kontrol Düzleminin Veri Düzlemi ile Etkileşimi

Elçiler (yani veri düzlemi) kullanılarak yapılandırılır Kubernetes CRD'si (Özel Kaynak Tanımları) Istio tarafından tanımlanır ve özellikle bu amaç için tasarlanmıştır. Bunun sizin için anlamı, bunların Kubernetes'te tanıdık bir sözdizimine sahip başka bir kaynak gibi görünmesidir. Bu kaynak oluşturulduktan sonra kontrol düzlemi tarafından alınacak ve Elçilere uygulanacaktır.

Hizmetlerin Istio ile ilişkisi

Istio'nun hizmetlerle ilişkisini anlattık ancak bunun tersini açıklamadık: hizmetlerin Istio ile ilişkisi nedir?

Dürüst olmak gerekirse, balıkların sudan haberdar olması gibi, hizmetler de Istio'nun varlığından haberdardır ve kendilerine "Su nedir?" diye sorarlar.

örnekleme Victoria Dimitrakopoulos: - Suyu nasıl buldunuz? - Su nedir ki?

Böylece çalışan bir kümeyi alabilirsiniz ve Istio bileşenlerini dağıttıktan sonra içinde bulunan hizmetler çalışmaya devam edecek ve bu bileşenleri çıkardıktan sonra her şey tekrar yoluna girecek. Bu durumda Istio'nun sağladığı yetenekleri kaybedeceğiniz açıktır.

Bu kadar teori yeter - hadi bu bilgiyi uygulamaya koyalım!

Uygulamada Istio

Istio, en az 4 vCPU'ya ve 8 GB RAM'e sahip bir Kubernetes kümesi gerektirir. Hızlı bir şekilde küme kurmak ve makaledeki talimatları takip etmek için yeni kullanıcılara hizmet sunan Google Cloud Platform'u kullanmanızı öneririm. ücretsiz 300$.

Bir küme oluşturduktan ve konsol yardımcı programı aracılığıyla Kubernetes'e erişimi yapılandırdıktan sonra Istio'yu Helm paket yöneticisi aracılığıyla yükleyebilirsiniz.

Dümen kurulumu

Helm istemcisini, aşağıda açıklandığı gibi bilgisayarınıza yükleyin. resmi belgeler. Bunu bir sonraki bölümde Istio'yu yüklemek için şablonlar oluşturmak için kullanacağız.

Istio'yu yükleme

Istio kaynaklarını şu adresten indirin: En son sürüm (Orijinal yazarın 1.0.5 sürümüne olan bağlantısı mevcut sürümle değiştirildi, yani 1.0.6 - yaklaşık çeviri.), içerikleri bundan sonra arayacağım tek bir dizine çıkartın [istio-resources].

Istio kaynaklarını kolayca tanımlamak için K8s kümesinde bir ad alanı oluşturun istio-system:

$ kubectl create namespace istio-system

Dizine giderek kurulumu tamamlayın [istio-resources] ve şu komutu çalıştırıyorum:

$ 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

Bu komut, Istio'nun temel bileşenlerini bir dosyaya çıkaracaktır istio.yaml. Aşağıdaki parametreleri belirterek standart şablonu kendimize uyacak şekilde değiştirdik:

• global.mtls.enabled yüklü false (yani mTLS kimlik doğrulaması devre dışı bırakıldı - yaklaşık)flört sürecimizi basitleştirmek için;
• tracing.enabled Jaeger kullanılarak istek takibini içerir;
• kiali.enabled hizmetleri ve trafiği görselleştirmek için Kiali'yi bir kümeye yükler;
• grafana.enabled Toplanan ölçümleri görselleştirmek için Grafana'yı yükler.

Oluşturulan kaynakları şu komutla kullanalım:

$ kubectl apply -f istio.yaml

Istio'nun kümeye kurulumu tamamlandı! Tüm bölmeler ad alanına girene kadar bekleyin istio-system edebilecektir Running veya Completedaşağıdaki komutu çalıştırarak:

$ kubectl get pods -n istio-system

Artık uygulamayı çalışır duruma getireceğimiz bir sonraki bölümde devam etmeye hazırız.

Duygu Analizi uygulamasının mimarisi

Daha önce bahsedilenlerde kullanılan Duyarlılık Analizi mikro hizmet uygulaması örneğini kullanalım. Kubernetes'e giriş makalesi. Istio'nun yeteneklerini pratikte gösterecek kadar karmaşık.

Uygulama dört mikro hizmetten oluşur:

1. Hizmet SA-Ön UçBir Reactjs uygulamasının ön ucuna hizmet eden;
2. Hizmet SA-Web UygulamasıDuyarlılık Analizi sorgularına hizmet eden;
3. Hizmet SA-Mantıkkendi kendini gerçekleştiren duygu analizi;
4. Hizmet SA-Geri BildirimAnalizin doğruluğu konusunda kullanıcılardan geri bildirim alan.

Bu diyagramda hizmetlerin yanı sıra Kubernetes'te gelen istekleri uygun hizmetlere yönlendiren Giriş Denetleyicisini de görüyoruz. Istio, Ingress Gateway'inde benzer bir konsept kullanıyor; daha fazla detayı aşağıda yer alacak.

Bir uygulamayı Istio'dan proxy ile çalıştırma

Makalede bahsedilen diğer işlemler için deponuzu klonlayın istio-ustalık. Kubernetes ve Istio için uygulamayı ve bildirimleri içerir.

Yan arabaları ekleme

Ekleme yapılabilir otomatik olarak veya el ile. Sepet kaplarını otomatik olarak eklemek için ad alanına bir etiket ayarlamanız gerekir. istio-injection=enabled, aşağıdaki komutla yapılır:

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

Artık varsayılan ad alanına dağıtılacak her bölme (default) sepet konteynerini alacaktır. Bunu doğrulamak için repositorynin kök dizinine giderek test uygulamasını dağıtalım. [istio-mastery] ve aşağıdaki komutu çalıştırıyorum:

$ 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

Hizmetleri dağıttıktan sonra, komutu çalıştırarak bölmelerin iki kapsayıcıya (hizmetin kendisi ve sepetiyle birlikte) sahip olup olmadığını kontrol edelim. kubectl get pods ve sütunun altında olduğundan emin olmak READY değer belirtildi 2/2, her iki kapsayıcının da çalıştığını simgeleyen:

$ 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

Görsel olarak şöyle görünüyor:

Bölmelerden birinde elçi vekili

Artık uygulama çalışır durumda olduğuna göre, gelen trafiğin uygulamaya gelmesine izin vermemiz gerekecek.

Giriş Ağ Geçidi

Bunu başarmak için en iyi uygulama (kümedeki trafiğe izin vermek) Giriş Ağ Geçidi Kümenin "kenarında" yer alan ve gelen trafik için yönlendirme, yük dengeleme, güvenlik ve izleme gibi Istio özelliklerini etkinleştirmenize olanak tanıyan Istio'da.

Ingress Gateway bileşeni ve onu harici olarak ileten hizmet, Istio kurulumu sırasında kümeye kuruldu. Hizmetin harici IP adresini bulmak için şunu çalıştırın:

$ 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

Bu IP'yi kullanarak uygulamaya erişmeye devam edeceğiz (buna HARİCİ-IP olarak değineceğim), dolayısıyla kolaylık olması açısından değeri bir değişkene yazacağız:

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

Bu IP'ye şimdi bir tarayıcı aracılığıyla erişmeye çalışırsanız Hizmet Kullanılamıyor hatası alırsınız, çünkü Istio varsayılan olarak tüm gelen trafiği engeller, Ağ Geçidi henüz tanımlanmadı.

Ağ geçidi kaynağı

Ağ Geçidi, Kubernetes'te, Istio'nun kümeye kurulmasından sonra tanımlanan ve gelen trafiğe izin vermek istediğimiz bağlantı noktalarını, protokolü ve ana bilgisayarları belirleme olanağı sağlayan bir CRD'dir (Özel Kaynak Tanımı).

Bizim durumumuzda tüm ana bilgisayarlar için 80 numaralı bağlantı noktasında HTTP trafiğine izin vermek istiyoruz. Görev aşağıdaki tanımla uygulanır (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:
- "*"

Bu konfigürasyonun seçici dışında herhangi bir açıklamaya ihtiyacı yoktur istio: ingressgateway. Bu seçiciyle yapılandırmanın hangi Giriş Ağ Geçidine uygulanacağını belirleyebiliriz. Bizim durumumuzda bu, Istio'da varsayılan olarak yüklenen Giriş Ağ Geçidi denetleyicisidir.

Yapılandırma aşağıdaki komut çağrılarak uygulanır:

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

Ağ geçidi artık 80 numaralı bağlantı noktasına erişime izin veriyor ancak istekleri nereye yönlendireceği hakkında hiçbir fikri yok. Bunun için ihtiyacınız olacak Sanal Hizmetler.

Sanal Hizmet kaynağı

VirtualService, Giriş Ağ Geçidine küme içinde izin verilen isteklerin nasıl yönlendirileceğini anlatır.

Uygulamamıza http-gateway üzerinden gelen isteklerin sa-frontend, sa-web-app ve sa-feedback hizmetlerine gönderilmesi gerekmektedir:

VirtualServices ile yapılandırılması gereken rotalar

SA-Frontend'e gönderilmesi gereken isteklere bakalım:

• Yol boyunca tam eşleşme / index.html'yi almak için SA-Frontend'e gönderilmelidir;
• Önekli yollar /static/* CSS ve JavaScript gibi ön uçta kullanılan statik dosyaları almak için SA-Frontend'e gönderilmelidir;
• Normal ifadeyle eşleşen yollar '^.*.(ico|png|jpg)$', SA-Frontend'e gönderilmelidir çünkü Bunlar sayfada görüntülenen resimlerdir.

Uygulama aşağıdaki konfigürasyonla gerçekleştirilir (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)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

Önemli noktalar:

1. Bu Sanal Hizmet, gelen istekleri ifade eder http ağ geçidi;
2. В destination İsteklerin gönderileceği servis belirlenir.

Dikkat: Yukarıdaki konfigürasyon bir dosyada saklanır sa-virtualservice-external.yamlSA-WebApp ve SA-Feedback'te yönlendirme ayarlarını da içerir, ancak burada makalede kısalık sağlamak amacıyla kısaltılmıştır.

VirtualService'i arayarak uygulayalım:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created

Dikkat: Istio kaynaklarını tükettiğimizde Kubernetes API Sunucusu, Istio Kontrol Düzlemi tarafından alınan bir olay oluşturur ve bundan sonra yeni yapılandırma her bir kapsülün Envoy proxy'lerine uygulanır. Ve Giriş Ağ Geçidi denetleyicisi, Kontrol Düzleminde yapılandırılmış başka bir Elçi gibi görünüyor. Bütün bunlar şemada şöyle görünüyor:

İstek yönlendirme için Istio-IngressGateway yapılandırması

Duygu Analizi uygulaması artık kullanıma sunuldu http://{EXTERNAL-IP}/. Bulunamadı durumunu alırsanız endişelenmeyin: Bazen yapılandırmanın etkili olması ve Envoy önbelleklerinin güncellenmesi biraz daha uzun sürebilir.

Devam etmeden önce trafik oluşturmak için uygulamayla biraz oynayın. (sonraki eylemlerde netlik sağlamak için varlığı gereklidir - yaklaşık çeviri.).

Kiali: gözlemlenebilirlik

Kiali yönetim arayüzüne ulaşmak için aşağıdaki komutu çalıştırın:

$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001

... ve aç http://localhost:20001/, yönetici/yönetici olarak oturum açın. Burada, örneğin Istio bileşenlerinin yapılandırmasını kontrol etmek, ağ isteklerinin ele geçirilmesinden toplanan bilgileri kullanarak hizmetleri görselleştirmek, "Kim kiminle iletişim kuruyor?", "Hizmetin hangi sürümünde sorun yaşanıyor" sorularına yanıt almak için birçok yararlı özellik bulacaksınız. başarısızlıklar mı?” ve benzeri. Genel olarak Grafana ile metrikleri görselleştirmeye geçmeden önce Kiali'nin yeteneklerini keşfedin.

Grafana: metrik görselleştirme

Istio'da toplanan metrikler Prometheus'a gider ve Grafana ile görselleştirilir. Grafana yönetim arayüzüne ulaşmak için aşağıdaki komutu çalıştırın ve ardından açın. 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

Menüye tıklayarak Ana Sayfa sol üst ve seçiliyor Istio Servis Kontrol Paneli sol üst köşede servisle başlayın sa-web-apptoplanan metriklere bakmak için:

Burada bizi boş ve tamamen sıkıcı bir performans bekliyor - yönetim bunu asla onaylamaz. Aşağıdaki komutla küçük bir yük oluşturalım:

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

Artık çok daha güzel grafiklerimiz var ve bunlara ek olarak izleme için harika Prometheus araçları ve zaman içinde performans, sağlık, hizmetlerdeki iyileştirmeler / bozulmalar hakkında bilgi edinmemizi sağlayacak metrikleri görselleştirmek için Grafana araçları var.

Son olarak hizmetlerdeki isteklerin izlenmesine bakalım.

Jaeger: izleme

Takibe ihtiyacımız olacak çünkü ne kadar çok hizmete sahip olursak başarısızlığın sebebine ulaşmak o kadar zor olur. Aşağıdaki resimdeki basit bir duruma bakalım:

Rastgele başarısız bir isteğin tipik örneği

İstek gelir, düşer - Sebebi nedir? İlk servis mi? Yoksa ikincisi mi? Her ikisinde de istisnalar var; her birinin kayıtlarına bakalım. Kendinizi ne sıklıkla bunu yaparken yakaladınız? Bizim işimiz geliştiricilerden çok yazılım dedektiflerine benziyor...

Bu, mikro hizmetlerde yaygın bir sorundur ve hizmetlerin birbirine benzersiz bir başlık ilettiği, ardından bu bilginin istek verileriyle karşılaştırılacağı izleme sistemine iletildiği dağıtılmış izleme sistemleriyle çözülür. İşte bir örnek:

TraceId isteği tanımlamak için kullanılır

Istio, satıcıdan bağımsız OpenTracing API çerçevesini uygulayan Jaeger Tracer'ı kullanıyor. Jaeger kullanıcı arayüzüne aşağıdaki komutla erişebilirsiniz:

$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686

şimdi git http://localhost:16686/ ve bir hizmet seçin sa-web-app. Hizmet açılır menüde gösterilmiyorsa sayfada etkinlik gösterin/oluşturun ve arayüzü güncelleyin. Bundan sonra düğmeye tıklayın İzleri Bul, en son izleri gösterecek - herhangi birini seçin - tüm izlere ilişkin ayrıntılı bilgiler görünecektir:

Bu iz şunları gösterir:

1. Talep geliyor istio-giriş ağ geçidi (bu, hizmetlerden biriyle ilk etkileşimdir ve istek için bir İzleme Kimliği oluşturulur), ardından ağ geçidi, isteği hizmete gönderir sa-web-app.
2. Serviste sa-web-app istek Elçi sepeti tarafından alınır, yayılma alanında bir "çocuk" oluşturulur (bu yüzden onu izlerde görüyoruz) ve konteynere yönlendirilir sa-web-app. (Açıklık - Jaeger'de adı, işlemin başlangıç ​​zamanı ve süresi olan mantıksal bir iş birimi. Açıklıklar iç içe yerleştirilebilir ve sıralanabilir. Açıklıkların yönlendirilmiş asiklik grafiği bir iz oluşturur. - yaklaşık. çeviri.)
3. Burada istek yöntemle işlenir duygu analizi. Bu izler uygulama tarafından zaten oluşturulmuştur; kod değişiklikleri gerektirdiler.
4. Bu andan itibaren POST isteği başlatılır. sa-mantık. İzleme kimliği şuradan iletilmelidir: sa-web-app.
5. ...

Dikkat: 4. adımda uygulama, Istio tarafından oluşturulan başlıkları görmeli ve bunları aşağıdaki resimde gösterildiği gibi sonraki isteklere aktarmalıdır:

(A) Istio, başlıkların iletilmesinden sorumludur; (B) Hizmetler başlıklardan sorumludur

Istio işin çoğunu yapıyor çünkü... gelen istekler için başlıklar oluşturur, her yan bakımda yeni aralıklar oluşturur ve bunları iletir. Ancak hizmetlerin içindeki başlıklarla çalışmazsanız tam istek izleme yolu kaybolacaktır.

Aşağıdaki başlıklar dikkate alınmalıdır:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

Bu zor bir iş değil, ancak uygulanmasını basitleştirmek için zaten mevcut birçok kütüphane - örneğin, sa-web-app hizmetinde, yalnızca Jaeger ve OpenTracing kitaplıklarını eklerseniz RestTemplate istemcisi bu başlıkları iletir. onun bağımlılıkları.

Duyarlılık Analizi uygulamasının Flask, Spring ve ASP.NET Core'daki uygulamaları gösterdiğini unutmayın.

Artık kutudan ne çıkardığımıza (ya da neredeyse kutudan ne çıkardığımıza) göre, ince ayarlı yönlendirmeye, ağ trafiği yönetimine, güvenliğe vb. bakalım!

Not. tercüme: Çevirileri yakın gelecekte blogumuzda yayınlanacak olan Rinor Maloku'nun Istio hakkındaki materyallerinin bir sonraki bölümünde bu konuyu okuyun. GÜNCELLEME (14 Mart): İkinci bölüm zaten yayınlandı.

çevirmenden PS

Blogumuzda da okuyun:

• "Istio ile mikro hizmetlere geri dön": bölüm 2 (yönlendirme, trafik kontrolü), 3. bölüm (kimlik doğrulama ve yetkilendirme);
• «Conduit - Kubernetes için hafif servis ağı";
• «Hizmet ağı nedir ve neden buna ihtiyacım var [mikro hizmetlere sahip bir bulut uygulaması için]?";
• «Kubernetes'te ağ oluşturmaya yönelik resimli bir kılavuz. Bölüm 1 ve 2";
• «Bu sepet konteyneri nasıl buraya [Kubernetes'e] geldi?'.

Kaynak: habr.com