MinIO ist ein offenes, AWS/S3 API kompatibles Object-Storage System, welches hervorragend dazu geeignet ist, in Kubernetes betrieben zu werden. Die Installation einer produktionsreifen Konfiguration gestaltet sich äußerst einfach.

Die einzigen beiden Voraussetzungen sind der Zugriff auf einen Kubernetes Cluster und HELM (in Version 3). Sollte der Cluster noch nicht bereit stehen, kannst du natürlich Minikube verwenden oder dir einmal k3s ansehen, damit kann man in wenigen Sekunden einen schlüsselfertigen Single-Node Kubernetes Cluster aufsetzen. Den Kubernetes Paketmanager HELM werde ich für die Installation von MinIO verwenden.

Egal mit welcher Cryptowährung man hantiert, es empfiehlt sich immer eine eigene Kopie der Blockchain zu besitzen, nicht nur um - im Falle transparenter Transaktionen - Einsicht zu erhalten, sondern primär um sich vor potentiellen Angriffen zu schützen, sich unabhängig von remote nodes zu machen und natürlich um das Netzwerk zu unterstützen. Nur so kann man den großen Vorteil einer Blockchain - die Dezentralität - überhaupt erst sinnvoll nutzen.

Insbesondere bei privacy coins, wie Monero - aber natürlich auch bei allen anderen Cryptowährungen - lohnt es sich, seinen Node via TOR (oder einem anderen Anonymisierungsnetzwerks wie I2P ) als HiddenService bereitzustellen und sich auf diese Weise von seinem lokalen PC aus zu verbinden.

In einem recht restriktivem Netzwerk benötigte ich eine Möglichkeit, um auf diverse interne Dienste über das Internet zugreifen zu können. Diesen Anlass nahm ich als Gelegenheit um etwas mit TOR und Onioncat herumzuspielen. Mein primäres Ziel war es, sicheren Zugriff auf den internen Mailserver zu gewähren, sodass ich E-Mails abrufen kann ohne direkt mit dem LAN verbunden zu sein.

TOR dient hier lediglich als Transportebene, so ist keine Portweiterleitung im Router notwendig. Onioncat wird als hidden-service bereitgestellt und erzeugt ein Overlay-Netzwerk, welches IPv6 als Protokoll auf Layer 3 verwendet. Die Dienste sind dann später über eine statische IPv6 Adresse via TOR/Onioncat erreichbar.

Hier sehe ich mir an, wie ich einen Multi-Master Kubernetes Cluster auf Basis von Rancher/k3s aufsetze. Als Hardwareplattform verwende ich fünf Raspberry Pi 3b+ in einem Picocluster auf denen HypriotOS läuft.

Die Hochverfügbarkeit des Kubernetes Clusters wird durch die Verwendung von HA-Proxy und keepalived erreicht. Eine virtuelle Failover IP-Adresse zeigt so immer auf einen verfügbaren Kubernetes Apiserver. Persistenter Speicherplatz mit Unterstützung für read-write many Zugriff wird Dank Rook über ein verteiltes Clusterfilesystem bereitgestellt, der den verfügbaren Speicherplatz der RPi SD-Karten nutzt.

Vor ein paar Tagen sollte ein älterer, bis dato ungenutzter, Server in Betrieb genommen werden, hierbei machten wir eine unerwartete Entdeckung: Ein unbekannter Prozess lastete alle verbauten CPUs bis zum Anschlag aus.

Da der Server noch nicht in das Produktionsnetzwerk überführt und somit auch nicht an das Monitoringsystem angeschlossen wurde, konnte das Problem über längere Zeit unerkannt bleiben.