Trident: iSCSI-Volumes, die mit Root-Berechtigungen auf OpenShift 4.5 gemountet wurden

Ich vermute, dass Sie den fsType-Parameter in Ihrer Speicherklasse nicht angegeben haben. Löschen Sie die vorhandene Speicherklasse (keine Auswirkung auf vorhandene Volumes), fügen Sie hinzu

fsType: "ext4"

zu Ihrer Speicherklasse yaml hinzufügen und neu erstellen.

Etwas Hintergrund

Wenn der Pod startet, kann er eine fsGroup als Teil des securityContext angeben. Kubernetes wendet diese Gruppen-ID auf alle Dateien/Ordner auf dem Volume (chown/chmod) an und fügt die Gruppe als zusätzliche Gruppe zu dem Benutzer hinzu, mit dem die App ausgeführt wird. Dadurch wird sichergestellt, dass die Berechtigungen korrekt festgelegt sind.

Da dies nicht in allen Szenarien möglich ist (basierend auf dem verwendeten Speicher), versucht Kubernetes zu erkennen, ob dies ausgeführt werden soll oder nicht. Einer der Indikatoren ist der fsType. Wenn das vorhanden ist, geht Kubernetes davon aus, dass es chown/chmod ausführen kann. In älteren Versionen war dies standardmäßig auf ext4 eingestellt. Dies hat sich mit neueren Versionen der CSI-Sidecar-Container, die in Trident 20.07.1 und höher enthalten sind, in „“ geändert. Wenn Sie also in alten Versionen fstype nicht in Ihrer Speicherklasse angegeben haben, wurde der Standard „ext4“ verwendet und alles funktionierte. In neueren Versionen gibt es einen leeren Standardwert. Wenn Sie ihn also nicht in Ihrer Speicherklasse haben, ist dieser leer – was dazu führt, dass Kubernetes glaubt, dass es keinen fsType gibt, und den Berechtigungsschritt überspringt.

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

Ich habe die iscsi-Speicherklasse gelöscht und neu erstellt und den Parameter ‚fsType: ext4‘ hinzugefügt:

$  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

Ich habe danach einen der Prometheus- und Elasticsearch-Pods neu gestartet. Aber das Problem bleibt.

$  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

Habe ich einen Schritt verpasst?

Sorry, das war mir nicht klar. Die Parameter der Speicherklasse werden nur auf neu erstellte Volumes angewendet. Bestehende PV erhalten dieses Set nicht. Ich fürchte, Sie können dies nicht für ein bereits vorhandenes PV ändern. Könnten Sie es bitte mit einem neuen PVC/PV versuchen?

Hallo, das löst das Problem! Vielen Dank!

Nachdem ich fsType: ext4 zur Konfiguration der iscsi-Speicherklasse hinzugefügt hatte, musste ich die PVCs löschen, die zu den fehlerhaften Prometheus-Pods gehören. Löschen Sie dann die fehlerhaften Pods. Sie werden automatisch erneut gestartet, bleiben aber im Status „Ausstehend“, bis ich die PVCs erneut erstellt habe.

Gleiches gilt für die Elasticsearch-Pods. Abgesehen davon, dass ich die PVCs nicht neu erstellen musste. Sie wurden automatisch erstellt.

Ich habe die Berechtigungen der iSCSI-Dateisysteme in den Pods überprüft. Sie gehören jetzt nicht mehr root:root .
Alle Pods befinden sich im Status „Wird ausgeführt“ und der Überwachungsclusteroperator ist nicht mehr herabgesetzt.

@timvandevoort dies hängt damit zusammen, wie Kubernetes fsGroups anwendet. Wie hier zu sehen ist: https://github.com/kubernetes/kubernetes/blob/f137c4777095b3972e2dd71a01365d47be459389/pkg/volume/csi/csi_mounter.go#L415

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

Solange für Ihre StorageClass ein parameters.fsType definiert ist, können Sie fsGroups über den Sicherheitskontext anwenden.

Ich markiere dieses Problem als "Geschlossen". Danke, dass Sie Trident verwenden!