Udostępnij za pośrednictwem


Przenoszenie klastra usługi Azure Kubernetes Service (AKS) do innego regionu

W tym artykule opisano wskazówki dotyczące przenoszenia klastra usługi Azure Kubernetes Service do innego regionu.

Istnieją różne powody, dla których możesz przenieść istniejące zasoby platformy Azure z jednego regionu do innego. Możesz chcieć:

  • Skorzystaj z nowego regionu świadczenia usługi Azure.
  • Wdrażanie funkcji lub usług dostępnych tylko w określonych regionach.
  • Spełnij wymagania dotyczące zasad wewnętrznych i ładu.
  • Dopasowanie do fuzji i przejęć firmy
  • Spełnianie wymagań dotyczących planowania pojemności.

Uwaga

Klienci z cyklami szybkiego wydawania często korzystają z potoków ciągłej integracji/ciągłego wdrażania. W takich przypadkach można rozważyć zmianę potoków kompilacji i wydania zamiast ponownego wdrażania klastrów usługi AKS w regionie docelowym.

Wymagania wstępne

Przed rozpoczęciem etapu planowania relokacji najpierw zapoznaj się z następującymi wymaganiami wstępnymi:

  • Upewnij się, że region docelowy ma wystarczającą pojemność (jednostki SKU maszyny wirtualnej), aby pomieścić nowe węzły klastra.

  • Sprawdź, czy masz uprawnienia do tworzenia zasobów w subskrypcji docelowej. Sprawdź, czy zasady platformy Azure nie ograniczają regionów, w których można wdrożyć usługę AKS.

  • (Opcjonalnie) Zbierz szablony infrastruktury jako kodu (IaC) lub skrypty, za pomocą których zainicjowano aprowizację źródłowego klastra usługi AKS.

  • Zbierz manifesty platformy Kubernetes, aby ponownie utworzyć obciążenie aplikacji w klastrze docelowym.

    Napiwek

    Ocena podejścia GitOps do wdrożenia obciążenia, w którym manifesty konfiguracji platformy Kubernetes są przechowywane w repozytorium Git i automatycznie stosowane przez operatora GitOps działającego w klastrze, takiego jak Flux. Podejście GitOps sprawia, że ponowne wdrażanie obciążeń w różnych klastrach jest proste podczas instalowania kontrolera GitOps i wskazywania go w repozytorium.

  • Przejrzyj implementację ruchu przychodzącego klastra.

  • Udokumentowanie zmian DNS wymaganych do wskazania domeny publicznej do punktu końcowego ruchu przychodzącego klastra.

  • Sprawdź, czy klaster przechowuje jakiekolwiek dane stanu, takie jak woluminy trwałe, które należy przeprowadzić migrację do klastra docelowego.

  • Dokumentowanie publicznego zarządzania certyfikatami TLS i dystrybucji.

  • Przechwyć wszystkie adresy IP zdefiniowane na liście dozwolonych usługi interfejsu API usługi AKS.

  • Omówienie wszystkich zasobów zależnych. Niektóre zasoby mogą być następujące:

    • Kolejki, magistrale komunikatów, aparaty pamięci podręcznej
    • Azure Key Vault
    • Tożsamość zarządzana
    • Konfiguracja sieci wirtualnej. Definiowanie wystarczających rozmiarów podsieci w celu umożliwienia wzrostu adresu IP kontenera w przypadku korzystania z zaawansowanego modelu sieci platformy Azure
    • Publiczny adres IP
    • Brama sieci wirtualnej (VNG). Jeśli komunikacja lokacja-lokacja jest wymagana w środowisku lokalnym w regionie docelowym, sieć wirtualna musi zostać utworzona w docelowej sieci wirtualnej.
    • Prywatny punkt końcowy platformy Azure. Należy przejrzeć zasoby usługi Azure PaaS korzystające z punktów końcowych łącza prywatnego, a nowe wystąpienia linków prywatnych utworzone w regionie docelowym, takim jak ACR, Azure SQL DB, KeyVault itp.
    • Usługa Azure Application Gateway
    • Usługa DNS platformy Azure
    • Azure Firewall
    • Azure Monitor (Container Insights)
    • Usługa Azure Container Registry może replikować obrazy między wystąpieniami usługi ACR. Aby uzyskać optymalną wydajność podczas ściągania obrazów, rejestr powinien istnieć w regionie docelowym.

      Uwaga

      Jeśli używasz usługi Azure Container Registry do uwierzytelniania w rejestrze kontenerów, tożsamość zarządzana nowego klastra usługi AKS może być udzieloną AcrPull rolą RBAC.

    • Dyski zarządzane platformy Azure
    • Azure Files

Przygotowywanie

Przed rozpoczęciem procesu relokacji klastra upewnij się, że wykonasz następujące przygotowania:

  1. Aby pomieścić węzły i zasobniki klastra usługi AKS, w przypadku korzystania z sieci CNI platformy Azure należy wdrożyć sieć wirtualną z wieloma podsieciami o wystarczającym rozmiarze.

  2. Jeśli używasz usługi Azure Key Vault, wdróż usługę Key Vault.

  3. Upewnij się, że odpowiednie certyfikaty ruchu przychodzącego TLS są dostępne do wdrożenia, najlepiej w bezpiecznym magazynie, takim jak usługa Azure Key Vault.

  4. Wdrażanie rejestru kontenerów. Synchronizuj obrazy rejestru źródłowego automatycznie lub ponownie skompiluj i wypchnij nowe obrazy do rejestru docelowego przy użyciu potoku lub skryptu ciągłej integracji/ciągłego wdrażania.

  5. Wdrażanie obszaru roboczego usługi Azure Monitor.

  6. (Opcjonalnie) Wdrażanie usługi aplikacja systemu Azure Gateway w celu obsługi ruchu przychodzącego kontrolera ruchu przychodzącego usługi Application Gateway (AGIC) może ściśle integrować się z klastrem

  7. Wdróż wszystkie źródła danych wymagane przez obciążenie klastra i przywróć lub zsynchronizuj dane źródłowe.

  8. Wykonaj istniejące artefakty IaC zdefiniowane w potoku ciągłej integracji/ciągłego wdrażania, które zostały użyte do wdrożenia klastra źródłowego i usług, od których zależy. Zmień parametry wejściowe kodu lub szablonu, aby ponownie wdrożyć inną grupę zasobów i region platformy Azure.

Wdróż ponownie

Wdróż klaster usługi AKS bez migracji danych, wykonując następujące kroki:

  1. Aby utworzyć środowisko docelowe na platformie Azure, ręcznie uruchom istniejące artefakty IaC na lokalnej stacji roboczej.

  2. Jeśli nie ma żadnych istniejących zasobów IaC, bieżąca konfiguracja klastra może zostać wyeksportowana jako szablon usługi ARM i wykonana względem regionu docelowego. Szablony IaC są tworzone od podstaw lub są modyfikowane wersje przykładowych szablonów przy użyciu rozwiązań Bicep, JSON, Terraform lub innego rozwiązania.

    Uwaga

    • Połączenia usługi Private Link, połączone rejestry usługi ACR i źródła danych obszaru roboczego usługi Azure Monitor nie są obecnie eksportowane przy użyciu tej metody i dlatego należy je usunąć z wygenerowanego szablonu przed wykonaniem.
  3. Wdróż obciążenie kontenera w klastrze usługi AKS, które można osiągnąć na dwa sposoby:

    • Manifesty ściągania są pobierane z repozytorium i stosowane przez kontroler działający w klastrze, znany jako podejście GitOps.
    • Push (Git: wypchnij) Manifesty są wypychane do klastra przy użyciu usługi interfejsu API Kubernetes i narzędzia wiersza polecenia kubectl z potoku ciągłej integracji/ciągłego wdrażania lub lokalnej stacji roboczej.
  4. Aby upewnić się, że nowy klaster działa zgodnie z oczekiwaniami, przeprowadź testowanie i walidację.

  5. Zmień publiczne wpisy DNS, aby wskazywały zewnętrzny adres IP ruchu przychodzącego klastra docelowego (publiczny adres IP usługi Azure Load Balancer lub publiczny adres IP usługi Application Gateway).

  6. Wdrożenie przy użyciu globalnego rozwiązania równoważenia obciążenia, takiego jak usługa Azure DNS lub Azure Traffic Manager, musi dodać region do konfiguracji.

Ponowne wdrażanie przy użyciu migracji danych

Obciążenia usługi AKS korzystające z magazynu lokalnego, takie jak woluminy trwałe, do przechowywania danych lub hostowania usług bazy danych w klastrze mogą być tworzone kopie zapasowe w klastrze źródłowym i przywracane do klastra docelowego. Aby dowiedzieć się, jak wykonywać kopie zapasowe i przywracać, zobacz Tworzenie kopii zapasowej usługi Azure Kubernetes Service przy użyciu interfejsu wiersza polecenia platformy Azure.