Azure Kubernetes Service'te (AKS) yönetilen ad alanlarına genel bakış

Şunlar için geçerlidir: ✔️ AKS Otomatik ✔️ AKS Standart

Azure Kubernetes Service'te (AKS) kümeleri yönetirken genellikle ekipleri ve iş yüklerini yalıtmalısınız. Mantıksal yalıtım ile birden çok iş yükü, ekip veya ortam için tek bir AKS kümesi kullanabilirsiniz. Kubernetes ad alanları, iş yükleri ve kaynaklar için mantıksal yalıtım sınırını oluşturur. Mantıksal yalıtım gerçekleştirmek, ad alanları oluşturmak, kaynak sınırları ayarlamak, ağ ilkeleri uygulamak ve rol tabanlı erişim denetimi aracılığıyla ekip erişimi vermek için betikler ve işlemler uygulamayı içerir. Ad alanı yönetimini, çok kiracılı kümeyi ve kaynak yalıtımını basitleştirmek için Azure Kubernetes Service'te (AKS) yönetilen ad alanlarını kullanmayı öğrenin.

Kümelerin mantıksal ayrımı genellikle fiziksel olarak yalıtılmış kümelere göre daha yüksek bir pod yoğunluğu sağlar ve kümede boşta kalan fazla işlem kapasitesi daha azdır. Küme otomatik ölçeklendiricisi veya Düğüm Otomatik Sağlama ile birleştirildiğinde, talepleri karşılamak için düğüm sayısını artırıp azaltabilirsiniz. Bu en iyi yöntem yaklaşımı, yalnızca gerekli düğüm sayısını çalıştırarak maliyetleri en aza indirir.

Ağ ilkeleri

Ağ İlkeleri , podlar, ad alanları ve dış uç noktalar arasındaki trafik akışını denetlemek için kullanabileceğiniz Kubernetes kaynaklarıdır. Ağ ilkeleri, giriş (gelen) ve çıkış (giden) trafiği için kurallar tanımlamanıza olanak tanıyarak yalnızca yetkili iletişime izin verildiğini güvence altına alır. Ağ ilkeleri uygulayarak, kümenizdeki iş yüklerinin güvenliğini ve yalıtımını geliştirebilirsiniz.

Uyarı

Aynı ad alanına izin ver seçeneğinin varsayılan giriş ağ ilkesi kuralı, varsayılan olarak güvenli bir duruşu tercih eder. Kubernetes Hizmetlerinizin, girişlerinizin veya ağ geçitlerinizin, örneğin ayrı bir ad alanında dağıtılan giriş denetleyicisinden dağıtıldıkları ad alanının dışından erişilebilir olması gerekiyorsa Tümüne izin ver'i seçmeniz gerekir. Daha sonra girişi yalnızca bu ad alanından olacak şekilde kısıtlamak için kendi ağ ilkenizi uygulayabilirsiniz.

Yönetilen ad alanları bir dizi yerleşik ilkeyle birlikte gelir.

  • Tümüne izin ver: Tüm ağ trafiğine izin verir.
  • Aynı ad alanına izin ver: Aynı ad alanı içindeki tüm ağ trafiğine izin verir.
  • Tümünü reddet: Tüm ağ trafiğini reddeder.

Yerleşik ilkelerden herhangi birini hem giriş hem de çıkış kurallarına uygulayabilirsiniz ve bunlar aşağıdaki varsayılan değerlere sahiptir.

Politika Varsayılan değer
Giriş Aynı ad alanına izin ver
Çıkış Tümüne izin ver

Uyarı

Microsoft Entra ID rollerine atanmış ve Microsoft.ContainerService/managedClusters/networking.k8s.io/networkpolicies/write gibi bir eyleme Azure Kubernetes Service RBAC Writer izin verilen kullanıcılar, Kubernetes API'si aracılığıyla daha fazla ağ politikası ekleyebilir.

Örneğin, bir yönetici giriş/çıkış için bir Deny All ilkesi uyguladığında ve bir kullanıcı Kubernetes API'si kullanarak bir ad alanı için bir Allow ilkesi uyguladığında, Allow ilkesi Deny All ilkesinden daha önceliklidir ve ad alanı için trafik akışına izin verilir.

Kaynak kotaları

Kaynak Kotaları , küme içindeki ad alanlarının kaynak tüketimini yönetmek ve sınırlamak için kullanılan Kubernetes kaynaklarıdır. Yöneticilerin bir ad alanında iş yükleri tarafından kullanılan CPU, bellek, depolama alanı veya diğer kaynak miktarıyla ilgili kısıtlamalar tanımlamasına olanak sağlar. Kaynak kotaları uygulayarak adil kaynak dağıtımı sağlayabilir, kaynak aşırı kullanımını önleyebilir ve küme kararlılığını koruyabilirsiniz.

Yönetilen ad alanları aşağıdaki kaynak kotalarıyla oluşturulabilir:

  • CPU istekleri ve sınırları: Ad alanı içindeki iş yüklerinin isteyebileceği veya tüketebileceği en düşük ve en yüksek CPU kaynağı miktarını tanımlayın. Kota, iş yüklerinin çalışması için yeterli CPU kaynağına sahip olmasını sağlarken diğer ad alanlarını etkileyebilecek aşırı kullanımı önler. Kota miliCPU formunda tanımlanır.
  • Bellek istekleri ve sınırları: Ad alanı içindeki iş yüklerinin isteyebileceği veya kullanabileceği en düşük ve en yüksek bellek kaynağı miktarını belirtin. Kota, aşırı bellek kullanımını önleyerek ve ad alanları arasında adil kaynak ayırmayı sağlayarak kararlılığı korumaya yardımcı olur. Kota, ,, Ei, , PiTi, Gigibi MiKi tanımlanır.

Etiketler ve ek açıklamalar

Kubernetes Etiketleri ve Ek Açıklamalar , ek bilgi sağlamak için ad alanları gibi Kubernetes nesnelerine eklenmiş meta verilerdir. Etiketler, kaynakları düzenlemek ve seçmek için kullanılan anahtar-değer çiftleridir ve verimli gruplandırma ve sorgulama sağlar. Ek açıklamalar, araçlar veya sistemler tarafından kullanılan yapılandırma ayrıntıları veya işlem yönergeleri gibi tanımlayıcı olmayan meta verileri depolar.

İsteğe bağlı olarak Kubernetes Etiketlerini ve Ek Açıklamalarını ad alanına uygulanacak şekilde ayarlayabilirsiniz.

Benimseme ilkesi

Benimseme ilkesi, yönetilen ad alanı oluşturulurken Kubernetes'teki mevcut bir ad alanının nasıl işleneceğini belirler.

Uyarı

Mevcut bir ad alanını yönetim altına almak kesintiye neden olabilir. Uygulanan kaynak kotası podlar tarafından istenenden daha azsa, kotayı aşan yeni dağıtımlar ve podlar reddedilir. Mevcut dağıtımlar etkilenmez, ancak ölçeklendirme reddedilir. Mevcut bir ad alanına ağ ilkeleri uygulamak, var olan trafiği etkileyebilir. Podlar veya dış uç noktalar arasındaki iletişimde istenmeyen kesintileri önlemek için ilkelerin test ve doğrulandığından emin olun.

Aşağıdaki seçenekler kullanılabilir:

  • Hiçbir zaman: Ad alanı kümede zaten varsa, yönetilen ad alanı olarak bu ad alanını oluşturma girişimi başarısız olur.
  • IfIdentical: Mevcut ad alanı ile istenen yapılandırma arasında fark olmaması koşuluyla, yönetilecek mevcut ad alanını devralın.
  • Her zaman: Ad alanındaki bazı alanların üzerine yazılsa bile, yönetilecek mevcut ad alanını her zaman devralın.

İlkeyi silme

Silme ilkesi, yönetilen ad alanı kaynağı silindiğinde Kubernetes ad alanının nasıl işleneceğini belirtir.

Uyarı

Delete ilkesiyle yönetilen bir ad alanının silinmesi, söz konusu ad alanı içindeki Dağıtımlar, Hizmetler, Girişler ve diğer Kubernetes nesneleri gibi tüm kaynakların silinmesine neden olur. Devam etmeden önce tüm kritik kaynakları yedeklediğinizden veya geçirdiğinizden emin olun.

Aşağıdaki seçenekler kullanılabilir:

  • Koru: Kubernetes ad alanını olduğu gibi tutarken yalnızca yönetilen ad alanı kaynağını silin. Ayrıca, ManagedByARM etiket ad alanından kaldırılır.
  • Sil: Hem yönetilen ad alanı kaynağını hem de Kubernetes ad alanını birlikte silin.

Yönetilen ad alanları yerleşik rolleri

Yönetilen ad alanları, denetim düzlemi için aşağıdaki yerleşik rolleri kullanır.

Rol Açıklama
Azure Kubernetes Service Ad Alanı Katkıda Bulunanı Bir kümede yönetilen ad alanları oluşturma, güncelleştirme ve silme erişimine izin verir.
Azure Kubernetes Service Ad Alanı Kullanıcısı Bir kümedeki yönetilen ad alanına salt okunur erişime izin verir. Ad alanında liste kimlik bilgilerine erişime izin verir.

Yönetilen ad alanları, veri düzlemi için aşağıdaki yerleşik rolleri kullanır.

Rol Açıklama
Azure Kubernetes Service RBAC Okuyucusu İsim alanındaki çoğu nesneyi görmek için salt okunur erişime izin verir. Rolleri veya rol bağlamalarını görüntülemeye izin vermez. Gizli Dizilerin içeriğinin okunması ad alanında ServiceAccount kimlik bilgilerine erişim sağladığından bu rol Gizli Dizilerin görüntülenmesine izin vermez ve bu da ad alanında herhangi bir ServiceAccount olarak API erişimine izin verir (ayrıcalık yükseltme biçimi).
Azure Kubernetes Service RBAC Yazıcısı Ad alanı içindeki çoğu nesneye okuma/yazma erişimine izin verir. Bu rol, rollerin veya rol bağlamalarının görüntülenmesine veya değiştirilmesine izin vermez. Ancak, bu rol Gizli Dizilere erişmeye ve podları ad alanında herhangi bir ServiceAccount olarak çalıştırmaya olanak tanır, bu nedenle ad alanında herhangi bir ServiceAccount'ın API erişim düzeylerini kazanmak için kullanılabilir.
Azure Kubernetes Service RBAC Yöneticisi Ad alanı içinde rol ve rol bağlamaları oluşturma özelliği de dahil olmak üzere ad alanı içindeki kaynakların çoğuna okuma/yazma erişimine izin verir. Bu rol, kaynak kotasına veya ad alanının kendisine yazma erişimine izin vermez.

Yönetilen ad alanları kullanım örnekleri

İlişkili kotalara veya ağ ilkelerine sahip ad alanlarının düzgün ayarlanması karmaşık ve zaman alabilir. Yönetilen ad alanları, AKS kümelerinizde Azure CLI kullanarak etkileşim kurabileceğiniz önceden yapılandırılmış ad alanları ayarlamanıza olanak sağlar.

Aşağıdaki bölümlerde, yönetilen ad alanları için bazı yaygın kullanım örnekleri özetlenmiştir.

AKS'de ekipleri ve kaynakları yönetme

Küçük bir başlangıçta yönetici olduğunuzu varsayalım. Sağlanan bir AKS kümeniz var ve finans, hukuk ve tasarım ekiplerinizden geliştiriciler için ad alanları ayarlamak istiyorsunuz. Şirketinizin ortamını ayarlarken, erişimin sıkı bir şekilde denetlendiğinden, kaynakların doğru şekilde kapsamlandırıldığından ve ortamların düzgün düzenlendiğinden emin olmak istiyorsunuz.

  • Finans ekibi, şirketin her yerinden ekiplerden form ve dosya alır, ancak ideal olarak ortamlarından ayrılmaması gereken hassas bilgileri tutar. Uygulamaları ve iş akışları bilgi işlem tarafında daha hafiftir ancak çok fazla bellek tüketir. Sonuç olarak, tüm ağ girişlerine, yalnızca kendi ad alanı içinde ağ çıkışına izin veren bir ad alanı ayarlamaya ve kaynaklarını buna göre kapsamaya karar verirsiniz. Ad alanına etiket eklemek, hangi ekibin bunu kullandığını kolayca belirlemenize yardımcı olur.

    az aks namespace add \
   --name $FINANCE_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 250m \
   --cpu-limit 500m \
   --memory-request 512Mi \
   --memory-limit 2Gi \
   --ingress-policy AllowAll \
   --egress-policy AllowSameNamespace \
   --labels team=finance

  • Hukuk ekibi öncelikli olarak hassas verilerle ilgilenir. Uygulamaları makul miktarda bellek kullanır ancak çok az işlem kaynağı gerektirir. Hem giriş/çıkış ilkeleri için son derece kısıtlayıcı bir ad alanı ayarlamaya hem de kaynak kotalarının kapsamını buna göre belirlemeye karar verirsiniz.

    az aks namespace add \
   --name $LEGAL_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 250m \
   --cpu-limit 500m \
   --memory-request 2Gi \
   --memory-limit 5Gi \
   --ingress-policy DenyAll \
   --egress-policy DenyAll \
   --labels team=legal

  • Tasarım ekibinin, şirket genelinde çalışmalarını göstermek için serbestçe veri akışı yapabilmesi gerekiyor. Ayrıca, ekiplerin onlara başvuru için içerik göndermesini de teşvik eder. Uygulamaları yoğundur ve büyük bir bellek ve CPU öbekleri gerektirir. Bunları en düşük düzeyde kısıtlayıcı bir ad alanıyla ayarlamaya ve bunlar için boyutlandırılabilir miktarda kaynak ayırmaya karar verirsiniz.

    az aks namespace add \
   --name $DESIGN_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 2000m \
   --cpu-limit 2500m \
   --memory-request 5Gi \
   --memory-limit 8Gi \
   --ingress-policy AllowAll \
   --egress-policy AllowAll \
   --labels team=design

Bu ad alanları ayarlandıysa, kuruluşunuzdaki üç ekip için her ekibin ihtiyaçlarına en uygun ortamda çalışmaya başlamasını sağlayacak ortamlara sahip olursunuz. Yöneticiler, ad alanlarını ihtiyaçlar değiştikçe güncelleştirmek için Azure CLI çağrılarını kullanabilir.

Yönetilen ad alanlarını görüntüleme

İşlediğiniz ekiplerin sayısı arttıkça veya kuruluşunuz büyüdükçe, ayarladığınız ad alanlarını gözden geçirmeniz gerektiğini fark edebilirsiniz.

Üç ad alanı olduğundan emin olmak için önceki bölümden kümenizdeki ad alanlarını gözden geçirmek istediğinizi varsayalım.

az aks namespace list Ad alanlarınızı gözden geçirmek için komutunu kullanın.

az aks namespace list \
  --cluster-name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --output table

Çıkışınız aşağıdaki örnek çıkışa benzer olmalıdır:

Name                               ResourceGroup    Location
------------------                 ---------------  ----------
$CLUSTER_NAME/$DESIGN_NAMESPACE    $RESOURCE_GROUP  <LOCATION>
$CLUSTER_NAME/$LEGAL_NAMESPACE     $RESOURCE_GROUP  <LOCATION>
$CLUSTER_NAME/$FINANCE_NAMESPACE   $RESOURCE_GROUP  <LOCATION>

Yönetilen ad alanlarına erişimi denetleme

Hangi kullanıcıların ad alanı içindeki belirli eylemlere erişimi olduğunu belirlemek için her ad alanı kapsamındaki Azure RBAC rollerini daha fazla kullanabilirsiniz. Uygun yapılandırmayla, kullanıcıların ad alanında ihtiyaç duydukları tüm erişime sahip olduğundan emin olurken, diğer ad alanlarına veya küme genelindeki kaynaklara erişimlerini sınırlayabilirsiniz.

Sonraki Adımlar

  • Last updated on