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?
Obecnie łączenie klastra usługi Azure Kubernetes Service (AKS) z usługą Azure Arc nie jest wymagane w przypadku większości scenariuszy. Możesz połączyć klaster, aby uruchomić niektóre usługi z obsługą usługi Azure Arc, takie jak App Services i Data Services, w oparciu o klaster. Można to zrobić przy użyciu funkcji lokalizacji niestandardowych platformy Kubernetes z obsługą usługi Azure Arc.
Czy mam połączyć klaster AKS-HCI i klastry Kubernetes w usłudze Azure Stack Edge z usługą Azure Arc?
Łączenie klastra AKS-HCI lub klastrów Kubernetes w usłudze 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.
Jeśli klaster Kubernetes z włączoną usługą Azure Arc znajduje się w usłudze Azure Stack Edge, usługa AKS w usłudze Azure Stack HCI (>= aktualizacja z kwietnia 2021 r.) lub usługa 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 Expired
wartość . W takich przypadkach, aby ponownie pracować z klastrem Kubernetes z usługą Azure Arc:
Usuń zasób i agenci kubernetes z włączoną usługą Azure Arc w klastrze.
az connectedk8s delete -n <name> -g <resource-group>
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>
Uwaga
az connectedk8s delete
spowoduje również usunięcie konfiguracji i rozszerzeń klastra na początku klastra. Po uruchomieniu az connectedk8s connect
programu utwórz ponownie konfiguracje i rozszerzenia klastra w klastrze ręcznie lub przy użyciu usługi Azure Policy.
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.