Azure Kubernetes Service (AKS)'de kubenet ağını kendi IP adresi aralıklarınızla kullanma

Önemli

31 Mart 2028 tarihinde Azure Kubernetes Service (AKS) için kubenet ağı kullanımdan kaldırılacaktır.

Hizmet kesintilerini önlemek için, Azure Kapsayıcı Ağı Arabirimi (CNI) katmanına yükseltmeniz gerekecekbu tarihten önce, çünkü o tarihten sonra AKS için kubenet üzerinde çalışan iş yükleri artık desteklenmeyecektir.

AKS kümeleri kubenet kullanır ve varsayılan olarak sizin için Azure bir sanal ağ ve alt ağ oluşturur. kubenet ile düğümler Azure sanal ağ alt ağından bir IP adresi alır. Pod'lar, Azure sanal ağ alt ağı düğümlerinden mantıksal olarak farklı bir adres alanından bir IP adresi alır. Daha sonra podların Azure sanal ağdaki kaynaklara ulaşabilmesi için ağ adresi çevirisi (NAT) yapılandırılır. Trafiğin kaynak IP adresi, düğümün birincil IP adresine NAT ile çevrilir. Bu yaklaşım, podların kullanması için ağ alanınızda ayırmanız gereken IP adreslerinin sayısını büyük ölçüde azaltır.

Azure Container Networking Interface (CNI) ile her pod alt ağdan bir IP adresi alır ve doğrudan erişilebilir. Bu IP adresleri önceden planlanmalıdır ve ağ alanınız genelinde benzersiz olmalıdır. Her düğümün desteklediği en fazla pod sayısı için bir yapılandırma parametresi vardır. Düğüm başına eşdeğer IP adresi sayısı daha sonra bu düğüm için önceden ayrılır. Bu yaklaşım daha fazla planlama gerektirir ve genellikle IP adresi tükenmesine veya uygulamanızın talebi arttıkça daha büyük bir alt ağda kümeleri yeniden oluşturma gereksinimine yol açar. Küme oluşturma zamanında veya yeni düğüm havuzları oluştururken düğüme dağıtılabilen en fazla pod sayısını yapılandırabilirsiniz. Yeni düğüm havuzları oluştururken belirtmezseniz maxPods kubenet için varsayılan 110 değerini alırsınız.

Bu makalede, aks kümesi için sanal ağ alt ağı oluşturmak ve kullanmak için kubenet ağının nasıl kullanılacağı gösterilmektedir. Ağ seçenekleri ve dikkat edilmesi gerekenler hakkında daha fazla bilgi için bkz . Kubernetes ve AKS için ağ kavramları.

Önkoşullar

  • AKS kümesinin sanal ağı giden İnternet bağlantısına izin vermelidir.
  • Aynı alt ağda birden fazla AKS kümesi oluşturmayın.
  • AKS kümeleri 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 veya 192.0.2.0/24 adreslerini Kubernetes hizmet adres aralığı, pod adres aralığı veya küme sanal ağ adres aralığı için kullanamaz. 1.33'ten önceki Kubernetes sürümlerini çalıştıran kümelerde, kümenizi oluşturduktan sonra bu aralıklar güncelleştirilemez. Kubernetes 1.33'den başlayarak, Kubernetes kaynağını kullanarak ServiceCIDR küme oluşturulduktan sonra hizmet IP aralığını genişletebilirsiniz.
  • AKS kümesi tarafından kullanılan küme kimliği en azından sanal ağınızdaki alt ağda Ağ Katkıda Bulunanı rolüne sahip olmalıdır. CLI, rol atamasının otomatik olarak ayarlanmasına yardımcı olur. ARM şablonu veya başka istemciler kullanıyorsanız rol atamasını el ile ayarlamanız gerekir. Küme kimliği oluşturmak ve izin atamak için abonelik sahibi gibi uygun izinlere de sahip olmanız gerekir. Yerleşik Ağ Katkıda Bulunanı rolünü kullanmak yerine özel bir rol tanımlamak istiyorsanız aşağıdaki izinlere ihtiyacınız vardır:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Kendi sanal ağınızı getirirseniz sanal ağ önkoşullarını gözden geçirin.

Uyarı

Windows Server düğüm havuzlarını kullanmak için Azure CNI kullanmanız gerekir. kubenet ağ modeli Windows Server kapsayıcılar için kullanılamaz.

Başlamadan önce

Azure CLI sürüm 2.0.65 veya üzerinin yüklü ve yapılandırılmış olması gerekir. Sürümü bulmak için az --version komutunu çalıştırın. Yüklemeniz veya yükseltmeniz gerekiyorsa bkz. Azure CLI yükleme.

Kendi alt ağınızla kubenet ağına genel bakış

Birçok ortamda, ayrılmış IP adresi aralıklarına sahip sanal ağlar ve alt ağlar tanımlamış ve bu kaynakları birden çok hizmet ve uygulamayı desteklemek için kullanırsınız. AKS kümeleri ağ bağlantısı sağlamak için kubenet (temel ağ) veya Azure CNI (gelen ağ) kullanabilir.

kubenet ile sanal ağ alt ağında yalnızca düğümler bir IP adresi alır. Podlar birbirleriyle doğrudan iletişim kuramaz. Bunun yerine, Kullanıcı Tanımlı Yönlendirme (UDR) ve IP yönlendirme, düğümler arasında podlar arasındaki bağlantıyı sağlar. UDR'ler ve IP iletme yapılandırması AKS hizmeti tarafından varsayılan olarak oluşturulur ve korunur, ancak isterseniz özel yol yönetimi için kendi yol tablonuzu getirebilirsiniz. Ayrıca, atanmış bir IP adresi alan ve uygulama için trafiği yük dengeleyen bir hizmetin arkasına pod dağıtabilirsiniz. Aşağıdaki diyagramda, AKS düğümlerinin sanal ağ alt ağında bir IP adresi aldığını, ancak podların almadığını gösterilmektedir.

AKS kümesi ile Kubenet ağ modeli

Azure bir UDR'de en fazla 400 yolunu desteklediğinden 400 düğümden büyük bir AKS kümeniz olamaz. AKS virtual düğümler ve Azure Ağ Politikaları kubenet ile desteklenmez. Calico Ağ İlkeleri desteklenir.

Azure CNI ile her pod, IP alt akında bir IP adresi alır ve diğer podlar ve hizmetlerle doğrudan iletişim kurabilir. Kümeleriniz belirttiğiniz IP adresi aralığı kadar büyük olabilir. Ancak, IP adresi aralığını önceden planlamanız gerekir ve tüm IP adresleri, desteklenebileceği en fazla pod sayısına göre AKS düğümleri tarafından kullanılır. virtual düğümler veya Ağ İlkeleri (Azure veya Calico) gibi gelişmiş ağ özellikleri ve senaryoları Azure CNI ile desteklenir.

Kubenet ile ilgili sınırlamalar ve dikkat edilmesi gerekenler

Not

Küme içindeki bazı sistem podları, kaplama adres alanından bir IP yerine konnectivity gibi, konak düğümünün IP adresini kullanır. Sistem podları, sanal ağdan bir IP adresi değil yalnızca düğüm IP'sini kullanır.

IP adresi kullanılabilirliği ve tükenmesi

Azure CNI ile ilgili yaygın bir sorun, atanan IP adresi aralığının bir kümeyi ölçeklendirirken veya yükseltirken daha fazla düğüm ekleyemeyecek kadar küçük olmasıdır. Ağ ekibi, beklenen uygulama taleplerinizi destekleyecek kadar büyük bir IP adresi aralığı da düzenleyemeyebilir.

Uzlaşma olarak, kubenet kullanan bir AKS kümesi oluşturabilir ve mevcut bir sanal ağ alt ağına bağlanabilirsiniz. Bu yaklaşım, düğümlerin kümede çalışabilecek olası podlar için önceden çok sayıda IP adresi ayırmaya gerek kalmadan tanımlı IP adreslerini almasını sağlar. kubenet ile çok daha küçük bir IP adresi aralığı kullanabilir ve büyük kümeleri ve uygulama taleplerini destekleyebilirsiniz. Örneğin, alt ağınızda /27 IP adresi aralığıyla, ölçeklendirmek veya yükseltmek için yeterli alanı olan 20-25 düğümlü bir küme çalıştırabilirsiniz. Bu küme boyutu en fazla 2.200-2.750 pod (düğüm başına varsayılan en fazla 110 pod) destekleyebilir. AKS'de kubenet ile yapılandırabileceğiniz düğüm başına en fazla pod sayısı 250'dir.

Aşağıdaki temel hesaplamalar, ağ modellerindeki farkı karşılaştırır:

  • kubenet: Basit bir /24 IP adresi aralığı, kümede en fazla 251 düğümü destekleyebilir. Her Azure sanal ağ alt ağı, yönetim işlemleri için ilk üç IP adresini ayırır. Bu düğüm sayısı, düğüm başına varsayılan en fazla 110 pod ile toplamda 27.610 podu destekleyebilir.
  • Azure CNI: Aynı temel /24 alt ağ aralığı yalnızca kümedeki en fazla eight düğümlerini destekleyebilir. Bu düğüm sayısı, varsayılan olarak düğüm başına en fazla 30 pod olacak şekilde, en fazla 240 podu destekleyebilir.

Not

Bu maksimum değerler yükseltme veya ölçeklendirme işlemlerini dikkate almaz. Uygulamada, alt ağ IP adresi aralığının desteklediği en fazla düğüm sayısını çalıştıramazsınız. Ölçeklendirme veya yükseltme işlemleri için bazı IP adreslerini kullanılabilir bırakmanız gerekir.

Sanal ağ eşlemesi ve ExpressRoute bağlantıları

Şirket içi bağlantı sağlamak için hem kubenet hem de Azure-CNI ağ yaklaşımları Azure sanal ağ eşleme veya ExpressRoute bağlantılarını kullanabilir. Çakışmayı ve yanlış trafik yönlendirmesini önlemek için IP adresi aralıklarınızı dikkatlice planlayın. Örneğin, birçok şirket içi ağ ExpressRoute bağlantısı üzerinden tanıtılan 10.0.0.0/8 adres aralığını kullanır. AKS kümelerinizi 172.16.0.0/16 gibi bu adres aralığının dışındaki Azure sanal ağ alt ağlarında oluşturmanızı öneririz.

Kullanılacak ağ modelini seçme

Aşağıdaki önemli noktalar, her ağ modelinin en uygun olduğu zamanları özetler:

Şu durumlarda kubenet kullanın:

  • Ip adresi alanınız sınırlı.
  • Pod iletişiminin çoğu küme içindedir.
  • Sanal düğümler veya Azure Ağ İlkesi gibi gelişmiş AKS özelliklerine ihtiyacınız yoktur.

Azure CNI kullanın:

  • Kullanılabilir IP adresi alanınız var.
  • Pod iletişiminin çoğu küme dışındaki kaynaklara yapılır.
  • Pod bağlantısı için kullanıcı tanımlı yolları yönetmek istemezsiniz.
  • Sanal düğümler veya Azure Ağ İlkesi gibi AKS gelişmiş özelliklerine ihtiyacınız vardır.

Hangi ağ modelini kullanacağınıza karar vermenize yardımcı olacak daha fazla bilgi için bkz . Ağ modellerini ve bunların destek kapsamını karşılaştırma.

Sanal ağ ve alt ağ oluşturma

  1. komutunu kullanarak az group create bir kaynak grubu oluşturun.

    az group create --name myResourceGroup --location eastus

  2. Kullanılacak bir sanal ağınız ve alt ağınız yoksa komutunu kullanarak az network vnet create bu ağ kaynaklarını oluşturun. Aşağıdaki örnek komut, adres ön eki 192.168.0.0/16 olan myAKSVnet adlı bir sanal ağ ve adres ön eki 192.168.1.0/24 olan myAKSSubnet adlı bir alt ağ oluşturur:

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. komutunu kullanarak az network vnet subnet show alt ağ kaynak kimliğini alın ve daha sonra kullanmak üzere adlı SUBNET_ID bir değişken olarak depolayın.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Sanal ağda AKS kümesi oluşturma

Sistem tarafından atanan yönetilen kimliklerle AKS kümesi oluşturma

Not

Sistem tarafından atanan kimlik kullanılırken Azure CLI, küme oluşturulduktan sonra sistem tarafından atanan kimliğe Ağ Katkıda Bulunanı rolü verir. ARM şablonu veya başka istemciler kullanıyorsanız, bunun yerine kullanıcı tarafından atanan yönetilen kimliği kullanmanız gerekir.

  • komutunu kullanarak az aks create sistem tarafından atanan yönetilen kimliklerle bir AKS kümesi oluşturun.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Dağıtım parametreleri:

    • --service-cidr isteğe bağlıdır. Bu adres, AKS kümesindeki iç hizmetleri bir IP adresi atamak için kullanılır. Bu IP adresi aralığı, Express Route veya Siteden Siteye VPN bağlantısı kullanarak Azure sanal ağlarınıza bağlanmanız veya bağlanmayı planlamanız durumunda şirket içi ağ aralıkları dahil olmak üzere ağ ortamınızda başka bir yerde kullanılmamış bir adres alanı olmalıdır. Varsayılan değer 10.0.0.0/16'dır.
    • --dns-service-ip isteğe bağlıdır. Adres, hizmet IP adresi aralığınızın .10 adresi olmalıdır. Varsayılan değer 10.0.0.10'dur.
    • --pod-cidr isteğe bağlıdır. Bu adres, ağ ortamınızda başka bir yerde kullanılmamış büyük bir adres alanı olmalıdır. Bu aralık, sanal ağlarınızı Azure üzerinde ExpressRoute veya Siteden Siteye VPN bağlantısı kullanarak bağladığınızda veya bağlamayı planladığınızda, şirket içi ağ aralıklarını içerir. Varsayılan değer 10.244.0.0/16'dır.
      • Bu adres aralığı, ölçeği artırmayı beklediğiniz düğüm sayısını karşılayacak kadar büyük olmalıdır. Küme dağıtıldıktan sonra bu adres aralığını değiştiremezsiniz.
      • Pod IP adresi aralığı, kümedeki her düğüme / 24 adres alanı atamak için kullanılır. Aşağıdaki örnekte, `--pod-cidr` değeri olan `10.244.0.0/16` ilk düğüme `10.244.0.0/24`, ikinci düğüme `10.244.1.0/24` ve üçüncü düğüme `10.244.2.0/24` atar.
      • Küme ölçeklendikçe veya yükseltildikçe, Azure platformu her yeni düğüme bir pod IP adresi aralığı atamaya devam eder.

Kullanıcı tarafından atanan yönetilen kimlikle AKS kümesi oluşturma

Yönetilen kimlik oluştur.

  • komutunu kullanarak az identity yönetilen kimlik oluşturun. Mevcut bir yönetilen kimliğiniz varsa, bunun yerine az identity show --ids <identity-resource-id> komutunu kullanarak asıl kimliği bulun.

    az identity create --name myIdentity --resource-group myResourceGroup

    Çıkışınız aşağıdaki örnek çıkışa benzemelidir:

    {
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Yönetilen kimlik için rol ataması ekle

Azure CLI kullanıyorsanız rol otomatik olarak eklenir ve bu adımı atlayabilirsiniz. ARM şablonu veya başka istemciler kullanıyorsanız rol ataması gerçekleştirmek için küme yönetilen kimliğinin Asıl Kimliğini kullanmanız gerekir.

  • komutunu kullanarak az network vnet show sanal ağ kaynak kimliğini alın ve adlı VNET_IDbir değişken olarak depolayın.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • komutunu kullanarak sanal ağda AKS kümenizin Ağ Katkıda Bulunanı izinleri için yönetilen kimliği atayın az role assignment create ve principalId<>sağlayın.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Not

Azure'un kullandığı kümenizin yönetilen kimliğine verilen iznin etkin hale gelmesi 60 dakika sürebilir.

AKS kümesi oluşturma

  • Komutunu kullanarak bir AKS kümesi oluşturun ve kullanıcı tarafından atanan yönetilen kimliği atamak amacıyla az aks create bağımsız değişkenine denetim düzleminin yönetilen kimlik kaynak kimliğini verin.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

AKS kümesi oluşturduğunuzda, otomatik olarak bir ağ güvenlik grubu ve yönlendirme tablosu oluşturulur. Bu ağ kaynakları AKS denetim düzlemi tarafından yönetilir. Ağ güvenlik grubu, düğümlerinizdeki sanal NIC'lerle otomatik olarak ilişkilendirilir. Yönlendirme tablosu otomatik olarak sanal ağ alt ağıyla ilişkilendirilir. Ağ güvenlik grubu kuralları ve yönlendirme tabloları, siz hizmetleri oluşturup kullanıma sunarken otomatik olarak güncelleştirilir.

Kubenet ile kendi alt ağınızı ve yönlendirme tablonuzu getirme

kubenet ile, küme alt ağlarınızda bir yönlendirme tablosu bulunmalıdır. AKS, kendi mevcut alt ağınızı ve yol tablonuzu getirmeyi destekler. Özel alt ağınız bir yönlendirme tablosu içermiyorsa AKS sizin için bir tablo oluşturur ve küme yaşam döngüsü boyunca kurallar ekler. Kümenizi oluştururken özel alt ağınız bir yönlendirme tablosu içeriyorsa AKS, küme işlemleri sırasında mevcut yol tablosunu kabul eder ve bulut sağlayıcısı işlemleri için uygun kuralları ekler/güncelleştirir.

Uyarı

Özel yol tablosuna özel kurallar ekleyebilir/güncelleştirebilirsiniz. Ancak, Kubernetes bulut sağlayıcısı tarafından eklenen kurallar güncellenemez veya kaldırılamaz. Gibi 0.0.0.0/0 kuralları, genellikle belirli bir yol tablosunda bulunur (giden trafik türü olmadığı sürece) ve NVA veya diğer çıkış ağ geçidi gibi internet ağ geçidinizin hedefiyle eşleşir. Kuralları güncelleştirirken dikkatli olun.

Özel yol tablosu ayarlama hakkında daha fazla bilgi edinin.

Kubenet ağı, istekleri başarıyla yönlendirmek için düzenli yönlendirme tablosu kuralları gerektirir. Bu tasarım nedeniyle, rota tablolarının ona bağlı olan her küme için dikkatli bir şekilde korunması gerekir. Farklı kümelerden pod CIDR'leri çakışabileceğinden birden çok küme yol tablosunu paylaşamaz ve bu da beklenmeyen ve bozuk yönlendirme senaryolarına neden olabilir. Aynı sanal ağda birden çok küme yapılandırırken veya her kümeye bir sanal ağ ayırdığınızda aşağıdaki sınırlamaları göz önünde bulundurun:

  • AKS kümesini oluşturmadan önce alt ağ ile özel bir yol tablosu ilişkilendirilmelidir.
  • küme oluşturulduktan sonra ilişkili yol tablosu kaynağı güncelleştirilemez. Ancak, özel kurallar rota tablosunda değiştirilebilir.
  • Her AKS kümesi, kümeyle ilişkili tüm alt ağlar için tek, benzersiz bir yol tablosu kullanmalıdır. Çakışan pod CIDR'leri ve çakışan yönlendirme kuralları nedeniyle bir yol tablosunu birden çok kümeyle yeniden kullanamazsınız.
  • Sistem tarafından atanan yönetilen kimlik için yalnızca Azure CLI aracılığıyla kendi alt ağınızı ve yönlendirme tablonuzu sağlamanız desteklenir çünkü Azure CLI rol atamasını otomatik olarak ekler. ARM şablonu veya başka istemciler kullanıyorsanız, kullanıcı tarafından atanan bir yönetilen kimlik kullanmanız, küme oluşturmadan önce izinleri atamanız ve kullanıcı tarafından atanan kimliğin özel alt ağınız ve özel yönlendirme tablonuz için yazma izinlerine sahip olduğundan emin olmanız gerekir.
  • Aynı yol tablosunun birden çok AKS kümesiyle kullanılması desteklenmez.

Not

Kubenet ağ eklentisiyle kendi sanal ağınızı ve yönlendirme tablonuzu oluşturup kullandığınızda, küme için kullanıcı tarafından atanan bir yönetilen kimlik yapılandırmanız gerekir. Sistem tarafından atanan yönetilen kimlikle, bir küme oluşturmadan önce kimliğinizi alamazsınız, bu da rol ataması sırasında gecikmeye neden olur.

Azure ağ eklentisiyle kendi sanal ağınızı ve yönlendirme tablonuzu oluşturup kullandığınızda hem sistem tarafından atanan hem de kullanıcı tarafından atanan yönetilen kimlikler desteklenir. KCG senaryoları için kullanıcı tarafından atanan yönetilen kimlik kullanmanızı kesinlikle öneririz.

AKS kümenize kullanıcı tarafından atanan yönetilen kimliğe sahip bir yönlendirme tablosu ekleme

Özel bir yol tablosu oluşturduktan ve bunu sanal ağınızdaki bir alt ağ ile ilişkilendirdikten sonra, kullanıcı tarafından atanan yönetilen kimlikle yol tablonuzu belirten yeni bir AKS kümesi oluşturabilirsiniz. AKS kümenizi dağıtmayı planladığınız yer için alt ağ kimliğini kullanmanız gerekir. Bu alt ağın özel yol tablonuzla da ilişkilendirilmesi gerekir.

  1. komutunu kullanarak az network vnet subnet list alt ağ kimliğini alın.

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. az aks create komutunu kullanarak ve --vnet-subnet-id ile --assign-identity parametrelerine kendi değerlerinizi girerek yönlendirme tablosu önceden yapılandırılmış özel bir alt ağa sahip bir AKS kümesi oluşturun.

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Sonraki adımlar

Bu makalede AKS kümenizi mevcut sanal ağ alt ağınıza nasıl dağıtabileceğiniz gösterildi. Artık Helm kullanarak yeni uygulamalar oluşturmaya başlayabilir veya Helm'i kullanarak mevcut uygulamaları dağıtabilirsiniz.

  • Son güncelleştirme: