Kubernetes Mülakat Rehberi: Pods, Services ve Deployments Detaylı Anlatım

Kubernetes mülakat soruları genellikle üç temel nesne üzerine yoğunlaşıyor: Pod, Service ve Deployment. Bu üç yapının birbirleriyle nasıl etkileştiği -- konteyner zamanlama mekanizmalarından ağ yönlendirmesine, kesintisiz güncellemelerden otomatik ölçeklendirmeye kadar -- tanımları ezberleyen adaylar ile üretim ortamlarını tasarlayabilecek adaylar arasındaki farkı ortaya koyuyor.

Bu rehber, her bir Kubernetes ilkelini üretim ortamına uygun YAML örnekleriyle ele alıyor, mülakatlarda önem verilen iç mekanizmaları açıklıyor ve DevOps ile platform mühendisliği görüşmelerinde sıklıkla karşılaşılan soruları kapsıyor.

Kubernetes Pod Yapısı: En Küçük Dağıtılabilir Birim

Pod, Kubernetes'te zamanlama işlemlerinin atomik birimidir. Aynı ağ ad alanı, IPC ad alanı ve depolama birimlerini paylaşan bir veya daha fazla konteyneri saran bir yapıdır. Pod içindeki her konteyner aynı IP adresini alır ve kardeş konteynerlerle localhost üzerinden iletişim kurabilir.

Tek konteyner içeren Pod, en yaygın kullanım örüntüsüdür. Çoklu konteyner içeren Pod'lar ise sidecar senaryoları için tercih edilir: log toplayıcılar, service mesh yapıları veya ana süreç başlamadan önce dosya sistemini hazırlayan init konteynerleri bunlara örnek gösterilebilir.

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

resources bloğu mülakatlarda kritik bir konudur. requests değerleri zamanlama kararlarını belirler: zamanlayıcı, Pod'u yeterli kapasiteye sahip bir node üzerine yerleştirir. limits ise çalışma zamanında tavan değerlerini uygular: bellek sınırının aşılması OOMKill'i tetiklerken, CPU sınırının aşılması throttling'e neden olur.

Pod Yaşam Döngüsü Aşamaları ve Yeniden Başlatma Politikaları

Kubernetes her Pod'u beş aşamada izler: Pending, Running, Succeeded, Failed ve Unknown. Mülakat yapan kişiler genellikle her geçişi neyin tetiklediğini sorar.

| Aşama | Anlamı | Yaygın Neden | |-------|--------|-------------| | Pending | Zamanlanmış ama çalışmıyor | Image çekme, yetersiz kaynak | | Running | En az bir konteyner aktif | Normal çalışma | | Succeeded | Tüm konteynerler 0 ile çıktı | Batch işler, init konteynerler | | Failed | En az bir konteyner sıfır olmayan kodla çıktı | Uygulama çökmeleri, OOMKill | | Unknown | Node ile iletişim kesildi | Ağ bölünmesi, node arızası |

restartPolicy alanı, bir konteyner çıktıktan sonra ne olacağını kontrol eder. Always (Deployment'ların varsayılanı) çıkış kodundan bağımsız olarak yeniden başlatır. OnFailure yalnızca sıfır olmayan çıkışlarda yeniden başlatır ve Job'lar için idealdir. Never ise konteynerin kapalı kalmasına izin verir ve tek seferlik debug Pod'ları için kullanılır.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

valueFrom.secretKeyRef örüntüsü, hassas verileri manifest dosyasından uzak tutar. Kubernetes Secret'ları varsayılan olarak base64 kodlanmıştır, şifrelenmemiştir. Üretim ortamları için EncryptionConfiguration API'si üzerinden dinlenme sırasında şifreleme etkinleştirilmeli veya HashiCorp Vault gibi harici bir secret yöneticisi kullanılmalıdır.

Kubernetes Deployment: Bildirimsel Dağıtım ve Ölçeklendirme

Bir Deployment, ReplicaSet'leri oluşturur ve yönetir; ReplicaSet'ler ise Pod'ları yönetir. Deployment denetleyicisi istenen durumu izler ve gerçeklikle uzlaştırır: ölçekleme sırasında yeni Pod'lar ekler, dağıtım süreçlerinde onları değiştirir ve sağlık kontrolleri başarısız olduğunda geri alım yapar.

Doğrudan Pod oluşturma, üretim ortamlarında neredeyse hiçbir zaman uygun değildir. Deployment'lar replika yönetimi, kesintisiz güncellemeler, geri alım geçmişi ve duraklat/devam et yetenekleri sunar.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

strategy.rollingUpdate bölümü, kesintisiz dağıtım davranışını tanımlar. maxUnavailable: 1 ve maxSurge: 1 ayarlarıyla Kubernetes bir yeni Pod oluşturur, readiness kontrollerini geçmesini bekler ve ardından bir eski Pod'u sonlandırır. Bu döngü, tüm replikalar yeni sürümü çalıştırana kadar tekrarlanır.

Başarısız Bir Kubernetes Deployment'ını Geri Alma

Geri alım işlemleri, mülakatlarda en sık sorulan konulardan biridir. Deployment denetleyicisi eski ReplicaSet'leri saklar (revisionHistoryLimit ile kontrol edilir), böylece geri alım anlık gerçekleşir ve yeniden image oluşturmaya gerek kalmaz.

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

undo komutu, Deployment spec'ini hedef revizyonun Pod template'ine uyacak şekilde yamalar. Ardından rolling update stratejisi her zamanki gibi uygulanır ve mevcut Pod'lar kademeli olarak geri alım sürümündekilere değiştirilir.

Kubernetes Service: Dinamik Pod'lar İçin Sabit Ağ Altyapısı

Pod'lar geçicidir. Her yeniden başlatmada yeni IP adresleri alırlar. Bir Service, sabit bir sanal IP (ClusterIP) ve DNS adı sağlayarak trafiği etiket seçicisiyle eşleşen sağlıklı Pod'lara yönlendirir.

Her node üzerindeki kube-proxy bileşeni, iptables veya IPVS kurallarını programlayarak trafiği arka uç Pod'larına dağıtır. Bir Pod readiness probe'unu geçemediğinde, Endpoints denetleyicisi o Pod'u Service'den kaldırır ve sağlıksız örneklere trafik ulaşmaz.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Service oluşturulduktan sonra, kümedeki herhangi bir Pod bu Service'e api-service.default.svc.cluster.local adresiyle (veya aynı namespace içinde yalnızca api-service olarak) ulaşabilir. CoreDNS, ad çözümlemesini yönetir.

Service Türleri: ClusterIP, NodePort ve LoadBalancer

Mülakat yapan kişiler, adaylardan üç ana Service türünü ve her birinin ne zaman uygun olduğunu açıklamasını bekler.

| Tür | Erişim Kapsamı | Kullanım Alanı | |-----|---------------|----------------| | ClusterIP | Yalnızca küme içi | Backend API'ler, veritabanları, önbellekler | | NodePort | Dış erişim: <NodeIP>:<Port> | Geliştirme, bare-metal kümeler | | LoadBalancer | Bulut sağlayıcı LB ile dış erişim | AWS/GCP/Azure üzerinde üretim trafiği |

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

LoadBalancer türü, bulut sağlayıcının yük dengeleyici denetleyicisini tetikleyerek harici bir uç noktası oluşturur. AWS üzerinde annotasyonlara bağlı olarak NLB veya ALB oluşturulur. Bulut entegrasyonu olmayan bare-metal kümelerde bu rolü MetalLB veya kube-vip üstlenir.

Deployment ve Service Arasındaki Bağlantı: Etiket Seçicileri

Bir Deployment ile bir Service arasındaki bağlantı yalnızca etiket seçicisidir, başka bir şey değil. İki nesne arasında açık bir referans bulunmaz. Service, spec.selector ile eşleşen etiketlere sahip Pod'ları izler ve otomatik olarak bir Endpoints listesi tutar.

Bu bağlantısız (decoupled) mimari, tek bir Service'in birden fazla Deployment'tan gelen Pod'lara trafik yönlendirmesine (canary dağıtımlar için faydalı) ve bir Deployment'ın birden fazla Service tarafından sunulmasına (farklı portlar, farklı erişim seviyeleri) olanak tanır.

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Ana Deployment 3 replika, canary ise 1 replika çalıştırdığında, Service trafiğin yaklaşık yüzde yirmi beşini canary'ye dağıtır. Herhangi bir Service yapılandırma değişikliği gerekmez; etiket eşlemesi her şeyi otomatik olarak halleder.

Kubernetes Deployment'ları İçin Yatay Pod Otomatik Ölçeklendirme

Sabit replika sayıları, düşük trafik dönemlerinde kaynak israfına yol açarken, ani artışlarda sistemin tökezlemesine neden olur. HorizontalPodAutoscaler (HPA), gözlemlenen metriklere dayanarak replika sayısını dinamik olarak ayarlar.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

HPA, varsayılan olarak her 15 saniyede bir metrics sunucusunu sorgular. Kubernetes v1.35 ile yapılandırılabilir HPA toleransı tanıtıldı ve sabit kodlanmış yüzde on eşiği kaldırıldı. Bu sayede gecikmeye duyarlı iş yüklerini çalıştıran ekipler, daha hassas ölçekleme tetikleyicileri belirleyebiliyor.

behavior.scaleDown.stabilizationWindowSeconds ayarı, flapping'i (ani trafik örüntülerinin neden olduğu hızlı ölçekleme yukarı/aşağı döngüleri) önler.

Sık Sorulan Kubernetes Mülakat Soruları ve Yanıtları

Bu sorular DevOps ve platform mühendisliği mülakatlarında sürekli karşımıza çıkar. Her yanıt, mülakat yapanların beklediği derinlikte hazırlanmıştır.

Bir Pod bellek limitini aştığında ne olur? Kubelet, OOM killer aracılığıyla SIGKILL sinyali gönderir. Konteyner 137 çıkış koduyla sonlanır. Deployment denetleyicisi başarısız Pod'u algılar ve yeniden başlatma politikası ile geri çekilme gecikmelerine tabi olarak yerine yenisini oluşturur.

Canary dağıtımlarda Kubernetes trafiği belirli bir Pod sürümüne nasıl yönlendirir? Service seçicisi paylaşılan etiketler üzerinden eşleme yapar (örneğin app: api). Hem kararlı (stable) hem de canary Deployment'ları bu etiketi kullanır. Trafik dağıtımı, hazır uç nokta sayısıyla orantılıdır: 3 kararlı replika + 1 canary replika, yaklaşık yüzde yirmi beş canary trafiği anlamına gelir. Hassas trafik bölme (örneğin yüzde beş) için Gateway API HTTPRoute ile ağırlıklı backend'ler kullanılır.

readinessProbe ile livenessProbe arasındaki fark nedir? Readiness probe, Pod'un Service'den trafik alıp almayacağını kontrol eder. Başarısız bir readiness probe, Pod'u Endpoints listesinden çıkarır ancak yeniden başlatmaz. Liveness probe ise konteynerin yeniden başlatılıp başlatılmayacağını kontrol eder. Başarısız bir liveness probe, konteyner yeniden başlatmasını tetikler. Her ikisi de HTTP, TCP veya exec kontrolleri kullanabilir.

Rolling update'ler kesintisiz çalışmayı nasıl garanti eder? Deployment denetleyicisi, maxSurge ve maxUnavailable parametreleriyle yönetilerek eski Pod'ları sonlandırmadan önce yeni Pod'lar oluşturur. Yeni Pod'lar, eski Pod'lar tahliye edilmeden önce readiness probe'larını geçmelidir. terminationGracePeriodSeconds (varsayılan: 30 saniye), devam eden isteklerin SIGKILL öncesinde tamamlanması için zaman tanır.

Kubernetes mülakatına hazırlanmak, salt teori değil uygulamalı YAML çalışması gerektirir. SharpSkill üzerindeki DevOps mülakat soruları bu konuları interaktif alıştırmalarla kapsar.

Sonuç

• Pod'lar zamanlama birimidir; her zaman requests ve limits kaynak değerleri belirlenmeli, hem readiness hem de liveness probe'ları yapılandırılmalıdır
• Deployment'lar replika sayısını, rolling update'leri ve geri alım geçmişini ReplicaSet'ler aracılığıyla yönetir; üretim ortamında asla doğrudan Pod oluşturulmamalıdır
• Service'ler etiket seçicileri ve sanal IP'ler aracılığıyla sabit ağ altyapısı sağlar: dahili trafik için ClusterIP, harici trafik için LoadBalancer kullanılır
• Deployment ile Service arasındaki bağlantı tamamen etiket tabanlıdır ve yapılandırma değişikliği gerektirmeden canary örüntülerine olanak tanır
• HPA, CPU ve bellek metriklerine dayanarak Deployment'ları ölçeklendirir; flapping'i önlemek için stabilizationWindowSeconds kullanılır
• Gateway API, Kubernetes v1.35 itibarıyla Ingress NGINX'in yerini almıştır ve yeni projeler başından itibaren bunu benimsemelidir
• Tanımları ezberlemek yerine gerçek YAML manifest'leri ve kubectl komutlarıyla pratik yapılmalıdır