Istio ve Kubernetes üretimde. Bölüm 2. İzleme

Geçmişte Makale Service Mesh Istio'nun temel bileşenlerine baktık, sistemle tanıştık ve genellikle Istio ile çalışmaya başladığımızda ortaya çıkan ana soruları yanıtladık. Bu bölümde bir ağ üzerinden izleme bilgilerinin toplanmasının nasıl organize edileceğine bakacağız.

Birçok geliştirici ve sistem yöneticisinin Service Mesh kelimesini duyduğunda aklına ilk gelen şey izlemedir. Aslında her ağ düğümüne, tüm TCP trafiğinin geçtiği özel bir proxy sunucusu ekliyoruz. Artık ağdaki tüm ağ etkileşimleri hakkında bilgilerin kolayca gönderilmesi mümkün görünüyor. Ne yazık ki gerçekte dikkate alınması gereken birçok nüans var. Şimdi onlara bakalım.

Bir numaralı yanılgı: Çevrimiçi yürüyüş verilerini ücretsiz olarak alabiliriz.

Aslında, nispeten ücretsiz olarak, sistemimizdeki düğümlerin yalnızca oklarla birbirine bağlanmasını ve hizmetler arasında geçen veri hızını (aslında yalnızca zaman birimi başına bayt sayısını) elde edebiliriz. Ancak çoğu durumda hizmetlerimiz HTTP, gRPC, Redis vb. gibi bir tür uygulama katmanı protokolü üzerinden iletişim kurar. Ve elbette, özellikle bu protokoller için izleme bilgilerini görmek istiyoruz; veri hızını değil, istek hızını görmek istiyoruz. Protokolümüzü kullanarak isteklerin gecikmesini anlamak istiyoruz. Son olarak, bir isteğin sistemimize giriş yapmasından kullanıcıdan yanıt almasına kadar geçen tam yolu görmek istiyoruz. Bu sorunun çözümü artık o kadar kolay değil.

Öncelikle Istio'da gönderme izleme aralıklarının mimari açıdan nasıl göründüğüne bakalım. İlk bölümden hatırladığımız gibi Istio'nun telemetri toplamak için Mixer adında ayrı bir bileşeni var. Ancak mevcut sürüm 1.0.*'da gönderim doğrudan proxy sunuculardan yani envoy proxy'den yapılıyor. Elçi proxy'si, zipkin protokolünü kullanarak izleme aralıklarının gönderilmesini destekler. Diğer protokolleri bağlamak mümkündür, ancak yalnızca bir eklenti aracılığıyla. Istio ile, yalnızca zipkin protokolünü destekleyen, derlenmiş ve yapılandırılmış bir elçi proxy'sine hemen sahip oluyoruz. Örneğin Jaeger protokolünü kullanmak ve izleme aralıklarını UDP aracılığıyla göndermek istiyorsak, kendi istio-proxy imajımızı oluşturmamız gerekecektir. İstio-proxy için özel eklentiler desteği vardır, ancak hala alfa sürümündedir. Bu nedenle, çok sayıda özel ayar olmadan yapmak istersek, izleme aralıklarını depolamak ve almak için kullanılan teknoloji aralığı azalır. Aslında ana sistemlerden artık Zipkin'in kendisini veya Jaeger'i kullanabilirsiniz, ancak her şeyi oraya zipkin uyumlu protokolü kullanarak gönderebilirsiniz (ki bu çok daha az verimlidir). Zipkin protokolünün kendisi, tüm izleme bilgilerinin oldukça pahalı olan HTTP protokolü aracılığıyla toplayıcılara gönderilmesini içerir.

Daha önce de söylediğim gibi uygulama düzeyindeki protokolleri izlemek istiyoruz. Bu, her hizmetin yanında bulunan proxy sunucularının şu anda ne tür bir etkileşimin gerçekleştiğini anlaması gerektiği anlamına gelir. Istio, varsayılan olarak tüm bağlantı noktalarını düz TCP olacak şekilde yapılandırır; bu, hiçbir izlemenin gönderilmeyeceği anlamına gelir. Trace'lerin gönderilebilmesi için öncelikle ana mesh yapılandırmasında bu seçeneği etkinleştirmeniz ve çok önemli olan kubernetes hizmet varlıklarının tüm bağlantı noktalarını hizmette kullanılan protokole uygun olarak adlandırmanız gerekir. Yani örneğin şu şekilde:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Ayrıca http-magic gibi bileşik adlar da kullanabilirsiniz (Istio, http'yi görecek ve bu bağlantı noktasını http uç noktası olarak tanıyacaktır). Format şu şekildedir: proto-ekstra.

Protokolü belirlemek için çok sayıda konfigürasyona yama yapmamak için kirli bir geçici çözüm kullanabilirsiniz: Pilot bileşenini tam olduğu anda yamalayın. protokol tanımlama mantığını gerçekleştirir. Sonunda elbette bu mantığı standart hale getirmek ve tüm portlar için bir adlandırma kuralına geçmek gerekecektir.

Protokolün gerçekten doğru tanımlanıp tanımlanmadığını anlamak için, envoy proxy'li sepet konteynerlerinden herhangi birine girip, /config_dump konumuyla envoy arayüzünün admin portuna istekte bulunmanız gerekir. Ortaya çıkan konfigürasyonda istenilen hizmetin operasyon alanına bakmanız gerekmektedir. Istio'da isteğin yapıldığı yeri tanımlayıcı olarak kullanılır. Bu parametrenin değerini Istio'da özelleştirmek için (bunu daha sonra izleme sistemimizde göreceğiz), sepet konteynerini başlatma aşamasında serviceCluster bayrağını belirtmek gerekir. Örneğin aşağı doğru kubernetes API'sinden elde edilen değişkenlerden şu şekilde hesaplanabilir:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Elçide izlemenin nasıl çalıştığını anlamak için iyi bir örnek burada.

İzleme aralıklarını göndermek için uç noktanın kendisi de elçi proxy başlatma bayraklarında belirtilmelidir, örneğin: --zipkinAddress tracing-collector.tracing:9411

İkinci yanılgı: Taleplerin tam izlerini sistem aracılığıyla, kutudan çıktığı gibi ucuz bir şekilde elde edebiliriz

Maalesef öyle değil. Uygulamanın karmaşıklığı, hizmetlerin etkileşimini halihazırda nasıl uyguladığınıza bağlıdır. Nedenmiş?

Gerçek şu ki, istio-proxy'nin bir hizmete gelen taleplerin aynı hizmetten ayrılanlarla yazışmalarını anlayabilmesi için, tüm trafiği basitçe durdurmak yeterli değildir. Bir tür iletişim tanımlayıcıya sahip olmanız gerekir. HTTP elçisi proxy'si, elçinin hizmete yönelik hangi özel isteğin diğer hizmetlere özel istekler oluşturduğunu anladığı özel başlıklar kullanır. Bu tür başlıkların listesi:

• x-istek kimliği,
• x-b3-iz kimliği,
• x-b3-spanid,
• x-b3-ebeveynspanid,
• x-b3-örneklenmiş,
• x-b3-bayrakları,
• x-ot-span-bağlamı.

Böyle bir mantığı ekleyebileceğiniz tek bir noktanız varsa, örneğin temel bir istemciniz varsa, o zaman her şey yolundadır, sadece bu kütüphanenin tüm istemciler için güncellenmesini beklemeniz gerekir. Ancak çok heterojen bir sisteminiz varsa ve ağ üzerinden hizmetten hizmete geçişte bir birleşme yoksa, bu büyük olasılıkla büyük bir sorun olacaktır. Böyle bir mantık eklenmezse tüm izleme bilgileri yalnızca “tek seviyeli” olacaktır. Yani, tüm hizmetler arası etkileşimleri alacağız, ancak bunlar ağ üzerinden tek geçiş zincirlerine yapıştırılmayacak.

Sonuç

Istio, bir ağ üzerinden izleme bilgileri toplamak için kullanışlı bir araç sağlar, ancak uygulama için sisteminizi uyarlamanız ve Istio uygulamasının özelliklerini dikkate almanız gerekeceğini anlamalısınız. Sonuç olarak, iki ana noktanın çözülmesi gerekir: uygulama düzeyindeki protokolün tanımlanması (elçi proxy'si tarafından desteklenmesi gerekir) ve hizmetten gelen isteklerden gelen isteklerin hizmete bağlantısı hakkındaki bilgilerin iletilmesinin ayarlanması (başlıklar kullanılarak) , HTTP protokolü durumunda). Bu sorunlar çözüldüğünde, birçok farklı dil ve çerçevede yazılmış çok heterojen sistemlerde bile ağdan şeffaf bir şekilde bilgi toplamamıza olanak tanıyan güçlü bir araca sahip oluyoruz.

Service Mesh ile ilgili bir sonraki makalede, Istio'nun en büyük sorunlarından biri olan, her sepet proxy konteynerinin yüksek RAM tüketimine bakacağız ve bununla nasıl başa çıkabileceğinizi tartışacağız.

Kaynak: habr.com