Kubernetes Nedir? Docker Konteyner Orkestrasyonu ve Dağıtım Rehberi

Kubernetes nedir sorusu, modern mikroservis mimarilerine ve bulut bilişim dünyasına adım atan her geliştiricinin ve sistem yöneticisinin karşısına çıkan en kritik sorulardan biridir. Docker Nedir? Konteyner Teknolojisine Giriş başlıklı rehberimizde detaylıca ele aldığımız üzere, konteyner teknolojisi uygulamalarımızı bağımlılıklarıyla birlikte paketleyip her ortamda sorunsuz çalıştırmamızı sağlar. Ancak üretim ortamına geçildiğinde yüzlerce veya binlerce Docker konteynerinin yönetimi, ölçeklenmesi, yük dengelenmesi ve kesintisiz çalışması tek başına Docker CLI ile sürdürülemez bir hal alır. İşte bu noktada Google tarafından geliştirilen ve daha sonra Cloud Native Computing Foundation (CNCF) bünyesine devredilen açık kaynaklı konteyner orkestrasyon platformu Kubernetes (K8s) devreye girer. 2026 yılı itibarıyla bulut tabanlı hosting altyapılarının ve kurumsal sistemlerin standart işletim sistemi haline gelen Kubernetes, konteynerlerin dağıtımını, ölçeklenmesini ve yönetimini tamamen otomatikleştirir.

Bu rehberde Kubernetes mimarisini, Docker ile arasındaki ilişkiyi, ilk uygulamanızı canlıya alma adımlarını ve üretim ortamında karşılaşabileceğiniz kritik yapılandırma stratejilerini tüm ayrıntılarıyla inceleyeceğiz.

Kubernetes Nedir ve Mimarisi Nasıl Çalışır?

Kubernetes'in sunduğu yüksek erişilebilirlik ve otomatik iyileştirme mekanizmalarını doğru kullanabilmek için mimarisini derinlemesine anlamak şarttır. Bir Kubernetes cluster'ı (kümesi) temel olarak iki ana bileşenden oluşur: Control Plane (Yönetim Düzlemi) ve Worker Nodes (İşçi Düğümler).

1. Control Plane Bileşenleri

Control Plane, cluster'ın beyni konumundadır. Sistem durumunu takip eder, kararlar alır (örneğin pod'ların hangi sunucuda çalışacağını seçer) ve gelen tüm API taleplerini işler.

• kube-apiserver: Kubernetes’in dış dünya ile haberleşen kapısıdır. Tüm kubectl komutları, API istekleri ve node iletişimleri bu RESTful servis üzerinden geçer.
• etcd: Cluster’ın tüm durum ve yapılandırma verilerini tutan, yüksek erişilebilirliğe sahip, oldukça hızlı bir anahtar-değer (key-value) veri deposudur. etcd yedeklemesi, felaket kurtarma (disaster recovery) planlarının temelini oluşturur.
• kube-scheduler: Yeni oluşturulan Pod'ların hangi Worker Node üzerinde çalışacağını, kaynak gereksinimlerini (CPU/RAM) ve kısıtlamaları analiz ederek kararlaştırır.
• kube-controller-manager: Cluster durumunu sürekli izler. Örneğin bir pod çöktüğünde veya düğüm erişilemez olduğunda istenen durumu (desired state) korumak için yeni pod'lar başlatır.

2. Worker Node Bileşenleri

Uygulamalarınızın gerçek anlamda çalıştığı fiziksel veya sanal sunuculardır. Her Worker Node üzerinde şu bileşenler koşar:
• Kubelet: Control Plane ile iletişim kuran ve pod'ların konteyner runtime içerisinde belirtilen spesifikasyonlara uygun olarak sorunsuz çalışmasını sağlayan ana ajandır.
• Kube-Proxy: Ağ kurallarını yönetir. Pod'lara gelen trafiği yönlendirir ve servisler arası IP/Port bazlı yük dengelemesini sağlar.
• Container Runtime: Konteynerleri çalıştıran alt katmandır. Günümüz modern mimarilerinde standart olarak containerd veya CRI-O kullanılır.

3. Temel Kubernetes Objeleri

Kubernetes üzerinde bir yapı kurarken şu üç temel objeyi sıklıkla kullanırız:
• Pod: Kubernetes’in en küçük yapı taşıdır. Bir veya birkaç konteynerin aynı ağ IP’sini ve depolama alanını paylaştığı bir gruptur.
• Deployment: Pod’ların kaç kopya (replica) olarak çalışacağını, güncelleme stratejilerini (Rolling Update) ve sürüm geri almalarını (Rollback) yöneten üst seviye yapılandırma objesidir.
• Service: Dinamik olarak silinip yeniden oluşturulan Pod'lara sabit bir IP adresi ve DNS adı sağlayan ağ katmanıdır.

Docker ve Kubernetes İlişkisi: Hangisini Ne Zaman Tercih Etmelisiniz?

Yazılım dünyasında sıklıkla yapılan hatalardan biri Docker ile Kubernetes'i rakip teknolojiler olarak görmektir. Gerçekte bu iki teknoloji birbiriyle rekabet etmez, birbirini tamamlar. Docker Tabanlı Hosting Nedir? Modern Web Projeleri İçin Konteyner Rehberi içeriğimizde incelediğimiz gibi Docker konteynerleri paketler ve çalıştırır; Kubernetes ise bu konteynerleri yüzlerce sunucu üzerinde orkestre eder.

Kubernetes, konteynerleri çalıştırmak için bir runtime'a ihtiyaç duyar. Docker tarafından geliştirilen containerd, Kubernetes'in en yaygın kullandığı konteyner yürütücülerinden biridir.

Tek Başına Docker veya Docker Compose Yeterli mi?

Şu senaryolarda Kubernetes kullanmak aşırı mühendislik (over-engineering) olabilir:

• Tek bir sanal sunucuda çalışan monolithic veya küçük ölçekli web siteleri.
• Anlık yüksek trafik dalgalanması yaşamayan ve yatay ölçeklemeye ihtiyaç duymayan projeler.
• DevOps bütçesi ve ekibin bakım kapasitesi kısıtlı olan durumlar.

Ne Zaman Kubernetes Kullanmalısınız?

• Otomatik Ölçekleme (Autoscaling): Anlık trafik artışlarında Pod sayılarını (HPA - Horizontal Pod Autoscaler) ve sunucu sayılarını (Cluster Autoscaler) otomatik artırmak gerektiğinde.
• Kendi Kendini İyileştirme (Self-Healing): Çöken konteynerlerin saniyeler içinde otomatik olarak tekrar başlatılması ve yanıt vermeyen düğümlerdeki Pod'ların sağlıklı düğümlere taşınması istendiğinde.
• Kesintisiz Güncelleme (Zero-Downtime Deployment): Kullanıcılara hiçbir kesinti hissettirmeden günde onlarca yeni sürüm yayınlamak gerektiğinde.

Uygulamalı Rehber: İlk Kubernetes Uygulamanızı Yayına Alma

Bu bölümde, yerel geliştirme ortamınızda (minikube veya kind kullanarak) ya da bir cloud sağlayıcısında ilk uygulamanızı adım adım nasıl yayınlayacağınızı inceleyeceğiz.

Adım 1: Deployment Yapılandırması (deployment.yaml)

Aşağıdaki YAML dosyası, bir Nginx uygulamasını 3 adet kopya (replica) halinde yayına alır. Dosyada CPU ve RAM limitleri belirtilmiştir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Adım 2: Service Yapılandırması (service.yaml)

Oluşturduğumuz Pod'lara cluster içerisinden ve dışından erişebilmek için bir Service tanımı yapıyoruz:

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  type: ClusterIP
  selector:
    app: web-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Adım 3: CLI Üzerinden Dağıtımı Gerçekleştirme

Yapılandırma dosyalarınızı oluşturduktan sonra kubectl komut satırı aracı ile cluster üzerine uygulayın:

# Deployment ve Service objelerini uygulayın
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# Pod'ların durumunu doğrulayın
kubectl get pods -l app=web-app

# Servis detaylarını inceleyin
kubectl get svc web-app-service

Uygulamanız canlıya alındığında, herhangi bir Pod çökerse Kubernetes saniyeler içinde yeni bir Pod oluşturarak toplam kopya sayısını 3 seviyesinde tutacaktır. Bu süreci otomatiğe bağlamak için CI/CD Süreçleri Nedir? Modern Yazılım Dağıtım Rehberi içeriğimizdeki boru hatlarını kullanabilirsiniz.

Production Ortamında Kubernetes: En İyi Uygulamalar ve Sık Yapılan Hatalar

Üretim ortamında Kubernetes çalıştırırken yapılan yapılandırma hataları ciddi maliyet kayıplarına ve güvenlik ihlallerine yol açabilir. 2026 yılı standartlarında dikkat etmeniz gereken kritik noktalar şunlardır:

1. Resource Request ve Limit Tanımlarının İhmal Edilmesi

Pod'lara kaynak sınırı konulmadığında, hatalı kod yazılmış tek bir Pod sunucudaki tüm CPU ve RAM'i tüketebilir ("noisy neighbor" problemi). Bu durum aynı Node üzerindeki kritik servislerin çökmesine neden olur.
• Requests: Pod'un başlatılabilmesi için düğümde bulunması gereken minimum kaynaktır.
• Limits: Pod'un kullanabileceği maksimum kaynaktır. Aşılması durumunda konteyner OOMKilled (Out of Memory) hatası alarak yeniden başlatılır.

2. Sağlık Kontrollerinin (Health Checks) Eklenmemesi

Bir konteynerin durumunun Running olması, içerideki uygulamanın sağlıklı çalıştığı anlamına gelmez. Uygulamanız kilitlenmiş veya veritabanı bağlantısını kaybetmiş olabilir. Bu durumun önüne geçmek için Liveness ve Readiness probları mutlaka tanımlanmalıdır:

livenessProbe:
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

3. Hassas Bilgilerin Statik Saklanması

Veritabanı şifreleri, API anahtarları ve gizli anahtarlar asla Git repolarında veya Deployment dosyalarında düz metin olarak saklanmamalıdır. Kubernetes Secret objeleri kullanılmalı ve bu veriler etcd üzerinde şifrelenmelidir (Encryption at Rest).

4. Ingress Controller ve SSL Otomasyonu

Her servis için dışarıya ayrı bir IP açmak maliyetlidir. Üretim ortamlarında trafiği tek bir noktadan karşılamak için Nginx Ingress Controller veya Traefik gibi yapı çözümleri kullanılmalı, Let's Encrypt entegrasyonu için cert-manager kurulmalıdır.

Karar Kriterleri: Kubernetes Sizin İçin Doğru Tercih mi?

Altyapı kararlarınızı verirken aşağıdaki adımları göz önünde bulundurabilirsiniz:

Trafik Profili: Projeniz anlık olarak %300-%500 arası trafik dalgalanmaları yaşıyor mu? Yanıtınız evet ise Kubernetes HPA (Horizontal Pod Autoscaler) size ciddi maliyet avantajı sağlar.

Ekip Yetkinliği: Ekibinizde Linux, network kurguları, YAML yapılandırmaları ve troubleshooting konularında deneyimli DevOps uzmanları var mı? Yoksa yönetilen (Managed) Kubernetes çözümlerini (Google GKE, AWS EKS, Azure AKS vb.) tercih etmek riskleri azaltır.

Uygulama Mimarisi: Uygulamanız mikroservis mimarisinde mi yoksa tek parça (monolit) bir yapıda mı? Mikroservis yapıları Kubernetes üzerinde çok daha verimli yönetilir.

Sonuç

Kubernetes nedir sorusuna kısaca verilebilecek en net yanıt: Modern konteyner mimarilerinin orkestrasyon motoru ve bulut yerel (cloud-native) altyapıların vazgeçilmez işletim sistemidir. Docker ile paketlediğiniz konteynerleri üretim ortamında kesintisiz, güvenli ve otomatik ölçeklenebilir şekilde çalıştırmak istediğinizde Kubernetes sunduğu gelişmiş ekosistem ile en güçlü çözüm ortağınız olur.

Sonraki Adımınız: Yerel bilgisayarınıza minikube kurun. Rehberde paylaştığımız deployment.yaml ve service.yaml dosyalarını uygulayarak ilk uygulamanızı yayına alın. Ardından kubectl delete pod <pod-adi> komutuyla bir Pod'u silin ve Kubernetes'in silinen Pod yerine yenisini saniyeler içinde nasıl otomatik olarak başlattığını gözlemleyin.