Viele "Legacy-Kunden" haben teilweise über die Jahre große Datenmengen angesammelt, die sie in der Regel auf NFS-Volumes speichern. Auch auf Ihrer "journey into the cloud" wollen sie diese Daten natürlich nicht missen. Gleichzeitig sind NFS und Cloud Dinge, die nicht in allen Fällen harmonieren. Insbesondere wenn "cloud" mit "Kubernetes" übersetzt wird. So ist es z. B. in Umgebungen mit "Managed Kubernetes" in der Regel unerwünscht, dass Kunden Zugriff auf die einzelnen VMs erhalten, auf denen ihr Kubernetes-Cluster läuft. Stattdessen erhalten sie Zugriff auf die Kubernetes-API und ggfs. noch ein Kubernetes-Dashboard, um sich auch visuell über den Status ihres Clusters informieren zu können.
Für Kunden ist es also in der Regel nicht möglich in so einer Umgebung NFS-Volumes an die Knoten zu mounten aus denen ihr Kubernetes-Cluster besteht. Die einzige Möglichkeit besteht darin, einen externen NFS-Server als "physical volume" zu definieren und dann in die Pods zu mounten, die Zugriff benötigen.
Genau für diesen Zweck gibt es im Kubernetes-Repository einen Strauß an Beispielen: https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs
Ein PV würde z. B. so konfiguriert:
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs
spec:
capacity:
storage: 1Mi
accessModes:
- ReadWriteMany
nfs:
server: nfs-server.default.svc.cluster.local
path: "/"
Und dieser könnte dann mit einem PVC "geclaimed" werden:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs
spec:
accessModes:
- ReadWriteMany
storageClassName: ""
resources:
requests:
storage: 1Mi
Damit alles "wie immer" funktioniert, müssen aber noch andere Parameter beachtet werden. Insbesondere muss natürlich die uid/gid im Container zum NFS-Volume passen. Damit das NFS-Volume überhaupt erreichbar wird, muss es entweder von einer Maschine, an der es gemountet ist, re-exportiert werden oder die IP-Adresse des Shares muß über eine Firewall geNATtet werden - was nicht ganz einfach sein dürfte, da die Kundenfirewalls im Storagenetz in der Regel kein Interface haben sollten.
Eine andere Möglichkeit besteht darin, die NFS-Volumes von einer Maschine, die diese gemountet hat, per S3 (und minio) für Kubernetes verfügbar zu machen. Im konkreten Fall z. B. diese:
/nfs/kdftp/hybris_transfer/Inbound/B2BUnits
/nfs/kdftp/hybris_transfer/Inbound/ProductionLines
In dem Volume kann nur der User hybris_transfer schreiben. Um nur genau diese Verzeichnisse freizugeben, muß man zwei minio-Prozesse starten:
su hybris_transfer -c 'export MINIO_ROOT_USER=htransfer ; export MINIO_ROOT_PASSWORD=geheim ; cd /nfs/kdftp/hybris_transfer/Inbound/B2BUnits ; /var/tmp/minio --quiet server /nfs/kdftp/hybris_transfer/Inbound/B2BUnits --address "10.62.249.142:6666" --console-address "10.62.249.142:6667"'
su hybris_transfer -c 'export MINIO_ROOT_USER=htransfer ; export MINIO_ROOT_PASSWORD=geheim ; cd /nfs/kdftp/hybris_transfer/Inbound/ProductionLines ; /var/tmp/minio --quiet server /nfs/kdftp/hybris_transfer/Inbound/ProductionLines --address "10.62.249.149:5555" --console-address "10.62.249.149:5556"'
Der Parameter "--console-address" startet eine GUI am angegebenen Port, über welche man grafisch durch die Verzeichnisse brausen kann.
Wie ich erfahren habe, gibt es "Bucket Naming Rules", die eingehalten werden sollten, damit die Spezifikation stimmt.
Auf die Idee hat mich damals übrigens napp-it gebracht, wo ich den Re-Export von NFS-Volumes als S3-Buckets zum ersten Mal gesehen hatte.