Kubernetes kümesini yeni sürüme yükseltme: sıra, komutlar, kontroller

Yükseltmeden önce bilinmesi gereken kurallar

Kubernetes sürümleri major.minor.patch biçimindedir ve yükseltmede en önemli kural, alt (minor) sürüm atlamamaktır. Küme bir alt sürümden hemen sonraki alt sürüme çıkarılır; patch sürümleri arasında ise serbest dolaşılır. Birkaç alt sürüm geride kalmış bir küme, her basamağı sırayla geçerek yükseltilir.

Yükseltme planlarken şu ön koşulları gözden geçirin:

• Hedef sürümün sürüm notlarını okuyun; kaldırılan API'ler ve davranış değişiklikleri orada yazar
• Kümeniz static pod olarak çalışan control plane ve etcd kullanıyor ya da harici etcd'ye sahip olmalı
• Önemli durumu yedekleyin; en azından etcd snapshot'ı alın
• Swap kapalı olmalı
• Yükseltme, kubelet'in kapsayıcılarını yeniden başlatır; iş yükleriniz birden çok kopya ve PodDisruptionBudget ile korunuyorsa kesinti en aza iner

Kubernetes'in sürüm uyumluluk politikası, bileşenlerin birbirinden en fazla ne kadar geride kalabileceğini tanımlar. Genel ilke şudur: API sunucusu en yeni bileşendir, kubelet ve kubectl ondan geride ya da yakın olabilir, ama ondan ileride olamaz.

Yükseltme sırası: önce control plane, sonra worker'lar

Doğru sıra şudur: önce ilk control plane düğümü, sonra varsa diğer control plane düğümleri, en son worker düğümler. Her düğümde aynı döngü uygulanır: kubeadm paketini yükselt, kubeadm'in yükseltme komutunu çalıştır, düğümü boşalt (drain), kubelet ve kubectl paketlerini yükselt, kubelet'i yeniden başlat, düğümü yeniden zamanlamaya aç (uncordon).

Paket depolarında dikkat edilecek nokta: eski apt.kubernetes.io ve yum.kubernetes.io depoları kullanımdan kaldırılmıştır ve dondurulmuştur; resmî belgelerde anılan yeni topluluk paket deposunu kullanın. Hedef sürümün tam paket adını bulmak için apt-cache madison kubeadm (Debian ve Ubuntu) ya da dnf list --showduplicates kubeadm (RHEL ailesi) komutlarına bakılır.

Paketleri sürüm sabitleme (hold) altında tutmak, bir sistem güncellemesinin kubeadm ya da kubelet'i habersiz yükseltmesini önler. Bu yüzden yükseltmeden önce unhold, sonra hold yapılır.

İlk control plane düğümünde adım adım

Aşağıdaki komutlar Debian tabanlı bir sistem içindir; <hedef_surum> yerine hedef sürümü yazın.

sudo apt-mark unhold kubeadm sudo apt-get update sudo apt-get install -y kubeadm='<hedef_surum>-*' sudo apt-mark hold kubeadm

sudo kubeadm upgrade plan sudo kubeadm upgrade apply v<hedef_surum>

upgrade plan, kümenin yükseltilebileceği sürümleri, sertifika durumunu ve bileşen sürümlerini listeler. upgrade apply, control plane bileşenlerini hedef sürüme çıkarır, CoreDNS ve kube-proxy yapılandırmasını günceller.

Sonra düğümü boşaltıp kubelet ve kubectl'i yükseltin:

kubectl drain <dugum_adi> --ignore-daemonsets sudo apt-mark unhold kubelet kubectl sudo apt-get install -y kubelet='<hedef_surum>-*' kubectl='<hedef_surum>-*' sudo apt-mark hold kubelet kubectl sudo systemctl daemon-reload sudo systemctl restart kubelet kubectl uncordon <dugum_adi>

Etcd sürümünün de değişeceği bir yükseltmede, belgelerde belirtilen kısa bir süre önce kube-apiserver'ı durdurmak, uçuştaki isteklerin tamamlanmasına yardım eder.

Diğer control plane düğümleri ve worker'lar

İkinci ve sonraki control plane düğümlerinde fark yalnızca tek komuttadır: upgrade apply yerine upgrade node çalıştırılır. Çünkü küme yapılandırması ilk düğümde zaten güncellenmiştir.

sudo kubeadm upgrade node

Worker düğümlerde sıra şöyledir: kubeadm paketini yükseltin, sudo kubeadm upgrade node çalıştırın, yönetim makinesinden kubectl drain ile düğümü boşaltın, kubelet paketini yükseltin, daemon-reload ve kubelet restart yapın, kubectl uncordon ile düğümü açın. Worker'ları aynı anda hepsini değil, kapasiteyi koruyacak şekilde birer birer ya da küçük gruplar hâlinde yükseltin; aksi hâlde iş yükleri sığacak düğüm bulamaz.

Bir düğümü boşaltırken drain, PodDisruptionBudget'lara uyar. Bir pod'u tahliye edemeyen bir bütçe drain'i bekletir; bu bir hata değil, korumanın çalıştığının işaretidir. Çözüm kopya sayısını artırmak ya da bütçeyi gözden geçirmektir, drain'i zorlamak değil.

Yükseltme sonrası doğrulama listesi

Her düğümden sonra, hepsi bittiğinde bir kez daha şu kontrolleri yapın:

• kubectl get nodes: tüm düğümler Ready ve beklenen sürümde olmalı
• kubectl version ve kubeadm version: istemci ve sunucu sürümleri uyumlu görünmeli
• kubectl get pods -A: kube-system ve uygulama pod'ları Running ya da Completed olmalı
• systemctl status kubelet ve gerekirse journalctl -xeu kubelet: kubelet hatasız çalışmalı
• Kritik uygulamaların uçtan uca testi: servis erişimi, Ingress, kalıcı depolama bağlantısı
• Sertifika durumu: kubeadm upgrade sertifikaları da yeniler; kubeadm certs check-expiration ile kontrol edebilirsiniz

Yükseltme sırasında container spec özeti değiştiği için tüm kapsayıcıların yeniden başlatılması beklenen davranıştır. Bunu yükseltme planında önceden duyurun.

Sık yapılan hatalar ve geri dönüş yolu

• Alt sürüm atlamak: desteklenmez ve küme bileşenlerini uyumsuz bırakabilir
• kubelet'i control plane'den önce yükseltmek
• Drain yapmadan kubelet yükseltmek; pod'lar ani yeniden başlatılır
• Paket sabitlemeyi (hold) kaldırmayı unutmak ya da yükseltme sonrası geri koymamak
• Yedeksiz başlamak
• Eklentileri (CNI, ingress denetleyicisi, CSI) yeni sürümle uyumlu mu diye kontrol etmemek
• Kaldırılmış API sürümlerini kullanan manifestleri önceden taramamak

Yükseltme yarıda kalır ya da başarısız olursa kubeadm, değişikliklerden önce yedek alıp otomatik geri alma dener; yine de çözüm olmazsa belgelerdeki 'başarısız durumdan kurtarma' bölümü ve etcd yedeğinden geri yükleme devreye girer. Bu yüzden yedek almak yükseltmenin ön koşuludur, isteğe bağlı bir adım değildir.

Üretimde ilk deneme test kümesinde yapılmalıdır; mümkünse üretimle aynı eklenti ve iş yükü setiyle.

Mindset programlarında bu beceri nerede çalışılır?

Kubernetes Administrator (CKA) Hazırlık eğitimi, kümeyi işleten sistem yöneticisi ve platform mühendisi rolleri için tasarlanmıştır. Müfredattaki Küme Kurulum ve Yapılandırma ile Sorun Giderme ve Teşhis modülleri, yükseltme prosedürünün dayandığı küme mimarisi ve arıza çözümleme becerilerini kapsar.

Kurumsal ekipler için pratik değeri, yükseltmeyi bir kişinin bilgisine bağlı kalan olay olmaktan çıkarıp tekrarlanabilir bir prosedüre dönüştürmektir: kim hangi sırayla ne yapar, hangi kontroller yapılır, nerede geri dönülür sorularının ortak yanıtı.