Не могу хранить данные на моем постоянном томе в Kubernetes (Google Cloud)

У меня есть модуль Redis в моем кластере Kubernetes в Google Cloud. Я построил ПВ и иск.

kind: PersistentVolume
apiVersion: v1
metadata:
  name: redis-pv
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: my-size 
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: postgres
  name: redis-pv-claim
spec:
  storageClassName: manual
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: my size 

Я также установил его в свой deployment.yaml

volumeMounts:
      - mountPath: /data
        name: redis-pv-claim
    volumes:
    - name: redis-pv-claim
      persistentVolumeClaim:
        claimName: redis-pv-claim  

Я не вижу ошибок во время работы модуля описания

Volumes:
  redis-pv-claim:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  redis-pv-claim
    ReadOnly:   false

Но он просто не может сохранить ни один ключ. После каждого развертывания папка «/ data» просто пуста.

Моя NFS сейчас активна, но я все еще не могу хранить данные.

Опишите ПВХ


Namespace:     my namespace 
StorageClass:  nfs-client
Status:        Bound
Volume:        pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-class: nfs-client
               volume.beta.kubernetes.io/storage-provisioner: cluster.local/ext1-nfs-client-provisioner
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Gi
Access Modes:  RWX
VolumeMode:    Filesystem
Mounted By:    my grafana pod
Events:        <none>

Однако Describe pod выдает ошибку.


Warning  FailedMount  18m   kubelet, gke-devcluster-pool-1-36e6a393-rg7d  MountVolume.SetUp failed for volume "pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3" : mount failed: exit status 1
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/8f7b6630-ed9b-427a-9ada-b75e1805ed60/volumes/kubernetes.io~nfs/pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3 --scope -- /
home/kubernetes/containerized_mounter/mounter mount -t nfs 192.168.1.21:/mnt/nfs/development-test-claim-pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3 /var/lib/kubelet/pods/8f7b6630-ed9b-427a-9ada-b75e1805ed60
/volumes/kubernetes.io~nfs/pvc-5d278b27-a51e-4262-8c1b-68b290b21fc3
Output: Running scope as unit: run-ra5925a8488ef436897bd44d526c57841.scope
Mount failed: mount failed: exit status 32
Mounting command: chroot

person Pasha    schedule 31.03.2020    source источник


Ответы (1)


Что происходит, когда у вас есть несколько узлов, использующих PVC для обмена файлами между модулями, это не лучший подход.

PVC могут обмениваться файлами между модулями, находящимися в одном узле. Поэтому, если у меня несколько узлов, иногда может сложиться впечатление, что мои файлы не хранятся должным образом.

Идеальным решением для вас является использование любого доступного решения DSF. В своем вопросе вы упоминаете, что используете GCP, и неясно, используете ли вы GKE или создали свой кластер поверх вычислительных экземпляров.

Если вы используете GKE, проверяли ли вы этот документ? ? Пожалуйста, дай мне знать.

Если у вас есть доступ к вашим узлам, самая простая установка, которую вы можете сделать, - это создать сервер NFS на одном из ваших узлов и использовать nfs-client-provisioner, чтобы предоставить доступ к серверу nfs из ваших модулей.

Я использую этот подход довольно давно, и он действительно хорошо работает.

1 - Установите и настройте NFS-сервер на моем главном узле (Debian Linux, это может измениться в зависимости от вашего дистрибутива Linux):

Перед установкой сервера ядра NFS нам необходимо обновить индекс репозитория нашей системы:

$ sudo apt-get update

Теперь выполните следующую команду, чтобы установить сервер ядра NFS в вашей системе:

$ sudo apt install nfs-kernel-server

Создайте каталог экспорта

$ sudo mkdir -p /mnt/nfs_server_files

Поскольку мы хотим, чтобы все клиенты имели доступ к каталогу, мы удалим ограничительные разрешения для папки экспорта с помощью следующих команд (это может варьироваться в зависимости от вашей настройки в соответствии с вашей политикой безопасности):

$ sudo chown nobody:nogroup /mnt/nfs_server_files
$ sudo chmod 777 /mnt/nfs_server_files

Назначьте серверный доступ клиенту (ам) через файл экспорта NFS

$ sudo nano /etc/exports

Внутри этого файла добавьте новую строку, чтобы разрешить доступ с других серверов к вашему общему ресурсу.

/mnt/nfs_server_files        10.128.0.0/24(rw,sync,no_subtree_check)

Возможно, вы захотите использовать в своей общей папке разные параметры. 10.128.0.0/24 - это моя внутренняя сеть k8s.

Экспортируйте общий каталог и перезапустите службу, чтобы убедиться, что все файлы конфигурации верны.

$ sudo exportfs -a
$ sudo systemctl restart nfs-kernel-server

Проверить все активные акции:

$ sudo exportfs
/mnt/nfs_server_files
                10.128.0.0/24

2 - Установите клиент NFS на все мои рабочие узлы:

$ sudo apt-get update
$ sudo apt-get install nfs-common

На этом этапе вы можете провести тест, чтобы проверить, есть ли у вас доступ к своему общему ресурсу с ваших рабочих узлов:

$ sudo mkdir -p /mnt/sharedfolder_client
$ sudo mount kubemaster:/mnt/nfs_server_files /mnt/sharedfolder_client

Обратите внимание, что на этом этапе вы можете использовать имя своего главного узла. Здесь K8s заботится о DNS. Убедитесь, что том смонтирован должным образом, и создайте несколько папок и файлов, чтобы убедиться, что все работает нормально.

$ cd /mnt/sharedfolder_client
$ mkdir test
$ touch file

Вернитесь к своему главному узлу и проверьте, находятся ли эти файлы в папке / mnt / nfs_server_files.

3 - Установите NFS Client Provisioner.

Установите Provider с помощью helm:

$ helm install --name ext --namespace nfs --set nfs.server=kubemaster --set nfs.path=/mnt/nfs_server_files stable/nfs-client-provisioner

Обратите внимание, что я указал для него пространство имен. Проверьте, запущены ли они:

$ kubectl get pods -n nfs
NAME                                         READY   STATUS      RESTARTS   AGE
ext-nfs-client-provisioner-f8964b44c-2876n   1/1     Running     0          84s

На данный момент у нас есть класс хранения под названием nfs-client:

$ kubectl get storageclass -n nfs
NAME         PROVISIONER                                AGE
nfs-client   cluster.local/ext-nfs-client-provisioner   5m30s

Нам нужно создать PersistentVolumeClaim:

$ more nfs-client-pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: nfs 
  name: test-claim
  annotations:
    volume.beta.kubernetes.io/storage-class: "nfs-client"
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi
$ kubectl apply -f nfs-client-pvc.yaml

Проверить статус (ожидается привязка):

$ kubectl get persistentvolumeclaim/test-claim -n nfs
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-claim   Bound    pvc-e1cd4c78-7c7c-4280-b1e0-41c0473652d5   1Mi        RWX            nfs-client     24s

4. Создайте простой модуль, чтобы проверить, можем ли мы читать / записывать общий ресурс NFS:

Создайте под, используя этот yaml:

apiVersion: v1
kind: Pod
metadata:
  name: pod0
  labels:
    env: test
  namespace: nfs  
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-claim
$ kubectl apply -f pod.yaml

Перечислим все смонтированные тома в нашем модуле:

$ kubectl exec -ti -n nfs pod0 -- df -h /mnt
Filesystem                                                                               Size  Used Avail Use% Mounted on
kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-a2e53b0e-f9bb-4723-ad62-860030fb93b1   99G   11G   84G  11% /mnt

Как мы видим, у нас есть том NFS, смонтированный на / mnt. (Важно отметить путь kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-a2e53b0e-f9bb-4723-ad62-860030fb93b1)

Проверим:

root@pod0:/# cd /mnt
root@pod0:/mnt# ls -la
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 08:33 .
drwxr-xr-x 1 root   root    4096 Nov  5 08:38 ..

Пусто. Создадим несколько файлов:

$ for i in 1 2; do touch file$i; done;
$ ls -l 
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 08:58 .
drwxr-xr-x 1 root   root    4096 Nov  5 08:38 ..
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file1
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file2

Теперь давайте посмотрим, где эти файлы на нашем сервере NFS (главный узел):

$ cd /mnt/nfs_server_files
$ ls -l 
total 4
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 09:11 nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12
$ cd nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12/
$ ls -l 
total 0
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file1
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file2

А вот файлы, которые мы только что создали внутри нашего модуля!

Пожалуйста, дайте мне знать, помогло ли вам это решение.

person Mark Watney    schedule 01.04.2020
comment
Привет, спасибо за ответ. К сожалению, это не сработало. Был создан NFS, и я могу видеть файлы, которые были созданы на неосновных узлах внутри моего общего ресурса. Единственная проблема, которую я до сих пор не вижу, - это файлы там, а также созданные мною панели управления Grafana. - person Pasha; 03.05.2020