it-swarm.com.de

So teilen Sie den Speicher zwischen Kubernetes-Pods

Ich bewerte Kubernetes als Plattform für unsere neue Anwendung. Im Moment sieht alles sehr aufregend aus! Ich habe jedoch ein Problem: Ich hosten mein Cluster in GCE und ich brauche einen Mechanismus, um Speicher zwischen zwei Pods zu teilen - dem Continuous Integration Server und meinem Anwendungsserver. Was ist der beste Weg, dies mit Kubernetes zu tun? Keiner der Volumetypen scheint meinen Bedürfnissen zu entsprechen, da GCE-Festplatten nicht freigegeben werden können, wenn ein Pod auf die Festplatte schreiben muss. NFS wäre perfekt, erfordert aber spezielle Build-Optionen für den Kubernetes-Cluster.

BEARBEITEN: Das Freigeben von Speicher scheint ein Problem zu sein, auf das ich jetzt mehrmals mit Kubernetes gestoßen bin. Es gibt mehrere Anwendungsfälle, bei denen ich nur ein Volume hätte und es an mehrere Pods (mit Schreibzugriff) anschließen würde. Ich kann nur davon ausgehen, dass dies ein allgemeiner Anwendungsfall wäre, nein?

EDIT2: Zum Beispiel diese Seite wird beschrieben, wie ein Elasticsearch-Cluster eingerichtet wird, es ist jedoch keine permanente Speicherung möglich ( wie hier beschrieben ).

28
Marco Lamina

Ein wenig spät, um diese Frage zu beantworten, aber aus meiner bisherigen Erfahrung mit Kubernetes/MSA geht es hier mehr um Ihr Design. Eines der grundlegenden Designmuster, das in MSA immer noch häufig auftritt, ist die ordnungsgemäße Kapselung Ihrer Services, die auch die Daten einschließt.

Ihr Dienst sollte sich um die Daten kümmern, die sich auf seinen betroffenen Bereich beziehen, und ähnlich wie OOP sollte der Zugriff auf diese Daten auf andere Dienste über eine Schnittstelle (eine API, eine PUBSUB-Nachricht usw.) erfolgen. Der Multi-Service-Zugriff auf Daten ist ein Muster, das den globalen Variablen in OOP ähnelt.

Ich gehe davon aus, dass auch Google die gleiche Meinung hat, und deshalb ist Kubernetes auf diese Weise eingerichtet.

Wenn Sie beispielsweise Protokolle schreiben möchten, sollten Sie über einen Protokolldienst verfügen, den jeder Dienst mit den relevanten Daten aufrufen kann, die er protokollieren muss. Wenn Sie direkt auf eine gemeinsam genutzte Festplatte schreiben, müssen Sie jeden Container aktualisieren, wenn Sie die Protokollverzeichnisstruktur usw. ändern oder zusätzliche Funktionen wie E-Mails bei Fehlern hinzufügen möchten.

21
Ian Belcher

NFS ist ein integriertes Volume-Plugin und unterstützt mehrere Pod-Schreiber. Es gibt keine speziellen Build-Optionen, um NFS in Kube zum Laufen zu bringen.

Ich arbeite bei Red Hat für Kubernetes und konzentriere mich hauptsächlich auf die Speicherung.

21
Mark Turansky

Haben Sie versucht, Google Cloud Storage ? Sie können sogar den Fuse-Adapter verwenden, um ihn wie eine Netzwerkfestplatte abzubilden.

3
Sandeep Dinesh

Wenn es sich um Protokolle handelt, die Sie auf die Festplatte schreiben möchten, sollten Sie sich logspout https://github.com/gliderlabs/logspout ansehen. Dadurch wird die Protokollierung jedes Pods erfasst, und Sie können den recht neuen Protokollierungsdienst von Google Cloud-Plattformen verwenden, der fluentd verwendet. Auf diese Weise werden alle Protokolle von jedem Pod an einem einzigen Ort gesammelt.

Wenn es sich um Daten handelt, die normalerweise in eine Datenbank oder etwas Ähnliches schreiben würden, empfehle ich einen separaten Server außerhalb des kubernetes-Clusters, auf dem die Datenbank ausgeführt wird.

EDIT

Um Dateien unter Pods gemeinsam zu nutzen, empfehle ich, ein Google Cloud-Speicherlaufwerk an jedem Knoten in Ihrem Kubernetes-Cluster zu installieren und dieses dann als Volume in jedem Pod einzurichten, der in das gemountete Verzeichnis auf dem Knoten und nicht direkt geladen wird zum Laufwerk. Das Einhängen in jeden Knoten ist gut, da Pods nicht auf bestimmten Knoten ausgeführt werden. In diesem Fall ist es am besten, sie zu zentralisieren.

3

Kürzlich veröffentlichte Google den Cloud-Dateispeicher. Hier finden Sie ein Tutorial: https://cloud.google.com/filestore/docs/accessing-fileshares

In manchen Szenarien kann dies eine gute Alternative zu Cloud-Storage/Buckets sein.

2
Geige V

Um ein Volume für mehrere Pods freizugeben, müssen Sie ein PVC mit Zugriffsmodus ReadWriteMany erstellen

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
    name: my-pvc
spec:
    accessModes:
      - ReadWriteMany
    storageClassName: myvolume
    resources:
        requests:
            storage: 1Gi

Danach können Sie es in mehrere Pods einbinden:

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app1
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'

Natürlich muss ein dauerhafter Datenträger über das Netzwerk erreichbar sein. Andernfalls müssen Sie sicherstellen, dass alle Pods auf dem Knoten mit diesem Volume geplant sind.

Dafür gibt es mehrere Datenträgertypen, die nicht an einen Cloud-Anbieter gebunden sind:

  • NFS
  • RBD (Ceph Block Device)
  • CephFS
  • Glusterfs
  • Portworx Volumes

Um ein Volume zu verwenden, müssen Sie es natürlich zuerst haben. Das heißt, wenn Sie NFS nutzen möchten, müssen Sie NFS auf allen Knoten im K8s-Cluster einrichten. Wenn Sie Ceph konsumieren möchten, müssen Sie den Ceph-Cluster usw. einrichten.

Der einzige Volumetyp, der Kubernetes standardmäßig unterstützt, ist Portworks. Es gibt Anweisungen zum wie man es in GKE einrichtet.

Um ein Ceph-Cluster in K8s einzurichten, befindet sich ein Projekt in der Entwicklung namens Rook .

Dies ist jedoch übertrieben, wenn Sie möchten, dass ein Ordner von einem Knoten in einem anderen Knoten verfügbar ist. In diesem Fall richten Sie einfach den NFS-Server ein. Es wäre nicht schwieriger als das Bereitstellen anderer Datenträgertypen und verbraucht viel weniger CPU-/Speicher-/Festplattenressourcen.

2
Vanuan

Hast du dir kubernetes Volumes angesehen? Wahrscheinlich möchten Sie eine gcePersistentDisk erstellen

Ein gcePersistentDisk-Volume hängt eine Google Compute Engine (GCE) Persistent Disk in Ihre Pod. Im Gegensatz zu emptyDir, das gelöscht wird, wenn ein Der Pod wird entfernt, der Inhalt eines PD bleibt erhalten und das Volume ist nur unmontiert. Dies bedeutet, dass ein PD mit Daten vorbelegt werden kann und diese Daten können zwischen den Pods „verteilt“ werden. Wichtig: Sie müssen Erstellen Sie ein PD mit gcloud oder der GCE-API oder der Benutzeroberfläche, bevor Sie es verwenden können Bei der Verwendung einer gcePersistentDisk gibt es einige Einschränkungen: Die Knoten Auf welchen Pods müssen GCE-VMs ausgeführt werden, die sich in der .__ befinden müssen. dasselbe GCE-Projekt und dieselbe Zone wie PD Eine Funktion von PD besteht darin, dass sie von mehreren Verbrauchern gleichzeitig schreibgeschützt montiert werden. Diese bedeutet, dass Sie eine PD mit Ihrem Dataset vorbelegen können und dann Parallel dazu aus beliebig vielen Hülsen. Leider können PDs nur von einem einzelnen Consumer im Read-Write-Modus eingehängt werden - nein gleichzeitige Verfasser erlaubt. Verwenden eines PD auf einem Pod, der von einem .__ gesteuert wird. ReplicationController schlägt fehl, es sei denn, der PD ist schreibgeschützt oder der Replikatanzahl ist 0 oder 1.

Um mehrere Schreibvorgänge aus verschiedenen Pods zu unterstützen, müssen Sie wahrscheinlich einen bulligen Pod erstellen, der einen Thrift- oder Socket-Type-Service verfügbar macht, der die Methoden readFromDisk und WriteToDisk verfügbar macht. 

2
varun

@Marco - in Bezug auf die Maven-bezogene Frage würde ich raten, dieses Problem nicht mehr als zentrales Speicherproblem zu betrachten und vielleicht als Serviceproblem zu betrachten. 

Ich habe in der Vergangenheit Maven-Repositorys unter HTTP ausgeführt (schreibgeschützt). Ich würde einfach ein Maven-Repo erstellen und es über Apache/Nginx in seinem eigenen Pod (Docker-Container) mit dem dedizierten Speicher, den Sie gerade für diesen Pod benötigen, freigeben. Anschließend können Sie es mithilfe von Service Discovery mit Ihrer Anwendung verbinden und Systeme erstellen. 

0
Dave Thomson