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

I den här referensarkitekturen skapar vi en baslinjeinfrastruktur som distribuerar Azure Kubernetes Service kluster (AKS). Den här artikeln innehåller rekommendationer för nätverk, säkerhet, identitet, hantering och övervakning av klustret baserat på en organisations affärsbehov.

implementering av den här arkitekturen finns på GitHub: Azure Kubernetes Service (AKS) Secure Baseline Reference Implementation. Du kan använda den som utgångspunkt och konfigurera den efter dina behov.

Nätverkskonfiguration

Nätverkstopologi
Planera IP-adresserna
Distribuera ingressresurser

Klusterbearbetning

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

Identitetshantering

Integrera Azure AD för klustret
Integrera Azure AD för arbetsbelastningen

Skydda dataflöde

Skydda nätverksflödet
Lägga till hemlighetshantering

Verksamhetskontinuitet

Skalbarhet
Tillgänglighet för kluster och noder
Tillgänglighet och stöd för flera regioner

Operations

CI/CD-pipelines för kluster och arbetsbelastningar
Klusterhälsa och mått
Kostnadshantering och rapportering

Nätverkstopologi

Den här arkitekturen använder en nätverkstopologi av nav och ekrar. Nav och ekrar distribueras i separata virtuella nätverk som är anslutna via peering. Några av fördelarna med den här topologin är:

• Åtskild hantering. Det gör det möjligt för ett sätt att tillämpa styrning och styra radien. Det stöder också begreppet landningszon med aparering av uppgifter.

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

• Organisationer arbetar ofta med regionala hub-spoke-topologier. Nätverks topologier av hub-spoke-ekrar kan utökas i framtiden och ge arbetsbelastningsisolering.

• Alla webbprogram bör kräva en brandväggstjänst för webbaserade program (WAF) för att styra HTTP-trafikflöden.

• Ett naturligt val för arbetsbelastningar som sträcker sig över 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 ändra nätverkstopologin.

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

Hubb

Det virtuella navnätverket är den centrala anslutningspunkten och observerbarheten. I nätverket distribueras tre undernät.

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

Azure Firewall är brandvägg som en tjänst. Brandväggsinstansen skyddar utgående nätverkstrafik. Utan det här säkerhetslagret kan flödet kommunicera med en skadlig tredjepartstjänst som kan exfiltrera känsliga företagsdata.

Undernät som 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 det lokala nätverket och det virtuella nätverket.

Undernät som Azure Bastion

Det här undernätet är en platshållare för Azure Bastion. Du kan använda Bastion för att få 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. Ekrarna har tre undernät:

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

Azure Application Gateway är en lastbalanserare för webbtrafik som arbetar i Layer 7. Referensimplementering använder Application Gateway v2 SKU som möjliggör Web Application Firewall (WAF). WAF skyddar inkommande trafik från vanliga webbtrafikattacker. Instansen har en offentlig IP-konfiguration på serversidan som tar emot användarbegäranden. Det är design Application Gateway kräver ett dedikerat undernät.

Undernät som värd för ingressresurserna

För att dirigera och distribuera trafik är Traefik den ingress-kontrollant som ska uppfylla Kubernetes-ingressresurserna. Azures interna lastbalanserare finns i det här undernätet.

Undernät som värd för klusternoderna

AKS har två separata grupper av noder (eller nodpooler). Systemnodpoolen är värd för poddar som kör kärnklustertjänster. Användarnodpoolen kör Contosos arbetsbelastning och inkommande styrenhet för att underlätta inkommande kommunikation till arbetsbelastningen. Arbetsbelastningen är ett enkelt ASP.NET program.

Mer information finns i Nätverkstopologi av hub-spoke-ekrar i Azure.

Planera IP-adresserna

Adressutrymmet för det virtuella nätverket ska vara tillräckligt stort för att rymma alla undernät. Konto för alla entiteter som tar emot trafik. IP-adresser för dessa entiteter allokeras från undernätets adressutrymme. Tänk på dessa punkter.

• Uppgradera

  AKS uppdaterar noder regelbundet för att se till att de underliggande virtuella datorerna är uppdaterade med 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 därför.

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

  I den här arkitekturen kan varje podd kontaktas direkt. Därför behöver varje podd en enskild adress. Poddskalbarhet påverkar adressberäkningen. Det beslutet beror på ditt val om antalet poddar som du vill utöka.

• Azure Private Link adresser

  Ta med 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 ska du hantera dessa adresser.

Den här arkitekturen är utformad för en enskild arbetsbelastning. För flera arbetsbelastningar kanske du vill isolera användarnodpoolerna från varandra och från systemnodpoolen. Det alternativet kan resultera i fler undernät som är mindre i storlek. Dessutom kan ingressresursen vara mer komplex. Du kan behöva flera ingress-styrenheter som kräver extra adresser.

En fullständig uppsättning överväganden för den här arkitekturen finns i Nätverkstopologi för AKS-baslinje.

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

Referens för containeravbildning

Förutom arbetsbelastningen kan klustret innehålla flera andra avbildningar, till exempel ingress-kontrollanten. 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 kan du importera den till containerregistret som överensstämmer med ditt SLO. Annars kan avbildningen vara föremål för oväntade tillgänglighetsproblem. Dessa problem kan orsaka driftproblem 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 avbildningar.
  • Du har inga offentliga beroenden.
  • Du kan komma åt pull-loggar för avbildningar för att övervaka aktiviteter och problem med att kontrollera anslutningar.
  • Dra nytta av integrerad containergenomsökning och avbildningsefterlevnad.

  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 referensimplementering 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 referensimplementering distribuerar systemnodpoolen med tre DS2_v2 noder. Den storleken är tillräcklig för att uppfylla den förväntade belastningen på systempoddarna. OS-disken är 512 GB.

Här är några saker att tänka på 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.

• De faktiska nodstorlekarna för din arbetsbelastning beror på de krav som designteamet har fastställt. Baserat på affärskraven har vi valt att DS4_v2 produktionsarbetsbelastningen. Om du vill sänka kostnaderna kan du minska storleken DS3_v2, vilket är minimirekommendationen.

• När du planerar kapaciteten för klustret bör du anta att din arbetsbelastning kan förbruka upp till 80 % av varje nod. de å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 värdet baserat på kraven för arbetsbelastningen, nodstorleken och ip-begränsningarna.

Integrera Azure Active Directory för klustret

Det är viktigt att skydda åtkomsten till och från klustret. Tänk frå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 tillåts åtkomst till.
• Åtkomst utanför . Ge identiteter åtkomst till Kubernetes-klustret. Auktorisera endast de externa entiteter som tillåts åtkomst till Kubernetes API-servern och Azure Resource Manager.

AKS-åtkomst till Azure

Det finns två sätt att hantera AKS till Azure-åtkomst via Azure Active Directory (Azure AD): tjänsthuvudnamn 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 programmässigt. Med hanterade identiteter hanterar och utför Azure AD autentisering och snabb rotation av hemligheter åt dig.

Vi rekommenderar att hanterade identiteter är aktiverade så att klustret kan interagera med externa Azure-resurser via Azure AD. Du kan bara aktivera den här inställningen när klustret skapas. Även om Azure AD inte används omedelbart kan du införliva det senare.

Som ett exempel på det inifrån och ut-fallet ska vi undersöka 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 autentiseringsuppgifterna för registret. Ett sätt är att lagra informationen i form av Kubernetes Secrets-objekt och använda imagePullSecrets för att hämta hemligheten. Den metoden rekommenderas inte på grund av säkerhetskomplexitet. Du behöver inte bara ha tidigare kunskaper om hemligheten, utan även att lämna ut hemligheten via DevOps-pipelinen. En annan orsak är driftskostnaderna för att hantera rotationen av hemligheten. Bevilja i stället acrPull åtkomst till klustrets hanterade identitet i registret. Den här metoden åtgärdar dessa problem.

I den här arkitekturen får klustret åtkomst till Azure-resurser som skyddas av Azure AD 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 har för avsikt att göra. Klustret autentiseras till Azure AD och tillåts eller nekas sedan åtkomst baserat på de roller som det har tilldelats. Här följer några exempel från den här referensimplementering där de inbyggda Azure-rollerna har tilldelats till klustret:

• Nätverksdeltagare. Klustrets möjlighet att styra det virtuella ekernätverket. Med den här rolltilldelningen kan AKS-klustersystems tilldelade identiteter fungera med det dedikerade undernätet för tjänsterna för intern indatakontrollant.
• Övervaka mått 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-registren.

Klusteråtkomst

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

AKS tillåter Kubernetes-åtkomst med Azure Active Directory på två sätt. Den första är att Azure Active Directory en identitetsprovider som är integrerad med det inbyggda Kubernetes RBAC-systemet. Den andra använder inbyggd Azure RBAC för att styra klusteråtkomsten. Båda beskrivs nedan.

Associera Kubernetes RBAC med Azure Active Directory

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

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

• Bindningar som tilldelar användare och grupper som tillåts utföra åtgärderna. Definieras av ett RoleBinding - eller CluserRoleBinding -objekt.

Kubernetes har vissa inbyggda roller som klusteradministratör, redigera, visa och så vidare. Bind rollerna till Azure Active Directory användare och grupper för att hantera åtkomst med hjälp av företagskatalogen. Mer information finns i Använda Kubernetes RBAC med Azure AD-integrering.

Kontrollera att dina Azure AD-grupper som används för kluster- och namnområdesåtkomst ingår i dina Azure AD-åtkomstgranskningar.

Använda Azure RBAC för Kubernetes-auktorisering

I stället för att använda Kubernetes RBAC med integrerad AAD-autentisering är ett annat alternativ att använda Azure RBAC och rolltilldelningar för att framtvinga klusteråtkomst. Fördelen med att använda Azure RBAC är att du inte behöver konfigurera interna Kubernetes RBAC-roller och rollbindningar.

Mer information finns i Azure-roller.

Lokala konton

AKS stöder intern Kubernetes-användarautentisering. Användaråtkomst till kluster med den här metoden rekommenderas inte. Den är certifikatbaserad och utförs externt mot din primära identitetsprovider. vilket gör centraliserad åtkomstkontroll och styrning för användare svårt. Hantera alltid åtkomsten till klustret via Azure Active Directory och konfigurera klustret så att det uttryckligen inaktiverar åtkomst till lokalt konto.

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

Integrera Azure Active Directory för arbetsbelastningen

På samma sätt som du har hanterade Azure-identiteter för hela klustret kan du tilldela hanterade identiteter på poddnivå. En podd hanterad identitet gör att den värdiserade arbetsbelastningen kan komma åt resurser via Azure Active Directory. Arbetsbelastningen lagrar till exempel filer i Azure Storage. När podden behöver åtkomst till dessa filer autentiseras den mot resursen.

I den här referensimplementering underlättas hanterade poddidentiteter via aad-pod-identity.

Distribuera ingressresurser

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

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

  I den här Azure Load Balancer används . Den placeras utanför klustret i ett undernät som är dedikerat för ingressresurser. Den tar emot trafik från Azure Application Gateway och att kommunikationen är via TLS. Information om TLS-kryptering för inkommande trafik finns i Ingress traffic flow.

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

Ingress-kontrollanten är en viktig komponent i klustret. Tänk på dessa punkter när du konfigurerar den här komponenten.

• Som en del av designbesluten ska du välja ett omfång inom vilket ingress-kontrollanten ska tillåtas 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ärskontinuhet om en nod inte fungerar. Använd podAntiAffinity för detta ändamål.

• Begränsa poddar så att de endast schemaläggs i användarnodpoolen med hjälp av nodeSelectors . Den här inställningen isolerar arbetsbelastning och systempoddar.

• Öppna portar och protokoll som tillåter att specifika entiteter skickar trafik till ingress-kontrollanten. I den här arkitekturen tar Traefik bara emot trafik från Azure Application Gateway.

• Ingress-kontrollanten ska skicka signaler som anger hälsotillståndet för poddar. Konfigurera readinessProbe inställningar och som övervakar livenessProbe hälsotillståndet för poddarna vid det angivna intervallet.

• Överväg att begränsa ingresskontrollantens åtkomst till specifika resurser och möjligheten att utföra vissa åtgärder. 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

Routerinställningar

Ingress-kontrollanten 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. annotations, tls och anger att vägar kommer entrypoints att betjänas via HTTPS. middlewaresanger att endast trafik från Azure Application Gateway undernät tillåts. Svaren använder gzip-kodning om klienten accepterar det. Eftersom Traefik använder TLS-avslutning är kommunikationen med backend-tjänsterna över HTTP.

apiVersion:networking.k8s.io/v1beta1
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: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

Skydda nätverksflödet

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

• Ingress-trafik. Från klienten till arbetsbelastningen som körs i klustret.

• Egress trafik. Från en podd eller nod i klustret till en extern tjänst.

• Pod-till-pod-trafik. Kommunikation mellan poddar. Den här trafiken omfattar kommunikation mellan ingress-kontrollanten och arbetsbelastningen. Om din arbetsbelastning består av flera program som distribueras till klustret, hamnar kommunikationen mellan dessa program i den här kategorin.

• Hanteringstrafik. Trafik som går mellan klienten och Kubernetes API-servern.

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

Ingresstrafikflö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. Servernamnindikator (SNI) strikt är aktiverat. TLS från end-to-end konfigureras via Application Gateway med hjälp av två olika TLS-certifikat, som du ser i den här bilden.

1. Klienten skickar en HTTPS-begäran till domännamnet: bicycle.contoso.com. Namnet associeras 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 webbaserade program (WAF) och förhandlar 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 serverplatsen. TLS-certifikatet lagras i Azure Key Vault. Den nås med hjälp av en användar tilldelad hanterad identitet som är integrerad med Application Gateway. Information om den funktionen finns i TLS-avslutning med Key Vault certifikat.

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

4. Ingress-kontrollanten 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 hemlighetshantering.

Du kan implementera TLS-trafik från början till slut hela vägen till arbetsbelastningspodden. Se till att mäta prestanda, svarstid och driftspåverkan när du fattar beslutet att skydda pod-till-pod-trafik. För de flesta kluster med en enda klientorganisation, med rätt kontrollplans-RBAC och mogna metoder för programutvecklingslivscykel, räcker det att TLS krypterar upp till ingress-kontrollanten och skyddar med Web Application Firewall (WAF). Detta minimerar belastningen på arbetsbelastningshanteringen och påverkan på nätverkets prestanda. Dina krav på arbetsbelastning och efterlevnad avgör var du utför TLS-avslutning.

Egress trafikflöde

För kontroll utan förtroende och möjligheten 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: er). Nästa hopp i vägen är den privata IP-adressen för Azure Firewall. Här bestämmer Azure Firewall om utgående trafik ska blockeras eller tillåtas. Beslutet baseras på de specifika regler som definieras i Azure Firewall eller de inbyggda reglerna för hotinformation.

Ett undantag till noll förtroende-kontrollen är när klustret behöver kommunicera med andra Azure-resurser. Klustret måste till exempel hämta en uppdaterad avbildning från containerregistret. Den rekommenderade metoden är att använda Azure Private Link. Fördelen är att specifika undernät når tjänsten direkt. Dessutom exponeras inte trafik mellan klustret och tjänsten för offentligt Internet. En nackdel är att Private Link behöver ytterligare konfiguration i stället för att använda måltjänsten över dess offentliga slutpunkt. Dessutom stöder inte alla Azure-tjänster eller SKU:er Private Link. I dessa fall bör du överväga att aktivera en tjänstslutpunkt 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 igenom brandväggens statiska IP-adress kan den adressen läggas till i tjänstens IP-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.

Pod-till-pod-trafik

Som standard kan en podd ta emot trafik från alla andra poddar i klustret. Kubernetes NetworkPolicy används för att begränsa nätverkstrafik mellan poddar. Tillämpa principer på ett bra 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 ingress-kontrollanten och arbetsbelastningen. Mer information finns i Nätverksprinciper.

Aktivera nätverksprincipen 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 anteckningen nedan. Andra alternativ är Grupprincip, ett välkänt alternativ med öppen källkod. Överväg Att användaCo om du behöver hantera nätverksprinciper för hela klustret. Co omfattas inte av Azure-standardsupporten.

Mer information finns i Skillnader mellan Azure Network Policy- och Klaco-principer och deras funktioner.

Hanteringstrafik

Som en del av att köra klustret tar Kubernetes API-servern emot trafik från resurser som vill göra hanteringsåtgärder i klustret, till exempel begäranden om att skapa resurser eller skala klustret. Exempel på dessa resurser är byggaragentpoolen 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 funktionen Auktoriserat IP-intervall i AKS för att endast tillåta trafik från dina auktoriserade IP-intervall till API-servern.

Mer information finns i Definiera API-server-auktoriserade IP-intervall.

Lägga till hemlighetshantering

Lagra hemligheter i ett hanterat nyckelarkiv, till exempel Azure Key Vault. Fördelen är att det hanterade arkivet hanterar rotering av hemligheter, erbjuder stark kryptering, tillhandahåller en granskningslogg för åtkomst och håller kärnhemligheter utanför distributionspipelinen.

Azure Key Vault är väl integrerad med andra Azure-tjänster. Använd den inbyggda funktionen i dessa tjänster för att komma åt hemligheter. Ett exempel på hur Azure Application Gateway åtkomst till TLS-certifikat för ingressflödet finns i avsnittet Ingress traffic flow (Ingress-trafikflöde).

Åtkomst till klusterhemligheter

Du måste använda podd-hanterade identiteter för att tillåta att en podd får åtkomst till hemligheter från ett visst arkiv.

Använd CSI-drivrutinen Secrets Store för att underlätta hämtningsprocessen. 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 CSI-drivrutinen Azure Key Vault Secrets Store för att hämta TLS-certifikatet från Azure Key Vault och läsa in det i podden som kör ingress-kontrollanten. Det görs när podd skapas och volymen lagrar både offentliga och privata nycklar.

Arbetsbelastningslagring

Arbetsbelastningen som används i den här arkitekturen är tillståndslös. Om du behöver lagra tillstånd 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 Storage 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 principerna via Azure Policy. Varje princip tillämpas på alla kluster i dess omfång. Azure Policy 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.

När du ställer in principer ska du tillämpa dem baserat på kraven för arbetsbelastningen. Tänk på följande faktorer:

• Vill du ange en samling principer (kallas initiativ) eller välja enskilda principer. Azure Policy 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 ytterligare principer för klustret och de resurser (ACR, Application Gateway, Key Vault med flera) som interagerar med klustret, enligt organisationens krav.

• Vill du granska ellerneka åtgärden? I granskningsläget tillåts åtgärden, men den flaggas som icke-kompatibel. Ha processer för att regelbundet kontrollera icke-kompatibla tillstånd och vidta nödvändiga åtgärder. I neka-läge blockeras åtgärden eftersom den strider 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 bör vara kompatibla med designen? Azure Policy har möjlighet att ange Kubernetes-namnrymder som är undantagna från principtvingande. Vi rekommenderar att du fortfarande tillämpar principer i granskningsläget så att du är medveten om dessa instanser.

• Har du krav som inte omfattas av de inbyggda principerna? I dessa sällsynta fall skapar du en anpassad Azure Policy som tillämpar dina anpassade OPA Gatekeeper-principer. Tillämpa inte principer direkt på klustret.

• 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. Se till att produktionsprinciperna också verifieras mot din förproduktionsmiljö. I annat fall kan du, när du distribuerar till produktionsmiljön, få oväntade ytterligare begränsningar som inte redovisats i förproduktion.

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

Implementeringen anger också 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 i en enda tilldelning.

Om du vill Azure Policy fungerar inifrån klustret kan du komma åt poddloggarna för alla poddar i namnområdet samt loggarna för poddarna och i gatekeeper-systemazure-policyazure-policy-webhookkube-system namnområdet .

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 automatisk poddskalning (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. Vid poddskalning kan programoperatorn öka eller minska antalet poddrepliker genom att justera ReplicaSet via Kubernetes-API:erna. När det gäller 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 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. Använd slutligen dessa data för att ange parametrar för autoskalning. Information om ett prestandajusteringsscenario med AKS finns i Prestandajusteringsscenario: Distribuerade affärstransaktioner.

Horisontell autoskalning av poddar

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

Vi rekommenderar att du anger det lägsta och högsta antalet repliker i HPA-resursen. Dessa värden begränsar gränserna för automatisk skalning.

HPA kan skalas baserat på processoranvändning, minnesanvändning och anpassade mått. Det är bara processoranvändningen som är tillgänglig. HorizontalPodAutoscaler-definitionen anger målvärden för dessa mått. Till exempel anger specifikationen en mål-CPU-användning. Medan poddar körs använder HPA-kontrollanten 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. Den använder sedan förhållandet för att avgöra om poddar är överallokerade 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 rastillstånd där (HPA) kontrollerar innan en skalningsåtgärd har slutförts. Resultatet kan vara en felaktig kvotberäkning. Mer information finns i Nedskalning av skalningshändelser.

Om din arbetsbelastning är händelsedriven är KEDA ett populärt alternativ med öppen källkod. Överväg KEDA om din arbetsbelastning styrs 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 praktiskt sätt att skala KEDA-arbetsbelastningar baserat 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 autoskalning av kluster 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, tillser autoskalningen automatiskt en ny nod i nodpoolen. På samma sätt 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 det högsta och lägsta antalet noder. De rekommenderade värdena beror på prestandaförväntningen för arbetsbelastningen, hur mycket du vill att klustret ska växa och kostnadskonsekvenser. Det minsta antalet är den reserverade kapaciteten för nodpoolen. I den här referensimplementering anges minimivärdet till 2 på grund av arbetsbelastningens enkla natur.

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

Beslut om affärskontinuhet

För att upprätthålla affärskontinu kontinuerlighet definierar Serviceavtal för infrastrukturen och ditt program. Information om beräkning av månatlig drifttid 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 kan du etablera fler noder.

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

Regelbunden underhåll av klustret, till exempel snabba uppdateringar, är avgörande för tillförlitligheten. Vi rekommenderar även att du övervakar hälsotillståndet för poddarna via avsökningar.

Poddtillgänglighet

Se till att poddresurser . Vi rekommenderar starkt att distributioner anger resurskrav för poddar. Schemaläggaren kan sedan schemalägga podden på rätt sätt. Tillförlitligheten blir avsevärt inaktuell om poddar inte kan schemaläggas.

Ange budgetar för poddavbrott. Den här inställningen anger hur många repliker i en distribution som kan komma ned under en uppdatering eller uppgradering. Mer information finns i Pod disruption budgets (Budgetar för poddavbrott).

Konfigurera flera repliker i distributionen för att hantera avbrott, till exempel maskinvarufel. För planerade händelser som uppdateringar och uppgraderingar kan en avbrottsbudget se till att det nödvändiga antalet poddrepliker finns för att hantera förväntad programbelastning.

Ange resurskvoter för arbetsbelastningens namnrymder. Resurskvoten i ett namnområde säkerställer att poddbegäranden och gränser är korrekt inställda på en distribution. Mer information finns i Framtvinga resurskvoter.

Ange poddbegäranden och begränsningar. Genom att ange dessa gränser kan Kubernetes effektivt allokera PROCESSOR- och minnesresurser till poddarna och ha högre containerdensitet på en nod. Begränsningar kan också öka tillförlitligheten med lägre kostnader på grund av bättre maskinvaruanvändning.

Du kan beräkna gränserna genom att testa och upprätta en baslinje. Börja med samma värden för begäranden och begränsningar. Justera sedan värdena gradvis tills du har etablerat ett tröskelvärde som kan orsaka instabilitet i klustret.

Dessa gränser kan anges i dina distributionsmanifest. Mer information finns i Ange poddbegäranden och begränsningar.

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

Om ditt serviceavtal kräver en högre drifttid ska du skydda mot förlust i en zon. 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 är 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 regionstillgä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 ger 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 zoner som begärs, till exempel nodpoolerna. Om du inte använder zonstöd i klustret är det inte säkert att kontrollplanskomponenterna sprids över tillgänglighetszonerna.

• Beroende resurser. Alla tjänstberoenden måste också ha stöd för zoner för fullständig zonindelning. 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 har etablerats. 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 omfattar tillgänglighetszonerna 1, 2 och 3. Andra resurser i infrastrukturen, till exempel Azure Firewall och Application Gateway distribueras till samma region med stöd för flera zoner. Geo-replikering har aktiverats för Azure Container Registry.

Flera regioner

Det räcker inte att aktivera tillgänglighetszoner om hela regionen går ned. 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 efter regionfel. En fördel med att använda parkopplade 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 automatiskt avbildningar till de valda Azure-regionerna och ger fortsatt åtkomst till avbildningar även om en region drabbas av avbrott.

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

Haveriberedskap

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

• Använd parkopplade regioner.

• En icke-tillståndsfull arbetsbelastning kan replikeras effektivt. Om du behöver lagra tillstånd i klustret (rekommenderas inte) bör du rekommendationer för data ofta i den parkopplade regionen.

• Integrera återställningsstrategin, till exempel replikering 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 Azure Container Registry aktiveras för geo-replikering. Om en region ligger nere kan du fortfarande hämta avbildningar från den replikerade regionen.

Serviceavtal för Kubernetes API Server Uptime

AKS kan användas som en kostnadsfri tjänst, men den nivån erbjuder inte ett serviceavtal med ekonomisk uppbackning. För att få detta serviceavtal måste du välja att lägga till ett serviceavtal för drifttid i köpet. Vi rekommenderar att alla produktionskluster använder det här alternativet. Reservera kluster utan det här alternativet för förproduktionskluster. I kombination med Azure-tillgänglighetszoner ökas serviceavtalet för Kubernetes API-servern till 99,95 %. Dina nodpooler och andra resurser omfattas av ett eget serviceavtal.

Avvägning

Det finns en kompromiss mellan kostnad och tillgänglighet 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 ökar också eftersom bandbreddsavgifterna som tillämpas när trafiken flyttas mellan zoner och regioner.

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

Testa med simuleringar och forcerad redundans

Säkerställ tillförlitlighet genom framtvingad redundanstestning med simulerade avbrott, till exempel att ta ned en nod, ta bort alla AKS-resurser i en viss zon för att simulera ett zonindelade fel eller ta bort ett externt beroende.

Övervaka och samla in mått

Funktionen Azure Monitor för containrar är det rekommenderade verktyget för övervakning och loggning 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 minne och CPU-användning för att övervaka hälsotillståndet för resurser och arbetsbelastningar som körs. Du kan använda den för att övervaka prestanda när poddarna skalas. En annan fördel är att du enkelt kan använda Azure Portal för att konfigurera diagram och instrumentpaneler. Den har möjlighet att skapa aviseringar som utlöser Automation-runbooks, Azure Functions och andra.

De flesta arbetsbelastningar som finns i poddar ger Prometheus-mått. Azure Monitor kan avskrapor Prometheus-mått och visualisera dem.

Det finns några verktyg från tredje part som är integrerade med Kubernetes. Dra nytta av logg- och måttplattformar som Grafana eller Datadog, om din organisation redan använder dem.

Med AKS hanterar Azure vissa grundläggande Kubernetes-tjänster. Loggar från dessa tjänster bör endast aktiveras per begäran från kundsupporten. Vi rekommenderar dock att du aktiverar dessa loggkällor eftersom de kan hjälpa dig att felsöka klusterproblem:

• Logga in på ClusterAutoscaler för att få observerbarhet för skalningsåtgärder. Mer information finns i Hämta loggar och status för autoskalning av kluster.
• KubeControllerManager ska kunna observeras i poddschemat.
• KubeAuditAdmin för att kunna observera aktiviteter som ändrar klustret.

Aktivera självreläkning

Övervaka hälsotillståndet för poddar genom att ställa in Liveness- och Readiness-avsökningar. Om en podd som inte svarar identifieras startar Kubernetes om podden. Livenessavsö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.

Säkerhetsuppdateringar

Se till att Kubernetes-versionen är 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 utlöses av klustret, till exempel tillgänglighet för nya AKS-versioner för klustret, kan göras via AKS-systemämnet för Azure Event Grid. Referensimplementering distribuerar det här Event Grid systemämne så att du kan prenumerera på Microsoft.ContainerService.NewKubernetesVersionAvailable händelsen från din lösning för meddelanden om händelseströmmar.

Veckovisa uppdateringar

AKS tillhandahåller nya nodavbildningar som har de senaste uppdateringarna för operativsystem och körning. Dessa nya avbildningar 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 nodpoolens basavbildning varje vecka. Mer information finns i Azure Kubernetes Service (AKS) node image upgrade the AKS Release Notes.

Dagliga uppdateringar

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

Genom att synkronisera dina nodavbildningar med den senaste veckovisa versionen minimeras dessa tillfälliga omstartsbegäranden samtidigt som säkerheten förbättras. Om du bara förlitar dig på uppgraderingar av nodavbildningar säkerställer du AKS-kompatibilitet och veckovisa säkerhetsuppdateringar. Att tillämpa dagliga uppdateringar kommer att åtgärda säkerhetsproblem snabbare, men de har inte nödvändigtvis testats i AKS. Använd där så är möjligt nodavbildningsuppgradering som din primära veckovisa strategi för säkerhetskorrigering.

Säkerhetsövervakning

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

• Aktivera Microsoft Defender för Kubernetes för hotidentifiering i dina Kubernetes-kluster.
• Använd Microsoft Defender för moln (Defender för moln) för att övervaka Kubernetes säkerhetsstatus.
• 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 är några saker att tänka på. Mer information finns i grundpelaren för driftskvalitet.

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 bygg vidare på den. En inledande uppgift är att konfigurera nätverk. Etablera virtuella nätverk för nav och ekrar och undernät i dessa nätverk. Ekrar 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 Azure Active Directory.

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 Azure Resource Manager (ARM)-mallar som är Terraform.

Se till att du etablerar resurser enligt styrningsprinciperna. När du till exempel väljer rätt VM-storlekar håller du dig inom kostnadsbegränsningarna och tillgänglighetszonsalternativen så att de matchar kraven för ditt program.

Om du behöver skriva en sekvens med kommandon använder du Azure CLI. De här kommandona omfattar en mängd Olika Azure-tjänster och kan automatiseras med hjälp av skript. Azure CLI stöds på Windows och Linux. Ett annat plattformsoberoende alternativ Azure PowerShell. Ditt val beror på önskad kompetensuppsättning.

Lagra och versionsskript och mallfiler i källkontrollsystemet.

CI/CD för arbetsbelastningar

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

Din distributionsstrategi måste innehålla en tillförlitlig och en pipeline för automatisk kontinuerlig leverans (CD). Ändringar i arbetsbelastningens containeravbildningar 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

I stället för att använda en imperativ metod som kubectl använder du verktyg som automatiskt synkroniserar ändringar i kluster och lagringsplatsen. För att hantera arbetsflödet, till exempel lansering av en ny version och validering av den versionen innan du distribuerar till produktion, bör du överväga ett GitOps-flöde. En agent distribueras i klustret för att se till att klustrets tillstånd samordnas med konfigurationen som lagras i din privata Git-lagringsplatsen. Kubernetes och AKS stöder inte den upplevelsen inbyggt. Ett rekommenderat alternativ är flux. Den 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 lagringsplatsen.
• Identifierar nya konfigurationsändringar.
• Utlöser distributioner.
• Uppdaterar önskad konfiguration som körs baserat på dessa ändringar.

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

Här är ett exempel från referensimplementeringen som visar hur du automatiserar klusterkonfigurationen med GitOps och Flux.

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

2. flux körs i podd i tillsammans med arbetsbelastningen. flux har skrivskyddad åtkomst till git-lagringsplatsen för att säkerställa att flux endast tillämpar ändringar som begärs av utvecklare.

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. Ha förgreningsprinciper på git-servern. På så sätt kan flera utvecklare godkänna en ändring innan den tillämpas på produktion.

Distributionsstrategier för arbetsbelastningar och kluster

Distribuera ändringar (arkitekturkomponenter, arbetsbelastning, klusterkonfiguration) till minst ett AKS-kluster för förproduktion. Detta simulerar att ändringen kan ta bort 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-testningoch canary-versionerkräver ytterligare process 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

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.

Etablera

• Det finns inga kostnader för AKS vid distribution, hantering och drift av Kubernetes-klustret. Den huvudsakliga kostnadsdrivrutinen är de instanser av virtuella datorer, lagring och nätverksresurser som används av klustret. Överväg att välja billigare virtuella datorer för systemnodpooler. Den rekommenderade SKU:n DS2_v2.

• Har inte samma konfiguration för utvecklings-/test- och produktionsmiljöer. Produktionsarbetsbelastningar har extra krav på hög tillgänglighet och blir dyrare. Det kanske inte är nödvändigt 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 dev/test eller experimentella arbetsbelastningar där tillgänglighet inte behöver garanteras. Till exempel räcker SLO:et. Om din arbetsbelastning har stöd för det bör du överväga att använda dedikerade nodpooler för VM med VM

  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 autoskalning av kluster att övervaka och fatta beslut om storlek.

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

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

• Om din arbetsbelastning förväntas finnas under en lång period kan du åta dig ett eller tre års reserverade VM-instanser 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 den totala kostnaden och mappa eventuella kostnader till en specifik resurs eller ett specifikt team. Om klustret delas mellan team kan du skapa återbetalningsrapporter per konsument för att identifiera kostnader som mäts för delade molntjänster. Mer information finns i Ange en taint, etikett eller tagg för en nodpool.

• Dataöverföringar inom tillgänglighetszoner i en region är inte kostnadsfria. Om din arbetsbelastning finns i flera regioner eller om det finns överföringar mellan faktureringszoner 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 samlar beräkningskostnaden ä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

Vi rekommenderar att du övervakar kostnaden i realtid eller åtminstone med jämna mellanrum för att vidta åtgärder före slutet av månaden när kostnaderna redan har beräknats. Övervaka även månadstrenden över tid för att hålla dig inom budgeten.

För att fatta datadrivna beslut kan du hitta vilken resurs (detaljerad nivå) som medför mest kostnad. Ha 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 till exempel avgöra om plattformen är för stor. Du kan se användningsmätare i Azure Monitor mått.

Optimera

Agera på rekommendationer som tillhandahålls av Azure Advisor. Det finns andra sätt att optimera:

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

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

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

• Om din arbetsbelastning stöder det skalar du användarnodpoolerna till 0 noder när det inte förväntas att de ska köras. Om det inte finns några arbetsbelastningar kvar schemalagda att köras i klustret bör du överväga att använda start-/stoppfunktionen i AKS för att stänga av all beräkning, inklusive systemnodpoolen och AKS-kontrollplanet.

Annan kostnadsrelaterad information finns i AKS pricing (AKS-priser).

Nästa steg

• Mer information om hur du är värd för mikrotjänster på AKS-baslinjen finns i Advanced Azure Kubernetes Service (AKS) microservices architecture (AKS)-mikrotjänstarkitektur.
• Information om hur du distribuerar AKS-baslinjen över flera regioner finns i AKS-baslinje för kluster i flera regioner.
• Information om hur du distribuerar AKS-baslinjen till en PCI-DSS 3.2.1-miljö finns i AKS-reglerat kluster för PCI-DSS 3.2.1.
• I produktöversikten för AKS finns Azure Kubernetes Service översikt GitHub.

Relaterade artiklar

Om du behöver uppdatera i Kubernetes slutför du introduktionen till Kubernetes och Utveckla och distribuera program på Kubernetes-utbildningsvägar på Microsoft Learn.