Azure Kubernetes Service (AKS) için Temel Kubernetes kavramları

  • Makale

Bu makalede, Azure'da kapsayıcılı uygulamaları büyük ölçekte dağıtmak ve çalıştırmak için kullanabileceğiniz yönetilen bir Kubernetes hizmeti olan Azure Kubernetes Service'in (AKS) temel kavramları açıklanmaktadır. Kubernetes'in altyapı bileşenleri hakkında bilgi edinmenize ve Kubernetes'in AKS'de nasıl çalıştığını daha iyi anlamanıza yardımcı olur.

Kubernetes nedir?

Kubernetes, kapsayıcı tabanlı uygulamaları ve bunların ilişkili ağ ve depolama bileşenlerini yöneten hızla gelişen bir platformdur. Kubernetes, temel alınan altyapı bileşenlerine değil uygulama iş yüklerine odaklanır. Kubernetes, yönetim işlemleri için güçlü bir API kümesi tarafından desteklenen dağıtımlara bildirim temelli bir yaklaşım sağlar.

Uygulama bileşenlerinin kullanılabilirliğini düzenleme ve yönetme amacıyla Kubernetes kullanarak modern, taşınabilir, mikro hizmet tabanlı uygulamalar derleyebilir ve çalıştırabilirsiniz. Kubernetes hem durum bilgisi olmayan hem de durum bilgisi olan uygulamaları destekler.

Kubernetes, açık bir platform olarak tercih ettiğiniz programlama dili, işletim sistemi, kitaplıklar veya mesajlaşma veri yolu ile uygulamalarınızı oluşturmanıza olanak tanır. Mevcut sürekli tümleştirme ve sürekli teslim (CI/CD) araçları, yayınları zamanlamak ve dağıtmak için Kubernetes ile tümleştirebilir.

AKS, dağıtım ve çekirdek yönetim görevlerinin karmaşıklığını azaltan yönetilen bir Kubernetes hizmeti sağlar. Azure platformu AKS denetim düzlemini yönetir ve yalnızca uygulamalarınızı çalıştıran AKS düğümleri için ödeme alırsınız.

Kubernetes küme mimarisi

Kubernetes kümesi iki bileşene ayrılır:

  • Temel Kubernetes hizmetlerini ve uygulama iş yüklerinin düzenlemesini sağlayan denetim düzlemi ve
  • Uygulama iş yüklerinizi çalıştıran düğümler.

Kubernetes denetim düzlemi ve düğüm bileşenleri

Kontrol düzlemi

Aks kümesi oluşturduğunuzda, Azure platformu ilişkili denetim düzlemini otomatik olarak oluşturur ve yapılandırr. Bu tek kiracılı denetim düzlemi, kullanıcıdan soyutlanmış yönetilen bir Azure kaynağı olarak hiçbir ücret ödemeden sağlanır. Yalnızca AKS kümesine eklenen düğümler için ödeme yaparsınız. Denetim düzlemi ve kaynakları yalnızca kümeyi oluşturduğunuz bölgede bulunur.

Denetim düzlemi aşağıdaki çekirdek Kubernetes bileşenlerini içerir:

Bileşen Veri Akışı Açıklaması
kube-apiserver API sunucusu temel kubernetes API'lerini kullanıma sunar ve veya Kubernetes panosu gibi kubectl yönetim araçları için etkileşim sağlar.
vbd etcd, Kubernetes kümenizin ve yapılandırmanızın durumunu korumaya yardımcı olan, Kubernetes içinde yüksek oranda kullanılabilir bir anahtar-değer deposudur.
kube-scheduler Uygulamaları oluşturduğunuzda veya ölçeklendirdiğinizde zamanlayıcı, iş yükünü çalıştırabilecek düğümleri belirler ve tanımlanan düğümleri başlatır.
kube-controller-manager Denetleyici yöneticisi, pod çoğaltma ve düğüm işlemlerini işleme gibi eylemler gerçekleştiren birkaç küçük denetleyiciyi denetler.

Kontrol düzlemi'ne doğrudan erişebileceğinizi unutmayın. Kubernetes denetim düzlemi ve düğüm yükseltmeleri Azure CLI veya Azure portalı aracılığıyla düzenlenir. Olası sorunları gidermek için Azure İzleyici'yi kullanarak denetim düzlemi günlüklerini gözden geçirebilirsiniz.

Not

Bir denetim düzlemini yapılandırmak veya doğrudan erişmek istiyorsanız, Küme API Sağlayıcısı Azure'ı kullanarak kendi kendine yönetilen bir Kubernetes kümesi dağıtabilirsiniz.

Düğümler

Uygulamalarınızı ve destekleyici hizmetleri çalıştırmak için bir Kubernetes düğümüne ihtiyacınız vardır. Her AKS kümesinin en az bir düğümü, Kubernetes düğüm bileşenlerini çalıştıran bir Azure sanal makinesi (VM) ve kapsayıcı çalışma zamanı vardır.

Düğümler aşağıdaki çekirdek Kubernetes bileşenlerini içerir:

Bileşen Veri Akışı Açıklaması
kubelet Denetim düzleminden gelen düzenleme isteklerini işleyen Kubernetes aracısı, istenen kapsayıcıları zamanlama ve çalıştırma.
kube-proxy Ara sunucu, her düğümdeki sanal ağı işler, ağ trafiğini yönlendirir ve hizmetler ve podlar için IP adreslemini yönetir.
kapsayıcı çalışma zamanı Kapsayıcı çalışma zamanı, kapsayıcılı uygulamaların çalıştırılmasına ve sanal ağ veya depolama gibi diğer kaynaklarla etkileşim kurmasına olanak tanır. Daha fazla bilgi için bkz . Kapsayıcı çalışma zamanı yapılandırması.

Kubernetes düğümü için Azure sanal makinesi ve destekleyici kaynaklar

Düğümlerinizin Azure VM boyutu CPU'ları, belleği, boyutu ve yüksek performanslı SSD veya normal HDD gibi kullanılabilir depolama türünü tanımlar. Uygulamalarınızın büyük miktarda CPU ve bellek mi yoksa yüksek performanslı depolama alanı mı gerektirebileceği konusunda düğüm boyutunu planlayın. Talebi karşılamak için AKS kümenizdeki düğüm sayısını ölçeklendirin. Ölçeklendirme hakkında daha fazla bilgi için bkz . AKS'deki uygulamalar için ölçeklendirme seçenekleri.

AKS'de, kümenizin düğümlerinin VM görüntüsü Ubuntu Linux, Azure Linux veya Windows Server 2022'yi temel alır. Aks kümesi oluşturduğunuzda veya düğüm sayısını genişlettiğiniz zaman Azure platformu istenen sayıda VM'yi otomatik olarak oluşturur ve yapılandırr. Aracı düğümleri standart VM'ler olarak faturalandırılır, bu nedenle Azure rezervasyonları dahil olmak üzere tüm VM boyutu indirimleri otomatik olarak uygulanır.

Yönetilen diskler için varsayılan disk boyutu ve performansı seçilen VM SKU'su ve vCPU sayısına göre atanır. Daha fazla bilgi için bkz . Varsayılan işletim sistemi disk boyutlandırması.

Not

Kubernetes düğüm kapsayıcısı çalışma zamanınızda ve işletim sisteminizde gelişmiş yapılandırma ve denetime ihtiyacınız varsa, Küme API Sağlayıcısı Azure'ı kullanarak kendi kendine yönetilen bir küme dağıtabilirsiniz.

İşletim sistemi yapılandırması

AKS, Kubernetes 1.25 ve üzeri kümeler için düğüm işletim sistemi (OS) olarak Ubuntu 22.04 ve Azure Linux 2.0'ı destekler. Ubuntu 18.04, Kubernetes sürüm 1.24 ve altı için düğüm havuzu oluşturma sırasında da belirtilebilir.

AKS, Kubernetes 1.25 ve üzeri kümelerdeki Windows düğüm havuzları için varsayılan işletim sistemi olarak Windows Server 2022'yi destekler. Windows Server 2019, Kubernetes sürüm 1.32 ve altı için düğüm havuzu oluşturma sırasında da belirtilebilir. Kubernetes sürüm 1.32 kullanım ömrü sona erdikten sonra Windows Server 2019 kullanımdan kaldırılıyor ve gelecek sürümlerde desteklenmiyor. Bu kullanımdan kaldırma hakkında daha fazla bilgi için bkz . AKS sürüm notları.

Kapsayıcı çalışma zamanı yapılandırması

Kapsayıcı çalışma zamanı, kapsayıcıları yürüten ve bir düğümdeki kapsayıcı görüntülerini yöneten yazılımdır. Çalışma zamanı, Linux veya Windows üzerinde kapsayıcıları çalıştırmak için sys çağrılarını veya işletim sistemine özgü işlevleri soyutlama konusunda yardımcı olur. Linux düğüm havuzları için containerd Kubernetes sürüm 1.19 ve üzeri üzerinde kullanılır. Windows Server 2019 ve 2022 düğüm havuzları containerd için genel kullanıma sunulmuştur ve Kubernetes sürüm 1.23 ve üzeri sürümlerde tek çalışma zamanı seçeneğidir. Mayıs 2023 itibarıyla Docker kullanımdan kaldırıldı ve artık desteklenmiyor. Bu kullanımdan kaldırma hakkında daha fazla bilgi için bkz . AKS sürüm notları.

Containerd , kapsayıcıları yürütmek ve düğümdeki görüntüleri yönetmek için gereken en düşük işlev kümesini sağlayan OCI (Open Container Initiative) uyumlu bir çekirdek kapsayıcı çalışma zamanıdır. Tabanlı düğümler ve düğüm havuzları ilecontainerd kubelet doğrudan containerd CRI (kapsayıcı çalışma zamanı arabirimi) eklentisini kullanmakla konuşur ve Docker CRI uygulamasıyla karşılaştırıldığında veri akışındaki ek atlamaları kaldırır. Bu nedenle daha iyi pod başlatma gecikme süresi ve daha az kaynak (CPU ve bellek) kullanımı görürsünüz.

Containerd v1.19'dan başlayan her Kubernetes sürümünde AKS'deki Kubernetes'in her GA sürümünde çalışır ve tüm Kubernetes ve AKS özelliklerini destekler.

Önemli

Kubernetes v1.19 veya üzeri sürümlerde oluşturulan Linux düğüm havuzlarına sahip kümeler varsayılan olarak kapsayıcı çalışma zamanıdır containerd . Önceki desteklenen Kubernetes sürümlerinde düğüm havuzlarına sahip kümeler, kapsayıcı çalışma zamanı için Docker alır. Düğüm havuzu Kubernetes sürümü destekleyen containerdbir sürüme containerd güncelleştirildikten sonra Linux düğüm havuzları olarak güncelleştirilir.

containerd , Windows Server 2019 ve 2022 düğüm havuzlarına sahip kümeler için genel olarak kullanılabilir ve Kubernetes v1.23 ve üzeri için tek kapsayıcı çalışma zamanı seçeneğidir. Docker düğüm havuzlarını ve kümelerini 1.23'ten önceki sürümlerde kullanmaya devam edebilirsiniz, ancak Docker artık Mayıs 2023'ten itibaren desteklenmemektedir. Daha fazla bilgi için bkz . ile containerdWindows Server düğüm havuzu ekleme.

Düğüm havuzlarınızı destekleyen containerd bir Kubernetes sürümüne containerd sahip kümeleri kullanmadan önce aks düğüm havuzlarında iş yüklerinizi test etmenizi kesinlikle öneririz.

containerd sınırlamalar/farklılıklar

  • için containerdKubernetes düğümlerindeki podlar, kapsayıcılar ve kapsayıcı görüntüleriyle ilgili sorunları gidermek için Docker CLI'nin yerine kullanılmasını crictl öneririz. hakkında crictldaha fazla bilgi için bkz . genel kullanım ve istemci yapılandırma seçenekleri.

    • Containerd Docker CLI'nın tam işlevselliğini sağlamaz. Yalnızca sorun giderme için kullanılabilir.
    • crictl , pod gibi kavramların mevcut olduğu kapsayıcıların Kubernetes dostu bir görünümünü sunar.

  • Containerd , standart günlük cri biçimini kullanarak günlüğe kaydetmeyi ayarlar. Günlük çözümünüz, Kapsayıcılar için Azure İzleyici gibi günlük biçimini desteklemelicri.

  • Artık Docker altyapısına /var/run/docker.sockerişemez veya Docker-in-Docker (DinD) kullanamazsınız.

    • Şu anda Docker altyapısından uygulama günlüklerini veya izleme verilerini ayıklarsanız bunun yerine Container Analizler kullanın. AKS, aracı düğümlerinde dengesizliklere neden olabilecek bant dışı komutların çalıştırılmasını desteklemez.
    • Görüntü oluşturmanızı veya docker altyapısını doğrudan kullanmanızı önermeyiz. Kubernetes, tüketilen kaynakların tam olarak farkında değildir ve bu yöntemler burada ve burada açıklandığı gibi çok sayıda sorun sunar.

  • Görüntüler oluştururken, AKS kümenizin içinde görüntü oluşturmadığınız sürece geçerli Docker derleme iş akışınızı normal şekilde kullanmaya devam edebilirsiniz. Bu durumda, ACR Görevlerini kullanarak görüntü oluşturmak için önerilen yaklaşıma veya Docker Buildx gibi daha güvenli bir küme içi seçeneğe geçmeyi göz önünde bulundurun.

Kaynak rezervasyonları

AKS, düğüm kaynaklarını kullanarak düğümün kümenizin bir parçası olarak çalışmasına yardımcı olur. Bu kullanım, düğümünüzün toplam kaynaklarıyla AKS'deki allocatable kaynakları arasında bir tutarsızlık oluşturabilir. Kullanıcı tarafından dağıtılan podlar için istekleri ve sınırları ayarlarken bu bilgileri unutmayın.

Düğümün allocatable kaynağını bulmak için komutunu kubectl describe node kullanabilirsiniz:

kubectl describe node [NODE_NAME]

AKS, düğüm performansını ve işlevselliğini korumak için her düğümde CPU ve bellek olmak üzere iki tür kaynak ayırır. Kaynaklarda düğüm büyüdükçe, kullanıcı tarafından dağıtılan podların yönetimine daha fazla ihtiyaç duyularak kaynak ayırması artar. Kaynak rezervasyonlarının değiştirilebileceğini unutmayın.

Not

Kapsayıcı Analizler (OMS) gibi AKS eklentilerini kullanmak fazladan düğüm kaynakları kullanır.

CPU

Ayrılmış CPU, düğüm türüne ve küme yapılandırmasına bağlıdır ve bu da ek özelliklerin çalıştırılması nedeniyle daha az allocatable CPU'ya neden olabilir. Aşağıdaki tabloda CPU ayırması milicore cinsinden gösterilmektedir:

Konakta CPU çekirdekleri 1 2 4 8 16 32 64
Kube ayrılmış (milicore) 60 100 140 180 260 420 740

Bellek

AKS'deki ayrılmış bellek iki değerin toplamını içerir:

Önemli

AKS 1.29, Ocak 2024'te önizlemede gösterilir ve bellek ayırmalarında bazı değişiklikler içerir. Bu değişiklikler aşağıdaki bölümde ayrıntılı olarak anlatılır.

AKS 1.29 ve üzeri

  1. kubeletdaemon varsayılan olarak memory.available<100Mi çıkarma kuralına sahiptir. Bu kural, bir düğümde her zaman en az 100Mi allocatable olmasını sağlar. Bir konak kullanılabilir bellek eşiğinin altında olduğunda, kubelet çalışan podlardan birinin sonlandırılmasına neden olur ve konak makinede bellek boşaltılır.

  2. Daha düşük değere göre ayarlanan bellek ayırma oranı: 20 MB * Düğümde desteklenen Maksimum Pod sayısı + toplam sistem bellek kaynaklarının %25'i veya%25'i.

    Örnekler:

    • VM 8 GB bellek sağlıyorsa ve düğüm en fazla 30 pod destekliyorsa AKS, kube ayrılmış için 20 MB * 30 Maksimum Pod + 50 MB = 650 MB ayırır. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
    • VM 4 GB bellek sağlıyorsa ve düğüm en fazla 70 pod destekliyorsa AKS, kube-reserved için %25 * 4 GB = 1000 MB ayırır, bu da 20 MB *70 Maksimum Pod + 50 MB = 1450 MB'tan azdır.

    Daha fazla bilgi için bkz . AKS kümesinde düğüm başına en fazla pod yapılandırma.

1.29 öncesi AKS sürümleri

  1. kubeletdaemon varsayılan olarak memory.available<750Mi çıkarma kuralına sahiptir. Bu kural, bir düğümün her zaman en az 750Mi allocatable özelliğine sahip olmasını sağlar. Bir konak kullanılabilir bellek eşiğinin altında olduğunda, kubelet çalışan podlardan birinin sonlandırılmasına neden olur ve konak makinesinde bellek boşaltılır.
  2. Kubelet daemon'un düzgün çalışması (kube-reserved) için gerilemeli bellek ayırma oranı.
    • İlk 4 GB belleğin %25'i
    • Sonraki 4 GB belleğin %20'sini (8 GB'a kadar)
    • Sonraki 8 GB belleğin %10'unu (16 GB'a kadar)
    • Sonraki 112 GB belleğin %6'sı (128 GB'a kadar)
    • 128 GB'tan fazla belleğin %2'sini

Not

AKS, hesaplanan belleğin parçası olmayan Windows düğümlerindeki sistem işlemleri için fazladan 2 GB ayırır.

Bellek ve CPU ayırma kuralları şunlar için tasarlanmıştır:

  • Bazı barındırma sistemi podları küme durumu açısından kritik de dahil olmak üzere aracı düğümlerini iyi durumda tutun.
  • Düğümün Kubernetes kümesinin parçası değilse bildireceğinden daha az allocatable bellek ve CPU raporlamasına neden olur.

Örneğin, bir düğüm 7 GB sunuyorsa, 750Mi sabit çıkarma eşiği dahil olmak üzere belleğin %34'ünü allocatable olarak raporlamaz.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Kubernetes'in kendi rezervasyonlarına ek olarak, temel düğüm işletim sistemi de işletim sistemi işlevlerini korumak için bir miktar CPU ve bellek kaynağı ayırır.

İlişkili en iyi yöntemler için bkz . AKS'deki temel zamanlayıcı özellikleri için en iyi yöntemler.

Düğüm havuzları

Not

Azure Linux düğüm havuzu genel kullanıma sunuldu (GA). Avantajlar ve dağıtım adımları hakkında bilgi edinmek için bkz . AKS için Azure Linux Container Host'a giriş.

Aynı yapılandırmanın düğümleri birlikte düğüm havuzları halinde gruplandırılır. Her Kubernetes kümesi en az bir düğüm havuzu içerir. Varsayılan bir düğüm havuzu oluşturan bir AKS kümesi oluşturduğunuzda ilk düğüm sayısını ve boyutlarını tanımlarsınız. AKS'deki bu varsayılan düğüm havuzu, aracı düğümlerinizi çalıştıran temel vm'leri içerir.

Not

Kümenizin güvenilir bir şekilde çalıştığından emin olmak için varsayılan düğüm havuzunda en az iki düğüm çalıştırmanız gerekir.

Aks kümesini varsayılan düğüm havuzuna göre ölçeklendirir veya yükseltebilirsiniz. Belirli bir düğüm havuzunu ölçeklendirmeyi veya yükseltmeyi seçebilirsiniz. Yükseltme işlemleri için, tüm düğümler başarıyla yükseltilene kadar çalışan kapsayıcılar düğüm havuzundaki diğer düğümlerde zamanlanır.

Daha fazla bilgi için bkz. Düğüm havuzları oluşturma ve Düğüm havuzlarını yönetme.

Varsayılan işletim sistemi disk boyutlandırması

Yeni bir küme oluşturduğunuzda veya var olan bir kümeye yeni düğüm havuzu eklediğinizde, işletim sistemi disk boyutunu varsayılan olarak vCPU sayısı belirler. vCPU sayısı VM SKU'sunu temel alır. Aşağıdaki tabloda her VM SKU'su için varsayılan işletim sistemi disk boyutu listelenir:

VM SKU Çekirdekleri (vCPU' lar) Varsayılan İşletim Sistemi Disk Katmanı Sağlanan IOPS Sağlanan Aktarım Hızı (Mb/sn)
1 - 7 P10/128G 500 100
8 - 15 P15/256G 1100 125
16 - 63 P20/512G 2300 150
64+ P30/1024G Kategori 5000 200

Önemli

Varsayılan işletim sistemi disk boyutlandırması yalnızca kısa ömürlü işletim sistemi diskleri desteklenmediğinde ve varsayılan işletim sistemi disk boyutu belirtilmediğinde yeni kümelerde veya düğüm havuzlarında kullanılır. Varsayılan işletim sistemi disk boyutu kümenizin performansını veya maliyetini etkileyebilir. Küme veya düğüm havuzu oluşturulduktan sonra işletim sistemi disk boyutunu değiştiremezsiniz. Bu varsayılan disk boyutlandırması, Temmuz 2022 veya sonrasında oluşturulan kümeleri veya düğüm havuzlarını etkiler.

Düğüm seçicileri

Birden çok düğüm havuzu olan bir AKS kümesinde Kubernetes Scheduler'a belirli bir kaynak için hangi düğüm havuzunun kullanılacağını söylemeniz gerekebilir. Örneğin, giriş denetleyicileri Windows Server düğümlerinde çalışmamalıdır. Bir pod'un zamanlanması gereken yeri denetlemek için düğüm seçicilerini düğüm işletim sistemi gibi çeşitli parametreleri tanımlamak için kullanırsınız.

Aşağıdaki temel örnek, "kubernetes.io/os" düğüm seçicisini kullanarak linux düğümünde bir NGINX örneği zamanlar: linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Daha fazla bilgi için bkz . AKS'de gelişmiş zamanlayıcı özellikleri için en iyi yöntemler.

Düğüm kaynak grubu

AKS kümesi oluşturduğunuzda, içinde küme kaynaklarının oluşturulacağı bir Azure kaynak grubu belirtirsiniz. AKS kaynak sağlayıcısı, bu kaynak grubuna ek olarak düğüm kaynak grubu adlı ayrı bir kaynak grubu oluşturur ve yönetir. Düğüm kaynak grubu aşağıdaki altyapı kaynaklarını içerir:

  • Düğüm havuzlarındaki her düğüm için sanal makine ölçek kümeleri ve VM'ler
  • Kümenin sanal ağı
  • Kümenin depolama alanı

Düğüm kaynak grubuna varsayılan olarak şu biçimde bir ad atanır: MC_resourceGroupName_clusterName_location. Küme oluşturma sırasında düğüm kaynak grubunuz için atanan adı belirtebilirsiniz. Azure Resource Manager şablonu kullanırken, özelliğini kullanarak nodeResourceGroup adı tanımlayabilirsiniz. Azure CLI kullanırken, aşağıdaki örnekte gösterildiği gibi parametresini az aks create komutuyla kullanırsınız--node-resource-group:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

AKS kümenizi sildiğinizde, AKS kaynak sağlayıcısı düğüm kaynak grubunu otomatik olarak siler.

Düğüm kaynak grubu aşağıdaki sınırlamalara sahiptir:

  • Düğüm kaynak grubu için var olan bir kaynak grubunu belirtemezsiniz.
  • Düğüm kaynak grubu için farklı bir abonelik belirtemezsiniz.
  • Küme oluşturulduktan sonra düğüm kaynak grubu adını değiştiremezsiniz.
  • Düğüm kaynak grubu içindeki yönetilen kaynaklar için ad belirtemezsiniz.
  • Düğüm kaynak grubu içindeki yönetilen kaynakların Azure tarafından oluşturulan etiketlerini değiştiremez veya silemezsiniz.

AKS kümesindeki düğüm kaynak grubu altındaki kaynaklarda Azure tarafından oluşturulan etiketleri değiştirmek, hizmet düzeyi hedefini (SLO) bozan desteklenmeyen bir eylemdir. Düğüm kaynak grubundaki Azure tarafından oluşturulan etiketleri veya diğer kaynak özelliklerini değiştirir veya silerseniz ölçeklendirme ve yükseltme hataları gibi beklenmeyen sonuçlar alabilirsiniz. AKS, düğüm kaynak grubundaki altyapı yaşam döngüsünü yönetir, bu nedenle herhangi bir değişiklik yapmak kümenizi desteklenmeyen bir duruma taşır. Daha fazla bilgi için bkz. AKS hizmet düzeyi sözleşmesi sunuyor mu?

AKS, düğüm kaynak grubundaki kaynaklara yayılan etiketleri oluşturmanıza ve değiştirmenize olanak tanır ve kümeyi oluştururken veya güncelleştirirken bu etiketleri ekleyebilirsiniz. Örneğin, bir iş birimi veya maliyet merkezi atamak için özel etiketler oluşturmak veya değiştirmek isteyebilirsiniz. Yönetilen kaynak grubunda kapsamı olan Azure İlkeleri de oluşturabilirsiniz.

Düğüm kaynak grubundaki değişikliklerin kümelerinizi etkileme olasılığını azaltmak için düğüm kaynak grubu kilitlemeyi etkinleştirerek AKS kaynaklarınıza reddetme ataması uygulayabilirsiniz. daha fazla bilgi için bkz . Tam olarak yönetilen kaynak grubu (önizleme).

Uyarı

Düğüm kaynak grubu kilitleme etkin değilse, düğüm kaynak grubundaki herhangi bir kaynağı doğrudan değiştirebilirsiniz. Düğüm kaynak grubundaki kaynakları doğrudan değiştirmek, kümenizin kararsız veya yanıt vermemeye başlamasına neden olabilir.

Podlar

Kubernetes, uygulamanızın örneklerini çalıştırmak için podları kullanır. Tek bir pod uygulamanızın tek bir örneğini temsil eder.

Podlar genellikle bir kapsayıcı ile 1:1 eşlemesi vardır. Gelişmiş senaryolarda, bir pod birden çok kapsayıcı içerebilir. Çok kapsayıcılı podlar aynı düğümde birlikte zamanlanır ve kapsayıcıların ilgili kaynakları paylaşmasına izin verir.

Pod oluşturduğunuzda, belirli bir cpu veya bellek miktarı için kaynak istekleri tanımlayabilirsiniz. Kubernetes Scheduler, kullanılabilir kaynaklara sahip bir düğümde çalıştırılacak podları zamanlayarak isteği karşılamaya çalışır. Ayrıca, bir pod'un temel düğümden çok fazla işlem kaynağı kullanmasını önlemek için en fazla kaynak sınırları belirtebilirsiniz. Önerilen en iyi uygulamamız, Kubernetes Scheduler'ın gerekli, izin verilen kaynakları tanımlamasına yardımcı olmak için tüm podlar için kaynak sınırları eklemektir.

Daha fazla bilgi için bkz . Kubernetes podları ve Kubernetes pod yaşam döngüsü.

Pod mantıksal bir kaynaktır, ancak uygulama iş yükleri kapsayıcılar üzerinde çalışır. Podlar genellikle kısa ömürlü, tek kullanımlık kaynaklardır. Tek tek zamanlanmış podlar, yüksek kullanılabilirlik ve yedekli Kubernetes özelliklerinden bazılarını kaçırır. Bunun yerine, Dağıtım Denetleyicisi gibi Kubernetes Denetleyicileri podları dağıtır ve yönetir.

Dağıtımlar ve YAML bildirimleri

Dağıtım, Kubernetes Dağıtım Denetleyicisi tarafından yönetilen aynı podları temsil eder. Dağıtım, oluşturulacak pod çoğaltmalarının sayısını tanımlar. Kubernetes Scheduler, podlar veya düğümler sorunlarla karşılaşırsa iyi durumdaki düğümlerde ek podların zamanlanmasını sağlar. Podların, kapsayıcı görüntüsünün veya ekli depolama alanının yapılandırmasını değiştirmek için dağıtımları güncelleştirebilirsiniz.

Dağıtım Denetleyicisi dağıtım yaşam döngüsünü yönetir ve aşağıdaki eylemleri gerçekleştirir:

  • Belirli sayıda çoğaltmayı boşaltıp sonlandırır.
  • Yeni dağıtım tanımından çoğaltmalar oluşturur.
  • Dağıtımdaki tüm çoğaltmalar güncelleştirilene kadar işleme devam eder.

AKS'deki durum bilgisi olmayan uygulamaların çoğu tek tek podları zamanlamak yerine dağıtım modelini kullanmalıdır. Kubernetes, gerekli çoğaltma sayısının küme içinde çalıştığından emin olmak için dağıtım durumunu ve durumunu izleyebilir. Tek tek zamanlandığında, podlar bir sorunla karşılaşırlarsa yeniden başlatılmaz ve geçerli düğümleri bir sorunla karşılaşırsa iyi durumdaki düğümlerde yeniden zamanlanmamıştır.

Uygulamanız en az sayıda kullanılabilir örnek gerektiriyorsa bir güncelleştirme işlemiyle yönetim kararlarını kesintiye uğratmak istemezsiniz. Pod Kesintisi Bütçeleri , bir güncelleştirme veya düğüm yükseltmesi sırasında dağıtımda kaç çoğaltmanın indirilebileceğini tanımlar. Örneğin, dağıtımınızda beş çoğaltma varsa, bir kerede yalnızca bir çoğaltmanın silinmesine veya yeniden zamanlanmasına izin vermek için dört pod kesintisi tanımlayabilirsiniz. Pod kaynak sınırlarında olduğu gibi, önerilen en iyi uygulamamız, her zaman en az sayıda çoğaltmanın mevcut olmasını gerektiren uygulamalarda pod kesintisi bütçeleri tanımlamaktır.

Dağıtımlar genellikle veya kubectl applyile kubectl create oluşturulur ve yönetilir. YAML biçiminde bir bildirim dosyası tanımlayarak dağıtım oluşturabilirsiniz. Aşağıdaki örnekte bir NGINX web sunucusu için temel dağıtım bildirim dosyası gösterilmektedir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

YAML bildirim dosyasındaki dağıtım belirtimlerinin dökümü aşağıdaki gibidir:

Belirtim Açıklama
.apiVersion Kaynağı oluştururken kullanmak istediğiniz API grubunu ve API kaynağını belirtir.
.kind Oluşturmak istediğiniz kaynak türünü belirtir.
.metadata.name Dağıtımın adını belirtir. Bu örnek YAML dosyası, Docker Hub'dan nginx görüntüsünü çalıştırır.
.spec.replicas Kaç pod oluşturulacağını belirtir. Bu örnek YAML dosyası üç yinelenen pod oluşturur.
.spec.selector Bu dağıtımdan hangi podların etkileneceğini belirtir.
.spec.selector.matchLabels Dağıtımın oluşturulan podları bulmasına ve yönetmesine olanak sağlayan {key, value} çiftlerinin bir haritasını içerir.
.spec.selector.matchLabels.app ile eşleşmesi .spec.template.metadata.labelsgerekir.
.spec.template.labels Nesneye eklenmiş {key, value} çiftlerini belirtir.
.spec.template.app ile eşleşmesi .spec.selector.matchLabelsgerekir.
.spec.spec.containers Pod'a ait kapsayıcıların listesini belirtir.
.spec.spec.containers.name DNS etiketi olarak belirtilen kapsayıcının adını belirtir.
.spec.spec.containers.image Kapsayıcı görüntüsü adını belirtir.
.spec.spec.containers.ports Kapsayıcıdan kullanıma sunma bağlantı noktalarının listesini belirtir.
.spec.spec.containers.ports.containerPort Podun IP adresinde kullanıma sunma bağlantı noktası sayısını belirtir.
.spec.spec.resources Kapsayıcı için gereken işlem kaynaklarını belirtir.
.spec.spec.resources.requests Gereken en düşük işlem kaynağı miktarını belirtir.
.spec.spec.resources.requests.cpu Gereken en düşük CPU miktarını belirtir.
.spec.spec.resources.requests.memory Gereken en düşük bellek miktarını belirtir.
.spec.spec.resources.limits İzin verilen en fazla işlem kaynağı miktarını belirtir. Kubelet bu sınırı zorlar.
.spec.spec.resources.limits.cpu İzin verilen en fazla CPU miktarını belirtir. Kubelet bu sınırı zorlar.
.spec.spec.resources.limits.memory İzin verilen en fazla bellek miktarını belirtir. Kubelet bu sınırı zorlar.

YAML bildiriminde yük dengeleyiciler gibi hizmetler dahil edilerek daha karmaşık uygulamalar oluşturulabilir.

Daha fazla bilgi için bkz . Kubernetes dağıtımları.

Helm ile paket yönetimi

Helm genellikle Kubernetes'teki uygulamaları yönetmek için kullanılır. Uygulama kodunun paketlenmiş sürümünü ve Kubernetes YAML bildirimlerini içeren mevcut genel Helm grafiklerini oluşturup kullanarak kaynakları dağıtabilirsiniz. Helm grafiklerini yerel olarak veya Azure Container Registry Helm grafik deposu gibi uzak bir depoda depolayabilirsiniz.

Helm'i kullanmak için helm istemcisini bilgisayarınıza yükleyin veya Azure Cloud Shell'de Helm istemcisini kullanın. Helm grafiklerini arayın veya oluşturun ve bunları Kubernetes kümenize yükleyin. Daha fazla bilgi için bkz . AKS'de Helm ile mevcut uygulamaları yükleme.

StatefulSets ve DaemonSets

Dağıtım Denetleyicisi Kubernetes Scheduler'ı kullanır ve kullanılabilir kaynakları olan kullanılabilir düğümlerde çoğaltmaları çalıştırır. Bu yaklaşım durum bilgisi olmayan uygulamalar için yeterli olsa da, Dağıtım Denetleyicisi aşağıdaki belirtimleri gerektiren uygulamalar için ideal değildir:

  • Kalıcı adlandırma kuralı veya depolama.
  • Küme içindeki her bir seçim düğümünde var olacak bir çoğaltma.

Ancak iki Kubernetes kaynağı, şu tür uygulamaları yönetmenize olanak tanır: StatefulSets ve DaemonSets.

StatefulSets, uygulamaların durumunu tek bir pod yaşam döngüsünün ötesinde tutar. DaemonSets , Kubernetes bootstrap işleminin başlarında her düğümde çalışan bir örnek olmasını sağlar.

StatefulSets

Modern uygulama geliştirme genellikle durum bilgisi olmayan uygulamaları hedefler. Veritabanı bileşenlerini içerenler gibi durum bilgisi olan uygulamalar için StatefulSets'i kullanabilirsiniz. Dağıtımlar gibi StatefulSet de en az bir özdeş pod oluşturur ve yönetir. StatefulSet içindeki çoğaltmalar dağıtım, ölçeklendirme, yükseltme ve sonlandırma işlemlerine yönelik düzgün ve sıralı bir yaklaşım izler. Çoğaltmalar StatefulSet ile yeniden zamanlandığında adlandırma kuralı, ağ adları ve depolama kalıcı olur.

kullanarak kind: StatefulSetuygulamayı YAML biçiminde tanımlayabilirsiniz. Buradan StatefulSet Denetleyicisi gerekli çoğaltmaların dağıtımını ve yönetimini işler. Azure Yönetilen Diskler veya Azure Dosyalar tarafından sağlanan kalıcı depolamaya veri yazma işlemleri. StatefulSets ile, StatefulSet silindiğinde bile temel alınan kalıcı depolama alanı kalır.

Daha fazla bilgi için bkz . Kubernetes StatefulSets.

Önemli

StatefulSet içindeki çoğaltmalar aks kümesindeki kullanılabilir düğümler arasında zamanlanır ve çalıştırılır. Kümenizdeki en az bir pod bir düğümde çalıştığından emin olmak için bunun yerine bir DaemonSet kullanmanız gerekir.

DaemonSets

Belirli günlük toplama veya izleme için tüm düğümlerde bir pod veya belirli bir düğüm kümesi çalıştırmanız gerekebilir. Bir veya daha fazla özdeş poda dağıtmak için DaemonSets'i kullanabilirsiniz. DaemonSet Denetleyicisi, belirtilen her düğümün podun bir örneğini çalıştırmasını sağlar.

DaemonSet Denetleyicisi, varsayılan Kubernetes zamanlayıcı başlatılmadan önce küme önyükleme işleminin başlarında düğümlerde pod zamanlayabilir. Bu özellik, bir Deployment veya StatefulSet içindeki geleneksel podlardan önce DaemonSet durumundaki podların zamanlanmasını sağlar.

StatefulSets gibi, kullanarak kind: DaemonSetyaml tanımının bir parçası olarak da bir DaemonSet tanımlayabilirsiniz.

Daha fazla bilgi için bkz . Kubernetes DaemonSets.

Not

Sanal Düğümler eklentisini kullanıyorsanız, DaemonSets sanal düğümde pod oluşturmaz.

Ad alanları

Podlar ve dağıtımlar gibi Kubernetes kaynakları, AKS kümesini bölmek ve kaynaklara erişim oluşturmak, görüntülemek veya yönetmek için mantıksal olarak ad alanları halinde gruplandırılır. Örneğin iş gruplarını ayırmak için ad alanları oluşturabilirsiniz. Kullanıcılar yalnızca kendilerine atanan ad alanları içindeki kaynaklarla etkileşimde bulunabilir.

Kaynakları ve uygulamaları mantıksal olarak bölmek için Kubernetes ad alanları

AKS kümesi oluşturduğunuzda aşağıdaki ad alanları kullanılabilir:

Ad Alanı Açıklama
varsayılan Podların ve dağıtımların hiçbiri sağlanmazsa varsayılan olarak oluşturulduğu yer. Daha küçük ortamlarda, ek mantıksal ayrımlar oluşturmadan uygulamaları doğrudan varsayılan ad alanına dağıtabilirsiniz. Ile gibi Kubernetes API'siyle kubectl get podsetkileşime geçtiğiniz zaman, hiçbiri belirtilmediğinde varsayılan ad alanı kullanılır.
kube-system DNS ve ara sunucu gibi ağ özellikleri veya Kubernetes panosu gibi temel kaynakların mevcut olduğu yerler. Genellikle bu ad alanına kendi uygulamalarınızı dağıtmazsınız.
kube-public Genellikle kullanılmaz, tüm kümede kaynakların görünür olması ve herhangi bir kullanıcı tarafından görüntülenebileceği için bunu kullanabilirsiniz.

Daha fazla bilgi için bkz . Kubernetes ad alanları.

Sonraki adımlar

Temel Kubernetes ve AKS kavramları hakkında daha fazla bilgi için aşağıdaki makalelere bakın: