利用Kubernetes实现各种应用
这篇文章主要讲解了"利用Kubernetes实现各种应用"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"利用Kubernetes实现各种应用"吧！
本节课将带领大家学习探针与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 字段，以及就绪探针等相关功能进一步使用。
03
课程总结
1、探针的使用，就绪探针与存活探针。三种探测方式
2、ReplicaSet 的工作原理，通过 label 将 pod 维持在一定数量
3、Deployment 的工作原理，升级方式以及如何回滚。
感谢各位的阅读，以上就是"利用Kubernetes实现各种应用"的内容了，经过本文的学习后，相信大家对利用Kubernetes实现各种应用这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！
