Basislijnarchitectuur voor een Azure Kubernetes Service-cluster (AKS)

Dit artikel bevat een aanbevolen basisinfrastructuurarchitectuur voor het implementeren van een AKS-cluster (Azure Kubernetes Service). Het maakt gebruik van onze ontwerpprincipes en is gebaseerd op best practices voor AKS-architectuur van het Azure Well-Architected Framework. In dit artikel worden meerdere afzonderlijke interdisciplinaire groepen, zoals netwerken, beveiliging en identiteitsteams, begeleid bij het implementeren van deze algemene infrastructuur.

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

Uw bedrijfsvereisten zijn van invloed op de doelarchitectuur en kunnen variëren tussen verschillende toepassingscontexten. Overweeg de architectuur als uitgangspunt voor preproductie- en productiefasen.

U kunt een implementatie van deze architectuur op GitHub gebruiken: referentie-implementatie van AKS-basislijn. Gebruik dit als alternatief uitgangspunt en configureer de referentiearchitectuur op basis van uw behoeften.

Netwerkconfiguratie

Netwerktopologie
De IP-adressen plannen
Toegangsbeheerobjectbronnen 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. Implementeer de hub en spokes in afzonderlijke virtuele netwerken die zijn verbonden via peering van virtuele netwerken. Deze topologie heeft verschillende voordelen. Gebruik deze topologie om:

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

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

• Regionale hub- en spoke-topologieën bieden. U kunt hub- en spoke-netwerktopologieën in de toekomst uitbreiden en workloadisolatie bieden.

• Gebruik een Web Application Firewall-service om de HTTP-verkeersstroom voor alle webtoepassingen te controleren.

• Ondersteuning bieden voor workloads die meerdere abonnementen omvatten.

• Maak de architectuur uitbreidbaar. Voor nieuwe functies of workloads kunt u nieuwe spokes toevoegen in plaats van de netwerktopologie opnieuw te ontwerpen.

• Ondersteuning voor het delen van resources, zoals een firewall en DNS-zones (Domain Name System) in netwerken.

• Afstemmen op de landingszone op ondernemingsniveau van Azure.

Een Visio-bestand van deze architectuur downloaden.

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

Zie Windows-containers op AKS voor meer informatie over de wijzigingen in het netwerkontwerp die zijn opgenomen in de Windows-containers in de referentiearchitectuur van de AKS-basislijn.

Virtueel hubnetwerk

Het virtuele hubnetwerk is het centrale punt van connectiviteit en waarneembaarheid. In deze architectuur bevat de hub:

• Azure Firewall met globaal firewallbeleid, gedefinieerd door uw centrale IT-teams om het firewallbeleid voor de hele organisatie af te dwingen.
• Azure Bastion voor externe toegang tot virtuele machines (VM's).
• Een gatewaysubnet voor VPN-connectiviteit.
• Azure Monitor voor netwerkobserveerbaarheid.

Binnen het netwerk heeft de architectuur drie subnetten.

Subnet voor het hosten van Azure Firewall

Azure Firewall is een beheerde firewallservice. Het Azure Firewall-exemplaar beveiligt uitgaand netwerkverkeer. Zonder deze beveiligingslaag kan het verkeer communiceren met een schadelijke, niet-Microsoft-service die gevoelige workloadgegevens kan exfiltreren. Gebruik Azure Firewall Manager om meerdere Azure Firewall-exemplaren centraal te implementeren en te configureren en Azure Firewall-beleid te beheren voor dit type virtuele netwerkarchitectuur van de hub.

Subnet voor het hosten van een gateway

Dit subnet is een tijdelijke aanduiding voor een VPN-gateway of een Azure 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 Azure Bastion gebruiken om veilig toegang te krijgen tot Azure-resources zonder de resources beschikbaar te maken op internet. Dit subnet is alleen bedoeld voor beheer en bewerkingen.

Virtueel spoke-netwerk

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

Subnet voor het hosten van Azure-toepassing-gateway

Application Gateway is een load balancer voor webverkeer die op Laag 7 werkt. De referentie-implementatie maakt gebruik van de Application Gateway v2-SKU waarmee Azure Web Application Firewall wordt ingeschakeld. Web Application Firewall beveiligt binnenkomend verkeer tegen 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 toegangsbeheerobjectcontroller 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 AKS voor meer informatie.

Subnet voor het hosten van de clusterknooppunten

AKS onderhoudt twee knooppuntgroepen, die afzonderlijke groepen knooppunten zijn. 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 Azure Private Link-eindpunten

Maak Private Link-verbindingen voor Azure Container Registry en Azure Key Vault , zodat gebruikers toegang hebben tot deze services via een privé-eindpunt in het virtuele spoke-netwerk. Voor privé-eindpunten is geen toegewezen subnet vereist. U kunt ook privé-eindpunten in het virtuele hubnetwerk plaatsen. In de implementatie van de basislijn worden de eindpunten geïmplementeerd in een toegewezen subnet in het virtuele spoke-netwerk. Deze aanpak vermindert het verkeer dat via de gekoppelde netwerkverbinding verloopt. Hiermee blijven de resources die deel uitmaken van het cluster in hetzelfde virtuele netwerk. U kunt ook gedetailleerde beveiligingsregels toepassen 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. Kubernetes wijst IP-adressen toe voor deze entiteiten vanuit de adresruimte van het subnet. Houd rekening met deze punten.

• Upgrades

  AKS werkt knooppunten regelmatig bij om ervoor te zorgen dat de onderliggende VM's 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. Zorg ervoor dat u voldoende adresruimte hebt voor deze tijdelijke IP-adressen van knooppunten.

  Voor pods hebt u mogelijk meer adressen nodig, afhankelijk van uw strategie. Voor rolling updates hebt u adressen nodig voor de tijdelijke pods die de workload uitvoeren 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 die uitgeschaalde knooppunten.

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

• Private Link-adressen

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

• Azure reserveert bepaalde adressen voor het gebruik ervan. 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. In een AKS-productiecluster scheidt u altijd de systeemknooppuntgroep van de gebruikersknooppuntgroep. Wanneer u meerdere werkbelastingen op het cluster uitvoert, wilt u de gebruikersknooppuntgroepen mogelijk van elkaar isoleren. Als u dat doet, resulteert dit 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-basisnetwerktopologie 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.

Zie Windows-containers in AKS voor meer informatie over de overwegingen bij het plannen van IP-adressen die zijn opgenomen in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

Invoegtoepassingen en preview-functies

Kubernetes en AKS ontwikkelen zich continu, met snellere releasecycli dan software voor on-premises omgevingen. Deze basislijnarchitectuur is afhankelijk van de geselecteerde AKS-preview-functies en AKS-invoegtoepassingen. Dit is het verschil tussen de twee:

• Het AKS-team beschrijft preview-functies zoals verzonden en verbeterd , omdat veel van de preview-functies slechts enkele maanden in die staat blijven voordat ze naar de fase algemene beschikbaarheid (GA) gaan.

• AKS-invoegtoepassingen en -extensies bieden extra, ondersteunde functionaliteit. AKS beheert de installatie, configuratie en levenscyclus.

Deze basislijnarchitectuur bevat niet elke preview-functie of invoegtoepassing. In plaats daarvan bevat het alleen de waarden die aanzienlijke waarde toevoegen aan een cluster voor algemeen gebruik. Naarmate deze functies uit de preview-versie komen, wordt deze basislijnarchitectuur dienovereenkomstig herzien. Er zijn enkele andere preview-functies of AKS-invoegtoepassingen die u mogelijk wilt evalueren in preproductieclusters. Deze functies kunnen uw beveiliging, beheerbaarheid of andere vereisten verbeteren. Met niet-Microsoft-invoegtoepassingen 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 de installatiekopieën naar uw cluster haalt.

• Verifieer het cluster om de installatiekopie op te halen.

• Importeer een openbare installatiekopieën in het containerregister die overeenkomt met uw serviceniveaudoelstelling (SLO), als u een openbare installatiekopieën gebruikt. Anders is de installatiekopieën mogelijk onderhevig aan onverwachte beschikbaarheidsproblemen. Als de installatiekopieën niet beschikbaar zijn wanneer u deze nodig hebt, kan dit operationele problemen veroorzaken. Hier volgen enkele voordelen van het gebruik van een privécontainerregister, zoals Azure Container Registry, 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.
  • U kunt profiteren van geïntegreerde containerscans en naleving van installatiekopieën.

• 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 de Container Registry-instantie die wordt geïmplementeerd.

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. Grote knooppunten minimaliseren de footprint van services die worden uitgevoerd op alle knooppunten, zoals bewaking en logboekregistratie.

• Selecteer het juiste VM-type als u specifieke workloadvereisten hebt. U hebt bijvoorbeeld een voor geheugen geoptimaliseerd product nodig voor sommige werkbelastingen of een gpu-versneld product voor anderen. Zie Grootten voor virtuele machines in Azure voor meer informatie.

• 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.

• Plan de werkelijke knooppuntgrootten voor uw workload op basis van de vereisten die door uw ontwerpteam worden bepaald. Op basis van de bedrijfsvereisten maakt deze architectuur gebruik van DS4_v2 voor de productieworkload. Als u de kosten wilt verlagen, kunt u de grootte verlagen tot DS3_v2. Dit is de minimale aanbeveling.

• Stel dat uw workload maximaal 80% van elk knooppunt verbruikt bij het plannen van capaciteit voor uw cluster. 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 er vanuit het perspectief van het cluster aan wanneer u beveiligingskeuzen maakt:

• Toegang tot binnenuit. Overweeg AKS-toegang tot Azure-onderdelen, zoals netwerkinfrastructuur, Container Registry en Key Vault. Autoriseren alleen de resources waartoe het cluster toegang moet hebben.
• Externe toegang. Identiteiten toegang bieden 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 methoden voor het beheren van AKS-toegang tot Azure raden we beheerde identiteiten aan. Met service-principals moet u geheimen beheren en roteren, handmatig of programmatisch. Met beheerde identiteiten beheert en voert Microsoft Entra ID de verificatie en tijdige rotatie van geheimen voor u uit.

U wordt aangeraden beheerde identiteiten in te schakelen en te gebruiken, zodat het cluster kan communiceren met externe Azure-resources via Microsoft Entra-id. Zelfs als u de integratie van Microsoft Entra ID niet onmiddellijk gebruikt, kunt u deze later opnemen.

Standaard zijn er twee primaire identiteiten die door het cluster worden gebruikt: de clusteridentiteit en de kubelet-identiteit. De onderdelen van het AKS-besturingsvlak gebruiken de clusteridentiteit om clusterresources te beheren, inclusief inkomende load balancers en door AKS beheerde openbare IP-adressen. De kubelet-identiteit wordt geverifieerd met Container Registry. Sommige invoegtoepassingen ondersteunen ook verificatie met behulp van een beheerde identiteit.

U moet beheerde identiteiten gebruiken wanneer het cluster installatiekopieën uit een containerregister moet ophalen. Voor deze actie moet het cluster de referenties van het register ophalen. Als u geen beheerde identiteit gebruikt, kunt u die informatie opslaan in de vorm van een Kubernetes-geheimobject en dit gebruiken imagePullSecrets om het geheim op te halen. We raden deze benadering niet aan vanwege beveiligingscomplexiteiten. U hebt niet alleen voorafgaande kennis van het geheim nodig, maar u moet dat geheim ook opslaan in de DevOps-pijplijn. Een andere reden waarom we deze aanpak niet aanbevelen, 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 de zorgen aangepakt.

In deze architectuur heeft het cluster toegang tot Azure-resources die microsoft Entra ID beveiligt en voert het cluster 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 doet. Het cluster verifieert zichzelf bij Microsoft Entra-id en wordt vervolgens toegang toegestaan of geweigerd op basis van de rollen die eraan zijn toegewezen. Hier volgen enkele voorbeelden van deze referentie-implementatie waarbij ingebouwde Azure-rollen worden toegewezen aan het cluster:

• De rol Inzender voor het netwerk. Beheert de mogelijkheid van het cluster om het virtuele spoke-netwerk te beheren. Met deze roltoewijzing kan de door het AKS-cluster toegewezen identiteit werken met het toegewezen subnet voor de interne toegangsbeheerservice.

• De rol Van uitgever van metrische gegevens bewaken. Hiermee beheert u de mogelijkheid van het cluster om metrische gegevens naar Azure Monitor te verzenden.

• AcrPull-rol. Hiermee beheert u de mogelijkheid van het cluster om installatiekopieën op te halen uit de opgegeven Azure Container Registry-exemplaren.

Clustertoegang

Microsoft Entra-integratie vereenvoudigt ook de beveiliging voor externe toegang. U kunt bijvoorbeeld kubectl gebruiken. Als eerste stap kunt u de az aks get-credentials opdracht uitvoeren om de referenties van het cluster op te halen. Microsoft Entra ID verifieert uw identiteit met de Azure-rollen die clusterreferenties mogen ophalen. Zie Beschikbare clusterrollenmachtigingen voor meer informatie.

AKS ondersteunt Kubernetes-toegang met behulp van Microsoft Entra ID op twee manieren. 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 methode maakt gebruik van systeemeigen Azure RBAC voor het beheren van clustertoegang. In de volgende secties worden beide benaderingen beschreven.

Kubernetes RBAC koppelen aan Microsoft Entra-id

Kubernetes ondersteunt RBAC via:

• Een set machtigingen die u definieert met behulp van een Role of ClusterRole object voor machtigingen voor het hele cluster.

• Bindingen die gebruikers en groepen toewijzen die gemachtigd zijn om de acties uit te voeren. Bindingen definiëren met behulp van een RoleBinding of ClusterRoleBinding object.

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

Zorg ervoor dat u de Microsoft Entra-groepen voor toegang tot clusters en naamruimten opneemt in uw Microsoft Entra-toegangsbeoordelingen.

Azure RBAC gebruiken voor Kubernetes-autorisatie

In plaats van kubernetes native RBAC ClusterRoleBindings te gebruiken en RoleBindings voor autorisatie met geïntegreerde Microsoft Entra-verificatie raden we u aan Azure RBAC en Azure-roltoewijzingen te gebruiken. Met deze aanpak worden autorisatiecontroles op het cluster afgedwongen. U kunt deze rollen zelfs toewijzen aan de bereiken van de beheergroep, het abonnement of de resourcegroep. Alle clusters onder het bereik nemen vervolgens een consistente set roltoewijzingen over 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. We raden u niet aan deze methode te gebruiken om gebruikerstoegang tot clusters te bieden. Deze methode is gebaseerd op certificaten en wordt extern uitgevoerd voor uw primaire id-provider, waardoor uw gecentraliseerde gebruikerstoegangsbeheer en -governance lastig zijn. 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 tot lokale clusteraccounts expliciet uitgeschakeld wanneer het systeem het cluster implementeert.

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 zich bij de resource als een door Azure beheerde identiteit.

In deze referentie-implementatie biedt Microsoft Entra Workload-ID op AKS de beheerde identiteiten voor pods. Deze benadering kan worden geïntegreerd met de systeemeigen kubernetes-mogelijkheden om te federeren met externe id-providers. Zie Federatie van workloadidentiteit voor meer informatie over Microsoft Entra Workload-ID federatie.

Binnenkomende resources implementeren

Kubernetes-toegangsbeheerbronnen verwerken routering en distributie voor inkomend verkeer naar het cluster. Er zijn twee delen van toegangsbeheerbronnen:

• De interne load balancer, beheerd door AKS. De load balancer maakt de ingangscontroller beschikbaar via een privé statisch IP-adres. Het fungeert als één contactpunt dat binnenkomende stromen ontvangt.

  Deze architectuur maakt gebruik van Azure Load Balancer. Load Balancer bevindt zich buiten het cluster in een subnet dat is toegewezen aan toegangsbeheerobjectbronnen. Het ontvangt verkeer van Application Gateway en de communicatie verloopt via TLS (Transport Layer Security). Zie Inkomend verkeerstroom voor meer informatie over TLS-versleuteling voor inkomend verkeer.

• De ingangscontroller. In dit voorbeeld wordt Traefik gebruikt. 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 de volgende punten bij het configureren van dit onderdeel.

• Beperk de ingangscontroller tot een specifiek bereik van bewerkingen als onderdeel van uw ontwerpbeslissingen. 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 ervoor te zorgen dat bedrijfscontinuïteit wordt gegarandeerd 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 Application Gateway.

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

• Overweeg om de toegang van de ingangscontroller tot specifieke resources te beperken en de mogelijkheid om bepaalde acties uit te voeren. U kunt deze beperking implementeren via Kubernetes RBAC-machtigingen. In deze architectuur krijgt Traefik bijvoorbeeld machtigingen om services en eindpunten te bekijken, op te halen en weer te geven met behulp van regels in het Kubernetes-object ClusterRole .

Zie Windows-containers op AKS voor meer informatie over het ontwerp voor inkomend verkeer voor de Windows-containers op AKS in de referentiearchitectuur van de basislijn.

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 opties geven aan dat routes worden geleverd via HTTPS. De middlewares optie geeft aan dat alleen verkeer van het Application Gateway-subnet is toegestaan. De antwoorden gebruiken gzip-codering als de client 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

In deze architectuur bevat de netwerkstroom het volgende:

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

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

• Pod-naar-pod-verkeer 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 tussen de client en de Kubernetes-API-server.

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 coderingen. SNI-strikte overeenkomsten (Server Name Indication) zijn ingeschakeld. End-to-end TLS wordt ingesteld via Application Gateway met behulp van twee verschillende TLS-certificaten, zoals wordt weergegeven in het volgende diagram.

Een Visio-bestand van deze architectuur downloaden.

1. De client verzendt een HTTPS-aanvraag naar de domeinnaam: bicycle.contoso.com. Deze naam is gekoppeld aan een DNS A-record aan het openbare IP-adres van Application 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 webtoepassingsfirewall en onderhandelt over de TLS-handshake voor bicycle.contoso.com, waardoor alleen veilige coderingen worden toegestaan. Application Gateway is een TLS-beëindigingspunt, wat belangrijk is omdat de webtoepassingsfirewall van Application Gateway het antwoord zonder opmaak moet inspecteren. Key Vault slaat het TLS-certificaat op. Het cluster heeft toegang tot het cluster met een door de gebruiker toegewezen beheerde identiteit die is geïntegreerd met Application Gateway. Zie TLS-beëindiging met Key Vault-certificaten voor meer informatie.

   Application Gateway verwerkt inspectieregels voor Web Application Firewall en voert routeringsregels uit waarmee het verkeer wordt doorgestuurd naar de geconfigureerde back-end.

3. Naarmate verkeer van Application Gateway naar de back-end wordt verplaatst, wordt het opnieuw versleuteld met een ander TLS-certificaat, een jokerteken voor *.aks-ingress.contoso.com, omdat het wordt doorgestuurd naar de interne load balancer. Deze herversleuteling zorgt ervoor dat onbeveiligd verkeer niet naar 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 Key Vault en het CSI-stuurprogramma (Container Storage Interface) koppelt deze aan het cluster. Zie Geheimbeheer toevoegen voor meer informatie.

U kunt end-to-end TLS-verkeer implementeren bij elke hop via de workloadpod. Zorg ervoor dat u de prestaties, latentie en operationele gevolgen meet bij het nemen van de beslissing om pod-naar-pod-verkeer te beveiligen. Voor de meeste clusters met één tenant, met de juiste beheervlak-RBAC en volwassen levenscyclusprocedures voor softwareontwikkeling, is het voldoende om TLS te versleutelen tot de ingangscontroller en te beveiligen met Web Application Firewall. Deze aanpak minimaliseert overhead in workloadbeheer en overhead vanwege slechte netwerkprestaties. Uw workload- en nalevingsvereisten bepalen waar u TLS-beëindiging uitvoert.

Uitgaande verkeersstroom

In deze architectuur raden we aan dat al het uitgaand verkeer van het cluster communiceert via Azure Firewall. U kunt ook uw eigen vergelijkbare virtuele netwerkapparaat gebruiken. We raden u niet aan andere uitgaande opties te gebruiken, zoals Azure NAT Gateway of een HTTP-proxy , omdat ze geen inspectie van netwerkverkeer bieden. Voor Zero Trust-beheer en de mogelijkheid om verkeer te controleren, wordt al het uitgaande verkeer van het cluster via firewall verplaatst. U kunt deze configuratie implementeren met door de gebruiker gedefinieerde routes (UDR's). De volgende hop van de route is het privé-IP-adres van Azure Firewall. Azure Firewall bepaalt of het uitgaand verkeer moet worden geblokkeerd of toegestaan. Deze beslissing is gebaseerd op de specifieke regels die u definieert in Azure Firewall of de ingebouwde regels voor bedreigingsinformatie.

Een alternatief voor Azure Firewall is het gebruik van de AKS HTTP-proxyfunctie . Al het verkeer dat het cluster verlaat, gaat naar het IP-adres van de HTTP-proxy, waarmee het verkeer wordt doorgestuurd of verwijderd.

Raadpleeg voor beide methoden de vereiste regels voor uitgaand netwerkverkeer voor AKS.

Een uitzondering op het zero trust-besturingselement is wanneer het cluster moet communiceren met andere Azure-resources. Het cluster moet bijvoorbeeld een bijgewerkte installatiekopie ophalen uit het containerregister of geheimen uit Key Vault. In deze scenario's wordt u aangeraden Private Link te gebruiken. Het voordeel is dat specifieke subnetten de service rechtstreeks bereiken en het verkeer tussen het cluster en de services niet via internet gaat. Een nadeel is dat Private Link extra configuratie nodig heeft in plaats van de doelservice te gebruiken via het openbare eindpunt. Bovendien ondersteunen niet alle Azure-services of -producten 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, kunt u deze adressen toevoegen aan de IP-acceptatielijst van de service. Een nadeel is dat Azure Firewall vervolgens meer regels nodig heeft om ervoor te zorgen dat alleen verkeer van een specifiek subnet wordt toegestaan. Houd rekening met deze adressen wanneer u meerdere IP-adressen plant voor uitgaand verkeer met Azure Firewall. Anders kunt u poortuitputting bereiken. Zie Een Azure Firewall met meerdere IP-adressen maken met meerdere IP-adressen voor meer informatie over het plannen van meerdere IP-adressen.

Zie Windows-containers op AKS voor informatie over de windows-specifieke uitgangspunten in de Windows-containers in de referentiearchitectuur voor AKS-basislijnen.

Pod-naar-pod-verkeer

Standaard kan een pod verkeer van elke andere pod in het cluster accepteren. Gebruik Kubernetes NetworkPolicy om netwerkverkeer tussen pods te beperken. Pas beleidsregels zorgvuldig toe of u hebt 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 u het cluster inricht, omdat u het later niet kunt toevoegen. U hebt een aantal keuzes voor technologieën die implementeren NetworkPolicy. Azure-netwerkbeleid wordt aanbevolen. Hiervoor is Azure Container Networking Interface (CNI) vereist. Zie de volgende opmerking voor meer informatie. 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-netwerkbeleidsengines 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 om het cluster te schalen. Voorbeelden van deze resources zijn de buildagentpool in een DevOps-pijplijn, een Azure Bastion-exemplaar binnen het Azure Bastion-subnet en de knooppuntgroepen zelf. In plaats van dit beheerverkeer van alle IP-adressen te accepteren, gebruikt u de functie voor door AKS geautoriseerde IP-bereiken om alleen verkeer van uw geautoriseerde IP-bereiken naar de API-server toe te staan

Zie Ip-adresbereiken definiëren die door de API-server zijn geautoriseerd voor meer informatie.

Voor een andere controlelaag kunt u tegen extra complexiteit een privé-AKS-cluster inrichten. Door een privécluster te gebruiken, kunt u ervoor zorgen dat netwerkverkeer tussen uw API-server en uw knooppuntgroepen alleen in het privénetwerk blijft en nooit beschikbaar is op internet. Zie AKS-privéclusters voor meer informatie.

Sleutelbeheer toevoegen

Geheimen opslaan in een beheerde sleutelopslag, zoals Key Vault. Het voordeel is dat een beheerd sleutelarchief de rotatie van geheimen afhandelt. Het biedt sterke versleuteling en een toegangscontrolelogboek. Het bewaart ook kerngeheimen uit de implementatiepijplijn. In deze architectuur wordt een Key Vault-firewall ingeschakeld en geconfigureerd, en Private Link wordt gebruikt bij het maken van verbinding vanuit resources in Azure die toegang nodig hebben tot geheimen en certificaten.

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 meer informatie over hoe Application Gateway toegang heeft tot TLS-certificaten voor de ingangsstroom .

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 Access 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 CSI-stuurprogramma voor geheimenarchief om het ophaalproces te vergemakkelijken. Wanneer de pod een geheim nodig heeft, maakt het stuurprogramma verbinding met het opgegeven archief, haalt een 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. Deze implementatie maakt gebruik van de Key Vault met het CSI-stuurprogramma voor geheimenopslag. De invoegtoepassing haalt het TLS-certificaat op uit Key Vault en laadt het stuurprogramma in de pod waarop de ingangscontroller wordt uitgevoerd. Deze bewerking vindt plaats tijdens het maken van pods en het volume slaat zowel openbare als de persoonlijke sleutels op.

Workloadopslag

De workload in deze architectuur is staatloos. Als u de status wilt opslaan, raden we u aan deze buiten het cluster te behouden. Richtlijnen voor de status van de werkbelasting vallen buiten het bereik van dit artikel.

Zie Opslagopties voor toepassingen in AKS voor meer informatie.

Beleidsbeheer

Een effectieve manier om een AKS-cluster te beheren, is door governance af te dwingen via beleid. Kubernetes implementeert beleidsregels via OPA Gatekeeper (Open Policy Agent). Voor AKS kunt u beleidsregels leveren via Azure Policy. Elk beleid is van toepassing op alle clusters binnen het bereik. OPA Gatekeeper verwerkt beleidshandhaving in het cluster en registreert alle beleidscontroles. De beleidswijzigingen worden niet onmiddellijk doorgevoerd in uw cluster, dus verwacht enige vertragingen.

Als u uw AKS-clusters wilt beheren, kunt u Azure Policy gebruiken voor het volgende:

• Voorkomen of beperken van de implementatie van AKS-clusters in een resourcegroep of abonnement. Pas standaarden toe voor uw organisatie. U kunt bijvoorbeeld een naamconventie volgen of een tag opgeven.
• 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 instellen, ook wel initiatieven genoemd 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. U wordt aangeraden een initiatief te selecteren en andere beleidsregels te kiezen voor het cluster en de resources, zoals Container Registry, Application Gateway of Key Vault, die communiceren met het cluster. Kies beleidsregels op basis van de vereisten van uw organisatie.

• Wilt u de actie controleren of weigeren ? In de controlemodus is de actie toegestaan, maar gemarkeerd als Niet-compatibel. Laat processen uitvoeren 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 bij het kiezen van deze modus, omdat deze te beperkend kan zijn voor de werking van de werkbelasting.

• 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 het afdwingen van beleid. U wordt aangeraden 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.

• 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 uw organisatie algemene beleidsregels heeft.

• Wijst u Azure-beleid toe 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 extra beperkingen waarvoor u geen rekening houdt in de preproductie.

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

De implementatie stelt ook extra 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 Container Registry-instantie. 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 en de logboeken voor de azure-policy en azure-policy-webhook pods in de kube-system naamruimte.

Zie het artikel over Windows-beleidsbeheer in de Windows-containers op AKS-beleidsbeheer voor meer informatie over overwegingen voor Windows-specifieke Azure Policy.

Schaalbaarheid van knooppunten en pods

Met een toenemende vraag kan Kubernetes worden uitgebreid door meer pods toe te voegen aan bestaande knooppunten, via horizontale automatische schaalaanpassing van pods. Wanneer Kubernetes niet langer meer pods kan plannen, 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 zowel automatische schaalaanpassing als handmatige benadering moet u waarschuwingen voor CPU-gebruik of aangepaste metrische gegevens bewaken en instellen. Voor het schalen van pods kan uw toepassingsoperator het aantal podreplica's verhogen of verkleinen door de ReplicaSet api's van Kubernetes aan te passen. Voor het schalen van clusters moet één methode worden gewaarschuwd 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 Azure Portal.

We raden de methode voor automatisch schalen aan omdat sommige van deze handmatige mechanismen zijn ingebouwd in de automatische schaalaanpassing.

Als algemene methode 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 het antwoord van de toepassing op schalen. Gebruik tot slot deze gegevens om de parameters voor automatisch schalen in te stellen. Zie het scenario voor het afstemmen van prestaties: gedistribueerde zakelijke transacties voor meer 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 u aangeraden het minimum- en maximumaantal replica's in te stellen. De waarden beperken de grenzen voor automatisch schalen.

De HPA kan worden geschaald op basis van CPU-gebruik, geheugengebruik en aangepaste metrische gegevens. Alleen CPU-gebruik wordt standaard verstrekt. De HorizontalPodAutoscaler definitie geeft doelwaarden op voor de metrische gegevens. De specificatie stelt bijvoorbeeld het cpu-doelgebruik 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 de 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 Kubernetes gebeurtenisgestuurde automatische schaalaanpassing (KEDA) . Overweeg KEDA als een gebeurtenisbron, zoals een berichtenwachtrij, uw workload aanstuurt in plaats van dat uw workload CPU-gebonden of geheugengebonden is. KEDA ondersteunt veel gebeurtenisbronnen of scalers. Gebruik de lijst met gebeurtenisbronnen die KEDA kan schalen op KEDA-schaalders. De lijst bevat de Azure Monitor-scaler. Dit is 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. Voeg deze toe tijdens het inrichten van het cluster. U hebt een afzonderlijke automatische schaalaanpassing van clusters nodig voor elke gebruikersknooppuntgroep.

De Kubernetes Scheduler activeert de automatische schaalaanpassing van clusters. 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 twee vanwege de eenvoud van de workload.

Voor de systeemknooppuntgroep is de aanbevolen minimumwaarde drie.

Zie het artikel Over Windows-containers in AKS voor meer informatie over overwegingen voor schalen die zijn opgenomen in deze referentiearchitectuur voor basislijnen.

Beslissingen voor bedrijfscontinuïteit

Als u bedrijfscontinuïteit wilt behouden, definieert u de SLO voor de infrastructuur en uw toepassing. Zie Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen voor meer informatie. Bekijk de SLA-voorwaarden (Service Level Agreement) voor AKS in de nieuwste SLA voor onlineservices artikel.

Clusterknooppunten

Als u wilt voldoen aan het minimale beschikbaarheidsniveau voor workloads, hebt u meerdere knooppunten in een knooppuntgroep nodig. Als een knooppunt mislukt, kan een ander knooppunt in dezelfde knooppuntgroep en het cluster doorgaan met het uitvoeren van de toepassing. Voor betrouwbaarheid raden we drie knooppunten aan 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 toepassing 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. U wordt aangeraden tags, labels en taints te gebruiken om de knooppuntgroep te identificeren en uw workload te plannen. Zorg ervoor dat uw systeemknooppuntgroep is besmet met de CriticalAddonsOnly taint.

Regelmatig onderhoud van uw cluster, zoals tijdige updates, zijn essentieel voor betrouwbaarheid. We raden u ook aan om de status van de pods te bewaken via tests.

Beschikbaarheid van pods

Geef resourcevereisten voor pods op: we raden u aan om resourcevereisten voor pods op te geven in uw implementaties. De scheduler kan vervolgens de pod op de juiste manier plannen. Betrouwbaarheid wordt aanzienlijk verminderd als uw 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 op een naamruimte helpt ervoor te zorgen dat podaanvragen en -limieten correct zijn ingesteld voor een implementatie. Zie Resourcequota afdwingen voor meer informatie.

Podaanvragen en -limieten instellen: Door aanvragen en limieten in te stellen, kunnen Kubernetes efficiënt CPU- en geheugenbronnen toewijzen aan de pods en kunt u een hogere containerdichtheid op een knooppunt hebben. Aanvragen en limieten kunnen ook uw betrouwbaarheid verhogen terwijl uw kosten worden verlaagd vanwege een beter hardwaregebruik.

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

U kunt aanvragen en limieten opgeven in uw implementatiemanifesten. Zie Pod-aanvragen en -limieten instellen voor meer informatie.

Beschikbaarheidszones en ondersteuning voor meerdere regio's

Gebruik beschikbaarheidszones als de regio deze ondersteunt om te beschermen tegen bepaalde soorten storingen. 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. De AKS-service beheert schaalsetbewerkingen en -configuratie. Hier volgen enkele overwegingen wanneer u meerdere zones inschakelt:

• Volledige infrastructuur: kies een regio die beschikbaarheidszones ondersteunt. Zie Beperkingen voor meer informatie. Als u een SLA voor uptime wilt hebben, moet u de Standard- of Premium-laag kiezen. De SLA voor uptime is groter wanneer u beschikbaarheidszones gebruikt.

• Cluster: u kunt alleen beschikbaarheidszones instellen wanneer u de knooppuntgroep maakt. Ze kunnen 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 zones 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, kan een zonefout ertoe leiden dat die service mislukt.

  Een beheerde schijf is bijvoorbeeld beschikbaar in de zone waarin deze is ingericht. Als er een fout optreedt, wordt het knooppunt mogelijk verplaatst naar een andere zone, maar wordt de beheerde schijf niet verplaatst met het knooppunt naar die zone.

Voor het gemak in deze architectuur wordt AKS geïmplementeerd in één regio met knooppuntgroepen die beschikbaarheidszones één, twee en drie omvatten. Andere resources van de infrastructuur, zoals Azure Firewall en Application Gateway, worden ook geïmplementeerd in dezelfde regio met ondersteuning voor meerdere zones. Geo-replicatie is ingeschakeld voor Container Registry.

Meerdere regio's

Wanneer u beschikbaarheidszones inschakelt, is het niet voldoende dekking in het onwaarschijnlijke geval dat een hele regio uitvalt. Als u een hogere beschikbaarheid wilt krijgen, voert u meerdere AKS-clusters in verschillende regio's uit.

• Geef de voorkeur aan gekoppelde regio's wanneer ze beschikbaar zijn. Een voordeel van het gebruik van gekoppelde regio's is betrouwbaarheid tijdens platformupdates. Azure zorgt ervoor dat slechts één regio in het paar tegelijk wordt bijgewerkt. Sommige regio's hebben geen paren. Als uw regio niet is gekoppeld, kunt u nog steeds een oplossing voor meerdere regio's implementeren door andere regio's te selecteren die u wilt gebruiken. Overweeg het gebruik van een CI/CD-pijplijn (continue integratie en continue levering), die u configureert voor het organiseren van herstel na een regiofout. Bepaalde DevOps-hulpprogramma's zoals Flux kunnen de implementaties voor meerdere regio's eenvoudiger maken.

• Geef de locatie op waar de redundante service het secundaire exemplaar heeft als een Azure-resource georedundantie ondersteunt. Als u bijvoorbeeld geo-replicatie inschakelt voor Container Registry, worden installatiekopieën automatisch gerepliceerd naar de geselecteerde Azure-regio's. Het biedt ook continue toegang tot afbeeldingen, zelfs als de primaire regio te maken krijgt met een storing.

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

Herstel na noodgeval

Als er een fout optreedt in de primaire regio, kunt u in het ideale geval snel een nieuw exemplaar maken in een andere regio. Hier volgen enkele aanbevelingen:

• Gebruik meerdere regio's. Als uw primaire regio een gekoppelde regio heeft, gebruikt u dat paar. Zo niet, selecteert u regio's op basis van uw vereisten voor gegevenslocatie en latentie.

• Gebruik een niet-stateful workload die u efficiënt kunt repliceren. Als u de status wilt opslaan in het cluster, wat niet wordt aanbevolen, moet u ervoor zorgen dat u regelmatig een back-up maakt van de gegevens in een andere regio.

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

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

• Implementeer uw infrastructuur als code, inclusief uw AKS-cluster en eventuele andere onderdelen die u nodig hebt. Als u in een andere regio wilt implementeren, kunt u de scripts of sjablonen opnieuw gebruiken om een identiek exemplaar te maken.

Back-up van cluster

Voor veel architecturen kunt u een nieuw cluster inrichten en terugsturen naar de bedrijfsstatus via opstarten op basis van Git-clusters, gevolgd door toepassingsimplementatie. Maar als er een kritieke resourcestatus is, zoals configuratietoewijzingen, taken en geheimen die niet kunnen worden vastgelegd in uw bootstrappingproces, moet u rekening houden met uw herstelstrategie. U wordt aangeraden stateless workloads uit te voeren in Kubernetes. Als uw architectuur een schijfstatus heeft, 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 momentopnamen van azure-schijven, permanente volumemomentopnamen.

VMware 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 nodig zijn om te beheren, bewaken, aanschaffen en beveiligen. Deze resources kunnen bestaan uit een Azure Storage-account, een Azure Backup-kluis en -configuratie en de functie voor vertrouwde toegang. Git-bewerkingen in combinatie met de intentie om staatloze workload uit te voeren, is in plaats daarvan de hersteloplossing.

Kies en valideer een back-upoplossing die voldoet aan uw bedrijfsdoelstelling, inclusief uw gedefinieerde herstelpuntdoelstelling en beoogde hersteltijd. Definieer uw herstelproces in een teamrunbook en oefen dit voor alle bedrijfskritieke workloads.

SLA voor Kubernetes-API-server

U kunt AKS gebruiken als een gratis service, maar die laag biedt geen SLA met financiële ondersteuning. Als u een SLA wilt verkrijgen, moet u de Standard-laag kiezen. We raden alle productieclusters aan om de Standard-laag te gebruiken. Reserveer de gratis laag voor preproductieclusters en de Premium-laag alleen voor bedrijfskritieke workloads . Wanneer u Azure-beschikbaarheidszones gebruikt, is de SLA van de Kubernetes-API-server hoger. Uw knooppuntgroepen en andere resources vallen onder hun eigen SLA's. Zie sla voor onlineservices voor meer informatie over specifieke SLA's voor elke service.

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 Container Registry, zijn beschikbaar in Premium-SKU's, wat duurder is. Voor implementaties in meerdere regio's neemt de kosten ook toe omdat de bandbreedtekosten van toepassing zijn wanneer verkeer tussen regio's wordt verplaatst.

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

Testen met simulaties en geforceerde failovers

Test de betrouwbaarheid van uw oplossing via geforceerde failovertests met gesimuleerde storingen. Simulaties kunnen bestaan uit 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. U kunt Ook Azure Chaos Studio gebruiken om verschillende soorten storingen in Azure en in het cluster te simuleren.

Zie Chaos Studio voor meer informatie.

Metrische gegevens bewaken en verzamelen

We raden Azure Monitor-containerinzichten aan 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 ook containerinzichten gebruiken om de prestaties te bewaken wanneer de pods worden geschaald. Het omvat telemetrie die essentieel is voor bewaking, analyse en visualisatie van de verzamelde gegevens. Container Insights identificeert trends en stelt u in staat om waarschuwingen te configureren voor het ontvangen van proactieve meldingen over kritieke problemen.

De meeste workloads die in pods worden gehost, verzenden metrische prometheus-gegevens. Containerinzichten kunnen worden geïntegreerd met Prometheus. U kunt de metrische gegevens van de toepassing en workload bekijken die zijn verzameld van knooppunten en Kubernetes.

Sommige niet-Microsoft-oplossingen zijn geïntegreerd met Kubernetes, zoals Datadog, Grafana of New Relic. Dus als uw organisatie deze oplossingen al gebruikt, kunt u hiervan profiteren.

Met AKS beheert Azure enkele van de belangrijkste Kubernetes-services. Azure implementeert de logboeken voor de AKS-besturingsvlakonderdelen als resourcelogboeken. U wordt aangeraden de volgende opties voor de meeste clusters in te schakelen. De opties kunnen u helpen bij het oplossen van clusterproblemen en ze hebben een relatief lage logboekdichtheid.

• ClusterAutoscaler: waarneembaarheid verkrijgen in de schaalbewerkingen met logboekregistratie. Zie Logboeken en status van automatische schaalaanpassing van clusters ophalen voor meer informatie.
• KubeControllerManager: waarneembaarheid verkrijgen in de interactie tussen Kubernetes en het Azure-besturingsvlak.
• kube-audit-admin: waarneembaarheid verkrijgen in activiteiten die uw cluster wijzigen. Er is geen reden om beide kube-audit en kube-audit-admin ingeschakeld te hebben. kube-audit is een superset van kube-audit-admin die ook niet-ongewijzigde bewerkingen (leesbewerkingen) omvat.
• guard: leg Microsoft Entra ID en Azure RBAC-controles vast.

Het kan handig zijn voor u om andere logboekcategorieën in te schakelen, zoals KubeScheduler of kube-audit, tijdens de ontwikkeling van de levenscyclus van een vroeg cluster of workload. De toegevoegde automatische schaalaanpassing van clusters, plaatsing en planning van pods en vergelijkbare gegevens kunnen u helpen bij het oplossen van problemen met cluster- of workloadbewerkingen. Maar als u de uitgebreide logboeken voor probleemoplossing fulltime bewaart nadat uw probleemoplossingsbehoeften zijn beëindigd, kunnen er onnodige kosten in rekening worden gebracht om de gegevens op te nemen en op te slaan 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 biedt meer waarneembaarheid in de status en prestaties van uw AKS-clusters. Het biedt ondersteuning voor het bereiken van uw SLO's.

Zie AKS bewaken met Azure Monitor voor meer informatie over onze aanbevolen procedures voor bewaking voor AKS.

Zie Windows-containers op AKS voor meer informatie over windows-specifieke bewakingsoverwegingen.

Metrische netwerkgegevens

Basisgegevens voor netwerken op clusterniveau zijn beschikbaar via systeemeigen platform- en Prometheus-metrische gegevens. U kunt de invoegtoepassing Netwerkobserveerbaarheid verder gebruiken om metrische netwerkgegevens beschikbaar te maken op knooppuntniveau. De meeste clusters moeten gebruikmaken van de invoegtoepassing Netwerkobserveerbaarheid om extra mogelijkheden voor het oplossen van netwerkproblemen te bieden en om onverwacht netwerkgebruik of problemen op knooppuntniveau te detecteren.

Voor workloads die zeer gevoelig zijn voor Transmission Control Protocol (TCP) of UDP-pakketverlies (User Datagram Protocol), latentie of DNS-druk, zijn de metrische netwerkgegevens op podniveau belangrijk. In AKS vindt u dat detailniveau met de functie Geavanceerde netwerkobserveerbaarheid . Voor de meeste workloads is deze diepte van de waarneembaarheid van het netwerk niet vereist. U moet de invoegtoepassing Advanced Network Observability niet installeren, tenzij uw pods een geoptimaliseerd netwerk eisen, met gevoeligheid tot op pakketniveau.

Zelfherstel inschakelen

Bewaak de status van pods door liveness- en gereedheidstests in te stellen. Als Kubernetes een niet-reagerende pod detecteert, wordt de pod opnieuw opgestart. Een livenesstest bepaalt of de pod in orde is. Als Kubernetes een niet-reagerende pod detecteert, wordt de pod opnieuw opgestart. Een gereedheidstest bepaalt of de pod gereed is voor het ontvangen van aanvragen en verkeer.

Routine-updates voor AKS-clusters

Een deel van de dag-2-bewerkingen voor Kubernetes-clusters is het uitvoeren van routineplatform- en besturingssysteemupdates. Er zijn drie lagen met updates voor elk AKS-cluster:

• De Kubernetes-versie (bijvoorbeeld Kubernetes 1.30.3 tot 1.30.7 of Kubernetes 1.30.7 tot 1.31.1), wat kan worden geleverd met Kubernetes API-wijzigingen en -afschaffingen. Versiewijzigingen op deze laag zijn van invloed op het hele cluster.
• De installatiekopieën van de virtuele harde schijf (VHD) op elk knooppunt, waarin updates van het besturingssysteem en updates van AKS-onderdelen worden gecombineerd. Deze updates worden getest op basis van de Kubernetes-versie van het cluster. Versiewijzigingen op deze laag worden toegepast op het niveau van de knooppuntgroep en hebben geen invloed op de Kubernetes-versie.
• Het eigen systeemeigen updateproces van het besturingssysteem, zoals Windows Update of apt. De leverancier van het besturingssysteem levert deze updates rechtstreeks en ze worden niet getest op basis van de Kubernetes-versie van het cluster. Versiewijzigingen op deze laag zijn van invloed op één knooppunt en hebben geen invloed op de Kubernetes-versie.

Elk van deze lagen wordt onafhankelijk beheerd. U bepaalt hoe elke laag wordt verwerkt voor de clusters van uw workload. Kies hoe vaak elk AKS-cluster, de bijbehorende knooppuntgroepen of de knooppunten worden bijgewerkt (de frequentie). Kies ook welke dagen of tijden u de updates wilt toepassen (uw onderhoudsvenster). Kies of updates handmatig of automatisch of helemaal niet worden geïnstalleerd. Net zoals de workload die op uw cluster wordt uitgevoerd, een veilige implementatie nodig heeft, moeten de updates voor uw clusters worden uitgevoerd.

Zie AKS-patch- en upgraderichtlijnen in de AKS day-2-bedieningshandleiding voor een uitgebreid perspectief over patchen en upgraden. Gebruik de volgende informatie voor basislijnaan aanbevelingen, zoals deze betrekking heeft op deze architectuur.

Onveranderbare infrastructuur

Workloads die gebruikmaken van AKS-clusters als onveranderbare infrastructuur, werken hun clusters niet automatisch of handmatig bij. Stel de upgrade van de knooppuntinstallatiekopieën in none op en de automatische upgrade van het cluster naar none. In deze configuratie bent u alleen verantwoordelijk voor alle upgrades in alle lagen. Wanneer een gewenste update beschikbaar wordt, moet u de update testen in een preproductieomgeving en de compatibiliteit ervan op een nieuw cluster evalueren. Daarna implementeert u een productiereplicazegel met de bijgewerkte AKS-versie en knooppuntgroep-VHD's. Wanneer het nieuwe productiecluster gereed is, wordt het oude cluster leeggezet en uiteindelijk uit bedrijf genomen.

Onveranderbare infrastructuur met regelmatige implementaties van nieuwe infrastructuur is de enige situatie waarin voor een productiecluster geen in-place upgradestrategie moet worden toegepast. Alle andere clusters moeten een in-place upgradestrategie hebben.

In-place upgrades

Werkbelastingen die geen AKS-clusters als onveranderbare infrastructuur gebruiken, moeten hun actieve clusters regelmatig bijwerken om alle drie de lagen aan te pakken. Stem uw updateproces af op de vereisten van uw workload. Gebruik de volgende aanbevelingen als uitgangspunt voor het ontwerpen van uw routine-updateproces.

• Plan de geplande onderhoudsfunctie van AKS, zodat u upgrades in uw cluster kunt beheren. Met deze functie kunt u de updates, een inherent riskante bewerking, op een gecontroleerde tijd uitvoeren om het effect van een onverwachte fout te verminderen.
• Configureer budgetten voor podonderbrekingen, zodat uw toepassing stabiel blijft tijdens rolling upgrades. Maar configureer de budgetten niet zo agressief dat ze voorkomen dat er knooppuntupgrades plaatsvinden, omdat de meeste upgrades een cordon- en afvoerproces op elk knooppunt vereisen.
• Bevestig het azure-resourcequotum en de beschikbaarheid van resources. In-place upgrades implementeren nieuwe exemplaren van knooppunten, ook wel piekknooppunten genoemd , voordat oude knooppunten worden verwijderd. Dit betekent dat azure-quotum en IP-adresruimte beschikbaar moeten zijn voor de nieuwe knooppunten. Een piekwaarde van 33% is een goed uitgangspunt voor de meeste workloads.
• Test de compatibiliteit met hulpprogramma's, zoals service-meshes of beveiligingsagents die u aan uw cluster hebt toegevoegd. En test uw workloadonderdelen, zoals ingangscontrollers, service-meshes en uw workloadpods. Voer tests uit in een preproductieomgeving.

In-place upgrades voor knooppunten

Gebruik het NodeImage kanaal voor automatische upgrade voor upgrades van installatiekopieën van knooppuntbesturingssystemen. Met dit kanaal configureert u uw cluster om de VHD op elk knooppunt bij te werken met updates op knooppuntniveau. Microsoft test de updates op uw AKS-versie. Voor Windows-knooppunten worden de updates ongeveer één keer per maand uitgevoerd. Voor Linux-knooppunten vindt deze updates ongeveer één keer per week plaats.

• De upgrades wijzigen nooit uw AKS- of Kubernetes-versie, dus compatibiliteit met kubernetes-API's is geen probleem.
• Wanneer u het upgradekanaal gebruikt NodeImage , wordt uw geplande onderhoudsvenster gerespecteerd, dat u ten minste één keer per week moet instellen. Stel het in, ongeacht het besturingssysteem van de knooppuntinstallatiekopieën dat u gebruikt om ervoor te zorgen dat de toepassing tijdig werkt.
• Deze updates omvatten beveiliging, compatibiliteit en functionele updates op besturingssysteemniveau, configuratie-instellingen voor besturingssystemen en updates van AKS-onderdelen.
• Installatiekopieën en de bijbehorende onderdeelversienummers worden bijgehouden met behulp van de AKS-releasetracker.

Als de beveiligingsvereisten voor uw cluster een agressievere patchfrequentie eisen en uw cluster de mogelijke onderbrekingen kan tolereren, gebruikt u in plaats daarvan het SecurityPatch upgradekanaal. Microsoft test deze updates ook. De updates worden alleen gepubliceerd als er beveiligingsupgrades zijn die Microsoft belangrijk genoeg acht om vrij te geven voordat de volgende upgrade van de geplande knooppuntinstallatiekopieën wordt uitgevoerd. Wanneer u het SecurityPatch kanaal gebruikt, krijgt u ook de updates die het NodeImage kanaal heeft ontvangen. De SecurityPatch kanaaloptie houdt nog steeds rekening met uw onderhoudsvensters, dus zorg ervoor dat uw onderhoudsvenster vaker hiaten (zoals dagelijks of elke andere dag) heeft om deze onverwachte beveiligingsupdates te ondersteunen.

De meeste clusters die in-place upgrades uitvoeren, moeten de None opties voor upgradekanaal Unmanaged voor knooppuntinstallatiekopieën vermijden.

In-place updates voor het cluster

Kubernetes is een snel evoluerend platform en regelmatige updates brengen belangrijke beveiligingsoplossingen en nieuwe mogelijkheden met zich mee. Het is belangrijk dat u actueel blijft met Kubernetes-updates. U moet binnen de twee meest recente versies of N-2 blijven. Het is essentieel om een upgrade uit te voeren naar de nieuwste versie van Kubernetes, omdat er regelmatig nieuwe versies worden uitgebracht.

De meeste clusters moeten in-place AKS-versie-updates kunnen uitvoeren met voldoende voorzichtigheid en striktheid. Het risico van het uitvoeren van een in-place AKS-versie-upgrade kan meestal worden beperkt door voldoende preproductietests, quotavalidatie en budgetconfiguratie voor podonderbreking. Maar elke in-place upgrade kan leiden tot onverwacht gedrag. Als in-place upgrades te riskant worden geacht voor uw workload, raden we u aan een blauwgroene implementatie van AKS-clusters te gebruiken in plaats van de resterende aanbevelingen te volgen.

U wordt aangeraden de functie voor automatische upgrade van het cluster te vermijden wanneer u voor het eerst een Kubernetes-cluster implementeert. Gebruik een handmatige benadering, die u de tijd biedt om een nieuwe AKS-clusterversie te testen in uw preproductieomgevingen voordat de updates uw productieomgeving raken. Deze aanpak bereikt ook het grootste niveau van voorspelbaarheid en controle. Maar u moet ijverig zijn om te controleren op nieuwe updates voor het Kubernetes-platform en snel nieuwe versies te gebruiken wanneer ze worden uitgebracht. Het is beter om een 'up-to-date' mindset over te nemen op een langetermijnondersteuningsbenadering .

U kunt meldingen ontvangen wanneer er een nieuwe AKS-versie beschikbaar is voor uw cluster met behulp van 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 Microsoft.ContainerService.NewKubernetesVersionAvailable gebeurtenis vanuit uw gebeurtenisstroommeldingsoplossing. Bekijk de opmerkingen bij de AKS-release voor specifieke compatibiliteitsproblemen, gedragswijzigingen of functieafbrekingen.

U kunt uiteindelijk het vertrouwenspunt bereiken met Kubernetes-releases, AKS-releases, uw cluster, de onderdelen op clusterniveau en de workload, om de functie voor automatische upgrade te verkennen. Voor productiesystemen zou het zeldzaam zijn om ooit verder patchte gaan. Wanneer u uw AKS-versie automatisch bijwerken, controleert u ook de AKS-versie-instelling van uw infrastructuur als de AKS-versie-instelling (IaC) van uw cluster, zodat deze niet worden gesynchroniseerd. Configureer uw geplande onderhoudsvenster ter ondersteuning van de automatische upgradebewerking.

Controleren van beveiliging

Bewaak uw containerinfrastructuur voor zowel actieve bedreigingen als potentiële beveiligingsrisico's. Hier volgen enkele resources:

• Microsoft Defender for Containers om Defender voor Cloud aanbevelingen voor uw containerinstallatiekopieën te identificeren en op te heffen.
• Defender for Containers scant regelmatig uw containerinstallatiekopieën op beveiligingsproblemen.
• Defender for Containers genereert ook realtime beveiligingswaarschuwingen voor verdachte activiteiten.
• AKS-beveiligingsconcepten voor toepassingen en clusters bevatten informatie over hoe containerbeveiliging de volledige end-to-end-pijplijn beveiligt van build naar de toepassingsworkloads die in AKS worden uitgevoerd.

Cluster- en workloadbewerkingen

Zie de ontwerpprincipes van Operational Excellence voor overwegingen met betrekking tot cluster- en workloadbewerkingen (DevOps).

Cluster bootstrapping

Nadat u de inrichting hebt uitgevoerd, hebt u een werkcluster, maar mogelijk hebt u nog enkele vereiste stappen voordat u workloads kunt implementeren. Het proces voor het voorbereiden van uw cluster wordt bootstrapping genoemd. Bootstrapping kan bestaan uit het implementeren van vereiste installatiekopieën op clusterknooppunten, het maken van naamruimten en het uitvoeren van andere taken die voldoen aan de vereisten van de use case van uw organisatie.

Om de kloof tussen een ingericht cluster en een correct geconfigureerde cluster te verkleinen, moeten clusteroperators nadenken over hoe hun unieke bootstrappingproces eruitziet. Ze moeten de relevante activa vooraf voorbereiden. Als bijvoorbeeld Kured op elk knooppunt wordt uitgevoerd voordat toepassingsworkloads worden geïmplementeerd, moet de clusteroperator controleren of een Container Registry-exemplaar dat de doelinstallatiekopieën bevat, al bestaat voordat het cluster wordt ingericht.

U kunt het bootstrappingproces configureren met behulp van een van de volgende methoden:

• GitOps Flux v2-clusterextensie
• Pipelines
• Zelfconfiguratie met Flux of Argo CD, bijvoorbeeld

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. Het stelt de omgeving in met een solide beheerbasis in de toekomst en biedt ook ondersteuning voor het opnemen van bootstrapping als resourcesjablonen om te worden afgestemd op uw IaC-strategie.

Ten slotte is kubectl bij het gebruik van de extensie niet vereist voor een deel van het bootstrappingproces. U kunt kubectl-gebaseerde toegang reserveren voor situaties met noodonderbrekingen. Tussen sjablonen voor Azure-resourcedefinities en het opstarten van manifesten via de GitOps-extensie kunt u alle normale configuratieactiviteiten uitvoeren zonder kubectl te hoeven gebruiken.

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 spokes en ook subnetten binnen die netwerken. Een spoke heeft bijvoorbeeld afzonderlijke subnetten voor systeem- en gebruikersknooppuntgroepen en toegangsbeheerbronnen. Implementeer een subnet voor Azure Firewall in de hub.

Een andere taak is het integreren van de basisworkload met Microsoft Entra-id.

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. U kunt Bicep-, Azure Resource Manager-sjablonen (ARM-sjablonen) of Terraform gebruiken.

Zorg ervoor dat u resources inricht volgens het beleid dat van toepassing is. Wanneer u bijvoorbeeld VM-grootten selecteert, blijft u binnen de kostenbeperkingen en opties voor beschikbaarheidszones om te voldoen aan de vereisten van uw toepassing. U kunt Azure Policy ook gebruiken om het beleid van uw organisatie af te dwingen voor deze beslissingen.

Als u een reeks opdrachten moet schrijven, gebruikt u Azure CLI. Deze opdrachten hebben betrekking op een reeks Azure-services en u kunt ze automatiseren via scripting. Windows en Linux ondersteunen Azure CLI. Een andere platformoverschrijdende optie is Azure PowerShell. Uw keuze is afhankelijk van uw favoriete vaardighedenset.

Sla uw scripts en sjabloonbestanden op en versie deze in uw broncodebeheersysteem.

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 geautomatiseerde pijplijn voor continue levering bevatten. Implementeer automatisch wijzigingen in de containerinstallatiekopieën van uw workload in het cluster.

In deze architectuur beheert GitHub Actions de werkstroom en implementatie. Andere populaire opties zijn Azure DevOps 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 voor die versie voordat u implementeert in productie, 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 handig omdat 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 de 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 een 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.

U kunt vertakkingsbeleid op uw Git-server hebben, zodat meerdere ontwikkelaars vervolgens wijzigingen kunnen goedkeuren via een pull-aanvraag voordat de wijziging wordt toegepast op productie.

Hoewel u GitOps en Flux handmatig kunt configureren, raden we u aan om de GitOps met flux v2-clusterextensie voor AKS te gebruiken.

Strategieën voor workload- en clusterimplementatie

Implementeer eventuele wijzigingen, zoals architectuuronderdelen, workload en clusterconfiguratie in ten minste één preproductie-AKS-cluster. Hierdoor wordt de wijziging gesimuleerd en kunnen problemen worden geïdentificeerd voordat ze in productie worden geïmplementeerd.

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

Geavanceerde implementatietechnieken, zoals blauwgroene implementatie, A/B-tests en canary-releases, vereisen extra processen en mogelijk extra hulpprogramma's. Flagger is een populaire opensource-oplossing voor het oplossen van geavanceerde implementatiescenario's.

Kostenbeheer

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

Overweeg om AKS-kostenanalyse te gebruiken voor gedetailleerde kostentoewijzing van clusterinfrastructuur door Kubernetes-specifieke constructies.

Zie Windows-containers op AKS voor meer informatie over overwegingen voor kostenbeheer die specifiek zijn voor Windows.

inrichten

• Inzicht in waar uw kosten vandaan komen. Er zijn minimale kosten verbonden aan AKS in implementatie, beheer en bewerkingen van het Kubernetes-cluster zelf. Wat van invloed is op de kosten zijn de VM-exemplaren, opslag, logboekgegevens en netwerkresources die door het cluster worden gebruikt. Overweeg goedkopere VM's te kiezen voor systeemknooppuntgroepen. De DS2_v2 reeks 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.

• Voeg een SLA voor uptime toe voor productieworkloads. Maar er zijn wel besparingen voor clusters die zijn ontworpen voor dev/test- of experimentele workloads waarbij beschikbaarheid niet hoeft 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.

• Richt een cluster in met het minimale aantal knooppunten en schakel de automatische schaalaanpassing van clusters in om de grootte te bewaken en te bepalen in plaats van te beginnen met een te groot cluster om te voldoen aan de schaalbehoeften.

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

• Houd er rekening mee dat wanneer u diagnostische gegevens inschakelt voor het cluster, de kosten kunnen verhogen.

• Voer één jaar of drie jaar azure Reserved Virtual Machine Instances in om de knooppuntkosten te verlagen als uw workload gedurende een lange periode moet bestaan. Zie Kosten besparen met azure Reserved Virtual Machine Instances voor meer informatie.

• Gebruik tags wanneer u knooppuntgroepen maakt. Tags helpen bij het maken van aangepaste rapporten om gemaakte kosten bij te houden. U kunt tags gebruiken om de totale 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.

• Verwacht extra bandbreedtekosten als uw workload meerdere regio's is en u gegevens tussen regio's repliceert. Zie bandbreedteprijzen voor meer informatie.

• Maak budgetten om binnen de kostenbeperkingen te blijven die uw organisatie identificeert. U kunt budgetten maken via Microsoft 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

U kunt het hele cluster en de kosten van berekening, opslag, bandbreedte, logboeken en de firewall bewaken. Azure biedt opties voor het bewaken en analyseren van kosten:

• Azure Advisor

• Microsoft Cost Management

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

Als u gegevensgestuurde beslissingen wilt nemen, kunt u bepalen welke resource op een gedetailleerd niveau de meeste kosten in rekening brengen. U hebt ook een goed beeld van de meters die het resourcegebruik berekenen. Door bijvoorbeeld metrische gegevens te analyseren, kunt u bepalen of het platform te veel 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 ondergeuste knooppunten in de knooppuntgroep te detecteren en te verwijderen.

  Belangrijk

  Het agressief wijzigen van instellingen voor automatische schaalaanpassing van clusters, zoals minimum- en maximumknooppuntinstellingen voor een knooppuntgroep, om invloed te hebben op de kosten kunnen contraproductieve resultaten opleveren. Als de instelling bijvoorbeeld scale-down-unneeded-time is ingesteld op 10 minuten en de minimum- en maximuminstellingen voor knooppunten om de vijf minuten worden gewijzigd op basis van de kenmerken van de werkbelasting, wordt het aantal knooppunten nooit verminderd. Dit komt doordat de berekening van de onnodige tijd voor elk knooppunt opnieuw wordt ingesteld omdat de instellingen voor automatische schaalaanpassing van clusters worden vernieuwd.

• 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 zijn die gepland zijn om in uw cluster te worden uitgevoerd, kunt u de AKS-functie starten/stoppen gebruiken om alle berekeningen af te sluiten, waaronder uw systeemknooppuntgroep en het AKS-besturingsvlak.

Zie AKS-prijzen voor andere kostengerelateerde informatie.

Volgende stappen

• Geavanceerde AKS-microservicesarchitectuur
• AKS-basislijn voor clusters met meerdere regio's
• Gereguleerd AKS-cluster voor PCI-DSS 3.2.1
• Referentiearchitectuur voor Windows-containers in AKS-basislijn

Verwante resources

• AKS-roadmap op GitHub
• Inleiding tot Kubernetes
• Toepassingen ontwikkelen en implementeren in Kubernetes
• Goed ontworpen frameworkbeoordeling voor AKS
• AKS-landingszoneversneller
• AKS day-2 operations guide
• Microservicesarchitectuur op AKS
• Azure Firewall gebruiken om een AKS-cluster te beveiligen
• Git-bewerkingen voor AKS
• Gegevensstreaming met AKS