feat(kuma-cp) add GlobalInsights api endpoint #3018
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
/global-insights
is an endpoint which will return aggregatedstatistics for global resources, like
Zone
,ZoneIngress
orMesh
. It's purpose is simmilar to theMeshInsights
, but forglobal resources, and will be used in our GUI to simplify
displaying statistics of these objects.
I've spent to much time thinking about the approach for adding
this endpoint and finally decided to go with the easiest one,
which is just asking for
Zone
s,ZoneIngress
es andMesh
esevery time endpoint is hitted as the
GlobalInsights
is differentthan other resources like
MeshInsights
as there always will beone. The assumption is also, that there won't be a lot of
the resources we'll be asking for every endpoint hit.
Other solutions considered were:
GlobalInsights
as the real resource, likeMeshInsights
, but then we would have to create separate k8s'CRD, for just the resource which would exist only one at a time.
Also, as it's the global resource, reconciliation of it would
be more complex.
json string in k8s' ConfigMap), but I really think it wouldn't
be right, as I think it would be not obvious and harder to
maintain in the future. The complexity of reconciliation would
be the same as in the option above.
I think this solution is very easy, and if anyhow it will become
performance bottleneck, we can just improve it/refactor it, without
breaking backward compatibility.
Full changelog
no changelog
Issues resolved
no issue resolved
Documentation
Testing
Backwards compatibility
backport-to-stable
label if the code is backwards compatible. Otherwise, list breaking changes.