Düzenle

Aracılığıyla paylaş

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

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS), işletimsel yükü Azure bulut platformuna devrederek Azure'da yönetilen bir Kubernetes kümesi dağıtmayı basitleştirir. Azure, barındırılan bir Kubernetes hizmeti olarak sistem durumu izleme ve bakım gibi kritik görevleri üstlenir. Azure platformu AKS denetim düzlemini yönetir ve yalnızca uygulamalarınızı çalıştıran AKS düğümleri için ödeme alırsınız.

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. Tüm bu paylaşım türleri sık sık çok kiracılı şemsiye terimi kullanılarak açıklanmaktadır. 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, AKS'nin çok kiracılı sistemler oluştururken yararlı olan bazı özellikleri 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ılık bölümüne bakın.

Çok kiracılı türler

Bir AKS kümesinin birden çok kiracıda nasıl paylaşılıp paylaştırılamını belirlemenin ilk adımı, kullanımda olan 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 çeşitleme hala mümkündür. Kubernetes belgelerinde çok kiracılı iki yaygın kullanım örneği açıklanmaktadır: 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.

Buna ek olarak, bu iş yüklerinin aynı kümede barındırılan veya Azure'da 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 kubectl gibi araçlar aracılığıyla Kubernetes kaynaklarına doğrudan erişime sahiptir. Ya da üyelerin Flux ve Argo CD gibi GitOps denetleyicileri veya diğer yayın otomasyon araçları türleri aracılığıyla dolaylı erişimi vardır.

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

Birden çok müşteri

Sık sık kullanılan diğer bir çok kiracı biçimi de 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ı, iş yüklerinin birbirinden güçlü bir şekilde yalıtıldığından emin olmak için kaynak kotaları ve ağ ilkeleri gibi Kubernetes ilkelerini kullanır.

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

Yalıtım modelleri

Kubernetes belgelerine göre, çok kiracılı bir Kubernetes kümesi genellikle kiracı 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, hizmet olarak yazılım (SaaS) uygulamasının müşteri başına örnekleri tarafından paylaşılan 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 ekibin kaynakların eşit payından daha fazlasını kullanabileceği konusunda endişe vardır. Kaynak Kotaları , yöneticilerin bu sorunu gidermesi için bir araçtır.

Yalıtım tarafından sağlanan güvenlik düzeyine bağlı olarak, yumuşak ve sabit çok kiracılılığı ayırt edebiliriz.

  • 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üklerinin 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.
  • Çok kiracılı sabit kiracı, heterojen kiracıların birbirine güvenmediği senaryoları tanımlamak için kullanılır. Bu senaryolar genellikle güvenlik ve kaynak paylaşımı açısından kullanılmaktadır.

Çok kiracılı bir Azure Kubernetes Service (AKS) kümesi oluşturmayı planlarken, Kubernetes tarafından sağlanan kaynak yalıtımı ve çok kiracılılık katmanlarını göz önünde bulundurmanız gerekir:

  • Küme
  • Ad Alanı
  • Düğüm havuzu veya düğüm
  • Pod
  • Kapsayıcı

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ıların podlarını zamanlamak kümede gereken makine sayısını azaltabilir. Ö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ğ İlkeleri'ni kullanabilirsiniz. Örneğin, aşağıdaki resimde 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.

Aynı kümede aynı uygulamanın birden çok örneğini barındıran bir SaaS sağlayıcı modelini gösteren diyagram.

Azure Kubernetes Service (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ı bölümüne 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 kullanılan bir soyutlamadır. Ad alanları, Kubernetes kümesini paylaşan kiracı iş yüklerini yalıtmak için kullanılabilir:

  • 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ü ad alanlarının çakışma 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 ad alanları içindeki kaynaklara ve hizmetlere erişmek üzere sınırlamak 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 bir 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 olmasını ve gürültülü komşu sorunlarından kaçınmasını sağlayabilir ve bu da aynı kümeyi paylaşan diğer kiracı uygulamalarını etkileyebilir.
  • 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:

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ı'na 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.

Azure Kubernetes Service (AKS), ağ ilkelerini uygulamak için iki yol sağlar:

  1. Azure'ın, Azure ağ ilkeleri olarak adlandırılan ağ ilkeleri için uygulaması vardır.
  2. Calico ağ ilkeleri, Tigera tarafından kurulan bir açık kaynak ağ ve ağ güvenliği çözümüdür.

Her iki uygulama da belirtilen ilkeleri zorunlu kılmak için Linux IPTable'ları 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 kubenet'i destekler. Daha fazla bilgi için bkz . Azure Kubernetes Service'te ağ ilkelerini kullanarak podlar arasındaki trafiğin güvenliğini sağlama.

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

Depolama yalıtımı

Azure, Azure SQL Veritabanı ve Azure Cosmos DB gibi yönetilen, hizmet olarak platform (PaaS) veri depoları 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 veya ayrı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.

Azure Kubernetes Service (AKS) üzerinde çalışan iş yükleri verileri depolamak için kalıcı birimleri de kullanabilir. Azure'da, Azure Depolama tarafından yedeklenen 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 Diskleri, Azure Dosyalar ve Azure NetApp Files tarafından yedeklenen kalıcı birimler oluşturmak için yerleşik depolama sınıfları sağlar. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) uygulamalar için depolama seçenekleri. Güvenlik ve dayanıklılık nedenleriyle, emptyDir ve hostPath aracı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ı 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. Bu senaryo hakkında daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) Azure 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 sorununu ö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 havuzlarında çalışacak şekilde kısıtlamak için renk tonları, toleranslar, düğüm etiketleri, düğüm seçicileri ve düğüm benzimliği kullanabilirsiniz.

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

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

Bu teknikleri birleştirebilirsiniz. Örneğin, bir Azure Ayrılmış Konak grubunda kiracı başına kümeleri ve düğüm havuzlarını çalıştırarak donanım düzeyinde iş yükü ayrımını ve fiziksel yalıtımı elde edebilirsiniz. Ayrıca Federal Bilgi İşlem Standardı (FIPS), Gizli Sanal Makineler (CVM) veya konak tabanlı şifrelemeyi destekleyen paylaşılan veya kiracı başına düğüm havuzları da oluşturabilirsiniz.

Düğüm yalıtımı, bir düğüm kümesinin veya düğüm havuzunun maliyetini tek bir kiracıyla kolayca ilişkilendirmenize ve geri ödemenize olanak tanır. Bu, çözümünüz tarafından benimsenen kiracı modeliyle kesinlikle ilgilidir.

Daha fazla bilgi için Kubernetes belgelerindeki Düğüm Yalıtımı'na bakın.

Kiralama modelleri

Azure Kubernetes Service (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 diyagram.

Her kiracı iş yükü ayrılmış bir AKS kümesinde çalışır ve farklı bir Azure kaynakları kümesine erişir. Genellikle, bu model kullanılarak oluşturulan çok kiracılı çözümler kod olarak altyapının (IaC) kapsamlı bir şekilde kullanılmasını sağlar. Örneğin, Bicep, Azure Resource Manager, Terraform veya Azure Resource Manager REST API'leri kiracıya ayrılmış kaynakların isteğe bağlı dağıtımını başlatmaya ve koordine etmede yardımcı olur. 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ı desenini kullanmayı 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 yalnızca tek bir kiracıya ait olan kapsayıcılara ve birimlere erişebilir. 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 ve bu da Gürültülü Komşu sorununu önlemenizi sağlar. 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. Çalışma Süresi SLA'sı (hizmet düzeyi sözleşmesi) özelliği, trafik talebini karşılamak için AKS kümesinin denetim düzleminin ölçeğini genişletmenize olanak tanır. 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ştirmeler ve değişiklikler kiracılar arasında aşamalı olarak dağıtılabilir 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.

Risk:

  • Her kiracı ayrılmış bir kaynak kümesi kullandığından maliyet verimliliği düşüktür.
  • Sürekli bakım, her kiracı için bir tane olmak üzere birden çok AKS kümesinde çoğaltılması gerektiğinden 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şlemleri de dikkate alırsanız bu size yardımcı olur. Benzer şekilde, 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ı kümeniz vardır. Aşağıdaki diyagramda gösterildiği gibi tüm kiracılar kaynağı kullanır:

Tümü tek bir paylaşılan dağıtım kullanan üç kiracıyı gösteren diyagram.

Avantajlar:

  • Bu model, paylaşılan bileşenlerle bir çözümü çalıştırma maliyetinin düşük olması nedeniyle caziptir. Bu kiracı modelini kullanırken, veri depoları gibi tüm kiracıların kaynakları tarafından oluşturulan trafiği sürdürmek için 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.

Riskler:

  • 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 ölçeği genişletebilir ve pod ve küme düğümlerinin sayısını ölçeklendikleyebilirsiniz. Örneğin, Kubernetes Event-driven Autoscaling (KEDA) kullanan bir dış mesajlaşma sisteminin bekleyen istek sayısını veya ölçümlerini inceleyebilirsiniz.
  • 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 göre tek tek kiracılarla ilişkilendirdiğinden emin olun. Kubecost gibi üçüncü taraf çözümler, farklı ekipler ve kiracılar genelinde maliyetleri hesaplamanıza ve ayırmanıza yardımcı olabilir.
  • Tek bir dağıtımda bakım daha kolay olabilir, çünkü yalnızca 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 müşteri tabanının tamamını etkileyebileceğinden bu durum genellikle daha risklidir.
  • Ö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 girmemek için kiracılarınızı birden çok Azure aboneliğine dağıtmayı düşünebilirsiniz.

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

Alternatif olarak, çok kiracılı Kubernetes uygulamanızı yatay olarak bölümleyebilirsiniz. Bu yaklaşım, bazı çözüm bileşenlerinin tüm kiracılar arasında paylaşılmasından ve tek tek kiracılar için ayrılmış kaynakların dağıtılmasından oluşur. Ö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:

Her birinde ayrılmış veritabanı ve tek bir paylaşılan Kubernetes uygulaması kullanan üç kiracıyı gösteren diyagram.

Avantajlar:

  • Yatay olarak bölümlenmiş dağıtımlar Gürültülü Komşu sorununu 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 kaynaklandığını belirlediyseniz 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 diğer kiracıların veritabanları (ve uygulama katmanı gibi paylaşılan bileşenler) etkilenmeden kalır.

Risk:

  • Yatay olarak bölümlenmiş bir dağıtımda, özellikle tek bir kiracı tarafından kullanılan bileşenler olmak üzere bileşenlerinizin otomatik dağıtımını ve yönetimini göz önünde bulundurmanız gerekir.
  • Bu model, iç ilkeler veya uyumluluk nedeniyle kaynakları diğer kiracılarla paylaşamayan 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. Yine de, daha yüksek performans ve yalıtım gerektiren müşteriler için tek kiracılı altyapılar da 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 biri 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ı tarafından paylaşılan bir veya daha fazla veritabanında depolanır.
  • Standart katman: Kiracı istekleri, güvenlik, ağ, 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 hizmet düzeyi sözleşmesi, 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ırmak için kullanılan aracı düğümlerinin sayısına ve SKU'sunu temel alan esnek bir maliyet modeli sağlayabilir. Farklı kiracı iş yüklerini yalıtmak için ayrılmış kümeler veya düğüm havuzları kullanmaya alternatif bir çözüm olarak Pod Korumalı Alanı'ni 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 diyagram. A ve B kiracıları aks kümesini paylaşır. C kiracısı ayrılmış bir AKS kümesine sahiptir.

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

Üç kiracıyı gösteren diyagram. A ve B kiracıları düğüm havuzunu paylaşır. C kiracısı ayrılmış bir düğüm havuzuna sahiptir.

Bu model, farklı katmanlar için farklı hizmet düzeyi sözleşmeleri de sunabilir. Örneğin temel katman %99,9 çalışma süresi, standart katman %99,95 çalışma süresi ve premium katman %99,99 çalışma süresi sunabilir. Daha yüksek hizmet düzeyi sözleşmesi (SLA), daha yüksek kullanılabilirlik hedefleri sağlayan hizmetler ve özellikler kullanılarak uygulanabilir.

Avantajlar:

  • Altyapıyı paylaşmaya devam ettiğiniz için, paylaşılan çok kiracılı dağıtımlara sahip olmanın bazı maliyet avantajlarından yararlanabilirsiniz. Aracı düğümleri için daha ucuz bir VM boyutu kullanan birden çok temel katman ve standart katman kiracı uygulaması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, Konnectivity veya Azure Uygulaması lication Gateway Giriş Denetleyicisi gibi 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 renk tonları, toleranslar, düğüm etiketleri, düğüm seçicileri ve düğüm benzini kullanabilirsiniz.
  • Paylaşılan kaynakları çalıştırmak için renk tonlarını, toleransları, düğüm etiketlerini, düğüm seçicileri ve düğüm benceliğini 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.

Risk:

  • 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ölmeye (tek bakış noktası) ihtiyacınız vardır.

Otomatik ölçeklendirme

Kiracı uygulamaları tarafından oluşturulan trafik talebine ayak uydurmak için azure kubernetes hizmetinizin (AKS) aracı düğümlerini ölçeklendirmek için küme otomatik ölçeklendiricisini 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.
  • Bölgesel 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 bakımından kaynak sıkıntısı nedeniyle podların bekleme durumunda olmasını önlemek için yeni aracı düğümleri ekler.

Benzer şekilde, 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.

Kaynak taleplerine göre podları otomatik olarak ölçeklendirmek için pod otomatik ölçeklendirmesini kullanabilirsiniz. Yatay Pod Otomatik Ölçeklendiricisi (HPA), CPU/bellek kullanımına veya özel ölçümlere göre pod çoğaltmalarının sayısını otomatik olarak ölçeklendirir. Kubernetes Olay Odaklı Otomatik Ölçeklendirme (KEDA) ile, kiracı uygulamaları tarafından kullanılan Azure Event Hubs veya Azure Service Bus gibi dış sistemlerin olay sayısına bağlı olarak Kubernetes'teki herhangi bir kapsayıcının ölçeklendirmesini yönlendirebilirsiniz.

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 Planlı Bakım'ı yoğun olmayan saatlerde gerçekleşecek şekilde zamanlayın. Planlı Bakım, 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 zamanlamanıza olanak tanır ve bu da iş yükü etkisini en aza indirir. 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

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, kubectl, Helm, Flux, Argo CD veya diğer araç türleri gibi araçları kullanırken kullanıcıların 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:

İş yükü kimliği

Tek bir AKS kümesinde birden çok kiracı uygulaması barındırıyorsanız ve her biri ayrı bir ad alanındaysa, her iş yükünün aşağı akış Azure hizmetlerine erişmek için farklı bir Kubernetes hizmet hesabı ve kimlik bilgileri kullanması gerekir. 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 ve bu sayede api sunucusuyla iletişim kurmak için yetkili podlar tarafından kullanılabilir. Ç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ğıtılan 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 federasyona yönelik Kubernetes yerel özellikleriyle tümleşir.

Pod Korumalı Alanı

AKS, kapsayıcı uygulaması ve paylaşılan çekirdek ile kapsayıcı konağının CPU, bellek ve ağ gibi 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ğıtmak, farklı ekiplerin veya müşterilerin kiracı iş yüklerini güçlü bir şekilde yalıtmanızı sağlar. 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üvenilir podlar çalıştırdığınızda veya yerel iletişim ve işlevsel gruplandırma için aynı düğümde DaemonSets ve ayrıcalıklı kapsayıcıları birlikte konumlandırdığınızda. 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ını 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. Pod başına yalıtım, bir üst VM düğümündeki kaynakları kullanan iç içe yerleştirilmiş bir basit Kata VM ile elde edilir. Bu modelde, her Kata podu iç içe bir Kata konuk SANAL makinesinde kendi çekirdeğini alır. Bu model, kapsayıcıları üst VM'de çalıştırmaya devam ederken tek bir konuk VM'ye birçok Kata kapsayıcısı yerleştirmenizi sağlar. Model, paylaşılan aks kümesinde güçlü bir yalıtım sınırı sağlar.

Daha fazla bilgi için bkz.

Azure Ayrılmış Konak

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ğlanabilir ve VM'leri doğrudan sağlanan konaklara yerleştirebilirsiniz.

AZURE Ayrılmış Ana Bilgisayarı'nı AKS ile kullanarak aşağıdakiler de dahil olmak üzere çeşitli avantajlar elde edebilirsiniz:

  • 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 platformu tarafından başlatılan 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 . Azure Kubernetes Service (AKS) kümesine Azure Ayrılmış Ana Bilgisayar ekleme.

Gizli Sanal Makineler

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 Sanal Makineler (CVM'ler) kullanabilirsiniz. CVM'ler donanım tabanlı bir güvenilen yürütme ortamı (TEE) kullanır. AMD Güvenli Şifrelenmiş Sanallaştırma - Güvenli İç İçe Disk Belleği (SEV-SNP) gizli VM'leri, hiper yöneticinin ve diğer konak yönetimi kodunun VM belleğine ve durumuna erişimini reddederek operatör erişimine karşı derinlemesine bir savunma katmanı ekler. Daha fazla bilgi için bkz . AKS kümesinde CVM'leri kullanma.

Federal Bilgi İşlem Standartları (FIPS)

FIPS 140-3 , bilgi teknolojisi ürün ve sistemlerindeki ş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 oluşturma 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.

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 konak makinelerinde bekleyen verileri şifreleyerek 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. Sarmalama olarak da bilinen zarf şifrelemesini kullanarak veri koruma anahtarını (DEK) şifrelemek için kendi anahtar şifreleme anahtarınızı (KEK) belirtebilirsiniz. İşletim sistemi ve veri diskleri için önbellek, belirttiğiniz KAG aracılığıyla da ş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.

Ağ

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 ekip arasında aks kümesi paylaşırken, 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 bir Azure özel uç noktası üzerinden 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 Azure Kubernetes Service kümesi oluşturma.

Yetkili IP'ler

Küme güvenliğini iyileştirmeye ve saldırıları en aza indirmeye yönelik ikinci seçenek, yetkili IP'ler kullanmaktır. Bu yaklaşım, genel AKS kümesinin denetim düzlemine erişimi İnternet Protokolü (IP) adreslerinin ve Sınıfsız Etki Alanları Arası Yönlendirme'nin (CIDR) iyi bilinen bir listesiyle kısıtlar. Yetkili IP'leri kullandığınızda, bunlar hala genel kullanıma sunulur, ancak erişim bir dizi IP aralığıyla sınırlıdır. Daha fazla bilgi için bkz . Azure Kubernetes Service'te (AKS) yetkili IP adresi aralıklarını kullanarak API sunucusuna güvenli erişim.

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

Azure Özel Bağlantı Hizmet Tümleştirmesi'ni 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 sunabilirsiniz.

Azure'da barındırılan çok kiracılı bir çözüm için Özel Bağlantı yapılandırma hakkında genel yönergeler için bkz. Çok kiracılılık ve Azure Ö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çididir. 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:

Birden çok kiracı uygulamasına gelen isteklerin güvenliğini sağlamak ve işlemek için AKS tarafından barındırılan bir ters ara sunucu kullanırken aşağıdaki önerileri göz önünde bulundurun:

  • Ters ara sunucuyu, yüksek ağ bant genişliğine ve hızlandırılmış ağ etkinleştirilmiş bir 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 Uygulaması lication Gateway Giriş Denetleyicisi'ni (AGIC) kullanırken aşağıdaki en iyi yöntemleri uygulamayı göz önünde bulundurun:

  • Otomatik Ölçeklendirme için giriş denetleyicisi tarafından kullanılan Application Gateway'i yapılandırın. Otomatik ölçeklendirme etkinleştirildiğinde Application Gateway ve 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 düzeyde sağlanan kapasitede çalışmasını gerektirmeyerek maliyet tasarrufu yapmanızı da sağlar. En düşük (ve isteğe bağlı olarak en yüksek) örnek sayısını belirtmeniz gerekir.
  • Kiracı uygulama sayısı en fazla site miktarını aştığında, her biri ayrı bir Application Gateway ile ilişkili Application Gateway Giriş Denetleyicisi'nin (AGIC) birden çok örneğini dağıtmayı göz önünde bulundurun. Her kiracı uygulamasının ayrılmış bir ad alanında çalıştığını varsayarsak, kiracı uygulamalarını Application Gateway Giriş Denetleyicisi'nin (AGIC) daha 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 küresel katman 7 yük dengeleyici ve Microsoft'un modern 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 yararlanabileceğ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 diyagram.

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

Azure Front Door'daki Azure Web Uygulaması Güvenlik Duvarı (WAF), web uygulamaları için merkezi koruma sağlar. Azure WAF'yi, İ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ı savunmak için kullanabilirsiniz.

Azure Front Door Premium'u, bir AKS kümesinde çalışan bir veya daha fazla kiracı uygulamasına dahili yük dengeleyici kaynağı üzerinden, Azure Özel Bağlantı Hizmeti kullanarak özel olarak bağlanacak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz. Azure Front Door Premium'u Özel Bağlantı ile 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 SNAT bağlantı noktası tükenme riski altında olabilir. SNAT Bağlantı Noktaları , aynı işlem kaynakları kümesinde çalışan uygulamalar tarafından başlatılan ayrı akışları korumak için kullanılan benzersiz tanımlayıcılar oluşturur. Paylaşılan bir Azure Kubernetes Service (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 Genel 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'lere izin verilmiyorsa veya çıkış için ek atlamalar gerekiyorsa, varsayılan kurulum tüm senaryoların gereksinimlerini karşılamayabilir. Varsayılan olarak, genel Load Balancer giden kuralları tarafından kullanılan varsayılan bir genel IP adresiyle oluşturulur. Giden kuralları, genel standart yük dengeleyici için kaynak ağ adresi çevirisini (SNAT) açıkça tanımlamanızı sağlar. Bu yapılandırma, arka uç örnekleriniz için giden İnternet bağlantısı sağlamak üzere yük dengeleyicinizin genel IP'lerini kullanmanıza olanak tanır. Gerektiğinde, SNAT bağlantı noktası tükenmesini önlemek için genel yük dengeleyicinin giden kurallarını ek genel IP adresleri kullanacak şekilde yapılandırabilirsiniz. Daha fazla bilgi için bkz . Giden kuralları aracılığıyla gidenler 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. AKS kümesinden giden bağlantıları işlemek için NAT Ağ Geçidi kullanırken SNAT bağlantı noktası tükenmesi riskini önlemek için ağ geçidiyle daha fazla genel IP adresi veya genel IP adresi ön eki ilişkilendirebilirsiniz. Daha fazla bilgi için bkz . Çok kiracılılık için Azure NAT Ağ Geçidi ile ilgili dikkat edilmesi gerekenler.
  • Kullanıcı tanımlı yol (UDR):Genel IP'lere 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. Bir kümeyi kullanıcı tanımlı yönlendirme için yapılandırdığınızda AKS çıkış yollarını otomatik olarak yapılandırmaz. Çıkış kurulumu sizin tarafınızdan yapılmalıdır. Örneğin, çıkış trafiğini bir Azure Güvenlik Duvarı üzerinden yönlendirirsiniz. AKS kümesinin daha önce yapılandırılmış bir alt ağ ile mevcut bir sanal ağa dağıtılması gerekir. Standart yük dengeleyici (SLB) 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.

İzleme

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 Container Insights'ı kullanabilirsiniz. Azure İzleyici, Azure Kubernetes Service'in (AKS) sistem durumunu ve performansını izlemenizi sağlar. Eğilimleri belirlemek ve kritik sorunları proaktif olarak size bildirmek için uyarıları yapılandırmak için toplanan verilerin günlükleri ve ölçümleri, telemetri analizini ve görselleştirmelerini içerir. Kapsayıcı içgörülerinin bu izlemeyi genişletmesini sağlayabilirsiniz.

Ayrıca, topluluk tarafından Kubernetes izlemesi için yaygın olarak kullanılan Prometheus ve Grafana gibi açık kaynak araçları da benimseyebilirsiniz. Alternatif olarak, izleme ve gözlemlenebilirlik için diğer üçüncü taraf araçlarını da benimseyebilirsiniz.

Maliyetler

Maliyet idaresi, maliyetleri denetlemeye yönelik ilkelerin sürekli uygulanması sürecidir. Kubernetes bağlamında kuruluşların maliyetleri denetlemesinin ve iyileştirmesinin çeşitli yolları vardır. Bunlar, 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ı içerir. Kiracı başına maliyetleri hesaplarken, kiracı uygulaması tarafından kullanılan herhangi bir kaynakla ilişkili maliyetleri dikkate almanız gerekir. Kiracılardan ücret almak için izlediğiniz yaklaşım, çözümünüz tarafından benimsenen kiracı modeline bağlıdır. Diğer ayrıntılar aşağıdaki kiracı modelleriyle açıklanmıştır:

  • Tamamen çok kiracılı: Tek, çok kiracılı bir uygulama tüm kiracı isteklerine hizmet ettiğinde, kaynak tüketimini ve her kiracı tarafından oluşturulan istek numarası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, sanal makinelerin sayısı ve boyutu, ağ trafiğinden kaynaklanan ağ maliyetleri, genel IP adresleri, yük dengeleyiciler, yönetilen diskler veya kiracı çözümü tarafından kullanılan 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. Düğüm havuzuna uygulanan etiketler, düğüm havuzu içindeki 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'leri, 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'ler, dosyalar veya diskler Kubernetes aracılığıyla kaldırıldığında, Kubernetes tarafından ayarlanan tüm etiketler kaldırılır. Kubernetes tarafından izlenmeyen kaynaklardaki etiketler etkilenmez. Daha fazla bilgi için bkz . Kubernetes kullanarak etiket ekleme.

Aks kümesi maliyetini izlemek ve yönetmek için KubeCost gibi açık kaynak araçları kullanabilirsiniz. Maliyet ayırmanın kapsamı bir dağıtım, hizmet, etiket, pod ve ad alanı olabilir ve bu da kümenin kullanıcılarını geri ödeme veya geri gösterme konusunda esneklik sağlar. Daha fazla bilgi için bkz . Kubecost ile maliyet idaresi.

Çok kiracılı bir uygulama için maliyetlerin ölçümü, ayrılması ve iyileştirilmesi hakkında daha fazla bilgi için bkz . Çok kiracılı bir çözümde maliyet yönetimi ve ayırma için mimari yaklaşımlar. Maliyet iyileştirme hakkında genel yönergeler için, Maliyet iyileştirme sütununa genel bakış başlıklı Azure İyi Tasarlanmış Çerçeve makalesine bakın

Katkıda Bulunanlar

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:

Diğer katkıda bulunanlar:

Sonraki adımlar

Çok kiracılı çözümlerin mimarları ve geliştiricileri için Kaynaklar'ı gözden geçirin.