Tillförlitlighet i Azure Application Gateway för containrar

Azure Application Gateway för containrar är en hanterad lastbalanserings- och dynamisk trafikhanteringstjänst på programlagret (lager 7) för arbetsbelastningar som körs i Kubernetes. Den dirigerar inkommande begäranden till backendmål i klustret.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur Azure Application Gateway för containrar hanterar tillfälliga fel, fel i tillgänglighetszonen, regionomfattande fel och serviceunderhåll. Den beskriver också alternativ för säkerhetskopiering och återställning samt viktig information om serviceavtalet (SLA).

Rekommendationer för produktionsdistribution för tillförlitlighet

Application Gateway for Containers har hög tillgänglighet som standard. För produktionsarbetsbelastningar:

  • För zonredundans distribuerar du Application Gateway för containrar i en region som stöder tillgänglighetszoner. Tjänsten är automatiskt zonredundant i dessa regioner.

  • Konfigurera ditt Kubernetes-kluster, Kubernetes-resurser och backend-arbetsbelastningar för zontålighet. Vägledning finns i Motståndskraft mot fel i tillgänglighetszoner.

  • För motståndskraft mot regionomfattande fel distribuerar du Application Gateway för containrar och dess beroende arbetsbelastningar i varje region och konfigurerar trafikhantering mellan regioner. Vägledning finns i Anpassade lösningar för flera regioner för resiliens.

  • Om du konfigurerar nätverkssäkerhetsgrupper (NSG:er) eller användardefinierade vägar (UDR) i associationens undernät följer du riktlinjerna för NSG och riktlinjer för användardefinierade vägar.

För ett exempel på en arkitektur och vägledning om topologi, trafikflöde, tillförlitlighet, säkerhet och drift, se Distribuera Application Gateway för containrar på Azure Kubernetes Service.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

En distribution av Application Gateway for Containers innehåller resurser i Azure och i ditt Kubernetes-kluster.

  • Azure resurser:Kontrollplanet samordnar gatewayens proxykonfiguration baserat på din konfiguration. Det Azure-hanterade dataplanet körs utanför klustret och bearbetar programtrafik.
  • Kubernetes-resurser: Du definierar routning och annan konfiguration med hjälp av Kubernetes-resurser. ALB Controller körs i klustret, bevakar dessa resurser och sprider konfigurationen till Application Gateway for Containers i Azure.

Du kan välja mellan två driftsättningsstrategier. Med strategin Bring Your Own (BYO) hanterar du livscykeln för Application Gateway för containrar, associationer och frontendresurser via Azure-verktyg. Med strategin hanterad av ALB Controller hanterar ALB Controller livscykeln för dessa Azure-resurser baserat på de Kubernetes-resurser som du definierar.

En fullständig beskrivning av komponenterna finns i Application Gateway for Containers-komponenter.

När du har distribuerat och konfigurerat Application Gateway för containrar, dirigeras inkommande begäranden till backendmålen, som representerar ditt program som körs i Kubernetes.

Om ALB Controller eller styrplanet inte är tillgängligt fortsätter dataplanet att bearbeta trafik med hjälp av den senast tillämpade konfigurationen. Vid avbrottet sprids inte konfigurationsuppdateringar och tjänsten kan inte konfigurera den konfiguration som krävs för utskalningshändelser.

Fysisk arkitektur

Azure hanterar och skalar automatiskt dataplansinfrastrukturen baserat på applikationstrafik. Application Gateway för containrar distribueras alltid i en konfiguration med hög tillgänglighet: i regioner som stöder tillgänglighetszoner är gatewayer zonredundanta; i regioner som inte stöder tillgänglighetszoner använder Azure tillgänglighetsuppsättningar.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.

När du använder Application Gateway för containrar bör du överväga följande metodtips:

  • Implementera logik för återförsök. Konfigurera klienter för att göra om begäranden efter tillfälliga anslutningsfel.

  • Konfigurera hälsoundersökningar med tolerans. Om du konfigurerar anpassade hälsokontroller anger du tröskelvärdet för att markeras som felaktig för att tolerera tillfälliga fel. Tröskelvärdet för feltillstånd anger antalet misslyckade avsökningar i följd som utlöser att serverdelsmålet markeras som felaktigt. Standardhälsoavsökningen använder ett tröskelvärde för ohälsosam status på tre avsökningar, vilket förhindrar att ett enda tillfälligt avsökningsfel markerar att serverdelen inte är felfri.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

När du distribuerar Application Gateway för containrar i en Azure region som stöder tillgänglighetszoner konfigurerar Microsoft automatiskt kontrollplanet och dataplanet som zonredundanta över flera zoner. Du väljer inte vilka zoner tjänsten använder.

Important

Microsoft hanterar zonredundans för kontrollplanet och dataplanet Application Gateway for Containers. För att uppnå zonresiliens från början till slut konfigurerar du ditt Kubernetes-kluster, Kubernetes-resurser och backend-arbetsbelastningar för att tillhandahålla fungerande mål i alla zoner.

Krav

Regionstöd: Om du vill använda zonredundans väljer du en region som stöder både Application Gateway för containrar och tillgänglighetszoner. Kontrollera regional tillgänglighet för Application Gateway för containrar och jämför den med listan över regioner som stöder tillgänglighetszoner.

Considerations

Delat ansvar med din Kubernetes-plattform: Microsoft hanterar trafikomdirigering för Application Gateway för containrar vid ett zonfel. För Azure Kubernetes Service (AKS) hanterar Microsoft kontrollplanet för Kubernetes. Du ansvarar för att konfigurera zonresiliens för klustrets nodpooler och andra resurser som du hanterar och för programmens beteende under ett zonavbrott.

  • Kluster: Konfigurera dina AKS-nodpooler och andra zonbundna klusterresurser som du hanterar över flera tillgänglighetszoner. AKS hanterar kontrollplanet; se Konfigurera tillgänglighetszoner för AKS-nodpooler.

  • Dina arbetslaster: Du ansvarar för att distribuera flera poddrepliker, sprida dem mellan zoner och se till att felfria arbetslaster i backend är tillgängliga för att hantera trafik under ett zonstopp. Du kan använda nodpooler som omfattar tillgänglighetszoner, begränsningar för topologispridning och pod anti-affinitet.

  • Kubernetes-konfigurationsobjekt: Application Gateway för containrar använder Kubernetes-konfigurationsobjekt som lagras av kluster-API:et. Deras tillgänglighet beror på Kubernetes-kontrollplanet och den konfiguration som du hanterar i klustret.

  • ALB Controller: Du installerar ALB Controller i Kubernetes-klustret för att synkronisera konfigurationen. Det är inte en del av datasökvägen för Application Gateway for Containers.

    ALB-styrenheten kör två repliker, där den ena fungerar som ledare och den andra som sekundär. Om ledaren blir otillgänglig kan den sekundära bli ledare och fortsätta att replikera konfigurationen. Båda replikerna kan köras i samma tillgänglighetszon, beroende på hur klustret schemalägger dem. Du ansvarar för att konfigurera klustret och styrenhetspoddarna för zonresiliens. Använd poddtopologispridningsbegränsningar eller pod anti-affinity för att distribuera replikerna mellan zoner. Mer information finns i Konfigurera tillgänglighetszoner för AKS-nodpooler.

Cost

Stöd för tillgänglighetszoner för Application Gateway för containrar medför inte extra avgifter utöver standardpriser för tjänster. Mer information om priser finns i Azure Application Gateway prissättning.

Konfigurera stöd för tillgänglighetszoner

När du distribuerar en ny gateway i en region som stöds är den zonredundant som standard. Du behöver inte aktivera zonredundans för Azure resurser.

Du ansvarar för att konfigurera kubernetes-kluster, ALB-styrenhet och backend-arbetslaster för zonresiliens.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du distribuerar Application Gateway för containrar i en region som stöder tillgänglighetszoner och alla zoner som används av tjänsten fungerar.

  • Drift över flera zoner: Det Azure-hanterade dataplanet för Application Gateway for Containers distribuerar inkommande begäranden över infrastrukturen i flera zoner.

    Du ansvarar för att konfigurera dina backend-arbetsbelastningar så att de körs över zoner och tillhandahåller fungerande mål för att ta emot den trafiken.

  • Datareplikering mellan zoner: Application Gateway för containrar lagrar inte programdata. Plattformen hanterar konfigurationstillståndet via det zonredundanta kontrollplanet för att ge beständighet och motståndskraft.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du distribuerar Application Gateway för containrar i en region som stöder tillgänglighetszoner och en av de zoner som används av tjänsten har ett avbrott.

  • Identifiering och åtgärd: Application Gateway för containrar omdirigerar trafik till infrastruktur i återstående felfria zoner under ett zonfel. Du behöver inte vidta åtgärder för gatewayens omfördelning av trafik.

    Du ansvarar dock för effekten av avbrottet på ditt Kubernetes-kluster och backendapplikationer.

  • Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.
  • Aktiva förfrågningar: Befintliga anslutningar till zonen som har slutat fungera tas bort. Klienter bör skicka begärandena igen genom att följa vägledningen i Motståndskraft mot tillfälliga fel. Nya anslutningar upprättas till infrastrukturen i de återstående felfria zonerna.

  • Förväntad dataförlust: Application Gateway för containrar lagrar inte programdata. Plattformen hanterar konfigurationstillståndet via det zonredundanta kontrollplanet för att ge beständighet och motståndskraft.

  • Förväntad stilleståndstid: Klienter kan uppleva ett kort avbrott när anslutningar till zonen som drabbats av fel avbryts. Klienter bör försöka skicka begärandena igen för att upprätta nya anslutningar till infrastrukturen i de återstående felfria zonerna.

    Det Azure-hanterade kontrollplanet är fortfarande tillgängligt under ett avbrott i en enskild zon. Men din möjlighet att tillämpa konfigurationsuppdateringar beror också på tillgängligheten för ditt Kubernetes-kontrollplan och din ALB-styrenhet.

  • Omfördelning: Application Gateway för containrar omdirigerar trafik till infrastruktur i återstående felfria zoner.

Zonåterställning

Application Gateway för containrar återställs själv från bakomliggande fel. Azure hanterar återställning av gatewayinfrastrukturen.

Test för zonfel

Application Gateway for Containers-plattformen hanterar trafikroutning och hantering vid zonfel för själva gatewayen. Du behöver inte initiera eller hantera gatewayens svar. Om du har ett Kubernetes-kluster som du hanterar kan du använda Azure Chaos Studio för att testa klustrets svar på zonfel. Mer information finns i Testa resiliens för tillgänglighetszoner.

Motståndskraft mot regionomfattande fel

Application Gateway för containrar är en tjänst i en enda region. Om den Azure-region där du driftsatte en gateway blir otillgänglig är gatewayen inte tillgänglig.

Anpassade lösningar för flera regioner för återhämtning

Application Gateway for Containers tillhandahåller inte någon inbyggd lösning för driftsättning i flera regioner eller redundans. Om du vill hantera avbrott i en region installerar och konfigurerar du en separat gateway och ett Kubernetes-kluster i varje region. Du ansvarar för att dirigera trafik mellan de regionala gatewayerna och konfigurera växling vid fel.

  • Konfigurera Application Gateway för containrar konsekvent mellan regioner. För att förenkla driftsättningar och hålla konfigurationerna synkroniserade definierar du din infrastruktur som kod (IaC) med hjälp av verktyg som Bicep eller Terraform.

  • Välj och konfigurera en global trafikhanteringstjänst, till exempel Azure Front Door eller Azure Traffic Manager, för att dirigera klienter till dina regionala gatewayer. Dessa tjänster använder olika routningsmodeller och konfigurationer för hälsoavsökning. Konfigurera den valda tjänsten för att dirigera trafik bort från en otillgänglig gateway och granska dess dokumentation för att förstå routningsbeteende och överväganden kring redundansväxling. Azure Front Door innehåller även funktioner som DDoS-skydd (Distribuerad denial-of-service), waf-funktioner (web application firewall) och regelbaserad routning.

  • Distribuera dina backendapplikationer i varje region och konfigurera dem för att tillhandahålla fungerande arbetsbelastningar under ett avbrott. Om dina program är beroende av data eller andra Azure tjänster, utforma och konfigurera även tjänsterna för tillgänglighet i flera regioner. Granska tillförlitlighetsvägledningen för varje tjänst för att förstå dess multiregionalternativ och begränsningar.

Säkerhetskopiering och återställning

Application Gateway for Containers lagrar inte programdata. Azure Resource Manager lagrar gatewayens Azure resurskonfiguration. Du kan återskapa dessa resurser genom att driftsätta deras konfiguration igen.

Du ansvarar för att bevara de konfigurations- och Kubernetes-resurser som definierar hur gatewayen driftsätts och dirigerar trafik:

  • Definiera Azure resurser och deras inställningar i infrastruktur som kod (IaC), till exempel Bicep eller Terraform, och behåll definitionerna i versionskontroll. Du kan använda dem för att omdistribuera gatewayresurserna.

  • Säkerhetskopiera Kubernetes-resurser som konfigurerar gatewayen, till exempel ApplicationLoadBalancer, Gatewayoch HTTPRoute resurser. Återställ dem till klustret när du behöver återskapa routningskonfigurationen.

  • Behåll relaterad konfiguration, inklusive anpassade regler och principer för brandvägg för webbapplikationer, i versionskontroll eller genom din standardkonfigurationssäkerhetskopieringsprocess. Du kan använda distributionspipelines för att återskapa Azure- och Kubernetes-resurserna konsekvent.

Motståndskraft mot serviceunderhåll

Microsoft hanterar underhåll för Application Gateway för containrar samtidigt som tjänstens höga tillgänglighet bibehålls.

Den minsta undernätsstorlek på /24 som krävs för varje association tar hänsyn till underhållsfönster, så du behöver inte allokera extra IP-adressutrymme för undernätet för underhåll.

Mer information finns i Skalning och tillgänglighet för Application Gateway för containrar.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Serviceavtalet Application Gateway for Containers mäter kontrollplanet och dataplanet separat. Båda planen räknas in i den övergripande SLA-beräkningen.