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

Den här referensarkitekturen tillhandahåller en rekommenderad infrastrukturarkitektur för baslinje för att distribuera ett AKS-kluster (Azure Kubernetes Service) i Azure. Den använder våra designprinciper och baseras på våra metodtips för arkitektur från Azure Well-Architected Framework för att vägleda ett tvärvetenskapligt eller flera olika team som nätverk, säkerhet och identitet genom att distribuera den här allmänna infrastrukturen.

Den här arkitekturen fokuserar inte på en arbetsbelastning, utan fokuserar på själva AKS-klustret. Informationen här är den lägsta rekommenderade baslinjen för de flesta AKS-kluster. Den integreras med Azure-tjänster som levererar observerbarhet, en nätverkstopologi som stöder tillväxt i flera regioner och skyddar trafiken i klustret.

Målarkitekturen påverkas av dina affärskrav och kan därför variera mellan olika programkontexter. Det bör betraktas som din startpunkt för förproduktions- och produktionsfaser.

En implementering av den här arkitekturen är också tillgänglig på GitHub: Referensimplementering för Azure Kubernetes Service (AKS). Du kan använda den som en alternativ startpunkt och konfigurera den baserat på dina behov.

Nätverkskonfiguration

Nätverkstopologin
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 med nav-ekrar. Hubben och ekrarna distribueras i separata virtuella nätverk som är anslutna via peering. Några fördelar med den här topologin är:

• Separat hantering. Möjliggör ett sätt att tillämpa styrning och följa principen om lägsta behörighet. Det stöder också konceptet med en Azure-landningszon med ansvarsfördelning.

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

• Organisationer arbetar ofta med regionala hub-spoke-topologier. Hub-spoke-nätverkstopologier kan utökas i framtiden och tillhandahålla arbetsbelastningsisolering.

• Alla webbprogram bör kräva en WAF-tjänst (Web Application Firewall) för att styra HTTP-trafikflödet.

• Ett naturligt val för arbetsbelastningar som omfattar flera prenumerationer.

• Det gör arkitekturen utökningsbar. För att hantera nya funktioner eller arbetsbelastningar kan nya ekrar läggas till i stället för att omdesigna nätverkstopologin.

• Vissa resurser, till exempel en brandvägg och DNS, kan delas mellan nätverk.

• Överensstämmer med landningszonerna 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.

Om du vill granska ändringar i nätverksdesignen som ingår i Windows-containrarna i AKS-baslinjereferensarkitekturen läser du den tillhörande artikeln.

Hubb

Det virtuella hubbnätverket är den centrala platsen för anslutning och observerbarhet. En hubb innehåller alltid en Azure Firewall med globala brandväggsprinciper som definierats av dina centrala IT-team för att framtvinga en brandväggsprincip för hela organisationen, Azure Bastion, ett gateway-undernät för VPN-anslutning och Azure Monitor för nätverksobservabilitet.

I nätverket distribueras tre undernät.

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

Azure Firewall är en brandvägg som en tjänst. Brandväggsinstansen skyddar utgående nätverkstrafik. Utan det här säkerhetsskiktet kan den här trafiken kommunicera med en skadlig tredjepartstjänst som kan exfiltera känsliga företagsdata. Med Azure Firewall Manager kan du distribuera och konfigurera flera Azure Firewall-instanser centralt och hantera Azure Firewall-principer för den här typen av nätverksarkitektur för det virtuella hubbnätverket .

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

Det här undernätet är en platshållare för en VPN- eller 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 Bastion för säker åtkomst till Azure-resurser utan att exponera resurserna för Internet. Det här undernätet används endast för hantering och åtgärder.

Talade

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

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

Azure Application Gateway är en lastbalanserare för webbtrafik som körs på Layer 7. Referensimplementeringen använder Application Gateway v2 SKU som aktiverar Brandvägg för webbaserade program (WAF). WAF 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 ska uppfylla Kubernetes-ingressresurserna. De interna Azure-lastbalanserarna finns i det här undernätet. Mer information finns i Använda en intern lastbalanserare med Azure Kubernetes Service (AKS).

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

AKS underhåller två separata grupper av noder (eller nodpooler). 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 Private Link-slutpunkter

Azure Private Link-anslutningar skapas för Azure Container Registry och Azure Key Vault, så att dessa tjänster kan nås med hjälp av en privat slutpunkt i det virtuella ekernätverket. Privata slutpunkter kräver inte något dedikerat undernät och kan också placeras i det virtuella hubbnätverket. I baslinjeimplementeringen distribueras de till ett dedikerat undernät i det virtuella ekernätverket. Den här metoden minskar trafiken som skickar den peerkopplade nätverksanslutningen, behåller de resurser som tillhör klustret i samma virtuella nätverk och gör att du kan 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. IP-adresser för dessa entiteter allokeras från undernätets adressutrymme. Tänk på dessa punkter.

• Uppgradering

  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.

  För poddar kan du behöva ytterligare 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 kan varje podd kontaktas 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.

• Azure Private Link-adresser

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

• Vissa adresser är reserverade för användning av Azure. 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. För flera arbetsbelastningar kanske du vill isolera användarnodpoolerna från varandra och från systemnodpoolen. Det valet resulterar 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.

Om du vill granska övervägandena för IP-adressplanering som ingår i Windows-containrarna i AKS-baslinjereferensarkitekturen kan du läsa den kompletterande artikeln.

Tilläggs- och förhandsversionsfunktioner

Kubernetes och AKS utvecklar ständigt produkter 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. Skillnaden mellan de två är följande:

• AKS-teamet beskriver förhandsversionsfunktioner som levererade och förbättrade. Anledningen till detta är att många av förhandsversionsfunktionerna förblir i det tillståndet i bara några månader innan de övergår till den allmänna versionen (GA).
• AKS-tillägg och tillägg ger ytterligare funktioner som stöds. Deras installation, konfiguration och livscykel hanteras av AKS.

Den här baslinjearkitekturen innehåller inte alla förhandsgranskningsfunktioner eller tillägg, utan endast de som lägger till betydande värde i ett allmänt kluster ingår. Eftersom dessa funktioner kommer från förhandsversionen kommer den här baslinjearkitekturen att revideras i enlighet med detta. Det finns några ytterligare förhandsversionsfunktioner eller AKS-tillägg som du kanske vill utvärdera i förproduktionskluster som ökar din säkerhet, hanterbarhet eller andra krav. Med tillägg från tredje part 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 drar dem till klustret.

• Klustret autentiseras för att hämta avbildningen.

• Om du använder en offentlig avbildning bör du överväga att importera den till ditt containerregister som överensstämmer med ditt SLO. Annars kan avbildningen bli föremål för oväntade tillgänglighetsproblem. Dessa problem kan orsaka driftsproblem om avbildningen inte är tillgänglig när du behöver den. Här är några fördelar med att använda containerregistret i stället för ett offentligt register:

  • Du kan blockera obehörig åtkomst till dina bilder.
  • Du kommer inte att ha offentliga beroenden.
  • Du kan komma åt avbildningens pull-loggar för att övervaka aktiviteter och prioritera anslutningsproblem.
  • Dra nytta av integrerad containergenomsökning och bildefterlevnad.

  Ett alternativ är Azure Container Registry (ACR).

• 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 ACR som distribueras som en del av arkitekturen.

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. OS-disken ä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. Det minimerar fotavtrycket för tjänster som körs på alla noder, till exempel övervakning och loggning.

• 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.

• Faktiska nodstorlekar för din arbetsbelastning beror på de krav som bestäms av designteamet. Baserat på affärskraven har vi valt DS4_v2 för produktionsarbetsbelastningen. För att sänka kostnaderna kan man minska storleken till DS3_v2, vilket är den minsta rekommendationen.

• När du planerar kapacitet för klustret antar du att din arbetsbelastning kan förbruka upp till 80 % av varje nod. å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 utifrån klustrets perspektiv när du gör säkerhetsval:

• Åtkomst inifrån och ut. AKS-åtkomst till Azure-komponenter som nätverksinfrastruktur, Azure Container Registry och Azure Key Vault. Auktorisera endast de resurser som klustret har å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å sätten rekommenderas hanterade identiteter. Med tjänstens huvudnamn ansvarar du för att 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 hanterade identiteter aktiveras så att klustret kan interagera med externa Azure-resurser via Microsoft Entra-ID. Du kan bara aktivera den här inställningen när klustret skapas. Även om Microsoft Entra-ID inte används omedelbart kan du införliva det senare.

Som standard finns det två primära identiteter som används av klustret, klusteridentitetenoch kubelet-identiteten. Klusteridentiteten används av AKS-kontrollplanskomponenterna för att hantera klusterresurser, inklusive inkommande lastbalanserare, AKS-hanterade offentliga IP-adresser osv. Kubelet-identiteten används för att autentisera med Azure Container Registry (ACR). Vissa tillägg stöder även autentisering med hjälp av en hanterad identitet.

Som ett exempel för inifrån och ut-fallet ska vi studera användningen av 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. Ett sätt är att lagra den informationen i form av Kubernetes Secrets-objektet och använda imagePullSecrets för att hämta hemligheten. Den metoden rekommenderas inte på grund av säkerhetskomplexiteter. Du behöver inte bara förkunskaper om hemligheten utan även avslöjande av den hemligheten via DevOps-pipelinen. En annan orsak är driftkostnaderna för att hantera hemlighetens rotation. Bevilja acrPull i stället åtkomst till klustrets kubelet-hanterade identitet till registret. Den här metoden tar itu med dessa problem.

I den här arkitekturen får klustret åtkomst till Azure-resurser som skyddas av Microsoft Entra-ID och 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 tänker utföra. Klustret autentiserar sig till Microsoft Entra-ID och sedan tillåts eller nekas åtkomst baserat på de roller som det har tilldelats. Här följer några exempel från den här referensimplementeringen där inbyggda Azure-roller har tilldelats till klustret:

• Nätverksdeltagare. Klustrets möjlighet att styra det virtuella ekernätverket. Med den här rolltilldelningen kan AKS-klustersystemtilldelad identitet arbeta med det dedikerade undernätet för de interna ingresskontrollanttjänsterna.
• Övervaka Metrics Publisher. Klustrets möjlighet att skicka mått till Azure Monitor.
• AcrPull. Klustrets möjlighet att hämta avbildningar från de angivna Azure Container Registries.

Klusteråtkomst

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

AKS tillåter Kubernetes-åtkomst med hjälp av Microsoft Entra-ID på två sätt. Den första är att använda Microsoft Entra-ID som identitetsprovider integrerad med det interna Kubernetes RBAC-systemet. Den andra är att använda inbyggd Azure RBAC för att styra klusteråtkomsten. Båda beskrivs nedan.

Associera Kubernetes RBAC med Microsoft Entra-ID

Kubernetes stöder rollbaserad åtkomstkontroll (RBAC) via:

• En uppsättning behörigheter. Definieras av ett Role eller ClusterRole -objekt för klusteromfattande behörigheter.

• Bindningar som tilldelar användare och grupper som får utföra åtgärderna. Definieras av ett RoleBinding eller ClusterRoleBinding -objekt.

Kubernetes har vissa inbyggda roller som klusteradministratör, redigering, vy och så vidare. 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 dina Microsoft Entra-grupper som används för kluster- och namnområdesåtkomst ingår i dina Microsoft Entra-åtkomstgranskningar.

Använda Azure RBAC för Kubernetes-auktorisering

I stället för att använda Kubernetes inbyggda RBAC (ClusterRoleBindings och RoleBindings) för auktorisering med integrerad Microsoft Entra-autentisering, är ett annat alternativ som vi rekommenderar att du använder Rolltilldelningar i Azure RBAC och Azure för att tillämpa auktoriseringskontroller i klustret. Dessa rolltilldelningar kan till och med läggas till i prenumerations- eller resursgruppsomfången så att alla kluster under omfånget ärver 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. Användaråtkomst till kluster med den här metoden föreslås inte. Den är certifikatbaserad och utförs externt till din primära identitetsprovider. göra centraliserad användaråtkomstkontroll och styrning svår. Hantera alltid åtkomsten till klustret med hjälp av Microsoft Entra-ID och konfigurera klustret så att det uttryckligen inaktiverar åtkomsten till det lokala kontot.

I den här referensimplementeringen inaktiveras åtkomst via lokala klusterkonton explicit när klustret distribueras.

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 åtkomst till dessa filer autentiserar sig podden mot resursen som en Hanterad Azure-identitet.

I den här referensimplementeringen tillhandahålls hanterade identiteter för poddar via Microsoft Entra Workload ID på AKS. Detta integreras med kubernetes interna funktioner för att federera med externa identitetsprovidrar. Mer information om Microsoft Entra-arbetsbelastnings-ID-federation finns i följande översikt.

Distribuera inkommande resurser

Kubernetes Inkommande resurser dirigerar och distribuerar inkommande trafik till klustret. Det finns två delar av inkommande resurser:

• Interna lastbalanserare. Hanteras av AKS. Den här lastbalanseraren exponerar ingresskontrollanten via en privat statisk IP-adress. Den fungerar som en kontaktpunkt som tar emot inkommande flöden.

  I den här arkitekturen används Azure Load Balancer. Den placeras utanför klustret i ett undernät som är dedikerat för inkommande resurser. Den tar emot trafik från Azure Application Gateway och kommunikationen sker via TLS. Information om TLS-kryptering för inkommande trafik finns i Inkommande trafikflöde.

• Ingresskontrollant. Vi har valt 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 kritisk komponent i klustret. Tänk på dessa punkter när du konfigurerar den här komponenten.

• Som en del av dina designbeslut väljer du ett omfång inom vilket ingresskontrollanten ska tillåtas att fungera. 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 slutar fungera. 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 gör det möjligt för specifika entiteter att skicka trafik till ingresskontrollanten. I den här arkitekturen tar Traefik bara emot trafik från Azure Application Gateway.

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

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

Om du vill granska ingressdesignen som används i Windows-containrar i AKS-baslinjereferensarkitekturen läser du den tillhörande artikeln.

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. , annotationstlsoch entrypoints anger att vägar kommer att hanteras via HTTPS. middlewares Anger att endast trafik från Azure 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

Nätverksflödet kan i den här kontexten kategoriseras som:

• Inkommande trafik. Från klienten till arbetsbelastningen 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. Kommunikation mellan poddar. Den här trafiken omfattar kommunikation mellan ingresskontrollanten och arbetsbelastningen. Om din arbetsbelastning består av flera program som distribuerats till klustret skulle kommunikationen mellan dessa program också ingå i den här kategorin.

• Hanteringstrafik. Trafik som går 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 cyphers. SNI-strikt (Server Name Indication) är aktiverat. TLS från slutpunkt till slutpunkt konfigureras via Application Gateway med hjälp av två olika TLS-certifikat, som visas i den här bilden.

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 via en DNS A-post till den offentliga IP-adressen för Azure Application Gateway. 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 (WAF) och förhandlar om TLS-handskakningen för bicycle.contoso.com, vilket endast tillåter säkra chiffer. Application Gateway är en TLS-avslutningspunkt eftersom det krävs för att bearbeta WAF-inspektionsregler och köra routningsregler som vidarebefordrar trafiken till den konfigurerade serverdelen. TLS-certifikatet lagras i Azure Key Vault. Den används med hjälp av en användartilldelad hanterad identitet som är integrerad med Application Gateway. Information om den funktionen finns i TLS-avslutning med Key Vault-certifikat.

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

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

Du kan implementera TLS-trafik från slutpunkt till slutpunkt på varje hopp till arbetsbelastningspodden. Se till att mäta prestanda, svarstid och driftpåverkan 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 ingressstyrenheten och skyddar med Web Application Firewall (WAF). Det minimerar belastningen på arbetsbelastningshantering och 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 all utgående trafik från klustret som kommunicerar via Azure Firewall eller din egen liknande virtuella nätverksinstallation, jämfört med andra alternativ som NAT Gateway eller HTTP-proxy. För kontroll utan förtroende och möjlighet att inspektera trafik flyttas all utgående trafik från klustret genom Azure Firewall. Du kan implementera det valet med hjälp av användardefinierade vägar (UDR). Nästa hopp för vägen är den privata IP-adressen för Azure Firewall. Här avgör Azure Firewall om utgående trafik ska blockeras eller tillåtas. Det beslutet baseras på de specifika regler som definierats i Azure Firewall eller de inbyggda hotinformationsreglerna.

Ett alternativ till att använda Azure Firewall är att använda AKS HTTP Proxy-funktion . All trafik som utgående klustret först anges till IP-adressen för HTTP-proxyn, som bestämmer sig för att vidarebefordra trafiken eller släppa den.

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

Ett undantag till nollförtroendekontrollen är när klustret behöver kommunicera med andra Azure-resurser. Klustret måste till exempel hämta en uppdaterad avbildning från containerregistret eller hemligheter från Azure Key Vault. Den rekommenderade metoden är att använda Azure Private Link. Fördelen är att specifika undernät når tjänsten direkt i stället för trafiken mellan klustret och de tjänster som går via Internet. En nackdel är att Private Link behöver ytterligare konfiguration i stället för att använda måltjänsten över sin offentliga slutpunkt. Dessutom stöder inte alla Azure-tjänster eller SKU:er 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 dessa adresser läggas till i tjänstens IP-tillåtna lista. En nackdel är att Azure Firewall måste ha ytterligare regler för att se till att endast trafik från ett visst undernät tillåts. Räkna in 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 planering av flera IP-adresser finns i Begränsa och kontrollera utgående trafik.

Mer information om hur du granskar Windows-specifika utgående överväganden som används i Windows-containrar i referensarkitekturen för AKS-baslinjen finns i den kompletterande artikeln.

Podd-till-poddtrafik

Som standard kan en podd acceptera trafik från andra poddar i klustret. Kubernetes NetworkPolicy används för att begränsa nätverkstrafiken mellan poddar. Tillämpa principer på ett omdömesgillt sätt, annars 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 klustret etableras eftersom det inte kan läggas till senare. Det finns några alternativ för tekniker som implementerar NetworkPolicy. Azure Network Policy rekommenderas, vilket kräver Azure Container Networking Interface (CNI), se kommentaren nedan. Andra alternativ är Calico Network Policy, 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 Network Policy och Calico-principer och deras funktioner.

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 eller skala klustret. Exempel på dessa resurser är byggagentpoolen i en DevOps-pipeline, ett Bastion-undernät och själva nodpoolerna. I stället för att acceptera den här hanteringstrafiken från alla IP-adresser använder du AKS-funktionen 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.

Om du vill ha ytterligare ett kontrolllager kan du etablera ett privat AKS-kluster på bekostnad av ytterligare komplexitet. Genom att använda ett privat kluster kan du se till att nätverkstrafik mellan DIN API-server och dina nodpooler endast finns kvar i det privata nätverket, att den inte exponeras för Internet. Mer information finns i PRIVATA AKS-kluster.

Lägg till hemlighetshantering

Lagra hemligheter i ett hanterat nyckelarkiv, till exempel Azure Key Vault. Fördelen är att det hanterade arkivet hanterar rotation av hemligheter, erbjuder stark kryptering, tillhandahåller en åtkomstgranskningslogg och håller kärnhemligheter borta från distributionspipelinen. I den här arkitekturen är Azure Key Vault-brandväggen aktiverad och konfigurerad med privata länkanslutningar till de resurser i Azure som behöver åtkomst till hemligheter och certifikat.

Azure 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. Ett exempel på hur Azure 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 komma åt hemligheterna. Mer information finns i Access Azure Key Vault using RBAC (Åtkomst till Azure Key Vault med 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 lager. För att underlätta hämtningsprocessen använder du en CSI-drivrutin för Secrets Store. När podden behöver en hemlighet ansluter drivrutinen till det angivna arkivet, hämtar hemligheten 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. I den här implementeringen har vi valt Azure Key Vault med Secrets Store CSI-drivrutinen med hjälp av tillägget för att hämta TLS-certifikatet från Azure Key Vault och läsa in det i podden som kör ingresskontrollanten. Det görs när podden skapas och volymen lagrar både offentliga och privata nycklar.

Lagring av arbetsbelastningar

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

Mer information om lagringsalternativ finns i Lagringsalternativ för program i Azure Kubernetes Service (AKS).

Principhantering

Ett effektivt sätt att hantera ett AKS-kluster är genom att framtvinga styrning via principer. Kubernetes implementerar principer via OPA Gatekeeper. För AKS levereras principer via Azure Policy. Varje princip tillämpas på alla kluster i dess omfång. Azure Policy-tillämpning hanteras slutligen av OPA Gatekeeper i klustret och alla principkontroller loggas. Principändringar återspeglas inte omedelbart i klustret, förvänta dig att se vissa fördröjningar.

Det finns två olika scenarier som Azure Policy levererar för att hantera dina AKS-kluster:

• Förhindra eller begränsa distributionen av AKS-kluster i en resursgrupp eller prenumeration genom att utvärdera organisationens standarder. Följ till exempel en namngivningskonvention, ange en tagg osv.
• 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 (kallas 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 och väljer ytterligare principer för klustret och de resurser (ACR, Application Gateway, Key Vault och andra) som interagerar med klustret enligt organisationens krav.

• Vill du granska eller neka åtgärden? I granskningsläge tillåts åtgärden men den flaggas som icke-kompatibel. Ha processer för att kontrollera icke-kompatibla 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 om hur du skapar anpassade principer 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 organisationen har allmänna principer.

• Azure-principer tilldelas 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 ytterligare begränsningar som inte har redovisats i förproduktion.

I den här referensimplementeringen aktiveras Azure Policy när AKS-klustret skapas och tilldelar det restriktiva initiativet i granskningsläge för att få insyn i bristande efterlevnad.

Implementeringen anger även ytterligare 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 ACR:en. Ö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 samt loggarna för azure-policy poddarna och azure-policy-webhook i kube-system namnområdet.

Information om hur du granskar Windows-specifika Azure Policy-överväganden som ingår i Windows-containrar i referensarkitekturen för AKS-baslinjen finns i den kompletterande artikeln.

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 (HPA). När ytterligare poddar inte längre kan schemaläggas måste antalet noder ökas via 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.

Det manuella eller programmatiska sättet kräver att du övervakar och ställer in aviseringar om CPU-användning eller anpassade mått. För poddskalning kan programoperatorn öka eller minska antalet poddrepliker genom att ReplicaSet justera via Kubernetes-API:er. För klusterskalning är ett sätt att få ett meddelande 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 portalen.

Autoskalning är den rekommenderade metoden eftersom vissa av dessa manuella mekanismer är inbyggda i autoskalningen.

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. 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 rekommenderas att du anger minsta och högsta antal repliker. Dessa värden begränsar gränserna för automatisk skalning.

HPA kan skalas baserat på CPU-användning, minnesanvändning och anpassade mått. Endast CPU-användning tillhandahålls direkt. HorizontalPodAutoscaler-definitionen anger målvärden för dessa mått. Specifikationen anger till exempel en mål-CPU-användning. 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 kontrollerar innan en skalningsåtgärd har slutförts. 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 KEDA. Överväg KEDA om din arbetsbelastning drivs av en händelsekälla, till exempel meddelandekö, i stället för att vara CPU- eller minnesbunden. KEDA stöder många händelsekällor (eller skalare). Du hittar listan över KEDA-skalare som stöds här , inklusive Azure Monitor-skalning, 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. Det bör läggas till under klusteretablering. Du behöver en separat kluster autoskalning för varje användarnodpool.

Autoskalning av kluster utlöses av Kubernetes-schemaläggaren. 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 på 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 2 på grund av arbetsbelastningens enkla karaktär.

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

Mer information om skalning som ingår i Windows-containrar i REFERENSarkitektur för AKS-baslinje finns i den kompletterande artikeln.

Beslut om affärskontinuitet

För att upprätthålla affärskontinuitet definierar du servicenivåavtalet för infrastrukturen och ditt program. Information om månatlig drifttidsberäkning finns i SLA för Azure Kubernetes Service (AKS).

Klusternoder

För att uppfylla den lägsta tillgänglighetsnivån för arbetsbelastningar krävs flera noder i en nodpool. Om en nod går ned kan en annan nod i nodpoolen i samma kluster fortsätta att köra programmet. För tillförlitlighet rekommenderas 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 dina program från systemtjänsterna genom att placera dem 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. Användning av taggar, etiketter och taints rekommenderas för att identifiera nodpoolen för att schemalägga din arbetsbelastning och se till att systemnodpoolen är fläckad med CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

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

Kontrollera poddresurser. Vi rekommenderar starkt att distributioner anger krav för poddresurser. Schemaläggaren kan sedan schemalägga podden på lämpligt sätt. Tillförlitligheten kommer att bli avsevärt inaktuell om 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 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 säkerställer att poddbegäranden och gränser har angetts korrekt för en distribution. Mer information finns i Framtvinga resurskvoter.

Ange poddbegäranden och gränser. Genom att ställa in dessa gränser kan Kubernetes effektivt allokera processor- och/eller minnesresurser till poddarna och ha högre containerdensitet på en nod. Begränsningar kan också öka tillförlitligheten med minskade kostnader på grund av bättre maskinvaruanvändning.

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

Dessa gränser kan anges i distributionsmanifesten. Mer information finns i Ange poddbegäranden och gränser.

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

Om ditt serviceavtal kräver en högre drifttid kan du skydda mot avbrott med hjälp av tillgänglighetszoner. Du kan använda 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. Skalningsuppsättningsåtgärder och konfiguration hanteras av AKS-tjänsten. Här följer några saker att tänka på när du aktiverar multizon:

• Hela infrastrukturen. Välj en region som stöder tillgänglighetszoner. Mer information finns i Begränsningar och regiontillgänglighet. Om du vill köpa ett serviceavtal för drifttid väljer du en region som stöder det alternativet. Serviceavtalet för drifttid är större när du använder tillgänglighetszoner.

• Kluster. Tillgänglighetszoner kan bara anges när nodpoolen skapas och 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.

  Multizone-stöd 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å ha stöd för zoner. Om en beroende tjänst inte stöder zoner är det möjligt att ett zonfel kan orsaka att tjänsten misslyckas.

En hanterad disk är till exempel tillgänglig i den zon där den etableras. Om ett fel uppstår kan noden flyttas till en annan zon, men den hanterade disken flyttas inte med noden till den zonen.

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

Flera regioner

Det räcker inte att aktivera tillgänglighetszoner om hela regionen slutar fungera. Om du vill ha högre tillgänglighet kör du flera AKS-kluster i olika regioner.

• Använd parkopplade regioner. Överväg att använda en CI/CD-pipeline som är konfigurerad för att använda en länkad region för att återställa från regionfel. En fördel med att använda kopplade regioner är tillförlitlighet under uppdateringar. Azure ser till att endast en region i paret uppdateras i taget. Vissa DevOps-verktyg som Flux kan göra distributioner i flera regioner enklare.

• Om en Azure-resurs stöder geo-redundans anger du den plats där den redundanta tjänsten ska ha sin sekundära. Om du till exempel aktiverar geo-replikering för Azure Container Registry replikeras automatiskt avbildningar till de valda Azure-regionerna och ger fortsatt åtkomst till avbildningar även om en region drabbats av ett avbrott.

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

Haveriberedskap

Vid fel i den primära regionen bör du snabbt kunna skapa en ny instans i en annan region. Här följer några rekommendationer:

• Använd parkopplade regioner.

• En icke-tillståndskänslig arbetsbelastning kan replikeras effektivt. Om du behöver lagra tillståndet i klustret (rekommenderas inte) kontrollerar du att du säkerhetskopierar data ofta i den kopplade regionen.

• Integrera återställningsstrategin, till exempel att replikera till en annan region, som en del av DevOps-pipelinen för att uppfylla dina servicenivåmål (SLO).

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

Säkerhetskopiering av kluster

För många arkitekturer kan etablering av ett nytt kluster och återställa det till driftstillstånd utföras via GitOps-baserade [Klusterstövlar}(#cluster-bootstrapping) och följt av programdistribution. Men om det finns ett kritiskt resurstillstånd, till exempel konfigurationskartor, jobb och potentiellt hemligheter som av någon anledning inte kan fångas in i din startprocess, bör du överväga din återställningsstrategi. Vi rekommenderar vanligtvis att du kör tillståndslösa arbetsbelastningar i Kubernetes, men om arkitekturen omfattar diskbaserat tillstånd måste du också ö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 Azure Disk-baserade, beständiga volymögonblicksbilder.

VMwares Velero är ett exempel på en vanlig Kubernetes-säkerhetskopieringslösning som du kan installera och hantera direkt. Alternativt kan AKS-säkerhetskopieringstillägget användas 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 skulle innebära extra Azure-resurser i arkitekturen för att hantera, övervaka, betala för och skydda. till exempel ett Azure Storage-konto, Azure Backup-valv och konfiguration och betrodd åtkomst. GitOps kombinerat med avsikten att köra tillståndslös arbetsbelastning är återställningslösningen implementerad.

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

Kubernetes API Server SLA

AKS kan användas som en kostnadsfri tjänst, men den nivån erbjuder inte ett ekonomiskt stödda serviceavtal. För att få det serviceavtalet måste du välja Standardnivå. Vi rekommenderar att alla produktionskluster använder standardnivån. Reservera kluster på den kostnadsfria nivån för förproduktionskluster. I kombination med Azure Tillgänglighetszoner ökas Kubernetes API-server-SLA till 99,95 %. Dina nodpooler och andra resurser omfattas av ett eget serviceavtal.

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 Azure Container Registry, är tillgängliga i premium-SKU:er, vilket är dyrare. Kostnaden kommer också att öka eftersom bandbreddsavgifter som tillämpas när trafiken flyttas mellan zoner och regioner.

Förvänta dig också ytterligare 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

Säkerställa tillförlitlighet genom tvingad redundanstestning med simulerade avbrott, till exempel stoppa en nod, ta bort alla AKS-resurser i en viss zon för att simulera ett zonfel eller anropa ett externt beroendefel. Azure Chaos Studio kan också användas för att simulera olika typer av avbrott i Azure och i klustret.

Mer information finns i Azure Chaos Studio.

Övervaka och samla in mått

Azure Monitor Container Insights är det rekommenderade verktyget 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 Metrics API 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 den för att övervaka prestanda när poddarna skalas. Den innehåller insamling av telemetri som är kritisk för övervakning, analys och visualisering av insamlade data för att identifiera trender och konfigurera aviseringar så att de meddelas proaktivt om kritiska problem.

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

Det finns några lösningar från tredje part som integreras med Kubernetes som du kan dra nytta av, till exempel Datadog, Grafana eller New Relic, om din organisation redan använder dem.

Med AKS hanterar Azure vissa viktiga Kubernetes-tjänster och loggarna för AKS-kontrollplanskomponenterna implementeras i Azure som resursloggar. Vi rekommenderar att de flesta kluster alltid har följande aktiverat eftersom de kan hjälpa dig att felsöka klusterproblem och ha en relativt låg loggdensitet:

• Logga in på ClusterAutoscaler för att få observerbarhet i skalningsåtgärderna. Mer information finns i Hämta loggar och status för autoskalning av kluster.
• KubeControllerManager att ha observerbarhet i interaktionen mellan Kubernetes och Azure-kontrollplanet.
• KubeAuditAdmin att ha observerbarhet i aktiviteter som ändrar klustret. Det finns ingen anledning att både ha både KubeAudit och KubeAuditAdmin aktiverade, eftersom KubeAudit är en supermängd kubeAuditAdminsom även innehåller icke-ändrande (läsåtgärder).
• Guard samlar in Microsoft Entra ID- och Azure RBAC-granskningar.

Andra loggkategorier, till exempel KubeScheduler eller KubeAudit, kan vara mycket användbara för att aktivera under utveckling av tidiga kluster- eller arbetsbelastningslivscykler, där extra kluster autoskalning, poddplacering och schemaläggning och liknande data kan hjälpa till att felsöka problem med kluster- eller arbetsbelastningsåtgärder. Att behålla de utökade felsökningsloggarna på heltid när felsökningsbehoven är över kan betraktas som en onödig kostnad för att mata in och lagra 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 hjälper till att möjliggöra ytterligare observerbarhet i hälsotillståndet och prestandan för dina AKS-kluster och stöder dina servicenivåmål (SLO).

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

Mer information om hur du granskar Windows-specifika övervakningsöverväganden som ingår i Windows-containrar i referensarkitekturen för AKS-baslinjen finns i den kompletterande artikeln.

Aktivera självåterställning

Övervaka hälsotillståndet för poddar genom att ange liveness- och beredskapsavsökningar. Om en podd som inte svarar identifieras startar Kubernetes om podden. Liveness-avsökningen avgör om podden är felfri. Om den inte svarar startar Kubernetes om podden. Beredskapsavsökningen avgör om podden är redo att ta emot begäranden/trafik.

AKS-klusteruppdateringar

Det är av största vikt att definiera en uppdateringsstrategi som överensstämmer med affärskraven. Att förstå förutsägbarhetsnivån för datum och tid när AKS-klusterversionen eller dess noder uppdateras, och den önskade graden av kontroll över vilka specifika avbildningar eller binärfiler som installeras är grundläggande aspekter som kommer att avgränsa aks-klusteruppdateringsritningen. Förutsägbarheten är kopplad till två viktiga aks-klusteruppdateringsegenskaper som är uppdateringstakts- och underhållsfönstret. Kontrollen är om uppdateringar installeras manuellt eller automatiskt. Organisationer med AKS-kluster som inte omfattas av en strikt säkerhetsförordning kan överväga veckovisa eller till och med månatliga uppdateringar, medan resten måste uppdatera säkerhetsmärkta korrigeringar så snart som möjligt (dagligen). Organisationer som använder AKS-kluster som oföränderlig infrastruktur uppdaterar dem inte. Det innebär att varken automatiska eller manuella uppdateringar utförs. I stället när en önskad uppdatering blir tillgänglig distribueras en replikstämpel och endast när den nya infrastrukturinstansen är klar töms den gamla, vilket ger dem den högsta kontrollnivån.

När skissen för AKS-klusteruppdatering har fastställts kan den enkelt mappas till tillgängliga uppdateringsalternativ för AKS-noder och AKS-klusterversion:

• AKS-noder:

  1. Inga/manuella uppdateringar: Detta är för oföränderlig infrastruktur eller när manuella uppdateringar är inställningen. Detta ger bättre förutsägbarhet och kontroll över AKS-noduppdateringarna.
  2. Automatiska obevakade uppdateringar: AKS kör interna OS-uppdateringar. Detta ger förutsägbarhet genom att konfigurera underhållsperioder i linje med vad som är bra för verksamheten. Det kan vara baserat på rusningstid och vad som är bäst driftsmässigt. Kontrollnivån är låg eftersom det inte går att veta i förväg vad som kommer att installeras specifikt i AKS-noden.
  3. Automatiska nodbilduppdateringar: Vi rekommenderar att aks-nodbilder uppdateras automatiskt när nya virtuella hårddiskar blir tillgängliga. Designunderhållsfönster som ska justeras så mycket som möjligt med företagets behov. För säkerhetsmärkta VHD-uppdateringar rekommenderar vi att du konfigurerar ett dagligt underhållsfönster som ger lägst förutsägbarhet. Regelbundna VHD-uppdateringar kan konfigureras med en veckovis underhållsperiod, varannan vecka eller till och med varje månad. Beroende på om behovet är för säkerhetsmärkta eller vanliga virtuella hårddiskar i kombination med det schemalagda underhållsfönstret varierar förutsägbarheten och ger mer eller mindre flexibilitet för att anpassas till affärskraven. Även om det alltid skulle vara idealiskt att lämna detta till affärskraven, ger verkligheten organisationer i uppdrag att hitta tipping point. Kontrollnivån är låg eftersom det inte går att veta i förväg vilka specifika binärfiler som ingår i en ny virtuell hårddisk och fortfarande är den här typen av automatiska uppdateringar det rekommenderade alternativet eftersom bilder granskas innan de blir tillgängliga.

  Kommentar

  Mer information om hur du konfigurerar automatiska UPPDATERINGAR av AKS-noder finns i Avbildningar av operativsystemet för automatisk uppgradering av noder.

• AKS-klusterversion:

  1. Inga/manuella uppdateringar: Detta är för oföränderlig infrastruktur eller när manuella uppdateringar är inställningen. Detta ger bättre förutsägbarhet och kontroll över uppdateringarna av AKS-klustrets version. Anmäl dig för detta rekommenderas eftersom det ger fullständig kontroll, vilket ger möjlighet att testa en ny AKS-klusterversion (dvs. 1.14.x till 1.15.x) i lägre miljöer innan du når produktionen.
  2. Automatiska uppdateringar: Ett produktionskluster rekommenderas inte att automatiskt korrigeras eller uppdateras på något sätt (t.ex. 1.16.x till 1.16.y) till en ny TILLGÄNGLIG AKS-klusterversion utan att testas korrekt i lägre miljöer. Kubernetes uppströmsversioner och uppdateringar av AKS-klusterversioner samordnas med en regelbunden takt, men rekommendationen är fortfarande att vara defensiv med AKS-kluster i produktion som ökar förutsägbarheten och kontrollen över uppdateringsprocessen. Mot bakgrund av den här konfigurationen för lägre miljöer som en del av operational excellence, så att proaktiva rutinmässiga testningskörningar kan identifiera potentiella problem så tidigt som möjligt.

Håll Kubernetes-versionen uppdaterad med de N-2-versioner som stöds. Det är viktigt att uppgradera till den senaste versionen av Kubernetes eftersom nya versioner släpps ofta.

Mer information finns i Uppdatera regelbundet till den senaste versionen av Kubernetes och Uppgradera ett AkS-kluster (Azure Kubernetes Service).

Meddelanden om händelser som genereras av klustret, till exempel ny tillgänglighet för AKS-version för klustret, kan göras via AKS-systemämnet för Azure Event Grid. Referensimplementeringen distribuerar det här Event Grid-systemämnet så att du kan prenumerera på Microsoft.ContainerService.NewKubernetesVersionAvailable händelsen från din händelseströmaviseringslösning.

Veckouppdateringar

AKS tillhandahåller nya nodavbildningar som har de senaste uppdateringarna av operativsystemet och körningen. Dessa nya bilder tillämpas inte automatiskt. Du ansvarar för att bestämma hur ofta bilderna ska uppdateras. Vi rekommenderar att du har en process för att uppgradera nodpoolernas basavbildning varje vecka. Mer information finns i Azure Kubernetes Service (AKS) node image upgrade the AKS Release Notes (Aks Release Notes).

Dagliga uppdateringar

Mellan avbildningsuppgraderingar laddar AKS-noder ned och installerar os- och körningskorrigeringar individuellt. En installation kan kräva att de virtuella noddatorerna startas om. AKS startar inte om noder på grund av väntande uppdateringar. Ha en process som övervakar noder för de tillämpade uppdateringarna som kräver en omstart och utför omstarten av dessa noder på ett kontrollerat sätt. Ett alternativ med öppen källkod är Kured (Kubernetes reboot daemon).

Om du håller nodbilderna synkroniserade med den senaste veckoversionen minimeras dessa tillfälliga omstartsbegäranden samtidigt som en förbättrad säkerhetsstatus bibehålls. Om du bara förlitar dig på nodbilduppgraderingar säkerställs AKS-kompatibilitet och veckovis säkerhetskorrigering. Att tillämpa dagliga uppdateringar löser säkerhetsproblem snabbare, men de har inte nödvändigtvis testats i AKS. Använd där det är möjligt en uppgradering av nodbilden som din primära strategi för säkerhetskorrigering varje vecka.

Säkerhetsövervakning

Övervaka containerinfrastrukturen för både aktiva hot och potentiella säkerhetsrisker:

• Aktivera Microsoft Defender för containrar för att identifiera och åtgärda Defender för molnet rekommendationer för dina containeravbildningar.
• Microsoft Defender for Containers söker regelbundet igenom dina containeravbildningar efter säkerhetsrisker.
• Microsoft Defender för containrar genererar också säkerhetsaviseringar i realtid för misstänkta aktiviteter.
• Information om säkerhetshärdning som tillämpas på virtuella AKS-datorvärdar finns i Säkerhetshärdning i värdoperativsystemet.

Kluster- och arbetsbelastningsåtgärder (DevOps)

Här följer några överväganden. Mer information finns i grundpelare för driftskvalitet .

Klusterstövlar

När etableringen är klar har du ett fungerande kluster, men det kan fortfarande krävas steg innan du distribuerar arbetsbelastningar. Processen med att förbereda klustret kallas bootstrapping och kan bestå av åtgärder som att distribuera nödvändiga avbildningar till klusternoder, skapa namnområden och allt annat som uppfyller kraven i ditt användningsfall eller din organisation.

För att minska klyftan mellan ett etablerat kluster och ett kluster som har konfigurerats korrekt bör klusteroperatorerna tänka på hur deras unika bootstrappingprocess kommer att se ut och förbereda relevanta tillgångar i förväg. Om det till exempel är viktigt att kured körs på varje nod innan programarbetsbelastningar distribueras, vill klusteroperatorn se till att en ACR som innehåller mål-Kured-avbildningen redan finns innan klustret etableras.

Bootstrapping-processen kan konfigureras med någon av följande metoder:

• Självkonfiguration med något som Flux eller Argo CD
• Pipelines
• GitOps Flux v2-klustertillägg

En av de största fördelarna med att använda GitOps Flux v2-klustertillägget för AKS är att det i själva verket 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 inkludering av den bootstrappingen som resursmallar för att anpassa sig till din IaC-strategi.

Slutligen, när du använder tillägget, kubectl krävs inte för någon del av bootstrapping-processen, och användning av kubectl-baserad åtkomst kan reserveras för nödsituationsbrottskorrigeringar. Mellan mallar för Azure-resursdefinitioner och start av manifest via GitOps-tillägget kan alla normala konfigurationsaktiviteter utföras utan att du behöver 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 ekern och undernäten i dessa nätverk. Ekern har till exempel separata undernät för system- och användarnodpooler och ingressresurser. Ett undernät för Azure Firewall i hubben.

En annan del kan vara att integrera den grundläggande arbetsbelastningen med Microsoft Entra-ID.

Använda infrastruktur som kod (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. Ett alternativ är en ARM-mall (Azure Resource Manager). En annan är Terraform.

Se till att när du etablerar resurser enligt de styrande principerna. När du till exempel väljer rätt VM-storlekar håller du dig inom kostnadsbegränsningarna, alternativen för tillgänglighetszoner för att matcha kraven för ditt program.

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

Lagra och versionsskript och mallfiler i källkontrollsystemet.

CI/CD för arbetsbelastning

Pipelines för arbetsflöde och distribution måste ha möjlighet att skapa och distribuera program kontinuerligt. Uppdateringar måste distribueras säkert och snabbt och återställas om det uppstår problem.

Distributionsstrategin måste innehålla en tillförlitlig och automatiserad pipeline för kontinuerlig leverans (CD). Ändringar i dina containeravbildningar för arbetsbelastningar ska distribueras automatiskt till klustret.

I den här arkitekturen har vi valt GitHub Actions för att hantera arbetsflödet och distributionen. Andra populära alternativ är Azure DevOps Services 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 att släppa en ny version och validera 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 start av ett nyligen etablerat kluster. En GitOps-metod är användbar för det här ändamålet, vilket gör det möjligt för operatörer att 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.
• Uppdateringar önskad konfiguration som körs baserat på dessa ändringar.

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

Här är ett exempel som visar hur du automatiserar klusterkonfigurationen med GitOps och flöde:

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

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

2. Flux körs i podden 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:et via kubectl.

5. Ha grenprinciper på Din Git-server. På så sätt kan flera utvecklare godkänna en ändring via en pull-begäran innan den tillämpas på produktion.

GitOps och Flux kan konfigureras manuellt, men GitOps med Flux v2-klustertillägget rekommenderas för AKS.

Strategier för arbetsbelastnings- och klusterdistribution

Distribuera alla ändringar (arkitekturkomponenter, arbetsbelastning, klusterkonfiguration) till minst ett AKS-kluster för förproduktion. Om du gör det simuleras att ändringen kan lösa problem innan du distribuerar till produktion.

Kör tester/valideringar i varje steg innan du går vidare till nästa för att se till att du kan skicka uppdateringar till produktionsmiljön på ett mycket kontrollerat sätt och minimera störningar från oväntade distributionsproblem. Den här distributionen bör följa ett liknande mönster som produktion med samma GitHub Actions-pipeline eller Flux-operatorer.

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

Kostnadshantering

Börja med att granska checklista för kostnadsoptimeringsdesign och lista ö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 används i arkitekturen. Andra metodtips beskrivs i avsnittet Kostnadsoptimering i Microsoft Azure Well-Architected Framework.

Överväg att aktivera AKS-kostnadsanalys för detaljerad klusterinfrastrukturkostnadsallokering av Kubernetes-specifika konstruktioner.

Mer information om kostnadshantering som är specifika för Windows-baserade arbetsbelastningar som ingår i Windows-containrarna i AKS-referensarkitekturen finns i den tillhörande artikeln.

Reservera

• Det finns inga kostnader som är kopplade till AKS vid distribution, hantering och drift av Kubernetes-klustret. Vad påverkar kostnaden är de virtuella datorinstanser, lagrings-, loggdata- och nätverksresurser som används av klustret. Överväg att välja billigare virtuella datorer för systemnodpooler. SKU :n 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. Det finns dock besparingar för kluster som är utformade för utvecklings-/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.

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

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

• Om du aktiverar diagnostik i klustret kan kostnaden öka.

• Om din arbetsbelastning förväntas finnas under en lång period kan du checka in på en eller tre års reserverade virtuella datorinstanser för att minska nodkostnaderna. Mer information finns i Reserverade virtuella datorer.

• Använd taggar när du skapar nodpooler. Taggar är användbara när du skapar anpassade rapporter för att spåra de kostnader som uppstår. Taggar ger möjlighet att spåra det totala antalet utgifter 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.

• Dataöverföringar mellan tillgänglighetszoner i en region är inte kostnadsfria. Om din arbetsbelastning är i flera regioner eller om det finns överföringar mellan tillgänglighetszoner kan du förvänta dig ytterligare bandbreddskostnad. Mer information finns i Trafik mellan faktureringszoner och regioner.

• Skapa budgetar för att hålla dig inom de kostnadsbegränsningar som organisationen har identifierat. Ett sätt är att skapa budgetar via Azure 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

För att övervaka kostnaden för hela klustret, tillsammans med beräkningskostnaden, samlar du även in kostnadsinformation om lagring, bandbredd, brandvägg och loggar. Azure tillhandahåller olika instrumentpaneler för att övervaka och analysera kostnader:

• Azure Advisor

• Azure Cost Management

Helst bör du övervaka kostnaden i realtid eller åtminstone vid en regelbunden takt för att vidta åtgärder före slutet av månaden när kostnaderna redan beräknas. Övervaka även den månatliga trenden över tid för att hålla dig kvar i budgeten.

För att fatta datadrivna beslut ska du fastställa vilken resurs (detaljerad nivå) som kostar mest. Har också en god förståelse för de mätare som används för att beräkna användningen av varje resurs. Genom att analysera mått kan du avgöra om plattformen till exempel ä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 underutnyttjarade noder i nodpoolen.

• 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

Fortsätt att lära dig om AKS-baslinjearkitekturen:

• Mer information om hur du är värd för mikrotjänster på AKS-baslinjen finns i Avancerad Azure Kubernetes Service-mikrotjänstarkitektur (AKS).
• Information om hur du distribuerar AKS-baslinjen i flera regioner finns i AKS-baslinjen för kluster i flera regioner.
• Information om hur du distribuerar AKS-baslinjen till en PCI-DSS 3.2.1-miljö finns i AKS-reglerade kluster för PCI-DSS 3.2.1.
• Mer information om överväganden för att lägga till Windows-containrar i referensarkitekturen finns i den kompletterande artikeln: Windows-containrar i REFERENSarkitektur för AKS-baslinje

Läs mer om AKS

• Granska AKS-produktöversikten i Azure Kubernetes Service Roadmap på GitHub.
• Om du behöver en uppdatering på Kubernetes slutför du introduktionen till Kubernetes och utvecklar och distribuerar program på Kubernetes utbildningsvägar.

Relaterade resurser

Se följande relaterade guider:

• Azure Well-Architected Framework-granskning för Azure Kubernetes Service (AKS)
• AKS-acceleratorn för landningszoner, som är en implementering i företagsskala baserat på den här arkitekturen. Acceleratorn hjälper dig att konfigurera Din Azure-miljö på ett konsekvent och upprepningsbart sätt med hjälp av IaC (Infrastructure-As-Code) för en Azure Kubernetes Service-distribution (AKS).
• Dagsguide för Azure Kubernetes Services (AKS) dag-2

Se följande relaterade arkitekturer:

• Arkitektur för mikrotjänster i Azure Kubernetes Service
• Använda Azure Firewall för att skydda ett AKS-kluster (Azure Kubernetes Service)
• GitOps för Azure Kubernetes Service
• Dataströmning med AKS