Kubernetes upgrade planı neden “sıradan bir bakım” değildir?

Kubernetes cluster kullanan ekipler için sürüm güncellemesi yalnızca yeni versiyona geçmek anlamına gelmez. API uyumluluğu, node işletim sistemi, ingress controller, storage class, CNI, CSI, monitoring agent’ları ve uygulama deployment’ları birlikte düşünülmelidir.

Özellikle üretim ortamında çalışan SaaS, e-ticaret, ERP, muhasebe, mobil uygulama backend’i veya mikroservis mimarilerinde plansız bir Kubernetes upgrade’i; kısa süreli servis kesintisine, pod scheduling sorunlarına veya veri katmanında beklenmeyen problemlere yol açabilir.

Bu yazıda Kubernetes cluster güncellemesini teknik örneklerle, uygulanabilir bir kontrol listesi üzerinden ele alıyoruz.

Narweb’in Kubernetes Cluster Hosting hizmeti; yüksek erişilebilirlik, güvenli node yönetimi ve planlı bakım süreçleri isteyen SaaS ekipleri için bu operasyon yükünü azaltmaya odaklanır. Daha esnek sunucu katmanı gereken yapılarda Cloud Dedicated Server ve VDS altyapılarıyla da Kubernetes mimarisi kurgulanabilir.

1. Mevcut cluster durumunu netleştirin

İlk adım mevcut cluster’ın hangi sürümde olduğunu, node’ların hazır durumda olup olmadığını ve sistem bileşenlerinin sağlıklı çalışıp çalışmadığını görmektir.

kubectl version --short
kubectl get nodes -o wide
kubectl get pods -A
kubectl get componentstatuses

Yeni Kubernetes sürümüne geçmeden önce özellikle şu bileşenler kontrol edilmelidir:

• Control plane: API Server, Controller Manager, Scheduler
• Worker node’lar: kubelet, container runtime, kernel durumu
• Network katmanı: CNI eklentisi, örneğin Calico, Cilium veya Flannel
• Storage katmanı: CSI driver, PVC/PV durumları
• Ingress: NGINX Ingress, Traefik veya benzeri bileşenler
• Monitoring: Prometheus, Grafana, alertmanager, log agent’ları

2. Kubernetes sürüm uyumluluğunu kontrol edin

Kubernetes dünyasında her bileşen aynı anda rastgele yükseltilmez. Kubernetes’in sürüm uyumluluk politikasına göre control plane, kubelet ve kubectl arasında belirli sürüm farkları desteklenir. Bu nedenle upgrade planı hazırlarken hedef sürüme doğrudan atlamak yerine desteklenen geçiş yolunu kontrol etmek gerekir.

Örnek olarak mevcut cluster sürümünü kontrol edelim:

kubectl version

Eğer cluster eski bir minor sürümdeyse, çoğu senaryoda adım adım ilerlemek daha güvenlidir:

1.32 → 1.33 → 1.34 → 1.35 → 1.36

Bu geçiş sırasında yalnızca Kubernetes değil, ona bağlı çalışan eklentiler de kontrol edilmelidir. Örneğin ingress controller’ın veya CNI eklentisinin hedef Kubernetes sürümüyle uyumlu olup olmadığı release notlarından doğrulanmalıdır.

3. Güncellemeden önce yedek alın

Cluster upgrade öncesinde en kritik adım yedektir. Kubernetes manifest dosyaları Git’te tutuluyor olsa bile, cluster içindeki bazı canlı kaynaklar ayrıca dışarı alınmalıdır.

Temel kaynakları dışa aktarmak için:

mkdir -p k8s-backup-$(date +%F)
cd k8s-backup-$(date +%F)

kubectl get all -A -o yaml > all-resources.yaml
kubectl get configmap -A -o yaml > configmaps.yaml
kubectl get secret -A -o yaml > secrets.yaml
kubectl get ingress -A -o yaml > ingress.yaml
kubectl get pvc -A -o yaml > pvc.yaml

Eğer cluster etcd kullanıyorsa, control plane seviyesinde etcd snapshot almak da önemlidir:

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Veri tabanı çalışan workload’lar için ise yalnızca PVC yedeğine güvenmek çoğu zaman yeterli değildir. PostgreSQL, MySQL, MongoDB gibi sistemlerde uygulama seviyesinde ayrıca dump veya snapshot stratejisi kullanılmalıdır.

4. Pod disruption budget ve replica sayısını kontrol edin

Worker node güncellemeleri sırasında node’lar sırayla boşaltılır. Bu işlem kubectl drain ile yapılır. Ancak deployment’lar tek replica çalışıyorsa veya PodDisruptionBudget yanlış tanımlandıysa uygulama kısa süreli kesinti yaşayabilir.

Örnek bir deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
        - name: api-service
          image: registry.example.com/api-service:1.4.2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5

Bu deployment için basit bir PodDisruptionBudget:

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

Böylece node boşaltma sırasında Kubernetes en az iki pod’un ayakta kalmasını hedefler.

5. Node drain işlemini kontrollü yapın

Worker node güncellemelerinde temel akış şu şekildedir:

kubectl cordon worker-01
kubectl drain worker-01 --ignore-daemonsets --delete-emptydir-data

# Node üzerinde işletim sistemi, kubelet veya container runtime güncellemesi yapılır.
# Ardından node yeniden cluster'a alınır.

kubectl uncordon worker-01
kubectl get nodes
kubectl get pods -A -o wide

Bu işlem her node için sırayla yapılmalıdır. Tüm node’ları aynı anda drain etmek üretim ortamı için risklidir.

6. Güncelleme sonrası test listesi hazırlayın

Upgrade tamamlandıktan sonra yalnızca kubectl get nodes çıktısının yeşil olması yeterli değildir. Uygulama, network ve veri katmanı birlikte doğrulanmalıdır.

Örnek kontrol komutları:

kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl top nodes
kubectl top pods -A

Uygulama seviyesinde ise şu testler yapılmalıdır:

• HTTP health endpoint kontrolleri
• Ingress ve TLS sertifika doğrulaması
• Veri tabanı bağlantı testi
• Queue/worker servislerinin çalışması
• Log ve metrik akışının Prometheus/Grafana tarafında görünmesi
• Backup job’larının hâlâ çalıştığının kontrolü

7. Rollback planı olmadan upgrade başlatmayın

İyi bir upgrade planında yalnızca “nasıl yükseltiriz?” sorusu değil, “sorun çıkarsa nasıl geri döneriz?” sorusu da cevaplanmalıdır.

Rollback planında en az şu başlıklar bulunmalıdır:

• Etcd snapshot konumu
• Veri tabanı yedeği ve geri dönüş süresi
• Eski deployment image tag’leri
• Ingress ve DNS değişikliklerinin geri alınma yöntemi
• Upgrade öncesi ve sonrası sorumlu kişi listesi
• Bakım penceresi ve müşteri iletişim planı

Örnek mini upgrade kontrol listesi

[ ] Mevcut Kubernetes sürümü kontrol edildi
[ ] Hedef sürüm için release note okundu
[ ] CNI / CSI / Ingress uyumluluğu doğrulandı
[ ] Etcd snapshot alındı
[ ] Kritik veritabanları ayrıca yedeklendi
[ ] Deployment replica sayıları kontrol edildi
[ ] PodDisruptionBudget tanımları kontrol edildi
[ ] Test ortamında upgrade denendi
[ ] Bakım penceresi belirlendi
[ ] Rollback planı hazırlandı
[ ] Node’lar sırayla drain/uncordon edildi
[ ] Uygulama ve monitoring testleri tamamlandı

Narweb Kubernetes Cluster Hosting ile yönetimli upgrade süreci

Kubernetes güçlü bir platformdur; ancak üretim ortamında doğru planlanmadığında operasyon yükü hızla artabilir. Narweb olarak Kubernetes Cluster Hosting hizmetimizde cluster kurulumu, node yönetimi, güvenli erişim, yedekleme, izleme ve bakım süreçlerini kurumsal ihtiyaçlara göre planlıyoruz.

Özellikle SaaS projeleri, ajanslar, yazılım firmaları ve yüksek erişilebilirlik isteyen ekipler için Kubernetes altyapısını yalnızca kurmakla kalmıyor; güncelleme, izleme, yedekleme ve kapasite planlama süreçlerinde de destek sağlıyoruz.

Kubernetes cluster’ınızı güvenli şekilde kurmak, taşımak veya güncellemek isterseniz Narweb ekibiyle iletişime geçebilirsiniz. İhtiyaca göre Kubernetes, PostgreSQL Cluster Hosting, S3 Object Storage Hosting ve AI Agent Hosting gibi SaaS altyapı bileşenleri birlikte planlanabilir.