引言

在K8s环境中，由于就绪检查设置不合理的问题，导致出现网关不可用的情况。

本文将详细探讨这个问题的原因，并提供一些解决方案，帮助有需要的同学解决类似的问题。

注：网关使用 spring-cloud-gateway

问题描述

描述

• 经用户反馈，进入小程序，首页空白一片，无商品数据展示。
• 研发收到反馈，进入小程序进行验证，发现小程序可正常使用。
• 这个过程大概有3分钟，过程中，一名前端同学通过抓包，发现部分API接口报503错误。

分析

• 这个问题就很诡异，从问题发生到自愈，没有做任何操作，自动就好了。
• 由于发现部分接口报503错误，所以直觉判断是网关有问题，因为从网关入手去分析。
• 通过告警信息，以及k8s事件日志，排查发现问题真的是出在网关上，具体原因见下。

问题原因

表象原因

• 通过k8s日志发现，网关触发了就绪检查的限制，将网关pod标记为不可用，导致用户请求报503错误。

根本原因

• 目前分析下来，大概率是k8s平台内部网络抖动等未知因素引起，但由于k8s底层无详细日志，暂无法继续往下深挖

问题原因分析

什么是就绪检查？

• 就绪检查，是一个用于验证应用程序是否准备就绪的机制。
• 当我们在K8s集群中部署网关时，我们希望确保该网关的所有依赖组件都已经准备就绪，然后才将流量引导到它。这个过程可以通过就绪检查来实现。
• 通常，就绪检查是通过在K8s的Pod配置中，定义一系列命令或HTTP请求来完成的。当这些命令或请求成功返回时，K8s会将该Pod标记为就绪。

就绪检查失败的可能原因？

• 就绪检查的超时设置不合理：如果就绪检查的超时时间设置得过短，而出现网络不稳定等未知情况，那么可能会出现超时的情况，导致就绪检查失败。
• 就绪检查的命令或请求有误：就绪检查的命令或请求可能存在错误，无法正确判断依赖组件是否准备就绪。
• 网关依赖组件的准备时间过长：如果网关所依赖的其他组件启动时间过长，超过了就绪检查的超时设置，就会导致就绪检查失败。

解决方案

通用方案

为了解决K8s 就绪检查 导致网关不可用的问题，我们可以采取以下措施：

调整就绪检查的超时设置：

• 通过适当增加就绪检查的超时时间，确保其能容纳依赖组件启动所需的时间。
• 这样可以防止就绪检查在依赖组件准备就绪之前失败。

优化就绪检查的命令或请求：

• 仔细检查就绪检查的命令或请求，并确保其正确性和可靠性。
• 确保命令或请求能够准确地判断依赖组件是否已经准备就绪。如果存在问题，及时修复并重新部署网关。

并行启动依赖组件：

• 如果网关所依赖的组件启动时间较长，可以考虑并行启动这些组件，以缩短整体的启动时间。

使用就绪探针：

• K8s提供了就绪探针（Readiness Probe）机制，可以用于检查应用程序是否准备就绪。
• 就绪探针是一种主动探测机制，可以定期发送请求或执行命令来验证应用程序的可用性。
• 与就绪检查不同，就绪探针不会导致Pod被标记为不可用，而只是在应用程序未准备就绪时暂停流量转发。
• 通过合理配置就绪探针，可以更灵活地控制网关的可用性。

实际改动

旧的健康检查机制

• 请求health接口，每10s检查一次，连续3次失败，1s超时，则将pod标记为不可用

新的健康检查机制

• 请求health接口，每10s检查一次，**连续6次失败，2s超时**，则将pod标记为不可用

结论

Kubernetes就绪检查，是确保应用程序在流量流入前，已经准备就绪的重要机制。

然而，不正确的配置或使用可能导致网关不可用的问题。

作为架构师和开发人员，在设计和部署Kubernetes环境时，应密切关注就绪检查的配置，以避免类似问题的发生。