Hantera moderna programplattformskluster

  • Artikel

Den Cloud Adoption Framework tillhandahåller en grundläggande metod för att definiera processer för driftshantering för molnet på ett oberoende sätt. Vägledningen hjälper dig att upprätta en baslinje för drifthantering och andra specialiserade driftlager. Den här vägledningen kan fortfarande gälla för organisationer som har en blandning av infrastruktur som en tjänst (IaaS), plattform som en tjänst (PaaS) och containerbaserade arbetsbelastningar. Den här artikeln beskriver vad du behöver integrera i dina befintliga åtgärder för att förbereda för containerhantering. Den belyser också fördelarna med att integrera Azure Kubernetes Service (AKS) i din strategi för containerhantering.

Verksamhetsanpassning för drifthanteringsbehov

Containrar tar bort beroenden på flera infrastrukturlager, vilket leder till förbättrade funktioner för drifthantering. För att kunna genomföra dessa operativa förbättringar kan du behöva ändra din övergripande strategi för molnhantering, från och med affärsanpassningen.

För att upprätta lämpliga metoder för driftshantering måste du förstå hur containrar kommer att användas i dina molnimplementeringsplaner och vilka fördelar du vill dra av från det här skiftet till containerbaserade arbetsbelastningar.

  • Kommer du att hantera flera tekniklösningar, till exempel containrar, IaaS och PaaS, på din molnplattform?
  • Kommer centraliserade team att stödja drift och hantering av containern eller AKS-plattformen? Flyttas ansvaret till de enskilda arbetsbelastningsteamen?
  • Kommer centraliserade team att stödja åtgärder och hantering av de arbetsbelastningar som körs i varje container eller podd? Flyttas ansvaret till de enskilda arbetsbelastningsteamen?
  • Använder du containrar för verksamhetskritiska arbetsbelastningar?
  • Använder du bara containrar för mindre kritiska arbetsbelastningar eller verktygsarbetsbelastningar för att minska kostnaderna?
  • Hur viktigt är prestanda och tillförlitlighet för dina enskilda arbetsbelastningar?
  • Är programmen i containrarna tillståndslösa? Behöver du bevara tillståndet för att skydda och återställa arbetsbelastningarna i containrarna?

Dessa grundläggande frågor beskriver hur du bäst integrerar containrar och AKS i din strategi för driftshantering.

Åtgärdsbaslinje

Implementering av en åtgärdsbaslinje ger centraliserad åtkomst till de verktyg som krävs för att driva och hantera alla tillgångar i din molnmiljö. Om du inte har en driftsbaslinje för dina icke-containerbaserade tillgångar kan du implementera den baslinje för åtgärder som definieras i metoden Hantera.

Din driftbaslinje bör innehålla verktyg och konfigurationer för att ge synlighet, övervakning, driftsefterlevnad, optimering och skydd/återställning.

Baslinje för drifthantering

Den driftbaslinje som beskrivs i artiklarna ovan ger inte stöd för dina containrar eller AKS-plattformen. Den tillhandahåller dock den verktygsgrund som kan utökas för att stödja containrar, till exempel Azure Monitor, Azure Backup och andra verktyg.

Om större delen av din portfölj i molnet finns i containrar bör du överväga att inkludera de specialiserade plattformsåtgärderna i nästa avsnitt i din driftbaslinje.

Plattformsdrift

Såvida inte den här implementeringen är din organisations första eller enda distribution till molnet bör du ha en baslinje för åtgärder. Det här avsnittet innehåller några verktyg som du kanske vill inkludera för att hantera container- eller AKS-distribution.

Inventering och synlighet

Övervakningscontainrar och AKS-kluster använder de verktyg, instrumentpaneler och aviseringar som ingår i din driftbaslinje. Du kan dock behöva göra mer konfiguration för att hämta data från dina containrar till verktyg för driftövervakning, till exempel Azure Monitor för containrar. Se översikten över Azure Monitor för containrar för att samla in de data som behövs för att lägga till container- och AKS-plattformsåtgärder i din driftbaslinje.

När du har konfigurerat Azure Monitor för att samla in data på dina containrar kan du övervaka följande områden som en del av dina centraliserade hanteringsprocesser:

  • Identifiera kluster som körs i olika regioner, helst knutna till en tjänstträdsinmatning och identifiera viktiga fakta i dessa kluster
    • Identifiera klusternodpooler, nätverk och lagringstopologier för dessa kluster
    • Identifiera stratifiering av AKS-version och nodbildversion.
  • Identifiera resursutnyttjande för klusternoder (process, minne och lagring)
  • Identifiera containrar som körs på noderna och deras bidrag till nodanvändningen
  • Förstå beteendet för kluster under genomsnittliga och tyngsta belastningar. Den här kunskapen kan hjälpa dig att identifiera kapacitetsbehov och fastställa den maximala belastning som klustret kan hantera.
  • Konfigurera aviseringar för att proaktivt meddela dig eller registrera när processor- och minnesanvändningen på noder eller containrar överskrider dina tröskelvärden, eller när en ändring av hälsotillståndet sker i klustret i infrastrukturen eller nodernas samlade hälsotillstånd.
  • Använd frågor för att skapa en gemensam uppsättning aviseringar, instrumentpaneler och detaljerad analys

Dessa data stöder även arbetsbelastningsåtgärder genom att tillhandahålla detaljerad information om de arbetsbelastningar som körs på den containerbaserade plattformen:

  • Granska resursutnyttjandet för arbetsbelastningar som körs på värden som inte är relaterade till standardprocesserna som stöder podden.
  • Integrera med Prometheus för att visa programmått.
  • Övervaka containerarbetsbelastningar som distribuerats till AKS-motorn lokalt och AKS-motorn i Azure Stack.
  • Övervaka containerarbetsbelastningar som distribuerats till Azure Red Hat OpenShift.
  • Övervaka containerarbetsbelastningar som distribuerats till Azure Arc-aktiverade Kubernetes (förhandsversion).

Driftefterlevnad

Korrigering, justering och storleksändring sker på några olika nivåer i en containerbaserad miljö. Operatörerna kan sitta i ett antal olika team, beroende på din önskade driftsmetod. För att upprätthålla driftsefterlevnad övervakar en operatör användningen, ändrar storlek på tillgångar för att balansera prestanda och kostnader och korrigerar de underliggande systemen för att minimera risker och konfigurationsavvikelser. Centrala IT-organisationer brukar leverera dessa uppgifter som en del av driftbaslinjen för IaaS- och PaaS-lösningar.

I en klustermiljö i Azure utförs dessa uppgifter på flera nivåer: AKS-kluster, nodavbildning och nodoperativsystem. Alla dessa åtgärder blir mer beroende av en förståelse och arbetsrelation för de arbetsbelastningar som körs i klustren eller på enskilda nodpooler. Följande instruktioner hjälper dig att utvärdera vad och om du vill göra för att använda dina containermiljöer.

  • Om storleksändringen och korrigeringen av AKS-klustret, nodavbildningen eller nodoperativsystemet levereras som en del av distributionspipelinen för programmet eller är beroende av programarkitektur eller konfiguration, är det bäst att flytta driftskompatibiliteten till arbetsbelastningsteamet för detaljerad kontroll. Eftersom arbetsbelastningar ofta är beroende av orkestreringsfunktioner är detta det vanligaste mönstret eftersom en oväntad ändring av AKS-versionen eller ändring av nodavbildningen kan vara katastrofal för arbetsbelastningen eller dess körningsverktyg.
  • För de mindre vanliga centraliserade klustren, som stöder en portfölj med arbetsbelastningar och en mängd olika program, kan det centraliserade åtgärdsteamet fortfarande ansvara för driftsefterlevnadsuppgifter. Följande guider hjälper dig att leverera dessa uppgifter i klustren. Att utföra dessa uppgifter regelbundet ingjuter plattformsspecifika åtgärder. Det finns en betydande risk i en central driftsmetod, och noggrann testning av uppgraderingar i förproduktionsmiljöer, tydligt och efterlevt schemalagt underhåll och beredskapsplaner för inkompatibla arbetsbelastningar måste alla finnas på plats. En felaktig uppgradering kan vara en felkritisk systemdel och på samma sätt kan en arbetsbelastning som inte kan uppgraderas göra att ett kluster inte stöds. Planera och hantera kluster för flera klientorganisationer med due diligence.

För båda klustertyperna följer du anvisningarna för uppgraderingar, nodavbildningar och uppdateringar av nodoperativsystem som finns nedan:

Skydda och återställa

AKS-noder är tillfälliga till sin natur och säkerhetskopieras därför inte på ett sätt som kan återställas individuellt. Återställning från en incident kan innebära att omdistribuera arbetsbelastningar till en ny nodpool eller ett helt nytt kluster beroende på incidentens omfattning.

  • Välj att lägga till ett serviceavtal för drifttid i klustret.
  • För högre serviceavtal kan du också överväga metodtips för BCDR i flera regioner för att ge ytterligare skydd.
  • Eftersom kluster inte ska innehålla tillstånd hanteras återställning av externt tillstånd med hjälp av befintliga riktlinjer för driftbaslinje. Om du förde in tillstånd i klustren ser du till att du följer operatorernas bästa praxis för lagring och har en strategi för att säkerhetskopiera och återställa dessa data för en viss arbetsbelastning. Användning av verktyg som Velero är ett exempel på plattformsspecifika åtgärder som utökar baslinjen för din verksamhet.
    • Om programportföljen tillämpas inkonsekvent bör det centrala driftteamet inte försöka underhålla båda lösningarna. Standardisera i stället verktygskedjan för önskat tillstånd för alla containrar, men flytta ansvaret för alternativa återställningslösningar till teamen för arbetsbelastningsåtgärder. Den här metoden ger utvecklarna designfrihet, håller nere de centrala kostnaderna och ger arbetsbelastningsteamen ett incitament att minska kostnaderna så att de uppfyller standarden.

Arbetsbelastningsdrift

Avsnittet om plattformsåtgärder ovan illustrerar en gemensam konversation när du hanterar AKS-kluster. Är Kubernetes-kluster en teknikplattform som ska hanteras centralt? Eller är de ett arbetsbelastningsverktyg som ska hanteras av de team som äger var och en av arbetsbelastningarna? Den frågan är annorlunda för olika organisationer. Konstanten i de flesta organisationer är att containrar och AKS är utformade för att ge arbetsbelastningsteamen större flexibilitet i hur de vill använda varje arbetsbelastning och tillhandahålla specifika funktioner som dessa arbetsbelastningar kan använda i sin arkitektur för att gynna programmets ägare och kunder.

Arbetsbelastningsåtgärder kan bygga på din befintliga driftbaslinje och plattformsspecifika åtgärder. Du kan också använda ett AKS-kluster på ett säkert sätt med helt decentraliserade arbetsbelastningsåtgärder. I båda fallen, när du behöver höja åtgärder för att fokusera på specifika resultat för en viss arbetsbelastning, kan du använda Azure Well-Architected Framework och Microsoft Azure Well-Architected Review för att få mycket specifik information om vilka typer av operativa processer och verktyg som ska användas för din arbetsbelastning.

Nästa steg: Nästa iteration för migrering

När migreringen av den moderna programplattformen är klar kan molnimplementeringsteamet påbörja nästa scenariospecifika migrering. Om det finns tilläggsplattformar som ska migreras kan den här artikelserien användas igen för att vägleda din nästa moderna programplattformsmigrering eller distribution.