Начало работы с постоянными томами Kubernetes

Что такое постоянные тома Kubernetes?

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

Чтобы включить постоянное хранилище, которое сохраняется после завершения работы контейнера или модуля, Kubernetes предоставляет подсистему постоянных томов. Он предоставляет объекты API, позволяющие постоянно выделять ресурсы хранения и управлять ими.

Вы можете настроить постоянное хранилище, используя следующие ресурсы API:

• PersistentVolume (PV) — каждый PV представляет ресурс хранения, доступный в кластере. В отличие от эфемерных томов, жизненный цикл PV не зависит от того, какой модуль использует его. Это гарантирует, что хранилище останется постоянным. Администраторы могут подготовить PV вручную. Kubernetes также может динамически предоставлять PV с помощью классов хранилища.

• PersistentVolumeClaims (PVC) — каждый PVC представляет запрос на хранение. PVC может потреблять только тот ресурс PV, который соответствует требованиям к его размеру и режимам доступа. Если соответствующий PV доступен, он привязан к PVC. В противном случае Kubernetes динамически подготавливает PV или запрос завершается ошибкой.

Дополнительные сведения см. в этом блоге о постоянных томах Kubernetes.

Концепции хранилища Kubernetes

Класс хранилища Kubernetes

Kubernetes позволяет администраторам определять StorageClasses, которые абстрагируются от реализации хранилища. Это позволяет пользователям запрашивать конкретный StorageClass, относящийся к каждому PVC, без указания всех требований к хранилищу.

Администраторы могут создавать различные типы StorageClasses, каждый из которых определяется по-своему для поставщика, параметров и reclaimPolicy. Он позволяет настраивать StorageClasses, которые обеспечивают различную производительность, например HDD или SSD, затраты и приложения.

Средство подготовки позволяет привязать StorageClass к определенным бэкендам, таким как AWS EBS или Azure Files, и к конечной точке хранилища. Дополнительные параметры доступны в зависимости от выбранного поставщика, чтобы помочь вам описать тома для каждого StorageClass, используя такие параметры, как «тип», «зона», «сервер» или «путь».

Kubernetes StatefulSet

Kubernetes StatefulSet — это объект API рабочей нагрузки для управления приложениями с отслеживанием состояния. Он позволяет определить набор модулей с уникальными сетевыми идентификаторами для развертывания и масштабирования в определенном порядке. StatefulSets помогает управлять постоянным хранилищем в кластере Kubernetes.

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

Плагины CSI для Kubernetes

Плагины Container Storage Interface (CSI) помогают сделать стороннее хранилище доступным для вашего кластера Kubernetes. Это помогает внедрить постоянное хранилище в контейнерные приложения. Подключаемые модули CSI получают запросы PVC, в которых сторонний поставщик указывается в качестве поставщика, а затем создают и монтируют запрошенный том.

Жизненный цикл PV и PVC

PVC — это запрос на PV, который существует как ресурс хранения в кластере Kubernetes. PVC привязан к соответствующему PV, чтобы обеспечить постоянное хранение. В результате жизненный цикл PV и PVC обычно тесно связан.

Подготовка

Kubernetes предоставляет следующие типы подготовки для постоянного хранилища:

• Статический — этот тип подготовки доступен для администраторов кластера. Он позволяет администраторам вручную создавать ресурсы PV и делать их доступными для всех пользователей кластера. Как только PV появится в API Kubernetes, пользователи могут создать запрос PVC для модуля, чтобы использовать ресурс PV.

• Динамический — этот тип подготовки доступен для кластера Kubernetes. Это позволяет кластеру автоматически подготавливать PV для соответствия PVC в соответствии с предопределенными StorageClasses. Динамическая подготовка обычно происходит, когда ни один из статически подготовленных PV не соответствует PVC.

Привязка

Контур управления отслеживает новые PVC. Как только пользователь создает новый PVC, контур управления ищет марширующий PV, который соответствует требованиям PVC. Он надеется удовлетворить запрошенный объем хранилища и может сделать это, используя PV, который превышает запрос. Вот как работает этот процесс:

• Если контур управления находит соответствующий PV, он привязывает его к PVC. Связывание гарантирует, что PV и PVC остаются эксклюзивными.

• Если контур управления не может найти PV, который соответствует требованиям PVC к режиму доступа и размеру хранилища, он динамически выделяет новый PV в соответствии с StorageClass и привязывает его к PVC.

• Если для PVC нет доступного PV — статического или динамического — PVC остается несвязанным на неопределенный срок.

С использованием

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

Восстановление

Когда пользователю больше не нужно использовать том, его можно удалить или сохранить. Пользователи могут удалить объект PVC непосредственно из API, что позволяет им восстановить этот ресурс. В противном случае политика восстановления PV определяет, что кластер должен делать с томом, который был освобожден из-за его претензии.

Краткое руководство: работа с постоянными томами

Это руководство основано на полном руководстве по постоянному хранилищу в документации Kubernetes.

Прежде чем приступить к этому руководству, настройте кластер Kubernetes на локальном компьютере только с одним узлом. Убедитесь, что kubectl установлен на вашем компьютере и успешно взаимодействует с кластером. Вы можете легко создать кластер из одного узла с помощью Minikube.

Шаг 1: Создайте файл на узле

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

Откройте оболочку для своего узла, создайте каталог с именем /mnt/data и внутри него создайте файл index.html с текстом «Hello World Persistent Volume».

Шаг 2: Создайте постоянный том

Чтобы создать постоянный том, откройте текстовый редактор и скопируйте и вставьте приведенный ниже код YAML.

apiВерсия: v1

вид: PersistentVolume

метаданные:

имя: мой-pv-том

метки:

тип: местный

спецификация:

имя_класса_хранилища: вручную

емкость:

хранилище: 6Gi

режимы доступа:

—ReadWriteOnce

Путь к хосту:

путь: "/mnt/data"

Сохраните файл YAML как my-pv-volume.yaml в локальном каталоге. Разверните постоянный том, выполнив следующую команду:

kubectl create -f my-pv-volume.yaml

Шаг 3. Создание заявки на постоянный том

Создайте спецификацию PVC, открыв текстовый редактор и скопировав приведенный ниже код YAML:

apiВерсия: v1

вид: PersistentVolumeClaim

метаданные:

имя: my-pv-claim

спецификация:

имя_класса_хранилища: вручную

режимы доступа:

—ReadWriteOnce

ресурсы:

запросы:

хранилище: 2Gi

Сохраните файл в своем локальном каталоге под именем my-pv-claim.yaml. Разверните его с помощью этой команды:**

kubectl применить -f my-pv-claim.yaml

Шаг 4: Создайте модуль и смонтируйте PVC как том

Теперь становится интереснее — давайте создадим модуль, который монтирует этот PVC, чтобы он мог использовать наш постоянный том. Скопируйте следующий код в текстовый редактор:

apiВерсия: v1

вид: стручок

метаданные:

имя: my-pv-pod

спецификация:

тома:

—имя: my-pv-storage

persistentVolumeClaim:

имя_требования: my-pv-claim

контейнеры:

— имя: мой-pv-контейнер

изображение: nginx

порты:

—ContainerPort: 80

имя: "http-сервер"

volumeMounts:

—mountPath: "/usr/share/nginx/html"

имя: my-pv-storage

Обратите внимание, что модуль определяет PVC, а не напрямую ссылается на PV. Kubernetes отвечает за сопоставление этого модуля с PV, который соответствует его требованиям, на основе информации в PVC. В нашем случае это просто, потому что есть только один PV.

Сохраните спецификацию пода в локальном каталоге под именем my-pv-pod.yaml. Разверните модуль, выполнив эту команду:

kubectl применить -f my-pv-pod.yaml

Убедитесь, что модуль работает:

kubectl получить pod my-pv-pod

Шаг 5. Убедитесь, что у модуля есть доступ к постоянному хранилищу

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

Запустите эту команду, чтобы войти в контейнер:

kubectl exec -it my-pv-pod -- /bin/bash

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

удачное обновление

способ установить завиток

свернуть http://localhost/

Вы должны увидеть содержимое ваших файлов index.html:

«Постоянный том Hello World»

Поздравляем! Вы только что создали модуль, который имеет доступ к постоянному тому через заявку на постоянный том.

Заключение

В этой статье я объяснил основы постоянного хранилища Kubernetes, объяснил концепции Persistent Volumes и Persistent Volume Claims и показал, как настроить быструю демонстрацию модуля, который монтирует PVC:

1. Создайте кластер из одного узла с помощью Minikube.

2. Создайте файл HTML на узле.

3. Создайте YAML-файл постоянного тома и разверните его с помощью kubectl.

4. Создайте YAML-файл Persistent Volume Claim и разверните его с помощью kubectl.

5. Создайте под YAML, который монтирует PVC как том, и разверните его с помощью kubectl.

6. Bash в контейнер и используйте curl для просмотра HTML-файла из шага 2 — это доказывает, что ваш контейнер имеет доступ к постоянному тому.

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