Best practices voor clusterisolatie in Azure Kubernetes Service (AKS)
Wanneer u clusters beheert in Azure Kubernetes Service (AKS), moet u vaak teams en workloads isoleren. AKS biedt flexibiliteit bij het uitvoeren van clusters met meerdere tenants en het isoleren van resources. Om uw investering in Kubernetes te maximaliseren, is het belangrijk dat u inzicht krijgt in AKS-functies voor multitenancy en isolatie.
Dit artikel met aanbevolen procedures is gericht op isolatie voor clusteroperators. In dit artikel leert u het volgende:
- Plannen voor clusters met meerdere tenants en scheiding van resources.
- Gebruik logische of fysieke isolatie in uw AKS-clusters.
Clusters ontwerpen voor multitenancy
Met Kubernetes kunt u teams en workloads in hetzelfde cluster logisch isoleren. Het doel is om het minste aantal bevoegdheden op te geven met betrekking tot de resources die elk team nodig heeft. Een Kubernetes-naamruimte maakt een logische isolatiegrens. Andere Kubernetes-functies en -overwegingen voor isolatie en multitenancy omvatten de volgende gebieden:
Plannen
Planning maakt gebruik van basisfuncties zoals resourcequota en budgetten voor podonderbreking. Zie Aanbevolen procedures voor basisfuncties in AKS voor meer informatie over deze functies.
Meer geavanceerde scheduler-functies zijn:
- Taints en toleranties.
- Knooppuntkiezers.
- Affiniteit tussen knooppunten en pods of antiaffiniteit.
Zie Aanbevolen procedures voor geavanceerde scheduler-functies in AKS voor meer informatie over deze functies.
Netwerken
Netwerken maken gebruik van netwerkbeleid om de verkeersstroom in en uit pods te beheren.
Verificatie en autorisatie
Verificatie en autorisatie maakt gebruik van:
- RBAC (op rollen gebaseerd toegangsbeheer).
- Microsoft Entra-integratie.
- Pod-identiteiten.
- Geheimen in Azure Key Vault.
Zie Best practices voor verificatie en autorisatie in AKS voor meer informatie over deze functies.
Containers
Containers zijn onder andere:
- De Azure Policy-invoegtoepassing voor AKS om podbeveiliging af te dwingen.
- Toegang tot podbeveiliging.
- Installatiekopieën en runtime scannen op beveiligingsproblemen.
- App Armor of Seccomp (Secure Computing) gebruiken om de toegang van containers tot het onderliggende knooppunt te beperken.
Logisch geïsoleerde clusters
Richtlijnen voor best practices
Teams en projecten scheiden met behulp van logische isolatie. Minimaliseer het aantal fysieke AKS-clusters dat u implementeert om teams of toepassingen te isoleren.
Met logische isolatie kunt u één AKS-cluster gebruiken voor meerdere workloads, teams of omgevingen. Kubernetes-naamruimten vormen de logische isolatiegrens voor workloads en resources.
Logische scheiding van clusters biedt meestal een hogere poddichtheid dan fysiek geïsoleerde clusters, met minder overtollige rekencapaciteit die inactief is in het cluster. In combinatie met de automatische schaalaanpassing van Kubernetes-clusters kunt u het aantal knooppunten omhoog of omlaag schalen om aan de eisen te voldoen. Deze best practice aanpak minimaliseert de kosten door alleen het vereiste aantal knooppunten uit te voeren.
Kubernetes-omgevingen zijn niet volledig veilig voor vijandig gebruik met meerdere tenants. In een omgeving met meerdere tenants werken meerdere tenants aan een gedeelde infrastructuur. Als alle tenants niet kunnen worden vertrouwd, hebt u extra planning nodig om te voorkomen dat tenants de beveiliging en service van anderen beïnvloeden.
Andere beveiligingsfuncties, zoals Kubernetes RBAC voor knooppunten, blokkeren efficiënt exploits. Voor echte beveiliging bij het uitvoeren van vijandige workloads met meerdere tenants moet u alleen een hypervisor vertrouwen. Het beveiligingsdomein voor Kubernetes wordt het hele cluster en niet een afzonderlijk knooppunt.
Voor deze typen vijandige workloads met meerdere tenants moet u fysiek geïsoleerde clusters gebruiken.
Fysiek geïsoleerde clusters
Richtlijnen voor best practices
Minimaliseer het gebruik van fysieke isolatie voor elke afzonderlijke team- of toepassingsimplementatie en gebruik in plaats daarvan logische isolatie.
Het fysiek scheiden van AKS-clusters is een algemene benadering van clusterisolatie. In dit isolatiemodel krijgen teams of workloads hun eigen AKS-cluster toegewezen. Hoewel fysieke isolatie eruit kan zien als de eenvoudigste manier om workloads of teams te isoleren, voegt dit beheer en financiële overhead toe. Met fysiek geïsoleerde clusters moet u meerdere clusters onderhouden en afzonderlijk toegang verlenen en machtigingen toewijzen. U wordt ook gefactureerd voor elk afzonderlijk knooppunt.
Fysiek geïsoleerde clusters hebben meestal een lage poddichtheid. Omdat elk team of elke workload een eigen AKS-cluster heeft, is het cluster vaak te ruim ingericht met rekenresources. Vaak worden er een paar pods gepland op deze knooppunten. Capaciteit van niet-geclaimde knooppunten kan niet worden gebruikt voor toepassingen of services in ontwikkeling door andere teams. Deze overtollige resources dragen bij aan de extra kosten in fysiek geïsoleerde clusters.
Volgende stappen
Dit artikel is gericht op clusterisolatie. Zie de volgende artikelen over aanbevolen procedures voor meer informatie over clusterbewerkingen in AKS: