kubernetes如何为有卷连接的状态应用提供HA？

Question

我无法将我的有状态的应用程序配置为对 kubernetes worker 失败具有弹性（我的应用程序 pod 存在的那个）。

$ 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>

一旦我拿下worker，kubernetes就会注意到pod没有响应，并将其调度到另一个worker。

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>

这很好，但新容器无法启动，因为它试图附加旧容器使用的相同的pvc，而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

我能够通过手动强制删除容器，解除对pvc的绑定并重新创建容器来解决这种情况，但这与我所期望的高可用性相差甚远。

我使用openEBS jiva卷，在手动干预后，我能够在PV上以正确的数据恢复容器，这意味着数据被正确复制到其他节点。

谁能解释一下我到底做错了什么，如何实现带卷连接的k8s应用的容错？

我发现这个相关的问题，但我没有看到任何克服这个问题的建议。https:/github.comopenebsopenebsissues2536

Answer 1

它最终会释放卷，通常限制因素是网络存储系统检测到卷未挂载的速度很慢。但你说的没错，这是一个限制因素。通常的解决方法是使用一个多挂载能力的卷类型来代替，比如NFS或CephFS。

Answer 2

要部署有状态的应用kubernetes有 有状态集 对象可能会在这种情况下帮助你。

StatefulSets对于需要以下一个或多个条件的应用来说是非常有价值的。

• 稳定的、唯一的网络标识符。
• 稳定的、持久的存储。
• 有序的、优雅的部署和扩展。
• 有序的、自动滚动更新。

Answer 3

对于无人管理的Kubernetes集群，这是一个适用于所有类型的RWO卷的难题。

围绕这个问题，Kubernetes社区已经进行了多次讨论，在这些问题中进行了总结。

• https:/github.comkubernetesenhancementspull1116。
• https:/github.comkuberneteskubernetesissues86281。
• https:/github.comkuberneteskubernetesissues53059。

目前的思路是借助NodeTolerations来提出解决方案，并通过CSI驱动来实现。

在openebs，我们在研究云服务商如何处理这种情况时，发现当一个节点被关闭时，其对应的节点对象会从集群中删除。这个操作并没有什么危害，因为当节点重新上线时，节点对象会被重新创建。