Проблемы с установкой постоянного тома как доступного для чтения в нескольких модулях

#kubernetes #google-kubernetes-engine #persistent-volumes

#kubernetes #google-kubernetes-engine #постоянные тома

Вопрос:

У меня возникли некоторые проблемы с получением постоянного тома ReadOnlyMany для монтирования в нескольких модулях на GKE. Прямо сейчас он монтируется только на одном модуле и не может монтироваться на других (из-за того, что том используется в первом модуле), в результате чего развертывание ограничено одним модулем.

Я подозреваю, что проблема связана с объемом, заполняемым из моментального снимка тома.

Просматривая связанные вопросы, я проверил, что spec.containers.volumeMounts.readOnly = true и spec.containers.volumes.PersistentVolumeClaim.readOnly = true являются наиболее распространенными исправлениями для связанных проблем.

Я включил соответствующий yaml ниже. Любая помощь будет с благодарностью!

Вот (большая часть) спецификации развертывания:

 spec:
  containers:
  - env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/secrets/google/key.json
    image: eu.gcr.io/myimage
    imagePullPolicy: IfNotPresent
    name: monsoon-server-sha256-1
    resources:
      requests:
        cpu: 100m
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /mnt/sample-ssd
      name: sample-ssd
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: gke-cluster-1-default-pool-3d6123cf-kcjo
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 29
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: sample-ssd
    persistentVolumeClaim:
      claimName: sample-ssd-read-snapshot-pvc-snapshot-5
      readOnly: true
  

Класс хранилища (который также является классом хранилища по умолчанию для этого кластера):

 apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sample-ssd
provisioner: pd.csi.storage.gke.io
volumeBindingMode: Immediate
parameters:
    type: pd-ssd
  

ПВХ:

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-ssd-read-snapshot-pvc-snapshot-5
spec:
  storageClassName: sample-ssd
  dataSource:
    name: sample-snapshot-5
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 20Gi
  

Комментарии:

1. Вот конкретное событие ошибки, которое я получаю от GKE: AttachVolume. Сбой подключения тома «pvc-0bf664e7-4cb0-4621-9ef0-f24d00115a27»: ошибка rpc: code = Internal desc = неизвестно Ошибка подключения: сбой при ожидании зональной операции: операция operation-1602875581480-5b1ce8da74009-eb0dd671-6821f2b2 не удалась ( RESOURCE_IN_USE_BY_ANOTHER_RESOURCE): Дисковый ресурс ‘проекты/муссон-273916/zones/europe-west2-a/disks/pvc-0bf664e7-4cb0-4621-9ef0-f24d00115a27’ уже используется ‘projects/monsoon-273916/zones/europe-west2-a/instances/gke-cluster-1-default-pool-3d6123cf-kcjo’

2. Открыта проблема github.com/kubernetes/kubernetes/issues/70505 связанные с настройками ROX, могут помочь!

3. Я предполагаю, что был создан постоянный объем? Как выглядит сам PV? был ли он помечен как spec.gcePersistentDisk.readOnly=true?

4. Спецификации PV нет, поскольку это был динамически подготовленный PVC. Вот соответствующие части «описания kubectl» для подготовленного PV: Класс хранилища: образец-Состояние ssd: Режимы ограниченного доступа: ROX VolumeMode: Источник файловой системы: Тип: Драйвер CSI (источник тома интерфейса контейнерного хранилища (CSI)): pd.csi.storage.gke.io Регулятор громкости: <snip> Только для чтения: false

5. @MikePerrow Какую версию kubernet вы используете?

Ответ №1:

Инженеры Google знают об этой проблеме.

Более подробную информацию об этой проблеме вы можете найти в отчете о проблеме и запросе на извлечение на GitHub.

Существует временное решение, если вы пытаетесь создать PD из моментального снимка и сделать его ROX:

  1. Предоставьте PVC с источником данных как RWO;

Это создаст новый вычислительный диск с содержимым исходного диска
2. Возьмите PV, который был подготовлен, и скопируйте его в новый PV, который является ROX в соответствии с документами

Вы можете выполнить это с помощью следующих команд:

Шаг 1

Предоставьте PVC с источником данных как RWO;

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: workaround-pvc
spec:
  storageClassName: ''
  dataSource:
    name: sample-ss
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  

Вы можете проверить имя диска с помощью command:

kubectl get pvc и проверьте VOLUME столбец. Это disk_name

Шаг 2

Возьмите PV, который был подготовлен, и скопируйте его в новый PV, который называется ROX

Как упоминалось в документах, вам необходимо создать другой диск, используя предыдущий диск (созданный на шаге 1) в качестве исходного:

 # Create a disk snapshot:
gcloud compute disks snapshot <disk_name>

# Create a new disk using snapshot as source
gcloud compute disks create pvc-rox --source-snapshot=<snapshot_name>
  

Создайте новый PV и PVC ReadOnlyMany

 apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-readonly-pv
spec:
  storageClassName: ''
  capacity:
    storage: 20Gi
  accessModes:
    - ReadOnlyMany
  claimRef:
    namespace: default
    name: my-readonly-pvc
  gcePersistentDisk:
    pdName: pvc-rox
    fsType: ext4
    readOnly: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-readonly-pvc
spec:
  storageClassName: ''
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 20Gi
  

Добавьте readOnly: true на свой volumes и volumeMounts , как упоминалось здесь

 readOnly: true