Dela via

Överväganden för hantering av åtgärder för Azure Kubernetes Service

  • Artikel

Kubernetes är en relativt ny teknik som utvecklas snabbt med ett imponerande ekosystem. Därför kan det vara svårt att hantera och skydda det.

Driftbaslinje för AKS

Du kan arbeta mot driftseffektivitet och kundframgång genom att utforma din Azure Kubernetes Service-lösning (AKS) med hantering och övervakning i åtanke.

Utformningsbeaktanden

Överväg följande faktorer:

  • Var medveten om AKS-gränser. Använd flera AKS-instanser för att skala utanför dessa gränser.
  • Tänk på olika sätt att isolera arbetsbelastningar logiskt i ett kluster och fysiskt i separata kluster.
  • Tänk på olika sätt att styra resursförbrukningen efter arbetsbelastningar.
  • Tänk på olika sätt att hjälpa Kubernetes att förstå hälsotillståndet för dina arbetsbelastningar.
  • Var medveten om olika storlekar på virtuella datorer och effekten av att använda den ena eller den andra datorn. Större virtuella datorer kan hantera mer belastning. Mindre virtuella datorer kan lättare ersättas av andra när de inte är tillgängliga för planerat och oplanerat underhåll. Tänk också på nodpooler och virtuella datorer i en skalningsuppsättning som tillåter virtuella datorer av olika storlekar i samma kluster. Större virtuella datorer är mer optimala eftersom AKS reserverar en mindre andel av sina resurser, vilket gör mer av dess resurser tillgängliga för dina arbetsbelastningar.
  • Tänk på olika sätt att övervaka och logga AKS. Kubernetes består av olika komponenter, och övervakning och loggning bör ge insikt i dess hälsa, trender och potentiella problem.
  • Med hjälp av övervakning och loggning kan det finnas många händelser som genereras av Kubernetes eller program som körs ovanpå. Aviseringar kan hjälpa till att skilja mellan loggposter för historiska ändamål och de som kräver omedelbara åtgärder.
  • Var medveten om uppdateringar och uppgraderingar som du bör göra. På Kubernetes-nivå finns det större versioner, mindre versioner och korrigeringsversioner. Kunden bör tillämpa dessa uppdateringar för att fortsätta att stödjas enligt principen i överordnad Kubernetes. På arbetsvärdnivå kan operativsystemets kernelkorrigeringar kräva en omstart, vilket kunden bör göra, och uppgradera till nya os-versioner. Förutom att uppgradera ett kluster manuellt kan du ange en kanal för automatisk uppgradering i klustret.
  • Tänk på klustrets resursbegränsningar och enskilda arbetsbelastningar.
  • Var medveten om skillnaderna mellan horisontell autoskalning av poddar och autoskalning av kluster
  • Överväg att skydda trafik mellan poddar med hjälp av nätverksprinciper och plugin-programmet för Azure-principer
  • För att felsöka program och tjänster som körs på AKS kan du behöva visa loggarna som genereras av kontrollplanskomponenter. Du kanske vill aktivera resursloggar för AKS eftersom loggning inte är aktiverat som standard.

Rekommendationer

  • Förstå AKS-gränser:

  • Använd logisk isolering på namnområdesnivå för att separera program, team, miljöer och affärsenheter. Isolering av flera klientorganisationer och kluster. Dessutom kan nodpooler hjälpa till vid noder med olika nodspecifikationer och underhåll som Kubernetes uppgraderar flera nodpooler

  • Planera och tillämpa resurskvoter på namnområdesnivå. Om poddar inte definierar resursbegäranden och begränsningar avvisar du distributionen med hjälp av principer och så vidare. Detta gäller inte kube-system poddar eftersom inte alla kube-system poddar har begäranden och gränser. Övervaka resursanvändningen och justera kvoterna efter behov. Grundläggande scheduler-funktioner

  • Lägg till hälsoavsökningar i dina poddar. Kontrollera att poddar innehåller livenessProbe, readinessProbeoch startupProbe AKS-hälsoavsökningar.

  • Använd VM-storlekar som är tillräckligt stora för att innehålla flera containerinstanser, så att du får fördelarna med ökad densitet, men inte så stor att klustret inte kan hantera arbetsbelastningen för en nod som misslyckas.

  • Använd en övervakningslösning. Azure Monitor-containerinsikter konfigureras som standard och ger enkel åtkomst till många insikter. Du kan använda Prometheus-integrering om du vill öka detaljnivån eller få erfarenhet av att använda Prometheus. Om du också vill köra ett övervakningsprogram på AKS bör du även använda Azure Monitor för att övervaka programmet.

  • Använd måttaviseringar för Azure Monitor-containerinsikter för att ge meddelanden när saker behöver direktåtgärder.

  • Använd funktionen för automatisk skalning av nodpooler tillsammans med horisontell autoskalning av poddar för att uppfylla programmets krav och för att minska belastningen på hög belastning.

  • Använd Azure Advisor för att få rekommendationer om bästa praxis för kostnad, säkerhet, tillförlitlighet, driftskvalitet och prestanda. Använd även Microsoft Defender för molnet för att förhindra och identifiera hot som bildsårbarheter.

  • Använd Azure Arc-aktiverade Kubernetes för att hantera Kubernetes-kluster som inte är AKS i Azure med hjälp av Azure Policy, Defender för molnet, GitOps och så vidare.

  • Använd poddbegäranden och gränser för att hantera beräkningsresurserna i ett AKS-kluster. Poddbegäranden och begränsningar informerar Kubernetes-schemaläggaren om vilka beräkningsresurser som ska tilldelas till en podd.

Affärskontinuitet/haveriberedskap för att skydda och återställa AKS

Din organisation måste utforma lämpliga funktioner på plattformsnivå för Azure Kubernetes Service (AKS) för att uppfylla sina specifika krav. Dessa programtjänster har krav relaterade till mål för återställningstid (RTO) och mål för återställningspunkter (RPO). Det finns flera saker att tänka på när det gäller haveriberedskap för AKS. Ditt första steg är att definiera ett serviceavtal (SLA) för din infrastruktur och ditt program. Lär dig mer om serviceavtalet för Azure Kubernetes Service (AKS). Mer information om månatliga drifttidsberäkningar finns i avsnittet SLA-information .

Utformningsbeaktanden

Överväg följande faktorer:

  • AKS-klustret bör använda flera noder i en nodpool för att tillhandahålla den lägsta tillgänglighetsnivån för ditt program.

  • Ange poddbegäranden och gränser. Om du ställer in dessa gränser kan Kubernetes:

    • Ge effektivt processor- och minnesresurser till poddarna.
    • Ha högre containerdensitet på en nod.

    Begränsningar kan också öka tillförlitligheten med minskade kostnader på grund av bättre användning av maskinvara.

  • AKS-lämplighet för tillgänglighetszoner eller tillgänglighetsuppsättningar.

    • Välj en region som stöder tillgänglighetszoner.
    • Tillgänglighetszoner kan bara anges när nodpoolen skapas och kan inte ändras senare. Multizone-stöd gäller endast för nodpooler.
    • För fullständig zonindelningsförmån måste alla tjänstberoenden också ha stöd för zoner. Om en beroende tjänst inte stöder zoner kan ett zonfel orsaka att tjänsten misslyckas.
    • Kör flera AKS-kluster i olika parkopplade regioner för högre tillgänglighet utöver vad tillgänglighetszoner kan uppnå. Om en Azure-resurs stöder geo-redundans anger du den plats där den redundanta tjänsten har sin sekundära region.

  • Du bör känna till riktlinjerna för haveriberedskap i AKS. Fundera sedan på om de gäller för de AKS-kluster som du använder för Azure Dev Spaces.

  • Skapa säkerhetskopior för program och data konsekvent.

    • En icke-tillståndskänslig tjänst kan replikeras effektivt.
    • Om du behöver lagra tillståndet i klustret säkerhetskopierar du data ofta i den parkopplade regionen. Ett övervägande är att korrekt lagringstillstånd i klustret kan vara komplicerat.

  • Uppdatering och underhåll av kluster.

    • Håll alltid klustret uppdaterat.
    • Var medveten om lanserings- och utfasningsprocessen.
    • Planera dina uppdateringar och underhåll.

  • Nätverksanslutning om en redundansväxling inträffar.

    • Välj en trafikrouter som kan distribuera trafik mellan zoner eller regioner, beroende på dina behov. Den här arkitekturen distribuerar Azure Load Balancer eftersom den kan distribuera trafik som inte är webbtrafik mellan zoner.
    • Om du behöver distribuera trafik mellan regioner bör du överväga att använda Azure Front Door.

  • Planerade och oplanerade redundansväxlingar.

    • När du konfigurerar varje Azure-tjänst väljer du funktioner som stöder haveriberedskap. Den här arkitekturen aktiverar till exempel Azure Container Registry för geo-replikering. Du kan fortfarande hämta bilder från den replikerade regionen om en region slutar fungera.

  • Underhåll devops-funktioner för att nå servicenivåmål.

  • Ta reda på om du behöver ett ekonomiskt säkerhetskopierat serviceavtal för kubernetes API-serverslutpunkten.

Designrekommendationer

Följande är metodtips för din design:

  • Använd tre noder för systemnodpoolen. För användarnodpoolen börjar du med inte mindre än två noder. Om du behöver högre tillgänglighet konfigurerar du fler noder.

  • Isolera programmet från systemtjänsterna genom att placera det i en separat nodpool. På så sätt körs Kubernetes-tjänster på dedikerade noder och konkurrerar inte med andra tjänster. Använd taggar, etiketter och taints för att identifiera nodpoolen för att schemalägga din arbetsbelastning.

  • Regelbunden underhåll av klustret, till exempel att göra uppdateringar i tid, är avgörande för tillförlitligheten. Tänk på supportfönstret för Kubernetes-versioner på AKS och planera dina uppdateringar. Dessutom rekommenderas övervakning av poddarnas hälsa via avsökningar.

  • Ta bort tjänsttillstånd från containrar när det är möjligt. Använd i stället en Azure-plattform som en tjänst (PaaS) som stöder replikering i flera regioner.

  • Kontrollera poddresurser. Vi rekommenderar starkt att distributioner anger krav för poddresurser. Schemaläggaren kan sedan schemalägga podden på lämpligt sätt. Tillförlitligheten minskar när poddar inte är schemalagda.

  • Konfigurera flera repliker i distributionen för att hantera störningar som maskinvarufel. För planerade händelser som uppdateringar och uppgraderingar kan en avbrottsbudget säkerställa att det antal poddrepliker som krävs finns för att hantera den förväntade programbelastningen.

  • Dina program kan använda Azure Storage för sina data. Eftersom dina program är spridda över flera AKS-kluster i olika regioner måste du hålla lagringen synkroniserad. Här är två vanliga sätt att replikera lagring:

    • Infrastrukturbaserad asynkron replikering
    • Programbaserad asynkron replikering

  • Uppskatta poddgränser. Testa och upprätta en baslinje. Börja med lika värden för begäranden och gränser. Justera sedan värdena gradvis tills du har fastställt ett tröskelvärde som kan orsaka instabilitet i klustret. Poddgränser kan anges i distributionsmanifesten.

    De inbyggda funktionerna ger en lösning på den komplexa uppgiften att hantera fel och störningar i tjänstarkitekturen. De här konfigurationerna hjälper till att förenkla både design och distributionsautomatisering. När en organisation har definierat en standard för serviceavtalet, RTO och RPO kan den använda inbyggda tjänster till Kubernetes och Azure för att uppnå sina affärsmål.

  • Ange budgetar för poddstörningar. Den här inställningen kontrollerar hur många repliker i en distribution som du kan ta bort under en uppdaterings- eller uppgraderingshändelse.

  • Framtvinga resurskvoter på tjänstnamnrymderna. Resurskvoten på ett namnområde säkerställer att poddbegäranden och gränser har angetts korrekt för en distribution.

    • Om du ställer in resurskvoter på klusternivå kan det orsaka problem när du distribuerar partnertjänster som inte har rätt begäranden och begränsningar.

  • Lagra dina containeravbildningar i Azure Container Registry och geo-replikera registret till varje AKS-region.

  • Använd serviceavtalet för drifttid för att aktivera ett ekonomiskt säkerhetskopierat, högre serviceavtal för alla kluster som är värdar för produktionsarbetsbelastningar. Ett SLA för drifttid garanterar en tillgänglighet på 99,95 procent för Kubernetes API-serverslutpunkt för kluster som använder tillgänglighetszoner, och 99,9 procent för kluster som inte använder tillgänglighetszoner. Dina noder, nodpooler och andra resurser omfattas av deras serviceavtal. AKS erbjuder en kostnadsfri nivå med ett servicenivåmål (SLO) på 99,5 % för dess kontrollplanskomponenter. Kluster utan serviceavtal för drifttid ska inte användas för produktionsarbetsbelastningar.

  • Använd flera regioner och peeringplatser för Azure ExpressRoute-anslutning .

    Om ett avbrott som påverkar en Azure-region eller peeringproviderplats inträffar kan en redundant hybridnätverksarkitektur bidra till att säkerställa oavbruten anslutning mellan platser.

  • Koppla samman regioner med global peering för virtuella nätverk. Om klustren behöver prata med varandra kan du ansluta båda virtuella nätverken till varandra genom peering för virtuella nätverk. Den här tekniken kopplar samman virtuella nätverk med varandra, vilket ger hög bandbredd i Microsofts stamnätverk, även i olika geografiska regioner.

  • Med hjälp av delat TCP-baserat anycast-protokoll ser Azure Front Door till att slutanvändarna snabbt ansluter till närmaste Front Door-plats. Andra funktioner i Azure Front Door är:

    • TLS-avslutning
    • Anpassad domän
    • Brandvägg för webbaserade program
    • URL-omskrivning
    • Sessionstillhörighet

    Granska behoven för din programtrafik för att lära dig vilken lösning som passar bäst.