Autor: Maximilian

Wir hatten ein seltsames Problem in einem unserer MySQL-Cluster: Die primäre Node konnte keine neuen Verbindungen mehr annehmen. Die Verbindungen wurden nicht abgelehnt, aber sie wurden auch nicht vollständig aufgebaut.

Ein Restart von mysqld hat das Problem gelöst – aber wir haben uns gefragt, was da passiert ist. Daher war eine der Maßnahmen im Post-Mortem, dass wir für die Zukunft dokumentieren, wie man Stacktrace aller MySQL-Threads dumpen kann.

Als das Problem kurz später noch mal auftrat, waren wir vorbereitet: Wir haben einen Coredump erstellt und uns dann mit gdb die Threads angesehen:

In Kubernetes ermöglichen Persistent Volumes (PVs) den Betrieb von Workloads mit persistentem State. Der Inhalt dieser Volumes existiert unabhängig von der Lebensdauer der Pods, die sie verwenden.

Es gibt viele verschiedene Implementierungen/Provider für PVs. Wenn man Kubernetes bei einem Cloud-Anbieter betreibt, kann man deren Blockdevice- oder Netzwerkdateisystem-Service verwenden, z.B. Elastic Block Store (EBS) bei AWS. 

Auch in einer on-prem-Umgebung wie unserer gibt es Möglichkeiten: die meisten unserer Persistent Volumes liegen auf NetApps. Mit dem offiziellen NetApp-Provisioner Trident werden diese bei Bedarf automatisch angelegt.

In manchen Fällen möchte man aber nicht Volumes per Netzwerk einbinden, sondern diese direkt auf der Node haben, d.h. Local Storage nutzen. Das kann z.B. schneller oder kostengünstiger sein, und hat weniger Abhängigkeiten. Es passt insbesondere dann, wenn die Redundanz der Daten auf Anwendungsebene sichergestellt ist, so dass ein Verlust eines einzelnen PVs keinen Datenverlust bedeutet.

Pods verwenden die PVs nicht direkt, sondern sie referenzieren einen Persistent Volume Claim (PVC). Ein PVC ist ein „Wunsch“ nach einem Volume einer bestimmter Art und Größe. Eine Controller-Loop in Kubernetes sorgt dafür, dass ein PVC mit einem passenden PV verknüpft wird. Erst dann kann das PVC von Pods verwendet werden.

Für die meisten Arten von Volumes gibt es dynamisches Provisioning: wenn jemand ein PVC erstellt, wird automatisch vom Hersteller-spezifischen Provisioner (wie NetApp Trident) ein passendes PV erstellt. Da das neue PV genau auf das PVC passt, werden diese dann von Kubernetes verknüpft. 

Bei den local Volumes gibt es stattdessen ein statisches Provisioning: der local-static-provisioner scannt nur auf der jeweiligen Node, wo er läuft, nach schon bestehenden Mountpoints oder Blockdevices, und erstellt dafür die PV-Objekte. Wenn man also ein PVC anlegt, und es gar kein passendes PV gibt, dann wird das PVC pending bleiben, bis man selbst ein Volume erstellt.