Använda Azure Firewall för att skydda ett AKS-kluster (Azure Kubernetes Service)

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

Den här guiden beskriver hur du skapar ett privat AKS-kluster i en nätverkstopologi med nav och eker med hjälp av Terraform och Azure DevOps. Azure Firewall används för att inspektera trafik till och från AKS-klustret (Azure Kubernetes Service). Klustret hanteras av ett eller flera virtuella ekernätverk som är peer-kopplade till det virtuella hubbnätverket.

Arkitektur

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

Arbetsflöde

Terraform-moduler används för att distribuera ett nytt virtuellt nätverk som har fyra undernät som är värdar för:

AKS-klustret (AksSubnet).
En virtuell jump-box-dator (VM) och privata slutpunkter (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

AKS-klustret använder en användardefinierad hanterad identitet för att skapa ytterligare resurser, till exempel lastbalanserare och hanterade diskar i Azure. Med Terraform-modulerna kan du distribuera ett AKS-kluster som har följande funktioner:

AKS-klustret består av följande pooler:

En systemnodpool som endast är värd för kritiska systempoddar och tjänster
En användarnodpool som är värd för användararbetsbelastningar och artefakter

En virtuell dator distribueras i det virtuella nätverk som är värd för AKS-klustret. När du distribuerar AKS som ett privat kluster kan systemadministratörer använda den här virtuella datorn för att hantera klustret via kommandoradsverktyget Kubernetes. Loggarna för startdiagnostik för den virtuella datorn lagras på ett Azure Storage-konto.

En Azure Bastion-värd ger förbättrad SSH-anslutning med säkerhet till den virtuella jump-box-datorn via SSL. Azure Container Registry används för att skapa, lagra och hantera containeravbildningar och artefakter (till exempel Helm-diagram).

Arkitekturen innehåller en Azure Firewall som används för att styra inkommande och utgående trafik via DNAT-regler, nätverksregler och programregler. Det hjälper också till att skydda arbetsbelastningar med hjälp av hotinformationsbaserad filtrering. Azure Firewall och Bastion distribueras till ett virtuellt navnätverk som är peer-kopplat till det virtuella nätverk som är värd för det privata AKS-klustret. En routningstabell och användardefinierade vägar används för att dirigera utgående trafik från det privata AKS-klustret till Azure Firewall.

Kommentar

Vi rekommenderar starkt att du använder Premium SKU för Azure Firewall eftersom det ger avancerat skydd mot hot.

Ett Key Vault används som ett hemligt arkiv av arbetsbelastningar som körs på AKS för att hämta nycklar, certifikat och hemligheter via Microsoft Entra Workload ID, Secrets Store CSI Driver eller Dapr. Med Azure Private Link kan AKS-arbetsbelastningar komma åt Azure PaaS-tjänster, till exempel Azure Key Vault, via en privat slutpunkt i det virtuella nätverket.

Topologin innehåller privata slutpunkter och privata DNS-zoner för dessa tjänster:

Azure Blob Storage-konto
Container Registry
Key Vault
API-servern för Kubernetes-klustret

Det finns en virtuell nätverkslänk mellan de virtuella hubb- och ekernätverken som är värdar för AKS-klustret och de privata DNS-zoner som beskrevs tidigare.

En Log Analytics-arbetsyta används för att samla in diagnostikloggar och mått från Azure-tjänster.

Komponenter

Azure Firewall är en molnbaserad, intelligent nätverksbrandväggssäkerhetstjänst som ger skydd mot hot för molnarbetsbelastningar som körs i Azure. Det är en helt tillståndskänslig brandvägg som en tjänst med inbyggd hög tillgänglighet och obegränsad molnskalbarhet. Det ger både trafikinspektion i öst-väst och nord-syd.
Container Registry är en hanterad, privat Docker-registertjänst som baseras på Docker Registry 2.0 med öppen källkod. Du kan använda Azure-containerregister med dina befintliga pipelines för containerutveckling och distribution eller använda Container Registry Tasks för att skapa containeravbildningar i Azure.
Azure Kubernetes Service förenklar distributionen av hanterade Kubernetes-kluster i Azure genom att avlasta driftkostnaderna till Azure. Som värdbaserad Kubernetes-tjänst hanterar Azure viktiga uppgifter som hälsoövervakning och underhåll. Eftersom Kubernetes-huvudservrar hanteras av Azure hanterar och underhåller du bara agentnoderna.
Key Vault lagrar och styr åtkomsten till hemligheter som API-nycklar, lösenord, certifikat och kryptografiska nycklar med förbättrad säkerhet. Med Key Vault kan du också enkelt etablera, hantera och distribuera offentliga och privata TLS/SSL-certifikat (Transport Layer Security/Secure Sockets Layer) för användning med Azure och dina interna anslutna resurser.
Azure Bastion är en fullständigt hanterad plattform som en tjänst (PaaS) som du etablerar i ditt virtuella nätverk. Azure Bastion ger en förbättrad RDP-anslutning (Remote Desktop Protocol) och SSH-anslutning (Secure Shell) till de virtuella datorerna i ditt virtuella nätverk, direkt från Azure-portalen via TLS.
Azure Virtual Machines tillhandahåller skalbara beräkningsresurser på begäran som ger dig flexibiliteten i virtualisering.
Azure Virtual Network är den grundläggande byggstenen för privata Azure-nätverk. Med virtuellt nätverk kan Azure-resurser (till exempel virtuella datorer) kommunicera med varandra, Internet och lokala nätverk med förbättrad säkerhet. Ett virtuellt Azure-nätverk är som ett traditionellt nätverk som är lokalt, men det innehåller azure-infrastrukturfördelar som skalbarhet, tillgänglighet och isolering.
Med virtuella nätverksgränssnitt kan virtuella Azure-datorer kommunicera med internet, Azure och lokala resurser. Du kan lägga till flera nätverkskort till en virtuell Azure-dator så att underordnade virtuella datorer kan ha egna dedikerade nätverksenheter och IP-adresser.
Azure-hanterade diskar tillhandahåller lagringsvolymer på blocknivå som Azure hanterar på virtuella Azure-datorer. Ultradiskar, premium sSD-enheter (Solid State Drives), standard-SSD:er och standardhårddiskenheter (HDD) är tillgängliga.
Blob Storage är en objektlagringslösning för molnet. Blob Storage är optimerat för lagring av enorma mängder ostrukturerade data.
Med Private Link kan du komma åt Azure PaaS-tjänster (till exempel Blob Storage och Key Vault) via en privat slutpunkt i ditt virtuella nätverk. Du kan också använda den för att komma åt Azure-värdbaserade tjänster som du äger eller som tillhandahålls av en Microsoft-partner.

Alternativ

Du kan använda en brandvägg från tredje part från Azure Marketplace i stället för Azure Firewall. Om du gör det är det ditt ansvar att konfigurera brandväggen så att den inspekterar och tillåter eller nekar inkommande och utgående trafik från AKS-klustret.

Information om scenario

I en produktionsmiljö bör kommunikationen med ett Kubernetes-kluster skyddas av en brandvägg som övervakar och kontrollerar inkommande och utgående nätverkstrafik baserat på en uppsättning säkerhetsregler. En brandvägg upprättar vanligtvis en barriär mellan ett betrott nätverk och ett ej betrott nätverk, till exempel Internet.

Du kan skapa ett privat AKS-kluster i en nätverkstopologi med nav och eker med hjälp av Terraform och Azure DevOps. Azure Firewall används för att inspektera trafik till och från AKS-klustret (Azure Kubernetes Service). Klustret hanteras av ett eller flera virtuella ekernätverk som är peer-kopplade till det virtuella hubbnätverket.

Azure Firewall har stöd för tre olika SKU:er för att hantera en mängd olika kundanvändningsfall och inställningar:

Azure Firewall Premium rekommenderas för att skydda mycket känsliga program, till exempel betalningsbearbetning. Den stöder avancerade funktioner för skydd mot hot som skadlig kod och TLS-inspektion.
Azure Firewall Standard rekommenderas för kunder som letar efter en Layer 3–Layer 7-brandvägg och som behöver automatisk skalning för att hantera trafiktoppar på upp till 30 Gbit/s. Den stöder företagsfunktioner som hotinformation, DNS-proxy, anpassade DNS- och webbkategorier.
Azure Firewall Basic rekommenderas för kunder med dataflödesbehov på mindre än 250 Mbit/s.

I följande tabell visas funktionerna i de tre Azure Firewall-SKU:erna. Mer information finns i Prissättning för Azure Firewall.

Screenshot that shows features of the three Azure Firewall SKUs

Som standard har AKS-kluster obegränsad utgående internetåtkomst. Med den här nivån av nätverksåtkomst kan noder och tjänster som körs i AKS-klustret komma åt externa resurser efter behov. Om du vill begränsa utgående trafik måste ett begränsat antal portar och adresser vara tillgängliga för att upprätthålla felfria klusterunderhållsuppgifter. Det enklaste sättet att ge säkerhet för utgående trafik från ett Kubernetes-kluster som AKS är att använda en programvarubrandvägg som kan styra utgående trafik baserat på domännamn. Azure Firewall kan begränsa utgående HTTP- och HTTPS-trafik baserat på målets fullständigt kvalificerade domännamn (FQDN). Du kan också konfigurera brandväggs- och säkerhetsreglerna för att tillåta dessa portar och adresser som krävs. Mer information finns i Kontrollera utgående trafik för klusternoder i AKS.

På samma sätt kan du styra inkommande trafik och förbättra säkerheten genom att aktivera hotinformationsbaserad filtrering på en Azure Firewall som distribueras till ett delat perimeternätverk. Den här filtreringen kan ge aviseringar och neka trafik till och från kända skadliga IP-adresser och domäner.

Potentiella användningsfall

I det här scenariot åtgärdas behovet av att förbättra säkerheten för inkommande och utgående trafik till och från ett Kubernetes-kluster.

Undvik asymmetrisk routning

I den här lösningen distribueras Azure Firewall till ett virtuellt navnätverk och det privata AKS-klustret distribueras till ett virtuellt ekernätverk. Azure Firewall använder nätverks- och programregelsamlingar för att styra utgående trafik. I det här fallet måste du konfigurera inkommande trafik till alla offentliga slutpunkter som exponeras av alla tjänster som körs på AKS för att komma in i systemet via en av de offentliga IP-adresser som används av Azure Firewall.

Paket anländer till brandväggens offentliga IP-adress men återgår till brandväggen via den privata IP-adressen (med standardvägen). Det här är ett problem. Undvik det genom att skapa en annan användardefinierad väg för brandväggens offentliga IP-adress, enligt följande diagram. Paket som går till brandväggens offentliga IP-adress dirigeras via Internet. Den här konfigurationen undviker standardvägen till brandväggens privata IP-adress.

Om du vill dirigera trafiken för dina AKS-arbetsbelastningar till Azure Firewall i det virtuella hubbnätverket måste du:

Skapa och associera en routningstabell till varje undernät som är värd för arbetsnoderna i klustret.
Skapa en användardefinierad väg för att vidarebefordra trafiken för 0.0.0.0/0 CIDR till den privata IP-adressen för Azure Firewall. Ange Virtuell installation för typen Nästa hopp.

Mer information finns i Självstudie: Distribuera och konfigurera Azure Firewall med hjälp av Azure-portalen.

Mer information finns i:

Distribuera arbetsbelastningar till ett privat AKS-kluster när du använder Azure DevOps

Om du använder Azure DevOps kan du inte använda Azure DevOps Microsoft-värdbaserade agenter för att distribuera dina arbetsbelastningar till ett privat AKS-kluster. De har inte åtkomst till dess API-server. Om du vill distribuera arbetsbelastningar till ditt privata AKS-kluster måste du etablera och använda en lokalt installerad Azure DevOps-agent i samma virtuella nätverk som ditt privata AKS-kluster eller i ett peer-kopplat virtuellt nätverk. I det senare fallet måste du skapa en virtuell nätverkslänk mellan aks-klustrets privata DNS-zon i nodresursgruppen och det virtuella nätverk som är värd för den lokala Azure DevOps-agenten.

Du kan distribuera en enda Windows - eller Linux Azure DevOps-agent på en virtuell dator eller använda en VM-skalningsuppsättning. Mer information finns i Azure Virtual Machine Scale Set-agenter. Alternativt kan du konfigurera en lokalt installerad agent i Azure Pipelines så att den körs i en Windows Server Core-container (för Windows-värdar) eller Ubuntu-container (för Linux-värdar) med Docker. Distribuera den som en podd med en eller flera repliker i ditt privata AKS-kluster. Mer information finns i:

Om de undernät som är värdar för nodpoolerna i ditt privata AKS-kluster har konfigurerats för att dirigera utgående trafik till en Azure Firewall via en routningstabell och en användardefinierad väg ska du skapa rätt program- och nätverksregler. Dessa regler måste tillåta agenten att komma åt externa webbplatser för att ladda ned och installera verktyg som Docker, Kubectl, Azure CLI och Helm på den virtuella agentdatorn. Mer information finns i Köra en lokalt installerad agent i Docker och Skapa och distribuera Azure DevOps Pipeline Agent på AKS.

Använda Azure Firewall framför en offentlig Standard Load Balancer

Resursdefinitioner i Terraform-modulerna använder livscykelmetaargumentet för att anpassa åtgärder när Azure-resurser ändras utanför Terraform-kontrollen. Argumentet ignore_changes används för att instruera Terraform att ignorera uppdateringar av angivna resursegenskaper, till exempel taggar. Resursdefinitionen för Azure Firewall Policy innehåller ett livscykelblock för att förhindra att Terraform uppdaterar resursen när en regelsamling eller en enda regel skapas, uppdateras eller tas bort. På samma sätt innehåller Azure Route Table ett livscykelblock för att förhindra att Terraform uppdaterar resursen när en användardefinierad väg skapas, tas bort eller uppdateras. På så sätt kan du hantera DNAT-, program- och nätverksreglerna för en Azure Firewall Policy och de användardefinierade vägarna för en Azure Route-tabell utanför Terraform-kontrollen.

Exemplet som är associerat med den här artikeln innehåller en Azure DevOps CD-pipeline som visar hur du distribuerar en arbetsbelastning till ett privat AKS-kluster med hjälp av en Azure DevOps-pipeline som körs på en lokalt installerad agent. Exemplet distribuerar bitnami redmine-projekthanteringswebbprogrammet med hjälp av ett offentligt Helm-diagram . Det här diagrammet visar exemplets nätverkstopologi:

Här är meddelandeflödet:

En begäran för det AKS-värdbaserade webbprogrammet skickas till en offentlig IP-adress som exponeras av Azure Firewall via en offentlig IP-konfiguration. Både den offentliga IP-adressen och den offentliga IP-konfigurationen är dedikerade till den här arbetsbelastningen.
En AZURE Firewall DNAT-regel översätter den offentliga IP-adressen och porten för Azure Firewall till den offentliga IP-adressen och porten som används av arbetsbelastningen i Kubernetes offentliga Standard Load Balancer för AKS-klustret i nodresursgruppen.
Lastbalanseraren skickar begäran till en av Kubernetes-tjänstpoddarna som körs på en av agentnoderna i AKS-klustret.
Svarsmeddelandet skickas tillbaka till den ursprungliga anroparen via en användardefinierad väg. Den offentliga IP-adressen för Azure Firewall är adressprefixet och Internet är typen Nästa hopp.
Alla arbetsbelastningsinitierade utgående anrop dirigeras till den privata IP-adressen för Azure Firewall som standard för användardefinierad väg. 0.0.0.0/0 är adressprefixet och Den virtuella installationen är typen Nästa hopp.

Mer information finns i Använda Azure Firewall framför AKS-klustrets offentliga standardlastbalanserare.

Använda Azure Firewall framför en intern Standard Load Balancer

I exemplet som är associerat med den här artikeln hanteras ett ASP.NET Core-program som en tjänst av ett AKS-kluster och frontas av en NGINX-ingresskontrollant. NGINX-ingressstyrenheten exponeras via en intern lastbalanserare som har en privat IP-adress i det virtuella ekernätverket som är värd för AKS-klustret. Mer information finns i Skapa en ingresskontrollant till ett internt virtuellt nätverk i AKS. När du distribuerar en NGINX-ingresskontrollant, eller mer allmänt en eller ClusterIP flera LoadBalancer tjänster, med kommentaren service.beta.kubernetes.io/azure-load-balancer-internal: "true" i metadataavsnittet, skapas en intern standardlastbalanserare med namnet kubernetes-internal under nodresursgruppen. Mer information finns i Använda en intern lastbalanserare med AKS. Som du ser i följande diagram exponeras testwebbprogrammet av Azure Firewall via en dedikerad offentlig IP-adress för Azure.

Här är meddelandeflödet:

En begäran för det AKS-värdbaserade testwebbprogrammet skickas till en offentlig IP-adress som exponeras av Azure Firewall via en offentlig IP-konfiguration. Både den offentliga IP-adressen och den offentliga IP-konfigurationen är dedikerade till den här arbetsbelastningen.
En AZURE Firewall DNAT-regel översätter den offentliga IP-adressen och porten för Azure Firewall till den privata IP-adressen och porten som används av NGINX-ingresskontrollanten i den interna Standard Load Balancer för AKS-klustret i nodresursgruppen.
Begäran skickas av den interna lastbalanseraren till en av Kubernetes-tjänstpoddarna som körs på en av agentnoderna i AKS-klustret.
Svarsmeddelandet skickas tillbaka till den ursprungliga anroparen via en användardefinierad väg. 0.0.0.0/0 är adressprefixet och Den virtuella installationen är typen Nästa hopp.
Alla arbetsbelastningsinitierade utgående anrop dirigeras till den privata IP-adressen för den användardefinierade vägen.

Mer information finns i Använda Azure Firewall framför en intern Standard Load Balancer.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Några av följande överväganden är allmänna rekommendationer som inte är specifika för att använda Azure Firewall för att förbättra skyddet av ett AKS-kluster. Vi tror att de är viktiga krav för den här lösningen. Detta gäller för överväganden för säkerhet, prestanda, tillgänglighet och tillförlitlighet, lagring, servicenät och övervakning.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Azure-plattformen ger förbättrat skydd mot olika hot, till exempel nätverksintrång och DDoS-attacker (Distributed Denial-of-Service). Du bör använda en brandvägg för webbprogram (WAF) för att skydda alla AKS-värdbaserade webbprogram och -tjänster som exponerar en offentlig HTTPS-slutpunkt. Du måste skydda dig mot vanliga hot som SQL-inmatning, skript för flera webbplatser och andra webbexploateringar. Det gör du genom att använda OWASP-regler (Open Web Application Security Project) och anpassade regler. Azure Web Application Firewall ger förbättrat centraliserat skydd av dina webbprogram mot vanliga sårbarheter och sårbarheter. Du kan distribuera Azure WAF med Azure Application Gateway, Azure Front Door och Azure Content Delivery Network.

DDoS-attacker är bland de största tillgänglighets- och säkerhetsproblemen för organisationer som flyttar sina program till molnet. En DDoS-attack försöker uttömma ett programs resurser, vilket gör programmet otillgängligt för legitima användare. DDoS-attacker kan riktas mot valfri slutpunkt som kan nås offentligt via Internet. Varje egenskap i Azure innehåller skydd via Azure DDoS-infrastrukturskydd utan extra kostnad. Skalan och kapaciteten i det globalt distribuerade Azure-nätverket ger bättre skydd mot vanliga nätverksnivåattacker genom alltid på trafikövervakning och realtidsreducering. DDoS-infrastrukturskydd kräver ingen användarkonfiguration eller programändringar. Det hjälper till att skydda alla Azure-tjänster, inklusive PaaS-tjänster som Azure DNS.

Azure DDoS Network Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Du bör aktivera Azure DDOS Network Protection i alla virtuella perimeternätverk.

Följande är några ytterligare säkerhetsöverväganden:

Skapa en privat slutpunkt för alla PaaS-tjänster som används av AKS-arbetsbelastningar, till exempel Key Vault, Azure Service Bus och Azure SQL Database. Trafiken mellan programmen och dessa tjänster exponeras inte för det offentliga Internet. Trafik mellan det virtuella AKS-klustrets virtuella nätverk och en instans av en PaaS-tjänst via en privat slutpunkt färdas i Microsofts stamnätverk, men kommunikationen skickas inte av Azure Firewall. Den här mekanismen ger bättre säkerhet och bättre skydd mot dataläckage. Mer information finns i Vad är Azure Private Link?.
När du använder Application Gateway framför AKS-klustret använder du en brandväggsprincip för webbprogram för att skydda offentliga arbetsbelastningar som körs på AKS från attacker.
Använd nätverksprinciper för att separera och skydda intratjänstkommunikation genom att styra vilka komponenter som kan kommunicera med varandra. Som standard kan alla poddar i ett Kubernetes-kluster skicka och ta emot trafik utan begränsningar. För att förbättra säkerheten kan du använda Azure-nätverksprinciper eller Calico-nätverksprinciper för att definiera regler som styr trafikflödet mellan olika mikrotjänster. Mer information finns i Nätverksprincip.
Exponera inte fjärranslutning till dina AKS-noder. Skapa en skyddsvärd eller en hoppruta i ett virtuellt hanteringsnätverk. Använd skyddsvärden för att dirigera trafik till ditt AKS-kluster.
Överväg att använda ett privat AKS-kluster i produktionsmiljön, eller åtminstone säker åtkomst till API-servern, med hjälp av auktoriserade IP-adressintervall i AKS. När du använder auktoriserade IP-adressintervall i ett offentligt kluster tillåter du alla utgående IP-adresser i Azure Firewall-nätverksregelsamlingen. I klusteråtgärder används Kubernetes API-servern.
Om du aktiverar DNS-proxy i Azure Firewall kan Azure Firewall bearbeta och vidarebefordra DNS-frågor från ett eller flera virtuella nätverk till en DNS-server som du väljer. Den här funktionen är avgörande och krävs för tillförlitlig FQDN-filtrering i nätverksregler. Du kan aktivera DNS-proxy i Inställningar för Azure Firewall och Brandväggsprincip. Mer information om DNS-proxyloggar finns i Logg och mått för Azure Firewall.
När du använder Azure Firewall framför Application Gateway kan du konfigurera kubernetes-ingressresursen så att den exponerar arbetsbelastningar via HTTPS och använder ett separat underdomän- och digitalt certifikat för varje klientorganisation. Application Gateway Ingress Controller (AGIC) konfigurerar automatiskt Application Gateway-lyssnarenför SSL-avslutning (Secure Sockets Layer).
Du kan använda Azure Firewall framför en tjänstproxy som NGINX-ingresskontrollanten. Den här kontrollanten tillhandahåller omvänd proxy, konfigurerbar trafikroutning och TLS-avslutning för Kubernetes-tjänster. Kubernetes ingress-resurser används för att konfigurera inkommande regler och vägar för enskilda Kubernetes-tjänster. Genom att använda en ingresskontrollant och ingressregler kan du använda en enda IP-adress för att dirigera trafik till flera tjänster i ett Kubernetes-kluster. Du kan generera TLS-certifikaten med hjälp av en identifierad certifikatutfärdare. Du kan också använda Let's Encrypt för att automatiskt generera TLS-certifikat med en dynamisk offentlig IP-adress eller med en statisk offentlig IP-adress. Mer information finns i Skapa en HTTPS-ingresskontrollant och använd dina egna TLS-certifikat på AKS.
Strikt samordning mellan Azure Firewall-operatören och klustret och arbetsbelastningsteamen är nödvändiga både för den inledande klusterdistributionen och på ett pågående sätt när arbetsbelastnings- och klusterbehoven utvecklas. Detta gäller särskilt när du konfigurerar autentiseringsmekanismerna, till exempel OAuth 2.0 och OpenID Anslut, som används av arbetsbelastningar för att autentisera sina klienter.
Använd följande riktlinjer för att skydda miljön som beskrivs i den här artikeln:

Tillgänglighet och tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Tillgänglighets- och tillförlitlighetsövervägandena här är inte specifika för flera klientorganisationer i AKS. Vi tror att de är viktiga krav för den här lösningen. Överväg följande metoder för att optimera tillgängligheten för ditt AKS-kluster och dina arbetsbelastningar.

Återhämtning inom regionen

Under distributionen kan du konfigurera Azure Firewall så att den omfattar flera tillgänglighetszoner för ökad tillgänglighet. Mer information om drifttidsprocent finns i serviceavtalet för Azure Firewall. Du kan också associera Azure Firewall med en specifik zon för närhets skull, även om den här konfigurationen påverkar serviceavtalet. Det kostar inget extra för en brandvägg som distribueras i en tillgänglighetszon. Det finns dock extra kostnader för inkommande och utgående dataöverföringar som är associerade med tillgänglighetszoner. Mer information finns i Prisinformation om bandbredd.
Överväg att distribuera nodpoolerna i ditt AKS-kluster i alla tillgänglighetszoner i en region. Använd en Azure Standard Load Balancer eller Application Gateway framför nodpoolerna. Den här topologin ger bättre återhämtning om det uppstår ett enda datacenterfel. Klusternoderna distribueras över flera datacenter i tre separata tillgänglighetszoner i en region.
Aktivera zonredundans i Container Registry för återhämtning inom regionen och hög tillgänglighet.
Använd begränsningar för poddtopologispridning för att styra hur poddar sprids över ditt AKS-kluster bland feldomäner som regioner, tillgänglighetszoner och noder.
Överväg att använda serviceavtal för drifttid för AKS-kluster som är värdar för verksamhetskritiska arbetsbelastningar. Serviceavtal för drifttid är en valfri funktion som möjliggör ett ekonomiskt säkerhetskopierat, högre serviceavtal för ett kluster. Serviceavtal för drifttid garanterar hög tillgänglighet för Kubernetes API-serverslutpunkten för kluster som använder tillgänglighetszoner. Du kan också använda det för kluster som inte använder tillgänglighetszoner, men serviceavtalet är lägre. Mer information om serviceavtal finns i Serviceavtal för drifttid. AKS använder huvudnoders repliker över uppdaterings- och feldomäner för att säkerställa att SLA-kraven är uppfyllda.

Haveriberedskap och affärskontinuitet

Överväg att distribuera din lösning till minst två kopplade Azure-regioner inom ett geografiskt område. Använd en global lastbalanserare, till exempel Azure Traffic Manager eller Azure Front Door, med en aktiv/aktiv eller aktiv/passiv routningsmetod, för att garantera affärskontinuitet och haveriberedskap (DR).
Azure Firewall är en regional tjänst. Om du distribuerar lösningen i två eller flera regioner måste du skapa en Azure Firewall i varje region. Du kan skapa en global Azure Firewall Policy för att inkludera regler med organisations mandat som gäller för alla regionala hubbar. Du kan använda den här principen som en överordnad princip för regionala Azure-principer. Principer som skapats med icke-tomma överordnade principer ärver alla regelsamlingar från den överordnade principen. Nätverksregelsamlingar som ärvs från en överordnad princip prioriteras alltid ovanför nätverksregelsamlingar som definieras som en del av en ny princip. Samma logik gäller för programregelsamlingar. Nätverksregelsamlingar bearbetas dock alltid före programregelsamlingar, oavsett arv. Mer information om Standard- och Premium-principer finns i Översikt över Azure Firewall Manager-principer.
Se till att skript, dokument och regelbundet testa alla regionala redundansprocesser i en QA-miljö. Detta hjälper till att undvika oförutsägbara problem om en kärntjänst påverkas av ett avbrott i den primära regionen. Dessa tester kontrollerar också om DR-metoden uppfyller RPO/RTO-mål, tillsammans med eventuella manuella processer och åtgärder som behövs för en redundansväxling.
Se till att testa redundansprocedurer för att verifiera att de fungerar som förväntat.
Lagra dina containeravbildningar i Container Registry. Geo-replikera registret till varje AKS-region. Mer information finns i Geo-replikering i Azure Container Registry.
Undvik om möjligt att lagra tjänsttillståndet i containern. Använd i stället en Azure PaaS som stöder replikering i flera regioner.
Om du använder Azure Storage förbereder och testar du en process för att migrera din lagring från den primära regionen till säkerhetskopieringsregionen.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

DevOps

Distribuera dina arbetsbelastningar till AKS med hjälp av ett Helm-diagram i en CI/CD-pipeline (kontinuerlig integrering och kontinuerlig leverans). Använd ett DevOps-system som GitHub Actions eller Azure DevOps. Mer information finns i Skapa och distribuera till Azure Kubernetes Service.
Om du vill testa ett program korrekt innan du gör det tillgängligt för användare använder du A/B-testning och kanariedistributioner i din programlivscykelhantering. Det finns flera tekniker som du kan använda för att dela upp trafiken mellan olika versioner av samma tjänst. Som ett alternativ kan du använda de trafikdelningsfunktioner som tillhandahålls av en tjänstnätimplementering. Mer information finns i Linkerd Traffic Split och Istio Traffic Management.
Använd Azure Container Registry eller ett annat containerregister (till exempel Docker Hub) för att lagra de privata Docker-avbildningarna som distribueras till klustret. AKS kan autentisera med Azure Container Registry med hjälp av dess Microsoft Entra-identitet.
Testa ingress och utgående trafik på dina arbetsbelastningar i en separat förproduktionsmiljö som speglar nätverkstopologin och brandväggsreglerna i produktionsmiljön. En stegvis distributionsstrategi hjälper dig att identifiera eventuella nätverk eller säkerhetsproblem innan du släpper en ny funktion eller nätverksregel i produktion.

Övervakning

Azure Firewall är helt integrerat med Azure Monitor för loggning av inkommande och utgående trafik som bearbetas av brandväggen. Mer information finns i Hotinformationsbaserad filtrering i Azure Firewall.

Följande övervakningsöverväganden är inte specifika för flera klientorganisationer i AKS, men vi tror att de är viktiga krav för den här lösningen.

Använd Container Insights för att övervaka hälsostatusen för AKS-klustret och arbetsbelastningarna.
Konfigurera alla PaaS-tjänster (till exempel Container Registry och Key Vault) för att samla in diagnostikloggar och mått.

Kostnadsoptimering

Kostnaden för den resulterande arkitekturen beror på följande konfigurationsinformation:

Tjänstnivåer
Skalbarhet (antalet instanser som dynamiskt allokeras av tjänster för att stödja en viss efterfrågan)
Automatiseringsskript
Din haveriberedskapsnivå

När du har utvärderat konfigurationsinformationen använder du Priskalkylatorn för Azure för att beräkna dina kostnader. Fler alternativ för prisoptimering finns i principerna för kostnadsoptimering i Microsoft Azure Well-Architected Framework.

Distribuera det här scenariot

Källkoden för det här scenariot är tillgänglig i GitHub. Den här lösningen är öppen källkod och tillhandahålls med en MIT-licens.

Förutsättningar

För onlinedistributioner behöver du ett Azure-konto. Om du inte har ett konto kan du skapa ett kostnadsfritt Azure-konto innan du börjar. Du måste uppfylla dessa krav innan du kan distribuera Terraform-moduler med hjälp av Azure DevOps:

Lagra Terraform-tillståndsfilen på ett Azure-lagringskonto. Mer information om hur du använder ett lagringskonto för att lagra fjärrtillstånd för Terraform, tillståndslåsning och kryptering i vila finns i Lagra Terraform-tillstånd i Azure Storage.
Skapa ett Azure DevOps-projekt. Mer information finns i Skapa ett projekt i Azure DevOps.
Skapa en Azure DevOps-tjänstanslutning till din Azure-prenumeration. Du kan använda autentisering av tjänstens huvudnamn (SPA) eller en Azure-hanterad tjänstidentitet när du skapar tjänstanslutningen. I båda fallen måste du se till att tjänstens huvudnamn eller hanterade identitet som används av Azure DevOps för att ansluta till din Azure-prenumeration tilldelas ägarrollen för hela prenumerationen.

Distribution till Azure

Ha din Azure-prenumerationsinformation till hands.

Klona GitHub-lagringsplatsen workbench:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Följ anvisningarna i filen README.md.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Paolo Salvatori | Huvudtjänsttekniker

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Granska rekommendationerna och metodtipsen för AKS i Microsoft Azure Well-Architected Framework:

Använda Azure Firewall för att skydda ett AKS-kluster (Azure Kubernetes Service)