Statefulset Kubernetes con volume persistente NFS
Ho un kubernetescluster e ho una semplice distribuzione per mongodbcon NFSset di volumi persistenti. Funziona bene, ma poiché risorse come i database sono statefulpensate di utilizzare Statefulsetper il mongodb, ma ora il problema è che, quando passo la documentazione, statefulset volumeClaimTemplatesinvece di volumes(nelle distribuzioni).
Ma ora arriva il problema.
in un deploymentfarlo in questo modo:
PersistentVolume-> PersistentVolumeClaim->Deployment
Ma come possiamo farlo Statefulset?
È come:
volumeClaimTemplates -> StatefulSet
Come posso impostare una PersistentVolumeper il volumeClaimTemplates. Se non usiamo PersistentVolumeper StatefulSet, come crea il volume e DOVE crea i volumi? È nelle hostmacchine (cioè i nodi di lavoro kubernetes)?
Poiché ho un NFSprovisioner separato che utilizzo per la mongodbdistribuzione (con replicasset = 1), come posso utilizzare la stessa configurazione con StatefulSet?
Ecco il mio mongo-deployment.yaml-> che trasformerò in un statefulset come mostrato nel secondo frammento di codice ( mongo-stateful.yaml)
mongo-deployment.yaml
<omitted>
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
name: mynfs # name can be anything
spec:
storageClassName: manual # same storage class as pvc
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
nfs:
server: <nfs-server-ip>
path: "/srv/nfs/mydata"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteMany # must be the same as PersistentVolume
resources:
requests:
storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mongodb-deployment
labels:
name: mongodb
spec:
selector:
matchLabels:
app: mongodb
replicas: 1
template:
metadata:
labels:
app: mongodb
spec:
containers:
- name: mongodb
image: mongo
ports:
- containerPort: 27017
... # omitted some parts for easy reading
volumeMounts:
- name: data
mountPath: /data/db
volumes:
- name: data
persistentVolumeClaim:
claimName: task-pv-claim
mongo-stateful.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
name: mynfs # name can be anything
spec:
storageClassName: manual # same storage class as pvc
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
server: <nfs-server-ip>
path: "/srv/nfs/mydata"
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mongodb-statefulset
spec:
selector:
matchLabels:
name: mongodb-statefulset
serviceName: mongodb-statefulset
replicas: 2
template:
metadata:
labels:
name: mongodb-statefulset
spec:
terminationGracePeriodSeconds: 10
containers:
- name: mongodb
image: mongo:3.6.4
ports:
- containerPort: 27017
volumeMounts:
- name: db-data
mountPath: /data/db
volumeClaimTemplates:
- metadata:
name: db-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "manual"
resources:
requests:
storage: 2Gi
Ma questo non funziona ( mongo-stateful.yaml) i pod sono nello pendingstato come quando lo descrivo mostra:
sono disponibili 0/3 nodi di default-scheduler: 1 nodo / i aveva contaminazione {node-role.kubernetes.io/master:}, che il pod non tollerava, 2 pod ha PersistentVolumeClaims immediati non associati
PS: la distribuzione funziona bene senza errori, il problema è con Statefulset
Qualcuno può aiutarmi, come scrivere un statefulset con i volumi?
Risposte
Se la tua classe di archiviazione non supporta il provisioning dinamico del volume, devi creare manualmente PV e PVC associati , utilizzando i file yaml, quindi il volumeClaimTemplates consentirà di collegare i PVC esistenti con i pod del tuo statefulset.
Ecco un esempio funzionante: https://github.com/k8s-school/k8s-school/blob/master/examples/MONGODB-install.sh
Dovresti:
- eseguirlo localmente su https://kind.sigs.k8s.io/, che supportano il provisioning dinamico del volume, quindi qui PVC e PV verranno creati automaticamente
- esportare file yaml di PV e PVC
- usa questi file yaml come modello per creare i tuoi PV e PVC per il tuo backend NFS.
Ecco cosa otterrai su Kind:
$ ./MONGODB-install.sh + kubectl apply -f 13-12-mongo-configmap.yaml configmap/mongo-init created + kubectl apply -f 13-11-mongo-service.yaml service/mongo created + kubectl apply -f 13-14-mongo-pvc.yaml statefulset.apps/mongo created $ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo-0 2/2 Running 0 8m38s
mongo-1 2/2 Running 0 5m58s
mongo-2 2/2 Running 0 5m45s
$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE database-mongo-0 Bound pvc-05247511-096e-4af5-8944-17e0d8222512 1Gi RWO standard 8m42s database-mongo-1 Bound pvc-f53c35a4-6fc0-4b18-b5fc-d7646815c0dd 1Gi RWO standard 6m2s database-mongo-2 Bound pvc-2a711892-eeee-4481-94b7-6b46bf5b76a7 1Gi RWO standard 5m49s $ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-05247511-096e-4af5-8944-17e0d8222512 1Gi RWO Delete Bound default/database-mongo-0 standard 8m40s
pvc-2a711892-eeee-4481-94b7-6b46bf5b76a7 1Gi RWO Delete Bound default/database-mongo-2 standard 5m47s
pvc-f53c35a4-6fc0-4b18-b5fc-d7646815c0dd 1Gi RWO Delete Bound default/database-mongo-1 standard 6m1s
E un dump di un PVC (generato qui da volumeClaimTemplateperché odf kind dynamic volume provisionning):
$ kubectl get pvc database-mongo-0 -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: rancher.io/local-path
volume.kubernetes.io/selected-node: kind-worker2
creationTimestamp: "2020-10-16T15:05:20Z"
finalizers:
- kubernetes.io/pvc-protection
labels:
app: mongo
managedFields:
...
name: database-mongo-0
namespace: default
resourceVersion: "2259"
selfLink: /api/v1/namespaces/default/persistentvolumeclaims/database-mongo-0
uid: 05247511-096e-4af5-8944-17e0d8222512
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard
volumeMode: Filesystem
volumeName: pvc-05247511-096e-4af5-8944-17e0d8222512
status:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
phase: Bound
E il relativo PV:
kubectl get pv pvc-05247511-096e-4af5-8944-17e0d8222512 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/provisioned-by: rancher.io/local-path
creationTimestamp: "2020-10-16T15:05:23Z"
finalizers:
- kubernetes.io/pv-protection
managedFields:
...
name: pvc-05247511-096e-4af5-8944-17e0d8222512
resourceVersion: "2256"
selfLink: /api/v1/persistentvolumes/pvc-05247511-096e-4af5-8944-17e0d8222512
uid: 3d1e894e-0924-411a-8378-338e48ba4a28
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 1Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: database-mongo-0
namespace: default
resourceVersion: "2238"
uid: 05247511-096e-4af5-8944-17e0d8222512
hostPath:
path: /var/local-path-provisioner/pvc-05247511-096e-4af5-8944-17e0d8222512_default_database-mongo-0
type: DirectoryOrCreate
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- kind-worker2
persistentVolumeReclaimPolicy: Delete
storageClassName: standard
volumeMode: Filesystem
status:
phase: Bound