Een Kubernetes-cluster met hoge beschikbaarheid implementeren op Azure Stack Hub
In dit artikel wordt beschreven hoe u een zeer beschikbare Kubernetes-clusteromgeving bouwt die is geïmplementeerd op meerdere Azure Stack Hub-exemplaren, op verschillende fysieke locaties.
In deze implementatiehandleiding voor oplossingen leert u het volgende:
- De AKS-engine downloaden en voorbereiden
- Verbinding maken naar de AKS Engine Helper-VM
- Een Kubernetes-cluster implementeren
- Verbinding maken aan het Kubernetes-cluster
- Verbinding maken Azure Pipelines naar Kubernetes-cluster
- Bewaking configureren
- Toepassing implementeren
- Toepassing automatisch schalen
- Traffic Manager configureren
- Kubernetes bijwerken
- Kubernetes schalen
Tip
Microsoft Azure Stack Hub is een uitbreiding van Azure. Azure Stack Hub brengt de flexibiliteit en innovatie van cloud-computing naar uw on-premises omgeving, waardoor de enige hybride cloud waarmee u hybride apps overal kunt bouwen en implementeren.
Het artikel Ontwerpoverwegingen voor hybride apps bespreekt de pijlers van softwarekwaliteit (plaatsing, schaalbaarheid, beschikbaarheid, tolerantie, beheersbaarheid en beveiliging) voor het ontwerpen, implementeren en gebruiken van hybride apps. De ontwerpoverwegingen helpen bij het optimaliseren van het ontwerp van hybride apps, waardoor de uitdagingen in productieomgevingen worden geminimim hetzelfde.
Vereisten
Voordat u aan de slag gaat met deze implementatiehandleiding, moet u het volgende doen:
- Lees het artikel Kubernetes-clusterpatroon met hoge beschikbaarheid.
- Bekijk de inhoud van de aanvullende GitHub opslagplaats, die aanvullende assets bevat waarnaar in dit artikel wordt verwezen.
- Een account hebben dat toegang heeft tot de Azure Stack Hub-gebruikersportal, met ten minste 'inzendermachtigingen'.
AKS-engine downloaden en voorbereiden
AKS Engine is een binair bestand dat kan worden gebruikt vanaf elke Windows- of Linux-host die de Azure Stack Hub Azure Resource Manager bereiken. In deze handleiding wordt beschreven hoe u een nieuwe virtuele Linux-VM (of Windows) implementeert op Azure Stack Hub. Deze wordt later gebruikt wanneer de AKS-engine de Kubernetes-clusters implementeert.
Notitie
U kunt ook een bestaande VM Windows Linux gebruiken om een Kubernetes-cluster op een Azure Stack Hub met behulp van de AKS-engine.
Het stapsgewijs proces en de vereisten voor de AKS-engine worden hier beschreven:
AKS Engine is een hulphulpprogramma voor het implementeren en uitvoeren van (onmanagede) Kubernetes-clusters (in Azure en Azure Stack Hub).
De details en verschillen van de AKS-engine op Azure Stack Hub worden hier beschreven:
In de voorbeeldomgeving wordt Terraform gebruikt om de implementatie van de AKS Engine-VM te automatiseren. U vindt de details en code in de GitHub-repo.
Het resultaat van deze stap is een nieuwe resourcegroep op Azure Stack Hub die de AKS Engine-helper-VM en gerelateerde resources bevat:
Notitie
Als u de AKS-engine moet implementeren in een niet-verbonden omgeving met air-gaped, bekijkt u Niet verbonden Azure Stack Hub instanties voor meer informatie.
In de volgende stap gebruiken we de zojuist geïmplementeerde AKS Engine-VM om een Kubernetes-cluster te implementeren.
Verbinding maken naar de AKS Engine-helper-VM
Eerst moet u verbinding maken met de eerder gemaakte AKS Engine-helper-VM.
De VM moet een openbaar IP-adres hebben en moet toegankelijk zijn via SSH (poort 22/TCP).
Tip
U kunt een hulpprogramma naar keuze gebruiken, zoals MobaXterm, puTTY of PowerShell in Windows 10 om via SSH verbinding te maken met een Linux-VM.
ssh <username>@<ipaddress>
Voer na het maken van de verbinding de opdracht aks-engine uit. Ga naar Ondersteunde AKS-engineversies voor meer informatie over de AKS-engine en Kubernetes-versies.
Een Kubernetes-cluster implementeren
De AKS Engine-helper-VM zelf heeft nog geen Kubernetes-cluster op onze Azure Stack Hub gemaakt. Het maken van het cluster is de eerste actie die moet worden ondernomen in de AKS Engine-helper-VM.
Het stapsgewijs proces wordt hier beschreven:
Het eindresultaat van de opdracht en de voorbereidingen in de vorige stappen is een volledig uitgerust Kubernetes-cluster dat is geïmplementeerd in de tenantruimte van het aks-engine deploy eerste Azure Stack Hub exemplaar. Het cluster zelf bestaat uit Azure IaaS-onderdelen, zoals VM's, load balancers, VNets, schijven, en meer.
- Azure load balancer (K8s API-eindpunt)
- Werkknooppunten (agentpool)
- Hoofdknooppunten
Het cluster is nu actief en in de volgende stap maken we er verbinding mee.
Verbinding maken aan het Kubernetes-cluster
U kunt nu verbinding maken met het eerder gemaakte Kubernetes-cluster, via SSH (met behulp van de SSH-sleutel die is opgegeven als onderdeel van de implementatie) of via kubectl (aanbevolen). Het Kubernetes-opdrachtregelprogramma kubectl is hier beschikbaar Windows, Linux en macOS. Deze is al vooraf geïnstalleerd en geconfigureerd op de hoofdknooppunten van het cluster:
ssh azureuser@<k8s-master-lb-ip>
Het is niet raadzaam om het hoofd-knooppunt als jumpbox te gebruiken voor beheertaken. De kubectl configuratie wordt opgeslagen in op de .kube/config hoofd-knooppunt(en) en op de AKS Engine-VM. U kunt de configuratie kopiëren naar een beheermachine met verbinding met het Kubernetes-cluster en daar de kubectl opdracht gebruiken. Het .kube/config bestand wordt later ook gebruikt om een serviceverbinding in Azure Pipelines te configureren.
Belangrijk
Houd deze bestanden veilig omdat ze de referenties voor uw Kubernetes-cluster bevatten. Een aanvaller met toegang tot het bestand heeft voldoende informatie om beheerderstoegang tot het bestand te krijgen. Alle acties die worden uitgevoerd met behulp van het eerste .kube/config bestand, worden uitgevoerd met behulp van een clusterbeheerdersaccount.
U kunt nu verschillende opdrachten proberen met kubectl om de status van uw cluster te controleren. Hier volgen voorbeeldopdrachten:
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
Belangrijk
Kubernetes heeft een eigen RBAC-model (Role-based Access Control) waarmee u specifieke roldefinities en rolbindingen kunt maken. Dit is de beste manier om de toegang tot het cluster te beheren in plaats van machtigingen voor clusterbeheerders uit te geven.
Verbinding maken Azure Pipelines naar Kubernetes-clusters
Om Azure Pipelines te verbinden met het zojuist geïmplementeerde Kubernetes-cluster, hebben we het kubeconfig-bestand () nodig, zoals .kube/config uitgelegd in de vorige stap.
- Verbinding maken op een van de hoofdknooppunten van uw Kubernetes-cluster.
- Kopieer de inhoud van het
.kube/configbestand. - Ga naar Azure DevOps > Project Instellingen > Service Connections om een nieuwe Kubernetes-serviceverbinding te maken (gebruik KubeConfig als verificatiemethode)
Belangrijk
Azure Pipelines (of de buildagents) moeten toegang hebben tot de Kubernetes-API. Als er een internetverbinding is tussen Azure Pipelines en het Azure Stack Hub Kubernetes-cluster, moet u een zelf-hostende Build-agent voor Azure Pipelines implementeren.
Wanneer u zelf-hostende agents voor Azure Pipelines implementeert, kunt u implementeren op Azure Stack Hub of op een computer met netwerkconnectiviteit naar alle vereiste beheer eindpunten. Bekijk hier de details:
De sectie overwegingen voor patroonimplementatie (CI/CD) bevat een beslissingsstroom die u helpt te begrijpen of door Microsoft gehoste agents of zelf-gehoste agents moeten worden gebruikt:
In deze voorbeeldoplossing bevat de topologie een zelf-hostende buildagent op elk Azure Stack Hub exemplaar. De agent heeft toegang tot Azure Stack Hub eindpunten voor beheer en de API-eindpunten van het Kubernetes-cluster.
Dit ontwerp voldoet aan een algemene regelgevingsvereiste, waarbij alleen uitgaande verbindingen van de toepassingsoplossing zijn vereist.
Bewaking configureren
U kunt Azure Monitor containers gebruiken om de containers in de oplossing te bewaken. Dit wijst Azure Monitor naar het kubernetes-cluster dat door de AKS-engine is geïmplementeerd op Azure Stack Hub.
Er zijn twee manieren om een Azure Monitor in te stellen in uw cluster. Voor beide manieren moet u een Log Analytics-werkruimte instellen in Azure.
- Methode 1 maakt gebruik van een Helm-grafiek
- Methode 2 als onderdeel van de AKS Engine-clusterspecificatie
In de voorbeeldtopologie wordt Methode 1 gebruikt, waardoor het proces kan worden geautomatiseerd en updates gemakkelijker kunnen worden geïnstalleerd.
Voor de volgende stap hebt u een Azure LogAnalytics-werkruimte (id en sleutel), Helm (versie 3) en kubectl op uw computer nodig.
Helm is een Kubernetes-pakketbeheer, beschikbaar als binair bestand dat wordt uitgevoerd op macOS, Windows en Linux. U kunt deze downloaden via helm.sh. Helm is afhankelijk van het Kubernetes-configuratiebestand dat wordt gebruikt voor de kubectl opdracht:
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
Met deze opdracht wordt de Azure Monitor op uw Kubernetes-cluster geïnstalleerd:
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
De Operations Management Suite-agent (OMS) op uw Kubernetes-cluster verzendt bewakingsgegevens naar uw Azure Log Analytics-werkruimte (met behulp van uitgaande HTTPS). U kunt nu Azure Monitor om meer inzicht te krijgen in uw Kubernetes-clusters op Azure Stack Hub. Dit ontwerp is een krachtige manier om de kracht van analyses te demonstreren die automatisch kunnen worden geïmplementeerd met de clusters van uw toepassing.
Belangrijk
Als Azure Monitor geen Azure Stack Hub-gegevens toont, controleert u of u de instructies voor het toevoegen van een AzureMonitor-Containers-oplossing aan een Azure Log Analytics-werkruimte zorgvuldig hebt gevolgd.
De toepassing implementeren
Voordat u onze voorbeeldtoepassing installeert, is er nog een stap voor het configureren van de op nginx gebaseerde controller voor ingress op ons Kubernetes-cluster. De controller voor binnenverkeer wordt gebruikt als laag 7-load balancer verkeer in ons cluster te leiden op basis van de host, het pad of het protocol. Nginx-ingress is beschikbaar als een Helm-grafiek. Raadpleeg de Helm-grafiek voor gedetailleerde instructies GitHub opslagplaats.
Onze voorbeeldtoepassing is ook verpakt als een Helm-grafiek, zoals de Azure Monitoring Agent in de vorige stap. Daarom is het eenvoudig om de toepassing te implementeren in ons Kubernetes-cluster. U vindt de Helm-grafiekbestanden in de GitHub-repo
De voorbeeldtoepassing is een toepassing met drie lagen, geïmplementeerd in een Kubernetes-cluster op elk van twee Azure Stack Hub exemplaren. De toepassing maakt gebruik van een MongoDB-database. Meer informatie over het repliceren van de gegevens over meerdere exemplaren vindt u in het patroon Gegevens en Storage overwegingen.
Nadat u de Helm-grafiek voor de toepassing hebt geïmplementeerd, ziet u dat alle drie de lagen van uw toepassing worden weergegeven als implementaties en stateful sets (voor de database) met één pod:
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
Aan de kant van de services vindt u de op nginx gebaseerde ingress controller en het openbare IP-adres:
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
Het 'externe IP'-adres is ons 'toepassings-eindpunt'. Zo maken gebruikers verbinding om de toepassing te openen en worden ze ook gebruikt als eindpunt voor onze volgende stap Configureer Traffic Manager.
De toepassing automatisch schalen
U kunt eventueel de horizontale automatische schaalvergroting voor pods configureren om omhoog of omlaag te schalen op basis van bepaalde metrische gegevens, zoals CPU-gebruik. Met de volgende opdracht maakt u een horizontale automatische schaalverificatie voor pods die 1 tot 10 replica's van de Pods onderhoudt die worden beheerd door de implementatie van ratings-web. HPA verhoogt en verlaagt het aantal replica's (via de implementatie) om een gemiddeld CPU-gebruik te handhaven voor alle pods van 80%:
kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10
U kunt de huidige status van automatisch schalen controleren door deze opdracht uit te voeren:
kubectl get hpa
NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE
ratings-web Deployment/ratings-web/scale 0% / 80% 1 10 1 18s
Traffic Manager configureren
Als u verkeer wilt distribueren tussen twee (of meer) implementaties van de toepassing, gebruiken we Azure Traffic Manager. Azure Traffic Manager is een dns-verkeer dat is load balancer in Azure.
Notitie
Traffic Manager gebruikt DNS om clientaanvragen om te leiden naar het meest geschikte service-eindpunt, op basis van een verkeersrouteringsmethode en de status van de eindpunten.
In plaats van Azure Traffic Manager kunt u ook andere globale oplossingen voor taakverdeling gebruiken die on-premises worden gehost. In het voorbeeldscenario gebruiken we Azure Traffic Manager verkeer te verdelen tussen twee exemplaren van onze toepassing. Ze kunnen worden uitgevoerd op Azure Stack Hub exemplaren op dezelfde of verschillende locaties:
In Azure configureren we Traffic Manager naar de twee verschillende exemplaren van onze toepassing:
Zoals u ziet, wijzen de twee eindpunten naar de twee exemplaren van de geïmplementeerde toepassing uit de vorige sectie.
Op dit punt:
- De Kubernetes-infrastructuur is gemaakt, met inbegrip van een controller voor ingressen.
- Clusters zijn geïmplementeerd op twee Azure Stack Hub exemplaren.
- Bewaking is geconfigureerd.
- Azure Traffic Manager wordt het verkeer verdeeld over de twee Azure Stack Hub exemplaren.
- Boven op deze infrastructuur is de voorbeeldtoepassing met drie lagen op een geautomatiseerde manier geïmplementeerd met behulp van Helm-grafieken.
De oplossing moet nu beschikbaar zijn en toegankelijk zijn voor gebruikers.
Er zijn ook enkele operationele overwegingen na de implementatie die het overwegen waard zijn. Deze worden in de volgende twee secties besproken.
Kubernetes bijwerken
Houd rekening met de volgende onderwerpen bij het upgraden van het Kubernetes-cluster:
- Het upgraden van een Kubernetes-cluster is een complexe bewerking op dag 2 die kan worden uitgevoerd met behulp van de AKS-engine. Zie Een Kubernetes-cluster upgradenop Azure Stack Hub voor meer Azure Stack Hub.
- Met de AKS-engine kunt u clusters upgraden naar nieuwere Kubernetes- en basisversies van de besturingssysteemafbeelding. Zie Stappen voor het upgraden naar een nieuwere Kubernetes-versie voor meer informatie.
- U kunt ook alleen de onderliggende knooppunten upgraden naar nieuwere versies van de basisversie van de besturingssysteemafbeelding. Zie Stappen om alleen de besturingssysteemafbeelding bij te upgraden voor meer informatie.
Nieuwere basisbesturingssysteemafbeeldingen bevatten beveiligings- en kernelupdates. Het is de verantwoordelijkheid van de clusteroperator om de beschikbaarheid van nieuwere Kubernetes-versies en besturingssysteemafbeeldingen te bewaken. De operator moet deze upgrades plannen en uitvoeren met behulp van de AKS-engine. De basis-os-afbeeldingen moeten worden gedownload van de Azure Stack Hub Marketplace door de Azure Stack Hub Operator.
Kubernetes schalen
Schalen is een andere dag 2-bewerking die kan worden orkestreerd met behulp van de AKS-engine.
Met de schaalopdracht wordt uw clusterconfiguratiebestand (apimodel.json) in de uitvoermap opnieuw gebruikt als invoer voor een Azure Resource Manager implementatie. De AKS-engine voert de schaalbewerking uit op een specifieke agentpool. Wanneer de schaalbewerking is voltooid, werkt de AKS-engine de clusterdefinitie bij in hetzelfde bestand apimodel.json. De clusterdefinitie weerspiegelt het aantal nieuwe knooppunt om de bijgewerkte, huidige clusterconfiguratie weer te geven.
Volgende stappen
- Meer informatie over ontwerpoverwegingen voor hybride apps.
- Bekijk en stel verbeteringen voor de code voor dit voorbeeld op GitHub.