Как kubernetes предоставляет HA для приложений с состоянием с подключенными томами? - PullRequest
Новая
       22

Как kubernetes предоставляет HA для приложений с состоянием с подключенными томами?

0 голосов
/ 28 апреля 2020

Я не могу настроить мое приложение с состоянием, чтобы оно было устойчивым к отказу работника kubernetes (тот, в котором существует мой модуль приложения) 

$ kk get pod -owide
NAME                                READY   STATUS    RESTARTS   AGE     IP                NODE               NOMINATED NODE   READINESS GATES
example-openebs-97767f45f-xbwp6     1/1     Running   0          6m21s   192.168.207.233   new-kube-worker1   <none>           <none>

Как только я убираю работника, kubernetes замечает, что модуль не отвечает и планирует его другому работнику. 

marek649@new-kube-master:~$ kk get pod -owide
NAME                                READY   STATUS              RESTARTS   AGE   IP                NODE               NOMINATED NODE   READINESS GATES
example-openebs-97767f45f-gct5b     0/1     ContainerCreating   0          22s   <none>            new-kube-worker2   <none>           <none>
example-openebs-97767f45f-xbwp6     1/1     Terminating         0          13m   192.168.207.233   new-kube-worker1   <none>           <none>

Это здорово, но новый контейнер не может запуститься, так как он пытается подключить тот же pv c, который использовался старым контейнером, и kubernetes не освобождает привязку к старому (не отвечающему) узлу. 

$ kk describe pod example-openebs-97767f45f-gct5b
Annotations:    <none>
Status:         Pending
IP:             
IPs:            <none>
Controlled By:  ReplicaSet/example-openebs-97767f45f
Containers:
  example-openebs:
    Container ID:   
    Image:          nginx
    Image ID:       
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /usr/share/nginx/html from demo-claim (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-4xmvf (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  demo-claim:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  example-pvc
    ReadOnly:   false
  default-token-4xmvf:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-4xmvf
    Optional:    false
QoS Class:       BestEffort
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           2m9s  default-scheduler          Successfully assigned default/example-openebs-97767f45f-gct5b to new-kube-worker2
  Warning  FailedAttachVolume  2m9s  attachdetach-controller    Multi-Attach error for volume "pvc-911f94a9-b43a-4cac-be94-838b0e7376e8" Volume is already used by pod(s) example-openebs-97767f45f-xbw
p6
  Warning  FailedMount         6s    kubelet, new-kube-worker2  Unable to attach or mount volumes: unmounted volumes=[demo-claim], unattached volumes=[demo-claim default-token-4xmvf]: timed out waiti
ng for the condition

Я могу разрешить эту ситуацию, вручную принудительно удалив контейнеры, освободив PV и заново создав контейнеры, но это далеко не так Наличие, которое я ожидаю.

Я использую тома openEBS jiva, и после ручного вмешательства я могу восстановить контейнер с правильными данными на PV, что означает, что данные правильно реплицируются на другие узлы.

Может кто-нибудь объяснить, пожалуйста что я делаю неправильно и как добиться отказоустойчивости для приложений k8s с подключенными томами?

Я обнаружил, что это связано, но я не вижу никаких предложений, как решить эту проблему https://github.com/openebs/openebs/issues/2536

Ответы [ 3 ]

1 голос
/ 28 апреля 2020

Это в конечном итоге приведет к освобождению тома, обычно ограничивающим фактором является медленная система сетевого хранения, обнаруживающая, что том отключен. Но вы правы, что это ограничение. Обычное исправление состоит в том, чтобы использовать вместо этого тип тома с поддержкой нескольких подключений, например NFS или CephFS.

0 голосов
/ 30 апреля 2020

Для неуправляемых кластеров Kubernetes это сложная проблема, которая применяется ко всем типам томов RWO.

Было несколько дискуссий по этому поводу в сообществе Kubernetes, которые кратко изложены в следующих выпусках:

Текущий мыслительный процесс состоит в том, чтобы воспользоваться помощью NodeTolerations, чтобы найти решение и внедрить решение с помощью драйвера CSI.

На openebs, когда мы посмотрели, как поставщики облачных услуг справляются с этим случаем, мы обнаружили, что когда узел отключается, его соответствующий объект узла удаляется из кластера. Эта операция не причинит вреда, поскольку, когда узел возвращается в оперативный режим, объект узла воссоздается.

0 голосов
/ 28 апреля 2020

Для развертывания приложения с состоянием kubernetes имеет Statefulset объект с может помочь вам в этом случае.

StatefulSets полезны для приложений, которые требуют одного или нескольких из следующих действий.

  • Стабильные, уникальные сетевые идентификаторы.
  • Стабильное, постоянное хранилище.
  • Упорядоченное, плавное развертывание и масштабирование.
  • Заказные, автоматические обновляемые обновления.
...