Istio'da canary yayın: VirtualService ve DestinationRule ile trafik bölme

Trafik bölme ve canary ne demek?

Canary yayın, yeni bir sürümü tüm kullanıcılara açmadan önce trafiğin küçük bir bölümüyle sınamaktır. Yeni sürüm sorun çıkarırsa etkilenen kullanıcı sayısı sınırlı kalır; sorun yoksa pay kademeli olarak artırılır. Bunu klasik Kubernetes ile yapmaya çalışırsanız pod sayısı oranına bağımlı kalırsınız: yeni sürümden az sayıda pod çalıştırarak "yaklaşık şu kadar trafik" elde edersiniz. Bu hem kaba hem de ölçeklemeyle birbirine bağlı bir yöntemdir.

Istio'da ise trafik payı, pod sayısından bağımsız olarak kural düzeyinde belirlenir. Yeni sürüme tek pod ayrılmış olsa bile trafiğin yarısını ona yönlendirebilirsiniz; ya da çok sayıda pod çalışırken payı çok küçük tutabilirsiniz. Bu ayrım, canary'nin kontrollü ve geri alınabilir olmasını sağlar.

Bu işi birbirini tamamlayan Istio kaynakları yapar. DestinationRule, bir servisin hangi alt kümelere (subset) ayrıldığını tanımlar; VirtualService ise isteklerin hangi alt kümeye ne ağırlıkla gideceğini belirler. Kurulumu yapılmış bir mesh ve sidecar enjekte edilmiş sürümler bu iş için ön koşuldur.

Sürümleri pod etiketleriyle ayırın

Alt kümeler, pod etiketlerine dayanır. Aynı Service'in arkasında çalışan Deployment'ların pod şablonlarında ortak bir uygulama etiketi ve farklı bir sürüm etiketi bulunmalıdır. Örneğin kurgusal bir "siparis" servisi için:

labels: app: siparis version: v1

ve yeni sürümde:

labels: app: siparis version: v2

Service yalnızca app etiketine göre seçim yapar; böylece her sürüm aynı Service'in arkasında yer alır. Istio'nun ayrımı yapabilmesi için etiket adı ve değerleri DestinationRule'daki alt küme tanımlarıyla birebir uyuşmalıdır. Etiketlerde yazım farkı olduğunda alt küme eşleşecek pod bulamaz ve istekler başarısız olur; sorun gidermede ilk bakılacak yerdir.

DestinationRule ile alt kümeleri tanımlayın

DestinationRule, hedef servisin hangi alt kümelere bölüneceğini söyler:

apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: siparis spec: host: siparis subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

host alanı Kubernetes Service adıdır. Her alt küme bir ad ve bir etiket seçicisi taşır. DestinationRule tek başına trafiği değiştirmez; yalnızca "v1" ve "v2" adlı grupların var olduğunu bildirir. Karşılıklı TLS kullanıyorsanız bu kuralda uygun TLS modunu da belirtmeniz gerekebilir; resmî belge, mTLS etkinken bunu atlamanın 503 hatalarına yol açabileceğini belirtir.

VirtualService ile ağırlıkları verin

Önce tüm trafiği mevcut sürüme yönlendirerek başlayın; yeni sürüm dağıtılmış ama henüz trafik almıyordur. Ardından canary payını açın:

apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: siparis spec: hosts: - siparis http: - route: - destination: host: siparis subset: v1 weight: 90 - destination: host: siparis subset: v2 weight: 10

Ağırlıkların toplamı 100 olmalıdır. Kuralı uygulayıp doğrulamak için kubectl get virtualservice siparis -o yaml komutuyla yayımlanan yapılandırmayı görebilirsiniz. Resmî görev, bölmenin etkisini bir örnek uygulama üzerinde sayfayı birçok kez yenileyerek gözlemlemeyi önerir; küçük paylarda dağılımın görünmesi için çok sayıda istek göndermek gerekir.

Her yayın adımında tek bir değişiklik yapın: ağırlığı bir kademe artırın, uygulayın, gözleyin. Yeni sürüm sorunsuzsa son adımda tüm payı ona verin; eski alt kümeyi bir süre hazır tutup geri dönüş yolunu açık bırakın, sonra kaldırın.

Belirli kullanıcıları yeni sürüme yönlendirmek: başlık eşleşmesi

Rastgele yüzde yerine, yalnızca ekibinizin içindeki testçilerin yeni sürümü görmesini isteyebilirsiniz. Bunun için VirtualService'e koşullu bir kural eklersiniz; koşul sağlanırsa istek doğrudan yeni alt kümeye gider, aksi halde ağırlıklı kural işler:

http: - match: - headers: x-canary: exact: "evet" route: - destination: host: siparis subset: v2 - route: - destination: host: siparis subset: v1

Kural sırası önemlidir: en özel koşul en üstte olmalıdır. Başlık yöntemi, canary'yi gerçek müşteri trafiğine açmadan önce üretim ortamında sınamak için kullanışlıdır. Hemen ardından ağırlıklı kurala geçilir. Başlığı yalnızca güvenilir kaynaklardan kabul ettiğinizden emin olun; dışarıdan gelen isteklerde bu başlığın taklit edilebilmesi istenmeyen bir yönlendirme yolu açabilir.

Aynı işi Kubernetes'in Gateway API kaynağı olan HTTPRoute ile de yapabilirsiniz; Istio belgeleri bu yaklaşımların her biri için örnek verir. HTTPRoute, apiVersion olarak gateway.networking.k8s.io/v1 kullanır.

Canary'yi nasıl izler, ne zaman geri alırsınız?

Yayın kararı, ağırlık değil gözlem verisiyle verilir. Her kademede sürümleri aynı ölçülerle kıyaslayın: hata oranı, gecikme dağılımı, kaynak tüketimi ve iş metrikleri (örneğin sipariş tamamlama oranı). Mesh'in sağladığı servis metrikleri ve dağıtık izler sürüm bazında filtrelendiğinde bu kıyası kolaylaştırır.

Geri alma kuralını yayından önce yazın: "hata oranı belirlenen eşiği aşarsa ağırlık eski sürüme geri çevrilir." Geri almanın tek bir yapılandırma değişikliği olması mesh'in en önemli kazancıdır; yeni imaj dağıtmaktan çok daha hızlıdır.

Sık yapılan hatalar: • Pod etiketleriyle alt küme tanımlarının uyuşmaması • Ağırlıkların toplamının hesaplanmaması • Küçük payla yetinip yeterince istek almadan "sorun yok" sonucuna varmak • Veritabanı şemasını sürümler arası uyumsuz bırakmak; sürümler aynı veriyi okuyup yazıyorsa canary yalnızca kod değil veri uyumluluğunu da sınar • Oturum gerektiren uygulamalarda aynı kullanıcının sürümler arasında gidip gelmesi; kullanıcı deneyimini bozacaksa yönlendirmeyi kullanıcı bazında sabitlemeyi düşünün

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Canary ve ileri yönlendirme, sürekli teslimat süreçlerini yöneten platform mühendisleri, DevOps ekipleri ve yayın sorumluları için temel yetkinliktir. Sorun, yeni sürümün tüm kullanıcılara bir anda ulaşmasının getirdiği riskin kontrol altına alınmasıdır.

Istio ile Service Mesh Uygulamaları eğitiminde trafik yönetimi temelleri ve canary ile ileri yönlendirme senaryoları ayrı modüllerdir; hemen ardından dayanıklılık desenleri gelir. Böylece ekip, önce yönlendirme kurallarını kavrar, sonra bu kuralların hata anındaki davranışını çalışır.