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änglig kapacitet 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:

Förutsättningar

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

• Läs artikeln Kubernetes-klustermönster med hög tillgänglighet.
• Granska innehållet i tilläggsdatabasen GitHub ,som innehåller ytterligare tillgångar som refereras till i den här artikeln.
• Ha ett konto som har åtkomst Azure Stack Hub användarportalen,med minst deltagarbehörighet.

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 (Windows) på Azure Stack Hub. Den kommer att användas senare när AKS Engine distribuerar Kubernetes-kluster.

Den stegvisa processen och kraven för AKS-motorn dokumenteras här:

• Installera AKS-motorn på Linux i Azure Stack Hub (eller med Windows)

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

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

• Vad är AKS-motorn på Azure Stack Hub?
• AKS-motor på Azure Stack Hub (på GitHub)

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

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

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

Anslut till hjälpdatorn för AKS-motorn

Först måste du ansluta till den tidigare skapade hjälpdatorn för AKS Engine.

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

ssh <username>@<ipaddress>

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

Distribuera ett Kubernetes-kluster

Den virtuella AKS-motorns hjälpmaskin har inte skapat något Kubernetes-kluster på Azure Stack Hub ännu. Att skapa klustret är den första åtgärden som ska vidtas i den virtuella AKS-motorns hjälpmaskin.

Den stegvisa processen dokumenteras här:

• Distribuera ett Kubernetes-kluster med AKS-motorn Azure Stack Hub

Slutresultatet av kommandot och förberedelserna i föregående steg är ett fullständigt Kubernetes-kluster som distribuerats till klientutrymmet för den aks-engine deploy 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.

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

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

Anslut till Kubernetes-klustret

Du kan nu ansluta till det tidigare skapade Kubernetes-klustret, antingen via SSH (med den SSH-nyckel som angetts som en del av distributionen) eller via kubectl (rekommenderas). Kommandoradsverktyget Kubernetes kubectl är tillgängligt för Windows, Linux och macOS kubectl Det är redan förinstallerat och konfigurerat på huvudnoderna i vårt kluster:

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

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 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.

Nu kan du prova olika kommandon med kubectl för att kontrollera klustrets status. 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

Anslut Azure Pipelines till Kubernetes-kluster

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

• Anslut till en av huvudnoderna i Kubernetes-klustret.
• Kopiera innehållet i .kube/config filen.
• Gå till Azure DevOps Project Inställningar Service Connections (Azure DevOps-tjänstanslutningar) för att skapa en ny >> "Kubernetes"-tjänstanslutning (använd KubeConfig som autentiseringsmetod)

När du distribuerar lokala 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. Mer information finns här:

• Azure Pipelines-agenterpå Windows eller Linux

Avsnittet om överväganden för mönsterdistribution (CI/CD) innehåller ett beslutsflöde som hjälper dig att förstå om du ska använda Microsofts värdbaserade agenter eller agenter med egen värd:

I den här exempellösningen innehåller topologin en bygga agent med egen värd på varje Azure Stack Hub instans. Agenten kan komma åt Azure Stack Hub hanteringsslutpunkter och Kubernetes-klustrets API-slutpunkter.

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 det AKS-motor-distribuerade Kubernetes-klustret på Azure Stack Hub.

Det finns två sätt att Azure Monitor i klustret. Båda sätten kräver att du ställer in 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 möjliggör 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) kubectl och på datorn.

Helm är en Kubernetes-pakethanterare som är tillgänglig som en binärfil 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 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

Med det här kommandot installeras Azure Monitor-agenten i Kubernetes-klustret:

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

OmS-agenten (Operations Management Suite) 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.

Distribuera programmet

Innan du installerar vårt exempelprogram finns det ytterligare ett steg för att konfigurera den nginx-baserade ingress-kontrollanten på vårt Kubernetes-kluster. Ingress-kontrollanten 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 Helm Chart GitHub-lagringsplatsen.

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-diagramfilerna i den tillhörande GitHub lagringsplatsen

Exempelprogrammet är ett program på tre nivåer som distribueras till ett Kubernetes-kluster på var och en 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 ochStorage överväganden .

När du har distribuerat Helm-diagrammet för programmet visas alla tre nivåerna i ditt program som distributioner och tillståndsfulla 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 finns den nginx-baserade ingress-kontrollanten 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 hur användare ansluter för att öppna programmet och kommer även att användas som slutpunkt för nästa steg Konfigurera Traffic Manager.

Autoskala programmet

Om du vill kan du 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 Horizontal Pod Autoscaler som underhåller 1 till 10 repliker av poddarna som styrs av ratings-web-distributionen. HPA ökar och minskar antalet repliker (via distributionen) för att upprätthålla en genomsnittlig processoranvändning på 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 lastbalanserare för DNS-baserad trafik i Azure.

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

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

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

I det här läget:

• Kubernetes-infrastrukturen har skapats, inklusive en ingress-kontrollant.
• Kluster har distribuerats över två Azure Stack Hub instanser.
• Övervakning har konfigurerats.
• Azure Traffic Manager belastningsutjämna 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 hjälp av Helm-diagram.

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

Det finns även några driftöverväganden efter distributionen som är värda att diskutera, som vi går in på i nästa två avsnitt.

Uppgradera Kubernetes

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

• Att uppgradera ett Kubernetes-kluster är en komplex dag 2-åtgärd som kan göras med AKS-motorn. Mer information finns i Uppgradera ett Kubernetes-kluster på Azure Stack Hub.
• Med AKS-motorn kan du uppgradera kluster till nyare Kubernetes- och basversioner av OPERATIVSYSTEMavbildningar. Mer information finns i Steg för att uppgradera till en nyare Kubernetes-version.
• Du kan också uppgradera endast de underliggande noderna till nyare basoperativsystemavbildningsversioner. Mer information finns i Steg för att endast uppgradera OS-avbildningen.

Nyare grundläggande OS-avbildningar innehåller säkerhets- och kerneluppdateringar. Det är klusteroperatorns ansvar att övervaka tillgängligheten för nyare Kubernetes-versioner och OS-avbildningar. Operatören bör planera och köra dessa uppgraderingar med hjälp av AKS-motorn. 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 AKS-motorn.

Skalningskommandot återanvänder klusterkonfigurationsfilen (apimodel.json) i utdatakatalogen som indata för en Azure Resource Manager distribution. AKS-motorn 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.

• Skala ett Kubernetes-kluster på Azure Stack Hub

Nästa steg

• Läs mer om designöverväganden för hybridapp.
• Granska och föreslå förbättringar av koden för det här exemplet på GitHub.