Cloud-Native Platformlar (Kubernetes, Container)

Olabilir, ve bu soruyu baştan sormak sonradan geri dönmekten çok daha ucuz.

Kubernetes, çok sayıda servisi olan ve sık sürüm çıkaran ekiplerde karşılığını veriyor: otomatik yeniden başlatma, kademeli dağıtım, yatay ölçekleme ve kaynak paylaşımı gibi problemleri tek bir modelde çözüyor. Bu problemler sizde yoksa, çözümü de bir kazanç getirmiyor.

Somut eşik şudur: üç uygulaması olan, ayda bir sürüm çıkan ve trafiği öngörülebilir bir kurumda Kubernetes'in getirdiği işletim yükü; cluster yükseltmeleri, ağ eklentisi, depolama sürücüsü, yetkilendirme modeli, observability stack'i; çözdüğü problemden büyük olur. Aynı iş yükü, yönetilen bir container çalıştırma hizmetiyle ya da hatta iyi yapılandırılmış sanal makinelerle daha az bakımla döner.

Değerlendirmeyi işe başlamadan yapıyoruz, çünkü "Kubernetes'e geçelim" kararı geri alınması pahalı bir karardır.

Control plane'i kendiniz işletmenin bir karşılığı olmalı; yoksa yönetilen hizmet kazandırıyor.

Kendi cluster'ınızı işletmeyi haklı çıkaran üç gerekçe var: verinin belirli bir tesiste durmasını zorunlu kılan bir düzenleme, yönetilen hizmetin desteklemediği bir ağ topolojisi, ya da API sunucusu düzeyinde özelleştirme gerektiren bir kurulum. Bunlardan biri geçerliyse kendi cluster'ınız doğru karardır.

Geçerli değilse, yönetilen hizmet control plane'in yükseltmesini, yamasını ve yedekliliğini üstleniyor; ve bu yük küçük değil. Kubernetes yılda üç küçük sürüm çıkarıyor ve her sürüm yaklaşık on dört ay destekleniyor; yani yükseltmeyi ertelemek bir seçenek değil, sadece ertelenmiş bir iş.

Pratikte çoğu kurumda doğru cevap karma oluyor: üretim yönetilen hizmette, özel gereksinimi olan tek bir iş yükü kendi cluster'ında.

Container varsayılan olarak güvenli değil. Varsayılan ayarlarla kurulmuş bir cluster, geniş bir saldırı yüzeyidir.

Beş katman birlikte çalışıyor. İmaj taraması: kullanılan temel imajlardaki bilinen açıklar sürekli taranır, çünkü bugün temiz olan bir imaj yarın açık taşır. İmza doğrulama: cluster'a yalnızca bilinen kaynaktan gelen imajın girmesi. En az yetki: container'ın root olarak çalışmaması, dosya sisteminin salt okunur olması, gereksiz yeteneklerin kaldırılması. Ağ politikaları: pod'lar arası trafiğin varsayılan olarak kapalı, yalnızca tanımlı yollara açık olması. Çalışma zamanı izleme: beklenmedik süreç başlatma ya da dosya erişimi gibi davranışların yakalanması.

Beşinden biri eksik olduğunda diğerleri bir dereceye kadar telafi ediyor, ama ilk üçü eksikse geri kalanı gürültü üretmekten öteye geçmiyor.

Hepsini değil, ve hepsini denemek bu geçişleri başarısız kılan en yaygın hata.

İyi aday olan uygulamanın üç özelliği var: durum tutmaması (oturum ve veri dışarıda), yatay ölçeklenebilmesi (ikinci kopya sorun çıkarmıyor), ve sık değişmesi (dağıtım kolaylığı gerçekten işe yarıyor).

Kötü aday da bellidir: yerel diske yazan, tek bir sunucunun IP'sine ya da lisans anahtarına bağlı, uzun süren toplu işler çalıştıran eski uygulamalar. Bunları container'a sokmak mümkün ama sonuç, çözdüğünden fazla karmaşıklık üreten bir kurulum oluyor: kalıcı hacimler, node ilişkilendirme kuralları, özel başlatma sırası.

Genellikle doğru sıra şu: önce yeni geliştirilen servisler, sonra ölçeklenme sorunu olan mevcut servisler, ve eski çekirdek uygulama en sonda ya da hiç.

Biz yapıyoruz, ve bunun ayrı bir hizmet kalemi olarak yazılmasının sebebi var.

Kubernetes'in sürüm döngüsü hızlı ve desteklenen pencere dar. Yükseltme planlanmadığında cluster birkaç ay içinde desteklenmeyen bir sürüme düşüyor; o noktadan sonra güvenlik yamaları gelmiyor ve tek çıkış yolu, birden fazla sürümü atlayarak yapılan riskli bir yükseltme oluyor.

Yükseltme yalnızca sürüm numarasını artırmak değil: her sürümde kaldırılan API'ler var ve uygulamanız o API'yi kullanıyorsa yükseltmeden sonra açılmaz. Bu yüzden sıra şu: önce kullanımdan kaldırılan API taraması, sonra test cluster'ında yükseltme, sonra uygulamaların doğrulanması, en son üretim.

Üretim yükseltmesi node'dan node'a yapılıyor, yani hizmet kesintisi olmuyor, ama bu ancak uygulamalar birden fazla kopya çalıştırıyorsa geçerli.

Doğrudan değil, ve bunu peşinen vaat eden bir teklif dikkatle okunmalı.

Container tek başına donanım maliyetini düşürmüyor. Düşüren şey, aynı fiziksel kaynak üzerinde daha yüksek yoğunlukla iş yükü çalıştırabilmek: sanal makine başına bir uygulama yerine, bir node'da onlarca container. Bu kazanç ancak iş yükleriniz birbirini tamamlayan kaynak profillerine sahipse gerçekleşiyor.

Buna karşılık yeni maliyetler geliyor: kayıt defteri, observability stack'i, control plane, ve en önemlisi ekibin öğrenme süresi. İlk yılda toplam maliyet genellikle artıyor, sonraki yıllarda düşüyor.

Asıl kazanç maliyette değil hızda: dağıtım süresinin saatlerden dakikalara inmesi ve geri alma işleminin gerçekten çalışması. Karar bu iki şeyin sizin için ne kadar değerli olduğuna bakılarak verilmeli.

Sorunun doğru hâli şudur: cluster'ın hangi parçası çökerse ne oluyor?

Bir node düşerse, üzerindeki pod'lar diğer node'larda yeniden başlatılıyor ve uygulama birden fazla kopya çalıştırıyorsa kullanıcı bunu görmüyor. Bu, Kubernetes'in asıl yaptığı iştir.

Control plane düşerse, çalışan uygulamalar çalışmaya devam ediyor, ama yeni dağıtım yapılamıyor, ölçekleme çalışmıyor ve düşen bir pod yeniden başlatılmıyor. Yani sistem ayakta ama körleşmiş oluyor. Bu yüzden control plane her zaman yedekli kuruluyor.

Cluster'ın tamamı kaybolursa (veri merkezi düzeyinde bir olay) devreye felaket kurtarma giriyor. Kubernetes bu senaryoyu kendi başına çözmüyor; cluster yapılandırması kod olarak saklanıyor ve ikinci bölgede yeniden kurulabiliyor olmalı.

Container'ın kendi dosya sisteminde durmuyor, ve bu ayrım kritik.

Container tanımı gereği geçici: silinip yeniden yaratıldığında içindeki her şey kayboluyor. Kalıcı veri bu yüzden dışarıda tutuluyor: kalıcı bir hacimde, bir veritabanı hizmetinde ya da nesne depolamada.

Pratikte üç yaklaşım var. Veritabanını cluster dışında yönetilen bir hizmet olarak çalıştırmak en yaygın ve en az sürprizli olanı. Cluster'ın içinde bir operatörle çalıştırmak mümkün ve bazı durumlarda doğru, ama yedekleme ve yükseltme sorumluluğunu size geri veriyor. Üçüncüsü, durumu tamamen dışarı almak: dosyalar nesne depolamada, oturumlar önbellekte.

Hangi yaklaşım seçilirse seçilsin, yedekleme cluster'ın değil verinin yedeklenmesidir; cluster yeniden kurulabilir, veri kurulamaz.

Uygulamayı geliştirenlerin bilmesi gerekmiyor; altyapıyı işletenlerin bilmesi gerekiyor. Bu ayrım, geçişin başarısını belirleyen şey.

Geliştirici tarafında hedef, cluster'ın görünmez olması: kod yazılır, pipeline çalışır, uygulama ayağa kalkar. Geliştiricinin YAML yazmak, ağ politikası tanımlamak ya da kaynak sınırı hesaplamak zorunda kalması, platformun yeterince kurulmadığı anlamına geliyor.

İşletme tarafında ise gerçek bir uzmanlık gerekiyor ve bu uzmanlık pahalı. Kurumların çoğu bu noktada bir tercih yapıyor: ya bu ekibi kuruyor ve elinde tutuyor, ya da işletmeyi devrediyor.

Devretme durumunda bile bir kişinin kurumda kalması doğru oluyor; kararların gerekçesini anlayan ve dışarıdan gelen öneriyi sorgulayabilen biri.