oauth2-proxy 的 /ping 与 /ready 健康检查端点有什么区别、怎么用于上线探活【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxyoauth2-proxy 是一个带身份认证的反向代理。把它部署到 Kubernetes、GCP 或自建服务器后面时编排器和负载均衡器都需要一个端点来判断这个进程还活着吗以及它现在能不能正常处理流量。oauth2-proxy 自身直接响应两个健康检查端点/ping和/ready二者回答的是不同的问题。本文基于项目文档说明两个端点的行为差异并给出用于上线探活的配置与验证方式。两个端点的行为差异根据 Endpoints 文档oauth2-proxy 会直接响应下列端点其余请求才会转发到上游/ping—— 返回 200 OK文档明确其用途是供健康检查使用basic health check。只要 oauth2-proxy 进程在运行访问它就能得到 200。/ready—— 只有当所有底层连接例如 Redis 会话存储都已连接时才返回 200 OK这是一个深度健康检查deep health check。从源码可以看清楚这条区分。ping 处理逻辑命中配置的路径后直接写回 200 和正文OK不检查任何外部依赖if isHealthCheckRequest(pathSet, userAgentSet, req) { rw.WriteHeader(http.StatusOK) fmt.Fprintf(rw, OK) return }而 ready 处理逻辑会先调用会话存储的VerifyConnection失败时返回 500 并输出错误信息if err : verifiable.VerifyConnection(req.Context()); err ! nil { rw.WriteHeader(http.StatusInternalServerError) fmt.Fprintf(rw, error: %v, err) return } rw.WriteHeader(http.StatusOK) fmt.Fprintf(rw, OK)VerifyConnection的实际实现决定了/ready检查的是什么Redis 存储的实现是对 Redis 发Ping即验证 redis 连接有效且服务器有响应而 cookie 会话存储没有外部连接其VerifyConnection直接返回成功见 cookie 存储实现。所以/ready是否严格取决于你使用的会话存储类型。对应到探活语义/ping适合做存活探针liveness进程活着即通过/ready适合做就绪探针readiness进程活着且依赖的连接可用才通过。需要说明文档对两个端点的描述是basic health checks和deep health checks上述与 liveness/readiness 的对应关系来自 oauthproxy.go 中 GCP 健康检查弃用警告的原文Reconfigure apps to use the ping path for liveness and readiness checks。用 curl 验证端点oauth2-proxy 默认监听127.0.0.1:4180配置项--http-address/http_address见 配置总览。在本机验证curl -i http://127.0.0.1:4180/ping curl -i http://127.0.0.1:4180/ready预期结果/ping始终返回200 OK正文为OK/ready底层存储可用时返回200 OK正文为OK连接失败时返回500正文形如error: 错误信息错误信息为VerifyConnection返回的具体错误。这两个端点不需要登录态不经过 OAuth 认证流程也不会被代理到上游可以直接被外部探测器访问。配置探活路径与访问方式相关配置项均在 配置总览 的 Server Options 中配置项说明默认值--ping-path/ping_path用于 basic 健康检查的 ping 端点路径/ping--ping-user-agent/ping_user_agent用于 basic 健康检查的 User-Agent不检查 User-Agent--ready-path/ready_path用于 deep 健康检查的 ready 端点路径/ready--http-address/http_addressHTTP 监听地址127.0.0.1:4180两点与上线探活直接相关监听地址要能被探测器访问到。默认127.0.0.1:4180只在本机可达。如果你的健康检查器宿主机上的 kubelet 之外的探测、外部负载均衡器健康检查等无法到达本机回环地址需要把--http-address调整为监听相应网卡例如--http-address 0.0.0.0:4180。用--ping-user-agent收紧访问。默认不检查 User-Agent。配合 ping 处理逻辑若配置了 User-Agent则只有请求路径命中 ping 路径、且请求的User-Agent头匹配时才返回 200否则请求继续交给后续处理。这可以避免你的健康端点被任意外部请求免费利用。GCP / GKE 的既有健康检查配置如果你的应用之前在 GCP/GKE 上依赖--gcp-healthchecks注意该选项已标记为弃用。启用时 oauth2-proxy 会打印如下警告见 oauthproxy.goWARNING: GCP HealthChecks are now deprecated: Reconfigure apps to use the ping path for liveness and readiness checks, set the ping user agent to GoogleHC/1.0 to preserve existing behaviour即迁移方式是把 GCP 健康检查指向 ping 路径并设置--ping-user-agent GoogleHC/1.0来保持原有行为GCP 健康检查器使用该 User-Agent。降低探活请求的日志噪音高频探活会灌满访问日志。/ping含通过--ping-user-agent命中的请求和/ready的日志记录可以通过--silence-ping-logging关闭--silence-ping-logging配置总览中的原文说明该项可disable logging of requests to ping ready endpoints从而减少日志量默认false。另外--exclude-logging-path也可以按路径排除日志例如/ping,/path2但专门针对这两个端点的开关是--silence-ping-logging。限制与边界文档和源码都只定义了通过时的 200/OK与/ready失败时的 500/error: ...没有给出超时阈值或重试建议探测频率、超时时间由你的编排器或负载均衡器自行决定oauth2-proxy 文档未涉及。/ready检查的对象是底层连接文档以 Redis 存储为例。使用 cookie 会话存储时没有外部连接可验证/ready的行为与进程存活检查无实质差别源码中该存储的VerifyConnection恒返回成功。/ping与/ready均由 oauth2-proxy 直接响应不经过认证与上游代理它们只反映代理本身及其会话存储连接的状态不代表上游应用可用。【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
oauth2-proxy 的 /ping 与 /ready 健康检查端点有什么区别、怎么用于上线探活？
oauth2-proxy 的 /ping 与 /ready 健康检查端点有什么区别、怎么用于上线探活【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxyoauth2-proxy 是一个带身份认证的反向代理。把它部署到 Kubernetes、GCP 或自建服务器后面时编排器和负载均衡器都需要一个端点来判断这个进程还活着吗以及它现在能不能正常处理流量。oauth2-proxy 自身直接响应两个健康检查端点/ping和/ready二者回答的是不同的问题。本文基于项目文档说明两个端点的行为差异并给出用于上线探活的配置与验证方式。两个端点的行为差异根据 Endpoints 文档oauth2-proxy 会直接响应下列端点其余请求才会转发到上游/ping—— 返回 200 OK文档明确其用途是供健康检查使用basic health check。只要 oauth2-proxy 进程在运行访问它就能得到 200。/ready—— 只有当所有底层连接例如 Redis 会话存储都已连接时才返回 200 OK这是一个深度健康检查deep health check。从源码可以看清楚这条区分。ping 处理逻辑命中配置的路径后直接写回 200 和正文OK不检查任何外部依赖if isHealthCheckRequest(pathSet, userAgentSet, req) { rw.WriteHeader(http.StatusOK) fmt.Fprintf(rw, OK) return }而 ready 处理逻辑会先调用会话存储的VerifyConnection失败时返回 500 并输出错误信息if err : verifiable.VerifyConnection(req.Context()); err ! nil { rw.WriteHeader(http.StatusInternalServerError) fmt.Fprintf(rw, error: %v, err) return } rw.WriteHeader(http.StatusOK) fmt.Fprintf(rw, OK)VerifyConnection的实际实现决定了/ready检查的是什么Redis 存储的实现是对 Redis 发Ping即验证 redis 连接有效且服务器有响应而 cookie 会话存储没有外部连接其VerifyConnection直接返回成功见 cookie 存储实现。所以/ready是否严格取决于你使用的会话存储类型。对应到探活语义/ping适合做存活探针liveness进程活着即通过/ready适合做就绪探针readiness进程活着且依赖的连接可用才通过。需要说明文档对两个端点的描述是basic health checks和deep health checks上述与 liveness/readiness 的对应关系来自 oauthproxy.go 中 GCP 健康检查弃用警告的原文Reconfigure apps to use the ping path for liveness and readiness checks。用 curl 验证端点oauth2-proxy 默认监听127.0.0.1:4180配置项--http-address/http_address见 配置总览。在本机验证curl -i http://127.0.0.1:4180/ping curl -i http://127.0.0.1:4180/ready预期结果/ping始终返回200 OK正文为OK/ready底层存储可用时返回200 OK正文为OK连接失败时返回500正文形如error: 错误信息错误信息为VerifyConnection返回的具体错误。这两个端点不需要登录态不经过 OAuth 认证流程也不会被代理到上游可以直接被外部探测器访问。配置探活路径与访问方式相关配置项均在 配置总览 的 Server Options 中配置项说明默认值--ping-path/ping_path用于 basic 健康检查的 ping 端点路径/ping--ping-user-agent/ping_user_agent用于 basic 健康检查的 User-Agent不检查 User-Agent--ready-path/ready_path用于 deep 健康检查的 ready 端点路径/ready--http-address/http_addressHTTP 监听地址127.0.0.1:4180两点与上线探活直接相关监听地址要能被探测器访问到。默认127.0.0.1:4180只在本机可达。如果你的健康检查器宿主机上的 kubelet 之外的探测、外部负载均衡器健康检查等无法到达本机回环地址需要把--http-address调整为监听相应网卡例如--http-address 0.0.0.0:4180。用--ping-user-agent收紧访问。默认不检查 User-Agent。配合 ping 处理逻辑若配置了 User-Agent则只有请求路径命中 ping 路径、且请求的User-Agent头匹配时才返回 200否则请求继续交给后续处理。这可以避免你的健康端点被任意外部请求免费利用。GCP / GKE 的既有健康检查配置如果你的应用之前在 GCP/GKE 上依赖--gcp-healthchecks注意该选项已标记为弃用。启用时 oauth2-proxy 会打印如下警告见 oauthproxy.goWARNING: GCP HealthChecks are now deprecated: Reconfigure apps to use the ping path for liveness and readiness checks, set the ping user agent to GoogleHC/1.0 to preserve existing behaviour即迁移方式是把 GCP 健康检查指向 ping 路径并设置--ping-user-agent GoogleHC/1.0来保持原有行为GCP 健康检查器使用该 User-Agent。降低探活请求的日志噪音高频探活会灌满访问日志。/ping含通过--ping-user-agent命中的请求和/ready的日志记录可以通过--silence-ping-logging关闭--silence-ping-logging配置总览中的原文说明该项可disable logging of requests to ping ready endpoints从而减少日志量默认false。另外--exclude-logging-path也可以按路径排除日志例如/ping,/path2但专门针对这两个端点的开关是--silence-ping-logging。限制与边界文档和源码都只定义了通过时的 200/OK与/ready失败时的 500/error: ...没有给出超时阈值或重试建议探测频率、超时时间由你的编排器或负载均衡器自行决定oauth2-proxy 文档未涉及。/ready检查的对象是底层连接文档以 Redis 存储为例。使用 cookie 会话存储时没有外部连接可验证/ready的行为与进程存活检查无实质差别源码中该存储的VerifyConnection恒返回成功。/ping与/ready均由 oauth2-proxy 直接响应不经过认证与上游代理它们只反映代理本身及其会话存储连接的状态不代表上游应用可用。【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考