Bu başvuru mimarisinde, Azure Kubernetes hizmetlerinde mikro Hizmetleri çalıştırırken dikkate alınması gereken çeşitli yapılandırmaların ayrıntıları yer alır. Bir mikro hizmet tabanlı uygulama genelinde ağ ilkelerini, Pod otomatik ölçeklendirmeyi ve dağıtılmış izlemeyi yapılandırma konuları vardır.
Bu mimari, aks temel mimarisiüzerinde oluşturulur ve Microsoft 'un aks altyapısı için önerilen başlangıç noktasıdır. aks taban çizgisi ayrıntıları, Azure Active Directory (Azure AD) pod kimliği, giriş ve çıkış kısıtlamaları, kaynak sınırları ve diğer güvenli aks altyapı yapılandırmalarına benzer özellikler altyapısal. Bu altyapısal ayrıntıları bu belgede ele alınmıyor. Mikro hizmet içeriğine devam etmeden önce AKS taban çizgisini tanımanız önerilir.
bu mimarinin başvuru uygulamasına GitHubkullanılabilir.
AKS üzerinde daha fazla temel mikro hizmet örneği ile başlamasını tercih ediyorsanız bkz. AKS üzerinde mikro hizmetler mimarisi
Bileşenler
Bu mimari aşağıdaki Azure bileşenlerini kullanır:
Azure Kubernetes hizmeti , yönetilen bir Kubernetes kümesi sağlayan bir Azure sunumudur. 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ı özellikleri şunlardır:
- Sistem ve Kullanıcı düğümü havuzu ayrımı
- AKS-yönetilen rol tabanlı erişim denetimi (RBAC) için Azure AD
- Azure AD Pod tarafından yönetilen kimlikler
- AKS için Azure Ilke eklentisi
- Azure Container ağ arabirimi (CNı)
- Kapsayıcılar için Azure İzleyici
Azure sanal ağları , sanal makinelerin (VM 'ler) ve uygulamaların çalıştırılması için yalıtılmış ve yüksek oranda güvenli ortamlardır. Bu başvuru mimarisi, eşlenmiş bir hub-bağlı sanal ağ topolojisi kullanır. Hub sanal ağı, Azure Güvenlik Duvarı ve Azure savunma alt ağlarını barındırır. Bağlı olan sanal ağ, AKS sistemi ve Kullanıcı düğümü havuzu alt ağlarını ve Azure Application Gateway alt ağını barındırır.
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 erışmek için belirli özel IP adresleri ayırır.
Web uygulaması güvenlik duvarı (WAF) ile Azure Application Gateway , aks kümesine http (S) yolları sunar ve Web trafiğini Web uygulamasına dengeler. Bu mimari, Kubernetes giriş denetleyicisi olarak Azure Application Gateway ınress denetleyicisi 'ni (agic) kullanır.
Azure savunma, güvenli bir yuva KATMANı (SSL) kullanarak sanal ağlardaki VM 'lere güvenli Uzak Masaüstü Protokolü (RDP) ve Secure Shell (SSH) erişimi sağlar ve VM 'LERI genel IP adresleri aracılığıyla açığa çıkarmak zorunda kalmaz.
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 onaylanan 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ılabilen özel kapsayıcı görüntülerini depolar. AKS, Azure AD tarafından yönetilen kimliğini kullanarak Container Registry kimliğini doğrular. Docker Hub gibi diğer kapsayıcı kayıt defterleri de kullanabilirsiniz.
Azure Cosmos DB , mongodb için açık kaynaklı Azure Cosmos DB apı'sini kullanarak verileri depolar. Mikro hizmetler genellikle durum bilgisiz durumundadır ve durumlarını dış veri depolarına yazar. Azure Cosmos DB, mongodb ve cassandra için açık kaynaklı apı 'ler içeren bir nosql veritabanıdır.
Azure Service Bus , hizmet olarak güvenilir bulut iletileri ve basit karma tümleştirme sunar. Service Bus, mikro hizmet uygulamalarıyla ortak olan zaman uyumsuz mesajlaşma düzenlerini destekler.
Redis Için Azure önbelleği , ağır trafik yüklerinin hızını ve performansını artırmak için uygulama mimarisine bir önbelleğe alma katmanı ekler.
Azure izleyici , uygulama telemetrisi ve Azure platformu ve hizmet ölçümleri dahil olmak üzere ölçümleri ve günlükleri toplar ve depolar. Bu verileri uygulamayı izlemek, uyarıları ve panoları ayarlamak ve hataların kök neden analizini yapmak için kullanabilirsiniz.
Diğer işlemler destek sistemi (OSS) bileşenleri:
Kubernetes için, Kubernetes nesnelerini, yayımlayacağınız, dağıtabileceğiniz, sürüm ve güncelleyebilir tek bir birimde sunan helk.
Gizli depolama CSI sağlayıcısı Azure Key Vault, Azure Key Vault depolanan gizli dizileri alır ve Kubernetes pods 'ye bağlamak Için gizli depo CSI sürücü arabirimini kullanır.
Flox, Kubernetes Için, Gima araç seti tarafından desteklenen açık ve genişletilebilir bir sürekli teslim çözümüdür.
İstek akışı
Yukarıdaki diyagramda gösterilen fabrikam drone teslim gönderimi uygulaması örneği, bu makalede ele alınan mimari bileşenleri ve uygulamaları uygular. Bu örnekte, kurgusal bir şirket olan Fabrikam, Inc., içni kuruttayı bir arada yönetir. İşletmeler hizmete kaydolabiliyor ve kullanıcılar teslim edilecek ürünleri almak üzere insansız hava aracı isteğinde bulunabiliyor. Bir müşteri bir çekme zamanlaması zamanlıyor, arka uç sistemi bir drone atar ve kullanıcıya tahmini bir teslim süresi bildirir. Teslim devam ederken, müşteri, sürekli olarak güncelleştirilmiş bir ETA ile drone 'nin konumunu izleyebilir.
bu istek akışı, Publisher aboneyi, rekabet eden müşterilerive ağ geçidi yönlendirme bulutu tasarım düzenlerini uygular. İleti akışı aşağıdaki gibi ilerler:
Bir drone alımı zamanlamak için bir HTTPS isteği gönderilir. İstekler Azure Application Gateway aracılığıyla AKS 'de küme içi mikro hizmet olarak çalışan alma Web uygulamasına geçer.
alma web uygulaması bir ileti oluşturur ve Service Bus ileti kuyruğuna gönderir.
Arka uç sistemi bir drone atar ve kullanıcıya bildirir. İş akışı:
- Service Bus ileti sırasından ileti bilgilerini tüketir.
- İstek mikro hizmetine, Redsıs dış veri depolaması için verileri Azure önbelleğine geçiren bir HTTPS isteği gönderir.
- Drone Zamanlayıcı mikro hizmetine bir HTTPS isteği gönderir.
- Verileri MongoDB dış veri depolamaya geçiren paket mikro hizmetine bir HTTPS isteği gönderir.
Dağıtım durumunu döndürmek için bir HTTPS GET isteği kullanılır. Bu istek, teslim mikro hizmetine Application Gateway üzerinden geçer.
Teslim mikro hizmeti, Reda için Azure önbelleğinden verileri okur.
Öneriler
Gelişmiş AKS mikro hizmet mimarileri dağıtımı yaparken bu önerileri uygulayın.
Application Gateway giriş denetleyicisi (AGIC)
API Gateway yönlendirme , genel bir mikro hizmetler tasarımmodelidir. API ağ geçidi, istekleri istemcilerden mikro hizmetlere yönlendiren bir ters proxy işlevi görür. Kubernetes giriş kaynağı ve giriş denetleyicisi , API Gateway 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 istemcilerin hizmetlerden ayrılmasıyla yardımcı olur.
- İstemci ile arka uç arasındaki chatter azaltmak için birden çok isteği tek bir istekte toplama.
- SSL sonlandırma, kimlik doğrulama, IP kısıtlamaları ve istemci hız sınırlaması veya arka uç hizmetlerinden azaltma gibi işlevleri boşaltma.
AKS kümesinin durumu Application Gateway özgü yapılandırmaya çevrilir ve Azure Resource Manager ile uygulanır.
Dış giriş denetleyicileri AKS kümelerine giriş alımı basitleştirir, güvenlik ve performansı artırır ve kaynakları kaydeder. Bu mimari giriş denetimi için Azure Application Gateway giriş denetleyicisi 'ni (AGIC) kullanır. Tüm trafiği işlemek için Application Gateway kullanmak, ek yük dengeleyici gereksinimini ortadan kaldırır. Pod Application Gateway karşı doğrudan bağlantılar oluşturduğundan, gereken atlama sayısı azaltılır ve bu da daha iyi performans elde edilir.
Application Gateway, yerleşik otomatik ölçeklendirme yeteneklerine sahiptir ve bunlar, istenmeyen bilgi işlem kaynaklarını tükettiklerinde ölçeklendirilmesi gereken küme dışı giriş denetleyicilerinden farklı olur. Application Gateway, katman 7 yönlendirme ve SSL sonlandırmasını 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 (TLS) içerir.
Agic giriş seçeneğinde, Application Gateway aks sanal ağının bir alt ağına dağıtıldığı için 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üvenli ağ ilkeleri
Ağ ilkeleri, AKS 'lerin birbirleriyle ve diğer ağ uç noktalarıyla nasıl iletişim kurmasına izin verildiğini belirtir. Varsayılan olarak, tüm giriş ve çıkış trafiğinden ve bu trafiğe izin verilir. Mikro hizmetlerinizin birbirleriyle ve diğer uç noktalarla nasıl iletişim kurduğunu tasarlarken, herhangi bir hizmet, cihaz, uygulama veya veri deposuna erişimin açık yapılandırma gerektirdiği bir sıfır güven ilkesi takip etmeyi göz önünde bulundurun.
Sıfır güvenle bir ilke uygularken bir strateji, hedef ad alanındaki tüm yığınlara giriş ve çıkış trafiğini reddeden bir ağ ilkesi oluşturmaktır. Aşağıdaki örnek, arka uç dev ad alanında bulunan tüm yığınlara uygulanacak bir ' tüm ilkeyi Reddet ' gösterir.
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 olduktan sonra, mikro hizmette her Pod 'ın içine ve dışına trafiğe izin vermek için belirli ağ kuralları tanımlamaya başlayın. Aşağıdaki örnekte, ağ ilkesi, arka uç dev ad alanındaki app.Kubernetes.io/Component: arka uçile eşleşen bir etikete sahip herhangi bir pod 'a uygulanır. App.Kubernetes.io/part-of: dronedeliveryile eşleşen bir etikete sahip bir pod 'tan kaynaklanmamışsa, ilke tüm trafiği engeller.
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 ve olası varsayılan ilkelere ek örnekler hakkında daha fazla bilgi için bkz. Kubernetes belgelerindeki ağ ilkeleri.
Kaynak kotaları
Kaynak kotaları, yöneticilerin bir geliştirme takımı veya proje genelinde kaynakları ayırabileceği ve sınırlayabileceği bir yoldur. Bir ad alanı üzerinde kaynak kotaları ayarlayabilir ve bunları, sınırları ayarlamak için kullanabilirsiniz:
- 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 Depolama kaynaklar.
- Oluşturulabilecek en fazla gizli dizi, hizmet veya iş sayısı gibi nesne sayısı.
Kaynak isteklerinin veya limitlerin birikimli toplamı atanan kotayı geçtiğinde, başka dağıtımlar başarılı olmaz.
Kaynak kotaları ad alanına atanan toplam sayıda Pod kümesinin, ad alanının kaynak kotasını aşmayacağından emin olun. Ön uç, kaynaklar için arka uç hizmetlerini (veya tersi) başlatamıyor.
Kaynak kotalarını tanımlarken, ad alanında oluşturulan tüm yığınların Pod belirtimlerinde sınır veya istek sağlaması gerekir. Bu değerleri sağlamıyorsa dağıtım reddedilir.
Aşağıdaki örnek, kaynak kota isteklerini ve sınırlarını ayarlayan bir pod belirtimini göstermektedir:
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 düğüm sayısını artırmak için Otomatik ölçeklendirmeyi destekler veya kullanılabilir toplam işlem kaynaklarını artırmak için kümedeki düğümleri arttırır. Otomatik ölçeklendirme, kendiliğinden düzeltme bir otonom geri bildirim sistemidir. Düğüm ve düğümleri el ile ölçeklendirebilseniz de, otomatik ölçeklendirme, hizmetlerin yüksek yüklere kaynak olarak geçen şekilde kaynak olma olasılığını en aza indirir. Otomatik ölçeklendirme stratejisi, hem Pod hem de düğümleri hesaba almalıdır.
Küme otomatik ölçeklendirme
Küme otomatik gizleme (CA) düğüm sayısını ölçeklendirir. Kaynak kısıtlamaları nedeniyle Pod 'nin zamanlanamadığı varsayın; küme otomatik yüklemesi daha fazla düğüm sağlar. AKS kümesini ve iş yüklerinizi ve ağır trafik için en fazla düğüm sayısını tutan en az düğüm sayısını tanımlarsınız. CA, bekleyen düğüm veya boş düğümler için her bir saniyede bir denetim yapar 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ırlarda, CA için örnek minimum ve maksimum düğüm ayarlanır:
"minCount": 2,
"maxCount": 5,
Pod otomatik ölçeklendirme
Yatay Pod otomatik Scaler (hPa) , gözlemlenen CPU, bellek veya özel ölçümlere göre Pod 'yi ölçeklendirir. Yatay Pod ölçeklendirmeyi yapılandırmak için, Kubernetes Deployment Pod belirtiminde hedef ölçümleri ve en az ve en fazla çoğaltma sayısını belirtirsiniz. Bu numaraları öğrenmek için hizmetlerinizi yük testi yapın.
CA ve HPA birlikte iyi çalışır, bu nedenle AKS kümenizde hem otomatik Scaler seçeneklerini etkinleştirin. HPA, uygulamayı ölçeklendirir, ancak 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, Pod 'nin kullandığı gerçek kaynaklara veya diğer ölçümlere bakar, ancak CA henüz zamanlanmamış olan düğüm için düğümleri sağlar. Bu nedenle, CA, Pod belirtiminde belirtilen şekilde istenen kaynaklara bakar. Bu değerleri ince ayar yapmak için yük testi kullanın.
Durum araştırmaları
Kubernetes yükü, bir hizmetin etiket seçicisiyle eşleşen trafiği Pod 'ye dengeler. Yalnızca başarılı bir şekilde başlatılan ve sağlıklı bir trafik alma işlemi olan Pod 'ler. Bir kapsayıcı kilitlenirse Kubernetes Pod öğesini kaldırır ve bir değişikliği zamanlar.
Kubernetes 'te Pod, iki tür sistem durumu araştırması sunabilir:
- Limize araştırma , Kubernetes 'in bir pod 'ın başarıyla başlatılıp başlatılmadığını ve sağlıklı olup olmadığını söyler.
- Hazırlık araştırması , Kubernetes 'in bir pod 'ın istekleri kabul etmeye hazır olup olmadığını söyler.
Kullanım araştırmaları, hala çalışmakta olan ancak sağlıksız ve geri dönüştürülecek olması gereken aykırı değerleri işler. Örneğin, HTTP isteklerine hizmet veren bir kapsayıcı askıda kalırsa kapsayıcı çökmez, ancak isteklere hizmet vermeyi keser. , Kubernetes 'i Pod 'ın yeniden başlatması için bildiren HTTP limize yönelik araştırma yanıt vermeyi durduruyor.
Bazı durumlarda, Pod başarıyla başlatılmış olsa da, bir pod trafiği almaya hazırmış olabilir. Örneğin, kapsayıcıda çalışan uygulama başlatma görevleri gerçekleştiriyor olabilir. Hazırlık araştırması, Pod 'un trafik almaya hazır olup olmadığını gösterir.
Mikro hizmetler, özellikle gerçekleştirdikleri denetimleri için özel olarak uyarlanmış gecikme ve zaman aşımı ile sistem durumu araştırmalarını kolaylaştıran, kodlardaki uç noktaları kullanıma sunmalıdır. HPa formül anahtarları bir pod üzerindeki Ready aşamasını neredeyse tamamen kapatır, bu nedenle sistem durumu araştırmalarının mevcut ve doğru olması önemlidir.
İzleme
Mikro Hizmetler uygulamasında uygulama performans yönetimi (APM) izleme, anormallikleri saptamak, sorunları tanılamak ve hizmetler arasındaki bağımlılıkları hızla anlamak için önemlidir. Azure izleyici 'nin bir parçası olan Application Insights, .net Core, Node.js, Java ve diğer birçok uygulama dilinde yazılmış canlı uygulamalar için APM izleme sağlar.
Application Insights:
- Gecikme ve sonuç kodu dahil olmak üzere HTTP isteklerini günlüğe kaydeder.
- Dağıtılmış izlemeyi varsayılan olarak sunar.
- İzlemelerde bir işlem KIMLIĞI içerir, bu nedenle belirli bir işlem için tüm izlemeleri eşleştirebilirsiniz.
- Genellikle izlemelerde ek bağlamsal bilgiler içerir.
Kubernetes dünyası ile hizmet telemetrisini bağlamak için, denetleyicilerle, düğümlerden ve kapsayıcılardan, kapsayıcı ve düğüm günlüklerinden ölçümler toplamak üzere Azure Izleyici telemetrisini AKS ile tümleştirin. .net kullanıyorsanız, kubernetes kitaplığı için Application Insights görüntü, kapsayıcı, düğüm, pod, etiket ve çoğaltma kümesi bilgileriyle telemetri Application Insights.
aşağıdaki diyagramda, aks mikro hizmetleri telemetri izlemesi için Application Insights oluşturduğu uygulama bağımlılığı eşlemesinin bir örneği gösterilmektedir:
Application Insights tümleştirmesi için ortak dilleri işaretleme seçenekleri hakkında daha fazla bilgi için bkz. Kubernetes Için uygulama izleme.
Ölçeklenebilirlik konusunda dikkat edilmesi gerekenler
Ölçeklenebilirlik planlaması yaparken aşağıdaki noktaları göz önünde bulundurun.
Otomatik ölçeklendirmeyi ve yineleme sayısının tanımlayıcı ya da bildirime dayalı yönetimini birleştirmeyin. Kullanıcılar ve bir otomatik korku, her ikisi de çoğaltmaların sayısını değiştirme girişimi beklenmedik davranışa neden olabilir. HPA etkinleştirildiğinde, dağıtılmasını istediğiniz en düşük numaraya sahip yineleme sayısını azaltın.
Pod otomatik ölçeklendirmesinin yan etkisi, ölçek genişletme ve ölçek genişletme olayları gerçekleştiği için sık sık oluşturulamayabilir veya çıkartılır. Bu etkileri azaltmak için:
- Yeni bir pod, trafiği kabul etmeye hazır olduğunda Kubernetes 'in bilmesini sağlamak için hazırlık araştırmaları kullanın.
- Tek seferde bir hizmetten kaç tane sayıda dizin çıkartılabilen sınırlamak için pod kesinti bütçelerini kullanın.
Bir 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ını yapın.
Çok kiracılı veya diğer gelişmiş iş yükleri, daha fazla ve büyük olasılıkla daha küçük alt ağları talep eden düğüm havuzu yalıtımı gereksinimlerine sahip olabilir. Şu anda genel önizleme aşamasında olan benzersiz alt ağlarla düğüm havuzları oluşturma hakkında daha fazla bilgi için bkz. benzersiz alt ağa sahip bir düğüm havuzu ekleme (Önizleme). Kuruluşların, hub-ışınsal içi uygulamalarına yönelik farklı standartları vardır. Kuruluş kılavuzlarınızı izlediğinizden emin olun.
Yönetilebilirlik konusunda dikkat edilmesi gerekenler
Yönetilebilirlik planlaması yaparken aşağıdaki noktaları göz önünde bulundurun.
AKS küme altyapısını otomatik dağıtım işlem hattı aracılığıyla yönetin. bu mimariye yönelik başvuru uygulamanız , işlem hattınızı oluştururken başvurabileceğinden kullanabileceğiniz bir GitHub eylemleri iş akışı sağlar.
İş akışı dosyası, yalnızca altyapıyı, iş yükünü değil, zaten mevcut sanal ağa ve Azure AD yapılandırmasına dağıtır. Altyapı ve iş yükünü ayrı olarak dağıtmak, ayrı yaşam döngüsünü ve işlemsel sorunları ele almanızı sağlar.
Bölgesel bir hata varsa, iş akışınızı başka bir bölgeye dağıtmak için bir mekanizma olarak düşünün. Yeni bir kümeyi parametre ve giriş değişikliklerini içeren yeni bir bölgede dağıtabilmeniz için işlem hattını oluşturun.
Güvenlik konuları
Güvenliği planlarken aşağıdaki noktaları göz önünde bulundurun.
AKS Pod, Azure AD 'de depolanan yönetilen bir kimlik ya da bır Azure AD hizmet sorumlusu ile bir istemci gizli anahtarı kullanarak kendi kimliğini doğrular. Bir pod kimliği kullanmak, bir istemci parolası gerektirmediğinden tercih edilir.
Yönetilen kimlikler sayesinde, yürütme işlemi Azure Resource Manager OAuth 2,0 belirteçlerini hızlıca alabilir; parola veya bağlantı dizesi gerekmez. aks 'de, Azure Active Directory (Azure AD) pod kimliğikullanarak tek tek ds 'ye kimlik atayabilirsiniz.
Mikro hizmet uygulamasındaki her hizmete, en az ayrıcalıklı RBAC atamalarını kolaylaştırmak için benzersiz bir pod kimliği atanmalıdır. Yalnızca bunları gerektiren hizmetlere kimlik atamalısınız.
Bir uygulama bileşeni için Kubernetes API erişimi gerektiren durumlarda, uygulama yığınlarının uygun şekilde kapsamlı bir API erişimi olan bir hizmetler hesabı kullanacak şekilde yapılandırıldığından emin olun. Kubernetes Services 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 Azure AD kullanarak veri düzlemi kimlik doğrulamasını desteklemez. Bu hizmetler için kimlik bilgilerini veya uygulama gizli dizilerini, üçüncü taraf hizmetleri veya API anahtarlarını depolamak için Azure Key Vault kullanın. Key Vault merkezi yönetim, erişim denetimi, bekleyen şifreleme ve tüm anahtar ve gizli dizileri denetleme sağlar.
AKS 'de, bir veya daha fazla gizli dizi Key Vault bir birim olarak bağlayabilirsiniz. Pod daha sonra normal bir birim gibi Key Vault gizli dizilerini okuyabilir. Daha fazla bilgi için, GitHub parolalar-mağaza-CSI-sürücü-sağlayıcı-Azure projesi ' ne bakın.
Fiyatlandırma
Microsoft Azure Well-Architected Framework'te Maliyet bölümünde maliyetle ilgili dikkat edilmesi gerekenler açıkmektedir. Senaryoya özgü maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın.
AKS'nin Kubernetes kümesi dağıtımı, yönetimi ve işlemleriyle ilişkili bir maliyeti yoktur. Yalnızca kümenin tükettiği SANAL makine örnekleri, depolama ve ağ kaynakları için ödeme ödersiniz. Küme otomatik ölçeklendirmesi, boş veya kullanılmayan düğümleri kaldırarak kümenin maliyetini önemli ölçüde düşürabilir.
Gerekli kaynakların maliyetini tahmin etmek için bkz. Container Services hesaplayıcısı.
Sonraki adımlar
- Azure Kubernetes Service (AKS) kümesi için temel mimari
- Kubernetes ile Azure'da mikro hizmetler tasarlama, derleme ve işletme
- AKS’de mikro hizmetler mimarisi
- AKS'de mikro hizmet mimarisini izleme
- Performans ayarlama senaryosu: Dağıtılmış iş işlemleri
- Kubernetes'te mikro hizmetler için CI/CD işlem hattı bina