Udostępnij za pośrednictwem

Migrowanie z usługi Amazon EKS do usługi Azure Kubernetes Service (AKS)

  • Artykuł

Ten artykuł zawiera strategie migracji typowych obciążeń bezstanowych i stanowych z usługi Amazon EKS do usługi Azure Kubernetes Service (AKS).

Kwestie wymagające rozważenia

Rzeczywisty proces wdrażania rzeczywistego obciążenia produkcyjnego może się różnić w zależności od następujących czynników:

  • Strategie wdrażania: wybór między metodami GitOps i tradycyjnymi metodami ciągłej integracji/ciągłego wdrażania Metodyki DevOps (CI/CD) znacząco wpływa na podejście wdrażania. Metodyka GitOps określa priorytety infrastruktury deklaratywnej zarządzanej za pośrednictwem repozytoriów kontrolowanych wersjami, podczas gdy ciągła integracja/ciągłe wdrażanie metodyki DevOps koncentruje się na zautomatyzowanych przepływach pracy na potrzeby dostarczania aplikacji.

  • Artefakty wdrażania: wybór artefaktów wdrożenia odgrywa kluczową rolę w definiowaniu struktury wdrażania. Pliki YAML, pliki manifestu, wykresy helm i konfiguracje kustomize reprezentują różne podejścia do określania i dostosowywania ustawień wdrożenia, z których każda ma swoje mocne strony i przypadki użycia.

  • Uwierzytelnianie i autoryzacja obciążenia: w zależności od konfiguracji metody uwierzytelniania i autoryzacji mogą się różnić. Do kontroli dostępu można użyć ról usługi Amazon Web Services (AWS) Identity and Access Management (IAM), mechanizmów tożsamości obciążeń lub parametry połączenia.

  • Monitorowanie: Implementacja rozwiązań do monitorowania jest krytycznym aspektem, który może obejmować różne narzędzia i metodologie w celu zapewnienia wydajności i kondycji wdrożonych obciążeń. Aby uzyskać więcej informacji na temat porównywania monitorowania usługi AKS z eks, zobacz Monitorowanie i rejestrowanie na platformie Kubernetes.

Przed rozpoczęciem migracji zapoznaj się z następującymi ogólnymi wskazówkami i zasobami najlepszych rozwiązań:

  • Zapoznaj się z operatorem klastra i najlepszymi rozwiązaniami dla deweloperów.
  • Zdefiniuj strategię monitorowania i alertów, aby upewnić się, że aplikacja działa zgodnie z oczekiwaniami.
  • Zdefiniuj wymagania dotyczące zabezpieczeń i zgodności dla aplikacji i środowiska usługi AKS.
  • Zdefiniuj zasady kontroli dostępu i sposób ich wymuszania. Zidentyfikuj wszelkie standardy zgodności, które muszą być zgodne.
  • Zdefiniuj plan odzyskiwania po awarii i ciągłości działania dla środowiska usługi AKS i aplikacji.
  • Zdefiniuj zasady i procedury tworzenia kopii zapasowych i przywracania. Zidentyfikuj cel czasu odzyskiwania (RTO) i cel punktu odzyskiwania (RPO).
  • Zidentyfikuj wszelkie zagrożenia lub wyzwania, które mogą wystąpić podczas wdrażania.
  • Przetestuj funkcjonalność, aby upewnić się, że aplikacja działa zgodnie z oczekiwaniami przed przekierowaniem ruchu na żywo do nowego klastra usługi AKS.

Zagadnienia dotyczące migracji obciążeń

W tej sekcji omówiono kilka kwestii, które należy wziąć pod uwagę przed migracją obciążeń z usługi Amazon EKS do usługi AKS.

Omówienie istniejącego środowiska Usługi Amazon EKS

Przeanalizuj istniejące środowisko EKS, aby zrozumieć bieżącą architekturę, zasoby i konfiguracje.

  • Przejrzyj konfigurację eks: Ocena konfiguracji klastra EKS, takich jak typy węzłów, liczba węzłów, wersja platformy Kubernetes i zasady obsługi oraz konfiguracja skalowania.

    Uwaga

    Eks umożliwia tworzenie niestandardowych obrazów AMI dla węzłów EKS. Usługa AKS nie zezwala na używanie niestandardowych obrazów węzłów. Jeśli wdrożenie wymaga dostosowania węzła, możesz zastosować dostosowywanie narzędzia kubelet i/lub zestawy DaemonSet, aby dostosować węzły.

  • Przejrzyj obciążenia aplikacji: zidentyfikuj wszystkie obciążenia Kubernetes uruchomione w klastrze EKS, w tym wdrożenia, usługi, zestawy stanowe, konfiguracje ruchu przychodzącego i trwałe oświadczenia woluminu. Upewnij się, że masz pełną listę aplikacji i skojarzonych z nimi zasobów.

  • Sprawdź zależności: zidentyfikuj wszelkie zależności dotyczące usług AWS specyficznych dla eks.

    Usługa AWS Dependency
    Menedżer wpisów tajnych platformy AWS Azure Key Vault
    Agent dyżurny usługi AWS Guard Usługa Microsoft Defender dla kontenerów
    Agent tożsamości eks pod Tożsamość obciążenia identyfikatora entra firmy Microsoft
    Sterowniki interfejsu magazynu kontenerów (CSI, Elastic Block Store) lub Elastic Block Store (EBS) Sterowniki AKS CSI

  • Tworzenie kopii zapasowej klastra EKS: możesz użyć narzędzia innego niż Microsoft, takiego jak Velero , aby utworzyć kopię zapasową i przeprowadzić migrację zasobów platformy Kubernetes i woluminów trwałych.

Przygotowywanie środowiska usługi Azure AKS

Wirtualna chmura prywatna amazon (VPC) Container Networking Interface (CNI) to domyślna wtyczka sieci obsługiwana przez eks. Klaster usługi AKS obsługuje wiele wtyczek sieciowych i metod wdrażania klastra w sieci wirtualnej, w tym:

Aby przygotować klaster usługi AKS, wykonaj następujące kroki:

  1. Utwórz nowy klaster usługi AKS na platformie Azure, konfigurując żądane ustawienia sieciowe zgodnie z wymaganiami.
  2. Przejrzyj manifesty platformy Kubernetes i pliki YAML używane w eks. Sprawdź, czy nie jest obsługiwana żadna potencjalna niezgodność wersji interfejsu API kubernetes lub określone konfiguracje eks, których usługa AKS nie obsługuje.
  3. Upewnij się, że obrazy platformy Docker i lokalizacja rejestru obrazów kontenerów są dostępne z klastra usługi AKS. Sprawdź łączność sieciową i wszystkie wymagane ustawienia uwierzytelniania i autoryzacji na potrzeby uzyskiwania dostępu do obrazów.

Wykonując poniższe kroki, można pomyślnie utworzyć klaster usługi AKS i zapewnić zgodność manifestów platformy Kubernetes i obrazów platformy Docker, zapewniając bezproblemowy proces migracji z eks do usługi AKS.

Omówienie migracji

Migracja z usługi Amazon EKS do usługi AKS obejmuje kilka kroków, takich jak:

  • Migracja obrazu kontenera: Migrowanie obrazów kontenerów jest kluczowym krokiem podczas przechodzenia z eks do usługi AKS. Do eksportowania i importowania obrazów można użyć narzędzi, takich jak kubectl, Docker lub rejestry kontenerów.

    1. Eksportowanie obrazów z eks.
    2. Skonfiguruj usługę Azure Container Registry i dołącz ją do usługi AKS, jeśli jeszcze tego nie zrobiono.
    3. Wypychanie obrazów do usługi Container Registry.

    Obrazy kontenerów można również zaimportować do usługi Container Registry bezpośrednio z publicznego lub prywatnego repozytorium platformy Azure. Aby uzyskać więcej informacji, zobacz Importowanie obrazów kontenerów.

  • Migracja manifestu platformy Kubernetes: usługa AKS używa manifestu pliku YAML kubernetes do definiowania obiektów Kubernetes. Wdrożenia są zwykle tworzone i zarządzane za pomocą polecenia kubectl create lub kubectl apply. Utwórz wdrożenie, definiując plik manifestu w formacie YAML. Aby uzyskać więcej informacji, zobacz ten przykładowy manifest usługi AKS. Aby dowiedzieć się więcej na temat sposobu działania plików YAML na platformie Kubernetes, zapoznaj się z tematem Wdrożenia i manifesty YAML.

  • Migracja danych: starannie zaplanuj migrację aplikacji stanowych, aby uniknąć utraty danych lub nieoczekiwanego przestoju. Aby uzyskać więcej informacji, zobacz sekcję Zagadnienia dotyczące migracji obciążeń stanowych.

Zagadnienia dotyczące migracji obciążeń bezstanowych

Migrowanie manifestów platformy Kubernetes obejmuje dostosowanie konfiguracji do pracy w środowisku platformy Azure, w tym następujące kroki:

  1. Manifesty aktualizacji: zaktualizuj manifesty platformy Kubernetes, aby używać nowych lokalizacji obrazów w usłudze Container Registry. Zastąp odwołania do obrazu w plikach YAML ścieżką rejestru kontenerów.

    1. Przejrzyj istniejące pliki manifestu platformy Kubernetes pod kątem konfiguracji specyficznych dla platformy AWS, takich jak role VPC i IAM.
    2. Przejrzyj role eks IAM skojarzone z węzłami, kontami usług i innymi zasobami. Zamapuj ją na równoważne role kontroli dostępu opartej na rolach (RBAC) usługi Azure AKS. Aby uzyskać więcej informacji, zobacz Tożsamość obciążenia platformy Kubernetes i dostęp.
    3. Zmodyfikuj pliki manifestu, aby zastąpić ustawienia specyficzne dla platformy AWS ustawieniami specyficznymi dla platformy Azure, takimi jak adnotacje.

  2. Zastosuj manifesty do usługi AKS:

    1. Nawiązywanie połączenia z klastrem usługi AKS.
    2. Zastosuj zmodyfikowane pliki manifestu kubernetes przy użyciu polecenia kubectl apply -f.

Zagadnienia dotyczące migracji obciążeń stanowych

Jeśli aplikacje używają woluminów trwałych (PV) lub trwałych oświadczeń woluminów (PVC) do przechowywania danych, upewnij się, że wykonasz kopię zapasową tych danych. Za pomocą narzędzi, takich jak Velero , można wykonywać kopie zapasowe klastra, w tym dla wirtualnych telewizorów i danych PVCs. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie zasobów klastra Amazon EKS przy użyciu platformy Velero.

Aplikacje stanowe zwykle mają stałe wymagania dotyczące magazynu danych, które dodają złożoność procesu migracji. Porównanie możliwości magazynu usług Amazon EKS i AKS można znaleźć w temacie Storage options for a Kubernetes cluster (Opcje magazynu dla klastra Kubernetes).

Wykonaj następujące kroki, aby utworzyć kopię zapasową danych trwałych:

  1. Konfigurowanie usługi Velero w klastrze AKS i EKS .
  2. Wykonaj kopię zapasową klastra EKS.
  3. Skopiuj kopię zapasową Velero z zasobnika S3 do usługi Azure Blob Storage, używając polecenia az copy.
  4. Ponieważ usługi AKS i EKS mogą używać różnych storageClassNames dla oświadczeń trwałych woluminów, utwórz obiekt configMap , który tłumaczy źródło storageClassNames na nazwę klasy zgodnej z usługą AKS. Ten krok można zignorować, jeśli używasz tego samego rozwiązania magazynu w klastrach EKS i AKS Kubernetes.
  5. Przywróć kopię zapasową do usługi AKS (za pomocą polecenia przywracania platformy Velero).
  6. Zastosuj niezbędne zmiany w przywróconych obiektach, takich jak odwołania do obrazów kontenerów w usłudze Amazon Elastic Container Registry (ECR) lub dostęp do wpisów tajnych.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

  • Dixit Arora | Starszy inżynier klienta, ISV DN CoE
  • Ketan Chawda | Starszy inżynier klienta, ISV DN CoE

Inni współautorzy:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki