Çok kiracılı kullanım için Azure Kubernetes Service (AKS) ile ilgili dikkat edilmesi gerekenler

Azure Kubernetes Service (AKS) , işletimsel yükü Azure bulut platformuna boşaltarak Azure'da yönetilen bir Kubernetes kümesi dağıtmayı kolaylaştırır. AKS barındırılan bir Kubernetes hizmeti olduğundan Azure, sistem durumu izleme ve bakım ile denetim düzlemi gibi kritik görevleri üstlenir.

AKS kümeleri farklı senaryolarda ve yollarla birden çok kiracı arasında paylaşılabilir. Bazı durumlarda, farklı uygulamalar aynı kümede çalıştırılabilir. Diğer durumlarda, aynı uygulamanın birden çok örneği, her kiracı için bir tane olacak şekilde aynı paylaşılan kümede çalıştırılabilir. Çok kiracılı terimi bu tür paylaşımları sık sık açıklar. Kubernetes'in son kullanıcılar veya kiracılar için birinci sınıf bir kavramı yoktur. Yine de, farklı kiracı gereksinimlerini yönetmenize yardımcı olacak çeşitli özellikler sağlar.

Bu makalede, çok kiracılı sistemler oluştururken kullanabileceğiniz AKS özelliklerinden bazıları açıklanmaktadır. Kubernetes çok kiracılılığıyla ilgili genel yönergeler ve en iyi yöntemler için Kubernetes belgelerindeki Çok kiracılı bakın.

Çok kiracılı türler

Aks kümesinin birden çok kiracıda nasıl paylaşıldığını belirlemenin ilk adımı, kullanılabilecek desenleri ve araçları değerlendirmektir. Genel olarak, Kubernetes kümelerindeki çok kiracılılık iki ana kategoriye ayrılır, ancak birçok varyasyon hala mümkündür. Kubernetes belgeleri çok kiracılı iki yaygın kullanım örneğini açıklar: birden çok ekip ve birden çok müşteri.

Birden çok ekip

Çoklu kiracının yaygın bir biçimi, bir kümeyi bir kuruluştaki birden çok ekip arasında paylaşmaktır. Her ekip bir veya daha fazla çözümü dağıtabilir, izleyebilir ve çalıştırabilir. Bu iş yüklerinin sıklıkla birbirleriyle ve aynı kümede veya diğer barındırma platformlarında bulunan diğer iç veya dış uygulamalarla iletişim kurması gerekir.

Ayrıca bu iş yüklerinin, aynı kümede barındırılan veya Azure'da hizmet olarak platform (PaaS) hizmetleri olarak çalışan ilişkisel veritabanı, NoSQL deposu veya mesajlaşma sistemi gibi hizmetlerle iletişim kurması gerekir.

Bu senaryoda, ekiplerin üyeleri genellikle kubectlgibi araçlar aracılığıyla Kubernetes kaynaklarına doğrudan erişime sahiptir. Ya da üyelerin Flux ve Argo CDgibi GitOps denetleyicileri aracılığıyla veya diğer sürüm otomasyonu araçları aracılığıyla dolaylı erişimi vardır.

Bu senaryo hakkında daha fazla bilgi için Kubernetes belgelerindeki Birden çok ekip bakın.

Birden çok müşteri

Sık sık kullanılan bir diğer çok kiracılılık biçimi, hizmet olarak yazılım (SaaS) satıcısıdır. Veya bir hizmet sağlayıcısı, müşterileri için ayrı kiracılar olarak kabul edilen bir iş yükünün birden çok örneğini çalıştırır. Bu senaryoda, müşterilerin AKS kümesine doğrudan erişimi yoktur, ancak yalnızca uygulamalarına erişebilirler. Ayrıca, uygulamalarının Kubernetes üzerinde çalıştığını bile bilmiyorlar. Maliyet iyileştirmesi genellikle kritik bir konudur. Hizmet sağlayıcıları, kaynak kotaları veağ ilkeleri gibi Kubernetes ilkelerini kullanarak iş yüklerinin birbirinden güçlü bir şekilde yalıtılmasını sağlar.

Bu senaryo hakkında daha fazla bilgi için Kubernetes belgelerindeki Birden çok müşteri konusuna bakın.

Yalıtım modelleri

Kubernetes belgelerine göre, çok kiracılı bir Kubernetes kümesi,kiracılar olarak adlandırılan birden çok kullanıcı ve iş yükü tarafından paylaşılır. Bu tanım, farklı ekiplerin veya bölümlerin kuruluş içinde paylaştığı Kubernetes kümelerini içerir. Ayrıca, bir SaaS uygulamasının müşteri başına örneklerini paylaşan kümeleri de içerir.

Küme çok kiracılılığı, birçok tek kiracılı ayrılmış kümeyi yönetmeye alternatiftir. Çok kiracılı bir Kubernetes kümesinin işleçleri kiracıları birbirinden yalıtmalıdır. Bu yalıtım, güvenliği aşılmış veya kötü amaçlı bir kiracının kümeye ve diğer kiracılara yapabilecekleri zararı en aza indirir.

Birkaç kullanıcı veya ekip aynı kümeyi sabit sayıda düğümle paylaştığında, bir ekip kaynakların eşit payından fazlasını kullanabilir. Yöneticiler bu sorunu gidermek için kaynak kotalarını kullanabilir.

Yalıtımın sağladığı güvenlik düzeyine bağlı olarak, yumuşak ve sabit çok kiracılılık arasında ayrım yapabilirsiniz.

• Geçici çoklu kiracı, kiracıların birbirine güvenen farklı ekipler veya departmanlar olduğu tek bir kuruluşta uygundur. Bu senaryoda yalıtım, iş yükü bütünlüğünü garanti etmeyi, farklı iç kullanıcı grupları genelinde küme kaynaklarını düzenlemeyi ve olası güvenlik saldırılarına karşı savunmayı hedefler.
• Sabit çok kiracılılık, heterojen kiracıların birbirine güvenmediği senaryoları genellikle güvenlik ve kaynak paylaşımı açısından açıklar.

Çok kiracılı bir AKS kümesi oluşturmayı planlarken, Kubernetes 'ın sağladığı kaynak yalıtımı ve çok kiracılılık katmanlarını göz önünde bulundurmanız gerekir:

• Küme
• Namespace
• Düğüm havuzu veya düğüm
• Pod
• Konteyner

Ayrıca, farklı kaynakların birden çok kiracı arasında paylaşılmasıyla ilgili güvenlik etkilerini göz önünde bulundurmanız gerekir. Örneğin, aynı düğümdeki farklı kiracılardan podları zamanlayarak kümede gereken makine sayısını azaltabilirsiniz. Öte yandan, belirli iş yüklerinin birlikte yerleştirilmesini engellemeniz gerekebilir. Örneğin, kuruluşunuzun dışındaki güvenilmeyen kodun hassas bilgileri işleyen kapsayıcılar ile aynı düğümde çalışmasına izin vermeyebilirsiniz.

Kubernetes kiracılar arasında mükemmel bir şekilde güvenli yalıtım garantisi vermese de, belirli kullanım örnekleri için yeterli olabilecek özellikler sunar. En iyi yöntem olarak, her kiracıyı ve Kubernetes kaynaklarını ad alanlarına ayırmanız gerekir. Daha sonra, kiracı yalıtımını zorlamak için Kubernetes rol tabanlı erişim denetimi (RBAC) ve ağ ilkelerini kullanabilirsiniz. Örneğin, aşağıdaki diyagramda aynı kümede aynı uygulamanın her kiracı için bir tane olan birden çok örneğini barındıran tipik SaaS sağlayıcı modeli gösterilmektedir. Her uygulama ayrı bir ad alanında bulunur.

AKS ile çok kiracılı çözümler tasarlamanın ve derlemenin çeşitli yolları vardır. Bu yöntemlerin her biri altyapı dağıtımı, ağ topolojisi ve güvenlik açısından kendi denge kümesiyle birlikte gelir. Bu yöntemler yalıtım düzeyini, uygulama eforunu, operasyonel karmaşıklığı ve maliyeti etkiler. Gereksinimlerinize göre denetim ve veri düzlemlerinde kiracı yalıtımı uygulayabilirsiniz.

Kontrol düzlemi yalıtımı

Denetim düzlemi düzeyinde yalıtımınız varsa, farklı kiracıların podlar ve hizmetler gibi diğer kişilerin kaynaklarına erişemediğini veya bu kaynakları etkileyemediğini garanti etmiş olursunuz. Ayrıca, diğer kiracıların uygulamalarının performansını da etkileyemezler. Daha fazla bilgi için Kubernetes belgelerindeki Denetim düzlemi yalıtım bakın. Denetim düzlemi düzeyinde yalıtım uygulamanın en iyi yolu, her kiracının iş yükünü ve Kubernetes kaynaklarını ayrı bir ad alanına ayırmaktır.

Kubernetes belgelerine göre ad alanı, tek bir kümedeki kaynak gruplarının yalıtımını desteklemek için kullandığınız bir soyutlamadır. Kubernetes kümesini paylaşan kiracı iş yüklerini yalıtmak için ad alanlarını kullanabilirsiniz.

• Ad alanları, ayrı kiracı iş yüklerinin birbirlerinin çalışmalarını etkileme riski olmadan kendi sanal çalışma alanlarında mevcut olmasını sağlar. Bir kuruluştaki ayrı ekipler ad alanlarını kullanarak projelerini birbirinden yalıtabilir çünkü adların çakışması riski olmadan farklı ad alanlarına aynı kaynak adlarını kullanabilirler.
• RBAC rolleri ve rol bağlamaları, ekiplerin kiracı kullanıcılarını ve işlemlerini yalnızca kendi ad alanları içindeki kaynaklara ve hizmetlere erişmek üzere sınırlandırmak için kullanabileceği ad alanı kapsamlı kaynaklardır. Farklı ekipler, izin veya yetenek listelerini tek bir ad altında gruplandırmak için roller tanımlayabilir. Ardından bu rolleri kullanıcı hesaplarına ve hizmet hesaplarına atayarak belirli bir ad alanında kaynaklara yalnızca yetkili kimliklerin erişebilmesini sağlar.
• CPU ve bellek için kaynak kotaları ad alanı nesneleridir. Ekipler, aynı kümeyi paylaşan iş yüklerinin sistem kaynağı tüketiminden güçlü bir şekilde yalıtıldığından emin olmak için bunları kullanabilir. Bu yöntem, ayrı bir ad alanında çalışan her kiracı uygulamasının çalışması için gereken kaynaklara sahip olduğundan emin olabilir ve aynı kümeyi paylaşan diğer kiracı uygulamalarını etkileyebilecekgürültülü komşu sorunlarını önleyebilir.
• Ağ ilkeleri, ekiplerin belirli bir kiracı uygulaması için hangi ağ trafiğine izin verildiğini zorlamak için benimseyebileceği ad alanı nesneleridir. Aynı kümeyi ağ perspektifinden paylaşan farklı iş yüklerini ayırmaya yönelik ağ ilkelerini kullanabilirsiniz.
• Farklı ad alanları içinde çalışan ekip uygulamaları, aynı küme, dış uygulamalar veya yönetilen hizmetler içindeki kaynaklara erişmek için farklı hizmet hesapları kullanabilir.
• Denetim düzlemi düzeyinde performansı geliştirmek için ad alanlarını kullanın. Paylaşılan kümedeki iş yükleri birden çok ad alanında düzenlenmişse, Kubernetes API'sinde işlemleri çalıştırırken aranacak daha az öğe vardır. Bu kuruluş API sunucusuna yönelik çağrıların gecikme süresini azaltabilir ve denetim düzleminin aktarım hızını artırabilir.

Ad alanı düzeyinde yalıtım hakkında daha fazla bilgi için Kubernetes belgelerinde aşağıdaki kaynaklara bakın:

• ad alanlarını
• erişim denetimlerini
• Kotaları

Veri düzlemi yalıtımı

Veri düzlemi yalıtımı, ayrı kiracıların podlarının ve iş yüklerinin birbirinden yeterince yalıtılmış olduğunu garanti eder. Daha fazla bilgi için Kubernetes belgelerindeki Veri düzlemi yalıtımı bölümüne bakın.

Ağ yalıtımı

Kubernetes'te modern, mikro hizmet tabanlı uygulamalar çalıştırdığınızda, genellikle hangi bileşenlerin birbiriyle iletişim kurabileceğini denetlemek istersiniz. Varsayılan olarak, AKS kümesindeki tüm podlar, aynı kümeyi paylaşan diğer uygulamalar da dahil olmak üzere kısıtlama olmadan trafik gönderebilir ve alabilir. Güvenliği geliştirmek için, trafik akışını denetlemek için ağ kuralları tanımlayabilirsiniz. Ağ ilkesi, podlar arasındaki iletişim için erişim ilkelerini tanımlayan bir Kubernetes belirtimidir. Aynı kümeyi paylaşan kiracı uygulamaları arasındaki iletişimi ayırmak için ağ ilkelerini kullanabilirsiniz.

AKS, ağ ilkelerini uygulamak için iki yol sağlar:

• Azure'ın, Azure ağ ilkeleri olarak adlandırılan ağ ilkeleri için uygulaması vardır.
• Calico ağ ilkeleri, Tigeratarafından kurulan bir açık kaynak ağ ve ağ güvenlik çözümüdür.

Her iki uygulama da belirtilen ilkeleri zorunlu kılmak için Linux iptable'larını kullanır. Ağ ilkeleri izin verilen ve izin verilmeyen IP çiftleri kümesine çevrilir. Bu çiftler daha sonra iptable filtre kuralları olarak programlanmıştır. Azure ağ ilkelerini yalnızca Azure CNI ağ eklentisiyle yapılandırılmış AKS kümeleriyle kullanabilirsiniz. Ancak, Calico ağ ilkeleri hem Azure CNI hem de kubenetdestekler. Daha fazla bilgi için bkz. Azure Kubernetes Service'da ağ ilkelerini kullanarak podlar arasındaki trafiğin güvenliğini sağlama .

Daha fazla bilgi için Kubernetes belgelerindeki Ağ yalıtımı bölümüne bakın.

Depolama yalıtımı

Azure, Azure SQL Veritabanı ve Azure Cosmos DBgibi zengin bir yönetilen PaaS veri depoları kümesi ve iş yükleriniz için kalıcı birimler olarak kullanabileceğiniz diğer depolama hizmetleri sunar. Paylaşılan AKS kümesinde çalışan kiracı uygulamalarıbir veritabanını veya dosya deposunu paylaşabilir veyaayrılmış bir veri deposu ve depolama kaynağı kullanabilir. Çok kiracılı bir senaryoda verileri yönetmeye yönelik farklı stratejiler ve yaklaşımlar hakkında daha fazla bilgi için bkz. Çok kiracılı çözümlerde depolama ve veriler için mimari yaklaşımlar.

AKS üzerinde çalışan iş yükleri verileri depolamak için kalıcı birimleri de kullanabilir. Azure'da, Azure Depolama'nın desteklediği Kubernetes kaynakları olarak kalıcı birimler oluşturabilirsiniz. Veri birimlerini el ile oluşturabilir ve bunları doğrudan podlara atayabilir veya AKS'nin bunlarıkalıcı birim talepleri kullanarak otomatik olarak oluşturmasını sağlayabilirsiniz. AKS, Azure Diskler, Azure Dosyalarve Azure NetApp Files desteği kalıcı birimler oluşturmak için yerleşik depolama sınıfları sağlar. Daha fazla bilgi için bkz. AKSuygulamaları için depolama seçeneklerini . Güvenlik ve dayanıklılık nedenleriyle, emptyDir ve hostPatharacılığıyla aracı düğümlerinde yerel depolama kullanmaktan kaçınmanız gerekir.

AKS yerleşik depolama sınıfları bir veya daha fazla kiracı için uygun olmadığında, farklı kiracıların gereksinimlerini karşılamak için özel depolama sınıfları oluşturabilirsiniz. Bu gereksinimler arasında birim boyutu, depolama SKU'su, hizmet düzeyi sözleşmesi (SLA), yedekleme ilkeleri ve fiyatlandırma katmanı yer alır.

Örneğin, her kiracı için özel bir depolama sınıfı yapılandırabilirsiniz. Daha sonra bu etiketi kullanarak ad alanında oluşturulan herhangi bir kalıcı birime etiket uygulayarak maliyetleri onlara yansıtabilirsiniz. Daha fazla bilgi için bkz. aksAzure etiketlerini kullanma .

Daha fazla bilgi için Kubernetes belgelerindeki Depolama yalıtımı bölümüne bakın.

Düğüm yalıtımı

gürültülü komşu sorunlarını önlemek ve bilgilerin açığa çıkması riskini azaltmak için kiracı iş yüklerini ayrı aracı düğümlerinde çalışacak şekilde yapılandırabilirsiniz. AKS'de yalıtım, güvenlik, mevzuat uyumluluğu ve performans için katı gereksinimleri olan kiracılar için ayrı bir küme veya yalnızca ayrılmış düğüm havuzu oluşturabilirsiniz.

Kiracıların podlarını yalnızca belirli bir düğüm kümesinde veya düğüm havuzu üzerinde çalışacak şekilde kısıtlamak için, tolerasyonları, düğüm etiketleri, düğüm seçicilerive düğüm benintitesi kullanabilirsiniz.

Genel olarak AKS, aşağıdakiler dahil olmak üzere çeşitli düzeylerde iş yükü yalıtımı sağlar:

• Çekirdek düzeyinde, paylaşılan aracı düğümlerinde basit sanal makinelerde (VM) kiracı iş yüklerini çalıştırarak ve Kata Kapsayıcılarıtabanlı Pod Korumalı Alanı kullanarak.
• Kiracı uygulamalarını ayrılmış kümelerde veya düğüm havuzlarında barındırarak fiziksel düzeyde.
• Donanım düzeyinde, Azure ayrılmış konaklarında kiracı iş yüklerini çalıştırarak, aracı düğümü VM'lerinin ayrılmış fiziksel makineler çalıştırmasını garanti eden. Donanım yalıtımı, kiracı iş yükleri için ek bir yalıtım katmanı sağlayan ayrılmış konaklara başka vm yerleştirilmesini sağlar.

Bu teknikleri birleştirebilirsiniz. Örneğin, donanım düzeyinde iş yükü ayırma ve fiziksel yalıtım elde etmek için Bir Azure Ayrılmış Konak grubu kiracı başına kümeleri ve düğüm havuzlarını çalıştırabilirsiniz. Ayrıca, Federal Bilgi İşlem Standardı (FIPS),gizli VM'leri veya konak tabanlı şifrelemedestekleyen paylaşılan veya kiracı başına düğüm havuzları oluşturabilirsiniz.

Bir düğüm kümesinin veya düğüm havuzunun maliyetini tek bir kiracıyla kolayca ilişkilendirmek ve ücretlendirmek için düğüm yalıtımını kullanın. Bu, çözümünüz tarafından benimsenen kiracı modeliyle kesinlikle ilgilidir.

Daha fazla bilgi için Kubernetes belgelerindeki Düğüm yalıtımı bölümüne bakın.

Kiracı modelleri

AKS daha fazla düğüm yalıtımı ve kiracı modeli türü sağlar.

Otomatik tek kiracılı dağıtımlar

Otomatik tek kiracılı dağıtım modelinde, bu örnekte gösterildiği gibi her kiracı için ayrılmış bir kaynak kümesi dağıtırsınız:

her birinin ayrı dağıtımları olan üç kiracıyı gösteren

Her kiracı iş yükü ayrılmış bir AKS kümesinde çalışır ve farklı bir Azure kaynakları kümesine erişir. Genellikle, bu modeli kullanarak oluşturduğunuz çok kiracılı çözümler, kod olarak altyapıyı (IaC)kapsamlı bir şekilde kullanır. Örneğin, BicepAzure Resource Manager, Terraformveya Azure Resource Manager REST API'leri kiracıya ayrılmış kaynakların isteğe bağlı dağıtımını başlatmaya ve koordine etmelerine yardımcı. Her bir müşteriniz için tamamen ayrı bir altyapı sağlamanız gerektiğinde bu yaklaşımı kullanabilirsiniz. Dağıtımınızı planlarken Dağıtım damgaları deseninikullanmayı göz önünde bulundurun.

Avantajları:

• Bu yaklaşımın temel avantajlarından biri, her kiracı AKS kümesinin API Sunucusu'nun ayrı olmasıdır. Bu yaklaşım, kiracılar arasında güvenlik, ağ ve kaynak tüketimi düzeyinde tam yalıtım sağlar. Kapsayıcının denetimini almayı yöneten bir saldırganın yalnızca tek bir kiracıya ait kapsayıcılara ve bağlı birimlere erişimi vardır. Tam yalıtım kiracı modeli, yüksek mevzuat uyumluluğu ek yükü olan bazı müşteriler için kritik öneme sahiptir.
• Kiracıların birbirlerinin sistem performansını etkileme olasılığı düşüktür, bu nedenlegürültülü komşu sorunlarını önlersiniz. Bu önemli nokta, API Server'a yönelik trafiği içerir. API sunucusu, herhangi bir Kubernetes kümesindeki paylaşılan, kritik bir bileşendir. API sunucusuna karşı kayıtsız, yüksek hacimli trafik oluşturan özel denetleyiciler kümenin dengesizliklerine neden olabilir. Bu dengesizlik istek hatalarına, zaman aşımlarına ve API yeniden deneme fırtınalarına yol açar. Aks kümesinin denetim düzleminin ölçeğini trafik talebini karşılayacak şekilde genişletmek için çalışma süresi SLA özelliğini kullanın. Yine de ayrılmış küme sağlamak, iş yükü yalıtımı açısından güçlü gereksinimleri olan müşteriler için daha iyi bir çözüm olabilir.
• Güncelleştirmeleri ve değişiklikleri kiracılar arasında aşamalı olarak dağıtabilirsiniz ve bu da sistem genelinde kesinti olasılığını azaltır. Her kaynak tek bir kiracı tarafından kullanıldığından Azure maliyetleri kiracılara kolayca geri yansıtılabilir.

Riskleri:

• Her kiracı ayrılmış bir kaynak kümesi kullandığından maliyet verimliliği düşüktür.
• Her kiracı için bir tane olmak üzere birden çok AKS kümesinde bakım etkinliklerini yinelemeniz gerektiğinden, devam eden bakımlar büyük olasılıkla zaman alır. operasyonel süreçlerinizi otomatikleştirmeyi ve değişiklikleri ortamlarınız aracılığıyla aşamalı olarak uygulamayı göz önünde bulundurun. Tüm varlığınız genelinde raporlama ve analiz gibi diğer dağıtımlar arası işlemler de yararlı olabilir. Birden çok dağıtımda verileri sorgulamayı ve işlemeyi planladığınıza emin olun.

Tamamen çok kiracılı dağıtımlar

Tamamen çok kiracılı bir dağıtımda tek bir uygulama tüm kiracıların isteklerine hizmet eder ve AKS kümesi de dahil olmak üzere tüm Azure kaynakları paylaşılır. Bu bağlamda, dağıtmak, izlemek ve bakımını yapmak için yalnızca bir altyapınız vardır. Aşağıdaki diyagramda gösterildiği gibi tüm kiracılar kaynağı kullanır:

Avantajları:

• Bu model, paylaşılan bileşenlerle bir çözümü çalıştırma maliyetinin düşük olması nedeniyle caziptir. Bu kiracı modelini kullandığınızda, daha büyük bir AKS kümesi dağıtmanız ve paylaşılan veri depoları için daha yüksek bir SKU benimsemeniz gerekebilir. Bu değişiklikler, veri depoları gibi tüm kiracı kaynaklarının oluşturduğu trafiğin sürdürülebilmesine yardımcı olur.

Riskleri:

• Bu bağlamda, tek bir uygulama tüm kiracıların isteklerini işler. Kiracıların uygulamayı çağrılarla dolup taşmasını önlemek için güvenlik önlemleri tasarlamanız ve uygulamanız gerekir. Bu çağrılar tüm sistemi yavaşlatabilir ve tüm kiracıları etkileyebilir.
• Trafik profili yüksek oranda değişkense, AKS kümesi otomatik ölçeklendiricisini pod ve aracı düğümlerinin sayısını değiştirecek şekilde yapılandırmanız gerekir. Yapılandırmanızı CPU ve bellek gibi sistem kaynağı kullanımına dayandırın. Alternatif olarak, özel ölçümlere göre pod ve küme düğümlerinin ölçeğini genişletebilir ve ölçeklendikleyebilirsiniz. Örneğin, Kubernetes tabanlı Event Driven Autoscaler (KEDA) kullanan bekleyen isteklerin sayısını veya dış mesajlaşma sisteminin ölçümlerini kullanabilirsiniz.
• Her kiracı için verileri ayırdığınızdan ve farklı kiracılar arasında veri sızıntısını önlemek için korumalar uyguladığınızdan emin olun.
• Azure maliyetlerini izlediğinden ve gerçek kullanımlarına bağlı olarak tek tek kiracılarla ilişkilendirdiğinden emin olun. kubecostgibi Microsoft dışı çözümler, farklı ekipler ve kiracılar arasında maliyetleri hesaplamanıza ve ayırmanıza yardımcı olabilir.
• Tek bir dağıtımda bakım daha kolay olabilir çünkü tek bir Azure kaynağı kümesini güncelleştirmeniz ve tek bir uygulamanın bakımını yapmak zorunda olmanız gerekir. Ancak, altyapı veya uygulama bileşenlerinde yapılan değişiklikler tüm müşteri tabanını etkileyebileceğinden de daha riskli olabilir.
• Ölçek sınırlamalarını da göz önünde bulundurmalısınız. Paylaşılan bir kaynak kümeniz olduğunda Azure kaynak ölçeği sınırlarına ulaşma olasılığınız daha yüksektir. Kaynak kotası sınırına ulaşmamak için kiracılarınızı birden çok Azure aboneliğine dağıtabilirsiniz.

Yatay olarak bölümlenmiş dağıtımlar

Alternatif olarak, çok kiracılı Kubernetes uygulamanızı yatay olarak bölümleyebilirsiniz. Bu yaklaşım tüm kiracılarda bazı çözüm bileşenlerini paylaşır ve tek tek kiracılar için ayrılmış kaynaklar dağıtır. Örneğin, bu çizimde gösterildiği gibi tek bir çok kiracılı Kubernetes uygulaması oluşturabilir ve ardından her kiracı için birer tane olmak üzere tek tek veritabanları oluşturabilirsiniz:

Avantajları:

• Yatay olarak bölümlenmiş dağıtımlar,gürültülü komşu sorunlarını azaltmanıza yardımcı olabilir. Kubernetes uygulamanızdaki trafik yükünün çoğunun, her kiracı için ayrı olarak dağıtabileceğiniz belirli bileşenlerden geldiğini belirlerseniz bu yaklaşımı göz önünde bulundurun. Örneğin, sorgu yükü yüksek olduğundan veritabanlarınız sisteminizin yükünün çoğunu alabilir. Tek bir kiracı çözümünüze çok sayıda istek gönderirse, veritabanının performansı olumsuz etkilenebilir, ancak uygulama katmanı gibi diğer kiracıların veritabanları ve paylaşılan bileşenleri etkilenmez.

Riskleri:

• Yatay olarak bölümlenmiş bir dağıtımda, bileşenlerinizin, özellikle de tek bir kiracının kullandığı bileşenlerin otomatik dağıtımını ve yönetimini göz önünde bulundurmanız gerekir.
• Bu model, iç ilke veya uyumluluk nedeniyle kaynakları diğer kiracılarla paylaşabilen müşteriler için gerekli yalıtım düzeyini sağlamayabilir.

Dikey bölümlenmiş dağıtımlar

Kiracıları birden çok AKS kümesi veya düğüm havuzu arasında dikey olarak bölümleyen bir karma model kullanarak tek kiracılı ve tamamen çok kiracılı modellerin avantajlarından yararlanabilirsiniz. Bu yaklaşım, önceki iki kiracı modeline göre aşağıdaki avantajları sağlar:

• Tek kiracılı ve çok kiracılı dağıtımların birleşimini kullanabilirsiniz. Örneğin, müşterilerinizin çoğunun çok kiracılı bir altyapıda aks kümesini ve veritabanını paylaşmasını sağlayabilirsiniz. Ayrıca, daha yüksek performans ve yalıtım gerektiren müşteriler için tek kiracılı altyapılar dağıtabilirsiniz.
• Kiracıları farklı yapılandırmalara sahip olabilecek birden çok bölgesel AKS kümesine dağıtabilirsiniz. Bu teknik en çok farklı coğrafyalara yayılmış kiracılarınız olduğunda etkilidir.

Bu kiracı modelinin farklı varyasyonlarını uygulayabilirsiniz. Örneğin, farklı işlev katmanlarına sahip çok kiracılı çözümünüzü farklı bir maliyetle sunmayı seçebilirsiniz. Fiyatlandırma modeliniz kaynak paylaşımı, performans, ağ ve veri ayrımları açısından her birinin artımlı performans ve yalıtım düzeyi sağlayan birden çok SKU sağlayabilir. Aşağıdaki katmanları göz önünde bulundurun:

• Temel katman: Kiracı istekleri, diğer kiracılarla paylaşılan tek, çok kiracılı bir Kubernetes uygulaması tarafından sunulur. Veriler, tüm Temel katman kiracılarının paylaştığı bir veya daha fazla veritabanında depolanır.
• Standart katman: Kiracı istekleri, güvenlik, ağ ve kaynak tüketimi açısından yalıtım sınırları sağlayan ayrı bir ad alanında çalışan ayrılmış bir Kubernetes uygulaması tarafından sunulur. Her kiracı için bir kiracı olan tüm kiracı uygulamaları, aynı AKS kümesini ve düğüm havuzunu diğer standart katman müşterilerle paylaşır.
• Premium katman: Kiracı uygulaması, daha yüksek bir SLA, daha iyi performans ve daha yüksek yalıtım derecesi sağlamak için ayrılmış düğüm havuzunda veya AKS kümesinde çalışır. Bu katman, kiracı uygulamasını barındıran aracı düğümlerinin sayısına ve SKU'sunu temel alan esnek bir maliyet modeli sağlayabilir. Ayrı kiracı iş yüklerini yalıtmak için ayrılmış kümelere veya düğüm havuzlarına alternatif bir çözüm olarak Pod Korumalı Alanı kullanabilirsiniz.

Aşağıdaki diyagramda, A ve B kiracılarının paylaşılan AKS kümesinde, C kiracısının ise ayrı bir AKS kümesinde çalıştığı bir senaryo gösterilmektedir.

Üç kiracıyı gösteren

Aşağıdaki diyagramda, A ve B kiracılarının aynı düğüm havuzunda, C kiracısının ise ayrılmış düğüm havuzunda çalıştığı bir senaryo gösterilmektedir.

Üç kiracıyı gösteren

Bu model, farklı katmanlar için farklı SLA'lar da sunabilir. Örneğin temel katman 99,9% çalışma süresi sunabilir, standart katman 99,95% çalışma süresi sunabilir ve premium katman 99,99% çalışma süresi sunabilir. Daha yüksek kullanılabilirlik hedefleri sağlayan hizmetleri ve özellikleri kullanarak daha yüksek SLA'yı uygulayabilirsiniz.

Avantajları:

• Altyapıyı paylaşmaya devam ettiğiniz için, çok kiracılı dağıtımları paylaşmanın bazı maliyet avantajlarından yararlanabilirsiniz. Aracı düğümleri için daha düşük maliyetli bir VM boyutu kullanan birden çok temel katman ve standart katman kiracı uygulaması arasında paylaşılan kümeleri ve düğüm havuzlarını dağıtabilirsiniz. Bu yaklaşım daha iyi yoğunluk ve maliyet tasarrufu sağlar. Premium katmanlı müşteriler için, DAHA yüksek VM boyutuna ve en fazla pod çoğaltması ve düğüm sayısına sahip AKS kümelerini ve düğüm havuzlarını daha yüksek bir fiyata dağıtabilirsiniz.
• CoreDNS, Konnectivityveya Azure Application Gateway Giriş Denetleyicisigibi sistem hizmetlerini ayrılmış bir sistem modu düğüm havuzunda çalıştırabilirsiniz. Kiracı uygulamasını bir veya daha fazla kullanıcı modu düğüm havuzunda çalıştırmak için, tolerasyonları, düğüm etiketleri,düğüm seçicileri ve düğüm benceliği kullanabilirsiniz.
• Paylaşılan kaynakları çalıştırmak için , tolerasyonları, düğüm etiketleri, düğüm seçicilerive düğüm benşim kullanabilirsiniz. Örneğin, belirli bir VM boyutuna, otomatik ölçeklendirici ayarlarına ve kullanılabilirlik alanları desteğine sahip ayrılmış bir düğüm havuzunda giriş denetleyicisine veya mesajlaşma sistemine sahip olabilirsiniz.

Riskleri:

• Hem çok kiracılı hem de tek kiracılı dağıtımları desteklemek için Kubernetes uygulamanızı tasarlamanız gerekir.
• Altyapılar arasında geçişe izin vermeyi planlıyorsanız, müşterileri çok kiracılı bir dağıtımdan kendi tek kiracılı dağıtımlarına geçirmeyi göz önünde bulundurmanız gerekir.
• Daha fazla AKS kümesini izlemek ve yönetmek için tutarlı bir stratejiye ve tek bir cam bölmesine veya tek bir bakış noktasına ihtiyacınız vardır.

Otomatik ölçeklendirme

Kiracı uygulamalarının oluşturduğu trafik talebine ayak uydurmak için, AKS'nin aracı düğümlerini ölçeklendirmek için küme otomatik ölçeklendiricisi etkinleştirebilirsiniz. Otomatik ölçeklendirme, sistemlerin aşağıdaki durumlarda yanıt vermeye devam etmelerine yardımcı olur:

• Trafik yükü belirli çalışma saatlerinde veya yılın dönemlerinde artar.
• Kiracı veya paylaşılan ağır yükler bir kümeye dağıtılır.
• Kullanılabilirlik alanında kesintiler nedeniyle aracı düğümleri kullanılamaz duruma gelir.

Düğüm havuzu için otomatik ölçeklendirmeyi etkinleştirdiğinizde, beklenen iş yükü boyutlarına göre en az ve en fazla düğüm sayısını belirtirsiniz. En fazla sayıda düğüm yapılandırarak, çalıştırdıkları ad alanından bağımsız olarak kümedeki tüm kiracı podları için yeterli alan sağlayabilirsiniz.

Trafik arttığında küme otomatik ölçeklendirmesi, CPU ve bellek gibi kaynak yetersizliklerinden dolayı podların beklemede duruma geçmesini önlemek için yeni aracı düğümleri ekler.

Yük azaldığında, küme otomatik ölçeklendirmesi belirtilen sınırlara göre düğüm havuzundaki aracı düğümlerinin sayısını azaltır ve bu da işlem maliyetlerinizi azaltmanıza yardımcı olur.

Podları kaynak taleplerine göre otomatik olarak ölçeklendirmek için pod otomatik ölçeklendirmesini kullanabilirsiniz. HorizontalPodAutoscaler, CPU veya bellek kullanımına veya özel ölçümlere göre pod çoğaltmalarının sayısını otomatik olarak ölçeklendirir. KEDAkullanarak, Kiracı uygulamalarının kullandığı Azure Event Hubs veya Azure Service Busgibi dış sistemlerden gelen olay sayısına göre Kubernetes'teki tüm kapsayıcıların ölçeğini artırabilirsiniz.

Dikey Pod Otomatik Ölçeklendiricisi (VPA) podlar için verimli kaynak yönetimi sağlar. VPA, podlara ayrılan CPU ve belleği ayarlayarak kiracı uygulamalarını çalıştırmak için gereken düğüm sayısını azaltmanıza yardımcı olur. Daha az düğüme sahip olmak toplam sahip olma maliyetini azaltır vegürültülü komşu sorunlarını önlemenize yardımcı olur.

Farklı kiracılar için daha iyi kaynak ayırma ve yalıtım sağlamak için düğüm havuzlarına Kapasite rezervasyon grupları atayın.

Bakım

Küme veya düğüm havuzu yükseltmeleri sırasında kiracı uygulamalarını etkileyebilecek kapalı kalma süresi riskini azaltmak için aks yoğun olmayan saatlerde planlı bakım zamanlayın. İş yükü etkisini en aza indirmek için kiracı uygulamalarını ve düğüm havuzlarını çalıştıran AKS kümelerinin denetim düzlemini güncelleştirmek için haftalık bakım pencereleri zamanlayın. Belirli bir günde bir gün veya saat aralığı belirterek kümenizde bir veya daha fazla haftalık bakım penceresi zamanlayabilirsiniz. Tüm bakım işlemleri zamanlanan pencereler sırasında gerçekleşir.

Güvenlik

Aşağıdaki bölümlerde AKS ile çok kiracılı çözümler için en iyi güvenlik yöntemleri açıklanmaktadır.

Küme erişimi

Bir kuruluştaki birden çok ekip arasında AKS kümesini paylaştığınızda, farklı kiracıları birbirinden yalıtmak için en az ayrıcalık ilkesini uygulamanız gerekir. Özellikle, kullanıcıların kubectl, Helm, Fluxveya Argo CDgibi araçları kullanırken yalnızca Kubernetes ad alanlarına ve kaynaklarına erişebildiğinden emin olmanız gerekir.

AKS ile kimlik doğrulaması ve yetkilendirme hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• AKS için erişim ve kimlik seçeneklerini
• AKS tarafından yönetilen Microsoft Entra tümleştirme
• AKS'de Microsoft Entra ID ile Kubernetes rol tabanlı erişim denetimini

İş yükü kimliği

Tek bir AKS kümesinde birden çok kiracı uygulaması barındırıyorsanız ve her uygulama ayrı bir ad alanındaysa, her iş yükü aşağı akış Azure hizmetlerine erişmek için farklı bir Kubernetes hizmet hesabı ve kimlik bilgileri kullanmalıdır. Hizmet hesapları, Kubernetes'teki birincil kullanıcı türlerinden biridir. Kubernetes API'sinde hizmet hesapları bulunur ve yönetilebilir. Hizmet hesabı kimlik bilgileri Kubernetes gizli dizileri olarak depolanır, bu nedenle yetkili podlar API Server ile iletişim kurmak için bunları kullanabilir. Çoğu API isteği, bir hizmet hesabı veya normal bir kullanıcı hesabı için kimlik doğrulama belirteci sağlar.

AKS kümelerine dağıttığınız kiracı iş yükleri, Azure Key Vault ve Microsoft Graph gibi Microsoft Entra ID korumalı kaynaklara erişmek için Microsoft Entra uygulama kimlik bilgilerini kullanabilir. Kubernetes için Microsoft Entra İş Yükü Kimliği, tüm dış kimlik sağlayıcılarıyla federasyon sağlamak için Kubernetes yerel özellikleriyle tümleşir.

Pod Korumalı Alanı

AKS, kapsayıcı uygulaması ile kapsayıcı konağının cpu, bellek ve ağ gibi paylaşılan çekirdek ve işlem kaynakları arasında yalıtım sınırı sağlayan Pod Korumalı Alanı adlı bir mekanizma içerir. Pod Korumalı Alanı, kiracı iş yüklerinin hassas bilgilerin güvenliğini sağlamasına ve Ödeme Kartı Endüstri Veri Güvenliği Standardı (PCI DSS), Uluslararası Standartlaştırma Kuruluşu (ISO) 27001 ve Sağlık Sigortası Taşınabilirlik ve Sorumluluk Yasası (HIPAA) gibi mevzuat, sektör veya idare uyumluluğu gereksinimlerini karşılamasına yardımcı olmak için diğer güvenlik önlemlerini veya veri koruma denetimlerini tamamlar.

Uygulamaları ayrı kümelere veya düğüm havuzlarına dağıtarak, farklı ekiplerin veya müşterilerin kiracı iş yüklerini güçlü bir şekilde yalıtabilirsiniz. Birden çok küme ve düğüm havuzu kullanmak, birçok kuruluşun ve SaaS çözümünün yalıtım gereksinimlerine uygun olabilir, ancak paylaşılan VM düğüm havuzlarına sahip tek bir kümenin daha verimli olduğu senaryolar vardır. Örneğin, aynı düğümde güvenilmeyen ve güvenilen podlar çalıştırdığınızda tek bir küme kullanabilir veya yerel iletişimi ve işlevsel gruplandırmayı hızlandırmak için aynı düğümde DaemonSets ve ayrıcalıklı kapsayıcıları birlikte kullanabilirsiniz. Pod Korumalı Alan, bu iş yüklerini ayrı kümelerde veya düğüm havuzlarında çalıştırmaya gerek kalmadan aynı küme düğümlerindeki kiracı uygulamalarını güçlü bir şekilde yalıtmanıza yardımcı olabilir. Diğer yöntemler kodunuzu yeniden derlemenizi veya diğer uyumluluk sorunlarına neden olmayı gerektirir, ancak AKS'deki Pod Korumalı Alanı gelişmiş bir güvenlik VM sınırı içinde değiştirilmemiş herhangi bir kapsayıcıyı çalıştırabilir.

AKS üzerinde Pod Korumalı Alanı, donanım tarafından zorlanan yalıtım sağlamak üzere AKS yığını için Azure Linux kapsayıcı konağı üzerinde çalışan Kata Kapsayıcıları temel alır. AKS'de Kata Kapsayıcıları, güvenliği sağlamlaştırılmış bir Azure hiper yöneticisi üzerinde oluşturulur. Bir üst VM düğümündeki kaynakları kullanan iç içe, basit bir Kata VM aracılığıyla pod başına yalıtım elde eder. Bu modelde, her Kata podu iç içe bir Kata konuk SANAL makinesinde kendi çekirdeğini alır. Kapsayıcıları üst VM'de çalıştırmaya devam ederken birden çok Kata kapsayıcısını tek bir konuk VM'ye yerleştirmek için bu modeli kullanın. Bu model, paylaşılan aks kümesinde güçlü bir yalıtım sınırı sağlar.

Daha fazla bilgi için bkz:

• AKS ile Pod Korumalı Alanı
• Pod Korumalı Alanı için AKS üzerinde Kata VM Yalıtılmış Kapsayıcıları için Desteği

Azure Ayrılmış Ana Bilgisayarı

Azure Ayrılmış Ana Bilgisayar, tek bir Azure aboneliğine ayrılmış fiziksel sunucular sağlayan ve fiziksel sunucu düzeyinde donanım yalıtımı sağlayan bir hizmettir. Bu ayrılmış konakları bir bölge, kullanılabilirlik alanı ve hata etki alanı içinde sağlayabilir ve VM'leri doğrudan sağlanan konaklara yerleştirebilirsiniz.

Aks ile Azure Ayrılmış Ana Bilgisayarı kullanmanın çeşitli avantajları vardır:

• Donanım yalıtımı, kiracı iş yükleri için ek bir yalıtım katmanı sağlayan ayrılmış konaklara başka vm yerleştirilmesini sağlar. Ayrılmış konaklar aynı veri merkezlerine dağıtılır ve diğer yalıtılmamış konaklarla aynı ağı ve temel depolama altyapısını paylaşır.

• Azure Ayrılmış Ana Bilgisayar, Azure platformunun başlattığı bakım olayları üzerinde denetim sağlar. Hizmetler üzerindeki etkiyi azaltmak ve kiracı iş yüklerinin kullanılabilirliğini ve gizliliğini sağlamaya yardımcı olmak için bir bakım penceresi seçebilirsiniz.

Azure Ayrılmış Ana Bilgisayar, SaaS sağlayıcılarının kiracı uygulamalarının hassas bilgilerin güvenliğini sağlamak için mevzuat, sektör ve idare uyumluluk gereksinimlerini karşıladığından emin olması konusunda yardımcı olabilir. Daha fazla bilgi için bkz. Aks kümesine Azure Ayrılmış Ana Bilgisayarı ekleme.

Karpenter

Karpenter, Kubernetes için oluşturulmuş bir açık kaynak düğüm yaşam döngüsü yönetim projesidir. Kubernetes kümesine Karpenter eklemek, bu kümede çalışan iş yüklerinin verimliliğini ve maliyetini artırabilir. Karpenter, Kubernetes zamanlayıcısının zamanlanamaz olarak işaretlediği podları izler. Ayrıca pod gereksinimlerini karşılayabilen düğümleri dinamik olarak sağlar ve yönetir.

Karpenter, yönetilen bir kümede düğüm sağlama ve iş yükü yerleştirme üzerinde ayrıntılı denetim sağlar. Bu denetim, kaynak ayırmayı iyileştirerek, her kiracının uygulamaları arasında yalıtım sağlayarak ve operasyonel maliyetleri azaltarak çok kiracılılığı geliştirir. AKS üzerinde çok kiracılı bir çözüm oluşturduğunuzda Karpenter, farklı kiracıları desteklemek için çeşitli uygulama gereksinimlerini yönetmenize yardımcı olacak kullanışlı özellikler sağlar. Örneğin, bazı kiracı uygulamalarının GPU için iyileştirilmiş düğüm havuzlarında, bazılarının ise bellek için iyileştirilmiş düğüm havuzlarında çalışması gerekebilir. Uygulamanız depolama için düşük gecikme süresi gerektiriyorsa, depolama ve uygulama katmanınızı birlikte kullanabilmeniz için bir pod için belirli bir kullanılabilirlik alanında çalışan bir düğüm gerektiğini belirtmek için Karpenter'ı kullanabilirsiniz.

AKS, Karpenter aracılığıyla AKS kümelerinde düğüm otomatik sağlamayı etkinleştirir. Kullanıcıların çoğu, Karpenter'ı yönetilen eklenti olarak etkinleştirmek için düğüm otomatik sağlama modunu kullanmalıdır. Daha fazla bilgi için bkz. düğüm otomatik sağlama. Daha gelişmiş özelleştirmeye ihtiyacınız varsa, Karpenter'ı kendi kendine barındırmayı seçebilirsiniz. Daha fazla bilgi için bkz. AKS Karpenter sağlayıcısı.

Gizli VM'ler

Kiracıların katı yalıtım, gizlilik ve güvenlik gereksinimlerini karşılamak üzere AKS kümenize bir veya daha fazla düğüm havuzu eklemek için gizli VM'leri kullanabilirsiniz. Gizli VM'lerdonanım tabanlı güvenilen yürütme ortamı kullanır. AMD Güvenli Şifrelenmiş Sanallaştırma - Güvenli İç İçe Disk Belleği (SEV-SNP) gizli VM'ler, vm belleğine ve durumuna hiper yönetici ve diğer konak yönetimi kodu erişimini reddeder ve bu da operatör erişimine karşı bir savunma katmanı ve ayrıntılı koruma sağlar. Daha fazla bilgi için bkz. AKS kümesinde gizli VM'leri kullanma.

Federal Bilgi İşlem Standartları (FIPS)

FIPS 140-3, bilgi teknolojisi ürün ve sistemlerinde şifreleme modülleri için minimum güvenlik gereksinimlerini tanımlayan bir ABD kamu standardıdır. AKS düğüm havuzları için FIPS uyumluluğunu etkinleştirerek kiracı iş yüklerinizin yalıtımını, gizliliğini ve güvenliğini geliştirebilirsiniz. FIPS uyumluluğu şifreleme, karma ve güvenlikle ilgili diğer işlemler için doğrulanmış şifreleme modüllerinin kullanılmasını sağlar. FIPS özellikli AKS düğüm havuzlarıyla, sağlam şifreleme algoritmaları ve mekanizmaları kullanarak mevzuat ve sektör uyumluluğu gereksinimlerini karşılayabilirsiniz. Azure, ÇOK kiracılı AKS ortamlarınızın güvenlik duruşunu güçlendirmenizi sağlayan AKS düğüm havuzları için FIPS'yi etkinleştirme hakkında belgeler sağlar. Daha fazla bilgi için bkz. AKS düğüm havuzları için FIPS'yi etkinleştirme.

Azure diskleriyle kendi anahtarlarınızı getirme (KAG)

Azure Depolama, aks kümesinin işletim sistemi ve veri diskleri de dahil olmak üzere bekleyen bir depolama hesabındaki tüm verileri şifreler. Varsayılan olarak, veriler Microsoft tarafından yönetilen anahtarlarla şifrelenir. Şifreleme anahtarları üzerinde daha fazla denetim için, AKS kümelerinizin diğer işletim sistemi ve veri disklerinde şifreleme için kullanılacak müşteri tarafından yönetilen anahtarlar sağlayabilirsiniz. Daha fazla bilgi için bkz:

• KAG'yi AKS'de Azure diskleriyle .
• azure disk depolamasunucu tarafı şifrelemesini .

Konak tabanlı şifreleme

AKS'de konak tabanlı şifreleme kiracı iş yükü yalıtımını, gizliliğini ve güvenliğini daha da güçlendirir. Konak tabanlı şifrelemeyi etkinleştirdiğinizde AKS, temel alınan konak makinelerinde bekleyen verileri şifreler ve bu da hassas kiracı bilgilerinin yetkisiz erişime karşı korunmasına yardımcı olur. Geçici diskler ve kısa ömürlü işletim sistemi diskleri, uçtan uca şifrelemeyi etkinleştirdiğinizde bekleyen platform tarafından yönetilen anahtarlarla şifrelenir.

AKS'de işletim sistemi ve veri diskleri varsayılan olarak platform tarafından yönetilen anahtarlarla sunucu tarafı şifreleme kullanır. Bu disklerin önbellekleri, platform tarafından yönetilen anahtarlarla beklemede şifrelenir. veri koruma anahtarı şifrelemek için kendi anahtarı şifreleme anahtarınızı zarf şifrelemesi (sarmalamaolarak da bilinir) belirtebilirsiniz. İşletim sistemi ve veri disklerinin önbelleği de belirttiğiniz BYOK şifrelenir.

Konak tabanlı şifreleme, çok kiracılı ortamlar için bir güvenlik katmanı ekler. Her kiracının işletim sistemi ve veri diski önbelleklerindeki verileri, seçilen disk şifreleme türüne bağlı olarak bekleyen müşteri tarafından yönetilen veya platform tarafından yönetilen anahtarlarla şifrelenir. Daha fazla bilgi için bkz:

• AKS üzerinde konak tabanlı şifrelemeyi
• AKS'da Azure diskleriyle KAG
• Azure Disk Depolama sunucu tarafı şifrelemesini

Ağ

Aşağıdaki bölümlerde AKS ile çok kiracılı çözümler için en iyi ağ yöntemleri açıklanmaktadır.

API sunucusuna ağ erişimini kısıtlama

Kubernetes'te API sunucusu, kümede kaynak oluşturma veya düğüm sayısını ölçeklendirme gibi eylemleri gerçekleştirmeye yönelik istekler alır. Bir kuruluştaki birden çok ekipte AKS kümesini paylaştığınızda, aşağıdaki çözümlerden birini kullanarak denetim düzlemine erişimi koruyun.

Özel AKS kümeleri

Özel aks kümesi kullanarak API sunucunuzla düğüm havuzlarınız arasındaki ağ trafiğinin sanal ağınızda kaldığından emin olabilirsiniz. Özel aks kümesinde, denetim düzlemi veya API sunucusu yalnızca AKS kümesinin aynı sanal ağında bulunan Azure özel uç noktasıaracılığıyla erişilebilen bir iç IP adresine sahiptir. Benzer şekilde, aynı sanal ağdaki tüm sanal makineler de özel uç nokta üzerinden denetim düzlemiyle özel olarak iletişim kurabilir. Daha fazla bilgi için bkz. özel AKS kümesi oluşturma.

Yetkili IP adresi aralıkları

Küme güvenliğini geliştirmek ve saldırıları en aza indirmek için ikinci seçenek,yetkili IP adresi aralıklarını kullanmaktır. Bu yaklaşım, genel AKS kümesinin denetim düzlemine erişimi iyi bilinen BIR IP adresleri ve Sınıfsız Inter-Domain Yönlendirme (CIDR) aralıkları listesiyle kısıtlar. Yetkili IP adreslerini kullandığınızda, bunlar hala genel kullanıma sunulur, ancak erişim bir dizi aralıkla sınırlıdır. Daha fazla bilgi için bkz. AKSyetkili IP adresi aralıklarını kullanarak API sunucusuna güvenli erişim .

Özel Bağlantı tümleştirmesi

Azure Özel Bağlantı hizmeti, uygulamaların bir sanal ağda tanımlanan ve bir Azure Load Balancer örneğinin ön uç IP yapılandırmasına bağlı Bir Azure özel uç nokta aracılığıyla hizmete özel olarak bağlanmasına olanak tanıyan bir altyapı bileşenidir. Özel Bağlantıile hizmet sağlayıcıları, hizmetlerini azure içinden veya şirket içinden veri sızdırma riskine gerek kalmadan kiracılarına güvenli bir şekilde sağlayabilir.

Özel Bağlantı hizmeti tümleştirme kullanarak kiracılara AKS tarafından barındırılan iş yüklerine güvenli bir şekilde özel bağlantı sağlayabilir ve genel İnternet'te herhangi bir genel uç noktayı kullanıma sunmanıza gerek kalmadan kullanabilirsiniz.

Azure'da barındırılan çok kiracılı bir çözüm için Özel Bağlantı'yı yapılandırma hakkında daha fazla bilgi için bkz. çok kiracılı ve özel bağlantı.

Ters proxy'ler

ters ara sunucu, genellikle kiracı uygulamalarının önünde gelen isteklerin güvenliğini sağlamak, filtrelemek ve göndermek için kullanılan bir yük dengeleyici ve API ağ geçidi. Popüler ters proxy'ler yük dengeleme, SSL sonlandırma ve katman 7 yönlendirme gibi özellikleri destekler. Ters proxy'ler genellikle güvenliği, performansı ve güvenilirliği artırmaya yardımcı olmak için uygulanır. Kubernetes için popüler ters proxy'ler aşağıdaki uygulamaları içerir:

• NGINX Giriş Denetleyicisi yük dengeleme, SSL sonlandırma ve katman 7 yönlendirme gibi gelişmiş özellikleri destekleyen popüler bir ters proxy sunucusudur.
• Traefik Kubernetes Giriş sağlayıcısı, giriş belirtimini destekleyerek küme hizmetlerine erişimi yönetmek için kullanılabilecek bir Kubernetes Giriş denetleyicisidir.
• HAProxy Kubernetes Giriş Denetleyicisi , Kubernetes için TLS sonlandırma, URL yolu tabanlı yönlendirme ve daha fazlası gibi standart özellikleri destekleyen başka bir ters ara sunucudur.
• Azure Application Gateway Giriş Denetleyicisi (AGIC), AKS müşterilerinin Azure'a özel Application Gateway L7 yük dengeleyiciyi kullanarak kiracı uygulamalarını genel İnternet'te veya şirket içinde sanal ağda çalışan diğer sistemlere sunmalarını sağlayan bir Kubernetes uygulamasıdır.

Birden çok kiracı uygulamasına gelen isteklerin güvenliğini sağlamaya ve işlemeye yardımcı olmak için AKS tarafından barındırılan bir ters ara sunucu kullandığınızda aşağıdaki önerileri göz önünde bulundurun:

• Ters ara sunucuyu, yüksek ağ bant genişliğine sahip ve hızlandırılmış ağ etkin VM boyutu kullanacak şekilde yapılandırılmış ayrılmış bir düğüm havuzunda barındırın.
• Otomatik ölçeklendirme için ters proxy'nizi barındıran düğüm havuzunu yapılandırın.
• Kiracı uygulamalarında gecikme süresinin ve zaman aşımlarının artmasından kaçınmak için, giriş denetleyicisi podlarının sayısının trafik dalgalanmalarıyla eşleşecek şekilde anında genişletilip daralabilmesi için bir otomatik ölçeklendirme ilkesi tanımlayın.
• Ölçeklenebilirlik ve ayrıştırma düzeyini artırmak için giriş denetleyicinizin birden çok örneğinde kiracı uygulamalarına gelen trafiği parçalamayı göz önünde bulundurun.

Azure Application Gateway Giriş Denetleyicisi (AGIC)kullandığınızda aşağıdaki en iyi yöntemleri uygulamayı göz önünde bulundurun:

• giriş denetleyicisinin otomatik ölçeklendirmeiçin kullandığı uygulama ağ geçidi yapılandırın. Otomatik ölçeklendirme etkinleştirildiğinde uygulama ağ geçidi ve web uygulaması güvenlik duvarı (WAF) v2 SKU'ları, uygulama trafiği gereksinimlerine göre ölçeği genişletebilir veya daraltabilir. Bu mod, uygulamanıza daha iyi esneklik sağlar ve uygulama ağ geçidi boyutunu veya örnek sayısını tahmin etme gereksinimini ortadan kaldırır. Bu mod, beklenen maksimum trafik yükü için ağ geçidinin en yüksek sağlanan kapasitede çalışmasını gerektirmeyerek maliyetlerden tasarruf etmenizi de sağlar. En düşük (ve isteğe bağlı olarak en yüksek) örnek sayısını belirtmeniz gerekir.
• Kiracı uygulama sayısısite sayısı en fazla sınırını aştığında, her biri ayrı bir uygulama ağ geçidiile ilişkilendirilmiş AGICbirden çok örneğini dağıtmayı düşünün. Her kiracı uygulamasının ayrılmış bir ad alanında çalıştığını varsayarsak, kiracı uygulamalarını AGICdaha fazla örneğine yaymak için birden çok ad alanı desteği kullanın.

Azure Front Door ile tümleştirme

Azure Front Door, dünya genelinde kullanıcılar ve web uygulamaları arasında hızlı, güvenilir ve güvenli erişim sağlayan, Microsoft'un küresel katman 7 yük dengeleyicisi ve modern bir bulut içeriği teslim ağıdır (CDN). Azure Front Door istek hızlandırma, SSL sonlandırma, yanıt önbelleğe alma, uçta WAF, URL tabanlı yönlendirme, yeniden yazma ve AKS tarafından barındırılan çok kiracılı uygulamaları genel İnternet'te kullanıma sunarken kullanabileceğiniz yeniden yönlendirmeler gibi özellikleri destekler.

Örneğin, tüm müşterilerin isteklerine hizmet vermek için AKS tarafından barındırılan çok kiracılı bir uygulama kullanmak isteyebilirsiniz. Bu bağlamda, her kiracı için bir tane olmak üzere birden çok özel etki alanını yönetmek için Azure Front Door'u kullanabilirsiniz. Uçta SSL bağlantılarını sonlandırabilir ve tüm trafiği tek bir ana bilgisayar adıyla yapılandırılmış AKS tarafından barındırılan çok kiracılı uygulamaya yönlendirebilirsiniz.

Azure Front Door ve AKS'nin nasıl bağlandığını gösteren

Azure Front Door'u istek kaynağı ana bilgisayar üst bilgisi arka uç uygulamasının etki alanı adıyla eşleşecek şekilde yapılandırabilirsiniz. İstemci tarafından gönderilen özgün üst bilgisi üst bilgisi aracılığıyla yayılır ve çok kiracılı uygulamanın kodu, gelen isteği doğru kiracıeşlemek için bu bilgileri kullanabilir.

Azure Front Door'da Azure Web Uygulaması Güvenlik Duvarı, web uygulamaları için merkezi koruma sağlar. Azure Web Uygulaması Güvenlik Duvarı, İnternet'te genel uç noktayı kötü amaçlı saldırılara karşı kullanıma sunan AKS tarafından barındırılan kiracı uygulamalarını savunmanıza yardımcı olabilir.

Azure Front Door Premium'u, Özel Bağlantıkullanarak bir AKS kümesinde çalışan bir veya daha fazla kiracı uygulamasına dahili yük dengeleyici kaynağı üzerinden özel olarak bağlanacak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz. Özel Bağlantıile Azure Front Door Premium'u iç yük dengeleyici kaynağına bağlama.

Giden bağlantılar

AKS tarafından barındırılan uygulamalar çok sayıda veritabanına veya dış hizmete bağlandığında, küme kaynak ağ adresi çevirisi (SNAT) bağlantı noktası tükenme riski altında olabilir. SNAT bağlantı noktaları, aynı işlem kaynakları kümesinde çalışan uygulamaların başlattığı ayrı akışları korumak için kullanılan benzersiz tanımlayıcılar oluşturur. Paylaşılan AKS kümesinde birkaç kiracı uygulaması çalıştırarak, SNAT bağlantı noktası tükenmesine yol açabilecek çok sayıda giden çağrı yapabilirsiniz. AKS kümesi giden bağlantıları üç farklı yolla işleyebilir:

• Azure Load Balancer: AKS varsayılan olarak çıkış bağlantıları için ayarlanacak ve kullanılacak bir Standart SKU Yük Dengeleyici sağlar. Ancak, genel IP adreslerine izin verilmiyorsa veya çıkış için ek atlamalar gerekiyorsa, varsayılan kurulum tüm senaryoların gereksinimlerini karşılamayabilir. Varsayılan olarak, genel yük dengeleyici, giden kurallarının kullandığı varsayılan bir genel IP adresiyle oluşturulur. Giden kuralları, genel standart yük dengeleyici için SNAT'yi açıkça tanımlamanıza olanak sağlar. Bu yapılandırma, arka uç örnekleriniz için giden İnternet bağlantısı sağlamak üzere yük dengeleyicinizin genel IP adreslerini kullanmanıza olanak tanır. Gerektiğinde,SNAT bağlantı noktası tükenmesini önlemek için, genel yük dengeleyicinin giden kurallarını daha fazla genel IP adresi kullanacak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz. Giden kuralları aracılığıyla giden için yük dengeleyicinin ön uç IP adresini kullanma.
• Azure NAT Gateway: Aks kümesini, kiracı uygulamalarından çıkış trafiğini yönlendirmek için Azure NAT Gateway kullanacak şekilde yapılandırabilirsiniz. NAT Gateway, genel IP adresi başına en fazla 16 IP adresi ile en fazla 64.512 giden UDP ve TCP trafik akışına izin verir. BIR AKS kümesinden giden bağlantıları işlemek için NAT Ağ Geçidi kullandığınızda SNAT bağlantı noktası tükenmesi riskini önlemek için ağ geçidine daha fazla genel IP adresi veya genel IP adresi ön eki ilişkilendirebilirsiniz. Daha fazla bilgi için bkz. Çok kiracılıiçin Azure NAT Gateway ile ilgili dikkat edilmesi gerekenler .
• kullanıcı tanımlı yol (UDR): Genel IP adreslerine izin vermeyen ve kümenin bir ağ sanal gerecinin (NVA) arkasında olmasını gerektirenler gibi özel ağ senaryolarını desteklemek için AKS kümesinin çıkış yolunu özelleştirebilirsiniz. kullanıcı tanımlı yönlendirmeiçin bir küme yapılandırdığınızda, AKS çıkış yollarını otomatik olarak yapılandırmaz. Çıkış kurulumunu tamamlamanız gerekir. Örneğin, çıkış trafiğini azure güvenlik duvarıüzerinden yönlendirirsiniz. AKS kümesini daha önce yapılandırdığınız bir alt ağa sahip mevcut bir sanal ağa dağıtmanız gerekir. Standart bir yük dengeleyici mimarisi kullanmadığınızda, açık çıkış oluşturmanız gerekir. Bu nedenle, bu mimari güvenlik duvarı, ağ geçidi veya ara sunucu gibi bir gerece çıkış trafiğinin açıkça gönderilmesini gerektirir. Ya da mimari, ağ adresi çevirisinin (NAT) standart yük dengeleyiciye veya alete atanmış bir genel IP tarafından gerçekleştirilmesini sağlar.

Izleme

Paylaşılan AKS kümesinde çalışan kiracı uygulamalarını izlemek ve tek tek ad alanları üzerindeki maliyet dökümlerini hesaplamak için azure İzleyici ve kapsayıcı içgörüleri kullanabilirsiniz. AKS'nin sistem durumunu ve performansını izlemek için Azure İzleyici'yi kullanın. Eğilimleri belirlemek ve kritik sorunları proaktif olarak size bildiren uyarıları yapılandırmak için toplanan verileringünlükleri ve ölçümleri, telemetri analizini ve görselleştirmelerini içerir. Bu izlemeyi genişletmek için kapsayıcı içgörüleri etkinleştirebilirsiniz.

Kubernetes izlemesi için yaygın olarak kullanılan Prometheus ve Grafanagibi açık kaynak araçları da benimseyebilirsiniz. Alternatif olarak, izleme ve gözlemlenebilirlik için Microsoft dışı diğer araçları da benimseyebilirsiniz.

Maliyet

Maliyet idaresi, maliyetleri denetlemeye yönelik ilkelerin sürekli uygulanması sürecidir. Kubernetes bağlamında kuruluşların maliyetleri denetlemek ve iyileştirmek için kullanabileceği çeşitli yöntemler vardır. Bu yöntemler, kaynak kullanımını ve tüketimini yönetmek ve temel altyapıyı proaktif olarak izlemek ve iyileştirmek için yerel Kubernetes araçlarını kullanmayı içerir. Kiracı başına maliyetleri hesaplarken, kiracı uygulamasının kullandığı herhangi bir kaynakla ilişkili maliyetleri dikkate almanız gerekir. Kiracılardan ücret almak için izlediğiniz yaklaşım, çözümünüzün benimsediği kiracı modeline bağlıdır. Aşağıdaki listede kiracı modelleri daha ayrıntılı olarak açıklanmaktadır:

• Tamamen çok kiracılı: Tek bir çok kiracılı uygulama tüm kiracı isteklerine hizmet ettiğinde, kaynak tüketimini ve her kiracının oluşturduğu istek sayısını izlemek sizin sorumluluğunuzdadır. Ardından müşterilerinizi buna göre ücretlendirebilirsiniz.
• Ayrılmış küme: Bir küme tek bir kiracıya ayrılmışsa Azure kaynaklarının maliyetlerini müşteriye geri göndermek kolaydır. Toplam sahip olma maliyeti, VM'lerin sayısı ve boyutu, ağ trafiğinin ağ maliyetleri, genel IP adresleri, yük dengeleyiciler ve kiracı çözümünün kullandığı yönetilen diskler veya Azure dosyaları gibi depolama hizmetleri gibi birçok faktöre bağlıdır. Maliyet ücretlendirme işlemlerini kolaylaştırmak için aks kümesini ve kaynaklarını düğüm kaynak grubunda etiketleyebilirsiniz. Daha fazla bilgi için bkz.kümeye etiket ekleme .
• Ayrılmış düğüm havuzu: Azure etiketini tek bir kiracıya ayrılmış yeni veya mevcut bir düğüm havuzuna uygulayabilirsiniz. Etiketler düğüm havuzundaki her düğüme uygulanır ve yükseltmeler aracılığıyla kalıcı hale uygulanır. Etiketler, genişleme işlemleri sırasında düğüm havuzuna eklenen yeni düğümlere de uygulanır. Etiket eklemek, ilke izleme veya maliyet ücretlendirme gibi görevlerde yardımcı olabilir. Daha fazla bilgi için bkz.düğüm havuzlarına etiket ekleme .
• Diğer kaynaklar: Ayrılmış kaynakların maliyetlerini belirli bir kiracıyla ilişkilendirmek için etiketleri kullanabilirsiniz. Özellikle kubernetes bildirimini kullanarak genel IP adreslerini, dosyaları ve diskleri etiketleyebilirsiniz. Bu şekilde ayarlanan etiketler, daha sonra başka bir yöntem kullanarak güncelleştirseniz bile Kubernetes değerlerini korur. Genel IP adresleri, dosyalar veya diskler Kubernetes aracılığıyla kaldırıldığında, Kubernetes kümelerinin tüm etiketleri kaldırılır. Kubernetes'in izlemediği kaynaklardaki etiketler etkilenmez. Daha fazla bilgi için bkz. Kuberneteskullanarak etiket ekleme.

AKS kümesinin maliyetini izlemek ve yönetmek için KubeCostgibi açık kaynak araçları kullanabilirsiniz. Maliyet ayırmanın kapsamını bir dağıtım, hizmet, etiket, pod ve ad alanına göre ayarlayabilirsiniz. Bu sayede kümenin kullanıcılarını geri alma veya geri gösterme konusunda esneklik sağlayabilirsiniz. Daha fazla bilgi için bkz. Kubecostile maliyet idaresi .

Çok kiracılı bir uygulamanın maliyetlerini ölçme, ayırma ve iyileştirme hakkında daha fazla bilgi için bkz. Çok kiracılı çözümde maliyet yönetimi ve ayırma için mimari yaklaşımlar. Maliyet iyileştirme hakkında genel yönergeler için Azure Well-Architected Framework makalesine bakın Maliyet İyileştirme sütununa genel bakış.

Yönetim

Birden çok kiracı aynı altyapıyı paylaştığında veri gizliliği, uyumluluk ve mevzuat gereksinimlerini yönetmek karmaşık hale gelebilir. Güçlü güvenlik önlemleri ve veri idaresi ilkeleri uygulamanız gerekir. Paylaşılan AKS kümeleri veri ihlali, yetkisiz erişim ve veri koruma düzenlemelerine uyumsuzluk riski daha yüksektir. Her kiracının benzersiz veri idare gereksinimleri ve uyumluluk ilkeleri olabilir ve bu da verilerin güvenliğini ve gizliliğini sağlamayı zorlaştırabilir.

Kapsayıcılar için Microsoft Defender, Kubernetes ortamları için tehdit algılama ve koruma özellikleri sağlayan buluta özel bir kapsayıcı güvenliği çözümüdür. Kapsayıcılar için Defender'ı kullanarak, bir Kubernetes kümesinde birden çok kiracı barındırırken veri idarenizi ve uyumluluk duruşunuzu geliştirebilirsiniz. Kapsayıcılar için Defender'ı kullanarak hassas verilerin korunmasına yardımcı olun, kapsayıcı davranışını ve ağ trafiğini analiz ederek tehditleri algılayıp yanıtlayın ve mevzuat gereksinimlerini karşılayın. Düzenleyicilere ve denetçilere uyumluluğu göstermek için denetim özellikleri, günlük yönetimi ve rapor oluşturma özellikleri sağlar.

Katkıda bulunan

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

• Paolo Salvatori | Baş Müşteri Mühendisi

Diğer katkıda bulunanlar:

• Bohdan Çerçilik | Kıdemli Müşteri Mühendisi
• John Downs | Baş Yazılım Mühendisi
• Chad Kittel | Baş Yazılım Mühendisi
• Arsen Vladimirskiy | Baş Müşteri Mühendisi

İlgili kaynak

• Çok kiracılı çözüm mimarları ve geliştiricileri için kaynaklar