Pourquoi l'état du réseau indique-t-il une erreur `NHC007` ?

Cloud privé virtuel

Dépannage de l'erreur NHC007 lors du contrôle de l'état du réseau.

Lorsque vous vérifiez l'état de santé de votre cluster en exécutant la commande ibmcloud oc cluster health issues --cluster <CLUSTER_ID>, vous obtenez une erreur similaire à l'exemple suivant.

ID       Component   Severity   Description
NHC007   Network     Warning    One or more DNS resolvers are not reachable from certain worker nodes.

Si vous vérifiez les détails du problème, vous verrez quels résolveurs DNS ne sont pas accessibles à partir de quel nœud de travail.

ibmcloud ks cluster health issue get --cluster <CLUSTER_ID> --issue NHC007

Cet avertissement indique que le trafic DNS de certains nœuds de travail est bloqué, peut-être en raison de politiques restrictives ou de configurations IaaS-level.

Vérifiez vos ressources Calico HostEndpoint (HEP) et GlobalNetworkPolicy (GNP), ainsi que vos ACL, groupes de sécurité et tout autre dispositif réseau susceptible de bloquer le trafic DNS sortant.

Consultez les ressources Calico HostEndpoint (HEP) pour dresser la liste des HEP Calico et vérifier si des configurations HEP pourraient appliquer de manière incorrecte des restrictions aux interfaces de vos nœuds de travail.
```
kubectl get hostendpoints.crd.projectcalico.org
```
Exemple de commande permettant de décrire un HEP spécifique.
```
kubectl describe hostendpoints.crd.projectcalico.org <hep-name>
```
Consultez le site Calico GlobalNetworkPolicies (GNP) pour obtenir la liste des GNP.
```
kubectl get globalnetworkpolicies.crd.projectcalico.org
```
Examinez les politiques spécifiques pour les règles DNS restrictives. Concentrez-vous sur les règles de egress qui affectent le port 53 ou s'appliquent aux étiquettes/sélecteurs de nœuds.
```
kubectl get globalnetworkpolicies.crd.projectcalico.org <policy-name> -o yaml
```
Testez l'accès au DNS à partir d'un pod de débogage; lancez un pod de débogage temporaire en utilisant le nom des nœuds de travail concernés pour l' nodeName. Si le DNS échoue ici, cela peut être dû à des blocages au niveau de l'infrastructure.
```
kubectl run  -i --tty debug \
  --image=us.icr.io/armada-master/network-alpine:latest \
  --restart=Never \
  --overrides='
{
  "apiVersion": "v1",
  "spec": {
    "nodeName": "<node-name>"
  }
}' -- sh
```
Exécutez les commandes suivantes dans le pod de débogage.
```
nslookup ibm.com
```
```
dig ibm.com
```
Vérifiez les listes de contrôle d'accès (ACL).
- Dans la console, naviguez vers VPC > Access control lists et assurez-vous que les règles de sortie autorisent à la fois UDP port 53 et TCP port 53.
- Dans le CLI, inspectez les ACL en exécutant les commandes suivantes.
```
    ibmcloud is network-acls
    ```
    ```sh {: pre}
    ibmcloud is network-acl <acl-id>
    ```
```
Inspectez les règles des groupes de sécurité pour trouver les groupes de sécurité associés à vos nœuds de travail, puis exécutez pour vérifier les paramètres des groupes de sécurité. Assurez-vous qu'aucune règle de sortie ne bloque le trafic DNS ( UDP / TCP port 53).
```
ibmcloud is security-group-rules <security-group-id>
```
Examinez votre infrastructure (appareils réseau, ACL, etc.) et autorisez le trafic sortant de UDP et TCP port 53
Si le DNS est toujours inaccessible après avoir passé en revue ces éléments, contactez l'assistance. Ouverture d'un cas de support. Dans les détails de l'affaire, veillez à inclure tout fichier journal, message d'erreur ou résultat de commande pertinent.

Pourquoi l'état du réseau indique-t-il une erreur NHC007 ?

Pourquoi l'état du réseau indique-t-il une erreur NHC007 ?

Pourquoi l'état du réseau indique-t-il une erreur `NHC007` ?