Cluster API v1.12: Yerinde Güncelleme ve Zincirleme

⏱️ 4 dk okuma📅 8 Ağustos 2026

Cluster API, Kubernetes kümelerinin yaşam döngüsünü bildirimsel biçimde yönetmek için geliştirilen bir projedir. Kullanıcılar ve platform ekipleri kümelerin istenen durumunu tanımlar, denetleyiciler de bu duruma sürekli yakınsamayı sağlar. Kubernetes’te Pod gruplarını yönetmek için StatefulSet veya Deployment kullandığınız gibi, Cluster API’de de kontrol düzlemi Machine’lerini yönetmek için KubeadmControlPlane, işçi Node gruplarını yönetmek için MachineDeployment kullanırsınız.

Yeni yayımlanan Cluster API v1.12.0 sürümü, sık yapılan yaşam döngüsü işlemlerindeki sürtünmeyi azaltmak için iki önemli özellik getiriyor: yerinde güncellemeler (in-place updates) ve zincirleme yükseltmeler (chained upgrades).

Sadelik ve kullanılabilirlik ön planda

v1.12.0, Cluster API topluluğunun yeniliği kullanıcıya minimum etkiyle sunma anlayışını bir kez daha yansıtıyor. Pratikte kullanıcının yapması gereken tek şey, önceki sürümlerde olduğu gibi Cluster veya Machine özelliklerini (spec) değiştirmek. Cluster API, mümkün ve uygun olduğunda yerinde güncellemeleri veya zincirleme yükseltmeleri otomatik olarak devreye alıyor.

Yerinde güncellemeler (in-place updates)

Kubernetes’in Deployment içindeki Pod’lar için yaptığına benzer şekilde, Cluster API de Machine spec’i değiştiğinde yeni bir Machine oluşturup eskisini silerek dağıtımı (rollout) gerçekleştiriyordu. Değişmez altyapı (immutable infrastructure) ilkesinden esinlenen bu yaklaşımın belirgin avantajları var:

Açıklaması kolay, öngörülebilir, tutarlı ve üzerinde düşünmesi basit.
Yalnızca iki temel işleme (oluşturma ve silme) dayandığı için uygulaması sade.
İşletim sistemi, önyükleme mekanizması gibi Machine’e özgü tercihlere bağımlı değil.

Değişmezliğin avantajları tartışmasız olsa da hem Kubernetes hem de Cluster API, iş yükü kesintilerini azaltacak iyileştirmeleri zamanla ekliyor. Cluster API tarafında önceki adımlar şunlardı:

Yalnızca Kubernetes kaynaklarını etkileyen değişikliklerin gereksiz rollout yaratmadan yerinde yayılabilmesi (in-place propagation).
Güncel olmayan Node’ların PreferNoSchedule ile işaretlenmesi; böylece rollout sırasında Pod’ların yeniden zamanlanma yükünün azaltılması.
Bare metal veya kısıtlı kaynaklı ortamlarda değişmez rollout’u kolaylaştıran “önce sil” (delete first) stratejisi.

v1.12.0 ile gelen yerinde güncelleme özelliği bu yolun bir sonraki adımı. Sürüm, Machine’leri silip yeniden oluşturmadan mevcut Machine’ler üzerinde değişiklik yapmayı sağlayan update extension desteğini getiriyor. Hem KubeadmControlPlane hem de MachineDeployment, bu yeni uzantı üzerinden yerinde güncellemeleri destekliyor. Bu da Cluster API’de mümkün olanın sınırını önemli ölçüde genişletiyor.

Yerinde güncellemeler nasıl çalışıyor?

En yalın anlatımıyla: Kullanıcı, Machine’lerin istenen durumunu değiştirerek bir güncelleme tetiklediğinde, Cluster API bu duruma ulaşmak için en uygun yolu kendisi seçiyor. Yeni olan şey, Cluster API’nin artık değişmez rollout ile yerinde güncelleme uzantısı arasında tercih yapabilmesi.

Burada dikkat edilecek bir nokta var: Bu, “değişmez rollout’a karşı yerinde güncelleme” meselesi değil. Cluster API her iki seçeneği de geçerli sayıyor ve ilgili değişiklik için en uygun mekanizmayı belirliyor. Cluster API bakımcılarının bakış açısına göre yerinde güncellemeler, Node drenajı veya Pod yeniden başlatması gerektirmeyen değişiklikler için (örneğin Machine kullanıcı kimlik bilgilerini değiştirmek) en yararlı seçenek. İş yükünün nasılsa kesintiye uğrayacağı durumlarda ise doğrudan rollout tercih ediliyor.

Yine de Cluster API genişletilebilir doğasına sadık kalıyor: Herkes kendi update extension’ını oluşturabilir ve değişmez rollout’un bazı avantajlarından ödün vererek yerinde güncellemeleri ne zaman ve nasıl kullanacağına karar verebilir.

Zincirleme yükseltmeler (chained upgrades)

Cluster API’deki ClusterClass ve yönetilen topolojiler (managed topologies), Kubernetes-as-a-Service sunan birçok platform için güçlü bir yapı taşı sağlıyor. v1.12.0 ile bu çerçeve önemli bir adım daha atıyor: Kullanıcılar artık tek bir işlemle birden fazla Kubernetes minör sürümünü aşarak yükseltme yapabiliyor. Bu işlem chained upgrade olarak adlandırılıyor.

Böylece kullanıcı bir hedef Kubernetes sürümü belirtiyor; ara adımları güvenli biçimde düzenlemek Cluster API’nin sorumluluğunda oluyor. Her minör yükseltmeyi tek tek yönetmek gerekmiyor.

Çalışma mantığı da sade: Kullanıcı Cluster için istenen sürümü değiştirerek güncellemeyi tetiklediğinde, Cluster API bir yükseltme planı (upgrade plan) hesaplıyor ve uygulamaya başlıyor. Örneğin bir Cluster’ı önce v1.33.0’a, sonra v1.34.0’a, ardından v1.35.0’a yükseltip her adımı ayrı ayrı takip etmek yerine, zincirleme yükseltme doğrudan v1.35.0’a gitmenizi sağlıyor.

Bir yükseltme planının uygulanması, kontrol düzlemi ve işçi Machine’lerinin sıkı biçimde kontrol edilen bir sırayla yükseltilmesi ve bu sürecin hedef duruma ulaşana kadar tekrarlanması demek. Cluster API bu döngüyü sizin yerinize yönetiyor.

Cluster API, işçi Machine’leri için yükseltme adımlarını optimize edip minimize ediyor. Kubernetes sürüm eğrilik (skew) politikalarının izin verdiği durumlarda işçi Machine’ler ara minör sürümlerdeki yükseltmeleri atlayabiliyor.

Bu özellikte de genişletilebilirlik merkezde: upgrade plan runtime extension‘ları planın nasıl hesaplanacağını etkilemek için kullanılabiliyor. Benzer şekilde lifecycle hook‘lar, örneğin kontrol düzlemi yükseltmesi tamamlandıktan sonra bir eklentiyi güncellemek gibi yükseltme sırasında yapılması gereken diğer görevleri otomatikleştirmek için devreye alınabiliyor.

Cluster API bakımcılarına göre zincirleme yükseltmeler, Kubernetes minör sürümlerine ayak uydurmakta zorlanan; örneğin yılda yalnızca bir kez ve üç sürüm birden (n-3 → n) atlayarak yükseltme yapmak isteyen kullanıcılar için özellikle faydalı. Bir uyarı da var: Birden fazla minör sürümü kolayca atlayabiliyor olmanız, kümenizi sık sık yamalamamak için bir bahane değil.

Değerlendirme

Cluster API manifestosunda belirtildiği gibi, alt proje “tamamlanmamış kalma hakkını” savunuyor; kullanıcı ihtiyaçları ve Cloud Native ekosistemi değiştikçe kendini de sürekli geliştirme gereğini kabul ediyor. Kubernetes gelişmeye devam ettikçe Cluster API de daha güvenli yükseltmeler, azaltılmış kesintiler ve büyük ölçekli Kubernetes yönetimi için daha güçlü yapı taşları etrafında yol almayı sürdürecek gibi görünüyor.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102