Betrouwbaarheid in Azure Application Gateway for Containers

Azure Application Gateway voor containers is een beheerde taakverdelings- en dynamische verkeersbeheerservice op toepassingslaag (laag 7) voor workloads die worden uitgevoerd in Kubernetes. Hiermee worden binnenkomende verzoeken naar back-enddoelen in uw cluster gerouteerd.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe Azure Application Gateway voor containers tijdelijke fouten, fouten in beschikbaarheidszones, regiobrede fouten en serviceonderhoud verwerkt. Ook worden opties voor back-up en herstel en belangrijke informatie over de SLA (Service Level Agreement) beschreven.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Application Gateway for Containers is standaard hoog beschikbaar. Voor productieworkloads:

Zie Application Gateway voor containers implementeren op Azure Kubernetes Service voor een voorbeeldarchitectuur en richtlijnen voor topologie, verkeersstroom, betrouwbaarheid, beveiliging en bewerkingen.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Een implementatie van Application Gateway for Containers bevat resources in Azure en in uw Kubernetes-cluster.

• Azure resources: het control plane organiseert de proxyconfiguratie van de gateway op basis van uw configuratie. Het Azure-beheerde data plane wordt buiten uw cluster uitgevoerd en verwerkt toepassingsverkeer.
• Kubernetes-resources: Je definieert routering en andere configuratie met behulp van Kubernetes-resources. De ALB-controller wordt uitgevoerd in uw cluster, controleert deze resources en voert uw configuratie door naar Application Gateway for Containers in Azure.

U kunt kiezen tussen twee uitrolstrategieën. Met de BYO-strategie (Bring Your Own) beheert u de levenscyclus van Application Gateway for Containers, koppeling en front-end-resources via Azure-hulpprogramma's. Met de strategie beheerd door ALB Controller beheert de ALB-controller de levenscyclus van deze Azure-resources op basis van de Kubernetes-resources die u definieert.

Zie Application Gateway for Containers components voor een volledige beschrijving van de onderdelen.

Nadat u Application Gateway for Containers hebt geïmplementeerd en geconfigureerd, worden binnenkomende aanvragen gerouteerd naar de back-enddoelen, die uw toepassing vertegenwoordigen die wordt uitgevoerd in Kubernetes.

Als de ALB-controller of het control plane niet beschikbaar is, blijft het data plane verkeer verwerken met behulp van de laatst succesvol toegepaste configuratie. Tijdens de storing worden configuratie-updates niet doorgegeven en kan de service de configuratie niet programmeren die is vereist voor uitschaalgebeurtenissen.

Fysieke architectuur

Azure beheert en schaalt automatisch de infrastructuur van het gegevensvlak op basis van toepassingsverkeer. Application Gateway for Containers wordt altijd geïmplementeerd in een configuratie met hoge beschikbaarheid: in regio's die beschikbaarheidszones ondersteunen, zijn gateways zone-redundant; in regio's die geen beschikbaarheidszones ondersteunen, gebruikt Azure beschikbaarheidssets.

Tolerantie voor 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. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Houd rekening met de volgende aanbevolen procedures wanneer u Application Gateway for Containers gebruikt:

• Implementeer logica voor opnieuw proberen. Configureer clients om verzoeken opnieuw te proberen na tijdelijke verbindingsfouten.

• Configureer gezondheidsonderzoeken met toleranties. Als u aangepaste statustests configureert, stelt u de drempelwaarde voor ongezonde status in om tijdelijke fouten te tolereren. De drempelwaarde voor de status Ongezond geeft het aantal opeenvolgende mislukte controles op waarmee het back-enddoel als Ongezond wordt gemarkeerd. De standaard-statuscontrole maakt gebruik van een drempel voor ongezond van drie controles, waardoor één tijdelijke testfout niet ertoe leidt dat de back-end als ongezond wordt gemarkeerd.

Tolerantie voor fouten in beschikbaarheidszones

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

Wanneer u Application Gateway for Containers implementeert in een Azure-regio die beschikbaarheidszones ondersteunt, configureert Microsoft automatisch het besturingsvlak en het gegevensvlak als zone-redundant, gespreid over meerdere zones. U selecteert niet welke zones de service gebruikt.

Requirements

Regioondersteuning: Als u zoneredundantie wilt gebruiken, kiest u een regio die ondersteuning biedt voor zowel Application Gateway voor Containers als beschikbaarheidszones. Controleer de regionale beschikbaarheid van Application Gateway for Containers en vergelijk deze met de lijst met regio's die beschikbaarheidszones ondersteunen.

Considerations

Gedeelde verantwoordelijkheid met uw Kubernetes-platform: Microsoft beheert verkeeromleiding voor Application Gateway for Containers tijdens een zonefout. Voor Azure Kubernetes Service (AKS) beheert Microsoft het Kubernetes-besturingsvlak. U bent verantwoordelijk voor het configureren van zoneredundantie voor de knooppuntpools van uw cluster en andere resources die u beheert, en voor het gedrag van uw toepassingen tijdens een zonestoring.

• Cluster: Configureer uw AKS-knooppuntgroepen en andere zonegebonden clusterbronnen die u beheert zodat ze beschikbaarheidszones beslaan. AKS beheert het besturingsvlak; zie Beschikbaarheidszones configureren voor AKS-knooppools.

• Uw workloads: U bent verantwoordelijk voor het implementeren van meerdere podreplica's, het verspreiden ervan over zones en het garanderen van gezonde back-endworkloads die beschikbaar zijn om verkeer te verwerken tijdens een storing in een zone. U kunt nodepools gebruiken die beschikbaarheidszones omvatten, beperkingen voor topologiespreiding en pod anti-affinity.

• Kubernetes-configuratieobjecten: Application Gateway for Containers maakt gebruik van Kubernetes-configuratieobjecten die zijn opgeslagen door de cluster-API. De beschikbaarheid is afhankelijk van het Kubernetes-besturingsvlak en de configuratie die u in uw cluster beheert.

• ALB-controller: U implementeert de ALB-controller in uw Kubernetes-cluster om de configuratie af te stemmen. Het maakt geen deel uit van het gegevenspad Application Gateway for Containers.

  De ALB-controller draait twee replica’s, waarbij de ene fungeert als de leider en de andere als de secundaire. Als de leider niet meer beschikbaar is, kan de secundaire de leider worden en doorgaan met het doorgeven van de configuratie. Beide replica's kunnen in dezelfde beschikbaarheidszone worden uitgevoerd, afhankelijk van hoe het cluster ze inplant. U bent verantwoordelijk voor het configureren van de cluster- en controllerpods voor zoneredundantie. Gebruik topologieverspreidingsbeperkingen voor pods of antiaffiniteit voor pods om de replica's over zones te verdelen. Zie Beschikbaarheidszones configureren voor AKS-knooppuntgroepen voor meer informatie.

Cost

Ondersteuning voor beschikbaarheidszones voor Application Gateway for Containers brengt geen extra kosten met zich mee buiten de standaardserviceprijzen. Zie prijsinformatie voor Azure Application Gateway.

Ondersteuning voor beschikbaarheidszones configureren

Wanneer u een nieuwe gateway in een ondersteunde regio implementeert, is deze standaard zone-redundant. U hoeft zoneredundantie niet in te schakelen voor Azure resources.

U bent verantwoordelijk voor het configureren van uw Kubernetes-cluster, ALB-controller en back-endworkloads voor zonetolerantie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u Application Gateway for Containers implementeert in een regio die ondersteuning biedt voor beschikbaarheidszones en alle zones die door de service worden gebruikt, operationeel zijn.

• Werking in meerdere zones: Het Azure-beheerde Application Gateway for Containers-gegevensvlak distribueert binnenkomende aanvragen over de infrastructuur in meerdere zones.

  U bent verantwoordelijk voor het configureren van uw back-endworkloads voor uitvoering in meerdere zones en het bieden van gezonde targets voor het ontvangen van dat verkeer.

• Replicatie van gegevens in meerdere zones: Application Gateway for Containers slaat geen toepassingsgegevens op. Het platform beheert de configuratiestatus via het zone-redundante control plane om bestendigheid en veerkracht te bieden.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u Application Gateway for Containers implementeert in een regio die beschikbaarheidszones ondersteunt en een van de zones die door de service worden gebruikt, een storing heeft.

• Detectie en reactie: Application Gateway for Containers leidt verkeer om naar infrastructuur in de resterende zones die in orde zijn tijdens een zone-uitval. U hoeft geen actie te ondernemen voor de herdistributie van het verkeer van de gateway.

  U bent echter verantwoordelijk voor het effect van de storing op uw Kubernetes-cluster en back-endtoepassingen.

• Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Bestaande verbindingen met de uitgevallen zone worden verwijderd. Clients moeten de verzoeken opnieuw proberen door de richtlijnen in Veerkracht bij tijdelijke fouten te volgen. Er worden nieuwe verbindingen tot stand gebracht met de infrastructuur in de resterende gezonde zones.

• Verwachte gegevensverlies: Application Gateway voor containers slaat geen toepassingsgegevens op. Het platform beheert de configuratiestatus via het zone-redundante control plane om bestendigheid en veerkracht te bieden.

• Verwachte downtime: Clients kunnen een korte onderbreking ervaren wanneer verbindingen met de mislukte zone worden verbroken. Clients moeten aanvragen opnieuw proberen om nieuwe verbindingen met infrastructuur tot stand te brengen in de resterende gezonde zones.

  Het door Azure beheerde control plane blijft beschikbaar tijdens een storing in één zone. Uw mogelijkheid om configuratie-updates toe te passen, is echter ook afhankelijk van de beschikbaarheid van uw Kubernetes-besturingsvlak en DE ALB-controller.

• Herdistributie: Application Gateway for Containers leidt verkeer om naar infrastructuur in de resterende zones die in orde zijn.

Herstel van zone

Application Gateway for Containers herstelt zelf van onderliggende problemen. Azure beheert het herstel van de gatewayinfrastructuur.

Testen op zonefouten

Het Application Gateway for Containers-platform beheert verkeersroutering en de reactie op zonefouten voor de gateway zelf. U hoeft de respons van de gateway niet te initiëren of te beheren. Als u een Kubernetes-cluster hebt dat u beheert, kunt u Azure Chaos Studio gebruiken om de reactie van het cluster op zonefouten te testen. Zie voor meer informatie Test op resilience van beschikbaarheidszones.

Tolerantie voor storingen in de hele regio

Application Gateway for Containers is een service met één regio. Als de Azure regio waar u een gateway hebt geïmplementeerd niet meer beschikbaar is, is die gateway niet meer beschikbaar.

Aangepaste multiregionale oplossingen voor veerkracht

Application Gateway voor containers biedt geen ingebouwde oplossing voor uitrol in meerdere regio's of failover. Als u voor een regiostoring wilt ontwerpen, implementeert en configureert u een afzonderlijke gateway en een Kubernetes-cluster in elke regio. U bent verantwoordelijk voor het sturen van verkeer tussen de regionale gateways en het configureren van failover.

• Configureer Application Gateway for Containers consistent in alle regio's. Om implementaties te vereenvoudigen en configuraties afgestemd te houden, definieert u uw infrastructuur als code (IaC) met behulp van hulpprogramma's zoals Bicep of Terraform.

• Kies en configureer een globale service voor verkeersbeheer, zoals Azure Front Door of Azure Traffic Manager, om clients naar uw regionale gateways te leiden. Deze services gebruiken verschillende routeringsmodellen en healthprobeconfiguraties. Configureer de geselecteerde service om verkeer weg te leiden van een niet-beschikbare gateway en bekijk de bijbehorende documentatie om inzicht te hebben in routeringsgedrag en failoveroverwegingen. Azure Front Door biedt ook mogelijkheden zoals DDoS-beveiliging (Distributed Denial of Service), WAF-mogelijkheden (Web Application Firewall) en routering op basis van regels.

• Rol uw back-endtoepassingen in elke regio uit en configureer ze om tijdens een storing gezonde workloads te leveren. Als uw toepassingen afhankelijk zijn van gegevens of andere Azure services, ontwerpt en configureert u deze services ook voor beschikbaarheid in meerdere regio's. Bekijk de betrouwbaarheidsrichtlijnen voor elke service om inzicht te hebben in de multiregio-opties en -beperkingen ervan.

Back-up maken en terugzetten

Application Gateway voor containers slaat geen toepassingsgegevens op. Azure Resource Manager slaat de Azure resourceconfiguratie van de gateway op. U kunt deze resources opnieuw maken door hun configuratie opnieuw te implementeren.

U bent verantwoordelijk voor het bewaren van de configuratie en Kubernetes-resources die bepalen hoe de gateway wordt geïmplementeerd en hoe deze verkeer routeert:

• Definieer de Azure resources en de bijbehorende instellingen in infrastructuur als code (IaC), zoals Bicep of Terraform, en behoud de definities in versiebeheer. U kunt ze gebruiken om de gatewaybronnen opnieuw uit te rollen.

• Maak een back-up van de Kubernetes-resources die de gateway configureren, zoals ApplicationLoadBalancer, Gatewayen HTTPRoute resources. Zet ze terug in uw cluster wanneer u de routeringsconfiguratie opnieuw moet maken.

• Bewaar gerelateerde configuratie, inclusief aangepaste regels en firewallbeleid voor webtoepassingen, in versiebeheer of via uw standaardconfiguratieback-upproces. U kunt implementatiepijplijnen gebruiken om de Azure- en Kubernetes-resources consistent opnieuw aan te maken.

Tolerantie voor serviceonderhoud

Microsoft beheert onderhoud voor Application Gateway for Containers terwijl Microsoft de hoge beschikbaarheid van de service handhaaft.

De vereiste minimale subnetgrootte van /24 voor elke koppeling houdt rekening met onderhoudsvensters, dus u hoeft geen extra IP-adresruimte voor het subnet toe te wijzen voor onderhoud.

Zie Schalen en beschikbaarheid voor Application Gateway voor containers voor meer informatie.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA van Application Gateway for Containers meet de beheerlaag en het gegevensvlak afzonderlijk. Beide vlakken worden meegenomen in de totale SLA-berekening.

Verwante onderwerpen

• Application Gateway for Containers implementeren op Azure Kubernetes Service
• Betrouwbaarheid in Azure