云平台将故障Pod流量下线通用思路与OpenShift操作实战云平台将故障Pod流量下线通用

文章图片

1 写在前边自从公司项目前年上了 OpenShift 3.9 私有云平台，更新部署程序的确变得更加容易了。但是带来了很多复杂性，运维实施人员的学习曲线也陡然上升。
上云之前：在项目没上容器云的早期，应用服务集群往往是由一个Nginx作为负载均衡器，当有集群中有一个节点出现故障时，只需要将 Nginx 上负载均衡块 upstream 块中的故障节点地址移除，刷新 Nginx 即可达到快速响应，也能慢慢收集性能指标进行分析。

文章图片

上云之后：在云上部署应用，应用容器生命周期由 Deployment 管理，多实例集群由 Service 负载流量（本文暂时不谈服务网格）。当应用集群中某个Pod出现故障，通过 Deployment 或 Service 并不能直接把某个 Pod 从流量负载中移出，使用存活探针的话基本没办法收集性能指标。（以下是k8s部署简图）

文章图片

就绪探针：能从流量中移出无响应 Pod，但是会受到应用检测健康的接口准确程度限制，比如，开发了一个请求立即返回接口供就绪探针检测使用，那么应用服务哪怕有一点点处理能力，就绪检测就是通过的，此时表现在客户面前，应用可能会非常卡顿。
存活探针：流量中移除无响应Pod，并重建或重启 Pod。
注：合理地配置就绪探针与存活探针有助于自动解决服务的绝大部分问题。但是，就绪探针的接口是否有用完全取决于程序员（如果只是立即返回，可以说用处不算大，最佳实践是探测服务的内部状态给出合适的响应），存活探针仅适用于某些重启就能解决的特殊情况（当由于应用程序的bug导致的无响应，而有 bug 的功能一直被调用，则 Pod 将一直重启，存活探针的作用就不大了，不如保留现场收集性能指标供程序员解决问题）。

本文目标：给出云平台将故障Pod流量下线通用思路，以及 OpenShift 平台将故障 Pod 流量下线，确保有收集性能指标的机会。相信本文对其他基于 k8s 的云平台也有一定参考价值。
2 梳理思路一般来讲，Pod 的多副本的流量直接来源是 Service。当应用不可用时，我们需要保留故障 Pod，最简单的办法是只配置就绪探针，但是就绪检测接口无法确保服务的确是就绪状态，那就需要人工介入了。
流量从哪里来？
对于 Pod 而言，流量来自于 Service。初学 K8s 时，都会看到类似下边的图，大意是 Service 是通过 Selector 配置的 Label 来匹配 Pod 的。

文章图片

那么，Service 直接连接到了 Pod 上么？
这样说并不准确，Service 与 Pod 中间还有一种资源 —— Endpoints，Service 通过 Selector 将匹配到的 IP 地址和端口列表存入 Endpoints。也就是说，当流量到达网络代理（KubeProxy）时，网络代理会从众多 Endpoints 中找出目标 Endpoints 并取出其中一个地址进行转发。
所以，流量能进入 Pod 是因为 Service 的 Selector 匹配到了相同 Label 的 Pod。
如果我修改了故障 Pod 的 Label，不就是可以流量下线了吗？理论可行，开始实践。
3 基于 OpenShift 实践下线故障 Pod 我们的主要目标是将故障 Pod 从流量中移除，所以可以先看看 Service 以哪个 Label 匹配 Pod。
这里以我测试环境的程序举例，通过 Deployment 处的 Actions - Edit Yaml 打开如下界面：

文章图片

可以看到 selector 选择的 Label 为 deloymentConfig: bi，这样我们就能确认 Pod 必须也有这个标签，那么我们去修改故障节点。
退出编辑 yaml 界面，可以看到该 Service 对应的 Pod 列表，这里以 bi-4-7dt6r 作为故障节点演示，点击 bi-4-7dt6r。