Wir haben einen Produktions-Kubernetes-Cluster, der in unregelmäßigen Abständen mehrere Ausfälle von ca. 1-5 Minuten aufweist. Wir versuchen, das Problem zu beheben, stoßen jedoch auf verschiedene Informations-/Wissenslücken und würden uns über Hilfe freuen.
Unser gesamter benutzerdefinierter Code und unsere gesamte benutzerdefinierte Software sind hochverfügbar und in mindestens zwei Replikaten bereitgestellt. Ihre Hochverfügbarkeit wurde unter Last getestet.
Der Kubernetes-ClusterIstSpot-Instanzen ausführen, und wenn Spot-Instanzen ausfallen, die nur unsere Pods enthalten, läuft alles weiterhin reibungslos und ohne Ausfälle. Was uns jedoch aufgefallen ist, ist, dass es, wenn Knoten ausfallen, die unsere Pods enthalten kube-dns, zu diesen Ausfällen kommt – aber nicht immer.
Wir verwenden 1.25 auf GKE und sind daher in der Nutzung eingeschränkt kube-dns. Wir verwenden 1 kube-dnsReplikat pro 3 Knoten (normalerweise haben wir 9 Knoten in Betrieb),Undkube-dnshaben über die Configmap mindestens 3 Knoten angegeben kube-dns-autoscaler. Wir verwenden aus verschiedenen Gründen auch Istio 1.17.1, abernichtfür mTLS. Wir haben auch einen PDB darauf, kube-dnsder nur 1 Unterbrechung zulässt.
Was wir sehen, ist, dass die meisten unserer Dienste bei ihren gegenseitigen Anfragen eine Zeitüberschreitung aufweisen (die istio-proxyZugriffsprotokolle protokollieren normalerweise einen 504 UTFehler), und einige der Dienste protokollieren tatsächlich einen EAI_AGAINFehler, was bedeutet, dass das DNS eine Zeitüberschreitung aufweist. Wir haben auch eine separate Anwendung ausgeführt, die eine Mischung aus Dienstnamen sowie die IP-Adresse des Dienstes direkt anpingt (dies beginnt, um die Fehlerbehebung zu erleichtern), und wir können sehen, dass während der Zeiten, in denen die EAI_AGAINFehler auftreten, die Pings der IP-Adressen erfolgreich sind, die Anfragen nach Dienstnamen jedoch nicht – was ein weiterer Hinweis darauf ist, dass dies kube-dnsmit dem Problem zusammenhängt.
Wir haben diese Service- und IP-Pings auch mit Pods verglichen, die einen Sidecar haben und mit denen, die keinen haben istio-proxy, und können das gleiche Verhalten feststellen, was bedeutet, dass das Problemnichtwegen istio.
Das Einzige, was wir in Erwägung ziehen, ist, dies zu implementieren, NodeLocal DNSCachesodass alle Knoten einen DNS-Cache haben und – vielleicht – alle zeitweiligen kube-dnsProbleme damit überdecken. Wir sind uns jedoch nicht sicher, ob dies helfen wird, und befürchten, dass dadurch ein größeres Problem verdeckt wird.
Wir sehen, dass das gleiche Problem auch in unserer Nicht-Produktionsumgebung auftritt, konnten es aber bisher nirgends reproduzieren. Es passiert einfach. Selbst Neustarts/Löschen von Knoten scheinen dies nicht zu verursachen.
Ich kann die Protokollierungsebene auch nicht erhöhen, kube-dnsda GKE die Bereitstellungsressource gesperrt und die Protokollierungsebenen zurückgesetzt hat …
Wir hoffen auf Ratschläge zur weiteren Fehlerbehebung und Lösung des Problems. Vielen Dank