Bewerken

Delen via

AKS-overwegingen (Azure Kubernetes Service) voor multitenancy

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) vereenvoudigt het implementeren van een beheerd Kubernetes-cluster in Azure door de operationele overhead naar het Azure-cloudplatform te offloaden. Omdat AKS een gehoste Kubernetes-service is, verwerkt Azure kritieke taken, zoals statuscontrole en onderhoud en het besturingsvlak.

AKS-clusters kunnen in verschillende scenario's en manieren worden gedeeld tussen meerdere tenants. In sommige gevallen kunnen diverse toepassingen in hetzelfde cluster worden uitgevoerd. In andere gevallen kunnen meerdere exemplaren van dezelfde toepassing worden uitgevoerd in hetzelfde gedeelde cluster, één voor elke tenant. De term multitenancy beschrijft vaak al deze typen delen. Kubernetes heeft geen eersteklas concept van eindgebruikers of tenants. Het biedt nog steeds verschillende functies om u te helpen bij het beheren van verschillende tenancyvereisten.

In dit artikel worden enkele van de functies van AKS beschreven die u kunt gebruiken bij het bouwen van systemen met meerdere tenants. Zie Multitenancy- in de Kubernetes-documentatie voor algemene richtlijnen en aanbevolen procedures voor Kubernetes-multitenancy.

Multitenancytypen

De eerste stap om te bepalen hoe u een AKS-cluster deelt tussen meerdere tenants, is het evalueren van de patronen en hulpprogramma's die beschikbaar zijn voor gebruik. Over het algemeen vallen multitenancy in Kubernetes-clusters in twee hoofdcategorieën, maar veel variaties zijn nog steeds mogelijk. In de Documentatie voor Kubernetes worden twee veelvoorkomende use cases voor multitenancy beschreven: meerdere teams en meerdere klanten.

Meerdere teams

Een veelvoorkomende vorm van multitenancy is het delen van een cluster tussen meerdere teams binnen een organisatie. Elk team kan een of meer oplossingen implementeren, bewaken en gebruiken. Deze workloads moeten vaak met elkaar communiceren en met andere interne of externe toepassingen die zich op hetzelfde cluster of andere hostingplatforms bevinden.

Daarnaast moeten deze workloads communiceren met services, zoals een relationele database, een NoSQL-opslagplaats of een berichtensysteem, dat wordt gehost in hetzelfde cluster of als PaaS-services (Platform as a Service) wordt uitgevoerd in Azure.

In dit scenario hebben leden van de teams vaak directe toegang tot Kubernetes-resources via hulpprogramma's, zoals kubectl. Of leden hebben indirecte toegang via GitOps-controllers, zoals Flux en Argo CD, of via andere typen hulpprogramma's voor releaseautomatisering.

Zie Meerdere teams in de Kubernetes-documentatie voor meer informatie over dit scenario.

Meerdere klanten

Een andere veelgebruikte vorm van multitenancy omvat vaak een SaaS-leverancier (Software as a Service). Of een serviceprovider voert meerdere exemplaren van een workload uit, die als afzonderlijke tenants worden beschouwd voor hun klanten. In dit scenario hebben de klanten geen directe toegang tot het AKS-cluster, maar hebben ze alleen toegang tot hun toepassing. Bovendien weten ze niet eens dat hun toepassing wordt uitgevoerd op Kubernetes. Kostenoptimalisatie is vaak een kritieke zorg. Serviceproviders gebruiken Kubernetes-beleid, zoals resourcequota en netwerkbeleid, om ervoor te zorgen dat de workloads sterk van elkaar worden geïsoleerd.

Zie Meerdere klanten in de Kubernetes-documentatie voor meer informatie over dit scenario.

Isolatiemodellen

Volgens de Kubernetes-documentatiewordt een Kubernetes-cluster met meerdere tenants gedeeld door meerdere gebruikers en workloads die vaak worden aangeduid als tenants. Deze definitie omvat Kubernetes-clusters die verschillende teams of afdelingen delen binnen een organisatie. Het bevat ook clusters die per klant exemplaren van een SaaS-toepassingsshare bevatten.

Cluster multitenancy is een alternatief voor het beheren van veel toegewezen clusters met één tenant. De operators van een Kubernetes-cluster met meerdere tenants moeten tenants van elkaar isoleren. Deze isolatie minimaliseert de schade die een aangetaste of schadelijke tenant kan doen voor het cluster en andere tenants.

Wanneer meerdere gebruikers of teams hetzelfde cluster delen met een vast aantal knooppunten, kan één team meer dan het evenredige aandeel van resources gebruiken. Beheerders kunnen resourcequota gebruiken om dit probleem aan te pakken.

Op basis van het beveiligingsniveau dat isolatie biedt, kunt u onderscheid maken tussen zachte en harde multitenancy.

  • Zachte multitenancy is geschikt binnen één onderneming waarbij tenants verschillende teams of afdelingen zijn die elkaar vertrouwen. In dit scenario is isolatie gericht op het garanderen van workloadintegriteit, het organiseren van clusterresources in verschillende interne gebruikersgroepen en het beschermen tegen mogelijke beveiligingsaanvallen.
  • Harde multitenancy beschrijft scenario's waarbij heterogene tenants elkaar niet vertrouwen, vaak vanuit het perspectief van beveiliging en het delen van resources.

Wanneer u van plan bent een AKS-cluster met meerdere tenants te bouwen, moet u rekening houden met de lagen resource-isolatie en multitenancy die Kubernetes biedt, waaronder:

  • Cluster
  • Namespace
  • Knooppuntgroep of knooppunt
  • Peul
  • Container

Daarnaast moet u rekening houden met de gevolgen voor de beveiliging van het delen van verschillende resources tussen meerdere tenants. U kunt bijvoorbeeld het aantal machines dat nodig is in het cluster verminderen door pods van verschillende tenants op hetzelfde knooppunt te plannen. Aan de andere kant moet u mogelijk voorkomen dat specifieke werkbelastingen worden gehost. U kunt bijvoorbeeld niet toestaan dat niet-vertrouwde code van buiten uw organisatie wordt uitgevoerd op hetzelfde knooppunt als containers die gevoelige informatie verwerken.

Hoewel Kubernetes geen perfecte veilige isolatie tussen tenants kan garanderen, biedt het wel functies die mogelijk voldoende zijn voor specifieke gebruiksvoorbeelden. Als best practice moet u elke tenant en de Bijbehorende Kubernetes-resources scheiden in hun naamruimten. U kunt vervolgens op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes gebruiken en netwerkbeleid om tenantisolatie af te dwingen. In het volgende diagram ziet u bijvoorbeeld het typische SaaS-providermodel dat als host fungeert voor meerdere exemplaren van dezelfde toepassing in hetzelfde cluster, één voor elke tenant. Elke toepassing bevindt zich in een afzonderlijke naamruimte.

diagram met een SaaS-providermodel dat als host fungeert voor meerdere exemplaren van dezelfde toepassing in hetzelfde cluster.

Er zijn verschillende manieren om multitenant-oplossingen te ontwerpen en te bouwen met AKS. Elk van deze methoden wordt geleverd met een eigen set compromissen, wat betreft de implementatie van infrastructuur, netwerktopologie en beveiliging. Deze methoden zijn van invloed op het isolatieniveau, de implementatie-inspanning, de operationele complexiteit en de kosten. U kunt tenantisolatie toepassen in de besturings- en gegevensvlakken op basis van uw vereisten.

Isolatie van besturingsvlak

Als u isolatie op het niveau van het besturingsvlak hebt, garandeert u dat verschillende tenants geen toegang hebben tot de resources van elkaar, zoals pods en services. Ze kunnen ook geen invloed hebben op de prestaties van de toepassingen van andere tenants. Zie Isolatie van besturingsvlak in de Kubernetes-documentatie voor meer informatie. De beste manier om isolatie op het niveau van het besturingsvlak te implementeren, is door de workload en de Kubernetes-resources van elke tenant te scheiden in een afzonderlijke naamruimte.

Volgens de Kubernetes-documentatieis een naamruimte een abstractie die u gebruikt ter ondersteuning van de isolatie van groepen resources binnen één cluster. U kunt naamruimten gebruiken om tenantworkloads te isoleren die een Kubernetes-cluster delen.

  • Met naamruimten kunnen afzonderlijke tenantworkloads in hun eigen virtuele werkruimte bestaan, zonder dat dit van invloed is op elkaars werk. Afzonderlijke teams binnen een organisatie kunnen naamruimten gebruiken om hun projecten van elkaar te isoleren, omdat ze dezelfde resourcenamen in verschillende naamruimten kunnen gebruiken zonder dat het risico bestaat dat namen elkaar overlappen.
  • RBAC-rollen en -rolbindingen naamruimte-resources zijn die teams kunnen gebruiken om tenantgebruikers en -processen te beperken voor toegang tot resources en services alleen in hun naamruimten. Verschillende teams kunnen rollen definiëren om lijsten met machtigingen of vaardigheden onder één naam te groeperen. Vervolgens wijzen ze deze rollen toe aan gebruikersaccounts en serviceaccounts om ervoor te zorgen dat alleen de geautoriseerde identiteiten toegang hebben tot de resources in een bepaalde naamruimte.
  • Resourcequota voor CPU en geheugen zijn naamruimteobjecten. Teams kunnen ze gebruiken om ervoor te zorgen dat workloads die hetzelfde cluster delen sterk worden geïsoleerd van het verbruik van systeembronnen. Deze methode kan ervoor zorgen dat elke tenanttoepassing die wordt uitgevoerd in een afzonderlijke naamruimte over de resources beschikt die nodig zijn om uit te voeren en problemen met lawaaierige burente voorkomen, wat van invloed kan zijn op andere tenanttoepassingen die hetzelfde cluster delen.
  • netwerkbeleid naamruimteobjecten zijn die teams kunnen gebruiken om af te dwingen welk netwerkverkeer is toegestaan voor een bepaalde tenanttoepassing. U kunt netwerkbeleid gebruiken om afzonderlijke workloads te scheiden die hetzelfde cluster delen vanuit een netwerkperspectief.
  • Teamtoepassingen die worden uitgevoerd in afzonderlijke naamruimten, kunnen verschillende serviceaccounts gebruiken om toegang te krijgen tot resources binnen hetzelfde cluster, externe toepassingen of beheerde services.
  • Gebruik naamruimten om de prestaties op het niveau van het besturingsvlak te verbeteren. Als workloads in een gedeeld cluster zijn ingedeeld in meerdere naamruimten, bevat de Kubernetes-API minder items om te zoeken bij het uitvoeren van bewerkingen. Deze organisatie kan de latentie van aanroepen op de API-server verminderen en de doorvoer van het besturingsvlak verhogen.

Zie de volgende resources in de Kubernetes-documentatie voor meer informatie over isolatie op naamruimteniveau:

Isolatie van gegevensvlak

Isolatie van gegevensvlakken garandeert dat pods en workloads van afzonderlijke tenants voldoende van elkaar worden geïsoleerd. Zie Isolatie van gegevensvlakken in de Kubernetes-documentatie voor meer informatie.

Netwerkisolatie

Wanneer u moderne, op microservices gebaseerde toepassingen uitvoert in Kubernetes, wilt u vaak bepalen welke onderdelen met elkaar kunnen communiceren. Standaard kunnen alle pods in een AKS-cluster zonder beperkingen verkeer verzenden en ontvangen, inclusief andere toepassingen die hetzelfde cluster delen. Om de beveiliging te verbeteren, kunt u netwerkregels definiëren om de verkeersstroom te beheren. Netwerkbeleid is een Kubernetes-specificatie die toegangsbeleid definieert voor communicatie tussen pods. U kunt netwerkbeleid gebruiken om de communicatie te scheiden tussen tenanttoepassingen die hetzelfde cluster delen.

AKS biedt twee manieren om netwerkbeleid te implementeren:

  • Azure heeft de implementatie voor netwerkbeleid, azure-netwerkbeleid genoemd.
  • Calico-netwerkbeleid is een opensource-netwerk- en netwerkbeveiligingsoplossing die is opgericht door Tigera.

Beide implementaties maken gebruik van Linux-iptables om het opgegeven beleid af te dwingen. Netwerkbeleid wordt omgezet in sets met toegestane en niet-toegestane IP-paren. Deze paren worden vervolgens geprogrammeerd als iptables-filterregels. U kunt alleen Azure-netwerkbeleid gebruiken met AKS-clusters die zijn geconfigureerd met de Azure CNI netwerkinvoegtoepassing. Calico-netwerkbeleid ondersteunt echter zowel Azure CNI- als kubenet-. Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in Azure Kubernetes Servicevoor meer informatie.

Zie Netwerkisolatie in de Kubernetes-documentatie voor meer informatie.

Opslagisolatie

Azure biedt een uitgebreide set beheerde PaaS-gegevensopslagplaatsen, zoals Azure SQL Database en Azure Cosmos DB, en andere opslagservices die u kunt gebruiken als permanente volumes voor uw workloads. Tenanttoepassingen die worden uitgevoerd op een gedeeld AKS-cluster kunnen een database of bestandsarchief delen, of ze kunnen een toegewezen gegevensopslagplaats en opslagresourcegebruiken. Zie Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingenvoor meer informatie over verschillende strategieën en benaderingen voor het beheren van gegevens in een scenario met meerdere tenants.

Workloads die worden uitgevoerd op AKS kunnen ook permanente volumes gebruiken om gegevens op te slaan. In Azure kunt u permanente volumes maken als Kubernetes-resources die door Azure Storage worden ondersteund. U kunt handmatig gegevensvolumes maken en deze rechtstreeks toewijzen aan pods, of u kunt AKS automatisch laten maken met behulp van permanente volumeclaims. AKS biedt ingebouwde opslagklassen voor het maken van permanente volumes die Azure Disks, Azure Filesen Ondersteuning voor Azure NetApp Files. Zie Storage-opties voor toepassingen in AKSvoor meer informatie. Om veiligheids- en tolerantieredenen moet u voorkomen dat u lokale opslag op agentknooppunten gebruikt via emptyDir- en hostPath-.

Wanneer AKS ingebouwde opslagklassen niet geschikt zijn voor een of meer tenants, kunt u aangepaste opslagklassen bouwen om te voldoen aan de vereisten van verschillende tenants. Deze vereisten omvatten volumegrootte, opslag-SKU, een SLA (Service Level Agreement), back-upbeleid en de prijscategorie.

U kunt bijvoorbeeld een aangepaste opslagklasse configureren voor elke tenant. U kunt deze vervolgens gebruiken om tags toe te passen op elk permanent volume dat in hun naamruimte is gemaakt om de kosten ervan terug te brengen. Zie Azure-tags gebruiken in AKS-voor meer informatie.

Zie Storage-isolatie in de Kubernetes-documentatie voor meer informatie.

Isolatie van knooppunten

U kunt tenantworkloads zo configureren dat deze worden uitgevoerd op afzonderlijke agentknooppunten om problemen met ruis te voorkomen en het risico op openbaarmaking van informatie te verminderen. In AKS kunt u een afzonderlijk cluster of alleen een toegewezen knooppuntgroep maken voor tenants met strikte vereisten voor isolatie, beveiliging, naleving van regelgeving en prestaties.

U kunt taints, toleranties, knooppuntlabels, knooppuntkiezersen knooppuntaffiniteit om de pods van tenants te beperken zodat ze alleen worden uitgevoerd op een bepaalde set knooppunten of knooppuntgroepen.

Over het algemeen biedt AKS isolatie van workloads op verschillende niveaus, waaronder:

  • Op kernelniveau door tenantworkloads uit te voeren op lichtgewicht virtuele machines (VM's) op gedeelde agentknooppunten en door gebruik te maken van Pod Sandboxing- op basis van Kata Containers.
  • Op fysiek niveau door tenanttoepassingen te hosten op toegewezen clusters of knooppuntgroepen.
  • Op hardwareniveau door tenantworkloads uit te voeren op toegewezen Azure-hosts die garanderen dat vm's met agentknooppunten toegewezen fysieke machines uitvoeren. Hardware-isolatie zorgt ervoor dat er geen andere VM's op de toegewezen hosts worden geplaatst, wat een extra isolatielaag biedt voor tenantworkloads.

U kunt deze technieken combineren. U kunt bijvoorbeeld clusters en knooppuntgroepen per tenant uitvoeren in een Azure Dedicated Host-groep om workloadscheiding en fysieke isolatie op hardwareniveau te bereiken. U kunt ook gedeelde of per tenant-knooppuntgroepen maken die ondersteuning bieden voor Federal Information Process Standard (FIPS), vertrouwelijke VM'sof op host gebaseerde versleuteling.

Gebruik knooppuntisolatie om eenvoudig de kosten van een set knooppunten of knooppuntgroep aan één tenant te koppelen en in rekening te brengen. Het is strikt gerelateerd aan het tenancymodel dat door uw oplossing wordt aangenomen.

Zie Knooppuntisolatie in de Kubernetes-documentatie voor meer informatie.

Tenancymodellen

AKS biedt meer typen knooppuntisolatie- en tenancymodellen.

Geautomatiseerde implementaties met één tenant

In een geautomatiseerd implementatiemodel met één tenant implementeert u een toegewezen set resources voor elke tenant, zoals wordt geïllustreerd in dit voorbeeld:

diagram met drie tenants, elk met afzonderlijke implementaties.

Elke tenantworkload wordt uitgevoerd in een toegewezen AKS-cluster en heeft toegang tot een afzonderlijke set Azure-resources. Doorgaans maken multitenant-oplossingen die u bouwt met behulp van dit model uitgebreid gebruik van infrastructuur als code (IaC). Bijvoorbeeld, Bicep, Azure Resource Manager, Terraformof de Azure Resource Manager REST API's helpen bij het initiëren en coördineren van de on-demand implementatie van tenant-toegewezen resources. U kunt deze benadering gebruiken wanneer u een volledig afzonderlijke infrastructuur moet inrichten voor elk van uw klanten. Overweeg bij het plannen van uw implementatie het patroon Implementatiestempelste gebruiken.

Voordelen:

  • Een belangrijk voordeel van deze benadering is dat de API-server van elk tenant-AKS-cluster afzonderlijk is. Deze aanpak garandeert volledige isolatie tussen tenants op basis van een niveau van beveiliging, netwerken en resourceverbruik. Een aanvaller die de controle over een container krijgt, heeft alleen toegang tot de containers en gekoppelde volumes die tot één tenant behoren. Een volledig isolatietenancymodel is essentieel voor sommige klanten met een hoge overhead voor naleving van regelgeving.
  • Tenants zijn waarschijnlijk niet van invloed op elkaars systeemprestaties, dus u voorkomt problemen met ruis. Deze overweging omvat het verkeer op basis van de API-server. De API-server is een gedeeld, kritiek onderdeel in een Kubernetes-cluster. Aangepaste controllers, die ongereguleerd, hoog volumeverkeer op de API-server genereren, kunnen instabiliteit van het cluster veroorzaken. Deze instabiliteit leidt tot mislukte aanvragen, time-outs en API-stormen voor opnieuw proberen. Gebruik de SLA-functie voor uptime om het besturingsvlak van een AKS-cluster uit te schalen om te voldoen aan de vraag naar verkeer. Het inrichten van een toegewezen cluster is mogelijk een betere oplossing voor klanten met sterke vereisten in termen van workloadisolatie.
  • U kunt updates en wijzigingen geleidelijk implementeren in tenants, waardoor de kans op een storing in het hele systeem wordt verminderd. Azure-kosten kunnen eenvoudig worden teruggeschreven naar tenants omdat elke resource wordt gebruikt door één tenant.

risico's:

  • Kostenefficiëntie is laag omdat elke tenant gebruikmaakt van een toegewezen set resources.
  • Doorlopend onderhoud is waarschijnlijk tijdrovend omdat u onderhoudsactiviteiten moet herhalen in meerdere AKS-clusters, één voor elke tenant. Overweeg om uw operationele processen te automatiseren en wijzigingen geleidelijk toe te passen via uw omgevingen. Andere bewerkingen voor meerdere implementaties, zoals rapportage en analyses in uw hele omgeving, kunnen ook nuttig zijn. Zorg ervoor dat u van plan bent om gegevens op te vragen en te manipuleren in meerdere implementaties.

Volledig multitenant-implementaties

In een volledig multitenant-implementatie dient één toepassing de aanvragen van alle tenants en worden alle Azure-resources gedeeld, inclusief het AKS-cluster. In deze context hebt u slechts één infrastructuur om te implementeren, bewaken en onderhouden. Alle tenants gebruiken de resource, zoals wordt geïllustreerd in het volgende diagram:

Een diagram met drie tenants die allemaal één gedeelde implementatie gebruiken.

Voordelen:

  • Dit model is aantrekkelijk vanwege de lagere kosten voor het gebruik van een oplossing met gedeelde onderdelen. Wanneer u dit tenancymodel gebruikt, moet u mogelijk een groter AKS-cluster implementeren en een hogere SKU gebruiken voor elke gedeelde gegevensopslagplaats. Deze wijzigingen helpen het verkeer te ondersteunen dat alle tenantresources, zoals gegevensopslagplaatsen, genereren.

risico's:

  • In deze context verwerkt één toepassing alle aanvragen van de tenants. U moet beveiligingsmaatregelen ontwerpen en implementeren om te voorkomen dat tenants de toepassing overspoelen met aanroepen. Deze aanroepen kunnen het hele systeem vertragen en van invloed zijn op alle tenants.
  • Als het verkeersprofiel zeer variabel is, moet u de automatische schaalaanpassing van het AKS-cluster configureren om het aantal pods en agentknooppunten te variëren. Baseer uw configuratie op het systeemresourcegebruik, zoals CPU en geheugen. U kunt ook uitschalen en schalen in het aantal pods en clusterknooppunten op basis van aangepaste metrische gegevens. U kunt bijvoorbeeld het aantal aanvragen in behandeling of de metrische gegevens van een extern berichtensysteem gebruiken dat gebruikmaakt van Op Kubernetes gebaseerde Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA).
  • Zorg ervoor dat u de gegevens voor elke tenant scheidt en beveiliging implementeert om gegevenslekken tussen verschillende tenants te voorkomen.
  • Zorg ervoor dat u Azure-kosten bijhouden en koppelen aan afzonderlijke tenants, op basis van hun werkelijke gebruik. Niet-Microsoft-oplossingen, zoals kubecost, kunnen u helpen bij het berekenen en opsplitsen van kosten voor verschillende teams en tenants.
  • Onderhoud kan eenvoudiger zijn met één implementatie, omdat u slechts één set Azure-resources hoeft bij te werken en één toepassing te onderhouden. Het kan echter ook riskanter zijn omdat wijzigingen in de infrastructuur of toepassingsonderdelen van invloed kunnen zijn op het hele klantenbestand.
  • U moet ook rekening houden met schaalbeperkingen. De kans is groter dat u limieten voor Azure-resourceschaal bereikt wanneer u een gedeelde set resources hebt. Om te voorkomen dat u een quotumlimiet voor resources bereikt, kunt u uw tenants verdelen over meerdere Azure-abonnementen.

Horizontaal gepartitioneerde implementaties

U kunt ook overwegen om uw Multitenant Kubernetes-toepassing horizontaal te partitioneren. Deze benadering deelt enkele oplossingsonderdelen in alle tenants en implementeert toegewezen resources voor afzonderlijke tenants. U kunt bijvoorbeeld één Kubernetes-toepassing met meerdere tenants bouwen en vervolgens afzonderlijke databases maken, één voor elke tenant, zoals wordt weergegeven in deze afbeelding:

een diagram met drie tenants. Elk maakt gebruik van een toegewezen database en één gedeelde Kubernetes-toepassing.

Voordelen:

  • Horizontaal gepartitioneerde implementaties kunnen u helpen bij het beperken van problemen met lawaaierige buren. Houd rekening met deze benadering als u identificeert dat de meeste verkeersbelasting voor uw Kubernetes-toepassing wordt veroorzaakt door specifieke onderdelen, die u afzonderlijk kunt implementeren voor elke tenant. Uw databases kunnen bijvoorbeeld de meeste belasting van uw systeem absorberen omdat de querybelasting hoog is. Als één tenant een groot aantal aanvragen naar uw oplossing verzendt, blijven de prestaties van een database mogelijk negatief beïnvloed, maar blijven de databases en gedeelde onderdelen van andere tenants, zoals de toepassingslaag, ongewijzigd.

risico's:

  • Met een horizontaal gepartitioneerde implementatie moet u nog steeds rekening houden met de geautomatiseerde implementatie en het beheer van uw onderdelen, met name de onderdelen die door één tenant worden gebruikt.
  • Dit model biedt mogelijk niet het vereiste isolatieniveau voor klanten die geen resources kunnen delen met andere tenants om redenen van intern beleid of naleving.

Verticaal gepartitioneerde implementaties

U kunt profiteren van de voordelen van de modellen met één tenant en volledig multitenant met behulp van een hybride model waarmee tenants verticaal worden gepartitioneerd in meerdere AKS-clusters of knooppuntgroepen. Deze aanpak biedt de volgende voordelen ten opzichte van de vorige twee tenancymodellen:

  • U kunt een combinatie van implementaties met één tenant en meerdere tenants gebruiken. U kunt bijvoorbeeld de meeste klanten een AKS-cluster en -database laten delen in een infrastructuur met meerdere tenants. U kunt ook infrastructuren met één tenant implementeren voor klanten die hogere prestaties en isolatie nodig hebben.
  • U kunt tenants implementeren in meerdere regionale AKS-clusters, mogelijk met verschillende configuraties. Deze techniek is het meest effectief wanneer u tenants verspreid over verschillende geografische gebieden hebt.

U kunt verschillende variaties van dit tenancymodel implementeren. U kunt er bijvoorbeeld voor kiezen om uw multitenant-oplossing met verschillende functionaliteitslagen tegen verschillende kosten aan te bieden. Uw prijsmodel kan meerdere SKU's bieden die elk een incrementeel prestatie- en isolatieniveau bieden in termen van resourcedeling, prestaties, netwerk en gegevensscheiding. Houd rekening met de volgende lagen:

  • Basic-laag: de tenantaanvragen worden verwerkt door één Multitenant Kubernetes-toepassing die wordt gedeeld met andere tenants. Gegevens worden opgeslagen in een of meer databases die alle Tenants in de Basic-laag delen.
  • Standard-laag: Tenantaanvragen worden geleverd door een toegewezen Kubernetes-toepassing die wordt uitgevoerd in een afzonderlijke naamruimte, die isolatiegrenzen biedt wat betreft beveiliging, netwerken en resourceverbruik. Alle tenanttoepassingen, één voor elke tenant, delen hetzelfde AKS-cluster en dezelfde knooppuntgroep met andere klanten in de standard-laag.
  • Premium-laag: de tenanttoepassing wordt uitgevoerd in een toegewezen knooppuntgroep of een AKS-cluster om een hogere SLA, betere prestaties en een hogere mate van isolatie te garanderen. Deze laag kan een flexibel kostenmodel bieden op basis van het aantal en de SKU van de agentknooppunten die als host fungeren voor de tenanttoepassing. U kunt Pod Sandboxing gebruiken als een alternatieve oplossing voor toegewezen clusters of knooppuntgroepen om afzonderlijke tenantworkloads te isoleren.

In het volgende diagram ziet u een scenario waarin tenants A en B worden uitgevoerd op een gedeeld AKS-cluster, terwijl tenant C wordt uitgevoerd op een afzonderlijk AKS-cluster.

diagram met drie tenants. Tenants A en B delen een AKS-cluster. Tenant C heeft een toegewezen AKS-cluster.

In het volgende diagram ziet u een scenario waarin tenants A en B worden uitgevoerd in dezelfde knooppuntgroep, terwijl tenant C wordt uitgevoerd op een toegewezen knooppuntgroep.

diagram met drie tenants. Tenants A en B delen een knooppuntgroep. Tenant C heeft een toegewezen knooppuntgroep.

Dit model kan ook verschillende SLA's bieden voor verschillende lagen. De Basic-laag kan bijvoorbeeld 99,9% uptime bieden, de standard-laag kan 99,95% uptime bieden en de Premium-laag kan 99,99% uptime bieden. U kunt de hogere SLA implementeren met behulp van services en functies die hogere beschikbaarheidsdoelen mogelijk maken.

Voordelen:

  • Omdat u nog steeds infrastructuur deelt, kunt u nog steeds enkele van de kostenvoordelen krijgen van gedeelde implementaties met meerdere tenants. U kunt clusters en knooppuntgroepen implementeren die worden gedeeld in meerdere basic-tier- en standard-tier-tenanttoepassingen, die een goedkopere VM-grootte gebruiken voor agentknooppunten. Deze aanpak garandeert betere dichtheid en kostenbesparingen. Voor klanten met een premium-laag kunt u AKS-clusters en -knooppuntgroepen implementeren met een hogere VM-grootte en een maximum aantal podreplica's en knooppunten tegen een hogere prijs.
  • U kunt systeemservices, zoals CoreDNS-, Konnectivityof Azure Application Gateway-ingangscontroller, uitvoeren in een toegewezen systeemmodusknooppuntgroep. U kunt taintsgebruiken, toleranties, knooppuntlabels, knooppuntkiezersen knooppuntaffiniteit om een tenanttoepassing uit te voeren op een of meer knooppuntgroepen in de gebruikersmodus.
  • U kunt taints, toleranties, knooppuntlabels, knooppuntkiezersen knooppuntaffiniteit gebruiken om gedeelde resources uit te voeren. U kunt bijvoorbeeld een ingangscontroller of berichtensysteem hebben op een toegewezen knooppuntgroep met een specifieke VM-grootte, instellingen voor automatische schaalaanpassing en ondersteuning voor beschikbaarheidszones.

risico's:

  • U moet uw Kubernetes-toepassing ontwerpen om implementaties van meerdere tenants en implementaties met één tenant te ondersteunen.
  • Als u van plan bent om migratie tussen infrastructuren toe te staan, moet u overwegen hoe u klanten migreert van een implementatie met meerdere tenants naar hun eigen implementatie met één tenant.
  • U hebt een consistente strategie en één glasvenster of één perspectief nodig om meer AKS-clusters te bewaken en te beheren.

Automatisch schalen

Als u de vraag naar verkeer wilt bijhouden die tenanttoepassingen genereren, kunt u de automatische schaalaanpassing van clusters inschakelen om de agentknooppunten van AKS te schalen. Automatisch schalen helpt systemen in de volgende omstandigheden responsief te blijven:

  • De verkeersbelasting neemt toe tijdens specifieke werkuren of perioden van het jaar.
  • Tenant- of gedeelde zware belastingen worden geïmplementeerd in een cluster.
  • Agentknooppunten zijn niet beschikbaar vanwege storingen in een beschikbaarheidszone.

Wanneer u automatisch schalen voor een knooppuntgroep inschakelt, geeft u een minimum en een maximum aantal knooppunten op op basis van de verwachte workloadgrootten. Door een maximum aantal knooppunten te configureren, kunt u voldoende ruimte voor alle tenantpods in het cluster garanderen, ongeacht de naamruimte waarin ze worden uitgevoerd.

Wanneer het verkeer toeneemt, voegt automatische schaalaanpassing van clusters nieuwe agentknooppunten toe om te voorkomen dat pods een status in behandeling hebben vanwege resourcetekorten zoals CPU en geheugen.

Wanneer de belasting afneemt, vermindert automatische schaalaanpassing van clusters het aantal agentknooppunten in een knooppuntgroep op basis van de opgegeven grenzen, waardoor uw operationele kosten worden verminderd.

U kunt automatische schaalaanpassing van pods gebruiken om pods automatisch te schalen op basis van resourcevereisten. HorizontalPodAutoscaler automatisch het aantal podreplica's schalen op basis van CPU- of geheugengebruik of aangepaste metrische gegevens. Met behulp van KEDA-kunt u het schalen van een container in Kubernetes stimuleren op basis van het aantal gebeurtenissen van externe systemen, zoals Azure Event Hubs of Azure Service Bus-, die tenanttoepassingen gebruiken.

Verticale automatische schaalaanpassing van pods (VPA) maakt efficiënt resourcebeheer mogelijk voor pods. Door de CPU en het geheugen dat aan pods is toegewezen, kunt u met VPA het aantal knooppunten verminderen dat nodig is om tenanttoepassingen uit te voeren. Als u minder knooppunten hebt, vermindert u de totale eigendomskosten en voorkomt u problemen met ruis.

Wijs capaciteitsreserveringsgroepen toe aan knooppuntgroepen om een betere resourcetoewijzing en isolatie voor verschillende tenants te bieden.

Onderhoud

Als u het risico op downtime wilt verminderen die van invloed kunnen zijn op tenanttoepassingen tijdens upgrades van cluster- of knooppuntgroepen, plant u AKS gepland onderhoud tijdens daluren. Plan wekelijks onderhoudsvensters om het besturingsvlak bij te werken van de AKS-clusters waarop tenanttoepassingen en knooppuntgroepen worden uitgevoerd om de impact van de werkbelasting te minimaliseren. U kunt een of meer wekelijkse onderhoudsvensters in uw cluster plannen door een dag of tijdsbereik op te geven op een specifieke dag. Alle onderhoudsbewerkingen worden uitgevoerd tijdens de geplande vensters.

Veiligheid

In de volgende secties worden de aanbevolen beveiligingsprocedures voor multitenant-oplossingen met AKS beschreven.

Clustertoegang

Wanneer u een AKS-cluster deelt tussen meerdere teams binnen een organisatie, moet u het principe van minimale bevoegdheid implementeren om verschillende tenants van elkaar te isoleren. U moet er met name voor zorgen dat gebruikers alleen toegang hebben tot hun Kubernetes-naamruimten en -resources wanneer ze hulpprogramma's zoals kubectl-, Helm-, Flux-of Argo CD-gebruiken.

Zie de volgende artikelen voor meer informatie over verificatie en autorisatie met AKS:

Workloadidentiteit

Als u meerdere tenanttoepassingen op één AKS-cluster host en elke toepassing zich in een afzonderlijke naamruimte bevindt, moet elke workload een ander Kubernetes-serviceaccount gebruiken en referenties voor toegang tot de downstream Azure-services. Serviceaccounts zijn een van de primaire gebruikerstypen in Kubernetes. De Kubernetes-API bevat en beheert serviceaccounts. Serviceaccountreferenties worden opgeslagen als Kubernetes-geheimen, zodat geautoriseerde pods deze kunnen gebruiken om te communiceren met de API-server. De meeste API-aanvragen bieden een verificatietoken voor een serviceaccount of een normaal gebruikersaccount.

Tenantworkloads die u in AKS-clusters implementeert, kunnen microsoft Entra-toepassingsreferenties gebruiken voor toegang tot met Microsoft Entra ID beveiligde resources, zoals Azure Key Vault en Microsoft Graph. Microsoft Entra Workload-id voor Kubernetes kan worden geïntegreerd met de systeemeigen kubernetes-mogelijkheden om te federeren met externe id-providers.

Pod-sandboxing

AKS bevat een mechanisme met de naam Pod Sandboxing dat een isolatiegrens biedt tussen de containertoepassing en de gedeelde kernel en rekenresources van de containerhost, zoals CPU, geheugen en netwerken. Pod Sandboxing vormt een aanvulling op andere beveiligingsmaatregelen of besturingselementen voor gegevensbescherming om tenantworkloads te helpen gevoelige informatie te beveiligen en te voldoen aan wettelijke, branche- of governancenalevingsvereisten, zoals PCI DSS (Payment Card Industry Data Security Standard), International Organization for Standardization (ISO) 27001 en Health Insurance Portability and Accountability Act (HIPAA).

Door toepassingen te implementeren op afzonderlijke clusters of knooppuntgroepen, kunt u de tenantworkloads van verschillende teams of klanten sterk isoleren. Het gebruik van meerdere clusters en knooppuntgroepen is mogelijk geschikt voor de isolatievereisten van veel organisaties en SaaS-oplossingen, maar er zijn scenario's waarin één cluster met gedeelde VM-knooppuntgroepen efficiënter is. U kunt bijvoorbeeld één cluster gebruiken wanneer u niet-vertrouwde en vertrouwde pods op hetzelfde knooppunt uitvoert of DaemonSets en bevoegde containers op hetzelfde knooppunt uitvoert voor snellere lokale communicatie en functionele groepering. Pod Sandboxing kunt u tenanttoepassingen op dezelfde clusterknooppunten sterk isoleren zonder dat u deze workloads hoeft uit te voeren in afzonderlijke clusters of knooppuntgroepen. Voor andere methoden moet u uw code opnieuw compileren of andere compatibiliteitsproblemen veroorzaken, maar pod-sandboxing in AKS kan elke container ongewijzigd uitvoeren binnen een verbeterde beveiligings-VM-grens.

Pod Sandboxing op AKS is gebaseerd op Kata Containers die worden uitgevoerd op de Azure Linux-containerhost voor AKS stack om hardware afgedwongen isolatie te bieden. Kata Containers op AKS zijn gebouwd op een door beveiliging beveiligde Azure-hypervisor. Het bereikt isolatie per pod via een geneste, lichtgewicht Kata-VM die gebruikmaakt van resources van een bovenliggend VM-knooppunt. In dit model krijgt elke Kata-pod een eigen kernel in een geneste Kata-gast-VM. Gebruik dit model om veel Kata-containers in één gast-VM te plaatsen terwijl u containers in de bovenliggende VM blijft uitvoeren. Dit model biedt een sterke isolatiegrens in een gedeeld AKS-cluster.

Zie voor meer informatie:

Azure Dedicated Host

Azure Dedicated Host is een service die fysieke servers biedt die zijn toegewezen aan één Azure-abonnement en hardware-isolatie op fysieke serverniveau biedt. U kunt deze toegewezen hosts inrichten binnen een regio, beschikbaarheidszone en foutdomein en u kunt VM's rechtstreeks in de ingerichte hosts plaatsen.

Er zijn verschillende voordelen voor het gebruik van Azure Dedicated Host met AKS, waaronder:

  • Hardware-isolatie zorgt ervoor dat er geen andere VM's op de toegewezen hosts worden geplaatst, wat een extra isolatielaag biedt voor tenantworkloads. Toegewezen hosts worden geïmplementeerd in dezelfde datacenters en delen dezelfde netwerk- en onderliggende opslaginfrastructuur als andere niet-geïsoleerde hosts.

  • Azure Dedicated Host biedt controle over onderhoudsgebeurtenissen die het Azure-platform start. U kunt een onderhoudsvenster kiezen om de impact op services te verminderen en de beschikbaarheid en privacy van tenantworkloads te waarborgen.

Azure Dedicated Host kan SaaS-providers helpen ervoor te zorgen dat tenanttoepassingen voldoen aan wettelijke, branche- en governancenalevingsvereisten voor het beveiligen van gevoelige informatie. Zie Azure Dedicated Host toevoegen aan een AKS-clustervoor meer informatie.

Karpenter

Karpenter- is een opensource-project voor levenscyclusbeheer voor knooppunten dat is gebouwd voor Kubernetes. Het toevoegen van Karpenter aan een Kubernetes-cluster kan de efficiëntie en kosten van het uitvoeren van workloads op dat cluster verbeteren. Karpenter kijkt naar pods die door de Kubernetes scheduler als niet-gepland worden gemarkeerd. Ook worden knooppunten die aan de podvereisten kunnen voldoen dynamisch in en beheerd.

Karpenter biedt nauwkeurige controle over het inrichten van knooppunten en de plaatsing van werkbelastingen in een beheerd cluster. Dit besturingselement verbetert multitenancy door resourcetoewijzing te optimaliseren, isolatie tussen de toepassingen van elke tenant te garanderen en operationele kosten te verlagen. Wanneer u een multitenant-oplossing op AKS bouwt, biedt Karpenter nuttige mogelijkheden om u te helpen diverse toepassingsvereisten te beheren om verschillende tenants te ondersteunen. U hebt bijvoorbeeld de toepassingen van sommige tenants nodig om te worden uitgevoerd op gpu geoptimaliseerde knooppuntgroepen en andere om te worden uitgevoerd op knooppuntgroepen die zijn geoptimaliseerd voor geheugen. Als uw toepassing lage latentie voor opslag vereist, kunt u Karpenter gebruiken om aan te geven dat voor een pod een knooppunt is vereist dat wordt uitgevoerd in een specifieke beschikbaarheidszone, zodat u uw opslag- en toepassingslaag kunt koppelen.

Met AKS kunt u knooppunten automatisch inrichten op AKS-clusters via Karpenter. De meeste gebruikers moeten de modus voor automatisch inrichten van knooppunten gebruiken om Karpenter in te schakelen als een beheerde invoegtoepassing. Zie Knooppunt automatisch inrichtenvoor meer informatie. Als u geavanceerdere aanpassingen nodig hebt, kunt u ervoor kiezen om Karpenter zelf te hosten. Zie de AKS Karpenter-providervoor meer informatie.

Vertrouwelijke VM's

U kunt vertrouwelijke VM's gebruiken om een of meer knooppuntgroepen toe te voegen aan uw AKS-cluster om te voldoen aan de strikte isolatie, privacy en beveiligingsvereisten van tenants. vertrouwelijke VM's een op hardware gebaseerde vertrouwde uitvoeringsomgeving gebruiken. AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) vertrouwelijke VM's de toegang tot de hypervisor en andere hostbeheercodetoegang tot VM-geheugen en -status weigeren, waardoor er een beveiligingslaag en diepgaande bescherming tegen de toegang van de operator wordt toegevoegd. Zie Vertrouwelijke VM's gebruiken in een AKS-clustervoor meer informatie.

Federal Information Process Standards (FIPS)

FIPS 140-3 is een Amerikaanse overheidsstandaard die minimale beveiligingsvereisten definieert voor cryptografische modules in producten en systemen van informatietechnologie. Door FIPS-naleving in te schakelen voor AKS-knooppuntgroepen, kunt u de isolatie, privacy en beveiliging van uw tenantworkloads verbeteren. FIPS- naleving zorgt ervoor dat gevalideerde cryptografische modules worden gebruikt voor versleuteling, hashing en andere beveiligingsgerelateerde bewerkingen. Met AKS-knooppuntgroepen met FIPS-functionaliteit kunt u voldoen aan wettelijke en branchenalevingsvereisten door robuuste cryptografische algoritmen en mechanismen te gebruiken. Azure biedt documentatie over het inschakelen van FIPS voor AKS-knooppuntgroepen, waarmee u de beveiligingspostuur van uw multitenant AKS-omgevingen kunt versterken. Zie FIPS inschakelen voor AKS-knooppuntgroepenvoor meer informatie.

Bring Your Own Keys (BYOK) met Azure-schijven

Azure Storage versleutelt alle gegevens in een opslagaccount-at-rest, inclusief het besturingssysteem en de gegevensschijven van een AKS-cluster. Standaard worden gegevens versleuteld met door Microsoft beheerde sleutels. Voor meer controle over versleutelingssleutels kunt u door de klant beheerde sleutels opgeven voor versleuteling in rust van het besturingssysteem en de gegevensschijven van uw AKS-clusters. Zie voor meer informatie:

Versleuteling op basis van host

op host gebaseerde versleuteling op AKS versterkt de isolatie van tenantworkloads, privacy en beveiliging verder. Wanneer u hostversleuteling inschakelt, versleutelt AKS data-at-rest op de onderliggende hostcomputers, zodat gevoelige tenantgegevens worden beschermd tegen onbevoegde toegang. Tijdelijke schijven en tijdelijke besturingssysteemschijven worden in rust versleuteld met door het platform beheerde sleutels wanneer u end-to-end-versleuteling inschakelt.

In AKS gebruiken besturingssysteem- en gegevensschijven versleuteling aan de serverzijde standaard met door platform beheerde sleutels. De caches voor deze schijven worden in rust versleuteld met door het platform beheerde sleutels. U kunt uw eigen sleutelversleutelingssleutel opgeven om de sleutel voor gegevensbeveiliging te versleutelen met behulp van envelopversleuteling, ook wel bekend als wrapping-. De cache voor het besturingssysteem en de gegevensschijven worden ook versleuteld via de BYOK- die u opgeeft.

Met versleuteling op basis van een host wordt een beveiligingslaag toegevoegd voor omgevingen met meerdere tenants. De gegevens van elke tenant in het besturingssysteem en de gegevensschijfcaches worden in rust versleuteld met door de klant beheerde of platformbeheerde sleutels, afhankelijk van het geselecteerde schijfversleutelingstype. Zie voor meer informatie:

Networking

In de volgende secties worden aanbevolen netwerkprocedures beschreven voor multitenant-oplossingen met AKS.

Netwerktoegang tot de API-server beperken

In Kubernetes ontvangt de API-server aanvragen voor het uitvoeren van acties in het cluster, zoals het maken van resources of het schalen van het aantal knooppunten. Wanneer u een AKS-cluster deelt tussen meerdere teams binnen een organisatie, beveiligt u de toegang tot het besturingsvlak met behulp van een van de volgende oplossingen.

Privé-AKS-clusters

Met behulp van een privé-AKS-cluster kunt u ervoor zorgen dat het netwerkverkeer tussen uw API-server en uw knooppuntgroepen binnen uw virtuele netwerk blijft. In een privé-AKS-cluster heeft het besturingsvlak of de API-server een intern IP-adres dat alleen toegankelijk is via een privé-eindpunt van Azure, dat zich in hetzelfde virtuele netwerk van het AKS-cluster bevindt. Op dezelfde manier kan elke virtuele machine in hetzelfde virtuele netwerk privé communiceren met het besturingsvlak via het privé-eindpunt. Zie Een privé-AKS-cluster makenvoor meer informatie.

Geautoriseerde IP-adresbereiken

De tweede optie voor het verbeteren van de clusterbeveiliging en het minimaliseren van aanvallen is door gebruik te maken van geautoriseerde IP-adresbereiken. Deze benadering beperkt de toegang tot het besturingsvlak van een openbaar AKS-cluster tot een bekende lijst met IP-adressen en CIDR-bereiken (Classless Inter-Domain Routing). Wanneer u geautoriseerde IP-adressen gebruikt, worden ze nog steeds openbaar weergegeven, maar is de toegang beperkt tot een set bereiken. Zie Beveiligde toegang tot de API-server met behulp van geautoriseerde IP-adresbereiken in AKSvoor meer informatie.

Azure Private Link-service is een infrastructuuronderdeel waarmee toepassingen privé verbinding kunnen maken met een service via een privé-eindpunt van Azure dat is gedefinieerd in een virtueel netwerk en is verbonden met de front-end-IP-configuratie van een Azure Load Balancer--exemplaar. Met Private Link-kunnen serviceproviders veilig hun services leveren aan hun tenants die vanuit Azure of on-premises verbinding kunnen maken, zonder risico's voor gegevensexfiltratie.

U kunt Private Link-serviceintegratie gebruiken om tenants op een veilige manier privéconnectiviteit te bieden met hun door AKS gehoste workloads, zonder dat u een openbaar eindpunt op het openbare internet hoeft bloot te leggen.

Zie Multitenancy- en Private Link-voor meer informatie over het configureren van Private Link voor een door Azure gehoste multitenant-oplossing.

Omgekeerde proxy's

Een omgekeerde proxy is een load balancer en een API-gateway die doorgaans wordt gebruikt voor tenanttoepassingen om binnenkomende aanvragen te beveiligen, filteren en verzenden. Populaire reverse proxy's ondersteunen functies zoals taakverdeling, SSL-beëindiging en laag 7-routering. Omgekeerde proxy's worden doorgaans geïmplementeerd om de beveiliging, prestaties en betrouwbaarheid te verbeteren. Populaire omgekeerde proxy's voor Kubernetes omvatten de volgende implementaties:

Wanneer u een omgekeerde AKS-hostende omgekeerde proxy gebruikt om binnenkomende aanvragen voor meerdere tenanttoepassingen te beveiligen en te verwerken, kunt u de volgende aanbevelingen overwegen:

  • Host de omgekeerde proxy op een toegewezen knooppuntgroep die is geconfigureerd voor het gebruik van een VM-grootte met een hoge netwerkbandbreedte en versneld netwerken ingeschakeld.
  • Configureer de knooppuntgroep die als host fungeert voor uw omgekeerde proxy voor automatisch schalen.
  • Om te voorkomen dat de latentie en time-outs voor tenanttoepassingen toenemen, definieert u een beleid voor automatisch schalen, zodat het aantal controllerpods voor inkomend verkeer direct kan worden uitgebreid en gecontractaliseerd om verkeersschommelingen te vinden.
  • Overweeg om het binnenkomende verkeer naar tenanttoepassingen te sharden, op meerdere exemplaren van uw ingangscontroller, om de schaalbaarheid en scheidingsniveau te verhogen.

Wanneer u de Azure Application Gateway-ingangscontroller (AGIC)gebruikt, kunt u overwegen de volgende best practices te implementeren:

  • Configureer de toepassingsgateway die de ingangscontroller gebruikt voor automatisch schalen. Als automatisch schalen is ingeschakeld, worden de WAF-SKU's (Application Gateway en Web Application Firewall) v2 uitgeschaald of ingeschaald op basis van de vereisten voor toepassingsverkeer. Deze modus biedt een betere elasticiteit voor uw toepassing en elimineert de noodzaak om de grootte of het aantal exemplaren van de toepassingsgateway te raden. Deze modus helpt u ook kosten te besparen door niet te vereisen dat de gateway wordt uitgevoerd op piekingerichte capaciteit voor de verwachte maximale verkeersbelasting. U moet een minimumaantal exemplaren (en eventueel maximaal) opgeven.
  • Overweeg om meerdere exemplaren van de AGIC-te implementeren, elk gekoppeld aan een afzonderlijke toepassingsgateway, wanneer het aantal tenanttoepassingen de maximumhoeveelheid sitesoverschrijdt. Ervan uitgaande dat elke tenanttoepassing wordt uitgevoerd in een toegewezen naamruimte, gebruikt u ondersteuning voor meerdere naamruimten om tenanttoepassingen te verspreiden over meer exemplaren van de AGIC-.

Integratie met Azure Front Door

Azure Front Door is een wereldwijde load balancer van laag 7 en een modern netwerk voor cloudinhoudlevering (CDN) van Microsoft dat snelle, betrouwbare en veilige toegang biedt tussen gebruikers en webtoepassingen over de hele wereld. Azure Front Door ondersteunt functies zoals aanvraagversnelling, SSL-beëindiging, reactiecaching, WAF aan de rand, routering op basis van URL's, herschrijven en omleidingen die u kunt gebruiken wanneer u AKS-gehoste multitenant-toepassingen beschikbaar maakt op het openbare internet.

U kunt bijvoorbeeld een door AKS gehoste multitenant-toepassing gebruiken om alle aanvragen van klanten te verwerken. In deze context kunt u Azure Front Door gebruiken om meerdere aangepaste domeinen te beheren, één voor elke tenant. U kunt SSL-verbindingen aan de rand beëindigen en al het verkeer routeren naar de door AKS gehoste multitenant-toepassing die is geconfigureerd met één hostnaam.

diagram dat laat zien hoe Azure Front Door en AKS verbinding maken.

U kunt Azure Front Door configureren om de hostheader van de aanvraag voor de origin-host te wijzigen zodat deze overeenkomt met de domeinnaam van de back-endtoepassing. De oorspronkelijke Host header die door de client wordt verzonden, wordt doorgegeven via de X-Forwarded-Host header en de code van de multitenant-toepassing kan deze informatie gebruiken om de binnenkomende aanvraag toe te wijzen aan de juiste tenant.

Azure Web Application Firewall, op Azure Front Door, biedt gecentraliseerde beveiliging voor webtoepassingen. Azure Web Application Firewall kan u helpen bij het verdedigen van door AKS gehoste tenanttoepassingen die een openbaar eindpunt op internet beschikbaar maken tegen schadelijke aanvallen.

U kunt Azure Front Door Premium configureren om privé verbinding te maken met een of meer tenanttoepassingen die worden uitgevoerd op een AKS-cluster, via een interne load balancer-oorsprong, met behulp van Private Link-. Zie Azure Front Door Premium verbinden met een interne load balancer-origin met Private Linkvoor meer informatie.

Uitgaande verbindingen

Wanneer AKS-gehoste toepassingen verbinding maken met een groot aantal databases of externe services, loopt het cluster mogelijk het risico dat de SNAT-poortuitputting (Network Address Translation) van het bronnetwerk wordt uitgeput. SNAT-poorten unieke id's genereren die worden gebruikt voor het onderhouden van afzonderlijke stromen die toepassingen uitvoeren op dezelfde set rekenresources. Door verschillende tenanttoepassingen uit te voeren op een gedeeld AKS-cluster, kunt u een groot aantal uitgaande aanroepen uitvoeren, wat kan leiden tot een uitputting van de SNAT-poort. Een AKS-cluster kan uitgaande verbindingen op drie verschillende manieren verwerken:

  • Azure Load Balancer: AKS richt standaard een Standard SKU Load Balancer in die moet worden ingesteld en gebruikt voor uitgaande verbindingen. De standaardinstelling voldoet echter mogelijk niet aan de vereisten van alle scenario's als openbare IP-adressen niet zijn toegestaan of als extra hops vereist zijn voor uitgaand verkeer. De openbare load balancer wordt standaard gemaakt met een standaard openbaar IP-adres dat de uitgaande regels gebruiken. Met uitgaande regels kunt u SNAT expliciet definiëren voor een openbare standaard load balancer. Met deze configuratie kunt u de openbare IP-adressen van uw load balancer gebruiken om uitgaande internetverbinding te bieden voor uw back-endinstanties. Als u zo nodig SNAT-poortuitputtingwilt voorkomen, kunt u de uitgaande regels van de openbare load balancer configureren om meer openbare IP-adressen te gebruiken. Zie Het front-end-IP-adres van een load balancer gebruiken voor uitgaand verkeer via uitgaande regelsvoor meer informatie.
  • Azure NAT Gateway-: u kunt een AKS-cluster configureren voor het gebruik van Azure NAT Gateway om uitgaand verkeer van tenanttoepassingen te routeren. Nat Gateway biedt maximaal 64.512 uitgaande UDP- en TCP-verkeerstromen per openbaar IP-adres, met maximaal 16 IP-adressen. Om het risico op uitputting van SNAT-poorten te voorkomen wanneer u een NAT-gateway gebruikt voor het afhandelen van uitgaande verbindingen vanuit een AKS-cluster, kunt u meer openbare IP-adressen of een voorvoegsel voor openbare IP-adressen koppelen aan de gateway. Zie overwegingen voor Azure NAT Gateway voor multitenancy-voor meer informatie.
  • door de gebruiker gedefinieerde route (UDR): u kunt de route voor uitgaand verkeer van een AKS-cluster aanpassen ter ondersteuning van aangepaste netwerkscenario's, zoals de routes die openbare IP-adressen weigeren en vereisen dat het cluster zich achter een virtueel netwerkapparaat (NVA) bevindt. Wanneer u een cluster configureert voor door de gebruiker gedefinieerde routering, configureert AKS niet automatisch uitgaande paden. U moet de installatie van uitgaand verkeer voltooien. U routeert bijvoorbeeld uitgaand verkeer via een Azure Firewall-. U moet het AKS-cluster implementeren in een bestaand virtueel netwerk met een subnet dat u eerder hebt geconfigureerd. Wanneer u geen standaard-load balancer-architectuur gebruikt, moet u expliciet uitgaand verkeer tot stand brengen. Daarom is voor deze architectuur expliciet uitgaand verkeer naar een apparaat vereist, zoals een firewall, gateway of proxy. Of met de architectuur kan de NAT (Network Address Translation) worden uitgevoerd door een openbaar IP-adres dat is toegewezen aan de standaard load balancer of het standaardapparaat.

Monitoring

U kunt Azure Monitor en containerinzichten gebruiken om tenanttoepassingen te bewaken die worden uitgevoerd op een gedeeld AKS-cluster en om kostenanalyses voor afzonderlijke naamruimten te berekenen. Gebruik Azure Monitor om de status en prestaties van AKS te bewaken. Het omvat de verzameling van logboeken en metrische gegevens, telemetrieanalyse en visualisaties van verzamelde gegevens om trends te identificeren en waarschuwingen te configureren die u proactief waarschuwt voor kritieke problemen. U kunt containerinzichten inschakelen om deze bewaking uit te breiden.

U kunt ook opensource-hulpprogramma's gebruiken, zoals Prometheus en Grafana, die veel worden gebruikt voor Kubernetes-bewaking. U kunt ook andere niet-Microsoft-hulpprogramma's gebruiken voor bewaking en waarneembaarheid.

Kosten

Kostenbeheer is het doorlopende proces van het implementeren van beleid om de kosten te beheren. In de Kubernetes-context zijn er verschillende methoden die organisaties kunnen gebruiken om kosten te beheren en te optimaliseren. Deze methoden omvatten het gebruik van systeemeigen Kubernetes-hulpprogramma's voor het beheren en beheren van resourcegebruik en -verbruik en het proactief bewaken en optimaliseren van de onderliggende infrastructuur. Wanneer u kosten per tenant berekent, moet u rekening houden met de kosten die zijn gekoppeld aan elke resource die door een tenanttoepassing wordt gebruikt. De aanpak die u volgt om kosten terug te brengen naar de tenants, is afhankelijk van het tenancymodel dat uw oplossing gebruikt. In de volgende lijst worden tenancymodellen gedetailleerder beschreven:

  • Volledig multitenant: Wanneer één multitenant-toepassing alle tenantaanvragen verwerkt, is het uw verantwoordelijkheid om het resourceverbruik bij te houden en het aantal aanvragen dat elke tenant genereert. Vervolgens brengt u uw klanten dienovereenkomstig kosten in rekening.
  • Toegewezen cluster: wanneer een cluster is toegewezen aan één tenant, is het eenvoudig om de kosten van Azure-resources terug te brengen naar de klant. De totale eigendomskosten zijn afhankelijk van veel factoren, waaronder het aantal en de grootte van VM's, de netwerkkosten van netwerkverkeer, openbare IP-adressen, load balancers en de opslagservices, zoals beheerde schijven of Azure-bestanden die door de tenantoplossing worden gebruikt. U kunt een AKS-cluster en de bijbehorende resources in de knooppuntresourcegroep taggen om kosten in rekening te brengen. Zie Tags toevoegen aan het clustervoor meer informatie.
  • Toegewezen knooppuntgroep: U kunt een Azure-tag toepassen op een nieuwe of bestaande knooppuntgroep die is toegewezen aan één tenant. Tags worden toegepast op elk knooppunt in de knooppuntgroep en blijven behouden via upgrades. Tags worden ook toegepast op nieuwe knooppunten die tijdens uitschaalbewerkingen aan een knooppuntgroep worden toegevoegd. Het toevoegen van een tag kan helpen bij taken zoals het bijhouden van beleid of het opladen van kosten. Zie Tags toevoegen aan knooppuntgroepenvoor meer informatie.
  • Andere resources: u kunt tags gebruiken om de kosten van toegewezen resources aan een bepaalde tenant te koppelen. U kunt met name openbare IP-adressen, bestanden en schijven taggen met behulp van een Kubernetes-manifest. Tags die op deze manier zijn ingesteld, behouden de Kubernetes-waarden, zelfs als u ze later bijwerkt met behulp van een andere methode. Wanneer openbare IP-adressen, bestanden of schijven worden verwijderd via Kubernetes, worden alle tags die Kubernetes-sets bevatten, verwijderd. Tags voor resources die door Kubernetes niet worden bijgehouden, blijven ongewijzigd. Zie Tags toevoegen met behulp van Kubernetesvoor meer informatie.

U kunt opensource-hulpprogramma's, zoals KubeCost, gebruiken om de kosten van een AKS-cluster te bewaken en te beheren. U kunt kostentoewijzing instellen voor een implementatie, service, label, pod en naamruimte, waarmee u flexibiliteit krijgt bij het terugrekenen of weergeven van gebruikers van het cluster. Zie Cost governance met Kubecostvoor meer informatie.

Zie Architectuurbenaderingen voor kostenbeheer en toewijzing in een multitenant-oplossingvoor meer informatie over de meting, toewijzing en optimalisatie van kosten voor een multitenant-toepassing. Zie het azure Well-Architected Framework-artikel Overzicht van de pijler Kostenoptimalisatievoor algemene richtlijnen over kostenoptimalisatie.

Governance

Wanneer meerdere tenants dezelfde infrastructuur delen, kan het beheren van gegevensprivacy, naleving en wettelijke vereisten ingewikkeld worden. U moet sterke beveiligingsmaatregelen en beleidsregels voor gegevensbeheer implementeren. Gedeelde AKS-clusters vormen een hoger risico op gegevensschendingen, onbevoegde toegang en niet-naleving van regelgeving voor gegevensbescherming. Elke tenant heeft mogelijk unieke vereisten voor gegevensbeheer en nalevingsbeleid, waardoor het moeilijk is om de beveiliging en privacy van de gegevens te waarborgen.

Microsoft Defender for Containers is een cloudeigen containerbeveiligingsoplossing die mogelijkheden biedt voor detectie en beveiliging van bedreigingen voor Kubernetes-omgevingen. Door Defender for Containers te gebruiken, kunt u uw houding voor gegevensbeheer en naleving verbeteren wanneer u meerdere tenants in een Kubernetes-cluster host. Gebruik Defender for Containers om gevoelige gegevens te beschermen, bedreigingen te detecteren en erop te reageren door containergedrag en netwerkverkeer te analyseren en te voldoen aan wettelijke vereisten. Het biedt controlemogelijkheden, logboekbeheer en het genereren van rapporten om naleving van regelgevers en auditors te demonstreren.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Andere inzenders: