Een Kubernetes-cluster met hoge beschikbaarheid implementeren in Azure Stack Hub
In dit artikel wordt uitgelegd hoe u een maximaal beschikbare Kubernetes-clusteromgeving bouwt, 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 met de AKS Engine Helper-VM
- Een Kubernetes-cluster implementeren
- Verbinding maken met het Kubernetes-cluster
- Azure Pipelines verbinden met Een 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 mogelijk is waarmee u overal hybride apps kunt bouwen en implementeren.
In het artikel Overwegingen bij het ontwerpen van hybride apps worden de pijlers van softwarekwaliteit (plaatsing, schaalbaarheid, beschikbaarheid, tolerantie, beheerbaarheid en beveiliging) voor het ontwerpen, implementeren en gebruiken van hybride apps besproken. De ontwerpoverwegingen helpen bij het optimaliseren van hybride app-ontwerp, waardoor uitdagingen in productieomgevingen worden geminimaliseerd.
Vereisten
Voordat u aan de slag gaat met deze implementatiehandleiding, moet u het volgende doen:
- Raadpleeg het artikel Kubernetes-clusterpatroon met hoge beschikbaarheid .
- Bekijk de inhoud van de bijbehorende 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 machtigingen voor 'inzender'.
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-eindpunten kan bereiken. In deze handleiding wordt beschreven hoe u een nieuwe Linux- (of Windows)VM implementeert in Azure Stack Hub. Deze wordt later gebruikt wanneer de AKS-engine de Kubernetes-clusters implementeert.
Notitie
U kunt ook een bestaande Windows- of Linux-VM gebruiken om een Kubernetes-cluster te implementeren in Azure Stack Hub met behulp van de AKS-engine.
Het stapsgewijze proces en de vereisten voor de AKS-engine worden hier beschreven:
AKS Engine is een hulpprogramma voor het implementeren en gebruiken van (onbeheerde) Kubernetes-clusters (in Azure en Azure Stack Hub).
De details en verschillen van de AKS-engine in 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 bijbehorende GitHub-opslagplaats.
Het resultaat van deze stap is een nieuwe resourcegroep in 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, air-gapped-omgeving, raadpleegt u Verbroken Azure Stack Hub-exemplaren voor meer informatie.
In de volgende stap gebruiken we de zojuist geïmplementeerde VM van de AKS-engine om een Kubernetes-cluster te implementeren.
Verbinding maken met de helper-VM van de AKS-engine
Eerst moet u verbinding maken met de eerder gemaakte helper-VM voor AKS Engine.
De VM moet een openbaar IP-adres hebben en toegankelijk zijn via SSH (poort 22/TCP).
Tip
U kunt een hulpprogramma naar keuze gebruiken, zoals MobaXterm, puTTY of PowerShell in Windows 10 om verbinding te maken met een Linux-VM met behulp van SSH.
ssh <username>@<ipaddress>
Nadat u verbinding hebt gemaakt, voert u de opdracht aks-engineuit. Ga naar Ondersteunde AKS-engineversies voor meer informatie over de AKS Engine- en Kubernetes-versies.
Een Kubernetes-cluster implementeren
De helper-VM van de AKS-engine zelf heeft nog geen Kubernetes-cluster gemaakt op onze Azure Stack Hub. Het maken van het cluster is de eerste actie die moet worden uitgevoerd in de helper-VM van de AKS-engine.
Het stapsgewijze proces wordt hier beschreven:
Het eindresultaat van de aks-engine deploy opdracht en de voorbereidingen in de vorige stappen is een volledig uitgerust Kubernetes-cluster dat is geïmplementeerd in de tenantruimte van het eerste Azure Stack Hub-exemplaar. Het cluster zelf bestaat uit Azure IaaS-onderdelen, zoals VM's, load balancers, VNets, schijven, enzovoort.
- Azure load balancer (K8s API-eindpunt) 2) werkknooppunten (agentpool) 3) hoofdknooppunten
Het cluster is nu actief en in de volgende stap maken we er verbinding mee.
Verbinding maken met 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 voor Windows, Linux en macOS. Het is al vooraf geïnstalleerd en geconfigureerd op de hoofdknooppunten van ons cluster:
ssh azureuser@<k8s-master-lb-ip>
Het wordt afgeraden om het hoofdknooppunt te gebruiken als een jumpbox voor beheertaken. De kubectl configuratie wordt opgeslagen in .kube/config de hoofdknooppunten en op de VM van de AKS-engine. U kunt de configuratie kopiëren naar een beheercomputer met connectiviteit 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 het oorspronkelijke .kube/config bestand, worden uitgevoerd met behulp van een clusterbeheerdersaccount.
U kunt nu verschillende opdrachten proberen om kubectl de status van uw cluster te controleren. Hier volgen voorbeelden van opdrachten:
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 gedetailleerde 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 delen.
Azure Pipelines verbinden met Kubernetes-clusters
Als u Azure Pipelines wilt verbinden met het zojuist geïmplementeerde Kubernetes-cluster, hebben we het bijbehorende kubeconfig-bestand (.kube/config) nodig, zoals uitgelegd in de vorige stap.
- Maak verbinding met een van de hoofdknooppunten van uw Kubernetes-cluster.
- Kopieer de inhoud van het
.kube/configbestand. - Ga naar Azure DevOps > Project Settings > Service Connections om een nieuwe Kubernetes-serviceverbinding te maken (gebruik KubeConfig als verificatiemethode)
Belangrijk
Azure Pipelines (of de bijbehorende buildagents) moeten toegang hebben tot de Kubernetes-API. Als er een internetverbinding is van Azure Pipelines naar het Kubernetes-cluster van Azure Stack Hub, moet u een zelf-hostende Azure Pipelines-buildagent implementeren.
Wanneer u zelf-hostende agents voor Azure Pipelines implementeert, kunt u implementeren op Azure Stack Hub of op een computer met netwerkverbinding met alle vereiste beheereindpunten. Bekijk de details hier:
De sectie overwegingen voor het implementeren van patronen (CI/CD) bevat een beslissingsstroom die u helpt te begrijpen of u door Microsoft gehoste agents of zelf-hostende agents moet gebruiken:
Download een Visio-bestand met alle diagrammen in dit artikel.
In deze voorbeeldoplossing bevat de topologie een zelf-hostende buildagent op elk Azure Stack Hub-exemplaar. De agent heeft toegang tot de Azure Stack Hub Management-eindpunten en de API-eindpunten van het Kubernetes-cluster.
Download een Visio-bestand met alle diagrammen in dit artikel.
Dit ontwerp voldoet aan een algemene wettelijke vereiste, namelijk alleen uitgaande verbindingen van de toepassingsoplossing.
Bewaking configureren
U kunt Azure Monitor voor 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 Azure Monitor in te schakelen op uw cluster. Voor beide manieren moet u een Log Analytics-werkruimte instellen in Azure.
- Methode één maakt gebruik van een Helm-grafiek
- Methode twee als onderdeel van de clusterspecificatie van de AKS-engine
In de voorbeeldtopologie wordt 'Methode 1' gebruikt, waarmee het proces kan worden geautomatiseerd en updates eenvoudiger 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-pakketbeheerder, beschikbaar als een binair bestand dat wordt uitgevoerd op macOS, Windows en Linux. Het kan worden gedownload op 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 installeert u de Azure Monitor-agent op uw Kubernetes-cluster:
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 OMS-agent (Operations Management Suite) in uw Kubernetes-cluster verzendt bewakingsgegevens naar uw Azure Log Analytics-werkruimte (met uitgaande HTTPS). U kunt nu Azure Monitor gebruiken om meer inzicht te krijgen in uw Kubernetes-clusters in 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 weergeeft, moet u ervoor zorgen dat u de instructies voor het toevoegen van AzureMonitor-Containers oplossing aan een Azure Log Analytics-werkruimte zorgvuldig hebt gevolgd.
De toepassing implementeren
Voordat u de voorbeeldtoepassing installeert, moet u nog een stap uitvoeren om de nginx-controller voor inkomend verkeer te configureren op ons Kubernetes-cluster. De controller voor inkomend verkeer wordt gebruikt als load balancer op laag 7 om verkeer in ons cluster te routeren op basis van host, pad of protocol. Nginx-ingress is beschikbaar als een Helm-grafiek. Raadpleeg de GitHub-opslagplaats helmgrafiek voor gedetailleerde instructies.
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 bijbehorende GitHub-opslagplaats
De voorbeeldtoepassing is een toepassing met drie lagen, geïmplementeerd op 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 opslagoverwegingen.
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 controller voor inkomend verkeer en het bijbehorende 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 toepassingseindpunt. Dit is de wijze waarop gebruikers verbinding maken om de toepassing te openen en worden ook gebruikt als het eindpunt voor de volgende stap Traffic Manager configureren.
De toepassing automatisch schalen
U kunt de horizontale schaalaanpassing voor pods desgewenst 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 schaalaanpassing van pods die 1 tot 10 replica's van de pods onderhoudt die worden beheerd door de ratings-webimplementatie. HPA verhoogt en verlaagt het aantal replica's (via de implementatie) om een gemiddeld CPU-gebruik voor alle pods van 80% te behouden:
kubectl autoscale deployment ratings-web --cpu-percent=80 --min=1 --max=10
U kunt de huidige status van automatische schaalaanpassing 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 op DNS gebaseerde load balancer voor verkeer in Azure.
Notitie
Traffic Manager maakt gebruik van 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 te gebruiken, kunt u ook andere globale oplossingen voor taakverdeling gebruiken die on-premises worden gehost. In het voorbeeldscenario gebruiken we Azure Traffic Manager om verkeer te distribueren tussen twee exemplaren van onze toepassing. Ze kunnen worden uitgevoerd op Azure Stack Hub-exemplaren op dezelfde of verschillende locaties:
Download een Visio-bestand met alle diagrammen in dit artikel.
In Azure configureren we Traffic Manager om te verwijzen naar de twee verschillende exemplaren van onze toepassing:
Zoals u ziet, verwijzen de twee eindpunten naar de twee exemplaren van de geïmplementeerde toepassing uit de vorige sectie.
Op dit punt:
- De Kubernetes-infrastructuur is gemaakt, inclusief een toegangscontroller.
- Clusters zijn geïmplementeerd in twee Azure Stack Hub-exemplaren.
- Bewaking is geconfigureerd.
- Met Azure Traffic Manager wordt het verkeer verdeeld over de twee Azure Stack Hub-exemplaren.
- Naast 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 de moeite waard zijn om te bespreken, die in de volgende twee secties worden behandeld.
Kubernetes bijwerken
Houd rekening met de volgende onderwerpen bij het upgraden van het Kubernetes-cluster:
- Het upgraden van een Kubernetes-cluster is een complexe dag 2-bewerking die kan worden uitgevoerd met behulp van de AKS-engine. Zie Een Kubernetes-cluster upgraden in Azure Stack Hub voor meer informatie.
- Met de AKS-engine kunt u clusters upgraden naar nieuwere kubernetes- en basisversies van de installatiekopieën van het besturingssysteem. 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 basisinstallatiekopieën van het besturingssysteem. Zie Stappen om alleen de installatiekopieën van het besturingssysteem bij te werken voor meer informatie.
Nieuwere installatiekopieën van het basisbesturingssysteem bevatten beveiligings- en kernelupdates. Het is de verantwoordelijkheid van de clusteroperator om de beschikbaarheid van nieuwere Kubernetes-versies en besturingssysteeminstallatiekopieën te bewaken. De operator moet deze upgrades plannen en uitvoeren met behulp van de AKS-engine. De basisinstallatiekopieën van het besturingssysteem 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 georganiseerd met behulp van de AKS-engine.
Met de opdracht schalen wordt het clusterconfiguratiebestand (apimodel.json) in de uitvoermap opnieuw gebruikt als invoer voor een nieuwe 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 apimodel.json-bestand. De clusterdefinitie weerspiegelt het aantal nieuwe knooppunten om de bijgewerkte, huidige clusterconfiguratie weer te geven.
Volgende stappen
- Meer informatie over overwegingen bij het ontwerpen van hybride apps.
- Bekijk en stel verbeteringen voor in de code voor dit voorbeeld op GitHub.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor