Trident: Тома iSCSI, смонтированные с правами root в OpenShift 4.5

Я предполагаю, что вы не указали параметр fsType в своем классе хранения. Удалите существующий класс хранилища (не влияет на существующие тома), добавьте

fsType: "ext4"

в свой класс хранения yaml и заново создайте.

Некоторый фон

Когда модуль запускается, он может указать fsGroup как часть securityContext. Kubernetes продолжит и применит этот идентификатор группы ко всем файлам/папкам на томе (chown/chmod) и добавит группу в качестве дополнительной группы для пользователя, с которым работает приложение. Это гарантирует, что разрешения установлены правильно.

Поскольку это возможно не во всех сценариях (в зависимости от того, какое хранилище используется), Kubernetes пытается определить, следует ли это запускать или нет. Одним из индикаторов является fsType. Если это существует, Kubernetes предполагает, что он сможет использовать chown/chmod. В более старых версиях по умолчанию было установлено значение ext4. Это изменилось на «» в более поздних версиях контейнеров sidecar CSI, которые включены в Trident 20.07.1 и выше. Таким образом, в старых версиях, если вы не указывали fstype в своем классе хранилища, использовалось значение по умолчанию «ext4», и все работало. В более поздних версиях есть пустое значение по умолчанию, поэтому, если у вас его нет в вашем классе хранилища, оно будет пустым, из-за чего Kubernetes считает, что fsType отсутствует, и пропускает шаг разрешения.

https://netapp-trident.readthedocs.io/en/stable-v21.01/kubernetes/known-issues.html?highlight=fstype#known-issues

https://netapp-trident.readthedocs.io/en/stable-v21.01/kubernetes/operations/tasks/storage-classes.html?highlight=fstype#deleting -a-storage-class

Я удалил и воссоздал класс хранения iscsi, добавив параметр «fsType: ext4»:

$  oc get sc/iscsi -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: "2021-03-26T12:34:52Z"
  managedFields:
  - apiVersion: storage.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:allowVolumeExpansion: {}
      f:mountOptions: {}
      f:parameters:
        .: {}
        f:backendType: {}
        f:fsType: {}
        f:storagePools: {}
      f:provisioner: {}
      f:reclaimPolicy: {}
      f:volumeBindingMode: {}
    manager: oc
    operation: Update
    time: "2021-03-26T12:34:52Z"
  name: iscsi
  resourceVersion: "4857712"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/iscsi
  uid: 55988799-c11e-4efa-a462-d7fa42aab7d2
mountOptions:
- discard
parameters:
  backendType: ontap-san
  fsType: ext4   <======
  storagePools: ontap_san_ci00150164:n1_data_vmdk_01,n2_data_vmdk_01
provisioner: csi.trident.netapp.io
reclaimPolicy: Delete
volumeBindingMode: Immediate

После этого я перезапустил один из модулей Prometheus и elasticsearch. Но проблема остается.

$  oc logs -f prometheus-k8s-0 -c prometheus
level=info ts=2021-03-26T12:36:09.589Z caller=main.go:330 msg="Starting Prometheus" version="(version=2.15.2, branch=rhaos-4.5-rhel-7, revision=c3b41963fbe48114e54396ac05b56b02cb3e4a0a)"
level=info ts=2021-03-26T12:36:09.589Z caller=main.go:331 build_context="(go=go1.13.4, user=root<strong i="9">@3d590aab9ed6</strong>, date=20200810-04:36:52)"
level=info ts=2021-03-26T12:36:09.589Z caller=main.go:332 host_details="(Linux 4.18.0-193.14.3.el8_2.x86_64 #1 SMP Mon Jul 20 15:02:29 UTC 2020 x86_64 prometheus-k8s-0 (none))"
level=info ts=2021-03-26T12:36:09.589Z caller=main.go:333 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2021-03-26T12:36:09.589Z caller=main.go:334 vm_limits="(soft=unlimited, hard=unlimited)"
level=error ts=2021-03-26T12:36:09.589Z caller=query_logger.go:85 component=activeQueryTracker msg="Error opening query log file" file=/prometheus/queries.active err="open /prometheus/queries.active: permission denied"
panic: Unable to create mmap-ed active query log

$  oc debug pod/prometheus-k8s-0
Defaulting container name to prometheus.
Use 'oc describe pod/prometheus-k8s-0-debug -n openshift-monitoring' to see all of the containers in this pod.

Starting pod/prometheus-k8s-0-debug ...
Pod IP: 10.131.0.128
If you don't see a command prompt, try pressing enter.
sh-4.2$ df -hT .
Filesystem                                    Type  Size  Used Avail Use% Mounted on
/dev/mapper/3600a098056303030303f4f77477a3276 ext4  9.8G   37M  9.3G   1% /prometheus
sh-4.2$ ls -ld /prometheus
drwxr-xr-x. 2 root root 4096 Mar 24 15:46 /prometheus
sh-4.2$ touch /prometheus/test
touch: cannot touch '/prometheus/test': Permission denied
sh-4.2$ id
uid=1000420000(1000420000) gid=0(root) groups=0(root),1000420000

Я пропустил один шаг?

Извините, я не ясно выразился по этому поводу. Параметры класса хранилища применяются только к новым томам, которые вы создаете. Любой существующий PV не получит этот набор. Боюсь, вы не можете изменить это для уже существующего PV. Не могли бы вы попробовать новый PVC/PV?

Здравствуйте, это решает проблему! Большое спасибо!

После добавления fsType: ext4 в конфигурацию класса хранилища iscsi мне пришлось удалить PVC, принадлежащие неисправным модулям prometheus. Затем удалите неисправные модули. Они будут снова запущены автоматически, но останутся в состоянии ожидания, пока я снова не создам PVC.

То же самое для модулей elasticsearch. За исключением того, что мне не пришлось воссоздавать PVCs. Они были созданы автоматически.

Я проверил разрешения файловых систем iSCSI внутри модулей. Теперь они больше не принадлежат root:root .
Все модули находятся в состоянии «Работает», а производительность кластерного оператора мониторинга больше не снижена.

@timvandevoort это связано с тем, как Kubernetes применяет fsGroups. Как видно здесь: https://github.com/kubernetes/kubernetes/blob/f137c4777095b3972e2dd71a01365d47be459389/pkg/volume/csi/csi_mounter.go#L415

if fsGroup == nil || driverPolicy == storage.NoneFSGroupPolicy || c.readOnly {
        return false
    }

Пока для вашего StorageClass определен parameters.fsType , вы можете применить fsGroups через Security Context.

Я отмечаю эту проблему как «Закрытую». Спасибо за использование Trident!