Azure Kubernetes Service (AKS) küme yükseltmeleri nasıl çalışır?

Önemli

AKS platformu tarafından başlatılan yükseltme işlemleri. 1 Haziran 2027'den itibaren AKS, 60 günlük platform destek ek süresi sona erdikten sonra desteklenmeyen bir Kubernetes sürümünde kalan tüm kümeleri otomatik olarak yükseltir. Platform tarafından başlatılan yükseltme bakım pencerenizi izlemez, kullanım dışı API kullanımı için durmaz ve düğüm boşaltmasını engelleyen pod kesinti bütçesini geçersiz kılabilir , bu nedenle iş yükleri kesintiye uğrayabilir. Yükseltme ayından önce, hedef Kubernetes sürümünde kaldırılmış API'leri değiştirin ve uyumsuz kendi kendine yönetilen eklentileri güncelleştirin. Platform tarafından başlatılan yükseltmeyi önlemek için kümelerinizi desteklenen bir Kubernetes sürümünde tutun. Daha fazla bilgi için bkz. AKS'de platform tarafından başlatılan yükseltmelere hazırlanma.

Azure Kubernetes Service (AKS) çalışan iş yüklerinde kesintiyi en aza indirmek için sıralı yükseltmeler gerçekleştirir.

Çoğu üretim iş yükü için AKS Otomatik, uygun olduğunda önerilen varsayılan değerdir. AKS Otomatik, otomatik Kubernetes sürüm yükseltmeleri, otomatik düğüm işletim sistemi (OS) görüntü güncelleştirmeleri, yönetilen sistem düğümü işlemleri ve el ile ek yükü azaltan yerleşik korumalar gibi yükseltme işlemleri için üretime hazır varsayılanlar içerir. Daha fazla bilgi için bkz. AKS Otomatik'e giriş.

Bu makalede AKS yükseltme mekaniği açıklanır ve AKS Otomatik ile AKS Standard'ın farklı olduğu noktalar vurgulanır.

Önkoşullar

Yükseltme modeli: AKS Otomatik ve AKS Standard

AKS Otomatik ve AKS Standart küme modları aynı Kubernetes yükseltme temellerini kullanır, ancak varsayılanlar ve operasyonel sahiplik açısından farklılık gösterir.

Yükseltme endişesi AKS Otomatik AKS Standard
Üretim konumlandırma Uygun olduğunda çoğu üretim iş yükü için önerilen varsayılan değer Varsayılan olarak daha el ile yapılandırmaya sahip esnek model
Kubernetes ikincil sürüm yükseltmeleri Önceden yapılandırılmış otomatik yükseltme kanalı Varsayılan olarak manuel, isteğe bağlı olarak otomatik kanal
İşletim sistemi imajı düğüm yükseltmeleri Önceden yapılandırılmış otomatik düğüm işletim sistemi görüntü kanalı Varsayılan olarak manuel, isteğe bağlı olarak otomatik kanal
Sistem düğümü havuzu işlemleri AKS tarafından yönetiliyor Müşteri tarafından yönetiliyor
Planlı bakım pencereleri Varsayılan olarak kullanılabilir İsteğe bağlı yapılandırma
İş yükü kesinti denetimleri Çoğaltma stratejisi, hazır olma davranışı ve kesinti ilkesi dahil olmak üzere müşteriye ait Çoğaltma stratejisi, hazır olma davranışı ve kesinti ilkesi dahil olmak üzere müşteriye ait

Note

AKS Otomatik, platform işlemlerini basitleştirir, ancak paylaşılan sorumluluk yine de geçerlidir. İş yükü düzeyinde kullanılabilirlik tasarımı ve çıkarma ilkesi davranışı müşteri sorumluluğunda kalır.

AKS'de aşamalı yükseltme davranışı

AKS, düğümleri değiştirirken veya yeniden imajlarken kapasiteyi koruyan kademeli bir yöntem kullanarak düğüm havuzlarını yükseltir. Bu davranış tüm AKS kümesi modlarında aynıdır.

Genel olarak, AKS:

  1. Yükseltme ayarlarına bağlı olarak geçici ani yük kapasitesi ekler.
  2. İş yüklerini taşımak için düğümleri kablolar ve boşaltlar.
  3. Düğümleri hedef sürüme yeniden yönlendirir veya değiştirir.
  4. Tamamlandıktan sonra geçici ani kapasite artışını kaldırır.

Sıralı yükseltme örneği

Bu örnek, maxSurge değeri 1 olarak ayarlanmış iki düğümlü bir kümenin Kubernetes 1.30'dan 1.31'e yükseltilmesini göstermektedir.

1. Adım: İlk kurulum

Küme, her bir uygulama podunu barındıran 1.30 sürümünü çalıştıran iki düğümle başlar.

Sürüm 1.30 çalıştıran, her biri uygulama podlarını barındıran iki düğüm ve yeni oluşturulmuş bir Surge Düğümü ile ilk küme kurulumunu gösteren diyagram.

  • Düğüm 1: Pod A, Pod B
  • Düğüm 2: Pod C, Pod D
  • Aşırı Gerilim Düğümü: Boş (DaemonSets ve yeni podlar hariç)

2. Adım: İlk düğümü izole et ve boşalt

AKS, yeni pod zamanlamasını önlemek için Node 1'i kordon altına alır ve ardından mevcut podları boşalttır.

Node 1'in kordonlanıp boşaltıldığını ve podların çıkarılıp diğer kullanılabilir düğümlerde değiştirildiğini gösteren diyagram.

  • Pod A → Surge Node'da çıkarıldı ve değiştirildi
  • Pod B → Düğüm 2'de kaldırıldı ve yeniden yerleştirildi

3. Adım: İlk düğümü yükseltme

Podlar diğer düğümlerde çalışmaya devam ederken Düğüm 1, Kubernetes sürüm 1.31 ile yeniden oluşturulur.

Düğüm 1’in 1.31 sürümüne yeniden görüntülendiğini, uygulama pod’larının ise Düğüm 2 ve Surge Düğümü üzerinde çalışmaya devam ettiğini gösteren diyagram.

  • Düğüm 1: v1.31'e yükseltildi
  • Düğüm 2: Pod B, Pod C, Pod D
  • `Surge Node: Pod A`

4. Adım: İkinci düğümü çevrele ve boşalt

AKS, Node 2 için işlemi tekrarlar, podlar çıkarılır ve zamanlayıcı bunları uygun kullanılabilir düğümlere yeniden dağıtır.

Node 2'nin kordon altına alınıp boşaltıldığını ve pod'ların tahliye edilerek yükseltilmiş Node 1 ile ek düğüm üzerinde yerlerine yenilerinin oluşturulduğunu gösteren diyagram.

  • Pod C, B → Düğüm 1'de kaldırıldı ve değiştirildi
  • Pod D → Surge Node'da çıkarıldı ve değiştirildi
  • Düğüm 2: v1.31'e izole edilen ve yeniden görüntülenen

5. Adım: Aşırı gerilim düğümünü kaldırma

Tüm kalıcı düğümler yükseltildikten sonra, Aşırı Gerilim Düğümü kordonlanır, boşaltılır ve silinir.

Podların tahliye edilip yükseltilen kalıcı düğümlerde yeniden oluşturulduğu, Surge düğümünün tahliye edilip silinmesini gösteren diyagram.

  • Pod A → Düğüm 1'de tahliye edildi ve değiştirildi
  • Pod D → Uzaklaştırıldı ve yerine yenisi yerleştirildi Düğüm 2'de
  • Dalgalanma Düğümü: Silindi

Son durum

Tüm düğümler artık küme genelinde zamanlanmış podlarla Kubernetes sürüm 1.31'i çalıştırıyor.

  • Düğüm 1 (v1.31): Pod A, Pod C
  • Düğüm 2 (v1.31): Pod B ve Pod D

Kısıtlayıcı Pod Kesinti Bütçesi (PDB) davranışı

Kısıtlayıcı bir PDB tahliyeyi engelliyorsa, düğümün boşaltılması gecikebilir veya tamamen engellenebilir. AKS, yapılandırılan davranışa bağlı olarak, diğer uygun düğümleri yükseltmeye devam etmek için Cordon boşaltılamayan düğüm davranışını kullanabilir. Engellenen düğümler, engelleme koşulu çözümlenene kadar eski bir sürümde kalabilir.

Note

Platform tarafından başlatılan yükseltmeler farklı davranır. AKS önce normal bir drain işlemini dener, ancak drain işlemi zaman aşımına uğrarsa veya başarısız olursa, kümenin desteklenen bir Kubernetes sürümüne ulaşması için PDB'yi geçersiz kılar.

Kısıtlayıcı PDB örneği

Bu örnekte, iki düğümlü bir kümenin Kubernetes 1.30'dan 1.31'e maxSurge2 yükseltilmesi ve pdb'nin ilk düğümün boşaltma işlemini engellemesi gösterilmektedir.

1. Adım: Kısıtlayıcı PDB ile ilk kurulum

Küme, 1.30 sürümünü çalıştıran iki düğümle başlar ve PDB, Pod A'nın kaldırılmasını önler.

İki düğümlü başlangıç kümesini, bir ek düğümü ve Pod A’yı çıkarılmaya karşı koruyan bir Pod Kesintisi Bütçesini gösteren diyagram.

  • Düğüm 1: Pod A (PDB ile korunan), Pod B
  • Düğüm 2: Pod C, Pod D
  • Aşırı Gerilim Düğümleri: Yeni oluşturulan 2 düğüm
  • PDB: Pod A'nın çıkarılmasını önler

2. Adım: İlk düğümü boşaltmayı deneme (engellendi)

AKS, Node 1'i kordon altına alır ancak PDB kısıtlamaları nedeniyle Pod A'yı boşaltamaz.

Düğüm 1’in kordon altına alındığını ancak drain işleminin Pod Kesinti Bütçesi tarafından engellendiğini, Pod A’nın takılı kaldığını ve Pod B’nin Surge Düğümüne tahliye edildiğini gösteren diyagram.

  • Düğüm 1: Kordonlu ve karantinaya alınmış olarak işaretlenmiş (Pod A takıldı)
  • Pod B → Surge Node 1'de tahliye edilip yerine yenisi konur, bu sırada Surge Node 2 geçici olarak kullanılmaz
  • Durum: Node 1 yükseltmesi engellendi

3. Adım: İkinci düğüme geçin

Düğüm 1 karantinaya alındığında AKS, Düğüm 2'yi yükseltmeye devam eder.

Düğüm 1'in karantinada kalırken, Düğüm 2'nin başarıyla kordon altına alınıp boşaltıldığını ve podların Ek Düğüme taşındığını gösteren diyagram.

  • Düğüm 1: Karantinada kalır (v1.30)
  • Düğüm 2: Kordon altına alınmış ve başarıyla boşaltılmış
  • Pod C → Surge Node 2'de çıkarıldı ve değiştirildi
  • Pod D → Surge Node 2'de çıkarıldı ve değiştirildi

4. Adım: İkinci düğümü yükseltme

Düğüm 2, Kubernetes sürüm 1.31'e başarıyla yeniden oluşturulur.

Node 1, Pod A ile karantinada kalırken Node 2'nin 1.31 sürümüne başarıyla yükseltildiğini gösteren diyagram.

  • Düğüm 1: Hala Pod A ile karantinada (v1.30)
  • Düğüm 2: v1.31'e yükseltildi
  • Dalgalanma Düğümü 1: Pod B
  • Dalgalanma Düğümü 2: Pod C, Pod D

5. Adım: Bir Aşırı Gerilim Düğümü, başka bir düğüm kaldırıldıkça kalıcı olarak değiştirilecek hale gelir

Düğüm 1 karantinada kalmaya devam ettiğinden, v1.31 sürümünü çalıştıran Surge Düğümü 1 kalıcı yedek haline gelir ve Surge Düğümü 2 silinir.

Node 1 karantinada kalmaya devam ederken, Surge Node’un 1.31 sürümünü çalıştıran kalıcı bir yedek hâline geldiğini gösteren diyagram.

  • Düğüm 1: Karantinaya alındı (v1.30) - el ile müdahale gerektirir
  • Pod C, Pod D → Surge Node 2'den tahliye edildi ve Node 2 üzerinde yerlerine yenileri kondu
  • Dalgalanma Düğümü 1 (v1.31): Pod B (artık kalıcı)
  • Dalgalanma Düğümü 2 (v1.31): Silindi

Son durum

Yükseltme, el ile müdahale gerektiren karantinaya alınmış bir düğümle tamamlanmıştır.

  • Düğüm 1: Pod A ile karantinaya alındı (v1.30) - Müşteri manuel olarak çözmelidir (bkz. Dren edilemez düğümleri çözme)
  • Düğüm 2 (v1.31): Normal çalışıyor
  • Eski Dalgalanma Düğümü (v1.31): Artık kalıcı değiştirme

Önemli

Karantinaya alınan düğüm (Düğüm 1) müşterinin sorumluluğundadır. Aşağıdakilerden birini seçmelisiniz:

  • PDB'yi A podunun çıkarılmasına izin verecek şekilde ayarlayın.
  • Pod A'nın el ile silinmesi.
  • Engelleme koşulunu düzelttikten sonra düğümü silin ve yeniden oluşturun.

PDB tarafından engellenen yükseltmeler için önemli noktalar

  • Boşaltılamayan düğüm davranışı: Bu karantina davranışını etkinleştirmek için düğüm havuzunda Cordon olarak ayarlayın.
  • Müşteri sorumluluğu: Karantinaya alınan düğümlerin çözümlenmesi için el ile müdahale gerekir.
  • Küme kapasitesi: Aşırı gerilim düğümü kalıcı hale gelir ve küme kapasitesi planlamasını etkileyebilir.
  • İzleme: Zamanında çözüm sağlamak için karantinaya alınan düğümleri Azure İzleyici veya kubectl aracılığıyla izleyin.

Tip

Karantina senaryosunun tamamını önlemek için otomatik PDB yönetimini kullanarak dağıtım çoğaltmalarının ölçeğini otomatik olarak artırarak, boşaltma başlamadan önce PDB kısıtlamalarının karşılanması sağlanır. Bu, çıkarma işleminin engelleme olmadan devam etmesini sağlayarak el ile karantina çözümü ihtiyacını ortadan kaldırır.

Blue-Green düğüm havuzu yükseltmeleri (manuel denetim)

Blue-Green yükseltmeleri, iş yüklerini geçirmeden önce yeni düğüm havuzlarının tamamını el ile oluşturarak daha denetimli bir yükseltme yaklaşımı sunar. Bu el ile yaklaşım, yükseltme işlemi ve zamanlaması üzerinde tam denetim sağlar.

Daha fazla bilgi için bkz. AKS’de Blue-Green düğüm havuzu yükseltmeleri.

Blue-Green yükseltmeleri ne zaman kullanılır?

Manuel Blue-Green düğüm havuzu yükseltmeleri, açıkça tanımlanmış geçiş denetim noktaları, özel doğrulama aşamaları veya sıkı biçimde kontrol edilen geçişler gibi özel gereksinimler için gelişmiş bir stratejidir.

İhtiyacınız olduğunda el ile Blue-Green kullanın:

  • operatör denetimindeki geçiş aşamaları.
  • İşlemeden önce özel doğrulama ve kabul ölçütleri.
  • Dahili çalıştırma prosedürlerine bağlı açıkça tanımlanmış geri alma akışı.

Uygun olduğunda çoğu üretim iş yükü için AKS Otomatik varsayılan yükseltme davranışı tercih edilen başlangıç noktasıdır ve el ile Blue-Green genellikle istisnai durumlar için ayrılmıştır.

Temel kavramlar

  • Mavi düğüm havuzu: Geçerli Kubernetes sürümünü çalıştıran mevcut düğüm havuzunuz.
  • Yeşil düğüm havuzu: Hedef Kubernetes sürümünü çalıştıran oluşturduğunuz yeni düğüm havuzu.
  • El ile denetim: Geçiş işleminin tüm yönlerini yönetirsiniz.
  • Doğrulama denetim noktaları: Ne zaman devam etmek, duraklatmak veya geri almak istediğinize siz karar verirsiniz.

Blue-Green yükseltmelerinin avantajları

  • Tam denetim: Her adımın tam olarak ne zaman gerçekleşeceğine siz karar verirsiniz.
  • Özel doğrulama: Kendi doğrulama ölçütlerinizi ve zamanlamanızı uygulayın.
  • Aşamalı geçiş: İş yüklerini tercih ettiğiniz hızda taşıyın.
  • Kolay geri alma: Özgün düğümler siz silene kadar kullanılabilir durumda kalır.

Blue-Green yükseltmeleri için dikkat edilmesi gerekenler

  • El ile çalışma: Süreç boyunca etkin yönetim gerektirir.
  • Kota gereksinimleri: Yükseltme sırasında düğüm kapasitesinin 2 katını gerektirir.
  • Planlama: Doğrulama ölçütlerinizi ve geri alma yordamlarınızı belgeleyin.

El ile Blue-Green yükseltme işlemi örneği

Bu örnek, Blue-Green dağıtımı kullanarak iki düğümlü bir kümeyi Kubernetes 1.30'dan 1.31'e el ile yükseltmeyi gösterir.

1. Adım: Yeşil düğüm havuzu oluşturma

Mevcut düğüm havuzunuzun yanında hedef Kubernetes sürümüyle el ile yeni bir düğüm havuzu oluşturarak başlarsınız.

1.30 sürümünü çalıştıran Mavi düğüm havuzu ile 1.31 sürümünü çalıştıran yeni oluşturulmuş Yeşil düğüm havuzunu içeren Blue-Green ilk kurulumunu gösteren şema.

  • Mavi düğüm havuzu (v1.30): Pod A, Pod B, Pod C, Pod D (mevcut)
  • Yeşil düğüm havuzu (v1.31): Boş (sizin tarafınızdan el ile oluşturulmuş)
  • Eyleminiz: az aks nodepool add yeni Kubernetes sürümüyle

2. Adım: Mavi düğümleri el ile kordonla

Mevcut podları çalışır durumda tutarken yeni pod zamanlamasını önlemek için mavi düğümleri bağlayın.

  • Eyleminiz: kubectl cordon her mavi düğümde
  • Mavi düğümler: İzole, yeni pod planlanmadı
  • Yeşil düğümler: İş yüklerini almaya hazır

3. Adım: Mavi düğümleri el ile boşaltın (kontrollü hız)

Düğümleri tek tek veya toplu olarak el ile boşaltarak geçiş hızını denetleyebilirsiniz.

İlk Mavi düğümün boşaltıldığını, pod'ların çıkarılıp Yeşil düğüm havuzunda yeniden oluşturulduğunu ve ikinci Mavi düğüm boşaltılırken kalan pod'ların Yeşil düğüm havuzuna taşındığını gösteren diyagram.

  • Eyleminiz: kubectl drain seçili mavi düğümlerde
  • Pod geçişi: Podlar otomatik olarak yeşil düğümlere yeniden zamanlanır
  • Doğrulama: Devam etmeden önce yeşil düğümlerdeki iş yüklerini doğrulama

4. Adım: Doğrulama ve karar verme

İş yüklerini taşıdıktan sonra yeşil düğümlerde uygulama performansını doğrulayın.

Tüm iş yüklerinin Yeşil düğüm havuzunda çalıştığı ve Mavi düğüm havuzunun geri dönüş için kullanılabilir durumda kaldığı doğrulama aşamasını gösteren diyagram.

Bu aşamada şunları yapabilirsiniz:

  • İzleyici: Uygulama ölçümlerini ve günlüklerini denetleme
  • Test: Yeşil düğüm havuzunda doğrulama testleri çalıştırma
  • Karar: Yeşile işleme veya maviye geri dönme

5. Adım: Commit et veya Roll back yap

Doğrulamanıza bağlı olarak yükseltmeyi el ile tamamlar veya geri alırsınız.

Seçenek A - Kaydetme (Başarı):

Mavi düğüm havuzunun silindiği ve Yeşil düğüm havuzunun birincil düğüm havuzu haline geldiği başarılı işlemeyi gösteren diyagram.

  • İşleminiz: az aks nodepool delete kullanarak mavi düğüm havuzunu silin
  • Sonuç: Yeşil düğüm havuzu birincil olur

Seçenek B - Geri alma (Algılanan sorunlar):

İş yüklerinin Mavi düğüm havuzuna geri döndüğünü ve Yeşil düğüm havuzunun silindiğini gösteren geri alma diyagramı.

  • Eyleminiz: kubectl uncordon kullanarak mavi düğümlerde cordon işlemini kaldırın, kubectl drain kullanarak yeşil düğümleri boşaltın ve az aks nodepool delete kullanarak yeşil düğüm havuzunu silin
  • Sonuç: İş yükleri Mavi düğümlere geri döner

Yükseltme planlaması için üretimde dikkat edilmesi gerekenler

  • Dalgalanma (maxSurge) yapılandırması: Yükseltmeler sırasında oluşturulan dalgalanma düğümlerinin sayısını denetler. Daha yüksek değerler yükseltmeleri hızlandırıp daha fazla kaynak tüketir.
  • Pod kesinti bütçeleri (PDB'ler): Yükseltme işlemi sırasında uygulamanın kullanılabilirliğini sağlamak için PDB'leri yapılandırın.
  • Düğüm havuzu yükseltmeleri: Her düğüm havuzu bağımsız olarak yükseltildi. Yükseltme stratejinizi buna göre planlayın.
  • Kapasite ve kota: Yükseltme dönemlerinden önce geçici ve sürekli durumdaki kapasite gereksinimlerini doğrulayın.
  • İzleme ve uyarılar: Yükseltme başlamadan önce izleme ve uyarı ayarlama.

AKS Otomatik'te, üretime hazır olma için çeşitli platform düzeyinde yükseltme seçenekleri önceden yapılandırılmıştır. AKS Standard'da ekipler genellikle bu seçimleri açıkça yapar.

İlgili içerik

  • Son güncelleştirme: