Azure Kubernetes Service (AKS) kümesi için temel mimari

Bu başvuru mimarisinde, bir Azure Kubernetes hizmeti (AKS) kümesi dağıtan bir taban çizgisi altyapısı oluşturacağız. Bu makale, kuruluşun iş gereksinimlerine bağlı olarak, kümenin Ağ, güvenlik, kimlik, yönetim ve izleme önerilerini içerir.

bu mimarinin uygulanması GitHub: Azure kubernetes Service (aks) güvenli temel başvuru uygulamasındakullanılabilir. Bunu bir başlangıç noktası olarak kullanabilir ve gereksinimlerinize göre yapılandırabilirsiniz.

Ağ yapılandırması

Ağ topolojisi
IP adreslerini planlayın
Giriş kaynaklarını dağıtma

Küme işlem

Temel küme için işlem
Kapsayıcı görüntüsü başvurusu
İlke yönetimi

Kimlik yönetimi

Küme için Azure AD 'yi tümleştirme
İş yükü için Azure AD 'yi tümleştirme

Güvenli veri akışı

Ağ akışının güvenliğini sağlama
Gizli dizi yönetimi ekleme

İş sürekliliği

Ölçeklenebilirlik
Küme ve düğüm kullanılabilirliği
Kullanılabilirlik ve çoklu bölge desteği

Operations

Küme ve iş yükü CI/CD işlem hatları
Küme durumu ve ölçümleri
Maliyet yönetimi ve raporlama

Ağ topolojisi

Bu mimari, hub-ışınsal-uç ağ topolojisi kullanır. Hub ve bağlı ağlar, eşlemeile bağlantılı ayrı sanal ağlarda dağıtılır. Bu topolojinin bazı avantajları şunlardır:

• Ayrılmış yönetim. İdare uygulama ve boşit yarıçapını denetleme için bir yol sağlar. Ayrıca, görev ayrımı ile giriş bölgesi kavramını destekler.

• Azure kaynaklarının doğrudan genel olarak açıklanmasını en aza indirir.

• Kuruluşlar genellikle bölgesel hub-bağlı topolojilerle çalışır. Hub-bağlı ağ topolojileri gelecekte genişletilebilir ve iş yükü yalıtımı sağlayabilir.

• Tüm Web uygulamaları, HTTP trafik akışlarını yönetmenize yardımcı olmak için bir Web uygulaması güvenlik duvarı (WAF) hizmeti gerektirir.

• Birden çok aboneliğe yayılan iş yükleri için doğal seçim.

• Mimarinin Genişletilebilir olmasını sağlar. Yeni özellikleri veya iş yüklerini karşılamak için, ağ topolojisini yeniden tasarlamak yerine yeni bağlı bileşen eklenebilir.

• Güvenlik Duvarı ve DNS gibi belirli kaynaklar ağlar arasında paylaşılabilir.

Hub

Hub sanal ağı, bağlantı ve Observability merkezi bir noktasıdır. Ağ içinde, üç alt ağ dağıtılır.

Azure Güvenlik duvarını barındıracak alt ağ

Azure Güvenlik duvarı hizmet olarak güvenlik duvarıdır. Güvenlik Duvarı örneği giden ağ trafiğinin güvenliğini sağlar. Bu güvenlik katmanı olmadan akış, hassas şirket verilerini etkileyebilecek kötü amaçlı bir üçüncü taraf hizmetiyle iletişim kurabilir.

Ağ geçidini barındıracak alt ağ

Bu alt ağ, VPN veya ExpressRoute ağ geçidi için bir yer tutucudur. Ağ Geçidi, şirket içi ağdaki ve sanal ağdaki yönlendiriciler arasında bağlantı sağlar.

Azure savunma 'yi barındıracak alt ağ

Bu alt ağ, Azuresavunma için bir yer tutucudur. Azure kaynaklarına kaynakları internet 'te kullanıma sunmadan güvenli bir şekilde erişmek için savunma kullanabilirsiniz. Bu alt ağ yalnızca yönetim ve işlemler için kullanılır.

Bileşen

Bağlı olan sanal ağ, AKS kümesini ve diğer ilgili kaynakları içerir. Bağlı bileşen üç alt ağa sahiptir:

Azure Application Gateway barındıracak alt ağ

Azure Application Gateway , katman 7 ' de çalışan bir Web trafiği yük dengeleyicidir. Başvuru uygulaması, Web uygulaması güvenlik duvarını (WAF) sağlayan Application Gateway v2 SKU 'su kullanır. WAF, yaygın web trafiği saldırılarına karşı gelen trafiğin güvenliğini sağlar. Örnekte, Kullanıcı isteklerini alan genel bir ön uç IP yapılandırması vardır. Tasarıma göre Application Gateway adanmış bir alt ağ gerektirir.

Giriş kaynaklarını barındıracak alt ağ

Trafiği yönlendirmek ve dağıtmak için Traefik, Kubernetes giriş kaynaklarını yerine getiren giriş denetleyicisidir. Bu alt ağda Azure iç yük dengeleyiciler bulunur.

Küme düğümlerini barındıracak alt ağ

AKS iki ayrı düğüm grubunu (veya düğüm havuzlarını) tutar. Sistem düğüm havuzu , çekirdek küme hizmetlerini çalıştıran bir pod barındırır. Kullanıcı düğümü havuzu , iş yüküne gelen iletişimi kolaylaştırmak için Contoso iş yükünü ve giriş denetleyicisi 'ni çalıştırır. iş yükü basit bir ASP.NET uygulamasıdır.

Ek bilgi için, Azure 'Da Merkez-uç ağ topolojisi.

IP adreslerini planlayın

Sanal ağın adres alanı tüm alt ağları tutabilecek kadar büyük olmalıdır. Trafik alacak tüm varlıkların hesabı. Bu varlıkların IP adresleri alt ağ adres alanından ayrılacaktır. Bu noktaları göz önünde bulundurun.

• Yükseltme

  AKS, temel sanal makinelerin güvenlik özellikleri ve diğer sistem yamaları üzerinde güncel olduğundan emin olmak için düğümleri düzenli olarak güncelleştirir. Bir yükseltme işlemi sırasında, AKS,, yükseltme düğümü ele alınan ve boşaltılmış olsa da, daha geçici olarak ana bilgisayarları barındıran bir düğüm oluşturur. Bu geçici düğüme, küme alt ağından bir IP adresi atanır.

  Pods için stratejinize bağlı olarak ek adreslere gerek duyabilirsiniz. Sıralı güncelleştirmeler için, gerçek yığınların güncelleştirildiği sırada iş yükünü çalıştıran geçici FID 'ler için adreslere ihtiyacınız vardır. Değiştirme stratejisini kullanırsanız, Pod kaldırılır ve yenilerini oluşturulur. Bu nedenle, eski Pod ile ilişkili adresler yeniden kullanılır.

• Ölçeklenebilirlik

  Tüm sistem ve Kullanıcı düğümlerinin düğüm sayısını ve en yüksek ölçeklenebilirlik sınırını dikkate alın. Ölçeği %400 oranında genişletmek istediğinizi varsayalım. Tüm bu genişleme düğümlerinin dört katı olması gerekir.

  Bu mimaride, her Pod 'a doğrudan bağlantı kurulabilirler. Bu nedenle, her Pod tek bir adrese ihtiyaç duyuyor. Pod ölçeklenebilirliği, adres hesaplamasını etkiler. Bu karar, büyütmek istediğiniz sayıda Pod 'nin seçimine bağlı olarak değişir.

• Azure özel bağlantı adresleri

  Özel bağlantı üzerinden diğer Azure hizmetleriyle iletişim için gereken adreslerdeki faktör. Bu mimaride, Azure Container Registry ve Key Vault bağlantıları için atanan iki adres vardır.

• Belirli adresler Azure tarafından kullanılmak üzere ayrılmıştır. Bunlar atanamaz.

Yukarıdaki liste ayrıntılı değildir. Tasarımınızda kullanılabilir IP adresi sayısını etkileyecek diğer kaynaklar varsa, bu adreslere uyum sağlayacak.

Bu mimari, tek bir iş yükü için tasarlanmıştır. Birden çok iş yükü için, Kullanıcı düğümü havuzlarını birbirinden ve sistem düğüm havuzundan yalıtmak isteyebilirsiniz. Bu seçenek, boyutu daha küçük olan alt ağların oluşmasına neden olabilir. Ayrıca, giriş kaynağı daha karmaşık olabilir. Ek adresler gerektirecek birden çok giriş denetleyicisi gerekebilir.

Bu mimariye yönelik tüm önemli noktalar için bkz. aks taban çizgisi ağ topolojisi.

Bir AKS kümesinin planlama IP 'si ile ilgili bilgiler için bkz. kümeniz IÇIN IP adreslemeplanlama.

Kapsayıcı görüntüsü başvurusu

İş yüküne ek olarak, küme, giriş denetleyicisi gibi çeşitli diğer görüntüler içerebilir. Bu görüntülerden bazıları ortak kayıt defterlerinde bulunabilir. Bunları kümenize çekmeden bu noktaları göz önünde bulundurun.

• Görüntüyü çekmek için kümenin kimliği doğrulanır.

• Ortak görüntü kullanıyorsanız, SLO 'iyle hizalanan kapsayıcı Kayıt defterinize içeri aktarmayı göz önünde bulundurun. Aksi halde, görüntü beklenmeyen kullanılabilirlik sorunlarına tabi olabilir. Bu sorunlar, ihtiyacınız olduğunda görüntü kullanılamazsa işlem sorunlarına neden olabilir. Ortak kayıt defteri yerine kapsayıcı kayıt defterinizi kullanmanın bazı avantajları aşağıda verilmiştir:

  • Görüntülerinize yetkisiz erişimi engelleyebilirsiniz.
  • Genel kullanıma açık bağımlılıklara sahip kalmazsınız.
  • Etkinlikleri izlemek ve bağlantı sorunlarını önceliklendirme için görüntü çekme günlüklerine erişebilirsiniz.
  • Tümleşik kapsayıcı taraması ve görüntü uyumluluğuna yararlanın.

  Bir seçenek Azure Container Registry (ACR).

• Yetkili kayıt defterlerinden görüntüleri çekin. Bu kısıtlamayı Azure Ilkesi aracılığıyla uygulayabilirsiniz. Bu başvuru uygulamasında, küme yalnızca mimarinin bir parçası olarak dağıtılan ACR 'den görüntüler çeker.

Temel küme için işlem yapılandırma

AKS 'de, her düğüm havuzu bir sanal makine ölçek kümesiyle eşlenir. Düğümler her düğüm havuzundaki sanal makinelerlerdir. Maliyetleri en aza indirmek için sistem düğümü havuzu için daha küçük bir VM boyutu kullanmayı düşünün. Bu başvuru uygulamasının sistem düğüm havuzunu üç DS2_v2 düğümü ile dağıtır. Bu boyut, sistem kimliklerinin beklenen yükünü karşılamak için yeterlidir. İşletim sistemi diski 512 GB 'tır.

Kullanıcı düğümü havuzu için bazı konular aşağıda verilmiştir:

• Bir düğümde ayarlanan maksimum sayıda Pod 'yi paketetmek için daha büyük düğüm boyutları seçin. İzleme ve günlüğe kaydetme gibi tüm düğümlerde çalışan hizmetlerin parmak izini en aza indirir.

• En az iki düğüm dağıtın. Bu şekilde, iş yükünün iki çoğaltma ile yüksek kullanılabilirlik düzenine sahip olması gerekir. AKS ile, küme yeniden oluşturmadan düğüm sayısını değiştirebilirsiniz.

• İş yükünüz için gerçek düğüm boyutları, tasarım ekibi tarafından belirlenen gereksinimlere bağlı olarak değişir. İş gereksinimlerine bağlı olarak, üretim iş yükü için DS4_v2 seçtik. Maliyetleri düşürmek için, en düşük öneri olan DS3_v2 boyutu düşürülemiyor.

• Kümeniz için kapasite planlama yaparken, iş yükünüzün her bir düğümün %80 ' e kadar kullanılabilir olduğunu varsayın; kalan %20, AKS Hizmetleri için ayrılmıştır.

• Kapasite planlamasına göre düğüm başına maksimum Pod 'yi ayarlayın. Kapasite temeli oluşturmaya çalışıyorsanız, 30 değeriyle başlayın. İş yükünün gereksinimlerine, düğüm boyutuna ve IP kısıtlamalarınızın gereksinimlerine göre bu değeri ayarlayın.

küme için Azure Active Directory tümleştirin

Kümeye ve kümeden erişimin güvenliğini sağlamak önemlidir. Güvenlik seçimi yaparken kümenin perspektifinden düşünün:

• İç erişim. Ağ altyapısı, Azure Container Registry ve Azure Key Vault gibi Azure bileşenlerine erişim. Yalnızca kümenin erişime izin verilen kaynakları yetkilendirin.
• Dışarıdan erişim. Kubernetes kümesine kimlikler erişimi sağlama. Yalnızca Kubernetes API sunucusuna ve Azure Resource Manager erişimine izin verilen dış varlıkları yetkilendirin.

Azure 'a yönelik AKS erişimi

Azure Active Directory (azure AD) aracılığıyla azure erişimi ile aks 'leri yönetmenin iki yolu vardır: azure kaynakları içinhizmet sorumluları veya yönetilen kimlikler.

İki şekilde yönetilen kimlikler önerilir. Hizmet sorumluları sayesinde, el ile veya program aracılığıyla gizli dizileri yönetme ve döndürme konusunda siz sorumlusunuz. Yönetilen kimlikler sayesinde, Azure AD kimlik doğrulamasını yönetir ve gerçekleştirir ve gizli dizileri sizin için zamanında döndürmektedir.

Kümenin Azure AD aracılığıyla dış Azure kaynaklarıyla etkileşime girebilmesi için yönetilen kimliklerin etkinleştirilmesi önerilir. Bu ayarı, yalnızca küme oluşturma sırasında etkinleştirebilirsiniz. Azure AD hemen kullanılmıyor olsa bile, daha sonra ekleyebilirsiniz.

İç içe bir örnek olarak, kümenin bir kapsayıcı kayıt defterinden görüntü çekmek gerektiğinde yönetilen kimliklerin kullanımını incelim. Bu eylem, kümenin kayıt defteri kimlik bilgilerini almasını gerektirir. Bu bilgiler, bu bilgileri Kubernetes gizli nesneleri biçiminde depolamanız ve imagePullSecrets gizli anahtarı almak için kullanmaktır. Güvenlik karmaşıklıkları nedeniyle bu yaklaşım önerilmez. yalnızca gizlilik bilgisine ve ayrıca DevOps işlem hattı aracılığıyla bu gizliliğe göz duymasına gerek kalmaz. Diğer bir nedenden dolayı, gizli anahtar dönüşü yönetiminin işletimsel bir yükü vardır. Bunun yerine, acrPull Kayıt defterinize kümenin yönetilen kimliğine erişim izni verin. Bu yaklaşım bu kaygılara yöneliktir.

Bu mimaride, küme Azure AD tarafından güvenliği sağlanan Azure kaynaklarına erişir ve yönetilen kimlikleri destekleyen işlemler gerçekleştirir. Kümenin tarafından gerçekleştirilen işlemlere bağlı olarak kümenin yönetilen kimliklerine Azure rol tabanlı erişim denetimi (Azure RBAC) ve izinleri atayın. Küme, Azure AD 'de kimliğini doğrular ve ardından atandığı rollere göre erişime izin verilir veya erişim engellenir. Bu başvuru uygulamasından Azure yerleşik rollerinin kümeye atandığı bazı örnekler aşağıda verilmiştir:

• Ağ katılımcısı. Kümenin bağlı sanal ağı denetleme özelliği. Bu rol ataması, AKS küme sistemi tarafından atanan kimliğin Iç giriş denetleyicisi Hizmetleri için ayrılmış alt ağ ile çalışmasına izin verir.
• Izleme ölçümleri Publisher. Kümenin Azure Izleyicisine ölçüm gönderme yeteneği.
• Acrpull. Kümenin, belirtilen Azure Container kayıt defterlerinden görüntüleri çekme yeteneği.

Küme erişimi

Azure AD tümleştirmesi, dışarıdan erişim için güvenliği de basitleştirir. Bir kullanıcının kubectl kullanmak istediğini varsayalım. İlk adım olarak, az aks get-credentials kümenin kimlik bilgilerini almak için komutunu gönderir. Azure AD, kullanıcının kimliğinin küme kimlik bilgilerini almaya izin verilen Azure rollerine karşı kimliğini doğrular. Daha fazla bilgi için bkz. kullanılabilir küme rolleri izinleri.

aks, Azure Active Directory kullanarak kubernetes erişimine iki şekilde izin verir. ilki, yerel kubernetes RBAC sistemiyle tümleştirilmiş bir kimlik sağlayıcısı olarak Azure Active Directory kullanıyor. Diğeri, küme erişimini denetlemek için yerel Azure RBAC kullanıyor. Her ikisi de aşağıda ayrıntılı olarak verilmiştir.

Kubernetes RBAC 'yi Azure Active Directory ilişkilendir

Kubernetes rol tabanlı erişim denetimi 'ni (RBAC) şu şekilde destekler:

• Bir izin kümesi. Küme genelinde Role izinler ClusterRole için bir veya nesnesi tarafından tanımlanır.

• Eylemleri yapmalarına izin verilen kullanıcıları ve grupları atayın bağlamalar. Bir veya nesnesi RoleBinding tarafından CluserRoleBinding tanımlanır.

Kubernetes'in küme yöneticisi, düzenleme, görüntüleme gibi bazı yerleşik rolleri vardır. Bu rolleri, erişimi Azure Active Directory için kurumsal dizin kullanmak üzere kullanıcılara ve gruplara bağlayın. Daha fazla bilgi için bkz. Azure AD tümleştirmesi ile Kubernetes RBAC kullanma.

Küme ve ad alanı erişimi için kullanılan Azure AD gruplarınızı Azure AD erişim incelemelerine dahil edin.

Kubernetes Yetkilendirmesi için Azure RBAC kullanma

Kubernetes RBAC'yi tümleşik AAD kimlik doğrulamasıyla kullanmak yerine, küme erişimini zorlamak için Azure RBAC ve Rol atamalarını kullanmak başka bir seçenektir. Azure RBAC kullanmanın avantajı, yerel Kubernetes RBAC rollerini ve rol bağlamalarını yapılandırmanız gerekmamadır.

Daha fazla bilgi için bkz. Azure rolleri.

Yerel hesaplar

AKS, yerel Kubernetes kullanıcı kimlik doğrulamasını destekler. Bu yöntemi kullanarak kümelere kullanıcı erişimi önerlanmaz. Sertifika tabanlıdır ve birincil kimlik sağlayıcınızın dışında gerçekleştirilir; merkezi kullanıcı erişim denetimi ve idareyi zorlaştırarak. Kümenize erişimi her zaman Azure Active Directory ve kümenizi yerel hesap erişimini açıkça devre dışı bırakarak yapılandırabilirsiniz.

Bu başvuru uygulamasında, küme dağıtıldığında yerel küme hesapları üzerinden erişim açıkça devre dışı bırakılır.

İş Azure Active Directory için uygulamaları tümleştirin

Kümenin tamamı için Azure Yönetilen Kimlikleri'ne sahip olmak gibi, pod düzeyinde yönetilen kimlikler atabilirsiniz. Pod yönetilen kimliği, barındırılan iş yükünün kaynaklara doğrudan erişim Azure Active Directory. Örneğin, iş yükü dosyaları Azure Depolama. Bu dosyalara erişmesi gereken pod, kaynakta kimliğini doğrular.

Bu başvuru uygulamasında, yönetilen pod kimlikleri aad-pod-identity aracılığıyla kolaylaştırıldı.

Giriş kaynaklarını dağıtma

Kubernetes Giriş kaynakları gelen trafiği kümeye yönlendirer ve dağıtır. Giriş kaynaklarının iki bölümü vardır:

• İç yük dengeleyici. AKS tarafından yönetilir. Bu yük dengeleyici, giriş denetleyicisini özel bir statik IP adresi aracılığıyla gösterir. Gelen akışları alan tek bir iletişim noktası olarak görev alır.

  Bu mimaride Azure Load Balancer kullanılır. Giriş kaynakları için ayrılmış bir alt ağda kümenin dışına yerleştirilir. Trafiği trafikten alır Azure Application Gateway iletişim TLS üzerindendir. Gelen trafik için TLS şifrelemesi hakkında bilgi için bkz. Giriş trafik akışı.

• Giriş denetleyicisi. Traefik'i seçtik. Kümedeki kullanıcı düğümü havuzunda çalışır. İç yük dengeleyiciden trafik alır, TLS'yi sonlandırılır ve HTTP üzerinden iş yükü podlarına iletir.

Giriş denetleyicisi, kümenin kritik bir bileşenidir. Bu bileşeni yapılandırarak bu noktaları göz önünde bulundurarak.

• Tasarım kararlarının bir parçası olarak, giriş denetleyicisinin çalışmasına izin verilen bir kapsam seçin. Örneğin, denetleyicinin yalnızca belirli bir iş yükünü çalıştıran podlarla etkileşim kurmasına izin veabilirsiniz.

• Yükü yaymak ve bir düğüm kapatıyorsa iş sürekliliğini sağlamak için çoğaltmaları aynı düğüme yerleştirmekten kaçının. Bu podAntiAffinity amaçla kullanın.

• kullanarak podları yalnızca kullanıcı düğümü havuzunda zamanlanacak şekilde nodeSelectors kısıtla. Bu ayar iş yükünü ve sistem podlarını yalıtır.

• Belirli varlıkların giriş denetleyicisine trafik göndermesine olanak sağlayan bağlantı noktalarını ve protokolleri açın. Bu mimaride, Traefik yalnızca Azure Application Gateway.

• Giriş denetleyicisi, podların durumunu belirten sinyaller göndermeli. Belirtilen readinessProbelivenessProbe aralıkta podların sistem durumunu izlemek için ve ayarlarını yapılandırabilirsiniz.

• Giriş denetleyicisinin belirli kaynaklara erişimini ve belirli eylemleri gerçekleştirme becerisini kısıtlamayı göz önünde bulundurabilirsiniz. Bu kısıtlama Kubernetes RBAC izinleri aracılığıyla geçerli olabilir. Örneğin, bu mimaride Traefik'e Kubernetes nesnesinde kurallar kullanılarak hizmetleri ve uç noktaları izleme, almaya ve listeye ekleme izinleri ClusterRole verildi.

Yönlendirici ayarları

Giriş denetleyicisi, trafiğin nereye gönderllr olduğunu belirlemek için yolları kullanır. Yollar, trafiğin alın aldığı kaynak bağlantı noktasını ve hedef bağlantı noktaları ve protokoller hakkında bilgileri belirtir.

Bu mimariden bir örnek şu şekildedir:

Traefik yolları yapılandırmak için Kubernetes sağlayıcısını kullanır. annotations, tls ve entrypoints yolların HTTPS üzerinden hizmet olacağını gösterir. yalnızca middlewares alt ağdan gelen trafiğe Azure Application Gateway olduğunu belirtir. İstemci kabul ederse yanıtlar gzip kodlamasını kullanır. Traefik TLS sonlandırması yaptığı için arka uç hizmetleriyle iletişim HTTP üzerinden uzer.

apiVersion:networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

Ağ akışının güvenliğini sağlama

Bu bağlamda ağ akışı şu şekilde kategorilere ayrılmıştır:

• Giriş trafiği. İstemciden kümede çalışan iş yüküne.

• Egress trafiği. Kümedeki bir poddan veya düğümden dış hizmete.

• Poddan poda trafik. Podlar arasındaki iletişim. Bu trafik, giriş denetleyicisi ile iş yükü arasındaki iletişimi içerir. Ayrıca, iş yükünüz kümeye dağıtılan birden çok uygulamadan oluşursa, bu uygulamalar arasındaki iletişim bu kategoriye girer.

• Yönetim trafiği. İstemci ile Kubernetes API sunucusu arasında giden trafik.

Bu mimari, tüm trafik türlerinin güvenliğini sağlamak için çeşitli güvenlik katmanlarına sahiptir.

Giriş trafiği akışı

Mimari yalnızca istemciden gelen TLS şifreli istekleri kabul eder. TLS v1.2, kısıtlı bir dizi şifre ile izin verilen en düşük sürümdür. Sunucu Adı Belirtme (SNI) katı etkinleştirilir. 4.00.000 TLS, bu Application Gateway gösterildiği gibi iki farklı TLS sertifikası kullanılarak iki farklı TLS sertifikası kullanılarak özel olarak ayarlanır.

1. İstemci, etki alanı adına bir HTTPS isteği gönderir: bicycle.contoso.com. Bu ad, bir DNS A kaydı aracılığıyla ile ilişkilendirilmiş ve bu kaydın genel IP Azure Application Gateway. Bu trafik, istemci tarayıcısı ile ağ geçidi arasındaki trafiğin incelenmemesi veya değiştirilenemesi için şifrelenir.

2. Application Gateway tümleşik bir web uygulaması güvenlik duvarı (WAF) vardır ve yalnızca güvenli şifrelemelere izin vererek bicycle.contoso.com için TLS el sıkışması üzerinde anlaşma sağlar. Application Gateway, WAF inceleme kurallarını işlemesi ve trafiği yapılandırılan arka ileriye yönlendiren yönlendirme kurallarını yürütmesi gerektiğinden bir TLS sonlandırma noktasıdır. TLS sertifikası Azure Key Vault depolanır. Application Gateway ile tümleştirilmiş Kullanıcı tarafından atanan yönetilen kimlik kullanılarak erişilir. Bu özellik hakkında bilgi için bkz. Key Vault sertifikalarla TLS sonlandırma.

3. Trafik Application Gateway arka uca taşınıyor, trafik, iç yük dengeleyiciye iletilmesi sırasında başka bir TLS sertifikası (*. aks-ingress.contoso.com için joker karakter) ile yeniden şifrelenir. Bu yeniden şifreleme, güvenli olmayan trafiğin küme alt ağına akış içermediğinden emin olmanızı sağlar.

4. Giriş denetleyicisi, şifreli trafiği yük dengeleyici üzerinden alır. Denetleyici, *. aks-ingress.contoso.com için başka bir TLS sonlandırma noktasıdır ve trafiği HTTP üzerinden iş yükü ayırımlara iletir. sertifikalar Azure Key Vault depolanır ve kapsayıcı Depolama arabirimi (csı) sürücüsü kullanılarak kümeye bağlanır. Daha fazla bilgi için bkz. gizli dizi yönetimi ekleme.

Her atlamada uçtan uca TLS trafiğini, iş yükü Pod 'e kadar her bir şekilde uygulayabilirsiniz. Pod-Pod trafiğinin güvenliğini sağlama kararı verirken performansı, gecikme süresini ve işlemsel etkiyi ölçdiğinizden emin olun. Tam denetim düzlemi RBAC ve yetişkinlere yönelik yazılım geliştirme yaşam döngüsü uygulamalarına sahip çoğu tek kiracılı kümeler için, giriş denetleyicisine ve Web uygulaması güvenlik duvarı (WAF) ile koruma için TLS ile şifreleme yeterlidir. Bu, iş yükü yönetiminde yükü en aza indirir ve ağ performansı etkiler. İş yükünüz ve uyumluluk gereksinimleriniz, TLS sonlandırmasınıgerçekleştirdiğiniz yeri belirler.

Egress trafik akışı

Sıfır güvenli denetim ve trafiği İnceleme özelliği için, kümeden gelen tüm çıkış trafiği Azure Güvenlik Duvarı üzerinden geçer. Bu seçeneği, Kullanıcı tanımlı yollar (UDRs) kullanarak uygulayabilirsiniz. Yolun sonraki atlaması, Azure Güvenlik duvarının özel IP adresidir . Burada Azure Güvenlik Duvarı, çıkış trafiğinin engellenip engellenmeyeceğini veya izin verip vermeyeceğine karar verir. Bu karar, Azure Güvenlik duvarında veya yerleşik tehdit bilgileri kurallarında tanımlanan belirli kurallara dayanır.

Sıfır güvenle denetim için bir özel durum, kümenin diğer Azure kaynaklarıyla iletişim kurması gerektiği durumdur. Örneğin, kümenin kapsayıcı kayıt defterinden güncelleştirilmiş bir görüntü çekmesi gerekir. Önerilen yaklaşım, Azure özel bağlantısıkullanmaktır. Bunun avantajı, belirli alt ağların hizmete doğrudan ulaşabilme hizmetidir. Ayrıca, küme ve hizmet arasındaki trafik, genel İnternet 'e açık değildir. Daha aşağı bir, özel bağlantının, hedef hizmeti genel uç noktası üzerinden kullanmak yerine ek yapılandırma ihtiyacı vardır. Ayrıca, tüm Azure hizmetleri veya SKU 'Ları özel bağlantıyı desteklemez. Bu gibi durumlarda, hizmete erişmek için alt ağda bir hizmet uç noktası etkinleştirmeyi düşünün.

Özel bağlantı veya hizmet uç noktaları bir seçenek değilse, genel uç noktaları aracılığıyla diğer hizmetlere erişebilir ve Azure Güvenlik duvarı kuralları ve hedef hizmette yerleşik olarak bulunan güvenlik duvarı üzerinden erişimi kontrol edebilirsiniz. Bu trafik, güvenlik duvarının statik IP adresi üzerinden gideceğinden, bu adrese hizmetin IP allowlist öğesi eklenebilir. Azure Güvenlik duvarının yalnızca belirli bir alt ağdan gelen trafiğe izin verildiğinden emin olmak için ek kurallara sahip olması gerekir.

Pod-Pod trafiği

Varsayılan olarak, Pod, kümedeki diğer Pod 'lerden gelen trafiği kabul edebilir. Kubernetes NetworkPolicy , Pod 'ler arasındaki ağ trafiğini kısıtlamak için kullanılır. İlkeleri uygulama bozacağından, aksi takdirde kritik bir ağ akışının engellediği bir duruma sahip olabilirsiniz. Giriş denetleyicisi ve iş yükü arasındaki trafik gibi yalnızca gerektiğinde belirli iletişim yollarına izin verin. Daha fazla bilgi için bkz. ağ ilkeleri.

Daha sonra eklenemediği için, küme sağlandığında ağ ilkesini etkinleştirin. Uygulayan teknolojiler için birkaç seçenek vardır NetworkPolicy . Azure Container Network Interface (CNı) gerektiren Azure ağ Ilkesi önerilir, aşağıdaki nota bakın. Diğer seçenekler de bilinen bir açık kaynak seçeneği olan Calıco ağ Ilkesini içerir. Küme genelinde ağ ilkelerini yönetmeniz gerekiyorsa Calıco 'yi düşünün. Calico standart Azure desteği kapsamında değildir.

Daha fazla bilgi için bkz. Azure ağ ilkesi Ile Calıco ilkeleri ve bunların özellikleri arasındaki farklar.

Yönetim trafiği

Küme çalıştırmanın bir parçası olarak Kubernetes API sunucusu, küme üzerinde yönetim işlemleri yapmak isteyen kaynaklardan (örneğin, kaynak oluşturma veya kümeyi ölçeklendirme istekleri) trafik alır. bu kaynaklara örnek olarak, DevOps işlem hattında derleme aracısı havuzunu, savunma alt ağını ve düğüm havuzlarını içerir. Tüm IP adreslerinden bu yönetim trafiğini kabul etmek yerine, yalnızca yetkilendirilmiş IP aralıklarından API sunucusuna giden trafiğe izin vermek için AKS 'in yetkilendirilmiş IP aralıkları özelliğini kullanın.

Daha fazla bilgi için bkz. API sunucusu YETKILENDIRILMIŞ IP aralıklarını tanımlama.

Gizli dizi yönetimi ekleme

Gizli dizileri, Azure Key Vault gibi bir yönetilen anahtar deposunda depolayın. Avantaj, yönetilen deponun gizli dizileri döndürmesini, güçlü şifreleme sağladığını, bir erişim denetim günlüğü sağlar ve temel gizli dizileri dağıtım ardışık düzeninin dışında tutar.

Azure Key Vault, diğer Azure hizmetleriyle birlikte iyi tümleşiktir. Gizli dizileri erişmek için bu hizmetlerin yerleşik özelliğini kullanın. Azure Application Gateway giriş akışı için TLS sertifikalarına nasıl eriştiği hakkında bir örnek için, giriş trafiği akışı bölümüne bakın.

Küme gizli dizileri

Pod 'un belirli bir mağazadan gizli anahtarlara erişmesine izin vermek için pod tarafından yönetilen kimlikler kullanmanız gerekir.

Alma işlemini kolaylaştırmak için, bir gizlilikler mağaza CSI sürücüsükullanın. Pod, bir gizli dizi gerektiğinde, sürücü belirtilen mağazaya bağlanır, bir birimde gizli dizi alır ve bu birimi kümeye bağlar. Pod daha sonra birim dosya sisteminden gizli dizi alabilir.

CSı sürücüsünde, çeşitli yönetilen mağazaları desteklemek için birçok sağlayıcı vardır. Bu uygulamada, TLS sertifikasını Azure Key Vault almak ve giriş denetleyicisini çalıştıran Pod 'a yüklemek için gizli dizileri deposu CSI sürücüsü ile Azure Key Vault seçtik. Pod oluşturma sırasında yapılır ve birim hem genel hem de özel anahtarları depolar.

İş yükü depolaması

Bu mimaride kullanılan iş yükü durum bilgisiz. Durumu depolamanız gerekiyorsa, kümenin dışından kalıcı hale getirmeniz önerilir. İş yükü durumu için rehberlik, bu makalenin kapsamı dışındadır.

depolama seçenekleri hakkında daha fazla bilgi edinmek için bkz. Azure kubernetes Service (aks) içindeki uygulamalar için Depolama seçenekleri.

İlke yönetimi

AKS kümesini yönetmenin etkili bir yolu, ilkeler aracılığıyla idare zorlamaya göre yapılır. Kubernetes, OPA Gatekeeper aracılığıyla ilkeleri uygular. AKS için, ilkeler Azure Ilkesi aracılığıyla dağıtılır. Her ilke, kapsamındaki tüm kümelere uygulanır. Azure Ilke zorlaması, sonunda kümede OPA Gatekeeper tarafından işlenir ve tüm ilke denetimleri günlüğe kaydedilir. İlke değişiklikleri kümenize hemen yansıtılmaz. Birkaç gecikme görmeniz beklenir.

İlkeleri ayarlarken, iş yükünün gereksinimlerine göre bunları uygulayın. Şu faktörleri göz önünde bulundurun:

• Bir ilke koleksiyonu (girişim olarak adlandırılır) ayarlamak veya ayrı ilkeler seçmek ister misiniz? Azure Ilkesi, iki yerleşik girişim sağlar: temel ve kısıtlı. Her girişim, bir AKS kümesi için geçerli olan yerleşik ilkelerin koleksiyonudur. Kuruluşunuzun gereksinimlerine göre, bir girişim ve küme için ek ilkeler (acr, Application Gateway, Key Vault ve diğerleri) seçin ve bu seçim yapmanız önerilir.

• Eylemi denetlemek veya reddetmek ister misiniz? Denetim modunda eyleme izin verilir, ancak uyumludeğil olarak işaretlenir. Düzenli bir temposunda uyumlu olmayan durumları kontrol etmek ve gerekli işlemleri yapmak için süreçler vardır. Reddetme modunda, ilke ihlal edildiği için eylem engellendi. İş yükünün çalışması için çok kısıtlayıcı olabileceğinden, bu modu seçerken dikkatli olun.

• İş yükünüzün tasarım ile uyumlu olmaması gereken alanlara sahip misiniz? Azure Ilkesinde, ilke zorlamada muaf tutulan Kubernetes ad alanlarını belirtme özelliği vardır. Bu örneklerden haberdar olmak için ilkeleri Denetim modunda uygulamanız önerilir.

• Yerleşik ilkeler kapsamında olmayan gereksinimleriniz var mı? Nadir durumlarda, özel OPA Gatekeeper ilkelerinize uygulanan özel bir Azure Ilke tanımı oluşturun. İlkeleri doğrudan kümeye uygulamayın.

• Kuruluş genelinde gereksinimleriniz var mı? Bu durumda, bu ilkeleri yönetim grubu düzeyinde ekleyin. Ayrıca, kuruluşunuz genel ilkelere sahip olsa bile kümenizin kendi iş yüküne özgü ilkelerini ataması gerekir.

• Azure ilkeleri belirli kapsamlara atanır. Üretim ilkelerinin aynı zamanda üretim öncesi ortamınız için de doğrulanıp doğrulanması güvence altına alınır. Aksi takdirde, üretim ortamınıza dağıtım yaparken, ön üretimde ' de hesaba katılmış olmayan beklenmeyen ek kısıtlamalara de karşılaşabilirsiniz.

Bu başvuru uygulamasında, AKS kümesi oluşturulduğunda Azure Ilkesi etkinleştirilir ve uyumlu olmayan bir görünürlük elde etmek için Denetim modunda kısıtlayıcı girişimi atar.

Uygulama, yerleşik girişimlerin parçası olmayan ek ilkeler de ayarlar. Bu ilkeler reddetme modunda ayarlanır. Örneğin, görüntülerin yalnızca dağıtılan ACR 'den çekildiğinizden emin olmak için bir ilke vardır. Kendi özel girişimlerinizi oluşturmayı düşünün. İş yükünüz için geçerli olan ilkeleri tek bir atamaya birleştirin.

Azure ilkesinin kümenizin içinden nasıl çalıştığını gözlemlemek için, ad alanındaki tüm yığınların Pod günlüklerine gatekeeper-systemazure-policy ve ad alanındaki ve pod için günlüklere erişebilirsiniz azure-policy-webhookkube-system .

Düğüm ve pod ölçeklenebilirliği

Artan talebe sahip Kubernetes, yatay Pod otomatik ölçeklendirme (HPA) aracılığıyla mevcut düğümlere daha fazla sayıda düğüm ekleyerek ölçeği değiştirebilir. Ek düğüm artık zamanlanmamışsa, AKS kümesi otomatik ölçeklendirmesiyle düğümlerin sayısı arttırılabiliyor olmalıdır. Eksiksiz ölçekleme çözümünün hem Pod çoğaltmaları hem de kümedeki düğüm sayısını ölçeklendirmeye yönelik yolları olmalıdır.

İki yaklaşım vardır: otomatik ölçeklendirme veya el ile ölçekleme.

El ile veya programlama yolu, CPU kullanımı veya özel ölçümler üzerinde uyarıları izlemenizi ve ayarlamanızı gerektirir. Pod ölçeklendirme için, uygulama işleci, ReplicaSet Kubernetes API 'lerini ayarlayarak Pod çoğaltmaları sayısını artırabilir veya azaltabilir. Küme ölçekleme için, Kubernetes Scheduler başarısız olduğunda bildirim almak bir yoldur. Diğer bir yol da zaman içinde bekleyen Pod 'leri izlemek içindir. Düğüm sayısını Azure CLı veya portalı aracılığıyla ayarlayabilirsiniz.

Otomatik ölçeklendirme, bu manuel mekanizmalardan bazıları otomatik Scaler içinde yerleşik olduğundan yaklaşım yaklaşımıdır.

Genel bir yaklaşım olarak en az sayıda Pod ve düğüm ile performans testi ile başlayın. Taban çizgisi beklentisini oluşturmak için bu değerleri kullanın. Daha sonra performans ölçümlerinin ve el ile ölçeklendirmenin bir birleşimini kullanarak performans sorunlarını belirleyip uygulamanın ölçeklendirilmesine yönelik yanıtını anlayın. Son olarak, bu verileri otomatik ölçeklendirme parametrelerini ayarlamak için kullanın. AKS kullanan bir performans ayarlama senaryosu hakkında daha fazla bilgi için bkz. performans ayarlama senaryosu: dağıtılmış iş işlemleri.

Yatay Pod Otomatik Ölçeklendiricisi

Yatay Pod otomatik Scaler (hPa), düğüm sayısını ölçeklendirilen bir Kubernetes kaynağıdır.

HPA kaynağında, en düşük ve en yüksek çoğaltma sayısını ayarlamak önerilir. Bu değerler, otomatik ölçeklendirme sınırlarını kısıtlar.

HPA CPU kullanımı, bellek kullanımı ve özel ölçümlere göre ölçeklendirebilir. Yalnızca CPU kullanımı kullanıma sunulmuştur. Horizontalpodadutoscaler tanımı, bu ölçümler için hedef değerleri belirtir. Örneğin, spec bir hedef CPU kullanımı belirler. Pod çalışırken, hPa denetleyicisi her Pod 'ın CPU kullanımını denetlemek için Kubernetes ölçümleri API 'sini kullanır. Bu değeri hedef kullanımyla karşılaştırır ve bir oranı hesaplar. Daha sonra, IP 'lerin fazla yüklenmiş mi yoksa az ayrılmış mi olduğunu belirleme oranını kullanır. Düğümlere yeni Pod atamak veya düğümlerden düğüm kaldırmak için Kubernetes zamanlayıcısını kullanır.

Bir ölçeklendirme işlemi tamamlanmadan önce (HPA) denetlediği bir yarış durumu olabilir. Sonuç yanlış bir oran hesaplaması olabilir. Ayrıntılar için bkz. ölçeklendirme olaylarının cooli.

İş yükünüz olay odaklı ise, popüler bir açık kaynak seçeneği Kedaolur. İş yükünüz CPU veya bellek sınırı yerine ileti kuyruğu gibi bir olay kaynağı tarafından yönlendiriliyorsa KEDA 'YU düşünün. KEDA birçok olay kaynağını (veya scalers) destekler. Desteklenen KEDA scalers listesini Azure izleyici Scalerdahil olmak üzere burada bulabilirsiniz. Azure Izleyici ölçümlerine göre KEDA iş yüklerini ölçeklendirmenin kolay bir yolu.

Küme otomatik Scaler

Küme otomatik yüklemesi , düğüm havuzundaki düğüm sayısını ölçeklendirilen bir aks eklenti bileşenidir. Küme sağlama sırasında eklenmelidir. Her Kullanıcı düğüm havuzu için ayrı bir küme otomatik Scaler gerekir.

Küme otomatik Scaler, Kubernetes Zamanlayıcı tarafından tetiklenir. Kubernetes Zamanlayıcı, kaynak kısıtlamaları nedeniyle Pod 'yi zamanlayamazsa, otomatik olarak düğüm havuzunda otomatik olarak yeni bir düğüm sağlar. Buna karşılık, küme otomatik Scaler, düğümlerin kullanılmayan kapasitesini denetler. Düğüm beklenen bir kapasitede çalışmıyorsa, düğüm başka bir düğüme taşınır ve kullanılmayan düğüm kaldırılır.

Otomatik Scaler 'ı etkinleştirdiğinizde, en yüksek ve en düşük düğüm sayısını ayarlayın. Önerilen değerler, iş yükünün performans beklentiine, kümenin ne kadar büyümesini istediğinize ve maliyet etkilerine bağlıdır. Minimum sayı, bu düğüm havuzu için ayrılmış kapasitedir. Bu başvuru uygulamasında, iş yükünün basit doğası nedeniyle en düşük değer 2 olarak ayarlanır.

Sistem düğüm havuzu için önerilen en düşük değer 3 ' dür.

İş sürekliliği kararları

İş sürekliliği sağlamak için altyapı ve uygulamanız için Hizmet Düzeyi Sözleşmesi tanımlayın. Aylık çalışma süresi hesaplaması hakkında daha fazla bilgi için bkz. Azure Kubernetes hizmeti (AKS) Için SLA.

Küme düğümleri

İş yükleri için en düşük kullanılabilirlik düzeyini karşılamak üzere bir düğüm havuzunda birden çok düğüm gerekir. Düğüm kapalıysa, aynı kümedeki düğüm havuzundaki başka bir düğüm uygulamayı çalıştırmaya devam edebilir. Güvenilirlik için, sistem düğüm havuzu için üç düğüm önerilir. Kullanıcı düğümü havuzu için, en az iki düğüm olmadan başlatın. Daha yüksek kullanılabilirlik gerekiyorsa daha fazla düğüm sağlayın.

Uygulamanızı sistem hizmetlerinden ayrı bir düğüm havuzuna yerleştirerek yalıtın. Bu şekilde, Kubernetes Hizmetleri adanmış düğümlerde çalışır ve iş yükünüz ile rekabet etmenize yol kalmaz. İş yükünüzü zamanlamak üzere düğüm havuzunu tanımlamak için etiketlerin, etiketlerin ve taklarınızın kullanılması önerilir.

Kümenizin düzenli olarak güncel tutulması, güvenilirlik açısından önemlidir. Ayrıca, yoklamaların sistem durumunu yoklamalar üzerinden izleme önerilir.

Pod kullanılabilirliği

Pod kaynaklarını sağlayın. Dağıtımların Pod kaynak gereksinimlerini belirtmesi kesinlikle önerilir. Zamanlayıcı daha sonra Pod 'yi uygun şekilde zamanlayabilir. Pod zamanlanmamışsa güvenilirlik önemli ölçüde kullanımdan kaldırılır.

Pod kesintisi bütçelerini ayarlayın. Bu ayar, bir dağıtım içindeki kaç yinelemenin bir güncelleştirme veya yükseltme olayı sırasında nasıl dönebileceğini belirler. Daha fazla bilgi için bkz. Pod kesintisi bütçeleri.

Donanım arızaları gibi kesintileri işlemek için dağıtımda birden çok kopya yapılandırın. Güncelleştirmeler ve yükseltmeler gibi planlı olaylar için, bir kesinti bütçesi beklenen uygulama yükünü işlemek için gereken Pod çoğaltmaları sayısını güvence altına alabilir.

İş yükü ad alanlarında kaynak kotalarını ayarlayın. Bir ad alanındaki kaynak kotası, Pod isteklerinin ve limitlerin bir dağıtımda doğru şekilde ayarlanmış olmasını sağlayacaktır. Daha fazla bilgi için bkz. kaynak kotalarını zorlama.

Pod isteklerini ve sınırlarını ayarlayın. Bu sınırları ayarlamak Kubernetes 'in, düğüm üzerinde CPU ve veya bellek kaynaklarını verimli bir şekilde ayırmasını ve bir düğümde daha yüksek kapsayıcı yoğunluğu olmasını sağlar. Daha iyi donanım kullanımı nedeniyle sınırlar, daha düşük maliyetlerle güvenilirliği de artırabilir.

Sınırları tahmin etmek için, test edin ve bir taban çizgisi oluşturun. İstekler ve sınırlar için eşit değerlerle başlayın. Daha sonra, kümede kararsızlık oluşmasına neden olabilecek bir eşik oluşturuluncaya kadar bu değerleri aşamalı olarak ayarlayın.

Bu sınırlar, dağıtım bildirimlerinde belirlenebilir. Daha fazla bilgi için bkz. Pod isteklerini ve sınırlarını ayarlama.

Kullanılabilirlik alanları ve çok bölgeli destek

SLA 'niz daha yüksek bir çalışma süresi gerektiriyorsa, bir bölgedeki kaybına karşı koruma altına alın. Bölge bunları destekliyorsa kullanılabilirlik bölgelerini kullanabilirsiniz. Hem denetim düzlemi bileşenleri hem de düğüm havuzlarındaki düğümler bölgeler arasında yayılabilir. Tüm bölge kullanılamıyorsa, bölgedeki başka bir bölgedeki bir düğüm hala kullanılabilir olur. Her düğüm havuzu, düğüm örneklerini ve ölçeklenebilirliği yöneten ayrı bir sanal makine ölçek kümesiyle eşlenir. Ölçek kümesi işlemleri ve yapılandırması AKS hizmeti tarafından yönetilir. Çoklu bölge 'yi etkinleştirirken bazı konular aşağıda verilmiştir:

• Tüm altyapı. Kullanılabilirlik alanlarını destekleyen bir bölge seçin. Daha fazla bilgi için bkz. sınırlamalar ve bölge kullanılabilirliği. Çalışma süresi SLA 'Sı satın almak istiyorsanız, bu seçeneği destekleyen bir bölge seçin. Kullanılabilirlik alanları kullanılırken çalışma süresi SLA 'Sı daha fazladır.

• Küme. Kullanılabilirlik alanları yalnızca düğüm havuzu oluşturulduğunda ayarlanabilir ve daha sonra değiştirilemez. Beklenen dağıtımın mümkün olması için tüm bölgelerde düğüm boyutları desteklenmelidir. Temel sanal makine ölçek kümesi, bölgeler arasında aynı donanım yapılandırmasını sağlar.

  Çoklu bölge desteği yalnızca düğüm havuzları için geçerli değildir, ancak denetim düzlemi de vardır. AKS denetim düzlemi, düğüm havuzları gibi istenen bölgeleri yayacaktır. Kümenizde bölge desteği kullanmıyorsanız, denetim düzlemi bileşenlerinin kullanılabilirlik alanları arasında yayılmasının garantisi yoktur.

• Bağımlı kaynaklar. Tüm hizmet bağımlılıklarının, tüm kullanım açısından da aynı zamanda bölgeleri desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bir bölge hatası hizmetin başarısız olmasına neden olabilir.

Örneğin, yönetilen bir disk, sağlandığı bölgede kullanılabilir. Bir hata olması durumunda, düğüm başka bir bölgeye geçebilir, ancak yönetilen disk bu bölgeye düğüm ile birlikte hareket edemezler.

Kolaylık olması için, Bu mimaride AKS, 1, 2 ve 3. kullanılabilirlik bölgelerini kapsayan düğüm havuzlarının bulunduğu tek bir bölgeye dağıtılır. Azure Güvenlik Duvarı ve Application Gateway gibi altyapının diğer kaynakları da çoklu bölge desteğiyle aynı bölgeye dağıtılır. Coğrafi çoğaltma Azure Container Registry için etkinleştirilmiştir.

Birden çok bölge

Tüm bölge kapalıysa kullanılabilirlik bölgelerini etkinleştirme yeterli olmayacaktır. Daha yüksek kullanılabilirlik sağlamak için, farklı bölgelerde birden çok AKS kümesi çalıştırın.

• Eşleştirilmiş bölgeleri kullanın. Bölge hatalarından kurtarmak için eşleştirilmiş bir bölge kullanmak üzere yapılandırılmış bir CI/CD işlem hattı kullanmayı düşünün. Eşlenmiş bölgeleri kullanmanın bir avantajı, güncelleştirmeler sırasında güvenilirliğe sahiptir. Azure, çiftin tek seferde yalnızca bir bölgesinin güncelleştirildiğinden emin olmanızı sağlar. flox gibi bazı DevOps araçları, çok bölgeli dağıtımları daha kolay hale getirir.

• Bir Azure kaynağı coğrafi artıklığı destekliyorsa, yedekli hizmetin ikincili olacağı konumu belirtin. Örneğin, Azure Container Registry için coğrafi çoğaltmanın etkinleştirilmesi, görüntüleri otomatik olarak seçili Azure bölgelerine çoğaltarak, bir bölgede kesinti yaşanıyorsa bile, görüntülere devam eden erişim sağlar.

• Gereksinime bağlı olarak bölgeler veya bölgeler arasında trafiği dağıtabilecek bir trafik yönlendiricisi seçin. bu mimari, web 'e ait olmayan trafiği bölgelere dağıtabilen için Azure Load Balancer dağıtır. Trafiği bölgeler arasında dağıtmanız gerekiyorsa, Azure ön kapısının kabul edilmesi gerekir. Diğer konular için bkz. yük dengeleyici seçme.

Olağanüstü Durum Kurtarma

Birincil bölgede hata olması durumunda, başka bir bölgede hızlı bir şekilde yeni bir örnek oluşturabilirsiniz. Bazı öneriler aşağıda verilmiştir:

• Eşleştirilmiş bölgeleri kullanın.

• Durum bilgisi olmayan bir iş yükü verimli bir şekilde çoğaltılabilir. Durumu kümede depolamanız gerekiyorsa (önerilmez), verileri eşleştirilmiş bölgede sık sık yedeklediğinizden emin olun.

• hizmet düzeyi hedeflerinizi (SLO) karşılamak için DevOps işlem hattının parçası olarak, başka bir bölgeye çoğaltma gibi kurtarma stratejisini tümleştirin.

• Her bir Azure hizmetini sağlarken olağanüstü durum kurtarmayı destekleyen Özellikler ' i seçin. Örneğin, Bu mimaride, Azure Container Registry coğrafi çoğaltma için etkinleştirilir. Bir bölge kapalıysa, çoğaltılan bölgeden görüntü çekmeye devam edebilirsiniz.

Kubernetes API sunucusu çalışma süresi SLA 'Sı

AKS ücretsiz bir hizmet olarak kullanılabilir, ancak bu katman mali olarak desteklenen bir SLA sunmaz. SLA 'yı edinmek için satın alımınızın bir çalışma süresi SLA 'Sı eklemeyi seçmeniz gerekir. Tüm üretim kümelerinin bu seçeneği kullanmasını öneririz. Ön üretim kümeleri için bu seçenek olmadan kümeleri ayır. Azure Kullanılabilirlik Alanları ile birleştirildiğinde, Kubernetes API sunucu SLA 'sı% 99,95 ' e yükseltilir. Düğüm havuzlarınız ve diğer kaynaklarınız kendi SLA 'Sı kapsamında ele alınmıştır.

Zorunluluğunu getirir

Mimarinin bölgeler ve özellikle bölgeler arasında dağıtımı için uygun maliyetli bir zorunluluğunu getirir vardır. Azure Container Registry coğrafi çoğaltma gibi bazı çoğaltma özellikleri Premium SKU 'Larda mevcuttur ve bu da daha pahalıdır. Trafik bölgeler ve bölgeler arasında taşınmışken uygulanan bant genişliği ücretleri de artar.

Ayrıca, bölgeler veya bölgeler arasındaki düğüm iletişiminde ek ağ gecikme süresi beklenir. Bu mimari kararının etkisini iş yükünüze göre ölçün.

Simülasyonlar ve zorlamalı yük devretme işlemleriyle test etme

Bir düğüm getirme, belirli bir bölgedeki tüm AKS kaynaklarını bir hata benzetimi yapmak veya bir dış bağımlılığı aşağı taşımak gibi sanal kesintilerle zorla yük devretme testi aracılığıyla güvenilirliğini güvence altına alın.

Ölçümleri izleme ve toplama

Olayları gerçek zamanlı olarak görüntüleyebilmeniz için, kapsayıcılar için Azure Izleyici özelliği, izleme ve günlüğe kaydetme için önerilen araçtır. Çalışan FID 'lerden kapsayıcı günlüklerini yakalar ve bunları görüntülenmek üzere toplar. Ayrıca, çalışan kaynakların ve iş yüklerinin durumunu izlemek için bellek ve CPU kullanımı hakkında ölçüm API 'sinden bilgi toplar. Performansı, Pod ölçeği olarak izlemek için kullanabilirsiniz. Başka bir avantaj de grafikleri ve panoları yapılandırmak için Azure portal kolayca kullanabilirsiniz. Otomasyon Runbook 'Larını, Azure Işlevlerini ve diğerlerini tetikleyen uyarılar oluşturma özelliğine sahiptir.

Pod 'de barındırılan iş yüklerinin çoğu, Prometheus ölçümlerini yayın. Azure Izleyici, Prometheus ölçümlerini korkutulama ve bunları görselleştirme yeteneğine sahiptir.

Kubernetes ile tümleştirilmiş bazı üçüncü taraf yardımcı programları vardır. Kuruluşunuz zaten kullanıyorsa Grafana veya Dataköpek gibi günlük ve ölçüm platformlarından yararlanın.

AKS ile Azure bazı çekirdek Kubernetes hizmetlerini yönetir. Bu hizmetlerden alınan Günlükler yalnızca müşteri desteğinden gelen istek başına etkinleştirilmelidir. Ancak, küme sorunlarını gidermenize yardımcı olabilecek bu günlük kaynaklarını etkinleştirmeniz önerilir:

• Ölçeklendirme işlemlerine Observability kazanmak için Clusterotomatik Scaler üzerinde oturum açılıyor. Daha fazla bilgi için bkz. küme otomatik Scaler günlüklerini ve durumunu alma.
• KubeControllerManager 'ın Pod Scheduler 'da Observability sahibi olması.
• KubeAuditAdmin,kümenizi değiştiren etkinliklerde gözlemlenebilirlik sağlamak için.

Kendi kendini düzeltmeyi etkinleştirme

Liveness ve Readiness yoklamalarını ayarerek podların durumunu izleme. Yanıt vermemeyen bir pod algılanırsa Kubernetes poda yeniden başlar. Canlılık araştırması pod'ların iyi olup olmadığını belirler. Yanıt vermiyorsa Kubernetes poda yeniden başlatılır. Hazır olma yoklama, pod'ın istekleri/trafiği almaya hazır olup olmadığını belirler.

Güvenlik güncelleştirmeleri

Kubernetes sürümünü desteklenen N-2 sürümleriyle güncel tutma. Kubernetes'in en son sürümüne yükseltme, yeni sürümler sık sık yayımlana kadar kritik öneme sahip.

Daha fazla bilgi için bkz. Kubernetes'in en son sürümüne düzenli olarak güncelleştirme ve Azure Kubernetes Service (AKS) kümesi yükseltme.

Kümeniz tarafından kümeniz için yeni AKS sürümü kullanılabilirliği gibi olayların bildirimi, kümeniz için AKS Sistem Konusu üzerinden Azure Event Grid. Başvuru uygulaması, olay akışı bildirim Event Grid abone olmak için bu Event Grid Microsoft.ContainerService.NewKubernetesVersionAvailable Sistem Konusunu dağıtır.

Haftalık güncelleştirmeler

AKS, en son işletim sistemi ve çalışma zamanı güncelleştirmelerini olan yeni düğüm görüntüleri sağlar. Bu yeni görüntüler otomatik olarak uygulanmaz. Görüntülerin ne sıklıkta güncelleştirilebilir gerektiğine karar vermek sizin sorumluluğundadır. Düğüm havuzlarının temel görüntüsünü haftalık olarak yükseltme işleminiz önerilir. Daha fazla bilgi için bkz. Azure Kubernetes Service (AKS) düğüm görüntüsünü yükseltme AKS Sürüm Notları.

Günlük güncelleştirmeler

Görüntü yükseltmeleri arasında AKS düğümleri işletim sistemi ve çalışma zamanı düzeltme eklerini ayrı ayrı indirip yükleyebilir. Yükleme, düğüm VM'lerini yeniden başlatmayı gerekli kılıyor olabilir. AKS bekleyen güncelleştirmeler nedeniyle düğümleri yeniden başlatmayacak. Yeniden başlatma gerektiren uygulanan güncelleştirmeler için düğümleri izleyen ve bu düğümlerin yeniden başlatma işlemini denetimli bir şekilde gerçekleştiren bir işleme sahip olun. Açık kaynak seçeneği Kured 'tir (Kubernetes reboot daemon).

Düğüm görüntülerinizi en son haftalık sürümle eşit tutmak, bu arada sırada yapılan yeniden başlatma isteklerini en aza indirerek gelişmiş bir güvenlik duruşu sağlar. Yalnızca düğüm görüntüsü yükseltmelerine bağlı olmak, AKS uyumluluğunu ve haftalık güvenlik düzeltme eki uygulama sağlar. Günlük güncelleştirmelerin uygulanması güvenlik sorunlarını daha hızlı çözecek ancak AKS'de test edilmemiştir. Mümkün olduğunca birincil haftalık güvenlik düzeltme eki uygulama stratejiniz olarak düğüm görüntüsü yükseltmesini kullanın.

Güvenliği izleme

Kapsayıcı altyapınızı hem etkin tehditler hem de olası güvenlik riskleri için izleme:

• Kubernetes kümeleriniz üzerinde tehdit algılama için Kubernetes için Microsoft Defender'ı etkinleştirin.
• Kubernetes güvenlik duruşlarını izlemek için Bulut için Microsoft Defender (Bulut için Defender) kullanın.
• AKS sanal makine konaklarına uygulanan güvenlik sağlamlaştırma hakkında bilgi için bkz. Konak işletim sisteminde Güvenlik Sağlamlaştırma.

Küme ve iş yükü işlemleri (DevOps)

Dikkat edilmesi gereken bazı noktalar buradadır. Daha fazla bilgi için operasyonel Mükemmellik sütuna bakın.

İş yükü sorumluluklarını yalıtma

Her bölümü ayrı ayrı yönetmek için iş yükünü ekiplere ve kaynak türlerine göre bölün.

Temel bileşenleri içeren temel bir iş yüküyle çalışmaya başlama ve temel bileşenler üzerinde derleme. İlk görev, ağı yapılandırmaktır. Merkez-bağlı sunucu ve alt ağlar için bu ağların içindeki sanal ağları sağlama. Örneğin, bağlı düğümün sistem ve kullanıcı düğümü havuzları ve giriş kaynakları için ayrı alt ağları vardır. Hub'da Azure Güvenlik Duvarı alt ağı.

Bir diğer bölüm de temel iş yükünü Azure Active Directory.

Kod Olarak Altyapı kullanma (IaC)

Mümkün olduğunca, bire bir yaklaşım üzerinde bir etkili bildirimsel yöntem seçin. Yapılandırma seçeneklerini belirten bir komut dizisi yazmak yerine, kaynakları ve bunların özelliklerini açıklayan bildirimsel söz dizimi kullanın. Seçeneklerden biri Azure Resource Manager (ARM) şablonlarından biri terraform'dur.

Kaynakları idare ilkelerine göre sağlarken emin olun. Örneğin, doğru VM boyutlarını seçerken, uygulama gereksinimleriyle eşleşmesi için maliyet kısıtlamaları ve kullanılabilirlik alanı seçeneklerine bağlı kalın.

Komut dizisi yazmanız gerekirse Azure CLI'sini kullanın. Bu komutlar bir dizi Azure hizmeti içerir ve betik aracılığıyla otomatik hale kullanılabilir. Azure CLI, Windows ve Linux'ta de desteklemektedir. Platformlar arası bir diğer seçenek de Azure PowerShell. Tercih ettiğiniz beceri kümesine bağlı olacaktır.

Betikleri ve şablon dosyalarını kaynak denetim sisteminize depolar ve sürümler.

İş yükü CI/CD

Pipelines ve dağıtım için uygulamaların sürekli olarak derleme ve dağıtma özelliğine sahip olması gerekir. Güncelleştirmelerin güvenli ve hızlı bir şekilde dağıtılması ve sorun olması durumunda geri alınarak dağıtılması gerekir.

Dağıtım stratejinizin güvenilir ve otomatik bir sürekli teslim (CD) işlem hattı içermesi gerekir. İş yükü kapsayıcı görüntülerinize yapılan değişiklikler kümeye otomatik olarak dağıtılacaktır.

Bu mimaride, iş akışını ve GitHub için Eylemler'i seçtik. Diğer popüler seçenekler Azure DevOps ServicesJenkins'leri içerir.

Küme CI/CD

Kubectl gibi bir yaklaşım kullanmak yerine küme ve depo değişikliklerini otomatik olarak eşitlenen araçları kullanın. Üretime dağıtmadan önce yeni bir sürümün yayımlanması ve bu sürümün doğrulanması gibi iş akışını yönetmek için bir GitOps akışını göz önünde bulundurabilirsiniz. Küme durumunun özel Git deponda depolanan yapılandırmayla eşgüdüme sahip olduğundan emin olmak için kümede bir aracı dağıtılır. Kubernetes ve AKS bu deneyimi yerel olarak desteklemez. Önerilen seçeneklerden biri, akışıdır. Kubernetes içinde dağıtımları tetiklemek için kümede bir veya daha fazla işleç kullanır. Flux şu görevleri yapar:

• Yapılandırılmış tüm depoları izler.
• Yeni yapılandırma değişikliklerini algılar.
• Dağıtımları tetikler.
• İstenen çalışan yapılandırmayı bu değişikliklere göre güncelleştirme.

Ayrıca, bu değişikliklerin nasıl dağıtılacağına yönelik ilkeler de yapabilirsiniz.

Burada, GitOps ve Flux ile küme yapılandırmasını otomatikleştirmeyi gösteren bir başvuru uygulamasından bir örnek ve ardından yer alan örnek vetir.

1. Geliştirici, bir git deposunda depolanan yapılandırma YAML dosyaları gibi değişiklikleri kaynak koda işler. Değişiklikler daha sonra git sunucusuna gönderir.

2. Flux, iş yüküyle birlikte podda çalışır. Değişikliğin yalnızca geliştiriciler tarafından istenen değişiklikleri uygulamak için git deposuna salt okunur erişimi vardır.

3. flux, yapılandırmada yapılan değişiklikleri tanır ve kubectl komutlarını kullanarak bu değişiklikleri uygular.

4. Geliştiricilerin kubectl aracılığıyla Kubernetes API'lerine doğrudan erişimi olmaz. Git sunucunuzda dal ilkelerine sahip olun. Bu şekilde, birden çok geliştirici bir değişikliği üretime uygulanmadan önce onaylar.

İş yükü ve küme dağıtım stratejileri

Herhangi bir değişikliği (mimari bileşenleri, iş yükü, küme yapılandırması) en az bir üretim öncesi AKS kümesine dağıtın. Bunu yapmak, değişikliğin benzetimini yaparak üretim ortamına dağıtmadan önce sorunları çözecek.

Güncelleştirmeleri üretim ortamına yüksek oranda denetimli bir şekilde ve beklentisiz dağıtım sorunlarından en aza indirerek emin olmak için bir sonraki aşamaya ilerlemeden önce her aşamada testler/doğrulamalar çalıştırın. Bu dağıtım, aynı GitHub Actions işlem hattı veya Flux işleçleri kullanılarak üretime benzer bir desene uymalı.

Mavi-yeşildağıtım, A/B testi ve Canarysürümü gibi gelişmiş dağıtım teknikleri, ek işlem ve potansiyel olarak araç gerektirir. Flagger, gelişmiş dağıtım senaryolarınızı çözmenize yardımcı olan popüler bir açık kaynak çözümüdür.

Maliyet yönetimi

Mimaride kullanılan hizmetlerin maliyetlerini tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın. Diğer en iyi yöntemler, Microsoft Azure Well-Architected Framework'te Maliyet İyileştirme bölümünde açıklanmıştır.

Sağlama

• Kubernetes kümesinin dağıtım, yönetim ve işlemlerinde AKS ile ilişkili bir maliyet yoktur. Ana maliyet sürücüsü, küme tarafından tüketilen sanal makine örnekleri, depolama ve ağ kaynaklarıdır. Sistem düğüm havuzları için ucuz VM 'leri seçmeyi düşünün. Önerilen SKU DS2_v2.

• Geliştirme/test ve üretim ortamları için aynı yapılandırmaya sahip değildir. Üretim iş yükleri yüksek kullanılabilirlik için ek gereksinimlere sahiptir ve daha pahalı olacaktır. Geliştirme/test ortamında gerekli olmayabilir.

• Üretim iş yükleri için bir çalışma süresi SLA 'Sı ekleyin. Ancak, kullanılabilirlik ve test için tasarlanan kümeler ya da kullanılabilirliğin garantisi olmaması gereken deneysel iş yükleri için yapılan tasarruflar vardır. Örneğin, SLO yeterlidir. Ayrıca, iş yükünüz destekliyorsa, spot VM 'leriçalıştıran adanmış spot düğüm havuzlarını kullanmayı göz önünde bulundurun.

  aks iş yükü mimarisinin bir parçası olarak Azure SQL Veritabanı veya Azure App Service içeren üretim dışı iş yükleri için, hizmet iskontoları almak üzere Azure Dev/Test abonelikleri kullanmaya uygun olup olmadığını değerlendirin.

• Ölçek ihtiyaçlarını karşılamak için büyük bir küme ile başlamak yerine, en az sayıda düğüm içeren bir küme sağlayın ve küme otomatik Scaler ' ı, boyutlandırma kararlarını izleyip yapın.

• Kubernetes 'in, donanımın kapasiteye göre kullanılabilmesi için daha yüksek yoğunluklu düğüm kaynakları ayırmasını sağlamak üzere Pod isteklerini ve sınırlarını ayarlayın.

• Kümede tanılamayı etkinleştirmek maliyeti artırabilir.

• İş yükünüzün uzun bir süre olması bekleniyorsa, düğüm maliyetlerini azaltmak için bir veya üç yıllık ayrılmış sanal makine örneğine atayabilirsiniz. Daha fazla bilgi için bkz. ayrılmış VM 'ler.

• Düğüm havuzları oluştururken etiketleri kullanın. Etiketler, tahakkuk edilen maliyetleri izlemek üzere özel raporlar oluşturmak için faydalıdır. Etiketler, giderlerin toplam sayısını takip etme ve herhangi bir maliyeti belirli bir kaynak ya da ekibe eşleme yeteneği sağlar. Ayrıca, küme takımlar arasında paylaşılmışsa, paylaşılan bulut hizmetleri için ölçülen maliyetleri belirlemek üzere tüketici başına geri ödeme raporları oluşturun. Daha fazla bilgi için bkz. düğüm havuzu için bir taınt, etiket veya etiket belirtme.

• Bir bölgenin kullanılabilirlik alanları içindeki veri aktarımları ücretsizdir. İş yükünüz çok bölgedeyse veya faturalandırma bölgelerinde aktarımlar varsa, ek bant genişliği maliyeti bekletir. Daha fazla bilgi için bkz. faturalandırma bölgeleri ve bölgeleri arasındaki trafik.

• Kuruluş tarafından tanımlanan maliyet kısıtlamaları dahilinde kalmak için bütçeler oluşturun. Azure maliyet yönetimi aracılığıyla bütçeleri oluşturmak tek bir yoldur. Ayrıca, belirli eşikler aşıldığında bildirimleri almak için uyarılar oluşturabilirsiniz. Daha fazla bilgi için bkz. şablon kullanarak bütçe oluşturma.

İzleyici

Tüm kümenin maliyetini izlemek için, işlem maliyetiyle birlikte depolama, bant genişliği, güvenlik duvarı ve Günlükler hakkında maliyet bilgileri de toplayın. Azure, maliyeti izlemek ve analiz etmek için çeşitli panolar sağlar:

• Azure Danışmanı

• Azure Maliyet Yönetimi

İdeal olarak, maliyetleri gerçek zamanlı olarak veya en azından düzenli bir temposunda izleyin ve maliyetler zaten hesaplanıyorsa ayın sonundan önce eyleme geçin. Ayrıca, bütçeye devam etmek için zaman içinde aylık eğilimi izleyin.

Veri odaklı kararlar almak için, kaynak (ayrıntılı düzeyi) en fazla maliyetli bir kaynak sağlar. Ayrıca, her bir kaynağın kullanımını hesaplamak için kullanılan ölçüleri de iyi anlamak gerekir. Ölçümleri analiz ederek, platformun örneğin daha fazla boyutlandırılıp boyutlandırılmayacağını belirleyebilirsiniz. Kullanım ölçümlerini Azure Izleyici ölçümlerinde görebilirsiniz.

İyileştirme

Azure Advisortarafından sunulan önerilere göre işlem yapın. İyileştirmek için başka yollar vardır:

• Düğüm havuzundaki az kullanılan düğümleri algılayıp kaldırmak için küme otomatik Scaler 'ı etkinleştirin.

• İş yükünüz destekliyorsa, düğüm havuzları için daha düşük bir SKU seçin.

• Uygulama, veri bloğu Ölçeklendirmesi gerektirmiyorsa, zaman içinde performans ölçümlerini çözümleyerek kümeyi yalnızca doğru boyuta göre boyutlandırmayı göz önünde bulundurun.

• İş yükünüz destekliyorsa, bunların çalışması için bir beklentisi olmadığında Kullanıcı düğümü havuzlarınızı 0 düğüm olarak ölçeklendirin . Ayrıca, kümenizde çalıştırılmak üzere zamanlanmış bir iş yükü yoksa, sistem düğüm havuzunuzu ve AKS denetim düzlemi 'ni içeren tüm işlemleri kapatmak için aks Başlat/Durdur özelliğini kullanmayı göz önünde bulundurun.

Maliyetle ilgili diğer bilgiler için bkz. aks fiyatlandırması.

Sonraki Adımlar

• AKS taban çizgisinde mikro hizmetleri barındırma hakkında bilgi edinmek için bkz. Gelişmiş Azure Kubernetes Service (AKS) mikro hizmetler mimarisi.
• AKS taban çizgisini birden çok bölgeye dağıtmak için bkz. çok bölgeli kümeleri Için aks taban çizgisi.
• AKS taban çizgisini PCI DSS 3.2.1 ortamına dağıtmak için bkz. PCI-DSS 3.2.1 Için aks düzenlenmiş kümesi.
• Bkz. AKS ürün yol haritası, GitHub Için Azure Kubernetes hizmet yol haritası.

İlgili makaleler:

Kubernetes 'te bir yenileyici gerekiyorsa, Kubernetes Ile ilgili girişi tamamlayıp Microsoft Learn Için Kubernetes öğrenme yollarında uygulamalar geliştirin ve dağıtın .