etcd spielt in Kubernetes Clustern typischerweise eine essentielle Rolle, denn hier wird der gesamte Zustand des Clusters gehalten. Die einzelnen Kubernetes API Server Instanzen selbst sind zustandslos.

etcd ist ein verteilter Key-Value-Store, der mit Multi-Version-Concurrency-Control arbeitet und darüber Change-Notification and Zugriff auf ältere Versionen ermöglicht.

Die Implementierung verwendet dazu einen Revisions-Zähler. Werden Daten gelöscht, hinzugefügt oder überschrieben, so werden diese Operationen stets zu einer neuen Revision assoziiert. Die vorheigen Zustände bleiben zunächst gespeichert, auch wenn sie überholt sind.

Damit diese quasi unendliche Geschichte nicht dazu führt, dass die Festplatte volläuft, müssen regelmäßig Wartungsaufgaben erfüllt werden.

Kubernetes speichert sämtliche Konfigurationsdaten des Clusters in einer Datenbank, typischerweise etcd.

etcd ist ein verteilter Key-Value-Store, durch mehrere Instanzen kann die Verfügbarkeit und Datensicherheit gewährleistet werden. Damit keine Daten verloren gehen, signalisiert etcd dem Betriebssystem per fsync()-Aufruf, dass ein sofortiges Schreiben auf Festplatte erfolgen soll.

Doch etcd kann auch zum Flaschenhals werden: Wenn keine Schreiboperationen möglich sind, ist auch die Clusteradministration blockiert. Ein weiterer Aspekt ist, dass selbst in einem relativ stabilen Cluster kontinuierliche Aktualisierungen diverser Kubernetes-Objekte erfolgen, wie z.B. zur Leader-Election.
Das führt zu recht hoher I/O-Last und kann bei günstigen SSDs/NVMe Speichern zu schneller Alterung führen.

Container haben den Betrieb von Softwaresystemen seit einigen Jahren modernisiert. Mit Docker, Podman und Kubernetes ist ein effizienter und automatisierter Betrieb möglich, der früher undenkbar war. Doch manchmal stört die Isolation, die Container mit sich bringen:
Was, wenn es gilt, den Inhalt eines Containers zur Laufzeit zu inspizieren und es ist keine Shell installiert?

In modernen Webanwendungen ist die Synchronisierung zwischen Frontend und Backend von zentraler Bedeutung. Nutzer erwarten reaktive Oberflächen, unmittelbares Feedback und konsistente Daten – selbst wenn mehrere Personen gleichzeitig an denselben...

React zählt seit geraumer Zeit zu den beliebtesten JavaScript Frontend Frameworks. Der Einstieg ist sehr leicht und die große Community hat zu einem breiten Ökosystem beigetragen. Doch eines hört man immer wieder. React soll langsam sein. Ein Grund...

Im letzten Blogpost über Astro wurde das Framework kurz vorgestellt und dessen Vorteile aufgezeigt. Einer dieser Vorteile hebt sich von den anderen besonders ab. Mit Astro ist man nicht auf nur ein Frontend-Framework beschränkt, sondern kann...

Wer heute eine Website entwickeln möchte, bei der Content und Suchmaschinenoptimierung (SEO) im Mittelpunkt stehen, kann aus einer Vielzahl moderner Frameworks wählen. In diesem Blogbeitrag wird das Open-Source-Framework Astro vorgestellt und...

Die Kubernetes Lernkurve fängt typischerweise mit einem Cluster an.
Das kann ein Minikube, mikrok8s, k3s, der Docker Desktop Kubernetes Cluster oder auch ein Cluster in der Cloud sein.

Ein Kubernetes Cluster kommt jedoch selten allein: Zumindest für Entwicklung und den produktiven Betrieb ist es sinnvoll, mit getrennten Clustern zu arbeiten.

Die IP-Adresse eines Clients stellt für Web-APIs einen wichtigen Datenpunkt dar. Sie wird für Anwendungsfälle wie der Personalisierung von Diensten, Protokollierungen und auch für Sicherheitsaspekte wie z.B. Rate Limiting benötigt. In diesem Artikel soll es daher darum gehen, wie sich die tatsächliche IP-Adresse eines Clients in einer Spring Boot Anwendung zuverlässig und sicher ermitteln lässt.

Um eine Anwendung vor unliebsamen Traffic wie Spam oder andere Formen von automatisierten Requests zu schützen, können Rate Limits genutzt werden. In diesem Artikel beschreibe ich, wie sich Rate Limits pro IP-Adresse in einer Spring Boot Anwendung umsetzen lassen.