Istio ile retry, timeout ve circuit breaker nasıl yapılandırılır

Dayanıklılık desenleri neden mesh katmanında yönetilir?

Bir mikro hizmet zincirinde tek bir yavaş servis, onu çağıran herkesi bekletir; beklemeler birikir, iş parçacıkları tükenir ve sorun zincir boyunca yayılır. Bunu engelleyen temel savunmalar şunlardır: zaman aşımı (bir çağrının ne kadar bekleneceği), yeniden deneme (geçici hatalarda tekrar) ve devre kesici (sürekli hata veren ya da aşırı yüklenmiş hedeften korunma).

Bu desenleri her uygulama kendi kütüphanesiyle uyguladığında, diller ve ekipler arasında farklı davranışlar ortaya çıkar. Istio ise bunları sidecar vekil düzeyinde, yapılandırma ile tanımlamanıza izin verir. Aynı kural bir servise bağlı tüm istemcilere uygulanır, kod değişmez ve kuralın etkisi merkezden izlenebilir.

Bu desenler farklı kaynaklarda yaşar: zaman aşımı ve yeniden deneme VirtualService'in http kuralında, devre kesici ise DestinationRule'un trafik politikasında (connectionPool ve outlierDetection) tanımlanır.

Zaman aşımı: bir çağrıya ne kadar süre tanırsınız?

Zaman aşımı, bir isteğin yanıtı için ayrılan toplam süredir. Istio'da varsayılan olarak devre dışıdır; yani siz belirtmedikçe vekil çağrıyı sınırlamaz. Resmî referanstaki örnek:

http: - timeout: 5s route: - destination: host: productpage.prod.svc.cluster.local

Doğru değeri bulmak için çağrılan servisin gerçek gecikme dağılımına bakın. Ortalamaya değil, yavaş istekleri temsil eden üst dilimlere göre belirleyin; çok sıkı bir zaman aşımı sağlıklı ama yavaş çağrıları kesip hata sayısını yapay olarak artırır, çok gevşek bir zaman aşımı ise korumayı anlamsızlaştırır.

Zincirlerde zaman aşımı bütçesi düşünülmelidir: bir servis birden fazla aşağı servisi çağırıyorsa, kendi zaman aşımı aşağı servislerin toplam süresini ve yeniden denemelerini karşılayacak kadar uzun olmalıdır. Aksi halde üstteki istemci, alttaki çağrıların sonuçlanmasını beklemeden vazgeçer ve alttaki iş boşuna sürer.

Yeniden deneme: hangi hatada, kaç kez, nasıl?

Yeniden deneme, geçici hataları (kısa süreli bağlantı kopması, bir pod'un yeniden başlaması) kullanıcıya yansıtmadan atlatmanın yoludur. VirtualService'te şöyle tanımlanır (değerler kurguseldir):

http: - route: - destination: host: siparis retries: attempts: 3 perTryTimeout: 2s retryOn: "connect-failure,refused-stream,unavailable"

attempts, izin verilen tekrar sayısıdır; sıfır yapmak yeniden denemeyi kapatır. perTryTimeout, her denemenin süre sınırıdır. retryOn, hangi durumların yeniden denemeyi tetikleyeceğini virgülle ayrılmış koşullarla belirtir. Hiçbir şey belirtmezseniz Istio varsayılan bir politika uygular: bağlantı hatası, reddedilen akış, servis kullanılamaz ve iptal koşulları yeniden denenir. Varsayılan politika, mesh geneli ayarlarla değiştirilebilir.

Yeniden denemenin tehlikesi büyütmedir: sorunlu bir servise gelen her istek birkaç kez tekrarlanırsa yük zaten zorlanan hedefin üzerine biner. Tekrarı yalnızca geçici hata koşullarıyla sınırlayın ve toplam süreyi (deneme sayısı çarpı deneme başına süre) zaman aşımınızın içinde tutun. Bir de idempotency konusu vardır: yan etkisi olan, tekrarı güvenli olmayan bir işlemi (örneğin ödeme) körü körüne yeniden denemek çift işleme yol açar. O tür uç noktalarda önce tekrar güvenliğini sağlayın.

Devre kesici: DestinationRule ile bağlantı limiti ve aykırı uç tespiti

Devre kesici birbirinden ayrı mekanizmalar içerir. Bağlantı havuzu sınırları (connectionPool), hedefe aynı anda açılabilecek bağlantı ve bekleyen istek sayısını sınırlar; sınır aşıldığında fazla istekler hızla reddedilir. Aykırı uç tespiti (outlierDetection) ise art arda hata veren pod'ları geçici olarak yük dengeleme havuzundan çıkarır. Resmî görevdeki örnek şöyledir:

apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: httpbin spec: host: httpbin trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100

Dikkat: Bu değerler devre kesicinin davranışını göstermek için bilerek çok düşük tutulmuştur. Üretimde kendi trafiğinizin gerçek eşzamanlılığına göre ayarlanır; çok sıkı bir limit sağlıklı yükte bile istekleri reddeder. Görevde belirtildiği gibi, limitten fazla eşzamanlı bağlantı ve istek gönderdiğinizde bazı isteklerin başarısız olduğunu görmeniz beklenen davranıştır. Karşılıklı TLS etkinse politikaya ISTIO_MUTUAL modunu eklememek 503 hatalarına yol açabilir.

Desenleri birlikte nasıl kurgularsınız? Örnek senaryo

Örneğin kurgusal bir sipariş servisi, stok servisini çağırıyor. Stok servisinin bir pod'u yavaşlıyor ve zaman zaman hata veriyor. Birlikte çalışan bir kurgu şöyle olur: • Stok servisinin DestinationRule'unda aykırı uç tespiti, art arda hata veren pod'u havuzdan kısa süreliğine çıkarır • Bağlantı havuzu sınırı, stok servisine aşırı eşzamanlı yük binmesini engeller • Sipariş servisi tarafındaki VirtualService, geçici hatalarda sınırlı sayıda yeniden deneme yapar ve her denemeye süre sınırı koyar • Toplam zaman aşımı, kullanıcının bekleyebileceği süreye göre belirlenir

Sonuç: Bir pod'un sorunu kullanıcıya yansımadan atlatılır; sorun yaygınsa hızlı ve net hata döner. Hızlı hata, yığılan bekleyen isteklerden daha iyidir, çünkü üst servis alternatif davranış (örneğin önbellekten yanıt) seçebilir.

Bu kuralları canlıya almadan önce test edin: yük üreten bir istemciyle eşzamanlı istek gönderip limitin devreye girdiğini, bir pod'u bilerek bozarak aykırı uç tespitinin onu havuzdan çıkardığını doğrulayın.

Sık yapılan hatalar

• Yeniden deneme koşullarını gereğinden geniş tutmak; her hata tekrarlanınca yük büyür
• Toplam süre hesabını yapmamak; yeniden denemeler zaman aşımını aşar ve istek zaten vazgeçilmiş olur
• Resmî örnekteki test değerlerini üretime kopyalamak
• Devre kesiciyi kurup izlememek; limit aşımı ve havuzdan çıkarma olaylarını gösteren metrikler olmadan davranışı yorumlayamazsınız
• Aykırı uç tespitinde tüm pod'ları çıkarabilecek bir üst sınır bırakmak; hizmetin tamamen durmasına neden olabilir
• mTLS açıkken TLS modunu belirtmeyi unutmak
• Uygulamanın kendi kütüphanesindeki yeniden denemeyi mesh kuralıyla birleştirip çarpan etkisi yaratmak; hem uygulama hem mesh katmanı deniyorsa toplam deneme sayısı katlanır

Bir kural değişikliğinde tek bir ayarı değiştirip sonucu gözlemlemek, hatanın kaynağını ayırt etmeyi kolaylaştırır.

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

Dayanıklılık desenleri, kesintisiz çalışması beklenen servisleri işleten platform ve güvenilirlik ekipleri için gündelik iştir. Çözülen sorun, tek bir bileşenin arızasının tüm sistemi etkilemesini önlemektir.

Istio ile Service Mesh Uygulamaları eğitiminde dayanıklılık desenleri ayrı bir modüldür; öncesinde trafik yönetimi ve canary, sonrasında güvenlik, mTLS ve gözlemlenebilirlik modülleri bulunur. Ekipler, bu sırayla kendi servis zincirlerinden birini seçip zaman aşımı, yeniden deneme ve devre kesici ayarlarını deneyebilir.