Comment partager le stockage entre les pods Kubernetes?
J'évalue Kubernetes en tant que plate-forme pour notre nouvelle application. Pour l'instant, cela a l'air très excitant! Cependant, je rencontre un problème: j’héberge mon cluster sur GCE et j’ai besoin d’un mécanisme pour partager le stockage entre deux pods - le serveur d’intégration continue et mon serveur d’applications. Quelle est la meilleure façon de faire cela avec les kubernetes? Aucun des types de volume ne semble répondre à mes besoins, car les disques GCE ne peuvent pas être partagés si un seul des modules doit écrire sur le disque. NFS serait parfait, mais semble nécessiter des options de construction spéciales pour le cluster Kubernetes?
EDIT: Le partage du stockage semble être un problème que j'ai rencontré à plusieurs reprises avec Kubernetes. Dans de nombreux cas d'utilisation, j'aimerais simplement disposer d'un volume et le connecter à plusieurs pods (avec accès en écriture). Je peux seulement supposer qu'il s'agirait d'un cas d'utilisation courant, non?
EDIT2: Par exemple, cette page explique comment configurer un cluster Elasticsearch, mais le connecter à un stockage persistant est impossible ( comme décrit ici ), ce qui le rend inutile :((
Un peu tard pour répondre à cette question, mais d'après mon expérience à ce jour de Kubernetes/MSA, le problème réside davantage dans votre modèle de conception. L'un des modèles de conception fondamentaux qui continuent à apparaître fréquemment dans MSA est l'encapsulation appropriée de vos services, qui inclut également ses données.
Votre service doit s'occuper des données liées à son domaine de préoccupation et, tout comme la POO, permettre l'accès à ces données à d'autres services via une interface (une API, un message PUBSUB, etc.). L'accès multiservices aux données est un anti-modèle s'apparentant à des variables globales en POO.
Je suppose que Google partage le même avis et c’est la raison pour laquelle Kubernetes est configuré de cette manière.
Par exemple, si vous souhaitez écrire des journaux, vous devez disposer d’un service de journalisation que chaque service peut appeler avec les données pertinentes qu’il doit consigner. Écrire directement sur un disque partagé signifie que vous devez mettre à jour tous les conteneurs si vous modifiez la structure de votre répertoire de journal, etc.
NFS est un plugin de volume intégré et prend en charge plusieurs rédacteurs de pod. Il n’existe aucune option de construction spéciale permettant à NFS de fonctionner dans Kube.
Je travaille chez Red Hat sur Kubernetes, principalement sur le stockage.
Avez-vous essayé Google Cloud Storage ? Vous pourrez peut-être même utiliser l’adaptateur Fuse pour le mapper comme un disque réseau.
Si ce sont des journaux que vous souhaitez écrire sur le disque, je vous suggère de regarder logspout https://github.com/gliderlabs/logspout . Cela collectera la journalisation de chaque pod, puis vous pourrez utiliser le tout nouveau service de journalisation de Google Cloud Platform, qui utilise fluentd. De cette façon, tous les journaux de chaque pod sont rassemblés dans un seul endroit.
Si ce sont des données qui écrivent normalement dans une base de données ou quelque chose de ce genre, je vous recommande de disposer d'un serveur séparé en dehors du cluster Kubernetes qui exécute la base de données.
MODIFIER
Pour partager des fichiers entre des pods, je vous recommande de monter un lecteur de stockage en nuage Google sur chaque nœud de votre cluster kubernetes, puis de le configurer en tant que volume dans chaque pod monté sur le répertoire monté sur le nœud et non directement. au lecteur. Le montage sur chaque nœud est une bonne chose, car les pods ne s'exécutent pas sur des nœuds désignés. Il est donc préférable de le centraliser dans ce cas.
Filestore dans le cloud récemment publié par Google, avec un tutoriel ici: https://cloud.google.com/filestore/docs/accessing-fileshares
Peut-être une bonne alternative au stockage en nuage/aux compartiments dans certains scénarios.
Pour partager un volume entre plusieurs pods, vous devez créer un PVC avec le mode d'accès ReadWriteMany.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: myvolume
resources:
requests:
storage: 1Gi
Après cela, vous pouvez le monter sur plusieurs 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'
Bien entendu, le volume persistant doit être accessible via le réseau. Sinon, vous devez vous assurer que tous les pods sont planifiés sur le noeud avec ce volume.
Il existe plusieurs types de volumes qui conviennent à cela et ne sont liés à aucun fournisseur de cloud:
- NFS
- RBD (Ceph Block Device)
- CephFS
- Glusterfs
- Portworx Volumes
Bien sûr, pour utiliser un volume, vous devez d'abord l'avoir. Autrement dit, si vous souhaitez utiliser NFS, vous devez configurer NFS sur tous les nœuds du cluster K8. Si vous souhaitez consommer Ceph, vous devez configurer le cluster Ceph, etc.
Portworks est le seul type de volume compatible avec Kubernetes prêt à l'emploi. Il existe des instructions sur comment le configurer dans GKE .
Pour installer le cluster Ceph dans les K8, un projet en développement appelé Rook .
Mais tout cela est excessif si vous souhaitez simplement qu'un dossier d'un nœud soit disponible dans un autre nœud. Dans ce cas, configurez simplement le serveur NFS. Cela ne serait pas plus difficile que de provisionner d'autres types de volumes et consommerait beaucoup moins de ressources processeur/mémoire/disque.
Avez-vous regardé kubernetes Volumes ? Vous envisagez probablement de créer un gcePersistentDisk
Un volume gcePersistentDisk monte un moteur de calcul Google (GCE) Disque persistant dans votre pod. Contrairement à emptyDir, qui est effacé lorsqu’un Le pod est supprimé, le contenu d'un PD est préservé et le volume est simplement démonté. Cela signifie qu'un PD peut être pré-rempli avec les données, et ces données peuvent être «transmises» entre les modules. Important: vous devez créez un PD à l'aide de gcloud ou de l'API ou de l'interface utilisateur de GCE avant de pouvoir l'utiliser Il existe certaines restrictions lors de l'utilisation d'un gcePersistentDisk: les nœuds Les machines virtuelles GCE sur lesquelles les pods sont en cours d’exécution doivent être dans le fichier Même projet GCE et même zone que le PD Une caractéristique de PD est qu’ils peuvent être monté en lecture seule par plusieurs consommateurs simultanément. Ce signifie que vous pouvez pré-renseigner un PD avec votre jeu de données, puis servir en parallèle avec autant de pods que vous le souhaitez. Malheureusement, les PD peuvent être monté par un seul consommateur en mode lecture-écriture - n ° __. écrivains simultanés autorisés. Utiliser un PD sur un pod contrôlé par un ReplicationController échouera sauf si le PD est en lecture seule ou le le nombre de répliques est 0 ou 1.
Pour prendre en charge plusieurs écritures à partir de divers pods, vous devrez probablement créer un pod robuste qui expose un service de types d'épargne ou de socket qui expose les méthodes readFromDisk et WriteToDisk.
@Marco - en ce qui concerne la question liée à Maven, mon conseil serait de cesser de considérer ce problème comme un problème de stockage centralisé et peut-être de le considérer comme une question de service.
J'ai déjà utilisé des référentiels Maven sous HTTP (en lecture seule). Je créerais simplement un dépôt Maven et l'exposerais sur Apache/Nginx dans son propre pod (conteneur docker) avec tout le stockage dédié dont vous avez besoin, puis utilisez la découverte de service pour le lier à votre application et à la construction de systèmes.