企业官网建设流程全解析

• 云原生
• DevOps
• 运维
• 微服务

本指南以 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 即可配置探针。

开始前需要满足两个前提：

1. 可以访问一个 Kubernetes 集群（远程集群，或本地kind、minikube均可）；
2. 已经安装 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下的livenessProbe：

• path：健康检查路径，对应你的 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 方式示例

对于无法暴露 HTTP 端口的进程，可以用命令方式探测：

livenessProbe: exec: command: ["cat", "/tmp/healthy"]

tcpSocket 方式示例

对纯 TCP 服务（如数据库、消息队列）用端口连通性探测：

livenessProbe: tcpSocket: port: 6379

httpGet 高级用法

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.yaml

KubeVela 控制器会把 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/ delay=0s timeout=1s period=10s #success=1 #failure=3 ...(other information)

输出中的关键信息与 Application 声明一一对应：http-get http://:8080/对应httpGet.path=/与httpGet.port=8080；delay=0s对应initialDelaySeconds默认值 0；timeout=1s、period=10s、#success=1、#failure=3分别对应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 trait

readinessProbe：就绪探针

除 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
• 运维
• 微服务