Un groupe de sécurité réseau personnalisé bloque le trafic
Lorsque vous accédez à une application hébergée sur un cluster Azure Kubernetes Service (AKS), vous recevez un message d’erreur « Expiration du délai ». Cette erreur peut se produire même si l’application est en cours d’exécution et que le reste de la configuration semble correct.
Conditions préalables
L’outil Kubernetes kubectl , ou un outil similaire, pour se connecter au cluster. Pour installer kubectl à l’aide d’Azure CLI, exécutez la commande az aks install-cli .
Outil URL du client (cURL) ou outil en ligne de commande similaire.
Outil en ligne de commande apt-get pour la gestion des packages.
Symptômes
Si vous exécutez les commandes kubectl get et cURL suivantes, vous rencontrez des erreurs « Timed out » qui ressemblent à la sortie de console suivante :
$ 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
Cause
Si vous rencontrez la même erreur « Délai d’expiration » à chaque fois, cela suggère généralement qu’un composant réseau bloque le trafic.
Pour résoudre ce problème, vous pouvez commencer par vérifier l’accès au pod, puis passer au client dans une approche interne-out .
Pour case activée le pod, exécutez les commandes suivantes kubectl get et 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
Sur la base de cette sortie, le pod semble s’exécuter correctement, sans aucun redémarrage.
Ouvrez un pod de test pour case activée l’accès au pod d’application. Exécutez les commandes , kubectl run, apt-getet cURL suivantes kubectl get:
$ 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
Le pod est accessible directement. Par conséquent, l’application est en cours d’exécution.
Le service défini est un LoadBalancer type. Cela signifie que le flux de requête du client final vers le pod sera le suivant :
Nœud AKS >> de l’équilibreur >> de charge client >> - Pod d’application
Dans ce flux de requête, nous pouvons bloquer le trafic via les composants suivants :
- Stratégies réseau dans le cluster
- Groupe de sécurité réseau (NSG) pour le sous-réseau AKS et le nœud AKS
Pour case activée stratégie réseau, exécutez la commande suivante kubectl get :
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
Seule la stratégie AKS par défaut existe. Par conséquent, la stratégie réseau ne semble pas bloquer le trafic.
Pour case activée les groupes de sécurité réseau et leurs règles associées à l’aide d’AKS, procédez comme suit :
Dans le Portail Azure, recherchez et sélectionnez Groupes de machines virtuelles identiques.
Dans la liste des instances de groupe identique, sélectionnez celle que vous utilisez.
Dans le volet de menu de votre groupe identique instance, sélectionnez
Networking.
La page Mise en réseau du groupe identique instance s’affiche. Dans l’onglet Règles de port d’entrée, deux ensembles de règles basés sur les deux groupes de sécurité réseau qui agissent sur le groupe identique instance :
Le premier ensemble est composé de règles NSG au niveau du sous-réseau. Ces règles sont affichées sous l’en-tête de note suivant :
Groupe de sécurité <réseau my-aks-nsg> (attaché au sous-réseau :< my-aks-subnet>)
Cette disposition est courante si un réseau virtuel personnalisé et un sous-réseau personnalisé pour le cluster AKS sont utilisés. L’ensemble de règles au niveau du sous-réseau peut ressembler au tableau suivant.
Priorité Nom Port Protocole Source Destination Action 65000 AllowVnetInBound N’importe lequel N’importe lequel VirtualNetwork VirtualNetwork Autoriser 65001 AllowAzureLoadBalancerInBound N’importe lequel N’importe lequel AzureLoadBalancer N’importe lequel Autoriser 65500 DenyAllInBound N’importe lequel N’importe lequel N’importe lequel N’importe lequel Refuser Le deuxième ensemble est composé de règles NSG au niveau de la carte réseau. Ces règles sont affichées sous l’en-tête de note suivant :
Groupe de sécurité réseau aks-agentpool-agentpool-number-nsg<> (attaché à l’interface réseau : aks-agentpool-vm-scale-set-number-vmss<>)
Ce groupe de sécurité réseau est appliqué par le cluster AKS et il est géré par AKS. L’ensemble de règles correspondant peut ressembler au tableau suivant.
Priorité Nom Port Protocole Source Destination Action 500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.X Allow 65000 AllowVnetInBound N’importe lequel N’importe lequel VirtualNetwork VirtualNetwork Autoriser 65001 AllowAzureLoadBalancerInBound N’importe lequel N’importe lequel AzureLoadBalancer N’importe lequel Autoriser 65500 DenyAllInBound N’importe lequel N’importe lequel N’importe lequel N’importe lequel Refuser
Au niveau de la carte réseau, il existe une règle de trafic entrant NSG pour TCP à l’adresse IP 10.81. x. x sur le port 80 (mis en surbrillance dans le tableau). Toutefois, il manque une règle équivalente dans les règles du groupe de sécurité réseau au niveau du sous-réseau.
Pourquoi AKS n’a-t-il pas appliqué la règle au groupe de sécurité réseau personnalisé ? AkS n’applique pas de groupes de sécurité réseau à son sous-réseau et ne modifie aucun des groupes de sécurité réseau associés à ce sous-réseau. AKS modifie les groupes de sécurité réseau uniquement au niveau de la carte réseau. Pour plus d’informations, consultez Puis-je configurer des groupes de sécurité réseau avec AKS ?.
Solution
Si l’application est activée pour l’accès sur un certain port, vous devez vous assurer que le groupe de sécurité réseau personnalisé autorise ce port en règle Inbound générale. Une fois la règle appropriée ajoutée dans le groupe de sécurité réseau personnalisé au niveau du sous-réseau, l’application est accessible.
$ 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
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.
Commentaires
Bientôt disponible : pendant toute l’année 2024, nous allons éliminer progressivement Problèmes GitHub comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, voir : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour