Kubernetes 中怎么实现应用高可用

这篇文章将为大家详细讲解有关Kubernetes 中怎么实现应用高可用，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

1. Kubernetes 探针

当你使用 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。

2. 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 中怎么实现应用高可用就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。