Partager via


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

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 :

  1. Dans le Portail Azure, recherchez et sélectionnez Groupes de machines virtuelles identiques.

  2. Dans la liste des instances de groupe identique, sélectionnez celle que vous utilisez.

  3. 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.