Persistentvolume и persistentvolumeclaim для нескольких развертываний

4.1 селектор

В PVC PV может быть дополнительно отфильтрован с помощью селектора тегов. Только PV, которые соответствуют селектору, будут связаны с PVC. Селектор состоит из следующих элементов:

• matchLabels: PVC будет выбирать только те фотокамеры, которые имеют такую ​​же метку, как эта;
• matchExpressions: выражения соответствия состоят из ключей, значений и операторов. Операторы включают In, NotIn, Exists и DoesNotExist. Могут быть выбраны только те PV, которые соответствуют выражению.

Если matchLabels и matchExpressions установлены одновременно, будет выполнена сумма, то есть будут выбраны только те PV, которые соответствуют вышеуказанным требованиям соответствия.

Deleting PV and PVC — an example

So, we have a pod running:

$ kk get pod pv-static-podNAME READY STATUS RESTARTS AGEpv-static-pod 1/1 Running 0 19s

Which is using a PVC:

$ kk get pvc pvc-staticNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-static Bound pv-static 50Gi RWO gp2 19h

And this PVC is bound to the PV:

$ kk get pv pv-staticNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpv-static 50Gi RWO Retain Bound default/pvc-static gp2 19h

And our PV has its set to Retain — so, after we will drop its PVC and PV all data must be kept.

Let’s check — add some data:

$ kk exec -ti pv-static-pod bashroot@pv-static-pod:/# echo Test > /usr/share/nginx/html/test.txtroot@pv-static-pod:/# cat /usr/share/nginx/html/test.txtTest

Exit from the pod and delete it, and then its PVC:

$ kubectl delete pod pv-static-podpod “pv-static-pod” deletedkubectl delete pvc pvc-staticpersistentvolumeclaim “pvc-static” deleted

Check the PV’s status:

$ kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpv-static 50Gi RWO Retain Released default/pvc-static gp2 25s

== Released, and at this moment we are not able to attach this volume again via a new PVC.

Let’s check — create a PVC again:

$ kubectl apply -f pvc-static.yamlpersistentvolumeclaim/pvc-static created

Create a pod:

$ kubectl apply -f pv-pod-stat.yamlpod/pv-static-pod created

And check its PVC status:

$ kubectl get pvc pvc-staticNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-static Pending pv-static 0 gp2 59s

The is Pending.

Delete the pod, PVC and at this time — delete the PersistentVolume too:

$ kubectl delete -f pv-pod-stat.yamlpod “pv-static-pod” deleted$ kubectl delete -f pvc-static.yamlpersistentvolumeclaim “pvc-static” deleted$ kubectl delete -f pv-static.yamlpersistentvolume “pv-static” deleted

Create all over again:

$ kubectl apply -f pv-static.yamlpersistentvolume/pv-static created$ kubectl apply -f pvc-static.yamlpersistentvolumeclaim/pvc-static created$ kubectl apply -f pv-pod-stat.yamlpod/pv-static-pod created

Check the PVC:

$ kubectl get pvc pvc-staticNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-static Bound pv-static 50Gi RWO gp2 27s

And check the data we’ve added earlier:

$ kubectl exec -ti pv-static-pod cat /usr/share/nginx/html/test.txtTest

All good — the data is still in its place.

4.3 PVCКак объем хранения

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

справочный материал

1. Адрес «Настройка модуля для использования PersistentVolume для хранилища»: https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

2. Постоянные тома: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

3. Адрес «Постоянное хранилище»: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/persistent-storage.md.

4. Адрес «PersistentVolume v1 core»: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#persistentvolume-v1-core

Создать под

Следующим шагом является создание модуля с использованием PersistentVolumeClaim в качестве тома.

Вот конфигурационный файл модуля:

Обратите внимание, что файл конфигурации модуля указывает PersistentVolumeClaim, но не указывает PersistentVolume. С точки зрения капсулы претензия — это том

Создайте контейнер:

Убедитесь, что контейнер запущен:

Используйте оболочку, чтобы войти внутрь работающего контейнера:

Проверьте в оболочке, применяет ли nginx файл index.html, предоставленный из тома пути к хосту:

Вывод показывает содержимое, записанное в том index.html пути к хосту:

3.5 CNI и таблица маршрутизации

Когда CNI (например, ) терпит сбой на любом из узлов, то он нарушает маршрутизацию и сетевое подключение в кластере K8s, часто локально для подверженного сбою узла/узлов.

Как и в случае с , проблему может решить либо перезапуск контейнера на этом узле, либо контроллер . Аналогично всем прочим рабочим нагрузкам кластера Поды CNI тоже очень уязвимы для сбоев.

Заключение

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

Мы рассмотрели три категории проблем и проанализировали многие связанные с ними неполадки:

1. Застревание Pod в состоянии .
2. и периодические перезапуски.
3. Проблемы с сетью.

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

• Kubernetes: сэкономьте до 50% с вытесняемыми объектами
• Kubernetes: безопасное управление секретами с GitOps
• Практичные Canary-релизы в Kubernetes с Argo Rollouts

Читайте нас в Telegram, VK и

Create a Pod

The next step is to create a Pod that uses your PersistentVolumeClaim as a volume.

Here is the configuration file for the Pod:

Notice that the Pod’s configuration file specifies a PersistentVolumeClaim, but
it does not specify a PersistentVolume. From the Pod’s point of view, the claim
is a volume.

Create the Pod:

Verify that the container in the Pod is running;

Get a shell to the container running in your Pod:

In your shell, verify that nginx is serving the file from the
hostPath volume:

The output shows the text that you wrote to the file on the
hostPath volume:

If you see that message, you have successfully configured a Pod to
use storage from a PersistentVolumeClaim.

2.5 Переработка

Стратегия утилизации PV объясняет кластеру, как следить за выпуском объемов из ПВХ. В настоящее время доступны три стратегии:Держать, перерабатыватьилиУдалить, Политика хранения позволяет повторно использовать этот ресурс. Когда PVC может поддерживать его, политика удаления будет одновременно удалять содержимое хранилища на томе и томе AWS EBS / GCE PD или Cinder. Если плагин может поддерживать его, стратегия утилизации выполнит базовую операцию стирания (rm -rf / thevolume / *), и этот том можно будет повторно применить.

2.5.1 удержание

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

1) Удалить PV: после удаления PV соответствующие ресурсы хранения во внешних объектах все еще там;

2) вручную удалить данные, оставленные во внешнем хранилище;

3) Удалите ресурсы хранения вручную. Если вам нужно повторно использовать эти ресурсы хранения, вам нужно создать новый PV.

2.5.2 циркуляция

Предупреждение: эта стратегия будет заброшена. Рекомендуется следовать модели динамического обеспечения.

Recycling выполняет базовую команду стирания на томе хранилища: rm -rf / thevolume / *, делая данные доступными для нового PVC.

2.5.3 Удалить

Для плагинов томов хранения, которые поддерживают стратегию удаления восстановления, удаление удалит PV из Kubernetes, а также удалит активы хранилища из связанных внешних устройств, таких как AWS EBS, GCE PD, Azure Disk или Cinder.

3. Постоянный объем хранения

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

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• FC (Fibre Channel)
• FlexVolume
• Flocker
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
• VMware Photon
• Portworx Volumes
• ScaleIO Volumes
• StorageOS

Объем постоянного хранилища можно сделать через файл конфигурации YAML и указать, какой тип подключаемого модуля используется. Ниже приведен файл конфигурации YAML для тома постоянного хранения. В этом файле конфигурации требуется место для хранения 5 Ги.Filesystem ，Режим доступаReadWriteOnceПереработайте постоянный том хранения с помощью стратегии Recycle recycle, укажите класс хранения как медленный и используйте тип плагина nfs. Следует отметить, что служба NFS должна присутствовать.

NFS хранилище в качестве Persistence Volume

Для простоты я взял в качестве хранилища PV nfs сервер. Для него не существует встроенного Provisioner, как к примеру, для Ceph. Возможно в будущем я рассмотрю более сложный пример с применением хранилища на основе ceph. Но перед этим надо будет написать статью про установку и работу с ceph.

Создаем yaml файл pv-nfs.yaml с описанием Persistence Volume на основе NFS.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-nfs-share
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    server: 10.1.4.39
    path: /mnt/nfs

Reclaim Policy

persistentVolumeReclaimPolicy — что будет происходить с pv после удаления pvc. Могут быть 3 варианта:

1. Retain — pv удален не будет.
2. Recycle — pv будет очищен.
3. Delete — pv будет удален.

Так как у нас нет Provisioner для nfs, удалять автоматически pv не получится. Так что у нас только 2 варианта — либо оставлять данные (retain), либо очищать том (recycle).

Все остальное и так понятно, описывать не буду. Добавляем описанный pv в кластер kubernetes.

# kubectl apply -f pv-nfs.yml

Проверяем список pv и pvc

# kubectl get pv
# kebectl get pvc

Мы просили в pvc только 1 Гб хранилища, но в pv было только хранилище с 10 Гб и оно было выдано. Как я и говорил раньше. Так что в случае ручного создания PV и PVC нужно самим следить за размером PV.

Удалить StatefulSet.

StatefulSet поддерживает каскадное удаление и некаскадное удаление. В режиме некаскадного удаления можно удалить только StatefulSet без удаления Pod, но при каскадном удалении удаляются все.

После некаскадного удаления StatefulSet, если Pod удален, исходный Pod больше не будет загружен, но будет создан новый Pod. Но если StatefulSet воссоздан, существующие поды будут реорганизованы в соответствии с правилами.

Некоторые распределенные системы не хотят управлять запуском и остановкой модулей по порядку, поэтому после версии 1.7 он предоставляетЭтот параметр по умолчанию, Можно установить наТаким образом, создание Pod не должно ждать, но оно будет создано и удалено одновременно.

4.2 Хранениекатегория

Если PVC использует поле storageClassName для указания класса хранения, к PVC могут быть привязаны только те PV, которые указывают тот же класс хранения. Для ПВХ, классы хранения не нужны. В зависимости от способа установки вы можете использовать менеджер надстроек для развертывания StorageClass по умолчанию в кластере Kubernetes во время процесса установки. Когда для PVC указывается селектор, а для StorageClass указывается, при сопоставлении PV берется AND между ними: то есть, могут совпадать только те PV, которые удовлетворяют как классу хранения, так и требуемому значению тега.

3.1 Kube-proxy и таблицы IP

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

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

Подключаем хранилище к поду

Теперь подключим наш PVC в виде volume к какому-нибудь поду. Опишем его в конфиге pod-with-nfs.yaml

kind: Pod
apiVersion: v1
metadata:
  name: pod-with-nfs
spec:
  containers:
    - name: app
      image: alpine
      volumeMounts:
      - name: data
        mountPath: /mnt/nfs
      command: ["/bin/sh"]
      args: 
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: fileshare

Применяем.

# kubectl apply -f pod-with-nfs.yaml

Затем проверяйте статус запущенного пода.

# kubectl get pod
NAME           READY   STATUS              RESTARTS   AGE
pod-with-nfs   0/1     ContainerCreating   0          80s

У меня он не стартовал. Я решил посмотреть из-за чего.

# kubectl describe pod pod-with-nfsУвидел в самом конце в разделе Messages ошибку:

Events:
  Type     Reason       Age    From                 Message
  ----     ------       ----   ----                 -------
  Warning  FailedMount  4m10s  kubelet, kub-node-1  MountVolume.SetUp failed for volume "my-nfs-share" : mount failed: exit status 32
Mounting command: systemd-run
Mounting arguments: --description=Kubernetes transient mount for /var/lib/kubelet/pods/3918714a-87eb-4e66-81cb-0f311461f47d/volumes/kubernetes.io~nfs/my-nfs-share --scope -- mount -t nfs 10.1.4.39:/mnt/nfs /var/lib/kubelet/pods/3918714a-87eb-4e66-81cb-0f311461f47d/volumes/kubernetes.io~nfs/my-nfs-share
Output: Running scope as unit run-980498.scope.
mount: wrong fs type, bad option, bad superblock on 10.1.4.39:/mnt/nfs,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount. helper program)

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Я сразу понял в чем проблема. На ноде, где стартовал под, не были установлены утилиты для работы с nfs. В моем случае система была Centos и я их установил.

# yum install nfs-utils nfs-utils-lib

После этого в течении минуты pod запустился. Зайдем в его консоль и посмотрим, подмонтировалась ли nfs шара.

# kubectl exec -it pod-with-nfs sh

Как видите, все в порядке. Попробуем теперь что-то записать в шару. Снова заходим на под и создаем текстовый файл.

# kubectl exec -it pod-with-nfs sh
# echo "test text" >> /mnt/nfs/test.txt

Теперь запустим еще один под и подключим ему этот же pvc. Для этого просто немного изменим предыдущий под, обозвав его pod-with-nfs2.

kind: Pod
apiVersion: v1
metadata:
  name: pod-with-nfs2
spec:
  containers:
    - name: app
      image: alpine
      volumeMounts:
      - name: data
        mountPath: /mnt/nfs
      command: ["/bin/sh"]
      args: 
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: fileshare

Запускаем под и заходим в него.

# kubectl apply -f pod-with-nfs2.yaml
# kubectl exec -it pod-with-nfs2 sh
# cat /mnt/nfs/test.txt
test text

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

Pod nodeAffinity

Next, we need to determine an AWS AvailabilityZone where is our AWS EBS for the Static PV was created:

$ aws ec2 — profile arseniy — region us-east-2 describe-volumes — volume-ids vol-0928650905a2491e2 — query '.AvailabilityZone]' — output textus-east-2a

us-east-2a — okay, then we need to create a pod on a Kubernetes Worker Node in the same AvailabilityZone.

Create a manifest:

apiVersion: v1kind: Podmetadata:  name: pv-static-podspec:  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:        nodeSelectorTerms:        - matchExpressions:          - key: failure-domain.beta.kubernetes.io/zone            operator: In            values:            - us-east-2a  volumes:    - name: pv-static-storage      persistentVolumeClaim:        claimName: pvc-static  containers:    - name: pv-static-container      image: nginx      ports:        - containerPort: 80          name: "nginx"      volumeMounts:        - mountPath: "/usr/share/nginx/html"          name: pv-static-storage

As opposed to the Dynamic PVC — here we’ve used the to specify that we want to use a node from the s-east-2a AZ.

Create that pod:

$ kk apply -f pv-pod-stat.yamlpod/pv-static-pod created

Check events:

0s Normal Scheduled Pod Successfully assigned default/pv-static-pod to ip-10–3–47–58.us-east-2.compute.internal0s Normal SuccessfulAttachVolume Pod AttachVolume.Attach succeeded for volume “pv-static”0s Normal Pulling Pod Pulling image “nginx”0s Normal Pulled Pod Successfully pulled image “nginx”0s Normal Created Pod Created container pv-static-container0s Normal Started Pod Started container pv-static-container

Partitions in the pod:

$ kk exec -ti pv-static-pod bashroot@pv-static-pod:/# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTnvme0n1 259:0 0 50G 0 disk|-nvme0n1p1 259:1 0 50G 0 part /etc/hosts`-nvme0n1p128 259:2 0 1M 0 partnvme1n1 259:3 0 50G 0 disk /usr/share/nginx/html

nvme1n1 is mounted, all works.

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

Настройка идентификатора группы хранения (GID) позволяет модулям использовать только один и тот же GID для операций записи. Несоответствие или отсутствие GID приведет к ошибкам определения разрешений. Чтобы уменьшить потребность в координации с пользователями, администраторы могут использовать GID для аннотирования PersistentVolume. Затем GID автоматически добавляется к любому модулю, который использует PersistentVolume.

Используйте аннотацию pv.beta.kubernetes.io/gid как следующий пример:

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

Примечание. Когда модуль использует PersistentVolume, GID, связанный с PersistentVolume, не существует в самом ресурсе модуля.

Dynamic PersistentVolumeClaim

Let’s describe a pod which will use our dynamic PVC:

apiVersion: v1kind: Podmetadata:  name: pv-dynamic-podspec:  volumes:    - name: pv-dynamic-storage      persistentVolumeClaim:        claimName: pvc-dynamic  containers:    - name: pv-dynamic-container      image: nginx      ports:        - containerPort: 80          name: "nginx"      volumeMounts:        - mountPath: "/usr/share/nginx/html"          name: pv-dynamic-storage

Here:

• : a PVC name which will be requested when a pod will be created
• : mount the pv-dynamic-storage volume to the directory in the pod

Create it:

$ kubectl apply -f pv-pods.yamlpod/pv-dynamic-pod created

Check again our PVC:

$ kubectl get pvc pvc-dynamicNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-dynamic Bound pvc-6d024b40-a239–4c35–8694-f060bd117053 5Gi RWO gp2 21h

Now we can see a new Volume with the ID pvc-6d024b40-a239–4c35–8694-f060bd117053 — check it:

$ kubectl describe pvc pvc-dynamicName: pvc-dynamicNamespace: defaultStorageClass: gp2Status: BoundVolume: pvc-6d024b40-a239–4c35–8694-f060bd117053…Finalizers: [kubernetes.io/pvc-protection]Capacity: 5GiAccess Modes: RWOVolumeMode: FilesystemEvents: <none>Mounted By: pv-dynamic-pod

Check that volume:

$ kubectl describe pv pvc-6d024b40-a239–4c35–8694-f060bd117053Name: pvc-6d024b40-a239–4c35–8694-f060bd117053…StorageClass: gp2Status: BoundClaim: default/pvc-dynamicReclaim Policy: DeleteAccess Modes: RWOVolumeMode: FilesystemCapacity: 5GiNode Affinity:Required Terms:Term 0: failure-domain.beta.kubernetes.io/zone in failure-domain.beta.kubernetes.io/region in Message:Source:Type: AWSElasticBlockStore (a Persistent Disk resource in AWS)VolumeID: aws://us-east-2b/vol-040a5e004876f1a40FSType: ext4Partition: 0ReadOnly: falseEvents: <none>

And the AWS EBS vol-040a5e004876f1a40:

$ aws ec2 — profile arseniy — region us-east-2 describe-volumes — volume-ids vol-040a5e004876f1a40 — output json{“Volumes”: [{“Attachments”: [{“AttachTime”: “2020–07–30T11:08:29.000Z”,“Device”: “/dev/xvdcy”,“InstanceId”: “i-0a3225e9fe7cb7629”,“State”: “attached”,“VolumeId”: “vol-040a5e004876f1a40”,“DeleteOnTermination”: false}],…

Check inside of the pod:

$ kk exec -ti pv-dynamic-pod bashroot@pv-dynamic-pod:/# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTnvme0n1 259:0 0 50G 0 disk|-nvme0n1p1 259:1 0 50G 0 part /etc/hosts`-nvme0n1p128 259:2 0 1M 0 partnvme1n1 259:3 0 5G 0 disk /usr/share/nginx/html

nvme1n1 — here is our partition.

Let’s write some data:

root@pv-dynamic-pod:/# echo Test > /usr/share/nginx/html/index.html

Drop the pod:

$ kk delete pod pv-dynamic-podpod “pv-dynamic-pod” deleted

Re-create it:

$ kubectl apply -f pv-pods.yamlpod/pv-dynamic-pod created

Check the data:

$ kk exec -ti pv-dynamic-pod cat /usr/share/nginx/html/index.htmlTest

Everything is still in its place.

2.2 Описание параметров PVC

1. : Режим доступа; описывает права доступа приложений пользователя к ресурсам хранилища.

• RWO: ReadWriteOnce, позволяет монтировать только один узел для чтения и записи;
• ROX: ReadOnlyMany, позволяющий монтировать несколько узлов и использовать их только для чтения;
• RWX: ReadWriteMany, позволяет монтировать несколько узлов для чтения и записи;

1. : Размер хранилища запроса ресурса;
2. : Режим тома хранилища, укажите имя объекта ресурса StorageClass, PV с определенной категорией могут быть привязаны только к PVC, запрашивающему эту категорию; (динамическое хранилище); конечно, его также можно установить на, PV, которые не установили определенный тип, могут быть связаны (статическое хранилище) только с PVC, которые не запрашивают какой-либо тип.
3. : Условия выбора PV, связывание PV может быть выполнено путем сопоставления меток; это также может быть выполненоВыполнить описание метки условия;

3 Жизненный цикл ПВХ

PVC также имеет в общей сложности 4 стадии жизненного цикла: доступный / связанный / освобожденный / неудачный.

• Доступен: статус «Доступен», без привязки к PV;
• Bound: состояние привязки, он был привязан к PV;
• Выпущено: состояние освобождено, связанный PV удален, ресурс освобожден, но не повторно используется кластером;
• Сбой: состояние сбоя, сбой автоматического восстановления ресурсов;

4 Общие команды для PVC

1. Создать (yaml way)
2. удалять
3. Посмотреть все ПВХ
4. Посмотреть ПВХ
5. смотрите подробности Примечание. Если в определенном пространстве имен, указанная выше команда может быть добавлена

StorageClass

The parameter will set the storage type.

Both PVC and PV must have the same class, otherwise, a PVC will not find a PV, and STATUS of such a PVC will be Pending.

If a PVC has no set — then a default value will be used:

$ kubectl get storageclass -o wideNAME PROVISIONER AGEgp2 (default) kubernetes.io/aws-ebs 65d

During this, if the is not set for a PV — this PV will be crated without class, and our PVC with the default class will not be able to use this PV with the «Cannot bind to requested volume «pvname»: storageClassName does not match» error:

…Events:Type Reason Age From Message — — — — — — — — — — — — -Warning VolumeMismatch 12s (x17 over 4m2s) persistentvolume-controller Cannot bind to requested volume “pvname”: storageClassName does not match…

See documentation and here>>>.

Create a PersistentVolume

In this exercise, you create a hostPath PersistentVolume. Kubernetes supports
hostPath for development and testing on a single-node cluster. A hostPath
PersistentVolume uses a file or directory on the Node to emulate network-attached storage.

In a production cluster, you would not use hostPath. Instead a cluster administrator
would provision a network resource like a Google Compute Engine persistent disk,
an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also
use
to set up
dynamic provisioning.

Here is the configuration file for the hostPath PersistentVolume:

The configuration file specifies that the volume is at on the
cluster’s Node. The configuration also specifies a size of 10 gibibytes and
an access mode of , which means the volume can be mounted as
read-write by a single Node. It defines the
for the PersistentVolume, which will be used to bind
PersistentVolumeClaim requests to this PersistentVolume.

Create the PersistentVolume:

View information about the PersistentVolume:

The output shows that the PersistentVolume has a of . This
means it has not yet been bound to a PersistentVolumeClaim.

3.3 Conntrack

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

В RHEL лимиты подключений для можно проверить так:

$  sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012net.netfilter.nf_conntrack_max = 262144

Create a PersistentVolume

Write a manifest file, let’s call it :

apiVersion: v1kind: PersistentVolumemetadata:  name: pv-staticspec:  capacity:    storage: 5Gi  accessModes:    - ReadWriteOnce  storageClassName: gp2  awsElasticBlockStore:    fsType: ext4    volumeID: vol-0928650905a2491e2

Here:

• : storage size
• : access type, here it is the , which means that this PV can be attached to an only one WorkerNode at the same time
• : storage access, see below
• : used device type
• : a filesystem type to be created on this volume
• : an AWS EBS disc ID

Create the PersistentVolume:

$ kubectl apply -f pv-static.yamlpersistentvolume/pv-static created

Check it:

$ kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpv-static 5Gi RWO Retain Available 69s