云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载本指南以 docs/examples/app-with-probe 示例为主线讲解如何在 KubeVela 的 Application 中通过properties.livenessProbe声明组件存活探针验证应用是否健康运行。读完本文你将掌握httpGet/exec/tcpSocket三种探针的写法、#HealthProbe全部参数的默认值与含义、kubectl部署与排查方法并从 CUE 组件模板与控制器测试源码层面理解 KubeVela 如何将探针声明渲染到 Kubernetes Pod 中。场景与前置条件探针Probe是 Kubernetes 保障在线服务可用性的核心机制kubelet 周期性对容器发起检查一旦 liveness 探针连续失败kubelet 就会按restartPolicy重启容器。KubeVela 作为应用交付平台把这一能力以声明式参数的形式暴露在 Application 的组件properties中用户无需直接编写 Deployment YAML 即可配置探针。开始前需要满足两个前提可以访问一个 Kubernetes 集群远程集群或本地kind、minikube均可已经安装 KubeVela安装方式可参考 charts/vela-core 及 references/cli/install.go 中的 CLI 安装流程。示例应用在 Application 中声明 livenessProbe仓库中的示例文件 app-with-probe.yaml 完整内容如下apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-website spec: components: - name: frontend type: webservice properties: image: oamdev/testapp:v1 cmd: [node, server.js] port: 8080 livenessProbe: httpGet: path: / port: 8080这是一个标准的core.oam.dev/v1beta1类型 Application包含一个名为frontend的webservice组件。其中与本文主题直接相关的关键字段是properties下的livenessProbepath健康检查路径对应你的 Web 服务器暴露的健康端点这里为根路径/port服务器监听的端口这里为8080。livenessProbe告诉 KubeVela请周期性地对frontend容器的http://:8080/发起 HTTP GET 请求只要请求成功返回即认为容器存活。三种探针方式与 #HealthProbe 参数全解示例使用的是httpGet方式这是 Web 服务最常用的探测方法。除此之外KubeVela 的webservice组件还支持exec与tcpSocket两种方式三者互斥必须且只能指定其一。从 webservice.cue 的定义可以看到完整的#HealthProbe结构该组件模板由 charts/vela-core/templates/defwithtemplate/webservice.yaml 打包下发到集群参数类型默认值说明exec对象无在容器内执行命令判断健康状态命令以空格分词组成数组退出码 0 视为成功其余视为失败httpGet对象无通过 HTTP GET 请求判断健康状态需指定path端点路径、port端口可选host、scheme默认HTTP、httpHeaderstcpSocket对象无通过探测 TCP 端口是否可连接判断健康状态需指定portinitialDelaySecondsint0容器启动后延迟多少秒才开始第一次探测periodSecondsint10每隔多少秒执行一次探测timeoutSecondsint1探测超时秒数超时视为失败successThresholdint1连续成功多少次才认为探针从失败转为成功failureThresholdint3连续失败多少次判定容器不存活liveness或未就绪readinessexec 方式示例对于无法暴露 HTTP 端口的进程可以用命令方式探测livenessProbe: exec: command: [cat, /tmp/healthy]tcpSocket 方式示例对纯 TCP 服务如数据库、消息队列用端口连通性探测livenessProbe: tcpSocket: port: 6379httpGet 高级用法httpGet还支持scheme、host、httpHeaders例如探测 HTTPS 端点readinessProbe: httpGet: path: /v1/health port: 8080 scheme: HTTPS httpHeaders: - name: Authorization value: Bearer xxx部署应用并检查状态将示例文件应用到集群kubectl apply -f app-with-probe.yamlKubeVela 控制器会把 Application 渲染为 Kubernetes 原生资源Deployment、Pod 等。查看 Pod 状态$ kubectl get pod NAME READY STATUS RESTARTS AGE frontend-86bc89d8f5-xgrnc 1/1 Running 0 18s再通过describe观察探针的实际配置$ kubectl describe pod frontend-86bc89d8f5-xgrnc ... Liveness: http-get http://:8080/ delay0s timeout1s period10s #success1 #failure3 ...(other information)输出中的关键信息与 Application 声明一一对应http-get http://:8080/对应httpGet.path/与httpGet.port8080delay0s对应initialDelaySeconds默认值 0timeout1s、period10s、#success1、#failure3分别对应timeoutSeconds、periodSeconds、successThreshold、failureThreshold的默认值见 webservice.cue。当探针连续 3 次failureThreshold探测失败时kubelet 会判定容器不再存活并自动重启它——这正是livenessProbe的自愈价值所在RESTARTS 列会随之增长。原理纵深探针参数如何渲染到 Pod从源码结构看探针能力的底层实现非常直观在 webservice.cue 中组件模板通过 CUE 条件渲染把参数透传到 Deployment 的容器字段if parameter[livenessProbe] ! _|_ { livenessProbe: parameter.livenessProbe } if parameter[readinessProbe] ! _|_ { readinessProbe: parameter.readinessProbe }也就是说webservice组件底层渲染为apps/v1Deployment见 webservice.cue将用户声明的livenessProbe/readinessProbe原样映射为 Pod 容器规格的对应字段随后由 KubeVela 资源调度器下发到集群最终由 kubelet 执行。整个链路为Application → 组件 CUE 模板渲染 → Deployment → Pod → kubelet 探针执行 → 失败自动重启。因此 app-with-probe.yaml 中 3 行探针声明等价于手写 Deployment 中数十行的livenessProbe配置且默认值由组件模板统一管理降低了用户心智负担。更多探针能力readinessProbe 与 startup-probe traitreadinessProbe就绪探针除 liveness 外webservice组件同样支持readinessProbe用于判断容器是否已准备好接收流量。它与 liveness 的参数结构完全相同同样基于#HealthProbe区别仅在语义readiness 失败不会重启容器只会把 Pod 从 Service 的 Endpoints 中摘除。startup-probe trait启动探针对于启动缓慢的应用如 JVM 应用KubeVela 还提供了独立的startup-probe内置 trait定义见 startup-probe.cue。它在#HealthProbe基础上额外支持containerName指定目标容器名不设置时默认为组件名terminationGracePeriodSeconds探针失败后优雅终止的宽限秒数grpc通过 gRPC HealthCheckRequest 探测probes为多容器场景批量指定探针。该 trait 通过podDisruptive: true与appliesToWorkloads: [deployments.apps, statefulsets.apps, daemonsets.apps, jobs.batch]声明适用负载类型见 startup-probe.cue可作为 trait 追加到组件上。其他支持探针的组件类型除webservice外仓库内置的 statefulset.cue、daemon.cue、cron-task.cue、task.cue、worker.cue 均定义了livenessProbe?: #HealthProbe与readinessProbe?: #HealthProbe参数使用方式与webservice完全一致。源码级验证控制器测试中的探针用例仓库控制器测试 application_controller_test.go 中构造了一个携带完整探针配置的 Application其livenessProbe包含failureThreshold: 3、httpGet.path: /v1/health、httpGet.port: 8080、httpGet.scheme: HTTP、initialDelaySeconds: 60、periodSeconds: 60、successThreshold: 1、timeoutSeconds: 5覆盖了#HealthProbe的全部字段同文件 application_controller_test.go 还有 test application with healthProbe which use https 用例验证 HTTPS 探针场景。这些用例证明探针参数从 Application 到 Pod 规格的完整渲染链路是经过端到端验证的读者可据此编写自己的探针配置。实践建议与注意事项三种探针各司其职启动慢的服务先用startup-probe放行再配livenessProbe兜底重启最后用readinessProbe控制流量接入不要用 liveness 承担 readiness 的职责避免因瞬时高负载误杀容器。合理设置阈值failureThreshold默认 3、timeoutSeconds默认 1s对延迟敏感的调用链可适当调大timeoutSeconds与periodSeconds避免误判。探测路径要轻量健康端点应只反映进程可用性避免在探针路径中执行重查询或依赖外部服务否则会放大抖动。通过kubectl describe pod校验部署后务必观察describe输出中的Liveness/Readiness/Startup行确认参数与声明一致参考上文示例输出。借助 KubeVela 的声明式探针能力你可以把容器健康管理收敛到 Application 这一个交付入口中让应用是否存活、何时自动重启成为可审计、可版本化的配置而非散落在裸 Deployment 中的零散字段。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐为什么选择YPrompt5大优势助你生成高质量AI提示词为什么选择YPrompt5大优势助你生成高质量AI提示词 YPrompt是一款强大的AI提示词生成与优化工具通过对话挖掘用户需求自动生成专业提示词支持系eogee/any4any服务健康检查存活探针与就绪探针配置eogee/any4any服务健康检查存活探针与就绪探针配置 在微服务架构中服务的可靠性直接决定了系统的稳定性。any4any作为集成语音识别、文本转语音、人工智能大模型模型推理服务RAG语音数字人音视频后端MCP服务Sealos容器健康检查存活探针与就绪探针最佳配置Sealos容器健康检查存活探针与就绪探针最佳配置 容器健康检查的关键价值 在KubernetesK8s集群管理中容器健康检查是保障应用高可用性的核心机云原生后端前端微服务容器编排AI 应用上一篇jcalaBlog写作体验基于Editor.md的Markdown编辑器完整使用指南下一篇桌面效率革命GeekDesk极客启动器重塑你的工作方式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KubeVela 应用健康探针（livenessProbe/readinessProbe）实战：用 Application 声明组件存活检测与自动重启
云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载本指南以 docs/examples/app-with-probe 示例为主线讲解如何在 KubeVela 的 Application 中通过properties.livenessProbe声明组件存活探针验证应用是否健康运行。读完本文你将掌握httpGet/exec/tcpSocket三种探针的写法、#HealthProbe全部参数的默认值与含义、kubectl部署与排查方法并从 CUE 组件模板与控制器测试源码层面理解 KubeVela 如何将探针声明渲染到 Kubernetes Pod 中。场景与前置条件探针Probe是 Kubernetes 保障在线服务可用性的核心机制kubelet 周期性对容器发起检查一旦 liveness 探针连续失败kubelet 就会按restartPolicy重启容器。KubeVela 作为应用交付平台把这一能力以声明式参数的形式暴露在 Application 的组件properties中用户无需直接编写 Deployment YAML 即可配置探针。开始前需要满足两个前提可以访问一个 Kubernetes 集群远程集群或本地kind、minikube均可已经安装 KubeVela安装方式可参考 charts/vela-core 及 references/cli/install.go 中的 CLI 安装流程。示例应用在 Application 中声明 livenessProbe仓库中的示例文件 app-with-probe.yaml 完整内容如下apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-website spec: components: - name: frontend type: webservice properties: image: oamdev/testapp:v1 cmd: [node, server.js] port: 8080 livenessProbe: httpGet: path: / port: 8080这是一个标准的core.oam.dev/v1beta1类型 Application包含一个名为frontend的webservice组件。其中与本文主题直接相关的关键字段是properties下的livenessProbepath健康检查路径对应你的 Web 服务器暴露的健康端点这里为根路径/port服务器监听的端口这里为8080。livenessProbe告诉 KubeVela请周期性地对frontend容器的http://:8080/发起 HTTP GET 请求只要请求成功返回即认为容器存活。三种探针方式与 #HealthProbe 参数全解示例使用的是httpGet方式这是 Web 服务最常用的探测方法。除此之外KubeVela 的webservice组件还支持exec与tcpSocket两种方式三者互斥必须且只能指定其一。从 webservice.cue 的定义可以看到完整的#HealthProbe结构该组件模板由 charts/vela-core/templates/defwithtemplate/webservice.yaml 打包下发到集群参数类型默认值说明exec对象无在容器内执行命令判断健康状态命令以空格分词组成数组退出码 0 视为成功其余视为失败httpGet对象无通过 HTTP GET 请求判断健康状态需指定path端点路径、port端口可选host、scheme默认HTTP、httpHeaderstcpSocket对象无通过探测 TCP 端口是否可连接判断健康状态需指定portinitialDelaySecondsint0容器启动后延迟多少秒才开始第一次探测periodSecondsint10每隔多少秒执行一次探测timeoutSecondsint1探测超时秒数超时视为失败successThresholdint1连续成功多少次才认为探针从失败转为成功failureThresholdint3连续失败多少次判定容器不存活liveness或未就绪readinessexec 方式示例对于无法暴露 HTTP 端口的进程可以用命令方式探测livenessProbe: exec: command: [cat, /tmp/healthy]tcpSocket 方式示例对纯 TCP 服务如数据库、消息队列用端口连通性探测livenessProbe: tcpSocket: port: 6379httpGet 高级用法httpGet还支持scheme、host、httpHeaders例如探测 HTTPS 端点readinessProbe: httpGet: path: /v1/health port: 8080 scheme: HTTPS httpHeaders: - name: Authorization value: Bearer xxx部署应用并检查状态将示例文件应用到集群kubectl apply -f app-with-probe.yamlKubeVela 控制器会把 Application 渲染为 Kubernetes 原生资源Deployment、Pod 等。查看 Pod 状态$ kubectl get pod NAME READY STATUS RESTARTS AGE frontend-86bc89d8f5-xgrnc 1/1 Running 0 18s再通过describe观察探针的实际配置$ kubectl describe pod frontend-86bc89d8f5-xgrnc ... Liveness: http-get http://:8080/ delay0s timeout1s period10s #success1 #failure3 ...(other information)输出中的关键信息与 Application 声明一一对应http-get http://:8080/对应httpGet.path/与httpGet.port8080delay0s对应initialDelaySeconds默认值 0timeout1s、period10s、#success1、#failure3分别对应timeoutSeconds、periodSeconds、successThreshold、failureThreshold的默认值见 webservice.cue。当探针连续 3 次failureThreshold探测失败时kubelet 会判定容器不再存活并自动重启它——这正是livenessProbe的自愈价值所在RESTARTS 列会随之增长。原理纵深探针参数如何渲染到 Pod从源码结构看探针能力的底层实现非常直观在 webservice.cue 中组件模板通过 CUE 条件渲染把参数透传到 Deployment 的容器字段if parameter[livenessProbe] ! _|_ { livenessProbe: parameter.livenessProbe } if parameter[readinessProbe] ! _|_ { readinessProbe: parameter.readinessProbe }也就是说webservice组件底层渲染为apps/v1Deployment见 webservice.cue将用户声明的livenessProbe/readinessProbe原样映射为 Pod 容器规格的对应字段随后由 KubeVela 资源调度器下发到集群最终由 kubelet 执行。整个链路为Application → 组件 CUE 模板渲染 → Deployment → Pod → kubelet 探针执行 → 失败自动重启。因此 app-with-probe.yaml 中 3 行探针声明等价于手写 Deployment 中数十行的livenessProbe配置且默认值由组件模板统一管理降低了用户心智负担。更多探针能力readinessProbe 与 startup-probe traitreadinessProbe就绪探针除 liveness 外webservice组件同样支持readinessProbe用于判断容器是否已准备好接收流量。它与 liveness 的参数结构完全相同同样基于#HealthProbe区别仅在语义readiness 失败不会重启容器只会把 Pod 从 Service 的 Endpoints 中摘除。startup-probe trait启动探针对于启动缓慢的应用如 JVM 应用KubeVela 还提供了独立的startup-probe内置 trait定义见 startup-probe.cue。它在#HealthProbe基础上额外支持containerName指定目标容器名不设置时默认为组件名terminationGracePeriodSeconds探针失败后优雅终止的宽限秒数grpc通过 gRPC HealthCheckRequest 探测probes为多容器场景批量指定探针。该 trait 通过podDisruptive: true与appliesToWorkloads: [deployments.apps, statefulsets.apps, daemonsets.apps, jobs.batch]声明适用负载类型见 startup-probe.cue可作为 trait 追加到组件上。其他支持探针的组件类型除webservice外仓库内置的 statefulset.cue、daemon.cue、cron-task.cue、task.cue、worker.cue 均定义了livenessProbe?: #HealthProbe与readinessProbe?: #HealthProbe参数使用方式与webservice完全一致。源码级验证控制器测试中的探针用例仓库控制器测试 application_controller_test.go 中构造了一个携带完整探针配置的 Application其livenessProbe包含failureThreshold: 3、httpGet.path: /v1/health、httpGet.port: 8080、httpGet.scheme: HTTP、initialDelaySeconds: 60、periodSeconds: 60、successThreshold: 1、timeoutSeconds: 5覆盖了#HealthProbe的全部字段同文件 application_controller_test.go 还有 test application with healthProbe which use https 用例验证 HTTPS 探针场景。这些用例证明探针参数从 Application 到 Pod 规格的完整渲染链路是经过端到端验证的读者可据此编写自己的探针配置。实践建议与注意事项三种探针各司其职启动慢的服务先用startup-probe放行再配livenessProbe兜底重启最后用readinessProbe控制流量接入不要用 liveness 承担 readiness 的职责避免因瞬时高负载误杀容器。合理设置阈值failureThreshold默认 3、timeoutSeconds默认 1s对延迟敏感的调用链可适当调大timeoutSeconds与periodSeconds避免误判。探测路径要轻量健康端点应只反映进程可用性避免在探针路径中执行重查询或依赖外部服务否则会放大抖动。通过kubectl describe pod校验部署后务必观察describe输出中的Liveness/Readiness/Startup行确认参数与声明一致参考上文示例输出。借助 KubeVela 的声明式探针能力你可以把容器健康管理收敛到 Application 这一个交付入口中让应用是否存活、何时自动重启成为可审计、可版本化的配置而非散落在裸 Deployment 中的零散字段。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐为什么选择YPrompt5大优势助你生成高质量AI提示词为什么选择YPrompt5大优势助你生成高质量AI提示词 YPrompt是一款强大的AI提示词生成与优化工具通过对话挖掘用户需求自动生成专业提示词支持系eogee/any4any服务健康检查存活探针与就绪探针配置eogee/any4any服务健康检查存活探针与就绪探针配置 在微服务架构中服务的可靠性直接决定了系统的稳定性。any4any作为集成语音识别、文本转语音、人工智能大模型模型推理服务RAG语音数字人音视频后端MCP服务Sealos容器健康检查存活探针与就绪探针最佳配置Sealos容器健康检查存活探针与就绪探针最佳配置 容器健康检查的关键价值 在KubernetesK8s集群管理中容器健康检查是保障应用高可用性的核心机云原生后端前端微服务容器编排AI 应用上一篇jcalaBlog写作体验基于Editor.md的Markdown编辑器完整使用指南下一篇桌面效率革命GeekDesk极客启动器重塑你的工作方式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考