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. Als gehoste Kubernetes-service verwerkt Azure kritieke taken, zoals statuscontrole en onderhoud. Het Azure-platform beheert het AKS-besturingsvlak en u betaalt alleen voor de AKS-knooppunten waarop uw toepassingen worden uitgevoerd.

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. Al deze typen delen worden vaak beschreven met behulp van de overkoepelende term multitenancy. 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 beschrijven we enkele van de functies van AKS die nuttig zijn bij het bouwen van systemen met meerdere tenants. Zie Multitenancy in de Kubernetes-documentatie voor algemene richtlijnen en best practices 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 tot uw beschikking. Over het algemeen vallen multitenancy in Kubernetes-clusters in twee hoofdcategorieën, hoewel veel variaties nog steeds mogelijk zijn. In de Kubernetes-documentatie 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 wordt uitgevoerd als PaaS-services 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 voor hun klanten, die als afzonderlijke tenants worden beschouwd. 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 zijn geïsoleerd.

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

Isolatiemodellen

Volgens de Kubernetes-documentatie wordt een Multitenant Kubernetes-cluster gedeeld door meerdere gebruikers en workloads die meestal tenants worden genoemd. Deze definitie omvat Kubernetes-clusters die verschillende teams of afdelingen delen binnen een organisatie. Het bevat ook clusters die worden gedeeld door exemplaren per klant van een SaaS-toepassing (Software-as-a-Service).

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, is er een probleem dat één team meer dan het evenredige aandeel van resources kan gebruiken. Resourcequota is een hulpprogramma dat beheerders kunnen gebruiken om dit probleem aan te pakken.

Op basis van het beveiligingsniveau dat wordt geboden door isolatie, kunnen we 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 de integriteit van workloads, het organiseren van clusterresources in verschillende interne gebruikersgroepen en het beschermen tegen mogelijke beveiligingsaanvallen.
  • Harde multitenancy wordt gebruikt om scenario's te beschrijven waarbij heterogene tenants elkaar niet vertrouwen, vaak vanuit beveiligings- en resourcedelingsperspectief.

Wanneer u van plan bent een AKS-cluster (Multitenant Azure Kubernetes Service) te bouwen, moet u rekening houden met de lagen resource-isolatie en multitenancy die worden geleverd door Kubernetes:

  • Cluster
  • Naamruimte
  • Knooppuntgroep of knooppunt
  • Pod
  • Container

Daarnaast moet u rekening houden met de gevolgen voor de beveiliging van het delen van verschillende resources tussen meerdere tenants. Het plannen van pods van verschillende tenants op hetzelfde knooppunt kan bijvoorbeeld het aantal machines verminderen dat nodig is in het cluster. 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 beveiligde 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. Vervolgens kunt u op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes en netwerkbeleid gebruiken om tenantisolatie af te dwingen. In de volgende afbeelding 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 (Azure Kubernetes Service). 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-documentatie is een naamruimte een abstractie die wordt gebruikt ter ondersteuning van de isolatie van groepen resources binnen één cluster. Naamruimten kunnen worden gebruikt 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 de naam elkaar overlapt.
  • RBAC-rollen en -rolbindingen zijn resources binnen het naamruimtebereik 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. Ze wijzen deze rollen vervolgens 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 te worden uitgevoerd en om problemen met ruis te voorkomen, die van invloed kunnen zijn op andere tenanttoepassingen die hetzelfde cluster delen.
  • Netwerkbeleid is naamruimteobjecten 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 de isolatie op naamruimteniveau:

Isolatie van gegevensvlak

Isolatie van gegevensvlakken garandeert dat pods en workloads van afzonderlijke tenants voldoende van elkaar worden geïsoleerd. Zie Data Plane Isolation 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 communicatie te scheiden tussen tenanttoepassingen die hetzelfde cluster delen.

Azure Kubernetes Service (AKS) biedt twee manieren om netwerkbeleid te implementeren:

  1. Azure heeft de implementatie voor netwerkbeleid, azure-netwerkbeleid genoemd.
  2. 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 IPTable-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 Service voor meer informatie.

Zie Netwerkisolatie in de Kubernetes-documentatie voor meer informatie.

Opslagisolatie

Azure biedt een uitgebreide set beheerde paaS-gegevensopslagplaatsen (platform-as-a-service), 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 opslagresource gebruiken. Zie Architectuurbenaderingen voor opslag en gegevens in multitenant-oplossingen voor meer informatie over verschillende strategieën en benaderingen voor het beheren van gegevens in een scenario met meerdere tenants.

Workloads die worden uitgevoerd op Azure Kubernetes Service (AKS) kunnen ook permanente volumes gebruiken om gegevens op te slaan. In Azure kunt u permanente volumes maken als Kubernetes-resources die worden ondersteund door Azure Storage. 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 worden ondersteund door Azure Disks, Azure Files en Azure NetApp Files. Zie Opslagopties voor toepassingen in Azure Kubernetes Service (AKS) voor meer informatie. Om veiligheids- en tolerantieredenen moet u voorkomen dat u lokale opslag op agentknooppunten gebruikt via emptyDir en hostPath.

Wanneer ingebouwde AKS-opslagklassen niet geschikt zijn voor een of meer tenants, kunt u aangepaste opslagklassen bouwen om aan verschillende tenantsvereisten te voldoen. 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 Azure Kubernetes Service (AKS) voor meer informatie over dit scenario.

Zie Opslagisolatie in de Kubernetes-documentatie voor meer informatie.

Isolatie van knooppunten

U kunt tenantworkloads zo configureren dat ze worden uitgevoerd op afzonderlijke agentknooppunten om het probleem met Ruis in buren 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, knooppuntkiezers en knooppuntaffiniteit gebruiken om de pods van tenants te beperken om alleen te worden uitgevoerd op een bepaalde set knooppunten of knooppuntgroepen.

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

  • Op kernelniveau door tenantworkloads uit te voeren op lichtgewicht virtuele machines op gedeelde agentknooppunten en pod-sandboxing te gebruiken 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 virtuele machines op de toegewezen hosts worden geplaatst, waardoor er een extra isolatielaag voor tenantworkloads wordt geboden.

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), Confidential Virtual Machines (CVM) of versleuteling op basis van een host.

Met knooppuntisolatie kunt u eenvoudig de kosten van een set knooppunten of knooppuntgroepen koppelen en terugrekenen aan één tenant. Het is strikt gerelateerd aan het tenancymodel dat door uw oplossing wordt aangenomen.

Zie Knooppuntisolatie in de Kubernetes-documentatie voor meer informatie.

Tenancymodellen

Azure Kubernetes Service (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 met dit model zijn gebouwd uitgebreid gebruik van infrastructuur als code (IaC). Bicep, Azure Resource Manager, Terraform of de REST API's van Azure Resource Manager helpen bijvoorbeeld 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 Implementatiestempels te 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 volumes die aan één tenant zijn gekoppeld. Een volledig isolatietenancymodel is essentieel voor sommige klanten met een hoge overhead voor naleving van regelgeving.
  • Tenants zijn waarschijnlijk niet van invloed op de systeemprestaties van elkaar, waardoor u het probleem met Noisy Neighbor kunt voorkomen. 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. Met de sla voor uptime (service level agreement) kunt u het besturingsvlak van een AKS-cluster uitschalen 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.
  • Updates en wijzigingen kunnen geleidelijk worden geïmplementeerd 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 door één tenant wordt gebruikt.

Risico 's:

  • Kostenefficiëntie is laag omdat elke tenant gebruikmaakt van een toegewezen set resources.
  • Doorlopend onderhoud is waarschijnlijk tijdrovend, omdat het moet worden gerepliceerd in meerdere AKS-clusters, één voor elke tenant. Overweeg om uw operationele processen te automatiseren en wijzigingen geleidelijk toe te passen via uw omgevingen. Het zou helpen als u ook andere bewerkingen voor meerdere implementaties bekijkt, zoals rapportage en analyses in uw hele omgeving. Zorg er ook voor 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 set infrastructuur om te implementeren, bewaken en onderhouden. Alle tenants gebruiken de resource, zoals wordt geïllustreerd in het volgende diagram:

Diagram met drie tenants, allemaal met één gedeelde implementatie.

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 om het verkeer te ondersteunen dat wordt gegenereerd door de resources van alle tenants, zoals gegevensopslagplaatsen.

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 inschalen in het aantal pods en clusterknooppunten, op basis van aangepaste metrische gegevens. U kunt bijvoorbeeld het aantal aanvragen in behandeling verkennen of de metrische gegevens van een extern berichtensysteem dat gebruikmaakt van Kubernetes 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 bijhoudt en koppelt aan afzonderlijke tenants, op basis van hun werkelijke gebruik. Oplossingen van derden, 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 is echter ook vaak riskanter 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 de schaallimieten voor Azure-resources bereikt wanneer u een gedeelde set resources hebt. Om te voorkomen dat u een quotumlimiet voor resources bereikt, kunt u overwegen om uw tenants over meerdere Azure-abonnementen te distribueren.

Horizontaal gepartitioneerde implementaties

U kunt ook overwegen om uw Multitenant Kubernetes-toepassing horizontaal te partitioneren. Deze benadering bestaat uit het delen van enkele oplossingsonderdelen in alle tenants en het implementeren van 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:

Diagram met drie tenants, elk met behulp van een toegewezen database en één gedeelde Kubernetes-toepassing.

Voordelen:

  • Horizontaal gepartitioneerde implementaties kunnen u helpen bij het oplossen van het probleem met Noisy Neighbor. Houd rekening met deze aanpak als u hebt vastgesteld 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, kunnen de prestaties van een database negatief worden beïnvloed, maar blijven de databases van andere tenants (en gedeelde onderdelen, 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 zich niet kunnen veroorloven om resources te delen met andere tenants, om interne beleidsregels of nalevingsredenen.

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. Toch kunt u 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, wat betreft het delen van resources, 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 worden gedeeld door alle Tenants in de Basic-laag.
  • Standard-laag: Tenants-aanvragen worden geleverd door een toegewezen Kubernetes-toepassing die wordt uitgevoerd in een afzonderlijke naamruimte, die isolatiegrenzen biedt wat betreft beveiliging, netwerken, 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 service level agreement, 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 worden gebruikt voor het hosten van de tenanttoepassing. U kunt Pod Sandboxing gebruiken als een alternatieve oplossing voor het gebruik van 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.

Op dezelfde manier toont het volgende diagram 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 serviceovereenkomsten 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% bieden. De hogere SLA (Service Level Agreement) kan worden geïmplementeerd met behulp van services en functies die hogere beschikbaarheidsdoelen mogelijk maken.

Voordelen:

  • Omdat u nog steeds infrastructuur deelt, kunt u nog steeds een aantal 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, Konnectivity of Azure-toepassing Gateway Ingress Controller, uitvoeren in een toegewezen systeemmodusknooppuntgroep. U kunt taints, toleranties, knooppuntlabels, knooppuntkiezers en knooppuntaffiniteit gebruiken om een tenanttoepassing uit te voeren op een of meer gebruikersmodusknooppuntgroepen.
  • U kunt taints, toleranties, knooppuntlabels, knooppuntkiezers en 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 (één uitkijkpunt) nodig om meer AKS-clusters te bewaken en te beheren.

Automatisch schalen

Als u de vraag naar verkeer wilt bijhouden die wordt gegenereerd door tenanttoepassingen, kunt u de automatische schaalaanpassing van clusters inschakelen om de agentknooppunten van uw Azure Kubernetes Service (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 zonegebonden storingen.

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 pods in een status in behandeling te voorkomen, vanwege een tekort aan resources in termen van 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 de resourcevereisten. Met horizontale automatische schaalaanpassing van pods (HPA) wordt het aantal podreplica's automatisch geschaald op basis van cpu-/geheugengebruik of aangepaste metrische gegevens. Met Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA) kunt u het schalen van elke container in Kubernetes stimuleren op basis van het aantal gebeurtenissen van externe systemen, zoals Azure Event Hubs of Azure Service Bus, dat wordt gebruikt door tenanttoepassingen.

Onderhoud

Als u het risico op downtime wilt verminderen die van invloed kunnen zijn op tenanttoepassingen tijdens upgrades van cluster- of knooppuntgroepen, plant u gepland AKS-onderhoud tijdens daluren. Met gepland onderhoud kunt u wekelijks onderhoudsvensters plannen om het besturingsvlak bij te werken van de AKS-clusters waarop tenanttoepassingen en knooppuntgroepen worden uitgevoerd, waardoor de impact van de werkbelasting wordt geminimaliseerd. 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.

Beveiliging

Clustertoegang

Wanneer u een AKS-cluster deelt tussen meerdere teams binnen een organisatie, moet u het principe van minimale bevoegdheden 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 gebruiken, zoals kubectl, Helm, Flux, Argo CD of andere typen hulpprogramma's.

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

Workload-identiteit

Als u meerdere tenanttoepassingen host op één AKS-cluster en elk zich in een afzonderlijke naamruimte bevindt, moet elke workload een ander Kubernetes-serviceaccount en -referenties gebruiken om toegang te krijgen 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 ze kunnen worden gebruikt door geautoriseerde pods om te communiceren met de API-server. De meeste API-aanvragen bieden een verificatietoken voor een serviceaccount of een normaal gebruikersaccount.

Tenantworkloads die zijn geïmplementeerd in AKS-clusters 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 kan geschikt zijn voor de isolatievereisten van veel organisaties en SaaS-oplossingen, maar er zijn scenario's waarin één cluster met gedeelde VM-knooppuntgroepen efficiënter is, bijvoorbeeld wanneer u niet-vertrouwde en vertrouwde pods uitvoert op hetzelfde knooppunt of daemonSets en bevoorrechte containers op hetzelfde knooppunt zoekt voor snellere lokale communicatie en functionele groepering. Met 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 door hardware afgedwongen isolatie te bieden. Kata Containers op AKS zijn gebouwd op een door beveiliging beveiligde Azure-hypervisor. De isolatie per pod wordt bereikt 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. Met dit model kunt u veel Kata-containers in één gast-VM plaatsen terwijl u containers in de bovenliggende VM blijft uitvoeren. Het 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 fysiek serverniveau biedt. Deze toegewezen hosts kunnen worden ingericht binnen een regio, beschikbaarheidszone en foutdomein, en u kunt VM's rechtstreeks in de ingerichte hosts plaatsen.

U kunt verschillende voordelen bereiken met behulp van Azure Dedicated Host met AKS, waaronder de volgende:

  • 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 worden geïnitieerd door het Azure-platform. 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-cluster (Azure Dedicated Host) voor meer informatie.

Vertrouwelijke virtuele machines

U kunt vertrouwelijke virtuele machines (CVM'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. CVM's maken gebruik van een op hardware gebaseerde, vertrouwde uitvoeringsomgeving (TEE). AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) vertrouwelijke VM's weigeren de hypervisor en andere hostbeheercodetoegang tot VM-geheugen en -status, waardoor een beveiligingslaag wordt toegevoegd tegen toegang tot operators. Zie CVM's gebruiken in een AKS-cluster voor 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, zodat u de beveiligingsstatus van uw multitenant AKS-omgevingen kunt versterken. Zie FIPS inschakelen voor AKS-knooppuntgroepen voor 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:

Op hosts gebaseerde versleuteling

Versleuteling op basis van een host op AKS versterkt de isolatie van tenantworkloads, privacy en beveiliging verder. Wanneer u hostversleuteling inschakelt, versleutelt AKS data-at-rest op de onderliggende hostcomputers om ervoor te zorgen dat 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 (KEK) opgeven om de GEGEVENSBEVEILIGINGssleutel (DEK) te versleutelen met behulp van envelopversleuteling, ook wel wrapping genoemd. 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:

Netwerken

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é Azure Kubernetes Service-cluster maken voor meer informatie.

Geautoriseerde IP-adressen

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

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

U kunt Azure 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 Azure Private Link voor algemene richtlijnen voor 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, moet u rekening houden met de volgende aanbevelingen:

  • 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-toepassing Gateway Ingress Controller (AGIC) gebruikt, kunt u overwegen de volgende best practices te implementeren:

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

Integratie met Azure Front Door

Azure Front Door is een wereldwijde load balancer op laag 7 en het moderne netwerk voor cloudinhoudlevering (CDN) van Microsoft dat snelle, betrouwbare en veilige toegang biedt tussen gebruikers en webtoepassingen over de hele wereld. Azure Front Door biedt ondersteuning voor functies zoals aanvraagversnelling, SSL-beëindiging, reactiecaching, WAF aan de rand, routering op basis van URL's, herschrijven en omleidingen die u kunt gebruiken bij het blootstellen van door AKS gehoste multitenant-toepassingen aan 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 origin 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 (WAF), op Azure Front Door, biedt gecentraliseerde beveiliging voor webtoepassingen. U kunt Azure WAF gebruiken om AKS-gehoste tenanttoepassingen te verdedigen 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 Azure Private Link Service. Zie Azure Front Door Premium verbinden met een interne load balancer-oorsprong met Private Link voor 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-poort uitgeput raakt. SNAT-poorten genereren unieke id's die worden gebruikt om afzonderlijke stromen te onderhouden die worden geïnitieerd door toepassingen die worden uitgevoerd op dezelfde set rekenresources. Door verschillende tenanttoepassingen uit te voeren op een gedeeld AKS-cluster (Azure Kubernetes Service), 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 Public 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. Standaard wordt de openbare Load Balancer gemaakt met een standaard openbaar IP-adres dat wordt gebruikt door de uitgaande regels. Met uitgaande regels kunt u expliciet SNAT (Source Network Address Translation) definiëren voor een openbare standaard load balancer. Met deze configuratie kunt u de openbare IP('s) van uw load balancer gebruiken om uitgaande internetverbinding te bieden voor uw back-endinstanties. Als u zo nodig SNAT-poortuitputting wilt voorkomen, kunt u de uitgaande regels van de openbare load balancer configureren om extra openbare IP-adressen te gebruiken. Zie Het front-end-IP-adres van een load balancer gebruiken voor uitgaand verkeer via uitgaande regels voor 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. Als u wilt voorkomen dat SNAT-poortuitputting optreedt wanneer u een NAT-gateway gebruikt om uitgaande verbindingen van een AKS-cluster te verwerken, kunt u meer openbare IP-adressen of een openbaar IP-adresvoorvoegsel aan de gateway koppelen. Zie Azure NAT Gateway-overwegingen 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. De uitgaande installatie moet door u worden uitgevoerd. U routeert bijvoorbeeld uitgaand verkeer via een Azure Firewall. Het AKS-cluster moet worden geïmplementeerd in een bestaand virtueel netwerk, met een subnet dat eerder is geconfigureerd. Wanneer u geen SLB-architectuur (Standard Load Balancer) gebruikt, moet u expliciet uitgaand verkeer instellen. 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.

Controleren

U kunt Azure Monitor en Container Insights gebruiken om tenanttoepassingen te bewaken die worden uitgevoerd op een gedeeld AKS-cluster en om kostenanalyses voor afzonderlijke naamruimten te berekenen. Met Azure Monitor kunt u de status en prestaties van Azure Kubernetes Service (AKS) bewaken. Het omvat de verzameling logboeken en metrische gegevens, telemetrieanalyse en visualisaties van verzamelde gegevens om trends te identificeren en waarschuwingen te configureren om u proactief op de hoogte te stellen van 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 door de community voor Kubernetes-bewaking. U kunt ook andere hulpprogramma's van derden 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 manieren waarop organisaties kosten kunnen beheren en optimaliseren. Deze omvatten systeemeigen Kubernetes-hulpprogramma's voor het beheren en beheren van resourcegebruik en -verbruik en om proactief de onderliggende infrastructuur te bewaken en te optimaliseren. Bij het berekenen van kosten per tenant moet u rekening houden met de kosten die zijn gekoppeld aan elke resource die wordt gebruikt door een tenanttoepassing. De aanpak die u volgt om kosten terug te brengen naar de tenants, is afhankelijk van het tenancymodel dat door uw oplossing is aangenomen. Meer informatie wordt uitgelegd met de volgende tenancymodellen:

  • Volledig multitenant: Wanneer één multitenant-toepassing alle tenantaanvragen verwerkt, is het uw verantwoordelijkheid om het resourceverbruik bij te houden en het aanvraagnummer dat door elke tenant wordt gegenereerd. 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 virtuele machines, de netwerkkosten als gevolg van netwerkverkeer, openbare IP-adressen, load balancers, de opslagservices, zoals beheerde schijven of Azure-bestanden die worden gebruikt door de tenantoplossing, enzovoort. U kunt een AKS-cluster en de bijbehorende resources in de knooppuntresourcegroep taggen om kosten in rekening te brengen. Zie Tags toevoegen aan het cluster voor meer informatie.
  • Toegewezen knooppuntgroep: U kunt een Azure-tag toepassen op een nieuwe of bestaande knooppuntgroep die is toegewezen aan één tenant. Tags die worden toegepast op een knooppuntgroep, 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 knooppuntgroepen voor 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. Met tags die op deze manier zijn ingesteld, blijven de Kubernetes-waarden behouden, 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 door Kubernetes zijn ingesteld, verwijderd. Tags voor deze resources die niet worden bijgehouden door Kubernetes, blijven ongewijzigd. Zie Tags toevoegen met behulp van Kubernetes voor meer informatie.

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

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

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Andere Inzenders:

Volgende stappen

Bekijk resources voor architecten en ontwikkelaars van multitenant-oplossingen.