Azure Kubernetes Service (AKS) için Temel Kubernetes kavramları
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.
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ı. |
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 containerd
bir 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 containerd
Windows 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
containerd
Kubernetes 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ındacrictl
daha 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ükcri
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.sock
eriş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 Insights'ı 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
Container Insights (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
kubelet
daemon 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.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.
- 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.
1.29 öncesi AKS sürümleri
kubelet
daemon 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.- 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 \
--generate-ssh-keys
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 apply
ile 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.labels gerekir. |
.spec.template.labels |
Nesneye eklenmiş {key, value} çiftlerini belirtir. |
.spec.template.app |
ile eşleşmesi .spec.selector.matchLabels gerekir. |
.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: StatefulSet
uygulamayı 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. Temel alınan kalıcı depolama, StatefulSet silindiğinde bile, olarak ayarlanmadığı Delete
sürece spec.persistentVolumeClaimRetentionPolicy
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: DaemonSet
yaml tanımının bir parçası olarak da bir DaemonSet tanımlayabilirsiniz.
Daha fazla bilgi için bkz . Kubernetes DaemonSets.
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.
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 pods etkileş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:
Azure Kubernetes Service
Geri Bildirim
https://aka.ms/ContentUserFeedback.
Çok yakında: 2024 boyunca, içerik için geri bildirim mekanizması olarak GitHub Sorunları’nı kullanımdan kaldıracak ve yeni bir geri bildirim sistemiyle değiştireceğiz. Daha fazla bilgi için bkz.Gönderin ve geri bildirimi görüntüleyin