One place for hosting & domains

      постоянных

      Настройка постоянных томов ReadWriteMany (RWX) с помощью NFS в DigitalOcean Kubernetes


      Введение

      Благодаря распределенной и динамической природе контейнеров, управление и настройка статичного хранилища могут стать проблемой при использовании Kubernetes, потому что сегодня рабочие нагрузки могут переключаться с одной виртуальной машины (VM) на другую в течение нескольких секунд. Для решения этой проблемы Kubernetes управляет томами с помощью системы постоянных томов (Persistent Volumes, PV), т. е. объектов API, которые представляют конфигурацию/том хранилища, и PersistentVolumeClaims (PVC), т. е. запроса хранилища, которое будет обслуживаться постоянным томом. Кроме того, драйверы интерфейса хранилища контейнеров (Container Storage Interface, CSI) помогают автоматизировать и управлять обработкой данных и предоставлением хранилища для контейнеризованных рабочих нагрузок. Эти драйверы отвечают за предоставление, монтирование, демонтирование, удаление и получение снимков томов.

      digitalocean-csi объединяет кластер Kubernetes с блочным хранилищем DigitalOcean. Разработчик может использовать этот инструмент для динамического предоставления томов блочного хранилища для контейнеризованных приложений в Kubernetes. Однако иногда приложениям может требоваться сохранение данных и их передача в нескольких разных дроплетах. Предоставляемое DigitalOcean по умолчанию решение CSI блочного хранилища поддерживает монтирование тома одного блочного хранилища на несколько дроплетов одновременно. Это означает, что это решение ReadWriteOnce (RWO), поскольку том ограничивается одним узлом. Протокол сетевой файловой системы (NFS), напротив, поддерживает экспорт этой же части многим потребителям. Это решение называется ReadWriteMany (RWX), поскольку несколько узлов могут монтировать том для чтения и записи. Поэтому мы можем использовать сервер NFS в нашем кластере, чтобы предоставить хранилище, которое может опираться на надежную основу в виде блочного хранилища DigitalOcean наряду с гибкостью долей NFS.

      В этом обучающем руководстве вы настроите динамическое предоставление томов NFS внутри кластера DigitalOcean Kubernetes (DOKS), где экспортируемые данные хранятся в томах блочного хранилища DigitalOcean. Затем вы развернете несколько экземпляров демо-приложения Nginx и протестируете обмен данными между каждым экземпляром.

      Предварительные требования

      Для прохождения этого обучающего руководства вам потребуется следующее:

      Примечание. Начиная с версии 3.0, для работы Helm больше не нужно устанавливать Tiller. Если вы используете последнюю версию Helm, см. инструкции в документации по установке Helm.

      Шаг 1 — Развертывание сервера NFS с Helm

      Для развертывания сервера NFS вы будете использовать таблицу Helm. Развертывание таблицы Helm — это автоматический процесс, который занимает меньше времени и менее подвержен ошибкам, по сравнению с созданием сервера NFS вручную.

      Во-первых, необходимо убедиться, что используемый по умолчанию репозиторий таблицы stable доступен для вас, добавив репозиторий:

      • helm repo add stable https://kubernetes-charts.storage.googleapis.com/

      Затем необходимо разместить метаданные для репозитория, который вы только что добавили. Это позволит гарантировать, что клиент Helm обновлен:

      Чтобы убедиться в доступе к репозиторию stable, выполните поиск по таблицам:

      В результате вы должны получить примерно следующий список доступных таблиц:

      Output

      NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.2 2.1.1 DEPRECATED Scales worker nodes within agent pools stable/aerospike 0.3.2 v4.5.0.5 A Helm chart for Aerospike in Kubernetes stable/airflow 5.2.4 1.10.4 Airflow is a platform to programmatically autho... stable/ambassador 5.3.0 0.86.1 A Helm chart for Datawire Ambassador ...

      Этот результат означает, что ваш клиент Helm запущен и обновлен.

      Теперь, когда вы выполнили настройку Helm, необходимо установить таблицу Helm nfs-server-provisioner для настройки сервера NFS. Если вы хотите просмотреть содержимое таблицы, ознакомьтесь с документацией на GitHub.

      При развертывании таблицы Helm вы должны будете задать несколько переменных для вашего сервера NFS, чтобы дополнительно уточнить конфигурацию вашего приложения. Кроме того, вы можете изучить другие варианты конфигурации и использовать их в соответствии с потребностями вашего приложения.

      Чтобы установить таблицу Helm, нужно использовать следующую команду:

      • helm install nfs-server stable/nfs-server-provisioner --set persistence.enabled=true,persistence.storageClass=do-block-storage,persistence.size=200Gi

      Данная команда позволяет получить сервер NFS со следующими вариантами конфигурации:

      • Добавляет постоянный том для сервера NFS с флагом --set. Это гарантирует, что все совместно используемые данные NFS будут сохраняться при перезапуске пода.
      • Для постоянного хранилища используется класс хранилища do-block-storage.
      • Предоставляет в общей сложности 200Gi, чтобы сервер NFS мог выполнять разбивку при экспорте.

      Примечание. Вариант persistence.size будет определять общую емкость всех томов NFS, которые вы можете предоставить. На момент написания этой статьи только версия DOKS 1.16.2-do.3 и выше поддерживает расширение тома, поэтому изменение размера этого тома необходимо выполнять вручную, если вы используете более раннюю версию. Если это так, необходимо учитывать будущие потребности при установке данного размера.

      После выполнения этой команды вы получите примерно следующий вывод:

      Output

      NAME: nfs-server LAST DEPLOYED: Thu Feb 13 19:30:07 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The NFS Provisioner service has now been installed. A storage class named 'nfs' has now been created and is available to provision dynamic volumes. You can use this storageclass by creating a PersistentVolumeClaim with the correct storageClassName attribute. For example: --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-dynamic-volume-claim spec: storageClassName: "nfs" accessModes: - ReadWriteOnce resources: requests: storage: 100Mi

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

      В результате вы получите следующий вывод:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 11m

      Затем проверьте созданный вами класс storageclass:

      Результат будет выглядеть примерно следующим образом:

      Output

      NAME PROVISIONER AGE do-block-storage (default) dobs.csi.digitalocean.com 90m nfs cluster.local/nfs-server-nfs-server-provisioner 3m

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

      Шаг 2 — Развертывание приложения с помощью общего PersistentVolumeClaim

      На этом шаге вы создадите пример развертывания вашего кластера DOKS для проверки настройки вашего хранилища. В этом случае мы будем использовать веб-сервер Nginx с именем web.

      Чтобы развернуть это приложение, необходимо предварительно написать файл YAML для указания параметров развертывания. Откройте файл nginx-test.yaml в вашем текстовом редакторе; в этом руководстве мы будем использовать nano:

      В этом файле добавьте следующие строки, чтобы определить развертывание с помощью PersistentVolumeClaim с именем nfs-data:

      nginx-test.yaml

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: web
        name: web
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: web
        strategy: {}
        template:
          metadata:
            creationTimestamp: null
            labels:
              app: web
          spec:
            containers:
            - image: nginx:latest
              name: nginx
              resources: {}
              volumeMounts:
              - mountPath: /data
                name: data
            volumes:
            - name: data
              persistentVolumeClaim:
                claimName: nfs-data
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: nfs-data
      spec:
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 2Gi
        storageClassName: nfs
      

      Сохраните файл и выйдите из текстового редактора.

      Это развертывание в соответствии с настройками использует сопровождающий PersistentVolumeClaim nfs-data и монтирует его в /data.

      В определении PVC вы должны увидеть, что в качестве storageClassName указано значение nfs. В этом случае кластер должен удовлетворять требованиям этого хранилища, используя правила класса storageClass nfs, созданного вами на предыдущем шаге. Новый запрос PersistentVolumeClaim будет обрабатываться, а затем часть NFS будет предоставляться для удовлетворения запроса в форме постоянного тома. Под будет пытаться монтировать данный PVC после его предоставления. После завершения монтирования вы должны убедиться, что функционал ReadWriteMany (RWX) работает корректно.

      Запустите развертывание с помощью следующей команды:

      • kubectl apply -f nginx-test.yaml

      Результат будет выглядеть следующим образом:

      Output

      deployment.apps/web created persistentvolumeclaim/nfs-data created

      Теперь убедитесь, что под web запущен:

      В результате вы получите следующий вывод:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 23m web-64965fc79f-b5v7w 1/1 Running 0 4m

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

      • kubectl scale deployment web --replicas=3

      Результат будет выглядеть следующим образом:

      Output

      deployment.extensions/web scaled

      Теперь запустите команду kubectl get еще раз:

      Вы получите масштабируемые экземпляры развертывания:

      Output

      NAME READY STATUS RESTARTS AGE nfs-server-nfs-server-provisioner-0 1/1 Running 0 24m web-64965fc79f-q9626 1/1 Running 0 5m web-64965fc79f-qgd2w 1/1 Running 0 17s web-64965fc79f-wcjxv 1/1 Running 0 17s

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

      Шаг 3 — Проверка обмена данными NFS

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

      Чтобы выполнить эту задачу, воспользуйтесь командой kubectl exec. Эта команда позволяет вам указывать под и запускать команды внутри этого пода. Дополнительную информацию о проверке ресурсов с помощью kubectl можно найти в нашей шпаргалке по kubectl.

      Чтобы создать файл с именем hello_world внутри одного из ваших подов web, воспользуйтесь kubectl exec для передачи команды touch. Обратите внимание, что число после web в имени пода у вас будет отличаться, поэтому замените выделенное имя пода на имя одного из ваших подов, которое вы можете найти в выводе команды kubectl get pods в последнем шаге.

      • kubectl exec web-64965fc79f-q9626 -- touch /data/hello_world

      Затем измените имя пода и используйте команду ls, чтобы вывести список файлов в директории /data другого пода:

      • kubectl exec web-64965fc79f-qgd2w -- ls /data

      Вывод должен содержать файл, созданный вами внутри первого пода:

      Output

      hello_world

      Это показывает, что все поды обмениваются данными с помощью NFS, а ваша настройка работает корректно.

      Заключение

      В этом обучающем руководстве вы создали сервер NFS на базе блочного хранилища DigitalOcean. Затем сервер NFS использовал это блочное хранилище для предоставления и экспорта частей NFS в рабочие нагрузки при использовании RWX-совместимого протокола. Выполнив эти действия, вы смогли обойти технические ограничения блочного хранилища DigitalOcean и использовать одни данные PVC в нескольких подах. После выполнения данного руководства ваш кластер DOKS сможет поддерживать гораздо более широкий набор вариантов развертывания.

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



      Source link