Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Bij het beantwoorden van de vraag 'Hoe configureer ik Kubernetes voor multitenancy?', moeten architecten eerst de conceptuele grenzen en isolatiemodellen begrijpen die beschikbaar zijn. Multitenancy in AKS is de praktijk van het uitvoeren van meerdere geïsoleerde workloads, die behoren tot verschillende teams, toepassingen of klanten, op een gedeeld Kubernetes-cluster. In dit artikel worden de belangrijkste concepten en architectuurmodellen voor multitenancy op Azure Kubernetes Service (AKS) beschreven.
Tip
Wat zijn de drie modellen voor multi-tenancy in AKS? AKS-multitenancy maakt gebruik van een isolatiespectrum met drie algemene modellen: naamruimteisolatie, isolatie van knooppuntgroepen en cluster-per-tenant. Naamruimte-isolatie is het meest geschikt voor vertrouwde interne teams en maximale kostenefficiëntie, nodepoolisolatie biedt een sterkere scheiding tussen workloads met matige overhead, en cluster-per-tenant biedt de sterkste isolatie voor onvertrouwde of sterk gereguleerde scenario's.
Voor stapsgewijze implementatie-instructies en YAML-manifesten raadpleegt u de bijbehorende handleiding: Aanbevolen procedures voor multitenancy in AKS.
Waarom multi-tenancy op AKS?
Met meerdere tenants kunnen meerdere teams, toepassingen of klanten één Kubernetes-cluster delen. De primaire logica voor multitenancy op AKS is kostenefficiëntie en operationele schaal.
Het gebruiken van een afzonderlijk cluster voor elke applicatie of elk team leidt tot aanzienlijke versnippering van resources, ongebruikte rekencapaciteit en een veel grotere overhead van het control plane. Door workloads te consolideren in clusters met meerdere tenants, maximaliseren organisaties het resourcegebruik en verminderen ze de clouduitgaven. Operationeel vermindert multitenancy de vlootgrootte, wat betekent dat platformteams minder clusters hebben om te patchen, upgraden, bewaken en beveiligen, waardoor levenscyclusbeheer wordt stroomlijnd.
Wat is het verschil tussen zachte en harde multitenancy?
Kubernetes is geen systeem met meerdere tenants. Om multitenancy te realiseren, moet u op basis van de mate van vertrouwen tussen tenants een 'soft' of 'hard' isolatiemodel ontwerpen.
Het verschil tussen soft en hard multitenancy in Kubernetes zit voornamelijk in het vertrouwensmodel en de daaruit voortvloeiende isolatievereisten. Zachte multitenancy gaat uit van vertrouwde interne tenants en richt zich op het voorkomen van onbedoelde interferentie door middel van logische maatregelen zoals namespaces, RBAC en quota. Bij harde multitenancy wordt ervan uitgegaan dat er weinig of geen vertrouwen is tussen tenants en dat er sterkere isolatiecontroles nodig zijn om het risico op schadelijke toegang, laterale verplaatsing en blootstelling van gegevens te verminderen.
| Model | Vertrouwensniveau | Doelstelling | Gebruiksituatie | Voorbeeldscenario's |
|---|---|---|---|---|
| Soft multi-tenancy | Hoge vertrouwensrelatie tussen interne tenants | Onbedoelde interferentie, resource-uitputting en configuratieconflicten voorkomen | Interne platformomgevingen waar teams infrastructuur delen | Meerdere productteams in één organisatie die een AKS-cluster delen voor dev/test en interne services |
| Strikte multitenancy | Lage of nul vertrouwensrelatie tussen tenants | Schadelijke aanvallen, zijdelingse verplaatsing en gegevensexfiltratie voorkomen | Hosting voor externe klanten en gereguleerde workloads | SaaS-provider die klantspecifieke workloads host, waarbij tenantisolatie een beveiligings- en nalevingsvereiste is |
Het isolatiespectrum
Multitenancy op AKS is geen binaire keuze; het bestaat in een spectrum. Naarmate u het spectrum doorloopt, neemt de isolatie toe, maar leidt dit tot operationele complexiteit en kosten. Dit spectrum vormt de organiserende ruggengraat voor clusterontwerp met meerdere tenants:
- Naamruimteisolatie (logisch): tenants delen dezelfde knooppuntgroepen en hetzelfde besturingsvlak, maar worden logisch gescheiden door Kubernetes-naamruimten. Dit is de basis van soft multi-tenancy.
- Isolatie van knooppuntgroepen (fysieke berekening): tenants delen het besturingsvlak, maar worden toegewezen werkknooppunten toegewezen. Dit verbetert de scheiding van werkbelastingen en het beperken van ruis, maar het is geen volledige tenantisolatie omdat onderdelen van het besturingsvlak en clusterniveau nog steeds worden gedeeld.
- Cluster-per-tenant (compleet fysiek): Tenants zijn volledig geïsoleerd met hun eigen AKS-besturingsvlak en gegevensvlak. Dit is de ultieme vorm van harde multitenancy, waardoor het delen op Kubernetes-niveau effectief wordt overgeslagen ten gunste van isolatie op Azure niveau.
AKS-basiscomponenten voor multitenancy
AKS biedt een reeks systeemeigen en Azure-geïntegreerde basisvoorzieningen voor het afdwingen van het isolatiespectrum.
- Microsoft Entra ID: biedt gecentraliseerd identiteits- en toegangsbeheer voor het verifiëren van gebruikers en geautomatiseerde systemen voor de Kubernetes-API.
- Azure RBAC: wijst Microsoft Entra ID identiteiten toe aan Kubernetes-machtigingen, zodat tenants alleen toegang hebben tot hun geautoriseerde resources.
- Beheerde naamruimten: biedt logische grenzen binnen het cluster om tenantbronnen te groeperen, quota's toe te passen en bereiktoegang toe te passen.
- Azure Policy/Gatekeeper: dwingt gecentraliseerde nalevings- en governanceregels af in het cluster om te voorkomen dat tenants onveilige of niet-geautoriseerde configuraties implementeren.
- Azure CNI: biedt systeemeigen integratie van virtuele netwerken voor AKS-netwerken en ondersteunt segmentatie van tenantverkeer met netwerkbeleidsbesturingselementen. Ip-gedrag van pods is afhankelijk van de geselecteerde CNI-modus (bijvoorbeeld Overlay of Pod Subnet).
- Azure Container Networking Services (ACNS) Cilium L7: levert krachtige, op eBPF gebaseerde netwerkbeleidsregels en laag 7-verkeerfilters om tenantnetwerkverkeer strikt te isoleren.
- Workloadidentiteit: hiermee kunnen afzonderlijke pods veilig worden geverifieerd bij externe Azure-services met behulp van federatieve identiteit, waardoor gedeelde geheimen tussen tenants worden geëlimineerd.
Isolatielagen over vlakken heen in kaart brengen
Als u een beveiligde architectuur met meerdere tenants wilt bouwen, moet u de AKS-primitieven toepassen op drie afzonderlijke vlakken van de clusteromgeving.
| Vliegtuig | Description | Toegepaste AKS-primitieven |
|---|---|---|
| Besturingsvlak | Toegang tot de Kubernetes API-server en logische grenzen beveiligen. | Microsoft Entra ID, Azure RBAC, beheerde naamruimten |
| Gegevensvlak | Netwerkverkeer, berekeningsuitvoering en grenzen op knooppuntniveau beveiligen. | Azure CNI, ACNS Cilium L7, Node-pools |
| Resourceplane | Rekenverbruik, externe toegang en configuratiecompatibiliteit beheren. | Azure Policy, werklastidentiteit |
Welk isolatiemodel moet u kiezen?
Gebruik de volgende matrix om te bepalen welk punt in het isolatiespectrum het beste past bij uw organisatievereisten.
| Isolatiemodel | Beveiligingsniveau | Kostenefficiëntie | Operationele complexiteit | Het meest geschikt voor |
|---|---|---|---|---|
| Tenant-specifieke naamruimte | Laag tot gemiddeld (logisch) | Hoog (maximaal delen) | Laag (één cluster dat moet worden beheerd) | Interne teams, ontwikkel-/testomgevingen, zachte multitenancy. |
| Node-pool-per-tenant | Hoog (geïsoleerde rekenresources) | Gemiddeld (gedeeld besturingsvlak) | Gemiddeld (Taints/toleraties beheren) | Interne en externe workloads die een sterkere rekenscheiding nodig hebben tijdens het delen van een besturingsvlak; niet ideaal voor vijandige zero-trust tenancy. |
| Cluster-per-tenant | Hoogste (fysiek) | Laag (hoge overhead) | Hoog (Vlootbeheer vereist) | Vijandige multi-tenancy, externe zakelijke klanten, zero-trust. |
Wanneer gebruikt u elk model?
- Gebruik naamruimte per tenant wanneer tenants intern of vertrouwd zijn, kostenefficiëntie een prioriteit is en logische isolatiebesturingselementen voldoende zijn.
- Gebruik node-pool-per-tenant wanneer u een sterkere scheiding van rekenresources nodig hebt en minder last wilt hebben van noisy-neighbor-effecten, terwijl u wel één AKS-besturingsvlak blijft delen.
- Gebruik cluster-per-tenant wanneer tenants niet-vertrouwd zijn, wettelijke grenzen strikt zijn of uw risicomodel minimale gedeelde infrastructuur vereist.
Volgende stappen
Nu u de conceptuele modellen en primitieven voor multitenancy begrijpt, gaat u verder met de implementatiehandleiding om deze concepten toe te passen op uw cluster.
Waar het op neer komt
- Multitenancy in Azure Kubernetes Service (AKS) is de praktijk van het uitvoeren van meerdere geïsoleerde tenantworkloads op een gedeelde Kubernetes-infrastructuur om de kosten te verlagen en bewerkingen te vereenvoudigen.
- Een naamruimte per tenant is het meest kostenefficiënte model voor vertrouwde interne werklasten, omdat hiermee de infrastructuur maximaal wordt gedeeld, waarbij logische scheidingen worden aangebracht.
- Eén knooppuntpool per tenant verbetert de scheiding van rekencapaciteit en de beheersing van noisy-neighbor-effecten, maar deelt nog steeds de AKS-beheerlaag en andere componenten op clusterniveau.
- Cluster-per-tenant biedt de sterkste tenantisolatie voor scenario's zonder vertrouwen en sterk gereglementeerd, maar hiervoor zijn hogere kosten en meer operationele overhead vereist.