如何将云平台故障Pod流量下线通用思路与OpenShift操作实战结合应用？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2345个文字，预计阅读时间需要10分钟。
“1+ 前言：自从公司项目前年上OpenShift 3.9 私有云平台，更新部署程序的变更得更加容易了。但这带来了许多复杂性，运维人员的学习曲线也相应上升。+ 云前：在项目未上云前，‘‘
1 写在前边自从公司项目前年上了 OpenShift 3.9 私有云平台，更新部署程序的确变得更加容易了。但是带来了很多复杂性，运维实施人员的学习曲线也陡然上升。
上云之前：在项目没上容器云的早期，应用服务集群往往是由一个 Nginx 作为负载均衡器，当有集群中有一个节点出现故障时，只需要将 Nginx 上负载均衡块 upstream 块中的故障节点地址移除，刷新 Nginx 即可达到快速响应，也能慢慢收集性能指标进行分析。
上云之后：在云上部署应用，应用容器生命周期由 Deployment 管理，多实例集群由 Service 负载流量 （本文暂时不谈服务网格）。当应用集群中某个Pod出现故障，通过 Deployment 或 Service 并不能直接把某个 Pod 从流量负载中移出，使用存活探针没办法收集性能指标（Pod 自动重启或重建），使用就绪探针需要开发可靠的就绪检测接口（严重依赖程序员）。以下是k8s部署简图
就绪探针：能从流量中移出无响应 Pod，严重依赖检测健康的接口可靠度。
存活探针：流量中移除无响应Pod，并重建或重启 Pod。
本文共计2345个文字，预计阅读时间需要10分钟。
“1+ 前言：自从公司项目前年上OpenShift 3.9 私有云平台，更新部署程序的变更得更加容易了。但这带来了许多复杂性，运维人员的学习曲线也相应上升。+ 云前：在项目未上云前，‘‘
1 写在前边自从公司项目前年上了 OpenShift 3.9 私有云平台，更新部署程序的确变得更加容易了。但是带来了很多复杂性，运维实施人员的学习曲线也陡然上升。
上云之前：在项目没上容器云的早期，应用服务集群往往是由一个 Nginx 作为负载均衡器，当有集群中有一个节点出现故障时，只需要将 Nginx 上负载均衡块 upstream 块中的故障节点地址移除，刷新 Nginx 即可达到快速响应，也能慢慢收集性能指标进行分析。
上云之后：在云上部署应用，应用容器生命周期由 Deployment 管理，多实例集群由 Service 负载流量 （本文暂时不谈服务网格）。当应用集群中某个Pod出现故障，通过 Deployment 或 Service 并不能直接把某个 Pod 从流量负载中移出，使用存活探针没办法收集性能指标（Pod 自动重启或重建），使用就绪探针需要开发可靠的就绪检测接口（严重依赖程序员）。以下是k8s部署简图
就绪探针：能从流量中移出无响应 Pod，严重依赖检测健康的接口可靠度。
存活探针：流量中移除无响应Pod，并重建或重启 Pod。