Налаштування Podʼа для використання PersistentVolume для зберігання

Ця сторінка показує, як налаштувати Pod для використання PersistentVolumeClaim для зберігання. Ось короткий опис процесу:

Ви, як адміністратор кластера, створюєте PersistentVolume на основі фізичного сховища. Ви не повʼязуєте том з жодним Podʼом.
Ви, як розробник / користувач кластера, створюєте PersistentVolumeClaim, який автоматично привʼязується до відповідного PersistentVolume.
Ви створюєте Pod, який використовує вищезгаданий PersistentVolumeClaim для зберігання.

Перш ніж ви розпочнете

Вам потрібно мати кластер Kubernetes, який має лише один вузол, і kubectl повинен бути налаштований на спілкування з вашим кластером. Якщо у вас ще немає кластера з одним вузлом, ви можете створити його, використовуючи Minikube.
Ознайомтеся з матеріалом в Постійні томи.

Створіть файл index.html на вашому вузлі

Відкрийте оболонку на єдиному вузлі вашого кластера. Спосіб відкриття оболонки залежить від того, як ви налаштували ваш кластер. Наприклад, якщо ви використовуєте Minikube, ви можете відкрити оболонку до вашого вузла, введенням minikube ssh.

У вашій оболонці на цьому вузлі створіть теку /mnt/data:

# Це передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo mkdir /mnt/data

У теці /mnt/data створіть файл index.html:

# Це також передбачає, що ваш вузол використовує "sudo" для запуску команд
# як суперкористувач
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

Примітка:

Якщо ваш вузол використовує інструмент для доступу суперкористувача, відмінний від sudo, ви зазвичай можете зробити це, якщо заміните sudo на імʼя іншого інструмента.

Перевірте, що файл index.html існує:

cat /mnt/data/index.html

Виведення повинно бути:

Hello from Kubernetes storage

Тепер ви можете закрити оболонку вашого вузла.

Створення PersistentVolume

У цьому завданні ви створюєте hostPath PersistentVolume. Kubernetes підтримує hostPath для розробки та тестування на одновузловому кластері. PersistentVolume типу hostPath використовує файл або теку на вузлі для емуляції мережевого сховища.

В операційному кластері ви не використовували б hostPath. Замість цього адміністратор кластера створив би мережевий ресурс, такий як постійний диск Google Compute Engine, розділ NFS або том Amazon Elastic Block Store. Адміністратори кластера також можуть використовувати StorageClasses для динамічного налаштування.

Ось файл конфігурації для PersistentVolume типу hostPath:

pods/storage/pv-volume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

Файл конфігурації вказує, що том знаходиться в /mnt/data на вузлі кластера. Конфігурація також вказує розмір 10 гібібайт та режим доступу ReadWriteOnce, що означає, що том може бути підключений як для читання-запису лише одним вузлом. Визначається імʼя StorageClass manual для PersistentVolume, яке буде використовуватися для привʼязки запитів PersistentVolumeClaim до цього PersistentVolume.

Примітка:

У цьому прикладі використовується режим доступу ReadWriteOnce для спрощення. Для операційного застосування проєкт Kubernetes рекомендує використовувати режим доступу ReadWriteOncePod.

Створіть PersistentVolume:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

Перегляньте інформацію про PersistentVolume:

kubectl get pv task-pv-volume

Вивід показує, що PersistentVolume має STATUS Available. Це означає, що він ще не був привʼязаний до PersistentVolumeClaim.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

Створення PersistentVolumeClaim

Наступним кроком є створення PersistentVolumeClaim. Podʼи використовують PersistentVolumeClaim для запиту фізичного сховища. У цій вправі ви створюєте PersistentVolumeClaim, який запитує том не менше трьох гібібайт, який може забезпечити доступ до читання-запису не більше одного вузла за раз.

Ось файл конфігурації для PersistentVolumeClaim:

pods/storage/pv-claim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Створіть PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

Після створення PersistentVolumeClaim панель управління Kubernetes шукає PersistentVolume, який відповідає вимогам заявки. Якщо панель управління знаходить відповідний PersistentVolume з тим самим StorageClass, вона привʼязує заявку до тому.

Знову подивіться на PersistentVolume:

kubectl get pv task-pv-volume

Тепер вивід показує STATUS як Bound.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m

Подивіться на PersistentVolumeClaim:

kubectl get pvc task-pv-claim

Вивід показує, що PersistentVolumeClaim привʼязаний до вашого PersistentVolume, task-pv-volume.

NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s

Створення Podʼа

Наступним кроком є створення Podʼа, який використовує ваш PersistentVolumeClaim як том.

Ось файл конфігурації для Podʼа:

pods/storage/pv-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Зверніть увагу, що файл конфігурації Podʼа вказує PersistentVolumeClaim, але не вказує PersistentVolume. З погляду Podʼа, заявка є томом.

Створіть Pod:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

Перевірте, що контейнер у Podʼі працює:

kubectl get pod task-pv-pod

Відкрийте оболонку для контейнера, що працює у вашому Podʼі:

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

У вашій оболонці перевірте, що nginx обслуговує файл index.html з тому hostPath:

# Обовʼязково запустіть ці 3 команди всередині кореневої оболонки, яка є результатом
# виконання "kubectl exec" на попередньому кроці
apt update
apt install curl
curl http://localhost/

Вивід показує текст, який ви записали у файл index.html у томі hostPath:

Hello from Kubernetes storage

Якщо ви бачите це повідомлення, ви успішно налаштували Pod для використання зберігання з PersistentVolumeClaim.

Очищення

Видаліть Pod:

kubectl delete pod task-pv-pod

Монтування одного і того ж PersistentVolume у двох місцях

Ви зрозуміли, як створити PersistentVolume і PersistentVolumeClaim, а також як змонтувати том в одне місце в контейнері. Розгляньмо, як можна змонтувати один і той самий PersistentVolume у двох різних місцях контейнера. Нижче наведено приклад:

pods/storage/pv-duplicate.yaml


apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
        # монтування site-data
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
        # інше монтування для nginx config
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        claimName: task-pv-storage

Nen:

subPath: Це поле дозволяє експонувати певні файли або теки зі змонтованого PersistentVolume у різних місцях контейнера. У цьому прикладі
- subPath: html монтує теку html.
- subPath: nginx.conf монтує певний файл, nginx.conf.

Оскільки перший subPath — html, на вузлі потрібно створити теку html у теці /mnt/data/.

Другий subPath nginx.conf означає, що буде використано файл у теці /mnt/data/. Ніяких інших тек створювати не потрібно.

На вашому контейнері nginx буде виконано два монтування тому:

/usr/share/nginx/html для статичного вебсайту
/etc/nginx/nginx.conf для файлу налаштувань

Переміщення файлу index.html на вашому Вузлі в нову теку

Згаданий тут файл index.html стосується до файлу, створеного у розділі "Створіть файл index.html на вашому вузлі".

Відкрийте оболонку на одному з вузлів кластера. Спосіб відкриття оболонки залежить від того, як ви налаштували кластер. Наприклад, якщо ви використовуєте Minikube, ви можете відкрити оболонку на вашому вузлі, скориставшись командою minikube ssh.

Створіть теку /mnt/data/html:

# Це припускає, що ваш вузол використовує "sudo" для запуску команд
# від імені суперкористувача
sudo mkdir /mnt/data/html

Перемістіть index.html в теку:

# Перемістіть index.html з поточного розташування до теки html
sudo mv /mnt/data/index.html html

Створення нового файлу nginx.conf

pods/storage/nginx.conf

user  nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;
events {
worker_connections  1024;
}
http {
include       /etc/nginx/mime.types;
default_type  application/octet-stream;
log_format  main  &#39;$remote_addr - $remote_user [$time_local] &#34;$request&#34; &#39;
                  &#39;$status $body_bytes_sent &#34;$http_referer&#34; &#39;
                  &#39;&#34;$http_user_agent&#34; &#34;$http_x_forwarded_for&#34;&#39;;

access_log  /var/log/nginx/access.log  main;

sendfile        on;
#tcp_nopush     on;

keepalive_timeout  60;

#gzip  on;

include /etc/nginx/conf.d/*.conf;
}

Це модифікована версія стандартного файлу nginx.conf. Тут стандартне значення keepalive_timeout змінено на 60.

Створіть файл nginx.conf:

cat <<EOF > /mnt/data/nginx.conf
user  nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '\$remote_addr - \$remote_user [\$time_local] "\$request" '
                      '\$status \$body_bytes_sent "\$http_referer" '
                      '"\$http_user_agent" "\$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  60;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}
EOF

Створення Podʼа

Тут ми створимо pod, який використовує наявні persistentVolume і persistentVolumeClaim. Однак, він монтує до контейнера лише певний файл nginx.conf і теку html.

Створіть pod:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-duplicate.yaml

Перевірте, що контейнер в Pod працює:

kubectl get pod test

Отримайте доступ до оболонки контейнера у вашому Podʼі:

kubectl exec -it test -- /bin/bash

У вашій оболонці переконайтеся, що nginx обслуговує файл index.html з тому hostPath:

# Переконайтеся, що ці 3 команди виконано в оболонці root, з якої запущено
# "kubectl exec" у попередньому кроці
apt update
apt install curl
curl http://localhost/

На виході буде показано текст, який ви записали до файлу index.html у томі hostPath:

Hello from Kubernetes storage

У вашій оболонці також переконайтеся, що nginx обслуговує файл nginx.conf з тома hostPath:

# Переконайтеся, що ці команди виконано в оболонці root, з якої запущено
# "kubectl exec" у попередньому кроці
cat /etc/nginx/nginx.conf | grep keepalive_timeout

На виході буде показано змінений текст, який ви записали до файлу nginx.conf на томі hostPath:

keepalive_timeout  60;

Якщо ви бачите ці повідомлення, це означає, що ви успішно налаштували Pod на використання певного файлу і теки у сховищі з PersistentVolumeClaim.

Очищення

Видаліть Pod:

kubectl delete pod test
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume

Якщо у вас ще не відкрито оболонку до вузла у вашому кластері, відкрийте нову оболонку так само як ви робили це раніше.

У оболонці на вашому вузлі видаліть файл і теку, які ви створили:

# Це передбачає, що ваш Вузол використовує "sudo" для виконання команд
# з правами суперкористувача
sudo rm /mnt/data/html/index.html
sudo rm /mnt/data/nginx.conf
sudo rmdir /mnt/data

Тепер ви можете закрити оболонку доступу до вашого вузла.

Контроль доступу

Зберігання даних із використанням ідентифікатора групи (GID) дозволяє запис лише для Podʼів, які використовують той самий GID. Невідповідність або відсутність GID призводить до помилок доступу. Щоб зменшити необхідність координації з користувачами, адміністратор може анотувати PersistentVolume з GID. Після цього GID автоматично додається до будь-якого Podʼа, який використовує цей PersistentVolume.

Використовуйте анотацію pv.beta.kubernetes.io/gid наступним чином:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

Коли Pod використовує PersistentVolume з анотацією GID, анотований GID застосовується до всіх контейнерів у Podʼі так само як GID, зазначені у контексті безпеки Podʼа. Кожен GID, незалежно від того, чи походить він з анотації PersistentVolume або специфікації Podʼа, застосовується до першого процесу, запущеного в кожному контейнері.

Примітка:

Коли Pod використовує PersistentVolume, GID, асоційовані з PersistentVolume, не відображаються на самому ресурсі Podʼа.

Що далі

Дізнайтеся більше про PersistentVolumes.
Прочитайте документ проєктування постійного сховища.

Довідка

Змінено April 18, 2025 at 5:12 PM PST: sync upstream (ebdf664e4b)

Налаштування Podʼа для використання PersistentVolume для зберігання

Перш ніж ви розпочнете

Створіть файл index.html на вашому вузлі

Примітка:

Створення PersistentVolume

Примітка:

Створення PersistentVolumeClaim

Створення Podʼа

Очищення

Монтування одного і того ж PersistentVolume у двох місцях

Переміщення файлу index.html на вашому Вузлі в нову теку

Створення нового файлу nginx.conf

Створення Podʼа

Очищення

Контроль доступу

Примітка:

Що далі

Довідка

Ваша думка