Delen via

Azure Well-Architected Framework review - Azure Kubernetes Service (AKS)

  • Artikel

Dit artikel bevat best practices voor architectuur voor Azure Kubernetes Service (AKS). De richtlijnen zijn gebaseerd op de vijf pijlers van topprestaties van architectuur:

  • Betrouwbaarheid
  • Beveiliging
  • Kostenoptimalisatie
  • Operationele uitmuntendheid
  • Prestatie-efficiëntie

We gaan ervan uit dat u de principes voor systeemontwerp begrijpt, werkkennis hebt van Azure Kubernetes Service en goed vertrouwd bent met de functies ervan. Zie Azure Kubernetes Service voor meer informatie.

Vereisten

Het begrijpen van de goed ontworpen frameworkpijlers kan helpen bij het produceren van een hoogwaardige, stabiele en efficiënte cloudarchitectuur. U wordt aangeraden uw workload te beoordelen met behulp van de Beoordeling van het Azure Well-Architected Framework .

Voor context kunt u overwegen een referentiearchitectuur te bekijken die deze overwegingen in het ontwerp weerspiegelt. We raden u aan om te beginnen met de basislijnarchitectuur voor een AKS-cluster (Azure Kubernetes Service) en microservicesarchitectuur in Azure Kubernetes Service. Bekijk ook de AKS-landingszoneversneller, die een architectuurbenadering en referentie-implementatie biedt voor het voorbereiden van abonnementen op landingszones voor een schaalbaar AKS-cluster (Azure Kubernetes Service).

Betrouwbaarheid

In de cloud erkennen we dat er fouten optreden. In plaats van fouten helemaal te proberen te voorkomen, is het doel de effecten van een onderdeel met een storing te beperken. Gebruik de volgende informatie om mislukte exemplaren te minimaliseren.

Bij het bespreken van betrouwbaarheid met Azure Kubernetes Service is het belangrijk om onderscheid te maken tussen de betrouwbaarheid van clusters en de betrouwbaarheid van workloads. De betrouwbaarheid van clusters is een gedeelde verantwoordelijkheid tussen de clusterbeheerder en de resourceprovider, terwijl de betrouwbaarheid van de werkbelasting het domein van een ontwikkelaar is. Azure Kubernetes Service heeft overwegingen en aanbevelingen voor beide rollen.

In de onderstaande ontwerpcontrolelijst en lijst met aanbevelingen worden bijschriften gemaakt om aan te geven of elke keuze van toepassing is op clusterarchitectuur, workloadarchitectuur of beide.

Controlelijst voor ontwerp

  • Clusterarchitectuur: Gebruik beschikbaarheidszones voor uw AKS-clusters voor kritieke workloads.
  • Clusterarchitectuur: plan de IP-adresruimte om ervoor te zorgen dat uw cluster betrouwbaar kan worden geschaald, inclusief het afhandelen van failoververkeer in topologieën met meerdere clusters.
  • Clusterarchitectuur: Bekijk de aanbevolen procedures voor het bewaken van Kubernetes met Azure Monitor om de beste bewakingsstrategie voor uw workloads te bepalen.
  • Workloadarchitectuur: Zorg ervoor dat workloads zijn gebouwd ter ondersteuning van horizontale schaalaanpassing en rapportage van toepassingsgereedheid en -status.
  • Cluster- en workloadarchitecturen: Zorg ervoor dat uw workload wordt uitgevoerd op gebruikersknooppuntgroepen en kies de juiste grootte-SKU. Neem minimaal twee knooppunten op voor gebruikersknooppuntgroepen en drie knooppunten voor de systeemknooppuntgroep.
  • Clusterarchitectuur: gebruik de SLA voor AKS Uptime om te voldoen aan beschikbaarheidsdoelen voor productieworkloads.

Aanbevelingen voor AKS-configuratie

Bekijk de volgende tabel met aanbevelingen om uw AKS-configuratie voor betrouwbaarheid te optimaliseren.

Aanbeveling Voordeel
Cluster- en workloadarchitecturen: Podplanning beheren met behulp van knooppuntkiezers en affiniteit. Hiermee kan de Kubernetes-planner workloads logisch isoleren op basis van hardware in het knooppunt. In tegenstelling tot toleranties kunnen pods zonder overeenkomende knooppuntkiezer worden gepland op gelabelde knooppunten, waardoor ongebruikte resources op de knooppunten kunnen worden gebruikt, maar prioriteit krijgen aan pods die de overeenkomende knooppuntkiezer definiëren. Gebruik knooppuntaffiniteit voor meer flexibiliteit, zodat u kunt definiëren wat er gebeurt als de pod niet kan worden vergeleken met een knooppunt.
Clusterarchitectuur: Zorg voor de juiste selectie van de netwerkinvoegtoepassing op basis van netwerkvereisten en clustergrootte. Azure CNI is vereist voor specifieke scenario's, zoals Windows-knooppuntgroepen, specifieke netwerkvereisten en Kubernetes-netwerkbeleid. Raadpleeg Kubenet versus Azure CNI voor meer informatie.
Cluster- en workloadarchitecturen: gebruik de SLA voor AKS Uptime voor clusters op productieniveau. De SLA voor AKS-uptime garandeert:
- 99.95%beschikbaarheid van het Kubernetes API-servereindpunt voor AKS-clusters die gebruikmaken van Azure Beschikbaarheidszones, of
- 99.9%beschikbaarheid voor AKS-clusters die geen gebruikmaken van Azure Beschikbaarheidszones.
Cluster- en workloadarchitecturen: bekijk de aanbevolen procedures voor het bewaken van Kubernetes met Azure Monitor om de beste bewakingsstrategie voor uw workloads te bepalen. N.v.t.
Clusterarchitectuur: Gebruik beschikbaarheidszones om de tolerantie binnen een Azure-regio te maximaliseren door AKS-agentknooppunten te distribueren over fysiek afzonderlijke datacenters. Door knooppuntgroepen over meerdere zones te spreiden, blijven knooppunten in de ene knooppuntgroep actief, zelfs als een andere zone is uitgevallen. Als er colokaliteitsvereisten bestaan, kan een reguliere AKS-implementatie op basis van virtuele-machineschaalsets in één zone of nabijheidsplaatsingsgroepen worden gebruikt om latentie tussen knooppunten te minimaliseren.
Clusterarchitectuur: Gebruik een strategie voor meerdere regio's door AKS-clusters te implementeren die zijn geïmplementeerd in verschillende Azure-regio's om de beschikbaarheid te maximaliseren en bedrijfscontinuïteit te bieden. Internetgerichte workloads moeten gebruikmaken van Azure Front Door of Azure Traffic Manager om verkeer wereldwijd te routeren tussen AKS-clusters.
Cluster- en workloadarchitecturen: Definieer podresourceaanvragen en -limieten in toepassingsimplementatiemanifesten en dwing af met Azure Policy. Limieten voor container-CPU- en geheugenresources zijn nodig om uitputting van resources in uw Kubernetes-cluster te voorkomen.
Cluster- en workloadarchitecturen: behoud de systeemknooppuntgroep geïsoleerd van toepassingsworkloads. Voor systeemknooppuntgroepen is een VM-SKU van ten minste 2 vCPU's en 4 GB geheugen vereist, maar 4 vCPU's of meer wordt aanbevolen. Referentiesysteem - en gebruikersknooppuntgroepen voor gedetailleerde vereisten.
Cluster- en workloadarchitecturen: Scheid toepassingen voor toegewezen knooppuntgroepen op basis van specifieke vereisten. Toepassingen kunnen dezelfde configuratie delen en VM's met GPU, CPU of geoptimaliseerd voor geheugen, of de mogelijkheid hebben om naar nul te schalen. Vermijd een groot aantal knooppuntgroepen om extra beheeroverhead te verminderen.
Clusterarchitectuur: Gebruik een NAT-gateway voor clusters waarop workloads worden uitgevoerd die veel gelijktijdige uitgaande verbindingen maken. Om betrouwbaarheidsproblemen met Beperkingen van Azure Load Balancer met veel gelijktijdig uitgaand verkeer te voorkomen, is er een NAT-gateway ter ondersteuning van betrouwbaar uitgaand verkeer op schaal.

Zie Principes van de betrouwbaarheidspijler voor meer suggesties.

Azure Policy

Azure Kubernetes Service biedt een breed scala aan ingebouwde Azure-beleidsregels die van toepassing zijn op zowel de Azure-resource als typische Azure-beleidsregels en het gebruik van de Azure Policy-invoegtoepassing voor Kubernetes, ook binnen het cluster. Er zijn talloze belangrijke beleidsregels met betrekking tot deze pijler die hier worden samengevat. Zie ingebouwde beleidsdefinities voor Kubernetes voor een gedetailleerdere weergave.

Cluster- en workloadarchitectuur

  • Clusters hebben gereedheids- of livestatustests geconfigureerd voor uw podspecificatie.

Naast de ingebouwde Azure Policy-definities kunnen aangepaste beleidsregels worden gemaakt voor zowel de AKS-resource als voor de Azure Policy-invoegtoepassing voor Kubernetes. Hiermee kunt u extra betrouwbaarheidsbeperkingen toevoegen die u wilt afdwingen in uw cluster- en workloadarchitectuur.

Beveiliging

Beveiliging is een van de belangrijkste aspecten van een architectuur. Als u wilt verkennen hoe AKS de beveiliging van uw toepassingsworkload kan verbeteren, raden we u aan de principes van het beveiligingsontwerp te bekijken. Als uw Azure Kubernetes Service-cluster moet worden ontworpen om een gevoelige workload uit te voeren die voldoet aan de wettelijke vereisten van de PCI-DSS 3.2.1 (Payment Card Industry Data Security Standard), controleert u het gereguleerde AKS-cluster voor PCI-DSS 3.2.1.

Raadpleeg de isolatievereisten van Azure Government IL5 voor meer informatie over ondersteuning en vereisten van DoD Impact Level 5 (IL5) met AKS.

Bij het bespreken van beveiliging met Azure Kubernetes Service is het belangrijk om onderscheid te maken tussen clusterbeveiliging en workloadbeveiliging. Clusterbeveiliging is een gedeelde verantwoordelijkheid tussen de clusterbeheerder en de resourceprovider, terwijl workloadbeveiliging het domein van een ontwikkelaar is. Azure Kubernetes Service heeft overwegingen en aanbevelingen voor beide rollen.

In de onderstaande ontwerpcontrolelijst en lijst met aanbevelingen worden bijschriften gedaan om aan te geven of elke keuze van toepassing is op clusterarchitectuur, workloadarchitectuur of beide.

Controlelijst voor ontwerp

  • Clusterarchitectuur: Beheerde identiteiten gebruiken om te voorkomen dat serviceprincipes worden beheerd en gedraaid.
  • Clusterarchitectuur: Gebruik Op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes met Microsoft Entra ID voor toegang tot minimale bevoegdheden en minimaliseer het verlenen van beheerdersbevoegdheden om configuratie en toegang tot geheimen te beveiligen.
  • Clusterarchitectuur: Gebruik Microsoft Defender voor containers met Azure Sentinel om bedreigingen in uw cluster en workloads die erop worden uitgevoerd, snel te detecteren en erop te reageren.
  • Clusterarchitectuur: Implementeer een privé-AKS-cluster om ervoor te zorgen dat clusterbeheerverkeer naar uw API-server in uw privénetwerk blijft. Of gebruik de acceptatielijst van de API-server voor niet-privéclusters.
  • Workloadarchitectuur: Gebruik een Web Application Firewall om HTTP(S)-verkeer te beveiligen.
  • Workloadarchitectuur: Zorg ervoor dat uw CI/CID-pijplijn wordt beveiligd met containerbewust scannen.

Aanbevelingen

Bekijk de volgende tabel met aanbevelingen voor het optimaliseren van uw AKS-configuratie voor beveiliging.

Aanbeveling Voordeel
Clusterarchitectuur: Microsoft Entra-integratie gebruiken. Het gebruik van Microsoft Entra ID centraliseert het onderdeel identiteitsbeheer. Elke wijziging in gebruikersaccount of groepsstatus wordt automatisch bijgewerkt in toegang tot het AKS-cluster. De ontwikkelaars en toepassingseigenaren van uw Kubernetes-cluster hebben toegang nodig tot verschillende resources.
Clusterarchitectuur: verifiëren met Microsoft Entra-id voor Azure Container Registry. AKS en Microsoft Entra ID maakt verificatie met Azure Container Registry mogelijk zonder het gebruik van imagePullSecrets geheimen. Controleer Verificatie met Azure Container Registry vanuit Azure Kubernetes Service voor meer informatie.
Clusterarchitectuur: beveilig netwerkverkeer naar uw API-server met een privé-AKS-cluster. Standaard wordt netwerkverkeer tussen uw knooppuntgroepen en de API-server het Microsoft backbone-netwerk verplaatst; Met behulp van een privécluster kunt u ervoor zorgen dat netwerkverkeer naar uw API-server alleen in het privénetwerk blijft.
Clusterarchitectuur: Voor niet-privé-AKS-clusters gebruikt u geautoriseerde IP-adresbereiken van de API-server. Wanneer u openbare clusters gebruikt, kunt u nog steeds het verkeer beperken dat de API-server van uw clusters kan bereiken met behulp van de functie geautoriseerd IP-bereik. Neem bronnen op zoals de openbare IP-adressen van uw implementatiebuildagents, operations management en het uitgangspunt van knooppuntgroepen (zoals Azure Firewall).
Clusterarchitectuur: Beveilig de API-server met Microsoft Entra RBAC. Het beveiligen van de toegang tot de Kubernetes-API-server is een van de belangrijkste dingen die u kunt doen om uw cluster te beveiligen. Integreer op rollen gebaseerd toegangsbeheer (RBAC) van Kubernetes met Microsoft Entra ID om de toegang tot de API-server te beheren. Schakel lokale accounts uit om alle clustertoegang af te dwingen met behulp van op Microsoft Entra ID gebaseerde identiteiten.
Clusterarchitectuur: Azure-netwerkbeleid of Calico gebruiken. Netwerkverkeer tussen pods in een cluster beveiligen en beheren.
Clusterarchitectuur: Clusters en pods beveiligen met Azure Policy. Azure Policy kan helpen bij het toepassen van afdwinging en beveiliging op schaal op uw clusters op een gecentraliseerde, consistente manier. Het kan ook bepalen welke functies pods worden verleend en of er iets wordt uitgevoerd op basis van bedrijfsbeleid.
Clusterarchitectuur: Beveiligde containertoegang tot resources. Beperk de toegang tot acties die containers kunnen uitvoeren. Geef het minste aantal machtigingen op en vermijd het gebruik van escalatie met hoofd- of bevoegdheden.
Workloadarchitectuur: Gebruik een Web Application Firewall om HTTP(S)-verkeer te beveiligen. Als u binnenkomend verkeer wilt scannen op mogelijke aanvallen, gebruikt u een webtoepassingsfirewall zoals Azure Web Application Firewall (WAF) op Azure-toepassing Gateway of Azure Front Door.
Clusterarchitectuur: uitgaand clusterverkeer beheren. Zorg ervoor dat het uitgaande verkeer van uw cluster wordt doorgegeven via een netwerkbeveiligingspunt, zoals Azure Firewall of een HTTP-proxy.
Clusterarchitectuur: gebruik het opensource-Microsoft Entra Workload-ID- en Secrets Store CSI-stuurprogramma met Azure Key Vault. Bescherm en roteer geheimen, certificaten en verbindingsreeks s in Azure Key Vault met sterke versleuteling. Biedt een toegangscontrolelogboek en bewaart kerngeheimen buiten de implementatiepijplijn.
Clusterarchitectuur: Gebruik Microsoft Defender for Containers. Bewaak en onderhoud de beveiliging van uw clusters, containers en hun toepassingen.

Zie Principes van de beveiligingspijler voor meer suggesties.

Azure Advisor helpt azure Kubernetes-service te garanderen en te verbeteren. Er worden aanbevelingen gegeven voor een subset van de items die worden vermeld in de onderstaande beleidssectie, zoals clusters zonder RBAC geconfigureerd, ontbrekende Microsoft Defender-configuratie, onbeperkte netwerktoegang tot de API-server. Op dezelfde manier worden er workloadaanaanvelingsaanaanvelingsaanvelingsopdrachten uitgevoerd voor een aantal van de onderdelen van het podbeveiligingsinitiatief. Bekijk de aanbevelingen.

Beleidsdefinities

Azure Policy biedt verschillende ingebouwde beleidsdefinities die van toepassing zijn op zowel de Azure-resource als AKS, zoals standaardbeleidsdefinities, en het gebruik van de Azure Policy-invoegtoepassing voor Kubernetes, ook binnen het cluster. Veel van de Azure-resourcebeleidsregels zijn beschikbaar in zowel Audit/Deny, maar ook in een variant Implementeren indien niet bestaat .

Er zijn talloze belangrijke beleidsregels met betrekking tot deze pijler die hier worden samengevat. Zie ingebouwde beleidsdefinities voor Kubernetes voor een gedetailleerdere weergave.

Clusterarchitectuur

  • beleid op basis van Microsoft Defender voor Cloud
  • Verificatiemodus en configuratiebeleid (Microsoft Entra-id, RBAC, lokale verificatie uitschakelen)
  • Api Server-netwerktoegangsbeleid, inclusief privécluster

Cluster- en workloadarchitectuur

  • Kubernetes-clusterpodbeveiligingsinitiatieven voor Linux-workloads
  • Beleid voor pod- en containermogelijkheden opnemen, zoals AppArmor, sysctl, beveiligingslimieten, SELinux, seccomp, bevoegde containers, cluster-API-referenties automatisch koppelen
  • Beleid voor koppelen, volumestuurprogramma's en bestandssysteem
  • Pod-/containernetwerkbeleidsregels, zoals hostnetwerk, poort, toegestane externe IP's, HTTPs en interne load balancers

Azure Kubernetes Service-implementaties maken vaak ook gebruik van Azure Container Registry voor Helm-grafieken en containerinstallatiekopieën. Azure Container Registry biedt ook ondersteuning voor een groot aantal Azure-beleidsregels die netwerkbeperkingen, toegangsbeheer en Microsoft Defender voor Cloud omvatten, wat een veilige AKS-architectuur vormt.

Naast het ingebouwde beleid kunnen aangepaste beleidsregels worden gemaakt voor zowel de AKS-resource als voor de Azure Policy-invoegtoepassing voor Kubernetes. Hiermee kunt u extra beveiligingsbeperkingen toevoegen die u wilt afdwingen in uw cluster- en workloadarchitectuur.

Zie AKS-beveiligingsconcepten en evalueer onze aanbevelingen voor beveiligingsmaatregelen op basis van de CIS Kubernetes-benchmark voor meer suggesties.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het begrijpen van uw verschillende configuratieopties en aanbevolen aanbevolen procedures om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Voordat u de richtlijnen in dit artikel volgt, raden we u aan de volgende bronnen te raadplegen:

Bij het bespreken van kostenoptimalisatie met Azure Kubernetes Service is het belangrijk om onderscheid te maken tussen de kosten van clusterresources en de kosten van workloadresources. Clusterresources zijn een gedeelde verantwoordelijkheid tussen de clusterbeheerder en hun resourceprovider, terwijl workloadresources het domein van een ontwikkelaar zijn. Azure Kubernetes Service heeft overwegingen en aanbevelingen voor beide rollen.

In de ontwerpcontrolelijst en lijst met aanbevelingen worden bijschriften gedaan om aan te geven of elke keuze van toepassing is op clusterarchitectuur, workloadarchitectuur of beide.

Voor optimalisatie van clusterkosten gaat u naar de Azure-prijscalculator en selecteert u Azure Kubernetes Service uit de beschikbare producten. U kunt verschillende configuratie- en betalingsplannen testen in de rekenmachine.

Controlelijst voor ontwerp

  • Clusterarchitectuur: gebruik de juiste VM-SKU per knooppuntgroep en gereserveerde instanties waar langetermijncapaciteit wordt verwacht.
  • Cluster- en workloadarchitecturen: gebruik de juiste beheerde schijflaag en -grootte.
  • Clusterarchitectuur: Bekijk metrische prestatiegegevens, te beginnen met CPU, geheugen, opslag en netwerk, om kostenoptimalisatiemogelijkheden te identificeren per cluster, knooppunten en naamruimte.
  • Cluster- en workloadarchitectuur: gebruik automatische schaalaanpassingen om in te schalen wanneer workloads minder actief zijn.

Aanbevelingen

Bekijk de volgende tabel met aanbevelingen om uw AKS-configuratie te optimaliseren voor kosten.

Aanbeveling Voordeel
Cluster- en workloadarchitecturen: SKU-selectie en beheerde schijfgrootte afstemmen op workloadvereisten. Door uw selectie aan uw workloadvereisten te koppelen, betaalt u niet voor overbodige resources.
Clusterarchitectuur: selecteer het juiste exemplaartype van de virtuele machine. Het selecteren van het juiste exemplaartype van de virtuele machine is essentieel omdat dit rechtstreeks van invloed is op de kosten van het uitvoeren van toepassingen op AKS. Het kiezen van een exemplaar met hoge prestaties zonder correct gebruik kan leiden tot verspilling van uitgaven, terwijl het kiezen van een minder krachtig exemplaar kan leiden tot prestatieproblemen en verhoogde downtime. Als u het juiste exemplaartype van de virtuele machine wilt bepalen, moet u rekening houden met workloadkenmerken, resourcevereisten en beschikbaarheidsbehoeften.
Clusterarchitectuur: Selecteer virtuele machines op basis van de Arm-architectuur. AKS biedt ondersteuning voor het maken van Arm64 Ubuntu-agentknooppunten, evenals een combinatie van Intel- en ARM-architectuurknooppunten binnen een cluster die betere prestaties tegen lagere kosten kan opleveren.
Clusterarchitectuur: Selecteer Azure Spot Virtual Machines. Met spot-VM's kunt u profiteren van niet-gebruikte Azure-capaciteit met aanzienlijke kortingen (tot 90% in vergelijking met prijzen voor betalen per gebruik). Als Azure capaciteit terug nodig heeft, verwijdert de Azure-infrastructuur de Spot-knooppunten.
Clusterarchitectuur: selecteer de juiste regio. Vanwege veel factoren variëren de kosten van resources per regio in Azure. Evalueer de vereisten voor kosten, latentie en naleving om ervoor te zorgen dat u uw workload rendabel uitvoert en dit geen invloed heeft op uw eindgebruikers of extra netwerkkosten maakt.
Workloadarchitectuur: onderhoud kleine en geoptimaliseerde installatiekopieën. Door uw installatiekopieën te stroomlijnen, kunt u de kosten verlagen omdat nieuwe knooppunten deze installatiekopieën moeten downloaden. Bouw installatiekopieën op een manier waarmee de container zo snel mogelijk kan worden gestart om fouten of time-outs van gebruikersaanvragen te voorkomen terwijl de toepassing wordt opgestart, wat mogelijk leidt tot overprovisioning.
Clusterarchitectuur: schakel Automatische schaalaanpassing van clusters in om het aantal agentknooppunten automatisch te verminderen als reactie op overtollige resourcecapaciteit. Door automatisch het aantal knooppunten in uw AKS-cluster omlaag te schalen, kunt u een efficiënt cluster uitvoeren wanneer de vraag laag is en omhoog schalen wanneer de vraag terugkeert.
Clusterarchitectuur: Schakel automatische inrichting van knooppunten in om de selectie van VM-SKU's te automatiseren. Automatische inrichting van knooppunten vereenvoudigt het selectieproces van de SKU en bepaalt, op basis van de resourcevereisten voor pods, de optimale VM-configuratie om workloads op de meest efficiënte en rendabele manier uit te voeren.
Workloadarchitectuur: gebruik de horizontale automatische schaalaanpassing van pods. Pas het aantal pods in een implementatie aan, afhankelijk van het CPU-gebruik of andere geselecteerde metrische gegevens, die ondersteuning bieden voor schaalbewerkingen voor clusters.
Workloadarchitectuur: Verticale automatische schaalaanpassing van pods gebruiken (preview). Berecht uw pods en stel aanvragen en limieten dynamisch in op basis van historisch gebruik.
Workloadarchitectuur: Gebruik Kubernetes Event Driven Autoscaling (KEDA). Schalen op basis van het aantal gebeurtenissen dat wordt verwerkt. Kies uit een uitgebreide catalogus met 50+ KEDA-schaalders.
Cluster- en workloadarchitecturen: Gebruik een financiële discipline en culturele praktijk in de cloud om het eigendom van cloudgebruik te stimuleren. De basis van het inschakelen van kostenoptimalisatie is de verspreiding van een kostenbesparingscluster. Een financiële operations-benadering (FinOps) wordt vaak gebruikt om organisaties te helpen de cloudkosten te verlagen. Het is een praktijk waarbij samenwerking tussen financiële, operationele en technische teams wordt gebruikt om afstemming op kostenbesparingsdoelen te stimuleren en transparantie te brengen in cloudkosten.
Clusterarchitectuur: Registreren voor Azure-reserveringen of Azure Savings Plan. Als u de capaciteit goed hebt gepland, is uw workload voorspelbaar en bestaat deze gedurende een langere periode, meldt u zich aan voor een Azure-reservering of een besparingsplan om uw resourcekosten verder te verlagen.
Clusterarchitectuur: Bekijk de aanbevolen procedures voor het bewaken van Kubernetes met Azure Monitor om de beste bewakingsstrategie voor uw workloads te bepalen. N.v.t.
Clusterarchitectuur: de AKS Cost Analysis-invoegtoepassing configureren. Met de clusterextensie kostenanalyse kunt u gedetailleerd inzicht krijgen in de kosten die zijn gekoppeld aan verschillende Kubernetes-resources in uw clusters of naamruimten.

Zie Principes van de pijler kostenoptimalisatie en Kosten optimaliseren in Azure Kubernetes Service voor meer suggesties.

Beleidsdefinities

Hoewel er geen ingebouwde beleidsregels zijn die betrekking hebben op kostenoptimalisatie, kunnen aangepaste beleidsregels worden gemaakt voor zowel de AKS-resource als voor de Azure Policy-invoegtoepassing voor Kubernetes. Hiermee kunt u extra beperkingen voor kostenoptimalisatie toevoegen die u wilt afdwingen in uw cluster- en workloadarchitectuur.

Cloudefficiëntie

Om workloads efficiënter en cloudefficiënter te maken, moeten er inspanningen worden gecombineerd rond kostenoptimalisatie, het verminderen van koolstofemissies en het optimaliseren van het energieverbruik. Het optimaliseren van de kosten van de toepassing is de eerste stap bij het duurzaam maken van workloads.

Leer hoe u duurzame en efficiënte AKS-workloads bouwt in principes voor duurzame software-engineering in Azure Kubernetes Service (AKS).

Operationele uitmuntendheid

Controle en diagnose zijn essentieel. U kunt niet alleen prestatiestatistieken meten, maar ook metrische gegevens gebruiken om problemen snel op te lossen. We raden u aan de ontwerpprincipes voor operationele uitmuntendheid en de handleiding voor dagelijkse bewerkingen te bekijken.

Bij het bespreken van operationele uitmuntendheid met Azure Kubernetes Service is het belangrijk om onderscheid te maken tussen operationele uitmuntendheid van clusters en operationele uitmuntendheid van workloads. Clusterbewerkingen zijn een gedeelde verantwoordelijkheid tussen de clusterbeheerder en hun resourceprovider, terwijl workloadbewerkingen het domein van een ontwikkelaar zijn. Azure Kubernetes Service heeft overwegingen en aanbevelingen voor beide rollen.

In de onderstaande ontwerpcontrolelijst en lijst met aanbevelingen worden bijschriften gedaan om aan te geven of elke keuze van toepassing is op clusterarchitectuur, workloadarchitectuur of beide.

Controlelijst voor ontwerp

  • Clusterarchitectuur: Gebruik een implementatie op basis van sjablonen met Bicep, Terraform of andere. Zorg ervoor dat alle implementaties herhaalbaar, traceerbaar en opgeslagen zijn in een opslagplaats voor broncode.
  • Clusterarchitectuur: bouw een geautomatiseerd proces om ervoor te zorgen dat uw clusters worden opgestart met de benodigde configuraties en implementaties voor het hele cluster. Dit wordt vaak uitgevoerd met Behulp van GitOps.
  • Workloadarchitectuur: gebruik een herhaalbare en geautomatiseerde implementatieprocessen voor uw workload binnen de levenscyclus van uw softwareontwikkeling.
  • Clusterarchitectuur: schakel diagnostische instellingen in om ervoor te zorgen dat interactie tussen besturingsvlak of kern-API-server wordt vastgelegd.
  • Cluster- en workloadarchitecturen: bekijk de aanbevolen procedures voor het bewaken van Kubernetes met Azure Monitor om de beste bewakingsstrategie voor uw workloads te bepalen.
  • Workloadarchitectuur: De workload moet worden ontworpen om telemetrie te verzenden die kan worden verzameld, wat ook de status van de liveheid en gereedheid moet omvatten.
  • Cluster- en workloadarchitecturen: Gebruik chaos-engineeringprocedures die gericht zijn op Kubernetes om problemen met de betrouwbaarheid van toepassingen of platforms te identificeren.
  • Workloadarchitectuur: Optimaliseer uw workload om efficiënt te werken en te implementeren in een container.
  • Cluster- en workloadarchitecturen: cluster- en workloadbeheer afdwingen met behulp van Azure Policy.

Aanbevelingen

Bekijk de volgende tabel met aanbevelingen voor het optimaliseren van uw AKS-configuratie voor bewerkingen.

Aanbeveling Voordeel
Cluster- en workloadarchitecturen: raadpleeg de documentatie over best practices voor AKS. Voor het bouwen en uitvoeren van toepassingen in AKS zijn er belangrijke overwegingen om te begrijpen en te implementeren. Deze gebieden omvatten multitenancy- en scheduler-functies, cluster- en podbeveiliging, of bedrijfscontinuïteit en herstel na noodgevallen.
Cluster- en workloadarchitecturen: Bekijk Azure Chaos Studio. Azure Chaos Studio kan helpen bij het simuleren van fouten en het activeren van situaties met herstel na noodgevallen.
Cluster- en workloadarchitecturen: bekijk de aanbevolen procedures voor het bewaken van Kubernetes met Azure Monitor om de beste bewakingsstrategie voor uw workloads te bepalen. N.v.t.
Clusterarchitectuur: Gebruik een strategie voor meerdere regio's door AKS-clusters te implementeren die zijn geïmplementeerd in verschillende Azure-regio's om de beschikbaarheid te maximaliseren en bedrijfscontinuïteit te bieden. Internetgerichte workloads moeten gebruikmaken van Azure Front Door of Azure Traffic Manager om verkeer wereldwijd te routeren tussen AKS-clusters.
Clusterarchitectuur: configuratiestandaarden voor clusters en pods operationeel maken met Azure Policy. Azure Policy kan helpen bij het toepassen van afdwinging en beveiliging op schaal op uw clusters op een gecentraliseerde, consistente manier. Het kan ook bepalen welke functies pods worden verleend en of er iets wordt uitgevoerd op basis van bedrijfsbeleid.
Workloadarchitectuur: platformmogelijkheden gebruiken in uw release-engineeringproces. Kubernetes- en toegangsbeheerobjectcontrollers ondersteunen veel geavanceerde implementatiepatronen voor opname in uw release-engineeringproces. Overweeg patronen zoals blauwgroene implementaties of canary-releases.
Cluster- en workloadarchitecturen: Gebruik blauw/groene implementaties op stempelniveau voor bedrijfskritieke workloads. Automatiseer uw bedrijfskritieke ontwerpgebieden, inclusief implementatie en testen.

Zie Principes van de operationele uitmuntendheidpijler voor meer suggesties.

Azure Advisor doet ook aanbevelingen voor een subset van de items die worden vermeld in de onderstaande beleidssectie, zoals niet-ondersteunde AKS-versies en niet-geconfigureerde diagnostische instellingen. Op dezelfde manier worden er aanbevelingen voor werkbelastingen uitgevoerd rond het gebruik van de standaardnaamruimte.

Beleidsdefinities

Azure Policy biedt verschillende ingebouwde beleidsdefinities die van toepassing zijn op zowel de Azure-resource als AKS, zoals standaardbeleidsdefinities, en het gebruik van de Azure Policy-invoegtoepassing voor Kubernetes, ook binnen het cluster. Veel van de Azure-resourcebeleidsregels zijn beschikbaar in zowel Audit/Deny, maar ook in een variant Implementeren indien niet bestaat .

Er zijn talloze belangrijke beleidsregels met betrekking tot deze pijler die hier worden samengevat. Zie ingebouwde beleidsdefinities voor Kubernetes voor een gedetailleerdere weergave.

Clusterarchitectuur

  • Azure Policy-invoegtoepassing voor Kubernetes
  • Configuratiebeleid voor GitOps
  • Beleid voor diagnostische instellingen
  • AKS-versiebeperkingen
  • Opdracht aanroepen voorkomen

Cluster- en workloadarchitectuur

  • Beperkingen voor implementatie van naamruimten

Naast het ingebouwde beleid kunnen aangepaste beleidsregels worden gemaakt voor zowel de AKS-resource als voor de Azure Policy-invoegtoepassing voor Kubernetes. Hiermee kunt u extra beveiligingsbeperkingen toevoegen die u wilt afdwingen in uw cluster- en workloadarchitectuur.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. We raden u aan de principes voor prestatie-efficiëntie te bekijken.

Wanneer u de prestaties met Azure Kubernetes Service bespreekt, is het belangrijk om onderscheid te maken tussen clusterprestaties en workloadprestaties. Clusterprestaties zijn een gedeelde verantwoordelijkheid tussen de clusterbeheerder en de resourceprovider, terwijl de prestaties van de werkbelasting het domein van een ontwikkelaar zijn. Azure Kubernetes Service heeft overwegingen en aanbevelingen voor beide rollen.

In de onderstaande ontwerpcontrolelijst en lijst met aanbevelingen worden bijschriften gedaan om aan te geven of elke keuze van toepassing is op clusterarchitectuur, workloadarchitectuur of beide.

Controlelijst voor ontwerp

Wanneer u ontwerpkeuzen maakt voor Azure Kubernetes Service, bekijkt u de principes voor prestatie-efficiëntie.

  • Cluster- en workloadarchitecturen: Voer een gedetailleerde oefening voor capaciteitsplannen uit en voer deze uit met SKU, instellingen voor automatisch schalen, IP-adressering en failoveroverwegingen.
  • Clusterarchitectuur: schakel automatische schaalaanpassing van clusters in om automatisch het aantal agentknooppunten aan te passen in reactie op de workloadvereisten.
  • Clusterarchitectuur: gebruik de horizontale automatische schaalaanpassing van pods om het aantal pods in een implementatie aan te passen, afhankelijk van het CPU-gebruik of andere geselecteerde metrische gegevens.
  • Cluster- en workloadarchitecturen: voer doorlopende belastingstests uit die zowel de automatische schaalaanpassing van pods als clusters uitvoeren.
  • Cluster- en workloadarchitecturen: Scheid workloads in verschillende knooppuntgroepen, waardoor onafhankelijke calling mogelijk is.

Aanbevelingen

Bekijk de volgende tabel met aanbevelingen voor het optimaliseren van uw Azure Kubernetes Service-configuratie voor prestaties.

Aanbeveling Voordeel
Cluster- en workloadarchitecturen: ontwikkel een gedetailleerd capaciteitsplan en controleer en wijzig voortdurend. Nadat u uw capaciteitsplan hebt geformaliseerd, moet dit regelmatig worden bijgewerkt door continu het resourcegebruik van het cluster te observeren.
Clusterarchitectuur: schakel automatische schaalaanpassing van clusters in om automatisch het aantal agentknooppunten aan te passen als reactie op resourcebeperkingen. Met de mogelijkheid om het aantal knooppunten in uw AKS-cluster automatisch omhoog of omlaag te schalen, kunt u een efficiënt, rendabel cluster uitvoeren.
Cluster- en workloadarchitecturen: Scheid workloads in verschillende knooppuntgroepen en overweeg om gebruikersknooppuntgroepen te schalen . In tegenstelling tot systeemknooppuntgroepen waarvoor altijd actieve knooppunten zijn vereist, kunt u met gebruikersknooppuntgroepen omhoog of omlaag schalen.
Workloadarchitectuur: gebruik geavanceerde AKS-plannerfuncties. Helpt bij het beheren van de taakverdeling van resources voor workloads die hiervoor nodig zijn.
Workloadarchitectuur: Gebruik zinvolle metrische gegevens voor het schalen van workloads. Niet alle schaalbeslissingen kunnen worden afgeleid van metrische cpu- of geheugengegevens. Vaak zijn er overwegingen voor schaalaanpassing afkomstig van complexere of zelfs externe gegevenspunten. Gebruik KEDA om een zinvolle regelset voor automatisch schalen te bouwen op basis van signalen die specifiek zijn voor uw workload.

Zie Principes van de pijler prestatie-efficiëntie voor meer suggesties.

Beleidsdefinities

Azure Policy biedt verschillende ingebouwde beleidsdefinities die van toepassing zijn op zowel de Azure-resource als AKS, zoals standaardbeleidsdefinities, en het gebruik van de Azure Policy-invoegtoepassing voor Kubernetes, ook binnen het cluster. Veel van de Azure-resourcebeleidsregels zijn beschikbaar in zowel Audit/Deny, maar ook in een variant Implementeren indien niet bestaat .

Er zijn talloze belangrijke beleidsregels met betrekking tot deze pijler die hier worden samengevat. Zie ingebouwde beleidsdefinities voor Kubernetes voor een gedetailleerdere weergave.

Cluster- en workloadarchitectuur

  • Limieten voor CPU- en geheugenresources

Naast het ingebouwde beleid kunnen aangepaste beleidsregels worden gemaakt voor zowel de AKS-resource als voor de Azure Policy-invoegtoepassing voor Kubernetes. Hiermee kunt u extra beveiligingsbeperkingen toevoegen die u wilt afdwingen in uw cluster- en workloadarchitectuur.

Aanvullende bronnen

Richtlijnen voor Azure Architecture Center

Richtlijn voor Cloud Adoption Framework

Volgende stappen