Provider Connectors
KNative and kro
How LevelFour reads KNative Services and kro instances, and where their recommendations make the change.
KNative and kro both render the Deployments your pods run in from an object of their own. A request change belongs in that object, so LevelFour reads it and points each recommendation there. Both work with no setting: the agent reads them when they are installed. What the agent reads lists the permissions and the fields.
KNative Serving
The agent reports a KNative Service as one workload, kind Service, across all its revisions. Its usage, its cost and its recommendations stay with the Service when a new revision rolls out.
On the Workloads tab it reads Knative Service, with how many revisions it has. Its drawer lists each revision: generation, when it was created, whether it is ready, its share of traffic, its replicas, and its containers' requests and limits.
A recommendation changes the container's requests and limits in the Service's own template, spec.template.spec.containers, where KNative sets them, matching the container by name. The pull request goes to the repository that deploys the Service, found the same way as for any workload.
Three things differ from a Deployment:
queue-proxygets no recommendation. KNative adds that container to every pod, outside your Service's container list.- No scale-to-zero recommendation. LevelFour leaves a KNative Service's scaling to KNative.
- The autoscaling target stays as it is. A recommendation never changes the
autoscaling.knative.dev/targetannotation.
kro
kro labels each object it renders from a ResourceGraphDefinition with the instance it came from (kro instances). The agent reads that instance and its ResourceGraphDefinition, and finds which instance field sets each container's requests and limits.
A recommendation for such a workload edits the instance, not the rendered Deployment. When the definition's template sets cpu: ${schema.spec.cpu}, the pull request changes spec.cpu in the instance.
LevelFour does not edit the instance when the definition sets a value itself, as a fixed value or an expression computed from other fields. Changing the definition would change every instance it renders, so that change stays with the team that owns it.
Instances in the kro.run API group are read with no setting. For instances in a group of your own, list the group in kro.instanceGroups (see Configure the agent), so the agent's role can read them.
A workload rendered inside a nested graph gets no instance change yet: the agent finds the fields only for resources at the top level of a ResourceGraphDefinition.
Clusters without the agent
See cost per namespace for an Amazon EKS or Google Kubernetes Engine cluster that does not run the LevelFour agent, from the cost allocation data in your bill.
Recommendations
How LevelFour sizes container requests, keeps room for the JVM heap and your namespace limits, works with HPA, KEDA and VPA, changes NodePools, node groups and volume claims, checks every change once it lands, and measures what it saved on your bill.