Een AKS-cluster (Azure Kubernetes Service) verplaatsen naar een andere regio

Dit artikel bevat richtlijnen voor het verplaatsen van een Azure Kubernetes Service-cluster naar een andere regio.

Er zijn verschillende redenen waarom u uw bestaande Azure-resources mogelijk van de ene regio naar de andere wilt verplaatsen. U kunt het volgende doen:

  • Profiteer van een nieuwe Azure-regio.
  • Implementeer functies of services die alleen beschikbaar zijn in specifieke regio's.
  • Voldoen aan interne beleids- en governancevereisten.
  • In overeenstemming met bedrijfsfusies en overnames
  • Voldoen aan vereisten voor capaciteitsplanning.

Opmerking

Klanten met snelle releasecycli maken vaak gebruik van CI/CD-pijplijnen. In dergelijke gevallen kunt u overwegen om de build- en release-pijplijnen te wijzigen in plaats van de AKS-clusters opnieuw te implementeren in de doelregio.

Vereiste voorwaarden

Voordat u begint met de fase van de herlocatieplanning, moet u eerst de volgende vereisten bekijken:

  • Zorg ervoor dat de doelregio voldoende capaciteit (VM-SKU's) heeft voor de nieuwe clusterknooppunten.

  • Controleer of u machtigingen hebt voor het maken van resources voor het doelabonnement. Controleer of Azure Policy de regio's waarnaar AKS kan worden geïmplementeerd, niet beperkt.

  • (Optioneel) Verzamel de IaC-sjablonen (Infrastructure as Code) of scripts waarmee u het bron-AKS-cluster hebt ingericht.

  • Verzamel de Kubernetes-manifesten om de toepassingsworkload in het doelcluster opnieuw te maken.

    Hint

    Evalueer een GitOps-benadering voor workloadimplementatie waarbij Kubernetes-configuratiemanifesten worden opgeslagen in een Git-opslagplaats en automatisch worden toegepast door een GitOps-operator die wordt uitgevoerd in het cluster, zoals Flux. Een GitOps-benadering maakt het opnieuw implementeren van workloads naar verschillende clusters net zo eenvoudig als het installeren van de GitOps-controller en het aanwijzen ervan in de opslagplaats.

  • Controleer de implementatie van inkomend cluster.

  • Documenteer de DNS-wijzigingen die nodig zijn om een openbaar domein naar het eindpunt voor inkomend verkeer van het cluster te verwijzen.

  • Controleer of in het cluster statusgegevens, zoals permanente volumes, worden opgeslagen die u naar het doelcluster moet migreren.

  • Documenteer openbaar TLS-certificaatbeheer en -distributie.

  • Leg alle IP-adressen vast die zijn gedefinieerd in de acceptatielijst van de AKS-API-service.

  • Inzicht krijgen in alle afhankelijke resources. Een aantal van de resources kan het volgende zijn:

    • Wachtrijen, berichtbussen, cachemotoren

    • Azure Key Vault

    • Beheeridentiteit

    • Configuratie van virtueel netwerk. Voldoende subnetgrootten definiëren om container-IP-groei mogelijk te maken als u het geavanceerde Azure-netwerkmodel gebruikt

    • Openbaar IP-adres

    • Virtuele netwerkgateway (VNG). Als site-naar-site-communicatie is vereist voor een on-premises omgeving in de doelregio, moet er een VNG worden gemaakt in het virtuele doelnetwerk.

    • Privé-eindpunt van Azure. Azure PaaS-resources die gebruikmaken van private link-eindpunten moeten worden geëvalueerd, en er moeten nieuwe private link-exemplaren worden aangemaakt in de doelregio, zoals ACR, Azure SQL DB, KeyVault, enzovoort.

    • Azure Application Gateway

    • Azure DNS

    • Azure Firewall

    • Azure Monitor (Container Insights)

    • Azure Container Registry kan afbeeldingen tussen ACR-instanties repliceren. Voor optimale prestaties bij het ophalen van images moet het register zich in de doelregio bevinden.

      Opmerking

      Als u Azure Container Registry gebruikt om te verifiëren bij het containerregister, kan de beheerde identiteit van het nieuwe AKS-cluster de toegewezen AcrPull RBAC-rol zijn.

    • Azure Managed Disks

    • Azure Files

Voorbereiden

Voordat u begint met het clusterverplaatsingsproces, moet u de volgende voorbereidingen voltooien:

  • Voor de AKS-clusterknooppunten en -pods implementeert u het virtuele netwerk met veel subnetten van voldoende grootte als u Azure CNI-netwerken gebruikt.
  • Als u Azure Key Vault gebruikt, implementeert u de Sleutelkluis.
  • Zorg ervoor dat de relevante TLS-toegangscertificaten beschikbaar zijn voor implementatie, idealiter in een beveiligd archief, zoals Azure Key Vault.
  • Een containerregister implementeren. Synchroniseer de bronregisterinstallatiekopieën automatisch of bouw nieuwe installatiekopieën opnieuw en push nieuwe installatiekopieën naar het doelregister met behulp van een CI/CD-pijplijn of script.
  • Een Azure Monitor-werkruimte implementeren.
  • (Optional) Azure Application Gateway implementeren om inkomend verkeer te verwerken; de Application Gateway Ingress Controller (AGIC) kan nauw integreren met het cluster.
  • Implementeer alle gegevensbronnen die vereist zijn voor de clusterworkload en herstel of synchroniseer de brongegevens.
  • Voer bestaande IaC-artefacten uit die zijn gedefinieerd in een CI/CD-pijplijn die zijn gebruikt voor het implementeren van het broncluster en de services die ervan afhankelijk zijn. Wijzig de code- of sjablooninvoerparameters om opnieuw te implementeren in een andere resourcegroep en Azure-regio.

Opnieuw implementeren

Implementeer het AKS-cluster zonder gegevensmigratie door de volgende stappen uit te voeren:

  1. Als u de doelomgeving in Azure wilt maken, moet u de bestaande IaC-artefacten handmatig uitvoeren op een lokaal werkstation.

  2. Als er geen bestaande IaC-assets zijn, kan de huidige clusterconfiguratie worden geëxporteerd als een ARM-sjabloon en worden uitgevoerd op basis van de doelregio. IaC-sjablonen worden helemaal zelf gemaakt of zijn gewijzigde versies van voorbeeldsjablonen met bicep, JSON, Terraform of een andere oplossing.

    Opmerking

    • Private Link-verbindingen, met ACR verbonden registers en gegevensbronnen van De Azure Monitor-werkruimte worden momenteel niet geëxporteerd met deze methode en moeten daarom worden verwijderd uit de gegenereerde sjabloon voordat deze wordt uitgevoerd.

  3. Implementeer de containerworkload naar het AKS-cluster, wat op twee manieren kan worden bereikt:

    • Pull-manifesten worden opgehaald uit een opslagplaats en toegepast door een controller die in het cluster wordt uitgevoerd, ook wel een GitOps-benadering genoemd.
    • Duwen. Manifesten worden naar het cluster gepusht met behulp van de Kubernetes API-service en het kubectl-opdrachtregelprogramma, hetzij vanuit een CI/CD-pijplijn of lokaal werkstation.

  4. Voer tests en validatie uit om ervoor te zorgen dat het nieuwe cluster naar verwachting wordt uitgevoerd.

  5. Wijzig uw openbare DNS-vermeldingen zodat deze verwijzen naar het externe inkomend IP-adres van het doelcluster (Azure Public Load Balancer IP of Openbare IP van Application Gateway).

  6. Een implementatie met behulp van een globale taakverdelingsoplossing, zoals Azure DNS of Azure Traffic Manager, moet de regio toevoegen aan de configuratie.

Opnieuw implementeren met gegevensmigratie

AKS-workloads die gebruikmaken van lokale opslag, zoals permanente volumes, om gegevens of databaseservices binnen het cluster op te slaan, kunnen op een broncluster worden geback-upt en naar een doelcluster worden hersteld. Zie Back-up maken van Azure Kubernetes Service met behulp van Azure CLI voor meer informatie over het uitvoeren van back-ups en herstel.

Verwante inhoud

  • Last updated on