İçeriğe Atla
Teknoloji · 9 dk okuma · görüntülenme
100%

Kubernetes ile Mikroservis Mimarisi

Kubernetes üzerinde mikroservis tasarlarken servis sınırları, trafik yönetimi, SLO ve platform sorumluluklarını birlikte ele alan pratik rehber.

Kubernetes üzerinde mikroservis mimarisini platform, servis sınırları ve gözlemlenebilirlik katmanlarıyla özetleyen kapak görseli

Kubernetes çoğu zaman “mikroservis platformu” diye düşünülür. Doğru; ama eksik. Kubernetes size bir orchestration düzlemi verir; mikroservisi başarılı yapan şey ise servis sınırları, trafik yönetimi, gözlemlenebilirlik ve operasyon disiplinidir.

Bu yazıda Kubernetes üzerinde mikroservis mimarisi kurarken, sahada en çok sorun çıkaran karar noktalarını ele alacağım: “servis nerede biter?”, “SLO nasıl tanımlanır?”, “platform ekibi neyi standardize etmelidir?” gibi.

Kubernetes üzerinde mikroservis mimarisini platform, servis sınırları ve gözlemlenebilirlik katmanlarıyla özetleyen kapak görseli
Kubernetes iskeleti verir; işletilebilirlik ise kas‑sinir sistemidir.

1) Servis sınırı: deployment unit değil domain boundary

En yaygın hata: Mikroservisi “ayrı deploy edilebilir parça” diye tanımlayıp sınırı teknik katmana göre çizmek.

Pratik tanım:

  • Mikroservis, tek bir iş yeteneğini sahiplenir
  • Kendi verisini yönetir (en azından ownership net)
  • Kendi SLO’suna göre işletilir

2) Minimum platform bileşenleri: standardize etmezseniz dağınıklık büyür

Sıfırdan kurulumda “minimum platform” seti:

  • Ingress/Gateway (L7 giriş)
  • Config/Secret yönetimi
  • Observability (log/metric/trace)
  • CI/CD + artifact registry
  • Policy/guardrail (PSA + OPA/Kyverno)

Platform ekibi bunları şablonlaştırırsa, servis ekipleri “işe” odaklanır.

3) Trafik yönetimi: timeout ve retry her servisin kaderini belirler

Distributed trafikte en sık kök neden: yanlış timeout/retry.

Minimum güvenli varsayılanlar:

  • Her çağrıda timeout
  • Retry budget + backoff
  • Outlier detection / circuit breaker (en azından edge’de)
  • Rate limit (public ve kritik iç servisler)

Mesh vs mesh‑siz tartışmasında kritik olan, bu politikaların tutarlılığıdır.

4) SLO ve error budget: mikroservisi gerçek yapan ölçüm

“Çalışıyor” demek, “SLO içinde” demektir:

  • Availability
  • Latency (p95/p99)
  • Error rate

Error budget yakılıyorsa deploy yavaşlatılır; budget sağlamsa hızlanılır. Bu ritim yoksa mikroservis, “çok parça çok problem”e dönüşür.

5) Kubernetes primitives: guardrail’leri zorunlu kıl

Benim minimum şablon maddelerim:

  • Resource requests/limits
  • Liveness/readiness probe
  • PDB (kritik servislerde)
  • HPA (doğru metrikle)
  • runAsNonRoot, readOnlyRootFilesystem, capabilities drop
  • Multi‑AZ yayılımı

Sonuç

Kubernetes mikroservisi mümkün kılar; ama başarı platform tasarımıyla gelir. Servis sınırını domain’e göre çizip trafik/SLO/guardrail standardını oturttuğunuzda mikroservis gerçekten ölçeklenir.

Paylaş:

Bu yazı faydalı oldu mu?

Yükleniyor...

Bu yazı nasıldı?

ME

Mustafa Erbay

Sistem Mimarisi · Network Uzmanı · Altyapı, Güvenlik ve Yazılım

2006'dan bu yana sistem mimarisi, network, sunucu altyapıları, büyük yapıların kurulumu, yazılım ve sistem güvenliği ekseninde çalışıyorum. Bu blogda sahada karşılığı olan teknik deneyimlerimi paylaşıyorum.

Kişisel Notlar

Bu notlar sadece sizde saklanır. Tarayıcınızda yerel olarak tutulur.

Hazır 0 karakter

Yorumlar

Sunucu Taraflı AI Moderasyon

Yorumlar sunucuda yapay zeka ile denetlenir ve kalıcı olarak saklanır.

?
0/2000

Sunucu taraflı AI denetim

Yeni yazılardan haberdar olun

Haftada bir yeni içerikler ve kaynaklar doğrudan e-postanıza gelsin.

Spam yok. Yalnızca yeni ve önemli içerikler için e-posta gönderilir.

Okuma İstatistikleriniz

0

Yazı Okundu

0dk

Okuma Süresi

0

Gün Serisi

-

Favori Kategori

İlgili Yazılar