Trident: Volumes iSCSI montés avec des autorisations root sur OpenShift 4.5

Je suppose que vous n'avez pas spécifié le paramètre fsType dans votre classe de stockage. Supprimez la classe de stockage existante (aucun impact sur les volumes existants), ajoutez

fsType: "ext4"

à votre yaml de classe de stockage et recréez.

Un peu de contexte

Lorsque le pod démarre, il peut spécifier un fsGroup dans le cadre du securityContext. Kubernetes ira de l'avant et appliquera cet ID de groupe à tous les fichiers/dossiers du volume (chown/chmod) et ajoutera le groupe en tant que groupe supplémentaire à l'utilisateur avec lequel l'application s'exécute. Cela garantit que les autorisations sont correctement définies.

Comme cela n'est pas possible dans tous les scénarios (en fonction du stockage utilisé), Kubernetes essaie de détecter si cela doit fonctionner ou non. L'un des indicateurs est le fsType. Si cela existe, Kubernetes suppose qu'il pourra chown/chmod. Dans les anciennes versions, il était défini sur ext4 par défaut. Cela a changé en "" avec les versions plus récentes des conteneurs side-car CSI qui sont inclus dans Trident 20.07.1 et supérieur. Ainsi, sur les anciennes versions, si vous ne spécifiiez pas fstype dans votre classe de stockage, le "ext4" par défaut était utilisé et tout fonctionnait. Dans les versions plus récentes, il existe une valeur par défaut vide, donc si vous ne l'avez pas dans votre classe de stockage, elle sera vide - ce qui fera croire à Kubernetes qu'il n'y a pas de fsType et sautera l'étape d'autorisation.

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

J'ai supprimé et recréé la classe de stockage iscsi en ajoutant le paramètre '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

J'ai ensuite redémarré l'un des pods Prometheus et elasticsearch. Mais le problème demeure.

$  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

Ai-je raté une étape ?

Désolé, je n'ai pas été clair à ce sujet. Les paramètres de la classe de stockage s'appliquent uniquement aux nouveaux volumes que vous créez. Tout PV existant n'obtiendra pas cet ensemble. Je crains que vous ne puissiez pas modifier cela pour un PV déjà existant. Pourriez-vous s'il vous plaît essayer avec un nouveau PVC/PV ?

Bonjour, cela résout le problème ! Merci beaucoup!

Après avoir ajouté fsType: ext4 à la configuration de la classe de stockage iscsi, j'ai dû supprimer les PVC appartenant aux pods prometheus défaillants. Supprimez ensuite les pods défaillants. Ils seront redémarrés automatiquement mais resteront dans l'état En attente jusqu'à ce que j'ai recréé les PVC.

Idem pour les pods elasticsearch. Sauf que je n'ai pas eu à recréer les PVC. Ils ont été créés automatiquement.

J'ai vérifié les autorisations des systèmes de fichiers iSCSI à l'intérieur des pods. Ils n'appartiennent plus à root:root maintenant.
Tous les pods sont en état d'exécution et l'opérateur de cluster de surveillance n'est plus dégradé.

@timvandevoort cela est lié à la façon dont Kubernetes applique fsGroups. Comme on peut le voir ici : https://github.com/kubernetes/kubernetes/blob/f137c4777095b3972e2dd71a01365d47be459389/pkg/volume/csi/csi_mounter.go#L415

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

Tant que votre StorageClass a un parameters.fsType défini, vous pouvez appliquer fsGroups via le contexte de sécurité.

Je marque ce problème comme "Fermé". Merci d'utiliser Trident !