Kubernetes’ Gizli Maliyetleri: Kendin Yönetmek Neden Pahalıya Patlıyor?

Her geçen gün Kubernetes’in gücüne övgüler düzülüyor. Peki ya Kubernetes’ı kendiniz çalıştırmanın gerçek maliyetine ne demeli? Bu maliyet sadece donanım faturasından ibaret değil. Zaman, insan kaynağı, başarısız hafta sonları ve aslında ürün geliştirmeye ayırabileceğiniz mühendislik saatleri de cabası. Eğer ekibiniz Kubernetes kümesini kendi başına yönetiyorsa, bu yazı tam size göre. Çünkü genellikle kendi kendinize çalıştırdığınız Kubernetes’in toplam maliyeti, etiket fiyatından çok daha yüksek çıkıyor.

Kubernetes’ın Gizli Faturasını Kimse Bütçeye Koymuyor

Birçok ekip Kubernetes’ı kendi bünyesinde çalıştırmaya karar verirken hesaplama yaparken şöyle düşünüyor: “Yönetilen bir hizmet için para ödemeyerek tasarruf ederiz. Bu kadar zor olamaz, değil mi?” Oysa bu hesaplama neredeyse her zaman eksik kalıyor. İşte gözden kaçan maliyet kalemleri:

• Sorumluluk kimin olacak? Kubernetes kendiliğinden çalışmıyor. En azından bir mühendisin kümeyi anlaması, üretim ortamını bozmadan yükseltmeyi bilmesi ve gece saatlerinde ağ sorunlarını çözebilmesi gerekiyor. Hindistan’da bu niteliklere sahip bir DevOps mühendisinin yıllık maaşı 1.2 milyon ila 2.5 milyon rupi arasında değişiyor. Üstelik bu mühendisin özellik geliştirme sürecinden çekilip kümeyle ilgilenmesi, fırsat maliyetini artırıyor.

• Yükseltmeler tek başına bir iş. Kubernetes her birkaç ayda bir yeni bir küçük versiyon yayınlıyor. Her versiyonun desteklenme süresi kısıtlı. Eğer çok geride kalırsanız, desteklenmeyen ve güvenlik açıkları barındıran yazılımlar çalıştırıyorsunuz demektir. Güncel kalmak için, yükseltmeleri test ortamında doğrulamanız, ardından kontrol düzlemi ve her çalışan düğümde dikkatlice uygulamaya geçirmeniz gerekiyor. Çoğu ekip için bu, her birkaç ayda bir birkaç gün süren bir görev haline geliyor.

• etcd kümenizin hafızasıdır ve bakıma ihtiyaç duyar. etcd, kümenizin tüm durumunu saklayan dağıtık bir anahtar-değer deposudur. Eğer düştüğünde çalışan bir yedeğiniz yoksa, kümeniz çalışması gerekenleri unutmuş olur. etcd yedeklerini ayarlamak, geri yüklemeleri test etmek ve yüksek kullanılabilirliği sağlamak gerçek bir mühendislik görevidir. Çoğu ekip, bir şeyler bozulana kadar bu adımları atlar.

• Sertifika yenileme. Kubernetes dahili olarak TLS sertifikaları kullanır. Bu sertifikalar zamanla sona erer. Üretim ortamında sona erdiğinde, sistemler sessizce arızalanmaya başlar ve ardından aniden her yerde sorunlar ortaya çıkar. Sertifika sona erme tarihlerini takip etmek ve programlı olarak yenilemek basit gibi görünse de, pratikte öyle değildir.

Her Arıza, Gizli Bir Vergi Gibidir

Kendi kendinize yönetilen bir kümede sorun çıktığında, araştırmayı da siz üstleniyorsunuz. Sorun kontrol düzleminde mi? Bir düğümde mi? Ağ politikasında mı? Yanlış yapılandırılmış kabul webhook’unda mı? etcd gecikmesinde mi? kube-proxy kurallarında mı? Her seferinde sıfırdan başlıyorsunuz. Küçük ölçekli bir Hint girişiminin kendi kümesini yönetirken ayda ortalama 15 ila 20 saatini küme bakımı, yükseltmeler ve arıza müdahalesine ayırdığı tahmin ediliyor. Bu, tutucu bir tahmin. Özel bir DevOps mühendisi olmayan ekipler için bu süre doğrudan ürün geliştirmeden çalınıyor. Bu süreyi ortalama saat başı tam maliyetle çarptığınızda, gerçek Kubernetes faturasını görmüş olursunuz.

"Bir şekilde hallederiz" Düşüncesinin Gerçek Maliyeti

Erken aşama ekipler arasında sıkça yaşanan bir senaryo var. Aylar 1 ila 3: Küme kurulur. Her şey çalışır. Ekip gurur duyar. Aylar 4 ila 6: İlk gerçek arıza. Bir düğüm kapanır. Birisi etcd’nin neden garip davrandığını anlamak için iki gün harcar. Bir sertifika sona erer. Düzeltme bir gün sürer. Aylar 7 ila 12: Küme üç küçük versiyon geride. Kimse yükseltmeyi eline almak istemez, çünkü geçmişteki bir yükseltme sorunlara yol açtı. Güvenlik yamaları atlanıyor. Bir kıdemli mühendis artık gayri resmi olarak Kubernetes sorumlusu olmuş ve bundan hoşnutsuz. 12. ay ve sonrası: Ekip nihayet yönetilen seçenekleri ciddi şekilde araştırmaya başlar.

Bu bir beceri eksikliğinden kaynaklanan bir başarısızlık değil. Altyapı karmaşıklığı zaman içinde arttıkça, kimsenin asıl görevi bu karmaşıklığı yönetmek olmadığında ortaya çıkan doğal bir sonuçtur.

Yönetilen Kubernetes’e Geçtiğinizde Neler Değişiyor?

Ekipler yönetilen Kubernetes’e geçtiğinde, kontrol düzlemi artık onların problemi olmaktan çıkıyor. Yükseltmeler, sertifika yenileme, etcd yedekleri, yüksek kullanılabilirlik — tüm bunları sağlayıcı yönetiyor. Ekibin geri kazandığı şey ise zaman. Bu zaman ürüne yatırılabiliyor. Bir de güvenilirlik açısından önemli bir avantaj var. Yönetilen Kubernetes sağlayıcıları kontrol düzlemi için %99.9 kullanılabilirlik SLA’sı sunuyor. Altyapı katmanında bir sorun yaşandığında, bu artık onların sorunu ve onların SLA’ları dahilinde çözümleniyor. Acil durum müdahale ekibinizin üyesi gece saatlerinde etcd’yi debug etmek zorunda kalmıyor.

Finans ve sağlık teknolojisi gibi düzenlemelerin sıkı olduğu sektörlerde çalışan ekipler için bu durum çok daha önemli. Uyumluluk, denetim günlükleri ve erişim kontrol gereksinimleri ortadan kalkmıyor, ancak zaten profesyonel standartlarda yönetilen altyapıda bu gereksinimleri karşılamak çok daha kolay hale geliyor.

Kendin Yönetmek Ne Zaman Mantıklı?

Adil olmak gerekirse, Kubernetes’ı kendi bünyesinde çalıştırmak bazı durumlarda doğru tercih olabilir:

• Büyük, özel bir platform mühendisliği ekibine sahip olan şirketler.
• Altyapının her katmanında tam kontrole ihtiyaç duyanlar.
• Performans gerekçeleriyle bare metal üzerinde çalışanlar ve yönetilen hizmetlerin bu gereksinimleri karşılayamadığı durumlar.

Bu ekipler için kendi kendine yönetilen Kubernetes karmaşıklığı, gereksinimler tarafından haklı kılınıyor. Ancak diğerleri için — ürün geliştirmeyi hızlandırmaya çalışan bir girişim, altyapı ekibi olmayan orta ölçekli bir şirket veya zaten ince eleyip sık dokuyan bir DevOps lideri için — gerçekçi yanıt genellikle yönetilen Kubernetes’in daha ucuz olduğudur. Maliyet hesabını tüm unsurlarıyla masaya yatırdığınızda, sonuç çoğu zaman bu yönde çıkıyor.

Unutmayın: Kubernetes’ın gücü şüphesiz büyük, ancak kendi başınıza yönetmenin bedeli de o kadar büyük. Doğru araçları seçmek, sadece teknolojiyle değil, zaman ve kaynaklarla da ilgili bir karar.