kubernetes-ingress-controller
kubernetes-ingress-controller copied to clipboard
Spike: introduce a CLI which will allow users to wait for applied manifests to be ready
Is there an existing issue for this?
- [X] I have searched the existing issues
Problem Statement
Given a set of kubernetes resources which are to be applied by KIC to the dataplane - Kong Gateway - there exists no universal approach to wait for those resources to be applied to be programmed on the dataplane and be ready to serve traffic as configured.
Various off the shelf solutions might exist such as e.g. kubectl wait ... but those have their own limitations.
For example the Gateway API HTTPRoute, contains its conditions in status.parents[].conditions[] (ref)which prevents it from working with kubectl wait ... --for=condition=Programmed=True
One could try to work around it by using --for=jsonpath='{.status.parents[0].conditions[?(@.type=="Programmed")].status}'=True but that has its own problems e.g. https://github.com/kubernetes/kubectl/issues/1224.
Even with the above fixed, kubectl wait:
waits until the specified condition is seen in the Status field of every given resource.
which doesn't fit the use case here since users might include in the manifest resources which do not support a particular readiness condition.
Proposed Solution
- Research whether a CLI tool implementation is feasible which would
- Scan a provided manifest file (or stdin) for resources and match them with known GVKs that do support readiness condition like e.g. Gateway API
HTTPRouteProgrammedcondition - Wait for those objects to contain such a status condition with
Statusset toTrue. Otherwise report a failure with this condition - For resources that do not support such a readiness condition report warnings that those cannot be waited for in the context of being applied to the dataplane.
- Scan a provided manifest file (or stdin) for resources and match them with known GVKs that do support readiness condition like e.g. Gateway API
- Consider making this a
kubectlcommand
Additional information
No response
Acceptance Criteria
- [ ] A research summary is provided whether the described tool is feasible and would fit users needs
- [ ] An issue (or a set of issues) is created to track implementation of such tool