Styra moderna programplattformslösningar

  • Artikel

Cloud Adoption Framework tillhandahåller en metod för att systematiskt och stegvis förbättra styrningen av din molnportfölj. Den här artikeln visar hur du kan utöka styrningsmetoden till Kubernetes-kluster som distribuerats till Azure eller andra offentliga eller privata moln.

Initial styrningsgrund

Styrningen börjar med en inledande styrningsgrund som ofta kallas en styrnings-MVP. Den här grunden distribuerar de grundläggande Azure-produkter som krävs för att leverera styrning i din molnmiljö.

Den inledande styrningsgrunden fokuserar på följande aspekter av styrningen:

  • Grundläggande hybridnätverk och -anslutning.
  • Rollbaserad åtkomstkontroll i Azure (RBAC) för identitets- och åtkomstkontroll.
  • Namngivnings- och taggningsstandarder för konsekvent identifiering av resurser.
  • Organisation av resurser med hjälp av resursgrupper, prenumerationer och hanteringsgrupper.
  • Azure Policy och Azure Blueprints för att tillämpa styrningsprinciper.

Dessa funktioner i den första styrningsgrunden kan användas för att styra moderna programplattformslösningsinstanser. Men först måste du lägga till några komponenter i den första grunden för att tillämpa Azure Policy på dina containrar. När du har konfigurerat kan du använda Azure Policy och din ursprungliga styrningsgrund för att styra följande typer av containrar:

Utöka styrningsområden

Den inledande styrningsgrunden kan användas för att utöka olika styrningsområden för att säkerställa konsekventa och stabila distributionsmetoder för alla dina Kubernetes-instanser.

Styrning av Kubernetes-kluster kan ses över med fem distinkta perspektiv.

Azure-resursstyrning

Den första är Azure-resursperspektivet. Se till att alla kluster följer organisationens krav. Detta omfattar begrepp som nätverkstopologi, privat kluster, Azure RBAC-roller för SRE-team, diagnostikinställningar, regiontillgänglighet, överväganden för nodpooler, Azure Container Registry-styrning, Azure Load Balancer-alternativ, AKS-tillägg, diagnostikinställningar och så vidare. Den här styrningen säkerställer konsekvens i "look and feel" och "topologi" för kluster i dina organisationer. Detta bör även omfatta startsteg för distribution efter kluster, till exempel vilka säkerhetsagenter som måste installeras och hur de ska konfigureras.

Snowflake-kluster är svåra att styra i någon central kapacitet. Minimera avvikelser mellan kluster så att principer kan tillämpas enhetligt och avvikande kluster avskräcks och kan identifieras. Detta kan även omfatta tekniker som används för att distribuera kluster, till exempel ARM, Bicep eller Terraform.

Azure Policy som tillämpas på hanteringsgrupp/prenumerationsnivå kan hjälpa dig att leverera många av dessa överväganden, men inte alla.

Kubernetes-arbetsbelastningsstyrning

Eftersom Kubernetes i sig är en plattform är den andra styrningen av vad som händer i ett kluster. Detta skulle omfatta saker som vägledning för namnområden, nätverksprinciper, Kubernetes RBAC, gränser och kvoter. Detta skulle vara styrning som tillämpas på arbetsbelastningarna, mindre för klustret. Varje arbetsbelastning kommer att vara unik, eftersom de alla löser olika affärsproblem och kommer att implementeras på olika sätt med olika tekniker. Det kanske inte finns många styrningsmetoder för "en storlek passar alla", men du bör överväga styrning kring SKAPANDE/förbrukning av OCI-artefakt, krav för leveranskedjan, användning av offentliga containerregister, avbildningskvarningsprocess, styrning av distributionspipeline.

Överväg att standardisera kring vanliga verktyg och mönster också, om det är praktiskt möjligt att göra det. Ge rekommendationer om tekniker som Helm, service mesh, ingresskontrollanter, GitOps-operatorer, beständiga volymer och så vidare. Här ingår även styrning kring användning av poddhanterad identitet och källhemligheter från Key Vault.

Skapa starka förväntningar kring åtkomst till telemetri för att säkerställa att arbetsbelastningsägare har lämplig åtkomst till de mått och data de behöver för att förbättra sin produkt, samtidigt som klusteroperatörer har åtkomst till systemtelemetri för att förbättra sitt tjänsterbjudande. Data måste ofta korskorreleras mellan de två, se till att styrningsprinciper finns på plats för att säkerställa lämplig åtkomst vid behov.

Azure Policy för AKS som tillämpas på klusternivå kan hjälpa till att leverera några av dessa, men inte alla.

Klusteroperatorroller (DevOps, SRE)

Den tredje är styrning kring klusteroperatorroller. Hur interagerar SRE-team med kluster? Vad är relationen mellan det teamet och arbetsbelastningsteamet. Är de likadana? Klusteroperatorer bör ha en tydligt definierad spelbok för klustertriageaktiviteter, till exempel hur de kommer åt klustren, var de kommer åt klustren och vilka behörigheter de har på klustren och när är dessa behörigheter tilldelade. Se till att eventuella skillnader görs i styrningsdokumentationen, policyn och utbildningsmaterialen kring arbetsbelastningsoperatorn jämfört med klusteroperatorn i det här sammanhanget. Beroende på din organisation kan de vara desamma.

Kluster per arbetsbelastning eller många arbetsbelastningar per kluster

Den fjärde är styrning av flera klientorganisationer. Det vill säga om kluster innehåller en "liknande gruppering" av program som per definition ägs av samma arbetsbelastningsteam och representerar en enda uppsättning relaterade arbetsbelastningskomponenter. Eller om kluster avsiktligt ska ha flera klientorganisationer med flera olika arbetsbelastningar och arbetsbelastningsägare. körs och styrs som ett hanterat tjänsterbjudande inom organisationen. Styrningsstrategin skiljer sig särskilt åt för var och en, och därför bör du styra att din valda strategi tillämpas. Om du behöver stöd för båda modellerna kontrollerar du att styrningsplanen är tydligt definierad för vilka principer som gäller för vilka typer av kluster.

Detta val borde ha gjorts under strategifasen eftersom det har betydande inverkan på personal, budgetering och innovation.

Håll dig uppdaterad

Den femte handlar om åtgärder, till exempel nodbildsåterhämtning (korrigering) och Kubernetes-versionshantering. Vem ansvarar för nodavbildningsuppgraderingar, spårning av tillämpade korrigeringar, spårning och sammanställa reparationsplaner för Kubernetes och AKS vanliga sårbarheter och exponeringar? Arbetsbelastningsteamen måste vara involverade i att verifiera att deras lösning fungerar vid klusteruppgraderingar, och om dina kluster inte är aktuella kommer de att falla ur Azure-supporten. Att ha en stark styrning kring "håll dig uppdaterad" är viktigt i AKS, mer så de flesta andra plattformar i Azure. Detta kommer att kräva en mycket nära arbetsrelation med programteam och dedikerad tid av dem, åtminstone varje månad, för arbetsbelastningsverifiering för att säkerställa att kluster förblir aktuella. Se till att alla team som är beroende av Kubernetes förstår kraven och kostnaderna för denna pågående insats, som kommer att pågå så länge de finns på plattformen.

Säkerhetsbaslinje

Följande metodtips kan läggas till i säkerhetsbaslinjen för att ta hänsyn till säkerheten för dina AKS-kluster:

Identitet

Det finns många metodtips som du kan använda för din identitetsbaslinje för att säkerställa konsekvent identitets- och åtkomsthantering i dina Kubernetes-kluster:

Nästa steg: Hantera moderna programplattformslösningar

Följande artiklar tar dig till vägledning vid specifika tidpunkter i molnimplementeringsresan för att hjälpa dig att lyckas i scenariot för molnimplementering.