Kubernetes kümesinin etcd yedeğini alma ve geri yükleme

Neden etcd yedeği kümenin sigortasıdır?

Kubernetes'in tüm durumu etcd'de tutulur: Deployment tanımları, Secret ve ConfigMap nesneleri, RBAC kuralları, servisler, düğüm kayıtları. Çalışan uygulamalarınızın kendisi düğümlerde durur ama kümenin neyi nasıl çalıştırması gerektiği bilgisi etcd'dedir. etcd verisi kaybolur ve yedek yoksa, konteynerler çalışmaya devam etse bile küme tanımını yeniden kurmanız gerekir.

Kubernetes belgeleri, etcd'yi arka depo olarak kullanan her küme için bir yedekleme planı olmasını şart koşar. Yedek almanın farklı yolları vardır: etcd'nin yerleşik snapshot özelliği, depolama katmanının birim (volume) snapshot'ı ve etcdctl ile alınan snapshot. Bu sayfa en yaygın ve sınavlarda da sorulan yol olan etcdctl snapshot yöntemini anlatır.

Başlamadan önce bilmeniz gerekenler

Burada iki farklı araç kullanılır; işleri farklıdır. etcdctl, ağ üzerinden etcd ile konuşur; snapshot almak gibi günlük işlemler bununla yapılır. etcdutl ise doğrudan veri dosyaları üzerinde çalışır; snapshot geri yükleme, defragmentasyon ve sürümler arası veri taşıma onun işidir. Yeni etcd sürümlerinde snapshot durum sorgusu da etcdutl tarafına taşınmıştır.

kubeadm ile kurulmuş bir kümede etcd, control plane düğümlerinde static pod olarak çalışır (stacked topoloji). Static pod manifesti genellikle /etc/kubernetes/manifests/etcd.yaml dosyasındadır ve içinde etcd'nin dinlediği adres, veri dizini ve sertifika yolları yazar. Yedek komutunun ihtiyaç duyduğu her değeri bu dosyadan okuyabilirsiniz; ezbere yol yazmak yerine önce manifesti açmak güvenli alışkanlıktır.

Bağlantı için sertifika dosyaları gerekir: etcd CA sertifikası, istemci sertifikası ve istemci anahtarı. kubeadm kümelerinde bunlar genellikle /etc/kubernetes/pki/etcd altında bulunur.

etcdctl ile snapshot alma

Yedeği, etcd üyesine erişebilen bir düğümde şöyle alırsınız:

etcdctl snapshot save /yedek/etcd-snapshot.db \ --endpoints=<etcd_adresi> \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key

Komut tek bir etcd üyesinden tutarlı bir anlık görüntü dosyası üretir. Dosyanın yerel diskte kalması yedek sayılmaz: düğümün diski kaybolursa yedek de kaybolur. Dosyayı kümenin dışında, erişimi kısıtlı bir depolama alanına kopyalayın; içinde Secret verileri bulunduğundan snapshot dosyası da hassas veri olarak ele alınmalıdır.

Yedeğin geçerliliğini kontrol etmek için:

etcdutl snapshot status /yedek/etcd-snapshot.db --write-out=table

Çıktıda karma değeri, revizyon, toplam anahtar sayısı ve boyut görünür. Yedek alınıp hiç doğrulanmaması ve geri yükleme denenmemesi, en sık görülen zayıflıktır.

Snapshot'tan geri yükleme adımları

Geri yükleme, mevcut veri dizinine yazmaz; snapshot'tan yeni bir veri dizini oluşturur:

etcdutl snapshot restore /yedek/etcd-snapshot.db --data-dir=/var/lib/etcd-restored

Çok üyeli bir etcd kümesinde her üye için üye adı, başlangıç küme listesi ve peer adresi gibi bayraklar eşleşen değerlerle verilir ve işlem her üyede yapılır. Tek control plane düğümlü kubeadm kümesinde çoğu zaman yukarıdaki biçim yeterlidir.

Static pod kullanan kümede asıl adım bundan sonra gelir: /etc/kubernetes/manifests/etcd.yaml dosyasında hostPath olarak etcd veri dizinini gösteren volume yolunu yeni dizinle (etcd-restored) değiştirirsiniz. Kubelet manifest değişikliğini fark eder ve etcd pod'unu yeni veri üzerinde yeniden başlatır. Birkaç dakika sonra API sunucusu yeniden yanıt vermeye başlar; kubectl get pods -A ile nesnelerin yedek anındaki hâline döndüğünü kontrol edin.

Geri yüklemenin sonucu, yedeğin alındığı andaki durumdur. O andan sonra oluşturulan nesneler kaybolur, silinenler geri gelir; bu yüzden geri yüklemeyi bilinçli bir olay olarak planlayın.

Örnek senaryo: yanlışlıkla silinen namespace

Örneğin bir ekip, bakım sırasında yanlış kümede bir namespace'i silmiş olsun. İçindeki Deployment, Service ve ConfigMap nesneleri gitmiştir. Güvenli yol şudur:

• Önce etkinin kapsamını belirleyin: yalnız bir namespace mi etkilendi, yoksa küme geneli mi?
• Yalnız tek namespace ise çoğu zaman manifest deposundan (GitOps veya CI kaydı) yeniden uygulamak, tüm küme durumunu geri almaktan daha az risklidir
• Küme geneli bir veri kaybı varsa son sağlam snapshot'ı seçin, bir test ortamında geri yükleyip nesnelerin yerinde olduğunu doğrulayın
• Üretimde geri yüklemeden önce API sunucusuna gelen trafiği durdurun, çünkü geri yükleme sırasında yazılan veriler kaybolur
• İş bitince kümenin sağlığını, düğüm durumlarını ve kritik uygulamaları sırayla kontrol edin

Bu örnek, yedeğin tek başına çözüm olmadığını gösterir: yedekleme sıklığı, saklama süresi ve geri yükleme prosedürü birlikte düşünülür.

Yedekleme düzeninin parçaları ve sık hatalar

Düzenli bir yedekleme düzeni şu parçalardan oluşur: zamanlanmış snapshot alma işi, dosyanın küme dışına kopyalanması, saklama süresi politikası, yedek dosyalarına erişim kontrolü ve belirli aralıklarla geri yükleme tatbikatı.

Sık yapılan hatalar:

• Sertifika yolunu ezbere yazmak; kümeye göre farklı olabilir, manifestten okuyun
• Snapshot'ı aynı diskte bırakmak
• Yedeği hiç geri yükleme denemesi yapmadan güvenmek
• Geri yükleme sonrası manifestte veri dizini yolunu güncellemeyi unutmak ve eski veriyle çalışmaya devam etmek
• Birden çok üyeli etcd kümesinde yalnız bir üyeyi geri yükleyip diğerlerini bırakmak
• Snapshot dosyasının Secret içerdiğini unutup herkese açık bir klasöre koymak

Kendi kurduğunuz bir kümede bu işler sizindir. Yönetilen Kubernetes servislerinde etcd'ye genellikle erişiminiz yoktur ve yedekleme sağlayıcının hizmetine bağlıdır; bu fark, hangi kümede hangi becerinin gerektiğini belirler.

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

Kubernetes Administrator (CKA) Hazırlık eğitimi, küme işleten sistem yöneticileri ve platform mühendisleri içindir; küme kurulumu, güvenlik ve sorun giderme modülleriyle yedekleme ve kurtarma görevlerinin sınav ve gerçek iş bağlamını birlikte ele alır.

Dağıtık Kilitleme ve Koordinasyon (ZooKeeper, etcd) eğitimi ise etcd'yi Kubernetes'ten bağımsız, bir koordinasyon deposu olarak inceler; etcd Modeli ve Kullanımı ile Arıza Senaryoları ve Dayanıklılık modülleri, yedeğin neden tutarlılık ve üyelik kavramlarıyla birlikte düşünülmesi gerektiğini anlamak isteyen altyapı ekipleri için uygundur.