Basislijnarchitectuur voor een Azure Kubernetes Service-cluster (AKS)

Deze referentiearchitectuur biedt een aanbevolen basisinfrastructuurarchitectuur voor het implementeren van een AKS-cluster (Azure Kubernetes Service) in Azure. Het maakt gebruik van onze ontwerpprincipes en is gebaseerd op onze best practices voor architectuur van het Azure Well-Architected Framework om een interdisciplinaire of meerdere afzonderlijke teams, zoals netwerken, beveiliging en identiteit, te begeleiden door deze infrastructuur voor algemeen gebruik te implementeren.

Deze architectuur is niet gericht op een workload, maar richt zich op het AKS-cluster zelf. De informatie hier is de minimaal aanbevolen basislijn voor de meeste AKS-clusters. Het is geïntegreerd met Azure-services die waarneembaarheid bieden, een netwerktopologie die ondersteuning biedt voor groei in meerdere regio's en het verkeer in het cluster beveiligt.

De doelarchitectuur wordt beïnvloed door uw bedrijfsvereisten en kan daardoor variëren tussen verschillende toepassingscontexten. Het moet als uitgangspunt worden beschouwd voor preproductie- en productiefasen.

Er is ook een implementatie van deze architectuur beschikbaar op GitHub: Azure Kubernetes Service (AKS) Baseline Reference Implementation. U kunt het als alternatief uitgangspunt gebruiken en configureren op basis van uw behoeften.

Netwerkconfiguratie

Netwerktopologie
De IP-adressen plannen
Toegangsbeheerde resources implementeren

Cluster berekenen

Berekenen voor het basiscluster
Naslaginformatie over containerinstallatiekopieën
Beleidsbeheer

Identiteitsbeheer

Microsoft Entra-id voor het cluster integreren
Microsoft Entra-id integreren voor de workload

Gegevensstroom beveiligen

De netwerkstroom beveiligen
Geheimbeheer toevoegen

Bedrijfscontinuïteit

Schaalbaarheid
Beschikbaarheid van clusters en knooppunten
Beschikbaarheid en ondersteuning voor meerdere regio's

Operations

CI/CD-pijplijnen voor clusters en workloads
Clusterstatus en metrische gegevens
Kostenbeheer en rapportage

Netwerktopologie

Deze architectuur maakt gebruik van een sternetwerktopologie. De hub en spoke(s) worden geïmplementeerd in afzonderlijke virtuele netwerken die zijn verbonden via peering. Enkele voordelen van deze topologie zijn:

• Gescheiden beheer. Hiermee kunt u governance toepassen en voldoen aan het principe van minimale bevoegdheden. Het biedt ook ondersteuning voor het concept van een Azure-landingszone met scheiding van taken.

• Minimaliseert de directe blootstelling van Azure-resources aan het openbare internet.

• Organisaties werken vaak met regionale hub-spoke-topologieën. Hub-spoke-netwerktopologieën kunnen in de toekomst worden uitgebreid en bieden isolatie van werkbelastingen.

• Voor alle webtoepassingen moet een WAF-service (Web Application Firewall) zijn vereist om de HTTP-verkeersstroom te beheren.

• Een natuurlijke keuze voor workloads die meerdere abonnementen omvatten.

• Hierdoor kan de architectuur worden uitgebreid. Voor nieuwe functies of workloads kunnen nieuwe spokes worden toegevoegd in plaats van de netwerktopologie opnieuw te ontwerpen.

• Bepaalde resources, zoals een firewall en DNS, kunnen worden gedeeld via netwerken.

• Komt overeen met de landingszones op ondernemingsniveau van Azure.

Een Visio-bestand van deze architectuur downloaden.

Zie Hub-spoke-netwerktopologie in Azure voor meer informatie.

Als u de wijzigingen in het netwerkontwerp in de Windows-containers in de referentiearchitectuur van de AKS-basislijn wilt bekijken, raadpleegt u het bijbehorende artikel.

Hub

Het virtuele hubnetwerk is het centrale punt van connectiviteit en waarneembaarheid. Een hub bevat altijd een Azure Firewall met globaal firewallbeleid dat is gedefinieerd door uw centrale IT-teams om het firewallbeleid voor de hele organisatie af te dwingen, Azure Bastion, een gatewaysubnet voor VPN-connectiviteit en Azure Monitor voor waarneembaarheid van het netwerk.

Binnen het netwerk worden drie subnetten geïmplementeerd.

Subnet voor het hosten van Azure Firewall

Azure Firewall is firewall als een service. Het firewallexemplaren beveiligt uitgaand netwerkverkeer. Zonder deze beveiligingslaag kan dit verkeer communiceren met een schadelijke service van derden die gevoelige bedrijfsgegevens kan exfiltreren. Met Azure Firewall Manager kunt u centraal meerdere Azure Firewall-exemplaren implementeren en configureren en Azure Firewall-beleid beheren voor dit type netwerkarchitectuur van de hub.

Subnet voor het hosten van een gateway

Dit subnet is een tijdelijke aanduiding voor een VPN- of ExpressRoute-gateway. De gateway biedt connectiviteit tussen de routers in uw on-premises netwerk en het virtuele netwerk.

Subnet voor het hosten van Azure Bastion

Dit subnet is een tijdelijke aanduiding voor Azure Bastion. U kunt Bastion gebruiken om veilig toegang te krijgen tot Azure-resources zonder de resources beschikbaar te maken op internet. Dit subnet wordt alleen gebruikt voor beheer en bewerkingen.

Sprak

Het virtuele spoke-netwerk bevat het AKS-cluster en andere gerelateerde resources. De spoke heeft vier subnetten:

Subnet voor het hosten van Azure-toepassing-gateway

Azure Application Gateway is een load balancer voor webverkeer die wordt uitgevoerd op Laag 7. De referentie-implementatie maakt gebruik van de Application Gateway v2-SKU die Web Application Firewall (WAF) inschakelt. WAF beveiligt binnenkomend verkeer van veelvoorkomende webverkeeraanvallen, waaronder bots. Het exemplaar heeft een openbare front-end-IP-configuratie die gebruikersaanvragen ontvangt. Application Gateway vereist standaard een toegewezen subnet.

Subnet voor het hosten van de toegangsbeheerobjectbronnen

Traefik is de ingangscontroller die voldoet aan de Kubernetes-toegangsbeheerobjectbronnen om verkeer te routeren en te distribueren. De interne Load Balancers van Azure bevinden zich in dit subnet. Zie Een interne load balancer gebruiken met Azure Kubernetes Service (AKS) voor meer informatie.

Subnet voor het hosten van de clusterknooppunten

AKS onderhoudt twee afzonderlijke groepen knooppunten (of knooppuntgroepen). De systeemknooppuntgroep host pods waarop kernclusterservices worden uitgevoerd. De gebruikersknooppuntgroep voert uw workload en de ingangscontroller uit om binnenkomende communicatie met de workload mogelijk te maken.

Subnet voor het hosten van Private Link-eindpunten

Azure Private Link-verbindingen worden gemaakt voor Azure Container Registry en Azure Key Vault, zodat deze services kunnen worden geopend met behulp van een privé-eindpunt in het virtuele spoke-netwerk. Voor privé-eindpunten is geen toegewezen subnet vereist en kunnen ze ook in het virtuele hubnetwerk worden geplaatst. In de implementatie van de basislijn worden ze geïmplementeerd in een toegewezen subnet binnen het virtuele spoke-netwerk. Deze aanpak vermindert het verkeer dat de gekoppelde netwerkverbinding doorgeeft, bewaart de resources die deel uitmaken van het cluster in hetzelfde virtuele netwerk en stelt u in staat om gedetailleerde beveiligingsregels toe te passen op subnetniveau met behulp van netwerkbeveiligingsgroepen.

Zie Private Link-implementatieopties voor meer informatie.

IP-adressen plannen

Een Visio-bestand van deze architectuur downloaden.

De adresruimte van het virtuele netwerk moet groot genoeg zijn om alle subnetten te kunnen bevatten. Account voor alle entiteiten die verkeer ontvangen. IP-adressen voor deze entiteiten worden toegewezen vanuit de adresruimte van het subnet. Houd rekening met deze punten.

• Upgraden

  AKS werkt knooppunten regelmatig bij om ervoor te zorgen dat de onderliggende virtuele machines up-to-date zijn op beveiligingsfuncties en andere systeempatches. Tijdens een upgradeproces maakt AKS een knooppunt dat tijdelijk als host fungeert voor de pods, terwijl het upgradeknooppunt is vastgezet en leeg is. Aan dat tijdelijke knooppunt wordt een IP-adres toegewezen vanuit het clustersubnet.

  Voor pods hebt u mogelijk aanvullende adressen nodig, afhankelijk van uw strategie. Voor rolling updates hebt u adressen nodig voor de tijdelijke pods waarop de workload wordt uitgevoerd terwijl de werkelijke pods worden bijgewerkt. Als u de vervangingsstrategie gebruikt, worden pods verwijderd en worden de nieuwe gemaakt. Adressen die aan de oude pods zijn gekoppeld, worden dus opnieuw gebruikt.

• Schaalbaarheid

  Let op het aantal knooppunten van alle systeem- en gebruikersknooppunten en de maximale schaalbaarheidslimiet. Stel dat u wilt uitschalen met 400%. U hebt vier keer het aantal adressen nodig voor al deze uitgeschaalde knooppunten.

  In deze architectuur kan rechtstreeks contact worden opgenomen met elke pod. Elke pod heeft dus een afzonderlijk adres nodig. Schaalbaarheid van pods heeft invloed op de adresberekening. Deze beslissing is afhankelijk van uw keuze over het aantal pods dat u wilt laten groeien.

• Azure Private Link-adressen

  Houd rekening met de adressen die nodig zijn voor communicatie met andere Azure-services via Private Link. In deze architectuur hebben we twee adressen toegewezen voor de koppelingen naar Azure Container Registry en Key Vault.

• Bepaalde adressen zijn gereserveerd voor gebruik door Azure. Ze kunnen niet worden toegewezen.

De voorgaande lijst is niet volledig. Als uw ontwerp andere resources heeft die van invloed zijn op het aantal beschikbare IP-adressen, kunt u deze adressen gebruiken.

Deze architectuur is ontworpen voor één workload. Voor meerdere workloads wilt u de gebruikersknooppuntgroepen mogelijk van elkaar en van de systeemknooppuntgroep isoleren. Deze keuze resulteert in meer subnetten die kleiner zijn. De toegangsbeheerresource kan ook complexer zijn. Als gevolg hiervan hebt u mogelijk meerdere toegangsbeheerobjectcontrollers nodig waarvoor extra IP-adressen zijn vereist.

Zie de AKS-basislijnnetwerktopologie voor de volledige set overwegingen voor deze architectuur.

Zie IP-adressering plannen voor uw cluster voor informatie over het plannen van IP-adressen voor een AKS-cluster.

Als u de overwegingen voor het plannen van IP-adressen in de Windows-containers in de referentiearchitectuur van de AKS-basislijn wilt bekijken, raadpleegt u het bijbehorende artikel.

Invoegtoepassingen en preview-functies

Kubernetes en AKS ontwikkelen voortdurend producten, met snellere releasecycli dan software voor on-premises omgevingen. Deze basislijnarchitectuur is afhankelijk van de geselecteerde AKS-preview-functies en AKS-invoegtoepassingen. Het verschil tussen de twee is als volgt:

• Het AKS-team beschrijft preview-functies zoals verzonden en verbeterd. De reden hiervoor is dat veel van de preview-functies slechts enkele maanden in die staat blijven voordat ze overschakelen naar de algemene releasefase (GA).
• AKS-invoegtoepassingen en -extensies bieden extra, ondersteunde functionaliteit. Hun installatie, configuratie en levenscyclus worden beheerd door AKS.

Deze basislijnarchitectuur bevat niet elke preview-functie of invoegtoepassing, in plaats daarvan alleen de functies die aanzienlijke waarde toevoegen aan een cluster voor algemeen gebruik. Naarmate deze functies uit de preview-fase komen, wordt deze basislijnarchitectuur dienovereenkomstig herzien. Er zijn enkele extra preview-functies of AKS-invoegtoepassingen die u mogelijk wilt evalueren in preproductieclusters die uw beveiliging, beheerbaarheid of andere vereisten verbeteren. Met invoegtoepassingen van derden moet u deze installeren en onderhouden, inclusief het bijhouden van beschikbare versies en het installeren van updates na het upgraden van de Kubernetes-versie van een cluster.

Naslaginformatie over containerinstallatiekopieën

Naast de workload kan het cluster verschillende andere installatiekopieën bevatten, zoals de ingangscontroller. Sommige van deze installatiekopieën bevinden zich mogelijk in openbare registers. Houd rekening met deze punten wanneer u ze in uw cluster ophaalt.

• Het cluster wordt geverifieerd om de installatiekopie op te halen.

• Als u een openbare installatiekopieën gebruikt, kunt u deze importeren in het containerregister dat overeenkomt met uw SLO. Anders is de installatiekopieën mogelijk onderhevig aan onverwachte beschikbaarheidsproblemen. Deze problemen kunnen operationele problemen veroorzaken als de installatiekopieën niet beschikbaar zijn wanneer u deze nodig hebt. Hier volgen enkele voordelen van het gebruik van uw containerregister in plaats van een openbaar register:

  • U kunt onbevoegde toegang tot uw afbeeldingen blokkeren.
  • U hebt geen openbare afhankelijkheden.
  • U hebt toegang tot pull-logboeken voor installatiekopieën om activiteiten te bewaken en verbindingsproblemen op te lossen.
  • Profiteer van geïntegreerde containerscans en naleving van installatiekopieën.

  Een optie is Azure Container Registry (ACR).

• Haal installatiekopieën op uit geautoriseerde registers. U kunt deze beperking afdwingen via Azure Policy. In deze referentie-implementatie haalt het cluster alleen installatiekopieën op uit ACR die is geïmplementeerd als onderdeel van de architectuur.

Rekenkracht configureren voor het basiscluster

In AKS wordt elke knooppuntgroep toegewezen aan een virtuele-machineschaalset. Knooppunten zijn VM's in elke knooppuntgroep. Overweeg om een kleinere VM-grootte te gebruiken voor de systeemknooppuntgroep om de kosten te minimaliseren. Met deze referentie-implementatie wordt de systeemknooppuntgroep geïmplementeerd met drie DS2_v2 knooppunten. Deze grootte is voldoende om te voldoen aan de verwachte belasting van de systeempods. De besturingssysteemschijf is 512 GB.

Hier volgen enkele overwegingen voor de gebruikersknooppuntgroep:

• Kies grotere knooppuntgrootten om het maximum aantal pods in te pakken dat is ingesteld op een knooppunt. Het minimaliseert de footprint van services die worden uitgevoerd op alle knooppunten, zoals bewaking en logboekregistratie.

• Implementeer ten minste twee knooppunten. Op die manier heeft de workload een patroon voor hoge beschikbaarheid met twee replica's. Met AKS kunt u het aantal knooppunten wijzigen zonder het cluster opnieuw te maken.

• De werkelijke knooppuntgrootten voor uw workload zijn afhankelijk van de vereisten die door het ontwerpteam worden bepaald. Op basis van de bedrijfsvereisten hebben we DS4_v2 gekozen voor de productieworkload. Als u de kosten wilt verlagen, kunt u de grootte verlagen tot DS3_v2, wat de minimale aanbeveling is.

• Bij het plannen van capaciteit voor uw cluster, wordt ervan uitgegaan dat uw workload maximaal 80% van elk knooppunt kan verbruiken; de resterende 20% is gereserveerd voor AKS-services.

• Stel de maximale pods per knooppunt in op basis van uw capaciteitsplanning. Als u een basislijn voor capaciteit wilt instellen, begint u met een waarde van 30. Pas deze waarde aan op basis van de vereisten van de workload, de grootte van het knooppunt en uw IP-beperkingen.

Microsoft Entra-id voor het cluster integreren

Het beveiligen van de toegang tot en van het cluster is essentieel. Denk vanuit het perspectief van het cluster wanneer u beveiligingskeuzen maakt:

• Toegang tot binnenuit. AKS-toegang tot Azure-onderdelen, zoals netwerkinfrastructuur, Azure Container Registry en Azure Key Vault. Autoriseren alleen de resources waartoe het cluster toegang heeft.
• Externe toegang. Identiteiten toegang verlenen tot het Kubernetes-cluster. Autoriseren alleen de externe entiteiten die toegang hebben tot de Kubernetes-API-server en Azure Resource Manager.

AKS-toegang tot Azure

Er zijn twee manieren om AKS-toegang tot Azure te beheren via Microsoft Entra ID: service-principals of beheerde identiteiten voor Azure-resources.

Van de twee manieren wordt beheerde identiteiten aanbevolen. Met service-principals bent u verantwoordelijk voor het beheren en roteren van geheimen, hetzij handmatig of programmatisch. Met beheerde identiteiten beheert en voert Microsoft Entra ID de verificatie en tijdige rotatie van geheimen voor u uit.

Het wordt aanbevolen om beheerde identiteiten in te schakelen , zodat het cluster kan communiceren met externe Azure-resources via Microsoft Entra-id. U kunt deze instelling alleen inschakelen tijdens het maken van het cluster. Zelfs als Microsoft Entra-id niet onmiddellijk wordt gebruikt, kunt u deze later opnemen.

Standaard worden er twee primaire identiteiten gebruikt door het cluster, de clusteridentiteit en de kubelet-identiteit. De clusteridentiteit wordt gebruikt door de AKS-besturingsvlakonderdelen voor het beheren van clusterresources, waaronder inkomende load balancers, door AKS beheerde openbare IP-adressen, enzovoort. De kubelet-identiteit wordt gebruikt voor verificatie met Azure Container Registry (ACR). Sommige invoegtoepassingen ondersteunen ook verificatie met behulp van een beheerde identiteit.

Laten we eens kijken naar het gebruik van beheerde identiteiten wanneer het cluster installatiekopieën uit een containerregister moet ophalen. Voor deze actie moet het cluster de referenties van het register ophalen. Een manier is om die informatie op te slaan in de vorm van kubernetes Secrets-object en imagePullSecrets om het geheim op te halen. Deze benadering wordt niet aanbevolen vanwege beveiligingscomplexiteiten. U hebt niet alleen voorafgaande kennis van het geheim nodig, maar ook de openbaarmaking van dat geheim via de DevOps-pijplijn. Een andere reden is de operationele overhead voor het beheren van de rotatie van het geheim. In plaats daarvan verleent acrPull u toegang tot de beheerde kubelet-identiteit van het cluster aan uw register. Met deze aanpak worden deze problemen aangepakt.

In deze architectuur heeft het cluster toegang tot Azure-resources die worden beveiligd door Microsoft Entra ID en voert het bewerkingen uit die beheerde identiteiten ondersteunen. Wijs op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) en machtigingen toe aan de beheerde identiteiten van het cluster, afhankelijk van de bewerkingen die het cluster wil uitvoeren. Het cluster verifieert zichzelf bij de Microsoft Entra-id en vervolgens wordt de toegang toegestaan of geweigerd op basis van de rollen waaraan het is toegewezen. Hier volgen enkele voorbeelden van deze referentie-implementatie waarbij ingebouwde Azure-rollen zijn toegewezen aan het cluster:

• Inzender voor het netwerk. De mogelijkheid van het cluster om het virtuele spoke-netwerk te beheren. Met deze roltoewijzing kan de toegewezen identiteit van het AKS-clustersysteem werken met het toegewezen subnet voor de interne toegangscontrollerservices.
• Uitgever van metrische gegevens bewaken. De mogelijkheid van het cluster om metrische gegevens naar Azure Monitor te verzenden.
• AcrPull. De mogelijkheid van het cluster om installatiekopieën op te halen uit de opgegeven Azure Container-registers.

Clustertoegang

Microsoft Entra-integratie vereenvoudigt ook de beveiliging voor externe toegang. Stel dat een gebruiker kubectl wil gebruiken. Als eerste stap voeren ze de az aks get-credentials opdracht uit om de referenties van het cluster op te halen. Microsoft Entra ID verifieert de identiteit van de gebruiker met de Azure-rollen die clusterreferenties mogen ophalen. Zie Beschikbare clusterrollenmachtigingen voor meer informatie.

Met AKS kan Kubernetes op twee manieren toegang krijgen met behulp van Microsoft Entra ID. De eerste is het gebruik van Microsoft Entra ID als een id-provider die is geïntegreerd met het systeemeigen Kubernetes RBAC-systeem. De andere maakt gebruik van systeemeigen Azure RBAC voor het beheren van clustertoegang. Beide worden hieronder beschreven.

Kubernetes RBAC koppelen aan Microsoft Entra-id

Kubernetes ondersteunt op rollen gebaseerd toegangsbeheer (RBAC) via:

• Een set machtigingen. Gedefinieerd door een Role of ClusterRole object voor machtigingen voor het hele cluster.

• Bindingen die gebruikers en groepen toewijzen die de acties mogen uitvoeren. Gedefinieerd door een RoleBinding of ClusterRoleBinding object.

Kubernetes heeft een aantal ingebouwde rollen, zoals clusterbeheerder, bewerken, weergeven, enzovoort. Bind deze rollen aan Microsoft Entra-gebruikers en -groepen om enterprise-directory te gebruiken om de toegang te beheren. Zie Kubernetes RBAC gebruiken met Microsoft Entra-integratie voor meer informatie.

Zorg ervoor dat uw Microsoft Entra-groepen die worden gebruikt voor toegang tot clusters en naamruimten, zijn opgenomen in uw Microsoft Entra-toegangsbeoordelingen.

Azure RBAC gebruiken voor Kubernetes-autorisatie

In plaats van Kubernetes native RBAC (ClusterRoleBindings en RoleBindings) te gebruiken voor autorisatie met geïntegreerde Microsoft Entra-verificatie, is een andere optie die we aanbevelen om Azure RBAC- en Azure-roltoewijzingen te gebruiken om autorisatiecontroles op het cluster af te dwingen. Deze roltoewijzingen kunnen zelfs worden toegevoegd aan het bereik van het abonnement of de resourcegroep, zodat alle clusters onder het bereik een consistente set roltoewijzingen overnemen met betrekking tot wie machtigingen heeft voor toegang tot de objecten in het Kubernetes-cluster.

Zie Azure RBAC voor Kubernetes-autorisatie voor meer informatie.

Lokale accounts

AKS ondersteunt systeemeigen Kubernetes-gebruikersverificatie. Gebruikerstoegang tot clusters die deze methode gebruiken, wordt niet voorgesteld. Het is op certificaten gebaseerd en wordt extern uitgevoerd voor uw primaire id-provider; gecentraliseerd gebruikerstoegangsbeheer en -beheer moeilijk maken. Beheer altijd de toegang tot uw cluster met behulp van Microsoft Entra ID en configureer uw cluster om expliciet toegang tot het lokale account uit te schakelen.

In deze referentie-implementatie wordt de toegang via lokale clusteraccounts expliciet uitgeschakeld wanneer het cluster wordt geïmplementeerd.

Microsoft Entra-id integreren voor de workload

Net als bij het hebben van een door het Azure-systeem toegewezen beheerde identiteit voor het hele cluster, kunt u beheerde identiteiten toewijzen op podniveau. Met een workload-id kan de gehoste workload toegang krijgen tot resources via Microsoft Entra-id. De workload slaat bijvoorbeeld bestanden op in Azure Storage. Wanneer deze bestanden moeten worden geopend, verifieert de pod zichzelf bij de resource als een door Azure beheerde identiteit.

In deze referentie-implementatie worden beheerde identiteiten voor pods aangeboden via Microsoft Entra Workload-ID op AKS. Dit integreert met de systeemeigen Kubernetes-mogelijkheden om te federeren met externe id-providers. Zie het volgende overzicht voor meer informatie over Microsoft Entra Workload-ID federatie.

Toegangsbeheerde resources implementeren

Kubernetes-resources voor inkomend verkeer routeren en distribueren naar het cluster. Er zijn twee delen van toegangsbeheerobjectbronnen:

• Interne load balancer. Beheerd door AKS. Deze load balancer maakt de ingangscontroller beschikbaar via een privé statisch IP-adres. Het fungeert als één contactpunt dat binnenkomende stromen ontvangt.

  In deze architectuur wordt Azure Load Balancer gebruikt. Het wordt buiten het cluster geplaatst in een subnet dat is toegewezen aan toegangsbeheerobjectbronnen. Het ontvangt verkeer van Azure-toepassing Gateway en die communicatie verloopt via TLS. Zie Inkomend verkeerstroom voor informatie over TLS-versleuteling voor inkomend verkeer.

• Controller voor inkomend verkeer. We hebben Traefik gekozen. Deze wordt uitgevoerd in de gebruikersknooppuntgroep in het cluster. Het ontvangt verkeer van de interne load balancer, beëindigt TLS en stuurt het door naar de workloadpods via HTTP.

De ingangscontroller is een essentieel onderdeel van het cluster. Houd rekening met deze punten bij het configureren van dit onderdeel.

• Kies als onderdeel van uw ontwerpbeslissingen een bereik waarin de ingangscontroller mag werken. U kunt bijvoorbeeld toestaan dat de controller alleen communiceert met de pods waarop een specifieke workload wordt uitgevoerd.

• Vermijd het plaatsen van replica's op hetzelfde knooppunt om de belasting te verdelen en bedrijfscontinuïteit te garanderen als een knooppunt uitvalt. Gebruik podAntiAffinity dit doel.

• Beperkingen voor pods die alleen in de gebruikersknooppuntgroep moeten worden gepland met behulp van nodeSelectors. Met deze instelling worden workload- en systeempods geïsoleerd.

• Open poorten en protocollen waarmee specifieke entiteiten verkeer naar de ingangscontroller kunnen verzenden. In deze architectuur ontvangt Traefik alleen verkeer van Azure-toepassing Gateway.

• De ingangscontroller moet signalen verzenden die de status van pods aangeven. Configureer readinessProbe en livenessProbe instellingen waarmee de status van de pods op het opgegeven interval wordt bewaakt.

• Overweeg om de toegang van de ingangscontroller tot specifieke resources te beperken en de mogelijkheid om bepaalde acties uit te voeren. Deze beperking kan worden geïmplementeerd via Kubernetes RBAC-machtigingen. In deze architectuur is Traefik bijvoorbeeld gemachtigd om services en eindpunten te bekijken, op te halen en weer te geven met behulp van regels in het Kubernetes-object ClusterRole .

Als u het ontwerp voor inkomend verkeer wilt bekijken dat wordt gebruikt in de Windows-containers in de referentiearchitectuur van de AKS-basislijn, raadpleegt u het bijbehorende artikel.

Routerinstellingen

De ingangscontroller gebruikt routes om te bepalen waar verkeer moet worden verzonden. Routes geven de bronpoort op waarop het verkeer wordt ontvangen en informatie over de doelpoorten en -protocollen.

Hier volgt een voorbeeld van deze architectuur:

Traefik gebruikt de Kubernetes-provider om routes te configureren. De annotations, tlsen entrypoints geven aan dat routes via HTTPS worden geleverd. Hiermee middlewares geeft u op dat alleen verkeer van het Azure-toepassing Gateway-subnet is toegestaan. De antwoorden gebruiken gzip-codering als de client dit accepteert. Omdat Traefik TLS-beëindiging uitvoert, verloopt de communicatie met de back-endservices via HTTP.

apiVersion:networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

De netwerkstroom beveiligen

Netwerkstroom kan in deze context worden gecategoriseerd als:

• Inkomend verkeer. Van de client naar de workload die wordt uitgevoerd in het cluster.

• Uitgaand verkeer. Van een pod of knooppunt in het cluster naar een externe service.

• Pod-naar-pod-verkeer. Communicatie tussen pods. Dit verkeer omvat communicatie tussen de ingangscontroller en de workload. Als uw workload bestaat uit meerdere toepassingen die zijn geïmplementeerd in het cluster, valt de communicatie tussen deze toepassingen ook in deze categorie.

• Beheerverkeer. Verkeer dat tussen de client en de Kubernetes API-server gaat.

Een Visio-bestand van deze architectuur downloaden.

Deze architectuur heeft verschillende beveiligingslagen om alle soorten verkeer te beveiligen.

Stroom inkomend verkeer

De architectuur accepteert alleen versleutelde TLS-aanvragen van de client. TLS v1.2 is de minimaal toegestane versie met een beperkte set cyphers. SNI(Server Name Indication) is strikt ingeschakeld. End-to-end TLS wordt ingesteld via Application Gateway met behulp van twee verschillende TLS-certificaten, zoals wordt weergegeven in deze afbeelding.

Een Visio-bestand van deze architectuur downloaden.

1. De client verzendt een HTTPS-aanvraag naar de domeinnaam: bicycle.contoso.com. Deze naam is gekoppeld via een DNS A-record aan het openbare IP-adres van Azure-toepassing Gateway. Dit verkeer wordt versleuteld om ervoor te zorgen dat het verkeer tussen de clientbrowser en gateway niet kan worden geïnspecteerd of gewijzigd.

2. Application Gateway heeft een geïntegreerde WAF (Web Application Firewall) en onderhandelt over de TLS-handshake voor bicycle.contoso.com, waardoor alleen veilige coderingen worden toegestaan. Application Gateway is een TLS-beëindigingspunt, omdat het vereist is om WAF-inspectieregels te verwerken en routeringsregels uit te voeren die het verkeer doorsturen naar de geconfigureerde back-end. Het TLS-certificaat wordt opgeslagen in Azure Key Vault. Deze wordt geopend met behulp van een door de gebruiker toegewezen beheerde identiteit die is geïntegreerd met Application Gateway. Zie TLS-beëindiging met Key Vault-certificaten voor informatie over deze functie.

3. Naarmate verkeer van Application Gateway naar de back-end wordt verplaatst, wordt het opnieuw versleuteld met een ander TLS-certificaat (jokerteken voor *.aks-ingress.contoso.com) omdat het wordt doorgestuurd naar de interne load balancer. Deze herversleuteling zorgt ervoor dat verkeer dat niet veilig is, niet in het clustersubnet stroomt.

4. De ingangscontroller ontvangt het versleutelde verkeer via de load balancer. De controller is een ander TLS-beëindigingspunt voor *.aks-ingress.contoso.com en stuurt het verkeer door naar de workloadpods via HTTP. De certificaten worden opgeslagen in Azure Key Vault en gekoppeld aan het cluster met behulp van het CSI-stuurprogramma (Container Storage Interface). Zie Geheimbeheer toevoegen voor meer informatie.

U kunt end-to-end TLS-verkeer allemaal implementeren bij elke hop naar de workloadpod. Zorg ervoor dat u de prestaties, latentie en operationele impact meet bij het nemen van de beslissing om pod-naar-pod-verkeer te beveiligen. Voor de meeste clusters met één tenant, met de juiste besturingsvlak RBAC en volwassen procedures voor de levenscyclus van softwareontwikkeling, is het voldoende om TLS te versleutelen tot de ingangscontroller en te beveiligen met Web Application Firewall (WAF). Hierdoor wordt de overhead in workloadbeheer en netwerkprestaties geminimaliseerd. Uw workload- en nalevingsvereisten bepalen waar u TLS-beëindiging uitvoert.

Uitgaande verkeersstroom

In deze architectuur raden we al het uitgaande verkeer van het cluster aan dat communiceert via Azure Firewall of uw eigen virtuele netwerkapparaat, via andere opties, zoals NAT Gateway of HTTP-proxy. Voor nulvertrouwensbeheer en de mogelijkheid om verkeer te controleren, wordt al het uitgaande verkeer van het cluster via Azure Firewall verplaatst. U kunt deze keuze implementeren met behulp van door de gebruiker gedefinieerde routes (UDR's). De volgende hop van de route is het privé-IP-adres van de Azure Firewall. Hier bepaalt Azure Firewall of het uitgaand verkeer moet worden geblokkeerd of toegestaan. Deze beslissing is gebaseerd op de specifieke regels die zijn gedefinieerd in de Azure Firewall of de ingebouwde regels voor bedreigingsinformatie.

Een alternatief voor het gebruik van Azure Firewall is het gebruik van de HTTP-proxyfunctie van AKS. Al het verkeer dat het cluster afleidt, wordt eerst ingesteld op het IP-adres van de HTTP-proxy, waarmee wordt besloten het verkeer door te sturen of neer te zetten.

Controleer met beide methoden de vereiste netwerkregels voor uitgaand verkeer voor AKS.

Een uitzondering op het beheer van nulvertrouwen is wanneer het cluster moet communiceren met andere Azure-resources. Het cluster moet bijvoorbeeld een bijgewerkte installatiekopie ophalen uit het containerregister of geheimen uit Azure Key Vault. De aanbevolen benadering is met behulp van Azure Private Link. Het voordeel is dat specifieke subnetten de service rechtstreeks bereiken in plaats van het verkeer tussen het cluster en de services die via internet worden uitgevoerd. Een nadeel is dat Private Link aanvullende configuratie nodig heeft in plaats van de doelservice te gebruiken via het openbare eindpunt. Bovendien bieden niet alle Azure-services of SKU's ondersteuning voor Private Link. Voor dergelijke gevallen kunt u overwegen om een service-eindpunt voor een virtueel netwerk in het subnet in te schakelen voor toegang tot de service.

Als Private Link of service-eindpunten geen optie zijn, kunt u andere services bereiken via hun openbare eindpunten en de toegang beheren via Azure Firewall-regels en de firewall die is ingebouwd in de doelservice. Omdat dit verkeer de statische IP-adressen van de firewall doorloopt, kunnen deze adressen worden toegevoegd aan de ip-acceptatielijst van de service. Een nadeel is dat Azure Firewall aanvullende regels moet hebben om ervoor te zorgen dat alleen verkeer van een specifiek subnet is toegestaan. Houd rekening met deze adressen wanneer u meerdere IP-adressen plant voor uitgaand verkeer met Azure Firewall, anders zou u poortuitputting kunnen bereiken. Zie Uitgaand verkeer beperken en beheren voor meer informatie over het plannen van meerdere IP-adressen.

Zie het bijbehorende artikel als u de overwegingen voor uitgaand verkeer wilt bekijken die worden gebruikt in de Windows-containers in de referentiearchitectuur van de AKS-basislijn.

Pod-naar-pod-verkeer

Standaard kan een pod verkeer van elke andere pod in het cluster accepteren. Kubernetes NetworkPolicy wordt gebruikt om netwerkverkeer tussen pods te beperken. Pas beleidsregels zorgvuldig toe, anders hebt u mogelijk een situatie waarin een kritieke netwerkstroom wordt geblokkeerd. Sta indien nodig alleen specifieke communicatiepaden toe, zoals verkeer tussen de ingangscontroller en de workload. Zie Netwerkbeleidsregels voor meer informatie.

Schakel netwerkbeleid in wanneer het cluster is ingericht omdat het later niet kan worden toegevoegd. Er zijn enkele opties voor technologieën die implementeren NetworkPolicy. Azure Network Policy wordt aanbevolen. Hiervoor is Azure Container Networking Interface (CNI) vereist. Zie de onderstaande opmerking. Andere opties zijn Calico-netwerkbeleid, een bekende opensource-optie. Overweeg Calico als u het netwerkbeleid voor het hele cluster moet beheren. Calico valt niet onder standaard ondersteuning voor Azure.

Zie Verschillen tussen Azure Network Policy en Calico-beleid en hun mogelijkheden voor meer informatie.

Beheerverkeer

Als onderdeel van het uitvoeren van het cluster ontvangt de Kubernetes-API-server verkeer van resources die beheerbewerkingen willen uitvoeren op het cluster, zoals aanvragen voor het maken van resources of het schalen van het cluster. Voorbeelden van deze resources zijn de buildagentpool in een DevOps-pijplijn, een Bastion-subnet en knooppuntgroepen zelf. In plaats van dit beheerverkeer van alle IP-adressen te accepteren, gebruikt u de functie Geautoriseerde IP-adresbereiken van AKS om alleen verkeer van uw geautoriseerde IP-bereiken naar de API-server toe te staan.

Zie Geautoriseerde IP-bereiken voor API-servers definiëren voor meer informatie.

Voor een extra controlelaag kunt u, ten koste van extra complexiteit, een privé-AKS-cluster inrichten. Met behulp van een privécluster kunt u ervoor zorgen dat netwerkverkeer tussen uw API-server en uw knooppuntgroepen alleen in het privénetwerk blijft, maar niet beschikbaar is op internet. Zie AKS-privéclusters voor meer informatie.

Sleutelbeheer toevoegen

Geheimen opslaan in een beheerd sleutelarchief, zoals Azure Key Vault. Het voordeel is dat het beheerde archief rotatie van geheimen afhandelt, sterke versleuteling biedt, een toegangscontrolelogboek biedt en kerngeheimen buiten de implementatiepijplijn bewaart. In deze architectuur is azure Key Vault-firewall ingeschakeld en geconfigureerd met private link-verbindingen met de resources in Azure die toegang nodig hebben tot geheimen en certificaten.

Azure Key Vault is goed geïntegreerd met andere Azure-services. Gebruik de ingebouwde functie van deze services voor toegang tot geheimen. Zie de sectie Inkomend verkeer voor inkomend verkeer voor een voorbeeld van hoe Azure-toepassing Gateway toegang krijgt tot TLS-certificaten voor de toegangsstroom.

Met het Azure RBAC-machtigingsmodel voor Key Vault kunt u de workloadidentiteiten toewijzen aan de roltoewijzing Key Vault Secrets User of Key Vault Reader en toegang krijgen tot de geheimen. Zie Toegang tot Azure Key Vault met behulp van RBAC voor meer informatie.

Toegang tot clustergeheimen

U moet workloadidentiteiten gebruiken om een pod toegang te geven tot geheimen uit een specifiek archief. Gebruik een stuurprogramma secrets store CSI om het ophaalproces te vergemakkelijken. Wanneer de pod een geheim nodig heeft, maakt het stuurprogramma verbinding met het opgegeven archief, haalt het geheim op een volume op en koppelt het dat volume in het cluster. De pod kan vervolgens het geheim ophalen uit het volumebestandssysteem.

Het CSI-stuurprogramma heeft veel providers ter ondersteuning van verschillende beheerde winkels. In deze implementatie hebben we de Azure Key Vault met het CSI-stuurprogramma Secrets Store gekozen met behulp van de invoegtoepassing om het TLS-certificaat op te halen uit Azure Key Vault en te laden in de pod waarop de ingangscontroller wordt uitgevoerd. Dit wordt gedaan tijdens het maken van pods en het volume slaat zowel openbare als de persoonlijke sleutels op.

Workloadopslag

De workload die in deze architectuur wordt gebruikt, is staatloos. Als u de status wilt opslaan, wordt het aanbevolen om de status buiten het cluster op te slaan. Richtlijnen voor de status van de werkbelasting vallen buiten het bereik van dit artikel.

Zie Opslagopties voor toepassingen in Azure Kubernetes Service (AKS) voor meer informatie over opslagopties.

Beleidsbeheer

Een effectieve manier om een AKS-cluster te beheren, is door governance af te dwingen via beleid. Kubernetes implementeert beleidsregels via OPA Gatekeeper. Voor AKS worden beleidsregels geleverd via Azure Policy. Elk beleid wordt toegepast op alle clusters binnen het bereik. Azure Policy-afdwinging wordt uiteindelijk verwerkt door OPA Gatekeeper in het cluster en alle beleidscontroles worden vastgelegd. Beleidswijzigingen worden niet onmiddellijk doorgevoerd in uw cluster. Verwacht dat er vertragingen optreden.

Er zijn twee verschillende scenario's die Azure Policy biedt voor het beheren van uw AKS-clusters:

• Voorkomen of beperken van de implementatie van AKS-clusters in een resourcegroep of abonnement door de standaarden van uw organisatie te evalueren. Volg bijvoorbeeld een naamconventie, geef een tag op, enzovoort.
• Beveilig uw AKS-cluster via Azure Policy voor Kubernetes.

Wanneer u beleidsregels instelt, past u deze toe op basis van de vereisten van de workload. Houd rekening met deze factoren:

• Wilt u een verzameling beleidsregels (zogenaamde initiatieven) instellen of afzonderlijke beleidsregels kiezen? Azure Policy biedt twee ingebouwde initiatieven: basis en beperkt. Elk initiatief is een verzameling ingebouwde beleidsregels die van toepassing zijn op een AKS-cluster. Het is raadzaam om een initiatief te selecteren en extra beleidsregels te kiezen voor het cluster en de resources (ACR, Application Gateway, Key Vault en andere) die met het cluster communiceren, overeenkomstig de vereisten van uw organisatie.

• Wilt u de actie controleren of weigeren ? In de controlemodus is de actie toegestaan, maar deze wordt gemarkeerd als Niet-compatibel. Processen hebben om niet-compatibele statussen regelmatig te controleren en de nodige actie te ondernemen. In de modus Weigeren wordt de actie geblokkeerd omdat deze het beleid schendt. Wees voorzichtig met het kiezen van deze modus, omdat deze te beperkend kan zijn voor de werkbelasting om te functioneren.

• Hebt u gebieden in uw workload die niet standaard compatibel moeten zijn? Azure Policy biedt de mogelijkheid om Kubernetes-naamruimten op te geven die zijn uitgesloten van beleidsafdwinging. Het is raadzaam om nog steeds beleidsregels toe te passen in de controlemodus , zodat u op de hoogte bent van deze exemplaren.

• Hebt u vereisten die niet worden gedekt door het ingebouwde beleid? U kunt een aangepaste Azure Policy-definitie maken waarmee uw aangepaste OPA Gatekeeper-beleid wordt toegepast. Pas aangepaste beleidsregels niet rechtstreeks toe op het cluster. Zie Aangepaste beleidsdefinities maken en toewijzen voor meer informatie over het maken van aangepaste beleidsregels.

• Hebt u vereisten voor de hele organisatie? Zo ja, voeg dit beleid toe op het niveau van de beheergroep. Uw cluster moet ook een eigen workloadspecifiek beleid toewijzen, zelfs als de organisatie algemene beleidsregels heeft.

• Azure-beleid wordt toegewezen aan specifieke bereiken. Zorg ervoor dat het productiebeleid ook wordt gevalideerd op basis van uw preproductieomgeving . Anders ondervindt u bij de implementatie in uw productieomgeving onverwachte aanvullende beperkingen waarvoor geen rekening werd gehouden in de preproductie.

In deze referentie-implementatie wordt Azure Policy ingeschakeld wanneer het AKS-cluster wordt gemaakt en het beperkende initiatief in de controlemodus wordt toegewezen om inzicht te krijgen in niet-naleving.

De implementatie stelt ook aanvullende beleidsregels in die geen deel uitmaken van ingebouwde initiatieven. Deze beleidsregels worden ingesteld in de modus Weigeren . Er is bijvoorbeeld een beleid ingesteld om ervoor te zorgen dat installatiekopieën alleen worden opgehaald uit de geïmplementeerde ACR. Overweeg om uw eigen aangepaste initiatieven te maken. Combineer de beleidsregels die van toepassing zijn op uw workload in één toewijzing.

Als u wilt zien hoe Azure Policy werkt vanuit uw cluster, hebt u toegang tot de podlogboeken voor alle pods in de gatekeeper-system naamruimte, evenals de logboeken voor de azure-policy en azure-policy-webhook pods in de kube-system naamruimte.

Zie het bijbehorende artikel voor informatie over het controleren van Windows-specifieke Azure Policy-overwegingen in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

Schaalbaarheid van knooppunten en pods

Met toenemende vraag kan Kubernetes worden uitgebreid door meer pods toe te voegen aan bestaande knooppunten, door middel van horizontaal automatisch schalen van pods (HPA). Wanneer er geen extra pods meer kunnen worden gepland, moet het aantal knooppunten worden verhoogd via automatische schaalaanpassing van AKS-clusters. Een volledige schaaloplossing moet manieren hebben om zowel podreplica's als het aantal knooppunten in het cluster te schalen.

Er zijn twee benaderingen: automatisch schalen of handmatig schalen.

Voor de handmatige of programmatische manier moet u waarschuwingen voor cpu-gebruik of aangepaste metrische gegevens bewaken en instellen. Voor het schalen van pods kan de toepassingsoperator het aantal podreplica's vergroten of verkleinen door de ReplicaSet api's van Kubernetes aan te passen. Voor het schalen van clusters kunt u een melding ontvangen wanneer de Kubernetes-scheduler mislukt. Een andere manier is om in de loop van de tijd te kijken naar pods die in behandeling zijn. U kunt het aantal knooppunten aanpassen via Azure CLI of de portal.

Automatisch schalen is de aanbevolen methode omdat sommige van deze handmatige mechanismen zijn ingebouwd in de automatische schaalaanpassing.

Als algemene benadering begint u met prestatietests met een minimum aantal pods en knooppunten. Gebruik deze waarden om de verwachting van de basislijn vast te stellen. Gebruik vervolgens een combinatie van metrische prestatiegegevens en handmatig schalen om knelpunten te vinden en inzicht te hebben in de reactie van de toepassing op schalen. Gebruik tot slot deze gegevens om de parameters voor automatisch schalen in te stellen. Zie Prestatieafstemmingsscenario: Gedistribueerde zakelijke transacties voor informatie over een scenario voor het afstemmen van prestaties met behulp van AKS.

Horizontale automatische schaalaanpassing van pods

De Horizontale schaalaanpassing van pods (HPA) is een Kubernetes-resource waarmee het aantal pods wordt geschaald.

In de HPA-resource wordt het instellen van het minimum- en maximumaantal replica's aanbevolen. Deze waarden beperken de grenzen voor automatisch schalen.

HPA kan worden geschaald op basis van het CPU-gebruik, geheugengebruik en aangepaste metrische gegevens. Alleen CPU-gebruik wordt standaard geleverd. De definitie HorizontalPodAutoscaler specificeert doelwaarden voor deze metrische gegevens. De specificatie stelt bijvoorbeeld een doel-CPU-gebruik in. Terwijl pods worden uitgevoerd, gebruikt de HPA-controller de Kubernetes Metrics-API om het CPU-gebruik van elke pod te controleren. Deze waarde wordt vergeleken met het doelgebruik en berekent een verhouding. Vervolgens wordt de verhouding gebruikt om te bepalen of pods overbezet of onderbezet zijn. Het is afhankelijk van de Kubernetes-planner om nieuwe pods toe te wijzen aan knooppunten of pods te verwijderen uit knooppunten.

Er kan een racevoorwaarde zijn waarbij (HPA) controleert voordat een schaalbewerking is voltooid. Het resultaat kan een onjuiste verhoudingsberekening zijn. Zie Cooldown van schaalgebeurtenissen voor meer informatie.

Als uw workload gebeurtenisgestuurd is, is een populaire opensource-optie KEDA. Overweeg KEDA als uw werkbelasting wordt aangestuurd door een gebeurtenisbron, zoals een berichtenwachtrij, in plaats van CPU- of geheugengebonden te zijn. KEDA ondersteunt veel gebeurtenisbronnen (of scalers). Hier vindt u de lijst met ondersteunde KEDA-schaalders, waaronder de Azure Monitor-schaalaanpassing; een handige manier om KEDA-workloads te schalen op basis van metrische gegevens van Azure Monitor.

Automatische schaalaanpassing van clusters

De automatische schaalaanpassing van clusters is een AKS-invoegtoepassingsonderdeel waarmee het aantal knooppunten in een knooppuntgroep wordt geschaald. Deze moet worden toegevoegd tijdens het inrichten van clusters. U hebt een afzonderlijke automatische schaalaanpassing van clusters nodig voor elke gebruikersknooppuntgroep.

De automatische schaalaanpassing van clusters wordt geactiveerd door de Kubernetes-scheduler. Wanneer de Kubernetes-planner een pod niet kan plannen vanwege resourcebeperkingen, richt de automatische schaalaanpassing automatisch een nieuw knooppunt in de knooppuntgroep in. Omgekeerd controleert de automatische schaalaanpassing van clusters de ongebruikte capaciteit van de knooppunten. Als het knooppunt niet wordt uitgevoerd op een verwachte capaciteit, worden de pods verplaatst naar een ander knooppunt en wordt het ongebruikte knooppunt verwijderd.

Wanneer u automatische schaalaanpassing inschakelt, stelt u het maximum- en minimumaantal knooppunten in. De aanbevolen waarden zijn afhankelijk van de verwachting van de prestaties van de workload, hoeveel u het cluster wilt laten groeien en wat de gevolgen voor de kosten zijn. Het minimumaantal is de gereserveerde capaciteit voor die knooppuntgroep. In deze referentie-implementatie is de minimumwaarde ingesteld op 2 vanwege de eenvoudige aard van de werkbelasting.

Voor de systeemknooppuntgroep is de aanbevolen minimumwaarde 3.

Zie het bijbehorende artikel voor meer informatie over schaaloverwegingen die zijn opgenomen in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

Beslissingen voor bedrijfscontinuïteit

Als u bedrijfscontinuïteit wilt behouden, definieert u de Service Level Agreement voor de infrastructuur en uw toepassing. Zie SLA voor Azure Kubernetes Service (AKS) voor informatie over de maandelijkse uptimeberekening.

Clusterknooppunten

Om te voldoen aan het minimale beschikbaarheidsniveau voor workloads, zijn er meerdere knooppunten in een knooppuntgroep nodig. Als een knooppunt uitvalt, kan een ander knooppunt in de knooppuntgroep in hetzelfde cluster doorgaan met het uitvoeren van de toepassing. Voor betrouwbaarheid worden drie knooppunten aanbevolen voor de systeemknooppuntgroep. Voor de gebruikersknooppuntgroep begint u met niet minder dan twee knooppunten. Als u een hogere beschikbaarheid nodig hebt, richt u meer knooppunten in.

Isoleer uw toepassingen van de systeemservices door deze in een afzonderlijke knooppuntgroep te plaatsen, aangeduid als een gebruikersknooppuntgroep. Op deze manier worden Kubernetes-services uitgevoerd op toegewezen knooppunten en concurreren ze niet met uw workload. Het gebruik van tags, labels en taints wordt aanbevolen om de knooppuntgroep te identificeren om uw workload te plannen en ervoor te zorgen dat uw systeemknooppuntgroep is voorzien van criticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

Regelmatig onderhoud van uw cluster, zoals tijdige updates, is van cruciaal belang voor betrouwbaarheid. Het wordt ook aanbevolen om de status van de pods via tests te controleren.

Beschikbaarheid van pods

Zorg ervoor dat podbronnen. Het wordt ten zeerste aanbevolen dat implementaties vereisten voor podresources opgeven. De scheduler kan vervolgens de pod op de juiste manier plannen. Betrouwbaarheid wordt aanzienlijk afgeschaft als pods niet kunnen worden gepland.

Budgetten voor podonderbreking instellen. Met deze instelling wordt bepaald hoeveel replica's in een implementatie kunnen optreden tijdens een update- of upgrade-gebeurtenis. Zie Budgetten voor podonderbrekingen voor meer informatie.

Configureer meerdere replica's in de implementatie om onderbrekingen zoals hardwarefouten af te handelen. Voor geplande gebeurtenissen, zoals updates en upgrades, kan een onderbrekingsbudget ervoor zorgen dat het vereiste aantal podreplica's bestaat om de verwachte belasting van de toepassing af te handelen.

Stel resourcequota in voor de workloadnaamruimten. Het resourcequotum voor een naamruimte zorgt ervoor dat podaanvragen en limieten correct zijn ingesteld voor een implementatie. Zie Resourcequota afdwingen voor meer informatie.

Podaanvragen en -limieten instellen. Door deze limieten in te stellen, kan Kubernetes cpu- en/of geheugenbronnen efficiënt toewijzen aan de pods en een hogere containerdichtheid op een knooppunt hebben. Limieten kunnen ook de betrouwbaarheid verhogen met lagere kosten vanwege een beter hardwaregebruik.

Als u de limieten wilt schatten, test en stelt u een basislijn in. Begin met gelijke waarden voor aanvragen en limieten. Pas deze waarden geleidelijk aan totdat u een drempelwaarde hebt vastgesteld die instabiliteit in het cluster kan veroorzaken.

Deze limieten kunnen worden opgegeven in uw implementatiemanifesten. Zie Pod-aanvragen en -limieten instellen voor meer informatie.

Beschikbaarheidszones en ondersteuning voor meerdere regio's

Als uw SLA een hogere uptime vereist, moet u zich beschermen tegen storingen met behulp van beschikbaarheidszones. U kunt beschikbaarheidszones gebruiken als de regio deze ondersteunt. Zowel de onderdelen van het besturingsvlak als de knooppunten in de knooppuntgroepen kunnen vervolgens over zones worden verdeeld. Als een hele zone niet beschikbaar is, is een knooppunt in een andere zone binnen de regio nog steeds beschikbaar. Elke knooppuntgroep wordt toegewezen aan een afzonderlijke virtuele-machineschaalset, waarmee knooppuntexemplaren en schaalbaarheid worden beheerd. Schaalsetbewerkingen en -configuratie worden beheerd door de AKS-service. Hier volgen enkele overwegingen bij het inschakelen van meerdere zones:

• Volledige infrastructuur. Kies een regio die beschikbaarheidszones ondersteunt. Zie Beperkingen en beschikbaarheid van regio's voor meer informatie. Als u een SLA voor uptime wilt kopen, kiest u een regio die deze optie ondersteunt. De SLA uptime is groter wanneer u beschikbaarheidszones gebruikt.

• Cluster. Beschikbaarheidszones kunnen alleen worden ingesteld wanneer de knooppuntgroep wordt gemaakt en kan later niet meer worden gewijzigd. De knooppuntgrootten moeten in alle zones worden ondersteund, zodat de verwachte distributie mogelijk is. De onderliggende virtuele-machineschaalset biedt dezelfde hardwareconfiguratie tussen zones.

  Ondersteuning voor meerdere zone's is niet alleen van toepassing op knooppuntgroepen, maar ook op het besturingsvlak. Het AKS-besturingsvlak omvat de aangevraagde zones, zoals de knooppuntgroepen. Als u geen zoneondersteuning in uw cluster gebruikt, zijn de onderdelen van het besturingsvlak niet gegarandeerd verspreid over beschikbaarheidszones.

• Afhankelijke resources. Voor volledig zonegebonden voordeel moeten alle serviceafhankelijkheden ook zones ondersteunen. Als een afhankelijke service geen zones ondersteunt, is het mogelijk dat een zonefout ertoe kan leiden dat die service mislukt.

Een beheerde schijf is bijvoorbeeld beschikbaar in de zone waarin deze is ingericht. In het geval van een fout kan het knooppunt worden verplaatst naar een andere zone, maar de beheerde schijf wordt niet verplaatst met het knooppunt naar die zone.

Ter vereenvoudiging wordt AKS in deze architectuur geïmplementeerd in één regio met knooppuntgroepen die beschikbaarheidszones 1, 2 en 3 omvatten. Andere resources van de infrastructuur, zoals Azure Firewall en Application Gateway, worden ook geïmplementeerd in dezelfde regio met ondersteuning voor meerdere zone's. Geo-replicatie is ingeschakeld voor Azure Container Registry.

Meerdere regio's

Het inschakelen van beschikbaarheidszones is niet voldoende als de hele regio uitvalt. Als u een hogere beschikbaarheid wilt hebben, voert u meerdere AKS-clusters uit in verschillende regio's.

• Gebruik gekoppelde regio's. Overweeg om een CI/CD-pijplijn te gebruiken die is geconfigureerd voor het gebruik van een gekoppelde regio om te herstellen van regiofouten. Een voordeel van het gebruik van gekoppelde regio's is betrouwbaarheid tijdens updates. Azure zorgt ervoor dat slechts één regio in het paar tegelijk wordt bijgewerkt. Bepaalde DevOps-hulpprogramma's zoals Flux kunnen de implementaties voor meerdere regio's eenvoudiger maken.

• Als een Azure-resource georedundantie ondersteunt, geeft u de locatie op waar de redundante service de secundaire locatie heeft. Als u bijvoorbeeld geo-replicatie inschakelt voor Azure Container Registry, worden installatiekopieën automatisch gerepliceerd naar de geselecteerde Azure-regio's en hebt u continue toegang tot installatiekopieën, zelfs als een regio een storing ondervindt.

• Kies een verkeersrouter die verkeer over zones of regio's kan verdelen, afhankelijk van uw behoeften. Met deze architectuur wordt Azure Load Balancer geïmplementeerd omdat het niet-webverkeer over zones kan verdelen. Als u verkeer wilt distribueren tussen regio's, moet Azure Front Door worden overwogen. Zie Een load balancer kiezen voor andere overwegingen.

Herstel na noodgeval

Als er fouten optreden in de primaire regio, moet u snel een nieuw exemplaar in een andere regio kunnen maken. Hier volgen enkele aanbevelingen:

• Gebruik gekoppelde regio's.

• Een niet-stateful workload kan efficiënt worden gerepliceerd. Als u de status in het cluster wilt opslaan (niet aanbevolen), moet u ervoor zorgen dat u regelmatig een back-up maakt van de gegevens in de gekoppelde regio.

• Integreer de herstelstrategie, zoals repliceren naar een andere regio, als onderdeel van de DevOps-pijplijn om te voldoen aan uw Service Level Objectives (SLO).

• Kies bij het inrichten van elke Azure-service functies die ondersteuning bieden voor herstel na noodgevallen. In deze architectuur is Azure Container Registry bijvoorbeeld ingeschakeld voor geo-replicatie. Als een regio uitvalt, kunt u nog steeds installatiekopieën ophalen uit de gerepliceerde regio.

Back-up van cluster

Voor veel architecturen kan het inrichten van een nieuw cluster en het terugkeren naar de bedrijfsstatus worden uitgevoerd via op GitOps gebaseerde [cluster bootstrapping}(#cluster-bootstrapping) en gevolgd door de implementatie van de toepassing. Als er echter een kritieke resourcestatus is, zoals configuratietoewijzingen, taken en mogelijk geheimen die om een of andere reden niet kunnen worden vastgelegd in uw bootstrapping-proces, kunt u uw herstelstrategie overwegen. Het wordt over het algemeen aanbevolen om stateless workloads uit te voeren in Kubernetes, maar als uw architectuur een schijfstatus omvat, moet u ook rekening houden met uw herstelstrategie voor die inhoud.

Wanneer de back-up van het cluster deel moet uitmaken van uw herstelstrategie, moet u een oplossing installeren die overeenkomt met uw bedrijfsvereisten binnen het cluster. Deze agent is verantwoordelijk voor het pushen van de status van de clusterresource naar een bestemming van uw keuze en het coördineren van op Azure Disk gebaseerde, permanente volumemomentopnamen.

VMware's Velero is een voorbeeld van een veelgebruikte Kubernetes-back-upoplossing die u rechtstreeks kunt installeren en beheren. U kunt ook de AKS-back-upextensie gebruiken om een beheerde Velero-implementatie te bieden. De AKS-back-upextensie ondersteunt het maken van back-ups van zowel Kubernetes-resources als permanente volumes, met planningen en back-upbereik extern als kluisconfiguratie in Azure Backup.

De referentie-implementatie implementeert geen back-up, waarbij extra Azure-resources in de architectuur nodig zijn om te beheren, bewaken, betalen en beveiligen; zoals een Azure Storage-account, Azure Backup-kluis en -configuratie en vertrouwde toegang. GitOps gecombineerd met de intentie om stateless workload uit te voeren, is de hersteloplossing die is geïmplementeerd.

Kies en valideer een oplossing die voldoet aan uw bedrijfsdoelstelling, inclusief uw gedefinieerde RPO (Recovery Point Objective) & Recovery Time Objective (RTO). Definieer dit herstelproces in een teamrunbook en oefen dit voor alle bedrijfskritieke workloads.

SLA voor Kubernetes-API-server

AKS kan worden gebruikt als een gratis service, maar die laag biedt geen SLA met financiële ondersteuning. Als u deze SLA wilt verkrijgen, moet u de Standard-laag kiezen. We raden alle productieclusters aan om de Standard-laag te gebruiken. Reserveer clusters in de gratis laag voor preproductieclusters. In combinatie met Azure Beschikbaarheidszones wordt de SLA van de Kubernetes-API-server verhoogd tot 99,95%. Uw knooppuntgroepen en andere resources vallen onder hun eigen SLA.

Afweging

Er is een compromis tussen kosten en beschikbaarheid voor het implementeren van de architectuur in verschillende zones en met name regio's. Sommige replicatiefuncties, zoals geo-replicatie in Azure Container Registry, zijn beschikbaar in Premium-SKU's, wat duurder is. De kosten nemen ook toe omdat er bandbreedtekosten worden toegepast wanneer verkeer wordt verplaatst tussen zones en regio's.

Verwacht ook extra netwerklatentie in knooppuntcommunicatie tussen zones of regio's. Meet de impact van deze architectuurbeslissing op uw workload.

Testen met simulaties en geforceerde failovers

Zorg voor betrouwbaarheid door middel van geforceerde failovertests met gesimuleerde storingen, zoals het stoppen van een knooppunt, het omlaag brengen van alle AKS-resources in een bepaalde zone om een zonegebonden fout te simuleren of een externe afhankelijkheidsfout aan te roepen. Azure Chaos Studio kan ook worden gebruikt om verschillende soorten storingen in Azure en in het cluster te simuleren.

Zie Azure Chaos Studio voor meer informatie.

Metrische gegevens bewaken en verzamelen

Azure Monitor Container Insights is het aanbevolen hulpprogramma om de prestaties van containerworkloads te bewaken, omdat u gebeurtenissen in realtime kunt bekijken. Hiermee worden containerlogboeken van de actieve pods vastgelegd en samengevoegd voor weergave. Het verzamelt ook informatie van de Api voor metrische gegevens over geheugen en CPU-gebruik om de status van actieve resources en workloads te bewaken. U kunt het ook gebruiken om de prestaties te bewaken terwijl de pods worden geschaald. Het omvat het verzamelen van telemetriekritiek voor bewaking, analyse en visualisatie van verzamelde gegevens om trends te identificeren en waarschuwingen te configureren om proactief op de hoogte te worden gesteld van kritieke problemen.

De meeste workloads die in pods worden gehost, verzenden metrische prometheus-gegevens. Container insights kan worden geïntegreerd met Prometheus om metrische gegevens van toepassingen en werkbelastingen weer te geven die worden verzameld van knooppunten en Kubernetes.

Er zijn enkele oplossingen van derden die met Kubernetes kunnen worden geïntegreerd, zoals Datadog, Grafana of New Relic, als uw organisatie deze al gebruikt.

Met AKS beheert Azure enkele kubernetes-kernservices en de logboeken voor de AKS-besturingsvlakonderdelen worden geïmplementeerd in Azure als resourcelogboeken. Het wordt aanbevolen dat de meeste clusters op elk moment het volgende hebben ingeschakeld, omdat ze u kunnen helpen bij het oplossen van clusterproblemen en een relatief lage logboekdichtheid hebben:

• Meld u aan bij ClusterAutoscaler om waarneembaarheid in de schaalbewerkingen te verkrijgen. Zie Logboeken en status van automatische schaalaanpassing van clusters ophalen voor meer informatie.
• KubeControllerManager om waarneembaarheid te hebben in de interactie tussen Kubernetes en het Azure-besturingsvlak.
• KubeAudit Beheer om waarneembaarheid te hebben in activiteiten die uw cluster wijzigen. Er is geen reden om zowel KubeAuditals KubeAudit Beheer beide ingeschakeld te hebben, omdat KubeAudit een superset is van KubeAudit Beheer die ook niet-wijzigingsbewerkingen (leesbewerkingen) omvat.
• Guard legt controles van Microsoft Entra ID en Azure RBAC vast.

Andere logboekcategorieën, zoals KubeScheduler of KubeAudit, kunnen erg handig zijn om tijdens de vroege ontwikkeling van de levenscyclus van clusters of workloads mogelijk te maken, waarbij automatische schaalaanpassing van clusters, podplaatsing en vergelijkbare gegevens kunnen helpen bij het oplossen van problemen met cluster- of workloadbewerkingen. Het bewaren van de uitgebreide logboeken voor het oplossen van problemen gedurende een volledige periode, kan worden beschouwd als onnodige kosten voor het opnemen en opslaan in Azure Monitor.

Hoewel Azure Monitor een set bestaande logboekquery's bevat om mee te beginnen, kunt u ze ook als basis gebruiken om uw eigen query's te bouwen. Naarmate uw bibliotheek groeit, kunt u logboekquery's opslaan en opnieuw gebruiken met behulp van een of meer querypakketten. Uw aangepaste bibliotheek met query's helpt extra waarneembaarheid mogelijk te maken in de status en prestaties van uw AKS-clusters en uw serviceniveaudoelstellingen (SLO's) te ondersteunen.

Zie Bewaking van Azure Kubernetes Service (AKS) met Azure Monitor voor meer informatie over onze best practices voor bewaking voor AKS.

Zie het bijbehorende artikel voor informatie over het controleren van windows-specifieke bewakingsoverwegingen die zijn opgenomen in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

Zelfherstel inschakelen

Bewaak de status van pods door liveness- en gereedheidstests in te stellen. Als er een niet-reagerende pod wordt gedetecteerd, start Kubernetes de pod opnieuw op. De livenesstest bepaalt of de pod in orde is. Als deze niet reageert, start Kubernetes de pod opnieuw op. De gereedheidstest bepaalt of de pod gereed is voor het ontvangen van aanvragen/verkeer.

AKS-clusterupdates

Het definiëren van een updatestrategie die consistent is met de bedrijfsvereisten, is van cruciaal belang. Inzicht in het voorspelbaarheidsniveau voor de datum en tijd waarop de AKS-clusterversie of de knooppunten ervan worden bijgewerkt en de gewenste mate van controle over welke specifieke installatiekopieën of binaire bestanden worden geïnstalleerd, zijn fundamentele aspecten waarmee de blauwdruk voor de AKS-clusterupdate wordt uitgelijnd. Voorspelbaarheid is gekoppeld aan twee belangrijke eigenschappen van AKS-clusterupdates die het updatefrequentie- en onderhoudsvenster zijn. Bepalen of updates handmatig of automatisch worden geïnstalleerd. Organisaties met AKS-clusters die niet onder een strikte beveiligingsregel vallen, kunnen wekelijkse of zelfs maandelijkse updates overwegen, terwijl de rest beveiligingsupdates met beveiligingsupdates moet bijwerken zodra deze beschikbaar zijn (dagelijks). Organisaties die AKS-clusters gebruiken als onveranderbare infrastructuur, worden niet bijgewerkt. Dit betekent dat er geen automatische of handmatige updates worden uitgevoerd. Wanneer een gewenste update beschikbaar wordt, wordt er een replicastempel geïmplementeerd en alleen wanneer het nieuwe infrastructuurexemplaren gereed is, wordt het oude exemplaar leeggezogen, waardoor ze het hoogste controleniveau krijgen.

Zodra de blauwdruk voor de AKS-clusterupdate is vastgesteld, kan deze eenvoudig worden toegewezen aan de beschikbare updateopties voor AKS-knooppunten en AKS-clusterversie:

• AKS-knooppunten:

  1. Geen/handmatige updates: dit is voor onveranderbare infrastructuur of wanneer handmatige updates de voorkeur hebben. Dit zorgt voor een betere voorspelbaarheid en controle over de AKS-knooppuntupdates.
  2. Automatische updates zonder toezicht: AKS voert systeemeigen besturingssysteemupdates uit. Dit biedt voorspelbaarheid door onderhoudsvensters te configureren die zijn afgestemd op wat goed is voor het bedrijf. Het kan zijn gebaseerd op piekuren en wat de beste bewerkingen zijn. Het controleniveau is laag omdat het niet mogelijk is om vooraf te weten wat er specifiek in het AKS-knooppunt wordt geïnstalleerd.
  3. Automatische updates van knooppuntinstallatiekopieën: het wordt aanbevolen om AKS-knooppuntinstallatiekopieën automatisch bij te werken wanneer nieuwe virtuele harde schijven (VHD's) beschikbaar komen. Ontwerponderhoudsvensters die zo veel mogelijk moeten worden afgestemd op de bedrijfsbehoeften. Voor VHD-updates met beveiligingslabels is het raadzaam om een dagelijks onderhoudsvenster te configureren dat de laagste voorspelbaarheid biedt. Regelmatige VHD-updates kunnen worden geconfigureerd met een wekelijks onderhoudsvenster, om de twee weken of zelfs maandelijks. Afhankelijk van of de behoefte is aan beveiliging gelabelde versus reguliere VHD's in combinatie met het geplande onderhoudsvenster, fluctueert de voorspelbaarheid, die meer of minder flexibiliteit biedt om te worden afgestemd op de bedrijfsvereisten. Hoewel dit altijd aan de bedrijfsvereisten voldoet, stelt de realiteit organisaties in staat om het punt te vinden. Het niveau van controle is laag omdat het niet mogelijk is om vooraf te weten welke specifieke binaire bestanden zijn opgenomen in een nieuwe VHD en toch dit type automatische updates is de aanbevolen optie omdat installatiekopieën worden gecontroleerd voordat ze beschikbaar komen.

  Notitie

  Voor meer informatie over het configureren van automatische updates van AKS-knooppunten raadpleegt u installatiekopieën van het besturingssysteem voor automatisch upgraden.

• AKS-clusterversie:

  1. Geen/handmatige updates: dit is voor onveranderbare infrastructuur of wanneer handmatige updates de voorkeur hebben. Hiermee bereikt u de voorspelbaarheid en controle over de updates van de AKS-clusterversies. Opt-in voor dit wordt aanbevolen, omdat dit volledig beheer overlaat, waardoor de kans wordt gegeven om een nieuwe AKS-clusterversie (d.w.e. 1.14.x tot 1.15.x) te testen in lagere omgevingen voordat de productie wordt bereikt.
  2. Automatische updates: een productiecluster wordt niet aanbevolen om automatisch te worden gepatcht of bijgewerkt (bijvoorbeeld 1.16.x naar 1.16.y) naar een nieuwe AKS-clusterversie die beschikbaar is zonder dat deze correct wordt getest in lagere omgevingen. Hoewel upstream-releases van Kubernetes en updates van AKS-clusterversies regelmatig worden gecoördineerd, is de aanbeveling nog steeds afweerbaar met AKS-clusters in productie waardoor de voorspelbaarheid en controle over het updateproces toenemen. Houd rekening met deze configuratie voor lagere omgevingen als onderdeel van Operational Excellence, waardoor proactieve routinetests zo snel mogelijk potentiële problemen kunnen detecteren.

Houd de Kubernetes-versie up-to-date met de ondersteunde N-2-versies. Upgraden naar de nieuwste versie van Kubernetes is essentieel omdat er regelmatig nieuwe versies worden uitgebracht.

Zie Regelmatig bijwerken naar de nieuwste versie van Kubernetes en een AKS-cluster (Azure Kubernetes Service) upgraden voor meer informatie.

Meldingen van gebeurtenissen die worden gegenereerd door uw cluster, zoals de beschikbaarheid van nieuwe AKS-versies voor uw cluster, kunnen worden bereikt via het AKS-systeemonderwerp voor Azure Event Grid. Met de referentie-implementatie wordt dit Event Grid-systeemonderwerp geïmplementeerd, zodat u zich kunt abonneren op de gebeurtenis vanuit uw Microsoft.ContainerService.NewKubernetesVersionAvailable gebeurtenisstroommeldingsoplossing.

Wekelijkse updates

AKS biedt nieuwe knooppuntinstallatiekopieën met de nieuwste updates voor het besturingssysteem en de runtime. Deze nieuwe afbeeldingen worden niet automatisch toegepast. U bent verantwoordelijk voor het bepalen hoe vaak de afbeeldingen moeten worden bijgewerkt. Het is raadzaam om wekelijks een upgrade uit te voeren voor de basisinstallatiekopieën van uw knooppuntgroepen. Zie de AKS-releaseopmerkingen voor AKS-knooppunten(Azure Kubernetes Service) voor meer informatie.

Dagelijkse updates

Tussen installatiekopieënupgrades downloaden en installeren AKS-knooppunten os- en runtimepatches afzonderlijk. Voor een installatie moeten de knooppunt-VM's mogelijk opnieuw worden opgestart. AKS start knooppunten niet opnieuw op vanwege updates die in behandeling zijn. Een proces hebben waarmee knooppunten worden gecontroleerd op de toegepaste updates waarvoor opnieuw opstarten is vereist en die knooppunten op een gecontroleerde manier opnieuw moeten worden opgestart. Een opensource-optie is Kured (Kubernetes reboot daemon).

Door uw knooppuntinstallatiekopieën gesynchroniseerd te houden met de meest recente wekelijkse release, worden deze incidentele herstartaanvragen geminimaliseerd, terwijl een verbeterde beveiligingspostuur behouden blijft. Als u alleen afhankelijk bent van upgrades van knooppuntinstallatiekopieën, zorgt u ervoor dat AKS-compatibiliteit en wekelijkse beveiligingspatches worden uitgevoerd. Terwijl het toepassen van dagelijkse updates sneller beveiligingsproblemen oplost, zijn ze niet noodzakelijkerwijs getest in AKS. Gebruik waar mogelijk de upgrade van knooppuntinstallatiekopieën als uw primaire strategie voor beveiligingspatches.

Controleren van beveiliging

Bewaak uw containerinfrastructuur voor zowel actieve bedreigingen als mogelijke beveiligingsrisico's:

• Schakel Microsoft Defender for Containers in om Defender voor Cloud aanbevelingen voor uw containerinstallatiekopieën te identificeren en te herstellen.
• Microsoft Defender for Containers scant regelmatig uw containerinstallatiekopieën op beveiligingsproblemen.
• Microsoft Defender for Containers genereert ook realtime beveiligingswaarschuwingen voor verdachte activiteiten.
• Zie Beveiligingbeveiliging in hostbesturingssystemen voor informatie over beveiligingsmaatregelen die zijn toegepast op hosts van virtuele AKS-machines.

Cluster- en workloadbewerkingen (DevOps)

Hier volgen enkele overwegingen. Zie de pijler Operational Excellence voor meer informatie.

Cluster bootstrapping

Nadat het inrichten is voltooid, hebt u een werkcluster, maar er zijn mogelijk nog steeds stappen vereist voordat u workloads implementeert. Het proces voor het voorbereiden van uw cluster wordt bootstrapping genoemd en kan bestaan uit acties zoals het implementeren van vereiste installatiekopieën op clusterknooppunten, het maken van naamruimten en alles wat voldoet aan de vereisten van uw use-case of organisatie.

Om de kloof tussen een ingericht cluster en een cluster dat correct is geconfigureerd, te verkleinen, moeten clusteroperators nadenken over hoe hun unieke bootstrappingsproces eruitziet en relevante assets vooraf voorbereiden. Als kured bijvoorbeeld op elk knooppunt wordt uitgevoerd voordat toepassingsworkloads worden geïmplementeerd, moet de clusteroperator ervoor zorgen dat er al een ACR met de doelinstallatiekopie bestaat voordat het cluster wordt ingericht.

Het opstartproces kan worden geconfigureerd met behulp van een van de volgende methoden:

• Zelfconfiguratie met iets als Flux of Argo CD
• Pipelines
• GitOps Flux v2-clusterextensie

Een van de belangrijkste voordelen van het gebruik van de GitOps Flux v2-clusterextensie voor AKS is dat er effectief geen kloof is tussen een ingericht cluster en een opstartcluster. De omgeving wordt in de toekomst ingesteld met een solide beheerbasis en biedt ook ondersteuning voor het opnemen van die bootstrapping als resourcesjablonen om te worden afgestemd op uw IaC-strategie.

Ten slotte is bij het gebruik van de extensie kubectl niet vereist voor een deel van het bootstrappingproces en kan het gebruik van kubectlop -gebaseerde toegang worden gereserveerd voor situaties met noodonderbrekingen. Tussen sjablonen voor Azure-resourcedefinities en het opstarten van manifesten via de GitOps-extensie kunnen alle normale configuratieactiviteiten worden uitgevoerd zonder dat u dit hoeft te gebruiken kubectl.

Workloadverantwoordelijkheden isoleren

Deel de workload door teams en typen resources om elk gedeelte afzonderlijk te beheren.

Begin met een basisworkload die de fundamentele onderdelen bevat en erop voortbouwt. Een eerste taak is het configureren van netwerken. Virtuele netwerken inrichten voor de hub en spoke en subnetten binnen deze netwerken. De spoke heeft bijvoorbeeld afzonderlijke subnetten voor systeem- en gebruikersknooppuntgroepen en toegangsbeheerbronnen. Een subnet voor Azure Firewall in de hub.

Een ander gedeelte kan zijn om de basisworkload te integreren met Microsoft Entra ID.

Infrastructure as Code (IaC) gebruiken

Kies waar mogelijk een idempotente declaratieve methode voor een imperatieve benadering. In plaats van een reeks opdrachten te schrijven waarmee configuratieopties worden opgegeven, gebruikt u declaratieve syntaxis waarmee de resources en de bijbehorende eigenschappen worden beschreven. Een optie is een ARM-sjablonen (Azure Resource Manager). Een andere is Terraform.

Zorg ervoor dat u resources inricht volgens het beleid dat van toepassing is. Wanneer u bijvoorbeeld de juiste VM-grootten selecteert, blijft u binnen de kostenbeperkingen, opties voor beschikbaarheidszones om te voldoen aan de vereisten van uw toepassing.

Als u een reeks opdrachten moet schrijven, gebruikt u Azure CLI. Deze opdrachten hebben betrekking op een reeks Azure-services en kunnen worden geautomatiseerd via scripts. Azure CLI wordt ondersteund in Windows en Linux. Een andere platformoverschrijdende optie is Azure PowerShell. Uw keuze is afhankelijk van de voorkeursvaardighedenset.

Sla scripts en sjabloonbestanden op in uw broncodebeheersysteem en versiescripts.

Workload CI/CD

Pijplijnen voor werkstroom en implementatie moeten continu toepassingen kunnen bouwen en implementeren. Updates moeten veilig en snel worden geïmplementeerd en teruggedraaid voor het geval er problemen zijn.

Uw implementatiestrategie moet een betrouwbare en een geautomatiseerde CD-pijplijn (Continuous Delivery) bevatten. Wijzigingen in de containerinstallatiekopieën van uw workload moeten automatisch worden geïmplementeerd in het cluster.

In deze architectuur hebben we GitHub Actions gekozen voor het beheren van de werkstroom en implementatie. Andere populaire opties zijn Azure DevOps Services en Jenkins.

Cluster-CI/CD

Een Visio-bestand van deze architectuur downloaden.

In plaats van een imperatieve benadering zoals kubectl te gebruiken, gebruikt u hulpprogramma's waarmee wijzigingen in clusters en opslagplaatsen automatisch worden gesynchroniseerd. Als u de werkstroom wilt beheren, zoals de release van een nieuwe versie en validatie van die versie voordat u in productie gaat, kunt u een GitOps-stroom overwegen.

Een essentieel onderdeel van de CI/CD-stroom is het opstarten van een nieuw ingericht cluster. Een GitOps-benadering is nuttig voor dit einde, waardoor operators het opstartproces declaratief kunnen definiëren als onderdeel van de IaC-strategie en de configuratie automatisch in het cluster kunnen zien.

Wanneer u GitOps gebruikt, wordt een agent geïmplementeerd in het cluster om ervoor te zorgen dat de status van het cluster wordt gecoördineerd met de configuratie die is opgeslagen in uw persoonlijke Git-opslagplaats. Een dergelijke agent is flux, die gebruikmaakt van een of meer operators in het cluster om implementaties in Kubernetes te activeren. Flux voert deze taken uit:

• Controleert alle geconfigureerde opslagplaatsen.
• Detecteert nieuwe configuratiewijzigingen.
• Hiermee worden implementaties geactiveerd.
• Hiermee wordt de gewenste actieve configuratie bijgewerkt op basis van deze wijzigingen.

U kunt ook beleidsregels instellen die bepalen hoe deze wijzigingen worden geïmplementeerd.

Hier volgt een voorbeeld van het automatiseren van clusterconfiguratie met GitOps en flux:

Een Visio-bestand van deze architectuur downloaden.

1. Een ontwikkelaar voert wijzigingen door in broncode, zoals YAML-configuratiebestanden, die zijn opgeslagen in een Git-opslagplaats. De wijzigingen worden vervolgens naar een Git-server gepusht.

2. Flux wordt uitgevoerd in pod naast de workload. Flux heeft alleen-lezentoegang tot de Git-opslagplaats om ervoor te zorgen dat Flux alleen wijzigingen toepast zoals aangevraagd door ontwikkelaars.

3. Flux herkent wijzigingen in de configuratie en past deze wijzigingen toe met behulp van kubectl-opdrachten.

4. Ontwikkelaars hebben geen directe toegang tot de Kubernetes-API via kubectl.

5. Vertakkingsbeleidsregels hebben op uw Git-server. Op die manier kunnen meerdere ontwikkelaars een wijziging goedkeuren via een pull-aanvraag voordat deze wordt toegepast op productie.

Hoewel GitOps en Flux handmatig kunnen worden geconfigureerd, wordt de GitOps met flux v2-clusterextensie aanbevolen voor AKS.

Strategieën voor workload- en clusterimplementatie

Implementeer eventuele wijzigingen (architectuuronderdelen, workload, clusterconfiguratie) in ten minste één AKS-cluster vóór productie. Als u dit doet, wordt de wijziging mogelijk ontrafeld voordat deze in productie wordt geïmplementeerd.

Voer tests/validaties uit in elke fase voordat u verdergaat met de volgende fase om ervoor te zorgen dat u updates naar de productieomgeving op een zeer gecontroleerde manier kunt pushen en onderbreking van onverwachte implementatieproblemen kunt minimaliseren. Deze implementatie moet een vergelijkbaar patroon volgen als productie, met behulp van dezelfde GitHub Actions-pijplijn of Flux-operators.

Voor geavanceerde implementatietechnieken, zoals blauwgroene implementatie, A/B-tests en Canary-releases, is extra proces en mogelijk hulpprogramma's vereist. Flagger is een populaire opensource-oplossing om u te helpen bij het oplossen van uw geavanceerde implementatiescenario's.

Kostenbeheer

Bekijk eerst de controlelijst voor het ontwerpen van kostenoptimalisatie en een lijst met aanbevelingen die worden beschreven in het Well Architected Framework for AKS. Gebruik de Azure-prijscalculator om de kosten te schatten voor de services die in de architectuur worden gebruikt. Andere aanbevolen procedures worden beschreven in de sectie Kostenoptimalisatie in Microsoft Azure Well-Architected Framework.

Overweeg om AKS-kostenanalyse in te schakelen voor gedetailleerde kostentoewijzing van clusterinfrastructuur door kubernetes-specifieke constructies.

Zie het bijbehorende artikel voor overwegingen voor kostenbeheer die specifiek zijn voor Windows-workloads die zijn opgenomen in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

inrichten

• Er zijn geen kosten verbonden aan AKS in de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. Wat wel invloed heeft op de kosten zijn de exemplaren van de virtuele machine, opslag, logboekgegevens en netwerkresources die door het cluster worden gebruikt. Overweeg goedkopere VM's te kiezen voor systeemknooppuntgroepen. De DS2_v2-SKU is een typisch VM-type voor de systeemknooppuntgroep.

• U hebt niet dezelfde configuratie voor ontwikkel-/test- en productieomgevingen. Productieworkloads hebben extra vereisten voor hoge beschikbaarheid en zijn doorgaans duurder. Deze configuratie is niet nodig in de ontwikkel-/testomgeving.

• Voor productieworkloads voegt u een SLA voor uptime toe. Er zijn echter besparingen voor clusters die zijn ontworpen voor dev/test- of experimentele workloads waarbij beschikbaarheid niet vereist is om te worden gegarandeerd. De SLO is bijvoorbeeld voldoende. Als uw workload dit ondersteunt, kunt u ook speciale spot-knooppuntgroepen gebruiken waarop spot-VM's worden uitgevoerd.

  Voor niet-productieworkloads met Azure SQL Database of Azure-app Service als onderdeel van de AKS-workloadarchitectuur, evalueert u of u in aanmerking komt voor het gebruik van Azure Dev/Test-abonnementen om servicekortingen te ontvangen.

• In plaats van te beginnen met een te groot cluster om te voldoen aan de schaalbehoeften, richt u een cluster in met een minimum aantal knooppunten en stelt u automatische schaalaanpassing van clusters in staat om de grootte te bewaken en te bepalen.

• Stel podaanvragen en -limieten in om Kubernetes toe te staan knooppuntbronnen met een hogere dichtheid toe te wijzen, zodat hardware wordt gebruikt voor capaciteit.

• Het inschakelen van diagnostische gegevens op het cluster kan de kosten verhogen.

• Als uw workload gedurende een lange periode wordt verwacht, kunt u zich doorvoeren op instanties van één of drie jaar gereserveerde virtuele machine om de knooppuntkosten te verlagen. Zie Gereserveerde VM's voor meer informatie.

• Gebruik tags wanneer u knooppuntgroepen maakt. Tags zijn handig bij het maken van aangepaste rapporten om de gemaakte kosten bij te houden. Tags bieden de mogelijkheid om het totale aantal uitgaven bij te houden en eventuele kosten toe te wijzen aan een specifieke resource of een specifiek team. Als het cluster wordt gedeeld tussen teams, bouwt u ook terugstortingsrapporten per consument om de kosten voor gedeelde cloudservices te identificeren. Zie Een taint, label of tag opgeven voor een knooppuntgroep voor meer informatie.

• Gegevensoverdracht tussen beschikbaarheidszones in een regio is niet gratis. Als uw workload meerdere regio's is of er overdrachten zijn tussen beschikbaarheidszones, verwacht u extra bandbreedtekosten. Zie Verkeer tussen factureringszones en regio's voor meer informatie.

• Maak budgetten om binnen de kostenbeperkingen te blijven die door de organisatie zijn geïdentificeerd. Een manier is om budgetten te maken via Azure Cost Management. U kunt ook waarschuwingen maken om meldingen te ontvangen wanneer bepaalde drempelwaarden worden overschreden. Zie Een budget maken met behulp van een sjabloon voor meer informatie.

Monitor

Als u de kosten van het hele cluster wilt bewaken, samen met de rekenkosten, verzamelt u ook kosteninformatie over opslag, bandbreedte, firewall en logboeken. Azure biedt verschillende dashboards voor het bewaken en analyseren van kosten:

• Azure Advisor

• Azure Cost Management

In het ideale geval kunt u kosten in realtime of ten minste met een regelmatige frequentie bewaken om actie te ondernemen vóór het einde van de maand wanneer de kosten al worden berekend. Controleer ook de maandelijkse trend in de loop van de tijd om in het budget te blijven.

Als u gegevensgestuurde beslissingen wilt nemen, kunt u bepalen welke resource (granular level) de meeste kosten in rekening brengen. U hebt ook een goed begrip van de meters die worden gebruikt om het gebruik van elke resource te berekenen. Door metrische gegevens te analyseren, kunt u bepalen of het platform bijvoorbeeld te groot is. U kunt de gebruiksmeters bekijken in metrische gegevens van Azure Monitor.

Optimaliseren

Reageren op aanbevelingen van Azure Advisor. Er zijn andere manieren om te optimaliseren:

• Schakel automatische schaalaanpassing van clusters in om onderbenutte knooppunten in de knooppuntgroep te detecteren en te verwijderen.

• Kies een lagere SKU voor de knooppuntgroepen als uw workload dit ondersteunt.

• Als voor de toepassing geen burst-schaalaanpassing is vereist, kunt u overwegen om het cluster naar de juiste grootte te schalen door prestatiegegevens in de loop van de tijd te analyseren.

• Als uw workload dit ondersteunt, schaalt u uw gebruikersknooppuntgroepen naar 0 knooppunten wanneer er geen verwachting is dat ze worden uitgevoerd. Als er geen workloads meer gepland zijn om te worden uitgevoerd in uw cluster, kunt u overwegen de functie AKS Starten/stoppen te gebruiken om alle berekeningen af te sluiten, waaronder uw systeemknooppuntgroep en het AKS-besturingsvlak.

Zie AKS-prijzen voor andere kostengerelateerde informatie.

Volgende stappen

Ga verder met het leren van de AKS-basislijnarchitectuur:

• Zie Advanced Azure Kubernetes Service (AKS) microservicesarchitectuur voor meer informatie over het hosten van Microservices in de AKS-basislijn.
• Zie AKS-basislijn voor clusters met meerdere regio's voor het implementeren van de AKS-basislijn in meerdere regio's.
• Zie voor het implementeren van de AKS-basislijn in een PCI-DSS 3.2.1-omgeving AKS gereglementeerd cluster voor PCI-DSS 3.2.1.
• Voor meer informatie over overwegingen voor het toevoegen van Windows-containers aan de referentiearchitectuur raadpleegt u het bijbehorende artikel: Windows-containers in de referentiearchitectuur van de AKS-basislijn

Meer informatie over AKS

• Bekijk de AKS-productroadmap, zie Azure Kubernetes Service Roadmap op GitHub.
• Als u een vernieuwing op Kubernetes nodig hebt, voltooit u de inleiding tot Kubernetes en ontwikkelt en implementeert u toepassingen in Kubernetes-leertrajecten .

Verwante resources

Raadpleeg de volgende gerelateerde handleidingen:

• Azure Well-Architected Framework review for Azure Kubernetes Service (AKS)
• De AKS Landing Zone Accelerator, een implementatie op ondernemingsniveau op basis van deze architectuur. Met de accelerator kunt u uw Azure-omgeving op een consistente en herhaalbare manier instellen met behulp van Infrastructure-As-Code (IaC) voor een AKS-implementatie (Azure Kubernetes Service).
• Bewerkingshandleiding voor Azure Kubernetes Services (AKS) dag 2

Zie de volgende gerelateerde architecturen:

• Microservicesarchitectuur in Azure Kubernetes Service
• Azure Firewall gebruiken om een AKS-cluster (Azure Kubernetes Service) te beveiligen
• GitOps voor Azure Kubernetes Service
• Gegevensstreaming met AKS