Bir uygulama çalışmaktadır. Ardından güncelleme gelir, bir sunucu arızalanır veya birkaç bölüm aynı anda daha fazla kapasite ister. Kubernetes konteynerlerin nerede çalışacağını ve kararlaştırılan işletim durumuna nasıl dönüleceğini düzenler. Bunun daha güvenilir bir uygulama sağlayıp sağlamadığı tüm mimariye bağlıdır.

Şirket içi sipariş portalını düşünelim: çalışanlar sipariş girer, bir arayüz bunları stok yönetim sistemine aktarır, arka plan süreci belge üretir. Bu işler ayrı konteynerlerde çalışabilir. Bunları tek tek başlatan kişi güncellemeleri, yeniden başlatmaları ve makinelere yerleşimi de düzenlemelidir. Orkestrasyon burada devreye girer.

İstenen durum işletimin temelini oluşturur

Kubernetes’te web uygulamasının iki örneğinin belirli bir yazılım sürümüyle çalışması tanımlanabilir. Platform istenen durumu mevcut durumla sürekli karşılaştırır. Deployment uygulamanın dağıtımını tanımlar ve Pod’ları ReplicaSet denetleyicisiyle yönetir. Bir örnek eksikse denetim sistemi yerine yenisini sağlamaya çalışır.

Bu güncellemelerde de yararlıdır: yeni sürüm aşamalı dağıtılabilir. Kaynaklar, başlatma davranışı ve güncelleme stratejisi buna uygun olmalıdır. Teknik olarak başarılı dağıtım siparişin doğru işlendiğini kanıtlamaz. Bu kontrol uygulamanın ve testlerinin görevidir.

Sipariş portalı üzerinden temel kavramlar

Konteyner imajı

Uygulamanın gerekli dosyaları ve çalışma zamanı bileşenlerini içeren paketlenmiş temeli. Çalışan konteynerler bu imajdan başlatılır.

Pod

Kubernetes’te dağıtılabilir en küçük birim. Genellikle bir uygulama konteyneri içerir; yakın ilişkili konteynerler bir Pod’u ve örneğin ağ ad alanını paylaşabilir. Web uygulamasının iki kopyası genellikle iki Pod demektir.

Node

Pod çalıştıran makine. Sanal makine veya fiziksel sunucu olabilir. Kubernetes bu nedenle sanallaştırma katmanını tamamlayabilir; onu mutlaka değiştirmez.

Küme ve kontrol düzlemi

Küme, denetim sistemini iş yüklerini çalıştıran Node’larla birleştirir. Kontrol düzleminde API sunucusu, durum veritabanı, scheduler ve denetleyiciler bulunur. Node’larda kubelet ve konteyner çalışma zamanı yürütmeyi sağlar.

Service

Bir Pod grubu için kararlı mantıksal erişim noktası. Pod adresleri değiştirildiklerinde değişebilir. Service erişimi kısa ömürlü tekil örneklerden ayırır.

Arıza sırasında gerçekte ne olur?

Bir Node arızalanırsa yönetilen Pod’lar uygun başka Node’larda yeniden oluşturulabilir. Arızanın algılanması, yeterli yedek kapasite ve gerekli verilere erişim gerekir. Aynı fiziksel host üzerindeki ikinci örnek host arızasına karşı korumaz. Aynı güç veya ağ alanındaki sunucular da ortak arıza noktası paylaşabilir.

Sipariş portalında web arayüzü hızla yenilenebilir. Ancak başlamış belge işi tekrarlandığında mükerrer fatura veya sipariş üretmemelidir. Örnek değiştirilirken oturumlar kontrolsüz kaybolmamalıdır. Bunlar yazılım mimarisine ve bağlı sistemlere bağlıdır.

Üç sunucu tek başına erişilebilirlik planı değildir. Denetim, uygulamalar, ağ, storage ve arıza sonrası kalan kapasite birlikte düşünülmelidir. Bulutta ve yönetilen Kubernetes’te de hangi sorumluluğun sağlayıcıda, hangisinin işletmede kaldığını gerçek hizmet kapsamı belirler.

Kalıcı veriler ayrı plan ister

Pod’lar değiştirilebilir. İş verileri bu yüzden yalnızca konteynerin yazılabilir dosya sisteminde bulunmamalıdır. Kubernetes, Persistent Volume ve bunları talep eden Persistent Volume Claim aracılığıyla kalıcı storage bağlayabilir. StorageClass uygun storage’ın nasıl sağlanacağını tanımlar.

Bu nesneler alttaki storage’ı kendiliğinden dayanıklı yapmaz. Yerel disk altyapısına bağlı kalır; harici storage hizmetinin kendi performans ve arıza özellikleri vardır. Küme dışındaki veritabanı da doğru çözüm olabilir. Uygulama desteği, veri tutarlılığı, erişim yolları ve kararlaştırılan kurtarma süreci belirleyicidir.

Portal için kabul edilebilir kesinti süresini, veri kaybını ve geri yüklemenin nasıl test edileceğini ayrı tanımlarız. Yanlışlıkla silinen veriyi tüm örneklere güvenilir biçimde yayan küme yedek değildir. Ayrıntılar: yedekleme ve kurtarma.

Ek kurulum ne zaman anlamlıdır?

Birkaç uygulama düzenli güncelleniyorsa, tekrarlanabilir dağıtım gerekiyorsa veya iş yükleri makinelere bilinçli paylaştırılacaksa Kubernetes ilgi çekicidir. Platform güncellemesi, erişim yönetimi, ağ, storage ve izleme işleri de yaratır.

Tek kararlı uygulama için iyi bakılan Docker Compose sunucusu veya klasik sanal makine ekonomik olarak daha uygun olabilir. Karar istenen işletim davranışıyla başlamalıdır: hangi kesintiler kabul edilir, değişiklik ne sıklıktadır, ortamı kim anlar ve sorun halinde kurtarabilir?

Yararlı pilotun doğrulanabilir hedefleri olur

• Temsilî iş sürecini gerçekçi veri hacmiyle, üretim müşteri verisi kullanmadan test edin.
• Planlanan geri dönüş dahil güncellemeyi deneyin. Veritabanı şema değişikliklerini ayrıca değerlendirin.
• Bir örneğin ve planlı bir altyapı bileşeninin arızasını kontrollü koşullarda test edin.
• Yedeği ayrı test ortamına geri yükleyip iş verilerinin kullanılabildiğini açarak doğrulayın.
• Alarmlar, platform bakımı ve uygulama için sorumluları adlarıyla belirleyin.

DAXS uygulamayı değerlendirmeye ve uygun altyapıyı seçmeye yardımcı olur; uygulamayı ve kararlaştırılan işletimi üstlenir. Somut kullanım durumu ve açık kabul ölçütleriyle ilk değerlendirme pratik başlangıçtır.

Kaynaklar: Kubernetes: platformun rolü ve sınırları · Küme bileşenleri · Pod’lar ve yaşam döngüsü · Deployment ve güncellemeler · Service · Kalıcı storage · Üretim ortamlarının planlanması