Senior Seviye Kubernetes Mülakat Soruları

100 adet ileri seviye soru ve cevapla hazırlanmış kapsamlı arşiv

Temel Kubernetes Kavramları

Kubernetes mimarisinin temel bileşenleri ve çalışma prensipleri

20 Soru

Pod'lar ve Container'lar

Pod ve container yönetimi, lifecycle ve yapılandırma

15 Soru

Deployment ve StatefulSet

Uygulama dağıtımı, güncelleme stratejileri ve stateful uygulamalar

15 Soru

Service ve Networking

Kubernetes'de servisler, ağ iletişimi ve trafik yönetimi

15 Soru

ConfigMap ve Secret

Yapılandırma yönetimi ve hassas verilerin depolanması

10 Soru

Persistent Storage

Kalıcı veri depolama ve volume yönetimi

10 Soru

Helm ve Package Management

Kubernetes uygulamalarını paketleme ve yönetme

5 Soru

Monitoring ve Logging

Kubernetes cluster'ını izleme ve log yönetimi

5 Soru

Kubernetes Güvenliği

Kubernetes ortamında güvenlik önlemleri ve best practices

5 Soru

İpuçları ve Best Practices

Kubernetes kullanımında ipuçları ve en iyi uygulamalar

5 Soru

Temel Kubernetes Kavramları

Kubernetes mimarisinin temel bileşenleri ve çalışma prensipleri ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes nedir ve ne işe yarar?

Cevap: Kubernetes, container'lı uygulamaları otomatikleştirmek, ölçeklendirmek ve yönetmek için kullanılan açık kaynaklı bir container orkestrasyon sistemidir.

  • Container'ların dağıtımını, ölçeklendirilmesini ve yönetimini otomatikleştirir
  • Kaynak kullanımını optimize eder
  • Kendini iyileştiren (self-healing) yetenekleri sunar
  • Hizmet kesintisini en aza indirir

❓ Soru 2: Kubernetes mimarisinin ana bileşenleri nelerdir?

Cevap: Kubernetes mimarisi Control Plane (Master) ve Worker (Node) bileşenlerinden oluşur.

  • Control Plane (Master) Bileşenleri:
    • API Server: Tüm operasyonlar için merkezi yönetim noktası
    • etcd: Cluster durumunu saklayan anahtar-değer deposu
    • Scheduler: Pod'ları node'lara atar
    • Controller Manager: Cluster durumunu denetleyen denetleyicileri çalıştırır
    • Cloud Controller Manager: Bulut sağlayıcı özelliklerini yönetir
  • Worker (Node) Bileşenleri:
    • Kubelet: Node'daki container'ları yönetir
    • Kube-proxy: Ağ kurallarını ve yük dengelemeyi yönetir
    • Container Runtime: Docker, containerd gibi container çalıştırma ortamları

❓ Soru 3: Kubernetes cluster'ı nasıl oluşturulur?

Cevap: Kubernetes cluster'ı oluşturmak için farklı yöntemler kullanılabilir:

  • kubeadm kullanarak: Standart ve en yaygın yöntem
  • Minikube ile: Yerel geliştirme ve test için
  • Kind (Kubernetes in Docker) ile: Docker container'ları içinde cluster oluşturma
  • Bulut sağlayıcıların yönetilen Kubernetes servisleri (EKS, GKE, AKS)

kubeadm ile cluster oluşturma örneği:

# Master node'da
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# Worker node'ları master'a bağlamak için
sudo kubeadm join <master-ip>:<master-port> --token <token> --discovery-token-ca-cert-hash <hash>

❓ Soru 4: kubectl komutu nedir ve nasıl kullanılır?

Cevap: kubectl, Kubernetes cluster'ı ile etkileşim kurmak için kullanılan komut satırı aracıdır.

Temel kubectl komutları:

# Cluster bilgilerini görüntüleme
kubectl cluster-info

# Node'ları listeleme
kubectl get nodes

# Pod'ları listeleme
kubectl get pods

# Bir YAML dosyasından kaynak oluşturma
kubectl create -f <dosya-adı>.yaml

# Bir deployment oluşturma
kubectl create deployment <deployment-adı> --image=<image-adı>

# Pod loglarını görüntüleme
kubectl logs <pod-adı>

# Pod içinde komut çalıştırma
kubectl exec -it <pod-adı> -- <komut>

# Bir kaynağı silme
kubectl delete deployment <deployment-adı>

❓ Soru 5: Kubernetes'te namespace nedir ve ne işe yarar?

Cevap: Namespace, aynı fiziksel cluster'da kaynakları mantıksal olarak ayırmak için kullanılan bir mekanizmadır.

  • Farklı ortamları (geliştirme, test, üretim) ayırmak için kullanılır
  • Kaynak çakışmalarını önler
  • Kaynak erişimini kontrol etmek için kullanılır
  • Kaynakları organize etmek için kullanılır

Namespace oluşturma ve kullanma:

# Namespace oluşturma
kubectl create namespace <namespace-adı>

# Namespace içinde kaynak oluşturma
kubectl create deployment <deployment-adı> --image=<image-adı> -n <namespace-adı>

# Tüm namespace'leri listeleme
kubectl get namespaces

# Belirli bir namespace'deki kaynakları listeleme
kubectl get pods -n <namespace-adı>

❓ Soru 6: Kubernetes'te label ve selector nedir?

Cevap: Label, Kubernetes nesnelerine eklenen key-value çiftleridir. Selector ise bu label'lara göre nesneleri filtrelemek için kullanılır.

  • Label: Nesnelere metadata eklemek için kullanılır
  • Selector: Label'lara göre nesneleri seçmek için kullanılır

Örnek kullanım:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
    tier: frontend
spec:
  containers:
  - name: my-container
    image: nginx

Selector ile Pod'ları seçme:

# app=my-app label'ına sahip pod'ları listele
kubectl get pods -l app=my-app

# tier=frontend ve app=my-app label'larına sahip pod'ları listele
kubectl get pods -l tier=frontend,app=my-app

❓ Soru 7: Kubernetes'te annotation nedir ve label'dan farkı nedir?

Cevap: Annotation, Kubernetes nesnelerine eklenen metadata'dır. Label'dan farkı, selector ile kullanılamaması ve genellikle daha büyük veriler için kullanılmasıdır.

  • Annotation: Nesneler hakkında ek bilgi depolamak için kullanılır
  • Label: Nesneleri seçmek ve gruplamak için kullanılır

Örnek kullanım:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  annotations:
    example.com/owner: "team-a"
    example.com/created-by: "john.doe"
  labels:
    app: my-app
    tier: frontend
spec:
  containers:
  - name: my-container
    image: nginx

❓ Soru 8: Kubernetes'te etcd nedir ve ne işe yarar?

Cevap: etcd, Kubernetes cluster'ının durumunu saklayan dağıtık bir anahtar-değer deposudur.

  • Tüm Kubernetes nesnelerinin durumunu saklar
  • Service discovery ve yapılandırma için kullanılır
  • Cluster durumunun tutarlılığını sağlar
  • Yüksek erişilebilirlik ve güvenilirlik sağlar

etcd'yi yedekleme:

# etcd snapshot oluşturma
ETCDCTL_API=3 etcdctl --endpoints=<etcd-ip>:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/etcd-snapshot.db

❓ Soru 9: Kubernetes API Server'ın görevi nedir?

Cevap: Kubernetes API Server, cluster'ın tüm operasyonları için merkezi yönetim noktasıdır.

  • Tüm Kubernetes nesnelerini (Pod, Service, Deployment vb.) yönetir
  • Doğrulama ve yetkilendirme işlemlerini gerçekleştirir
  • Diğer Kubernetes bileşenleri ile iletişim kurar
  • RESTful API aracılığıyla dış dünyaya açılır

❓ Soru 10: Kubernetes Controller Manager'ın görevi nedir?

Cevap: Controller Manager, cluster durumunu denetleyen denetleyicileri çalıştıran bileşendir.

  • Node Controller: Node'ların durumunu izler
  • Replication Controller: Pod'ların istenen sayıda olmasını sağlar
  • Endpoint Controller: Endpoint nesnelerini doldurur
  • Service Account & Token Controller: Service account'ları ve token'ları yönetir

❓ Soru 11: Kubernetes Scheduler'ın görevi nedir?

Cevap: Kubernetes Scheduler, yeni oluşturulan Pod'ları çalıştırmak için uygun Node'ları seçen bileşendir.

  • Pod'ları Node'lara atar
  • Kaynak kullanımını dikkate alır
  • Donanım, yazılım ve politika kısıtlamalarını göz önünde bulundurur
  • Yük dengeleme sağlar

❓ Soru 12: Kubelet'in görevi nedir?

Cevap: Kubelet, her Node'da çalışan ve Node'daki container'ları yöneten bileşendir.

  • Pod'ların durumunu izler
  • Container'ları başlatır, durdurur ve yeniden başlatır
  • Node'un kaynak kullanımını izler
  • API Server ile iletişim kurar

❓ Soru 13: Kube-proxy'nin görevi nedir?

Cevap: Kube-proxy, her Node'da çalışan ve ağ kurallarını ve yük dengelemeyi yöneten bileşendir.

  • Service'ler için ağ kurallarını yönetir
  • Pod'lara gelen trafiği yönlendirir
  • Cluster IP'lerini yönetir
  • Trafiği Pod'lar arasında dağıtır

❓ Soru 14: Kubernetes'te RBAC nedir ve nasıl çalışır?

Cevap: RBAC (Role-Based Access Control), Kubernetes'te kullanıcıların ve servis hesaplarının yetkilendirilmesini sağlayan bir mekanizmadır.

  • Role: Belirli bir namespace içindeki izinleri tanımlar
  • ClusterRole: Tüm namespace'ler için geçerli olan izinleri tanımlar
  • RoleBinding: Role veya ClusterRole'u kullanıcı veya servis hesabına bağlar
  • ClusterRoleBinding: ClusterRole'u kullanıcı veya servis hesabına bağlar

RBAC örneği:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

❓ Soru 15: Kubernetes'te ServiceAccount nedir?

Cevap: ServiceAccount, Pod'ların Kubernetes API'sine erişmek için kullandığı bir hesaptır.

  • Pod'ların API Server ile iletişim kurmasını sağlar
  • Her namespace'de varsayılan bir ServiceAccount vardır
  • Pod'lara özel izinler atamak için kullanılır
  • Token'lar otomatik olarak Pod'lara mount edilir

ServiceAccount oluşturma:

# ServiceAccount oluşturma
kubectl create serviceaccount <serviceaccount-adı>

# ServiceAccount listeleme
kubectl get serviceaccounts

# ServiceAccount detaylarını görüntüleme
kubectl describe serviceaccount <serviceaccount-adı>

❓ Soru 16: Kubernetes'te Context nedir?

Cevap: Kubernetes Context, farklı cluster'lara ve namespace'lere erişim için kullanılan yapılandırmalardır.

  • Farklı cluster'lara kolayca geçiş yapmayı sağlar
  • Farklı namespace'lerde çalışmayı kolaylaştırır
  • kubectl config komutu ile yönetilir

Context yönetimi:

# Mevcut context'i görüntüleme
kubectl config current-context

# Tüm context'leri listeleme
kubectl config get-contexts

# Context değiştirme
kubectl config use-context <context-adı>

# Yeni context oluşturma
kubectl config set-context <context-adı> --cluster=<cluster-adı> --user=<kullanıcı-adı> --namespace=<namespace-adı>

❓ Soru 17: Kubernetes'te kubeconfig dosyası nedir?

Cevap: kubeconfig dosyası, cluster'lara erişim için gerekli bilgileri içeren bir yapılandırma dosyasıdır.

  • Cluster'ların URL'lerini içerir
  • Kullanıcı kimlik doğrulama bilgilerini içerir
  • Context'leri tanımlar
  • Varsayılan olarak ~/.kube/config dosyasında bulunur

❓ Soru 18: Kubernetes'te Taint ve Tolerance nedir?

Cevap: Taint, Node'lara uygulanan ve Pod'ların bu Node'larda çalışmasını kısıtlayan bir özelliktir. Tolerance ise Pod'ların Taint'leri tolere etmesini sağlayan bir özelliktir.

  • Taint: Node'lara "NoSchedule", "PreferNoSchedule" veya "NoExecute" etkileri uygular
  • Tolerance: Pod'ların Taint'leri tolere etmesini sağlar

Taint ve Tolerance örneği:

# Node'a taint ekleme
kubectl taint nodes <node-adı> key=value:NoSchedule

# Pod'a tolerance ekleme
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

❓ Soru 19: Kubernetes'te Node Affinity ve Anti-Affinity nedir?

Cevap: Node Affinity, Pod'ların belirli Node'larda çalışmasını sağlayan bir kuraldır. Anti-Affinity ise Pod'ların belirli Node'larda çalışmamasını sağlayan bir kuraldır.

  • requiredDuringSchedulingIgnoredDuringExecution: Zorunlu, scheduling sırasında dikkate alınır
  • preferredDuringSchedulingIgnoredDuringExecution: Tercihli, scheduling sırasında dikkate alınır

Node Affinity örneği:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

❓ Soru 20: Kubernetes'te Resource Quota ve Limit Range nedir?

Cevap: Resource Quota, bir namespace içindeki kaynakların kullanımını sınırlayan bir nesnedir. Limit Range ise Pod ve Container'ların kaynak kullanımını sınırlayan bir nesnedir.

  • Resource Quota: Namespace seviyesinde kaynak sınırlaması
  • Limit Range: Pod ve Container seviyesinde kaynak sınırlaması

Resource Quota örneği:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: my-namespace
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "10"
    limits.memory: 16Gi

Limit Range örneği:

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-memory-limit-range
  namespace: my-namespace
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    max:
      cpu: "1"
      memory: 1Gi
    min:
      cpu: 50m
      memory: 64Mi
    type: Container

Pod'lar ve Container'lar

Pod ve container yönetimi, lifecycle ve yapılandırma ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te Pod nedir ve ne işe yarar?

Cevap: Pod, Kubernetes'te dağıtım ve yönetim için en küçük birimidir. Bir veya daha fazla container'ı içerebilir.

  • Bir veya daha fazla container'ı barındırır
  • Aynı Node üzerinde çalışır
  • Ağ ve depolama kaynaklarını paylaşır
  • Geçici ve değiştirilebilir bir yapıya sahiptir

Pod oluşturma örneği:

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

❓ Soru 2: Bir Pod içinde birden fazla container neden kullanılır?

Cevap: Bir Pod içinde birden fazla container kullanmanın çeşitli nedenleri vardır:

  • Sidecar pattern: Ana uygulama container'ına yardımcı hizmetler sunmak
  • Adapter pattern: Uygulama ile dış dünya arasında arayüz oluşturmak
  • Ambassador pattern: Uygulama ile dış servisler arasında proxy oluşturmak
  • Log collection: Log toplama ve yönetme
  • Monitoring: Uygulama performansını izleme

Multi-container Pod örneği:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app-container
    image: my-app:1.0
    ports:
    - containerPort: 8080
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: log-volume
      mountPath: /var/log
  volumes:
  - name: log-volume
    emptyDir: {}

❓ Soru 3: Kubernetes'te Pod lifecycle aşamaları nelerdir?

Cevap: Kubernetes'te Pod'ların yaşam döngüsü şu aşamalardan oluşur:

  • Pending: Pod oluşturuldu, ancak henüz çalışmıyor
  • Running: Pod'daki container'lar çalışıyor
  • Succeeded: Pod'daki tüm container'lar başarıyla tamamlandı
  • Failed: Pod'daki en az bir container hata ile sonlandı
  • Unknown: Pod durumu bilinmiyor

Pod durumlarını görüntüleme:

# Pod durumlarını listeleme
kubectl get pods

# Pod detaylarını görüntüleme
kubectl describe pod <pod-adı>

# Pod durumunu izleme
kubectl get pods -w

❓ Soru 4: Kubernetes'te Container Restart Policy nedir?

Cevap: Container Restart Policy, container'lar hata verdiğinde ne yapılacağını belirler.

  • Always: Container her zaman yeniden başlatılır (varsayılan)
  • OnFailure: Sadece hata durumunda yeniden başlatılır
  • Never: Container yeniden başlatılmaz

Restart Policy örneği:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-app:1.0
  restartPolicy: OnFailure

❓ Soru 5: Kubernetes'te Init Container nedir?

Cevap: Init Container, ana container'lar başlamadan önce çalışan özel container'lardır.

  • Uygulama başlamadan önce ön koşulları kontrol etmek için kullanılır
  • Veritabanı migrasyonu, yapılandırma dosyalarını oluşturma gibi görevler için kullanılır
  • Sıralı olarak çalışırlar, bir init container tamamlanmadan diğeri başlamaz
  • Tüm init container'lar tamamlanmadan ana container'lar başlamaz

Init Container örneği:

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

❓ Soru 6: Kubernetes'te Pod'lara kaynak limitleri nasıl atanır?

Cevap: Kubernetes'te Pod'lara ve container'lara kaynak limitleri (CPU, memory) atamak için resources bölümü kullanılır.

  • requests: Container'ın ihtiyaç duyduğu minimum kaynak miktarı
  • limits: Container'ın kullanabileceği maksimum kaynak miktarı

Kaynak limitleri örneği:

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

❓ Soru 7: Kubernetes'te Liveness ve Readiness Probe nedir?

Cevap: Liveness ve Readiness Probe, Kubernetes'in container'ların durumunu kontrol etmek için kullandığı mekanizmalardır.

  • Liveness Probe: Container'ın çalışıp çalışmadığını kontrol eder. Hata durumunda container'ı yeniden başlatır.
  • Readiness Probe: Container'ın trafiği kabul edip etmediğini kontrol eder. Hazır değilse trafiği yönlendirmez.

Probe örneği:

apiVersion: v1
kind: Pod
metadata:
  name: probe-pod
spec:
  containers:
  - name: probe-container
    image: nginx
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

❓ Soru 8: Kubernetes'te Pod'lara nasıl ortam değişkenleri atanır?

Cevap: Kubernetes'te Pod'lara ortam değişkenleri atamak için çeşitli yöntemler kullanılır.

  • Doğrudan Pod tanımında env bölümü kullanarak
  • ConfigMap'lerden ortam değişkenleri alarak
  • Secret'lardan ortam değişkenleri alarak

Ortam değişkenleri örneği:

apiVersion: v1
kind: Pod
metadata:
  name: env-pod
spec:
  containers:
  - name: env-container
    image: nginx
    env:
    - name: DATABASE_URL
      value: "postgresql://db:5432/mydb"
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: api-secret
          key: api-key

❓ Soru 9: Kubernetes'te Pod logları nasıl görüntülenir?

Cevap: Kubernetes'te Pod loglarını görüntülemek için kubectl logs komutu kullanılır.

Log görüntüleme komutları:

# Pod loglarını görüntüleme
kubectl logs <pod-adı>

# Pod loglarını takip etme
kubectl logs -f <pod-adı>

# Multi-container Pod'da belirli bir container'ın loglarını görüntüleme
kubectl logs <pod-adı> -c <container-adı>

# Önceki container'ın loglarını görüntüleme
kubectl logs <pod-adı> --previous

# Son 100 satırı görüntüleme
kubectl logs --tail=100 <pod-adı>

# Belirli bir zamandan sonraki logları görüntüleme
kubectl logs --since=1h <pod-adı>

❓ Soru 10: Kubernetes'te Pod'larda hata ayıklama nasıl yapılır?

Cevap: Kubernetes'te Pod'larda hata ayıklama için çeşitli yöntemler kullanılır.

  • describe: Pod detaylarını görüntüleme
  • logs: Pod loglarını görüntüleme
  • exec: Pod içinde komut çalıştırma
  • port-forward: Yerel makineden Pod'a port yönlendirme
  • events: Cluster olaylarını görüntüleme

Hata ayıklama komutları:

# Pod detaylarını görüntüleme
kubectl describe pod <pod-adı>

# Pod içinde shell çalıştırma
kubectl exec -it <pod-adı> -- /bin/bash

# Yerel makineden Pod'a port yönlendirme
kubectl port-forward <pod-adı> <local-port>:<pod-port>

# Cluster olaylarını görüntüleme
kubectl get events --sort-by=.metadata.creationTimestamp

❓ Soru 11: Kubernetes'te Pod'lara Volume nasıl bağlanır?

Cevap: Kubernetes'te Pod'lara Volume bağlamak için volumes ve volumeMounts bölümleri kullanılır.

  • emptyDir: Pod yaşam döngüsü boyunca var olan geçici bir depolama
  • hostPath: Node'un dosya sistemini Pod'a bağlama
  • persistentVolumeClaim: Kalıcı depolama talebi
  • configMap: ConfigMap'i dosya olarak bağlama
  • secret: Secret'ı dosya olarak bağlama

Volume bağlama örneği:

apiVersion: v1
kind: Pod
metadata:
  name: volume-pod
spec:
  containers:
  - name: volume-container
    image: nginx
    volumeMounts:
    - name: html-volume
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html-volume
    emptyDir: {}

❓ Soru 12: Kubernetes'te Pod'lara güvenlik bağlamı (Security Context) nasıl atanır?

Cevap: Kubernetes'te Pod'lara ve container'lara güvenlik bağlamı atamak için securityContext bölümü kullanılır.

  • runAsUser: Container'ı çalıştıracak kullanıcı ID'si
  • runAsGroup: Container'ı çalıştıracak grup ID'si
  • fsGroup: Volume'ların dosya sistemi grup ID'si
  • privileged: Privileged modda çalıştırma
  • readOnlyRootFilesystem: Sadece okunabilir dosya sistemi

Güvenlik bağlamı örneği:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-pod
spec:
  securityContext:
    fsGroup: 2000
  containers:
  - name: security-context-container
    image: nginx
    securityContext:
      runAsUser: 1000
      runAsGroup: 3000
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

❓ Soru 13: Kubernetes'te Pod'lara nasıl kaynak kotası (Resource Quota) atanır?

Cevap: Kubernetes'te Pod'lara kaynak kotası atamak için ResourceQuota nesnesi kullanılır.

  • Namespace seviyesinde kaynak kullanımını sınırlar
  • Pod, Service, PVC gibi nesne sayısını sınırlayabilir
  • CPU, memory, storage gibi kaynakları sınırlayabilir

Resource Quota örneği:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: my-namespace
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "10"
    limits.memory: 16Gi
    persistentvolumeclaims: "5"

❓ Soru 14: Kubernetes'te Pod'lara nasıl ağ politikası (Network Policy) uygulanır?

Cevap: Kubernetes'te Pod'lara ağ politikası uygulamak için NetworkPolicy nesnesi kullanılır.

  • Pod'lar arasındaki ağ trafiğini kontrol eder
  • Gelen (ingress) ve giden (egress) trafiği kısıtlayabilir
  • Label selector ile Pod'ları hedefler

Network Policy örneği:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

❓ Soru 15: Kubernetes'te Pod'lara nasıl pod disruption budget (PDB) uygulanır?

Cevap: Kubernetes'te Pod'lara pod disruption budget (PDB) uygulamak için PodDisruptionBudget nesnesi kullanılır.

  • Planlı kesintiler sırasında uygulamanın çalışmaya devam etmesini sağlar
  • Minimum kullanılabilir Pod sayısını garanti eder
  • Node bakımı gibi işlemler sırasında hizmet kesintisini önler

Pod Disruption Budget örneği:

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

Deployment ve StatefulSet

Uygulama dağıtımı, güncelleme stratejileri ve stateful uygulamalar ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te Deployment nedir ve ne işe yarar?

Cevap: Deployment, Kubernetes'te Pod'ları ve ReplicaSet'leri yönetmek için kullanılan bir nesnedir.

  • Pod'ların istenen sayıda olmasını sağlar
  • Pod'ların durumunu izler ve yeniden oluşturur
  • Uygulama güncellemelerini yönetir
  • Geri alma (rollback) işlemlerini destekler

Deployment oluşturma örneği:

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

❓ Soru 2: Kubernetes'te ReplicaSet nedir ve Deployment ile ilişkisi nedir?

Cevap: ReplicaSet, Kubernetes'te Pod'ların istenen sayıda çalışmasını sağlayan bir denetleyicidir. Deployment, ReplicaSet'leri yönetir.

  • Pod'ların istenen sayıda olmasını sağlar
  • Pod'ları otomatik olarak yeniden oluşturur
  • Deployment, ReplicaSet'leri oluşturur ve yönetir
  • Doğrudan ReplicaSet oluşturmak yerine Deployment kullanmak önerilir

❓ Soru 3: Kubernetes'te Deployment güncelleme stratejileri nelerdir?

Cevap: Kubernetes'te Deployment güncelleme stratejileri şunlardır:

  • RollingUpdate (varsayılan): Eski Pod'ları yavaş yavaş yenileriyle değiştirir
  • Recreate: Tüm eski Pod'ları siler ve yenilerini oluşturur

Güncelleme stratejisi örneği:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    # ...

❓ Soru 4: Kubernetes'te Deployment nasıl geri alınır (rollback)?

Cevap: Kubernetes'te Deployment geri almak için kubectl rollout undo komutu kullanılır.

Geri alma komutları:

# Deployment geçmişini görüntüleme
kubectl rollout history deployment/<deployment-adı>

# Deployment'ı önceki sürüme geri alma
kubectl rollout undo deployment/<deployment-adı>

# Deployment'ı belirli bir revizyona geri alma
kubectl rollout undo deployment/<deployment-adı> --to-revision=<revizyon-numarası>

❓ Soru 5: Kubernetes'te StatefulSet nedir ve Deployment'dan farkı nedir?

Cevap: StatefulSet, durumlu (stateful) uygulamaları yönetmek için kullanılan bir nesnedir. Deployment'dan farkları şunlardır:

  • Pod'ların öngörülebilir ve benzersiz isimleri vardır
  • Pod'ların öngörülebilir ve sıralı oluşturulması, güncellenmesi ve silinmesi sağlanır
  • Pod'ların kararlı ve benzersiz ağ kimlikleri vardır
  • Pod'ların kararlı ve kalıcı depolamaları vardır
  • Veritabanı, mesaj kuyruğu gibi durumlu uygulamalar için kullanılır

❓ Soru 6: Kubernetes'te StatefulSet için Headless Service nedir?

Cevap: Headless Service, StatefulSet Pod'ları için ağ kimliği sağlayan bir Service türüdür.

  • clusterIP'si None olarak ayarlanır
  • Doğrudan Pod'lara DNS sorguları yapılmasını sağlar
  • StatefulSet Pod'ları arasında keşif (discovery) sağlar

Headless Service örneği:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

❓ Soru 7: Kubernetes'te StatefulSet için Volume Claim Template nedir?

Cevap: Volume Claim Template, StatefulSet'teki her Pod için ayrı bir PersistentVolumeClaim oluşturan bir şablondur.

  • Her Pod için benzersiz bir PersistentVolumeClaim oluşturur
  • Pod'lar silindiğinde PersistentVolumeClaim'ler korunur
  • Veri kalıcılığını sağlar

Volume Claim Template örneği:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

❓ Soru 8: Kubernetes'te DaemonSet nedir ve ne işe yarar?

Cevap: DaemonSet, her Node'da (veya belirli Node'larda) bir Pod çalıştıran bir nesnedir.

  • Her Node'da bir Pod çalıştırır
  • Yeni Node'lar eklendiğinde otomatik olarak bu Node'larda Pod oluşturur
  • Node'lar silindiğinde bu Node'lardaki Pod'ları temizler
  • Log toplama, monitoring, ağ eklentileri gibi sistem seviyesi görevler için kullanılır

DaemonSet örneği:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2

❓ Soru 9: Kubernetes'te Job nedir ve ne işe yarar?

Cevap: Job, Kubernetes'te bir veya daha fazla Pod oluşturan ve bu Pod'ların başarıyla tamamlanmasını sağlayan bir nesnedir.

  • Batch işleri için kullanılır
  • Pod'ların başarıyla tamamlanmasını garanti eder
  • Belirli sayıda başarı tamamlanmasını sağlar
  • Veritabanı migrasyonu, veri işleme gibi görevler için kullanılır

Job örneği:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

❓ Soru 10: Kubernetes'te CronJob nedir ve ne işe yarar?

Cevap: CronJob, Kubernetes'te zamanlanmış Job'lar oluşturan bir nesnedir.

  • Zamanlanmış görevler için kullanılır
  • Cron formatında zamanlama yapar
  • Veritabanı yedekleme, rapor oluşturma gibi periyodik görevler için kullanılır

CronJob örneği:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

❓ Soru 11: Kubernetes'te Deployment durumunu nasıl kontrol edilir?

Cevap: Kubernetes'te Deployment durumunu kontrol etmek için çeşitli komutlar kullanılır.

Durum kontrol komutları:

# Deployment durumunu görüntüleme
kubectl rollout status deployment/<deployment-adı>

# Deployment detaylarını görüntüleme
kubectl describe deployment <deployment-adı>

# Deployment geçmişini görüntüleme
kubectl rollout history deployment/<deployment-adı>

# Deployment revizyon detaylarını görüntüleme
kubectl rollout history deployment/<deployment-adı> --revision=<revizyon-numarası>

❓ Soru 12: Kubernetes'te Deployment güncellemesi nasıl durdurulur?

Cevap: Kubernetes'te Deployment güncellemesini durdurmak için kubectl rollout pause komutu kullanılır.

Güncelleme durdurma komutları:

# Deployment güncellemesini durdurma
kubectl rollout pause deployment/<deployment-adı>

# Deployment güncellemesini devam ettirme
kubectl rollout resume deployment/<deployment-adı>

❓ Soru 13: Kubernetes'te Deployment ölçeği nasıl ayarlanır?

Cevap: Kubernetes'te Deployment ölçeğini ayarlamak için kubectl scale komutu veya YAML dosyası kullanılır.

Ölçeklendirme komutları:

# Deployment ölçeğini ayarlama
kubectl scale deployment <deployment-adı> --replicas=<replica-sayısı>

# Otomatik ölçeklendirme (Horizontal Pod Autoscaler) oluşturma
kubectl autoscale deployment <deployment-adı> --min=<minimum-replica> --max=<maksimum-replica> --cpu-percent=<cpu-yüzdesi>

❓ Soru 14: Kubernetes'te StatefulSet ölçeği nasıl ayarlanır?

Cevap: Kubernetes'te StatefulSet ölçeğini ayarlamak için kubectl scale komutu kullanılır.

Ölçeklendirme komutları:

# StatefulSet ölçeğini ayarlama
kubectl scale statefulset <statefulset-adı> --replicas=<replica-sayısı>

# StatefulSet ölçeğini artırma (sıralı olarak)
kubectl scale statefulset <statefulset-adı> --replicas=<replica-sayısı> --current-replicas=<mevcut-replica-sayısı>

❓ Soru 15: Kubernetes'te Deployment ve StatefulSet için hangi durumlarda hangisi tercih edilmelidir?

Cevap: Deployment ve StatefulSet arasında seçim yaparken şu faktörler dikkate alınmalıdır:

  • Deployment tercih edilir:
    • Stateless (durumsuz) uygulamalar için
    • Web sunucuları, API'ler gibi uygulamalar için
    • Hızlı ölçeklendirme ve güncelleme gerektiren uygulamalar için
  • StatefulSet tercih edilir:
    • Stateful (durumlu) uygulamalar için
    • Veritabanları, mesaj kuyrukları gibi uygulamalar için
    • Stable network identifier ve persistent storage gerektiren uygulamalar için

Service ve Networking

Kubernetes'de servisler, ağ iletişimi ve trafik yönetimi ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te Service nedir ve ne işe yarar?

Cevap: Kubernetes'te Service, bir grup Pod'a ağ erişimi sağlayan bir nesnedir.

  • Pod'lara stable network identity sağlar
  • Pod'lar arasında yük dengeleme yapar
  • Pod'ların değişmesine rağmen erişilebilirliği sağlar
  • Service discovery imkanı sunar

Service oluşturma örneği:

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

❓ Soru 2: Kubernetes'te Service türleri nelerdir?

Cevap: Kubernetes'te Service türleri şunlardır:

  • ClusterIP (varsayılan): Sadece cluster içinden erişilebilen bir IP adresi atar
  • NodePort: Her Node'un aynı portunu dışarıya açar
  • LoadBalancer: Bulut sağlayıcının load balancer'ını kullanır
  • ExternalName: Dış bir servisin CNAME kaydını döndürür

❓ Soru 3: Kubernetes'te ClusterIP Service nasıl çalışır?

Cevap: ClusterIP Service, Kubernetes cluster'ı içinden erişilebilen bir IP adresi sağlar.

  • Sadece cluster içinden erişilebilir
  • Kube-proxy tarafından iptables veya IPVS kurallarıyla yönetilir
  • Pod'lar arasında yük dengeleme yapar

ClusterIP Service örneği:

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

❓ Soru 4: Kubernetes'te NodePort Service nasıl çalışır?

Cevap: NodePort Service, her Node'un aynı portunu dışarıya açarak dışarıdan erişim sağlar.

  • Her Node'da aynı port numarasını açar (30000-32767 aralığında)
  • Dışarıdan herhangi bir Node IP'si ve bu port üzerinden erişim sağlar
  • Trafik otomatik olarak ilgili Pod'lara yönlendirilir

NodePort Service örneği:

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080
    nodePort: 30007

❓ Soru 5: Kubernetes'te LoadBalancer Service nasıl çalışır?

Cevap: LoadBalancer Service, bulut sağlayıcının load balancer'ını kullanarak dışarıdan erişim sağlar.

  • Bulut sağlayıcının (AWS, GCP, Azure) load balancer'ını kullanır
  • Dışarıdan erişim için bir dış IP adresi atar
  • Tüm Node'lara trafik dağıtır
  • Üretim ortamlarında dışarıya açılan servisler için kullanılır

LoadBalancer Service örneği:

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

❓ Soru 6: Kubernetes'te ExternalName Service nasıl çalışır?

Cevap: ExternalName Service, dış bir servisin CNAME kaydını döndüren bir Service türüdür.

  • Dış bir servise (veritabanı, dış API vb.) erişim için kullanılır
  • Cluster içinden bu servise erişmek için bir DNS adı sağlar
  • Herhangi bir port veya selector tanımlanmaz

ExternalName Service örneği:

apiVersion: v1
kind: Service
metadata:
  name: my-database-service
spec:
  type: ExternalName
  externalName: my-database.example.com

❓ Soru 7: Kubernetes'te Ingress nedir ve ne işe yarar?

Cevap: Kubernetes'te Ingress, cluster dışından HTTP ve HTTPS trafiğini cluster içine yönlendiren bir nesnedir.

  • HTTP ve HTTPS trafiğini yönetir
  • Host ve path bazlı yönlendirme yapar
  • SSL termination sağlar
  • Tek bir IP adresinden birden fazla servise erişim sağlar

Ingress örneği:

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

❓ Soru 8: Kubernetes'te Ingress Controller nedir?

Cevap: Kubernetes'te Ingress Controller, Ingress kaynaklarını uygulayan ve gelen trafiği yönlendiren bir bileşendir.

  • Ingress kaynaklarını okur ve uygular
  • Gelen trafiği ilgili servislere yönlendirir
  • Popüler Ingress Controller'lar: Nginx, Traefik, HAProxy, Istio
  • Cluster'a Ingress Controller kurulumu gerekir

Nginx Ingress Controller kurulumu:

# Nginx Ingress Controller kurulumu
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/cloud/deploy.yaml

❓ Soru 9: Kubernetes'te Network Policy nedir ve ne işe yarar?

Cevap: Kubernetes'te Network Policy, Pod'lar arasındaki ağ trafiğini kontrol eden bir nesnedir.

  • Pod'lar arasındaki iletişimi kısıtlar
  • Gelen (ingress) ve giden (egress) trafiği kontrol eder
  • Güvenlik politikaları uygular
  • Network plugin'inin bu özelliği desteklemesi gerekir (Calico, Weave Net, Cilium)

Network Policy örneği:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: backend

❓ Soru 10: Kubernetes'te Headless Service nedir ve ne işe yarar?

Cevap: Kubernetes'te Headless Service, clusterIP'si olmayan ve doğrudan Pod'lara DNS sorguları yapılmasını sağlayan bir Service türüdür.

  • clusterIP'si None olarak ayarlanır
  • Doğrudan Pod'lara DNS sorguları yapılmasını sağlar
  • StatefulSet'ler ile birlikte kullanılır
  • Her Pod için ayrı bir DNS kaydı oluşturur

Headless Service örneği:

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None
  selector:
    app: my-app
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080

❓ Soru 11: Kubernetes'te Service discovery nasıl çalışır?

Cevap: Kubernetes'te Service discovery, DNS ve environment variables kullanılarak çalışır.

  • DNS: Kubernetes, her Service için DNS kayıtları oluşturur
  • Environment Variables: Pod oluşturulduğunda diğer Service'ler için environment variables oluşturulur

Service discovery örneği:

# Service DNS sorgusu
nslookup my-service.default.svc.cluster.local

# Pod içinde environment variables görüntüleme
kubectl exec -it <pod-adı> -- env | grep SERVICE

❓ Soru 12: Kubernetes'te EndpointSlice nedir ve ne işe yarar?

Cevap: Kubernetes'te EndpointSlice, bir Service'in arkasındaki Pod'ların IP adreslerini ve portlarını içeren bir nesnedir.

  • Service'ler için Endpoint'leri yönetir
  • Büyük ölçekli sistemlerde daha performanslıdır
  • Endpoint'leri daha küçük parçalara böler
  • Topolojik olarak dağıtık Endpoint'leri yönetir

❓ Soru 13: Kubernetes'te Ingress için SSL/TLS nasıl yapılandırılır?

Cevap: Kubernetes'te Ingress için SSL/TLS yapılandırmak için Secret nesneleri kullanılır.

  • Sertifika ve özel anahtar bir Secret içinde saklanır
  • Ingress tanımında bu Secret referans edilir
  • Gelen HTTPS trafiği Ingress Controller tarafından sonlandırılır

SSL/TLS yapılandırma örneği:

# TLS Secret oluşturma
kubectl create secret tls my-tls-secret --key my-tls.key --cert my-tls.crt
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
spec:
  tls:
  - hosts:
    - my-app.example.com
    secretName: my-tls-secret
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

❓ Soru 14: Kubernetes'te Service için Session Affinity nasıl ayarlanır?

Cevap: Kubernetes'te Service için Session Affinity, bir istemcinin tüm isteklerini aynı Pod'a yönlendirmek için kullanılır.

  • Client IP'ye göre oturum benzerliği sağlar
  • Stateless uygulamalarda oturum durumunu korumak için kullanılır
  • sessionAffinity: ClientIP ve sessionAffinityConfig: ClientIP yapılandırması kullanılır

Session Affinity örneği:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600

❓ Soru 15: Kubernetes'te Ingress için path-based routing nasıl yapılandırılır?

Cevap: Kubernetes'te Ingress için path-based routing, farklı URL yollarını farklı servislere yönlendirmek için kullanılır.

  • Farklı path'ler için farklı backend'ler tanımlanır
  • Gelen isteklerin URL yollarına göre yönlendirme yapılır
  • Tek bir domain altında birden fazla servise erişim sağlar

Path-based routing örneği:

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

ConfigMap ve Secret

Yapılandırma yönetimi ve hassas verilerin depolanması ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te ConfigMap nedir ve ne işe yarar?

Cevap: Kubernetes'te ConfigMap, yapılandırma verilerini (örneğin, ortam değişkenleri, yapılandırma dosyaları) depolamak için kullanılan bir nesnedir.

  • Yapılandırma verilerini Pod'lardan ayırır
  • Ortam değişkenleri, komut satırı argümanları veya yapılandırma dosyaları olarak kullanılabilir
  • Uygulama kodunu değiştirmeden yapılandırmayı güncellemeye olanak tanır
  • Yapılandırma verilerini version kontrol sistemlerinde saklamaya olanak tanır

ConfigMap oluşturma örneği:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  # key-value çiftleri olarak özellikler
  database_url: "postgresql://db:5432/mydb"
  # yapılandırma dosyası olarak
  application.properties: |
    server.port=8080
    spring.datasource.url=jdbc:postgresql://db:5432/mydb

❓ Soru 2: Kubernetes'te Secret nedir ve ConfigMap'den farkı nedir?

Cevap: Kubernetes'te Secret, hassas verileri (şifreler, API anahtarları, token'lar) depolamak için kullanılan bir nesnedir.

  • Secret: Hassas verileri depolar, veriler base64 ile kodlanır
  • ConfigMap: Hassas olmayan yapılandırma verilerini depolar, veriler düz metin olarak saklanır
  • Secret'lar daha güvenli bir şekilde saklanır ve kullanılır
  • Secret'lar otomatik olarak Pod'lara mount edilebilir veya ortam değişkenleri olarak kullanılabilir

Secret oluşturma örneği:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  # base64 ile kodlanmış değerler
  username: YWRtaW4=  # admin
  password: MWYyZDFlMmU2N2Rm  # 1f2d1e2e67df

❓ Soru 3: Kubernetes'te ConfigMap ve Secret nasıl oluşturulur?

Cevap: Kubernetes'te ConfigMap ve Secret'ler farklı şekillerde oluşturulabilir.

YAML dosyası ile oluşturma:

# ConfigMap oluşturma
kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

# Dosyadan ConfigMap oluşturma
kubectl create configmap my-config --from-file=path/to/config-file

# Secret oluşturma
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret

# Dosyadan Secret oluşturma
kubectl create secret generic my-secret --from-file=path/to/secret-file

❓ Soru 4: Kubernetes'te ConfigMap ve Secret'lar Pod'lara nasıl bağlanır?

Cevap: Kubernetes'te ConfigMap ve Secret'lar Pod'lara ortam değişkenleri veya volume olarak bağlanabilir.

Ortam değişkeni olarak kullanma:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: DATABASE_URL
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: database_url
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

Volume olarak kullanma:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
    - name: secret-volume
      mountPath: /etc/secret
  volumes:
  - name: config-volume
    configMap:
      name: my-config
  - name: secret-volume
    secret:
      secretName: my-secret

❓ Soru 5: Kubernetes'te ConfigMap ve Secret'lar nasıl güncellenir?

Cevap: Kubernetes'te ConfigMap ve Secret'lar güncellendiğinde, bu değişikliklerin Pod'lara yansıması bağlama yöntemine bağlıdır.

  • Ortam değişkenleri olarak kullanılan ConfigMap ve Secret'lar: Güncellenmez, Pod'ların yeniden başlatılması gerekir
  • Volume olarak bağlanan ConfigMap ve Secret'lar: Otomatik olarak güncellenir, ancak uygulamanın bu değişiklikleri algılaması gerekir

ConfigMap güncelleme komutları:

# ConfigMap güncelleme
kubectl edit configmap <configmap-adı>

# ConfigMap'i dosyadan güncelleme
kubectl create configmap <configmap-adı> --from-file=path/to/config-file --dry-run=client -o yaml | kubectl apply -f -

# Secret güncelleme
kubectl edit secret <secret-adı>

❓ Soru 6: Kubernetes'te Secret türleri nelerdir?

Cevap: Kubernetes'te farklı kullanım amaçları için çeşitli Secret türleri vardır.

  • Opaque (varsayılan): Key-value çiftleri için kullanılır
  • kubernetes.io/service-account-token: Service Account token'ları için kullanılır
  • kubernetes.io/dockercfg: Docker registry kimlik doğrulama için kullanılır
  • kubernetes.io/dockerconfigjson: Docker registry JSON yapılandırması için kullanılır
  • kubernetes.io/basic-auth: Temel kimlik doğrulama için kullanılır
  • kubernetes.io/ssh-auth: SSH kimlik doğrulama için kullanılır
  • kubernetes.io/tls: TLS sertifikaları için kullanılır
  • bootstrap.kubernetes.io/token: Bootstrap token'ları için kullanılır

Docker registry Secret örneği:

apiVersion: v1
kind: Secret
metadata:
  name: registry-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6eyJyZWdpc3RyeS5leGFtcGxlLmNvbSI6eyJ1c2VybmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJwYXNzd29yZCIsImF1dGgiOiJjbUZqYjI1MFpXNTBhV1Y1UFNKT2FtTnZkWE5rTnpJPSJ9fX0=

❓ Soru 7: Kubernetes'te ConfigMap ve Secret'lar için Immutable seçeneği ne işe yarar?

Cevap: Kubernetes'te ConfigMap ve Secret'lar için Immutable seçeneği, bu nesnelerin değiştirilemez olmasını sağlar.

  • Immutable ConfigMap ve Secret'lar oluşturulduktan sonra değiştirilemez
  • Güncelleme yapmak için yeni bir nesne oluşturulmalıdır
  • Performansı artırır, çünkü Kubernetes bu nesneleri izlemek zorunda kalmaz
  • İstemci tarafında önbelleğe alma için daha güvenlidir

Immutable ConfigMap örneği:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-immutable-config
  immutable: true
data:
  key1: value1
  key2: value2

❓ Soru 8: Kubernetes'te ConfigMap ve Secret'lar için envFrom kullanımı nasıl yapılır?

Cevap: Kubernetes'te envFrom, ConfigMap veya Secret'teki tüm key-value çiftlerini ortam değişkenleri olarak Pod'a eklemek için kullanılır.

  • ConfigMap veya Secret'teki tüm anahtarları ortam değişkenleri olarak ekler
  • Birden çok ConfigMap veya Secret için kullanılabilir
  • Önek (prefix) ekleyerek ortam değişkeni adlarını değiştirebilir

envFrom kullanımı örneği:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    envFrom:
    - configMapRef:
        name: my-config
    - secretRef:
        name: my-secret
    - prefix: CONFIG_
      configMapRef:
        name: my-config-with-prefix

❓ Soru 9: Kubernetes'te ConfigMap ve Secret'lar için subPath kullanımı nasıl yapılır?

Cevap: Kubernetes'te subPath, ConfigMap veya Secret'teki tek bir dosyayı Pod'daki belirli bir yola bağlamak için kullanılır.

  • ConfigMap veya Secret'teki belirli bir anahtarı dosya olarak bağlar
  • Pod'daki belirli bir yola bağlar
  • Diğer dosyaların üzerine yazılmasını önler

subPath kullanımı örneği:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config/my-config-file
      subPath: my-config-file
  volumes:
  - name: config-volume
    configMap:
      name: my-config
      items:
      - key: my-config-file
        path: my-config-file

❓ Soru 10: Kubernetes'te ConfigMap ve Secret'lar için en iyi güvenlik uygulamaları nelerdir?

Cevap: Kubernetes'te ConfigMap ve Secret'lar için en iyi güvenlik uygulamaları şunlardır:

  • Hassas veriler için ConfigMap yerine Secret kullanın
  • Secret'ları version kontrol sistemlerinde saklamayın
  • Secret'ları şifrelemek için Kubernetes Encryption Configuration kullanın
  • En az prensibini uygulayın, yalnızca gerekli izinleri verin
  • Secret'ları düzenli olarak döndürün (rotate)
  • Secret'ları Pod'lara bağlarken salt okunur (read-only) olarak mount edin
  • Immutable ConfigMap ve Secret'lar kullanarak performansı ve güvenliği artırın

Persistent Storage

Kalıcı veri depolama ve volume yönetimi ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te PersistentVolume (PV) nedir ve ne işe yarar?

Cevap: Kubernetes'te PersistentVolume (PV), cluster yöneticisi tarafından sağlanan bir depolama kaynağıdır.

  • Cluster'daki fiziksel depolama kaynaklarını temsil eder
  • NFS, iSCSI, FC, GCE Persistent Disk, AWS EBS, Azure Disk gibi çeşitli depolama türlerini destekler
  • Cluster yöneticisi tarafından provision edilir (statik provision)
  • Pod'ların yaşam döngüsünden bağımsız olarak veri kalıcılığını sağlar

PersistentVolume oluşturma örneği:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

❓ Soru 2: Kubernetes'te PersistentVolumeClaim (PVC) nedir ve ne işe yarar?

Cevap: Kubernetes'te PersistentVolumeClaim (PVC), kullanıcıların depolama taleplerini belirtmek için kullandığı bir nesnedir.

  • Kullanıcıların depolama ihtiyaçlarını (boyut, erişim modu vb.) belirtmesine olanak tanır
  • PVC, uygun PV ile otomatik olarak eşleştirilir
  • Pod'lar PVC'leri kullanarak depolama kaynaklarına bağlanır
  • Uygulama geliştiricilerin depolama detaylarından soyutlanmasını sağlar

PersistentVolumeClaim oluşturma örneği:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow

❓ Soru 3: Kubernetes'te StorageClass nedir ve ne işe yarar?

Cevap: Kubernetes'te StorageClass, depolama kaynaklarının dinamik provision edilmesini sağlayan bir nesnedir.

  • Depolama türlerini (fast, slow, ssd, hdd vb.) tanımlar
  • Dinamik provision için kullanılır
  • Volume provisioner'ı (örneğin, kubernetes.io/aws-ebs, kubernetes.io/gce-pd) belirtir
  • Parametreler (replication, IOPS, vb.) tanımlanabilir
  • PVC oluşturulurken StorageClass belirtilerek otomatik PV oluşturulur

StorageClass oluşturma örneği:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  replicationtype: "regional"
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - debug
volumeBindingMode: Immediate

❓ Soru 4: Kubernetes'te PersistentVolume erişim modları nelerdir?

Cevap: Kubernetes'te PersistentVolume erişim modları, bir PV'ye nasıl erişilebileceğini belirler.

  • ReadWriteOnce (RWO): Volume'ü tek bir Node'da okuma/yazma için bağlanabilir
  • ReadOnlyMany (ROX): Volume'ü birçok Node'da salt okunur olarak bağlanabilir
  • ReadWriteMany (RWX): Volume'ü birçok Node'da okuma/yazma için bağlanabilir
  • ReadWriteOncePod (RWOP): Volume'ü tek bir Pod'da okuma/yazma için bağlanabilir (Kubernetes 1.22+)

❓ Soru 5: Kubernetes'te PersistentVolume geri kazanım politikaları nelerdir?

Cevap: Kubernetes'te PersistentVolume geri kazanım politikaları, PVC silindiğinde PV'ye ne olacağını belirler.

  • Retain (tut): PV ve veri korunur, PVC silinir ancak PV serbest kalır ve manuel olarak yeniden kullanılabilir
  • Delete (sil): PV ve ilişkili depolama kaynağı (AWS EBS, GCE PD vb.) silinir
  • Recycle (geri dönüştür): PV'deki veriler temizlenir ve PV yeni bir PVC için kullanılabilir hale gelir (çoğu provisioner tarafından desteklenmez)

❓ Soru 6: Kubernetes'te Volume türleri nelerdir?

Cevap: Kubernetes'te farklı kullanım amaçları için çeşitli volume türleri vardır.

  • emptyDir: Pod yaşam döngüsü boyunca var olan geçici bir depolama alanı
  • hostPath: Node'un dosya sistemini Pod'a bağlar
  • persistentVolumeClaim: PersistentVolumeClaim'i Pod'a bağlar
  • configMap: ConfigMap'i dosya olarak Pod'a bağlar
  • secret: Secret'ı dosya olarak Pod'a bağlar
  • downwardAPI: Pod ve container bilgilerini dosya olarak Pod'a bağlar
  • projected: Birden fazla volume kaynağını birleştirir
  • nfs: NFS paylaşımını Pod'a bağlar
  • iscsi: iSCSI diskini Pod'a bağlar
  • glusterfs: GlusterFS dosya sistemini Pod'a bağlar
  • rbd: Ceph RBD blok cihazını Pod'a bağlar
  • flexVolume: Kendi volume driver'ınızı kullanmanıza olanak tanır
  • azureFile, azureDisk, cinder, vsphereVolume, vsphereVirtualDiskVolume, portworxVolume, scaleIO, storageos, quobyte: Bulut sağlayıcı ve üçüncü taraf depolama çözümleri için volume türleri

❓ Soru 7: Kubernetes'te Volume'ler Pod'lara nasıl bağlanır?

Cevap: Kubernetes'te Volume'ler Pod'lara volumes ve volumeMounts bölümleri kullanılarak bağlanır.

Volume bağlama örneği:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: my-persistent-storage
      mountPath: /data
    - name: my-config-volume
      mountPath: /etc/config
  volumes:
  - name: my-persistent-storage
    persistentVolumeClaim:
      claimName: my-pvc
  - name: my-config-volume
    configMap:
      name: my-config

❓ Soru 8: Kubernetes'te StatefulSet'ler için Volume Claim Template nedir?

Cevap: Kubernetes'te StatefulSet'ler için Volume Claim Template, StatefulSet'teki her Pod için ayrı bir PersistentVolumeClaim oluşturan bir şablondur.

  • Her Pod için benzersiz bir PersistentVolumeClaim oluşturur
  • Pod'lar silindiğinde PersistentVolumeClaim'ler korunur
  • Veri kalıcılığını sağlar
  • StatefulSet Pod'ları yeniden oluşturulduğunda aynı PersistentVolumeClaim'leri kullanır

Volume Claim Template örneği:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

❓ Soru 9: Kubernetes'te PersistentVolume'lar nasıl izlenir ve yönetilir?

Cevap: Kubernetes'te PersistentVolume'ları izlemek ve yönetmek için çeşitli komutlar kullanılır.

PersistentVolume yönetimi komutları:

# PersistentVolume'ları listeleme
kubectl get pv

# PersistentVolume detaylarını görüntüleme
kubectl describe pv <pv-adı>

# PersistentVolumeClaim'leri listeleme
kubectl get pvc

# PersistentVolumeClaim detaylarını görüntüleme
kubectl describe pvc <pvc-adı>

# StorageClass'ları listeleme
kubectl get sc

# StorageClass detaylarını görüntüleme
kubectl describe sc <storageclass-adı>

# PVC'yi PV ile eşleştirme durumunu kontrol etme
kubectl get pv,pvc -o wide

❓ Soru 10: Kubernetes'te PersistentVolume boyutunu nasıl genişletirsiniz?

Cevap: Kubernetes'te PersistentVolume boyutunu genişletmek için StorageClass ve PVC güncellemesi yapılır.

  • StorageClass'te allowVolumeExpansion: true olarak ayarlanmalıdır
  • PVC'nin resources.requests.storage alanı güncellenir
  • Desteklenen depolama türleri: AWS EBS, GCE PD, Azure Disk, Cinder, vSphere, GlusterFS, Ceph RBD
  • Pod'ların yeniden başlatılması gerekmez, ancak bazı durumlarda dosya sistemini yeniden boyutlandırmak gerekebilir

PVC boyutunu genişletme örneği:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-expandable-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi  # Önceki değer 10Gi idi, 20Gi'ye çıkarıldı
  storageClassName: expandable-storage

Helm ve Package Management

Kubernetes uygulamalarını paketleme ve yönetme ile ilgili sorular ve cevaplar.

❓ Soru 1: Helm nedir ve ne işe yarar?

Cevap: Helm, Kubernetes uygulamalarını paketlemek, yapılandırmak ve dağıtmak için kullanılan bir paket yöneticisidir.

  • "Kubernetes için apt/yum/homebrew" olarak bilinir
  • Kubernetes uygulamalarını "Charts" adı verilen paketler halinde paketler
  • Karmaşık uygulamaları kolayca yönetmeyi sağlar
  • Uygulama sürümlerini yönetir ve güncellemeleri kolaylaştırır
  • Paylaşılan depolar (repositories) aracılığıyla uygulamaları dağıtır

❓ Soru 2: Helm Chart'ın yapısı nasıldır?

Cevap: Helm Chart'ı, Kubernetes uygulamalarını paketlemek için kullanılan dosya koleksiyonudur.

  • Chart.yaml: Chart'ın meta bilgilerini içerir (ad, versiyon, açıklama vb.)
  • values.yaml: Chart için varsayılan yapılandırma değerlerini içerir
  • templates/: Kubernetes manifest dosyalarını içerir (Deployment, Service, Ingress vb.)
  • charts/: Bu Chart'ın bağımlı olduğu diğer Chart'ları içerir
  • .helmignore: Paketlenmeyecek dosyaları belirtir
  • NOTES.txt: Kurulumdan sonra gösterilen bilgileri içerir
  • requirements.yaml (Helm 2'de): Chart bağımlılıklarını tanımlar

Chart.yaml örneği:

apiVersion: v2
name: my-chart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.0.0"
keywords:
  - my-app
  - kubernetes
home: https://my-app.example.com
sources:
  - https://github.com/my-org/my-app
maintainers:
  - name: John Doe
    email: john@example.com

❓ Soru 3: Helm 2 ve Helm 3 arasındaki temel farklar nelerdir?

Cevap: Helm 2 ve Helm 3 arasında önemli farklar vardır:

  • Tiller: Helm 2'de Tiller adında bir sunucu component'i vardı, Helm 3'te kaldırıldı
  • Release bilgileri: Helm 2'de Tiller'da saklanırdı, Helm 3'te Kubernetes'te Secret olarak saklanır
  • Chart bağımlılıkları: Helm 2'de requirements.yaml kullanılırdı, Helm 3'te Chart.yaml içinde dependencies bölümü kullanılır
  • Güvenlik: Helm 3'te RBAC ve güvenlik iyileştirmeleri yapıldı
  • Kütüphane: Helm 3'te Go kütüphanesi yeniden yazıldı

❓ Soru 4: Helm ile Chart nasıl oluşturulur ve paketlenir?

Cevap: Helm ile Chart oluşturmak ve paketlemek için şu adımlar izlenir:

Chart oluşturma:

# Yeni bir Chart oluşturma
helm create my-chart

# Mevcut bir dizinden Chart oluşturma
helm create .

Chart paketleme:

# Chart'ı paketleme
helm package my-chart

# Chart'ı belirli bir dizine paketleme
helm package my-chart -d /path/to/directory

# Chart'ı imzlayarak paketleme
helm package --sign --key keyname --keyring path/to/keyring my-chart

❓ Soru 5: Helm ile Chart nasıl kurulur ve yönetilir?

Cevap: Helm ile Chart'ları kurmak ve yönetmek için çeşitli komutlar kullanılır.

Chart kurulumu ve yönetimi:

# Depo ekleme
helm repo add stable https://charts.helm.sh/stable

# Depo güncelleme
helm repo update

# Chart kurulumu
helm install my-release stable/nginx-ingress

# Varsayılan değerleri özelleştirerek kurulum
helm install my-release -f values.yaml stable/nginx-ingress

# Sürüm yükseltme
helm upgrade my-release stable/nginx-ingress

# Sürüm geçmişi
helm history my-release

# Sürümü önceki bir sürüme geri alma
helm rollback my-release 1

# Sürümü kaldırma
helm uninstall my-release

# Kurulu sürümleri listeleme
helm list

# Tüm sürümleri listeleme
helm list --all

Monitoring ve Logging

Kubernetes cluster'ını izleme ve log yönetimi ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te monitoring için hangi araçlar kullanılır?

Cevap: Kubernetes'te monitoring için çeşitli araçlar kullanılır:

  • Prometheus: Metrik toplama ve depolama için popüler bir açık kaynaklı monitoring çözümü
  • Grafana: Metrikleri görselleştirmek için kullanılan bir dashboard aracı
  • Alertmanager: Prometheus'tan gelen uyarıları yönetmek için kullanılır
  • Metrics Server: Cluster kaynak kullanımı metriklerini toplar (CPU, memory)
  • Node Exporter: Node'ların donanım ve işletim sistemi metriklerini toplar
  • Kube State Metrics: Kubernetes nesnelerinin (Deployment, Pod, vb.) metriklerini toplar
  • Jaeger/Zipkin: Dağıtık izleme (distributed tracing) için kullanılır

❓ Soru 2: Kubernetes'te logging için hangi araçlar kullanılır?

Cevap: Kubernetes'te logging için çeşitli araçlar kullanılır:

  • ELK Stack (Elasticsearch, Logstash, Kibana): Popüler bir log yönetimi çözümü
  • EFK Stack (Elasticsearch, Fluentd, Kibana): Fluentd ile log toplama
  • Fluent Bit: Hafif bir log forwarder ve processor
  • Loki: Grafana Labs tarafından geliştirilen bir log toplama sistemi
  • Promtail: Loki ile birlikte kullanılan bir log toplama aracı
  • Splunk: Kurumsal bir log yönetimi çözümü
  • Graylog: Açık kaynaklı bir log yönetimi platformu

❓ Soru 3: Kubernetes'te Prometheus nasıl kurulur ve yapılandırılır?

Cevap: Kubernetes'te Prometheus kurulumu ve yapılandırması şu şekildedir:

Prometheus kurulumu:

# Helm kullanarak Prometheus kurulumu
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack

# Manuel kurulum için YAML dosyaları
kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/master/bundle.yaml

Prometheus yapılandırması:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: monitoring
spec:
  serviceMonitorSelector:
    matchLabels:
      team: frontend
  resources:
    requests:
      memory: 400Mi
  enableAdminAPI: false

❓ Soru 4: Kubernetes'te ServiceMonitor nedir ve nasıl kullanılır?

Cevap: Kubernetes'te ServiceMonitor, Prometheus'un hangi servisleri izleyeceğini belirten bir nesnedir.

  • ServiceMonitor, Prometheus Operator tarafından kullanılır
  • Hangi servislerin izleneceğini, hangi metriklerin toplanacağını ve hangi portların kullanılacağını belirtir
  • ServiceMonitor'lar otomatik olarak Prometheus tarafından keşfedilir

ServiceMonitor örneği:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: monitoring
  labels:
    app: my-app
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: web
    interval: 30s
    path: /metrics

❓ Soru 5: Kubernetes'te log toplama nasıl yapılır?

Cevap: Kubernetes'te log toplama için çeşitli yöntemler kullanılır:

  • Node-level logging agent: Her Node'da bir log toplama aracı çalıştırma (Fluentd, Fluent Bit)
  • Sidecar container: Her Pod'da log toplama için bir container çalıştırma
  • Direct log shipping: Uygulamaların doğrudan logları merkezi bir sisteme göndermesi

Fluentd DaemonSet ile log toplama örneği:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd:v1.16-1
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

Kubernetes Güvenliği

Kubernetes ortamında güvenlik önlemleri ve best practices ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te güvenlik için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te güvenlik için en iyi uygulamalar şunlardır:

  • En az prensibi: Sadece gerekli izinleri verin
  • RBAC (Role-Based Access Control): Kullanıcı ve servis hesapları için rol tabanlı erişim kontrolü kullanın
  • Network Policy: Pod'lar arasındaki ağ trafiğini kısıtlayın
  • Pod Security Policy (PSP) / Pod Security Admission (PSA): Güvenli Pod oluşturmayı zorunlu kılın
  • Image güvenliği: Sadece güvenilir ve taranmış image'lar kullanın
  • Secret yönetimi: Hassas verileri güvenli bir şekilde saklayın
  • Encryption: Etki alanında veri şifrelemesi kullanın
  • Audit logging: Tüm işlemleri loglayın
  • Düzenli güncellemeler: Kubernetes ve bileşenlerini düzenli olarak güncelleyin
  • Güvenlik taramaları: Düzenli olarak güvenlik açığı taramaları yapın

❓ Soru 2: Kubernetes'te Pod Security Policy (PSP) nedir?

Cevap: Kubernetes'te Pod Security Policy (PSP), Pod'ların oluşturulmasında güvenlik kısıtlamaları getiren bir nesnedir.

  • Pod'ların hangi özelliklere sahip olabileceğini kontrol eder
  • Privileged mod, host network, host PID, host IPC gibi özellikleri kısıtlayabilir
  • Kullanıcı ve grup ID'lerini kontrol edebilir
  • Volume türlerini kısıtlayabilir
  • Not: Kubernetes 1.25+ sürümünde PSP kaldırılmıştır, yerine Pod Security Admission kullanılır

Pod Security Policy örneği:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

❓ Soru 3: Kubernetes'te Pod Security Admission (PSA) nedir?

Cevap: Kubernetes'te Pod Security Admission, Pod'ların oluşturulmasında güvenlik standartlarını zorunlu kılan bir admission controller'dır.

  • Pod Security Policy'nin yerini alan yeni bir özelliktir
  • Üç güvenlik seviyesi tanımlar: privileged, baseline, restricted
  • Namespace veya cluster seviyesinde uygulanabilir
  • Etiketler ve admission configuration kullanılarak yapılandırılır

Pod Security Admission yapılandırma örneği:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.25
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.25
    pod-security.kubernetes.io/warn: privileged
    pod-security.kubernetes.io/warn-version: v1.25

❓ Soru 4: Kubernetes'te Network Policy nasıl kullanılır?

Cevap: Kubernetes'te Network Policy, Pod'lar arasındaki ağ trafiğini kontrol eden bir nesnedir.

  • Pod'lar arasındaki iletişimi kısıtlar
  • Gelen (ingress) ve giden (egress) trafiği kontrol eder
  • Label selector kullanarak Pod'ları hedefler
  • Network plugin'inin bu özelliği desteklemesi gerekir (Calico, Weave Net, Cilium)

Network Policy örneği:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 5432
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: backup
    ports:
    - protocol: TCP
      port: 80

❓ Soru 5: Kubernetes'te container image güvenliği nasıl sağlanır?

Cevap: Kubernetes'te container image güvenliği sağlamak için şu yöntemler kullanılır:

  • Güvenilir registry'ler kullanma: Docker Hub, GCR, ECR, ACR gibi güvenilir registry'ler kullanın
  • Image imzalama: Cosign veya Notary gibi araçlarla image'ları imzalayın
  • Güvenlik taraması: Trivy, Clair, Anchore gibi araçlarla image'ları güvenlik açıklarına karşı tarayın
  • ImagePolicyWebhook: Image'ları kabul etmeden önce kontrol eden bir webhook kullanın
  • Minimal image'lar kullanma: Alpine, Scratch gibi minimal temel image'lar kullanın
  • Sabit versiyonlar kullanma: :latest yerine belirli bir versiyon etiketi kullanın
  • Image güncellemeleri: Düzenli olarak image'ları güncelleyin ve yeniden tarayın

ImagePolicyWebhook örneği:

apiVersion: v1
kind: ValidatingWebhookConfiguration
metadata:
  name: image-policy-webhook
webhooks:
- name: image-policy.example.com
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["pods"]
    scope: "Namespaced"
  clientConfig:
    service:
      name: image-policy-service
      namespace: image-policy
      path: "/validate"
  admissionReviewVersions: ["v1", "v1beta1"]
  timeoutSeconds: 5

İpuçları ve Best Practices

Kubernetes kullanımında ipuçları ve en iyi uygulamalar ile ilgili sorular ve cevaplar.

❓ Soru 1: Kubernetes'te kaynak optimizasyonu için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te kaynak optimizasyonu için en iyi uygulamalar şunlardır:

  • Doğru kaynak limitleri ve istekleri ayarlama: Her container için uygun CPU ve memory limitleri ve istekleri ayarlayın
  • Horizontal Pod Autoscaler (HPA) kullanma: CPU veya memory kullanımına göre Pod sayısını otomatik olarak ölçeklendirin
  • Vertical Pod Autoscaler (VPA) kullanma: Container'ların kaynak limitlerini ve isteklerini otomatik olarak ayarlayın
  • Cluster Autoscaler kullanma: Node kaynakları yetersiz olduğunda otomatik olarak Node ekleyin
  • Right-sizing: Uygulamaların gerçek kaynak kullanımını izleyin ve limitleri buna göre ayarlayın
  • Resource Quota ve Limit Range kullanma: Namespace'lerde kaynak kullanımını sınırlayın
  • Node affinity ve anti-affinity kullanma: Pod'ları uygun Node'lara yerleştirin
  • Pod Topology Spread kullanma: Pod'ları farklı bölgelere, alanlara veya Node'lara dağıtın

❓ Soru 2: Kubernetes'te performans optimizasyonu için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te performans optimizasyonu için en iyi uygulamalar şunlardır:

  • Efficient scheduling: Pod'ları uygun Node'lara yerleştirmek için node selector, node affinity ve taint/toleration kullanın
  • Efficient networking: Calico, Cilium gibi yüksek performanslı CNI plugin'leri kullanın
  • Efficient storage: Uygulama ihtiyaçlarına uygun storage sınıfları kullanın
  • Efficient logging: Log toplama için Fluent Bit gibi hafif araçlar kullanın
  • Efficient monitoring: Prometheus ve Grafana kullanarak performansı izleyin
  • Efficient scaling: HPA, VPA ve Cluster Autoscaler kullanarak otomatik ölçeklendirme yapın
  • Efficient resource usage: Kaynak kullanımını izleyin ve optimize edin
  • Efficient updates: Rolling update stratejilerini kullanarak kesintisiz güncelleme yapın

❓ Soru 3: Kubernetes'te hata ayıklama için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te hata ayıklama için en iyi uygulamalar şunlardır:

  • Detaylı loglama: Uygulamalarınızdan detaylı loglar çıkarın
  • Merkezi log yönetimi: Logları merkezi bir sistemde toplayın
  • Health check'ler: Uygulamalarınız için liveness ve readiness probe'lar tanımlayın
  • Distributed tracing: Jaeger veya Zipkin kullanarak istekleri izleyin
  • Event monitoring: Kubernetes olaylarını izleyin
  • Resource monitoring: CPU, memory, disk ve ağ kullanımını izleyin
  • Debug container'lar: Hata ayıklama için özel container'lar kullanın
  • kubectl debug komutu: Pod'lara hata ayıklama container'ı eklemek için kubectl debug komutunu kullanın
  • Port forwarding: Yerel makineden Pod'lara port yönlendirme yapın

❓ Soru 4: Kubernetes'te yüksek erişilebilirlik için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te yüksek erişilebilirlik için en iyi uygulamalar şunlardır:

  • Multi-master setup: Control Plane bileşenlerini birden fazla Node'a dağıtın
  • etcd cluster: etcd'yi birden fazla Node'a dağıtın ve düzenli olarak yedekleyin
  • Multi-zone deployment: Uygulamalarınızı farklı bölgelere veya alanlara dağıtın
  • Pod Disruption Budget (PDB): Planlı kesintiler sırasında minimum kullanılabilir Pod sayısını garanti edin
  • Horizontal Pod Autoscaler (HPA): Yük arttığında otomatik olarak Pod sayısını artırın
  • Cluster Autoscaler: Kaynaklar yetersiz olduğunda otomatik olarak Node ekleyin
  • Health checks: Uygulamalarınız için liveness ve readiness probe'lar tanımlayın
  • Load balancing: Service ve Ingress kullanarak trafiği dağıtın
  • Graceful shutdown: Uygulamalarınızın düzgün bir şekilde kapanmasını sağlayın

❓ Soru 5: Kubernetes'te maliyet optimizasyonu için en iyi uygulamalar nelerdir?

Cevap: Kubernetes'te maliyet optimizasyonu için en iyi uygulamalar şunlardır:

  • Right-sizing: Pod'lar için doğru kaynak limitleri ve istekleri ayarlayın
  • Spot/preemptible VM'ler kullanma: Test ve geliştirme ortamları için spot VM'ler kullanın
  • Autoscaling: HPA, VPA ve Cluster Autoscaler kullanarak kaynakları ihtiyaç duyulduğunda ekleyin
  • Cluster küçültme: Kullanılmayan kaynakları otomatik olarak kaldırın
  • Efficient storage: Uygulama ihtiyaçlarına uygun storage sınıfları kullanın
  • Multi-tenancy: Aynı cluster'da birden fazla uygulama çalıştırın
  • Cost monitoring: OpenCost, Kubecost gibi araçlarla maliyetleri izleyin
  • Resource quotas: Namespace'lerde kaynak kullanımını sınırlayın
  • Scheduling optimizations: Pod'ları daha az sayıda Node'da çalıştırın