Kubernetes с управлением на локальном постоянном томе с помощью docker для Windows

#kubernetes #kubernetes-helm

#kubernetes #kubernetes-helm

Вопрос:

Я попытался использовать helm в docker для Windows на локальном компьютере. Когда я использовал класс хранилища в качестве локального хранилища, постоянного тома и требования к постоянному объему без helm, он работал нормально. Но когда я использовал этот параметр с helm, произошел сбой.

localStrageClass.yaml

 kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
  

pv.yaml

 apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv002
  labels:
    type: local
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  #storageClassName: hostpath
  mountOptions:
    - hard
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /c/k/share/mysql
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        #- key: docker.io/hostname
        - key: kubernetes.io/hostname
          operator: In
          values:
          - docker-desktop
  

pvc.yaml

 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-mysql-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-storage
  

mysqlConf.yaml

 persistence:
  enabled: true
  storageClass: local-storage
  existingClaim: local-mysql-claim
  accessMode: ReadWriteOnce
  size: 1Gi
  annotations: {}
  

установка $ helm —имя mysql stable/mysql -f mysqlConf.yaml
$ kubectl описать модуль mysql

 Containers:
  mysql:
    Container ID:   docker://533e4569603b05fac83a0a701da97898b3190503618796678ac5db6340c4dce6
    Image:          mysql:5.7.14
    Image ID:       docker-pullable://mysql@sha256:c8f03238ca1783d25af320877f063a36dbfce0daa56a7b4955e6c6e05ab5c70b
    Port:           3306/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Thu, 28 Mar 2019 13:24:25  0900
      Finished:     Thu, 28 Mar 2019 13:24:25  0900
    Ready:          False
    Restart Count:  2
    Requests:
      cpu:      100m
      memory:   256Mi
    Liveness:   exec [sh -c mysqladmin ping -u root -p${MYSQL_ROOT_PASSWORD}] delay=30s timeout=5s period=10s #success=1 #failure=3
    Readiness:  exec [sh -c mysqladmin ping -u root -p${MYSQL_ROOT_PASSWORD}] delay=5s timeout=1s period=10s #success=1 #failure=3

    Environment:
      MYSQL_ROOT_PASSWORD:  <set to the key 'mysql-root-password' in secret 'mysql'>  Optional: false
      MYSQL_PASSWORD:       <set to the key 'mysql-password' in secret 'mysql'>       Optional: true
      MYSQL_USER:
      MYSQL_DATABASE:
    Mounts:
      /var/lib/mysql from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-dccpv (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  local-mysql-claim
    ReadOnly:   false
  default-token-dccpv:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-dccpv
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From                     Message
  ----     ------     ----               ----                     -------
  Normal   Scheduled  39s                default-scheduler        Successfully assigned default/mysql-698897ff79-n768k to docker-desktop
  Normal   Pulled     38s                kubelet, docker-desktop  Container image "busybox:1.29.3" already present on machine
  Normal   Created    38s                kubelet, docker-desktop  Created container
  Normal   Started    38s                kubelet, docker-desktop  Started container
  Normal   Pulled     18s (x3 over 37s)  kubelet, docker-desktop  Container image "mysql:5.7.14" already present on machine
  Normal   Created    17s (x3 over 37s)  kubelet, docker-desktop  Created container
  Normal   Started    17s (x3 over 37s)  kubelet, docker-desktop  Started container
  Warning  BackOff    13s (x5 over 35s)  kubelet, docker-desktop  Back-off restarting failed container
  

Когда storageClassName был hostpath или не использовался файл конфигурации как

установка $ helm —имя mysql stable /mysql

это сработало нормально.

Пожалуйста, скажите мне, как исправить эту проблему.

Ответ №1:

Я думаю, у вас несоответствие режимов доступа между тем, что вы заявляете в определении PVC (ReadWriteOnce), и тем, что предлагает ваш класс хранения (ReadWriteMany).

Пожалуйста, имейте в виду также, что постоянные тома типа hostPath не поддерживают режим ReadWriteMany (см. спецификацию здесь).

Я бы предложил вам создать PV, подобный этому:

 # Create PV of manual StorageClass
kind: PersistentVolume
apiVersion: v1
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/C/Users/K8S/mysql" 
  

и переопределите конфигурацию PVC storageClassName по умолчанию во время установки helm следующим образом:

 helm install --name my-sql stable/mysql --set persistence.storageClass=manual
  

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

1. Я попробовал ваше предложение, но оно вызвало «Сбой планирования: модуль отключил немедленные постоянные запросы на объем’. Итак, я изменил только «ReadWriteMany» на «ReadWriteOnce» и «local-storage» на «manual», все работает нормально. Благодарим вас за сотрудничество!

2. Я рад, что смог вам помочь. Я тестировал его на minikube в Windows, а не на Docker Desktop, отсюда, вероятно, и проблема с запуском вышеупомянутого рецепта как есть.

3. Похоже, что эта проблема зависит от версии kubectl и helm, потому что kubectl 1.14 и helm 1.13 вызывают проблемы того же типа, но комбинация бета-версии kubectl 1.14 и helm 1.12 работала нормально. Спасибо за ваш совет. Я буду использовать minikube вместо Docker Desktop, который является хрупким и нестабильным.