Delen via

Overzicht van beheerde naamruimten in Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Wanneer u clusters beheert in Azure Kubernetes Service (AKS), moet u vaak teams en workloads 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. Het uitvoeren van logische isolatie omvat het implementeren van scripts en processen voor het maken van naamruimten, het instellen van resourcelimieten, het toepassen van netwerkbeleid en het verlenen van teamtoegang via op rollen gebaseerd toegangsbeheer. Meer informatie over het gebruik van beheerde naamruimten in Azure Kubernetes Service (AKS) om het beheer van naamruimten, multitenancy van clusters en resourceisolatie te vereenvoudigen.

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 automatische schaalaanpassing van clusters of automatische inrichting van knooppunten kunt u het aantal knooppunten omhoog of omlaag schalen om te voldoen aan de vereisten. Deze best practice aanpak minimaliseert de kosten door alleen het vereiste aantal knooppunten uit te voeren.

Netwerkbeleid

Netwerkbeleid is Kubernetes-resources die u kunt gebruiken om de verkeersstroom tussen pods, naamruimten en externe eindpunten te beheren. Met netwerkbeleid kunt u regels definiëren voor inkomend (inkomend) en uitgaand verkeer (uitgaand verkeer), zodat alleen geautoriseerde communicatie is toegestaan. Door netwerkbeleid toe te passen, kunt u de beveiliging en isolatie van workloads binnen uw cluster verbeteren.

Opmerking

De standaardregel voor inkomend netwerkbeleid van Dezelfde naamruimte toestaan kiest standaard voor een veilige houding. Als u wilt dat uw Kubernetes Services, ingresses of gateways toegankelijk zijn van buiten de naamruimte waar ze worden geïmplementeerd, bijvoorbeeld vanaf een ingangscontroller die is geïmplementeerd in een afzonderlijke naamruimte, moet u Alles toestaan selecteren. U kunt vervolgens uw eigen netwerkbeleid toepassen om het binnenkomend netwerkverkeer te beperken, zodat alleen verkeer uit die naamruimte is toegestaan.

Beheerde naamruimten worden geleverd met een set ingebouwde beleidsregels.

  • Alles toestaan: hiermee staat u al het netwerkverkeer toe.
  • Dezelfde naamruimte toestaan: staat al het netwerkverkeer binnen dezelfde naamruimte toe.
  • Alles weigeren: hiermee weigert u al het netwerkverkeer.

U kunt elk van de ingebouwde beleidsregels toepassen op regels voor inkomend en uitgaand verkeer en ze hebben de volgende standaardwaarden.

Beleid Standaardwaarde
Ingang Dezelfde naamruimte toestaan
Uitgang Alles toestaan

Opmerking

Gebruikers met een Microsoft.ContainerService/managedClusters/networking.k8s.io/networkpolicies/write actie, zoals Azure Kubernetes Service RBAC Writer, binnen de Microsoft Entra ID-rol die aan hen is toegewezen, kunnen netwerkbeleidregels toevoegen via de Kubernetes-API.

Als een beheerder bijvoorbeeld een Deny All beleid toepast voor inkomend/uitgaand verkeer en een gebruiker een Allow beleid toepast voor een naamruimte via de Kubernetes-API, heeft het Allow beleid prioriteit boven het Deny All beleid en wordt verkeer toegestaan voor de naamruimte.

Resourcequota

Resourcequota zijn Kubernetes-resources die worden gebruikt om het resourceverbruik van naamruimten binnen een cluster te beheren en te beperken. Hiermee kunnen beheerders beperkingen definiëren voor de hoeveelheid CPU, geheugen, opslag of andere resources die worden gebruikt door workloads in een naamruimte. Door resourcequota toe te passen, kunt u zorgen voor evenredige verdeling van resources, het overgebruik van resources voorkomen en de stabiliteit van clusters behouden.

Beheerde naamruimten kunnen worden gemaakt met de volgende resourcequota:

  • CPU-aanvragen en -limieten: definieer de minimale en maximale hoeveelheid CPU-resources die workloads in de naamruimte kunnen aanvragen of gebruiken. Het quotum zorgt ervoor dat werkbelastingen voldoende CPU-resources hebben om te functioneren, terwijl wordt voorkomen dat overgebruik optreedt dat invloed kan hebben op andere naamruimten. Het quotum wordt gedefinieerd in de milliCPU-vorm.
  • Geheugenaanvragen en -limieten: geef de minimale en maximale hoeveelheid geheugenbronnen op die workloads in de naamruimte kunnen aanvragen of gebruiken. Het quotum helpt stabiliteit te behouden door overtoewijzing van geheugen te voorkomen en eerlijke resourcetoewijzing tussen naamruimten te garanderen. Het quotum wordt gedefinieerd in de vorm van machten van twee equivalenten, zoals Ei, Pi, Ti, Gi, Mi, Ki.

Labels en aantekeningen

Kubernetes-labels en aantekeningen zijn metagegevens die zijn gekoppeld aan Kubernetes-objecten, zoals naamruimten, om aanvullende informatie te verstrekken. Labels zijn sleutel-waardeparen die worden gebruikt om resources te ordenen en te selecteren, waardoor efficiënte groepering en query's mogelijk zijn. Aantekeningen slaan niet-geïdentificeerde metagegevens op, zoals configuratiedetails of operationele instructies, die worden gebruikt door hulpprogramma's of systemen.

U kunt desgewenst Kubernetes-labels en aantekeningen instellen die moeten worden toegepast op de naamruimte.

Acceptatiebeleid

Het acceptatiebeleid bepaalt hoe een bestaande naamruimte in Kubernetes wordt verwerkt bij het maken van een beheerde naamruimte.

Waarschuwing

Het onboarden van een bestaande naamruimte die moet worden beheerd, kan leiden tot onderbrekingen. Als het toegepaste resourcequotum kleiner is dan wat er al door pods wordt aangevraagd, worden nieuwe implementaties en pods die het quotum overschrijden, geweigerd. Bestaande implementaties worden niet beïnvloed, maar schalen is niet toegestaan. Het toepassen van netwerkbeleid op een bestaande naamruimte kan van invloed zijn op bestaand verkeer. Zorg ervoor dat het beleid wordt getest en gevalideerd om onbedoelde onderbrekingen van de communicatie tussen pods of externe eindpunten te voorkomen.

De volgende opties zijn beschikbaar:

  • Nooit: Als de naamruimte al in het cluster bestaat, mislukt het maken van die naamruimte als een beheerde naamruimte.
  • IfIdentical: neem de bestaande naamruimte over die moet worden beheerd, mits er geen verschillen zijn tussen de bestaande naamruimte en de gewenste configuratie.
  • Altijd: neem altijd de bestaande naamruimte over die moet worden beheerd, zelfs als sommige velden in de naamruimte mogelijk worden overschreven.

Beleid verwijderen

Het verwijderingsbeleid geeft aan hoe de Kubernetes-naamruimte wordt verwerkt wanneer de beheerde naamruimteresource wordt verwijderd.

Waarschuwing

Als u een beheerde naamruimte verwijdert met het beleid Verwijderen , worden alle resources in die naamruimte, zoals Implementaties, Services, Ingresses en andere Kubernetes-objecten, verwijderd. Zorg ervoor dat u een back-up maakt van kritieke resources of migreert voordat u doorgaat.

De volgende opties zijn beschikbaar:

  • Behouden: Verwijder alleen de resource van de beheerde naamruimte terwijl u de Kubernetes-naamruimte intact houdt. Daarnaast wordt het ManagedByARM label verwijderd uit de naamruimte.
  • Verwijderen: Verwijder zowel de beheerde naamruimteresource als de Kubernetes-naamruimte samen.

Ingebouwde rollen voor beheerde naamruimten

Beheerde naamruimten maken gebruik van de volgende ingebouwde rollen voor het besturingsvlak.

Rol Beschrijving
Inzender voor Azure Kubernetes Service-naamruimten Hiermee kunt u beheerde naamruimten in een cluster maken, bijwerken en verwijderen.
Azure Kubernetes Service Namespace User Hiermee staat u alleen-lezentoegang toe tot een beheerde naamruimte in een cluster. Hiermee verleent u toegang tot lijstreferenties in de naamruimte.

Beheerde naamruimten maken gebruik van de volgende ingebouwde rollen voor het gegevensvlak.

Rol Beschrijving
Azure Kubernetes Service RBAC Reader Staat alleen-lezentoegang toe om de meeste objecten in een naamruimte te zien. Het laat niet toe om rollen of rolbindingen weer te geven. Deze rol staat het bekijken van geheimen niet toe, omdat het lezen van de inhoud van geheimen toegang biedt tot ServiceAccount-referenties in de naamruimte, waardoor API-toegang wordt toegestaan als enige ServiceAccount in de naamruimte (een vorm van escalatie van bevoegdheden).
Azure Kubernetes Service RBAC Writer Geeft lees-/schrijftoegang tot de meeste objecten in een namespace. Deze rol staat het weergeven of wijzigen van rollen of rolbindingen niet toe. Deze rol biedt echter toegang tot geheimen en het uitvoeren van pods als een ServiceAccount in de naamruimte, zodat deze kan worden gebruikt om de API-toegangsniveaus van een ServiceAccount in de naamruimte te verkrijgen.
Azure Kubernetes Service RBAC-beheerder Staat lees-/schrijftoegang toe tot de meeste resources in een naamruimte, inclusief de mogelijkheid om rollen en rolbindingen in de naamruimte te maken. Met deze rol is schrijftoegang tot het resourcequotum of de naamruimte zelf niet toegestaan.

Use cases voor beheerde naamruimten

Het correct instellen van naamruimten met gekoppelde quota of netwerkbeleid kan complex en tijdrovend zijn. Met beheerde naamruimten kunt u vooraf geconfigureerde naamruimten instellen in uw AKS-clusters waarmee u kunt communiceren met behulp van de Azure CLI.

In de volgende secties worden enkele veelvoorkomende use cases voor beheerde naamruimten beschreven.

Teams en middelen beheren op AKS

Stel dat u een admin bent bij een kleine startup. U hebt een AKS-cluster ingericht en u wilt naamruimten instellen voor ontwikkelaars van uw financiële, juridische en ontwerpteams . Wanneer u de omgeving van uw bedrijf instelt, wilt u ervoor zorgen dat de toegang nauw wordt beheerd, resources juist zijn afgestemd en omgevingen goed zijn georganiseerd.

  • Het financiële team ontvangt formulieren en bestanden van teams in het hele bedrijf, maar ze bevatten gevoelige informatie die hun omgeving idealiter niet zou mogen verlaten. Hun toepassingen en werkstromen zijn lichter aan de computerzijde, maar verbruiken veel geheugen. Als gevolg hiervan besluit u een naamruimte in te stellen waarmee alle netwerktoegang wordt toegestaan, netwerkverkeer naar buiten alleen binnen hun naamruimte plaatsvindt, en de resources dienovereenkomstig worden behandeld. Een label voor de naamruimte helpt eenvoudig te identificeren welk team het gebruikt.

    az aks namespace add \
   --name $FINANCE_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 250m \
   --cpu-limit 500m \
   --memory-request 512Mi \
   --memory-limit 2Gi \
   --ingress-policy AllowAll \
   --egress-policy AllowSameNamespace \
   --labels team=finance

  • Het juridische team behandelt voornamelijk gevoelige gegevens. Hun toepassingen gebruiken een redelijke hoeveelheid geheugen, maar vereisen weinig rekenresources. U besluit een naamruimte in te stellen die extreem beperkend is voor zowel het toegangs-/uitgangsbeleid als om de resourcequota dienovereenkomstig vast te stellen.

    az aks namespace add \
   --name $LEGAL_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 250m \
   --cpu-limit 500m \
   --memory-request 2Gi \
   --memory-limit 5Gi \
   --ingress-policy DenyAll \
   --egress-policy DenyAll \
   --labels team=legal

  • Het ontwerpteam heeft de mogelijkheid nodig om gegevens vrij te laten stromen om hun werk in het hele bedrijf te laten zien. Ze moedigen teams ook aan om inhoud ter referentie te verzenden. Hun toepassingen zijn intensief en vereisen een groot deel van het geheugen en de CPU. U besluit ze in te stellen met een minimaal beperkende naamruimte en een aanzienlijke hoeveelheid resources toe te wijzen.

    az aks namespace add \
   --name $DESIGN_NAMESPACE \
   --cluster-name $CLUSTER_NAME \
   --resource-group $RESOURCE_GROUP \
   --cpu-request 2000m \
   --cpu-limit 2500m \
   --memory-request 5Gi \
   --memory-limit 8Gi \
   --ingress-policy AllowAll \
   --egress-policy AllowAll \
   --labels team=design

Nu deze naamruimten zijn ingesteld, hebt u nu omgevingen voor de drie teams in uw organisatie waarmee elk team aan de slag kan in een omgeving die het beste bij hun behoeften past. Beheerders kunnen Azure CLI-aanroepen gebruiken om de naamruimten bij te werken naarmate de behoeften veranderen.

Beheerde naamruimten weergeven

Naarmate het aantal teams waarmee u te maken krijgt, uitbreidt of als uw organisatie groeit, moet u mogelijk de naamruimten bekijken die u hebt ingesteld.

Stel dat u de naamruimten in uw cluster uit de vorige sectie wilt controleren om ervoor te zorgen dat er drie naamruimten zijn.

Gebruik de az aks namespace list opdracht om uw naamruimten te controleren.

az aks namespace list \
  --cluster-name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --output table

Uw output zou eruit moeten zien zoals de volgende voorbeeldoutput.

Name                               ResourceGroup    Location
------------------                 ---------------  ----------
$CLUSTER_NAME/$DESIGN_NAMESPACE    $RESOURCE_GROUP  <LOCATION>
$CLUSTER_NAME/$LEGAL_NAMESPACE     $RESOURCE_GROUP  <LOCATION>
$CLUSTER_NAME/$FINANCE_NAMESPACE   $RESOURCE_GROUP  <LOCATION>

Toegang tot beheerde naamruimten beheren

U kunt azure RBAC-rollen, die zijn gericht op elke naamruimte, verder gebruiken om te bepalen welke gebruikers toegang hebben tot bepaalde acties binnen de naamruimte. Met de juiste configuratie kunt u ervoor zorgen dat gebruikers alle toegang hebben die ze nodig hebben binnen de naamruimte, terwijl ze hun toegang tot andere naamruimten of clusterbrede resources beperken.

Volgende stappen

  • Last updated on