Niestandardowa sieciowa grupa zabezpieczeń blokuje ruch
Gdy uzyskujesz dostęp do aplikacji hostowanej w klastrze usługi Azure Kubernetes Service (AKS), zostanie wyświetlony komunikat o błędzie "Przekroczono limit czasu". Ten błąd może wystąpić nawet wtedy, gdy aplikacja jest uruchomiona, a pozostała część konfiguracji wydaje się być poprawna.
Wymagania wstępne
Narzędzie Kubernetes kubectl lub podobne narzędzie do nawiązywania połączenia z klastrem. Aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli.
Narzędzie Adres URL klienta (cURL) lub podobne narzędzie wiersza polecenia.
Narzędzie wiersza polecenia apt-get do obsługi pakietów.
Symptomy
Jeśli uruchomisz następujące polecenia kubectl get i cURL, wystąpią błędy "Przekroczono limit czasu", które przypominają następujące dane wyjściowe konsoli:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-66648877fc-v78jm 1/1 Running 0 5m53s
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-loadbalancer-service LoadBalancer 10.0.107.79 10.81.x.x 80:31048/TCP 4m14s
$ curl -Iv http://10.81.124.39 # Use an IP address that fits the "EXTERNAL-IP" pattern.
* Trying 10.81.x.x:80...
* connect to 10.81.x.x port 80 failed: Timed out
* Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
Przyczyna
Jeśli za każdym razem występuje ten sam błąd "Przekroczono limit czasu", zwykle sugeruje to, że składnik sieci blokuje ruch.
Aby rozwiązać ten problem, możesz zacząć od sprawdzenia dostępu do zasobnika, a następnie przejść do klienta w podejściu wewnątrz.
Aby sprawdzić zasobnik, uruchom następujące kubectl get polecenia i polecenie kubectl describe :
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 53s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl describe pod my-deployment-66648877fc-v78jm # Specify the pod name from the previous command.
...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 117s default-scheduler Successfully assigned default/my-deployment-66648877fc-v78jm to aks-agentpool-42617579-vmss000000
Normal Pulling 116s kubelet Pulling image "httpd"
Normal Pulled 116s kubelet Successfully pulled image "httpd" in 183.532816ms
Normal Created 116s kubelet Created container webserver
Normal Started 116s kubelet Started container webserver
Na podstawie tych danych wyjściowych zasobnik wydaje się działać poprawnie, bez żadnych ponownych uruchomień.
Otwórz zasobnik testowy, aby sprawdzić dostęp do zasobnika aplikacji. Uruchom następujące kubectl getpolecenia , kubectl run, apt-geti cURL:
$ kubectl get pods -o wide # Get the pod IP address.
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 7m45s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl run -it --rm aks-ssh --image=debian:stable # Launch the test pod.
If you don't see a command prompt, try pressing enter.
$ root@aks-ssh:
$ # Install packages inside the test pod.
$ root@aks-ssh: apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
...
...
Running hooks in /etc/ca-certificates/update.d...
done.
$ # Try to check access to the pod using the pod IP address from the "kubectl get" output.
$ curl -Iv http://172.25.0.93
* Trying 172.25.0.93:80...
* Connected to 172.25.0.93 (172.25.0.93) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 172.25.0.93 left intact
Zasobnik jest dostępny bezpośrednio. W związku z tym aplikacja jest uruchomiona.
Zdefiniowana usługa jest typem LoadBalancer . Oznacza to, że przepływ żądania od klienta końcowego do zasobnika będzie następujący:
Zasobnik >> aplikacji węzła >> usługi AKS modułu równoważenia obciążenia klienta >>
W tym przepływie żądań możemy zablokować ruch przez następujące składniki:
- Zasady sieciowe w klastrze
- Sieciowa grupa zabezpieczeń dla podsieci usługi AKS i węzła usługi AKS
Aby sprawdzić zasady sieciowe, uruchom następujące kubectl get polecenie:
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
Istnieją tylko domyślne zasady usługi AKS. W związku z tym zasady sieciowe nie blokują ruchu.
Aby sprawdzić sieciowe grupy zabezpieczeń i skojarzone z nimi reguły przy użyciu usługi AKS, wykonaj następujące kroki:
W witrynie Azure Portal wyszukaj i wybierz pozycję Zestawy skalowania maszyn wirtualnych.
Na liście wystąpień zestawu skalowania wybierz używane wystąpienia.
W okienku menu wystąpienia zestawu skalowania wybierz pozycję
Networking.
Zostanie wyświetlona strona Sieć dla wystąpienia zestawu skalowania. Na karcie Reguły portów wejściowych są wyświetlane dwa zestawy reguł, które są oparte na dwóch sieciowych grupach zabezpieczeń, które działają w wystąpieniu zestawu skalowania:
Pierwszy zestaw składa się z reguł sieciowej grupy zabezpieczeń na poziomie podsieci. Te reguły są wyświetlane pod następującym nagłówkiem notatek:
Sieciowa grupa zabezpieczeń my-aks-nsg> (dołączona do podsieci: <my-aks-subnet>)<
Ten układ jest typowy, jeśli jest używana niestandardowa sieć wirtualna i niestandardowa podsieć klastra usługi AKS. Zestaw reguł na poziomie podsieci może przypominać poniższą tabelę.
Priorytet Nazwa Port Protokół Element źródłowy Element docelowy Akcja 65000 AllowVnetInBound Dowolne Dowolne VirtualNetwork VirtualNetwork Zezwalaj 65001 AllowAzureLoadBalancerInBound Dowolne Dowolne AzureLoadBalancer Dowolne Zezwalaj 65500 DenyAllInBound Dowolne Dowolne Dowolne Dowolne Zablokuj Drugi zestaw składa się z reguł sieciowej grupy zabezpieczeń na poziomie karty sieciowej. Te reguły są wyświetlane pod następującym nagłówkiem notatek:
Sieciowa grupa zabezpieczeń aks-agentpool-agentpool-number-nsg<> (dołączona do interfejsu sieciowego: aks-agentpool-vm-scale-set-number-vmss)<>
Ta sieciowa grupa zabezpieczeń jest stosowana przez klaster usługi AKS i jest zarządzana przez usługę AKS. Odpowiedni zestaw reguł może przypominać poniższą tabelę.
Priorytet Nazwa Port Protokół Element źródłowy Element docelowy Akcja 500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.x Zezwalaj 65000 AllowVnetInBound Dowolne Dowolne VirtualNetwork VirtualNetwork Zezwalaj 65001 AllowAzureLoadBalancerInBound Dowolne Dowolne AzureLoadBalancer Dowolne Zezwalaj 65500 DenyAllInBound Dowolne Dowolne Dowolne Dowolne Zablokuj
Na poziomie karty sieciowej istnieje reguła ruchu przychodzącego sieciowej grupy zabezpieczeń dla protokołu TCP pod adresem IP 10.81.x.x na porcie 80 (wyróżnionym w tabeli). Jednak w regułach sieciowej grupy zabezpieczeń na poziomie podsieci brakuje reguły równoważnej.
Dlaczego usługa AKS nie zastosowała reguły do niestandardowej sieciowej grupy zabezpieczeń? Ponieważ usługa AKS nie stosuje sieciowych grup zabezpieczeń do podsieci i nie zmodyfikuje żadnych sieciowych grup zabezpieczeń skojarzonych z tą podsiecią. Usługa AKS zmodyfikuje sieciowe grupy zabezpieczeń tylko na poziomie karty sieciowej. Aby uzyskać więcej informacji, zobacz Temat Czy mogę skonfigurować sieciowe grupy zabezpieczeń za pomocą usługi AKS?.
Rozwiązanie
Jeśli aplikacja jest włączona w celu uzyskania dostępu na określonym porcie, musisz upewnić się, że niestandardowa sieciowa grupa zabezpieczeń zezwala na ten port jako regułę Inbound . Po dodaniu odpowiedniej reguły w niestandardowej sieciowej grupie zabezpieczeń na poziomie podsieci aplikacja jest dostępna.
$ curl -Iv http://10.81.x.x
* Trying 10.81.x.x:80...
* Connected to 10.81.x.x (10.81.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 10.81.x.x left intact
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.