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

Not. tercüme: Birinci bölüm Bu seri, Istio yeteneklerini tanıtmaya ve bunları çalışırken göstermeye adanmıştır. Şimdi bu hizmet ağının yapılandırılması ve kullanımının daha karmaşık yönlerinden ve özellikle de ince ayarlanmış yönlendirme ve ağ trafiği yönetimi hakkında konuşacağız.

Ayrıca makalenin depodaki yapılandırmaları (Kubernetes ve Istio için bildirimler) kullandığını da hatırlatırız. istio-ustalık.

Trafik Yönetimi

Istio ile kümede aşağıdakileri sağlayacak yeni özellikler ortaya çıkıyor:

• Dinamik istek yönlendirme: kanarya sunumları, A/B testi;
• Yük dengeleme: basit ve tutarlı, karmalara dayalı;
• Düşmelerden sonra iyileşme: zaman aşımları, yeniden denemeler, devre kesiciler;
• Hata ekleme: gecikmeler, iptal edilen istekler vb.

Makalenin devamında, bu yetenekler seçilen uygulama örnek olarak kullanılarak gösterilecek ve yol boyunca yeni kavramlar tanıtılacaktır. Bu konseptin ilki olacak DestinationRules (yani trafiğin/isteklerin alıcısıyla ilgili kurallar - yaklaşık çeviri)A/B testini bunun yardımıyla etkinleştiriyoruz.

A/B testi: Uygulamada DestinationRules

A/B testi, bir uygulamanın iki sürümünün olduğu (genellikle görsel olarak farklı oldukları) ve hangisinin kullanıcı deneyimini iyileştireceğinden %100 emin olmadığımız durumlarda kullanılır. Bu nedenle her iki sürümü de aynı anda çalıştırıyor ve metrikleri topluyoruz.

A/B testini göstermek için gereken ön ucun ikinci sürümünü dağıtmak için aşağıdaki komutu çalıştırın:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

Yeşil sürümün dağıtım bildirimi iki noktada farklılık gösterir:

1. Resim farklı bir etikete dayanmaktadır - istio-green,
2. Kapsüllerin bir etiketi vardır version: green.

Her iki dağıtımın da bir etiketi olduğundan app: sa-frontend,istekler sanal hizmet tarafından yönlendirilir sa-external-services servis için sa-frontend, tüm örneklerine yönlendirilecek ve yük, aracılığıyla dağıtılacak hepsini bir kez deneme algoritmasıbu da aşağıdaki duruma yol açacaktır:

İstenilen dosyalar bulunamadı

Bu dosyalar uygulamanın farklı sürümlerinde farklı şekilde adlandırıldıkları için bulunamadı. Şundan emin olalım:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Bu demektir ki, index.htmlStatik dosyaların bir sürümünü talep eden statik dosyalar, yük dengeleyici tarafından farklı bir sürüme sahip olan ve bariz nedenlerden dolayı bu tür dosyaların bulunmadığı bölmelere gönderilebilir. Bu nedenle uygulamanın çalışabilmesi için bir kısıtlama koymamız gerekiyor: “index.html'ye hizmet veren uygulamanın aynı sürümü sonraki istekleri de sunmalıdır'.

Tutarlı karma tabanlı yük dengelemeyle bu hedefe ulaşacağız (Tutarlı Karma Yük Dengeleme). Bu durumda aynı istemciden gelen istekler aynı arka uç örneğine gönderilir, önceden tanımlanmış bir özelliğin kullanıldığı (örneğin, bir HTTP üstbilgisi). DestinationRules kullanılarak uygulandı.

Hedef Kuralları

Sonra Sanal Hizmet İstenilen hizmete bir istek gönderildiğinde, DestinationRules'u kullanarak bu hizmetin örneklerine yönelik trafiğe uygulanacak politikaları tanımlayabiliriz:

Istio kaynaklarıyla trafik yönetimi

Dikkat: Istio kaynaklarının ağ trafiği üzerindeki etkisi burada anlaşılması kolay bir şekilde sunulmaktadır. Daha net ifade etmek gerekirse, isteğin hangi bulut sunucusuna gönderileceği kararı, CRD'de yapılandırılan Giriş Ağ Geçidindeki Elçi tarafından verilir.

Hedef Kuralları ile yük dengelemeyi tutarlı karmalar kullanacak ve aynı hizmet örneğinin aynı kullanıcıya yanıt vermesini sağlayacak şekilde yapılandırabiliriz. Aşağıdaki yapılandırma bunu başarmanıza olanak tanır (destinasyonrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP başlığının içeriğine göre karma oluşturulacak version.

Yapılandırmayı aşağıdaki komutla uygulayın:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

Şimdi aşağıdaki komutu çalıştırın ve başlığı belirlerken doğru dosyaları aldığınızdan emin olun. version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

Dikkat: Başlığa farklı değerler eklemek ve sonuçları doğrudan tarayıcıda test etmek için kullanabilirsiniz. bu uzantı Chrome'a (ya Bununla Firefox için - yakl. çeviri.).

Genel olarak DestinationRules, yük dengeleme alanında daha fazla yeteneğe sahiptir; ayrıntılar için bkz. resmi belgeler.

VirtualService'i daha fazla incelemeden önce, aşağıdaki komutları çalıştırarak uygulamanın "yeşil sürümünü" ve ilgili trafik yönü kuralını kaldıralım:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Yansıtma: Uygulamada Sanal Hizmetler

Gölgeleme (“koruyucu”) veya Yansıtma (“yansıtma”) Son kullanıcıları etkilemeden üretimdeki bir değişikliği test etmek istediğimiz durumlarda kullanılır: Bunu yapmak için, istekleri istenen değişikliklerin yapıldığı ikinci bir örneğe kopyalarız ("yansıtırız") ve sonuçlarına bakarız. Basitçe söylemek gerekirse, bu, meslektaşınızın en kritik konuyu seçip, hiç kimsenin inceleyemeyeceği kadar büyük bir pislik yığını şeklinde bir çekme talebinde bulunmasıdır.

Bu senaryoyu çalışırken test etmek için, SA-Logic'in hatalarla birlikte ikinci bir örneğini oluşturalım (buggy) aşağıdaki komutu çalıştırarak:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

Şimdi tüm örneklerin olduğundan emin olmak için komutu çalıştıralım. app=sa-logic Ayrıca ilgili sürümlere sahip etiketleri de vardır:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

Hizmet sa-logic etiketli bölmeleri hedefler app=sa-logic, böylece tüm istekler tüm örnekler arasında dağıtılacaktır:

... ancak isteklerin v1 örneklerine gönderilmesini ve v2 örneklerine yansıtılmasını istiyoruz:

Bunu, kuralların VirtualService'in alt kümelerini ve belirli bir alt kümeye olan rotalarını belirleyeceği DestinationRule ile birlikte VirtualService aracılığıyla başaracağız.

Hedef Kurallarında Alt Kümeleri Tanımlama

Alt kümeler (alt kümeler) aşağıdaki konfigürasyonla belirlenir (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. Ev sahibi (host) bu kuralın yalnızca rotanın servise doğru gittiği durumlar için geçerli olduğunu tanımlar. sa-logic;
2. Başlıklar (name) alt kümeler, alt küme örneklerine yönlendirme yapılırken kullanılır;
3. Etiket (label), örneklerin alt kümenin parçası olabilmesi için eşleşmesi gereken anahtar/değer çiftlerini tanımlar.

Yapılandırmayı aşağıdaki komutla uygulayın:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

Artık alt kümeler tanımlandığına göre, devam edebilir ve VirtualService'i sa-logic'e gelen isteklere kurallar uygulayacak şekilde yapılandırabiliriz; böylece:

1. Bir alt kümeye yönlendirildi v1,
2. Bir alt kümeye yansıtıldı v2.

Aşağıdaki manifesto planlarınızı gerçekleştirmenizi sağlar (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Burada açıklamaya gerek yok, hadi uygulamalı olarak görelim:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

Aşağıdaki komutu çağırarak yükü ekleyelim:

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

Grafana'daki sonuçlara bakalım; burada hataların olduğu sürümü görebilirsiniz (buggy) isteklerin ~%60'ı için başarısız olur, ancak bu hataların hiçbiri, çalışan bir hizmet tarafından yanıtlandığı için son kullanıcıları etkilemez.

Sa-logic hizmetinin farklı versiyonlarının başarılı yanıtları

Burada ilk olarak VirtualService'in hizmetlerimizin Elçilerine nasıl uygulandığını gördük: ne zaman sa-web-app için bir talepte bulunur sa-logic, isteği v1 alt kümesine yönlendirmek ve isteği hizmetin v2 alt kümesine yansıtmak üzere - VirtualService aracılığıyla - yapılandırılan sepet Envoy'dan geçer sa-logic.

Biliyorum, Sanal Hizmetlerin basit olduğunu düşünüyor olabilirsiniz. Bir sonraki bölümde, onların da gerçekten harika olduklarını söyleyerek bu konuyu genişleteceğiz.

Kanarya sunumları

Canary Dağıtımı, bir uygulamanın yeni sürümünün az sayıda kullanıcıya sunulması sürecidir. Sürümde herhangi bir sorun olmadığından emin olmak için kullanılır ve ancak bundan sonra (sürümün) kalitesinden emin olarak onu diğer kullanıcılara dağıtır.оdaha büyük izleyici kitlesi.

Kanarya çıkışlarını göstermek için bir alt kümeyle çalışmaya devam edeceğiz buggy у sa-logic.

Önemsiz şeylerle zaman kaybetmeyelim ve kullanıcıların %20'sini derhal hatalı sürüme (bu bizim kanarya dağıtımımızı temsil edecektir) ve geri kalan %80'i normal hizmete gönderelim. Bunu yapmak için aşağıdaki VirtualService'i kullanın (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 ağırlıktır (weight), bir alıcıya veya alıcının bir alt kümesine yönlendirilecek isteklerin yüzdesini belirtir.

Önceki VirtualService yapılandırmasını güncelleyelim sa-logic aşağıdaki komutla:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... ve bazı isteklerin başarısızlıkla sonuçlandığını hemen göreceğiz:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices, canary dağıtımlarını mümkün kılıyor: Bu durumda, sorunların potansiyel etkisini kullanıcı tabanının %20'sine kadar daralttık. Müthiş! Artık kodumuzdan emin olmadığımız her durumda (başka bir deyişle - her zaman...), yansıtmayı ve canary rollouts'u kullanabiliriz.

Zaman aşımları ve yeniden denemeler

Ancak hatalar her zaman kodda yer almaz. Listedeki "Dağıtık Hesaplama Hakkında 8 Yanılgı“İlk sırada “ağın güvenilir olduğuna” dair hatalı inanç var. Gerçekte ağ hayır güvenilir ve bu nedenle zaman aşımlarına ihtiyacımız var (zaman aşımları) ve yeniden dener (yeniden denemeler).

Gösterim amacıyla aynı sorunlu sürümü kullanmaya devam edeceğiz sa-logic (buggy) ve ağın güvenilmezliğini rastgele hatalarla simüle edeceğiz.

Hata içeren hizmetimizin 1/3'ünün yanıt vermesinin çok uzun sürmesi, 1/3'ünün Dahili Sunucu Hatası ile bitmesi ve 1/3'ünün sayfayı başarılı bir şekilde geri döndürme şansı olsun.

Bu tür sorunların etkisini azaltmak ve kullanıcıların hayatını daha iyi hale getirmek için şunları yapabiliriz:

1. Hizmetin yanıt vermesi 8 saniyeden uzun sürerse zaman aşımı ekleyin,
2. istek başarısız olursa yeniden deneyin.

Uygulama için aşağıdaki kaynak tanımını kullanacağız (sa-logic-yeniden denemeler-zaman aşımları-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. İsteğin zaman aşımı 8 saniyeye ayarlanmıştır;
2. İstekler 3 kez yeniden denenir;
3. Ve yanıt süresi 3 saniyeyi aşarsa her deneme başarısız sayılır.

Bu bir optimizasyondur çünkü kullanıcının 8 saniyeden fazla beklemesi gerekmeyecektir ve başarısızlık durumunda yanıt almak için üç yeni girişimde bulunarak başarılı yanıt şansını artıracağız.

Güncellenen yapılandırmayı aşağıdaki komutla uygulayın:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

Başarılı yanıtların sayısının yukarıda arttığını Grafana grafiklerinden kontrol edin:

Zaman aşımları ve yeniden denemeler eklendikten sonra başarılı yanıt istatistiklerinde iyileştirmeler yapıldı

Bir sonraki bölüme geçmeden önce (veya daha doğrusu, makalenin bir sonraki bölümüne geçin, çünkü bunda artık pratik deneyler olmayacak - yaklaşık çeviri.), silmek sa-logic-buggy ve aşağıdaki komutları çalıştırarak VirtualService'i kullanın:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

Devre Kesici ve Bölme Modelleri

Mikro hizmet mimarisinde, kendinizi kurtarmanıza olanak tanıyan iki önemli kalıptan bahsediyoruz (kendi kendini iyileştirme) Hizmetler.

şalter ("devre kesici") Sağlıksız olduğu düşünülen bir hizmet örneğine gelen istekleri sonlandırmak ve istemci istekleri o hizmetin sağlıklı örneklerine yönlendirilirken hizmeti geri yüklemek için kullanılır (bu, başarılı yanıtların yüzdesini artırır). (Not: Desenin daha ayrıntılı bir açıklaması bulunabilir; örneğin, burada.)

gemi bölmesi ("bölüm") Hizmet arızalarının tüm sistemi etkilemesini engeller. Örneğin, Hizmet B bozuldu ve başka bir hizmet (Hizmet B'nin istemcisi), Hizmet B'ye bir istekte bulunarak iş parçacığı havuzunu tüketmesine ve diğer isteklere (Hizmet B'den olmasalar bile) hizmet verememesine neden oldu. (Not: Desenin daha ayrıntılı bir açıklaması bulunabilir; örneğin, burada.)

Bu kalıpların uygulama ayrıntılarını atlayacağım çünkü onları bulmak kolay resmi belgelerve ayrıca makalenin bir sonraki bölümünde tartışılacak olan kimlik doğrulama ve yetkilendirmeyi de gerçekten göstermek istiyorum.

çevirmenden PS

Blogumuzda da okuyun:

• "Istio ile mikro hizmetlere geri dön": 1. bölüm (ana özelliklere giriş), 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]?'.

Kaynak: habr.com