Rozwiązywanie problemów z błędami podczas wdrażania rozszerzeń klastra usługi AKS
W tym artykule omówiono sposób rozwiązywania problemów z błędami występującymi podczas wdrażania rozszerzeń klastra dla usługi Microsoft Azure Kubernetes Service (AKS).
Błędy tworzenia rozszerzeń
Błąd: Nie można uzyskać odpowiedzi od agenta w czasie
Ten błąd występuje, jeśli usługi platformy Azure nie otrzymają odpowiedzi od agenta rozszerzenia klastra. Taka sytuacja może wystąpić, ponieważ klaster usługi AKS nie może nawiązać połączenia z platformą Azure.
Przyczyna 1. Agent rozszerzenia klastra i zasobniki menedżera nie są inicjowane
Agent rozszerzenia klastra i menedżer są kluczowymi składnikami systemu, które są odpowiedzialne za zarządzanie cyklem życia aplikacji Kubernetes. Inicjowanie agenta rozszerzenia klastra i zasobników menedżera może zakończyć się niepowodzeniem z powodu następujących problemów:
- Ograniczenia zasobów
- Ograniczenia zasad
- Defekty węzłów, takie jak
NoSchedule
Rozwiązanie 1. Upewnij się, że agent rozszerzenia klastra i zasobniki menedżera działają prawidłowo
Aby rozwiązać ten problem, upewnij się, że agent rozszerzenia klastra i zasobniki menedżera są prawidłowo zaplanowane i można je uruchomić. Jeśli zasobniki są zablokowane w stanie nieprzeczytanym, sprawdź opis zasobnika, uruchamiając następujące kubectl describe pod polecenie, aby uzyskać więcej szczegółów na temat podstawowych problemów (na przykład defektów, które uniemożliwiają planowanie, niewystarczającą ilość pamięci lub ograniczenia zasad):
kubectl describe pod -n kube-system extension-operator-{id}
Oto przykład danych wyjściowych polecenia:
kube-system extension-agent-55d4f4795f-sqx7q 2/2 Running 0 2d19h
kube-system extension-operator-56c8d5f96c-nvt7x 2/2 Running 0 2d19h
W przypadku klastrów połączonych z usługą ARC uruchom następujące polecenie, aby sprawdzić opis zasobnika:
kubectl describe pod -n azure-arc extension-manager-{id}
Oto przykład danych wyjściowych polecenia:
NAMESPACE NAME READY STATUS RESTARTS AGE
azure-arc cluster-metadata-operator-744f8bfbd4-7pssr 0/2 ImagePullBackOff 0 6d19h
azure-arc clusterconnect-agent-7557d99d5c-rtgqh 0/3 ImagePullBackOff 0 6d19h
azure-arc clusteridentityoperator-9b8b88f97-nr8hf 0/2 ImagePullBackOff 0 6d19h
azure-arc config-agent-6d5fd59b8b-khw2d 0/2 ImagePullBackOff 0 6d19h
azure-arc controller-manager-5bc97f7db6-rt2zs 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-events-collector-7596688867-sqzv2 0/2 ImagePullBackOff 0 6d19h
azure-arc extension-manager-86bbb949-6s59q 0/3 ImagePullBackOff 0 6d19h
azure-arc flux-logs-agent-5f55888db9-wnr4c 0/1 ImagePullBackOff 0 6d19h
azure-arc kube-aad-proxy-646c475dcc-92b86 0/2 ImagePullBackOff 0 6d19h
azure-arc logcollector-5cbc659bfb-9v96d 0/1 ImagePullBackOff 0 6d19h
azure-arc metrics-agent-5794866b46-j9949 0/2 ImagePullBackOff 0 6d19h
azure-arc resource-sync-agent-6cf4cf7486-flgwc 0/2 ImagePullBackOff 0 6d19h
Gdy agent rozszerzenia klastra i zasobniki menedżera działają i są w dobrej kondycji, ustanawiają komunikację z usługami platformy Azure w celu zainstalowania aplikacji Kubernetes i zarządzania nimi.
Przyczyna 2: Problem dotyczy bloku ruchu wychodzącego lub zapory
Jeśli agent rozszerzenia klastra i zasobniki menedżera są w dobrej kondycji i nadal występuje błąd "Nie można uzyskać odpowiedzi od agenta w czasie", prawdopodobnie istnieje problem z blokiem ruchu wychodzącego lub zaporą. Ten problem może zablokować komunikację agenta rozszerzenia klastra i zasobników menedżera z platformą Azure.
Rozwiązanie 2. Upewnij się, że zostały spełnione wymagania wstępne dotyczące sieci
Aby rozwiązać ten problem, upewnij się, że zostały spełnione wymagania wstępne dotyczące sieci opisane w temacie Reguły sieci wychodzącej i nazwy FQDN dla klastrów usługi Azure Kubernetes Service (AKS).
Przyczyna 3: Ruch nie jest autoryzowany
Agent rozszerzenia bezskutecznie próbuje wywołać <region>.dp.kubernetesconfiguration.azure.com punkty końcowe usługi płaszczyzny danych. Ten błąd generuje wpis "Kod błędu: 403, Komunikat Ten ruch nie jest autoryzowany" w dziennikach zasobnika agenta rozszerzenia.
kubectl logs -n kube-system extension-agent-<pod-guid>
{ "Message": "2024/02/07 06:04:43 \"Errorcode: 403, Message This traffic is not authorized., Target /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/provider/managedclusters/clusters/<cluster-name>/configurations/getPendingConfigs\"", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>, "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
{ "Message": "2024/02/07 06:04:43 Failed to GET configurations with err : {\u003cnil\u003e}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5", "AgentTimestamp": "2024/02/07 06:04:43.672" }
Ten błąd występuje, jeśli wstępnie istniejącego elementu PrivateLinkScope istnieje na płaszczyźnie danych rozszerzenia dla platformy Kubernetes z włączoną usługą Azure Arc, a sieć wirtualna (lub prywatny serwer DNS) jest współużytkowana między platformą Kubernetes z włączoną usługą Azure Arc a klastrem zarządzanym przez usługę AKS. Ta konfiguracja sieci powoduje, że ruch wychodzący usługi AKS z płaszczyzny danych rozszerzenia będzie również kierowany przez ten sam prywatny adres IP zamiast za pośrednictwem publicznego adresu IP.
Uruchom następujące polecenie nslookup w klastrze usługi AKS, aby pobrać konkretny prywatny adres IP rozpoznawany przez punkt końcowy płaszczyzny danych:
PS D:\> kubectl exec -it -n kube-system extension-agent-<pod-guid> -- nslookup <region>.dp.kubernetesconfiguration.azure.com
Non-authoritative answer:
<region>.dp.kubernetesconfiguration.azure.com canonical name = <region>.privatelink.dp.kubernetesconfiguration.azure.com
Name: <region>.privatelink.dp.kubernetesconfiguration.azure.com
Address: 10.224.1.184
Podczas wyszukiwania prywatnego adresu IP w witrynie Azure Portal wyniki wyszukiwania wskazują dokładny zasób: sieć wirtualna, prywatną strefę DNS, prywatny serwer DNS itd. Ten zasób ma prywatny punkt końcowy skonfigurowany dla płaszczyzny danych rozszerzenia dla platformy Kubernetes z obsługą usługi Azure Arc.
Rozwiązanie 3.1: (Zalecane) Tworzenie oddzielnych sieci wirtualnych
Aby rozwiązać ten problem, zalecamy utworzenie oddzielnych sieci wirtualnych dla obliczeń platformy Kubernetes z obsługą usługi Azure Arc i usługi AKS.
Rozwiązanie 3.2: Tworzenie przesłonięcia usługi CoreDNS
Jeśli zalecane rozwiązanie nie jest możliwe w Twojej sytuacji, utwórz zastąpienie CoreDNS dla punktu końcowego płaszczyzny danych rozszerzenia, aby przejść przez sieć publiczną. Aby uzyskać więcej informacji na temat dostosowywania usługi CoreDNS, zobacz sekcję "Wtyczka hostów" "Dostosowywanie sieci CoreDNS za pomocą usługi Azure Kubernetes Service".
Aby utworzyć zastąpienie usługi CoreDNS, wykonaj następujące kroki:
Znajdź publiczny adres IP punktu końcowego płaszczyzny danych rozszerzenia, uruchamiając
nslookuppolecenie . Upewnij się, że region (na przykładeastus2euap) został zmieniony na podstawie lokalizacji klastra usługi AKS:nslookup <region>.dp.kubernetesconfiguration.azure.com Non-authoritative answer: Name: clusterconfig<region>.<region>.cloudapp.azure.com Address: 20.39.12.229 Aliases: <region>.dp.kubernetesconfiguration.azure.com <region>.privatelink.dp.kubernetesconfiguration.azure.com <region>.dp.kubernetesconfiguration.trafficmanager.netUtwórz kopię zapasową istniejącej konfiguracji coreDNS:
kubectl get configmap -n kube-system coredns-custom -o yaml > coredns.backup.yamlZastąp mapowanie regionalnego punktu końcowego płaszczyzny danych (na przykład
eastus2euap) na publiczny adres IP. W tym celu utwórz plik YAML o nazwie corednsms.yaml, a następnie skopiuj następującą przykładową konfigurację do nowego pliku. (Upewnij się, że adres i nazwa hosta są aktualizowane przy użyciu wartości środowiska).apiVersion: v1 kind: ConfigMap metadata: name: coredns-custom # This is the name of the configuration map that you can overwrite with your changes. namespace: kube-system data: extensionsdp.override: | # You can select any name here, but it must have the .override file name extension. hosts { 20.39.12.229 <region>.dp.kubernetesconfiguration.azure.com fallthrough }Aby utworzyć ConfigMap, uruchom
kubectl applypolecenie , określając nazwę pliku manifestu YAML:kubectl apply -f corednsms.yamlAby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, uruchom polecenie ponownego uruchamiania wdrożenia kubectl:
kubectl -n kube-system rollout restart deployment corednsnslookupUruchom ponownie polecenie, aby upewnić się, że punkt końcowy płaszczyzny danych jest rozpoznawany jako podany publiczny adres IP:kubectl exec -it -n kube-system extension-agent-55d4f4795f-nld9q -- nslookup [region].dp.kubernetesconfiguration.azure.com Name: <region>.dp.kubernetesconfiguration.azure.com Address: 20.39.12.229
Dzienniki zasobników agenta rozszerzenia nie powinny już rejestrować wpisów błędów "Kod błędu: 403, komunikat Ten ruch nie jest autoryzowany". Zamiast tego dzienniki powinny zawierać kody odpowiedzi "200".
kubectl logs -n kube-system extension-agent-{id}
{ "Message": "GET configurations returned response code {200}", "LogType": "ConfigAgentTrace", "LogLevel": "Information", "Environment": "prod", "Role": "ClusterConfigAgent", "Location": "<region>", "ArmId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.ContainerService/managedclusters/<cluster-name>", "CorrelationId": "", "AgentName": "ConfigAgent", "AgentVersion": "1.14.5" }
Błąd: Zasobniki rozszerzeń nie mogą być zaplanowane, jeśli wszystkie pule węzłów w klastrze są skażone "CriticalAddonsOnly"
W przypadku wystąpienia tego błędu w dzienniku agenta rozszerzenia jest rejestrowany następujący wpis:
Błąd zasobnika rozszerzenia: dostępne są węzły 0/2: 2 węzły miały nieopowiedziane właściwości {CriticalAddonsOnly: true}. Wywłaszczanie: dostępne są węzły 0/2: 2 Wywłaszczanie nie jest przydatne do planowania.
Przyczyna
Ten błąd występuje podczas próby włączenia rozszerzeń (takich jak rozproszone środowisko uruchomieniowe aplikacji (DAPR) w klastrze usługi AKS, który ma CriticalAddonsOnly skażone pule węzłów. W takiej sytuacji zasobniki rozszerzeń nie są zaplanowane w żadnym węźle, ponieważ nie ma tolerancji dla tych defektów.
Aby wyświetlić sytuację błędu, sprawdź zasobniki rozszerzeń, aby sprawdzić, czy są one zablokowane w stanie oczekiwania:
kubectl get po -n {namespace-name} -l app.kubernetes.io/name={name}
NAME READY STATUS RESTARTS AGE
{podname} 0/2 Pending 0 2d6h
Opisz zasobniki, aby zobaczyć, że nie można ich zaplanować z powodu nieobsługiwalnego defektu:
kubectl describe po -n {namespace-name} {podname}
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 18s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {CriticalAddonsOnly: true}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
Uwaga 16.
Zalecamy, aby nie instalować rozszerzeń w
CriticalAddOnsOnlyniezatłoczonych pulach węzłów, chyba że jest to wymagane w przypadku obciążeń aplikacji.Zalecamy, aby nie używać defektu
CriticalAddOnsOnlyw klastrach puli z jednym węzłem. Jeśli używasz tego defektu w klastrze, który ma tylko jedną pulę węzłów, nie można zaplanować zasobników aplikacji w klastrze. Upewnij się, że co najmniej jedna pula węzłów w klastrze nie ma tego defektu. Aby uzyskać więcej informacji na temat sposobuCriticalAddonsOnlyużycia adnotacji, zobacz Zarządzanie pulami węzłów systemowych w usłudze Azure Kubernetes Service (AKS).
Rozwiązanie 1. Dodawanie puli węzłów do klastra
Aby rozwiązać ten problem, dodaj jeszcze jedną pulę węzłów, która nie ma defektu CriticalAddonsOnly . Ta akcja powoduje zaplanowanie zasobników rozszerzeń w nowej puli węzłów.
Rozwiązanie 2. Usuwanie defektu "CriticalAddonsOnly"
Jeśli jest to możliwe i praktyczne, możesz usunąć CriticalAddonsOnly defekt, aby zainstalować rozszerzenie w klastrze.
Błędy programu Helm
Mogą wystąpić dowolne z następujących błędów związanych z programem Helm:
- Upłynął limit czasu oczekiwania na gotowość zasobów
- Nie można pobrać wykresu Helm z adresu URL repozytorium
- Renderowanie wykresu Helm z podanymi wartościami nie powiodło się
- Zasób już istnieje w klastrze
- Operacja jest już w toku dla programu Helm
Błąd: Przekroczono limit czasu oczekiwania na gotowość zasobów
Instalacja aplikacji Kubernetes kończy się niepowodzeniem i wyświetla następujące komunikaty o błędach:
zadanie nie powiodło się: BackoffLimitExceeded
Przekroczono limit czasu oczekiwania na powrót zasobu do stanu gotowego/ukończonego.
Przyczyna
Ten problem ma następujące typowe przyczyny:
Ograniczenia zasobów: Niewystarczająca ilość pamięci lub zasobów procesora CPU w klastrze może uniemożliwić pomyślne zainicjowanie zasobników, zadań lub innych zasobów Kubernetes. W końcu taka sytuacja powoduje przekroczenie limitu czasu instalacji. Ograniczenia zasad lub defekty węzłów (takie jak
NoSchedule) mogą również blokować inicjowanie zasobów.Niezgodność architektury: próba zaplanowana aplikacji opartej na systemie Linux na węźle opartym na systemie Windows (lub odwrotnie) może spowodować błędy inicjowania zasobów Kubernetes.
Nieprawidłowe ustawienia konfiguracji: Nieprawidłowe ustawienia konfiguracji mogą uniemożliwić uruchamianie zasobników.
Rozwiązanie
Aby rozwiązać ten problem, wykonaj następujące kroki:
Sprawdź zasoby: upewnij się, że klaster Kubernetes ma wystarczające zasoby i że planowanie zasobników jest dozwolone w węzłach (należy rozważyć defekty). Sprawdź, czy zasoby pamięci i procesora CPU spełniają wymagania.
Sprawdzanie zdarzeń: sprawdź zdarzenia w przestrzeni nazw kubernetes, aby zidentyfikować potencjalne problemy, które mogą uniemożliwić zasobnikom, zadaniam lub innym zasobom Kubernetes osiągnięcie stanu gotowości.
Sprawdź wykresy i konfiguracje programu Helm: wiele aplikacji Kubernetes używa wykresów Helm do wdrażania zasobów w klastrze. Niektóre aplikacje mogą wymagać danych wejściowych użytkownika za pośrednictwem ustawień konfiguracji. Upewnij się, że wszystkie podane wartości konfiguracji są dokładne i spełniają wymagania instalacji.
Błąd: Nie można pobrać wykresu Helm z adresu URL repozytorium
Ten błąd jest spowodowany problemami z łącznością między klastrem a zaporą oprócz problemów z blokowaniem ruchu wychodzącego. Aby rozwiązać ten problem, zobacz Reguły sieci wychodzącej i nazwy FQDN dla klastrów usługi Azure Kubernetes Service (AKS).
Błąd: renderowanie wykresu helm nie powiodło się z podanymi wartościami
Ten błąd występuje, jeśli aplikacje Kubernetes korzystają z wykresów Helm w celu wdrożenia zasobów w klastrze Kubernetes. Te aplikacje mogą wymagać danych wejściowych użytkownika udostępnianych za pośrednictwem ustawień konfiguracji, które są przekazywane jako wartości programu Helm podczas instalacji. Jeśli brakuje żadnego z tych kluczowych ustawień konfiguracji lub są one nieprawidłowe, wykres Helm może nie być renderowany.
Aby rozwiązać ten problem, sprawdź dokumentację rozszerzenia lub aplikacji, aby określić, czy pominięto wszystkie obowiązkowe wartości, czy podano nieprawidłowe wartości podczas instalacji aplikacji. Te wytyczne mogą pomóc w rozwiązaniu problemów z renderowaniem wykresu programu Helm, które są spowodowane brakującymi lub niedokładnymi wartościami konfiguracji.
Błąd: Zasób już istnieje w klastrze
Ten błąd występuje, jeśli istnieje konflikt między zasobami Kubernetes w klastrze i zasobami Kubernetes, które aplikacja próbuje zainstalować. Komunikat o błędzie zwykle określa nazwę zasobu powodującego konflikt.
Jeśli zasób powodujący konflikt jest niezbędny i nie można go zamienić, być może nie będzie można zainstalować aplikacji. Jeśli zasób nie jest krytyczny i można go usunąć, usuń zasób powodujący konflikt, a następnie spróbuj ponownie zainstalować.
Błąd: Operacja jest już w toku dla programu Helm
Ten błąd występuje, jeśli operacja jest już w toku dla określonej wersji. Aby rozwiązać ten problem, poczekaj 10 minut, a następnie spróbuj ponownie wykonać operację.
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.