容器显示不健康如何处理 容器失效模式

21. 简述 Kubernetes 中 Pod 的重启策略？

答：Pod 重启策略（RestartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 RestartPolicy 的设置来进行相应操作。Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。

• Always：当容器失效时，由 kubelet 自动重启该容器；
• OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器；
• Never：不论容器运行状态如何，kubelet 都不会重启该容器。

同时 Pod 的重启策略与控制方式关联，当前可用于管理 Pod 的控制器包括
ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（静态 Pod）。
不同控制器的重启策略限制如下：

• RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行；
• Job：OnFailure 或 Never，确保容器执行完成后不再重启；
• kubelet：在 Pod 失效时重启，不论将 RestartPolicy 设置为何值，也不会对 Pod进行健康检查。

22. 简述 Kubernetes 中 Pod 的健康检查方式？

答：对 Pod 的健康检查可以通过两类探针来检查：LivenessProbe 和ReadinessProbe。

• LivenessProbe 探针：用于判断容器是否存活（running 状态），如果LivenessProbe 探针探测到容器不健康，则 kubelet 将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针，kubelet 认为该容器的 LivenessProbe 探针返回值用于是“Success”。
• ReadineeProbe 探针：用于判断容器是否启动完成（ready 状态）。如果ReadinessProbe 探针探测到失败，则 Pod 的状态将被修改。EndpointController 将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 Eenpoint。
• startupProbe 探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针 kill 掉。

23. 简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式？

答：kubelet 定期执行 LivenessProbe 探针来诊断容器的健康状态，通常有以下三种
方式：

• ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器健康。
• TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP连接，则表明容器健康。
• HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响应的状态码大于等于 200 且小于 400，则表明容器健康。

24. 简述 Kubernetes Pod 的常见调度方式？

答：Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式：

• Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
• NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。
• NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前有两种节点亲和力表达：
• requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。
• preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。
• Taints 和 Tolerations（污点和容忍）：
• Taint：使 Node 拒绝特定 Pod 运行；
• Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。

25. 简述 Kubernetes 初始化容器（init container）？

答：init container 的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个 init container 时，将按顺序逐个运行，并且只有前一个 init container 运行成功后才能运行后一个 init container。当所有 init container 都成功运行后，Kubernetes 才会初始化 Pod 的各种信息，并开始创建和运行应用容器。

26. 简述 Kubernetes deployment 升级过程？

答：

• 初始创建 Deployment 时，系统创建了一个 ReplicaSet，并按用户的需求创建了对应数量的 Pod 副本。
• 当更新 Deployment 时，系统创建了一个新的 ReplicaSet，并将其副本数量扩展到 1，然后将旧 ReplicaSet 缩减为 2。
• 之后，系统继续按照相同的更新策略对新旧两个 ReplicaSet 进行逐个调整。
• 最后，新的 ReplicaSet 运行了对应个新版本 Pod 副本，旧的 ReplicaSet 副本数量则缩减为 0。

27. 简述 Kubernetes deployment 升级策略？

答：
在 Deployment 的定义中，可以通过 spec.strategy 指定 Pod 更新的策略，目前支持两种策略：Recreate（重建）和 RollingUpdate（滚动更新），默认值为RollingUpdate。

• Recreate：设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod时，会先杀掉所有正在运行的 Pod，然后创建新的 Pod。
• RollingUpdate：设置 spec.strategy.type=RollingUpdate，表示 Deployment会以滚动更新的方式来逐个更新 Pod。同时，可以通过设置spec.strategy.rollingUpdate 下的两个参数（maxUnavailable 和 maxSurge）来控制滚动更新的过程。

28. 简述 Kubernetes DaemonSet 类型的资源特性？

答：DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行，并且每个节点只能运行一个 pod，这是它和 deployment 资源对象的最大也是唯一的区别。因此，在定义 yaml 文件中，不支持定义 replicas。
它的一般使用场景如下：

• 在去做每个节点的日志收集工作。
• 监控每个节点的的运行状态。

29. 简述 Kubernetes 自动扩容机制？

答：Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器实现基于 CPU使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能指标，并与 HPA 资源对象中的扩缩容条件进行对比，在满足条件时对 Pod 副本数量进行调整。

• HPA 原理
  Kubernetes 中的某个 Metrics Server（Heapster 或自定义 Metrics Server）持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API（Heapster 的API 或聚合 API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod 副本数量。

当目标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器（Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。

30. 简述 Kubernetes Service 类型？

答：通过创建 Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。其主要类型有：

• ClusterIP：虚拟的服务 IP 地址，该地址用于 Kubernetes 集群内部的 Pod 访问，在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发；
• NodePort：使用宿主机的端口，使能够访问各 Node 的外部客户端通过 Node的 IP 地址和端口号就能访问服务；
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址，通常用于公有云。