EKS Auto Mode uygulamalı: Düğümleri, autoscaling'i ve add-on'ları AWS yönetiyor

Auto Mode neleri değiştiriyor

dev.to'da yayınlanan uygulamalı bir inceleme, bir Kubernetes cluster'ının compute, storage ve network yönetiminin operatör yerine AWS'e geçtiği Amazon seçeneği EKS Auto Mode'u ele alıyor. Yazarın belirttiğine göre arka planda Karpenter ve Bottlerocket tabanlı node'lar çalışıyor, ancak bu detaylar perde arkasında kalıyor: boyutlandırılacak node group'lar ve tek tek kurulup sürümlenecek add-on'lar yok.

Hedeflenen sorun, geleneksel bir EKS cluster'ı işletmenin operasyonel yükü. Yazar, operatörlerin normalde sahip olduğu işleri sıralıyor: node group'ları seçmek ve boyutlandırmak, Spot ile On-Demand arasında karar vermek, Cluster Autoscaler veya Karpenter gibi bir autoscaler'ı IAM izinleriyle birlikte kurup ayarlamak, CoreDNS, kube-proxy, EBS CSI driver ve VPC CNI gibi add-on'ları yönetmek, bir işletim sistemi CVE'si çıktığında node AMI'lerini yamalamak ve yetersiz bellek yüzünden Pending durumunda takılan pod'ları debug etmek. Yazara göre bunların hiçbiri ürünü daha iyi yapmıyor — bu emek yalnızca Kubernetes'in var olabilmesi için var.

Tek komut, iki node pool'u

Laboratuvar için AWS CLI v2, eksctl v0.195.0 veya daha yeni bir sürüm, kubectl ve EC2, EKS, IAM ile VPC'yi kapsayan IAM izinleri gerekiyor. İncelemeye göre, auto mode bayrağıyla verilen tek bir eksctl create cluster komutu, cluster'ı, VPC'yi, subnet'leri ve AWS tarafından yönetilen temel add-on'ları yaklaşık 15 dakikada ayağa kaldırıyor.

Auto Mode ardından kendi başına iki node pool oluşturuyor. System pool, CoreDNS ve yönetilen add-on'lar gibi cluster iç bileşenlerini barındıran tek bir node ile başlıyor; bu yüzden cluster oluşturulduktan hemen sonra kubectl get nodes bir node gösteriyor. General-purpose pool sıfırdan başlıyor ve bir workload compute'a ihtiyaç duyana kadar boş kalıyor. Yazarın çıkarımı: boş bir application pool bir arıza durumu değildir — henüz planlanmış bir şey yoktur ve AWS boşta duran node'lar için ücret almıyordur.

Node'lar ihtiyaç anında geliyor

Laboratuvarda, üç replikalı bir nginx deployment'ının LoadBalancer service ile dağıtılması, general-purpose pool'da yaklaşık 30 saniyede bir node'un ortaya çıkmasını sağladı; ne bir autoscaler'a dokunuldu ne de bir node group düzenlendi. Deployment on replikaya çıkarıldığında, mevcut kapasite yetmeyince ek instance'lar geldi. Temizlik tek bir eksctl delete cluster komutu; yazar ayrıca faturada kötü bir sürpriz yaşamamak için laboratuvar kaynaklarının mutlaka yıkılması gerektiğini vurguluyor.

Karşılığında ne veriyorsunuz

İnceleme, klasik EKS ile Auto Mode'u birçok eksende karşılaştırıyor: node yönetimi operatörden ya da kendinizin işlettiği bir Karpenter'dan AWS'e geçiyor; add-on'lar yönetilen hale geliyor; AMI güncellemeleri AWS'in işi oluyor; autoscaling otomatikleşiyor. Karşılığında özelleştirme seviyesi tamdan sınırlıya düşüyor, ama öğrenme eğrisi dikten yumuşağa iniyor.

Yazar, hızlıca yeni bir cluster kurarken, node'lara bakacak birisini ayıramayan küçük ekipler için ve API'lar, worker'lar ve web servisleri gibi oldukça standart workload'lar için Auto Mode'u öneriyor. Çok özel node yapılandırmalarına — özel kernel'ler, zahmetli DaemonSet'ler, özel sürücülü GPU'lar — bağlı workload'larda, para kazandıran iyi ayarlanmış bir Karpenter'ı zaten işleten ekiplerde ve AMI yaşam döngüsünün tamamen kontrol edilmesini gerektiren uyumluluk rejimlerinde ise temkinli olunması tavsiye ediliyor.

Maliyet sorusu

Yazıya göre Auto Mode, altta yatan EC2 maliyetlerinin üzerine küçük bir yönetim ücreti ekliyor. Yazar asıl hesabı şöyle kuruyor: ücret eksi artık node'lara, autoscaler'lara ve yamalamaya harcanmayan mühendislik saatleri — bu da tabloyu epey değiştiriyor.

Neden önemli

Node boyutlandırma, autoscaler bakımı ve AMI yamalama, AWS üzerinde production Kubernetes işletmenin en kalıcı zaman yutanları arasında ve bunların hiçbiri üstünde çalışan yazılımı farklılaştırmıyor. Auto Mode bu katmanın tamamını shared-responsibility çizgisinin öte yanına, AWS'e taşıyor ve tamamen yönetilen Kubernetes yüzeylerine doğru devam eden daha geniş eğilimi sürdürüyor. Takas açık: operatörler node düzeyinde kontrol derecelerinden vazgeçiyor ve operasyonel saat geri kazanıyor. Standart workload'lar için bu anlaşma güçlü görünüyor; özel veya uyumluluka bağlı cluster'larda yazarın anlattıkları manuel yolun hâlâ geçerli olduğunu düşündürüyor. Production'da EKS çalıştıran ekipler, karar vermeden önce kritik olmayan bir workload'da deneyip kazanılan zamanı ölçebilir.