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

> Kubernetes mülakatlarında Pods, Services ve Deployments konularında sorulan sorular -- YAML örnekleri, ağ mekanizmaları ve ölçeklendirme stratejileri ile 2026 rehberi.

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, pods, services, deployments
- Reading time: 12 min

---

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.

> **Hızlı Başvuru**
>
> Bir Pod, tek bir node üzerinde bir veya daha fazla konteyner çalıştırır. Bir Deployment, Pod replikalarını ve dağıtım süreçlerini yönetir. Bir Service ise bu Pod'lara ulaşabilmek için sabit bir ağ ucu noktası sağlar. Bu üç nesne, Kubernetes v1.35 ve sonraki sürümlerini kullanan herhangi bir kümede iş yükü yönetiminin yüzde seksenini karşılar.

## 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.

```yaml
# 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.

> **Mülakatlarda Sık Yapılan Hata**
>
> Bellek limitleri belirlenip `requests` değeri atlandığında öngörülemez zamanlama davranışları ortaya çıkar. Kubelet, Pod'u gerçekte iş yükünü kaldıramayacak bir node üzerine yerleştirmiş olabilir. Üretim ortamındaki Pod'larda her zaman hem `requests` hem de `limits` tanımlanmalıdır.

## 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.

```yaml
# 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](https://kubernetes.io/docs/concepts/workloads/controllers/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.

```yaml
# 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.

```bash
# 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](https://kubernetes.io/docs/concepts/services-networking/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.

```yaml
# 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 |

```yaml
# 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.

> **Gateway API, Ingress'in Yerini Alıyor**
>
> Kubernetes v1.35 itibarıyla Ingress NGINX denetleyicisi resmi olarak kullanımdan kaldırılmıştır. [Gateway API](https://gateway-api.sigs.k8s.io/), HTTP yönlendirme, TLS sonlandırma ve trafik bölme için artık önerilen yaklaşımdır. Yeni kümeler başından itibaren Gateway API ile kurulmalıdır.

## 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.

```yaml
# 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](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA), gözlemlenen metriklere dayanarak replika sayısını dinamik olarak ayarlar.

```yaml
# 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ı](/technologies/devops/interview-questions/kubernetes-basics) 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/tr/blog/devops/kubernetes-interview-pods-services-deployments-explained