Dela via


Kubernetes-klustermönster med hög tillgänglighet

Den här artikeln beskriver hur du skapar och använder en Kubernetes-baserad infrastruktur med hög tillgänglighet med hjälp av AkS-motorn (Azure Kubernetes Service) på Azure Stack Hub. Det här scenariot är vanligt för organisationer med kritiska arbetsbelastningar i starkt begränsade och reglerade miljöer. Organisationer inom domäner som ekonomi, försvar och myndigheter.

Kontext och problem

Många organisationer utvecklar molnbaserade lösningar som utnyttjar toppmoderna tjänster och tekniker som Kubernetes. Även om Azure tillhandahåller datacenter i de flesta regioner i världen finns det ibland gränsanvändningsfall och scenarier där affärskritiska program måste köras på en specifik plats. Här är några saker att tänka på:

  • Platskänslighet
  • Svarstid mellan programmet och lokala system
  • Bevarande av bandbredd
  • Uppkoppling
  • Regelmässiga eller lagstadgade krav

Azure, i kombination med Azure Stack Hub, löser de flesta av dessa problem. En bred uppsättning alternativ, beslut och överväganden för en lyckad implementering av Kubernetes som körs på Azure Stack Hub beskrivs nedan.

Lösning

Det här mönstret förutsätter att vi måste hantera en strikt uppsättning begränsningar. Programmet måste köras lokalt och alla personuppgifter får inte nå offentliga molntjänster. Övervakning och andra icke-PII-data kan skickas till Azure och bearbetas där. Externa tjänster som ett offentligt containerregister eller andra kan nås men kan filtreras via en brandvägg eller proxyserver.

Exempelprogrammet som visas här är utformat för att använda Kubernetes-interna lösningar när det är möjligt. Den här designen undviker leverantörslåsning genom att inte använda plattformsspecifika tjänster. Programmet använder till exempel en mongoDB-databasserverdel med egen värd i stället för en PaaS-tjänst eller en extern databastjänst. Mer information finns i Introduktion till Kubernetes på Azures utbildningsväg.

Applikationsmönster Hybrid

Föregående diagram illustrerar programarkitekturen för exempelprogrammet som körs på Kubernetes på Azure Stack Hub. Appen består av flera komponenter, bland annat:

  1. Ett AKS-motorbaserat Kubernetes-kluster på Azure Stack Hub.
  2. cert-manager, som tillhandahåller en uppsättning verktyg för certifikathantering i Kubernetes, som används för att automatiskt begära certifikat från Let's Encrypt.
  3. Ett Kubernetes-namnområde som innehåller programkomponenterna för klientdelen (ratings-web), API (ratings-api) och databas (ratings-mongodb).
  4. Den ingresskontrollant som dirigerar HTTP/HTTPS-trafik till slutpunkter i Kubernetes-klustret.

Exempelprogrammet används för att illustrera programarkitekturen. Alla komponenter är exempel. Arkitekturen innehåller bara en enda programdistribution. För att uppnå hög tillgänglighet (HA) kör vi distributionen minst två gånger på två olika Azure Stack Hub-instanser – de kan köras antingen på samma plats eller på två (eller flera) olika platser:

Infrastrukturarkitektur

Tjänster som Azure Container Registry, Azure Monitor och andra finns utanför Azure Stack Hub i Azure eller lokalt. Den här hybriddesignen skyddar lösningen mot avbrott i en enda Azure Stack Hub-instans.

Komponenter

Den övergripande arkitekturen består av följande komponenter:

Azure Stack Hub är ett tillägg för Azure som kan köra arbetsbelastningar i en lokal miljö genom att tillhandahålla Azure-tjänster i ditt datacenter. Gå till Översikt över Azure Stack Hub om du vill veta mer.

Azure Kubernetes Service Engine (AKS Engine) är motorn bakom det hanterade Kubernetes-tjänsterbjudandet, Azure Kubernetes Service (AKS), som är tillgängligt i Azure idag. För Azure Stack Hub gör AKS Engine att vi kan distribuera, skala och uppgradera helt aktuella, självhanterade Kubernetes-kluster med hjälp av Azure Stack Hubs IaaS-funktioner. Gå till AKS-motoröversikt om du vill veta mer.

Gå till kända problem och begränsningar för att lära dig mer om skillnaderna mellan AKS Engine på Azure och AKS Engine på Azure Stack Hub.

Azure Virtual Network (VNet) används för att tillhandahålla nätverksinfrastrukturen på varje Azure Stack Hub för virtuella datorer (VM) som är värd för Kubernetes-klusterinfrastrukturen.

Azure Load Balancer- används för Kubernetes API-slutpunkten och Nginx-ingresskontrollanten. Lastbalanseraren dirigerar extern trafik (till exempel Internet) till noder och virtuella datorer som erbjuder en specifik tjänst.

Azure Container Registry (ACR) används för att lagra privata Docker-avbildningar och Helm-diagram som distribueras till klustret. AKS-motorn kan autentisera med Container Registry med hjälp av Microsoft Entra-ID. Kubernetes kräver inte ACR. Du kan använda andra containerregister, till exempel Docker Hub.

Azure Repos är en uppsättning versionskontrollverktyg som du kan använda för att hantera din kod. Du kan också använda GitHub eller andra git-baserade lagringsplatser. Gå till Översikt över Azure-lagringsplatser om du vill veta mer.

Azure Pipelines ingår i Azure DevOps Services och kör automatiserade versioner, tester och distributioner. Du kan också använda CI/CD-lösningar från tredje part, till exempel Jenkins. Gå till Översikt över Azure Pipeline om du vill veta mer.

Azure Monitor- samlar in och lagrar mått och loggar, inklusive plattformsmått för Azure-tjänsterna i lösnings- och programtelemetrin. Använd dessa data för att övervaka applikationen, konfigurera aviseringar och instrumentpaneler och utföra felanalyser. Azure Monitor integreras med Kubernetes för att samla in mått från kontrollanter, noder och containrar, samt containerloggar och huvudnodloggar. Gå till Översikt över Azure Monitor för mer information.

Azure Traffic Manager är en DNS-baserad lastbalanserare som gör att du kan distribuera trafik optimalt till tjänster i olika Azure-regioner eller Azure Stack Hub-distributioner. Traffic Manager ger också hög tillgänglighet och svarstider. Programslutpunkterna måste vara tillgängliga utifrån. Det finns även andra lokala lösningar.

Kubernetes Ingress Controller exponerar HTTP(S) rutter till tjänster i ett Kubernetes-kluster. Nginx eller någon lämplig ingresskontrollant kan användas för detta ändamål.

Helm är en pakethanterare för Kubernetes-distribution, vilket ger ett sätt att paketera olika Kubernetes-objekt som Distributioner, Tjänster, Hemligheter, i ett enda "diagram". Du kan publicera, distribuera, styra versionshantering och uppdatera ett diagramobjekt. Azure Container Registry kan användas som lagringsplats för att lagra paketerade Helm-diagram.

Designöverväganden

Det här mönstret följer några överväganden på hög nivå som beskrivs mer detaljerat i nästa avsnitt i den här artikeln:

  • Programmet använder lösningar som är inbyggda i Kubernetes för att undvika leverantörsinlåsning.
  • Programmet använder en arkitektur för mikrotjänster.
  • Azure Stack Hub behöver inte inkommande men tillåter utgående Internetanslutning.

Dessa rekommenderade metoder gäller även för verkliga arbetsbelastningar och scenarier.

Överväganden för skalbarhet

Skalbarhet är viktigt för att ge användarna konsekvent, tillförlitlig och högpresterande åtkomst till programmet.

Exempelscenariot omfattar skalbarhet på flera lager i programstacken. Här är en översikt på hög nivå över de olika lagren:

Arkitekturnivå Påverkar Hur?
Applikation Applikation Horisontell skalering baserat på antalet poddar/repliker/containerinstanser*
Kluster Kubernetes-kluster Antal noder (mellan 1 och 50), VM-SKU-storlekar och nodpooler (AKS-motorn på Azure Stack Hub stöder för närvarande endast en enda nodpool); använda AKS-motorns skalningskommando (manuellt)
Infrastruktur Azure Stack Hub Antal noder, kapacitet och skalningsenheter i en Azure Stack Hub-distribution

* Använder Kubernetes' horisontella poddautoskalning (HPA); automatiserad måttbaserad skalning eller lodrät skalning genom att ändra storleken på containerinstanserna (cpu/minne).

Azure Stack Hub (infrastrukturnivå)

Azure Stack Hub-infrastrukturen är grunden för den här implementeringen eftersom Azure Stack Hub körs på fysisk maskinvara i ett datacenter. När du väljer hubbmaskinvara måste du göra val för CPU, minnesdensitet, lagringskonfiguration och antal servrar. Om du vill veta mer om Skalbarheten för Azure Stack Hub kan du läsa följande resurser:

Kubernetes-kluster (klusternivå)

Själva Kubernetes-klustret består av och bygger på Azure (Stack) IaaS-komponenter, inklusive beräknings-, lagrings- och nätverksresurser. Kubernetes-lösningar omfattar huvud- och arbetsnoder, som distribueras som virtuella datorer i Azure (och Azure Stack Hub).

  • Kontrollplansnoder (master) tillhandahåller kubernetes-kärntjänster och orkestrering av programarbetsbelastningar.
  • Arbetsnoder (arbetare) kör dina programarbetsbelastningar.

När du väljer VM-storlekar för den första distributionen finns det flera saker att tänka på:

  • Cost – Tänk på den totala kostnaden per virtuell dator när du planerar dina arbetsnoder. Om dina programarbetsbelastningar till exempel kräver begränsade resurser bör du planera att distribuera virtuella datorer med mindre storlek. Azure Stack Hub, precis som Azure, faktureras normalt på förbrukningsbasis, så det är viktigt att storleksanpassa de virtuella datorerna för Kubernetes-roller på lämpligt sätt för att optimera förbrukningskostnaderna.

  • Skalbarhet – Skalbarhet för klustret uppnås genom att skala in och ut antalet huvud- och arbetsnoder, eller genom att lägga till ytterligare nodpooler (inte tillgängligt på Azure Stack Hub idag). Skalning av klustret kan göras baserat på prestandadata som samlas in med Container Insights (Azure Monitor + Log Analytics).

    Om programmet behöver fler (eller färre) resurser kan du skala ut (eller i) dina aktuella noder vågrätt (mellan 1 och 50 noder). Om du behöver fler än 50 noder kan du skapa ytterligare ett kluster i en separat prenumeration. Du kan inte skala upp de faktiska virtuella datorerna lodrätt till en annan VM-storlek utan att distribuera om klustret.

    Skalning görs manuellt med hjälp av den virtuella AKS Engine-hjälpdatorn som användes för att distribuera Kubernetes-klustret från början. Mer information finns i Skala Kubernetes-kluster

  • kvoter – Överväg de kvoter du har konfigurerat när du planerar en AKS-distribution på din Azure Stack Hub. Kontrollera att varje prenumeration har rätt planer och de konfigurerade kvoterna. Prenumerationen måste hantera mängden beräkning, lagring och andra tjänster som behövs för dina kluster när de skalas ut.

  • Programarbetsbelastningar – Se begreppen kluster och arbetsbelastningar i Kubernetes-huvudbegreppen för Azure Kubernetes Service-dokumentet. Den här artikeln hjälper dig att begränsa den virtuella datorns storlek baserat på programmets beräknings- och minnesbehov.

program (programnivå)

På programlagret använder vi Kubernetes HORIZONTAL Pod Autoscaler (HPA). HPA kan öka eller minska antalet repliker (podd-/containerinstanser) i vår distribution baserat på olika mått (till exempel CPU-användning).

Ett annat alternativ är att skala containerinstanser vertikalt. Detta kan åstadkommas genom att ändra mängden processor och minne som begärs och är tillgängligt för en specifik distribution. Mer information finns i Hantera resurser för containrar på kubernetes.io.

Nätverks- och anslutningsöverväganden

Nätverk och anslutning påverkar också de tre lager som tidigare nämnts för Kubernetes på Azure Stack Hub. I följande tabell visas lagren och vilka tjänster de innehåller:

Lager Påverkar Vad?
Applikation Applikation Hur är programmet tillgängligt? Kommer den att exponeras för Internet?
Kluster Kubernetes-kluster Kubernetes API, AKS Engine VM, hämtar containerbilder, skickar övervakningsdata och telemetri
Infrastruktur Azure Stack Hub Tillgänglighet för Azure Stack Hub-hanteringsslutpunkter som portalen och Azure Resource Manager-slutpunkter.

Applikation

För programskiktet är det viktigaste att tänka på om programmet är exponerat och tillgängligt från Internet. Från ett Kubernetes-perspektiv innebär internetexponering att exponera en distribution eller podd med hjälp av en Kubernetes-tjänst eller en Ingress-controller.

Att exponera ett program med en offentlig IP-adress via en lastbalanserare eller en ingresskontrollant innebär inte att programmet nu är tillgängligt via Internet. Det är möjligt för Azure Stack Hub att ha en offentlig IP-adress som bara är synlig i det lokala intranätet – inte alla offentliga IP-adresser är verkligen Internetuppkopplade.

Föregående block tar hänsyn till inkommande trafik till programmet. Ett annat ämne som måste beaktas för en lyckad Kubernetes-distribution är utgående/utgående trafik. Här följer några användningsfall som kräver utgående trafik:

  • Hämta containeravbildningar som lagras på DockerHub eller Azure Container Registry
  • Hämtar Helm-diagram
  • Generera Application Insights-data (eller andra övervakningsdata)

Vissa företagsmiljöer kan kräva användning av transparenta eller icke-transparenta proxyservrar. Dessa servrar kräver specifik konfiguration på olika komponenter i vårt kluster. AKS Engine-dokumentationen innehåller olika detaljer om hur du hanterar nätverksproxy. För mer information, se AKS Engine och proxyservrar

Slutligen måste trafik mellan kluster flöda mellan Azure Stack Hub-instanser. Exempeldistributionen består av enskilda Kubernetes-kluster som körs på enskilda Azure Stack Hub-instanser. Trafik mellan dem, till exempel replikeringstrafiken mellan två databaser, är "extern trafik". Extern trafik måste dirigeras via antingen en plats-till-plats-VPN eller offentliga IP-adresser för Azure Stack Hub för att ansluta Kubernetes till två Azure Stack Hub-instanser:

inter- och intraklustertrafik

kluster

Kubernetes-klustret behöver inte nödvändigtvis vara tillgängligt via Internet. Den relevanta delen är Kubernetes API som används för att driva ett kluster, till exempel med hjälp av kubectl. Kubernetes API-slutpunkten måste vara tillgänglig för alla som driver klustret eller distribuerar program och tjänster ovanpå det. Det här avsnittet beskrivs mer detaljerat ur ett DevOps-perspektiv i distributionsöverväganden (CI/CD) avsnittet nedan.

På klusternivå finns det också några överväganden kring utgående trafik:

  • Noduppdateringar (för Ubuntu)
  • Övervaka data (skickas till Azure LogAnalytics)
  • Andra agenter som kräver utgående trafik (specifika för varje distribuerares miljö)

Innan du distribuerar kubernetes-klustret med hjälp av AKS Engine ska du planera för den slutliga nätverksdesignen. I stället för att skapa ett dedikerat virtuellt nätverk kan det vara mer effektivt att distribuera ett kluster till ett befintligt nätverk. Du kan till exempel använda en befintlig VPN-anslutning från plats till plats som redan har konfigurerats i din Azure Stack Hub-miljö.

Infrastruktur

Infrastruktur avser åtkomst till Azure Stack Hub-hanteringsslutpunkter. Slutpunkterna omfattar klient- och administratörsportalerna samt Azure Resource Manager-administratörs- och klientslutpunkterna. Dessa slutpunkter krävs för att använda Azure Stack Hub och dess kärntjänster.

Data- och lagringsöverväganden

Två instanser av vårt program kommer att distribueras på två enskilda Kubernetes-kluster över två Azure Stack Hub-instanser. Den här designen kräver att vi överväger hur du replikerar och synkroniserar data mellan dem.

Med Azure har vi den inbyggda funktionen för att replikera lagring över flera regioner och zoner i molnet. För närvarande med Azure Stack Hub finns det inga inbyggda sätt att replikera lagring över två olika Azure Stack Hub-instanser – de bildar två oberoende moln utan övergripande sätt att hantera dem som en uppsättning. Att planera för återhämtning av program som körs i Azure Stack Hub tvingar dig att överväga detta oberoende i din programdesign och distributioner.

I de flesta fall är lagringsreplikering inte nödvändigt för ett motståndskraftigt och högtillgängligt program som distribueras i AKS. Men du bör överväga oberoende lagring per Azure Stack Hub-instans i din programdesign. Om den här designen är ett problem eller ett vägblock för att distribuera lösningen på Azure Stack Hub finns det möjliga lösningar från Microsoft-partner som tillhandahåller bifogade filer för lagring. Med bifogade lagringsbilagor får du en lagringsreplikeringslösning i flera Azure Stack Hubs och Azure. Mer information finns i Partnerlösningar.

I vår arkitektur övervägdes dessa lager:

Konfiguration

Konfigurationen omfattar konfigurationen av Azure Stack Hub, AKS Engine och själva Kubernetes-klustret. Konfigurationen bör automatiseras så mycket som möjligt och lagras som Infrastruktur som kod i ett Git-baserat versionskontrollsystem som Azure DevOps eller GitHub. De här inställningarna kan inte enkelt synkroniseras mellan flera distributioner. Därför rekommenderar vi att du lagrar och tillämpar konfiguration utifrån och använder DevOps-pipelinen.

Applikation

Programmet ska lagras på en Git-baserad lagringsplats. När det finns en ny distribution, ändringar i programmet eller återställning efter katastrof kan den enkelt rullas ut med hjälp av Azure Pipelines.

data

Data är det viktigaste i de flesta programdesign. Programdata måste vara synkroniserade mellan de olika instanserna av programmet. Data behöver också en strategi för säkerhetskopiering och haveriberedskap om det uppstår ett avbrott.

Att uppnå den här designen beror mycket på teknikval. Här följer några lösningsexempel för att implementera en databas på ett sätt med hög tillgänglighet på Azure Stack Hub:

Överväganden när du arbetar med data på flera platser är ett ännu mer komplext övervägande för en lösning med hög tillgänglighet och motståndskraft. Överväga:

  • Svarstid och nätverksanslutning mellan Azure Stack Hubs.
  • Tillgänglighet för identiteter för tjänster och behörigheter. Varje Azure Stack Hub-instans integreras med en extern katalog. Under distributionen väljer du att använda antingen Microsoft Entra-ID eller Microsoft Entra-ID-federation. Därför finns det potential att använda en enda identitet som kan interagera med flera oberoende Azure Stack Hub-instanser.

Affärskontinuitet och haveriberedskap

Affärskontinuitet och haveriberedskap (BCDR) är ett viktigt ämne i både Azure Stack Hub och Azure. Den största skillnaden är att i Azure Stack Hub måste operatorn hantera hela BCDR-processen. I Azure hanteras delar av BCDR automatiskt av Microsoft.

BCDR påverkar samma områden som nämns i föregående avsnitt data- och lagringsöverväganden:

  • Infrastruktur/konfiguration
  • Programtillgänglighet
  • Programdata

Som vi nämnde i föregående avsnitt är dessa områden azure stack hub-operatörens ansvar och kan variera mellan organisationer. Planera BCDR enligt dina tillgängliga verktyg och processer.

infrastruktur och konfiguration

Det här avsnittet beskriver den fysiska och logiska infrastrukturen och konfigurationen av Azure Stack Hub. Den omfattar åtgärder i administratörs- och klientutrymmena.

Azure Stack Hub-operatorn (eller administratören) ansvarar för underhåll av Azure Stack Hub-instanserna. Inklusive komponenter som nätverk, lagring, identitet och andra ämnen som ligger utanför omfånget för den här artikeln. Mer information om detaljerna i Azure Stack Hub-åtgärder finns i följande resurser:

Azure Stack Hub är den plattform och infrastruktur som Kubernetes-program ska distribueras på. Programägaren för Kubernetes-programmet kommer att vara en användare av Azure Stack Hub, med åtkomst beviljad för att distribuera den programinfrastruktur som behövs för lösningen. Programinfrastruktur i det här fallet innebär Kubernetes-klustret, som distribueras med HJÄLP av AKS Engine och de omgivande tjänsterna. Dessa komponenter distribueras till Azure Stack Hub, som begränsas av ett Azure Stack Hub-erbjudande. Kontrollera att erbjudandet som accepteras av Kubernetes-programägaren har tillräcklig kapacitet (uttryckt i Azure Stack Hub-kvoter) för att distribuera hela lösningen. Som rekommenderat i föregående avsnitt bör programdistributionen automatiseras med hjälp av Infrastruktur-som-kod och distributionspipelines som Azure DevOps och Azure Pipelines.

Mer information om erbjudanden och kvoter för Azure Stack Hub finns i Översikt över Azure Stack Hub-tjänster, planer, erbjudanden och prenumerationer

Det är viktigt att spara och lagra AKS Engine-konfigurationen på ett säkert sätt, inklusive dess utdata. Dessa filer innehåller konfidentiell information som används för att komma åt Kubernetes-klustret, så de måste skyddas från att exponeras för icke-administratörer.

Programtillgänglighet

Programmet ska inte förlita sig på säkerhetskopior av en distribuerad instans. Som standard distribuerar du om programmet helt efter infrastruktur-som-kod-mönster. Omdistribuera till exempel med Azure DevOps Azure Pipelines. BCDR-proceduren bör omfatta omdistribution av programmet till samma eller ett annat Kubernetes-kluster.

Applikationsdata

Programdata är den viktiga delen för att minimera dataförlust. I föregående avsnitt beskrevs metoder för att replikera och synkronisera data mellan två (eller flera) instanser av programmet. Beroende på vilken databasinfrastruktur (MySQL, MongoDB, MSSQL eller andra) som används för att lagra data, finns det olika tekniker för databastillgänglighet och säkerhetskopiering att välja mellan.

De rekommenderade sätten att uppnå integritet är att använda antingen:

  • En intern säkerhetskopieringslösning för den specifika databasen.
  • En säkerhetskopieringslösning som officiellt stöder säkerhetskopiering och återställning av den databastyp som används av ditt program.

Viktig

Lagra inte dina säkerhetskopierade data på samma Azure Stack Hub-instans där dina programdata finns. Ett fullständigt avbrott i Azure Stack Hub-instansen skulle också äventyra dina säkerhetskopior.

Tillgänglighetsöverväganden

Kubernetes på Azure Stack Hub som distribueras via AKS Engine är inte en hanterad tjänst. Det är en automatiserad distribution och konfiguration av ett Kubernetes-kluster med hjälp av Azure Infrastructure-as-a-Service (IaaS). Därför ger den samma tillgänglighet som den underliggande infrastrukturen.

Azure Stack Hub-infrastrukturen är redan motståndskraftig mot fel och tillhandahåller funktioner som tillgänglighetsuppsättningar för att distribuera komponenter över flera fel- och uppdateringsdomäner. Men den underliggande tekniken (redundansklustring) medför fortfarande viss stilleståndstid för virtuella datorer på en påverkad fysisk server, om det uppstår ett maskinvarufel.

Det är en bra idé att distribuera kubernetes-produktionsklustret och arbetsbelastningen till två (eller flera) kluster. Dessa kluster ska finnas på olika platser eller datacenter och använda tekniker som Azure Traffic Manager för att dirigera användare baserat på klustersvarstid eller baserat på geografi.

Använda Traffic Manager för att styra trafikflöden

Kunder som har ett enda Kubernetes-kluster ansluter vanligtvis till tjänstens IP- eller DNS-namn för ett visst program. I en distribution med flera kluster bör kunderna ansluta till ett Traffic Manager DNS-namn som pekar på tjänsterna/ingressen för varje Kubernetes-kluster.

Använda Traffic Manager för att dirigera till lokalt kluster

Not

Det här mönstret är också en rekommenderad praxis för (hanterade) AKS-kluster i Azure.

Själva Kubernetes-klustret, som distribueras via AKS-motorn, bör bestå av minst tre huvudnoder och två arbetsnoder.

Identitets- och säkerhetsöverväganden

Identitet och säkerhet är viktiga ämnen. Särskilt när lösningen omfattar oberoende Azure Stack Hub-instanser. Kubernetes och Azure (inklusive Azure Stack Hub) har båda olika mekanismer för rollbaserad åtkomstkontroll (RBAC):

  • Azure RBAC styr åtkomsten till resurser i Azure (och Azure Stack Hub), inklusive möjligheten att skapa nya Azure-resurser. Behörigheter kan tilldelas till användare, grupper eller tjänsthuvudnamn. (Ett huvudnamn för tjänsten är en säkerhetsidentitet som används av program.)
  • Kubernetes RBAC styr behörigheter till Kubernetes API. Att till exempel skapa poddar och visa poddar är åtgärder som kan auktoriseras (eller nekas) till en användare via RBAC. Om du vill tilldela Kubernetes-behörigheter till användare skapar du roller och rollbindningar.

Azure Stack Hub-identitet och RBAC-

Azure Stack Hub innehåller två alternativ för identitetsprovider. Vilken provider du använder beror på miljön och om den körs i en ansluten eller frånkopplad miljö:

  • Microsoft Entra-ID – kan endast användas i en ansluten miljö.
  • Microsoft Entra ID-federation till en traditionell Active Directory-skog – kan användas i både en ansluten eller frånkopplad miljö.

Identitetsprovidern hanterar användare och grupper, inklusive autentisering och auktorisering för åtkomst till resurser. Åtkomst kan beviljas till Azure Stack Hub-resurser som prenumerationer, resursgrupper och enskilda resurser som virtuella datorer eller lastbalanserare. Om du vill ha en konsekvent åtkomstmodell bör du överväga att använda samma grupper (antingen direkt eller kapslade) för alla Azure Stack Hubs. Här är ett konfigurationsexempel:

Diagram över kapslade Microsoft Entra-ID-grupper med Azure Stack Hub.

Exemplet innehåller en dedikerad grupp för ett specifikt syfte. Om du till exempel vill ge deltagarbehörigheter för resursgruppen som innehåller vår Kubernetes-klusterinfrastruktur på en specifik Azure Stack Hub-instans (här "Seattle K8s Cluster Contributor"). Dessa grupper kapslas sedan i en övergripande grupp som innehåller "undergrupper" för varje Azure Stack Hub.

Vår exempelanvändare har nu behörigheten "Deltagare" för båda resursgrupperna som innehåller hela uppsättningen Kubernetes-infrastrukturresurser. Användaren kommer att ha åtkomst till resurser på båda Azure Stack Hub-instanserna, eftersom instanserna delar samma identitetsprovider.

Viktig

Dessa behörigheter påverkar endast Azure Stack Hub och vissa av de resurser som distribueras ovanpå den. En användare som har den här åtkomstnivån kan göra mycket skada, men inte komma åt de virtuella Kubernetes IaaS-datorerna eller Kubernetes-API:et utan ytterligare åtkomst till Kubernetes-distributionen.

Kubernetes-identitet och RBAC

Ett Kubernetes-kluster använder som standard inte samma identitetsprovider som den underliggande Azure Stack Hub. De virtuella datorer som är värdar för Kubernetes-klustret, huvudnoderna och arbetsnoderna använder den SSH-nyckel som anges under distributionen av klustret. Den här SSH-nyckeln krävs för att ansluta till dessa noder med hjälp av SSH.

Kubernetes API (till exempel åtkomst med kubectl) är också skyddad av tjänstkonton, inklusive ett standardtjänstkonto kallat "klusteradmin". Autentiseringsuppgifterna för det här tjänstkontot lagras ursprungligen i filen .kube/config på dina Kubernetes-huvudnoder.

Hantering av hemligheter och programautentiseringsuppgifter

Det finns flera alternativ för att lagra hemligheter som anslutningssträngar eller databasautentiseringsuppgifter:

  • Azure Key Vault
  • Kubernetes-hemligheter
  • Tredjepartslösningar som HashiCorp Vault (körs på Kubernetes)

Lagra inte hemligheter eller autentiseringsuppgifter i klartext i dina konfigurationsfiler, programkod eller i skript. Och lagra dem inte i ett versionskontrollsystem. Implementeringsautomatiseringen bör istället hämta hemligheterna efter behov.

Korrigera och uppdatera

Processen Patch and Update (PNU) i Azure Kubernetes Service är delvis automatiserad. Kubernetes-versionsuppgraderingar utlöses manuellt, medan säkerhetsuppdateringar tillämpas automatiskt. Dessa uppdateringar kan innehålla os-säkerhetskorrigeringar eller kerneluppdateringar. AKS startar inte automatiskt om dessa Linux-noder för att slutföra uppdateringsprocessen.

PNU-processen för ett Kubernetes-kluster som distribueras med AKS Engine på Azure Stack Hub är ohanterad och är klusteroperatorns ansvar.

AKS Engine hjälper till med de två viktigaste uppgifterna:

Nyare bas-OS-avbildningar innehåller de senaste säkerhetskorrigeringarna för operativsystemet och kerneluppdateringar.

Mekanismen obevakad uppgradering installerar automatiskt säkerhetsuppdateringar som släpps innan en ny basversion av os-avbildningen är tillgänglig på Azure Stack Hub Marketplace. Obevakad uppgradering aktiveras som standard och installerar säkerhetsuppdateringar automatiskt, men startar inte om Kubernetes-klusternoderna. Omstart av noderna kan automatiseras med hjälp av Kubernetes med öppen källkod REstart Daemon (kured)). Kured övervakar Linux-noder som kräver en omstart och hanterar sedan automatiskt omläggningen av poddar som körs och nodens omstartsprocess.

Överväganden för distribution (CI/CD)

Azure och Azure Stack Hub exponerar samma REST-API:er för Azure Resource Manager. Dessa API:er hanteras på samma sätt som andra Azure-moln (Azure, Azure China 21Vianet, Azure Government). Det kan finnas skillnader i API-versioner mellan moln, och Azure Stack Hub tillhandahåller endast en delmängd av tjänsterna. URI:n för hanteringsslutpunkten skiljer sig också åt för varje moln och för varje instans av Azure Stack Hub.

Förutom de subtila skillnader som nämns ger Azure Resource Manager REST API:er ett konsekvent sätt att interagera med både Azure och Azure Stack Hub. Samma uppsättning verktyg kan användas här som används med andra Azure-moln. Du kan använda Azure DevOps, verktyg som Jenkins eller PowerShell, för att distribuera och samordna tjänster till Azure Stack Hub.

överväganden

En av de största skillnaderna när det gäller Azure Stack Hub-distributioner är frågan om Internettillgänglighet. Internettillgänglighet avgör om du vill välja en Microsoft-värdbaserad eller en lokalt installerad byggagent för dina CI/CD-jobb.

En lokalt installerad agent kan köras ovanpå Azure Stack Hub (som en virtuell IaaS-dator) eller i ett nätverksundernät som har åtkomst till Azure Stack Hub. Gå till Azure Pipelines-agenter för att lära dig mer om skillnaderna.

Följande bild hjälper dig att avgöra om du behöver en lokalt installerad eller en Microsoft-värdbaserad byggagent:

lokalt installerade byggagenter Ja eller Nej

  • Är Azure Stack Hub-hanteringsslutpunkterna tillgängliga via Internet?
    • Ja: Vi kan använda Azure Pipelines med Microsoft-hostade agenter för att ansluta till Azure Stack Hub.
    • Nej: Vi behöver lokalt installerade agenter som kan ansluta till Azure Stack Hubs hanteringsslutpunkter.
  • Är vårt Kubernetes-kluster tillgängligt via Internet?
    • Ja: Vi kan använda Azure Pipelines med Microsoft-värdbaserade agenter för att interagera direkt med Kubernetes API-slutpunkt.
    • Nej: Vi behöver lokalt installerade agenter som kan ansluta till Kubernetes-klustrets API-slutpunkt.

I scenarier där Azure Stack Hub-hanteringsslutpunkter och Kubernetes API är tillgängliga via Internet kan distributionen använda en Microsoft-värdbaserad agent. Den här distributionen resulterar i en programarkitektur på följande sätt:

översikt över offentlig arkitektur

Om Azure Resource Manager-slutpunkterna, Kubernetes-API:et eller båda inte är direkt tillgängliga via Internet kan vi använda en lokal byggagent för att köra pipelinestegen. Den här designen behöver mindre anslutning och kan distribueras med endast lokal nätverksanslutning till Azure Resource Manager-slutpunkter och Kubernetes-API:et:

översikt över arkitektur för lokal drift

Not

Hur är det med frånkopplade scenarier? I scenarier där antingen Azure Stack Hub eller Kubernetes eller båda inte har internetuppkopplade hanteringsslutpunkter är det fortfarande möjligt att använda Azure DevOps för dina distributioner. Du kan antingen använda en lokalt installerad agentpool (som är en DevOps-agent som körs lokalt eller på själva Azure Stack Hub) eller en helt lokalt installerad Azure DevOps Server. Den lokalt installerade agenten behöver endast utgående HTTPS-internetanslutning (TCP/443).

Mönstret kan använda ett Kubernetes-kluster (distribuerat och orkestrerat med AKS-motorn) på varje Azure Stack Hub-instans. Den innehåller ett program som består av en klientdel, en mellannivå, serverdelstjänster (till exempel MongoDB) och en nginx-baserad ingresskontrollant. I stället för att använda en databas som finns i K8s-klustret kan du använda "externa datalager". Databasalternativen omfattar MySQL, SQL Server eller någon form av databas som finns utanför Azure Stack Hub eller i IaaS. Konfigurationer som denna finns inte i omfånget här.

Partnerlösningar

Det finns Microsoft Partner-lösningar som kan utöka funktionerna i Azure Stack Hub. De här lösningarna har hittats användbara i distributioner av program som körs i Kubernetes-kluster.

Lagrings- och datalösningar

Som beskrivs i data- och lagringsövervägandenhar Azure Stack Hub för närvarande ingen intern lösning för att replikera lagring över flera instanser. Till skillnad från Azure finns det inte möjlighet att replikera lagring i flera regioner. I Azure Stack Hub är varje instans ett eget distinkt moln. Lösningar är dock tillgängliga från Microsoft-partner som möjliggör lagringsreplikering i Azure Stack Hubs och Azure.

SCALITY

Scality levererar lagring i skala för webben som har drivit digitala företag sedan år 2009. Scality RING, vår programvarudefinierade lagring, förvandlar x86-servrar till en obegränsad lagringspool för alla typer av data – fil och objekt – i petabyteskala.

CLOUDIAN

Cloudian förenklar företagslagring med obegränsad skalbar lagring som konsoliderar massiva datauppsättningar till en enda, lätthanterad miljö.

Nästa steg

Om du vill veta mer om begrepp som introduceras i den här artikeln:

När du är redo att testa lösningsexemplet fortsätter du med distributionsguiden Kubernetes-kluster med hög tillgänglighet. Distributionsguiden innehåller stegvisa instruktioner för att distribuera och testa dess komponenter.