Warum zeigt der Netzwerkstatus einen `NHC007` Fehler an?

Virtual Private Cloud

Fehlerbehebung bei der Netzwerkzustandsprüfung NHC007.

Wenn Sie den Status Ihres Clusters überprüfen, indem Sie ibmcloud oc cluster health issues --cluster <CLUSTER_ID> ausführen, erhalten Sie eine Fehlermeldung wie im folgenden Beispiel.

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

Wenn Sie die Details des Problems überprüfen, sehen Sie, auf welche DNS-Auflöser von welchem Arbeitsknoten aus nicht zugegriffen werden kann.

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

Diese Warnung weist darauf hin, dass der DNS-Verkehr von bestimmten Worker Nodes blockiert wird, möglicherweise aufgrund restriktiver Richtlinien oder IaaS-level Konfigurationen.

Überprüfen Sie Ihre Calico HostEndpoint (HEP) und GlobalNetworkPolicy (GNP) Ressourcen sowie Ihre ACLs, Sicherheitsgruppen und alle anderen Netzwerk-Appliances, die ausgehenden DNS-Verkehr blockieren können.

Überprüfen Sie die Calico HostEndpoint (HEP)-Ressourcen, um Calico HEPs aufzulisten und zu prüfen, ob HEP-Konfigurationen möglicherweise fälschlicherweise Einschränkungen auf Ihre Arbeitsknotenschnittstellen anwenden.
```
kubectl get hostendpoints.crd.projectcalico.org
```
Beispielbefehl zur Beschreibung eines bestimmten HEP.
```
kubectl describe hostendpoints.crd.projectcalico.org <hep-name>
```
Überprüfen Sie Calico GlobalNetworkPolicies (GNP), um GNPs aufzulisten.
```
kubectl get globalnetworkpolicies.crd.projectcalico.org
```
Überprüfen Sie spezifische Richtlinien auf restriktive DNS-Regeln. Konzentrieren Sie sich auf egress Regeln, die Port 53 betreffen oder sich auf Knotenbeschriftungen/Selektoren beziehen.
```
kubectl get globalnetworkpolicies.crd.projectcalico.org <policy-name> -o yaml
```
Testen Sie den DNS-Zugriff von einem Debug-Pod aus, indem Sie einen temporären Debug-Pod starten, bei dem Sie den Namen des betroffenen Worker-Knotens für „ nodeName “ verwenden. Wenn DNS hier versagt, kann dies an Blockaden auf Infrastrukturebene liegen.
```
kubectl run  -i --tty debug \
  --image=us.icr.io/armada-master/network-alpine:latest \
  --restart=Never \
  --overrides='
{
  "apiVersion": "v1",
  "spec": {
    "nodeName": "<node-name>"
  }
}' -- sh
```
Führen Sie die folgenden Befehle im Debug-Pod aus.
```
nslookup ibm.com
```
```
dig ibm.com
```
Überprüfen Sie die ACLs (Zugriffskontrolllisten).
- Navigieren Sie in der Konsole zu VPC > Zugriffskontrolllisten und stellen Sie sicher, dass ausgehende Regeln sowohl UDP Port 53 als auch TCP Port 53 zulassen.
- In der CLI inspizieren Sie ACLs, indem Sie die folgenden Befehle ausführen.
```
    ibmcloud is network-acls
    ```
    ```sh {: pre}
    ibmcloud is network-acl <acl-id>
    ```
```
Überprüfen Sie die Sicherheitsgruppenregeln, um die Sicherheitsgruppen zu finden, die mit Ihren Arbeitsknoten verknüpft sind, und führen Sie diese dann aus, um die Sicherheitsgruppeneinstellungen zu überprüfen. Vergewissern Sie sich, dass keine ausgehenden Regeln vorhanden sind, die den DNS-Verkehr blockieren ( UDP / TCP port 53).
```
ibmcloud is security-group-rules <security-group-id>
```
Überprüfen Sie Ihre Infrastruktur (Netzwerkgeräte, ACLs usw.) und erlauben Sie UDP und TCP Anschluss 53 ausgehenden Datenverkehr
Wenn DNS nach Überprüfung dieser Punkte immer noch nicht erreichbar ist, wenden Sie sich an den Support. Öffnen Sie einen Supportfall. Fügen Sie den Falldetails unbedingt alle relevanten Protokolldateien, Fehlermeldungen oder Befehlsausgaben bei.

Warum zeigt der Netzwerkstatus einen NHC007 Fehler an?

Warum zeigt der Netzwerkstatus einen NHC007 Fehler an?

Warum zeigt der Netzwerkstatus einen `NHC007` Fehler an?