kubernetes集群实战——Pod生命周期、检测探针和控制器的运用

1. Pod生命周期

Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

1.1 Init 容器介绍

Init 容器是一种专用的容器，在Pod 内的应用容器启动之前运行，并包括一些应用镜像中不存在的实用工具和安装脚本。
你可以在Pod的规格信息中与containers数组同级的位置指定 Init 容器

Init 容器与普通的容器非常像，除了如下两点：
• 它们总是运行到完成。
• Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成。 • 每个 Init 容器必须运行成功，下一个才能够运行。

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

Init 容器能做什么？
• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
• Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
• 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
• Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
• 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

1.2 使用 Init 容器

流程原理：定义一个具有 1个 Init 容器的简单 Pod，等待 myservice 启动，一旦我们启动了 myservice 这个 Service，我们能够看到 Init 容器启动完成，并且 myapp-pod 被创建，Pod 将启动spec区域中的应用容器

vim init.yml ##编辑init.yml pod文件
kubectl apply -f init.yml   ##启动这个 Pod
kubectl get pod ##可以看到Init容器初始化未成功，它需要service的启动，才可以成功初始化
vim service.yml ##创建Service 的配置文件
kubectl apply -f service.yml    ##创建myservice的 service 命令
kubectl get pod ##可以看到Init容器执行完毕，随后my-app的Pod转移进入 Running 状态

init.yml文件内容

service.yml文件内容

Init容器启动完成后，再去删除Service是不会影响应用容器的运行的

注意：
需要在物理机关闭网络连接，否则kubernetes集群将通过我们虚拟机网络配置文件中的dns解析到Service（而不是通过kubernetes自带dns解析到），我们不建立Service配置文件Init容器也会初始化完成，这样的话和实验目的有差异，所以建议关闭网络连接

2.检测探针

探针是由 kubelet 对容器执行的定期诊断：
• ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
• TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
• HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
• 成功：容器通过了诊断。
• 失败：容器未通过诊断。
• 未知：诊断失败，因此不会采取任何行动。
Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测 (startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。
重启策略
• PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。
Pod 的生命
• 一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。 • 建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
三种可用的控制器：
• 使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
• 对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
• 提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod

2.1 存活探针检测

存活探针由 kubelet 来执行，因此所有的请求都在 kubelet 的网络命名空间中进行。

vim init.yml ##编辑init.yml pod文件，加入以下参数tcpSocket：   ##检测服务的端口，探测这个端口是否一直存在，一直存在证明这个服务是存活状态initialDelaySeconds: 1  ##表示启动后的延迟periodSeconds: 2  ##周期两秒一次timeoutSeconds: 1   ##超时设定
kubectl apply -f init.yml   ##启动这个 Pod
kubectl get pod ##可以看到Init容器初始化未成功，它需要service的启动，才可以成功初始化
kubectl apply -f service.yml
kubectl get pod ##可以看到Init容器执行完毕，随后my-app的Pod转移进入 Running 状态
kubectl describe svc myservice  ##查看myservice状态信息

手动关闭nginx服务，会自动restarts一次，restarts项显示为1

再次测试：关闭nginx服务，会自动restarts一次，restarts项显示为2

vim service.yml  ##编辑service.yml
kubectl apply -f service.yml        ##运用service.yml
kubectl get pod
kubectl describe svc myservice  ##查看myservice状态信息

2.2 就绪探针检测

vim init.yml ##编辑init.yml pod文件，加入以下参数readinessProbe: httpGet: path: /hostname.html port: 80 initialDelaySeconds: 1 periodSeconds: 2timeoutSeconds: 1
kubectl apply -f init.yml   ##启动这个 Pod
kubectl get pod ##看到READY项是就绪状态
kubectl exec -it myapp-pod --sh ##进入pod内部容器注释掉访问页使它不能被访问（服务存活但未就绪）

进入pod内部容器注释掉访问页使它不能被访问（服务存活但未就绪）：

kubectl get pod  ##看到READY项不是就绪状态，在不是就绪状态时，它是不会加入到service的，可以看到Endpoints是空的

测试：
访问报404错误，这说明服务是存活状态，但是他没有准备好供客户浏览的信息

再次编辑，取消注释访问页，使它成为就绪状态，这里需要重新加载nginx服务

就绪状态后，可以看到Endpoints是有ip地址的，可以访问到信息

在service.yml文件中将9376端口改为80，方便访问

运行一个控制器管理的pod，副本数为2

可以看到在访问service的IP时，做了负载均衡

3. 控制器

3.1 控制器类型

Pod 的分类：
• 自主式 Pod：Pod 退出后不会被创建
• 控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目
控制器类型：
• Replication Controller和ReplicaSet
• Deployment
• DaemonSet
• StatefulSet
• Job
• CronJob
• HPA全称Horizontal Pod Autoscaler
StatefulSet
• StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”
• StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。
StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：
• 稳定的、唯一的网络标识符。
• 稳定的、持久的存储。
• 有序的、优雅的部署和缩放。
• 有序的、自动的滚动更新。
HPA
• 根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放。

3.2 各类型控制器的使用

（1）rs控制器
Replication Controller和ReplicaSet
• ReplicaSet 是下一代的 Replication Controller，官方推荐使用ReplicaSet。
• ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。
• ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。
• 虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

vim rs.yml       ##编辑rs控制器运行的pod，指定 Pod 副本数量为3
kubectl apply -f rs.yml ##运行pod
kubectl get pod
kubectl get pod -o wide

控制器控制的pod，在需要做更改时，不需要删除pod重新建立，直接编辑pod文件更改再运行即可
更改副本个数为5

（2）Deployment控制器
Deployment
• Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。
典型的应用场景：
• 用来创建Pod和ReplicaSet
• 滚动更新和回滚
• 扩容和缩容
• 暂停与恢复

删除之前rs控制器所建立的pod

vim deployment.yml       ##编辑deployment控制器运行的pod，指定 Pod 副本数量为2
kubectl apply -f deployment.yml ##运行pod
kubectl get pod ##Deployment 已创建所有两个副本，并且所有副本都是最新的（它们包含最新的 Pod 模板）并且可用
kubectl get all ##列出当前namespace下的所有信息资源
要查看 Deployment 创建的 ReplicaSet （rs），运行 kubectl get rs。输出：
注意， ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子。

更新 Deployment
更新镜像版本：myapp:v2

查看 Deployment ，将看到它首先创建了两个新的 Pod，然后删除（回收）了一些旧的 Pods，并创建了新的 Pods。它不会杀死老 Pods，直到有足够的数量新的 Pods 已经出现，并没有创造新的 Pods，直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用，并且总共最多 4 个 Pods 可用。

原来的版本没有被删掉是为了以后做回滚用

维护数量不变：
删除一个会自动重新创建一个
当发现有 pod状态不对的，可以直接删除它之后会自动新建一个：

运行多个版本的Deployment：

（3）DaemonSet控制器
DaemonSet
• DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod 。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
DaemonSet 的典型用法：
• 在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。
• 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。
• 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、 zabbix agent等
• 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。
• 一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志，并且对不同硬件类型具有不同的内存、CPU 要求。
在私有仓库上添加zabbix-agent镜像，使得kubernetes集群中的节点可以拉取到

vim daemonset.yml        ##编辑daemonset控制器运行的pod
kubectl apply -f daemonset.yml  ##运行pod
kubectl get pod
kubectl get pod -o wide ## 可以看到集群中的每个节点都运行一个pod

（4）Job控制器
Job
• 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。

这里以运算pi任务做示例
在私有仓库上添加perl镜像，使得kubernetes集群中的节点可以拉取到

vim job.yml      ##编辑job控制器运行的pod
kubectl apply -f job.yml    ##运行pod
kubectl get pod
kubectl logs example-job-bwqbl  ##查看pod运行日志，可以看到pi值，我们设置的是小数点后2000位

（5）CronJob控制器
CronJob
• Cron Job 创建基于时间调度的 Jobs。
• 一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

vim cronjob.yml      ##编辑cronjob控制器运行的pod
kubectl apply -f cronjob.yml    ##运行pod
kubectl get pod ##每分钟运行一个pod
kubectl logs cronjob-example-1592902620-8qrgt   ##查看输出