Gelişmiş Azure Kubernetes Service (AKS) mikro hizmetler mimarisi

Azure Application Gateway
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Virtual Network

Bu başvuru mimarisi, Azure Kubernetes Services üzerinde mikro hizmetleri çalıştırırken göz önünde bulundurulacak çeşitli yapılandırmaların ayrıntılarını sağlar. Konu başlıkları arasında ağ ilkelerini yapılandırma, pod otomatik ölçeklendirme ve mikro hizmet tabanlı bir uygulamada dağıtılmış izleme yer alır.

Bu mimari, Microsoft'un AKS altyapısı için önerilen başlangıç noktası olan AKS Baseline mimarisini temel alır. AKS temeli, Microsoft Entra İş Yükü Kimliği, giriş ve çıkış kısıtlamaları, kaynak sınırları ve diğer güvenli AKS altyapısı yapılandırmaları gibi altyapı özelliklerinin ayrıntılarını içerir. Bu altyapı ayrıntıları bu belgede ele alınmamıştır. Mikro hizmetler içeriğine geçmeden önce AKS temeli hakkında bilgi sahibi olmanız önerilir.

GitHub logoBu mimarinin başvuru uygulaması GitHub'da kullanılabilir.

Mimari

Network diagram showing the hub-spoke network with two peered virtual networks and the Azure resources this implementation uses.

Bu mimarinin bir Visio dosyasını indirin.

AKS'de daha temel bir mikro hizmetler örneğiyle başlamak isterseniz bkz . AKS'de mikro hizmetler mimarisi.

İş akışı

Bu istek akışı Yayımcı-Abone, Rakip Tüketiciler ve Ağ Geçidi Yönlendirme bulut tasarım desenlerini uygular. Mesajlaşma akışı aşağıdaki gibi devam eder:

  1. İnsansız hava aracıyla teslim alma zamanlamak için bir HTTPS isteği gönderilir. İstekler Azure Uygulaması lication Gateway'i aks'de küme içi bir mikro hizmet olarak çalışan alma web uygulamasına geçirir.

  2. Alma web uygulaması bir ileti oluşturur ve Service Bus ileti kuyruğuna gönderir.

  3. Arka uç sistemi bir insansız hava aracı atar ve kullanıcıya bildirir. İş akışı:

    • Service Bus ileti kuyruğundaki ileti bilgilerini tüketir.
    • Verileri dış veri depolama alanına Redis için Azure Cache ileten Delivery mikro hizmete bir HTTPS isteği gönderir.
    • İnsansız Hava Aracı Scheduler mikro hizmeti için bir HTTPS isteği gönderir.
    • Verileri MongoDB dış veri depolama alanına geçiren Paket mikro hizmeti için bir HTTPS isteği gönderir.
  4. Teslim durumunu döndürmek için BIR HTTPS GET isteği kullanılır. Bu istek Application Gateway üzerinden Teslim mikro hizmetine geçer.

  5. Teslim mikro hizmeti verileri Redis için Azure Cache okur.

Components

Bu mimaride aşağıdaki Azure bileşenleri kullanılır:

Azure Kubernetes Service , yönetilen bir Kubernetes kümesi sağlayan bir Azure teklifidir. AKS kullanılırken Kubernetes API sunucusu Azure tarafından yönetilir. Kubernetes düğümlerine veya düğüm havuzlarına erişilebilir ve küme operatörü tarafından yönetilebilir.

Bu mimaride kullanılan AKS altyapısı özellikleri şunlardır:

Azure Sanal Ağ, sanal makineleri (VM) ve uygulamaları çalıştırmak için yalıtılmış ve yüksek oranda güvenli ortamlardır. Bu başvuru mimarisi eşlenmiş merkez-uç sanal ağ topolojisi kullanır. Merkez sanal ağı, Azure güvenlik duvarını ve Azure Bastion alt ağlarını barındırıyor. Uç sanal ağı AKS sistemi ve kullanıcı düğümü havuzu alt ağlarını ve Azure Uygulaması lication Gateway alt ağını barındırıyor.

Azure Özel Bağlantı AKS sistemi ve kullanıcı düğümü havuzu alt ağı içindeki Özel Uç Noktalardan Azure Container Registry ve Key Vault'a erişmek için belirli özel IP adresleri ayırır.

Azure Uygulaması Lication Gateway ile web uygulaması güvenlik duvarı (WAF), AKS kümesine HTTP(S) yollarını kullanıma sunar ve web trafiğini web uygulamasına yükler. Bu mimaride Kubernetes giriş denetleyicisi olarak Azure Uygulaması Lication Gateway Giriş Denetleyicisi (AGIC) kullanılır.

Azure Bastion , vm'leri genel IP adresleri aracılığıyla kullanıma sunmaya gerek kalmadan güvenli bir yuva katmanı (SSL) kullanarak sanal ağlardaki VM'lere güvenli uzak masaüstü protokolü (RDP) ve güvenli kabuk (SSH) erişimi sağlar.

Azure Güvenlik Duvarı, tüm Azure Sanal Ağ kaynaklarını koruyan bir ağ güvenlik hizmetidir. Güvenlik duvarı çıkış trafiği olarak yalnızca onaylı hizmetlere ve tam etki alanı adlarına (FQDN) izin verir.

Dış depolama ve diğer bileşenler:

Azure Key Vault , AKS hizmetleri için güvenlik anahtarlarını depolar ve yönetir.

Azure Container Registry , AKS kümesinde çalıştırılabilir özel kapsayıcı görüntülerini depolar. AKS, Microsoft Entra yönetilen kimliğini kullanarak Container Registry ile kimlik doğrulaması yapar. Docker Hub gibi diğer kapsayıcı kayıt defterlerini de kullanabilirsiniz.

Azure Cosmos DB, MongoDB için açık kaynak Azure Cosmos DB'yi kullanarak verileri depolar. Mikro hizmetler genellikle durum bilgisi yoktur ve durumlarını dış veri depolarına yazar. Azure Cosmos DB, MongoDB ve Cassandra için açık kaynak API'leri olan bir NoSQL veritabanıdır.

Azure Service Bus , hizmet olarak güvenilir bulut mesajlaşması ve basit hibrit tümleştirme sunar. Service Bus, mikro hizmet uygulamalarıyla ortak olan zaman uyumsuz mesajlaşma desenlerini destekler.

Redis için Azure Cache yoğun trafik yüklerinin hızını ve performansını artırmak için uygulama mimarisine bir önbelleğe alma katmanı ekler.

Azure İzleyici , uygulama telemetrisi ve Azure platformu ile hizmet ölçümleri dahil olmak üzere ölçümleri ve günlükleri toplar ve depolar. Uygulamayı izlemek, uyarıları ve panoları ayarlamak ve hataların kök neden analizini gerçekleştirmek için bu verileri kullanabilirsiniz.

Diğer işlemler sistem (OSS) bileşenlerini destekler:

Kubernetes nesnelerini yayımlayabileceğiniz, dağıtabileceğiniz, sürümleyebileceğiniz ve güncelleştirebileceğiniz tek bir ünitede paketleyen Kubernetes paket yöneticisi Helm.

Azure Key Vault Gizli Depolama CSI sağlayıcısı, Azure Key Vault'ta depolanan gizli dizileri alır ve Bunları Kubernetes podlarına bağlamak için Gizli Dizi Deposu CSI sürücü arabirimini kullanır.

GitOps Toolkit tarafından desteklenen Kubernetes için açık ve genişletilebilir bir sürekli teslim çözümü olan Flux.

Senaryo ayrıntıları

Önceki diyagramda gösterilen Fabrikam İnsansız Hava Aracı Teslimat Gönderimi Uygulaması örneği, bu makalede ele alınan mimari bileşenleri ve uygulamaları uygular. Bu örnekte kurgusal bir şirket olan Fabrikam, Inc., insansız hava aracı uçak filosunu yönetiyor. İşletmeler hizmete kaydolabiliyor ve kullanıcılar teslim edilecek ürünleri almak üzere insansız hava aracı isteğinde bulunabiliyor. Müşteri teslim alma zamanladığında arka uç sistemi bir insansız hava aracı atar ve kullanıcıya tahmini teslimat süresini bildirir. Teslimat devam ederken müşteri sürekli güncelleştirilen bir ETA ile insansız hava aracının konumunu izleyebilir.

Olası kullanım örnekleri

Bu çözüm uçak, havacılık ve havacılık endüstrileri için idealdir.

Öneriler

Gelişmiş AKS mikro hizmet mimarilerini dağıtırken bu önerileri uygulayın.

Application Gateway Giriş Denetleyicisi (AGIC)

API Gateway Yönlendirmesi genel bir mikro hizmet tasarım desenidir. API ağ geçidi, istemcilerin isteklerini mikro hizmetlere yönlendiren ters ara sunucu işlevi görür. Kubernetes giriş kaynağı ve giriş denetleyicisi API ağ geçidi işlevlerinin çoğunu şu şekilde işler:

İstemci isteklerinin doğru arka uç hizmetlerine yönlendirilmesi, istemciler için tek bir uç nokta sağlar ve istemcileri hizmetlerden ayırmaya yardımcı olur.

  • İstemci ile arka uç arasındaki sohbeti azaltmak için birden çok isteği tek bir istekte toplama.
  • SSL sonlandırma, kimlik doğrulaması, IP kısıtlamaları ve arka uç hizmetlerinden istemci hızı sınırlama veya azaltma gibi işlevleri boşaltma.

AKS kümesinin durumu Application Gateway'e özgü yapılandırmaya çevrilir ve Azure Resource Manager aracılığıyla uygulanır.

Dış giriş denetleyicileri AKS kümelerine trafik alımını basitleştirir, güvenliği ve performansı artırır ve kaynak tasarrufu sağlar. Bu mimaride giriş denetimi için Azure Uygulaması lication Gateway Giriş Denetleyicisi (AGIC) kullanılır. Application Gateway'in tüm trafiği işlemek için kullanılması ek yük dengeleyici gereksinimini ortadan kaldırır. Podlar Application Gateway ile doğrudan bağlantı kurduğundan, gerekli atlama sayısı azalır ve bu da daha iyi performans sağlar.

Application Gateway' in yerleşik otomatik ölçeklendirme özellikleri vardır; bunun aksine, istenmeyen miktarda işlem kaynağı tüketen küme içi giriş denetleyicilerinin ölçeği genişletilmelidir. Application Gateway, katman 7 yönlendirme ve SSL sonlandırma gerçekleştirebilir ve yerleşik bir web uygulaması güvenlik duvarı (WAF) ile tümleştirilmiş uçtan uca Aktarım Katmanı Güvenliği 'ne (TLS) sahiptir.

AGIC giriş seçeneği için, APPLICATION Gateway AKS sanal ağının bir alt ağına dağıtıldığından AKS kümesini yapılandırırken CNI ağını etkinleştirmeniz gerekir. Çok kiracılı iş yükleri veya geliştirme ve test ortamlarını destekleyen tek bir küme daha fazla giriş denetleyicisi gerektirebilir.

Sıfır güven ağ ilkeleri

Ağ ilkeleri, AKS podlarının birbirleriyle ve diğer ağ uç noktalarıyla nasıl iletişim kurmasına izin verileceğini belirtir. Varsayılan olarak, podlara ve podlardan gelen tüm giriş ve çıkış trafiğine izin verilir. Mikro hizmetlerinizin birbirleriyle ve diğer uç noktalarla nasıl iletişim kuracaklarını tasarlarken, herhangi bir hizmete, cihaza, uygulamaya veya veri deposuna erişimin açık yapılandırma gerektirdiği sıfır güven ilkesini uygulamayı göz önünde bulundurun.

Sıfır güven ilkesi uygulama stratejilerinden biri, hedef ad alanı içindeki tüm podlara yönelik tüm giriş ve çıkış trafiğini reddeden bir ağ ilkesi oluşturmaktır. Aşağıdaki örnekte, arka uç geliştirme ad alanında bulunan tüm podlar için geçerli olacak bir 'tüm ilkeyi reddet' gösterilmektedir.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Kısıtlayıcı bir ilke uygulandıktan sonra, mikro hizmetteki her poddan gelen ve giden trafiğe izin vermek için belirli ağ kuralları tanımlamaya başlayın. Aşağıdaki örnekte, ağ ilkesi arka uç-geliştirme ad alanı içindeki herhangi bir poda app.kubernetes.io/component eşleşen bir etiketle uygulanır: arka uç. İlke, app.kubernetes.io/part-of ile eşleşen bir etikete sahip bir poddan kaynaklanmadığı sürece trafiği reddeder: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Kubernetes ağ ilkeleri hakkında daha fazla bilgi ve olası varsayılan ilkelere ilişkin ek örnekler için Kubernetes belgelerindeki Ağ İlkeleri'ne bakın.

Kaynak kotaları

Kaynak kotaları, yöneticilerin geliştirme ekibi veya proje genelinde kaynakları ayırması ve sınırlaması için bir yoldur. Bir ad alanında kaynak kotaları ayarlayabilir ve bunları kullanarak şu sınırlara ayarlayabilirsiniz:

  • CPU ve bellek veya GPU'lar gibi işlem kaynakları.
  • Belirli bir depolama sınıfı için birim sayısı veya disk alanı miktarı dahil olmak üzere kaynakları Depolama.
  • Oluşturulabilecek en fazla gizli dizi, hizmet veya iş sayısı gibi nesne sayısı.

Kaynak isteklerinin veya limitlerinin birikmeli toplamı atanan kotayı geçtikten sonra başka dağıtım başarılı olmaz.

Kaynak kotaları, ad alanına atanan toplam pod kümesinin ad alanının kaynak kotasını aşamamasını sağlar. Ön uç, kaynaklar için arka uç hizmetlerini aç bırakamaz veya tam tersi de geçerlidir.

Kaynak kotalarını tanımladığınızda, ad alanında oluşturulan tüm podların pod belirtimlerinde sınırlar veya istekler sağlaması gerekir. Bu değerleri sağlamazlarsa dağıtım reddedilir.

Aşağıdaki örnekte, kaynak kotası isteklerini ve sınırlarını ayarlayan bir pod belirtimi gösterilmektedir:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Kaynak kotaları hakkında daha fazla bilgi için bkz:

Otomatik ölçeklendirme

Kubernetes, bir dağıtıma ayrılan pod sayısını artırmak veya kullanılabilir toplam işlem kaynağını artırmak için kümedeki düğümleri artırmak için otomatik ölçeklendirmeyi destekler. Otomatik ölçeklendirme, kendi kendini düzelten otonom bir geri bildirim sistemidir. Podları ve düğümleri el ile ölçeklendirebilmenize rağmen otomatik ölçeklendirme, hizmetlerin yüksek yüklerde kaynak gereksinimine neden olma olasılığını en aza indirir. Otomatik ölçeklendirme stratejisi hem podları hem de düğümleri hesaba katmalıdır.

Küme otomatik ölçeklendirme

Küme otomatik ölçeklendiricisi (CA), düğüm sayısını ölçeklendirir. Kaynak kısıtlamaları nedeniyle podların zamanlanamadığından; küme otomatik ölçeklendiricisi daha fazla düğüm sağlar. AKS kümesini ve iş yüklerinizi çalışır durumda tutmak için en az sayıda düğüm ve yoğun trafik için en fazla düğüm sayısı tanımlarsınız. CA, bekleyen podları veya boş düğümleri birkaç saniyede bir denetler ve AKS kümesini uygun şekilde ölçeklendirir.

Aşağıdaki örnekte ARM şablonundan CA yapılandırması gösterilmektedir:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

ARM şablonunda aşağıdaki satırlar, CA için örnek en düşük ve en yüksek düğümleri ayarlar:

"minCount": 2,
"maxCount": 5,

Pod otomatik ölçeklendirme

Yatay Pod Otomatik Ölçeklendiricisi (HPA), gözlemlenen CPU, bellek veya özel ölçümlere göre podları ölçeklendirir. Yatay pod ölçeklendirmeyi yapılandırmak için Kubernetes dağıtım podunun belirtiminde hedef ölçümleri ve en düşük ve en fazla çoğaltma sayısını belirtirsiniz. Bu sayıları belirlemek için hizmetlerinizi yük testi gerçekleştirin.

CA ve HPA birlikte iyi çalıştığından AKS kümenizde her iki otomatik ölçeklendirici seçeneğini de etkinleştirin. HPA uygulamayı ölçeklendirirken CA altyapıyı ölçeklendirir.

Aşağıdaki örnek HPA için kaynak ölçümlerini ayarlar:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA, tüketilen gerçek kaynaklara veya çalışan podlardan gelen diğer ölçümlere bakar, ancak CA henüz zamanlanmamış podlar için düğümler sağlar. Bu nedenle CA, pod belirtiminde belirtildiği gibi istenen kaynaklara bakar. Bu değerlere ince ayar yapmak için yük testlerini kullanın.

Durum araştırmaları

Kubernetes, hizmetin etiket seçicisi ile eşleşen podlara gelen trafiği dengeler. Yalnızca başarıyla başlatılan ve iyi durumda olan podlar trafik alır. Bir kapsayıcı kilitlenirse Kubernetes podu kaldırır ve bir değişiklik zamanlar.

Kubernetes'te pod iki tür sistem durumu araştırmasını kullanıma açabilir:

  • Canlılık araştırması Kubernetes'e bir podun başarıyla başlatılıp başlatılmadığını ve iyi durumda olup olmadığını bildirir.
  • Hazır olma yoklaması Kubernetes'e bir podun istekleri kabul etmeye hazır olup olmadığını bildirir.

Canlılık yoklamaları hala çalışan ancak iyi durumda olmayan ve geri dönüştürülmesi gereken podları işler. Örneğin, HTTP isteklerini sunan bir kapsayıcı kilitleniyorsa, kapsayıcı kilitlenmez, ancak isteklerin sunulmasını durdurur. HTTP canlılık yoklaması yanıt vermeyi durdurarak Kubernetes'i podu yeniden başlatması konusunda bilgilendirir.

Bazen pod başarıyla başlatılsa bile trafiği almaya hazır olmayabilir. Örneğin, kapsayıcıda çalışan uygulama başlatma görevlerini gerçekleştiriyor olabilir. Hazır olma yoklaması, podun trafiği almaya hazır olup olmadığını gösterir.

Mikro hizmetler, özel olarak gerçekleştirdikleri denetimlere göre uyarlanmış gecikme ve zaman aşımı ile sistem durumu yoklamalarını kolaylaştıran uç noktaları kodlarında kullanıma sunmalıdır. HPA formül tuşları, poddaki Hazır aşamasından neredeyse tamamen uzaktır, bu nedenle sistem durumu yoklamalarının mevcut olması ve doğru olması kritik önem taşır.

İzleme

Mikro hizmetler uygulamasında Uygulama Performansı Yönetimi (APM) izlemesi anomalileri algılamak, sorunları tanılamak ve hizmetler arasındaki bağımlılıkları hızla anlamak için kritik öneme sahiptir. Azure İzleyici'nin bir parçası olan Application Analizler. .NET Core, Node.js, Java ve diğer birçok uygulama dilinde yazılmış canlı uygulamalar için APM izlemesi sağlar.

Application Insights:

  • Gecikme süresi ve sonuç kodu da dahil olmak üzere HTTP isteklerini günlüğe kaydeder.
  • Dağıtılmış izlemeyi varsayılan olarak etkinleştirir.
  • Belirli bir işlemin tüm izlemelerini eşleştirebilmeniz için izlemelere bir işlem kimliği ekler.
  • genellikle izlemelerde ek bağlamsal bilgiler içerir.

Kubernetes dünyasıyla hizmet telemetrisini bağlamsal hale getirmek için Azure İzleyici telemetrisini AKS ile tümleştirerek denetleyiciler, düğümler ve kapsayıcıların yanı sıra kapsayıcı ve düğüm günlüklerinden ölçümler toplayın. .NET kullanıyorsanız, Kubernetes kitaplığı için Application Analizler Application Analizler telemetrisini görüntü, kapsayıcı, düğüm, pod, etiket ve çoğaltma kümesi bilgileriyle zenginleştirir.

Aşağıdaki diyagramda, Application Analizler'ın AKS mikro hizmetler telemetri izlemesi için oluşturduğu uygulama bağımlılığı eşlemesinin bir örneği gösterilmektedir:

Example of an Application Insights dependency map for an AKS microservices application.

Application Insights tümleştirmesi için ortak dilleri izleme seçenekleri hakkında daha fazla bilgi için bkz . Kubernetes için uygulama izleme.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Ölçeklenebilirlik

Ölçeklenebilirlik planlaması yaparken aşağıdaki noktaları göz önünde bulundurun.

  • Çoğaltma sayısının otomatik ölçeklendirme ve kesin veya bildirim temelli yönetimini birleştirmeyin. Hem kullanıcılar hem de bir otomatik ölçeklendirici çoğaltma sayısını değiştirmeye çalışırken beklenmeyen davranışlara neden olabilir. HPA etkinleştirildiğinde, çoğaltma sayısını dağıtılmasını istediğiniz en düşük sayıya düşürün.

  • Pod otomatik ölçeklendirmesinin bir yan etkisi, ölçeği genişletme ve ölçeği daraltma olayları gerçekleştiğinde podların sık sık oluşturulup çıkarılabilmesidir. Bu etkileri azaltmak için:

    • Kubernetes'e yeni bir podun trafiği kabul etmeye hazır olduğunu bildirmek için hazır olma yoklamalarını kullanın.
    • Bir kerede bir hizmetten çıkarılacak pod sayısını sınırlamak için pod kesintisi bütçelerini kullanın.
  • Küme oluşturduktan sonra VM boyutunu değiştiremezsiniz, bu nedenle kümeyi oluştururken aracı düğümleri için uygun bir VM boyutu seçmek üzere ilk kapasite planlaması yapın.

  • Çok kiracılı veya diğer gelişmiş iş yüklerinde daha fazla ve büyük olasılıkla daha küçük alt ağlar gerektiren düğüm havuzu yalıtım gereksinimleri olabilir. Benzersiz alt ağlarla düğüm havuzları oluşturma hakkında daha fazla bilgi için bkz . Benzersiz alt ağa sahip düğüm havuzu ekleme. Kuruluşların merkez-uç uygulamaları için farklı standartları vardır. Kuruluş yönergelerinizi izlediğinizden emin olun.

Yönetilebilirlik

Yönetilebilirlik planlaması yaparken aşağıdaki noktaları göz önünde bulundurun.

  • Aks kümesi altyapısını otomatik dağıtım işlem hattı aracılığıyla yönetin. Bu mimari için başvuru uygulaması, işlem hattınızı oluştururken başvurabileceğiniz bir GitHub Actions iş akışı sağlar.

  • İş akışı dosyası, zaten var olan sanal ağa ve Microsoft Entra yapılandırmasına iş yükünü değil yalnızca altyapıyı dağıtır. Altyapıyı ve iş yükünü ayrı ayrı dağıtmak, farklı yaşam döngüsü ve operasyonel sorunları gidermenize olanak tanır.

  • Bölgesel bir hata olduğunda iş akışınızı başka bir bölgeye dağıtma mekanizması olarak düşünün. Parametre ve giriş değişiklikleriyle yeni bir bölgeye yeni bir küme dağıtabilmeniz için işlem hattını oluşturun.

Güvenlik

Güvenlik, kasıtlı saldırılara ve değerli verilerinizin ve sistemlerinizin kötüye kullanılmasına karşı güvence sağlar. Daha fazla bilgi için bkz . Güvenlik sütununa genel bakış.

Güvenlik planlaması yaparken aşağıdaki noktaları göz önünde bulundurun.

  • AKS podu, Microsoft Entra Id'de depolanan bir iş yükü kimliğini kullanarak kimliğini doğrular. İstemci gizli dizisi gerektirmediğinden iş yükü kimliğinin kullanılması tercih edilir.

  • Yönetilen kimliklerle yürütme işlemi Azure Resource Manager OAuth 2.0 belirteçlerini hızla alabilir; parolalara veya bağlantı dizesi gerek yoktur. AKS'de, Microsoft Entra İş Yükü Kimliği kullanarak tek tek podlara kimlik atayabilirsiniz.

  • Mikro hizmet uygulamasındaki her hizmete, en az ayrıcalıklı RBAC atamalarını kolaylaştırmak için benzersiz bir iş yükü kimliği atanmalıdır. Kimlikleri yalnızca bunları gerektiren hizmetlere atamanız gerekir.

  • Bir uygulama bileşeninin Kubernetes API erişimi gerektirdiği durumlarda, uygulama podlarının uygun kapsamlı API erişimine sahip bir hizmet hesabı kullanacak şekilde yapılandırıldığından emin olun. Kubernetes hizmet hesabını yapılandırma ve yönetme hakkında daha fazla bilgi için bkz . Kubernetes Hizmet Hesaplarını Yönetme.

  • Tüm Azure hizmetleri Microsoft Entra Id kullanarak veri düzlemi kimlik doğrulamayı desteklemez. Bu hizmetler, üçüncü taraf hizmetler veya API anahtarları için kimlik bilgilerini veya uygulama gizli dizilerini depolamak için Azure Key Vault kullanın. Azure Key Vault merkezi yönetim, erişim denetimi, bekleyen şifreleme ve tüm anahtarlar ile gizli diziler için denetim sağlar.

  • AKS'de, Key Vault'tan bir veya daha fazla gizli diziyi birim olarak bağlayabilirsiniz. Pod daha sonra Key Vault gizli dizilerini normal bir birim gibi okuyabilir. Daha fazla bilgi için GitHub'da secrets-store-csi-driver-provider-azure projesine bakın.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Sonraki adımlar