¿Cómo compartir almacenamiento entre pods de Kubernetes?

NFS es un plugin de volumen incorporado y soporta múltiples pod writers. No hay opciones especiales de compilación para que NFS funcione en Kube.

Trabajo en Red Hat en Kubernetes, centrado principalmente en el almacenamiento.

¿has probado , Google Cloud Storage? Es posible que incluso pueda usar el FUSE adapter para mapearlo como un disco de red.

Si está buscando escribir registros en el disco, le sugiero que mire logspout https://github.com/gliderlabs/logspout . Esto recopilará el registro de cada pod y luego puede usar el servicio de registro bastante nuevo de Google cloud platforms que usa fluentd. De esa manera todos los registros de cada vaina se recogen en un solo lugar.

Si se trata de datos que normalmente se escriben en una base de datos o algo de esa naturaleza, recomiendo tener un servidor separado fuera de kubernetes clúster que ejecuta la base de datos.

EDITAR

Para compartir archivos entre pods, recomiendo montar una unidad de almacenamiento de Google Cloud en cada nodo de tu clúster de kubernetes, y luego configurarla como un volumen en cada pod que se monte en ese directorio montado en el nodo y no directamente en la unidad. Tenerlo montado en cada nodo es bueno porque los pods no se ejecutan en nodos designados, por lo que es mejor centralizarlo en ese caso.

¿Has mirado los volúmenes de kubernetes ? Probablemente esté buscando crear un disco GCEPERSISTENT

Un volumen de disco GCEPERSISTENT monta un motor de Cómputo de Google (GCE) Disco persistente en su pod. A diferencia de emptyDir, que se borra cuando un Pod se elimina, el contenido de un PD se conserva y el volumen es simplemente sin montar. Esto significa que un PD puede ser rellenado previamente con datos, y esos datos pueden ser "entregados" entre pods. Importante: Debe crear un PD usar gcloud o la API o interfaz de usuario de GCE antes de poder usarla Hay algunas restricciones cuando se usa un disco GCEPERSISTENT: los nodos en qué pods se están ejecutando deben estar las máquinas virtuales GCE esas máquinas virtuales deben estar en el mismo proyecto y zona de GCE como el PD Una característica de PD es que pueden ser montado como de solo lectura por múltiples consumidores simultáneamente. Este significa que puede rellenar previamente un PD con su conjunto de datos y luego servir en paralelo de tantas vainas como necesites. Desafortunadamente, el PDs puede sólo ser montado por un solo consumidor en modo de lectura-escritura-no se permiten escritores simultáneos. Usando un PD en un pod controlado por un ReplicationController fallará a menos que el PD sea de el recuento de réplicas es 0 o 1.

Para soportar múltiples escrituras desde varios pods, probablemente necesitará crear un pod carnoso que exponga un servicio de ahorro o tipos de socket que exponga los métodos readFromDisk y WriteToDisk.

@Marco - con respecto a la pregunta relacionada con Maven, mi consejo sería dejar de considerar esto como un problema de almacenamiento centralizado y tal vez pensar en ello como un problema de servicio.

He ejecutado repositorios Maven bajo HTTP en el pasado (solo lectura). Simplemente crearía un repositorio Maven y lo expondría a través de Apache / Nginx en su propio pod (contenedor docker) con todo el almacenamiento dedicado que necesite para ese pod y luego usaría service discovery para vincularlo a su aplicación y compilar sistemas.

Lo que está tratando de hacer es opuesto al propósito de kubernetes, ya que cada uno de los pods más encapsulados, debe buscar otras alternativas de almacenamiento:

1. Blobs (imágenes,videos,audio), debe usar almacenamiento en la nube
2. Para los registros, debe usar stackdriver
3. de Otro modo debería bigquery almacén de datos bigtable sql llave

Google tiene disco persistente eso puede lograr lo que estás tratando de hacer, pero como he dicho es mejor que elijas otras opciones Incluso en el diagrama de Google no recomienda persistent-disk

Google lanzó recientemente cloud filestore, con un tutorial aquí: https://cloud.google.com/filestore/docs/accessing-fileshares

Podría ser una buena alternativa al almacenamiento en la nube/buckets para algunos escenarios.

Para compartir un volumen entre múltiples pods, debe crear un PVC con modo de acceso ReadWriteMany

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

Después de eso puedes montarlo en múltiples pods:

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'

Por supuesto, el volumen persistente debe ser accesible a través de la red. De lo contrario, deberá asegurarse de que todos los pods estén programados en el nodo con ese volumen.

Hay varios tipos de volumen que son adecuados para eso y no están vinculados a ningún proveedor de nube:

• NFS
• RBD (Ceph Dispositivo de bloqueo)
• CephFS
• Glusterfs
• Portworx Volumes

Por supuesto, para usar un volumen, primero debe tenerlo. Es decir, si desea consumir NFS, debe configurar NFS en todos los nodos del clúster K8s. Si desea consumir Ceph, debe configurar Ceph cluster, etc.

El único tipo de volumen que soporta Kubernetes es Portworks. Hay instrucciones sobre cómo configurarlo en GKE.

Para configurar el clúster de Ceph en K8s hay un proyecto en desarrollo llamado Rook .

Pero esto es demasiado si solo desea que una carpeta de un nodo esté disponible en otro nodo. En este caso, simplemente configure el servidor NFS. No sería más difícil que aprovisionar otros tipos de volúmenes y consumirá mucho menos recursos de cpu/memoria/disco.