Problemy z łącznością z aplikacją Tunnel

Usługa Microsoft Azure Kubernetes Service (AKS) używa określonego składnika do tunelowania, bezpiecznej komunikacji między węzłami a płaszczyzną sterowania. Tunel składa się z serwera po stronie płaszczyzny sterowania i klienta po stronie węzłów klastra. W tym artykule omówiono, jak diagnozować i rozwiązywać problemy związane z łącznością tunelową w usłudze AKS.

Uwaga

Wcześniej składnik tunelu AKS był tunnel-front. Została ona teraz zmigrowana do usługi Konnectivity , nadrzędnego składnika Kubernetes. Aby uzyskać więcej informacji na temat tej migracji, zobacz informacje o wersji usługi AKS i dziennik zmian.

Wymagania wstępne

• Azure CLI

Symptomy

Zostanie wyświetlony komunikat o błędzie podobny do następujących przykładów dotyczących portu 10250:

Błąd z serwera: Pobierz "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: i/o timeout

Błąd z serwera: błąd połączenia z zapleczem: połączenie tcp <aks-node-ip>:10250: przekroczenie limitu czasu operacji we/wy

Błąd z serwera: Pobierz "https://< aks-node-name>:10250/containerLogs/<name>/<pod-name>/<container-name>": http: serwer udzielił odpowiedzi HTTP na klienta HTTPS

Serwer interfejsu API Kubernetes używa portu 10250 do nawiązania połączenia z węzłem kubelet w celu pobrania dzienników. Jeśli port 10250 zostanie zablokowany, dzienniki kubectl i inne funkcje będą działać tylko dla zasobników uruchamianych w węzłach, w których zaplanowano składnik tunelu. Aby uzyskać więcej informacji, zobacz Porty i protokoły Kubernetes: Węzły robocze.

Ponieważ nie można ustanowić składników tunelu lub łączności między serwerem a klientem, funkcje takie jak następujące nie będą działać zgodnie z oczekiwaniami:

• Elementy webhook kontrolera dostępu

• Możliwość pobierania dziennika (za pomocą polecenia kubectl logs )

• Uruchamianie polecenia w kontenerze lub uzyskiwanie do wewnątrz kontenera (przy użyciu polecenia kubectl exec )

• Przekazywanie lokalnych portów jednego lub więcej zasobników (używając polecenia kubectl port-forward)

Przyczyna 1. Sieciowa grupa zabezpieczeń blokuje port 10250

Uwaga

Ta przyczyna dotyczy wszystkich komponentów tunelu, które mogą znajdować się w klastrze usługi AKS.

Możesz użyć sieciowej grupy zabezpieczeń platformy Azure do filtrowania ruchu sieciowego do i z zasobów platformy Azure w sieci wirtualnej platformy Azure. Sieciowa grupa zabezpieczeń zawiera reguły zabezpieczeń, które zezwalają lub blokują ruch sieciowy przychodzący i wychodzący między kilkoma typami zasobów platformy Azure. Dla każdej reguły można określić źródło i obiekt docelowy, port i protokół. Aby uzyskać więcej informacji, zobacz Jak sieciowe grupy zabezpieczeń filtrować ruch sieciowy.

Jeśli sieciowa grupa zabezpieczeń blokuje port 10250 na poziomie sieci wirtualnej, funkcje tunelu (takie jak dzienniki i wykonywanie kodu) będą działać tylko dla zasobników zaplanowanych w węzłach, w których zaplanowano zasobniki tunelu. Inne pody nie będą działać, ponieważ ich węzły nie będą mogły dotrzeć do tunelu, a tunel jest przypisany do innych węzłów. Aby sprawdzić ten stan, możesz przetestować łączność przy użyciu poleceń netcat (nc) lub telnet. Możesz uruchomić polecenie az vmss run-command invoke, aby przeprowadzić test łączności i sprawdzić, czy zakończy się powodzeniem, przekroczeniem limitu czasu lub innym problemem.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

Rozwiązanie 1: Dodaj regułę NSG w celu zezwolenia na dostęp do portu 10250

Jeśli używasz sieciowej grupy zabezpieczeń i masz określone ograniczenia, upewnij się, że dodano regułę zabezpieczeń zezwalającą na ruch dla portu 10250 na poziomie sieci wirtualnej. Poniższy obraz witryny Azure Portal przedstawia przykładową regułę zabezpieczeń:

Jeśli chcesz być bardziej restrykcyjny, możesz zezwolić na dostęp do portu 10250 tylko na poziomie podsieci.

Uwaga

• Należy odpowiednio dostosować pole Priorytet . Jeśli na przykład masz regułę, która blokuje wiele portów (w tym port 10250), reguła wyświetlana na obrazie powinna mieć niższy numer priorytetu (niższe liczby mają wyższy priorytet). Aby uzyskać więcej informacji na temat priorytetu, zobacz Reguły zabezpieczeń.

• Jeśli po zastosowaniu tego rozwiązania nie widzisz żadnych zmian behawioralnych, możesz ponownie utworzyć zasobniki składnika tunelu. Usunięcie tych zasobników powoduje ich ponowne utworzenie.

Przyczyna 2. Narzędzie nieskomplikowanej zapory (UFW) blokuje port 10250

Uwaga

Ta przyczyna dotyczy dowolnego komponentu tunelu, który znajduje się w klastrze usługi AKS.

Uncomplicated Firewall (UFW) to program wiersza polecenia do zarządzania zaporą sieciową netfilter. Węzły usługi AKS używają systemu Ubuntu. W związku z tym UFW jest domyślnie instalowany na węzłach AKS, ale jest wyłączony.

Domyślnie, jeśli ufW jest włączona, zablokuje dostęp do wszystkich portów, w tym port 10250. W takim przypadku jest mało prawdopodobne, aby można było użyć protokołu Secure Shell (SSH) do nawiązania połączenia z węzłami klastra usługi AKS na potrzeby rozwiązywania problemów. Dzieje się tak, ponieważ UFW może również blokować port 22. Aby rozwiązać problemy, możesz uruchomić polecenie az vmss run-command invoke, aby wywołać polecenie ufw sprawdzające, czy UFW jest włączona.

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

Co zrobić, jeśli wyniki wskazują, że ufW jest włączona i nie zezwala na port 10250? W takim przypadku funkcje tunelu (takie jak dzienniki i wykonywanie kodu) nie będą działać dla zasobników zaplanowanych w węzłach z włączoną funkcją UFW. Aby rozwiązać ten problem, zastosuj jedno z następujących rozwiązań w systemie UFW.

Ważne

Przed użyciem tego narzędzia do wprowadzania jakichkolwiek zmian, zapoznaj się z polityką wsparcia AKS (zwłaszcza konserwacją węzłów i dostępem), aby zapobiec wprowadzeniu klastra w nieobsługiwany scenariusz.

Uwaga

Jeśli po zastosowaniu rozwiązania nie widzisz żadnych zmian behawioralnych, możesz ponownie utworzyć zasobniki składnika tunelu. Usunięcie tych podów spowoduje ich ponowne utworzenie.

Rozwiązanie 2a: wyłączanie nieskomplikowanej zapory

Uruchom następujące az vmss run-command invoke polecenie, aby wyłączyć UFW:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

Rozwiązanie 2b: Konfigurowanie nieskomplikowanej zapory w celu zezwolenia na dostęp do portu 10250

Aby wymusić, że UFW zezwoli na dostęp do portu 10250, uruchom następujące az vmss run-command invoke polecenie:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

Przyczyna 3. Narzędzie iptables blokuje port 10250

Uwaga

Ta przyczyna dotyczy dowolnego składnika tunelu, który znajduje się w klastrze usługi AKS.

Narzędzie iptables umożliwia administratorowi systemu skonfigurowanie reguł filtrowania pakietów IP zapory systemu Linux. Reguły można skonfigurować tak iptables , aby blokowały komunikację na porcie 10250.

Możesz wyświetlić reguły dla węzłów, aby sprawdzić, czy port 10250 jest zablokowany, czy skojarzone pakiety są porzucane. W tym celu uruchom następujące iptables polecenie:

iptables --list --line-numbers

W danych wyjściowych dane są pogrupowane w kilka łańcuchów, w tym łańcuch INPUT . Każdy łańcuch zawiera tabelę reguł w następujących nagłówkach kolumn:

• num (numer reguły)
• target
• prot (protokół)
• opt
• source
• destination

INPUT Czy łańcuch zawiera regułę, w której elementem docelowym jest DROP, protokół to tcp, a miejscem docelowym jest tcp dpt:10250? Jeśli tak iptables , blokuje dostęp do portu docelowego 10250.

Rozwiązanie 3. Usuwanie reguły iptables blokującej dostęp na porcie 10250

Uruchom jedno z następujących poleceń, aby usunąć regułę iptables uniemożliwiającą dostęp do portu 10250:

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

Aby rozwiązać twój dokładny lub potencjalny scenariusz, zalecamy sprawdzenie instrukcji iptables uruchamiając iptables --help polecenie.

Ważne

Przed użyciem tego narzędzia do wprowadzania jakichkolwiek zmian, zapoznaj się z polityką wsparcia usługi AKS (zwłaszcza z sekcją dotyczącą konserwacji węzłów i dostępu), aby zapobiec wejściu klastra w nieobsługiwany scenariusz.

Przyczyna 4: Port ruchu wychodzącego 1194 lub 9000 nie jest otwarty

Uwaga

Ta przyczyna dotyczy tylko tunnel-front zasobników i aks-link .

Czy istnieją ograniczenia ruchu wychodzącego, takie jak z zapory usługi AKS? Jeśli są, port 9000 jest wymagany, aby zapewnić poprawne działanie poda tunnel-front. Podobnie port 1194 jest wymagany dla zasobnika aks-link .

Konnectivity opiera się na porcie 443. Domyślnie ten port jest otwarty. W związku z tym nie musisz martwić się o problemy z łącznością na tym porcie.

Rozwiązanie 4. Otwieranie portu 9000

Mimo że tunnel-front został przeniesiony do usługi Konnectivity, niektóre klastry AKS nadal używają tunnel-front, który opiera się na porcie 9000. Upewnij się, że urządzenie wirtualne lub dowolne urządzenie sieciowe lub oprogramowanie zezwala na dostęp do portu 9000. Aby uzyskać więcej informacji na temat wymaganych reguł i zależności, zobacz Globalne reguły sieci wymagane na platformie Azure.

Przyczyna 5. Wyczerpanie portów źródłowego tłumaczenia adresów sieciowych (SNAT)

Uwaga

Ta przyczyna dotyczy dowolnego składnika tunelu, który znajduje się w klastrze usługi AKS. Nie ma jednak zastosowania do prywatnych klastrów AKS. Wyczerpanie portów SNAT (Source Network Address Translation) może wystąpić tylko w przypadku komunikacji publicznej. W przypadku prywatnych klastrów usługi AKS serwer interfejsu API znajduje się w sieci wirtualnej lub podsieci usługi AKS.

Jeśli zabraknie portów SNAT (niepowodzenie portów SNAT), węzły nie mogą nawiązać połączenia z serwerem interfejsu API. Kontener tunelu znajduje się po stronie serwera interfejsu API. W związku z tym łączność tunelu nie zostanie nawiązana.

Jeśli zasoby portów SNAT zostaną wyczerpane, przepływy wychodzące kończą się niepowodzeniem, dopóki istniejące przepływy nie zwolnią niektórych portów SNAT. Usługa Azure Load Balancer odzyskuje porty SNAT po zamknięciu przepływu. Używa czterominutowego limitu czasu bezczynności, aby odzyskać porty SNAT z przepływów bezczynnych.

Można wyświetlić porty SNAT albo z metryk równoważnika obciążenia AKS, albo z diagnostyki usługi, jak opisano w poniższych sekcjach. Aby uzyskać więcej informacji na temat wyświetlania portów SNAT, zobacz Jak mogę zapoznaj się ze statystykami połączeń wychodzących?.

Metryki równoważenia obciążenia AKS

Aby wyświetlić porty SNAT za pomocą metryk modułu równoważenia obciążenia usługi AKS, wykonaj następujące kroki:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Usługi Kubernetes.

2. Na liście usług Kubernetes wybierz nazwę klastra.

3. W okienku menu klastra znajdź nagłówek Ustawienia , a następnie wybierz pozycję Właściwości.

4. Wybierz nazwę wymienioną w obszarze Grupa zasobów infrastruktury.

5. Wybierz równoważenie obciążenia kubernetes.

6. W okienku menu modułu równoważenia obciążenia znajdź nagłówek Monitorowanie , a następnie wybierz pozycję Metryki.

7. Dla typu metryki wybierz pozycję Liczba połączeń SNAT.

8. Wybierz pozycję Zastosuj podział.

9. Ustaw opcję Podziel według na Stan Połączenia.

Diagnostyka usługi

Aby wyświetlić porty SNAT przy użyciu diagnostyki usługi, wykonaj następujące kroki:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Usługi Kubernetes.

2. Na liście usług Kubernetes wybierz nazwę klastra.

3. W okienku menu klastra wybierz pozycję Diagnozuj i rozwiąż problemy.

4. Wybierz pozycję Problemy z łącznością.

5. W obszarze Połączenie SNAT i alokacja portów wybierz pozycję Wyświetl szczegóły.

6. W razie potrzeby użyj przycisku Zakres czasu, aby dostosować przedział czasu.

Rozwiązanie 5a: upewnij się, że aplikacja korzysta z buforowania połączeń

Takie zachowanie może wystąpić, ponieważ aplikacja nie korzysta z istniejących połączeń. Zalecamy, aby nie tworzyć jednego połączenia wychodzącego na żądanie. Taka konfiguracja może powodować wyczerpanie połączeń. Sprawdź, czy kod aplikacji przestrzega najlepszych praktyk i czy używa puli połączeń. Większość bibliotek obsługuje buforowanie połączeń. W związku z tym nie należy tworzyć nowego połączenia wychodzącego na żądanie.

Rozwiązanie 5b: Dostosowywanie przydzielonych portów wychodzących

Jeśli wszystko jest ok w aplikacji, musisz dostosować przydzielone porty wychodzące. Aby uzyskać więcej informacji na temat alokacji portów wychodzących, zobacz Konfigurowanie przydzielonych portów wychodzących.

Rozwiązanie 5c: używaj zarządzanej bramy NAT podczas tworzenia klastra

Możesz skonfigurować nowy klaster, aby używać zarządzanej bramy NAT (Network Address Translation) dla połączeń wychodzących. Aby uzyskać więcej informacji, zobacz Create an AKS cluster with a Managed NAT Gateway.

Przyczyna 6. Problemy z wydajnością agentów konnectivity związane ze wzrostem klastra

W miarę zwiększania się klastra wydajność agentów konnectivity może ulec pogorszeniu z powodu zwiększonego ruchu sieciowego, większej liczby żądań lub ograniczeń zasobów.

Uwaga

Ta przyczyna dotyczy tylko Konnectivity-agent podów.

Rozwiązanie 6: Proporcjonalny autoskalator klastra dla agenta konnectivity

Aby zarządzać wyzwaniami dotyczącymi skalowalności w dużych klastrach, implementujemy narzędzie do automatycznego skalowania proporcjonalnego klastra dla naszych agentów konnectivity. Takie podejście jest zgodne ze standardami branżowymi i najlepszymi rozwiązaniami. Zapewnia optymalne użycie zasobów i zwiększoną wydajność.

Dlaczego ta zmiana została wprowadzona Wcześniej agent Konnectivity miał stałą liczbę replik, która mogła utworzyć wąskie gardło w miarę wzrostu klastra. Implementując narzędzie do automatycznego skalowania proporcjonalnego klastra, umożliwiamy dynamiczne dostosowywanie liczby replik na podstawie reguł skalowania węzłów w celu zapewnienia optymalnej wydajności i użycia zasobów.

Jak działa działanie automatycznego skalowania proporcjonalnego klastra Funkcja automatycznego skalowania proporcjonalnego klastra wykorzystuje konfigurację drabinkową w celu określenia liczby replik agentów Konnectivity na podstawie rozmiaru klastra. Konfiguracja drabiny jest definiowana w mapie konfiguracji konnectivity-agent-autoscaler w przestrzeni nazw kube-system. Oto przykład konfiguracji drabiny:

nodesToReplicas": [
    [1, 2],
    [100, 3],
    [250, 4],
    [500, 5],
    [1000, 6],
    [5000, 10]
]

Ta konfiguracja zapewnia, że liczba replik jest odpowiednio skalowana wraz z liczbą węzłów w klastrze, aby zapewnić optymalną alokację zasobów i lepszą niezawodność sieci.

Jak używać narzędzia do automatycznego skalowania proporcjonalnego klastra? Wartości domyślne można zastąpić, aktualizując mapę konfiguracji konnectivity-agent-autoscaler w przestrzeni nazw kube-system. Oto przykładowe polecenie służące do aktualizowania mapy konfiguracji:

kubectl edit configmap <pod-name> -n kube-system

To polecenie otwiera configmap w edytorze, aby umożliwić wprowadzanie niezbędnych zmian.

Co należy sprawdzić

W węzłach należy monitorować zabicia z powodu braku pamięci (OOM), ponieważ nieprawidłowa konfiguracja narzędzia do automatycznego skalowania proporcjonalnego klastra może spowodować niewystarczającą ilość pamięci przydzieloną dla agentów konnectivity. Ta nieprawidłowa konfiguracja występuje z następujących kluczowych powodów:

Wysokie użycie pamięci: W miarę zwiększania się klastra użycie pamięci agentów Konnectivity może znacznie wzrosnąć. Ten wzrost może wystąpić szczególnie podczas szczytowych obciążeń lub w przypadku obsługi dużej liczby połączeń. Jeśli konfiguracja narzędzia do automatycznego skalowania proporcjonalnego klastra nie skalują replik odpowiednio, agentom może zabraknąć pamięci.

Stałe limity zasobów: Jeśli zapotrzebowanie na zasoby i limity dla agentów Konnectivity są ustawione zbyt nisko, mogą nie mieć wystarczającej ilości pamięci do obsługi obciążenia, co prowadzi do błędów OOM (Out Of Memory). Błędnie skonfigurowane ustawienia automatycznego skalowania proporcjonalnego klastra mogą zaostrzyć ten problem, nie zapewniając wystarczającej liczby replik do dystrybucji obciążenia.

Rozmiar klastra i zmienność obciążenia: Procesor CPU i pamięć, które są wymagane przez agentów Konnectivity, mogą się znacznie różnić w zależności od rozmiaru klastra i obciążenia. Jeśli konfiguracja poziomów automatycznego skalowania proporcjonalnego klastra nie jest odpowiednio dostosowana i adaptacyjnie zmieniana do wzorców użycia klastra, może to spowodować nadmierne przydzielanie pamięci i zabicia procesów z powodu OOM.

Aby zidentyfikować i rozwiązać problemy z zabójstwami OOM, wykonaj następujące kroki:

1. Sprawdź, czy w węzłach nie ma zabić OOM: Użyj następującego polecenia, aby sprawdzić, czy w węzłach nie ma zabić OOM:

kubectl get events --all-namespaces | grep -i 'oomkill'

2. Sprawdź użycie zasobów węzła: sprawdź użycie zasobów w węzłach, aby upewnić się, że nie zabraknie pamięci:

kubectl top nodes

3. Przejrzyj żądania zasobów i limity dla zasobników: upewnij się, że zasobniki agenta Konnectivity mają odpowiednie żądania zasobów i limity ustawione, aby zapobiec działaniu OOM Killer.

kubectl get pod <pod-name> -n kube-system -o yaml | grep -A5 "resources:"

4. Dostosuj żądania zasobów i limity: w razie potrzeby zmodyfikuj te ustawienia dla zasobników agenta Konnectivity, edytując wdrożenie.

kubectl edit deployment konnectivity-agent -n kube-system

Wyłączenie odpowiedzialności za kontakty z osobami trzecimi

Firma Microsoft udostępnia informacje dotyczące sposobu kontaktowania się z innymi firmami, aby ułatwić uzyskanie dodatkowych informacji w tym temacie. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje, że informacje dotyczące innych firm są prawidłowe.

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.