Kubernetes dağıtımları, altyapılarını güncellemek ve bulut tabanlı bir mimariye geçmek isteyen kuruluşlara pek çok avantaj sunuyor.
Ancak Kubernetes’i geliştiriciler ve BT yöneticileri için çekici kılan birçok şey, yedekleme ve felaket kurtarma (DR) söz konusu olduğunda potansiyel sorunlar da yaratıyor.
Geleneksel monolitik uygulamalar ve hatta sanal makineler (VM’ler) dikkatli bir şekilde yapıldığı sürece yedeklemek ve bir felaket kurtarma planına dahil etmek nispeten kolaydır. Ancak Kubernetes ve kapsayıcılar (birbirine bağlı mikro hizmetleri, durumsuz uygulamaları ve kalıcı depolama alanları ile) farklı bir şekilde çalışır. Felaket kurtarmanın buna izin vermesi gerekir.
Kubernetes için DR’ye neden ihtiyacımız var?
Üretimde giderek daha fazla konteyner ve Kubernetes kullanılıyor. Sonuç olarak, Kubernetes’in hayati verileri ve temel iş süreçlerini işleme olasılığı daha yüksek.
Kuruluşların, Kubernetes tabanlı bir uygulamayı oluşturan verileri ve çeşitli mikro hizmetleri koruması ve bunları doğru bir şekilde ve zamanında kurtarabilmelerini sağlaması gerekir.
Ve BT ekiplerinin, Kubernetes tabanlı bir dağıtımın tüm kritik parçalarının felaket kurtarma planı tarafından kapsandığından emin olması gerekir. Bu sadece kalıcı depolamayı standart ve değiştirilemez yedeklemelerle korumakla ilgili bir soru değildir, kuruluşların tüm kümeyi ve bileşenlerini ve verilerini koruması gerekir, böylece bunları sorunsuz bir şekilde geri yükleyebilirler. Tüm bunların da test edilmesi gerekir.
Kubernetes için DR’nin zorlukları nelerdir?
Kubernetes kümeleri için DR, küme bileşenlerinin ve yapılandırmasının tanımlanması ve korunması anlamına gelir.
Sonra veri hacimleri var. Kubernetes verileri giderek artan bir şekilde kalıcı depolamada yer alıyor ve bu da felaket kurtarma ekibinin görevini bir nebze daha kolay hale getiriyor. Ancak DR uzmanlarının, Kubernetes tabanlı uygulamaların verileri nerede depoladığını bilmeleri gerekir çünkü bunlar yerel, bulut ve hibrit depolamada çalışabilir.
Gartner analisti Tony Iams’a göre iyi haber şu ki, ayrıntılı yedekleme daha zor olsa da konteyner uygulamaları felaket kurtarma ve iş sürekliliğine uygun özelliklere sahip.
“Konteynerlerin doğal taşınabilirliği ve değişmezliği, eksiksiz bir uygulama yığınını birden fazla konumda tutarlı bir şekilde çoğaltmayı kolaylaştırır” diyor. “Sürekli entegrasyon/sürekli dağıtım kullanarak [CI/CD] “Süreçler sayesinde, konteynerleştirilmiş uygulamalar ihtiyaç duyulduğu anda ve yerde, ister ikincil bir sitede, isterse bir arıza meydana geldikten sonra birincil siteyi yeniden yapılandırmak için kolayca yeniden oluşturulabilir ve teslim edilebilir.”
DR ile Kubernetes ortamlarında azaltılması gereken riskler nelerdir?
Kubernetes’in karşı karşıya olduğu riskler, diğer tüm kurumsal teknoloji işletim ortamlarının karşı karşıya olduğu risklerle aynıdır: donanım arızası, yazılım sorunları (altta yatan Linux işletim sistemindekiler dahil), elektrik veya ağ arızaları, fiziksel felaketler ve tabii ki fidye yazılımları da dahil olmak üzere siber saldırılar.
Ancak konteynerlerin esnekliği ve dağıtılmış yapısı, uygulamaları tek noktadan kaynaklanan arızalara karşı savunmasız hale getirebilir; dağıtılmış mimariler, donanım kesintilerinin etkisini artırabilir.
Örneğin bir kuruluş, tüm sanal makineyi çoğaltabilir veya değiştirilemez bir anlık görüntü oluşturabilir ve bir uygulamayı veya iş sürecini çalıştırmak için gereken her şeyi yakaladıklarından makul ölçüde emin olabilir. Kubernetes ile daha fazla bağımlılık vardır.
Iams, konteynerli uygulamaların depolamayı ele alma biçimini belirli bir risk olarak tanımlıyor. Ana işletim sisteminin dosya sistemini kullanan geleneksel uygulamaların aksine, “konteynerler, verileri konteynerin kendi yerel dosya sisteminin dışındaki depolamaya yazan birimleri kullanarak verileri kalıcı hale getiriyor” diyor.
Konteynerler Kubernetes kümelerindeyse, BT ekiplerinin bildirimlerin ve diğer politika yapılandırmalarının yedeklendiğinden ve konteynerlerin geri yüklemeden sonra depolama alanlarına yeniden bağlanabildiğinden emin olması gerekir.
Kubernetes ortamı için bir DR planı hangi temel noktaları içermelidir?
Kubernetes ortamı için başarılı bir felaket kurtarma, geleneksel uygulamalara yönelik bir kurtarma planından genellikle daha ayrıntılı olacaktır.
Firmalar, tüm kümeler yerine Kubernetes sisteminin belirli bölümlerini kurtarabildikleri takdirde kesinti süresini ve veri kaybını azaltabilirler. Bir Kubernetes ortamının her bir bölümü kendi kurtarma noktasına ve kurtarma zamanı hedeflerine (RPO/RTO) sahip olabilir.
Ancak bunun için BT ekiplerinin Kubernetes bileşenleri ve destekledikleri iş süreçleri hakkında kapsamlı ve güncel bir resme sahip olması gerekiyor.
Geleneksel ortamlar için bir DR planı için bir yaklaşım, öncelikle geri yüklenmesi gereken hizmetlere öncelik vermektir.
Burada birbiriyle bağlantılı iki soruyu sormak faydalı olacaktır:
- İşletme operasyonları açısından en kritik öneme sahip olan ve bu nedenle öncelikle tekrar çevrimiçi hale getirilmesi gereken Kubernetes tabanlı uygulamalar hangileridir?
- Hangi (Kubernetes) hizmetleri ve bağımlılıkları bu konteynerları en hızlı şekilde geri getirecek?
Bu, iyi bir şekilde yapılırsa bir organizasyonun uygulamalarını, tüm bir kümeyi geri yüklemeye güvenmekten daha hızlı bir şekilde, belki de daha az işlevsellikle çevrimiçi hale getirmesini sağlayabilir.
Kesin yaklaşım muhtemelen kuruluşun olgunluğuna ve riske yaklaşımına bağlı olacaktır.
Iams, “Bu aşamada, bulut tabanlı ve geleneksel altyapı mühendislerinin soruna en iyi şekilde nasıl yaklaşılacağı konusunda farklı görüşleri var” diyor.
“Bulut tabanlı mühendisler, CI/CD iş akışları aracılığıyla yeniden dağıtım yöntemlerine öncelik verirken, geleneksel yaklaşımlar Kubernetes uygulamaları ve veri koruması için yedekleme ve kurtarma araçlarına güvenir.” Analist firması, kuruluş yeterince olgunlaşmışsa uygulama merkezli bir yaklaşım öneriyor.
Kubernetes için DR’nin altyapı gereksinimleri nelerdir?
Fiziksel altyapı söz konusu olduğunda, Kubernetes’in esnekliği bir uygulamayı kurtarmayı kolaylaştırmalıdır. Bu, şirket içi donanımdan buluta veya hatta bulut sağlayıcıları arasında geçiş yaparak olabilir.
DR uzmanlarının gerekli kaynakların mevcut olduğundan emin olması gerekir. Buna Kubernetes kümelerini çalıştırmak için hesaplama gereksinimleri ve kalıcı birimleri kurtarmak için depolama alanı dahildir. Uygun ağ kaynakları da önemlidir.
Uygulamaların kurtarılması için, BT ekipleri uygulama merkezli bir GitOps yaklaşımı kullandıysa, kurtarma için ArgoCD veya Flux CD’yi kullanabilirler.
Aksi takdirde, en iyi yaklaşım muhtemelen Kasten, Trilio, CloudCasa veya Cohesity (şu anda Veritas’ın veri koruma işinin de sahibi) gibi Kubernetes konusunda uzmanlaşmış bir satıcının aracı olacaktır. Commvault ve Rubrik gibi satıcılar da kapsayıcıları ve bulut tabanlı uygulamaları destekler.
Bunlar, kümelere dağıtılan ve kümelerin bir uygulamayı nasıl oluşturduğunu ve bir kesinti olması durumunda bunların nasıl geri yükleneceğini anlayan “Kubernetes farkında” araçlardır.