Azure Arc-hybridhantering och -distribution för Kubernetes-kluster

Azure Arc
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Policy
Azure Role-based access control

Den här referensarkitekturen visar hur Azure Arc utökar Kubernetes-klusterhantering och -konfiguration över kunddatacentra, gränsplatser och flera molnmiljöer.

Arkitektur

Arkitekturdiagram visar en Topologi för Azure Arc for Kubernetes.

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

Arbetsflöde

Arkitekturen består av följande aspekter:

  • Azure Arc-aktiverade Kubernetes. Koppla och konfigurera Kubernetes-kluster i eller utanför Azure med hjälp av Azure Arc-aktiverade Kubernetes. När ett Kubernetes-kluster är kopplat till Azure Arc tilldelas det ett Azure Resource Manager-ID och en hanterad identitet.
  • Azure Kubernetes Service. Värdhantera Kubernetes-kluster i Azure för att minska komplexiteten och driftkostnaderna för Kubernetes-klusterhantering.
  • Lokalt Kubernetes-kluster. Bifoga CNCF-certifierade Kubernetes-kluster (Cloud Native Computing Foundation) som finns i lokala eller tredjepartsmolnmiljöer.
  • Azure Policy. Distribuera och hantera principer för Arc-aktiverade Kubernetes-kluster.
  • Azure Monitor. Observera och övervaka Arc-aktiverade Kubernetes-kluster.

Komponenter

  • Azure Arc är en brygga som utökar Azure-plattformen, vilket gör det möjligt att skapa program och tjänster som kan köras över datacenter, vid gränsen och i miljöer med flera moln.
  • Azure Kubernetes Service (AKS) är en hanterad tjänst för distribution och skalning av Kubernetes-kluster.
  • Azure Policy gör det möjligt att uppnå molnefterlevnad i realtid i stor skala med konsekvent resursstyrning.
  • Azure Monitor tillhandahåller observerbarhet från slutpunkt till slutpunkt för dina program, infrastruktur och nätverk.

Information om scenario

Du kan använda Azure Arc för att registrera Kubernetes-kluster som finns utanför Microsoft Azure. Du kan sedan använda Azure-verktyg för att hantera dessa kluster tillsammans med kluster som finns i Azure Kubernetes Service (AKS).

Potentiella användningsfall

Vanliga användningsområden för den här arkitekturen inkluderar:

  • Hantera lokala Kubernetes-kluster och -kluster som finns i AKS för inventering, gruppering och taggning.
  • Använda Azure Monitor för att övervaka Kubernetes-kluster i hybridmiljöer.
  • Använda Azure Policy för att distribuera och tillämpa principer för Kubernetes-kluster i hybridmiljöer.
  • Använda Azure Policy för att distribuera och framtvinga GitOps.

Rekommendationer

Följande avsnitt innehåller rekommendationer som gäller för de flesta scenarier. Microsoft rekommenderar att du följer dem om du inte har ett krav som åsidosätter dem.

Klusterregistrering

Du kan registrera alla aktiva CNCF Kubernetes-kluster. Du behöver en kubeconfig-fil för att komma åt klustret och en klusteradministratörsroll i klustret för att distribuera Arc-aktiverade Kubernetes-agenter. Du använder Azures kommandoradsgränssnitt (CLI) för att utföra klusterregistreringsuppgifter. Användaren eller tjänstens huvudnamn som du använder för az login - och az connectedk8s connect-kommandona kräver läs- och skrivbehörigheter för resurstypen Microsoft.Kubernetes/connectedClusters. Kubernetes-klustret – Azure Arc Onboarding-rollen har dessa behörigheter och kan användas för rolltilldelningar på antingen användarens huvudnamn eller tjänstens huvudnamn. Helm 3 krävs för registrering av klustret som använder tillägget connectedk8s. Azure CLI version 2.3 eller senare krävs för att installera Azure Arc-aktiverade Kubernetes-kommandoradsgränssnittstillägg.

Azure Arc-agenter för Kubernetes

Azure Arc-aktiverade Kubernetes består av några agenter (kallas även operatorer) som körs i klustret som distribueras till azure-arc-namnområdet:

  • deployment.apps/config-agent. Bevakar det anslutna klustret efter konfigurationsresurser för källkontroll som tillämpas på klustret och uppdaterar efterlevnadstillståndet.
  • deployment.apps/controller-manager. En operator för operatorer som samordnar interaktioner mellan Azure Arc-komponenter.
  • deployment.apps/metrics-agent. Samlar in mått från andra Arc-agenter för att säkerställa att dessa agenter uppvisar optimala prestanda.
  • deployment.apps/cluster-metadata-operator. Samlar in klustermetadata, klusterversion, antal noder och Azure Arc-agentversion.
  • deployment.apps/resource-sync-agent. Synkroniserar tidigare nämnda klustermetadata till Azure.
  • deployment.apps/clusteridentityoperator. Underhåller MSI-certifikatet (Managed Service Identity) som används av andra agenter för att kommunicera med Azure.
  • deployment.apps/flux-logs-agent. Samlar in loggar från flödesoperatorerna som distribueras som en del av källkontrollkonfigurationen.
  • deployment.apps/extension-manager. Installerar och hanterar livscykeln för helm-tilläggsdiagram.
  • deployment.apps/kube-azure-ad-proxy. Används för autentisering av de begäranden som skickas till klustret med hjälp av Cluster Connect.
  • deployment.apps/clusterconnect-agent. En omvänd proxyagent som gör det möjligt för funktionen för klusteranslutning att ge åtkomst till klustrets apiserver. Det är en valfri komponent som endast distribueras om funktionen för klusteranslutning är aktiverad i klustret.
  • deployment.apps/guard. En webhook-server för autentisering och auktorisering som används för rollbaserad åtkomstkontroll i Microsoft Entra (RBAC). Det är en valfri komponent som endast distribueras om azure-rbac-funktionen är aktiverad i klustret.

Mer information finns i Ansluta ett Azure Arc-aktiverat Kubernetes-kluster.

Övervaka kluster med hjälp av Azure Monitor Container Insights

Det är viktigt att övervaka containrarna. Azure Monitor Container Insights ger en omfattande övervakningsupplevelse för AKS- och AKS-motorkluster. Du kan också konfigurera Azure Monitor Container Insights för att övervaka Azure Arc-aktiverade Kubernetes-kluster som finns utanför Azure. Detta ger omfattande övervakning av dina Kubernetes-kluster i azure-, lokala och tredjepartsmolnmiljöer.

Azure Monitor Container Insights kan ge dig prestandasynlighet genom att samla in minnes- och processormått från kontrollanter, noder och containrar, mått som är tillgängliga i Kubernetes via API:et (Metrics Application Programming Interface). Containerloggar samlas också in. När du har aktiverat övervakning från Kubernetes-kluster samlas mått och loggar automatiskt in åt dig av en containerbaserad version av Log Analytics-agenten. Mått skrivs till måttlagret och loggdata skrivs till loggarkivet som är associerat med din Log Analytics-arbetsyta. Mer information om Azure Monitor Container Insights finns i Översikt över Azure Monitor Container Insights.

Du kan aktivera Azure Monitor Container Insights för en eller flera distributioner av Kubernetes med hjälp av antingen ett PowerShell-skript eller ett Bash-skript.

Information om hur du aktiverar övervakning för Arc-aktiverade Kubernetes-kluster finns i Aktivera övervakning av Azure Arc-aktiverat Kubernetes-kluster

Använda Azure Policy för att aktivera GitOps-baserad programdistribution

Använd Azure Policy för att framtvinga att varje GitOps-aktiverad Microsoft.Kubernetes/connectedclusters-resurs eller Microsoft.ContainerService/managedClusters-resurs har specifika Microsoft.KubernetesConfiguration/fluxConfigurations som tillämpas på den. Du kan till exempel använda en baslinjekonfiguration på ett eller flera kluster eller distribuera specifika program till flera kluster. Om du vill använda Azure Policy väljer du en definition från de inbyggda Azure Policy-definitionerna för Azure Arc-aktiverade Kubernetes och skapar sedan en principtilldelning.

När du skapar principtilldelningen anger du omfånget till en Azure-resursgrupp eller prenumeration. Ange också parametrarna för den fluxConfiguration som skapas. När tilldelningen skapas identifierar principmotorn alla anslutnaCluster- eller managedCluster-resurser som finns inom omfånget och tillämpar sedan fluxConfigurationvar och en.

Om du använder flera källlagringsplatser för varje kluster (till exempel en lagringsplats för den centrala IT-/klusteroperatorn och andra lagringsplatser för programteam) aktiverar du detta med hjälp av flera principtilldelningar och konfigurerar varje principtilldelning för att använda en annan källlagringsplats.

Mer information finns i Distribuera program konsekvent i stor skala med flux v2-konfigurationer och Azure Policy.

Distribuera program med GitOps

GitOps är en metod för att deklarera det önskade tillståndet för Kubernetes-konfigurationen (distributioner, namnområden och så vidare) på en källlagringsplats, till exempel en Git- eller Helm-lagringsplats, Buckets eller Azure Blob Storage. Detta följs av en avsökning och pull-baserad distribution av dessa konfigurationer till klustret med hjälp av en operatör.

Anslutningen mellan klustret och en eller flera källlagringsplatser är aktiverad genom att distribuera tillägget microsoft.flux till klustret. Egenskaperna för fluxConfiguration-resursen representerar var och hur Kubernetes-resurser ska flöda från källlagringsplatsen till klustret. FluxConfiguration-data lagras krypterade i vila i en Azure Cosmos DB-databas för att säkerställa datasekretess.

Flux-config-agenten som körs i klustret ansvarar för att söka efter nya eller uppdaterade fluxConfiguration-tilläggsresurser på Den Azure Arc-aktiverade Kubernetes-resursen, för att distribuera program från källlagringsplatsen och för att sprida uppdateringar som görs till fluxConfiguration. Du kan till och med skapa flera fluxConfiguration-resurser med hjälp av namnområdesomfånget på samma Azure Arc-aktiverade Kubernetes-kluster för att uppnå flera innehavare.

Källlagringsplatsen kan innehålla alla giltiga Kubernetes-resurser, inklusive Namnområden, ConfigMaps, Distributioner och DaemonSets. Den kan också innehålla Helm-diagram för distribution av program. Vanliga scenarier för källlagringsplatser är att definiera en baslinjekonfiguration för din organisation som kan innehålla vanliga rollbasåtkomstkontrollroller (RBAC) roller och bindningar, övervakningsagenter, loggningsagenter och klusteromfattande tjänster.

Du kan också hantera en större samling kluster som distribueras i heterogena miljöer. Du kan till exempel ha en lagringsplats som definierar baslinjekonfigurationen för din organisation och sedan tillämpa den på flera Kubernetes-kluster samtidigt. Du kan också distribuera program till ett kluster från flera källlagringsplatser.

Mer information finns i Distribuera program med GitOps med Flux v2.

Topologi, nätverk och routning

Azure Arc-agenter kräver följande protokoll/portar/utgående URL:er för att fungera:

Slutpunkt (DNS) beskrivning
https://management.azure.com:443 Krävs för att agenten ska kunna ansluta till Azure och registrera klustret.
https://[region].dp.kubernetesconfiguration.azure.com:443 Dataplansslutpunkt för agenten för att push-överföra status och hämta konfigurationsinformation, där [region] representerar den Azure-region som är värd för AKS-instansen.
https://docker.io:443 Krävs för att hämta containeravbildningar.
https://github.com:443, git://github.com:9418 Exempel på GitOps-lagringsplatser finns på GitHub. Konfigurationsagenten kräver anslutning till den git-slutpunkt som du anger.
https://login.microsoftonline.com:443 Krävs för att hämta och uppdatera Azure Resource Manager-token.
https://azurearcfork8s.azurecr.io:443 Krävs för att hämta containeravbildningar för Azure Arc-agenter.

En fullständig lista över URL:er för Azure Arc-tjänster finns i Nätverkskraven för Azure Arc.

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.

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.

  • I de flesta fall bör den plats som du väljer när du skapar installationsskriptet vara den Azure-region som är geografiskt närmast dina lokala resurser. Resten av data lagras i azure-geografin som innehåller den region som du anger, ett faktum som kan påverka ditt val av region om du har krav på datahemvist. Om ett avbrott påverkar Den Azure-region som datorn är ansluten till påverkar inte driftstoppet den anslutna datorn, men hanteringsåtgärder som använder Azure kanske inte slutförs. För motståndskraft när det uppstår ett regionalt avbrott är det bäst att du, om du har flera platser som tillhandahåller en geografiskt redundant tjänst, ansluter datorerna på varje plats till en annan Azure-region. Information om tillgängliga regioner finns i Regioner som stöds för Azure Arc-aktiverade Kubernetes.
  • Du bör se till att de tjänster som refereras i avsnittet Arkitektur stöds i den region där Azure Arc distribueras.

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.

  • Du kan använda Azure RBAC för att hantera åtkomst till Azure Arc-aktiverade Kubernetes i Azure och lokala miljöer som använder Microsoft Entra-identiteter. Mer information finns i Använda Azure RBAC för Kubernetes-auktorisering.
  • Microsoft rekommenderar att du använder ett huvudnamn för tjänsten som har begränsad behörighet för att registrera Kubernetes-kluster till Azure Arc. Den här metoden är användbar i CI/CD-pipelines som Azure Pipelines och GitHub Actions. Mer information finns i Skapa ett Azure Arc-aktiverat registreringstjänsthuvudnamn.
  • För att förenkla tjänstens huvudnamnshantering kan du använda hanterade identiteter i AKS. Kluster måste dock skapas med hjälp av den hanterade identiteten, och befintliga kluster (inklusive Azure och lokala kluster) kan inte migreras till hanterade identiteter. Mer information finns i Använda hanterade identiteter i Azure Kubernetes Service.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Allmänna kostnadsöverväganden beskrivs i avsnittet Principer för kostnadsoptimering i Microsoft Azure Well-Architected Framework.

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.

  • Innan du konfigurerar dina Azure Arc-aktiverade Kubernetes-kluster bör du granska begränsningarna för Azure Resource Manager-prenumerationer och Resursgruppsgränser för att planera för antalet kluster.
  • Använd Helm, paketeringsverktyget med öppen källkod, för att installera och hantera Kubernetes-programmets livscykel. På samma sätt som Linux-pakethanterare som APT och Yum använder du Helm för att hantera Kubernetes-diagram, som är paket med förkonfigurerade Kubernetes-resurser.

Deltagare

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

Huvudförfattare:

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

Nästa steg

Relaterad hybridvägledning:

Relaterade arkitekturer: