作者简介

胡家靖                                     

百度基础架构部研发工程师

负责函数计算与云原生产品的研发

本文基于百度云原生团队『云原生基础知识概述及实践』系列视频课程——『Kubernetes 入门—Kubernetes 实现应用高可用』梳理.

视频课程可点击：https://cloud.baidu.com/video-center/video.html?id=609进行学习。

导读

在前两节课，我们学习了 Docker（Kubernetes入门——深入浅出讲Docker）和 Kubernetes（Kubernetes入门——Kubernetes工作原理及使用）（Kubernetes入门——Kubernetes应用部署）相关基础知识。

Pod 代表了 Kubernetes 中的基本部署单元，但是，在一般情况下我们不会直接使用 Pod，因为每一次重启它的 IP 都会发生变化；如果你希望自己的应用能自动保持健康运行而且无需手动干预，则需要通过创建 ReplicaSet 或者 Deployment 这样的资源来管理实际的 Pod。

另外很多时候我们需要判断 Pod 是否需要重启，请求是否可被调度到 Pod，探针的出现使得这些问题迎刃而解。

本节课将带领大家学习探针与 Deployment 的使用。通过实践与学习，了解 Kubernetes 如何实现应用的高可用。

课程主要分为以下四个部分：

第一部分：探针

第二部分：Deployment 的使用

第三部分：Demo

第四部分：总结

01 Kubernets 探针

当你使用 kubernetes 的时候，有没有遇到过 Pod 在启动后一会就挂掉然后又重新启动这样的恶性循环？Kubernetes 如何检测 pod 是否还存活？虽然容器已经启动，Kubernetes 如何知道容器的进程是否准备好对外提供服务了呢？答案是：探针

探针种类

LivenessProbe

• 介绍：LivenessProbe 又称存活探针，其作用主要用于检测容器是否还在运行。kubelet 使用存活探测器来知道什么时候要重启容器。例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。

• 用途：Kubernetes 可以通过存活探针来检查容器是否还在运行。如果探测失败，则 Kubernetes 将会认为容器已经不在运行，将会重新启动容器。

• 探测方式：

1. HTTP：kubelet 对容器的 IP 地址指定路径执行 HTTP GET 请求。根据返回码判断是否探测成功 2. TCP 套接字：尝试与容器指定端口建立 TCP 连接，如果建立成功则表示探测成功。3. Exec：在容器内执行任意命令，检查退出状态码。如返回值为 0，则探测成功。

• 存活探针 yaml 文件：

绿色为 http 探针，这里请求容器的 8080 端口，如果返回是 2xx，或者 3xx，那么表示探测成功。

红色为 exec 探针，这里执行了一个 cat 命令。

蓝色的为 tcp 探针。作用为和 8080 端口尝试建立 TCP 连接。

ReadnessProbe：

• 介绍：就绪探针。用于探测 Pod 是否已经就绪。由于部分 Pod 启动时将会有较长的初始化时间，就绪探针可以用于探测 Pod 是否已经初始化完毕。kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流  量，  当一个 Pod 内的所有容器都准备好了，才能把这个 Pod 看作就绪了。这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。

•  用途：就绪探针在容器生命周期中会被定期调用。确定 Pod 是否接受客户端请求，当容器的准备就绪探测返回成功时，表示容器已经准备好接受请求。

 探测方式：

•  1.HTTP：对容器的 IP 地址指定路径执行 HTTP GET 请求。根据返回码判断是否探测成功 2.TCP 套接字：尝试与容器指定端口建立 TCP 连接，如果建立成功则表示探测成功。3.Exec：在容器内执行任意命令，检查退出状态码。如状态码为 0，则探测成功。

•  就绪探针的 yaml 文件：

就绪探针与存活探针配置几乎一致。

只是字段为 readinessProbe。

02 Deployment 的使用

ReplicaSet

• 简介：Pod 不可靠，可能会宕掉，可以配置重启，但是如果是 Pod 所在的节点宕掉，Pod 就会完全丢失，如果在生产环境就会出现问题。另外我们一般不会使用单个 Pod，而是许多组相同的 Pod 来提供服务，如果手动维护的话会特别困难，特别是在集群数量比较大的时候，所以这里对 ReplicaSet 进行介绍。ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

• 工作原理：RepicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符，一个用来标明应该维护的副本个数的数值，一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值，进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。

• 工作过程：ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

 每次 ReplicaSet 会监控当前 Pod 的数量，如果 Pod 数量多于要求的数量，则会自动删除一 部分。否则会自动创建，创建过程中会使用模板创建。

ReplicaSet 为故障节点上运行的 Pod 创建了新的替代副本，轻松地实现了 pod 的水平伸缩。

如果你更改了一个 pod 的标签，就有可能让它脱离它所属的 ReplicaSet

同理，如果你想将一个 Pod 归到 Replicas Set 中，也可以使用修改标签的方式将其增加到 ReplicaSet 中。

ReplicaSet yaml 示例

1.Label Selector: 标签选择器，用于确定作用域

2.Replicas：副本个数，也就是作用域

3.Pod template: pod 模板

Deployment

一个 Deployment 控制器为 Pod 和 ReplicasSet 提供声明式的更新能力。

你负责描述 Deployment 中的 目标状态，而 Deployment 控制器以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。

Deployment yaml 示例

Deployment yaml 文件与 ReplicaSet 十分相似， 只是多了 strategy 字段。该字段主要用于描述升级方式。

Deployment 并不直接管理 Pod

当创建 Deployment 时，ReplicaSet 也会随之创建。在实际使用 Deployment 的时候，实际的 Pod 由 ReplicaSet 创建和管理，而不是由 Deployment 直接管理。

使用 Deployment 可以更容易地更新应用程序，因为可以直接定义单个 Deployment 资源所需要达到的状态，并让 Kubernetes 处理中间状态。

升级 Deployment

 Deployment 支持声明式更新，即只需要修改 Deployment 资源中的 Pod 模板，Kubernetes 会自动将实际的系统状态收敛为资源中定义的状态。

Deployment 支持不同的升级策略，主要分为 RollingUpdate 以及 Recreate 模式，本策略在 deployment.spec.strategy 字段中定义。详情可以使用 kubectl explain 命令获取。

  Deployment Recreate 升级

 Deployment Recreate 升级策略将会直接停止老版本 Pod， 并创建新的 ReplicaSet 和 Pod。并且进行流量切换。具体步骤如下所示：

缺陷是，升级过程中有一段时间没有 Pod 运行，此时如果有外部请求，服务就处于不可用状态，会损失一定流量。

Deployment RollingUpdate 升级

滚动升级方式如上图所示：

Kubernetes 会先额外创建 v2 版本的 pod 以及 replicaSet。并且逐渐销毁 v1 版本的 pod，从而实现滚动升级

同时，在生产环境中我们十分建议 Deployment 配合就绪探针使用。因为默认情况下， Pod running 时就会接受请求。但是实际上内部服务可能并未就绪。

所以可以配合 minReadySeconds 字段，以及就绪探针等相关功能进一步使用。

更多精彩课程欢迎关注百度开发者中心公众号。