Kubernetes nedir? Kurumsalda ne zaman gerekir?

"Kubernetes nedir?" sorusu, son birkaç yılda yalnızca yazılım ekiplerinin değil, BT yöneticileri ile ürün sahiplerinin de gündemine yerleşti. Bunun arkasında sadece popülerlik yok. Kurumsal uygulamalar artık daha sık yayın alıyor, birden fazla ortamda çalışıyor ve trafik dalgalanmalarına daha açık hale geliyor. Tek sunucuda çalışan klasik dağıtım modeli, 1 uygulama ve ayda 1 sürüm için yeterli olabilir. Ne var ki aynı yapı içinde 8 servis, günlük dağıtım ve eşzamanlı yüzlerce ya da binlerce kullanıcı olduğunda operasyonel yük çok hızlı büyür.

Kubernetes, konteynerleştirilmiş uygulamaları çalıştırmak, ölçeklemek ve yönetmek için kullanılan açık kaynaklı bir orkestrasyon platformudur. En yalın haliyle şu sorunu çözer: Birden fazla konteyneri, birden fazla sunucuda, kesintiyi azaltarak ve tekrarlanabilir şekilde nasıl yönetirsiniz? Buradaki kritik nokta şu: Her konteyner kullanan ekip Kubernetes’e ihtiyaç duymaz. Kurumsal tarafta asıl soru, “Kubernetes modern mi?” değil, “Bizim operasyonel karmaşıklığımız bu yatırımı haklı çıkarıyor mu?” olmalıdır.

Bu yazıda kubernetes nedir sorusunu teknik ama anlaşılır bir çerçevede ele alacağız. Sonrasında da kurumsal uygulamalarda hangi eşiklerden sonra konteyner yönetiminin gerekli hale geldiğini, hangi durumlarda ise daha hafif bir yaklaşımın yeterli kalacağını açıklayacağız.

Kubernetes nedir? Temel mantığı nasıl çalışır?

Kubernetes, konteynerleri tek tek çalıştıran bir araç değil; onları istenen duruma göre yöneten bir sistemdir. Geliştirici ya da operasyon ekibi sisteme “Bu uygulamadan 3 kopya çalışsın, 8080 portundan servis edilsin, biri düşerse yeniden ayağa kalksın” der. Kubernetes de bu hedef durumu korumaya çalışır. Bu yaklaşımın adı declarative model olarak geçer.

Temel bileşenler birkaç kavram etrafında şekillenir:

• Pod: Kubernetes içindeki en küçük dağıtım birimidir. Çoğu senaryoda 1 pod içinde 1 ana konteyner çalışır.
• Deployment: Uygulamanın kaç kopya çalışacağını ve güncellemenin nasıl yapılacağını tanımlar.
• Service: Pod’ların değişken IP’lerini soyutlar ve sabit bir erişim noktası sağlar.
• Ingress: HTTP/HTTPS trafiğini dış dünyadan içeri yönlendirir.
• ConfigMap ve Secret: Konfigürasyonun ve hassas verilerin imajdan ayrı yönetilmesini sağlar.

Kısa bir örnek faydalı olacaktır. Aşağıdaki YAML, 3 kopya çalışan basit bir web uygulamasını tanımlar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: example/web-app:1.0.0
          ports:
            - containerPort: 8080

Burada öne çıkan detay “replicas: 3” satırıdır. Bir pod kapanırsa Kubernetes yenisini planlamaya çalışır. Sunucu bakım için devre dışı bırakılırsa, uygun başka bir node üzerinde yeniden çalıştırabilir. İşin merkezinde yalnızca tek komutla dağıtım yapmak değil, dağıtımdan sonra beklenen durumu korumak da vardır.

Konteyner yönetimi neden klasik sunucu yönetiminden farklıdır?

Geleneksel modelde bir uygulama çoğu zaman tek ya da az sayıda sanal makineye kurulur. Sürüm geçişleri elle, script ile veya basit CI/CD adımlarıyla yapılabilir. 2 ortam, 1 veritabanı ve ayda birkaç dağıtım söz konusuysa bu model rahatlıkla iş görebilir.

Ancak tablo mikroservis ya da çoklu ortam yapısına kaydığında işler değişir. Diyelim ki kurum içinde 12 servis var. Her biri farklı imaj sürümüne sahip. Geliştirme, test, staging ve production olmak üzere 4 ortam kullanılıyor. Yalnızca sürüm kombinasyonları bile, elle yönetilmesi zor bir yapı oluşturur. Buna sağlık kontrolü, log toplama, servis keşfi, yatay ölçekleme ve rollback ihtiyacı da eklendiğinde sorun, sadece “uygulamayı çalıştırmak” olmaktan çıkar.

Konteyner yönetimi tam bu noktada devreye girer. Amaç, Docker komutlarını daha kurumsal bir yüzle tekrar etmek değildir. Asıl amaç şu başlıkları standartlaştırmaktır:

• Dağıtımların tekrarlanabilir olması
• Arıza anında otomatik iyileşme davranışı
• Ortamlar arası yapı farklarının azalması
• Kaynak kullanımının daha görünür ve kontrol edilebilir hale gelmesi

Örneğin bir e-ticaret sisteminde kampanya günü API trafiği normal günün 4 katına çıkabilir. Tek VM üzerinde çalışan bir uygulamada ölçekleme, çoğu zaman yeni sunucu açmayı, yük dengeleyici ayarını değiştirmeyi ve sürüm uyumluluğunu kontrol etmeyi gerektirir. Kubernetes tarafında ise doğru tasarlandıysa pod sayısını otomatik artırmak mümkün hale gelir. Elbette bunun anlamlı olması için uygulamanın stateless tasarlanmış olması ve veritabanı darboğazının çözülmüş bulunması gerekir. Kubernetes, tek başına mimari kusurları sihirli biçimde düzeltmez.

Kurumsal uygulamalarda Kubernetes ne zaman gerekir?

En kritik soru burada karşımıza çıkar. Her kurumun Kubernetes kurması gerekmez. Hatta bazı ekiplerde erken geçiş, faydadan çok operasyonel yük üretir. Gerçek ihtiyaç ise çoğunlukla belirli eşiklerde görünür hale gelir.

1. Servis sayısı arttığında

Monolitik tek uygulama ile 2-3 servislik yapı arasında ciddi fark vardır. Servis sayısı 6, 10 veya daha fazlasına çıktığında bağımlılık yönetimi, sürüm koordinasyonu ve çalışma düzeni zorlaşır. Her servis için ayrı dağıtım, sağlık kontrolü ve log akışı gerekir. Bu aşamada orkestrasyon katmanı anlam kazanmaya başlar.

2. Dağıtım sıklığı yükseldiğinde

Ayda 1 sürüm alan bir kurumsal portal ile günde birkaç kez yayın alan SaaS ürünü aynı operasyon modelini taşımaz. Haftada 10’dan fazla deployment yapan ekiplerde rollout, rollback ve otomasyon kalitesi doğrudan iş riskine dönüşür. Kubernetes bu süreci tek başına çözmez; fakat CI/CD ile birleştiğinde sürüm yönetimini daha güvenli hale getirir.

3. Yük dalgalanması belirginse

Çağrı merkezi entegrasyonu olan CRM, dönemsel sınav platformu, bayi sipariş sistemi veya kampanya odaklı B2B portal gibi yapılarda trafik sabit değildir. Gün içinde 5 kat artış yaşanan sistemlerde manuel ölçekleme yavaş kalır. Bu durumda otomatik ölçekleme teknik bir lüks değil, operasyonel bir gereklilik olabilir.

4. Yüksek erişilebilirlik hedefi varsa

“Bakım için gece kesinti yaparız” yaklaşımı bazı iç uygulamalarda hâlâ kabul edilebilir. Ancak 7/24 çalışan müşteri portalları, saha ekiplerinin kullandığı mobil backend servisleri ya da çok lokasyonlu ERP entegrasyon katmanında kesinti toleransı düşüktür. 1 pod yerine 2 veya 3 pod kopyası çalıştırmak, tek node arızasının etkisini azaltmak gibi ihtiyaçlar Kubernetes ile daha sistematik biçimde yönetilir.

5. Hibrit veya çoklu bulut yapısı gündemdeyse

Uygulamanın bir kısmı şirket içi veri merkezinde, bir kısmı da bulutta çalışıyorsa operasyon zorlaşır. Kubernetes, doğru kurulduğunda bu farklı çalışma ortamları arasında ortak bir soyutlama sağlar. Yine de burada dikkatli olmak gerekir; her hibrit yapı Kubernetes gerektirir demek doğru olmaz. Belirleyici olan, entegrasyon katmanının yoğunluğu ve taşınabilirlik ihtiyacıdır.

Hangi durumlarda Kubernetes gerekmeyebilir?

Bu bölüm çoğu zaman atlanır. Oysa doğru karar verebilmek için gereksiz kullanımı da netleştirmek gerekir.

Aşağıdaki senaryolarda Kubernetes aşırı yatırım olabilir:

• Tek uygulama, düşük trafik, yılda birkaç sürüm
• Küçük ekip: örneğin 2 geliştirici ve ayrı DevOps rolü yok
• Uygulama tek sunucuda stabil çalışıyor ve ölçek baskısı yok
• Stateful bağımlılıklar yoğun, konteynerleşme disiplini henüz oturmamış
• İzleme, loglama, secret yönetimi gibi temel operasyon süreçleri bile kurulmamış

Bir örnek verelim. İç kullanım için geliştirilen bir insan kaynakları uygulaması düşünün. 300 çalışan kullanıyor, eşzamanlı kullanıcı sayısı 20-30 bandında ve dağıtım ayda 1 kez yapılıyor. Böyle bir uygulamayı önce Docker + basit CI/CD + ters proxy ile olgunlaştırmak daha mantıklı olabilir. Kubernetes burada teknik olarak çalışır; ama bakım maliyeti faydanın önüne geçebilir.

Bir diğer pratik eşik de operasyon süresidir. Eğer küme kurulumunu, izlemeyi, yedeklemeyi, güvenlik yamalarını ve erişim modelini yönetebilecek kapasite yoksa sistem kısa sürede kırılgan hale gelir. Kubernetes kullanmak, operasyon sorumluluğunu azaltmaz; onu daha görünür ve daha disiplinli hale getirir.

Kurumsal geçişte yalnızca Kubernetes değil, çevresindeki ekosistem de önemlidir

Başarılı bir kurulum, yalnızca cluster açmakla tamamlanmaz. Kurumsal senaryoda en az 6 başlığın birlikte düşünülmesi gerekir: CI/CD, gözlemlenebilirlik, güvenlik, secret yönetimi, maliyet kontrolü ve yedekleme stratejisi.

Somut bir çerçeve çizelim. Production ortamında 15 servis çalıştıran bir şirket için yalnızca deployment manifest’leri yeterli değildir. Ekipler genelde şu bileşenleri de planlar:

• CI/CD: Git tabanlı pipeline, imaj üretimi, güvenlik taraması, otomatik dağıtım
• Monitoring: CPU, memory, restart sayısı, response time gibi metriklerin takibi
• Logging: Pod bazlı logların merkezi olarak toplanması
• Secret management: API anahtarları ve bağlantı bilgilerinin güvenli şekilde saklanması
• Policy ve erişim: RBAC, namespace ayrımı, servis hesabı yönetimi

Özellikle güvenlik tarafı küçümsenmemelidir. Yanlış tanımlanmış bir container image, root yetkisiyle çalışan pod ya da herkese açık bırakılmış dashboard ciddi risk yaratır. Kurumsal ortamda “çalışıyor olması” yeterli kabul edilmez; izlenebilir, denetlenebilir ve geri alınabilir olması gerekir.

Geçiş kararı nasıl verilmeli? Kısa bir değerlendirme modeli

Karar sürecini soyut bırakmamak için basit bir puanlama mantığı kullanılabilir. Aşağıdaki 5 sorunun her birine “evet” diyorsanız Kubernetes değerlendirmesi güç kazanır:

1. Production’da 5’ten fazla servis var mı?
2. Ayda 4’ten fazla sürüm alıyor musunuz?
3. Trafik gün içinde veya dönemsel olarak 3 kat ve üstü değişiyor mu?
4. Kesinti toleransı 1 saatten kısa mı?
5. Operasyon otomasyonu ve gözlemlenebilirlik için ayrılmış ekip kapasitesi var mı?

Bu 5 maddeden 4 veya 5 tanesi kurumunuz için doğruysa, Kubernetes ciddi bir adaydır. 0, 1 ya da 2 “evet” varsa önce daha sade çözümleri değerlendirmek daha sağlıklı olur. Aradaki gri alanda ise managed Kubernetes servisleri, küçük bir pilot proje ve sınırlı kapsamlı geçiş yaklaşımı öne çıkar.

Pilot proje için iyi bir hedef, kritik ama çekirdek olmayan bir servistir. Örneğin raporlama API’si veya doküman işleme servisi. İlk 6-8 haftada dağıtım süresi, rollback kolaylığı, kaynak tüketimi ve operasyon yükü ölçülür. Karar, moda akımlarına göre değil, bu gerçek veriler üzerinden verilir.

Sonuç: Kubernetes bir araçtır, ihtiyaç varsa güçlü bir araçtır

Kubernetes nedir sorusunun en doğru kısa cevabı şudur: Konteynerleştirilmiş uygulamaları ölçekli ve tekrarlanabilir biçimde yönetmeye yarayan bir orkestrasyon platformu. Kurumsal taraftaki değeri, çoklu servis yapısı, sık dağıtım, dalgalı trafik ve yüksek erişilebilirlik ihtiyacı arttıkça daha belirgin hale gelir.

Her uygulama için gerekli değildir. Küçük ekipler ve sade sistemler için daha hafif mimariler çoğu zaman daha verimlidir. Buna karşılık büyüyen ürünlerde, entegrasyon yoğun platformlarda ve operasyonel riskin yükseldiği yapılarda Kubernetes ciddi bir standartlaşma sağlar. Sağlıklı yaklaşım, teknoloji seçimini etiket değeriyle değil, iş yükünün gerçek karmaşıklığıyla eşleştirmektir.

Kurumsal uygulama yol haritasında doğru soru “Kubernetes kullanmalı mıyız?” değil, “Mevcut ölçeğimiz, sürüm hızımız ve erişilebilirlik hedefimiz hangi yönetim modelini gerektiriyor?” sorusudur. Net cevap da tam burada ortaya çıkar.