Нет способа применить изменения к развертыванию, связанному с ReadWriteOnce PV, в движке gCloud Kubernetes?

Поскольку диск GCE не поддерживает ReadWriteMany , у меня нет возможности применить изменения к развертыванию, кроме как застрять в ContainerCreating с FailedAttachVolume .

Итак, вот моя настройка:

<сильный>1. ПВХ

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: mysql
spec:
  storageClassName: "standard"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

<сильный>2. Сервис

apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306
  selector:
    app: mysql

<сильный>3. Развертывание

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql/mysql-server
        name: mysql
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /mysql-data
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

Все это отлично подходит для создания PVC, svc и развертывания. Pod и контейнер успешно запустились и работали должным образом.


Однако, когда я попытался применить изменение: kubectl apply -f mysql_deployment.yaml

Во-первых, модули были заблокированы, а существующий не прекращался, а новый создавался вечно.

NAME             READY     STATUS              RESTARTS   AGE
mysql-nowhash    1/1       Running             0          2d
mysql-newhash    0/2       ContainerCreating   0          15m

Во-вторых, из консоли gCloud внутри модуля, который я пытался создать, я получил два важных журнала ошибок:

1 из 2 FailedAttachVolume

Multi-Attach error for volume "pvc-<hash>" Volume is already exclusively attached to one node and can't be attached to another  FailedAttachVolume

2 из 2 FailedMount

Unable to mount volumes for pod "<pod name and hash>": timeout expired waiting for volumes to attach/mount for pod "default"/"<pod name and hash>". list of unattached/unmounted volumes=[mysql-persistent-storage] 

Я сразу подумал о ReadWriteOnce возможностях gCloud PV. Потому что движок kubernetes создаст новый модуль перед тем, как закрыть существующий. Таким образом, при ReadWriteOnce он никогда не сможет создать новый модуль и потребовать существующий pvc...

Любая идея или мне следует использовать какой-либо другой способ выполнения обновлений развертывания? признателен за любой вклад и предложение =)

примечание: мой текущий обходной путь заключается в создании промежуточного модуля NFS, чтобы сделать его похожим на пвк ReadWriteMany, это сработало, но звучит глупо ... требует дополнительных затрат на ввод-вывод хранилища для облегчения обновления развертывания? .. = P


person Michael Linus    schedule 22.10.2018    source источник


Ответы (1)


Причина в том, что если вы применяете UpdateStrategy: RollingUpdate (по умолчанию), k8s ожидает готовности нового контейнера, прежде чем закрыть старый. Вы можете изменить это поведение, применив UpdateStrategy: Recreate

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy

person Louis Baumann    schedule 22.10.2018
comment
Учитывая, что я не ожидаю нулевого простоя UpdateStrategy, верно? - person Michael Linus; 23.10.2018
comment
в яблочко. вы не можете привязать PVC с режимом доступа ReadWriteOnce к двум модулям одновременно. если вы запускаете свое приложение с ожиданием высокой доступности, развертывание только одного экземпляра в любом случае не будет соответствовать этому ожиданию. в зависимости от архитектуры и дизайна приложения я бы рекомендовал увеличить количество реплик и изменить параметры RollingUpdate, как показано в примере: container-solutions.com/kubernetes-deployment-strategies - person Louis Baumann; 24.10.2018