Kubernetes——使用副本机制和控制器部署托管Pod

Posted 2021-11-02 刘小豆豆豆

2、副本机制和控制器部署托管Pod

当需要pod能够自动保持运行，并且保持健康时，通常会创建ReplicationController或Deployment这样的资源来托管Pod，接着由它们来创建并管理实际的pod。

当创建未托管的pod时 ，会选择一个集群节点来运行pod, 然后在该节点上运行容器。Kubemetes会监控这些容器， 并且在它们失败的时候自动重新启动它们。 **但是如果整个节点失败，那么节点上的pod会丢失，并且不会被新节点替换。**除非这些pod被控制器托管。

2.1 保持Pod健康

在K8s中，只要将 pod 调度到某个节点， 该节点上的 Kubelet 就会运行 pod 的容器， 从此只要该 pod 存在， 就会保持运行。 如果容器的主进程崩溃， Kubelet 将重启容器。 如果应用程序中有一个导致它每隔一段时间就会崩溃的 bug, Kubemetes 会自动重启应用程序， 所以即使应用程序本身没有做任何特殊的事， 在 Kubemetes 中运行也能自动获得自我修复的能力。

但有时进程没有崩溃，仍需要停止工作，例如发生OOM时，JVM进程会一直运行，此时需要程序向k8s发出信号，告诉k8s运行异常并重新启动此程序。

2.1.1 存活探针

k8s可以通过存活探针来检查容器是否还在运行，可以为每个pod中的每个容器单独制定存货探针，如果探测失败，k8s会重新启动容器。

K8有以下三种探测容器的机制：

• HTTP GET探针对容器的 IP 地址（你指定的端口和路径）执行 HTTP GET 请求。
  • 如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP 响应状态码是2xx或3xx), 则认为探测成功。如果服务器返回错误响应状态 码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。
• TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立则探测成功，否则重启容器。
• Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是0, 则探测成功。所有其他状态码都被认为失败。

2.1.2 创建HTTP存活探针

将存活探针添加到pod：

该pod的描述文件定义了一个httpGet存活探针，该探针告诉Kubernetes定期在端口8080路径上执行HTTPGET请求，以确定该容器是否健康。

可以通过kubectl describe的内容查看具体的内容：

可以看到容器现在正在运行，但之前由于错误而终止。退出代码为137。数字137是两个数字的总和： 128+x, 其中x是终止进程的信号编号。在这个例子中，x等于9, 这是SIGKILL 的信号编号，意味着这个进程被强行终止。

注意：当容器进程被强行终止时，会创建一个全新的容器，而不是重启。

2.1.3 探针的附加属性

除了明确指定的存活探针选项，还可以看到其他属性，例如delay(延迟）、 timeout(超时）、period(周期）等。delay=Os部分显示在容器启动后立即 开始探测。timeout仅设置为1秒，因此容器必须在1秒内进行响应， 不然这次探测记作失败。每10秒探测一次容器(period=10s), 并在探测连续三次失败 (#failure= 3)后重启容器。

如果没有设置初始延迟(initialDelaySeconds)，探针将在启动时立即开始探测容器， 这通常会导致探测失败， 因为应用程序还没准备好开始接收请求。 如果失败次数超过阅值，在应用程序能正确响应请求之前， 容器就会重启。

为了更好地进行存活检查， 需要将探针配置为请求特定的URL路径（例如 /health), 并让应用 从内部对内部运行的所有重要组件执行状态检查， 以确保它们都没有终止或停止响应。需要注意，/health HTTP站点不需要认证，否则会一直失败。

2.2 使用RC托管pod

2.2.1 ReplicationController

ReplicationController是一种Kubemetes资源，可确保它的pod始终保持运行状态。 如果pod因任何原因消失（例如节点从集群中消失或由于该pod已从节点中逐出），则ReplicationController 会注意到缺少了pod并创建替代pod。

控制器的协调流程：

一个ReplicationController有三个主要部分：

• label selector ( 标签选择器），用于确定ReplicationController作用域中有哪些 pod。
• replica count (副本个数），指定应运行的pod 数量。
• pod template (pod模板），用于创建新的pod 副本。

创建RC：

注意： RC是根据标签来选择自己管辖的Pod。

模板中的pod标签显然必须和ReplicationController的标签选择器匹配，使用 kubectl create 命令即可创建。

应对节点故障：

在发生节点故障后，Kubemetes会自动将pod迁移到其他机器。 在 ReplicationController检测到它的pod己关闭后不久， 它将启动新的pod以替换它们。

2.2.2 水平缩放Pod

放大或者缩小pod的数量规模就和在ReplicationController资源中更改Replicas 字段的值一样简单。

• 使用命令修改： kubectl scale re kubia --replicas=10
• 通过编辑定义的Yaml来缩放ReplicationController

2.2.3 删除RC

通过 kubectl delete 删除 ReplicationController 时， pod也会被删除。 但是由于由 ReplicationController 创建的 pod不是 ReplicationController 的组成部分， 只是由其进行管理， 因此可以只删除 ReplicationController 并保待 pod 运行 。

当使用 kubectl delete 删除 ReplicationController 时， 可以通过给命令增 加 --cascade= false 选项来保持 pod 的运行。

2.3 使用RS托管Pod

最初，ReplicationController 是用于复制和在异常时重新调度节点的唯 一 Kubemetes 组件， 后来又引入了 一个名为 ReplicaSet 的类似资源 。 它是新一代的 ReplicationController, 并且将其完全替换掉 (ReplicationController 最终将被弃用）。

2.3.1 比较RC 和RS

ReplicaSet的行为与ReplicationController完全相同，但pod选择器的表达能力更强。

举个例子，单个ReplicationController 无法将 pod与标签 env=production 和 env=devel 同时匹配。它只能匹配带有env=devel标签的 pod 或带有 env=devel 标签的 pod。 但是一个ReplicaSet可以匹配两组 pod 并将它们视为一个大组。而且RS可以只匹配key无论value的值是什么（可以理解为env = * )

定义RS

2.3.2 RS的标签选择器

可以给选择器添加额外的表达式。如示例，每个表达式都必须 包含一个key、 一个operator (运算符），并且可能还有一个values的列表（取决于 运算符）。

• In : Label的值 必须与其中 一个指定的values 匹配。

• Notln : Label的值与任何指定的values 不匹配。

• Exists : pod 必须包含一个指定名称的标签（值不重要）。使用此运算符时， 不应指定 values字段。

• DoesNotExist : pod不得包含有指定名称的标签。values属性不得指定 。 如果你 指定了多个表达式，则所有这些表达式都必须为true才能使选择器与 pod匹配。如果同时指定matchLabels和matchExpressions, 则所有标签都 必须匹配，并且所有表达式必须计算为true以使该pod与选择器匹配。

2.4 使用PodDamonSet 在每一个节点上运行一个

Replicationcontroller和ReplicaSet 都用于在Kubemetes集群上运行部署特定数量的pod。

**PodDamonSet 可以让Pod在集群中的每一个节点中运行，例如日志收集器，资源监控器等。 **

使用PodDamonSet

2.5 运行单个任务Pod

如果只想运行完成工作后就终止任务， ReplicationController、 ReplicaSet和DaemonSet会持续运行任 务，永远达不到完成态。 这些 pod 中的进程在退出时会重新启动。但是在一个可完成的任务中，其进程终止后，不应该再重新启动。

2.5.1 Job资源

Kubemetes 通过 Job 资源提供了对此的支持， 它允许你运行一种 pod, 该 pod 在内部进程成功结束时， 不重启容器。 一旦任务完成， pod 就被认为处千完成状态。

在发生节点故障时，该节点上由 Job管理的 pod将按照 ReplicaSet 的 pod 的方式， 重新安排到其他节点。 如果进程本身异常退出（进程返回错误退出代码时）， 可以将 Job 配置为重新启动容器。

job 对于临时任务很有用， 关键是任务要以正确的方式结束。 可以在未托管的 pod 中运行任务并等待它完成， 但是如果发生节点异常或 pod 在执行任务时 被从节点中逐出， 则需要手动重新创建该任务。 手动做这件事并不合理，特别是如果任务需要几个小时才能完成。

定义Job资源

同时Job支持顺序执行和并行执行：

顺序执行Job Pod ：

Job将一个接一个地运行五个pod。它最初创建一个pod, 当pod的容器运行完 成时，它创建第二个pod, 以此类推，直到五个pod成功完成。如果其中 一个pod 发生故障，工作会创建一个新的pod, 所以Job总共可以创建五个以上的pod。

并行执行Job Pod：

创建一个CronJob

2.6 总结：

• 使用存活探针，让Kubernetes在容器不健康的情况下立即重启它（应用程序定义了健康的条件）。
• 不应该直接创建pod , 因为如果它们被错误地删除，它们正在运行的节点异常， 或者它们从节点中被逐出时， 它们将不会被重新创建。
• ReplicationController始终保持所需数量的pod 副本正在运行。
• 水平缩放pod与在ReplicationController上更改所需的副本个数一样简单。
• pod不属于ReplicationController, 如有必要可以在它们之间移动 。
• ReplicationController 将从pod模板创建新的pod。更改模板对现有的pod 没有影响。
• ReplicationController 应该替换为 ReplicaSe t和Deployment, 它们提供相同的能力， 但具有额外的强大功能。
• ReplicationController 和 ReplicaSet 将 pod 安排到随机集群节点， 而 DaemonSet 确保每个节点都运行一个 DaemonSet 中定义的 pod 实例。
• 执行批处理任务的 pod 应通过 Kubernetes Job 资源创建， 而不是直接或通过 ReplicationController 或类似对象创建。
• 需要在未来某个时候运行的 Job 可以通过 CronJob 资源创建。