Kubernetes Nedir?
Container Orkestrasyon Rehberi

Docker ile konteynerleri oluşturmayı ve çalıştırmayı öğrendiniz. Tek bir sunucuda birkaç konteyner yönetmek Docker Compose ile gayet rahat. Ama peki ya 50 sunucu üzerinde 500 konteyner çalıştırmanız gerekiyorsa? Bir konteyner çöktüğünde otomatik olarak yenisinin başlamasını, trafik artınca yeni konteynerler eklenmesini, güncelleme sırasında kesinti olmamasını istiyorsanız? Bu noktada sahneye Kubernetes çıkıyor.

Container Orkestrasyon Neden Gerekli?

Tek bir konteyneri çalıştırmak kolay. Düzinelerce servisten oluşan bir mikroservis mimarisini birden fazla sunucuda yönetmek ise bambaşka bir hikaye. Orkestrasyon olmadan şu sorularla başbaşa kalırsınız: Hangi konteyner hangi sunucuda çalışmalı? CPU ve bellek kaynakları nasıl dağıtılmalı? Bir sunucu çöktüğünde üzerindeki konteynerler nereye taşınmalı? Konteynerler birbirini nasıl bulmalı? Yeni bir versiyon nasıl kesintisiz deploy edilmeli?

Bu soruların her birini elle yönetmeye çalışmak, belirli bir ölçeğin üzerinde sürdürülebilir değil. Container orkestrasyon araçları tam da bu problemleri çözmek için geliştirildi ve Kubernetes bu alandaki açık standart haline geldi.

Kubernetes'in Kısa Tarihi

Kubernetes (kısaca K8s), Google'ın iç kullanım için geliştirdiği Borg ve Omega sistemlerinden esinlenerek 2014 yılında açık kaynak olarak yayınlandı. Google, on yılı aşkın süredir milyarlarca konteyneri bu şekilde yönetiyordu. Kubernetes, bu deneyimin kristalize edilmiş hali olarak düşünülebilir. 2015'te Cloud Native Computing Foundation'a (CNCF) devredildi ve bugün AWS, Microsoft, Google, Red Hat gibi devlerin yanı sıra binlerce katkıcı tarafından geliştirilmeye devam ediyor.

Adı Yunanca'da "kaptan" veya "dümenci" anlamına gelir. K ile s arasında 8 harf olduğu için kısaca K8s olarak da yazılır.

Kubernetes Mimarisi

Kubernetes, master-worker mimarisiyle çalışır. Bir K8s kümesi (cluster), en az bir control plane (master) node'u ve bir veya daha fazla worker node'dan oluşur. Bu bileşenleri tek tek inceleyelim.

Control Plane (Master Node)

Control plane, kümenin beynidir. Tüm kararları verir ama kendisi iş yükü çalıştırmaz. Birkaç kritik bileşenden oluşur:

• API Server: Kümeye yapılan tüm isteklerin giriş noktasıdır. kubectl komutları, dashboard arayüzü ve diğer bileşenler API Server üzerinden haberleşir.
• etcd: Kümenin tüm durum bilgisini saklayan dağıtık anahtar-değer veritabanıdır. Hangi pod nerede çalışıyor, hangi servisler tanımlı, hangi konfigürasyonlar aktif gibi tüm veriler burada tutulur.
• Scheduler: Yeni oluşturulan pod'ları uygun worker node'lara atar. Bu atamayı yaparken CPU, bellek, disk, ağ yakınlığı ve tanımlı kısıtlamaları dikkate alır.
• Controller Manager: Kümenin istenen durumla (desired state) mevcut durumu (current state) arasındaki farkları sürekli kontrol eder ve düzeltici aksiyonlar alır. Örneğin bir pod çöktüyse yenisini başlatır.

Worker Node

Worker node'lar, asıl iş yükünün çalıştığı makinelerdir. Her worker node şu bileşenlere sahiptir:

• kubelet: Node üzerindeki pod'ları yöneten agent. Control plane'den talimatları alır ve pod'ların istenen durumda çalışmasını sağlar.
• kube-proxy: Ağ kurallarını yöneten bileşen. Servisler arası iletişimi ve dış trafiğin doğru pod'a yönlendirilmesini sağlar.
• Container Runtime: Konteynerleri çalıştıran motor. Containerd veya CRI-O gibi runtime'lar kullanılır.

Temel Kubernetes Kavramları

Pod

Pod, Kubernetes'in en küçük deploy edilebilir birimidir. Bir pod, bir veya daha fazla konteyneri içerir ve bu konteynerler aynı ağ namespace'ini ve depolama alanını paylaşır. Pratikte çoğu pod tek bir konteyner içerir, ama yan konteynerler (sidecar) eklenmesi gereken durumlar da vardır. Örneğin, ana uygulama konteynerinin yanına log toplama veya proxy konteyneri eklenebilir.

# Basit bir pod tanımı
apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.25
      ports:
        - containerPort: 80
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

Deployment

Pod'ları doğrudan oluşturmak yerine genellikle Deployment kullanırız. Deployment, pod'ların istenen sayıda (replica) çalışmasını garanti eder. Bir pod çökerse otomatik olarak yenisi oluşturulur. Güncelleme yapılacağında rolling update stratejisiyle eski pod'lar kademeli olarak yenileriyle değiştirilir, böylece kesinti yaşanmaz.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myapp:v2
          ports:
            - containerPort: 3000

Yukarıdaki tanım, myapp:v2 image'ından 3 pod oluşturur ve sürekli 3 pod'un çalışır durumda olmasını sağlar. Image versiyonunu v3 olarak güncelleyip tekrar apply ettiğinizde, K8s eski pod'ları teker teker kapatıp yenilerini başlatır.

Service

Pod'lar geçicidir. Çöktüğünde yenisi farklı bir IP adresiyle oluşturulabilir. Service, pod'ların önüne sabit bir ağ kimliği koyar. Diğer servisler veya dış dünya, pod'ların IP adresini bilmek zorunda kalmaz; Service üzerinden erişir. Üç temel Service türü vardır:

• ClusterIP: Sadece küme içinden erişilebilir. Servisler arası iletişim için kullanılır.
• NodePort: Her node üzerinde bir port açar ve dışarıdan erişim sağlar. Genellikle geliştirme ortamlarında kullanılır.
• LoadBalancer: Bulut sağlayıcının load balancer'ını otomatik olarak oluşturur. Production'da en çok kullanılan türdür.

Namespace

Namespace, bir kümeyi mantıksal bölümlere ayırmanızı sağlar. Farklı ekiplerin, ortamların (dev, staging, production) veya projelerin aynı küme üzerinde izole şekilde çalışmasını mümkün kılar. Kaynak kotaları namespace bazında tanımlanabilir.

ConfigMap ve Seçret

Uygulama konfigürasyonlarını konteyner image'ından ayırmak önemlidir. ConfigMap, hassas olmayan konfigürasyon verilerini (environment değişkenleri, konfigürasyon dosyaları) tutarken, Seçret hassas verileri (şifreler, API anahtarları, sertifikalar) şifreli olarak saklar.

Managed Kubernetes: EKS, AKS, GKE

Kubernetes'i sıfırdan kurup yönetmek ciddi operasyonel yük getirir. Bu noktada bulut çözümleri hizmetlerimiz devreye girer. etcd yedekleme, control plane güncelleme, sertifika yönetimi, ağ yapılandırması gibi işler uzmanlık gerektirir. Bu yüzden büyük bulut sağlayıcılar, yönetilen (managed) Kubernetes servisleri sunar.

Amazon EKS (Elastic Kubernetes Service): AWS ekosistemiyle derin entegrasyon sağlar. IAM rolleri, ALB Ingress Controller, EBS/EFS depolama seçenekleri ile AWS'nin tüm servislerini doğal olarak kullanabilirsiniz. AWS üzerinde zaten altyapınız varsa en mantıklı tercih budur.

Azure AKS (Azure Kubernetes Service): Microsoft ekosistemiyle uyumluluk ön plandadır. Active Directory entegrasyonu, Azure DevOps pipeline'ları ve Azure Monitor ile sıkı entegrasyon sunar. .NET tabanlı uygulamalar ve Windows konteyner desteği gereken senaryolarda güçlü bir seçenek.

Google GKE (Google Kubernetes Engine): Kubernetes'in doğduğu yer olmanın avantajıyla en olgun managed servistir. Autopilot modu ile node yönetimini tamamen Google'a bırakabilirsiniz. GKE, yeni Kubernetes özelliklerini genellikle ilk destekleyen servis olma özelliğini taşır.

Her üçünde de control plane yönetimi, otomatik güncellemeler ve ölçeklendirme sağlayıcı tarafından yapılır. Siz sadece worker node'ları ve üzerindeki iş yüklerini yönetirsiniz.

Kubernetes Ne Zaman Gerekli, Ne Zaman Değil?

Kubernetes güçlü bir araç, ama her proje için doğru araç değil. K8s'i kullanmak mantıklı olan senaryoları ve daha basit alternatiflerin yeterli olacağı durumları netleştirelim.

Kubernetes kullanın: Düzinelerce mikroservisiniz varsa ve bunları bağımsız olarak ölçeklendirmeniz gerekiyorsa. Birden fazla takım aynı altyapı üzerinde çalışıyorsa. Yüksek erişilebilirlik (high availability) ve otomatik failover zorunluysa. Farklı ortamlar (dev, staging, production) arasında tutarlılık sağlamak istiyorsanız.

Daha basit alternatifler düşünün: Tek bir monolit uygulamanız varsa, Docker Compose veya doğrudan bir PaaS (Railway, Render, Fly.io) yeterli olabilir. Küçük bir ekipseniz ve operasyonel yükü karşılayacak DevOps deneyiminiz sınırlıysa, managed PaaS çözümleri daha az baş ağrısı çıkarır. Serverless fonksiyonlarla (AWS Lambda, Google Cloud Functions) çözülebilecek iş yükleri için K8s gereksiz karmaşıklık ekler.

Kubernetes'in öğrenme eğrisi dik, operasyonel maliyeti yüksek. Ama doğru senaryoda sağladığı esneklik ve ölçeklenebilirlik hiçbir alternatifle kıyaslanamaz.

Kubernetes'e Başlangıç İpuçları

K8s dünyasına adım atmak istiyorsanız, önerilen yol haritası şöyle:

Docker'ı iyi öğrenin. Kubernetes, konteyner teknolojisinin üzerine inşa edilmiştir. Dockerfile yazmayı, image oluşturmayı ve konteyner ağ yapısını anlamadan K8s'e geçmek çok zor olur.

Yerel ortamda deneyin. Minikube veya kind (Kubernetes in Docker) ile kendi makinenizde tek node'lu bir küme kurun. kubectl komutlarını öğrenin, basit deployment ve service tanımları yazın. Hata yapın, kırın, düzeltin.

YAML'a alışın. K8s'de neredeyse her şey YAML dosyalarıyla tanımlanır. Pod, Deployment, Service, ConfigMap, Ingress hepsi birer YAML manifestosu. Bu dosyaları versiyon kontrolünde tutmak, altyapınızı kod olarak (Infrastructure as Code) yönetmenizi sağlar.

Helm'i keşfedin. Helm, Kubernetes için bir paket yöneticisidir. Yaygın uygulamaları (PostgreSQL, Redis, Prometheus, Grafana) tek bir komutla kurmanızı sağlar. Kendi uygulamalarınız için de Helm chart'ları oluşturabilirsiniz.

Monitoring kurun. Prometheus + Grafana kombinasyonu, K8s ekosisteminin standart monitoring çözümüdür. Kümenizin sağlığını, pod'ların kaynak kullanımını ve uygulama metriklerini izlemeden production'a çıkmayın.

Kubernetes karmaşık bir ekosistem, ama adım adım öğrenildiğinde son derece güçlü bir araç. DevOps kültürü ve pratikleri ile birleştiğinde yazılım teslimat sürecinizi kökten dönüştürür. Konteyner orkestrasyon ihtiyaçınız varsa, K8s endüstri standardı olmaya devam ediyor ve yakın gelecekte bu durumun değişeceğine dair hiçbir işaret yok.