Basislijnarchitectuur voor een Azure Kubernetes Service-cluster (AKS)

In deze referentiearchitectuur bouwen we een basislijninfrastructuur die een AKS-cluster (Azure Kubernetes Service) implementeert. Dit artikel bevat aanbevelingen voor netwerken, beveiliging, identiteit, beheer en bewaking van het cluster op basis van de bedrijfsvereisten van een organisatie.

 GitHub: Azure Kubernetes Service (AKS) Secure Baseline Reference Implementation. U kunt deze gebruiken als uitgangspunt en deze configureren op basis van uw behoeften.

Netwerkconfiguratie

Netwerktopologie
De IP-adressen plannen
Resources voor ingress implementeren

Cluster compute

Compute voor het basiscluster
Naslag voor containerafbeeldingen
Beleidsbeheer

Identiteitsbeheer

Azure AD integreren voor het cluster
Azure AD integreren voor de workload

Gegevensstroom beveiligen

De netwerkstroom beveiligen
Geheimbeheer toevoegen

Bedrijfscontinuïteit

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

Operations

CI/CD-pijplijnen voor clusters en workloads
Status en metrische gegevens van cluster
Kostenbeheer en rapportage

Netwerktopologie

Deze architectuur maakt gebruik van een hub-spoke-netwerktopologie. 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. Het biedt een manier om governance toe te passen en de radius van de organisatie te bepalen. Het ondersteunt ook het concept van landingszone met scheiding van taken.

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

• Organisaties werken vaak met regionale hub-spoke-topologies. Hub-spoke-netwerkologieën kunnen in de toekomst worden uitgebreid en bieden isolatie van workloads.

• Alle webtoepassingen moeten een WAF-service (Web Application Firewall) nodig hebben om HTTP-verkeersstromen te kunnen beheren.

• Een natuurlijke keuze voor workloads die meerdere abonnementen bespannen.

• Dit maakt de architectuur uitvouwbaar. 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 tussen netwerken.

Hub

Het virtuele hubnetwerk is het centrale punt van connectiviteit en waarneembaarheid. Binnen het netwerk worden drie subnetten geïmplementeerd.

Subnet voor het hosten van Azure Firewall

Azure Firewall is een firewall als een service. Het firewall-exemplaar beveiligt uitgaand netwerkverkeer. Zonder deze beveiligingslaag kan de stroom communiceren met een kwaadwillende service van derden die gevoelige bedrijfsgegevens kan exfiltreren.

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 het 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 drie subnetten:

Subnet voor het hosten van Azure Application Gateway

Azure Application Gateway is een webverkeer dat load balancer op laag 7. De referentie-implementatie maakt gebruik van de Application Gateway v2 SKU waarmee Web Application Firewall (WAF). WAF beveiligt binnenkomend verkeer tegen veelvoorkomende aanvallen op internetverkeer. Het exemplaar heeft een openbare front-end-IP-configuratie die gebruikersaanvragen ontvangt. Voor een Application Gateway is een toegewezen subnet vereist.

Subnet voor het hosten van de ingress-resources

Traefik is de controller voor ingress die voldoet aan de Kubernetes-ingress-resources om verkeer te routeer en te distribueren. De interne Load Balancers van Azure bestaan in dit subnet.

Subnet voor het hosten van de clusterknooppunten

AKS onderhoudt twee afzonderlijke groepen knooppunten (of knooppuntgroepen). De systeemknooppuntgroep host pods die kernclusterservices uitvoeren. De gebruikers-knooppuntgroep voert de Contoso-workload en de controller voor uitgaand verkeer uit om binnenkomende communicatie met de werkbelasting mogelijk te maken. De workload is een eenvoudige ASP.NET toepassing.

Hub-spoke-netwerktopologie in Azure voor meer informatie.

De IP-adressen plannen

De adresruimte van het virtuele netwerk moet groot genoeg zijn voor alle subnetten. 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 zijn bijgewerkt met beveiligingsfuncties en andere systeempatches. Tijdens een upgradeproces maakt AKS een knooppunt dat tijdelijk als host voor de pods wordt gebruikt, terwijl het upgrade-knooppunt wordt afgesloten en leeg wordt gemaakt. Aan dat tijdelijke knooppunt wordt een IP-adres uit het clustersubnet toegewezen.

  Voor pods hebt u mogelijk extra 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 replace-strategie gebruikt, worden pods verwijderd en worden de nieuwe gemaakt. Adressen die aan de oude pods zijn gekoppeld, worden dus opnieuw gebruikt.

• Schaalbaarheid

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

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

• Azure Private Link adressen

  Factor in de adressen die vereist zijn voor communicatie met andere Azure-services via Private Link. In deze architectuur zijn 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, moet u rekening houden met deze adressen.

Deze architectuur is ontworpen voor één workload. Voor meerdere workloads wilt u mogelijk de gebruikers-knooppuntgroepen van elkaar en van de systeem-knooppuntgroep isoleren. Deze keuze kan leiden tot meer subnetten die kleiner zijn. De resource voor ingress is mogelijk ook complexer. Mogelijk hebt u meerdere ingresscontrollers nodig waarvoor extra adressen nodig zijn.

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

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

Naslag voor containerafbeeldingen

Naast de werkbelasting kan het cluster verschillende andere afbeeldingen bevatten, zoals de controller voor ingressen. Sommige van deze afbeeldingen bevinden zich mogelijk in openbare registers. Houd rekening met deze punten bij het binnenhalen van deze punten in uw cluster.

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

• Als u een openbare afbeelding gebruikt, kunt u deze importeren in het containerregister dat is afgestemd op uw SLO. Anders is de afbeelding mogelijk onderhevig aan onverwachte beschikbaarheidsproblemen. Deze problemen kunnen operationele problemen veroorzaken als de afbeelding niet beschikbaar is wanneer u deze nodig hebt. Hier zijn 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 afbeeldingen om activiteiten te bewaken en verbindingsproblemen te tri triage.
  • Profiteer van geïntegreerde containerscans en naleving van afbeeldingen.

  Een optie is Azure Container Registry (ACR).

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

Rekenkracht configureren voor het basiscluster

In AKS wordt elke knooppuntgroep aan een virtuele-machineschaalset toe te kennen. Knooppunten zijn VM's in elke knooppuntgroep. Overweeg het gebruik van een kleinere VM-grootte voor de systeem-knooppuntgroep om de kosten te minimaliseren. Deze referentie-implementatie implementeert de systeemknooppuntgroep 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 zijn enkele overwegingen voor de gebruikers-knooppuntgroep:

• Kies grotere knooppuntgrootten om het maximum aantal pods op een knooppunt in te pakken. 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 knooppunt 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 gekozen DS4_v2 voor de productieworkload. Om de kosten te verlagen, kunt u de grootte DS3_v2, wat de minimale aanbeveling is.

• Wanneer u capaciteit voor uw cluster plant, gaat u ervan uit dat uw workload maximaal 80% van elk knooppunt kan verbruiken; de resterende 20% is gereserveerd voor AKS-services.

• Stel het maximum aantal pods per knooppunt in op basis van uw capaciteitsplanning. Als u probeert een basislijn voor capaciteit vast te stellen, begint u met een waarde van 30. Pas deze waarde aan op basis van de vereisten van de workload, de knooppuntgrootte en uw IP-beperkingen.

De Azure Active Directory voor het cluster integreren

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

• Inside-out toegang. AKS-toegang tot Azure-onderdelen, zoals netwerkinfrastructuur, Azure Container Registry en Azure Key Vault. Alleen de resources machtigen die het cluster toegang heeft.
• Externe toegang. Identiteiten toegang geven tot het Kubernetes-cluster. Alleen de externe entiteiten machtigen die toegang hebben tot de Kubernetes API-server en Azure Resource Manager.

AKS-toegang tot Azure

Er zijn twee manieren om toegang van AKS tot Azure te beheren via Azure Active Directory (Azure AD): service-principals of beheerde identiteiten voor Azure-resources.

Van de twee manieren wordt beheerde identiteiten aanbevolen. Met service-principals bent u verantwoordelijk voor het handmatig of programmatisch beheren en roteren van geheimen. Met beheerde identiteiten beheert en voert Azure AD de verificatie en tijdige roulatie van geheimen voor u uit.

Het is raadzaam dat beheerde identiteiten zijn ingeschakeld, zodat het cluster kan communiceren met externe Azure-resources via Azure AD. U kunt deze instelling alleen inschakelen tijdens het maken van het cluster. Zelfs als Azure AD niet onmiddellijk wordt gebruikt, kunt u deze later opnemen.

Als voorbeeld voor een inside-out geval gaan we het gebruik van beheerde identiteiten bestuderen wanneer het cluster afbeeldingen uit een containerregister moet halen. Voor deze actie moet het cluster de referenties van het register op halen. Eén manier is om die informatie op te slaan in de vorm van het Kubernetes Secrets-object en te gebruiken om imagePullSecrets het geheim op te halen. Deze aanpak wordt niet aanbevolen vanwege de complexiteit van de beveiliging. U hebt niet alleen vooraf kennis van het geheim nodig, maar ook de openbaarmaking van dat geheim via de DevOps-pijplijn. Een andere reden is de operationele overhead van het beheren van de roulatie van het geheim. Verleen in plaats acrPull daarvan toegang tot de beheerde identiteit van het cluster aan uw register. Deze aanpak lost deze problemen op.

In deze architectuur heeft het cluster toegang tot Azure-resources die worden beveiligd door Azure AD en worden bewerkingen uitgevoerd 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 Azure AD en krijgt vervolgens toegang op basis van de toegewezen rollen. Hier zijn enkele voorbeelden van deze referentie-implementatie waarbij ingebouwde Azure-rollen zijn toegewezen aan het cluster:

• Netwerkbijdrager. De mogelijkheid van het cluster om het virtuele spoke-netwerk te bepalen. Met deze roltoewijzing kan een door het AKS-clustersysteem toegewezen identiteit werken met het toegewezen subnet voor de interne toegangscontrollerservices.
• Monitoring Metrics Publisher. De mogelijkheid van het cluster om metrische gegevens naar de Azure Monitor.
• AcrPull. De mogelijkheid van het cluster om afbeeldingen op te halen uit de opgegeven Azure-containerregisters.

Clustertoegang

Azure AD-integratie vereenvoudigt ook de beveiliging voor externe toegang. Stel dat een gebruiker kubectl wil gebruiken. Als eerste stap verzendt de opdracht az aks get-credentials om de referenties van het cluster op te halen. Azure AD verifieert de identiteit van de gebruiker aan de hand van de Azure-rollen die clusterreferenties mogen krijgen. Zie Beschikbare clusterrollenmachtigingen voor meer informatie.

Met AKS kunt u kubernetes-toegang op Azure Active Directory twee manieren. De eerste is het gebruik Azure Active Directory als een identiteitsprovider die is geïntegreerd met het systeemeigen Kubernetes RBAC-systeem. De andere maakt gebruik van native Azure RBAC voor het beheer van clustertoegang. Beide worden hieronder beschreven.

Kubernetes RBAC koppelen aan Azure Active Directory

Kubernetes ondersteunt op rollen gebaseerd toegangsbeheer (RBAC) via:

• Een set machtigingen. Gedefinieerd door een Role - of ClusterRole -object voor clusterbrede machtigingen.

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

Kubernetes heeft een aantal ingebouwde rollen, zoals clusterbeheerder, bewerken, weergeven, en meer. Verbind deze rollen met Azure Active Directory gebruikers en groepen om de toegang te beheren met de bedrijfsdirectory. Zie Kubernetes RBACgebruiken met Azure AD-integratie voor meer informatie.

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

Azure RBAC gebruiken voor Kubernetes-autorisatie

In plaats van Kubernetes RBAC te gebruiken met geïntegreerde AAD-verificatie, kunt u ook Azure RBAC en roltoewijzingen gebruiken om clustertoegang af te dwingen. Het voordeel van het gebruik van Azure RBAC is dat u geen systeemeigen Kubernetes RBAC-rollen en -rolbindingen hoeft te configureren.

Zie Azure-rollen voor meer informatie.

Lokale accounts

AKS ondersteunt native Kubernetes-gebruikersverificatie. Gebruikerstoegang tot clusters met behulp van deze methode wordt niet aanbevolen. Het is gebaseerd op certificaten en wordt extern uitgevoerd op uw primaire id-provider; gecentraliseerd gebruikerstoegangsbeheer en beheer moeilijk maken. Beheer altijd de toegang tot uw cluster via Azure Active Directory en configureer uw cluster om de toegang tot het lokale account expliciet uit te schakelen.

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

De Azure Active Directory voor de workload integreren

Net als bij azure beheerde identiteiten voor het hele cluster, kunt u beheerde identiteiten toewijzen op podniveau. Met een door pods beheerde identiteit heeft de gehoste workload toegang tot resources via Azure Active Directory. De workload slaat bijvoorbeeld bestanden op in de Azure Storage. Wanneer deze bestanden moeten worden gebruikt, verifieert de pod zichzelf aan de resource.

In deze referentie-implementatie worden beheerde pod-identiteiten gefaciliilieerd via aad-pod-identity.

Resources voor ingress implementeren

Kubernetes-resources voor inkomend verkeer routeeren en distribueren binnenkomend verkeer naar het cluster. Er zijn twee delen van de resources voor ingress:

• Interne load balancer. Beheerd door AKS. Dit load balancer de controller voor binnengangen via een privé statisch IP-adres. Het fungeert als een enkel contactpunt dat inkomende stromen ontvangt.

  In deze architectuur wordt Azure Load Balancer gebruikt. Het wordt buiten het cluster geplaatst in een subnet dat is toegewezen voor resources voor ingressen. Het ontvangt verkeer van Azure Application Gateway en die communicatie gaat via TLS. Zie Verkeersstroom voor uitgaand verkeer voor informatie over TLS-versleuteling voor inkomende verkeer.

• Controller voor ingress. 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 doorsturen naar de workloadpods via HTTP.

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

• Als onderdeel van uw ontwerpbeslissingen kiest u een bereik waarin de toegangscontroller 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 spreiden en voor bedrijfscontinuïteit te zorgen als een knooppunt uit bedrijf wordt geplaatst. Gebruik podAntiAffinity voor dit doel.

• Beperk pods om alleen te worden gepland in de gebruikers-knooppuntgroep met behulp van nodeSelectors . Met deze instelling worden workloads en systeempods geïsoleerd.

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

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

• Overweeg de toegang van de toegangscontroller 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 heeft Traefik bijvoorbeeld machtigingen gekregen om services en eindpunten te bekijken, op te halen en weer te geven met behulp van regels in het Kubernetes-object. ClusterRole

Routerinstellingen

De controller voor toegangsverkeer maakt gebruik van routes om te bepalen waar verkeer moet worden verzendt. Routes geven de bronpoort op waarop het verkeer wordt ontvangen en informatie over de doelpoorten en -protocollen.

Hier is een voorbeeld van deze architectuur:

Traefik gebruikt de Kubernetes-provider om routes te configureren. De annotations , en geven aan dat routes worden bediend via tls entrypoints HTTPS. De middlewares geeft aan dat alleen verkeer van het Azure Application Gateway subnet is toegestaan. De antwoorden gebruiken gzip-codering als de client akkoord gaat. Omdat Traefik TLS-beëindiging doet, vindt communicatie met de back-endservices via HTTP gebruik.

apiVersion:networking.k8s.io/v1beta1
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: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

De netwerkstroom beveiligen

In deze context kan de netwerkstroom worden gecategoriseerd als:

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

• Egress 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 controller voor binnenverkeer en de werkbelasting. Als uw workload bestaat uit meerdere toepassingen die in het cluster zijn geïmplementeerd, valt de communicatie tussen deze toepassingen in deze categorie.

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

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

Verkeersstroom voor binnenverkeer

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

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

2. Application Gateway een geïntegreerde Web Application Firewall (WAF) en onderhandelt over de TLS-handshake voor bicycle.contoso.com, zodat alleen beveiligde coderingen mogelijk zijn. 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 gebruikt 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 meer informatie over deze functie.

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

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

U kunt end-to-end TLS-verkeer bij elke hop naar de workloadpod implementeren. 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 beheervlak-RBAC en volwassen softwareontwikkelingslevenscyclusprocedures, is het voldoende om TLS te versleutelen tot de controller voor ingress en te beveiligen met Web Application Firewall (WAF). Dit minimaliseert de overhead in workloadbeheer en de impact op de netwerkprestaties. Uw workload- en nalevingsvereisten bepalen waar u TLS-beëindiging moet uitvoeren.

Egress verkeersstroom

Voor zero-trust control en de mogelijkheid om verkeer te inspecteren, loopt al het verkeer van het cluster via Azure Firewall. 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 toegangsverkeer wordt 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 uitzondering op het zero-trust-besturingselement is wanneer het cluster moet communiceren met andere Azure-resources. Het cluster moet bijvoorbeeld een bijgewerkte afbeelding uit het containerregister halen. De aanbevolen aanpak is het gebruik van Azure Private Link. Het voordeel is dat specifieke subnetten de service rechtstreeks bereiken. Bovendien wordt verkeer tussen het cluster en de service niet blootgesteld aan openbaar internet. 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 SKU's Private Link. In die gevallen kunt u overwegen om een service-eindpunt in te stellen op het subnet 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 via het statische IP-adres van de firewall gaat, kan dat adres worden toegevoegd aan de IP-allowlist van de service. Een nadeel is dat Azure Firewall extra regels nodig hebben om ervoor te zorgen dat alleen verkeer van een specifiek subnet is toegestaan.

Pod-naar-pod-verkeer

Standaard kan een pod verkeer van een andere pod in het cluster accepteren. Kubernetes NetworkPolicy wordt gebruikt om netwerkverkeer tussen pods te beperken. Pas beleidsregels op een verstandige manier toe, anders is er mogelijk een situatie waarin een kritieke netwerkstroom wordt geblokkeerd. Sta waar nodig alleen specifieke communicatiepaden toe, zoals verkeer tussen de controller voor toegangsverkeer en de werkbelasting. Zie Netwerkbeleid voor meer informatie.

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

Zie Verschillen tussen Azure-netwerkbeleid en Policy-beleidsregels 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 op het cluster willen uitvoeren, 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-adresbereiken naar de API-server toe te staan.

Zie Define API server authorized IP ranges (Geautoriseerde IP-adresbereiken voor API-server definiëren) voor meer informatie.

Geheimbeheer toevoegen

Sla geheimen op in een beheerd sleutelopslag, zoals Azure Key Vault. Het voordeel is dat het beheerde winkel roulatie van geheimen afhandelt, sterke versleuteling biedt, een toegangscontrolelogboek biedt en kerngeheimen buiten de implementatiepijplijn houdt.

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 Verkeersstroom voor Azure Application Gateway toegang tot TLS-certificaten voor de toegangsstroom voor toegang tot het toegangsverkeer.

Toegang tot clustergeheimen

U moet door pods beheerde identiteiten gebruiken om een pod toegang te geven tot geheimen uit een specifieke store.

Gebruik het stuurprogramma Secrets Store CSI om het ophalen te vergemakkelijken. Wanneer de pod een geheim nodig heeft, maakt het stuurprogramma verbinding met het opgegeven opslagcluster, haalt het geheim op een volume op en koppelt het dat volume in het cluster. De pod kan vervolgens het geheim van het volumebestandssysteem op halen.

Het CSI-stuurprogramma heeft veel providers ter ondersteuning van verschillende beheerde winkels. In deze implementatie hebben we de Azure Key Vault met Secrets Store CSI-stuurprogramma gekozen om het TLS-certificaat op te halen uit Azure Key Vault en te laden in de pod met de controller voor het binnenhalen. Dit wordt gedaan tijdens het maken van pods en het volume slaat zowel de 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 deze buiten het cluster op te slaan. Richtlijnen voor de workloadtoestand vallen buiten het bereik van dit artikel.

Zie Voor meer informatie over opslagopties Storage opties voor toepassingen in Azure Kubernetes Service (AKS).

Beleidsbeheer

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

Bij het instellen van beleidsregels moet u deze toepassen op basis van de vereisten van de workload. Houd rekening met de volgende factoren:

• Wilt u een verzameling beleidsregels instellen (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. Het is raadzaam om een initiatief te selecteren en aanvullende beleidsregels te kiezen voor het cluster en de resources (ACR, Application Gateway, Key Vault en andere) die met het cluster communiceren, op de manier die uw organisatie nodig heeft.

• Wilt u de actie controleren of weigeren? In de controlemodus is de actie toegestaan, maar deze wordt gemarkeerd als Niet-compatibel. Zorg dat processen regelmatig niet-compatibele staten controleren en de nodige actie 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 om de workload te laten functioneren.

• Hebt u gebieden in uw workload die niet standaard compatibel moeten zijn? Azure Policy beschikt over de mogelijkheid om Kubernetes-naamruimten op te geven die zijn uitgesloten van beleidsuitding. 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 onder het ingebouwde beleid vallen? In deze zeldzame gevallen maakt u een aangepaste Azure Policy die uw aangepaste OPA Gatekeeper-beleid past. Pas beleid niet rechtstreeks op het cluster toe.

• Hebt u vereisten voor de hele organisatie? Als dat het zo is, voegt u dit beleid toe op het niveau van de beheergroep. Uw cluster moet ook een eigen workload-specifiek beleid toewijzen, zelfs als de organisatie algemene beleidsregels heeft.

• Azure-beleidsregels worden toegewezen aan specifieke scopes. Zorg ervoor dat het productiebeleid ook wordt gevalideerd voor uw preproductieomgeving. Anders kan het zijn dat u tijdens de implementatie in uw productieomgeving onverwachte extra beperkingen tegen komt die niet in pre-productie zijn meegenomen.

In deze referentie-implementatie Azure Policy ingeschakeld wanneer het AKS-cluster wordt gemaakt en wordt het beperkende initiatief toegewezen in de controlemodus 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 om ervoor te zorgen dat de afbeeldingen alleen uit de geïmplementeerde ACR worden gehaald. Overweeg 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 naamruimte, evenals de logboeken voor de pods en in de gatekeeper-system azure-policy azure-policy-webhook kube-system naamruimte.

Schaalbaarheid van knooppunt en pod

Met een toenemende vraag kan Kubernetes worden opgeschaald door meer pods toe te voegen aan bestaande knooppunten, via horizontale automatische schaalvergroting van pods (HPA). Wanneer extra pods niet meer kunnen worden gepland, moet het aantal knooppunten worden verhoogd via automatische schalen van AKS-clusters. Een volledige schaaloplossing moet manieren hebben om zowel podreplica's als het aantal knooppunt in het cluster te schalen.

Er zijn twee benaderingen: automatisch schalen of handmatig schalen.

Op 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 verhogen of verlagen door de aan te passen via ReplicaSet Kubernetes-API's. Voor het schalen van clusters kunt u een melding ontvangen wanneer de Kubernetes-scheduler uitvalt. Een andere manier is om te kijken of er in de tijd pods in behandeling zijn. U kunt het aantal knooppunt aanpassen via Azure CLI of de portal.

Automatisch schalen is de benadering omdat sommige van deze handmatige mechanismen zijn ingebouwd in de automatische schaalverdeling.

Als algemene benadering begint u met prestatietests met een minimum aantal pods en knooppunten. Gebruik deze waarden om de basislijnverwachting vast te stellen. Gebruik vervolgens een combinatie van metrische prestatiegegevens en handmatig schalen om knelpunten te vinden en inzicht te krijgen in de reactie van de toepassing op schalen. Gebruik ten slotte deze gegevens om de parameters voor automatisch schalen in te stellen. Zie Performance tuning scenario: Distributed business transactions (Scenario voor het afstemmen van prestaties: gedistribueerde bedrijfstransacties)voor meer informatie over een scenario voor het afstemmen van de prestaties met behulp van AKS.

Horizontale automatische schaalaanpassing van pods

De HPA (Horizontal Pod Autoscaler) is een Kubernetes-resource die het aantal pods schaalt.

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

HPA kan worden geschaald op basis van het CPU-gebruik, geheugengebruik en aangepaste metrische gegevens. Alleen CPU-gebruik wordt meegeleverd. Met de definitie horizontalPodAutoscaler worden doelwaarden voor deze metrische gegevens opgegeven. De specificatie stelt bijvoorbeeld het CPU-doelgebruik in. Terwijl pods worden uitgevoerd, gebruikt de HPA-controller kubernetes Metrics API om het CPU-gebruik van elke pod te controleren. Deze waarde wordt vergeleken met het doelgebruik en er wordt een verhouding berekend. Vervolgens wordt de verhouding gebruikt om te bepalen of pods overbeplaatst of te kort zijn toegewezen. Het is afhankelijk van de Kubernetes-scheduler om nieuwe pods toe te wijzen aan knooppunten of pods van knooppunten te verwijderen.

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 KEDA een populaire opensource-optie. Overweeg KEDA als uw workload wordt aangestuurd door een gebeurtenisbron, zoals een berichtenwachtrij, in plaats van CPU- of geheugengebonden. KEDA ondersteunt veel gebeurtenisbronnen (of scalers). U vindt hier de lijst met ondersteunde KEDA-scalers, inclusief de Azure Monitor scaler; een handige manier om KEDA-workloads te schalen op basis van Azure Monitor metrische gegevens.

Automatische schaalverdeder voor clusters

De automatische schaalvergroting van clusters is een AKS-invoegonderdeel dat het aantal knooppunten in een knooppuntgroep schaalt. Deze moet worden toegevoegd tijdens het inrichten van het cluster. U hebt een afzonderlijke automatische schaalverdeder voor clusters nodig voor elke gebruikersknooppuntgroep.

De automatische schaalverdedering van clusters wordt geactiveerd door de Kubernetes-scheduler. Wanneer de Kubernetes-scheduler vanwege resourcebeperkingen geen planning kan maken voor een pod, wordt automatisch een nieuw knooppunt in de knooppuntgroep in de automatische schaalverdeigingsgroep geplaatst. De automatische schaalverdedering van clusters controleert daarentegen de ongebruikte capaciteit van de knooppunten. Als het knooppunt niet op een verwachte capaciteit wordt uitgevoerd, worden de pods verplaatst naar een ander knooppunt en wordt het ongebruikte knooppunt verwijderd.

Wanneer u automatische schaalset inschakelen, stelt u het maximum- en minimumaantal knooppunt in. De aanbevolen waarden zijn afhankelijk van de prestatieverwachting van de workload, hoeveel u wilt dat het cluster groeit en de gevolgen voor de kosten. Het minimale aantal is de gereserveerde capaciteit voor die knooppuntgroep. In deze referentie-implementatie is de minimumwaarde ingesteld op 2 vanwege de eenvoudige aard van de workload.

Voor de systeem-knooppuntgroep is de aanbevolen minimumwaarde 3.

Beslissingen voor bedrijfscontinuïteit

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

Clusterknooppunten

Om te voldoen aan het minimale beschikbaarheidsniveau voor workloads, zijn meerdere knooppunten in een knooppuntgroep nodig. Als een knooppunt uitgaat, 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. Begin voor de gebruikersknooppuntgroep met niet minder dan twee knooppunten. Als u een hogere beschikbaarheid nodig hebt, moet u meer knooppunten inrichten.

Isoleer uw toepassing van de systeemservices door deze in een afzonderlijke knooppuntgroep te plaatsen. 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 voor het plannen van uw workload.

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

Beschikbaarheid van pods

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

Stel podonderbrekingsbudgetten in. Met deze instelling bepaalt u hoeveel replica's in een implementatie tijdens een update- of upgradegebeurtenis kunnen uit vallen. Zie Pod-onderbrekingsbudgetten 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 toepassingsbelasting te verwerken.

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.

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

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

Deze limieten kunnen worden opgegeven in uw implementatiemanifests. Zie Podaanvragen en -limieten instellen voor meer informatie.

Beschikbaarheidszones en ondersteuning voor meerdere regio's

Als uw SLA een hogere uptime vereist, beschermt u tegen verlies in een zone. U kunt beschikbaarheidszones gebruiken als de regio deze ondersteunt. Zowel de onderdelen van het besturingsvlak als de knooppunten in de knooppuntgroepen kunnen zich vervolgens over zones verspreiden. Als een hele zone niet beschikbaar is, is een knooppunt in een andere zone binnen de regio nog steeds beschikbaar. Elke knooppuntgroep wordt aan een afzonderlijke virtuele-machineschaalset toe te kennen, waarmee knooppunt-exemplaren en schaalbaarheid worden beheert. Bewerkingen en configuratie van schaalsets worden beheerd door de AKS-service. Hier zijn enkele overwegingen bij het inschakelen van multizone:

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

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

  Ondersteuning voor meerdere zone 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, worden de onderdelen van het besturingsvlak niet gegarandeerd verdeeld over beschikbaarheidszones.

• Afhankelijke resources. Voor een volledig zonelijk voordeel moeten alle serviceafhankelijkheden ook zones ondersteunen. Als een afhankelijke service geen ondersteuning biedt voor zones, is het mogelijk dat een zonefout ertoe kan leiden dat die service uitvallen.

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

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

Meerdere regio's

Het inschakelen van beschikbaarheidszones is niet voldoende als de hele regio uitgaat. Voer meerdere AKS-clusters uit in verschillende regio's om een hogere beschikbaarheid te hebben.

• Gekoppelde regio's gebruiken. Overweeg het gebruik van een CI/CD-pijplijn 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 er slechts één regio in het paar tegelijk wordt bijgewerkt. Bepaalde DevOps-hulpprogramma's, zoals flux, kunnen de implementaties in meerdere regio's eenvoudiger maken.

• Als een Azure-resource geo-redundantie ondersteunt, geeft u de locatie op waar de redundante service de secundaire service heeft. Als u bijvoorbeeld geo-replicatie inschakelen voor Azure Container Registry worden afbeeldingen automatisch gerepliceerd naar de geselecteerde Azure-regio's en krijgt deze ook in een regio nog steeds toegang tot afbeeldingen als er een storing is opgetreden.

• Kies een verkeersrouter die verkeer kan distribueren over zones of regio's, afhankelijk van uw vereisten. Deze architectuur implementeert Azure Load Balancer omdat niet-webverkeer over zones kan worden verdeeld. Als u verkeer tussen regio's wilt distribueren, moet Azure Front Door rekening worden gehouden. Zie Een load balancer voor andere load balancer.

Herstel na noodgevallen

In het geval van een storing in de primaire regio moet u snel een nieuwe instantie in een andere regio kunnen maken. Hier volgen enkele aanbevelingen:

• Gekoppelde regio's gebruiken.

• Een niet-stateful workload kan efficiënt worden gerepliceerd. Als u de status in het cluster wilt opslaan (niet aanbevolen), moet u regelmatig een back-up maken 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 noodherstel. In deze architectuur is Azure Container Registry ingeschakeld voor geo-replicatie. Als een regio uitgaat, kunt u nog steeds afbeeldingen uit de gerepliceerde regio halen.

SLA voor kubernetes-API-server uptime

AKS kan worden gebruikt als een gratis service, maar die laag biedt geen SLA met financiële middelen. Als u die SLA wilt verkrijgen, moet u ervoor kiezen om een SLA voor uptime toe te voegen aan uw aankoop. We raden aan dat alle productieclusters deze optie gebruiken. Reserveer clusters zonder deze optie 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 afweging tussen kosten en beschikbaarheid voor het implementeren van de architectuur in 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 zullen ook toenemen omdat bandbreedtekosten worden toegepast wanneer verkeer tussen zones en regio's wordt verplaatst.

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 geforceerd failovertests uit te voeren met gesimuleerde storingen, zoals het uitvallen van een knooppunt, het omlaag brengen van alle AKS-resources in een bepaalde zone om een zonefout te simuleren of het verminderen van een externe afhankelijkheid.

Metrische gegevens bewaken en verzamelen

De functie Azure Monitor containers is het aanbevolen hulpprogramma voor bewaking en logboekregistratie, omdat u gebeurtenissen in realtime kunt bekijken. Het legt containerlogboeken vast van de pods die worden uitgevoerd en aggregeert ze voor weergave. Het verzamelt ook informatie van de API voor metrische gegevens over geheugen- en CPU-gebruik om de status van de lopende resources en workloads te bewaken. U kunt deze gebruiken om de prestaties te bewaken terwijl de pods worden geschaald. Een ander voordeel is dat u eenvoudig grafieken Azure Portal dashboards kunt configureren. Het biedt de mogelijkheid om waarschuwingen te maken die Automation-runbooks, Azure Functions activeren.

De meeste workloads die worden gehost in pods, geven metrische Prometheus-gegevens weer. Azure Monitor is in staat om metrische gegevens van Prometheus te scrapen en te visualiseren.

Er zijn enkele hulpprogramma's van derden die zijn geïntegreerd met Kubernetes. Profiteer van logboek- en metrische platformen, zoals Grafana of Datadog, als uw organisatie deze al gebruikt.

Met AKS beheert Azure enkele belangrijke Kubernetes-services. Logboeken van deze services mogen alleen worden ingeschakeld per aanvraag van de klantondersteuning. Het is echter raadzaam om deze logboekbronnen in teschakelen, omdat ze u kunnen helpen bij het oplossen van clusterproblemen:

• Logboekregistratie op de ClusterAutoscaler om waarneembaarheid te krijgen in de schaalbewerkingen. Zie Logboeken en status van automatische schaalverdedering voor clusters ophalen voor meer informatie.
• KubeControllerManager om waarneembaarheid te hebben in pod scheduler.
• KubeAuditAdmin om waarneembaarheid te hebben in activiteiten die uw cluster wijzigen.

Zelfherstel inschakelen

Controleer de status van pods door liveheids- en gereedheidstests in te stellen. Als er een pod wordt gedetecteerd die niet reageert, start Kubernetes de pod opnieuw op. De test voor de liveheid 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 om aanvragen/verkeer te ontvangen.

Beveiligingsupdates

Houd de Kubernetes-versie up-to-date met de ondersteunde N-2-versies. Een upgrade 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 Upgrade an Azure Kubernetes Service cluster (AKS)voor meer informatie.

Meldingen van gebeurtenissen die door uw cluster worden veroorzaakt, zoals de beschikbaarheid van nieuwe AKS-versies voor uw cluster, kunnen worden bereikt via het AKS-systeemonderwerp voor Azure Event Grid. De referentie-implementatie implementeert dit Event Grid systeemonderwerp, zodat u zich kunt abonneren op de gebeurtenis vanuit de meldingsoplossing Microsoft.ContainerService.NewKubernetesVersionAvailable voor de gebeurtenisstroom.

Wekelijkse updates

AKS biedt nieuwe knooppuntafbeeldingen met de nieuwste updates voor het besturingssysteem en runtime. Deze nieuwe afbeeldingen worden niet automatisch toegepast. U bent verantwoordelijk voor het bepalen hoe vaak de afbeeldingen moeten worden bijgewerkt. Het wordt aanbevolen dat u een proces hebt om de basisafbeelding van uw knooppuntgroepen wekelijks bij te upgraden. Zie voor meer informatie Azure Kubernetes Service (AKS) node image upgrade the AKS Release Notes (AKS-releasenotities).

Dagelijkse updates

Tussen upgrades van afbeeldingen downloaden en installeren AKS-knooppunten afzonderlijk patches voor het besturingssysteem en runtime. Voor een installatie moeten de knooppunt-VM's mogelijk opnieuw worden opgestart. AKS start knooppunten niet opnieuw op vanwege wachtende updates. Een proces hebben dat knooppunten controleert op de toegepaste updates waarvoor opnieuw moet worden opgestart en die knooppunten op een gecontroleerde manier opnieuw moeten worden opgestart. Een opensource-optie is Wased (Kubernetes-daemon voor opnieuw opstarten).

Als u uw knooppuntafbeeldingen synchroon houdt met de meest recente wekelijkse release, worden deze aanvragen voor incidenteel opnieuw opstarten geminimaliseerd terwijl een verbeterde beveiligingsstatus behouden blijft. Als u alleen vertrouwt op upgrades van knooppuntafbeeldingen, zorgt u voor AKS-compatibiliteit en wekelijkse beveiligingspatches. Het toepassen van dagelijkse updates lost beveiligingsproblemen sneller op, maar ze zijn niet noodzakelijkerwijs getest in AKS. Gebruik waar mogelijk de upgrade van knooppuntafbeeldingen als uw primaire strategie voor wekelijkse beveiligingspatching.

Beveiligingsbewaking

Controleer uw containerinfrastructuur op zowel actieve bedreigingen als potentiële beveiligingsrisico's:

• Schakel Azure Defender voor Kubernetes voor detectie van bedreigingen op uw Kubernetes-clusters.
• Gebruik Azure Security Center (ASC) om de beveiligingsstatus van Kubernetes te bewaken.
• Zie Beveiligingsbeveiliging in hostbesturingssysteem voor meer informatie over beveiligingsbeveiliging die wordt toegepast op hosts van virtuele AKS-machines.

Cluster- en workloadbewerkingen (DevOps)

Hier zijn enkele overwegingen. Zie de pijler Operationele uitmuntendheid voor meer informatie.

Workloadverantwoordelijkheden isoleren

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

Begin met een basisworkload die de basisonderdelen bevat en bouw erop voort. 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 gebruikers-knooppuntgroepen en toegangsbronnen. Een subnet voor Azure Firewall in de hub.

Een ander deel kan zijn om de basisworkload te integreren met Azure Active Directory.

Infrastructure as Code (IaC) gebruiken

Kies waar mogelijk een idempotente declaratieve methode boven een imperatieve benadering. In plaats van een reeks opdrachten te schrijven die configuratieopties opgeven, gebruikt u declaratieve syntaxis die de resources en hun eigenschappen beschrijft. Een optie is een Azure Resource Manager (ARM)-sjablonen, een andere optie is Terraform.

Zorg ervoor dat u resources inrichten volgens het beleid voor bestuur. Wanneer u bijvoorbeeld de juiste VM-grootten selecteert, blijft u binnen de kostenbeperkingen en beschikbaarheidszoneopties die overeenkomen met de vereisten van uw toepassing.

Als u een reeks opdrachten wilt schrijven, gebruikt u Azure CLI. Deze opdrachten hebben betrekking op een scala aan Azure-services en kunnen worden geautomatiseerd via scripting. Azure CLI wordt ondersteund op Windows en Linux. Een andere platformoverschrijdende optie is Azure PowerShell. Uw keuze is afhankelijk van de vaardighedenset van uw voorkeur.

Sla scripts en sjabloonbestanden en sjabloonbestanden op in uw broncodebeheersysteem.

WORKLOAD-CI/CD

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

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

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

Cluster-CI/CD

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 deze implementeert in productie, kunt u een GitOps-stroom overwegen. Er 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-repo. Kubernetes en AKS bieden geen ondersteuning voor deze ervaring. Een aanbevolen optie is flux. Er worden een of meer operators in het cluster gebruikt om implementaties in Kubernetes te activeren. flux doet de volgende taken:

• Bewaakt alle geconfigureerde opslagplaatsen.
• Detecteert nieuwe configuratiewijzigingen.
• Activeert implementaties.
• Werkt de gewenste configuratie voor uitvoering bij op basis van deze wijzigingen.

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

Hier ziet u een voorbeeld van de referentie-implementatie die laat zien hoe u clusterconfiguratie met GitOps en Flux automatiseert.

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

2. flux wordt samen met de workload in pod uitgevoerd. flux heeft alleen-lezentoegang tot de Git-opslagplaats om ervoor te zorgen dat flux alleen wijzigingen aan het toepassen is 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. Vertakkingsbeleid op uw Git-server hebben. Op die manier kunnen meerdere ontwikkelaars een wijziging goedkeuren voordat deze wordt toegepast op productie.

Strategieën voor workload- en clusterimplementatie

Implementeer elke wijziging (architectuuronderdelen, workload, clusterconfiguratie) in ten minste één AKS-cluster vóór de productie. Hierdoor wordt gesimuleerd dat de wijziging problemen kan veroorzaken voordat deze in productie wordt geïmplementeerd.

Voer tests/validaties uit in elke fase voordat u verder gaat met de volgende om ervoor te zorgen dat u updates op een zeer gecontroleerde manier naar de productieomgeving kunt pushen en onderbrekingen 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 Blue-green-implementatie, A/B-testsen Canary-releases,zijn extra proces- en mogelijk hulpprogramma's vereist. Flagger is een populaire opensource-oplossing voor het oplossen van uw geavanceerde implementatiescenario's.

Kostenbeheer

Gebruik de Azure-prijscalculator om de kosten te schatten voor de services die in de architectuur worden gebruikt. Andere best practices worden beschreven in de sectie Kostenoptimalisatie in Microsoft Azure Well-Architected Framework.

Inrichten

• Er zijn geen kosten verbonden aan AKS bij de implementatie, het beheer en de bewerkingen van het Kubernetes-cluster. Het belangrijkste kostendrijver is de virtuele-machine-exemplaren, opslag- en netwerkbronnen die door het cluster worden verbruikt. Overweeg goedkopere VM's te kiezen voor systeem-knooppuntgroepen. De aanbevolen SKU is DS2_v2.

• U hebt niet dezelfde configuratie voor dev/test- en productieomgevingen. Productieworkloads hebben extra vereisten voor hoge beschikbaarheid en zijn duurder. Dit is mogelijk niet nodig in de dev/test-omgeving.

• Voeg een SLA voor uptime toe voor productieworkloads. 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 overwegen om toegewezen spot-knooppuntgroepen te gebruiken die spot-VM's uitvoeren.

  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, moet u een cluster inrichten met een minimum aantal knooppunten en de automatische schaalbaarheid van clusters inschakelen om beslissingen over de schaal te bewaken en te nemen.

• Stel podaanvragen en -limieten in zodat Kubernetes knooppuntbronnen met een hogere dichtheid kan toewijzen, zodat hardware wordt gebruikt voor capaciteit.

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

• Als uw workload naar verwachting voor een lange periode bestaat, kunt u een of drie jaar gereserveerde instanties van virtuele machines uitvoeren om de knooppuntkosten te verlagen. Zie Gereserveerde VM's voor meer informatie.

• Tags gebruiken bij het maken van knooppuntgroepen. Tags zijn handig bij het maken van aangepaste rapporten om de gemaakte kosten bij te houden. Tags bieden de mogelijkheid om het totaal aan onkosten bij te houden en eventuele kosten toe te voegen aan een specifieke resource of team. Als het cluster wordt gedeeld tussen teams, kunt u ook terugboekingsrapporten per consument maken om de naar gebruik gemeten kosten voor gedeelde cloudservices te identificeren. Zie Een taint, label of tag opgeven voor een knooppuntgroep voor meer informatie.

• Gegevensoverdracht binnen beschikbaarheidszones van een regio is niet gratis. Als uw workload meerdere regio's heeft of als er overdrachten tussen factureringszones zijn, kunt u extra bandbreedtekosten verwachten. 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. Eén 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, verzamelt u samen met de rekenkosten 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 de kosten in realtime of ten minste met een regelmatige regelmaat bewaken om actie te ondernemen vóór het einde van de maand wanneer de kosten al zijn berekend. Controleer ook de maandelijkse trend gedurende een periode om binnen het budget te blijven.

Als u gegevensgestuurde beslissingen wilt nemen, moet u bepalen welke resource (granulair niveau) de meeste kosten met zich mee 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 bijvoorbeeld bepalen of het platform te groot is. U kunt de gebruiksmeters bekijken in Azure Monitor metrische gegevens.

Optimaliseren

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

• Schakel de automatische schaalverdediging van clusters in om onderbelegde 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-schaalbaarheid is vereist, kunt u overwegen om het cluster naar de juiste grootte te schalen door metrische prestatiegegevens in de tijd te analyseren.

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

Zie AKS-prijzenvoor meer informatie over kosten.

Volgende stappen

• Zie Advanced Azure Kubernetes Service (AKS)-microservicesarchitectuurvoor meer informatie over het hosten van microservices op de AKS-basislijn.
• Zie AKS-basislijn voor clusters met meerdere regio's voor het implementeren van de AKS-basislijn in meerdere regio's.
• Zie AKS-gereguleerd cluster voor PCI-DSS 3.2.1voor het implementeren van de AKS-basislijn in een PCI-DSS 3.2.1-omgeving.
• Zie het AKS-productschema. Zie Azure Kubernetes Service Roadmap op GitHub.

Verwante artikelen:

Als u een vernieuwing in Kubernetes nodig hebt, voltooit u de leertrajecten Intro to Kubernetes en Develop and deploy applications on Kubernetes (Toepassingen ontwikkelen en implementeren in Kubernetes) op Microsoft Learn.