2026’da En Popüler 46 Kubernetes Mülakat Sorusu ve Cevabı

Temel Kubernetes Mülakat Soruları

Şimdi temel Kubernetes mülakat sorularıyla başlayalım. Bu sorular, Kubernetes’i anlamak ve onunla çalışmak için gereken temel bilgileri kapsar. 

1. Kubernetes’te Pod nedir?

Pod, Kubernetes’te en küçük devreye alınabilir birimdir. Paylaşılan bir ortamda çalışan bir veya daha fazla konteyneri temsil eder. Pod içindeki konteynerler ağ ve depolama kaynaklarını paylaşır.

Basit bir Pod tanımına ait YAML dosyası şöyledir:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

2. kubectl’in amacı nedir?

Kubectl, Kubernetes kaynaklarını yönetmek ve küme ile etkileşime geçmek için birincil CLI aracıdır. Aşina olmanız gereken bazı yaygın kubectl komutları şunlardır:

kubectl get pods 				 # tüm Pod’ları listele
kubectl get services 			 # tüm Service’leri listele
kubectl logs <pod-name> 	  	 # bir Pod’un günlüklerini görüntüle
kubectl exec -it <pod-name> – /bin/sh # Pod içinde bir kabuk aç

3. Kubernetes’te Deployment nedir?

Kubernetes’te Deployment, Pod’ların yaşam döngüsünü yöneten daha üst düzey bir soyutlamadır. İstenen kopya sayısının ayakta ve çalışır durumda olmasını sağlar; kademeli güncellemeler, geri alma ve kendi kendini iyileştirme gibi özellikler sunar. 

Basit bir Deployment tanımına ait YAML dosyası şu şekildedir: 

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

4. Kubernetes Service nedir ve neden gereklidir?

Kubernetes’te Service, bir grup Pod’u dışa açar ve bu Pod’lar arasında ve onlara doğru iletişime izin verir. 

Pod’lar kısa ömürlü olduğundan IP’leri değişebilir; bu da Pod’larla konuşan uygulamanın IP adresini de değiştirmesi gerektiği anlamına gelir. Bu nedenle Service’ler sabit bir IP adresine sahip, stabil bir ağ uç noktası sağlar.

Basit bir Service YAML tanımı:

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

Yukarıdaki Service, app: my-app etiketine sahip Pod’lara trafiği yönlendirir.

5. Kubernetes Service’lerinde hangi servis tipleri mevcuttur?

Kubernetes, her biri farklı bir ağ amacına hizmet eden dört ana Service türü sağlar:

• ClusterIP (varsayılan): Pod’ların dahili iletişimini sağlar. Yalnızca küme içinden erişilebilir.
• NodePort: Servisi her Node üzerinde statik bir porta açar; küme dışından erişilebilir hale getirir.
• LoadBalancer: Bir bulut sağlayıcısının harici yük dengeleyicisini kullanır. Servise bir genel IP üzerinden erişilir.
• ExternalName: Bir Kubernetes Servisini harici bir ana bilgisayar adına eşler. 

6. Kubernetes’te ConfigMap ve secret’ların rolü nedir?

ConfigMap, hassas olmayan yapılandırma verilerini; secret ise API anahtarları ve parolalar gibi hassas verileri saklar.

Secret kullanımı, gizli bilgileri uygulama kodunuza koymaktan kaçınmanızı sağlar. Buna karşılık, ConfigMap’ler değerlerin kolayca düzenlenebilmesi ve uygulama kodunuzda kalıcı olmasına gerek olmaması sayesinde uygulamalarınızı daha yapılandırılabilir hale getirir.

Örnek ConfigMap YAML tanımı:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"

Örnek secret YAML tanımı (base64 ile kodlanmış [şifrelenmemiş] veri):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" Base64 ile kodlanmış

7. Kubernetes’te Namespace nedir?

Namespace, bir Kubernetes kümesi içinde sanal bir kümedir. Çok kiracılı ortamlarda iş yüklerini izole ederek kaynakları düzenlemeye yardımcı olur.

Aşağıda, kubectl kullanarak nasıl Namespace oluşturacağınızı ve o Namespace içinde Pod’ları nasıl oluşturup çekeceğinizi gösteren kısa bir kod parçası bulabilirsiniz:

# “dev” adlı bir namespace oluşturun
kubectl create namespace dev

# o namespace içinde bir Pod oluşturun
kubectl run nginx --image=nginx --namespace=dev

# o namespace içindeki Pod’ları alın
kubectl get pods --namespace=dev

8. Kubernetes’te Label ve Selector nedir?

Label’lar, nesnelere (örn. Pod’lar) eklenen anahtar/değer çiftleridir. Kubernetes nesnelerini düzenlemeye yardımcı olur. Selector’lar, kaynakları Label’lara göre filtreler. 

Aşağıda environment: production ve app: nginx etiketlerine sahip bir Pod örneği yer alıyor:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80

Şimdi aşağıdaki label selector’ı kullanarak environment: pod etiketine sahip tüm Pod’ları çekebilirsiniz:

kubectl get pods -l environment=production

9. Kalıcı Hacimler (PV) ve Kalıcı Hacim Talepleri (PVC) nedir?

Persistent Volume (PV), Pod yaşam döngülerinin ötesinde kalıcı olan depolama sağlar. PV, bir küme yöneticisi tarafından önceden tedarik edilen veya StorageClass’lar kullanılarak dinamik olarak sağlanan, kümede bir depolama parçasıdır.

Persistent Volume Claim (PVC), bir kullanıcının depolama talebidir. 

İşte bir PV ve PVC YAML tanım örneği: 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Orta Seviye Kubernetes Mülakat Soruları

Artık temelleri pratiğe döktüğünüze göre orta seviye sorulara geçebiliriz. Bu seviyede ağ, güvenlik, kaynak yönetimi ve sorun giderme gibi kavramları anlamak esastır.

10. Kubernetes ağ yapısı nedir ve nasıl çalışır?

Kubernetes ağ yapısı, Pod’lar, Service’ler ve harici istemciler arasında iletişime olanak tanır. Düz bir ağ yapısı izler; varsayılan olarak tüm Pod’lar birbirleriyle iletişim kurabilir.  

Kubernetes’teki temel ağ kavramları şunlardır:

• Pod’dan Pod’a iletişim: Her Pod benzersiz bir IP alır ve küme içinde iletişim kurabilir. 
• Service’ten Pod’a iletişim: Pod’lar kısa ömürlü olduğundan Service’ler bir Pod grubuna stabil bir ağ uç noktası sağlar. Her Pod, her oluşturulduğunda yeni bir IP alır.
• Ingress denetleyicileri: Harici HTTP/HTTPS trafiğini yönetir.
• Ağ politikaları: Pod’lar arasındaki iletişime izin veren veya kısıtlayan kuralları tanımlar.

11. Kubernetes’te Rol Tabanlı Erişim Kontrolü (RBAC) nedir?

RBAC, kullanıcıları ve servisleri izinlerine göre kısıtlayan bir güvenlik mekanizmasıdır. Şunlardan oluşur:

• Role ve ClusterRole: Kaynaklar üzerinde izin verilen eylemleri tanımlar.
• RoleBinding ve ClusterRoleBinding: Roller kullanıcılar veya servis hesaplarına atanır.

Aşağıdaki YAML, yalnızca Pod’lara salt-okunur erişim veren bir role örneğini gösterir:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Bu pod-reader rolü şimdi RoleBinding kullanılarak bir kullanıcıya bağlanabilir:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

12. Kubernetes otomatik ölçeklendirmeyi nasıl yapar?

Kubernetes, kaynak kullanımını optimize etmek için üç tür otomatik ölçeklendirme sağlar:

1. Horizontal Pod Autoscaler (HPA): Pod sayısını CPU kullanımı, bellek kullanımı veya özel metriklere göre ayarlar.
2. Vertical Pod Autoscaler (VPA): Tekil Pod’lar için CPU ve bellek isteklerini ayarlar.
3. Cluster Autoscaler: Kaynak ihtiyacına göre kümedeki işçi düğüm sayısını ayarlar.

Bir HPA’yı kubectl ile oluşturabilirsiniz:

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10

Yukarıdaki komut, adı nginx olan bir Deployment için bir HPA oluşturur ve tüm Pod’lar genelinde ortalama CPU kullanımını %50’de tutmaya çalışır, minimum kopya sayısı 1, maksimum kopya sayısı ise 10 olacak şekilde.

13. Kubernetes Pod’larında nasıl hata ayıklarsınız?

Pod’lar başarısız olduğunda Kubernetes çok sayıda hata ayıklama yöntemi sunar:

• Hatalar için konteyner günlüklerini kontrol etmek üzere kubectl logs kullanın.
• Olayları ve son durum değişikliklerini incelemek için kubectl describe pod kullanın.
• Konteyner içinde etkileşimli bir kabuk açıp içeriden araştırmak için kubectl exec kullanın.
• kubectl get pods --field-selector=status.phase=Failed kullanarak tüm başarısız Pod’ları listeleyin.

# belirli bir Pod’un loglarını al
kubectl get logs <pod-name>

# Pod’u ayrıntılandır ve olayları kontrol et
kubectl describe pod <pod-name>

# Pod içinde etkileşimli kabuk aç
kubectl exec -it <pod-name> – /bin/sh

# tüm başarısız pod’ları kontrol et
kubectl get pods --field-selector=status.phase=Failed

Bu komutlar, yanlış yapılandırmaları, kaynak kısıtlarını veya uygulama hatalarını tespit etmeye yardımcı olur.

14. Kubernetes’te kademeli güncellemeler ve geri almalar nasıl yapılır?

Kubernetes Deployment’lar kesinti yaşanmaması için kademeli güncellemeleri destekler. Bir Deployment’ı düzenleyerek veya imajını yeni bir sürüme açıkça ayarlayarak kademeli güncelleme yapabilirsiniz:

kubectl set image deployment/my-deployment nginx=nginx:1.21

Ardından Deployment durumunu kontrol edebilirsiniz:

kubectl rollout status deployment my-deployment

Önceki sürüme dönmek isterseniz şu komutu çalıştırabilirsiniz:

kubectl rollout undo deployment my-deployment

15. Kubernetes’te Ingress nedir ve nasıl çalışır?

Ingress, Kubernetes kümesi içindeki Service’lere harici HTTP/HTTPS erişimini yöneten bir API nesnesidir.  Ana bilgisayar adı ve yollara göre yönlendirme yapar; birden çok uygulama için ters proxy görevi görür.

Örnek Ingress YAML tanımı:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

16. Kubernetes Gateway API nedir ve Ingress’ten farkı nedir?

Gateway API, Kubernetes ağının modern evrimidir ve standart Ingress’in yerini almayı hedefler. Ingress basit HTTP yönlendirme için tasarlanmıştı, ancak kümeler karmaşıklaştıkça sınırlı ve parçalı hale geldi.

Gateway API bunu şu şekilde iyileştirir:

• Role dayalı tasarım: Gateway tanımını (altyapı mühendisleri yönetir) Route’lardan (uygulama geliştiricileri yönetir) ayırır.
• Daha iyi destek: Trafik bölme (A/B testi), başlık eşleme ve karmaşık özel açıklamalara gerek kalmadan çoklu küme ağı gibi gelişmiş trafik özelliklerini yerel olarak destekler.

17. Kubernetes kaynak limitleri ve isteklerini nasıl ele alır?

Kubernetes, Pod’lar için kaynak istekleri ve limitleri belirlemenize izin vererek adil tahsisi sağlar ve küme kaynaklarının aşırı kullanımını önler.

• İstekler, bir Pod’un ihtiyaç duyduğu minimum CPU ve bellek miktarıdır. Pod’a kalıcı olarak tahsis edilir.
• Limitler, bir Pod’un kullanabileceği en yüksek değerdir. Pod’a önceden tahsis edilmez; ancak daha fazla kaynağa ihtiyaç duyarsa, limite ulaşana kadar büyüyebilir.

Kaynak istekleri ve limitleri belirleyen örnek Pod YAML tanımı:

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"

18. Bir Pod’un kaynak ihtiyacı atanmış limitlerin ötesine geçerse ne olur?

Bir Pod’un bellek tüketimi atanmış bellek limitini aşarsa Kubernetes konteyneri hemen sonlandırır ve bellek yetersizliği (OOM) hatası oluşur. Bir yeniden başlatma politikası tanımlıysa konteyner yeniden başlatılır.

Bellekten farklı olarak, bir Pod atanmış CPU limitini aşarsa öldürülmez. Bunun yerine Kubernetes CPU kullanımını kısar ve uygulamanın yavaşlamasına neden olur.

19. Init container’lar nedir ve ne zaman kullanılmalıdır?

Init container’lar, ana konteynerler başlamadan önce çalışan özel konteynerlerdir. Bağımlılıkları kontrol ederek, yapılandırma dosyalarını yükleyerek veya verileri hazırlayarak ortamı hazırlarlar.

Örneğin, bir veritabanının ayağa kalkmasını bekleyen bir init container olabilir:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image

20. Kubernetes Pod kesintilerini ve yüksek erişilebilirliği nasıl yönetir?

Kubernetes, Pod Disruption Budget’lar (PDB), anti-affinity kuralları ve kendi kendini iyileştirme mekanizmaları ile yüksek erişilebilirlik sağlar. Bu mekanizmalar şöyle çalışır:

• Pod Disruption Budget (PDB): Gönüllü kesintiler (ör. küme güncellemeleriyle düğümlerin ölçek düşürülmesi) sırasında minimum sayıda Pod’un erişilebilir kalmasını sağlar.
• Pod affinity ve anti-affinity: Hangi Pod’ların birlikte ya da ayrı zamanlanacağını kontrol eder.
• Node selector’lar ve Taint/Toleration’lar: İş yüklerinin düğümlere nasıl dağıtılacağını kontrol eder.

İki Pod’un kesintiler sırasında çalışır kalmasını garanti eden örnek PDB YAML tanımı:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

İleri Seviye Kubernetes Mülakat Soruları

Bu bölüm, durumlu uygulamalar, çoklu küme yönetimi, güvenlik, performans optimizasyonu ve sorun giderme odaklı ileri seviye Kubernetes mülakat sorularını kapsar. Kıdemli bir pozisyona başvuruyorsanız mutlaka göz atın.

21. StatefulSet nedir ve Deployment’tan nasıl farklıdır?

StatefulSet, durumlu uygulamalar için kullanılır; stabil ağ kimlikleri, kalıcı depolama ve sıralı devreye alma gerektirir. Deployment’tan farklı olarak StatefulSet şunları garanti eder:

• Pod’lar stabil ve benzersiz ağ kimliklerine sahiptir; Pod adları pod-0, pod-1 vb. şeklindedir.
• Pod’lar sıralı şekilde oluşturulur, güncellenir ve silinir.
• Her Pod yeniden başlatmalar arasında kalıcı depolamasını korur. Kalıcı depolama StatefulSet YAML tanımının bir parçası olarak tanımlanır.

22. Service mesh nedir ve Kubernetes’te neden kullanılır?

Service mesh, servisten servise iletişimi yönetir ve şunları sağlar:

• Trafik yönetimi (yük dengeleme, canary dağıtımlar).
• Güvenlik (servisler arası mTLS şifreleme).
• Gözlemlenebilirlik (izleme, metrikler, loglama)

Tüm bu özellikler altyapı katmanında yer alır; kod değişikliği gerekmez. 

Popüler Kubernetes service mesh çözümleri: Istio, Linkerd ve Consul.

23. Bir Kubernetes kümesini nasıl güvenli hale getirebilirsiniz?

Bir Kubernetes kümesini güvenli hale getirmek için 4C güvenlik modelini izleyin:

1. Bulut sağlayıcı güvenliği: IAM rolleri ve güvenlik duvarı kurallarını kullanın.
2. Küme güvenliği: RBAC, denetim günlükleri ve API sunucusu güvenliğini etkinleştirin.
3. Konteyner güvenliği: İmajları tarayın ve non-root kullanıcılar kullanın.
4. Kod güvenliği: Secret yönetimi uygulayın ve ağ politikaları kullanın.

24. Kubernetes’te Taint ve Toleration nedir?

Taint ve Toleration, Pod’ların nerede çalışacağını kontrol eder:

• Taint: Düğümleri Pod’ları reddedecek şekilde işaretler.
• Toleration: Pod’ların belirli Taint’leri yok saymasına izin verir.

Yalnızca belirli iş yüklerini kabul edecek şekilde bir düğümü taint etme örneği:

kubectl taint nodes node1 key1=value1:NoSchedule

Bu, gerekli Toleration eklenene kadar hiçbir Pod’un node1 üzerinde zamanlanamayacağı anlamına gelir.

Toleration, PodSpec bölümüne aşağıdaki gibi eklenir:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: “value1”
    effect: "NoSchedule"

Pod’un node1 üzerinde zamanlanmasına izin verilir.

25. Kubernetes sidecar konteynerleri nedir ve nasıl kullanılır?

Sidecar konteyneri, aynı Pod içinde ana uygulama konteynerinin yanında çalışır. Yaygın kullanım alanları şunlardır:

• Günlükleme ve izleme (örn. Fluentd ile log toplama).
• Güvenlik proxy’leri (örn. service mesh için Istio’nun Envoy proxy’sini çalıştırmak).
• Yapılandırma yönetimi (örn. uygulama ayarlarını eşitlemek).

Günlük işleme için sidecar konteyner örneği:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}

Sidecar konteyneri Fluentd çalıştırır ve paylaşılan birim aracılığıyla ana konteynerden log toplar.

26. Yerel Sidecar’lar (SidecarContainers) nedir ve hangi sorunu çözer?

Kubernetes v1.28/1.29’dan önce, sidecar konteynerler yalnızca uygulamanızın yanında çalışan normal konteynerlerdi. Bu bir “yarış durumu” oluşturuyordu: uygulamanız sidecar’ınızdan (ör. bir güvenlik proxy’si veya log gönderici) önce başlarsa, yardımcı bileşen hazır olmadığı için uygulama çökebilir veya veri kaybedebilirdi.

Yerel Sidecar’lar, initContainers bölümünde restartPolicy: Always ile sidecar tanımlamanıza izin vererek bu sorunu çözer.

• Nasıl çalışır: Kubernetes bunları init container olarak ele alır; yani ana uygulama başlamadan başarıyla başlatılmaları gerekir.
• Faydası: Bu, uygulamanız tek bir isteği bile işlemeye başlamadan önce güvenlik proxy’lerinin veya loglayıcıların tamamen aktif olmasını garanti eder.

27. Üç tipik Pod hatası ve nasıl düzeltileceğini söyleyin.

Pod’lar Pending, CrashLoopBackOff veya ImagePullBackOff durumlarında takılabilir:

• Pod Pending durumunda takılı: Düğüm uygunluğunu ve kaynak limitlerini kontrol edin. Daha fazla bilgi için Pod’un olaylarını inceleyebilirsiniz.
• CrashLoopBackOff: Uygulama loglarını inceleyin ve yanlış yapılandırmaları kontrol edin.
• ImagePullBackOff: Doğru imaj adı ve çekme kimlik bilgilerini doğrulayın. Yine, daha fazla bilgi için Pod’un olaylarını inceleyin.

Pod’un olaylarını describe komutuyla kontrol edebilirsiniz:

kubectl describe pod <pod-name>

28. Kubernetes mutating admission webhook’u nedir ve nasıl çalışır?

Mutating admission webhook, Kubernetes nesnelerinin kümeye uygulanıp kalıcı hale gelmeden gerçek zamanlı olarak değiştirilmesine izin verir. etcd’ye yazılmadan önce API isteklerini yakalayan dinamik bir admission controller çalıştırır. İstek yükünü, isteğe devam edilmesine izin vermeden önce alanları enjekte ederek, değiştirerek veya kaldırarak düzenleyebilir.

Yaygın kullanım alanları şunlardır:

• Sidecar enjekte etmek.
• Pod, Deployment veya diğer kaynaklar için varsayılan değerleri ayarlamak.
• En iyi uygulamaları zorlamak (örn. kaynak limitlerini otomatik atamak).
• Güvenlik yapılandırmaları eklemek (örn. denetim takibi için etiket zorunluluğu).

29. Kubernetes’te sıfır kesintiyle Deployment’lar nasıl uygulanır?

Sıfır kesintili Deployment’lar, güncellemelerin canlı trafiği kesintiye uğratmamasını sağlar. Kubernetes bunu şu yollarla başarır:

• Kademeli güncellemeler (varsayılan; eski Pod’ları yenileriyle aşamalı olarak değiştirir).
• Canary dağıtımlar (kullanıcıların bir alt kümesiyle test etme).
• Mavi-yeşil dağıtımlar (canlı ve test ortamları arasında geçiş).

Readiness probe’lar, Kubernetes’in hazır olmayan Pod’lara trafik göndermesini önlemeye yardımcı olur.

30. Kubernetes Custom Resource Definition (CRD) nedir ve ne zaman kullanılmalıdır?

Custom Resource Definition (CRD), Kubernetes API’lerini genişleterek özel kaynakları tanımlamaya ve yönetmeye olanak tanır. Kubernetes API’sinin bu kaynakları yönetmek için kullanılmaya devam etmesi gereken özel kullanım durumları için kullanılır; örneğin:

• Özel uygulamaları yönetmek (örn. makine öğrenimi modelleri).
• Kendini iyileştiren uygulamalar için Kubernetes operatörlerini etkinleştirmek.

Örnek CRD YAML tanımı:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string

Artık örneğin shirt nesnesini kubectl ile çekebilirsiniz:

kubectl get shirts

Makine öğrenimi iş akışları için Docker ve Kubernetes’ten nasıl yararlanılacağını bu uygulamalı konteynerleştirme eğitiminde keşfedin.

31. Kubernetes operatörleri nedir ve nasıl çalışır?

Kubernetes operatörü, karmaşık uygulamaların dağıtımını, ölçeklenmesini ve yönetimini otomatikleştirerek Kubernetes işlevselliğini genişletir. CRD’ler ve özel denetleyiciler kullanılarak oluşturulur ve uygulamaya özgü mantığı yönetir.

Operatörler, Kubernetes’te özel kaynaklar tanımlayarak ve kümedeki değişiklikleri izleyerek belirli görevleri otomatikleştirir. 

Bir operatörün temel bileşenleri şunlardır:

• Custom Resource Definition (CRD): Yeni bir Kubernetes API kaynağı tanımlar.
• Özel denetleyici: CRD’yi izler ve istenen duruma göre otomasyon mantığını uygular.
• Uzlaştırma döngüsü: Uygulama durumunun beklenen durumla sürekli uyumlu olmasını sağlar.

Yöneticiler için Kubernetes Mülakat Soruları

Kubernetes yöneticileri, üretim iş yükleri için kümeleri sürdürür, güvenli hale getirir ve optimize eder. Bu bölüm, küme yönetimine odaklanan Kubernetes mülakat sorularını kapsar.

32. Kubernetes’te bir etcd kümesi nasıl yedeklenir ve geri yüklenir?

Etcd, tüm küme durumunu tutan anahtar-değer deposudur. Veri kaybını önlemek için düzenli yedeklemeler esastır.

Aşağıdaki komutla bir yedek oluşturabilirsiniz:

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>

Bir yedekten geri yüklemek isterseniz şunu çalıştırabilirsiniz:

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db

33. Bir Kubernetes kümesi nasıl güvenli şekilde yükseltilir?

Kubernetes kümesini yükseltmek, minimum kesinti ve küme kararlılığını koruma gerektiren çok adımlı bir süreçtir. Yöneticiler, yükseltme sırasında sorunları önlemek için yapılandırılmış bir yaklaşım izlemelidir:

1. Yükseltmeden önce etcd’yi boşaltın (drain) ve yedekleyin; başarısızlık halinde geri yükleyebilmek için.
2. Kontrol düzlemi düğümünü yükseltin.
3. Kontrol düzlemi düğümlerinde kubelet ve kubectl’i yükseltin.
4. İşçi düğümleri tek tek yükseltin. Her işçi düğümü, yükseltmeden önce iş yükü kesintisini önlemek için boşaltılmalıdır.
5. Küme eklentilerini yükseltin (örn. Ingress denetleyicileri, izleme araçları, …).

34. Bir Kubernetes kümesi nasıl izlenir?

Kubernetes yöneticileri CPU, bellek, disk, ağ ve uygulama sağlığını izlemelidir. Bu görevler için aşağıdaki araçlar önerilir:

• Prometheus + Grafana: Küme metriklerini toplayın ve görselleştirin. Sorunlar için gerçek zamanlı uyarılar oluşturun.
• Loki + Fluentd: Log toplayıp analiz edin.
• Kubernetes dashboard: UI tabanlı küme izleme.
• Jaeger/OpenTelemetry: Dağıtık izleme.

35. Bir Kubernetes kümesi nasıl güvenli hale getirilir?

Güvenlik kilit önemdedir ve her yönetici bir Kubernetes kümesini güvenli hale getirmek için en iyi uygulamaları izlemelidir:

• RBAC’i etkinleştirin: Kullanıcı erişimini Role ve RoleBinding ile kısıtlayın.
• Pod security admission: Pod güvenlik standartlarını zorlamak için admission controller’lar kullanın.
• NetworkPolicy’leri uygulayın: Pod iletişimini kısıtlayın; varsayılan olarak tüm Pod’lar birbirleriyle iletişim kurabilir.
• API belirteçlerini ve sertifikaları düzenli olarak döndürün.
• Secret yönetimi kullanın: Vault, AWS Secrets Manager vb. araçları kullanın. 

Kubernetes’in bulutta nasıl uygulandığını AWS Elastic Kubernetes Service (EKS) ile konteyner orkestrasyonu rehberiyle öğrenin.

36. Kubernetes loglaması nasıl kurulur?

Merkezi loglama, hata ayıklama ve denetim için gereklidir. İki farklı log yığını seçeneği:

• Loki + Fluentd + Grafana (Hafif ve hızlı).
• ELK Yığını (Elastic, Logstash, Kibana) (Ölçeklenebilir ve kurumsal seviyede).

37. Kubernetes’te yüksek erişilebilirlik nasıl uygulanır?

Yüksek erişilebilirlik, Kubernetes kümenizde çalışan uygulamaların kesinti yaşamamasını sağlamak için gereklidir. Şunlarla yüksek erişilebilirlik sağlayabilirsiniz:

• Birden fazla kontrol düzlemi düğümü kullanmak. Birden çok API sunucusu, biri başarısız olsa bile kesintiyi önler.
• Küme otomatik ölçekleyicisini etkinleştirmek. Bu, talebe göre düğüm ekler/kaldırır.

38. Kubernetes kümesinde çok kiracılık (multi-tenancy) nasıl uygulanır?

Şirketiniz için Kubernetes kuruyorsanız çok kiracılık oldukça önemlidir. Birden fazla ekibin veya uygulamanın, birbirini etkilemeden güvenli şekilde aynı Kubernetes kümesini paylaşmasını sağlar.

İki tür çok kiracılık vardır:

1. Yumuşak çok kiracılık: Namespace, RBAC ve NetworkPolicy kullanarak namespace düzeyinde izolasyon sağlar.
2. Sert çok kiracılık: Sanal kümeler veya ayrı kontrol düzlemleri kullanarak fiziksel kümeyi izole eder (örn. KCP).

39. Kubernetes secret’ları etcd’de nasıl şifrelenir?

Etcd, tüm küme durumunu depolar; bu da kritik bilgilerin orada olduğu anlamına gelir. 

Varsayılan olarak Kubernetes, secret’ları etcd’de şifrelenmemiş olarak saklar; bu da onları tehlikeye açık hale getirir. Bu nedenle, secret’ların depoda şifrelenmesi için rest’te şifrelemeyi etkinleştirmek kritik olabilir. 

İlk adım olarak bir şifreleme yapılandırma dosyası oluşturmalı ve bu dosyada bir şifreleme/şifre çözme anahtarı saklamalısınız:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}

Yukarıdaki yapılandırma, Kubernetes’in Secret kaynaklarını şifrelemek için aescbc sağlayıcısını kullanacağını, şifrelenmemiş veriler için identity’ye geri döneceğini belirtir.

Sonraki adımda, genellikle kontrol düzlemi düğümünde /etc/kubernetes/manifests/kube-apiserver.yaml yolunda bulunan kube-apiserver yapılandırma dosyasını uyarlamalı ve oluşturduğunuz şifreleme yapılandırma dosyasını işaret eden -- encryption-provider-config bayrağını eklemelisiniz:

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml

Değişiklikleri kaydedin ve yeni yapılandırmayı uygulamak için kube-apiserver’ı yeniden başlatın.

40. Çok kiracılı ortamlarda Kubernetes kaynak kotaları nasıl yönetilir?

Kaynak kotaları, tek bir kiracının (namespace’in) küme kaynaklarını aşırı tüketmesini ve diğer kiracıları engellemesini önler.

Belirli bir namespace’e belirli miktarda kaynak tahsis etmek için ResourceQuota tanımlayabilirsiniz. O namespace’in kullanıcıları, namespace’in ResourceQuota’sında tanımlandığı kadar kaynağı tüketen kaynaklar oluşturabilir.

Örnek ResourceQuota YAML tanımı:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Bir namespace’in ResourceQuota’sını şu şekilde kontrol edebilirsiniz:

kubectl describe resourcequota namespace-quota -n team-a

41. CoreDNS nedir? Nasıl yapılandırılır ve kullanılır?

CoreDNS, Kubernetes kümeleri için varsayılan DNS sağlayıcısıdır. Servis keşfi sağlar ve Pod’ların IP adresleri yerine dahili DNS adlarını kullanarak iletişim kurmasına olanak tanır.

CoreDNS’in özellikleri:

• Dahili DNS çözümlemesini gerçekleştirir (my-service.default.svc.cluster.local).
• Özel DNS yapılandırmasını destekler.
• DNS sorgularını birden çok Pod arasında yük dengeler.
• Daha iyi performans için önbellekleme sağlar.

CoreDNS’i, kube-system namespace’inde saklanan ConfigMap ile yapılandırabilirsiniz. Geçerli ayarları şu şekilde görüntüleyebilirsiniz:

kubectl get configmap coredns -n kube-system -o yaml

CoreDNS yapılandırmasını uyarlamak için bu ConfigMap’i güncelleyin ve değişiklikleri uygulayın.

Senaryo Tabanlı ve Problem Çözme Odaklı Kubernetes Mülakat Soruları

Mühendisler, gerçek dünya Kubernetes ortamlarında düzenli olarak karmaşık ölçeklenebilirlik, ağ, güvenlik, performans ve sorun giderme zorluklarıyla karşılaşır ve mülakat yapanlar bunun farkındadır. Bu bölüm, pratik Kubernetes problemlerini çözme becerinizi test eden senaryo tabanlı mülakat soruları sunar.

42. Yavaş bir Kubernetes uygulamasının hata ayıklanması

“Ekibiniz, Kubernetes’te çalışan bir uygulamanın yavaşladığını ve kullanıcıların yüksek yanıt süreleri yaşadığını bildiriyor. Bunu nasıl çözersiniz?”

Soruna şu adımlarla yaklaşabilirsiniz:

1. Pod kaynak kullanımını kontrol edin. Limitlerdeyse kaynakları artırın.

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory

2. Yavaş Pod’u ayrıntılandırın. Kaynak kısma, yeniden başlatma sayıları veya liveness probe hatalarına bakın.

kubectl describe pod <pod-name>

3. Konteyner loglarında hataları kontrol edin. Zaman aşımları, hatalar veya bağlantı hatalarına bakın.

kubectl logs <pod-name>

4. Ağ gecikmesini test edin; uygulamaları yavaşlatabilir.

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service

5. Kubernetes düğüm sağlığını doğrulayın ve düğümlerde kaynak tükenmesini kontrol edin.

kubectl get nodes
kubectl describe node <node-name>

43. Nginx web sunucusu çalışıyor, ancak açılan URL bağlanamıyor

“Kubernetes’te bir Nginx web sunucusu dağıttınız ve Pod sorunsuz çalışıyor, ancak uygulamaya açığa çıkarılan URL üzerinden erişilemiyor. Ne yapabilirsiniz?”

Yukarıdaki probleme yaklaşım adımları:

1. Nginx Pod’un çalıştığını ve sağlıklı olduğunu doğrulayın.

kubectl get pods -o wide
kubectl describe pod nginx-web

2. Service ve port eşlemesini kontrol edin. Doğru portun açığa çıkarıldığından ve Pod’un konteyner portuyla eşleştiğinden emin olun. Service’in doğru Pod’ları bulduğunu kontrol edin.

kubectl describe service nginx-service

3. Ağ politikalarını kontrol edin. Bir ağ politikası gelen trafiği engelliyorsa Service erişilebilir olmayacaktır.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

4. Ingress ve harici DNS yapılandırmasını doğrulayın.

kubectl describe ingress nginx-ingress

44. Kubernetes Deployment yükseltmeden sonra başarısız oluyor

“Uygulamanızın yeni bir sürümünü dağıttınız, ancak başlatılamıyor, kullanıcılar için kesinti oluşuyor. Bunu nasıl düzeltirsiniz?”

Soruna yaklaşım:

1. Çalışan önceki sürüme geri dönün.

kubectl rollout undo deployment my-app

2. Deployment geçmişini kontrol edin ve yeni sürümde nelerin değiştiğini belirleyin.

kubectl rollout history deployment my-app

3. Yeni Pod’un loglarında hataları kontrol edin.

kubectl logs -l app=my-app

4. Readiness ve liveness probe’larını kontrol edin.

5. İmaj çekme sorunlarını doğrulayın. Bazen yeni imaj hatalıdır veya mevcut değildir.

45. Uygulama harici bir veritabanına bağlanamıyor

“Kubernetes’te çalışan bir mikro servis, küme dışında barındırılan harici bir veritabanına bağlanamıyor. Bunu nasıl düzeltirsiniz?”

Soruna yaklaşım adımları:

1. Pod içinden harici bağlantıyı doğrulayın. Veritabanının Kubernetes ağından erişilebilir olup olmadığını kontrol edin.

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432

2. Pod içinde DNS çözümlemesini kontrol edin. Başarısız olursa, CoreDNS yanlış yapılandırılmış olabilir.

kubectl exec -it <pod-name> -- nslookup my-database.example.com

3. Harici erişimi engelleyen ağ politikaları olup olmadığını kontrol edin; giden trafiği engelleyebilirler.

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>

46. Küme kaynakları tükendi; yeni Pod’lar pending durumda kalıyor

“Yeni pod’lar Pending durumunda kalıyor. Pod’lara yakından baktığımızda ‘0/3 düğüm uygun: yetersiz CPU ve bellek’ mesajını görüyoruz. Bunu nasıl teşhis eder ve çözersiniz?”

Soruna yaklaşım adımları:

1. Küme kaynak uygunluğunu kontrol edin. Zamanlamayı engelleyen yüksek CPU/bellek kullanımını arayın.

kubectl describe node <node-name>
kubectl top nodes

2. En çok kaynağı tüketen Pod’ları kontrol edin. Pod’lar için istek ve limitleri ayarlayın ki aşırı tüketmesinler. Bunu kümedeki tüm namespace’ler için de zorunlu kılabilirsiniz.

kubectl top pods --all-namespaces

3. Kaynak açmak için önemsiz iş yüklerini ölçek düşürün.

kubectl scale deployment <deployment-name> --replicas=0

4. Küme kaynaklarını artırmak için mevcut düğüm sayısını yükseltin. Bir küme otomatik ölçekleyicisi kullanılıyorsa, daha fazla düğüm ekleyin.

Kubernetes Mülakatına Hazırlık İçin İpuçları

Kendi Kubernetes mülakatı deneyimlerimden öğrendiğim, başarının yalnızca kavramları ezberlemekten ibaret olmadığıdır. Bilginizi gerçek dünya senaryolarında uygulamanız, verimli şekilde sorun gidermeniz ve çözümlerinizi net biçimde açıklamanız gerekir.

Kubernetes mülakatlarında başarılı olmak istiyorsanız aşağıdaki ipuçlarını izleyin:

1. Temel Kubernetes kavramlarına hakim olun. Pod’lar, Deployment’lar, Service’ler, Persistent Volume’ler, ConfigMap’ler, Secret’lar vb. konuları anlayın.
2. Kubernetes ile pratik deneyim edinin. Ben mülakatlarıma hazırlanırken kendi Minikube kümemi kurup mikro servisler dağıtmanın kavrayışımı pekiştirdiğini gördüm. Ölçekli pratik için bir bulut sağlayıcısının yönetilen Kubernetes hizmetini de kullanabilirsiniz.
3. Kubernetes sorunlarını nasıl gidereceğinizi öğrenin; gerçek dünyada Kubernetes ile çalışmanın önemli bir kısmı sorun gidermektir. İşte muhtemelen zamanınızın çoğunu uygulama sorunlarını çözerek harcayacaksınız.
• Tipik sorunlar arasında takılı kalan Pod’lar, ağ hataları, doğru bağlanmayan kalıcı hacimler ve düğüm arızaları yer alır.
4. Kubernetes ağ yapısını ve yük dengelemeyi anlayın. Ağın nasıl uygulandığına, Pod’ların nasıl iletişim kurduğuna, hangi Service türlerinin bulunduğuna ve uygulamaların nasıl dışa açılacağına odaklanın.
5. Kubernetes iş yüklerini nasıl ölçekleyip optimize edeceğinizi bilin. Mülakatlarda sıklıkla ölçekleme stratejileri ve maliyet optimizasyonu sorulur. HPA, küme otomatik ölçekleyicisi, kaynak istekleri ve limitlerinde yetkin olun. 
6. Kubernetes güvenlik en iyi uygulamalarını anlayın. RBAC, Pod güvenlik bağlamı, ağ politikaları ve secret yönetimine aşina olun.
7. Kubernetes mimarisi ve iç işleyişini inceleyin. Kontrol düzlemi bileşenlerine ve kubelet ile konteyner çalışma zamanının nasıl etkileştiğine aşina olun.

Teorik bilgiyi pratikle birleştirip gerçek dünya sorun gidermeden öğrenerek, herhangi bir Kubernetes mülakatında ustalaşacaksınız!

Sonuç

Kubernetes güçlü ama karmaşık bir konteyner orkestrasyon sistemidir. Kubernetes rollerine yönelik mülakatlar, teoriye derinlemesine hakimiyet ve gerçek dünya problem çözme becerisi gerektirir. İster ilk işini arayan bir junior mühendis olun ister daha ileri roller hedefleyen bir senior, hazırlık her zaman anahtardır.

Pratiğin önemini yeterince vurgulayamam. Uygulamalarınızdaki sorunları daha hızlı bulmanıza ve yeteneklerinize daha fazla güvenmenize yardımcı olur.

Temellerinizi güçlendirmek istiyorsanız, sağlam bir temel oluşturmak için Containerization and Virtualization Concepts gibi kursları, ardından pratik Kubernetes deneyimi kazanmak için Introduction to Kubernetes kursunu incelemenizi şiddetle öneririm. Hazır olduğunuzda, becerilerinizi sergilemek için bir Kubernetes sertifikasına göz atabilirsiniz. 

Mülakatlarınızda hepinize başarılar dilerim!