Kubernetes Pod Yönetimi ve Cluster Mimarisi Rehberi

Bu rehber, Kubernetes'e aşina olan ancak Pod yaşam döngüsünü ve cluster bileşenlerinin birbirini nasıl etkilediğini daha net anlamak isteyen geliştiriciler için hazırlandı. Örnekler kubectl ve YAML manifestoları üzerinden ilerler; komutları kendi cluster'ınızda doğrulamanız beklenir. Sürüm numarası vermiyorum; API davranışları sürüme göre değişebileceği için kullandığınız sürümün resmi dokümantasyonunu esas alın.

Önkoşullar

• Çalışan bir Kubernetes cluster'ına kubectl ile erişebiliyor olmanız.
• Namespace, Deployment, Service gibi temel kaynakları en az bir kez kullanmış olmanız.
• Manifesto dosyalarını düzenleyebileceğiniz bir editör.

Cluster Mimarisi: Kontrol Düzlemi ve İşçi Düğümler

Bir Kubernetes cluster'ı iki katmandan oluşur: kontrol düzlemi (control plane) ve işçi düğümler (worker nodes).

Kontrol düzlemi bileşenleri:

• kube-apiserver: Tüm isteklerin geçtiği merkez. kubectl de dahil her istemci bu API'ye konuşur.
• etcd: Cluster durumunun tutulduğu tutarlı anahtar-değer deposu.
• kube-scheduler: Yeni oluşturulan Pod'ları uygun bir düğüme atar.
• kube-controller-manager: ReplicaSet, Deployment, Node gibi denetleyicileri çalıştırır ve istenen durumu gerçek duruma yaklaştırır.

İşçi düğüm bileşenleri:

• kubelet: Düğümdeki Pod'ların tanımlandığı gibi çalışmasını sağlar.
• kube-proxy: Service soyutlaması için ağ yönlendirmesini yönetir.
• Container runtime: Konteynerleri gerçekten çalıştıran katman.

Bu ayrımın pratik sonucu şudur: bir Pod'un nereye yerleşeceğine scheduler karar verir, ancak gerçek durumu sürekli istenen duruma çeken şey denetleyicilerdir. Bu yüzden bir Pod'u elle silseniz bile, onu yöneten bir denetleyici varsa yenisi oluşturulur.

Pod Nedir, Ne Değildir

Pod, Kubernetes'in en küçük dağıtılabilir birimidir. Bir veya birden fazla konteyneri, paylaşılan ağ ve depolama bağlamıyla birlikte sarar.

Önemli noktalar:

• Aynı Pod içindeki konteynerler aynı ağ ad alanını paylaşır; localhost üzerinden birbirlerine erişebilirler.
• Pod'lar dayanıklı değildir. Silinir, yeniden oluşturulur, başka bir düğüme taşınabilir. Bu yüzden üretimde doğrudan Pod oluşturmak yerine genellikle Deployment, StatefulSet veya DaemonSet gibi denetleyiciler kullanılır.
• Bir Pod'a yeni bir konteyner "eklenmez". Pod tanımı değiştiğinde Pod yeniden oluşturulur.

Adım Adım: Pod Tanımlama ve Yönetme

1. Basit bir Pod manifestosu

apiVersion: v1
kind: Pod
metadata:
  name: ornek-pod
  labels:
    app: ornek
spec:
  containers:
    - name: uygulama
      image: nginx:alpine
      ports:
        - containerPort: 80

Beklenen davranış: kubectl apply -f pod.yaml sonrası scheduler Pod'u bir düğüme atar, kubelet imajı çeker ve konteyneri başlatır. kubectl get pod ornek-pod çıktısında Running durumunu görürsünüz. Bu Pod'un sahibi bir denetleyici olmadığı için silindiğinde yeniden oluşturulmaz.

2. Deployment ile yönetilen Pod'lar

Üretimde tercih edilen yaklaşım budur:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ornek-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ornek
  template:
    metadata:
      labels:
        app: ornek
    spec:
      containers:
        - name: uygulama
          image: nginx:alpine
          ports:
            - containerPort: 80

Beklenen davranış: ReplicaSet üç Pod oluşturur. Bir Pod silinirse denetleyici eksik kalanı tamamlar. selector.matchLabels ile template.metadata.labels uyuşmazsa Deployment Pod'ları yönetemez; bu en sık yapılan yapılandırma hatalarından biridir.

3. Pod durumunu okuma

kubectl get pods
kubectl describe pod ornek-pod
kubectl logs ornek-pod

describe çıktısı, bir Pod'un neden Pending veya CrashLoopBackOff durumunda kaldığını anlamak için ilk bakılacak yerdir. Events bölümü genellikle nedeni açıkça söyler.

4. Pod içinde komut çalıştırma

kubectl exec -it ornek-pod -- sh

Bu komut Pod içindeki konteynere etkileşimli bir kabuk açar. Konteyner içinde hata ayıklama için kullanışlıdır; ancak üretim ortamında bu erişimin kimlerle sınırlı olduğunu ayrıca değerlendirmek gerekir.

Yaşam Döngüsü ve Sağlık Kontrolleri

Pod'lar yaşam döngüsü boyunca farklı fazlardan geçer: Pending, Running, Succeeded, Failed, Unknown. Bu fazlar Pod'un genel durumunu anlatır; konteyner bazındaki durumlar ise Waiting, Running, Terminated olabilir.

Sağlık için iki temel kontrol vardır:

• livenessProbe: Başarısız olursa kubelet konteyneri yeniden başlatır.
• readinessProbe: Başarısız olduğu sürece Pod, Service'in trafik gönderdiği uç noktalara dahil edilmez.

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

Beklenen davranış: uygulama /healthz yanıtı vermediğinde konteyner yeniden başlatılır; /ready yanıtı gelmediğinde trafik bu Pod'a yönlendirilmez. Bu iki kontrolü karıştırmak yaygın bir hatadır; liveness için ağır bağımlılık kontrolleri koymak, geçici bir dış servis kesintisinde gereksiz yeniden başlatmalara yol açabilir.

Kaynak Yönetimi

Konteynerlere kaynak sınırı tanımlamak, bir Pod'un tüm düğümü tüketmesini engeller:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

requests scheduler'ın yerleştirme kararında kullanılır; limits ise üst sınırdır. Bellek limiti aşılırsa konteyner sonlandırılabilir (OOMKilled), CPU limiti aşılırsa konteyner kısılır. Bu davranış farkını bilmek, kaynak sorunlarını teşhis ederken işinizi kolaylaştırır.

Yaygın Hatalar

• Doğrudan Pod oluşturmak: Üretimde denetleyici kullanmamak, Pod silindiğinde hizmetin kaybolmasına yol açar.
• Etiket/selector uyuşmazlığı: Deployment veya Service beklediğiniz Pod'ları bulamaz.
• Readiness probe tanımlamamak: Hazır olmayan Pod'a trafik gider, kullanıcı hataları ortaya çıkar.
• latest etiketi kullanmak: Hangi imajın çalıştığı belirsizleşir; geri alma ve tekrarlanabilirlik zorlaşır.
• Kaynak sınırı koymamak: Tek bir Pod düğüm kaynaklarını tüketip diğer iş yüklerini etkileyebilir.

Güvenlik Etkileri

• Konteynerleri root olmayan kullanıcıyla çalıştırmak, bir kaçış durumunda etkiyi azaltır. securityContext ile runAsNonRoot ve runAsUser ayarlanabilir.
• Ayrıcalıklı (privileged) konteynerlerden kaçının; gerekli değilse allowPrivilegeEscalation: false ve salt okunur kök dosya sistemi (readOnlyRootFilesystem) değerlendirilebilir.
• NetworkPolicy ile Pod'lar arası trafiği varsayılan olarak kısıtlamak, yatay hareketi zorlaştırır.
• RBAC: kubectl exec ve Pod oluşturma yetkileri güçlü yetkilerdir; kimin hangi namespace'te ne yapabildiğini sınırlayın.
• İmajları güvenilir kaynaklardan çekin ve etiketleri sabitleyin.

Toparlarsak

Pod'lar Kubernetes'in temel yapı taşıdır ama tek başına dayanıklı değildir; onları denetleyicilerle yönetmek, sağlık kontrolleriyle izlemek ve kaynak sınırlarıyla korumak gerekir. Cluster mimarisini anlamak, bir Pod'un neden Pending kaldığından tutun da trafiğin neden yanlış Pod'a gittiğine kadar pek çok sorunu daha hızlı teşhis etmenizi sağlar.