Distribuera ett Kubernetes-kluster med hög tillgänglighet på Azure Stack Hub

Den här artikeln visar hur du skapar en Kubernetes-klustermiljö med hög tillgänglighet som distribueras på flera Azure Stack Hub-instanser på olika fysiska platser.

I den här distributionsguiden för lösningen lär du dig att:

  • Ladda ned och förbereda AKS-motorn
  • Ansluta till AKS Engine Helper VM
  • Distribuera ett Kubernetes-kluster
  • Ansluta till Kubernetes-klustret
  • Ansluta Azure Pipelines till Kubernetes-kluster
  • Konfigurera övervakning
  • Distribuera programmet
  • Autoskalning av program
  • Konfigurera Traffic Manager
  • Uppgradera Kubernetes
  • Skala Kubernetes

Tips

Hybridpelare Microsoft Azure Stack Hub är ett tillägg till Azure. Azure Stack Hub ger flexibiliteten och innovationen inom molnbaserad databehandling till din lokala miljö, vilket möjliggör det enda hybridmoln som gör att du kan skapa och distribuera hybridappar var som helst.

Artikeln Om designöverväganden för hybridappar granskar grundpelare för programvarukvalitet (placering, skalbarhet, tillgänglighet, återhämtning, hanterbarhet och säkerhet) för design, distribution och användning av hybridappar. Designövervägandena hjälper dig att optimera hybridappdesignen och minimera utmaningarna i produktionsmiljöer.

Förutsättningar

Innan du börjar med den här distributionsguiden bör du se till att du:

Ladda ned och förbereda AKS-motorn

AKS Engine är en binärfil som kan användas från valfri Windows- eller Linux-värd som kan nå Azure Stack Hub Azure Resource Manager-slutpunkter. Den här guiden beskriver hur du distribuerar en ny virtuell Linux-dator (eller Windows) på Azure Stack Hub. Den används senare när AKS Engine distribuerar Kubernetes-klustren.

Anteckning

Du kan också använda en befintlig virtuell Windows- eller Linux-dator för att distribuera ett Kubernetes-kluster på Azure Stack Hub med hjälp av AKS Engine.

Den stegvisa processen och kraven för AKS Engine finns dokumenterade här:

AKS Engine är ett hjälpverktyg för att distribuera och använda (ohanterade) Kubernetes-kluster (i Azure och Azure Stack Hub).

Information och skillnader i AKS-motorn på Azure Stack Hub beskrivs här:

Exempelmiljön använder Terraform för att automatisera distributionen av den virtuella datorn med AKS-motorn. Du hittar information och kod på den tillhörande GitHub-lagringsplatsen.

Resultatet av det här steget är en ny resursgrupp på Azure Stack Hub som innehåller AKS Engine helper VM och relaterade resurser:

VM-resurser för AKS-motorn i Azure Stack Hub

Anteckning

Om du behöver distribuera AKS Engine i en frånkopplad luftgapad miljö kan du läsa Mer information finns i Frånkopplade Azure Stack Hub-instanser .

I nästa steg använder vi den nyligen distribuerade virtuella DATORN AKS Engine för att distribuera ett Kubernetes-kluster.

Ansluta till aks-motorns hjälpdator

Först måste du ansluta till den tidigare skapade virtuella aks-motorns hjälpdator.

Den virtuella datorn ska ha en offentlig IP-adress och vara tillgänglig via SSH (port 22/TCP).

Översiktssida för AKS Engine VM

Tips

Du kan använda ett verktyg som MobaXterm, puTTY eller PowerShell i Windows 10 för att ansluta till en virtuell Linux-dator med hjälp av SSH.

ssh <username>@<ipaddress>

När du har anslutit kör du kommandot aks-engine. Gå till VERSIONER av AKS-motorn som stöds om du vill veta mer om AKS-motorn och Kubernetes-versionerna.

exempel på aks-engine-kommandorad

Distribuera ett Kubernetes-kluster

Själva AKS-motorns hjälpdator har ännu inte skapat något Kubernetes-kluster på vår Azure Stack Hub. Att skapa klustret är den första åtgärden som ska vidtas i aks engine helper VM.

Den stegvisa processen dokumenteras här:

Slutresultatet av aks-engine deploy kommandot och förberedelserna i föregående steg är ett fullständigt aktuellt Kubernetes-kluster som distribuerats till klientutrymmet för den första Azure Stack Hub-instansen. Själva klustret består av Azure IaaS-komponenter som virtuella datorer, lastbalanserare, virtuella nätverk, diskar och så vidare.

Kluster-IaaS-komponenter i Azure Stack Hub-portalen

  1. Azure-lastbalanserare (K8s API-slutpunkt) 2) Arbetsnoder (agentpool) 3) huvudnoder

Klustret är nu igång och i nästa steg ansluter vi till det.

Ansluta till Kubernetes-klustret

Nu kan du ansluta till det tidigare skapade Kubernetes-klustret, antingen via SSH (med SSH-nyckeln som anges som en del av distributionen) eller via kubectl (rekommenderas). Kommandoradsverktyget kubectl Kubernetes är tillgängligt för Windows, Linux och macOS här. Den är redan förinstallerad och konfigurerad på huvudnoderna i klustret:

ssh azureuser@<k8s-master-lb-ip>

Köra kubectl på huvudnoden

Vi rekommenderar inte att du använder huvudnoden som en jumpbox för administrativa uppgifter. Konfigurationen kubectl lagras i .kube/config på huvudnoderna samt på den virtuella datorn med AKS-motorn. Du kan kopiera konfigurationen till en administratörsdator med anslutning till Kubernetes-klustret och använda kubectl kommandot där. Filen .kube/config används också senare för att konfigurera en tjänstanslutning i Azure Pipelines.

Viktigt

Skydda dessa filer eftersom de innehåller autentiseringsuppgifterna för ditt Kubernetes-kluster. En angripare med åtkomst till filen har tillräckligt med information för att få administratörsåtkomst till den. Alla åtgärder som utförs med den första .kube/config filen utförs med ett klusteradministratörskonto.

Nu kan du prova olika kommandon med kubectl för att kontrollera statusen för klustret. Här är exempelkommandon:

kubectl get nodes
NAME                       STATUS   ROLE     VERSION
k8s-linuxpool-35064155-0   Ready    agent    v1.14.8
k8s-linuxpool-35064155-1   Ready    agent    v1.14.8
k8s-linuxpool-35064155-2   Ready    agent    v1.14.8
k8s-master-35064155-0      Ready    master   v1.14.8
kubectl cluster-info
Kubernetes master is running at https://aks.***
CoreDNS is running at https://aks.***/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://aks.***/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy
Metrics-server is running at https://aks.***/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy

Viktigt

Kubernetes har en egen RBAC-modell (Rollbaserad Access Control) som gör att du kan skapa detaljerade rolldefinitioner och rollbindningar. Det här är det bästa sättet att styra åtkomsten till klustret i stället för att dela ut behörigheter för klusteradministratör.

Ansluta Azure Pipelines till Kubernetes-kluster

För att ansluta Azure Pipelines till det nyligen distribuerade Kubernetes-klustret behöver vi dess kubeconfig-fil (.kube/config) enligt beskrivningen i föregående steg.

  • Anslut till en av huvudnoderna i ditt Kubernetes-kluster.
  • Kopiera filens .kube/config innehåll.
  • Gå till Tjänstanslutningar för Azure DevOps-projektinställningar >> för att skapa en ny Kubernetes-tjänstanslutning (använd KubeConfig som autentiseringsmetod)

Viktigt

Azure Pipelines (eller dess byggagenter) måste ha åtkomst till Kubernetes-API:et. Om det finns en Internetanslutning från Azure Pipelines till Azure Stack Hub Kubernetes-klustret måste du distribuera en lokal Azure Pipelines Build Agent.

När du distribuerar lokalt installerade agenter för Azure Pipelines kan du distribuera antingen på Azure Stack Hub eller på en dator med nätverksanslutning till alla nödvändiga hanteringsslutpunkter. Se informationen här:

Avsnittet om överväganden för distribution (CI/CD) innehåller ett beslutsflöde som hjälper dig att förstå om du ska använda Agenter med Microsoft som värd eller lokalt installerade agenter:

Diagram som visar ett beslutsflöde med lokalt installerade agenter.

Ladda ned en Visio-fil med alla diagram i den här artikeln.

I den här exempellösningen innehåller topologin en lokal byggagent på varje Azure Stack Hub-instans. Agenten kan komma åt Azure Stack Hub-hanteringsslutpunkterna och Kubernetes-klustrets API-slutpunkter.

Diagram som visar utgående trafik.

Ladda ned en Visio-fil med alla diagram i den här artikeln.

Den här designen uppfyller ett vanligt regelkrav, som är att endast ha utgående anslutningar från programlösningen.

Konfigurera övervakning

Du kan använda Azure Monitor för containrar för att övervaka containrarna i lösningen. Detta pekar Azure Monitor på det AKS-motordistribuerade Kubernetes-klustret på Azure Stack Hub.

Det finns två sätt att aktivera Azure Monitor i klustret. Båda sätten kräver att du konfigurerar en Log Analytics-arbetsyta i Azure.

  • Metod ett använder ett Helm-diagram
  • Metod två som en del av AKS Engine-klusterspecifikationen

I exempeltopologin används "Metod ett", vilket gör att automatisering av processen och uppdateringar kan installeras enklare.

För nästa steg behöver du en Azure LogAnalytics-arbetsyta (ID och nyckel), Helm (version 3) och kubectl på datorn.

Helm är en Kubernetes-pakethanterare som är tillgänglig som en binär fil som körs på macOS, Windows och Linux. Den kan laddas ned på helm.sh. Helm förlitar sig på Kubernetes-konfigurationsfilen som används för kubectl kommandot:

helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
helm repo update

helm install incubator/azuremonitor-containers \
--set omsagent.secret.wsid=<your_workspace_id> \
--set omsagent.secret.key=<your_workspace_key> \
--set omsagent.env.clusterName=<my_prod_cluster> \
--generate-name

Det här kommandot installerar Azure Monitor-agenten i ditt Kubernetes-kluster:

kubectl get pods -n kube-system
NAME                                       READY   STATUS
omsagent-8qdm6                             1/1     Running
omsagent-r6ppm                             1/1     Running
omsagent-rs-76c45758f5-lmc4l               1/1     Running

Operations Management Suite-agenten (OMS) i kubernetes-klustret skickar övervakningsdata till Azure Log Analytics-arbetsytan (med utgående HTTPS). Nu kan du använda Azure Monitor för att få djupare insikter om dina Kubernetes-kluster på Azure Stack Hub. Den här designen är ett kraftfullt sätt att demonstrera kraften i analyser som kan distribueras automatiskt med programmets kluster.

Azure Stack Hub-kluster i Azure Monitor

Information om Azure Monitor-kluster

Viktigt

Om Azure Monitor inte visar några Azure Stack Hub-data kontrollerar du att du har följt anvisningarna om hur du lägger till AzureMonitor-Containers lösning på en Azure Log Analytics-arbetsyta noggrant.

Distribuera programmet

Innan du installerar vårt exempelprogram finns det ytterligare ett steg för att konfigurera den nginx-baserade ingresskontrollanten i vårt Kubernetes-kluster. Ingresskontrollanten används som en layer 7-lastbalanserare för att dirigera trafik i vårt kluster baserat på värd, sökväg eller protokoll. Nginx-ingress är tillgängligt som ett Helm-diagram. Detaljerade anvisningar finns i GitHub-lagringsplatsen för Helm Chart.

Vårt exempelprogram paketeras också som ett Helm-diagram, som Azure Monitoring Agent i föregående steg. Därför är det enkelt att distribuera programmet till vårt Kubernetes-kluster. Du hittar Helm Chart-filerna i den tillhörande GitHub-lagringsplatsen

Exempelprogrammet är ett program med tre nivåer som distribueras till ett Kubernetes-kluster på var och en av två Azure Stack Hub-instanser. Programmet använder en MongoDB-databas. Du kan lära dig mer om hur du får data replikerade över flera instanser i mönstret Data- och Lagringsöverväganden.

När du har distribuerat Helm-diagrammet för programmet visas alla tre nivåerna i programmet som distributioner och tillståndskänsliga uppsättningar (för databasen) med en enda podd:

kubectl get pod,deployment,statefulset
NAME                                         READY   STATUS
pod/ratings-api-569d7f7b54-mrv5d             1/1     Running
pod/ratings-mongodb-0                        1/1     Running
pod/ratings-web-85667bfb86-l6vxz             1/1     Running

NAME                                         READY
deployment.extensions/ratings-api            1/1
deployment.extensions/ratings-web            1/1

NAME                                         READY
statefulset.apps/ratings-mongodb             1/1

På tjänsterna hittar du den nginx-baserade ingresskontrollanten och dess offentliga IP-adress:

kubectl get service
NAME                                         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)
kubernetes                                   ClusterIP      10.0.0.1       <none>        443/TCP
nginx-ingress-1588931383-controller          LoadBalancer   10.0.114.180   *public-ip*   443:30667/TCP
nginx-ingress-1588931383-default-backend     ClusterIP      10.0.76.54     <none>        80/TCP
ratings-api                                  ClusterIP      10.0.46.69     <none>        80/TCP
ratings-web                                  ClusterIP      10.0.161.124   <none>        80/TCP

"Extern IP-adress" är vår "programslutpunkt". Det är så användarna ansluter för att öppna programmet och kommer även att användas som slutpunkt för nästa steg Konfigurera Traffic Manager.

Skala programmet automatiskt

Du kan också konfigurera horizontal pod autoscaler för att skala upp eller ned baserat på vissa mått som CPU-användning. Följande kommando skapar en horisontell podd-autoskalning som underhåller 1 till 10 repliker av poddarna som styrs av distributionen ratings-web. HPA ökar och minskar antalet repliker (via distributionen) för att upprätthålla en genomsnittlig processoranvändning för alla poddar på 80 %:

kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10

Du kan kontrollera den aktuella statusen för autoskalning genom att köra det här kommandot:

kubectl get hpa
NAME          REFERENCE                      TARGET    MINPODS   MAXPODS   REPLICAS   AGE
ratings-web   Deployment/ratings-web/scale   0% / 80%  1         10        1          18s

Konfigurera Traffic Manager

För att distribuera trafik mellan två (eller flera) distributioner av programmet använder vi Azure Traffic Manager. Azure Traffic Manager är en DNS-baserad trafiklastbalanserare i Azure.

Anteckning

Traffic Manager använder DNS för att dirigera klientbegäranden till den lämpligaste tjänstslutpunkten, baserat på en trafikroutningsmetod och slutpunkternas hälsotillstånd.

I stället för att använda Azure Traffic Manager kan du också använda andra globala lösningar för belastningsutjämning lokalt. I exempelscenariot använder vi Azure Traffic Manager för att distribuera trafik mellan två instanser av vårt program. De kan köras på Azure Stack Hub-instanser på samma eller olika platser:

Diagram som visar en lokal trafikhanterare.

Ladda ned en Visio-fil med alla diagram i den här artikeln.

I Azure konfigurerar vi Traffic Manager så att det pekar på de två olika instanserna av vårt program:

TM-slutpunktsprofil

Som du ser pekar de två slutpunkterna på de två instanserna av det distribuerade programmet från föregående avsnitt.

Nu:

  • Kubernetes-infrastrukturen har skapats, inklusive en ingresskontrollant.
  • Kluster har distribuerats över två Azure Stack Hub-instanser.
  • Övervakning har konfigurerats.
  • Azure Traffic Manager belastningsutjämning av trafik mellan de två Azure Stack Hub-instanserna.
  • Utöver den här infrastrukturen har exempelprogrammet med tre nivåer distribuerats på ett automatiserat sätt med Helm-diagram.

Lösningen bör nu vara tillgänglig för användarna!

Det finns också några driftsöverväganden efter distributionen som är värda att diskutera, som beskrivs i de kommande två avsnitten.

Uppgradera Kubernetes

Tänk på följande när du uppgraderar Kubernetes-klustret:

Nyare os-basavbildningar innehåller säkerhets- och kerneluppdateringar. Det är klusteroperatörens ansvar att övervaka tillgängligheten för nyare Kubernetes-versioner och OS-avbildningar. Operatorn bör planera och köra dessa uppgraderingar med hjälp av AKS Engine. Basoperativsystemavbildningarna måste laddas ned från Azure Stack Hub Marketplace av Azure Stack Hub-operatören.

Skala Kubernetes

Skala är en annan dag 2-åtgärd som kan orkestreras med hjälp av AKS Engine.

Skalningskommandot återanvänder klusterkonfigurationsfilen (apimodel.json) i utdatakatalogen som indata för en ny Azure-Resource Manager distribution. AKS Engine kör skalningsåtgärden mot en specifik agentpool. När skalningsåtgärden är klar uppdaterar AKS Engine klusterdefinitionen i samma apimodel.json-fil. Klusterdefinitionen återspeglar antalet nya noder för att återspegla den uppdaterade aktuella klusterkonfigurationen.

Nästa steg