Rozwiązywanie problemów z serwerem interfejsu API itp. w usługach Azure Kubernetes Services
Ten przewodnik ma na celu ułatwienie identyfikowania i rozwiązywania wszelkich mało prawdopodobnych problemów, które mogą wystąpić na serwerze interfejsu API w dużych wdrożeniach usługi Microsoft Azure Kubernetes Services (AKS).
Firma Microsoft przetestowała niezawodność i wydajność serwera interfejsu API w skali 5000 węzłów i 200 000 zasobników. Klaster zawierający serwer interfejsu API ma możliwość automatycznego skalowania w poziomie i dostarczania celów poziomu usług Kubernetes (SLO). Jeśli wystąpią duże opóźnienia lub przekroczenia limitu czasu, prawdopodobnie jest to spowodowane wyciekiem zasobów w katalogu rozproszonym etc (itp.) lub nieprawidłowy klient ma nadmierne wywołania interfejsu API.
Wymagania wstępne
Narzędzie Kubernetes kubectl . Aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli .
Dzienniki diagnostyczne usługi AKS (w szczególności zdarzenia kube-audit), które są włączone i wysyłane do obszaru roboczego usługi Log Analytics. Aby określić, czy dzienniki są zbierane przy użyciu trybu diagnostyki specyficznej dla zasobu lub usługi Azure, sprawdź blok Ustawienia diagnostyczne w Azure Portal.
Warstwa Standardowa dla klastrów usługi AKS. Jeśli używasz warstwy Bezpłatna, serwer interfejsu API itp. zawiera ograniczone zasoby. Klastry usługi AKS w warstwie Bezpłatna nie zapewniają wysokiej dostępności. Często jest to główna przyczyna problemów z serwerem interfejsu API i itd.
Wtyczka kubectl-aks do uruchamiania poleceń bezpośrednio w węzłach usługi AKS bez użycia płaszczyzny sterowania Kubernetes.
Symptomy
W poniższej tabeli przedstawiono typowe objawy awarii serwera interfejsu API:
| Objaw | Opis |
|---|---|
| Limity czasu z serwera interfejsu API | Częste limity czasu wykraczają poza gwarancje w umowie SLA serwera interfejsu API usługi AKS. Na przykład kubectl limit czasu poleceń. |
| Duże opóźnienia | Duże opóźnienia, które sprawiają, że obiekty SLO platformy Kubernetes ulegają awarii. Na przykład kubectl wyświetlenie listy zasobników trwa dłużej niż 30 sekund. |
Zasobnik serwera interfejsu API w CrashLoopbackOff stanie lub napotkane błędy wywołań elementu webhook |
Sprawdź, czy nie masz żadnego niestandardowego elementu webhook dopuszczenia (takiego jak aparat zasad Kyverno ), który blokuje wywołania serwera interfejsu API. |
Lista kontrolna rozwiązywania problemów
Jeśli występują duże opóźnienia, wykonaj następujące kroki, aby wskazać klienta powodującego błąd i typy wywołań interfejsu API, które kończą się niepowodzeniem.
Krok 1. Identyfikowanie najpopularniejszych agentów użytkowników według liczby żądań
Aby określić, którzy klienci generują najwięcej żądań (i potencjalnie największe obciążenie serwera interfejsu API), uruchom zapytanie podobne do następującego kodu. Poniższe zapytanie zawiera listę 10 pierwszych agentów użytkowników według liczby wysłanych żądań serwera interfejsu API.
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| summarize count() by UserAgent
| top 10 by count_
| project UserAgent, count_
Uwaga
Jeśli zapytanie nie zwraca żadnych wyników, być może wybrano nieprawidłową tabelę do wykonywania zapytań dotyczących dzienników diagnostycznych. W trybie specyficznym dla zasobu dane są zapisywane w poszczególnych tabelach w zależności od kategorii zasobu. Dzienniki diagnostyczne są zapisywane w AKSAudit tabeli. W trybie diagnostyki platformy Azure wszystkie dane są zapisywane w AzureDiagnostics tabeli. Aby uzyskać więcej informacji, zobacz Dzienniki zasobów platformy Azure.
Chociaż warto wiedzieć, którzy klienci generują najwyższy wolumin żądań, sam duży wolumin żądań może nie być powodem do niepokoju. Lepszym wskaźnikiem rzeczywistego obciążenia, które każdy klient generuje na serwerze interfejsu API, jest opóźnienie odpowiedzi, które występuje.
Krok 2. Identyfikowanie i przedstawianie średniego opóźnienia żądań serwera interfejsu API na agenta użytkownika
Aby zidentyfikować średnie opóźnienie żądań serwera interfejsu API na agenta użytkownika wykreślonych na wykresie czasowym, uruchom następujące zapytanie:
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize avg(latency) by UserAgent, bin(start_time, 5m)
| render timechart
To zapytanie jest kontynuacją zapytania w sekcji "Identyfikowanie najlepszych agentów użytkowników według liczby żądań" . Może to dać więcej informacji na temat rzeczywistego obciążenia generowanego przez każdego agenta użytkownika w czasie.
Porada
Analizując te dane, można zidentyfikować wzorce i anomalie, które mogą wskazywać problemy w klastrze lub aplikacjach usługi AKS. Można na przykład zauważyć, że określony użytkownik ma duże opóźnienia. Ten scenariusz może wskazywać typ wywołań interfejsu API, które powodują nadmierne obciążenie serwera interfejsu API lub itp.
Krok 3. Identyfikowanie nieprawidłowych wywołań interfejsu API dla danego agenta użytkownika
Uruchom następujące zapytanie, aby tabulacji 99 percentyla (P99) opóźnienia wywołań interfejsu API w różnych typach zasobów dla danego klienta:
AKSAudit
| where TimeGenerated between(now(-1h)..now()) // When you experienced the problem
| extend HttpMethod = Verb
| extend Resource = tostring(ObjectRef.resource)
| where UserAgent == "DUMMYUSERAGENT" // Filter by name of the useragent you are interested in
| where Resource != ""
| extend start_time = RequestReceivedTime
| extend end_time = StageReceivedTime
| extend latency = datetime_diff('millisecond', end_time, start_time)
| summarize p99latency=percentile(latency, 99) by HttpMethod, Resource
| render table
Wyniki tego zapytania mogą być przydatne do identyfikowania rodzajów wywołań interfejsu API, które nie obsługują nadrzędnych obiektów SLO platformy Kubernetes. W większości przypadków obraźliwy klient może wykonywać zbyt wiele LIST wywołań dla dużego zestawu obiektów lub obiektów, które są zbyt duże. Niestety nie są dostępne żadne twarde limity skalowalności, które ułatwiają użytkownikom skalowalność serwera interfejsu API. Limity skalowalności serwera interfejsu API lub itp. zależą od różnych czynników objaśnianych w progach skalowalności platformy Kubernetes.
Przyczyna 1. Reguła sieci blokuje ruch z węzłów agenta do serwera interfejsu API
Reguła sieciowa może blokować ruch między węzłami agenta a serwerem interfejsu API.
Aby sprawdzić, czy nieprawidłowo skonfigurowane zasady sieciowe blokują komunikację między serwerem interfejsu API a węzłami agenta, uruchom następujące polecenia kubectl-aks :
kubectl aks config import \
--subscription <mySubscriptionID> \
--resource-group <myResourceGroup> \
--cluster-name <myAKSCluster>
kubectl aks check-apiserver-connectivity --node <myNode>
Polecenie importowania konfiguracji pobiera informacje o zestawie skalowania maszyn wirtualnych dla wszystkich węzłów w klastrze. Następnie polecenie check-apiserver-connectivity używa tych informacji do weryfikowania łączności sieciowej między serwerem interfejsu API a określonym węzłem, specjalnie dla jego bazowego wystąpienia zestawu skalowania.
Uwaga
Jeśli dane wyjściowe check-apiserver-connectivity polecenia zawierają Connectivity check: succeeded komunikat, łączność sieciowa jest niezakłócona.
Rozwiązanie 1. Napraw zasady sieciowe w celu usunięcia blokady ruchu
Jeśli dane wyjściowe polecenia wskazują, że wystąpił błąd połączenia, skonfiguruj ponownie zasady sieciowe, aby nie blokowały niepotrzebnie ruchu między węzłami agenta a serwerem interfejsu API.
Przyczyna 2: Powodujące nieszczelność klienta itp. obiektów i powoduje spowolnienie itd.
Typowym problemem jest ciągłe tworzenie obiektów bez usuwania nieużywanych obiektów w bazie danych itp. Może to powodować problemy z wydajnością, gdy etcd zajmuje się zbyt dużą liczbą obiektów (ponad 10 000) dowolnego typu. Szybki wzrost zmian w takich obiektach może również spowodować przekroczenie rozmiaru etcd bazy danych (domyślnie 4 gigabajty).
Aby sprawdzić użycie bazy danych itp., przejdź do pozycji Diagnozowanie i rozwiązywanie problemów w Azure Portal. Uruchom narzędzie do diagnostyki problemów z dostępnością etcd , wyszukując ciąg "etcd" w polu wyszukiwania. Narzędzie do diagnostyki przedstawia podział użycia i całkowity rozmiar bazy danych.
Jeśli chcesz tylko szybko wyświetlić bieżący rozmiar bazy danych etcd w bajtach, uruchom następujące polecenie:
kubectl get --raw /metrics | grep -E "etcd_db_total_size_in_bytes|apiserver_storage_size_bytes|apiserver_storage_db_total_size_in_bytes"
Uwaga
Nazwa metryki w poprzednim poleceniu jest inna dla różnych wersji platformy Kubernetes. W przypadku platformy Kubernetes w wersji 1.25 lub starszej użyj polecenia etcd_db_total_size_in_bytes. W przypadku platformy Kubernetes w wersji od 1.26 do 1.28 użyj polecenia apiserver_storage_db_total_size_in_bytes.
Rozwiązanie 2. Definiowanie przydziałów na potrzeby tworzenia obiektów, usuwania obiektów lub ograniczania okresu istnienia obiektu itp.
Aby zapobiec osiągnięciu pojemności itp. i spowodowaniu przestoju klastra, można ograniczyć maksymalną liczbę utworzonych zasobów. Możesz również spowolnić liczbę poprawek generowanych dla wystąpień zasobów. Aby ograniczyć liczbę obiektów, które można utworzyć, można zdefiniować przydziały obiektów.
Jeśli zidentyfikowano obiekty, które nie są już używane, ale zajmują zasoby, rozważ ich usunięcie. Możesz na przykład usunąć ukończone zadania, aby zwolnić miejsce:
kubectl delete jobs --field-selector status.successful=1
W przypadku obiektów, które obsługują automatyczne oczyszczanie, można ustawić wartość Czas wygaśnięcia (TTL), aby ograniczyć okres istnienia tych obiektów. Możesz również oznaczyć etykietami obiekty, aby można było zbiorczo usunąć wszystkie obiekty określonego typu przy użyciu selektorów etykiet. Jeśli ustanowisz odwołania właściciela między obiektami, wszystkie obiekty zależne zostaną automatycznie usunięte po usunięciu obiektu nadrzędnego.
Przyczyna 3. Klient powodujący błąd wykonuje nadmierne wywołania LISTY lub PUT
Jeśli ustalisz, że etcd nie jest przeciążony zbyt wieloma obiektami, obraźliwy klient może wykonywać zbyt wiele LIST wywołań lub PUT wywoływać serwer interfejsu API.
Rozwiązanie 3a: Dostrajanie wzorca wywołań interfejsu API
Rozważ dostrojenie wzorca wywołania interfejsu API klienta, aby zmniejszyć nacisk na płaszczyznę sterowania.
Rozwiązanie 3b: Ograniczanie klienta, który przeciąża płaszczyznę sterowania
Jeśli nie możesz dostroić klienta, możesz użyć funkcji Priorytet i sprawiedliwość na platformie Kubernetes, aby ograniczyć obciążenie klienta. Ta funkcja może pomóc w zachowaniu kondycji płaszczyzny sterowania i zapobiec awarii innych aplikacji.
W poniższej procedurze przedstawiono sposób ograniczania interfejsu API zasobników LISTY klienta, który ma zostać ustawiony na pięć równoczesnych wywołań:
Twórca flowschema, który pasuje do wzorca wywołania interfejsu API klienta powodującego niezgodność:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2 kind: FlowSchema metadata: name: restrict-bad-client spec: priorityLevelConfiguration: name: very-low-priority distinguisherMethod: type: ByUser rules: - resourceRules: - apiGroups: [""] namespaces: ["default"] resources: ["pods"] verbs: ["list"] subjects: - kind: ServiceAccount serviceAccount: name: bad-client-account namespace: defaultTwórca konfiguracji o niższym priorytecie w celu ograniczenia nieprawidłowych wywołań interfejsu API klienta:
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2 kind: PriorityLevelConfiguration metadata: name: very-low-priority spec: limited: assuredConcurrencyShares: 5 limitResponse: type: Reject type: LimitedObserwuj wywołanie ograniczone w metrykach serwera interfejsu API.
kubectl get --raw /metrics | grep "restrict-bad-client"
Przyczyna 4. Niestandardowy element webhook może spowodować zakleszczenie w zasobnikach serwera interfejsu API
Niestandardowy element webhook, taki jak Kyverno, może powodować zakleszczenie w zasobnikach serwera interfejsu API.
Sprawdź zdarzenia związane z serwerem interfejsu API. Mogą zostać wyświetlone komunikaty zdarzeń podobne do następującego tekstu:
Wystąpił błąd wewnętrzny: nie można wywołać elementu webhook "mutate.kyverno.svc-fail": nie można wywołać elementu webhook: Post "https://kyverno-system-kyverno-system-svc.kyverno-system.svc:443/mutate/fail?timeout=10s": write unix @->/tunnel-uds/proxysocket: write: broken pipe
W tym przykładzie element webhook weryfikacji blokuje tworzenie niektórych obiektów serwera interfejsu API. Ponieważ ten scenariusz może wystąpić w czasie rozruchu, nie można utworzyć serwera interfejsu API i zasobników Konnectivity. W związku z tym element webhook nie może nawiązać połączenia z tymi zasobnikami. Ta sekwencja zdarzeń powoduje zakleszczenie i komunikat o błędzie.
Rozwiązanie 4. Usuwanie konfiguracji elementu webhook
Aby rozwiązać ten problem, usuń konfiguracje elementów webhook weryfikujące i mutujące. Aby usunąć te konfiguracje elementów webhook w aplikacji Kyverno, zapoznaj się z artykułem dotyczącym rozwiązywania problemów z kyverno.
Wyłączenie odpowiedzialności za kontakty z osobami trzecimi
Firma Microsoft udostępnia informacje kontaktowe innych firm, które ułatwiają znalezienie dodatkowych informacji na ten temat. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.
Zastrzeżenie dotyczące innych firm
Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.
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 platformy Azure.