Kubernetes群集的零停机服务器更新-技术圈

原文标题：Zero Downtime Server Updates For Your Kubernetes Cluster
发布时间：Jan 26, 2019
原文链接：https://blog.gruntwork.io/zero-downtime-server-updates-for-your-kubernetes-cluster-902009df5b33
文章作者：yorinasub17

在Kubernetes集群的生命周期中，总会有某个时候，你需要对集群的宿主机节点进行维护。这可能包括程序包更新，内核升级或部署新的VM映像。在Kubernetes中，这些操作被视为“自愿中断”。

译注：参考Kubernetes对自愿中断和非自愿中断的定义
链接：https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions

这篇文章是一个分为四部分的博客系列的第一篇，下一篇文章会介绍如何优雅地关闭 Pod。

在这个系列中我们会介绍 Kubernetes 提供的所有用来实现集群中工作节点的零宕机时间更新的工具。

问题说明

我们将从简单直接的维护宿主机节点的方法开始，确定该方法的挑战和潜在风险，并逐步构建解决我们在整个系列中发现的每个问题的方法。在这个博客系列结束时我们将完成一个Kubernetes配置，该配置利用生命周期钩子，就绪探针（redinessProbe）和 PodDisruptionBudgets 来实现 Kubernetes集群的零停机时间部署。

译注：推荐阅读「Pod的活性探针和就绪探针」

为了开始我们的旅程，让我们看一个具体的例子。假设我们有一个两节点的 Kubernetes 集群，集群上运行着一个使用了两个 Pod 和一个 Service 资源的应用程序。

现在的问题是我们要升级集群中两个宿主机节点的内核版本。我们将如何执行升级？简单粗暴的方法是使用更新的配置启动新节点，在启动新节点后关闭旧节点。尽管这种方法有效，但是这种方法存在一些问题：

当关闭旧节点时，节点上的 Pod 也会被删除。如果 Pod 需要清理以正常关闭上面运行的应用程序该怎么办？底层的VM技术可能不会等待 Pod 执行清理过程。
如果同时关闭所有节点怎么办？在将 Pod 重新启动到新节点中时，你的应用程序服务会短暂中断。

我们想要的是一种从旧节点上正常迁移 Pod 的方法，以确保在对节点进行更改时，没有任何工作负载在运行。或者，如示例中所述，如果要完全替换群集（例如替换VM镜像），我们希望将工作负载从旧节点移到新节点。在这两种情况下，我们都希望避免调度新的 Pod 到旧节点上，我们可以使用kubectl drain命令来实现这一点。

把Pod调度到节点之外

排出操作（kubectl drain）实现了将所有 Pod 重新调度到节点之外的目的。在排出操作期间，该节点会被标记为不可调度（通过给节点添加 NoSchedule 污点实现）。这样可以防止新建的Pod被调度到节点上。之后，排出操作开始从节点上驱逐 Pod，通过将 TERM 信号发送到 Pod 的底层容器来关闭当前在节点上运行的容器。

尽管kubectl drain将很好地处理将Pod 逐出节点的工作，但仍有两个因素可能会在kubectl drain 触发的操作运行期间导致服务中断：

运行中的应用程序需要能够优雅地处理 TERM 信号，当一个 Pod 驱逐时，Kubernetes 会向 Pod 发送 TERM 信号，然后在强制终结容器前会等待一段时间让容器自己关闭，这个等待时间是可以配置的。但是，如果 Pod 里的应用程序不能优雅地处理 TERM 信号，则仍然会导致不干净地关闭 Pod，比如应用程序正在工作期间（例如提交数据库事务等）。
应用程序将失去为其提供服务的所有 Pod 。在新节点上启动新容器时，您的服务会遭遇停机。

避免停机

为了最大程度地减少因维护集群等自愿性中断而导致的停机时间，Kubernetes 提供以下中断处理功能：

Graceful termination
Lifecycle hooks
PodDisruptionBudgets

本系列的其余部分中，我们将使用 Kubernetes 的这些功能来减轻驱逐事件造成的服务中断。为了使后续操作更容易，我们将在上面的示例中使用以下资源配置：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    targetPort: 80
    port: 80

上面的配置里包含了一个 Deployment 资源的最简示例，这个 Deployment 会始终维持集群中有两个标签为 app: nginx的 Pod，另外配置里还提供了一个可用于访问集群内 Nginx Pod 的 Service 资源的定义。

我们将在本系列的整个过程中逐步增加其内容，以构建最终配置，以实现Kubernetes提供的所有功能，最大程度地减少维护操作期间的停机时间。

下一篇文章，我们将会讲解如何利用 Kubernetes 的生命周期钩子（Lifecycle Hooks）来正常关闭 Pod。