Delen via

De status van Kubernetes-clusters herstellen na een noodgeval

  • Artikel

Van toepassing op: AKS op Azure Stack HCI 22H2, AKS op Windows Server

In AKS op Azure Stack HCI of Windows Server wordt het beheercluster geïmplementeerd als één zelfstandige virtuele machine (VM) per implementatie, waardoor het één storingspunt is. Het is belangrijk te weten dat een storing in een beheercluster geen invloed heeft op toepassingen die worden uitgevoerd in de workloadclusters. Wanneer de VM van het beheercluster mislukt, blijven de workloadclusters (en workloads) actief, maar kunt u geen dag-2-bewerkingen uitvoeren. U kunt bijvoorbeeld geen nieuwe workloadclusters maken, een knooppuntgroep maken of schalen of Kubernetes-versies upgraden totdat de VIRTUELE machine is hersteld.

Het beheercluster is een VM die wordt bijgehouden in Windows-failoverclustering. Het is ook tolerant voor onderbrekingen op hostniveau. Met andere woorden, tijdens een storing van een hostmachine start Windows-failoverclustering de VIRTUELE machine opnieuw op een goede hostcomputer opnieuw op. Dit artikel bevat richtlijnen voor het uitvoeren van de volgende taken:

  • Herstel de status van AKS op nieuwe hardware (kan een nieuwe site zijn).
  • Herstel na beschadiging van het beheercluster.

In een van deze scenario's moet u het beheercluster en alle workloadclusters opnieuw maken.

De status van AKS herstellen op nieuwe hardware of een nieuwe site

Voor het herstellen van de status van Kubernetes-clusters moet u een beheercluster hebben dat beschikbaar is op nieuwe hardware of op de nieuwe locatie.

  • AKS biedt ondersteuning voor het maken van back-ups van Kubernetes-clusters naar Azure Blob Storage en MinIO met behulp van Velero. Microsoft raadt aan een back-up te maken van Azure Storage, omdat er drie redundante kopieën van gegevens in de primaire opslagregio worden geboden.
  • Overweeg om de back-up uit te voeren op een cron-taak om ervoor te zorgen dat beschikbare back-ups voldoen aan de beoogde herstelpunten.

Vereisten

Bereid de koude stand-by voor op een noodgeval door een beheercluster en een leeg workloadcluster te maken. U hebt een leeg workloadcluster nodig voor elk Kubernetes-cluster dat u wilt herstellen vanuit een back-up. De volgende vereisten zijn vereist:

Herstellen na beschadiging van beheercluster

Voor herstel na beschadiging van een beheercluster moet AKS worden verwijderd en het beheercluster en alle workloadclusters opnieuw worden geïnstalleerd. Workloadclusters kunnen worden hersteld in lege workloadclusters vanuit Velero-back-ups.

De volgende vereisten zijn vereist:

  • Back-ups van workloadclusters: back-ups maken van workloadclusters en deze herstellen met Behulp van Velero.
  • Back-up van AKS-configuratie voor eerdere netwerk-, opslag- en clusterinstellingen. Clusterinstellingen zijn onder andere grootten en aantallen besturingsvlak, load balancer en werkknooppunt-VM's. Als uw oude cluster bijvoorbeeld 3 Standard_A2_V2 VM's in het besturingsvlak had, moet u 3 VM's met het besturingsvlak maken in de nieuwe omgeving.

Voer de volgende stappen uit om te herstellen van beschadiging van beheerclusters:

Veelgestelde vragen

Welke tolerantie is ingebouwd in het beheercluster?

Elke AKS-implementatie bevat een beheercluster dat één zelfstandige VM is. Voor tolerantie en hoge beschikbaarheid is AKS afhankelijk van Windows-failoverclustering om de VM te herstellen als er een onderbreking optreedt.

Een storing in een beheercluster heeft geen invloed op toepassingen die worden uitgevoerd in workloadclusters. Wanneer de VM van het beheercluster uitvalt, heeft dit gevolgen voor het uitvoeren van AKS Day 2-bewerkingen, zoals het maken van nieuwe workloadclusters, het maken of schalen van knooppuntgroepen, het upgraden van Kubernetes-versies, enzovoort, totdat de VIRTUELE machine is hersteld. In gevallen waarin u niet kunt herstellen na een storing in een beheercluster, raden we u aan contact op te maken met Microsoft Ondersteuning.

Wat is opgenomen in een Velero-back-up?

Bestandsnaam Inhoudsbeschrijving
*-csi-volumesnapshotclasses.json.gz Bestanden met csi zijn de permanente momentopnamen van volumes.
*-csi-volumesnapshotcontents.json.gz Bestanden met csi zijn permanente momentopnamen van volumes.
*-csi-volumesnapshots.json.gz Bestanden met csi zijn de permanente momentopnamen van volumes.
*-logs.gz Logboekuitvoer van back-upbewerking. Dezelfde gegevens worden uitgevoerd: velero backup log <backupname>.
*-podvolumebackups.json.gz Metagegevens over de pods en permanente volumes.
*-resource-list.json.gz Resources in een back-up worden vermeld in dit bestand.
*-volumesnapshots.json.gz Metagegevens over de pods en permanente volumes.
*.tar.gz Metagegevens: naamruimte, aantal podreplica's, geheugen, cpu. Dezelfde gegevens als geretourneerd door: kubectl get deployment.

Wat is er niet opgenomen in Velero-back-ups?

De Velero-back-up bevat niet de volgende items:

  • AKS-configuratie (Beheercluster)
  • Metagegevens van VM met besturingsvlak (API-server)
  • Metagegevens van load balancer (HA-proxy)
  • Netwerkinstellingen
  • Opslaginstellingen

Hoe kan ik een back-up maken van de AKS-configuratie vóór een noodgeval?

Als u een back-up van de configuratie van het beheercluster wilt maken, opent u een PowerShell-venster en voert u de volgende opdracht uit:

Get-AksHciConfig | ConvertTo-Json

Hoe kan ik ervoor zorgen dat het workloadcluster dezelfde configuratie heeft als vóór een noodgeval?

Als u een back-up van de configuratie van het workloadcluster wilt maken, opent u een PowerShell-venster en voert u de volgende opdracht uit:

Get-AksHciCluster -name <cluster name> | ConvertTo-Json

Volgende stappen