İş hedeflerine hizalı yükseltmeler için GKE rollout sequencing özel aşamalarla GA oldu

Aşamalı yükseltme hattı nasıl çalışıyor

Google Kubernetes Engine her zaman otomatik yükseltmeleri kademeli olarak uygulamıştır, ancak sıralama Google Cloud'un bölgesel zaman çizelgelerini izler. dev.to'da yayınlanan bir Google Cloud teknik kılavuzuna göre bu varsayılan, bir organizasyonun ortamları haritayla örtüşmemeye başladığında bağımsız cluster'lar için pek uygun düşmüyor: bölgesel bir rollout, başka yerde ön üretim doğrulaması tamamlanmadan önce üretim cluster'larına ulaşabiliyor.

Artık genel kullanıma açılan özel aşamalı rollout sequencing özelliği tam da bunu çözmek için tasarlandı. Platform ekipleri, geliştirme, staging ve üretim ortamları için mantıksal sınırlar görevi gören GKE fleet'lerine referans veren RolloutSequence adlı merkezi bir kaynakta sıralı bir yükseltme hattı tanımlıyor.

GKE bir release channel için yeni bir otomatik yükseltme hedefi yayınladığında ya da bir operatör açıkça bir sürüm tetiklediğinde, bir Rollout nesnesi oluşturulur ve yapılandırılmış aşamaları sırayla dolaşır. Her aşamada önce control plane yükseltmeleri başlar; oradaki tüm control plane'ler hedef sürüme ulaştığında bir soak sayacı devreye girer. Node yükseltmeleri paralel ilerler ve surge veya blue-green gibi mevcut node pool stratejilerine uymaya devam eder. Rollout, ancak hem control plane'ler hem node'lar tamamlandığında ve soak süresi dolduğunda bir sonraki aşamaya geçer.

Çok aşamalı hatların süresiz takılmasını önlemek için GKE, bir aşamanın yükseltmeyi bitirmesinin 30 günden fazla sürmesi durumunda (bu, bakım pencereleri veya hariç tutmalar kısıtlayıcıysa yaşanabilir) zorunlu bir soak süresi uygular.

Fleet'leri label selector'larla bölmek

Önceki fleet tabanlı sıralama katı biçimde fleet düzeyinde işliyordu; yani bir sonrakinin başlaması için tüm fleet'in bitmesi gerekiyordu. Özel aşamalar bunu değiştiriyor: tek bir fleet artık Common Expression Language (CEL) label selector'ları kullanılarak birden fazla rollout aşamasına bölünebiliyor. Tipik bir kullanım, üretim fleet'i içinde diğer her şeyden önce yükseltilen bir canary katmanı ayırmaktır.

İki mimari kural geçerlidir. Bir aşama bir fleet'i label selector ile filtreliyorsa, o fleet'e referans veren son aşama selector'ı bırakmalıdır; böylece hiçbir cluster atlanmaz ve bu aşama bir nevi kapsayıcı rolü oynar. Ayrıca bir cluster birden fazla aşamayla eşleştiğinde GKE onu yalnızca en erken eşleşen aşamaya atar.

Sequence'lar gcloud CLI ile kaydedilir; aşama tanımları bir YAML manifest olarak verilir ve RolloutSequence merkezi bir yönetim projesinde oluşturulur.

Runtime kontrolleri ve yükseltme kapsamı

Özellik ayrıca, yapılandırmayı sökmeden aktif rollout'lar üzerinde yaşam döngüsü eylemleri getiriyor. Canary aşamasındaki doğrulama sorunlar ortaya çıkarırsa operatörler rollout'u duraklatabilir; bu, o aşamada ve sonraki aşamalarda yeni cluster yükseltmelerinin başlamasını engellerken devam eden işlemlerin bitmesine izin verir ve sorun giderildikten sonra rollout devam ettirilebilir. force-complete-stage eylemi, otomatik testler kararlılığı zaten doğruladığında kalan soak süresini atlar ve bir sürüm çözülemeyen bir gerileme taşıyorsa rollout tamamen iptal edilebilir.

Otomatik yükseltme kapsamı da daraltılabilir. Bir sequence yalnızca control plane ve node patch yükseltmeleriyle sınırlanabilir, böylece minor sürüm değişiklikleri manuel kontrol altında kalır. Zorunlu yükseltmeler bunu yine de geçersiz kılar: 90 gündür patch'lenmemiş control plane'ler ve sürüm desteğinin sonuna yaklaşan cluster'lar, istikrar ve güvenliği korumak için yükseltilmeye devam eder.

Ölçek sınırları ve çoklu organizasyon desteği

Kılavuza göre tek bir RolloutSequence 15'e kadar farklı aşamayı destekler. Fleet'ler 250'ye kadar cluster barındırır; hafif üyelikler ve onaylı bir kota artışıyla bu sayı 2.000'e kadar çıkabilir. Bir sequence boyunca toplam soak süresi 90 günle, tek tek aşama soak süreleri ise 30 günle sınırlıdır. Sequence'lar projeleri hatta farklı Google Cloud organizasyonlarını kapsayabilir ve Google, sürekli teslim pratiğiyle uyumlu olarak RolloutSequence kaynaklarının adanmış bir host projesinde tutulmasını önerir.

Neden önemli

Büyük fleet operatörleri uzun süredir patch güncelliği ile üretim güvenliği arasında seçim yapmak zorundaydı, çünkü bölgesel rollout takvimleri hangi cluster'ların gerçekten en önemli olduğunu bilmiyordu. Yükseltme sıralamasını iş topolojisine bağlı bildirimsel bir yapılandırmaya dönüştürerek GKE bu boşluğu kapatıyor. Label tabanlı canary katmanları, soak sayaçları, duraklatma ve devam ettirme kontrolleri ve yalnızca patch yükseltmelerini otomatikleştirme yeteneği, cluster patch'lemeyi aşamalı bir yazım teslim hattına benzer bir şeye dönüştürüyor; bu da çoğu kurumsal işletmenin yönetilen bir Kubernetes platformundan beklediği kontrol düzeyi.