Хранилище — это общая потребность приложений. Они нужны для хранения файлов журналов, файлов конфигурации, артефактов, мультимедиа и многого другого. Когда приложения запускаются на веб-сервере, они используют дисковое пространство на сервере для хранения этих файлов. Однако, когда они запускаются в контейнере, распределение дискового пространства не так просто. Есть несколько соображений при создании стратегии для контейнерных объемов:
- Файлы на диске в контейнере могут быть эфемерными.
- Контейнер перезапускается, теряя все файлы, которые у него есть.
- Файлы необходимы для совместного использования между контейнерами.
- Файлы могут быть необходимы по истечении срока службы стручков.
Одним из преимуществ использования Kubernetes для управления контейнерами является то, что он предоставляет несколько вариантов для удовлетворения различных потребностей в хранении.
тома
Том Kubernetes — это каталог на диске, поддерживаемый некоторыми носителями. Этот том доступен для всех контейнеров, работающих внутри контейнера. В спецификации Pod указывается, какой тип тома должен быть подготовлен и где его монтировать. Тип тома указывается путем выбора одного из множества типов томов, которые предоставляет Kubernetes. Вот некоторые из них:
- AWS EBS
- Azure Disk
- Ceph файловая система
- ConfigMap
- emptyDir
- местный
- NFS
- persistentVolumeClaim
- секрет
emptyDir
Этот тип тома создается, когда Pod запланирован на узле. Этот объем только для жизни стручка. Он удаляется, как только модуль завершается. Все контейнеры внутри Pod разделяют этот объем. Вариант использования для такого тома может заключаться в том, чтобы использовать его как временное пространство для внутренней работы приложений или использовать в качестве кэша для повышения производительности приложений. Смотрите ниже спецификации стручка:
YAML
1
apiVersionv1
2
kindPod
3
metadata
4
namemy-server
5
spec
6
containers
7
imagenginx
8
namemy-server
9
volumeMounts
10
mountPath/testcache
11
namecache-volume
12
volumes
13
namecache-volume
14
emptyDir
15
mediumMemory
AWS EBS, Azure Disk и GCE Persistent Disk
AWS / AKS / GKE и другие облачные провайдеры предоставляют хранилище для использования их управляемыми сервисами Kubernetes. Рассмотрим следующий пример, в котором спецификация Pod использует диск Azure:
YAML
1
apiVersionv1
2
kindPod
3
metadata
4
nameazure-volume
5
spec
6
containers
7
imagehttpd
8
nameazure-volume
9
volumeMounts
10
nameazureVolume
11
mountPath/mnt/azure
12
volumes
13
nameazure
14
azureDisk
15
diskNamemy-test.vhd
16
diskURIhttps//my.blob.com/vhd/my-test.vhd
В приведенной выше спецификации,
-
diskName: Имя объекта блоба VHD -
diskURI: URI двоичного объекта VHD
Постоянный объем
Все спецификации стручков, которые мы видели, упоминают тип тома, который будет использоваться этим стручком. Это тесно связывает вид объема со стручком. Тем не менее, иногда лучше не указывать явно тип тома, а просто предоставлять различные хранилища, и модули будут использовать хранилище, которое подходит им лучше всего. Это обрабатывается с помощью утверждения «Постоянный том» и «Постоянный том».
Постоянный том (PV) представляет собой хранилище, предоставленное вами. Это ресурс в кластере Kubernetes, и его время жизни больше, чем у блоков в кластере.
Заявка на постоянный объем (PVC) — это спецификация, которая запрашивает хранилище, которое будет использовать Pod.
Следовательно, PV — это ресурс хранения, а PVC — это запрос на этот ресурс.
- Во-первых, вы предоставляете PV данные о фактическом хранении.
- Затем вы создаете спецификацию PVC, в которой есть детали запроса на хранение.
- Цикл управления Kubernetes пытается связать PVC с любым совпадающим PV.
- Kubernetes тогда устанавливает связанный объем к Стручку.
- Когда пользователь больше не нуждается в томе, он может удалить PVC. В спецификации PV упоминается политика восстановления, которая сообщает кластеру, что делать после освобождения тома.
Спецификация PV выглядит следующим образом:
YAML
x
1
apiVersionv1
2
kindPersistentVolume
3
metadata
4
namemy-pv
5
spec
6
capacity
7
storage10Gi
8
volumeModeFilesystem
9
accessModes
10
ReadWriteOnce
11
persistentVolumeReclaimPolicyRecycle
12
storageClassNameany-name
13
nfs
14
path/test
15
server10.0.0.0
16
-
capacity: указывает размер тома. -
volumeMode: использовать файловую систему для использования файловой системы или блока для блочного устройства. -
accessMode: это может бытьReadWriteOnce,ReadOnlyManyилиReadWriteMany -
reclaimPolicy: Это может быть «Сохранить», «Восстановить» или «Удалить».
Примените вышеуказанную спецификацию PV:
xxxxxxxxxx
1
$ kubectl apply -f my-pv.yaml
Спецификация ПВХ выглядит следующим образом:
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPersistentVolumeClaim
3
metadata
4
namemy-pvc
5
spec
6
accessModes
7
ReadWriteOnce
8
volumeModeFilesystem
9
resources
10
requests
11
storage10Gi
12
storageClassNameany-name
Примените вышеуказанную спецификацию ПВХ:
Оболочка
xxxxxxxxxx
1
$ kubectl apply -f my-pvc.yaml
Теперь мы можем использовать эту спецификацию Pod следующим образом:
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPod
3
metadata
4
namepod-with-volume
5
spec
6
containers
7
imagenginx
8
namepod-with-volume
9
volumeMounts
10
mountPath/data
11
namemy-volume
12
volumes
13
namemy-volume
14
persistentVolumeClaim
15
claimNamemy-pvc
моментальные снимки
Для включения моментальных снимков тома kubernetes предоставляет VolumeSnapshotContent и VolumeSnapshot ресурсы.
A VolumeSnapshotContent - это моментальный снимок содержимого тома, а VolumeSnapshot запрос на моментальный снимок. Так же, как ПВХ связан с PV, так и VolumeSnapshot связан с VolumeSnapshotContent. Вот примерная спецификация обоих:
YAML
xxxxxxxxxx
1
apiVersionsnapshot.storage.k8s.io/v1beta1
2
kindVolumeSnapshot
3
metadata
4
namemy-vol-snapshot
5
spec
6
source
7
volumeSnapshotContentNamemy-snapshot-content
YAML
xxxxxxxxxx
1
apiVersionsnapshot.storage.k8s.io/v1beta1
2
kindVolumeSnapshotContent
3
metadata
4
namemy-snapshot-content
5
spec
6
deletionPolicyDelete
7
driverhostpath.csi.k8s.io
8
source
9
snapshotHandle8qgh0te3-nleb-63h8-g6ae-734rac76hu01
10
volumeSnapshotRef
11
namemy-vol-snapshot
12
namespacedefault
Динамические тома
До сих пор мы создавали тома вручную, но в управляемой среде настоятельно рекомендуется иметь возможность создавать тома по требованию. Kubernetes предоставляет динамические тома, которые устраняют необходимость предварительной подготовки томов. Чтобы включить динамические тома, мы должны использовать ресурс Kubernetes, известный как StorageClass . Этот объект указывает, какой поставщик хранилища должен использоваться, и связанные параметры. Например, чтобы использовать SSD-диск, предоставленный Google Kubernetes Engine, создайте следующее StorageClass:
YAML
xxxxxxxxxx
1
apiVersionstorage.k8s.io/v1
2
kindStorageClass
3
metadata
4
namemy-class
5
provisionerkubernetes.io/gce-pd
6
parameters
7
typepd-ssd
Теперь создайте, PersistentVolumeClaim который использует это StorageClass
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPersistentVolumeClaim
3
metadata
4
namemy-pvc
5
spec
6
accessModes
7
ReadWriteOnce
8
storageClassNamemy-class
9
resources
10
requests
11
storage30Gi
Это автоматически обеспечивает SSD как постоянный диск.
Резюме
- Kubernetes Volumes предлагает хранение, которое является постоянным и длится дольше, чем срок службы контейнера или даже контейнера.
- Чтобы отделить объемные типы со спецификацией pod, используйте PVC и PV.
- Для динамического предоставления томов используйте StorageClass.
В этом посте описаны все вышеперечисленные функции с почти реальными образцами Kubernetes, и они могут быть легко использованы в ваших проектах.