Kubernetes-clusterpatroon met hoge beschikbaarheid

In dit artikel wordt beschreven hoe u een maximaal beschikbare Kubernetes-infrastructuur kunt ontwerpen en gebruiken met behulp van Azure Kubernetes Service (AKS) Engine op Azure Stack Hub. Dit scenario is gebruikelijk voor organisaties met kritieke workloads in zeer beperkte en gereguleerde omgevingen. Organisaties in domeinen zoals financiën, defensie en overheid.

Context en probleem

Veel organisaties ontwikkelen cloudeigen oplossingen die gebruikmaken van state-of-the-art services en technologieën zoals Kubernetes. Hoewel Azure datacenters biedt in de meeste regio's van de wereld, zijn er soms edge-use cases en scenario's waarin bedrijfskritieke toepassingen op een specifieke locatie moeten worden uitgevoerd. Overwegingen zijn onder andere:

• Locatiegevoeligheid
• Latentie tussen de toepassing en on-premises systemen
• Bandbreedtebehoud
• Connectiviteit
• Wettelijke of wettelijke vereisten

Azure, in combinatie met Azure Stack Hub, lost de meeste van deze problemen op. Hieronder vindt u een breed scala aan opties, beslissingen en overwegingen voor een succesvolle implementatie van Kubernetes die wordt uitgevoerd op Azure Stack Hub.

Oplossing

In dit patroon wordt ervan uitgegaan dat we te maken hebben met een strikte set beperkingen. De toepassing moet on-premises worden uitgevoerd en alle persoonlijke gegevens mogen geen openbare cloudservices bereiken. Bewakings- en andere niet-PII-gegevens kunnen naar Azure worden verzonden en daar worden verwerkt. Externe services, zoals een openbaar Container Registry of andere, kunnen worden geopend, maar kunnen worden gefilterd via een firewall of proxyserver.

De voorbeeldtoepassing die hier wordt weergegeven, is ontworpen om waar mogelijk kubernetes-oplossingen te gebruiken. Dit ontwerp voorkomt vergrendeling van leveranciers in plaats van platformeigen services te gebruiken. De toepassing gebruikt bijvoorbeeld een zelf-hostende Back-end van de MongoDB-database in plaats van een PaaS-service of een externe databaseservice. Zie het leertraject Inleiding tot Kubernetes in Azure voor meer informatie.

In het voorgaande diagram ziet u de toepassingsarchitectuur van de voorbeeldtoepassing die wordt uitgevoerd op Kubernetes in Azure Stack Hub. De app bestaat uit verschillende onderdelen, waaronder:

1. Een Kubernetes-cluster op basis van een AKS-engine in Azure Stack Hub.
2. cert-manager, dat een reeks hulpprogramma's biedt voor certificaatbeheer in Kubernetes, wordt gebruikt om automatisch certificaten aan te vragen bij Let's Encrypt.
3. Een Kubernetes-naamruimte met de toepassingsonderdelen voor de front-end (ratings-web), API (ratings-api) en database (ratings-mongodb).
4. De controller voor inkomend verkeer die HTTP/HTTPS-verkeer routeert naar eindpunten binnen het Kubernetes-cluster.

De voorbeeldtoepassing wordt gebruikt om de toepassingsarchitectuur te illustreren. Alle onderdelen zijn voorbeelden. De architectuur bevat slechts één toepassingsimplementatie. Om hoge beschikbaarheid (HA) te bereiken, voeren we de implementatie ten minste twee keer uit op twee verschillende Azure Stack Hub-exemplaren. Deze kunnen op dezelfde locatie of op twee (of meer) verschillende sites worden uitgevoerd:

Services zoals Azure Container Registry, Azure Monitor en andere worden buiten Azure Stack Hub gehost in Azure of on-premises. Dit hybride ontwerp beschermt de oplossing tegen storingen van één Azure Stack Hub-exemplaar.

Onderdelen

De algehele architectuur bestaat uit de volgende onderdelen:

Azure Stack Hub is een uitbreiding van Azure waarmee workloads kunnen worden uitgevoerd in een on-premises omgeving door Azure-services te bieden in uw datacenter. Ga naar Overzicht van Azure Stack Hub voor meer informatie.

Azure Kubernetes Service Engine (AKS Engine) is de engine achter het beheerde Kubernetes-serviceaanbod, Azure Kubernetes Service (AKS), dat momenteel beschikbaar is in Azure. Voor Azure Stack Hub kan de AKS-engine volledig functionele, zelfbeheerde Kubernetes-clusters implementeren, schalen en upgraden met behulp van de IaaS-mogelijkheden van Azure Stack Hub. Ga naar Overzicht van AKS-engine voor meer informatie.

Ga naar Bekende problemen en beperkingen voor meer informatie over de verschillen tussen de AKS-engine in Azure en de AKS-engine in Azure Stack Hub.

Azure Virtual Network (VNet) wordt gebruikt om de netwerkinfrastructuur op elke Azure Stack Hub te bieden voor de Virtual Machines (VM's) die als host fungeren voor de Kubernetes-clusterinfrastructuur.

Azure Load Balancer wordt gebruikt voor het Kubernetes API-eindpunt en de Nginx-ingangscontroller. De load balancer routeert extern verkeer (bijvoorbeeld internet) naar knooppunten en VM's die een specifieke service aanbieden.

Azure Container Registry (ACR) wordt gebruikt voor het opslaan van persoonlijke Docker-installatiekopieën en Helm-grafieken, die in het cluster worden geïmplementeerd. De AKS-engine kan worden geverifieerd met het Container Registry met behulp van een Azure AD-identiteit. Voor Kubernetes is geen ACR vereist. U kunt andere containerregisters gebruiken, zoals Docker Hub.

Azure-opslagplaatsen is een set hulpprogramma's voor versiebeheer die u kunt gebruiken om uw code te beheren. U kunt ook GitHub of andere op Git gebaseerde opslagplaatsen gebruiken. Ga naar Overzicht van Azure-opslagplaatsen voor meer informatie.

Azure Pipelines maakt deel uit van Azure DevOps Services en voert geautomatiseerde builds, tests en implementaties uit. U kunt ook CI/CD-oplossingen van derden gebruiken, zoals Jenkins. Ga naar Overzicht van Azure Pipeline voor meer informatie.

Met Azure Monitor worden metrische gegevens en logboeken verzameld en opgeslagen, waaronder metrische platformgegevens voor de Azure-services in de oplossing en toepassingstelemetrie. Gebruik deze gegevens om de toepassing te bewaken, waarschuwingen en dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren. Azure Monitor kan worden geïntegreerd met Kubernetes om metrische gegevens te verzamelen van controllers, knooppunten en containers, evenals containerlogboeken en hoofdknooppuntlogboeken. Ga naar Overzicht van Azure Monitor voor meer informatie.

Azure Traffic Manager is een load balancer op basis van DNS-verkeer waarmee u verkeer optimaal kunt distribueren naar services in verschillende Azure-regio's of Azure Stack Hub-implementaties. Traffic Manager biedt ook hoge beschikbaarheid en reactiesnelheid. De toepassingseindpunten moeten toegankelijk zijn van buitenaf. Er zijn ook andere on-premises oplossingen beschikbaar.

Kubernetes Ingress Controller maakt HTTP(S)-routes beschikbaar voor services in een Kubernetes-cluster. Nginx of een geschikte ingangscontroller kan voor dit doel worden gebruikt.

Helm is een pakketbeheerder voor kubernetes-implementatie en biedt een manier om verschillende Kubernetes-objecten, zoals Implementaties, Services en Geheimen, te bundelen in één 'grafiek'. U kunt een grafiekobject publiceren, implementeren, beheren en bijwerken. Azure Container Registry kan worden gebruikt als opslagplaats voor het opslaan van verpakte Helm-grafieken.

Overwegingen bij het ontwerpen

Dit patroon volgt een aantal overwegingen op hoog niveau die in de volgende secties van dit artikel uitgebreider worden beschreven:

• De toepassing maakt gebruik van systeemeigen Kubernetes-oplossingen om vergrendeling van leveranciers te voorkomen.
• De toepassing maakt gebruik van een microservicearchitectuur.
• Azure Stack Hub heeft geen inkomend verkeer nodig, maar staat uitgaande internetverbinding toe.

Deze aanbevolen procedures zijn ook van toepassing op workloads en scenario's in de praktijk.

Schaalbaarheidsoverwegingen

Schaalbaarheid is belangrijk om gebruikers consistente, betrouwbare en goed presterende toegang tot de toepassing te bieden.

Het voorbeeldscenario heeft betrekking op schaalbaarheid op meerdere lagen van de toepassingsstack. Hier volgt een overzicht op hoog niveau van de verschillende lagen:

Architectuurniveau	Van invloed	Hoe?
Toepassing	Toepassing	Horizontaal schalen op basis van het aantal pods/replica's/Container Instances*
Cluster	Kubernetes-cluster	Aantal knooppunten (tussen 1 en 50), VM-SKU-grootten en knooppuntgroepen (AKS-engine in Azure Stack Hub ondersteunt momenteel slechts één knooppuntgroep); met behulp van de schaalopdracht van de AKS-engine (handmatig)
Infrastructuur	Azure Stack Hub	Aantal knooppunten, capaciteit en schaaleenheden binnen een Azure Stack Hub-implementatie

* Met behulp van de horizontale automatische schaalaanpassing van pods van Kubernetes (HPA); geautomatiseerd schalen op basis van metrische gegevens of verticaal schalen door het aanpassen van de grootte van de containerinstanties (cpu/geheugen).

Azure Stack Hub (infrastructuurniveau)

De Azure Stack Hub-infrastructuur vormt de basis van deze implementatie, omdat Azure Stack Hub wordt uitgevoerd op fysieke hardware in een datacenter. Wanneer u uw Hub-hardware selecteert, moet u keuzes maken voor CPU, geheugendichtheid, opslagconfiguratie en aantal servers. Bekijk de volgende resources voor meer informatie over de schaalbaarheid van Azure Stack Hub:

• Overzicht van capaciteitsplanning voor Azure Stack Hub
• Extra schaaleenheidknooppunten toevoegen in Azure Stack Hub

Kubernetes-cluster (clusterniveau)

Het Kubernetes-cluster zelf bestaat uit en is gebouwd op Azure (Stack) IaaS-onderdelen, waaronder reken-, opslag- en netwerkresources. Kubernetes-oplossingen hebben betrekking op hoofd- en werkknooppunten, die als VM's in Azure (en Azure Stack Hub) worden geïmplementeerd.

• Besturingsvlakknooppunten (master) bieden de belangrijkste Kubernetes-services en indeling van toepassingsworkloads.
• Werkknooppunten (werkrol ) voeren uw toepassingsworkloads uit.

Bij het selecteren van VM-grootten voor de eerste implementatie zijn er verschillende overwegingen:

• Kosten : houd bij het plannen van uw werkknooppunten rekening met de totale kosten per VM die u maakt. Als uw toepassingsworkloads bijvoorbeeld beperkte resources vereisen, moet u van plan zijn om kleinere VM's te implementeren. Azure Stack Hub, net als Azure, wordt normaal gesproken gefactureerd op basis van verbruik. Daarom is het op de juiste manier aanpassen van de grootte van de VM's voor Kubernetes-rollen van cruciaal belang voor het optimaliseren van de verbruikskosten.

• Schaalbaarheid : schaalbaarheid van het cluster wordt bereikt door het aantal hoofd- en werkknooppunten in en uit te schalen of door extra knooppuntgroepen toe te voegen (momenteel niet beschikbaar in Azure Stack Hub). Het schalen van het cluster kan worden uitgevoerd op basis van prestatiegegevens die worden verzameld met behulp van Container Insights (Azure Monitor + Log Analytics).

  Als uw toepassing meer (of minder) resources nodig heeft, kunt u uw huidige knooppunten horizontaal uitschalen (tussen 1 en 50 knooppunten). Als u meer dan 50 knooppunten nodig hebt, kunt u een extra cluster maken in een afzonderlijk abonnement. U kunt de werkelijke VM's niet verticaal omhoog schalen naar een andere VM-grootte zonder het cluster opnieuw te implementeren.

  Schalen wordt handmatig uitgevoerd met behulp van de AKS Engine-helper-VM die in eerste instantie is gebruikt om het Kubernetes-cluster te implementeren. Zie Kubernetes-clusters schalen voor meer informatie

• Quota: houd rekening met de quota die u hebt geconfigureerd bij het plannen van een AKS-implementatie op uw Azure Stack Hub. Zorg ervoor dat voor elk abonnement de juiste abonnementen en de quota zijn geconfigureerd. Het abonnement moet geschikt zijn voor de hoeveelheid rekenkracht, opslag en andere services die nodig zijn voor uw clusters wanneer ze worden uitgeschaald.

• Toepassingsworkloads: raadpleeg de concepten clusters en workloads in het document Kubernetes-kernconcepten voor Azure Kubernetes Service. Dit artikel helpt u bij het bepalen van de juiste VM-grootte op basis van de reken- en geheugenbehoeften van uw toepassing.

Toepassing (toepassingsniveau)

Op de toepassingslaag gebruiken we Kubernetes Horizontal Pod AutoScaler (HPA). HPA kan het aantal replica's (pod/Container Instances) in onze implementatie verhogen of verlagen op basis van verschillende metrische gegevens (zoals CPU-gebruik).

Een andere optie is om containerinstanties verticaal te schalen. Dit kan worden bereikt door de hoeveelheid CPU en geheugen die is aangevraagd en beschikbaar is voor een specifieke implementatie te wijzigen. Zie Resources voor containers beheren op kubernetes.io voor meer informatie.

Overwegingen voor netwerken en connectiviteit

Netwerken en connectiviteit zijn ook van invloed op de drie eerder genoemde lagen voor Kubernetes in Azure Stack Hub. In de volgende tabel ziet u de lagen en de services die ze bevatten:

Laag	Van invloed	Wat?
Toepassing	Toepassing	Hoe is de toepassing toegankelijk? Wordt het blootgesteld aan internet?
Cluster	Kubernetes-cluster	Kubernetes-API, AKS Engine VM, containerinstallatiekopieën ophalen (uitgaand), bewakingsgegevens en telemetrie verzenden (uitgaand)
Infrastructuur	Azure Stack Hub	Toegankelijkheid van de Azure Stack Hub-beheereindpunten, zoals de portal en Azure Resource Manager-eindpunten.

Toepassing

Voor de toepassingslaag is de belangrijkste overweging of de toepassing beschikbaar is en toegankelijk is via internet. Vanuit het perspectief van Kubernetes betekent internettoegankelijkheid het beschikbaar maken van een implementatie of pod met behulp van een Kubernetes-service of een toegangscontroller.

Het beschikbaar maken van een toepassing met behulp van een openbaar IP-adres via een Load Balancer of een toegangscontroller betekent niet dat de toepassing nu toegankelijk is via internet. Het is mogelijk dat Azure Stack Hub een openbaar IP-adres heeft dat alleen zichtbaar is op het lokale intranet. Niet alle openbare IP-adressen zijn echt op internet gericht.

In het vorige blok wordt rekening gehouden met inkomend verkeer naar de toepassing. Een ander onderwerp dat moet worden overwogen voor een geslaagde Kubernetes-implementatie is uitgaand/uitgaand verkeer. Hier volgen enkele gebruiksvoorbeelden waarvoor uitgaand verkeer is vereist:

• Containerinstallatiekopieën ophalen die zijn opgeslagen in DockerHub of Azure Container Registry
• Helm-grafieken ophalen
• Application Insights-gegevens (of andere bewakingsgegevens) verzenden

Sommige bedrijfsomgevingen vereisen mogelijk het gebruik van transparante of niet-transparante proxyservers. Deze servers vereisen een specifieke configuratie op verschillende onderdelen van ons cluster. De documentatie van de AKS-engine bevat verschillende details over het gebruik van netwerkproxy's. Zie AKS-engine en proxyservers voor meer informatie

Ten slotte moet verkeer tussen clusters stromen tussen Azure Stack Hub-exemplaren. De voorbeeldimplementatie bestaat uit afzonderlijke Kubernetes-clusters die worden uitgevoerd op afzonderlijke Azure Stack Hub-exemplaren. Verkeer ertussen, zoals het replicatieverkeer tussen twee databases, is 'extern verkeer'. Extern verkeer moet worden gerouteerd via een site-naar-site-VPN of openbare IP-adressen van Azure Stack Hub om Kubernetes te verbinden op twee Azure Stack Hub-exemplaren:

Cluster

Het Kubernetes-cluster hoeft niet noodzakelijkerwijs toegankelijk te zijn via internet. Het relevante onderdeel is de Kubernetes-API die wordt gebruikt om een cluster te beheren, bijvoorbeeld met behulp van kubectl. Het Kubernetes API-eindpunt moet toegankelijk zijn voor iedereen die het cluster beheert of er toepassingen en services op implementeert. Dit onderwerp wordt uitgebreider behandeld vanuit devOps-perspectief in de sectie Overwegingen voor implementatie (CI/CD) hieronder.

Op clusterniveau zijn er ook enkele overwegingen met betrekking tot uitgaand verkeer:

• Knooppuntupdates (voor Ubuntu)
• Bewakingsgegevens (verzonden naar Azure LogAnalytics)
• Andere agents die uitgaand verkeer vereisen (specifiek voor de omgeving van elke implementatie)

Voordat u uw Kubernetes-cluster implementeert met behulp van de AKS-engine, moet u het uiteindelijke netwerkontwerp plannen. In plaats van een toegewezen Virtual Network te maken, kan het efficiënter zijn om een cluster in een bestaand netwerk te implementeren. U kunt bijvoorbeeld gebruikmaken van een bestaande site-naar-site-VPN-verbinding die al is geconfigureerd in uw Azure Stack Hub-omgeving.

Infrastructuur

Infrastructuur verwijst naar toegang tot de Beheereindpunten van Azure Stack Hub. Eindpunten omvatten de tenant- en beheerportals en de Azure Resource Manager-beheerders- en tenanteindpunten. Deze eindpunten zijn vereist voor het uitvoeren van Azure Stack Hub en de bijbehorende kernservices.

Overwegingen voor gegevens en opslag

Er worden twee exemplaren van onze toepassing geïmplementeerd, op twee afzonderlijke Kubernetes-clusters, in twee Azure Stack Hub-exemplaren. Voor dit ontwerp moeten we nadenken over het repliceren en synchroniseren van gegevens tussen de twee.

Met Azure hebben we de ingebouwde mogelijkheid om opslag te repliceren in meerdere regio's en zones in de cloud. Momenteel zijn er met Azure Stack Hub geen systeemeigen manieren om opslag te repliceren naar twee verschillende Azure Stack Hub-exemplaren. Ze vormen twee onafhankelijke clouds zonder overkoepelende manier om ze als een set te beheren. Bij het plannen van tolerantie van toepassingen die in Azure Stack Hub worden uitgevoerd, moet u rekening houden met deze onafhankelijkheid in het ontwerp en de implementaties van uw toepassing.

In de meeste gevallen is opslagreplicatie niet nodig voor een tolerante en maximaal beschikbare toepassing die is geïmplementeerd op AKS. Maar u moet rekening houden met onafhankelijke opslag per Azure Stack Hub-exemplaar in uw toepassingsontwerp. Als dit ontwerp een probleem of wegblok is voor het implementeren van de oplossing in Azure Stack Hub, zijn er mogelijke oplossingen van Microsoft partners die opslagbijlagen bieden. Opslagbijlagen bieden een oplossing voor opslagreplicatie voor meerdere Azure Stack Hubs en Azure. Zie partneroplossingen voor meer informatie.

In onze architectuur is rekening gehouden met deze lagen:

Configuratie

De configuratie omvat de configuratie van Azure Stack Hub, AKS Engine en het Kubernetes-cluster zelf. De configuratie moet zoveel mogelijk worden geautomatiseerd en opgeslagen als Infrastructure-as-Code in een versiebeheersysteem op basis van Git, zoals Azure DevOps of GitHub. Deze instellingen kunnen niet eenvoudig worden gesynchroniseerd tussen meerdere implementaties. Daarom raden we u aan om configuratie van buitenaf op te slaan en toe te passen en DevOps-pijplijn te gebruiken.

Toepassing

De toepassing moet worden opgeslagen in een Git-opslagplaats. Wanneer er een nieuwe implementatie, wijzigingen in de toepassing of herstel na noodgevallen zijn, kan deze eenvoudig worden geïmplementeerd met behulp van Azure Pipelines.

Gegevens

Gegevens zijn de belangrijkste overweging in de meeste toepassingsontwerpen. Toepassingsgegevens moeten gesynchroniseerd blijven tussen de verschillende exemplaren van de toepassing. Gegevens hebben ook een strategie voor back-up en herstel na noodgevallen nodig als er een storing is.

Het bereiken van dit ontwerp is sterk afhankelijk van technologische keuzes. Hier volgen enkele voorbeelden van oplossingen voor het implementeren van een database op een manier met hoge beschikbaarheid in Azure Stack Hub:

• Een SQL Server 2016-beschikbaarheidsgroep implementeren in Azure en Azure Stack Hub
• Een MongoDB-oplossing met hoge beschikbaarheid implementeren in Azure en Azure Stack Hub

Overwegingen bij het werken met gegevens op meerdere locaties is een nog complexere overweging voor een maximaal beschikbare en flexibele oplossing. Overweeg het volgende:

• Latentie en netwerkconnectiviteit tussen Azure Stack Hubs.
• Beschikbaarheid van identiteiten voor services en machtigingen. Elk Azure Stack Hub-exemplaar kan worden geïntegreerd met een externe map. Tijdens de implementatie kiest u ervoor om Azure Active Directory (Azure AD) of Active Directory Federation Services (ADFS) te gebruiken. Als zodanig is het mogelijk om één identiteit te gebruiken die kan communiceren met meerdere onafhankelijke Azure Stack Hub-exemplaren.

Bedrijfscontinuïteit en herstel na noodgevallen

Bedrijfscontinuïteit en herstel na noodgevallen (BCDR) is een belangrijk onderwerp in zowel Azure Stack Hub als Azure. Het belangrijkste verschil is dat in Azure Stack Hub de operator het hele BCDR-proces moet beheren. In Azure worden onderdelen van BCDR automatisch beheerd door Microsoft.

BCDR is van invloed op dezelfde gebieden die worden genoemd in de vorige sectie Overwegingen voor gegevens en opslag:

• Infrastructuur/configuratie
• Beschikbaarheid van toepassingen
• Toepassingsgegevens

En zoals vermeld in de vorige sectie, zijn deze gebieden de verantwoordelijkheid van de Azure Stack Hub-operator en kunnen deze per organisatie verschillen. Plan BCDR op basis van uw beschikbare hulpprogramma's en processen.

Infrastructuur en configuratie

In deze sectie worden de fysieke en logische infrastructuur en de configuratie van Azure Stack Hub behandeld. Het behandelt acties in de beheer- en tenantruimten.

De Azure Stack Hub-operator (of beheerder) is verantwoordelijk voor het onderhoud van de Azure Stack Hub-exemplaren. Inclusief onderdelen zoals het netwerk, de opslag, de identiteit en andere onderwerpen die buiten het bereik van dit artikel vallen. Zie de volgende resources voor meer informatie over de specifieke kenmerken van Azure Stack Hub-bewerkingen:

• Gegevens herstellen in Azure Stack Hub met de Infrastructure Backup Service
• Back-up voor Azure Stack Hub inschakelen vanuit de beheerdersportal
• Herstellen van onherstelbaar gegevensverlies
• Aanbevolen procedures voor de service Infrastructure Backup

Azure Stack Hub is het platform en de infrastructuur waarop Kubernetes-toepassingen worden geïmplementeerd. De eigenaar van de toepassing voor de Kubernetes-toepassing is een gebruiker van Azure Stack Hub, met toegang verleend voor het implementeren van de toepassingsinfrastructuur die nodig is voor de oplossing. Toepassingsinfrastructuur betekent in dit geval het Kubernetes-cluster, geïmplementeerd met behulp van de AKS-engine en de bijbehorende services. Deze onderdelen worden geïmplementeerd in Azure Stack Hub, beperkt door een Azure Stack Hub-aanbieding. Zorg ervoor dat de aanbieding die is geaccepteerd door de eigenaar van de Kubernetes-toepassing voldoende capaciteit heeft (uitgedrukt in Azure Stack Hub-quota) om de hele oplossing te implementeren. Zoals aanbevolen in de vorige sectie, moet de implementatie van de toepassing worden geautomatiseerd met behulp van Infrastructure-as-Code en implementatiepijplijnen zoals Azure DevOps Azure Pipelines.

Zie Overzicht van Azure Stack Hub-services, -abonnementen, -aanbiedingen en -abonnementen voor meer informatie over azure Stack Hub-aanbiedingen en -quota

Het is belangrijk om de configuratie van de AKS-engine veilig op te slaan en op te slaan, inclusief de uitvoer. Deze bestanden bevatten vertrouwelijke informatie die wordt gebruikt voor toegang tot het Kubernetes-cluster, dus het moet worden beschermd tegen blootstelling aan niet-beheerders.

Beschikbaarheid van toepassingen

De toepassing mag niet afhankelijk zijn van back-ups van een geïmplementeerd exemplaar. Als standaardprocedure implementeert u de toepassing volledig opnieuw volgens infrastructure-as-code-patronen. Implementeer bijvoorbeeld opnieuw met behulp van Azure DevOps Azure Pipelines. De BCDR-procedure moet betrekking hebben op het opnieuw implementeren van de toepassing naar hetzelfde of een ander Kubernetes-cluster.

Toepassingsgegevens

Toepassingsgegevens zijn het kritieke onderdeel om gegevensverlies tot een minimum te beperken. In de vorige sectie zijn technieken beschreven voor het repliceren en synchroniseren van gegevens tussen twee (of meer) exemplaren van de toepassing. Afhankelijk van de database-infrastructuur (MySQL, MongoDB, MSSQL of andere) die wordt gebruikt om de gegevens op te slaan, zijn er verschillende database-beschikbaarheids- en back-uptechnieken waaruit u kunt kiezen.

De aanbevolen manieren om integriteit te bereiken, zijn door een van de volgende manieren te gebruiken:

• Een systeemeigen back-upoplossing voor de specifieke database.
• Een back-upoplossing die officieel ondersteuning biedt voor back-up en herstel van het databasetype dat door uw toepassing wordt gebruikt.

Belangrijk

Sla uw back-upgegevens niet op hetzelfde Azure Stack Hub-exemplaar op waar uw toepassingsgegevens zich bevinden. Een volledige storing van het Azure Stack Hub-exemplaar zou ook uw back-ups in gevaar kunnen komen.

Beschikbaarheidsoverwegingen

Kubernetes op Azure Stack Hub geïmplementeerd via AKS Engine is geen beheerde service. Het is een geautomatiseerde implementatie en configuratie van een Kubernetes-cluster met behulp van Azure Infrastructure-as-a-Service (IaaS). Als zodanig biedt het dezelfde beschikbaarheid als de onderliggende infrastructuur.

Azure Stack Hub-infrastructuur is al bestand tegen fouten en biedt mogelijkheden zoals beschikbaarheidssets voor het distribueren van onderdelen over meerdere fout- en updatedomeinen. Maar de onderliggende technologie (failoverclustering) ondervindt nog steeds enige downtime voor VM's op een beïnvloede fysieke server, als er een hardwarefout optreedt.

Het is een goede gewoonte om uw Kubernetes-productiecluster en de workload te implementeren naar twee (of meer) clusters. Deze clusters moeten worden gehost op verschillende locaties of datacenters en technologieën zoals Azure Traffic Manager gebruiken om gebruikers te routeren op basis van de reactietijd van het cluster of op basis van geografie.

Klanten met één Kubernetes-cluster maken doorgaans verbinding met het service-IP-adres of de DNS-naam van een bepaalde toepassing. In een implementatie met meerdere clusters moeten klanten verbinding maken met een Traffic Manager DNS-naam die verwijst naar de services/inkomend verkeer in elk Kubernetes-cluster.

Notitie

Dit patroon is ook een best practice voor (beheerde) AKS-clusters in Azure.

Het Kubernetes-cluster zelf, geïmplementeerd via de AKS-engine, moet bestaan uit ten minste drie hoofdknooppunten en twee werkknooppunten.

Identiteits- en beveiligingsoverwegingen

Identiteit en beveiliging zijn belangrijke onderwerpen. Met name wanneer de oplossing onafhankelijke Azure Stack Hub-exemplaren omvat. Kubernetes en Azure (inclusief Azure Stack Hub) hebben beide afzonderlijke mechanismen voor op rollen gebaseerd toegangsbeheer (RBAC):

• Azure RBAC beheert de toegang tot resources in Azure (en Azure Stack Hub), inclusief de mogelijkheid om nieuwe Azure-resources te maken. Machtigingen kunnen worden toegewezen aan gebruikers, groepen of service-principals. (Een service-principal is een beveiligingsidentiteit die wordt gebruikt door toepassingen.)
• Kubernetes RBAC beheert machtigingen voor de Kubernetes-API. Het maken van pods en het weergeven van pods zijn bijvoorbeeld acties die kunnen worden geautoriseerd (of geweigerd) voor een gebruiker via RBAC. Als u Kubernetes-machtigingen wilt toewijzen aan gebruikers, maakt u rollen en rolbindingen.

Azure Stack Hub-identiteit en RBAC

Azure Stack Hub biedt twee opties voor id-providers. De provider die u gebruikt, is afhankelijk van de omgeving en of deze wordt uitgevoerd in een verbonden of niet-verbonden omgeving:

• Azure AD: kan alleen worden gebruikt in een verbonden omgeving.
• ADFS naar een traditioneel Active Directory-forest: kan worden gebruikt in zowel een verbonden als niet-verbonden omgeving.

De id-provider beheert gebruikers en groepen, inclusief verificatie en autorisatie voor toegang tot resources. Toegang kan worden verleend aan Azure Stack Hub-resources, zoals abonnementen, resourcegroepen en afzonderlijke resources, zoals VM's of load balancers. Als u een consistent toegangsmodel wilt hebben, kunt u overwegen om dezelfde groepen (direct of geneste) te gebruiken voor alle Azure Stack Hubs. Hier volgt een configuratievoorbeeld:

Het voorbeeld bevat een toegewezen groep (met behulp van AAD of ADFS) voor een specifiek doel. Als u bijvoorbeeld inzendermachtigingen wilt opgeven voor de resourcegroep die onze Kubernetes-clusterinfrastructuur bevat op een specifiek Azure Stack Hub-exemplaar (hier 'Seattle K8s Cluster Contributor'). Deze groepen worden vervolgens genest in een algemene groep die de 'subgroepen' voor elke Azure Stack Hub bevat.

De voorbeeldgebruiker heeft nu inzendermachtigingen voor beide resourcegroepen die de volledige set Kubernetes-infrastructuurresources bevatten. De gebruiker heeft toegang tot resources op beide Azure Stack Hub-exemplaren, omdat de exemplaren dezelfde id-provider delen.

Belangrijk

Deze machtigingen zijn alleen van invloed op Azure Stack Hub en sommige resources die erop zijn geïmplementeerd. Een gebruiker met dit toegangsniveau kan veel schade aanrichten, maar heeft geen toegang tot de Kubernetes IaaS-VM's of de Kubernetes-API zonder extra toegang tot de Kubernetes-implementatie.

Kubernetes-identiteit en RBAC

Een Kubernetes-cluster gebruikt standaard niet dezelfde id-provider als de onderliggende Azure Stack Hub. De VM's die als host fungeren voor het Kubernetes-cluster, de hoofd- en werkknooppunten, gebruiken de SSH-sleutel die is opgegeven tijdens de implementatie van het cluster. Deze SSH-sleutel is vereist om verbinding te maken met deze knooppunten met behulp van SSH.

De Kubernetes-API (bijvoorbeeld toegankelijk via kubectl) wordt ook beveiligd door serviceaccounts, waaronder een standaardserviceaccount voor clusterbeheerders. De referenties voor dit serviceaccount worden in eerste instantie opgeslagen in het .kube/config bestand op uw Kubernetes-hoofdknooppunten.

Geheimenbeheer en toepassingsreferenties

Voor het opslaan van geheimen, zoals verbindingsreeksen of databasereferenties, zijn er verschillende opties, waaronder:

• Azure Key Vault
• Kubernetes Secrets
• Oplossingen van derden, zoals HashiCorp Vault (uitgevoerd op Kubernetes)

Sla geheimen of referenties niet op in platte tekst in uw configuratiebestanden, toepassingscode of in scripts. En sla ze niet op in een versiebeheersysteem. In plaats daarvan moet de implementatieautomatisering de geheimen naar behoefte ophalen.

Patchen en bijwerken

Het PNU-proces (Patch and Update) in Azure Kubernetes Service is gedeeltelijk geautomatiseerd. Kubernetes-versie-upgrades worden handmatig geactiveerd, terwijl beveiligingsupdates automatisch worden toegepast. Deze updates kunnen beveiligingspatches van het besturingssysteem of kernelupdates bevatten. AKS start deze Linux-knooppunten niet automatisch opnieuw op om het updateproces te voltooien.

Het PNU-proces voor een Kubernetes-cluster dat is geïmplementeerd met behulp van de AKS-engine in Azure Stack Hub, is niet beheerd en is de verantwoordelijkheid van de clusteroperator.

AKS Engine helpt bij de twee belangrijkste taken:

• Upgraden naar een nieuwere kubernetes- en basisversie van de installatiekopieën van het besturingssysteem
• Alleen de basisinstallatiekopieën van het besturingssysteem upgraden

Nieuwere installatiekopieën van het basisbesturingssysteem bevatten de meest recente beveiligingspatches van het besturingssysteem en kernelupdates.

Het mechanisme Voor upgrade zonder toezicht installeert automatisch beveiligingsupdates die worden uitgebracht voordat een nieuwe versie van de basisinstallatiekopieën van het besturingssysteem beschikbaar is in de Azure Stack Hub Marketplace. Upgrade zonder toezicht is standaard ingeschakeld en beveiligingsupdates worden automatisch geïnstalleerd, maar de Kubernetes-clusterknooppunten worden niet opnieuw opgestart. Het opnieuw opstarten van de knooppunten kan worden geautomatiseerd met behulp van de opensource-KUbernetes REboot Daemon (kured)). Kured let op Linux-knooppunten die opnieuw moeten worden opgestart, en verwerkt vervolgens automatisch het opnieuw instellen van actieve pods en het proces voor het opnieuw opstarten van knooppunten.

Overwegingen bij implementatie (CI/CD)

Azure en Azure Stack Hub maken dezelfde Azure Resource Manager REST API's beschikbaar. Deze API's worden net als elke andere Azure-cloud aangepakt (Azure, Azure China 21Vianet, Azure Government). Er kunnen verschillen zijn in API-versies tussen clouds en Azure Stack Hub biedt slechts een subset van services. De beheereindpunt-URI is ook verschillend voor elke cloud en elk exemplaar van Azure Stack Hub.

Afgezien van de subtiele verschillen die worden genoemd, bieden Azure Resource Manager REST API's een consistente manier om te communiceren met zowel Azure als Azure Stack Hub. Hier kan dezelfde set hulpprogramma's worden gebruikt als bij elke andere Azure-cloud. U kunt Azure DevOps, hulpprogramma's zoals Jenkins of PowerShell, gebruiken om services te implementeren en te organiseren in Azure Stack Hub.

Overwegingen

Een van de belangrijkste verschillen als het gaat om implementaties van Azure Stack Hub is de kwestie van internettoegankelijkheid. Internettoegankelijkheid bepaalt of u een Microsoft gehoste of een zelf-hostende buildagent selecteert voor uw CI/CD-taken.

Een zelf-hostende agent kan worden uitgevoerd boven op Azure Stack Hub (als een IaaS-VM) of in een netwerksubnet dat toegang heeft tot Azure Stack Hub. Ga naar Azure Pipelines-agents voor meer informatie over de verschillen.

Met de volgende afbeelding kunt u bepalen of u een zelf-hostende of een Microsoft-gehoste buildagent nodig hebt:

• Zijn de Beheereindpunten van Azure Stack Hub toegankelijk via internet?
  • Ja: We kunnen Azure Pipelines gebruiken met Microsoft-gehoste agents om verbinding te maken met Azure Stack Hub.
  • Nee: we hebben zelf-hostende agents nodig die verbinding kunnen maken met de beheereindpunten van Azure Stack Hub.
• Is ons Kubernetes-cluster toegankelijk via internet?
  • Ja: We kunnen Azure Pipelines gebruiken met Microsoft gehoste agents om rechtstreeks te communiceren met het Kubernetes API-eindpunt.
  • Nee: we hebben zelf-hostende agents nodig die verbinding kunnen maken met het Api-eindpunt van het Kubernetes-cluster.

In scenario's waarin de Beheereindpunten van Azure Stack Hub en De Kubernetes-API toegankelijk zijn via internet, kan de implementatie gebruikmaken van een Microsoft gehoste agent. Deze implementatie resulteert als volgt in een toepassingsarchitectuur:

Als de Azure Resource Manager-eindpunten, Kubernetes-API of beide niet rechtstreeks toegankelijk zijn via internet, kunnen we gebruikmaken van een zelf-hostende buildagent om de pijplijnstappen uit te voeren. Dit ontwerp heeft minder connectiviteit nodig en kan alleen worden geïmplementeerd met on-premises netwerkconnectiviteit met Azure Resource Manager-eindpunten en de Kubernetes-API:

Notitie

Hoe zit het met niet-verbonden scenario's? In scenario's waarin Azure Stack Hub of Kubernetes of beide geen internetgerichte beheereindpunten hebben, is het nog steeds mogelijk om Azure DevOps te gebruiken voor uw implementaties. U kunt een zelf-hostende agentpool (een DevOps-agent die on-premises of op Azure Stack Hub zelf wordt uitgevoerd) of een volledig zelf-hostende Azure DevOps Server on-premises gebruiken. De zelf-hostende agent heeft alleen uitgaande HTTPS-internetverbinding (TCP/443) nodig.

Het patroon kan een Kubernetes-cluster gebruiken (geïmplementeerd en ingedeeld met AKS-engine) op elk Azure Stack Hub-exemplaar. Het bevat een toepassing die bestaat uit een front-end, een middelste laag, back-endservices (bijvoorbeeld MongoDB) en een op nginx gebaseerde ingress-controller. In plaats van een database te gebruiken die wordt gehost op het K8s-cluster, kunt u gebruikmaken van 'externe gegevensarchieven'. Databaseopties zijn onder andere MySQL, SQL Server of elk type database dat buiten Azure Stack Hub of in IaaS wordt gehost. Configuraties zoals deze vallen hier niet binnen het bereik.

Partneroplossingen

Er zijn Microsoft Partner-oplossingen waarmee de mogelijkheden van Azure Stack Hub kunnen worden uitgebreid. Deze oplossingen zijn nuttig gebleken bij implementaties van toepassingen die worden uitgevoerd op Kubernetes-clusters.

Opslag- en gegevensoplossingen

Zoals beschreven in Overwegingen voor gegevens en opslag, heeft Azure Stack Hub momenteel geen systeemeigen oplossing voor het repliceren van opslag tussen meerdere exemplaren. In tegenstelling tot Azure bestaat de mogelijkheid om opslag in meerdere regio's te repliceren niet. In Azure Stack Hub is elk exemplaar een eigen afzonderlijke cloud. Er zijn echter oplossingen beschikbaar bij Microsoft partners die opslagreplicatie in Azure Stack Hubs en Azure mogelijk maken.

SCALITY

Scality biedt opslag op webschaal die sinds 2009 digitale bedrijven heeft aangedreven. De Scality RING, onze door software gedefinieerde opslag, verandert standaard x86-servers in een onbeperkte opslaggroep voor elk type gegevens (bestand en object) op petabyteschaal.

CLOUDIAN

Cloudian vereenvoudigt bedrijfsopslag met onbeperkte schaalbare opslag waarmee enorme gegevenssets worden geconsolideerd in één, eenvoudig te beheren omgeving.

Volgende stappen

Voor meer informatie over concepten die in dit artikel worden geïntroduceerd:

• Schalen in meerdere clouds en geo-gedistribueerde app-patronen in Azure Stack Hub.
• Microservicearchitectuur op Azure Kubernetes Service (AKS).

Wanneer u klaar bent om het voorbeeld van de oplossing te testen, gaat u verder met de implementatiehandleiding voor Kubernetes-clusters met hoge beschikbaarheid. De implementatiehandleiding bevat stapsgewijze instructies voor het implementeren en testen van de onderdelen.