Kubernetes'te cluster'ın hafızası etcd'dir. Deployment tanımları, ConfigMap'ler, Secret'lar, ServiceAccount'lar, node kaydı, event'ler — hepsi orada durur. Bir arıza sonrası cluster'ı geri getirmek, node kurmak değil, doğru bir etcd snapshot'ından cluster durumunu yeniden inşa etmektir.
etcd neden ayrı ele alınır
etcd, Raft üzerinden çalışan bir key-value store'dur ve Kubernetes API sunucusunun tek gerçek veri kaynağıdır. Cluster'da başka hiçbir yerde tutulmayan durum burada tutulur: bir Deployment nesnesinin son hâli, hangi node'un hangi Secret'ı gördüğü, hangi Job'ın hangi tarihte tamamlandığı. Bir apiserver ya da controller-manager çökerse yeniden başlatmak yeterlidir; ama etcd bozulduğunda cluster'ın kendisi silinmiş olur.
Bu asimetri, yedekleme stratejisinin de asimetrik olmasını gerektirir. Node'lar için imaj ve otomasyon yeterken etcd için düzenli, doğrulanmış ve cluster'dan bağımsız bir konumda saklanan snapshot şarttır. Kendi işlettiğimiz Kubernetes cluster yönetimi hizmetinde control plane yedekleme prosedürü, cluster'ın ilk kurulumundan önce yazılır — çünkü ilk arıza sonrasında yazmak için çok geç kalınmış olur.
Sıklık, hedef konum ve saklama
Sıklık üç değişkene bağlıdır: cluster'da saatte kaç yazma olduğu, kabul edilebilir veri kaybı penceresi ve snapshot'ın kendisinin ne kadar yer kapladığı. Yoğun bir üretim cluster'ında saatte bir snapshot makul bir alt sınırdır; günde bir yedek kâğıt üstünde vardır ama gerçek bir kayıp anında son bir günlük değişikliği geri getirmez.
Snapshot'ın gideceği yer, cluster'ın olası tek arıza noktasından uzak olmak zorundadır. Aynı fiziksel node'a yazılan yedek, o node çöktüğünde yedek olmaktan çıkar. Uygulamada iki katmanlı bir hedef işe yarar: cluster'ın yakınında hızlı erişimli bir depo ve uzakta, farklı bir hata alanında dayanıklı bir depo. Nesne depolama tarafında bu ayrımı özel bulut altyapımızda iki farklı bucket ve iki farklı politika ile kuruyoruz.
Saklama süresi de ayrıca tanımlanmalıdır. Son bir haftanın saatlik snapshot'ları, son bir ayın günlük snapshot'ları ve son bir yılın haftalık snapshot'ları gibi kademeli bir plan, disk maliyetini kontrol altında tutarken hem yakın hem uzak zaman hatalarına karşı geri dönüş noktası bırakır.
Geri yükleme provası yapılmamış yedek yedek değildir
En sık atlanan adım budur. Snapshot alma cron'u çalıştığı sürece görev bitmiş
sayılır; oysa etcdctl snapshot restore komutunun gerçekten
beklendiği gibi çalıştığı, üretimde denemeden bilinmez. Snapshot dosyasının
hash'i uyuşmayabilir, restore edilen veri yeni bir data-dir'e taşınırken
izin sorunu çıkabilir, apiserver restore sonrası yeni kimliği tanımayabilir.
Prova, ayrı bir laboratuvar cluster'ında ayda en az bir kez yapılmalıdır.
Prosedür şu sırayla ilerler: mevcut etcd durdurulur, data-dir taşınır,
snapshot yeni bir dizine restore edilir, etcd yeni data-dir ile başlatılır,
apiserver yeniden bağlanır ve son olarak birkaç örnek nesnenin gerçekten
geldiği kubectl get ile doğrulanır. Bu adımlardan biri
belgelenmemişse gerçek arızada zaman kaybedilir.
Yönetilen control plane'de resim tamamen değişir
Yönetilen bir Kubernetes servisi kullanıyorsanız etcd size kapalıdır. Sağlayıcı kendi tarafında yedek almaktadır, ama bu yedeğin hangi sıklıkta alındığı, ne kadar saklandığı ve nasıl geri yükleneceği çoğu zaman şeffaf değildir. Sağlayıcının panelinde bir tıkla önceki bir noktaya dönme imkânı olmayabilir; olsa bile, dönüş kararı sağlayıcının SLA'sı içinde kalır.
Uygulamada güvenli olan yol, sağlayıcının yedeklemesini bir güvence olarak görmek ama tek dayanak yapmamaktır. Namespace bazlı nesne dışa aktarımı düzenli çalıştırılmalı, kalıcı disklerin snapshot'ları ayrı bir hesapta ya da bölgede saklanmalıdır. GitOps akışı bu tabloyu sessizce tamamlar: tüm manifestler bir git deposundaysa, cluster kaybedilse bile yeniden inşa edilebilir. Bu yaklaşımın sürüm yükseltme tarafındaki karşılığını Kubernetes sürüm yükseltme yazısında ele almıştık; yedekleme, aynı disiplinin arıza tarafındaki yansımasıdır.
Sık sorulan sorular
etcd yedeği ne sıklıkla alınmalı?
Cluster'da her gün kaç değişiklik olduğuna bağlıdır. Yoğun bir üretim cluster'ında saatte bir snapshot makul bir alt sınırdır. Yedekleme sıklığı kabul edilebilir veri kaybı süresine bağlıdır; iki snapshot arasındaki değişiklikler geri yükleme durumunda kaybedilir.
Snapshot'ı nereye koymalıyım?
Kesinlikle yedeği aldığınız node'un dışına. Aynı disk arızası hem cluster'ı hem yedeği götürebilir. En az iki farklı fiziksel konum, tercihen bir tanesi cluster'ın yakınında hızlı erişim için, diğeri uzakta dayanıklılık için.
Geri yükleme provası neden şart?
Denenmemiş bir yedek yedek sayılmaz. etcdctl snapshot restore komutu sessizce başarısız olabilir ya da restore edilen veri hash uyuşmazlığı yüzünden reddedilebilir. Bu, arızanın ortasında değil, sakin bir günde keşfedilmelidir.
Yönetilen Kubernetes'te etcd'ye erişimim yoksa ne yapmalıyım?
Sağlayıcının kendi yedekleme mekanizmasına güvenmek yerine, tüm namespace nesnelerini düzenli olarak dışa aktarın ve kalıcı disklerin snapshot'ını ayrı bir hesap ya da bölgeye alın. Uygulama katmanında GitOps akışı bu resmi doğal olarak tamamlar.
etcd tek başına restore edilince cluster hemen ayakta mı?
Hayır. Restore sonrası apiserver'ın yeni data-dir'i tanıması, controller-manager ve scheduler'ın leader election'ı yenilemesi gerekir. Pod'lar yeniden zamanlanır, kalıcı disklerin doğru node'a bağlandığından ve DNS'in ayakta olduğundan ayrıca emin olunmalıdır.