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 « Délai d’attente ». 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.
Prerequisites
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 d’URL client (cURL) ou d’un 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 « Délai d’attente » qui ressemblent à la sortie de la 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.
Pour vérifier le pod, exécutez les commandes suivantes kubectl get et kubectl :
$ 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
En fonction de cette sortie, le pod semble s’exécuter correctement, sans redémarrage.
Ouvrez un pod de test pour vérifier l’accès au pod d’application. Exécutez les commandes suivantes kubectl get, kubectl run, apt-getet 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
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 :
Pod d’application d’application du nœud >> AKS de l’équilibreur >> de charge client >>
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 vérifier la 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 par défaut AKS existe. Par conséquent, la stratégie réseau ne semble pas bloquer le trafic.
Pour vérifier 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 instance de groupe identique, sélectionnez
Networking.
La page Mise en réseau de l’instance de groupe identique s’affiche. Dans l’onglet Règles de port de trafic entrant, deux ensembles de règles sont affichés en fonction des deux groupes de sécurité réseau qui agissent sur l’instance de groupe identique :
Le premier ensemble est composé de règles de groupe de sécurité réseau au niveau du sous-réseau. Ces règles sont affichées sous le titre 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 Quelconque Quelconque VirtualNetwork VirtualNetwork Allow 65 001 AllowAzureLoadBalancerInBound Quelconque Quelconque AzureLoadBalancer Quelconque Allow 65 500 DenyAllInBound Quelconque Quelconque Quelconque Quelconque Deny Le deuxième jeu est composé de règles de groupe de sécurité réseau au niveau de la carte réseau. Ces règles sont affichées sous le titre 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 Autoriser 65 000 AllowVnetInBound Quelconque Quelconque VirtualNetwork VirtualNetwork Allow 65 001 AllowAzureLoadBalancerInBound Quelconque Quelconque AzureLoadBalancer Quelconque Allow 65 500 DenyAllInBound Quelconque Quelconque Quelconque Quelconque Deny
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, une règle équivalente est manquante 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é ? Étant donné que AKS n’applique pas de groupes de sécurité réseau à son sous-réseau et qu’il 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, voir 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 tant que Inbound règle. 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.