Limity czasu protokołu TCP, gdy narzędzie kubectl lub inne narzędzia innych firm łączą się z serwerem interfejsu API
W tym artykule omówiono sposób rozwiązywania problemów z limitami czasu protokołu TCP występującymi w przypadku użycia narzędzia kubectl lub innych narzędzi innych firm w celu nawiązania połączenia z serwerem interfejsu API w usłudze Microsoft Azure Kubernetes Service (AKS). Aby zapewnić cele poziomu usług (SLO) i umowy dotyczące poziomu usług (SLA), usługa AKS używa płaszczyzn kontroli wysokiej dostępności (HA), które są skalowane w pionie i w poziomie, na podstawie liczby rdzeni.
Symptomy
Występują powtarzające się przekroczenia limitu czasu połączenia.
Przyczyna 1: Zasobniki, które są odpowiedzialne za komunikację płaszczyzny sterowania węzłem, nie są uruchomione
Jeśli tylko kilka poleceń interfejsu API stale przekracza limit czasu, następujące zasobniki mogą nie być w stanie uruchomienia:
konnectivity-agenttunnelfrontaks-link
Uwaga 16.
W nowszych wersjach tunnelfront usługi AKS i aks-link są zastępowane elementem konnectivity-agent, więc zobaczysz konnectivity-agenttylko .
Te zasobniki są odpowiedzialne za komunikację między węzłem a płaszczyzną sterowania.
Rozwiązanie: Zmniejszenie wykorzystania lub przeciążenia hostów węzłów
Upewnij się, że węzły hostujące te zasobniki nie są nadmiernie używane lub przeciążone. Rozważ przeniesienie węzłów do własnej puli węzłów systemowych.
Aby sprawdzić, w którym węźle jest hostowany zasobnik konnectivity-agent i jak korzystać z węzła, uruchom następujące polecenia:
# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
# Check the usage of the node hosting the pod
$ kubectl top node
Przyczyna 2. Dostęp jest blokowany na niektórych wymaganych portach, nazwach FQDN i adresach IP
Jeśli wymagane porty, w pełni kwalifikowane nazwy domen (FQDN) i adresy IP nie są otwarte, kilka wywołań poleceń może zakończyć się niepowodzeniem. Bezpieczna, tunelowana komunikacja w usłudze AKS między serwerem interfejsu API a zasobnikem (za pośrednictwem konnectivity-agent zasobnika) wymaga pomyślnego działania niektórych z tych elementów.
Rozwiązanie: otwórz niezbędne porty, nazwy FQDN i adresy IP
Aby uzyskać więcej informacji na temat portów, nazw FQDN i adresów IP, które należy otworzyć, zobacz Reguły sieci wychodzącej i nazwy FQDN dla klastrów usługi Azure Kubernetes Service (AKS).
Przyczyna 3. Rozszerzenie TLS negocjacji protokołu Warstwy aplikacji jest zablokowane
Aby nawiązać połączenie między płaszczyzną sterowania i węzłami, konnectivity-agent zasobnik wymaga rozszerzenia Transport Layer Security (TLS) na potrzeby negocjacji protokołu warstwy aplikacji (ALPN). Być może to rozszerzenie zostało wcześniej zablokowane.
Rozwiązanie: Włączanie rozszerzenia ALPN
Włącz rozszerzenie ALPN na zasobniku konnectivity-agent , aby zapobiec przekroczeniu limitu czasu protokołu TCP.
Przyczyna 4. Zakresy autoryzowanych adresów IP serwera interfejsu API nie obejmują bieżącego adresu IP
Jeśli używasz autoryzowanych zakresów adresów IP na serwerze interfejsu API, wywołania interfejsu API będą blokowane, jeśli twój adres IP nie jest uwzględniony w autoryzowanych zakresach.
Rozwiązanie: Zmodyfikuj autoryzowane zakresy adresów IP, tak aby obejmowały twój adres IP
Zmień autoryzowane zakresy adresów IP, aby adres IP był objęty zakresem. Aby uzyskać więcej informacji, zobacz Aktualizowanie autoryzowanych zakresów adresów IP serwera interfejsu API klastra.
Przyczyna 5: Klient lub aplikacja przecieka wywołania do serwera interfejsu API
Częste wywołania GET mogą gromadzić i przeciążać serwer interfejsu API.
Rozwiązanie: Używaj zegarków zamiast wywołań GET, ale upewnij się, że aplikacja nie wycieka tych wywołań
Upewnij się, że używasz zegarków zamiast częstych wywołań GET do serwera interfejsu API. Należy również upewnić się, że aplikacje innych firm nie wyciekają żadnych połączeń kontrolnych ani wywołań GET. Na przykład w architekturze mikrousługi Istio usterka w aplikacji miksera tworzy nowe połączenie zegarka serwera interfejsu API za każdym razem, gdy wpis tajny jest odczytywany wewnętrznie. Ponieważ to zachowanie odbywa się w regularnych odstępach czasu, połączenia kontrolne szybko gromadzą się. Te połączenia ostatecznie powodują przeciążenie serwera interfejsu API niezależnie od wzorca skalowania.
Przyczyna 6. Zbyt wiele wersji we wdrożeniach programu Helm
Jeśli używasz zbyt wielu wydań we wdrożeniach programu Helm (menedżera pakietów Kubernetes), węzły zaczynają zużywać zbyt dużo pamięci. Powoduje to również dużą ilość ConfigMap obiektów (danych konfiguracji), co może spowodować niepotrzebne skoki użycia na serwerze interfejsu API.
Rozwiązanie: Ogranicz maksymalną liczbę poprawek dla każdej wersji
Ponieważ maksymalna liczba poprawek dla każdej wersji jest domyślnie nieskończona, należy uruchomić polecenie , aby ustawić tę maksymalną liczbę na rozsądną wartość. W przypadku programu Helm 2 polecenie to helm init. W przypadku programu Helm 3 polecenie to uaktualnienie narzędzia Helm. --history-max <value> Ustaw parametr podczas uruchamiania polecenia.
| Wersja | Polecenie |
|---|---|
| Helm 2 | helm init --history-max <maximum-number-of-revisions-per-release> ... |
| Helm 3 | helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ... |
Przyczyna 7. Ruch wewnętrzny między węzłami jest blokowany
W klastrze usługi AKS mogą występować blokady ruchu wewnętrznego między węzłami.
Rozwiązanie: Rozwiązywanie problemów z błędem "dial tcp Node_IP:10250: i/o timeout" (Wybieranie numeru tcp <Node_IP>:10250: przekroczenie limitu czasu operacji we/wy)
Przyczyna 8: Klaster jest prywatny
Klaster jest klastrem prywatnym, ale klient, z którego próbujesz uzyskać dostęp do serwera interfejsu API, znajduje się w publicznej lub innej sieci, która nie może połączyć się z podsiecią używaną przez usługę AKS.
Rozwiązanie: użyj klienta, który może uzyskać dostęp do podsieci usługi AKS
Ponieważ klaster jest prywatny, a jego płaszczyzna sterowania znajduje się w podsieci usługi AKS, nie można nawiązać połączenia z serwerem interfejsu API, chyba że znajduje się w sieci, która może łączyć się z podsiecią usługi AKS. Jest to oczekiwane zachowanie.
W takim przypadku spróbuj uzyskać dostęp do serwera interfejsu API z poziomu klienta w sieci, która może komunikować się z podsiecią usługi AKS. Ponadto sprawdź, czy sieciowe grupy zabezpieczeń lub inne urządzenia między sieciami nie blokują pakietów.
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 na temat platformy Azure.