Question

我想在任何节点上运行应用程序。每个节点应始终至少有一个实例，但允许更多实例，主要是在更新过程中，以防止该Pod（和节点）停机。

Kubernetes部署更新通常通过启动新的Pod来起作用，并且一旦可用，旧的Pod就会终止。太完美了，但就我而言，我需要一个DaemonSet来始终在所有节点上启动特定的应用程序。但是，在更新此DaemonSet时，Kubernetes会一个接一个地杀死一个Pod（即逐个节点），然后然后启动一个新Pod，这意味着在更新期间的任何给定时间内Pod可能没有运行在一个节点上。

与Deployment相比，DaemonSet似乎是执行此操作的正确方法，但是在更新DaemonSet时我找不到任何防止停机的方法。有什么办法吗？我还考虑过使用Deployments并手动更新副本数量和antiPodAffinity，这样每个节点只能部署一个Pod，但这有点麻烦。

Answer 1

关于添加此功能的讨论很长。您可以看到它们here和here

长话短说，这实际上是不可能的。您可以尝试将maxUnavailable: 0和type: rollingUpdate合并到您的updateStrategy中，但我认为这不受正式支持。

示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
  labels:
    service: my-daemonset
spec:
  selector:
    matchLabels:
      service: my-daemonset
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        service: my-daemonset
    spec:
      containers:
      - name: daemonset-update
        image: my-image:latest

Answer 2

截止到今天，使用DeamonSet可以在不停机的情况下执行滚动更新！您需要在集群上至少运行2个节点，并在DaemonSet配置中将maxUnavailable设置为1。

假定以前的配置，当推送更新时，第一个节点将开始更新。第二个将等待，直到第一个完成。成功后，第二个将执行相同操作。

主要缺点是，您需要使2个节点连续运行，或在更新之前/之后采取措施生成/杀死一个节点。

Answer 3

假设您的应用程序每个节点可以容忍一个以上的Pod（似乎是这种情况），则可以创建第二个DaemonSet，并在确定新的DaemonSet正常运行后删除原始的DaemonSet。这个过程要复杂一些，但是它可以让您控制何时删除旧容器。

请注意，最终您将获得一个DaemonSet并使用另一个名称。如果您感到困扰，您总是可以再次重复该过程以返回到原始名称。

更新DaemonSet，而不会像部署一样停机

3 个答案: