Często zadawane pytania — platforma Kubernetes z obsługą usługi Azure Arc i usługa GitOps

Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące platformy Kubernetes z obsługą usługi Azure Arc i usługi GitOps.

Jaka jest różnica między platformą Kubernetes z obsługą usługi Azure Arc i usługą Azure Kubernetes Service (AKS)?

Usługa AKS to zarządzana oferta kubernetes platformy Azure. Usługa AKS upraszcza wdrażanie zarządzanego klastra Kubernetes na platformie Azure, odciążając znaczną część złożoności i nakładu pracy operacyjnej na platformę Azure. Ponieważ wzorce kubernetes są zarządzane przez platformę Azure, można zarządzać węzłami agenta i zarządzać nimi tylko.

Platforma Kubernetes z obsługą usługi Azure Arc umożliwia rozszerzenie możliwości zarządzania platformy Azure (takich jak Azure Monitor i Azure Policy), łącząc klastry Kubernetes z platformą Azure. Należy zachować bazowy klaster Kubernetes.

Czy muszę połączyć klastry usługi AKS uruchomione na platformie Azure z usługą Azure Arc?

Łączenie klastra usługi Azure Kubernetes Service (AKS) z usługą Azure Arc nie jest wymagane w większości scenariuszy. Możesz połączyć klaster usługi AKS w celu uruchomienia niektórych usług z obsługą usługi Azure Arc, takich jak azure Container Apps lub usługi danych z obsługą usługi Arc w klastrze. Można to zrobić przy użyciu funkcji lokalizacji niestandardowych platformy Kubernetes z obsługą usługi Azure Arc.

Czy należy połączyć usługę AKS w usłudze Azure Local lub Azure Stack Edge z usługą Azure Arc?

Łączenie usługi AKS w usłudze Azure Local lub Azure Stack Edge z usługą Azure Arc zapewnia klastrom reprezentację zasobów w usłudze Azure Resource Manager. Ta reprezentacja zasobu rozszerza możliwości, takie jak konfiguracja klastra, usługa Azure Monitor i usługa Azure Policy (Gatekeeper) do połączonych klastrów Kubernetes.

W przypadku usługi Azure Stack Edge, usługi AKS w usłudze Azure Local (>= aktualizacja z kwietnia 2021 r.) lub usługi AKS w systemie Windows Server 2019 Datacenter (>= aktualizacja z kwietnia 2021 r.) konfiguracja platformy Kubernetes nie jest uwzględniana bezpłatnie.

Jak mogę wygasły adres platformy Kubernetes z włączoną usługą Azure Arc?

Tożsamość zarządzana przypisana przez system skojarzona z klastrem Kubernetes z włączoną usługą Azure Arc jest używana tylko przez agentów usługi Azure Arc do komunikowania się z usługami Azure Arc. Certyfikat skojarzony z tą tożsamością zarządzaną przypisaną przez system ma okres wygaśnięcia 90 dni, a agenci spróbują odnowić ten certyfikat między dniem 46 a dniem 90. Aby uniknąć wygaśnięcia certyfikatu tożsamości zarządzanej, upewnij się, że klaster jest w trybie online co najmniej raz między dniem 46 i dniem 90, aby można było odnowić certyfikat.

Jeśli certyfikat tożsamości zarządzanej wygaśnie, zasób zostanie uznany Expired i wszystkie funkcje usługi Azure Arc (takie jak konfiguracja, monitorowanie i zasady) przestaną działać w klastrze.

Aby sprawdzić, kiedy certyfikat tożsamości zarządzanej wygaśnie dla danego klastra, uruchom następujące polecenie:

az connectedk8s show -n <name> -g <resource-group>

W danych wyjściowych wartość managedIdentityCertificateExpirationTime wskazuje, kiedy certyfikat tożsamości zarządzanej wygaśnie (znacznik 90D dla tego certyfikatu).

Jeśli wartość managedIdentityCertificateExpirationTime wskazuje znacznik czasu z przeszłości, connectivityStatus pole w powyższych danych wyjściowych zostanie ustawione na Expiredwartość . W takich przypadkach, aby ponownie pracować z klastrem Kubernetes z usługą Azure Arc:

1. Usuń zasób i agenci kubernetes z włączoną usługą Azure Arc w klastrze.

   az connectedk8s delete -n <name> -g <resource-group>
   

2. Utwórz ponownie zasób Kubernetes z włączoną usługą Azure Arc, wdrażając agentów w klastrze.

   az connectedk8s connect -n <name> -g <resource-group>
   

Jeśli korzystam już z potoków ciągłej integracji/ciągłego wdrażania, czy nadal mogę używać konfiguracji platformy Kubernetes z obsługą usługi Azure Arc lub usługi AKS i GitOps?

Tak, nadal można używać konfiguracji w klastrze odbierających wdrożenia za pośrednictwem potoku ciągłej integracji/ciągłego wdrażania. W porównaniu z tradycyjnymi potokami ciągłej integracji/ciągłego wdrażania konfiguracje usługi GitOps oferują pewne dodatkowe korzyści.

Uzgadnianie dryfu

Potok ciągłej integracji/ciągłego wdrażania stosuje zmiany tylko raz podczas uruchamiania potoku. Jednak operator GitOps w klastrze stale sonduje repozytorium Git, aby pobrać żądany stan zasobów Kubernetes w klastrze. Jeśli operator GitOps wykryje, że żądany stan zasobów różni się od rzeczywistego stanu zasobów w klastrze, ten dryf zostanie uzgodniony.

Stosowanie metodyki GitOps na dużą skalę

Potoki ciągłej integracji/ciągłego wdrażania są przydatne w przypadku wdrożeń opartych na zdarzeniach w klastrze Kubernetes (na przykład wypychania do repozytorium Git). Jednak aby wdrożyć tę samą konfigurację we wszystkich klastrach Kubernetes, należy ręcznie skonfigurować poświadczenia każdego klastra Kubernetes w potoku ciągłej integracji/ciągłego wdrażania.

W przypadku platformy Kubernetes z włączoną usługą Azure Arc, ponieważ usługa Azure Resource Manager zarządza konfiguracjami usługi GitOps, można zautomatyzować tworzenie tej samej konfiguracji we wszystkich zasobach Kubernetes i AKS z obsługą usługi Azure Arc przy użyciu usługi Azure Policy w zakresie subskrypcji lub grupy zasobów. Ta funkcja ma nawet zastosowanie do zasobów platformy Kubernetes i usługi AKS z obsługą usługi Azure Arc utworzonych po przypisaniu zasad.

Ta funkcja stosuje konfiguracje punktów odniesienia (takie jak zasady sieciowe, powiązania ról i zasady zabezpieczeń zasobników) w całym spisie klastra Kubernetes w celu spełnienia wymagań dotyczących zgodności i ładu.

Zgodność klastra

Stan zgodności każdej konfiguracji usługi GitOps jest zgłaszany z powrotem do platformy Azure. Dzięki temu można śledzić wszelkie nieudane wdrożenia.

Czy platforma Kubernetes z włączoną usługą Azure Arc przechowuje dane klientów poza regionem klastra?

Funkcja umożliwiająca przechowywanie danych klientów w jednym regionie jest obecnie dostępna tylko w regionie Azji Południowo-Wschodniej (Singapur) regionu Azja i Brazylia Południowa (Sao Paulo) Regionu Geograficznego Brazylii (Sao Paulo). W przypadku wszystkich innych regionów dane klientów są przechowywane w obszarze geograficznym. Dotyczy to rozszerzeń dostawcy wpisów tajnych usługi Open Service Mesh z obsługą usługi Azure Arc i azure Key Vault obsługiwanych w rozwiązaniu Kubernetes z obsługą usługi Azure Arc. Aby uzyskać informacje o innych rozszerzeniach klastra, zapoznaj się z ich dokumentacją, aby dowiedzieć się, jak przechowują dane klientów. Aby uzyskać więcej informacji, zobacz Centrum zaufania.

Następne kroki

• Zapoznaj się z naszym przewodnikiem Szybki start, aby połączyć klaster Kubernetes z usługą Azure Arc.
• Masz już klaster usługi AKS lub klaster Kubernetes z włączoną usługą Azure Arc? Utwórz konfiguracje GitOps w klastrze Kubernetes z włączoną usługą Azure Arc.
• Dowiedz się, jak skonfigurować potok ciągłej integracji/ciągłego wdrażania za pomocą metodyki GitOps.
• Dowiedz się, jak za pomocą usługi Azure Policy stosować konfiguracje na dużą skalę.
• Poznaj zautomatyzowane scenariusze platformy Kubernetes z obsługą usługi Azure Arc dzięki usłudze Azure Arc Jumpstart.