Warum werden DNS-Fehler angezeigt, nachdem ein angepasster DNS-Auflöser hinzugefügt wurde?
Virtual Private Cloud4.15 und höher
Sie sehen DNS-Fehler, nachdem Sie einen benutzerdefinierten DNS-Resolver in Ihrer VPC erstellt haben, in der bereits ein 4.15-Cluster existiert.
Beheben Sie Probleme mit benutzerdefinierten DNS-Konfigurationen bei Satellite-Speicher.
In jedem der folgenden Fälle wird die kube-<clusterID>-Sicherheitsgruppe synchronisiert und die Workerknoten werden wie in den folgenden Schritten beschrieben ersetzt. Beachten Sie, dass das Problem möglicherweise nicht sofort
auftritt, nachdem der Resolver in der VPC erstellt und aktiviert wurde. DNS enthält einen Cache, der Namenssuche auflösen kann, bis ein Worker ersetzt oder erneut gestartet wird oder Pods erneut gestartet werden.
- Das Hinzufügen oder Ersetzen eines Workerknotens zum Cluster schlägt fehl und
ibmcloud ks workerszeigt einen Worker-Status ähnlich dem folgenden an:Infrastructure instance status is 'failed': Can't start instance because provisioning failed. - Wenn Sie
oc get ocausführen, wird ein Fehler ähnlich dem folgenden angezeigt.dial tcp: lookup s3.direct.eu-de.cloud-object-storage.appdomain.cloud on 172.21.0.10:53: server misbehaving. - Ein Neustart eines Workers führt dazu, dass sich die Pods auf diesem Worker im Status „
Terminating“ befinden, die Webkonsole unter OpenShift nicht mehr geöffnet werden kann oder sich Ingress im Status „Critical“ befindet.
Wenn Sie einen benutzerdefinierten DNS-Auflöser in Ihrer VPC aktiviert haben, bevor Sie einen 4.15 Cluster erstellen, fügt Red Hat OpenShift on IBM Cloud automatisch Regeln hinzu, um den Datenverkehr über die IP-Adressen des DNS-Auflösers zu Ihrer
verwalteten Sicherheitsgruppe IBM Cloud zuzulassen (kube-<clusterID>).
Wenn Sie jedoch einen angepassten DNS-Auflöser auf einer VPC aktivieren, die bereits einen Cluster mit 4.15 enthält, verlieren diese vorhandenen Cluster den Zugriff auf DNS.
Um dieses Problem zu beheben, ermöglichen Sie den Zugriff auf die DNS-Auflöser in Ihren vorhandenen Clustern, indem Sie die Sicherheitsgruppe kube-<clusterID> synchronisieren. Durch die Synchronisierung der Sicherheitsgruppe
„ kube-<clusterID> “ werden Regeln hinzugefügt, die den Datenverkehr über die IP-Adressen der DNS-Resolver zulassen.
-
Suchen Sie die Sicherheitsgruppen-ID Ihrer
kube-<clusterID>-Sicherheitsgruppe.ibmcloud is security-groups -
Sicherheitsgruppe synchronisieren.
ibmcloud oc security-group sync --cluster <clusterID> --security-group <security-group-ID> -
Ersetzen Sie die Worker-Knoten in Ihrem Cluster.
ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID> -
Wenn das Problem weiterhin auftritt, wenden Sie sich bitte an den Support. Öffnen Sie einen Supportfall. Stellen Sie in den Falldetails sicher, dass alle relevanten Protokolldateien, Fehlernachrichten oder Befehlsausgaben enthalten sind.
Weitere Szenarios
Fehlerbedingungen, die auf die Kombination eines angepassten DNS-Resolvers in der VPC und 4.15-Clustern in derselben VPC zurückzuführen sein können.
Wenn der Cluster nach der Erstellung des DNS-Resolvers erstellt wird
Wenn Sie einen 4.15-Cluster nach der Erstellung eines angepassten DNS-Resolvers erstellen und Ihr Worker nicht in den Status Normal oder Active wechselt, werden die Regeln für den angepassten DNS-Resolver nicht zur
Sicherheitsgruppe kube-<clusterID> hinzugefügt, bevor sie von der Logik benötigt werden, die die Worker implementiert.
- Listen Sie die Details der Sicherheitsgruppe
kube-<clusterID>auf, um sicherzustellen, dass die angepassten DNS-Auflöser-IPs als Ziele zur Sicherheitsgruppe hinzugefügt werden.ibmcloud is sg kube-<clusterID> - Ersetzen Sie die Worker-Knoten in Ihrem Cluster.
ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID> - Wenn das Problem weiterhin auftritt, wenden Sie sich bitte an den Support. Öffnen Sie einen Supportfall. Stellen Sie in den Falldetails sicher, dass alle relevanten Protokolldateien, Fehlernachrichten oder Befehlsausgaben enthalten sind.