Overzicht van hoge beschikbaarheid en herstel na noodgevallen voor Azure Kubernetes Service (AKS)

Bij het maken en beheren van toepassingen in de cloud is er altijd een risico op onderbrekingen en rampen. Om bedrijfscontinuïteit (BC) te garanderen, moet u plannen voor hoge beschikbaarheid (HA) en herstel na noodgevallen (DR).

Hoge beschikbaarheid verwijst naar het ontwerp en de implementatie van een systeem of service die zeer betrouwbaar is en minimale downtime ondervindt. Hoge beschikbaarheid is een combinatie van hulpprogramma's, technologieën en processen die ervoor zorgen dat een systeem of service beschikbaar is om de beoogde functie uit te voeren. Hoge beschikbaarheid is een essentieel onderdeel van dr-planning. DR is het proces van herstel na een noodgeval en het herstellen van bedrijfsactiviteiten naar een normale status. DR is een subset van BC, dat het proces is van het onderhouden van bedrijfsfuncties of het snel hervatten ervan in het geval van een grote onderbreking.

Dit artikel bevat enkele aanbevolen procedures voor toepassingen die zijn geïmplementeerd in AKS, maar is in geen enkele zin bedoeld als een volledige lijst met mogelijke oplossingen.

Overzicht van technologie

Een Kubernetes-cluster bestaat uit twee onderdelen:

• Het besturingsvlak, dat de belangrijkste Kubernetes-services en indeling van toepassingsworkloads biedt, en
• De knooppunten, waarop uw toepassingsworkloads worden uitgevoerd.

Wanneer u een AKS-cluster maakt, maakt en configureert het Azure-platform automatisch een besturingsvlak. AKS biedt twee prijscategorieën voor clusterbeheer: de gratis laag en de Standard-laag. Zie de prijscategorieën Gratis en Standard voor AKS-clusterbeheer voor meer informatie.

Het besturingsvlak en de bijbehorende resources bevinden zich alleen in de regio waar u het cluster hebt gemaakt. AKS biedt een besturingsvlak met één tenant met een toegewezen API-server, planner, enzovoort. U definieert het aantal en de grootte van de knooppunten en het Azure-platform configureert de beveiligde communicatie tussen het besturingsvlak en de knooppunten. Interactie met het besturingsvlak vindt plaats via Kubernetes-API's, zoals kubectl of het Kubernetes-dashboard.

Als u uw toepassingen en ondersteunende services wilt uitvoeren, hebt u een Kubernetes-knooppunt nodig. Een AKS-cluster heeft ten minste één knooppunt, een virtuele Azure-machine (VM) waarop de Onderdelen van het Kubernetes-knooppunt en de containerruntime worden uitgevoerd. De Azure VM-grootte voor uw knooppunten definieert CPU's, geheugen, grootte en het beschikbare opslagtype (zoals SSD met hoge prestaties of gewone HDD). Plan de VM en de opslaggrootte om te bepalen of uw toepassingen grote hoeveelheden CPU en geheugen of opslag met hoge prestaties nodig kunnen hebben. In AKS is de VM-installatiekopie voor de knooppunten van uw cluster gebaseerd op Ubuntu Linux, Azure Linux of Windows Server 2022. Wanneer u een AKS-cluster maakt of het aantal knooppunten uitschaalt, maakt en configureert het Azure-platform automatisch het aangevraagde aantal virtuele machines.

Zie Kubernetes-kernconcepten voor AKS voor meer informatie over cluster- en workloadonderdelen in AKS.

Belangrijke aandachtspunten

Regionale en wereldwijde resources

Regionale resources worden ingericht als onderdeel van een implementatiestempel in één Azure-regio. Deze resources delen niets met resources in andere regio's en kunnen onafhankelijk worden verwijderd of gerepliceerd naar andere regio's. Zie Regionale bronnen voor meer informatie.

Globale resources delen de levensduur van het systeem en kunnen wereldwijd beschikbaar zijn binnen de context van een implementatie met meerdere regio's. Zie Globale resources voor meer informatie.

Hersteldoelstellingen

Een volledig plan voor herstel na noodgevallen moet bedrijfsvereisten opgeven voor elk proces dat door de toepassing wordt geïmplementeerd:

• Recovery Point Objective (RPO) is de maximale duur van acceptabel gegevensverlies. RPO wordt gemeten in tijdseenheden, zoals minuten, uren of dagen.
• Recovery Time Objective (RTO) is de maximale duur van acceptabele downtime, waarbij downtime is gedefinieerd door uw specificatie. Als de acceptabele downtime in een noodgeval bijvoorbeeld acht uur is, is de RTO acht uur.

Beschikbaarheidszones

U kunt beschikbaarheidszones gebruiken om uw gegevens over meerdere zones in dezelfde regio te verdelen. Binnen een regio zijn beschikbaarheidszones dicht genoeg om verbindingen met lage latentie met andere beschikbaarheidszones te hebben, maar ze zijn ver genoeg van elkaar om de kans te verkleinen dat meer dan één wordt beïnvloed door lokale storingen of het weer. Zie Aanbevelingen voor meer informatie over het gebruik van beschikbaarheidszones en regio's.

Zonegebonden tolerantie

AKS-clusters zijn bestand tegen zonegebonden fouten. Als een zone mislukt, blijft het cluster actief in de resterende zones. Het besturingsvlak en de knooppunten van het cluster worden verdeeld over de zones en het Azure-platform verwerkt automatisch de distributie van de knooppunten. Zie AKS zonegebonden tolerantie voor meer informatie.

Load balancing

Wereldwijde taakverdeling

Wereldwijde taakverdelingsservices verdelen verkeer over regionale back-ends, clouds of hybride on-premises services. Deze services routeren verkeer van eindgebruikers naar de dichtstbijzijnde beschikbare back-end. Ze reageren ook op wijzigingen in de betrouwbaarheid of prestaties van de service om de beschikbaarheid en prestaties te maximaliseren. De volgende Azure-services bieden globale taakverdeling:

• Azure Front Door
• Azure Traffic Manager
• Azure Load Balancer voor meerdere regio's
• Azure Kubernetes Fleet Manager

Regionale taakverdeling

Regionale taakverdelingsservices verdelen verkeer binnen virtuele netwerken over vm's of zone-redundante service-eindpunten binnen een regio. De volgende Azure-services bieden regionale taakverdeling:

• Azure-belastingsverdeling
• Azure Application Gateway
• Azure-toepassing Gateway voor containers

Waarneembaarheid

U moet gegevens verzamelen van toepassingen en infrastructuur om effectieve bewerkingen en maximale betrouwbaarheid mogelijk te maken. Azure biedt hulpprogramma's waarmee u uw AKS-workloads kunt bewaken en beheren. Zie Waarneembaarheidsresources voor meer informatie.

Definitie van bereik

De uptime van toepassingen wordt belangrijk wanneer u AKS-clusters beheert. Standaard biedt AKS hoge beschikbaarheid met behulp van meerdere knooppunten in een virtuele-machineschaalset, maar deze knooppunten beschermen uw systeem niet tegen een regiofout. Als u uw uptime wilt maximaliseren, plant u de bedrijfscontinuïteit en bereidt u zich voor op herstel na noodgevallen met behulp van de volgende aanbevolen procedures:

• Plan AKS-clusters in meerdere regio's.
• Verkeer routeren over meerdere clusters met behulp van Azure Traffic Manager.
• Gebruik geo-replicatie voor uw containerinstallatiekopieënregisters.
• Plan de toepassingsstatus in meerdere clusters.
• Opslag repliceren in meerdere regio's.

Implementatiemodelimplementaties

Implementatiemodel	Voordelen	Nadelen
Actief-actief	• Geen gegevensverlies of inconsistentie tijdens failover • Hoge tolerantie • Beter gebruik van resources met hogere prestaties	• Complexe implementatie en beheer • Hogere kosten • Vereist een load balancer en vorm van verkeersroutering
Actief-passief	• Eenvoudigere implementatie en beheer • Lagere kosten • Hiervoor is geen load balancer of Traffic Manager vereist	• Potentieel voor gegevensverlies of inconsistentie tijdens failover • Langere hersteltijd en downtime • Ondergebruik van resources
Passief-koud	• Laagste kosten • Vereist geen synchronisatie, replicatie, load balancer of Traffic Manager • Geschikt voor niet-kritieke werkbelastingen met lage prioriteit	• Hoog risico op gegevensverlies of inconsistentie tijdens failover • Langste hersteltijd en downtime • Vereist handmatige tussenkomst om cluster te activeren en back-up te activeren

Implementatiemodel voor actieve hoge beschikbaarheid

In het implementatiemodel voor actieve hoge beschikbaarheid (HA) hebt u twee onafhankelijke AKS-clusters geïmplementeerd in twee verschillende Azure-regio's (meestal gekoppelde regio's, zoals Canada - centraal en Canada - oost of US - oost 2 en US - centraal) die actief verkeer bedienen.

Met deze voorbeeldarchitectuur:

• U implementeert twee AKS-clusters in afzonderlijke Azure-regio's.
• Tijdens normale bewerkingen wordt netwerkverkeer tussen beide regio's gerouteerd. Als één regio niet beschikbaar is, wordt verkeer automatisch gerouteerd naar een regio die zich het dichtst bij de gebruiker bevindt die de aanvraag heeft uitgegeven.
• Er is een geïmplementeerd hub-spoke-paar voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid beheert de firewallregels in de regio's.
• Azure Key Vault wordt ingericht in elke regio om geheimen en sleutels op te slaan.
• Azure Front Door-load balanceert en routeert verkeer naar een regionaal Azure-toepassing Gateway-exemplaar, dat zich vóór elk AKS-cluster bevindt.
• Regionale Log Analytics-exemplaren slaan metrische gegevens en diagnostische logboeken voor regionale netwerken op.
• De containerinstallatiekopieën voor de workload worden opgeslagen in een beheerd containerregister. Eén Azure Container Registry wordt gebruikt voor alle Kubernetes-exemplaren in het cluster. Geo-replicatie voor Azure Container Registry maakt het repliceren van installatiekopieën naar de geselecteerde Azure-regio's mogelijk en biedt continue toegang tot installatiekopieën, zelfs als een regio een storing ondervindt.

Als u een actief-actief-implementatiemodel in AKS wilt maken, voert u de volgende stappen uit:

1. Maak twee identieke implementaties in twee verschillende Azure-regio's.

2. Maak twee exemplaren van uw web-app.

3. Maak een Azure Front Door-profiel met de volgende resources:

   • Een eindpunt.
   • Twee oorsprongsgroepen, elk met een prioriteit van één.
   • Een route.

4. Beperk netwerkverkeer alleen naar de web-apps vanuit het Azure Front Door-exemplaar. 5. Configureer alle andere back-endservices van Azure, zoals databases, opslagaccounts en verificatieproviders.

5. Code implementeren in beide web-apps met continue implementatie.

Zie het overzicht van de aanbevolen oplossing voor actieve en actieve beschikbaarheid voor AKS voor meer informatie.

Implementatiemodel voor actief-passief herstel na noodgevallen

In het implementatiemodel voor actief-passief herstel na noodgevallen (DR) hebt u twee onafhankelijke AKS-clusters geïmplementeerd in twee verschillende Azure-regio's (meestal gekoppelde regio's, zoals Canada - centraal en Canada - oost of US - oost 2 en US - centraal) die actief verkeer bedienen. Slechts één van de clusters dient op elk gewenst moment actief verkeer. Het andere cluster bevat dezelfde configuratie- en toepassingsgegevens als het actieve cluster, maar accepteert geen verkeer, tenzij dit wordt geleid door een Traffic Manager.

Met deze voorbeeldarchitectuur:

• U implementeert twee AKS-clusters in afzonderlijke Azure-regio's.
• Tijdens normale bewerkingen routeert netwerkverkeer naar het primaire AKS-cluster, dat u instelt in de Azure Front Door-configuratie.
  • Prioriteit moet worden ingesteld tussen 1-5 , waarbij 1 de hoogste en 5 de laagste is.
  • U kunt meerdere clusters instellen op hetzelfde prioriteitsniveau en het gewicht van elk cluster opgeven.
• Als het primaire cluster niet beschikbaar is (noodgeval) wordt verkeer automatisch gerouteerd naar de volgende regio die is geselecteerd in Azure Front Door.
  • Al het verkeer moet de Azure Front Door Traffic Manager doorlopen om dit systeem te laten werken.
• Azure Front Door routeert verkeer naar de Azure-app-gateway in de primaire regio (cluster moet worden gemarkeerd met prioriteit 1). Als deze regio mislukt, leidt de service verkeer om naar het volgende cluster in de prioriteitslijst.
  • Regels zijn afkomstig van Azure Front Door.
• Er wordt een hub-spoke-paar geïmplementeerd voor elk regionaal AKS-exemplaar. Azure Firewall Manager-beleid beheert de firewallregels in de regio's.
• Azure Key Vault wordt ingericht in elke regio om geheimen en sleutels op te slaan.
• Regionale Log Analytics-exemplaren slaan metrische gegevens en diagnostische logboeken voor regionale netwerken op.
• De containerinstallatiekopieën voor de workload worden opgeslagen in een beheerd containerregister. Eén Azure Container Registry wordt gebruikt voor alle Kubernetes-exemplaren in het cluster. Geo-replicatie voor Azure Container Registry maakt het repliceren van installatiekopieën naar de geselecteerde Azure-regio's mogelijk en biedt continue toegang tot installatiekopieën, zelfs als een regio een storing ondervindt.

Als u een actief-passief implementatiemodel in AKS wilt maken, voert u de volgende stappen uit:

1. Maak twee identieke implementaties in twee verschillende Azure-regio's.

2. Configureer regels voor automatisch schalen voor de secundaire toepassing, zodat deze wordt geschaald naar hetzelfde aantal exemplaren als de primaire wanneer de primaire regio inactief wordt. Hoewel inactief, hoeft deze niet omhoog te worden geschaald. Dit helpt de kosten te verlagen.

3. Maak twee exemplaren van uw webtoepassing, met één op elk cluster.

4. Maak een Azure Front Door-profiel met de volgende resources:

   • Een eindpunt.
   • Een oorspronkelijke groep met een prioriteit voor de primaire regio.
   • Een tweede oorspronkelijke groep met een prioriteit van twee voor de secundaire regio.
   • Een route.

5. Beperk netwerkverkeer naar de webtoepassingen alleen vanuit het Azure Front Door-exemplaar.

6. Configureer alle andere back-endservices van Azure, zoals databases, opslagaccounts en verificatieproviders.

7. Code implementeren in beide webtoepassingen met continue implementatie.

Zie het overzicht van de aanbevolen oplossing voor actief-passief herstel na noodgevallen voor AKS voor meer informatie.

Implementatiemodel voor passieve koude failover

Het passieve-koude failover-implementatiemodel wordt op dezelfde manier geconfigureerd als het actieve-passieve implementatiemodel voor herstel na noodgevallen, behalve dat de clusters inactief blijven totdat een gebruiker deze activeert in het geval van een noodgeval. We beschouwen deze benadering buiten het bereik omdat het een vergelijkbare configuratie omvat als actief-passief, maar met de extra complexiteit van handmatige interventie om het cluster te activeren en een back-up te activeren.

Met deze voorbeeldarchitectuur:

• U maakt twee AKS-clusters, bij voorkeur in verschillende regio's of zones voor betere tolerantie.
• Wanneer u een failover moet uitvoeren, activeert u de implementatie om de verkeersstroom over te nemen.
• Als het primaire passieve cluster uitvalt, moet u het koude cluster handmatig activeren om de verkeersstroom over te nemen.
• Deze voorwaarde moet worden ingesteld door handmatige invoer elke keer of een bepaalde gebeurtenis zoals opgegeven door u.
• Azure Key Vault wordt ingericht in elke regio om geheimen en sleutels op te slaan.
• Regionale Log Analytics-exemplaren slaan metrische gegevens en diagnostische logboeken voor regionale netwerken voor elk cluster op.

Als u een passief-koude failover-implementatiemodel in AKS wilt maken, voert u de volgende stappen uit:

1. Maak twee identieke implementaties in verschillende zones/regio's.
2. Configureer regels voor automatisch schalen voor de secundaire toepassing, zodat deze wordt geschaald naar hetzelfde aantal exemplaren als de primaire wanneer de primaire regio inactief wordt. Hoewel deze niet actief is, hoeft deze niet omhoog te worden geschaald, wat helpt de kosten te verlagen.
3. Maak twee exemplaren van uw webtoepassing, met één op elk cluster.
4. Configureer alle andere back-endservices van Azure, zoals databases, opslagaccounts en verificatieproviders.
5. Stel een voorwaarde in wanneer het koude cluster moet worden geactiveerd. U kunt een load balancer gebruiken als u dat nodig hebt.

Zie het overzicht van de aanbevolen passieve-koude failoveroplossing voor AKS voor meer informatie.

Servicequota en -limieten

AKS stelt standaardlimieten en quota in voor resources en functies, inclusief gebruiksbeperkingen voor bepaalde VM-SKU's.

Bron	Limiet
Maximumaantal clusters per abonnement	5000 Opmerking: clusters verdelen over verschillende regio's om rekening te houden met beperkingslimieten voor Azure API
Maximumaantal knooppunten per cluster met virtuele-machineschaalsets en standaard load balancer-SKU	5000 voor alle knooppuntgroepen Opmerking: Als u maximaal 5000 knooppunten per cluster niet kunt schalen, raadpleegt u Aanbevolen procedures voor grote clusters.
Maximum aantal knooppunten per knooppuntgroep (virtuele-machineschaalsets)	1000
Maximum aantal knooppuntgroepen per cluster	100
Maximum aantal pods per knooppunt: met kubenet-netwerkinvoegtoepassing 1	Maximum: 250 Azure CLI-standaardinstelling: 110 Standaardsjabloon voor Azure Resource Manager: 110 Standaardimplementatie in Azure Portal: 30
Maximum aantal pods per knooppunt: met Azure Container Networking Interface (Azure CNI)1	Maximum: 250 Maximum aanbevolen voor Windows Server-containers: 110 Standaard: 30
AKS-invoegtoepassing (Open Service Mesh) (OSM)	Kubernetes-clusterversie: ondersteunde AKS-versies OSM-controllers per cluster: 1 Pods per OSM-controller: 1600 Kubernetes-serviceaccounts die worden beheerd door OSM: 160
Maximale kubernetes-services met gelijke taakverdeling per cluster met Standard Load Balancer-SKU	300
Maximumaantal knooppunten per cluster met virtuele-machinebeschikbaarheidssets en basic load balancer-SKU	100

¹ Windows Server-containers moeten gebruikmaken van de Azure CNI-netwerkinvoegtoepassing. Kubenet wordt niet ondersteund voor Windows Server-containers.

Kubernetes-besturingsvlaklaag	Grenswaarde
Standaardlaag	Schaalt de Kubernetes-API-server automatisch op basis van belasting. Grotere limieten voor besturingsvlakonderdelen en API-server-/etc-exemplaren.
Gratis laag	Beperkte resources met een limiet van 50 aanvragen voor het dempen en 100 alleen-lezen aanroepen. Aanbevolen knooppuntlimiet van 10 knooppunten per cluster. Het meest geschikt voor experimenteren, leren en eenvoudig testen. Niet aanbevolen voor productie-/kritieke workloads.

Zie AKS-servicequota en -limieten voor meer informatie.

Backup

Azure Backup biedt ondersteuning voor het maken van back-ups van AKS-clusterbronnen en permanente volumes die zijn gekoppeld aan het cluster met behulp van een back-upextensie. De Backup-kluis communiceert met het AKS-cluster via de extensie om back-up- en herstelbewerkingen uit te voeren.

Raadpleeg voor meer informatie de volgende artikelen:

• Over AKS-back-up met behulp van Azure Backup (preview)
• Een back-up maken van AKS met behulp van Azure Backup (preview)