Argo CD 3.5 yükseltme rehberi denetim baskısı altındaki paylaşımlı kümeleri hedefliyor

Oleksandr Kuryzhev tarafından dev.to'da yayımlanan bir rehber, operasyon ekiplerinin paylaşımlı kümedeki Argo CD kurulumlarını 3.5 sürümüne nasıl taşıması gerektiğini ortaya koyuyor; merkezi iddiası ise bu geçişin manifest'te bir sürüm numarası değiştirmek değil, provası yapılmış bir rollout'u gerektirdiği.

Senaryo tanıdık: paylaşımlı bir kümede birkaç yüz Application ile Argo CD 3.2 veya 3.3 çalıştıran bir platform ekibi ve bir sonraki denetimden önce 3.5 isteyen bir talep. Makaleye göre Argo CD 3.5 Ağustos 2026'da çıktı ve 3.5.6'ya kadar yama sürümleri takip etti; upstream destek politikası yalnızca en yeni minor hatlarını kapsadığı için, bir ekip bekledikçe aşılması gereken fark büyüyor. Yazar, yazıyı bir değişiklik günlüğünün tekrarı değil bir süreç rehberi olarak konumlandırıyor ve davranış değişikliklerinin yetkili kaydı olarak operator kılavuzundaki yükseltme bölümü ile sürüm notlarına işaret ediyor.

Her şey hareket etmeden önce hazırlık

Ön koşullar Kubernetes izinleriyle başlıyor: Argo CD namespace'inde admin hakları ve CRD'ler ile cluster role'leri uygulamak için küme kapsamlı haklar. argocd CLI'sı hedef sunucuyla eşleşmelidir, çünkü birkaç minor geride kalan bir istemci daha yeni bir API sunucusuna karşı tuhaf davranabilir. Staging ortamı temsili bir Application, ApplicationSet dilimi ile gerçek argocd-cm ve argocd-rbac-cm ayarlarını taşımalıdır — yazar, ham bir kurulumun az şey ortaya koyduğunu belirtiyor. Ekiplerin ayrıca kurulum yöntemlerini yazılı hale getirmesi gerekiyor, çünkü ham manifest'ler, Kustomize overlay'leri ve topluluk Helm chart'ı sürümleri farklı şekilde sabitler ve bir chart sürümü, uygulama sürümüyle aynı sayı değildir.

Bir dış bağımlılık özel attention alıyor: ingress-nginx. Rehber, controller'ın Mart 2026'da emekliye ayrıldığını ve başka güvenlik düzeltmesi almadığını belirttiği için, arkasında duran bir Argo CD sunucusu Gateway API'ye veya bakımı yapılan başka bir controller'a taşınmalıdır — ayrı bir değişiklik olarak, çünkü ikisini tek pencerede birleştirmek herhangi bir login veya gRPC hatasını teşhis ederken belirsiz kılar.

Önce snapshot, sonra her minor'ın notlarını okuyun

Birinci adım geri yüklenebilir bir yedek ve bir baseline yakalar. argocd admin export ile üretilen yedek, Application'ları, AppProject'leri, ayarları ve secret'ları içerir ve depo kimlik bilgileri ile küme secret'ları içerebileceği için şifreli saklanmalıdır. Baseline, yükseltmeden sonra karşılaştırma için argocd app list ile alınan her Application'ın adı, sync durumu ve sağlık durumunun bir listesidir. Rehber ayrıca hangi Application'ların halihazırda OutOfSync veya Degraded olduğunu kaydetmeyi öneriyor, böylece önceden var olan sapma yeni sürümün üzerine yıkılmaz.

İkinci adım okumak: mevcut minor ile 3.5 arasındaki her yükseltme notu, sırayla, çünkü atlanan notlar varsayılanların fark edilmeden değiştiği yerlerdir. Yazar öğeleri yapılandırma düzenlemesi gerektiren breaking change'ler, runtime davranışını değiştiren varsayılan değişiklikleri ve kaldırma tarihli deprecation'lara ayırıyor, sonra bunları argocd-cm, argocd-cmd-params-cm, argocd-rbac-cm ve varsa config management plugin'leriyle karşılaştırıyor.

İki alan ekstra inceleme alıyor. Resource tracking veya ignore-difference ayarlarındaki değişiklikler, aksi halde temiz bir yükseltmeden sonra yüzlerce Application'ı OutOfSync'e çevirebilir, bu yüzden staging'de gerçek Application'larla argocd app diff kullanılarak test edilmelidir. Ve repo-server imajında paketli gelen Helm ve Kustomize sürümleri minor'lar arasında değişebilir ve aynı chart için üretilen çıktıyı değiştirebilir.

Staging'de prova yapın, sonra üretime taşıyın

Prova tam bir yama sürümünü sabitler — yazım anında v3.5.6, asla hareketli bir tag değil — ve upstream manifest'i server-side apply ve --force-conflicts ile uygular; bu, Argo CD'nin büyük CRD'lerini annotation boyutu hataları olmadan ele almanın belgelenmiş yoludur. Manifest topolojiyle eşleşmelidir: bir HA kurulumunun üzerine standart install.yaml uygulamak HA bileşenlerinin yerine geçer. --force-conflicts ile belgelenmiş bir tuzak, uygulamanın upstream manifest'in ayarladığı her alanın sahipliğini alması ve kubectl edit veya kubectl patch ile yapılmış el düzenlemelerini, overlay içinde olmadıkça sıfırlamasıdır.

Üretime geçiş sakin bir pencereye, sync ortasındaki büyük bir sürümün uzağına aittir. Application controller yeniden başlar ve her şeyi yeniden reconcile eder; ortaya çıkan repo-server ve API sunucusu yük patlaması, yazara göre büyük kurulumlar için yükseltmenin baskın maliyetidir. Geri alma somuttur — önceki sabitlenmiş manifest'i yeniden uygulayın, sonra durum bozuksa export'tan argocd admin import ile geri yükleyin — ancak CRD şema değişiklikleri her zaman temiz geri alınamaz, bu yüzden taşımayı gerçekten risksizleştiren şey geri alma değil provadır. Bir instance'dan çok küme çalıştıran ekiplere önce ikincil bir instance'ı yükseltmeleri önerilir. Doğrulama döngüyü kapatır: sunucu sürümünü onaylayın, uygulama listesini yeniden üretin ve baseline ile karşılaştırın.

Neden önemli

Argo CD'nin destek politikası ve denetim son tarihleri hareket etmek için gerçek bir baskı yaratıyor, ancak paylaşımlı kümeler riski yoğunlaştırıyor: resource tracking'deki tek bir varsayılan değişikliği yüzlerce Application'da kitlesel OutOfSync durumu olarak ortaya çıkabilir ve bir yükseltmeyi bir olaya dönüştürebilir. Rehberin değeri, bir sürüm atlamasını karşılaştırılabilir bir baseline'la provalı, diff'lenebilir bir sürece dönüştürmesidir; uyarıları — emekliye ayrılmış bir ingress controller'ı, CLI sürüm uyuşmazlıkları, chart-uygulama sürümü karmaşası, her zaman geri alınamayan CRD değişiklikleri — yükseltmeleri rutin sayan ekipleri ısıran belirli arıza modlarını adlandırır. Resmî Argo CD yükseltme dokümantasyonu davranış değişiklikleri için doğruluk kaynağı olmaya devam ediyor; dev.to yazısı ise bu değişiklikleri hayatta kalabilir kılan süreci sunuyor.