tutorial ingress google create cluster docker google-cloud-platform kubernetes

docker - ingress - ¿Cómo compartir almacenamiento entre las vainas Kubernetes?



kubernetes vs docker (9)

¿Has mirado los Volumes kubernetes? Probablemente estés buscando crear un gcePersistentDisk

Un volumen gcePersistentDisk monta un disco persistente de Google Compute Engine (GCE) en su pod. A diferencia de emptyDir, que se borra cuando se quita un Pod, el contenido de un PD se conserva y el volumen simplemente se desmonta. Esto significa que un PD puede rellenarse previamente con datos, y que los datos pueden ser "entregados" entre los pods. Importante: debe crear un PD con gcloud o la API o la interfaz de usuario de GCE antes de poder usarlo. Existen algunas restricciones al usar gcePersistentDisk: los nodos en los que se ejecutan los pods deben ser máquinas virtuales de GCE. Estas máquinas virtuales deben estar en el mismo proyecto de GCE. y la zona como el PD Una de las características del PD es que pueden ser montados como solo lectura por varios consumidores simultáneamente. Esto significa que puede rellenar previamente un PD con su conjunto de datos y luego servirlo en paralelo desde tantos pods como necesite. Desafortunadamente, los PD solo pueden ser montados por un solo consumidor en modo de lectura y escritura, no se permiten escritores simultáneos. El uso de un PD en un pod controlado por un ReplicationController fallará a menos que el PD sea de solo lectura o el número de réplicas sea 0 o 1.

Para admitir múltiples escrituras de varios pods, probablemente deba crear un pod que le muestre un servicio de tipos de ahorro o socket que exponga los métodos readFromDisk y WriteToDisk.

Estoy evaluando a Kubernetes como una plataforma para nuestra nueva aplicación. Por ahora, todo parece muy emocionante! Sin embargo, tengo un problema: alojo mi clúster en GCE y necesito algún mecanismo para compartir el almacenamiento entre dos pods: el servidor de integración continua y mi servidor de aplicaciones. ¿Cuál es la mejor manera de hacer esto con kubernetes? Ninguno de los tipos de volumen parece satisfacer mis necesidades, ya que los discos GCE no se pueden compartir si un pod necesita escribir en el disco. ¿NFS sería perfecto, pero parece requerir opciones de compilación especiales para el clúster kubernetes?

EDITAR: compartir almacenamiento parece ser un problema que me he encontrado varias veces ahora usando Kubernetes. Hay varios casos de uso en los que me gustaría tener un volumen y conectarlo a varios pods (con acceso de escritura). Solo puedo asumir que este sería un caso de uso común, ¿no?

EDIT2: por ejemplo, esta página describe cómo configurar un clúster de Elasticsearch, pero es imposible conectarlo con un almacenamiento persistente ( como se describe aquí ), lo que hace que no tenga sentido :(

@Marco: en lo que respecta a la pregunta relacionada con Maven, mi consejo sería dejar de ver esto como un problema de almacenamiento centralizado y quizás considerarlo como un problema de servicio.

He ejecutado repositorios de Maven bajo HTTP en el pasado (solo lectura). Simplemente crearía un repositorio de Maven y lo expondría sobre Apache / Nginx en su propio pod (contenedor docker) con el almacenamiento dedicado que necesite para ese pod y luego utilizaré el descubrimiento de servicios para vincularlo a su aplicación y sistemas de compilación.

Lo que estás tratando de hacer es opuesto al propósito de kubernetes, ya que cada una de las cápsulas está más encapsulada, debes buscar otras alternativas de almacenamiento:

  1. Blobs (imágenes, videos, audio), debe usar almacenamiento en la nube
  2. Para los registros, debe utilizar stackdriver
  3. Por otra parte, deberías bigquery datastore bigtable sql spanner

Google tiene persistent-disk que puede lograr lo que usted está tratando de hacer, pero como dije, es mejor que elija otras options Incluso en el diagrama de Google no se recomienda persistent-disk

NFS es un complemento de volumen incorporado y es compatible con múltiples escritores de pod. No hay opciones de compilación especiales para que NFS funcione en Kube.

Trabajo en Red Hat en Kubernetes, enfocado principalmente en almacenamiento.

Para compartir un volumen entre múltiples pods, necesitaría 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 para el nodo con ese volumen.

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

  • NFS
  • RBD (Ceph Block Device)
  • CephFS
  • Glusterfs
  • Volúmenes de Portworx

Por supuesto, para usar un volumen necesitas tenerlo primero. Es decir, si desea consumir NFS, necesita configurar NFS en todos los nodos del clúster K8s. Si desea consumir Ceph, necesita configurar el clúster de Ceph y así sucesivamente.

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

Para configurar el cluster Ceph en K8s hay un proyecto en desarrollo llamado Rook .

Pero todo esto es excesivo si solo desea que una carpeta de un nodo esté disponible en otro nodo. En este caso basta con configurar el servidor NFS. No sería más difícil que aprovisionar otros tipos de volumen y consumirá muchos menos recursos de cpu / memoria / disco.

Un poco tarde para responder a esta pregunta, pero desde mi experiencia hasta ahora en Kubernetes / MSA, el problema aquí es más en su patrón de diseño. Uno de los patrones de diseño fundamentales que sigue apareciendo con frecuencia en MSA es la encapsulación adecuada de sus servicios, que también incluye sus datos.

Su servicio debe cuidar los datos relacionados con su área de preocupación y, al igual que OOP, debe permitir el acceso a estos datos a otros servicios a través de una interfaz (una API, un mensaje PUBSUB, etc.). El acceso multiservicio a los datos es un anti-patrón similar a las variables globales en OOP.

Supongo que Google también tiene la misma opinión y esta es la razón por la que Kubernetes está configurado de esta manera.

Como ejemplo, si estaba buscando escribir registros, debería tener un servicio de registro al que cada servicio pueda llamar con los datos relevantes que necesita para registrar. Escribir directamente en un disco compartido significa que necesitaría actualizar cada contenedor si cambia la estructura del directorio de registro, etc. o decide agregar funcionalidad adicional como correos electrónicos en caso de errores.

Si lo que está buscando es escribir en el disco, le sugiero que busque en logspout https://github.com/gliderlabs/logspout . Esto recopilará el registro de cada pod y luego podrá usar el servicio de registro bastante nuevo de las plataformas de nube de Google que utiliza fluentd. De esa manera, todos los registros de cada pod se reúnen en un solo lugar.

Si son datos que normalmente se escribirían en una base de datos o algo de esa naturaleza, recomiendo tener un servidor separado fuera del clúster de kubernetes que ejecuta la base de datos.

EDITAR

Para compartir archivos entre pods, recomiendo montar una unidad de almacenamiento en la nube de google en cada nodo de su clúster de kubernetes, luego configurarlo como un volumen en cada pod que se monta 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 los nodos designados, por lo que es mejor centralizarlo en ese caso.