Ne yapıyoruz?
Kubernetes, modern altyapının bel kemiği hâline geldi — esnek, ölçeklenebilir ve otomasyon odaklı yapısıyla uygulamaları yönetmemize olanak sağlayan güçlü bir orkestrasyon motoru.
Ancak zaman içinde birçok ekip Kubernetes’i her şeyin koştuğu bir çok amaçlı platforma dönüştürdü. Logging mi? Koy K8s’e. Database mi? Koy K8s’e. Security aracı mı? Tabiiki K8s’e. Monitoring mi? Evet, onu da ekle…
Sonuç?
Karmaşık, kırılgan, yavaşlayan, upgrade edilmesi zor ve yönetmesi eziyet olan Kubernetes cluster’ları.
Daha iyisi nasıl mümkün?
İşin temeli basit ama etkili bir felsefe.
Bu Felsefe
Kubernetes’i sade tut. Onu, en iyi yaptığı işte kullan — stateless workload’ları çalıştırmak — ve diğer her şeyi dışarı at.
Bu da şu fonksiyonların cluster dışına taşınması anlamına geliyor:
- Storage
- Logging & log pipeline’ları
- Metrics sistemleri
- Security tarayıcıları
- Database workload’ları
- Ağ (networking) karmaşıklığı
- Her türlü stateful veya operasyonel olarak ağır bileşenler
Bunlar clusterdan çıkarıldığında Kubernetes çok daha hafif, öngörülebilir ve son derece stabil hâle gelir.
Bu yaklaşım Kubernetes karşlığı bilakis Kubernetes’i olması gerektiği gibi kullanmayı savunur.
Neden Kubernetes’te Basitlik Dostunuzdur?
1) Basit cluster’lar daha öngörülebilir davranır
Kubernetes kontrol katmanı (control plane), node üzerindeki fazla yükten kolayca etkilenir. Log collector’lar, service mesh sidecar’ları, operator’lar, proxy’ler, sürekli çalışan CRD’ler… hepsi ilave yük getirir.
2) Upgrade çok daha kolay olur
Bulut servis sağlayıcıları tarafından yönetilen cluster’ları bile upgrade etmek özellikle API değişimlerinde bas ağrısı haline gelir. Daha az bağımlılık ve daha az CRD, daha düşük risk ve çok daha kolay bir upgrade süreci demektir.
3)Troubleshooting çok daha hızlı yapılabilir
Sade bir cluster, karmaşayı azaltır ve problemin gerçek kaynağını bulmayı çok kolaylaştırır.
4) Ekipler daha hızlı üretir
Geliştiriciler platformla savaşmak yerine değer üretmeye odaklanır.
5) Daha az kesinti, daha düşük risk
Basit sistemlerin daha az hassas noktası vardır.
Ekiplerin Yaptığı Yaygın Hatalar
Hata 1: Elasticsearch, Loki, Kafka gibi ağır stateful sistemlerin Kubernetes’e gömülmesi
Bu sistemlerin depolama IOPS’una, düşük gecikmeye ve özel yönetim dikkatine ihtiyacı vardır — uygulama cluster’ı ile aynı yerde olmaları büyük risk yaratır.
Hata 2: Application cluster’ında tam log pipeline’ı çalıştırmak
Fluentd/FluentBit gibi DaemonSet’ler CPU tüketir, log depolamak ise storage yükünü artırır.
Hata 3: Monitoring stack’lerini (Prometheus, Grafana, Loki) Application cluster’ında çalıştırmak
Metrics toplama çoğu zaman uygulamalardan bile daha fazla kaynak tüketir.
Hata 4: Default olarak service mesh kullanmak
Envoy sidecar’ı çoğu zaman uygulamanızdan daha fazla CPU tüketebilir.
Hata 5: Kubernetes’i database platformu olarak görmek
StatefulSet’ler bunun kolayca yapilabilecegini hissterrir ama failover, node drain, disk migration aşamalarında gerçek sorunlar ortaya çıkar. Cicim aylari bittikten sonra mevcut altyapıyı değiştirmek işkenceye döner.
Hata 6: Tüm şirket araçlarını tek bir kümeye doldurmak
CI runner’lar, güvenlik araçları, operatörler, logging, monitoring, DB’ler… hepsi bir araya geldiğinde küme “çöp kutusuna” döner ve artık K8s kabus olmaya baslar.
Daha İyi Bir Kubernetes Tasarımı İçin Seçenekler
Aşağıda bu felsefeye uygun iki temel mimari yaklaşım bulunuyor.
Seçenek A: Managed Service’ler ve SaaS Kullanmak
Kubernetes Clusterı İçinde:
Sadece uygulamalarınız (microservice’ler) bulunur. Diğer tüm servisler ve ağır bileşenlerle vedalaşılır.
Kubernetes Dışında (Managed Service veya SaaS):
- Logs → CloudWatch, Datadog, Elastic Cloud
- Metrics → Managed Prometheus, Grafana Cloud
- Dashboards → Grafana SaaS
- Search → AWS OpenSearch Service
- Databases → RDS / Aurora / DynamoDB
- Secrets → AWS Secrets Manager / Vault (external)
- Traces → Managed tracing çözümleri
Bu modelde kümeler hafiftir, hızlıdır ve minimum operasyon gerektirir. Bu managed servislerin getireceği ilave masraf en büyük dezavantajdır.
Seçenek B: Araçlar, Logging ve Monitoring İçin İkinci Bir Kubernetes Kümesi Kurmak
Büyük organizasyonlarda veya full SaaS kullanamayan ekiplerde oldukça yaygındır.
1. Application Cluster
Burada şunlar çalışır:
- Microservice’ler
- API workload’ları
- CronJob’lar
- Ingress’ler
- Çok hafif sidecar’lar
Bu kümeler stateless, sade ve ölçeklemesi kolaydır.
2. Platform / Observability / Tooling Cluster
Bu cluster genelde şunları içerir:
- Prometheus
- Alertmanager
- Grafana
- Loki / Tempo / Jaeger
- Logging pipeline (FluentBit, Vector)
- Vault
- CI runner’lar
- ArgoCD / GitOps araçları
- Service Mesh control-plane
Neden mantıklı?
- Ağır araçlar uygulama cluster’larını boğmaz
- Observability arızası uygulamaları etkilemez
- Farklı ölçek ihtiyaçları ayrı kümelerde çözülür
- Güvenlik izolasyonu artar
- Uygulama cluster’ı sade, küçük ve hızlı kalır
Bu model, “SaaS kullanmak istemiyorum ama uygulama cluster’ını da şişirmek istemiyorum” diyen ekipler için idealdir.
Sonuç
Basitlik bir eksiklik değildir — bir avantajdır.
Sorumlulukları azaltılmış bir Kubernetes cluster’ı:
- daha güvenilir,
- daha kolay ölçeklenen,
- daha rahat upgrade edilebilen,
- yazılım mühendisler için daha anlaşılır,
- çok daha sade bir mimariye sahip olur.
İster managed service, ister ayrı bir observability kümesi, ister ikisinin birleşimi olsun:
Önemli olan şudur:
Kubernetes’i en iyi yaptığı işe odaklayın — stateless workload’ları çalıştırmak.
Basit Kubernetes = Güçlü Kubernetes.
Örnek: Minimalist Mimari
Application Cluster
- Sadece microservice’ler
- Stateful workload yok
- Operatör karmaşası yok
- Hafif ve sade bir yapı
Observability / Tooling Cluster
- Prometheus
- Grafana
- Loki/ELK
- Jenkins/ArgoCD
- Vault
- CI runner’lar
- İç proxy’ler
Managed Service’ler
- RDS / Aurora
- DynamoDB
- ElasticSearch / OpenSearch
- CloudWatch Logs
- Secrets Manager
Bu mimari; modüler, ölçeklenebilir, bakımı kolay ve güvenilir Kubernetes platformları tasarlamanızı sağlar.
