Kubernetes öğrenmeye başlayanların, platformun tüm bileşenlerini ve seçeneklerini ilk haftadan itibaren kavramaya çalışması gerekmez. Portainer.io'dan Joep Piscaer'in ortaya koyduğu sonuç budur. VMware mimarı olarak önceki deneyimine ve geliştiricilerle BT çalışanlarının konteyner tabanlı ortamlara geçerken aynı soruyla karşılaştığı gözlemine dayanarak şu soruyu soruyor: Öğrenmeye gerçekte nereden başlanmalı?
Yazara göre yaygın öğrenme yolları her zaman uygun bir başlangıç noktası sunmuyor. Kubernetes belgeleri kapsamlı; ücretli kurslar da aynı belgeleri yeniden sunabiliyor. Sertifika odaklı yollar ise hızla derinleşebilir veya temel kavramlar arasında bağlantılı bir anlayış oluşturmadan uzun kaynak listeleri sunabilir. Bu nedenle yazar, platformun çok sayıdaki ayrıntısına geçmeden önce davranışını açıklayan sınırlı sayıdaki fikirden, yani zihinsel “iskelelerden” başlamayı öneriyor.
İstenen durum mekanizmasıyla başlayın
İlk kavram, istenen durum ve uzlaştırmadır. Kubernetes'te mesele yalnızca bir konteyneri çalıştırmak için komut vermek değildir; kullanıcı belirli bir durumun mevcut olması gerektiğini bildirir. Ardından platform, gerçek durumu bu bildirimle karşılaştırmayı ve aradaki farkı düzeltmeyi sürdürür. Yazara göre kendini onarma, ölçeklendirme ve kademeli dağıtımlar gibi işlevler, istenen durumun veya bu durumun değiştirilme biçiminin farklılaşmasıyla aynı mekanizmanın kapsamına girer.
Bu kavramın hem eğitimsel hem de pratik önemi vardır. Öğrenen kişi her işlevi ayrı bir özellik olarak ezberlemek yerine Kubernetes davranışına tek bir mekanizmanın farklı uygulamaları olarak bakabilir. Yazar, bu anlayışın eksik olması hâlinde platformun geri kalanının ezberlenmesi gereken uzun birbiriyle bağlantısız özellikler listesi gibi görüneceğini vurguluyor.
Düğüm modelindeki farkı anlayın
İkinci temel unsur, kontrol düzlemi ile çalışan düğümler arasındaki ayrımın yanı sıra bir düğümün “değiştirilebilir” olmasının ne anlama geldiğini anlamaktır. Yazar bunu, ekibin arızalı bir ESXi ana bilgisayarını onararak, iş yüklerini üzerinden taşıyarak veya yükselterek ve ardından yeniden hizmete alarak yönetebildiği geleneksel VMware deneyimiyle karşılaştırıyor.
Kubernetes'te ise bir düğüm arızalandığında sistem, zorunlu olarak düğümün kendisini kurtarması gerektiğini varsaymaz. Her sağlıklı düğüm herhangi bir iş yükünü çalıştırabilir. Bu nedenle sistem, belirli bir donanım parçası olarak korumak yerine etkilenen düğümü devre dışı bırakıp değiştirecek şekilde tasarlanmıştır. Piscaer, geleneksel altyapı yönetimi alışkanlıklarının bu modele aktarılmasının, platformun gerektiğinde terk etmek üzere tasarladığı bir bileşeni ekiplerin korumasına yol açabileceğine dikkat çekiyor.
Ağlarda sorunun katmanını belirleyin
Yazar ağları dört ardışık katman üzerinden incelemeyi öneriyor: konteynerden pod'a, pod'dan servise, servisten ingress'e ve ardından ingress'ten dış dünyaya.
Bu yaklaşıma göre ağ sorunlarını teşhis ederken yaşanan karmaşanın önemli bir bölümü, ekibin sorunun hangi katmanda meydana geldiğini belirlememesinden kaynaklanır. Pod'un IP adresi vardır, ancak bu adres değişkendir; servis IP adresi ise sanaldır ve sabittir. Ayrıca bu IP üzerinde doğrudan dinleme yapan bir işlem bulunması da gerekmez. İncelenen katmanı bilmek, ek tanılama komutları çalıştırmadan önce belirsizliğin büyük bir bölümünü ortadan kaldırabilir.
requests ve limits değerlerini operasyonel sınırlar olarak ele alın
Kaynak, kaynak isteklerini (requests) ve sınırlarını (limits) yalnızca yol gösterici değerler değil, operasyonel iş yükünün hayatta kalma sözleşmeleri olarak tanımlıyor. Zamanlayıcı, iş yükünü çalıştırmak için uygun yeri belirlerken request değerini kullanır; limit ise aşılmaması gereken üst sınırı temsil eder.
Kaynakları olduğundan fazla bildirmek kapasitenin israfına, olduğundan az bildirmek ise düğüm alanı tükendiğinde kritik bir anda pod'ların tahliye edilmesine yol açabilir. Yazar bu hatayı, test ortamında çalışıp üretimde çöken iş yükleri arasındaki tekrarlanan farkla ilişkilendiriyor ve sorunun uygulama kodunda değil, kaynakların tanımlanma biçiminde olabileceğini açıklıyor.
CNI ve CSI eklentileri neden var?
Beşinci temel unsur, ağ ve depolama uygulamalarının Kubernetes içine tek bir uygulama olarak dahil edilmek yerine neden CNI ve CSI gibi eklentilere bırakıldığını anlamaktır. Kaynak, platformun sözleşmeleri tanımladığını, ancak uygulamayı eklentilere bıraktığını açıklıyor; çünkü uç ortamındaki küçük bir kümenin ihtiyaçları, çok bölgeli ve düzenlemelere tabi bir ortamın ihtiyaçlarından kökten farklıdır.
Bu, araçlar ve seçenekler ekosisteminin neden bu kadar geniş olduğunu açıklar. Ağ için birden fazla seçeneğin bulunması mutlaka tesadüfi bir karmaşa değildir; bu durum, tüm ortamlara tek bir tasarım dayatmak yerine esnekliğin seçilmesinin doğrudan sonucudur. Bu, eklenti seçiminin kolaylaştığı anlamına gelmez; ancak seçeneklerin çokluğunu doğru bağlama yerleştirir.
Öğrenen açısından pratikte ne değişir?
Önerilen yaklaşım GitOps, gözlemlenebilirlik, servis ağları ve politika motorları gibi konuları ortadan kaldırmaz; ancak öğrenenin bu konuları anlamlı kılacak bir sorunla karşılaşmasına kadar erteler. Temel mekanizma, kontrol düzlemi ile düğümlerin yapısı, ağ yolu ve kaynak sınırları anlaşıldıktan sonra bu konulara geçiş, tüm “haritayı” kapsamaya çalışmak yerine belirli bir pratik soruya dayanır.
Bu, eğitimsel bir değerlendirmedir; sertifika almak için resmî bir yol veya uzmanlaşmış belgelerin alternatifi değildir. Kaynak ayrıca kurulum adımları ya da çalıştırma komutları sunmaz; ilk anlayışı oluşturmak için bir çerçeve sunar. Maddenin sonunda yazar, kubeschool.portainer.io adresinde sağlayıcıdan bağımsız olduğunu belirttiği ücretsiz bir eğitim kaynağına işaret ediyor. Bu kaynak yazarın bağlı olduğu kuruluşla ilişkilidir; dolayısıyla burada bağımsız olarak doğrulanmış bir başvuru kaynağı değil, kaynakta önerilen bir kaynak olarak değerlendirilmelidir.