Ich sah das Problem mit Kubernetes nach OOM auf dem Master-Knoten. Die Kubernetes-Dienste waren in Ordnung, es gab keine Fehler- oder Warnmeldungen im Protokoll. Aber Kubernetes konnte die neue Bereitstellung, die nach dem OOM erstellt wurde, nicht verarbeiten.Kubernetes bricht nach OOM
Ich lud Kubernetes von . Und es löste das Problem, begann Kubernetes normal zu arbeiten.
Ich frage mich nur, ist es erwartet Verhalten oder Fehler in Kubernetes?
Es scheint, dass das Problem nicht von OOM verursacht wurde. Es wurde von kube-controller verursacht, egal ob OOM passiert ist oder nicht.
Wenn ich den Kube-Controller neu starte, beginnt Kubernetes Prozessbereitstellungen und Pods normal.
Es wäre großartig, wenn Sie das Protokoll von kube-controller teilen können. Aber wenn ein API-Server abstürzt/OOMKilled, kann es in der frühen Version von kubernetes potentielle Synchronisationsprobleme geben (ich erinnere mich, dass wir ähnliche Probleme mit dem Daemonset gesehen haben und ich habe Fehler bei der Kubernete-Community eingereicht), aber selten.
In der Zwischenzeit haben wir viel Arbeit gemacht, um die Kubernetes-Produktion fertig zu machen: sowohl Tuning-Kubernetes als auch Basteln anderer Micro-Services, die mit Kubernetes kommunizieren müssen. Hoffe, dass diese Blog-Einträge helfen würde:
https://applatix.com/making-kubernetes-production-ready-part-2/ Hier geht es um mehr als 30 Knöpfe wir stimmen Kubernetes verwendet
https://applatix.com/making-kubernetes-production-ready-part-3/ Hier geht es um Mikro Service Verhalten Cluster Stabilität
„, um sicherzustellen, aber Kubernetes gescheitert neuen Einsatz zu verarbeiten, das wurde erstellt, nachdem OOM passiert ist. " - Was waren die Ereignisse/Protokolle, wenn die 'Bereitstellung' nicht möglich war? – surajd