Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service)

Den här artikeln innehåller en rekommenderad infrastrukturarkitektur för baslinje för att distribuera ett AKS-kluster (Azure Kubernetes Service). Den använder våra designprinciper och baseras på metodtips för AKS-arkitektur från Azure Well-Architected Framework. Den här artikeln hjälper dig att vägleda flera olika tvärvetenskapliga grupper, till exempel nätverk, säkerhet och identitetsteam, när de distribuerar den här allmänna infrastrukturen.

Den här arkitekturen fokuserar inte på en arbetsbelastning. Det koncentrerar sig på SJÄLVA AKS-klustret. Den här informationen är den lägsta rekommenderade baslinjen för de flesta AKS-kluster. Den integreras med Azure-tjänster som levererar observerbarhet, tillhandahåller en nätverkstopologi som stöder tillväxt i flera regioner och säker trafik i klustret.

Dina affärskrav påverkar målarkitekturen och kan variera mellan olika programkontexter. Tänk på arkitekturen som startpunkt för förproduktions- och produktionsfaser.

Du kan använda en implementering av den här arkitekturen på GitHub: AKS-baslinjereferensimplementering. Använd den som en alternativ startpunkt och konfigurera referensarkitekturen baserat på dina behov.

Nätverkskonfiguration

Nätverkstopologi
Planera IP-adresserna
Distribuera inkommande resurser

Klusterberäkning

Beräkning för basklustret
Referens för containeravbildning
Principhantering

Identitetshantering

Integrera Microsoft Entra-ID för klustret
Integrera Microsoft Entra-ID för arbetsbelastningen

Skydda dataflödet

Skydda nätverksflödet
Lägga till hemlig hantering

Verksamhetskontinuitet

Skalbarhet
Kluster- och nodtillgänglighet
Tillgänglighet och stöd för flera regioner

Operations

Kluster- och arbetsbelastnings-CI/CD-pipelines
Klusterhälsa och mått
Kostnadshantering och rapportering

Nätverkstopologi

Den här arkitekturen använder en nätverkstopologi för nav och ekrar. Distribuera hubben och ekrarna i separata virtuella nätverk som är anslutna via peering för virtuella nätverk. Den här topologin har flera fördelar. Använd den här topologin för att:

• Aktivera separat hantering. Du kan tillämpa styrning och följa principen om minsta behörighet. Det stöder också konceptet med en Azure-landningszon med en uppdelning av uppgifter.

• Minimera direkt exponering av Azure-resurser för det offentliga Internet.

• Ange regionala nav- och ekertopologier. Du kan expandera hubb- och ekernätverkstopologier i framtiden och tillhandahålla arbetsbelastningsisolering.

• Använd en brandväggstjänst för webbprogram för att inspektera HTTP-trafikflödet för alla webbprogram.

• Ge stöd för arbetsbelastningar som omfattar flera prenumerationer.

• Gör arkitekturen utökningsbar. För att hantera nya funktioner eller arbetsbelastningar kan du lägga till nya ekrar i stället för att göra om nätverkstopologin.

• Stöd för delning av resurser, till exempel en brandvägg och DNS-zoner (Domain Name System), mellan nätverk.

• Anpassa till landningszonen i Företagsskala i Azure.

Ladda ned en Visio-fil med den här arkitekturen.

Mer information finns i Nätverkstopologi för hub-spoke i Azure.

Mer information om ändringar av nätverksdesignen som ingår i Windows-containrar i AKS-baslinjereferensarkitekturen finns i Windows-containrar på AKS.

Virtuellt hubbnätverk

Det virtuella hubbnätverket är den centrala platsen för anslutning och observerbarhet. I den här arkitekturen innehåller hubben:

• Azure Firewall med globala brandväggsprinciper som definieras av dina centrala IT-team för att framtvinga en brandväggsprincip för hela organisationen.
• Azure Bastion för fjärråtkomst till virtuella datorer (VM).
• Ett gatewayundernät för VPN-anslutning.
• Azure Monitor för nätverksobservabilitet.

Arkitekturen i nätverket har tre undernät.

Undernät som ska vara värd för Azure Firewall

Azure Firewall är en hanterad brandväggstjänst. Azure Firewall-instansen skyddar utgående nätverkstrafik. Utan det här säkerhetsskiktet kan trafiken kommunicera med en skadlig, icke-Microsoft-tjänst som kan exfiltera känsliga arbetsbelastningsdata. Använd Azure Firewall Manager för att centralt distribuera och konfigurera flera Azure Firewall-instanser och hantera Azure Firewall-principer för den här typen av hubbarkitektur för virtuella nätverk .

Undernät som ska vara värd för en gateway

Det här undernätet är en platshållare för en VPN-gateway eller en Azure ExpressRoute-gateway. Gatewayen ger anslutning mellan routrarna i ditt lokala nätverk och det virtuella nätverket.

Undernät som ska vara värd för Azure Bastion

Det här undernätet är en platshållare för Azure Bastion. Du kan använda Azure Bastion för säker åtkomst till Azure-resurser utan att exponera resurserna för Internet. Det här undernätet är endast till för hantering och åtgärder.

Virtuellt ekernätverk

Det virtuella ekernätverket innehåller AKS-klustret och andra relaterade resurser. Ekern har följande undernät.

Undernät som ska vara värd för Azure Application Gateway

Application Gateway är en lastbalanserare för webbtrafik som körs på Layer 7. Referensimplementeringen använder Application Gateway v2 SKU som aktiverar Azure Web Application Firewall. Brandväggen för webbaserade program skyddar inkommande trafik från vanliga webbtrafikattacker, inklusive robotar. Instansen har en offentlig IP-konfiguration för klientdelen som tar emot användarbegäranden. Application Gateway kräver avsiktligt ett dedikerat undernät.

Undernät som ska vara värd för inkommande resurser

För att dirigera och distribuera trafik är Traefik den ingresskontrollant som uppfyller Kubernetes-ingressresurserna. De interna Azure-lastbalanserarna finns i det här undernätet. Mer information finns i Använda en intern lastbalanserare med AKS.

Undernät som ska vara värd för klusternoderna

AKS underhåller två nodpooler, som är separata grupper av noder. Systemnodpoolen är värd för poddar som kör kärnklustertjänster. Användarnodpoolen kör din arbetsbelastning och ingresskontrollanten för att aktivera inkommande kommunikation till arbetsbelastningen.

Undernät som ska vara värd för Azure Private Link-slutpunkter

Skapa Private Link-anslutningar för Azure Container Registry och Azure Key Vault så att användarna kan komma åt dessa tjänster via en privat slutpunkt i det virtuella ekernätverket. Privata slutpunkter kräver inte ett dedikerat undernät. Du kan också placera privata slutpunkter i det virtuella hubbnätverket. I baslinjeimplementeringen distribueras slutpunkterna till ett dedikerat undernät i det virtuella ekernätverket. Den här metoden minskar trafiken som passerar genom den peerkopplade nätverksanslutningen. Den behåller de resurser som tillhör klustret i samma virtuella nätverk. Du kan också tillämpa detaljerade säkerhetsregler på undernätsnivå med hjälp av nätverkssäkerhetsgrupper.

Mer information finns i Distributionsalternativ för Private Link.

Planera IP-adresser

Ladda ned en Visio-fil med den här arkitekturen.

Adressutrymmet för det virtuella nätverket bör vara tillräckligt stort för att rymma alla undernät. Ta hänsyn till alla entiteter som tar emot trafik. Kubernetes allokerar IP-adresser för dessa entiteter från undernätets adressutrymme. Tänk på dessa punkter.

• Uppgraderingar

  AKS uppdaterar noder regelbundet för att se till att de underliggande virtuella datorerna är uppdaterade om säkerhetsfunktioner och andra systemkorrigeringar. Under en uppgraderingsprocess skapar AKS en nod som tillfälligt är värd för poddarna, medan uppgraderingsnoden är avspärrad och tömd. Den tillfälliga noden tilldelas en IP-adress från klustrets undernät. Se till att du har tillräckligt med adressutrymme för dessa tillfälliga nod-IP-adresser.

  För poddar kan du behöva fler adresser beroende på din strategi. För löpande uppdateringar behöver du adresser för de tillfälliga poddar som kör arbetsbelastningen medan de faktiska poddarna uppdateras. Om du använder ersättningsstrategin tas poddar bort och de nya skapas. Adresser som är associerade med de gamla poddarna återanvänds alltså.

• Skalbarhet

  Ta hänsyn till antalet noder för alla system- och användarnoder och deras maximala skalbarhetsgräns. Anta att du vill skala ut med 400 %. Du behöver fyra gånger så många adresser för alla dessa utskalade noder.

  I den här arkitekturen kontaktar resurser varje podd direkt. Varje podd behöver därför en enskild adress. Poddens skalbarhet påverkar adressberäkningen. Det beslutet beror på vilket val du väljer om hur många poddar du vill öka.

• Private Link-adresser

  Ta hänsyn till de adresser som krävs för kommunikation med andra Azure-tjänster via Private Link. Den här arkitekturen har två adresser tilldelade för länkarna till Container Registry och Key Vault.

• Azure reserverar vissa adresser för användning. De kan inte tilldelas.

Föregående lista är inte fullständig. Om din design har andra resurser som påverkar antalet tillgängliga IP-adresser kan du hantera dessa adresser.

Den här arkitekturen är utformad för en enda arbetsbelastning. I ett AKS-produktionskluster separerar du alltid systemnodpoolen från användarnodpoolen. När du kör flera arbetsbelastningar i klustret kanske du vill isolera användarnodpoolerna från varandra. När du gör det resulterar det i fler undernät som är mindre i storlek. Dessutom kan ingressresursen vara mer komplex, och därför kan du behöva flera ingresskontrollanter som kräver extra IP-adresser.

Fullständig uppsättning överväganden för den här arkitekturen finns i AKS-baslinjenätverkstopologi.

Information om hur du planerar IP för ett AKS-kluster finns i Planera IP-adressering för klustret.

Mer information om överväganden för IP-adressplanering som ingår i Windows-containrar i REFERENSarkitekturen för AKS-baslinje finns i Windows-containrar på AKS.

Tilläggs- och förhandsversionsfunktioner

Kubernetes och AKS utvecklas kontinuerligt, med snabbare lanseringscykler än programvara för lokala miljöer. Den här baslinjearkitekturen är beroende av utvalda AKS-förhandsversionsfunktioner och AKS-tillägg. Här är skillnaden mellan de två:

• AKS-teamet beskriver förhandsgranskningsfunktioner som levererade och förbättrade eftersom många av förhandsversionsfunktionerna bara är i det tillståndet i några månader innan de övergår till fasen allmän tillgänglighet (GA).

• AKS-tillägg och tillägg ger extra funktioner som stöds. AKS hanterar installationen, konfigurationen och livscykeln.

Den här baslinjearkitekturen innehåller inte alla förhandsgranskningsfunktioner eller tillägg. I stället innehåller den bara de som lägger till betydande värde i ett allmänt kluster. Eftersom dessa funktioner kommer från förhandsversionen ändras den här baslinjearkitekturen i enlighet med detta. Det finns några andra förhandsversionsfunktioner eller AKS-tillägg som du kanske vill utvärdera i förproduktionskluster. Dessa funktioner kan förbättra din säkerhet, hanterbarhet eller andra krav. Med tillägg som inte kommer från Microsoft måste du installera och underhålla dem, inklusive spårning av tillgängliga versioner och installation av uppdateringar efter uppgradering av kubernetes-versionen för ett kluster.

Referens för containeravbildning

Utöver arbetsbelastningen kan klustret innehålla flera andra avbildningar, till exempel ingresskontrollanten. Vissa av dessa avbildningar kan finnas i offentliga register. Tänk på dessa punkter när du hämtar avbildningarna till klustret.

• Autentisera klustret för att hämta avbildningen.

• Importera en offentlig avbildning till containerregistret som överensstämmer med ditt servicenivåmål (SLO), om du använder en offentlig avbildning. Annars kan avbildningen bli föremål för oväntade tillgänglighetsproblem. Om avbildningen inte är tillgänglig när du behöver den kan det orsaka driftsproblem. Här är några fördelar med att använda ett privat containerregister, till exempel Azure Container Registry, i stället för ett offentligt register:

  • Du kan blockera obehörig åtkomst till dina bilder.
  • Du har inte offentliga beroenden.
  • Du kan komma åt avbildningshämtningsloggar för att övervaka aktiviteter och prioritera anslutningsproblem.
  • Du kan dra nytta av integrerad containergenomsökning och avbildningsefterlevnad.

• Hämta avbildningar från auktoriserade register. Du kan tillämpa den här begränsningen via Azure Policy. I den här referensimplementeringen hämtar klustret endast avbildningar från containerregisterinstansen som distribueras.

Konfigurera beräkning för basklustret

I AKS mappar varje nodpool till en VM-skalningsuppsättning. Noder är virtuella datorer i varje nodpool. Överväg att använda en mindre VM-storlek för systemnodpoolen för att minimera kostnaderna. Den här referensimplementeringen distribuerar systemnodpoolen med tre DS2_v2 noder. Den storleken räcker för att uppfylla den förväntade belastningen på systempoddarna. Operativsystemdisken är 512 GB.

Här följer några överväganden för användarnodpoolen:

• Välj större nodstorlekar för att packa det maximala antalet poddar som angetts på en nod. Stora noder minimerar fotavtrycket för tjänster som körs på alla noder, till exempel övervakning och loggning.

• Välj lämplig typ av virtuell dator om du har specifika arbetsbelastningskrav. Du kan till exempel behöva en minnesoptimerad produkt för vissa arbetsbelastningar eller en GPU-accelererad produkt för andra. Mer information finns i Storlekar för virtuella datorer i Azure.

• Distribuera minst två noder. På så sätt har arbetsbelastningen ett mönster med hög tillgänglighet med två repliker. Med AKS kan du ändra antalet noder utan att återskapa klustret.

• Planera de faktiska nodstorlekarna för din arbetsbelastning baserat på de krav som bestäms av designteamet. Baserat på affärskraven använder den här arkitekturen DS4_v2 för produktionsarbetsbelastningen. Om du vill sänka kostnaderna kan du minska storleken till DS3_v2, vilket är den minsta rekommendationen.

• Anta att din arbetsbelastning förbrukar upp till 80 % av varje nod när du planerar kapacitet för klustret. Återstående 20 % är reserverade för AKS-tjänster.

• Ange maximalt antal poddar per nod baserat på din kapacitetsplanering. Om du försöker upprätta en kapacitetsbaslinje börjar du med värdet 30. Justera det värdet baserat på kraven för arbetsbelastningen, nodstorleken och dina IP-begränsningar.

Integrera Microsoft Entra-ID för klustret

Det är viktigt att skydda åtkomsten till och från klustret. Tänk på det från klustrets perspektiv när du gör säkerhetsval:

• Åtkomst inifrån och ut. Överväg AKS-åtkomst till Azure-komponenter som nätverksinfrastruktur, Container Registry och Key Vault. Auktorisera endast de resurser som klustret ska ha åtkomst till.
• Åtkomst utanför. Ge identiteter åtkomst till Kubernetes-klustret. Auktorisera endast de externa entiteter som har åtkomst till Kubernetes API-servern och Azure Resource Manager.

AKS-åtkomst till Azure

Det finns två sätt att hantera AKS-åtkomst till Azure via Microsoft Entra-ID: tjänstens huvudnamn eller hanterade identiteter för Azure-resurser.

Av de två metoderna för att hantera AKS-åtkomst till Azure rekommenderar vi hanterade identiteter. Med tjänstens huvudnamn måste du hantera och rotera hemligheter, antingen manuellt eller programmatiskt. Med hanterade identiteter hanterar och utför Microsoft Entra-ID autentisering och rätt tidsrotation av hemligheter åt dig.

Vi rekommenderar att du aktiverar och använder hanterade identiteter så att klustret kan interagera med externa Azure-resurser via Microsoft Entra-ID. Även om du inte använder Microsoft Entra ID-integrering omedelbart kan du införliva det senare.

Som standard finns det två primära identiteter som används av klustret: klusteridentiteten och kubelet-identiteten. AKS-kontrollplanskomponenterna använder klusteridentiteten för att hantera klusterresurser, inklusive inkommande lastbalanserare och AKS-hanterade offentliga IP-adresser. Kubelet-identiteten autentiseras med Container Registry. Vissa tillägg stöder även autentisering med hjälp av en hanterad identitet.

Du bör använda hanterade identiteter när klustret behöver hämta avbildningar från ett containerregister. Den här åtgärden kräver att klustret hämtar registrets autentiseringsuppgifter. Om du inte använder en hanterad identitet kan du lagra den informationen i form av ett Kubernetes-hemligt objekt och använda imagePullSecrets för att hämta hemligheten. Vi rekommenderar inte den här metoden på grund av säkerhetskomplexiteter. Du behöver inte bara förkunskaper om hemligheten, du måste också lagra den hemligheten i DevOps-pipelinen. En annan anledning till att vi inte rekommenderar den här metoden är driftkostnaderna för att hantera rotationen av hemligheten. Bevilja AcrPull i stället åtkomst till klustrets kubelet-hanterade identitet till registret. Den här metoden tar itu med problemen.

I den här arkitekturen får klustret åtkomst till Azure-resurser som Microsoft Entra-ID:t skyddar och klustret utför åtgärder som stöder hanterade identiteter. Tilldela rollbaserad åtkomstkontroll i Azure (Azure RBAC) och behörigheter till klustrets hanterade identiteter, beroende på vilka åtgärder klustret utför. Klustret autentiserar sig till Microsoft Entra-ID och tillåts eller nekas sedan åtkomst baserat på de roller som tilldelats det. Här följer några exempel från den här referensimplementeringen där inbyggda Azure-roller tilldelas till klustret:

• Rollen Nätverksdeltagare. Hanterar klustrets möjlighet att styra det virtuella ekernätverket. Med den här rolltilldelningen kan den systemtilldelade AKS-klusteridentiteten fungera med det dedikerade undernätet för den interna ingresskontrollanttjänsten.

• Övervaka rollen Metrics Publisher. Hanterar klustrets möjlighet att skicka mått till Azure Monitor.

• AcrPull-roll. Hanterar klustrets möjlighet att hämta avbildningar från de angivna Azure Container Registry-instanserna.

Klusteråtkomst

Microsoft Entra-integrering förenklar också säkerheten för extern åtkomst. Du kanske till exempel vill använda kubectl. Som ett första steg kan du köra az aks get-credentials kommandot för att hämta autentiseringsuppgifterna för klustret. Microsoft Entra-ID autentiserar din identitet mot de Azure-roller som tillåts hämta klusterautentiseringsuppgifter. Mer information finns i Tillgängliga behörigheter för klusterroller.

AKS stöder Kubernetes-åtkomst med hjälp av Microsoft Entra-ID på två sätt. Det första är att använda Microsoft Entra ID som identitetsprovider integrerad med det interna Kubernetes RBAC-systemet. Den andra metoden använder inbyggd Azure RBAC för att styra klusteråtkomst. I följande avsnitt beskrivs båda metoderna.

Associera Kubernetes RBAC med Microsoft Entra ID

Kubernetes stöder RBAC via:

• En uppsättning behörigheter som du definierar med hjälp av ett Role eller ClusterRole -objekt för klusteromfattande behörigheter.

• Bindningar som tilldelar användare och grupper som har behörighet att utföra åtgärderna. Definiera bindningar med hjälp av ett RoleBinding eller ClusterRoleBinding -objekt.

Kubernetes har vissa inbyggda roller som klusteradministratör, redigering och vy. Binda dessa roller till Microsoft Entra-användare och -grupper för att använda företagskatalogen för att hantera åtkomst. Mer information finns i Använda Kubernetes RBAC med Microsoft Entra-integrering.

Se till att du inkluderar Microsoft Entra-grupperna för kluster- och namnområdesåtkomst i dina Microsoft Entra-åtkomstgranskningar.

Använda Azure RBAC för Kubernetes-auktorisering

I stället för att använda Kubernetes interna RBAC ClusterRoleBindings och RoleBindings för auktorisering med integrerad Microsoft Entra-autentisering rekommenderar vi att du använder Rolltilldelningar i Azure RBAC och Azure. Den här metoden tillämpar auktoriseringskontroller i klustret. Du kan till och med tilldela dessa roller i hanteringsgruppen, prenumerationen eller resursgruppens omfång. Alla kluster under omfånget ärver sedan en konsekvent uppsättning rolltilldelningar med avseende på vem som har behörighet att komma åt objekten i Kubernetes-klustret.

Mer information finns i Azure RBAC för Kubernetes-auktorisering.

Lokala konton

AKS stöder inbyggd Kubernetes-användarautentisering. Vi rekommenderar inte att du använder den här metoden för att ge användare åtkomst till kluster. Den här metoden är certifikatbaserad och utförs externt mot din primära identitetsprovider, vilket gör det svårt att få centraliserad användaråtkomstkontroll och styrning. Hantera alltid åtkomst till klustret med hjälp av Microsoft Entra-ID och konfigurera klustret så att det uttryckligen inaktiverar åtkomst till det lokala kontot.

I den här referensimplementeringen inaktiveras åtkomsten till lokala klusterkonton explicit när systemet distribuerar klustret.

Integrera Microsoft Entra-ID för arbetsbelastningen

På samma sätt som du har en azure-systemtilldelad hanterad identitet för hela klustret kan du tilldela hanterade identiteter på poddnivå. Med en arbetsbelastningsidentitet kan den värdbaserade arbetsbelastningen komma åt resurser via Microsoft Entra-ID. Arbetsbelastningen lagrar till exempel filer i Azure Storage. När den behöver komma åt dessa filer autentiserar podden sig själv mot resursen som en Hanterad Azure-identitet.

I den här referensimplementeringen tillhandahåller Microsoft Entra-arbetsbelastnings-ID på AKS hanterade identiteter för poddar. Den här metoden integreras med kubernetes interna funktioner för att federera med externa identitetsprovidrar. Mer information om Microsoft Entra-arbetsbelastnings-ID-federation finns i Arbetsbelastningsidentitetsfederation.

Distribuera ingångsresurser

Kubernetes ingressresurser hanterar routning och distribution för inkommande trafik till klustret. Det finns två delar av inkommande resurser:

• Den interna lastbalanseraren som hanteras av AKS. Lastbalanseraren exponerar ingresskontrollanten via en privat statisk IP-adress. Den fungerar som en kontaktpunkt som tar emot inkommande flöden.

  Den här arkitekturen använder Azure Load Balancer. Load Balancer ligger utanför klustret i ett undernät som är dedikerat för inkommande resurser. Den tar emot trafik från Application Gateway och kommunikationen sker via TLS (Transport Layer Security). Mer information om TLS-kryptering för inkommande trafik finns i Inkommande trafikflöde.

• Ingresskontrollanten. I det här exemplet används Traefik. Den körs i användarnodpoolen i klustret. Den tar emot trafik från den interna lastbalanseraren, avslutar TLS och vidarebefordrar den till arbetsbelastningspoddarna via HTTP.

Ingresskontrollanten är en viktig komponent i klustret. Tänk på följande när du konfigurerar den här komponenten.

• Begränsa ingresskontrollanten till ett specifikt omfång för åtgärder som en del av dina designbeslut. Du kan till exempel tillåta att kontrollanten endast interagerar med de poddar som kör en specifik arbetsbelastning.

• Undvik att placera repliker på samma nod för att sprida ut belastningen och säkerställa affärskontinuitet om en nod misslyckas. Använd podAntiAffinity för detta ändamål.

• Begränsa att poddar endast schemaläggs i användarnodpoolen med hjälp nodeSelectorsav . Den här inställningen isolerar arbetsbelastningar och systempoddar.

• Öppna portar och protokoll som låter specifika entiteter skicka trafik till ingresskontrollanten. I den här arkitekturen tar Traefik bara emot trafik från Application Gateway.

• Konfigurera readinessProbe och livenessProbe inställningar som övervakar poddarnas hälsotillstånd vid det angivna intervallet. Ingresskontrollanten bör skicka signaler som indikerar poddars hälsa.

• Överväg att begränsa ingresskontrollantens åtkomst till specifika resurser och möjligheten att utföra vissa åtgärder. Du kan implementera den begränsningen via Kubernetes RBAC-behörigheter. I den här arkitekturen har Traefik till exempel behörighet att titta på, hämta och lista tjänster och slutpunkter med hjälp av regler i Kubernetes-objektet ClusterRole .

Mer information om ingressdesignen för Windows-containrar på AKS i referensarkitekturen för baslinjen finns i Windows-containrar på AKS.

Routerinställningar

Ingresskontrollanten använder vägar för att avgöra var trafik ska skickas. Vägar anger källporten där trafiken tas emot och information om målportarna och protokollen.

Här är ett exempel från den här arkitekturen:

Traefik använder Kubernetes-providern för att konfigurera vägar. Alternativen annotations, tlsoch entrypoints anger att vägar hanteras via HTTPS. Alternativet middlewares anger att endast trafik från Application Gateway-undernätet tillåts. Svaren använder gzip-kodning om klienten accepterar det. Eftersom Traefik avslutar TLS sker kommunikationen med serverdelstjänsterna via HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port: 
              number: 80

Skydda nätverksflödet

I den här arkitekturen innehåller nätverksflödet:

• Inkommande trafik från klienten till den arbetsbelastning som körs i klustret.

• Utgående trafik från en podd eller nod i klustret till en extern tjänst.

• Podd-till-podd-trafik mellan poddar. Den här trafiken omfattar kommunikation mellan ingresskontrollanten och arbetsbelastningen. Om din arbetsbelastning består av flera program som distribueras till klustret hamnar kommunikationen mellan dessa program också i den här kategorin.

• Hanteringstrafik mellan klienten och Kubernetes API-servern.

Ladda ned en Visio-fil med den här arkitekturen.

Den här arkitekturen har flera säkerhetslager för att skydda alla typer av trafik.

Inkommande trafikflöde

Arkitekturen accepterar endast TLS-krypterade begäranden från klienten. TLS v1.2 är den lägsta tillåtna versionen med en begränsad uppsättning chiffer. Strikt matchning av servernamnindikering (SNI) är aktiverad. TLS från slutpunkt till slutpunkt konfigureras via Application Gateway med hjälp av två olika TLS-certifikat, enligt följande diagram.

Ladda ned en Visio-fil med den här arkitekturen.

1. Klienten skickar en HTTPS-begäran till domännamnet: bicycle.contoso.com. Det namnet är associerat med en DNS A-post till application gatewayens offentliga IP-adress. Den här trafiken krypteras för att säkerställa att trafiken mellan klientwebbläsaren och gatewayen inte kan inspekteras eller ändras.

2. Application Gateway har en integrerad brandvägg för webbprogram och förhandlar om TLS-handskakningen för bicycle.contoso.com, vilket endast tillåter säkra chiffer. Application Gateway är en TLS-avslutningspunkt, vilket är viktigt eftersom Application Gateways brandvägg för webbprogram måste inspektera klartextsvaret. Key Vault lagrar TLS-certifikatet. Klustret kommer åt det med en användartilldelad hanterad identitet som är integrerad med Application Gateway. Läs mer i TLS-avslutning med Key Vault-certifikat.

   Application Gateway bearbetar inspektionsregler för webbaserade programbrandväggar och kör routningsregler som vidarebefordrar trafiken till den konfigurerade serverdelen.

3. När trafiken flyttas från Application Gateway till serverdelen krypteras den igen med ett annat TLS-certifikat, som är ett jokertecken för *.aks-ingress.contoso.com, eftersom det vidarebefordras till den interna lastbalanseraren. Den här omkryptering hjälper till att säkerställa att oskyddad trafik inte flödar in i klustrets undernät.

4. Ingresskontrollanten tar emot den krypterade trafiken via lastbalanseraren. Kontrollanten är en annan TLS-avslutningsplats för *.aks-ingress.contoso.com och vidarebefordrar trafiken till arbetsbelastningspoddarna via HTTP. Certifikaten lagras i Key Vault och CSI-drivrutinen (Container Storage Interface) monterar dem i klustret. Mer information finns i Lägga till hemlig hantering.

Du kan implementera TLS-trafik från slutpunkt till slutpunkt vid varje hopp via arbetsbelastningspodden. Se till att mäta prestanda, svarstid och driftseffekter när du fattar beslutet att skydda podd-till-pod-trafik. För de flesta kluster med en enda klientorganisation, med rätt RBAC-kontrollplan och mogna livscykelmetoder för programvaruutveckling, räcker det med att TLS krypterar upp till ingresskontrollanten och skyddar med Brandvägg för webbprogram. Den här metoden minimerar kostnaderna för arbetsbelastningshantering och omkostnader på grund av dåliga nätverksprestanda. Dina arbetsbelastnings- och efterlevnadskrav avgör var du utför TLS-avslutning.

Utgående trafikflöde

I den här arkitekturen rekommenderar vi att all utgående trafik från klustret kommunicerar via Azure Firewall. Eller så kan du använda en egen virtuell nätverksinstallation. Vi rekommenderar inte att du använder andra utgående alternativ, till exempel Azure NAT Gateway eller en HTTP-proxy eftersom de inte tillhandahåller kontroll av nätverkstrafik. För Nulta pouzdanost kontroll och möjligheten att inspektera trafik flyttas all utgående trafik från klustret genom brandväggen. Du kan implementera den här konfigurationen med användardefinierade vägar (UDR). Nästa hopp för vägen är den privata IP-adressen för Azure Firewall. Azure Firewall avgör om utgående trafik ska blockeras eller tillåtas. Det beslutet baseras på de specifika regler som du definierar i Azure Firewall eller de inbyggda hotinformationsreglerna.

Ett alternativ till Azure Firewall är att använda AKS HTTP-proxyfunktionen . All trafik som lämnar klustret går till IP-adressen för HTTP-proxyn, som vidarebefordrar trafiken eller släpper den.

För någon av metoderna granskar du de regler för utgående nätverkstrafik som krävs för AKS.

Ett undantag till Nulta pouzdanost kontroll är när klustret behöver kommunicera med andra Azure-resurser. Klustret kan till exempel behöva hämta en uppdaterad avbildning från containerregistret eller hemligheter från Key Vault. I dessa scenarier rekommenderar vi att du använder Private Link. Fördelen är att specifika undernät når tjänsten direkt och att trafiken mellan klustret och tjänsterna inte går via Internet. En nackdel är att Private Link behöver extra konfiguration i stället för att använda måltjänsten över sin offentliga slutpunkt. Dessutom har inte alla Azure-tjänster eller produkter stöd för Private Link. I sådana fall bör du överväga att aktivera en tjänstslutpunkt för virtuellt nätverk i undernätet för att få åtkomst till tjänsten.

Om Private Link eller tjänstslutpunkter inte är ett alternativ kan du nå andra tjänster via deras offentliga slutpunkter och styra åtkomsten via Azure Firewall-regler och brandväggen som är inbyggd i måltjänsten. Eftersom den här trafiken går via brandväggens statiska IP-adresser kan du lägga till dessa adresser i tjänstens IP-lista. En nackdel är att Azure Firewall sedan behöver fler regler för att se till att den endast tillåter trafik från ett visst undernät. Ta hänsyn till dessa adresser när du planerar flera IP-adresser för utgående trafik med Azure Firewall. Annars kan du nå portöverbelastning. Mer information om hur du planerar för flera IP-adresser finns i Skapa en Azure-brandvägg med flera IP-adresser.

Information om De Windows-specifika övervägandena för utgående trafik i Windows-containrar på AKS-baslinjereferensarkitekturen finns i Windows-containrar på AKS.

Podd-till-poddtrafik

Som standard kan en podd acceptera trafik från andra poddar i klustret. Använd Kubernetes NetworkPolicy för att begränsa nätverkstrafiken mellan poddar. Tillämpa principer på ett omdömesgillt sätt, eller så kan du ha en situation där ett kritiskt nätverksflöde blockeras. Tillåt endast specifika kommunikationsvägar efter behov, till exempel trafik mellan ingresskontrollanten och arbetsbelastningen. Mer information finns i Nätverksprinciper.

Aktivera nätverksprincip när du etablerar klustret eftersom du inte kan lägga till det senare. Du har några alternativ för tekniker som implementerar NetworkPolicy. Vi rekommenderar Azure-nätverksprincip, som kräver Azure Container Networking Interface (CNI). Mer information finns i följande anteckning. Andra alternativ är Calico-nätverksprincip, ett välkänt alternativ med öppen källkod. Tänk på Calico om du behöver hantera klusteromfattande nätverksprinciper. Calico omfattas inte av standardsupporten för Azure.

Mer information finns i Skillnader mellan Azure-nätverksprincipmotorer.

Hanteringstrafik

Som en del av att köra klustret tar Kubernetes API-servern emot trafik från resurser som vill utföra hanteringsåtgärder i klustret, till exempel begäranden om att skapa resurser för att skala klustret. Exempel på dessa resurser är byggagentpoolen i en DevOps-pipeline, en Azure Bastion-instans i Azure Bastion-undernätet och själva nodpoolerna. I stället för att acceptera den här hanteringstrafiken från alla IP-adresser använder du funktionen AKS-auktoriserade IP-intervall för att endast tillåta trafik från dina auktoriserade IP-intervall till API-servern

Mer information finns i Definiera API-serverauktoriserade IP-intervall.

För ett annat kontrolllager kan du, på bekostnad av extra komplexitet, etablera ett privat AKS-kluster. Genom att använda ett privat kluster kan du se till att nätverkstrafiken mellan API-servern och nodpoolerna endast finns kvar i det privata nätverket och aldrig exponeras för Internet. Mer information finns i PRIVATA AKS-kluster.

Lägg till hemlighetshantering

Lagra hemligheter i ett hanterat nyckelarkiv, till exempel Key Vault. Fördelen är att ett hanterat nyckelarkiv hanterar rotationen av hemligheter. Det ger stark kryptering och en åtkomstgranskningslogg. Den håller även kärnhemligheter borta från distributionspipelinen. I den här arkitekturen aktiveras och konfigureras en Key Vault-brandvägg, och Private Link används när du ansluter från resurser i Azure som behöver åtkomst till hemligheter och certifikat.

Key Vault är väl integrerat med andra Azure-tjänster. Använd den inbyggda funktionen för dessa tjänster för att få åtkomst till hemligheter. Mer information om hur Application Gateway får åtkomst till TLS-certifikat för ingressflödet finns i avsnittet Inkommande trafikflöde .

Med Azure RBAC-behörighetsmodellen för Key Vault kan du tilldela arbetsbelastningsidentiteterna till rolltilldelningen Key Vault Secrets User eller Key Vault Reader och få åtkomst till hemligheterna. Mer information finns i Åtkomst till Key Vault med hjälp av RBAC.

Åtkomst till klusterhemligheter

Du måste använda arbetsbelastningsidentiteter för att tillåta att en podd får åtkomst till hemligheter från ett visst arkiv. För att underlätta hämtningsprocessen använder du en CSI-drivrutin för hemligheter. När podden behöver en hemlighet ansluter drivrutinen till det angivna arkivet, hämtar en hemlighet på en volym och monterar volymen i klustret. Podden kan sedan hämta hemligheten från volymfilsystemet.

CSI-drivrutinen har många leverantörer som stöder olika hanterade butiker. Den här implementeringen använder Key Vault med CSI-drivrutinen för hemligheter. Tillägget hämtar TLS-certifikatet från Key Vault och läser in drivrutinen i podden som kör ingresskontrollanten. Den här åtgärden inträffar när podden skapas och volymen lagrar både offentliga och privata nycklar.

Lagring av arbetsbelastningar

Arbetsbelastningen i den här arkitekturen är tillståndslös. Om du behöver lagra tillståndet rekommenderar vi att du bevarar det utanför klustret. Vägledning för arbetsbelastningstillstånd ligger utanför omfånget för den här artikeln.

Mer information finns i Lagringsalternativ för program i AKS.

Principhantering

Ett effektivt sätt att hantera ett AKS-kluster är att tillämpa styrning via principer. Kubernetes implementerar principer via Open Policy Agent (OPA) Gatekeeper. För AKS levererar du principer via Azure Policy. Varje princip gäller för alla kluster i dess omfång. OPA Gatekeeper hanterar principframtvingande i klustret och loggar alla principkontroller. Principändringarna återspeglas inte omedelbart i klustret, så förvänta dig vissa fördröjningar.

Om du vill hantera dina AKS-kluster kan du använda Azure Policy för att:

• Förhindra eller begränsa distributionen av AKS-kluster i en resursgrupp eller prenumeration. Tillämpa standarder för din organisation. Du kan till exempel följa en namngivningskonvention eller ange en tagg.
• Skydda ditt AKS-kluster via Azure Policy for Kubernetes.

När du anger principer tillämpar du dem baserat på arbetsbelastningens krav. Tänk på följande faktorer:

• Vill du ange en samling principer, även kallade initiativ, eller välja enskilda principer? Azure Policy innehåller två inbyggda initiativ: grundläggande och begränsad. Varje initiativ är en samling inbyggda principer som gäller för ett AKS-kluster. Vi rekommenderar att du väljer ett initiativ och väljer andra principer för klustret och resurserna, till exempel Container Registry, Application Gateway eller Key Vault, som interagerar med klustret. Välj principer baserat på organisationens krav.

• Vill du granska eller neka åtgärden? I granskningsläge tillåts åtgärden men flaggas som icke-kompatibel. Ha processer för att kontrollera inkompatibla tillstånd med jämna mellanrum och vidta nödvändiga åtgärder. I neka-läge blockeras åtgärden eftersom den bryter mot principen. Var försiktig när du väljer det här läget eftersom det kan vara för restriktivt för att arbetsbelastningen ska fungera.

• Har du områden i din arbetsbelastning som inte ska vara kompatibla avsiktligt? Azure Policy har möjlighet att ange Kubernetes-namnområden som är undantagna från principframtvingande. Vi rekommenderar att du fortfarande tillämpar principer i granskningsläge så att du känner till dessa instanser.

• Har du krav som inte omfattas av de inbyggda principerna? Du kan skapa en anpassad Azure Policy-definition som tillämpar dina anpassade OPA Gatekeeper-principer. Tillämpa inte anpassade principer direkt på klustret. Mer information finns i Skapa och tilldela anpassade principdefinitioner.

• Har du organisationsomfattande krav? I så fall lägger du till dessa principer på hanteringsgruppsnivå. Klustret bör också tilldela sina egna arbetsbelastningsspecifika principer, även om din organisation har allmänna principer.

• Tilldelar du Azure-principer till specifika omfång? Kontrollera att produktionsprinciperna också verifieras mot din förproduktionsmiljö. När du distribuerar till produktionsmiljön kan du annars stöta på oväntade extra begränsningar som du inte tar hänsyn till i förproduktion.

Den här referensimplementeringen aktiverar Azure Policy när AKS-klustret skapas. Det restriktiva initiativet tilldelas i granskningsläge för att få insyn i inkompatibilitet.

Implementeringen anger även extra principer som inte ingår i några inbyggda initiativ. Dessa principer anges i neka-läge . Det finns till exempel en princip för att se till att avbildningar endast hämtas från den distribuerade Container Registry-instansen. Överväg att skapa egna anpassade initiativ. Kombinera de principer som gäller för din arbetsbelastning till en enda tilldelning.

Om du vill se hur Azure Policy fungerar inifrån klustret kan du komma åt poddloggarna för alla poddar i gatekeeper-system namnområdet och loggarna för azure-policy poddarna och azure-policy-webhook i kube-system namnområdet.

Mer information om Windows-specifika Azure Policy-överväganden finns i artikeln Windows-containrar i AKS-principhantering .

Skalbarhet för noder och poddar

Med ökande efterfrågan kan Kubernetes skala ut genom att lägga till fler poddar till befintliga noder, via horisontell autoskalning av poddar. När Kubernetes inte längre kan schemalägga fler poddar måste antalet noder ökas genom automatisk skalning av AKS-kluster. En fullständig skalningslösning måste ha sätt att skala både poddrepliker och antalet noder i klustret.

Det finns två metoder: automatisk skalning eller manuell skalning.

Både den automatiska skalningen och den manuella metoden kräver att du övervakar och anger aviseringar om CPU-användning eller anpassade mått. För poddskalning kan programoperatören öka eller minska antalet poddrepliker genom att ReplicaSet justera via Kubernetes-API:er. För klusterskalning ska en metod meddelas när Kubernetes-schemaläggaren misslyckas. Ett annat sätt är att hålla utkik efter väntande poddar över tid. Du kan justera antalet noder via Azure CLI eller Azure-portalen.

Vi rekommenderar autoskalningsmetoden eftersom vissa av dessa manuella mekanismer är inbyggda i autoskalningsmetoden.

Som en allmän metod börjar du med prestandatestning med ett minsta antal poddar och noder. Använd dessa värden för att fastställa baslinjeförväntningen. Använd sedan en kombination av prestandamått och manuell skalning för att hitta flaskhalsar och förstå programmets svar på skalning. Slutligen använder du dessa data för att ange parametrarna för automatisk skalning. Mer information om ett prestandajusteringsscenario med hjälp av AKS finns i Scenario för prestandajustering: Distribuerade affärstransaktioner.

Horisontell autoskalning av poddar

HPA (Horizontal Pod Autoscaler) är en Kubernetes-resurs som skalar antalet poddar.

I HPA-resursen rekommenderar vi att du anger minsta och högsta antal repliker. Värdena begränsar autoskalningsgränsen.

HPA kan skalas baserat på CPU-användning, minnesanvändning och anpassade mått. Endast CPU-användning tillhandahålls direkt. Definitionen HorizontalPodAutoscaler anger målvärden för måtten. Specifikationen anger till exempel cpu-målanvändningen. När poddar körs använder HPA-styrenheten Kubernetes Metrics API för att kontrollera varje podds CPU-användning. Den jämför det värdet med målanvändningen och beräknar ett förhållande. Sedan används förhållandet för att avgöra om poddar är överbelagda eller underallokerade. Den förlitar sig på Kubernetes-schemaläggaren för att tilldela nya poddar till noder eller ta bort poddar från noder.

Det kan finnas ett konkurrenstillstånd där HPA kontrolleras innan en skalningsåtgärd slutförs. Resultatet kan vara en felaktig förhållandeberäkning. Mer information finns i Cooldown of scaling events (Nedkylning av skalningshändelser).

Om din arbetsbelastning är händelsedriven är ett populärt alternativ med öppen källkod Kubernetes händelsedriven autoskalning (KEDA). Tänk på KEDA om en händelsekälla, till exempel meddelandekö, kör din arbetsbelastning i stället för att din arbetsbelastning är CPU-bunden eller minnesbunden. KEDA stöder många händelsekällor eller skalare. Använd listan över händelsekällor som KEDA kan skala på KEDA-skalare. Listan innehåller Azure Monitor-skalning, vilket är ett bekvämt sätt att skala KEDA-arbetsbelastningar baserat på Azure Monitor-mått.

Autoskalning av kluster

Autoskalning av kluster är en AKS-tilläggskomponent som skalar antalet noder i en nodpool. Lägg till den under klusteretablering. Du behöver en separat kluster autoskalning för varje användarnodpool.

Kubernetes-schemaläggaren utlöser autoskalning av klustret. När Kubernetes-schemaläggaren inte kan schemalägga en podd på grund av resursbegränsningar etablerar autoskalning automatiskt en ny nod i nodpoolen. Omvänt kontrollerar autoskalning av kluster den outnyttjade kapaciteten för noderna. Om noden inte körs med en förväntad kapacitet flyttas poddarna till en annan nod och den oanvända noden tas bort.

När du aktiverar autoskalning anger du maximalt och minsta antal noder. De rekommenderade värdena beror på arbetsbelastningens prestandaförväntningar, hur mycket du vill att klustret ska växa och kostnadskonsekvenser. Det minsta antalet är den reserverade kapaciteten för den nodpoolen. I den här referensimplementeringen anges minimivärdet till två på grund av enkelheten i arbetsbelastningen.

För systemnodpoolen är det rekommenderade minimivärdet tre.

Information om överväganden för Windows-specifik skalning som ingår i den här referensarkitekturen för baslinjen finns i artikeln Windows-containrar i AKS .

Beslut om affärskontinuitet

För att upprätthålla affärskontinuitet definierar du SLO för infrastrukturen och ditt program. Mer information finns i Rekommendationer för att definiera tillförlitlighetsmål. Granska serviceavtalsvillkoren (SLA) för AKS i den senaste artikeln om serviceavtal för usluge na mreži.

Klusternoder

För att uppfylla den lägsta tillgänglighetsnivån för arbetsbelastningar behöver du flera noder i en nodpool. Om en nod misslyckas kan en annan nod i samma nodpool och kluster fortsätta att köra programmet. För tillförlitlighet rekommenderar vi 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 etablerar du fler noder.

Isolera programmet från systemtjänsterna genom att placera det i en separat nodpool, som kallas för en användarnodpool. På så sätt körs Kubernetes-tjänster på dedikerade noder och konkurrerar inte med din arbetsbelastning. Vi rekommenderar att du använder taggar, etiketter och taints för att identifiera nodpoolen och schemalägga din arbetsbelastning. Kontrollera att systemnodpoolen är fläckad med CriticalAddonsOnly taint.

Regelbunden underhåll av klustret, till exempel uppdateringar i tid, är avgörande för tillförlitligheten. Vi rekommenderar också att du övervakar poddarnas hälsotillstånd via avsökningar.

Poddtillgänglighet

Ange krav för poddresurser: Vi rekommenderar att du anger krav för poddresurser i dina distributioner. Schemaläggaren kan sedan schemalägga podden på lämpligt sätt. Tillförlitligheten minskar avsevärt om dina poddar inte kan schemaläggas.

Ange budgetar för poddstörningar: Den här inställningen avgör hur många repliker i en distribution som kan komma ned under en uppdaterings- eller uppgraderingshändelse. Mer information finns i Podd-avbrottsbudgetar.

Konfigurera flera repliker i distributionen för att hantera störningar, till exempel maskinvarufel. För planerade händelser, till exempel uppdateringar och uppgraderingar, kan en avbrottsbudget hjälpa till att säkerställa att det nödvändiga antalet poddrepliker finns för att hantera förväntad programbelastning.

Ange resurskvoter för arbetsbelastningens namnområden: Resurskvoten på ett namnområde hjälper till att säkerställa att poddbegäranden och gränser har angetts korrekt för en distribution. Mer information finns i Framtvinga resurskvoter.

Ange poddbegäranden och begränsningar: Genom att ange begäranden och gränser kan Kubernetes effektivt allokera processor- och minnesresurser till poddarna, och du kan få högre containerdensitet på en nod. Förfrågningar och gränser kan också öka din tillförlitlighet samtidigt som du minskar dina kostnader på grund av bättre maskinvaruanvändning.

Om du vill beräkna gränserna för en arbetsbelastning testar och upprättar du en baslinje. Börja med lika värden för begäranden och gränser. Justera sedan värdena gradvis tills du upprättar ett tröskelvärde som kan orsaka instabilitet i klustret.

Du kan ange begäranden och gränser i distributionsmanifestet. Mer information finns i Ange poddbegäranden och gränser.

Tillgänglighetszoner och stöd för flera regioner

Om du vill skydda mot vissa typer av avbrott använder du tillgänglighetszoner om regionen stöder dem. Både kontrollplanskomponenterna och noderna i nodpoolerna kan sedan spridas över zoner. Om en hel zon inte är tillgänglig är en nod i en annan zon i regionen fortfarande tillgänglig. Varje nodpool mappar till en separat VM-skalningsuppsättning som hanterar nodinstanser och skalbarhet. AKS-tjänsten hanterar skalningsuppsättningsåtgärder och konfiguration. Här följer några överväganden när du aktiverar flera zoner:

• Hela infrastrukturen: Välj en region som stöder tillgänglighetszoner. Mer information finns i Begränsningar. Om du vill ha ett serviceavtal för drifttid måste du välja standard- eller Premium-nivån. Serviceavtalet för drifttid är större när du använder tillgänglighetszoner.

• Kluster: Du kan bara ange tillgänglighetszoner när du skapar nodpoolen. De kan inte ändras senare. Nodstorlekarna bör stödjas i alla zoner så att den förväntade fördelningen är möjlig. Den underliggande vm-skalningsuppsättningen har samma maskinvarukonfiguration mellan zoner.

  Stöd för flera zoner gäller inte bara för nodpooler, utan även kontrollplanet. AKS-kontrollplanet sträcker sig över de begärda zonerna, till exempel nodpoolerna. Om du inte använder zonstöd i klustret är kontrollplanskomponenterna inte garanterade att spridas över tillgänglighetszoner.

• Beroende resurser: För fullständig zonindelningsförmån måste alla tjänstberoenden också stödja zoner. Om en beroende tjänst inte stöder zoner är det möjligt att ett zonfel kan orsaka att tjänsten misslyckas.

  Till exempel är en hanterad disk tillgänglig i zonen där den etablerades. Om ett fel inträffar kan noden flyttas till en annan zon, men den hanterade disken flyttas inte med noden till den zonen.

För enkelhetens skull i den här arkitekturen distribueras AKS till en enda region med nodpooler som sträcker sig över tillgänglighetszonerna ett, två och tre. Andra resurser i infrastrukturen, till exempel Azure Firewall och Application Gateway, distribueras också till samma region med stöd för flera zoner. Geo-replikering är aktiverat för Container Registry.

Flera regioner

När du aktiverar tillgänglighetszoner är det inte tillräckligt med täckning i den osannolika händelsen att en hel region misslyckas. Om du vill få högre tillgänglighet kör du flera AKS-kluster i olika regioner.

• Föredrar parkopplade regioner när de är tillgängliga. En fördel med att använda kopplade regioner är tillförlitlighet vid plattformsuppdateringar. Azure ser till att endast en region i paret uppdateras i taget. Vissa regioner har inte par. Om din region inte är kopplad kan du fortfarande distribuera en lösning för flera regioner genom att välja andra regioner att använda. Överväg att använda en CI/CD-pipeline (kontinuerlig integrering och kontinuerlig leverans), som du konfigurerar för att samordna återställning från ett regionfel. Vissa DevOps-verktyg som Flux kan göra distributioner i flera regioner enklare.

• Ange den plats där den redundanta tjänsten har sin sekundära instans om en Azure-resurs stöder geo-redundans. Genom att till exempel aktivera geo-replikering för Container Registry replikeras automatiskt avbildningar till de valda Azure-regionerna. Det ger också fortsatt åtkomst till bilder även om den primära regionen upplever ett avbrott.

• Välj en trafikrouter som kan distribuera trafik mellan zoner eller regioner, beroende på dina behov. Den här arkitekturen distribuerar Load Balancer eftersom den kan distribuera icke-webbtrafik mellan zoner. Om du behöver distribuera trafik mellan regioner bör du överväga Azure Front Door. Andra alternativ finns i Välj en lastbalanserare.

Haveriberedskap

Om ett fel inträffar i den primära regionen kan du helst snabbt skapa en ny instans i en annan region. Här följer några rekommendationer:

• Använd flera regioner. Om din primära region har en parkopplad region använder du det paret. Om inte väljer du regioner baserat på dina krav på datahemvist och svarstid.

• Använd en icke-tillståndskänslig arbetsbelastning som du kan replikera effektivt. Om du behöver lagra tillståndet i klustret, vilket vi inte rekommenderar, måste du säkerhetskopiera data ofta i en annan region.

• Integrera återställningsstrategin, till exempel att replikera till en annan region, som en del av DevOps-pipelinen för att uppfylla ditt SLO.

• Etablera varje Azure-tjänst med hjälp av funktioner som stöder haveriberedskap. I den här arkitekturen är till exempel Container Registry aktiverat för geo-replikering. Om en region misslyckas kan du fortfarande hämta bilder från den replikerade regionen.

• Distribuera infrastrukturen som kod, inklusive ditt AKS-kluster och andra komponenter som du behöver. Om du behöver distribuera till en annan region kan du återanvända skripten eller mallarna för att skapa en identisk instans.

Säkerhetskopiering av kluster

För många arkitekturer kan du etablera ett nytt kluster och återställa det till drifttillstånd via Git-driftsbaserad klusterstövlar, följt av programdistribution. Men om det finns ett kritiskt resurstillstånd, till exempel konfigurationskartor, jobb och hemligheter som inte kan fångas in i din startprocess, bör du överväga din återställningsstrategi. Vi rekommenderar att du kör tillståndslösa arbetsbelastningar i Kubernetes. Om arkitekturen omfattar diskbaserat tillstånd måste du även överväga din återställningsstrategi för innehållet.

När klustersäkerhetskopiering måste ingå i återställningsstrategin måste du installera en lösning som matchar dina affärskrav i klustret. Den här agenten ansvarar för att push-överföra klustrets resurstillstånd till ett mål som du väljer och samordna Azures diskbaserade, beständiga volymögonblicksbilder.

VMware Velero är ett exempel på en vanlig Kubernetes-säkerhetskopieringslösning som du kan installera och hantera direkt. Eller så kan du använda AKS-säkerhetskopieringstillägget för att tillhandahålla en hanterad Velero-implementering. AKS-säkerhetskopieringstillägget stöder säkerhetskopiering av både Kubernetes-resurser och beständiga volymer, med scheman och säkerhetskopieringsomfång externaliserat som valvkonfiguration i Azure Backup.

Referensimplementeringen implementerar inte säkerhetskopiering, vilket innebär extra Azure-resurser för att hantera, övervaka, köpa och skydda. Dessa resurser kan innehålla ett Azure Storage-konto, ett Azure Backup-valv och en konfiguration och funktionen för betrodd åtkomst. I stället är Git-åtgärder som kombineras med avsikten att köra tillståndslös arbetsbelastning återställningslösningen.

Välj och verifiera en säkerhetskopieringslösning som uppfyller ditt affärsmål, inklusive ditt definierade mål för återställningspunkt och återställningstid. Definiera återställningsprocessen i en team-runbook och öva på den för alla affärskritiska arbetsbelastningar.

Serviceavtal för Kubernetes API-server

Du kan använda AKS som en kostnadsfri tjänst, men den nivån erbjuder inte ett ekonomiskt stödda serviceavtal. För att få ett serviceavtal måste du välja standardnivån. Vi rekommenderar att alla produktionskluster använder standardnivån. Reservera den kostnadsfria nivån för förproduktionskluster och Premium-nivån endast för verksamhetskritiska arbetsbelastningar . När du använder Azure-tillgänglighetszoner är Kubernetes API-server-SLA högre. Dina nodpooler och andra resurser omfattas av sina egna serviceavtal. Mer information om specifika serviceavtal för varje tjänst finns i Serviceavtal för usluge na mreži.

Avvägning

Det finns en kostnads-till-tillgänglighet-kompromiss för att distribuera arkitekturen mellan zoner och särskilt regioner. Vissa replikeringsfunktioner, till exempel geo-replikering i Container Registry, är tillgängliga i premium-SKU:er, vilket är dyrare. För distributioner i flera regioner ökar kostnaden också eftersom bandbreddsavgifter tillämpas när trafiken flyttas mellan regioner.

Förvänta dig också extra nätverksfördröjning i nodkommunikation mellan zoner eller regioner. Mät effekten av det här arkitekturbeslutet på din arbetsbelastning.

Testa med simuleringar och forcerad redundans

Testa lösningens tillförlitlighet genom tvingad redundanstestning med simulerade avbrott. Simuleringar kan omfatta att stoppa en nod, ta bort alla AKS-resurser i en viss zon för att simulera ett zonfel eller anropa ett externt beroendefel. Du kan också använda Azure Chaos Studio för att simulera olika typer av avbrott i Azure och i klustret.

Mer information finns i Chaos Studio.

Övervaka och samla in mått

Vi rekommenderar Azure Monitor-containerinsikter för att övervaka prestanda för containerarbetsbelastningar eftersom du kan visa händelser i realtid. Den samlar in containerloggar från de poddar som körs och aggregerar dem för visning. Den samlar också in information från mått-API:et om minnes- och CPU-användning för att övervaka hälsotillståndet för resurser och arbetsbelastningar som körs. Du kan också använda containerinsikter för att övervaka prestanda när poddarna skalas. Den innehåller telemetri som är viktig för övervakning, analys och visualisering av insamlade data. Containerinsikter identifierar trender och gör att du kan konfigurera aviseringar för att ta emot proaktiva meddelanden om kritiska problem.

De flesta arbetsbelastningar som finns i poddar genererar Prometheus-mått. Containerinsikter kan integreras med Prometheus. Du kan visa de program- och arbetsbelastningsmått som samlas in från noder och Kubernetes.

Vissa icke-Microsoft-lösningar integreras med Kubernetes, till exempel Datadog, Grafana eller New Relic. Så om din organisation redan använder dessa lösningar kan du dra nytta av dem.

Med AKS hanterar Azure några av kubernetes-kärntjänsterna. Azure implementerar loggarna för AKS-kontrollplanskomponenterna som resursloggar. Vi rekommenderar att du aktiverar följande alternativ i de flesta kluster. Alternativen kan hjälpa dig att felsöka klusterproblem och de har en relativt låg loggdensitet.

• ClusterAutoscaler: få observerbarhet i skalningsåtgärderna med loggning. Mer information finns i Hämta loggar och status för autoskalning av kluster.
• KubeControllerManager: få observerbarhet i interaktionen mellan Kubernetes och Azure-kontrollplanet.
• kube-audit-admin: få observerbarhet i aktiviteter som ändrar klustret. Det finns ingen anledning att ha både kube-audit och kube-audit-admin aktiverat. kube-audit är en supermängd av kube-audit-admin som även innehåller icke-kompatibla (läsåtgärder).
• guard: samla in Microsoft Entra ID- och Azure RBAC-granskningar.

Det kan vara användbart för dig att aktivera andra loggkategorier, till exempel KubeScheduler eller kube-audit, under utveckling av tidiga kluster eller arbetsbelastningars livscykel. Den tillagda klustrets autoskalning, poddplacering och schemaläggning och liknande data kan hjälpa dig att felsöka problem med kluster- eller arbetsbelastningsåtgärder. Men om du behåller de utökade felsökningsloggarna på heltid när felsökningsbehoven har upphört kan det medföra onödiga kostnader för att mata in och lagra data i Azure Monitor.

Azure Monitor innehåller en uppsättning befintliga loggfrågor till att börja med, men du kan också använda dem som grund för att skapa egna frågor. När biblioteket växer kan du spara och återanvända loggfrågor med hjälp av ett eller flera frågepaket. Ditt anpassade bibliotek med frågor ger mer observerbarhet när det gäller hälsotillstånd och prestanda för dina AKS-kluster. Den har stöd för att uppnå dina serviceavtal.

Mer information om våra metodtips för övervakning för AKS finns i Övervaka AKS med Azure Monitor.

Mer information om Windows-specifika övervakningsöverväganden finns i Windows-containrar på AKS.

Nätverksmått

Grundläggande nätverksmått på klusternivå är tillgängliga via interna plattforms- och Prometheus-mått. Du kan ytterligare använda tillägget Nätverksobservabilitet för att exponera nätverksmått på nodnivå. De flesta kluster bör använda tillägget Nätverksobservabilitet för att tillhandahålla extra funktioner för nätverksfelsökning och för att identifiera oväntad nätverksanvändning eller problem på nodnivå.

För arbetsbelastningar som är mycket känsliga för TCP-paket (Transmission Control Protocol) eller UDP-paketförluster (User Datagram Protocol), svarstid eller DNS-tryck är nätverksmåtten på poddnivå viktiga. I AKS kan du hitta den detaljnivån med funktionen Advanced Network Observability . De flesta arbetsbelastningar kräver inte det här djupet av nätverksobservabilitet. Du bör inte installera tillägget Advanced Network Observability såvida inte dina poddar kräver ett mycket optimerat nätverk med känslighet ned till paketnivån.

Aktivera självåterställning

Övervaka hälsotillståndet för poddar genom att ange liveness- och beredskapsavsökningar. Om Kubernetes identifierar en podd som inte svarar startas podden om. En liveness-avsökning avgör om podden är felfri. Om Kubernetes identifierar en podd som inte svarar startas podden om. En beredskapsavsökning avgör om podden är redo att ta emot begäranden och trafik.

Rutinuppdateringar för AKS-kluster

En del av dag-2-åtgärder för Kubernetes-kluster är att utföra rutinmässiga uppdateringar av plattformar och operativsystem. Det finns tre lager med uppdateringar att hantera i varje AKS-kluster:

• Kubernetes-versionen (till exempel Kubernetes 1.30.3 till 1.30.7 eller Kubernetes 1.30.7 till 1.31.1), som kan komma med Kubernetes API-ändringar och utfasningar. Versionsändringar på det här lagret påverkar hela klustret.
• Avbildningen av den virtuella hårddisken (VHD) på varje nod, som kombinerar uppdateringar av operativsystemet och AKS-komponentuppdateringar. Dessa uppdateringar testas mot klustrets Kubernetes-version. Versionsändringar på det här lagret tillämpas på nodpoolsnivå och påverkar inte Kubernetes-versionen.
• Operativsystemets egen inbyggda uppdateringsprocess, till exempel Windows Update eller apt. Operativsystemets leverantör tillhandahåller dessa uppdateringar direkt och de testas inte mot klustrets Kubernetes-version. Versionsändringar på det här lagret påverkar en enskild nod och påverkar inte Kubernetes-versionen.

Vart och ett av dessa lager styrs oberoende av varandra. Du bestämmer hur varje lager ska hanteras för dina arbetsbelastningskluster. Välj hur ofta varje AKS-kluster, dess nodpooler eller noder uppdateras (kadensen). Välj också vilka dagar eller tider som uppdateringarna ska tillämpas (underhållsfönstret). Välj om uppdateringar ska installeras manuellt eller automatiskt eller inte alls. Precis som arbetsbelastningen som körs i klustret behöver en säker distributionspraxis, så gör även uppdateringarna till dina kluster.

Ett omfattande perspektiv på korrigering och uppgradering finns i AKS-korrigerings- och uppgraderingsguiden i driftguiden för AKS day-2. Använd följande information för baslinjerekommendationer när det gäller den här arkitekturen.

Oföränderlig infrastruktur

Arbetsbelastningar som använder AKS-kluster som oföränderlig infrastruktur uppdaterar inte automatiskt eller manuellt sina kluster. Ange nodavbildningsuppgradering till none och automatisk uppgradering av klustret till none. I den här konfigurationen är du ensam ansvarig för alla uppgraderingar i alla lager. När en uppdatering som du vill ha blir tillgänglig måste du testa uppdateringen i en förproduktionsmiljö och utvärdera dess kompatibilitet i ett nytt kluster. Därefter distribuerar du en produktionsreplikstämpel som innehåller den uppdaterade AKS-versionen och de virtuella hårddiskarna för nodpoolen. När det nya produktionsklustret är klart töms det gamla klustret och inaktiveras så småningom.

Oföränderlig infrastruktur med regelbundna distributioner av ny infrastruktur är den enda situation där ett produktionskluster inte ska ha någon uppgraderingsstrategi på plats. Alla andra kluster bör ha en uppgraderingsstrategi på plats.

Uppgraderingar på plats

Arbetsbelastningar som inte använder AKS-kluster som oföränderlig infrastruktur bör regelbundet uppdatera sina kluster som körs för att hantera alla tre lagren. Justera uppdateringsprocessen efter arbetsbelastningens krav. Använd följande rekommendationer som utgångspunkt för att utforma din rutinuppdateringsprocess.

• Schemalägg funktionen för planerat underhåll i AKS så att du kan styra uppgraderingar i klustret. Med den här funktionen kan du utföra uppdateringarna, en riskfylld åtgärd, vid en kontrollerad tidpunkt för att minska effekten av ett oväntat fel.
• Konfigurera budgetar för poddstörningar så att programmet förblir stabilt under löpande uppgraderingar. Men konfigurera inte budgetarna så aggressiva att de blockerar att noduppgraderingar sker, eftersom de flesta uppgraderingar kräver en avspärrnings- och tömningsprocess på varje nod.
• Bekräfta Azure-resurskvoten och resurstillgängligheten. Uppgraderingar på plats distribuerar nya instanser av noder, så kallade överspänningsnoder, innan gamla noder tas bort. Det innebär att Azure-kvoten och IP-adressutrymmet måste vara tillgängliga för de nya noderna. Ett överspänningsvärde på 33 % är en bra startpunkt för de flesta arbetsbelastningar.
• Testa kompatibiliteten med verktyg, till exempel tjänstnät eller säkerhetsagenter som du har lagt till i klustret. Och testa dina arbetsbelastningskomponenter, till exempel ingresskontrollanter, tjänstnät och dina arbetsbelastningspoddar. Gör tester i en förproduktionsmiljö.

Uppgraderingar på plats för noder

Använd den automatiska uppgraderingskanalen NodeImage för nod-OS-avbildningsuppgraderingar. Den här kanalen konfigurerar klustret för att uppdatera den virtuella hårddisken på varje nod med uppdateringar på nodnivå. Microsoft testar uppdateringarna mot din AKS-version. För Windows-noder sker uppdateringarna ungefär en gång per månad. För Linux-noder sker dessa uppdateringar ungefär en gång i veckan.

• Uppgraderingarna ändrar aldrig din AKS- eller Kubernetes-version, så Kubernetes API-kompatibilitet är inget problem.
• När du använder NodeImage som uppgraderingskanal respekterar den ditt planerade underhållsperiod, som du bör ange minst en gång i veckan. Ange det oavsett vilket nodavbildningsoperativsystem du använder för att säkerställa ett snabbt program.
• Dessa uppdateringar omfattar säkerhet på operativsystemnivå, kompatibilitet och funktionella uppdateringar, konfigurationsinställningar för operativsystem och AKS-komponentuppdateringar.
• Avbildningsutgåvor och deras inkluderade komponentversionsnummer spåras med hjälp av AKS-versionsspåraren.

Om säkerhetskrav för klustret kräver en mer aggressiv uppdateringstakt och klustret kan tolerera potentiella avbrott använder du uppgraderingskanalen SecurityPatch i stället. Microsoft testar även dessa uppdateringar. Uppdateringarna publiceras endast om det finns säkerhetsuppgraderingar som Microsoft anser vara tillräckligt viktiga för att släppas innan nästa schemalagda nodbilduppgradering. När du använder SecurityPatch kanalen får du även de uppdateringar som NodeImage kanalen har tagit emot. Kanalalternativet SecurityPatch respekterar fortfarande dina underhållsperioder, så se till att underhållsfönstret har mer frekventa luckor (till exempel dagligen eller varannan dag) för att stödja dessa oväntade säkerhetsuppdateringar.

De flesta kluster som utför uppgraderingar på plats bör undvika kanalalternativen och Unmanaged nodavbildningens None uppgraderingskanal.

Uppdateringar på plats till klustret

Kubernetes är en snabbt växande plattform, och regelbundna uppdateringar ger viktiga säkerhetskorrigeringar och nya funktioner. Det är viktigt att du förblir aktuell med Kubernetes-uppdateringar. Du bör hålla dig inom de två senaste versionerna eller N-2. Det är viktigt att uppgradera till den senaste versionen av Kubernetes eftersom nya versioner släpps ofta.

De flesta kluster bör kunna utföra uppdateringar av AKS-versionen på plats med tillräcklig försiktighet och noggrannhet. Risken för att utföra en uppgradering av AKS-versionen på plats kan främst minskas genom tillräcklig förproduktionstestning, kvotvalidering och budgetkonfiguration för poddar. Men alla uppgraderingar på plats kan resultera i oväntat beteende. Om uppgraderingar på plats anses vara för riskfyllda för din arbetsbelastning rekommenderar vi att du använder en blågrön distribution av AKS-kluster i stället för att följa de återstående rekommendationerna.

Vi rekommenderar att du undviker funktionen för automatisk uppgradering av klustret när du först distribuerar ett Kubernetes-kluster. Använd en manuell metod som ger dig tid att testa en ny AKS-klusterversion i dina förproduktionsmiljöer innan uppdateringarna når produktionsmiljön. Den här metoden uppnår också den största nivån av förutsägbarhet och kontroll. Men du måste vara noga med att övervaka nya uppdateringar av Kubernetes-plattformen och snabbt införa nya versioner när de släpps. Det är bättre att anta ett "håll dig aktuellt" tänkesätt över en långsiktig stödstrategi .

Du kan få meddelanden när en ny AKS-version är tillgänglig för klustret med hjälp av AKS-systemavsnittet för Azure Event Grid. Referensimplementeringen distribuerar det här Event Grid-systemavsnittet så att du kan prenumerera på Microsoft.ContainerService.NewKubernetesVersionAvailable händelsen från din händelseströmaviseringslösning. Granska AKS-viktig information om specifika kompatibilitetsproblem, beteendeändringar eller funktionsutfasningar.

Du kan så småningom komma till en säker punkt med Kubernetes-versioner, AKS-versioner, klustret, dess komponenter på klusternivå och arbetsbelastningen för att utforska funktionen för automatisk uppgradering. För produktionssystem skulle det vara ovanligt att någonsin gå längre än patch. När du uppgraderar AKS-versionen automatiskt kontrollerar du även aks-versionsinställningen för din infrastruktur som kod (IaC) för klustret så att de inte blir osynkroniserade. Konfigurera fönstret planerat underhåll för att stödja den automatiska uppgraderingen.

Säkerhetsövervakning

Övervaka containerinfrastrukturen för både aktiva hot och potentiella säkerhetsrisker. Här är några resurser:

• Microsoft Defender för containrar för att identifiera och åtgärda Defender for Cloud-rekommendationer för dina containeravbildningar.
• Defender for Containers söker regelbundet igenom dina containeravbildningar efter säkerhetsrisker.
• Defender for Containers genererar också säkerhetsaviseringar i realtid för misstänkta aktiviteter.
• AKS-säkerhetsbegrepp för program och kluster innehåller information om hur containersäkerhet skyddar hela pipelinen från slutpunkt till slutpunkt från version till programarbetsbelastningar som körs i AKS.

Kluster- och arbetsbelastningsåtgärder

Information om kluster- och arbetsbelastningsåtgärder (DevOps) finns i designprinciperna för operational excellence.

Klusterstövlar

När du har etablerat har du ett fungerande kluster, men du kan fortfarande ha några nödvändiga steg innan du kan distribuera arbetsbelastningar. Processen att förbereda klustret kallas bootstrapping. Bootstrapping kan bestå av att distribuera nödvändiga avbildningar till klusternoder, skapa namnområden och utföra andra uppgifter som uppfyller kraven i organisationens användningsfall.

För att minska klyftan mellan ett etablerat kluster och ett korrekt konfigurerat kluster bör klusteroperatorer tänka på hur deras unika bootstrappingprocess ser ut. De måste förbereda de relevanta tillgångarna i förväg. Om det till exempel är viktigt att kured körs på varje nod innan programarbetsbelastningar distribueras, bör klusteroperatorn kontrollera att det redan finns en Container Registry-instans som innehåller mål-Kured-avbildningen innan klustret etableras.

Du kan konfigurera bootstrappingprocessen med någon av följande metoder:

• GitOps Flux v2-klustertillägg
• Pipelines
• Självkonfiguration med Flux eller Argo CD, till exempel

En av de största fördelarna med att använda GitOps Flux v2-klustertillägget för AKS är att det i praktiken inte finns något mellanrum mellan ett etablerat kluster och ett bootstrapped-kluster. Den konfigurerar miljön med en solid hanteringsgrund framöver, och den stöder även att bootstrapping som resursmallar överensstämmer med din IaC-strategi.

När du använder tillägget krävs kubectl inte för någon del av bootstrappingprocessen. Du kan reservera kubectl-baserad åtkomst för nödlösningssituationer. Mellan mallar för Azure-resursdefinitioner och start av manifest via GitOps-tillägget kan du utföra alla normala konfigurationsaktiviteter utan att behöva använda kubectl.

Isolera arbetsbelastningsansvar

Dela upp arbetsbelastningen efter team och typer av resurser för att hantera varje del individuellt.

Börja med en grundläggande arbetsbelastning som innehåller de grundläggande komponenterna och bygga vidare på den. En första uppgift är att konfigurera nätverk. Etablera virtuella nätverk för hubben och ekrarna och även undernät i dessa nätverk. En eker har till exempel separata undernät för system- och användarnodpooler och ingressresurser. Distribuera ett undernät för Azure Firewall i hubben.

En annan uppgift är att integrera den grundläggande arbetsbelastningen med Microsoft Entra-ID.

Använda IaC

Välj en idempotent deklarativ metod framför en imperativ metod, där det är möjligt. I stället för att skriva en sekvens med kommandon som anger konfigurationsalternativ använder du deklarativ syntax som beskriver resurserna och deras egenskaper. Du kan använda Bicep, Azure Resource Manager-mallar (ARM-mallar) eller Terraform.

Se till att etablera resurser enligt de styrande principerna. När du till exempel väljer VM-storlekar håller du dig inom kostnadsbegränsningarna och alternativen för tillgänglighetszoner för att matcha kraven för ditt program. Du kan också använda Azure Policy för att framtvinga organisationens principer för dessa beslut.

Om du behöver skriva en sekvens med kommandon använder du Azure CLI. Dessa kommandon täcker en rad Azure-tjänster och du kan automatisera dem via skript. Windows och Linux stöder Azure CLI. Ett annat plattformsoberoende alternativ är Azure PowerShell. Ditt val beror på din önskade kompetensuppsättning.

Lagra och version dina skript och mallfiler i källkontrollsystemet.

CI/CD för arbetsbelastning

Pipelines för arbetsflöde och distribution måste kunna skapa och distribuera program kontinuerligt. Uppdateringar måste distribueras på ett säkert och snabbt sätt och återställas om det skulle uppstå problem.

Distributionsstrategin måste innehålla en tillförlitlig och automatiserad pipeline för kontinuerlig leverans. Distribuera ändringar i dina arbetsbelastningscontaineravbildningar till klustret automatiskt.

I den här arkitekturen hanterar GitHub Actions arbetsflödet och distributionen. Andra populära alternativ är Azure DevOps och Jenkins.

Kluster-CI/CD

Ladda ned en Visio-fil med den här arkitekturen.

I stället för att använda en imperativ metod som kubectl använder du verktyg som automatiskt synkroniserar kluster- och lagringsplatsändringar. Om du vill hantera arbetsflödet, till exempel lanseringen av en ny version och validering av den versionen innan du distribuerar till produktion, bör du överväga ett GitOps-flöde.

En viktig del av CI/CD-flödet är att starta ett nyligen etablerat kluster. En GitOps-metod är användbar eftersom den låter operatorerna deklarativt definiera bootstrappingprocessen som en del av IaC-strategin och se konfigurationen som återspeglas i klustret automatiskt.

När du använder GitOps distribueras en agent i klustret för att se till att klustrets tillstånd samordnas med konfigurationen som lagras på din privata Git-lagringsplats. En sådan agent är flux, som använder en eller flera operatorer i klustret för att utlösa distributioner i Kubernetes. Flux utför följande uppgifter:

• Övervakar alla konfigurerade lagringsplatser.
• Identifierar nya konfigurationsändringar.
• Utlöser distributioner.
• Uppdaterar önskad körningskonfiguration baserat på dessa ändringar.

Du kan också ange principer som styr hur ändringarna distribueras.

Här är ett exempel som visar hur du automatiserar klusterkonfigurationen med GitOps och Flux:

Ladda ned en Visio-fil med den här arkitekturen.

1. En utvecklare genomför ändringar i källkoden, till exempel konfigurations-YAML-filer, som lagras på en Git-lagringsplats. Ändringarna skickas sedan till en Git-server.

2. Flux körs i en podd tillsammans med arbetsbelastningen. Flux har skrivskyddad åtkomst till Git-lagringsplatsen för att se till att Flux endast tillämpar ändringar som utvecklare begär.

3. Flux identifierar ändringar i konfigurationen och tillämpar dessa ändringar med hjälp av kubectl-kommandon.

4. Utvecklare har inte direkt åtkomst till Kubernetes API via kubectl.

Du kan ha grenprinciper på git-servern så att flera utvecklare sedan kan godkänna ändringar via en pull-begäran innan ändringen tillämpas på produktion.

Även om du kan konfigurera GitOps och Flux manuellt rekommenderar vi GitOps med Flux v2-klustertillägget för AKS.

Strategier för arbetsbelastnings- och klusterdistribution

Distribuera alla ändringar, till exempel arkitekturkomponenter, arbetsbelastningar och klusterkonfiguration till minst ett AKS-kluster för förproduktion. Detta simulerar ändringen och kan identifiera problem innan de distribueras till produktion.

Kör tester och valideringar i varje steg innan du går vidare till nästa. Det hjälper till att säkerställa att du kan push-överföra uppdateringar till produktionsmiljön på ett mycket kontrollerat sätt och minimera störningar från oväntade distributionsproblem. Distributionen bör följa ett liknande mönster som produktion genom att använda samma GitHub Actions-pipeline eller Flux-operatorer.

Avancerade distributionstekniker, till exempel blågrön distribution, A/B-testning och kanarieversioner, kräver extra processer och potentiellt extra verktyg. Flagger är en populär lösning med öppen källkod som hjälper dig att lösa avancerade distributionsscenarier.

Kostnadshantering

Börja med att granska designchecklistan för kostnadsoptimering och listan över rekommendationer som beskrivs i Well-Architected Framework för AKS. Använd Priskalkylatorn för Azure för att beräkna kostnaderna för de tjänster som du använder i arkitekturen. Andra metodtips finns i Kostnadsoptimering.

Överväg att använda AKS-kostnadsanalys för detaljerad kostnadsallokering av klusterinfrastruktur av Kubernetes-specifika konstruktioner.

Information om överväganden för Windows-specifik kostnadshantering finns i Windows-containrar på AKS.

Reservera

• Förstå var dina kostnader kommer ifrån. Det finns minimala kostnader för AKS i distribution, hantering och drift av Själva Kubernetes-klustret. Det som påverkar kostnaden är de VM-instanser, lagring, loggdata och nätverksresurser som används av klustret. Överväg att välja billigare virtuella datorer för systemnodpooler. Serien DS2_v2 är en typisk VM-typ för systemnodpoolen.

• Har inte samma konfiguration för utvecklings-/test- och produktionsmiljöer. Produktionsarbetsbelastningar har extra krav för hög tillgänglighet och är vanligtvis dyrare. Den här konfigurationen är inte nödvändig i utvecklings-/testmiljön.

• Lägg till ett serviceavtal för drifttid för produktionsarbetsbelastningar. Men det finns besparingar för kluster som är utformade för dev/test eller experimentella arbetsbelastningar där tillgänglighet inte krävs för att garanteras. SLO räcker till exempel. Om din arbetsbelastning stöder det bör du överväga att använda dedikerade nodpooler för oanvänd kapacitet som kör virtuella datorer med oanvänd kapacitet.

  För icke-produktionsarbetsbelastningar som inkluderar Azure SQL Database eller Azure App Service som en del av AKS-arbetsbelastningsarkitekturen bör du utvärdera om du är berättigad att använda Azure Dev/Test-prenumerationer för att få tjänstrabatter.

• Etablera ett kluster med det minsta antalet noder och gör det möjligt för klustrets autoskalning att övervaka och fatta storleksbeslut i stället för att börja med ett överdimensionerat kluster för att uppfylla skalningsbehoven.

• Ange poddbegäranden och gränser så att Kubernetes kan allokera nodresurser med högre densitet så att du använder maskinvara till kapacitet.

• Tänk på att när du aktiverar diagnostik i klustret kan det öka kostnaden.

• Genomför ett eller tre års Azure Reserved Virtual Machine-instanser för att minska nodkostnaderna om din arbetsbelastning måste finnas under en längre tid. Mer information finns i Spara kostnader med Azure Reserved Virtual Machine Instances.

• Använd taggar när du skapar nodpooler. Taggar hjälper dig när du skapar anpassade rapporter för att spåra kostnader som uppstår. Du kan använda taggar för att spåra de totala utgifterna och mappa eventuella kostnader till en specifik resurs eller ett visst team. Om klustret delas mellan team skapar du dessutom återbetalningsrapporter per konsument för att identifiera kostnader för delade molntjänster. Mer information finns i Ange en taint, etikett eller tagg för en nodpool.

• Förvänta dig extra bandbreddskostnader om din arbetsbelastning är flera regioner och du replikerar data mellan regioner. Mer information finns i Bandbreddspriser.

• Skapa budgetar för att hålla dig inom de kostnadsbegränsningar som din organisation identifierar. Du kan skapa budgetar via Microsoft Cost Management. Du kan också skapa aviseringar för att få meddelanden när vissa tröskelvärden överskrids. Mer information finns i Skapa en budget med hjälp av en mall.

Monitor

Du kan övervaka hela klustret och kostnaden för beräkning, lagring, bandbredd, loggar och brandväggen. Azure tillhandahåller alternativ för att övervaka och analysera kostnader:

• Azure Advisor

• Microsoft Cost Management

Helst bör du övervaka dina kostnader i realtid eller åtminstone vid en regelbunden takt. Du kan sedan vidta åtgärder före slutet av månaden när kostnaderna redan har beräknats. Övervaka även de månatliga trenderna över tid för att hålla dig kvar i budgeten.

För att fatta datadrivna beslut kan du fastställa vilken resurs på detaljerad nivå som kostar mest. Ha också en god förståelse för de mätare som beräknar resursanvändning. Genom att till exempel analysera mått kan du avgöra om plattformen är överdimensionerad. Du kan se användningsmätare i Azure Monitor-mått.

Optimera

Agera på rekommendationer från Azure Advisor. Det finns andra sätt att optimera:

• Aktivera autoskalning av kluster för att identifiera och ta bort underanvända noder i nodpoolen.

  Viktigt!

  Att aggressivt ändra autoskalningsinställningar för kluster, till exempel lägsta och högsta nodinställningar för en nodpool, för att påverka kostnaderna kan ha kontraproduktiva resultat. Om scale-down-unneeded-time det till exempel är inställt på 10 minuter och de minsta och högsta nodinställningarna ändras var femte minut baserat på arbetsbelastningens egenskaper, minskar aldrig antalet noder. Det beror på att beräkningen av den onödiga tiden för varje nod återställs på grund av att autoskalningsinställningarna för klustret uppdateras.

• Välj en lägre SKU för nodpoolerna om din arbetsbelastning stöder den.

• Om programmet inte kräver burst-skalning bör du överväga att ändra storleken på klustret till rätt storlek genom att analysera prestandamått över tid.

• Om din arbetsbelastning stöder det skalar du dina användarnodpooler till 0 noder när det inte finns några förväntningar på att de ska köras. Om det inte finns några arbetsbelastningar kvar som är schemalagda att köras i klustret kan du överväga att använda funktionen AKS start/stop för att stänga av all beräkning, vilket inkluderar systemnodpoolen och AKS-kontrollplanet.

Annan kostnadsrelaterad information finns i AKS-priser.

Nästa steg

• Avancerad ARKITEKTUR för AKS-mikrotjänster
• AKS-baslinje för kluster i flera regioner
• AKS-reglerat kluster för PCI-DSS 3.2.1
• Referensarkitektur för Windows-containrar i AKS-baslinje

Relaterade resurser

• AKS-översikt på GitHub
• Introduktion till Kubernetes
• Utveckla och distribuera program i Kubernetes
• Granskning av välarkitekterat ramverk för AKS
• ACCELERATOR för AKS-landningszon
• Aks dag-2-driftguide
• Arkitektur för mikrotjänster i AKS
• Använda Azure Firewall för att skydda ett AKS-kluster
• Git-åtgärder för AKS
• Dataströmning med AKS