Kuberhealthy：把持续驗證封装成 Kubernetes HealthCheck
一個 Kubernetes 操作符，用於作為 pod 運行綜合檢查。與普羅米修斯配合得很好！
秒懂
- 它是什麼？
- Kuberhealthy 用控制器按计划启动短生命周期检查 Pod，并通过状态界面、JSON API 与 Prometheus 暴露结果。
- 適合誰用？
- 它适合已经使用 Kubernetes、希望把 API 烟测或多步骤业务驗證写进清单和發布流程的团队，不适合只需要主机级指标的场景。先在隔离命名空间执行 Helm 安裝，创建一个有明确超时的 HealthCheck，再同时查看 kubectl 状态、/json 和 /metrics 是否一致。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月14日）與我們的分析，不構成法律意見。
開源專案深度解析
Kuberhealthy 的工作方式 · kuberhealthy-kuberhealthy-deep-analysis
Kuberhealthy 是一个用于合成监控和持续驗證的 Kubernetes 操作器。它调度、跟踪、监控并管理用于检查的 Kubernetes Pod。该倉庫定义了 HealthCheck 自定义资源；每个 HealthCheck 指示控制器按计划启动一个短生命周期的检查器 Pod。该 Pod 執行你的驗證逻辑，然后向 Kuberhealthy 报告。结果随后通过内置状态界面、JSON API 和 Prometheus 指标端点提供。
專案核對 0：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
将检查作为程式碼 · kuberhealthy-kuberhealthy-deep-analysis
README 将检查描述为 Kubernetes 清单，因此你可以将它们与應用程序一起交付。一个检查可以執行多步骤工作流，例如模拟使用者登录、创建记录、驗證并清理。由于每个检查都是一个容器，你可以使用任何适合容器的语言编写；README 列出了 Go、Python、Rust 和 bash 作为示例。这使得监控逻辑成为部署流水线的一部分，而不是一个单独的系統。
專案核對 1：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
安裝 Kuberhealthy · kuberhealthy-kuberhealthy-deep-analysis
README 说安裝是通过應用 Helm、Kustomize 或 ArgoCD 清单完成的。对于 Helm，指令是 `helm install kuberhealthy deploy/helm/kuberhealthy -n kuberhealthy --create-namespace`。对于 Kustomize，指令是 `kubectl apply -k github.com/kuberhealthy/kuberhealthy/deploy/kustomize/base?ref=main`。对于 ArgoCD，指令是 `kubectl apply -f deploy/argocd/kuberhealthy.yaml`。安裝后，你可以使用 `kubectl -n kuberhealthy port-forward svc/kuberhealthy 8080:80` 进行端口转发，并打开 `http://localhost:8080` 查看状态界面。
專案核對 2：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
HealthCheck 自定义资源 · kuberhealthy-kuberhealthy-deep-analysis
HealthCheck 是 Kuberhealthy 管理的核心对象。它的 spec 包含 runInterval、timeout 和 podSpec。README 中的示例使用内置的 deployment check，它会创建一个測試部署、执行滚动更新并拆除它。清单将镜像设置为 `docker.io/kuberhealthy/deployment-check:v0.1.1`，传递诸如 `CHECK_DEPLOYMENT_REPLICAS` 和 `CHECK_DEPLOYMENT_ROLLING_UPDATE` 的环境变量，并指定资源请求和限制。你可以使用 `kubectl get healthcheck` 或 `kubectl get hc` 查询检查。
專案核對 3：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
读取检查状态 · kuberhealthy-kuberhealthy-deep-analysis
Kuberhealthy 以两种机器可读的形式暴露检查状态。`/metrics` 端点用于 Prometheus，包含 `check`、`namespace` 和 `status` 等标签。README 显示了 `kuberhealthy_check{check="api-smoke-test",namespace="kuberhealthy",status="1"} 1` 和 `kuberhealthy_check_duration_seconds{check="api-smoke-test",namespace="kuberhealthy"} 0.23`。`/json` 端点返回一个 JSON 对象，包含 `ok` 字段和包含 `lastRun` 和 `runDuration` 的 `checks` 映射。内置状态界面也会显示这些结果。
專案核對 4：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
编写自己的检查 · kuberhealthy-kuberhealthy-deep-analysis
要编写检查，README 指向 `docs/CHECK_CREATION.md` 和位于 `docs/CHECKS_REGISTRY.md` 的 HealthCheck 注册表。它列出了 Go、Python、TypeScript、JavaScript、Rust、Ruby、Java 和 Bash 的客户端库。Go 示例使用 `github.com/kuberhealthy/kuberhealthy/v3/pkg/checkclient` 来报告成功或失败。客户端会自动处理 `KH_REPORTING_URL` 和 `KH_RUN_UUID` 环境变量以及截止时间强制执行。
專案核對 5：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
檔案、采用者和社区 · kuberhealthy-kuberhealthy-deep-analysis
README 链接到完整的檔案索引、采用者列表、貢獻指南和开放問題列表。它还提到了 Slack 频道和每月电话会议。该倉庫使用 Apache 2.0 授權；授權摘录授予使用、复制和分发相关的版权和专利权利，但未提及支援、保修或安全保证。README 本身没有列出具体的生产使用者，也没有提供基准測試。
專案核對 6：請在 kuberhealthy-kuberhealthy-deep-analysis 的 README、設定檔或命令輸出中確認這一節描述的具體行為，並把檔案路徑、參數名稱、平台條件與錯誤結果分開記錄。這些觀察可用來判斷功能是否真的符合目前流程，也能在升級後定位差異。素材未列出的性能或安全承諾，不應自行補上。
Kuberhealthy 的專案核對 1：以 README 已列出的入口、命令或設定鍵執行一次完整流程，保存 kubectl、curl、helm、make 或專案本身命令的標準輸出與錯誤文字，並記下輸入檔案、資源名稱、版本和產物位置。對 Kuberhealthy 而言，這些記號能把控制器狀態、服務端點、容器日誌或建置產物連回具體步驟；文件未說明的效能、相容性和故障恢復，不從名稱推定。
Kuberhealthy 的專案核對 2：以 README 已列出的入口、命令或設定鍵執行一次完整流程，保存 kubectl、curl、helm、make 或專案本身命令的標準輸出與錯誤文字，並記下輸入檔案、資源名稱、版本和產物位置。對 Kuberhealthy 而言，這些記號能把控制器狀態、服務端點、容器日誌或建置產物連回具體步驟；文件未說明的效能、相容性和故障恢復，不從名稱推定。
Kuberhealthy 的專案核對 3：以 README 已列出的入口、命令或設定鍵執行一次完整流程，保存 kubectl、curl、helm、make 或專案本身命令的標準輸出與錯誤文字，並記下輸入檔案、資源名稱、版本和產物位置。對 Kuberhealthy 而言，這些記號能把控制器狀態、服務端點、容器日誌或建置產物連回具體步驟；文件未說明的效能、相容性和故障恢復，不從名稱推定。
編輯結論
它适合已经使用 Kubernetes、希望把 API 烟测或多步骤业务驗證写进清单和發布流程的团队，不适合只需要主机级指标的场景。先在隔离命名空间执行 Helm 安裝，创建一个有明确超时的 HealthCheck，再同时查看 kubectl 状态、/json 和 /metrics 是否一致。 本專案核對項目1應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。 本專案核對項目2應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。 本專案核對項目3應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。 本專案核對項目4應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。 本專案核對項目5應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。 本專案核對項目6應依 README 的實際入口和版本標籤保存輸出，並以專案名稱、命令或檔案路徑標記，避免把未說明的行為當成保證。
社群筆記