carvel-dev / carvel-dev/kapp-controller

Support exposing the status of individual resources applied on cluster

Open
#1,412 3 comments 0 reactions 0 assignees View on GitHub
carvel-accepted enhancement
Dominant language
Go
Stars
323
Forks
127
Avg merge
2d 10h
Merged PRs (30d)
6

Description

**Describe the problem/challenge you have**

Once the package contents fetched from the source are applied on the cluster through App CR, there is no way to know the health of the individual resources applied on the cluster. It would be helpful to know the status of individual resources applied, on the "status" section of App CR. This would be useful for SRE/ops teams managing hundreds or thousands of clusters - wherein this information can be scraped for monitoring.

**Describe the solution you'd like**

The controller that manages App, can also watch the individual resources being applied through informers. For core types, like deployments and pods where health information is already available, this can be used and stamped on App CR's status.

**Anything else you would like to add:**

A similar feature is available an OLM v1's component named [Rukpak](https://github.com/operator-framework/rukpak). Kubernetes-sigs/cli-utils (https://github.com/kubernetes-sigs/cli-utils/tree/master/pkg/kstatus) provides a set of helpers to enable collecting of status from core resource types. More details on the implementation can be found here: https://github.com/operator-framework/rukpak/blob/main/internal/healthchecks/builtin.go#L16-L33

Open questions:
- Should we trigger reconcile, when any of the resource is unhealthy?
- Would watching resources through informers increase cache, thereby affecting performance?

---
Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the App controller and its current status handling, then compare the proposed approach with Kubernetes-sigs/cli-utils kstatus and Rukpak's health checks. Done means exposing health for individual resources applied through an App CR, while resolving the open questions about reconciliation and informer cache impact.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.