Betrouwbaarheid in Azure Kubernetes Service (AKS)

In dit artikel wordt de betrouwbaarheidsondersteuning in Azure Kubernetes Service (AKS) beschreven, met informatie over tolerantie binnen regio's via beschikbaarheidszones en implementaties in meerdere regio's.

Betrouwbaarheid is een gedeelde verantwoordelijkheid tussen u en Microsoft. U kunt deze handleiding gebruiken om erachter te komen welke betrouwbaarheidsopties voldoen aan uw specifieke bedrijfsdoelstellingen en uptimedoelstellingen.

Aanbevelingen voor productie-implementatie

Zie de volgende artikelen voor aanbevelingen over het implementeren van betrouwbare productieworkloads in AKS:

• Best practices voor implementatie en clusterbetrouwbaarheid voor AKS
• Overzicht van hoge beschikbaarheid (HA) en herstel na noodgevallen voor AKS
• Overwegingen voor zonetolerantie voor AKS

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u een AKS-cluster maakt, maakt en configureert het Azure-platform automatisch:

• Een besturingsvlak met de API-server, enzovoort, de planner en andere pods die nodig zijn om uw workload te beheren.

• Een systeemknooppuntgroep voor uw abonnement die als host fungeert voor uw invoegtoepassingen en andere pods die worden uitgevoerd in de kube-system-naamruimte .

Nadat deze eerste installatie van de knooppuntgroep is voltooid, kunt u knooppuntgroepen toevoegen of verwijderen voor uw eigen gebruikersworkloads. AKS beheert geen knooppuntgroepen voor betrouwbaarheid en u moet ervoor zorgen dat uw workloads bestand zijn tegen storingen in de infrastructuur.

Veerkracht is een gedeelde verantwoordelijkheid tussen u en Microsoft. Als rekenservice beheert AKS enkele aspecten van de betrouwbaarheid van uw cluster, maar u bent verantwoordelijk voor het beheren van andere aspecten.

• Microsoft beheert het besturingsvlak en andere beheerde onderdelen van AKS.

• Het is uw verantwoordelijkheid om:

  • Definieer hoe onderdelen, waaronder knooppuntgroepen en load balancers die aan services zijn gekoppeld, moeten worden geconfigureerd om te voldoen aan uw betrouwbaarheidsvereisten. Nadat u de onderdelen hebt gedefinieerd, implementeert en beheert Microsoft deze vervolgens namens u.

  • Beheer alle onderdelen buiten het AKS-cluster, inclusief opslag en databases. Controleer of deze onderdelen voldoen aan uw betrouwbaarheidsvereisten. Wanneer u uw workloads implementeert, moet u ervoor zorgen dat andere Azure-onderdelen ook zijn geconfigureerd voor tolerantie door de aanbevolen procedures voor deze services te volgen.

Tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Ze corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen bij het communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het omgaan met tijdelijke fouten voor meer informatie.

Wanneer u AKS gebruikt, kunnen tijdelijke fouten optreden vanwege verschillende oorzaken, waaronder toepassingscrashes, schalen van pods en taakverdelingsbewerkingen, knooppuntpatching en tijdelijke infrastructuurfouten, zoals hardware- of netwerkproblemen.

Het is onmogelijk om alle tijdelijke fouten te elimineren, zodat clients die toegang hebben tot uw door AKS gehoste toepassingen, moeten worden voorbereid om mislukte aanvragen opnieuw uit te voeren en andere aanbevelingen voor tijdelijke foutafhandeling te volgen. U kunt de kans op tijdelijke fouten minimaliseren en de downtime die ze kunnen veroorzaken voorkomen of beperken door aanbevolen procedures voor Kubernetes en Azure in uw implementatie te volgen.

• Stel in uw pod YAML budgetten voor podonderbrekingen (PDBs) in om op te geven hoeveel pods u tegelijkertijd in een Ready status moet hebben. Wanneer u PDBs instelt, zorgt AKS voor een minimale beschikbaarheid van replica's wanneer bewerkingen worden uitgevoerd om de knooppunten op te snoeren en leeg te maken. Als niet aan een PDB kan worden voldaan tijdens processen zoals upgrades, blijft de pod functioneren en kan de bewerking mislukken. Zie PDBs voor meer informatie.

• Gebruik maxUnavailable om het maximale aantal replica's te bepalen dat op een bepaald moment niet beschikbaar kan zijn. Wanneer u bijvoorbeeld een rolling restart uitvoert, zorgt AKS ervoor dat niet meer dan het maxUnavailable aantal pods tegelijkertijd wordt verplaatst. Zie maxUnavailable voor meer informatie.

• Volg de aanbevolen procedures voor implementatie. Podreplica's kunnen ook mislukken vanwege toepassingsproblemen. Voor meer informatie, zie best practices op implementatieniveau voor de betrouwbaarheid van AKS-clusters.

Notitie

Als u wilt dat AKS uw implementaties valideert voor naleving van aanbevolen procedures en blokkerings- of waarschuwingsmeldingen biedt, kunt u implementatiebeveiligingen (preview) gebruiken. Implementatiebeveiligingen zijn een beheerd aanbod waarmee aanbevolen procedures voor producten worden afgedwongen voordat uw code in het cluster wordt geïmplementeerd.

Ondersteuning voor beschikbaarheidszone

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

Wanneer u een AKS-cluster implementeert in een regio die beschikbaarheidszones ondersteunt, vereisen verschillende onderdelen verschillende configuratietypen.

Het AKS-besturingsvlak is standaard zone-resilient. Als een zone mislukt, vereist het besturingsvlak geen configuratie of beheer om tolerantie te bereiken. De tolerantie van het besturingsvlak is echter niet voldoende om uw cluster operationeel te houden wanneer een zone uitvalt. Voor de systeemknooppuntgroep en eventuele gebruikersknooppuntgroepen die u implementeert, moet u ondersteuning voor beschikbaarheidszones inschakelen om ervoor te zorgen dat uw workloads bestand zijn tegen fouten in de beschikbaarheidszone.

Ondersteuning voor regio

U kunt zonebestendige AKS-clusters implementeren in elke regio die beschikbaarheidszones ondersteunt.

Overwegingen

Als u de betrouwbaarheid en tolerantie van AKS-productieworkloads in een regio wilt verbeteren, moet u AKS configureren voor zoneredundantie door de volgende configuraties uit te voeren:

• Implementeer meerdere replica's. Kubernetes spreidt uw pods over knooppunten op basis van knooppuntlabels. Als u uw workload wilt verdelen over zones, moet u meerdere replica's van uw pod implementeren. Als u bijvoorbeeld de knooppuntgroep met drie zones configureert, maar slechts één replica van uw pod implementeert, is uw implementatie geen zonetolerant.

• Schakel automatisch schalen in. Kubernetes-knooppuntgroepen bieden handmatige en automatische schaalopties. Door handmatig schalen te gebruiken, kunt u indien nodig knooppunten toevoegen of verwijderen, en wachtende pods blijven in de wachtrij totdat u een knooppuntgroep omhoog schaalt. AKS-beheerd schalen gebruikt de cluster autoscaler of het automatisch inrichten van knooppunten (NAP). AKS schaalt de knooppuntgroep omhoog of omlaag op basis van de vereisten van de pod binnen het SKU-quotum en de capaciteit van uw abonnement. Deze methode helpt ervoor te zorgen dat uw pods worden gepland op beschikbare knooppunten in de beschikbaarheidszones.

• Beperkingen voor podtopologie instellen. Gebruik beperkingen voor podtopologiespreiding om te bepalen hoe pods over verschillende knooppunten of zones worden verdeeld. Beperkingen helpen u bij het bereiken van hoge beschikbaarheid, tolerantie en efficiënt resourcegebruik. Als u liever pods strikt over zones verspreidt, kunt u beperkingen instellen om een pod in de status 'in behandeling' te plaatsen, zodat het evenwicht tussen pods over de zones behouden blijft. Zie beperkingen voor spreiding van pod-topologieën voor meer informatie.

• Zonetolerant netwerken configureren. Als uw pods extern verkeer leveren, configureert u uw clusternetwerkarchitectuur met behulp van services zoals Azure Application Gateway, Azure Load Balancer of Azure Front Door.

• Zorg ervoor dat afhankelijkheden zonetolerant zijn. De meeste AKS-toepassingen gebruiken andere services voor opslag, beveiliging of netwerken. Zorg ervoor dat u de aanbevelingen voor zonetolerantie voor deze services bekijkt.

Kosten

Er worden geen extra kosten in rekening gebracht voor het inschakelen van ondersteuning voor beschikbaarheidszones in AKS. U betaalt voor de virtuele machines (VM's) en andere resources die u in de beschikbaarheidszones implementeert.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuw AKS-cluster met ondersteuning voor beschikbaarheidszones: Zie Een AKS-cluster (Azure Kubernetes Service) maken dat gebruikmaakt van beschikbaarheidszones om ondersteuning voor beschikbaarheidszones te configureren.
• Migratie: U kunt ondersteuning voor beschikbaarheidszones niet inschakelen nadat u een cluster hebt gemaakt. In plaats daarvan moet u een nieuw cluster maken waarvoor ondersteuning voor beschikbaarheidszones is ingeschakeld en het bestaande cluster verwijderen.
• Ondersteuning voor beschikbaarheidszones uitschakelen: U kunt ondersteuning voor beschikbaarheidszones niet uitschakelen nadat u een cluster hebt gemaakt. In plaats daarvan moet u een nieuw cluster maken waarvoor ondersteuning voor beschikbaarheidszones is uitgeschakeld en het bestaande cluster verwijderen.

Normale bewerkingen

• Verkeersroutering tussen zones: Wanneer u een AKS-cluster implementeert dat gebruikmaakt van beschikbaarheidszones, is het belangrijk om ervoor te zorgen dat uw netwerkonderdelen ook zonebestendig zijn. Afhankelijk van de load balancers en andere netwerkonderdelen die u gebruikt, moet u mogelijk expliciet onderdelen configureren om verkeer naar de juiste knooppunten in de juiste zones te routeren en te reageren op zonestoringen. Zie Overwegingen voor zonetolerantie voor AKS voor meer informatie.

• Gegevensreplicatie tussen zones: Als u een staatloze workload uitvoert, moet u beheerde Azure-services, zoals Azure-databases, Azure Cache voor Redis of Azure Storage , gebruiken om de toepassingsgegevens op te slaan. U kunt deze services gebruiken om ervoor te zorgen dat uw verkeer kan worden verplaatst tussen knooppunten en zones zonder risico voor gegevensverlies of voor de gebruikerservaring. U kunt Kubernetes-implementaties, diensten en gezondheidsonderzoeken gebruiken om stateloze pods te beheren en gelijke distributie tussen zones te garanderen.

  Als u de status in uw cluster wilt opslaan met behulp van Azure-schijven, gebruikt u zone-redundante opslag van Azure om ervoor te zorgen dat uw gegevens worden gerepliceerd in meerdere beschikbaarheidszones. Zie Het juiste schijftype kiezen op basis van toepassingsbehoeften voor meer informatie.

Ontspannende ervaring

• Detectie en reactie: Wanneer er een zonestoring optreedt, voert het besturingsvlak automatisch een failover uit. Als uw knooppuntgroepen beschikbaarheidszones gebruiken en de aanbevolen procedures voor zonetolerantie volgen, kunt u verwachten dat AKS knooppunten en replica's weergeeft in de zones die operationeel zijn. AKS voert deze taak automatisch uit wanneer u beheerde oplossingen zoals automatische schaalaanpassing van clusters of NAP gebruikt. Zonder automatisch schalen blijven knooppunten en replica's In afwachting en wachten tot handmatige interventie de node pool opschaalt.

  AKS probeert ook de pods opnieuw te verdelen over de gezonde zones. Als u ervoor kiest om uw nodepool handmatig te schalen in een zone-downscenario, blijven uw pods mogelijk in de status In behandeling wanneer er geen knooppunten beschikbaar zijn in de gezonde zones. Uitschalen in de resterende zones is ook onderhevig aan de beschikbaarheid van quota en capaciteit voor de VM-SKU die u gebruikt.

• Bekendmaking: AKS waarschuwt u niet wanneer een zone niet beschikbaar is. U kunt uw knooppunt- of podstatusgegevens gebruiken om de status van uw knooppunten en pods te bewaken.

• Actieve aanvragen: Actieve aanvragen kunnen onderbrekingen ondervinden. Sommige aanvragen kunnen mislukken en latentie kan toenemen terwijl uw workload een failover naar een andere zone uitvoert.

• Verwachte gegevensverlies: Als u de status in uw cluster opslaat met behulp van Azure-schijven en u zone-redundante opslag gebruikt, wordt verwacht dat een zonefout geen gegevensverlies veroorzaakt.

• Verwachte downtime: Als u zonetolerantie voor uw cluster en pods correct configureert, wordt verwacht dat een zonefout geen downtime voor uw AKS-workload veroorzaakt.

• Verkeer omleiden: Load balancers leiden nieuwe binnenkomende aanvragen om naar pods op gezonde knooppunten.

Zie Overwegingen voor zonetolerantie voor AKS voor meer informatie.

terugval

Wanneer de beschikbaarheidszone wordt hersteld, is het gedrag van failback afhankelijk van het onderdeel:

• Besturingsvlak: AKS herstelt automatisch de bewerkingen van het besturingsvlak in alle beschikbaarheidszones. Er is geen handmatige tussenkomst vereist.

• Knooppuntgroepen en knooppunten: Direct na failback blijven knooppunten in de eerder in orde gestelde zones en worden ze niet hersteld in de herstelde zone. De volgende keer dat u een knooppuntschaalbewerking uitvoert, bijvoorbeeld wanneer u de knooppuntgroep uitschaalt, kan de knooppuntgroep knooppunten maken in de herstelde zone.

• Pods: Onmiddellijk na de failback blijven pods draaien op de knooppunten waarop ze momenteel draaien. Wanneer nieuwe pods worden aangemaakt of bestaande pods worden hermaakt, komen ze in aanmerking voor het gebruik van knooppunten in de herstelde zone.

• Opslag: Opslag die is gekoppeld aan pods, wordt hersteld op basis van hoe zone-redundante opslag werkt.

Testen op zone-uitval

U kunt uw tolerantie voor fouten in de beschikbaarheidszone testen met behulp van de volgende methoden:

• Cordon- en drain-knooppunten in één beschikbaarheidszone
• Een fout in de beschikbaarheidszone simuleren met behulp van Azure Chaos Studio

Ondersteuning voor meerdere regio's

AKS-clusters zijn regionale resources. Als de regio niet beschikbaar is, is uw AKS-cluster ook niet beschikbaar.

Alternatieve benaderingen voor meerdere regio's

Als u uw Kubernetes-workload wilt implementeren in meerdere Azure-regio's, hebt u twee opties om de indeling van deze clusters te beheren.

• Gebruik Azure Kubernetes Fleet Manager als u een eenvoudigere, beheerde ervaring wilt. Met behulp van Azure Kubernetes Fleet Manager kunt u het volgende doen:

  • Een set AKS-clusters beheren als één eenheid en deze clusters kunnen worden gedistribueerd over meerdere Azure-regio's.

  • Automatiseer specifieke aspecten van clusterbeheer, zoals upgrades van cluster- en knooppuntinstallatiekopieën.

  • Gebruik de mogelijkheden voor verkeerdistributie om verkeer over de clusters te verdelen en automatisch een failover uit te voeren als een regio niet beschikbaar is.

• Failover coördineren met behulp van een handmatig actief-actief- of actief-passief implementatiemodel indien uw workload meer genuanceerde controle over de verschillende onderdelen van failovers vereist. Voor meer informatie, zie het overzicht van hoge beschikbaarheid en herstel na noodgevallen voor AKS.

Reservekopieën

Azure Backup heeft een extensie die u kunt gebruiken om een back-up te maken van AKS-clusterbronnen en permanente volumes die aan het cluster zijn gekoppeld. De Backup-kluis communiceert met het AKS-cluster via de extensie om back-up- en herstelbewerkingen uit te voeren.

Als uw AKS-cluster zich in een gekoppelde regio bevindt, kunt u back-ups configureren die moeten worden opgeslagen in geografisch redundante opslag. U kunt geografisch redundante back-ups herstellen in de gekoppelde regio.

Zie de volgende artikelen voor meer informatie:

• Wat is Azure Kubernetes Service backup?
• Een back-up maken van AKS met behulp van Azure Backup

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Redundantie, replicatie en back-up voor meer informatie.

Probeer staatloze clusters te gebruiken die de noodzaak van back-up minimaliseren. Sla gegevens op in externe opslagsystemen en -databases in plaats van in uw cluster.

Dienstenniveauovereenkomst

De SLA (Service Level Agreement) voor AKS beschrijft de verwachte beschikbaarheid van de service en de voorwaarden waaraan moet worden voldaan om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

AKS biedt drie prijscategorieën voor clusterbeheer: Gratis, Standard en Premium. Met de gratis laag kunt u AKS gebruiken om uw workloads te testen. De Standard- en Premium-lagen zijn ontworpen voor productieworkloads. Wanneer u een AKS-cluster implementeert waarvoor beschikbaarheidszones zijn ingeschakeld, neemt het uptimepercentage dat is gedefinieerd in de SLA toe. De SLA is echter alleen van toepassing als u een cluster implementeert in de prijscategorie Standard of Premium.

Verwante inhoud

• Betrouwbaarheid in Azure