Enhance get_resource Function in Lua Scripts to Fetch Other Kubernetes Resources for Custom Health Checks

[suresh-mahawar]

Summary

Currently, the get_resource function in Lua scripts for custom health checks in ArgoCD allows fetching information only about the resource for which the custom health check is being applied. However, there is no built-in capability to fetch information about other Kubernetes resources. This limitation restricts the ability to create robust and flexible custom health checks that depend on the state of multiple resources.

Motivation

Enhancing the get_resource function to allow fetching other resources would significantly expand the possibilities for custom health checks in ArgoCD.

Use Case

For example, consider a custom health check for:

"apps/v1", "Deployment", "example-deployment", "default"
Currently, the script can fetch details only about the Deployment/example-deployment itself:

local resourceJSON, err = get_resource("apps/v1", "Deployment", "example-deployment", "default")
if err ~= nil then
  hs.status = "Degraded"
  hs.message = "Failed to fetch resource: " .. err
else
  hs.status = "Healthy"
  hs.message = "Fetched resource successfully: " .. resourceJSON
end
return hs

However, in scenarios where the health of the deployment depends on other resources—such as Open Policy Agent (OPA) resources like:

"templates.gatekeeper.sh/v1", "ConstraintTemplate", "gatekeeper-system"
it becomes impossible to incorporate those dependencies. For example:

local resourceJSON, err = get_resource("templates.gatekeeper.sh/v1", "ConstraintTemplate", "gatekeeper-system")
if err ~= nil then
  hs.status = "Degraded"
  hs.message = "Failed to fetch resource: " .. err
else
  hs.status = "Healthy"
  hs.message = "Fetched resource successfully: " .. resourceJSON
end
return hs

This limitation forces users to rely on external tools or manual updates to push necessary data into the resource being checked, which adds complexity and overhead.

Proposal

Enhance the get_resource function to allow Lua scripts to fetch information about other Kubernetes resources beyond the current resource. This feature will:

Improve Flexibility: Enable custom health checks to depend on the state of other resources.
Reduce Tooling Overhead: Eliminate the need for separate tools or controllers to push resource data.
Increase Robustness: Allow more sophisticated health checks for interconnected resources, making applications more reliable.

Conclusion

This feature will empower users to build more robust and holistic health checks in ArgoCD, leveraging the state of the broader Kubernetes ecosystem. We hope you consider this proposal to unlock new possibilities for ArgoCD's custom health check functionality.

[crenshaw-dev]

I'm really not a fan of that pattern for a number of reasons:

1. performance: adds a network-bound task to a script that's meant to be very fast
2. mental model: complicates how Argo CD assesses when to run the health check
3. security model: how does Argo CD restrict what resources the health check can get?

If you need to augment the Deployment with more information, I'd recommend writing a controller. For some use cases, a kro ResourceGroup might do the trick.