Kubernetes yükseltmeleri sırasında EKS node'larını kesintisiz döndürmek için add-on sürümlerini köprülemek

dev.to'da yayımlanan bir gönderi, Amazon EKS node gruplarını kesintisiz yükseltmek için bir teknik ortaya koyuyor: node'ları bir Kubernetes minor sürümünden bir sonrakine döndürmeden önce, her EKS add-on'unu hem mevcut hem de hedef Kubernetes sürümünde desteklenen en yeni sürüme taşıyın. Yazar buna "köprü sürümü" (bridge version) hilesi diyor ve teknik, AWS'nin dokümante ettiği yükseltme sırasındaki belirli bir zafiyeti gideriyor.

Standart yükseltme sırasındaki boşluk

dev.to gönderisine göre AWS yükseltme kılavuzu önce control plane, sonra node'lar, sonra add-on'lar sırasını öngörüyor. Bu kağıt üzerinde işe yarar, ancak node döndürmesi sırasında yeni node'ların, yalnızca önceki Kubernetes minor sürümüne karşı doğrulanmış eski add-on sürümlerini çalıştırdığı bir pencere bırakıyor.

En çok acı veren add-on'lar, her pod'un bağımlı olduğular. Vpc-cni her node'da pod IP'lerini dağıtır, CoreDNS her workload için isim çözümlemesi yapar, aws-ebs-csi-driver ise stateful pod'lar için volume'leri bağlar. Yazarın belirttiği gibi, bunlardan biri yeni döndürülmüş bir node'da yanlış davranırsa, bunu roll'un tam ortasında, çevrenizde her yana yeniden planlanan pod'larla öğrenirsiniz.

Köprü sürümü nedir

Köprü sürümü, hem mevcut hem de hedef Kubernetes sürümünüzün desteklenen sürüm listelerinde görünen en yeni add-on sürümüdür. Node'lar döndürülmeden önce her add-on köprü sürümündeyse, eski node'lar eski sürüm için doğrulanmış bir add-on sürümü, yeni node'lar aynı sürümün yeni sürüm için doğrulanmış halini çalıştırır ve hiçbir node, kendi Kubernetes sürümü için doğrulanmamış bir add-on çalıştırmaz.

Gönderiye göre köprü sürümü her iki sürümde de geçerli olduğu için node yükseltmesinden önce herhangi bir noktada uygulanabilir: ya daha eski minor'dayken en başta, ya da control plane yukarı taşındıktan hemen sonra. Yazarın kullandığı sıra şöyle: önce control plane, sonra köprü add-on'ları, sonra node'lar ve isteğe bağlı olarak son olarak varsayılan add-on sürümlerine geçiş. Bu AWS'nin rehberiyle çelişmez; node döndürmesinden önce tek bir ekstra güvenli adım ekler.

Köprü sürümünü bulmak

EKS, aws eks describe-addon-versions komutuyla belirli bir Kubernetes sürümü için bir add-on'un kullanılabilir her sürümünü listeleyebilir. Köprü, basitçe her iki listede de bulunan en yeni sürümdür ve gönderi, ikisini de sorgulayan, kesişimlerini alan ve en yüksek ortak girdiyi seçen bir bash script'i içeriyor; kesişim yoksa ara bir atlama gerekebileceği uyarısını da ekliyor.

Yazarın kümesinde Kubernetes 1.35'ten 1.36'ya geçerken çoğu add-on'un her iki sürümde zaten aynı en yeni sürümü vardı: vpc-cni v1.23.1-eksbuild.1, coredns v1.14.6-eksbuild.4, aws-ebs-csi-driver v1.66.0-eksbuild.1 ve metrics-server v0.9.0-eksbuild.11. Bunlar için köprü, yalnızca en yeni build'dir.

Kube-proxy istisna. Sürümü Kubernetes minor'unu takip ettiği için 1.36'daki en yeni sürüm (v1.36.0-eksbuild.25) 1.35'te mevcut değil ve köprü, 1.35 build'i olan v1.35.3-eksbuild.29. Tavsiye, node'lar tamamen 1.36'ya geçene kadar kube-proxy'yi bu köprüde tutmak.

Terraform nasıl kablolu

Control plane sürümü tek bir değişkenden, var.cluster_version değişkeninden gelir; dolayısıyla bunu 1.35'ten 1.36'ya değiştirmek Terraform'un kümeyi yerinde güncellemesini sağlar. Gönderi, EKS'nin bir seferde yalnızca bir minor sürüm yükselttiğini ve geri alma sunmadığını vurgulayarak bunu en dikkatli planlanması gereken adım yapıyor. VPC ve erişim yapılandırması yükseltme sırasında değişmez, node'lar ve add-on'lar ayrı kaynaklar olduğu için control plane tek başına hedeflenebilir.

Yönetilen node grubu aynı sürüm değişkenini okur ve bu, node AMI'sini control plane sürümüne bağlar. Değişkeni değiştirmek, grubu eşleşen ETS-optimize AMI'ye döndürür... doğru yazımıyla EKS-optimized AMI'ye döndürür. İki ayar bu döndürmenin davranışını şekillendirir: max_unavailable = 1 aynı anda tek node'u döndürür ki geri kalanlar trafiğe hizmet vermeye devam etsin, force_update_version = true ise bir PodDisruptionBudget pod drain'lerini engellese bile güncellemenin ilerlemesine izin verir. Yazar, EKS'nin PDB'ye rağmen eninde sonunda pod'ları tahliye edeceği için bunu kullanılabilirliğe mal olabilecek tek ayar olarak işaretliyor; bu nedenle kritik workload'ların yeterli kopyaya ihtiyacı var.

Add-on'lar, bir liste değişkeni üzerinde yinelenen tek bir aws_eks_addon kaynağıyla yönetilir; dolayısıyla sürüm yükseltmek bir veri değişikliğidir. EBS CSI driver, service account role ARN'i alan tek add-on'dur.

Neden önemli

Node döndürmesi, bir EKS yükseltmesinin gerçek olduğu yerdir: workload'ların fiilen taşındığı ve bozuk bir add-on'un olay olarak ortaya çıktığı an tam da budur. Add-on uyumluluk çalışmasını döndürmeden önce uygulanan bir köprü sürümüne kaydırmak, node yükseltmelerini riskli kılan sürüm uyumsuzluğunu ortadan kaldırır ve AWS'nin önerdiği sıranın yerine geçmek yerine ona eklenir. Terraform ile EKS yöneten ekipler için bu yaklaşım yükseltme yolunu da basit tutar: tek bir değişken control plane'i ve node'ları yönetir, add-on sürümleri ise bilinen iyi hedeflere sahip veri değişikliklerine dönüşür. Uyarılar her zamanki gibi geçerli: kube-proxy'nin her iki sürümde aynı en yeni sürümü olmayacak, zorlanan güncellemeler disruption budget'ları geçersiz kılabilir ve control plane yükseltmesi geri alınamaz.