-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[kube-prometheus-stack] update kps to v0.65.1 #3267
Conversation
Signed-off-by: QuentinBisson <[email protected]>
Signed-off-by: QuentinBisson <[email protected]>
Well this will not be fun to fix:
|
So the issue is coming from the newer PrometheusAgent CRD which is causing the helm secret to be too big. The only solution I can think of is to have the crds outside the chart but maybe you can think of a better solution? If that is fine with you i was thinking of doing something similar to https://github.com/cowboysysop/charts/tree/master/charts/vertical-pod-autoscaler/templates/crds a job that pulls and would then also update the crds |
An immediate/short-term solution might be using stripped-down crds as released by the Prometheus operator team. These do not include description fields, the manifests are considerably smaller. |
That could work but this would reduce functionality as users would not be able to use I also tend to think the job will help as upgrades of CRDs will then be at the charge of the helm chart :) |
Yes, a job would do. Keeping the CRDs out of the chart seems to be the only fix in this respect. |
Related #1876 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please check for the failing ci?
@monotek i'm trying to fix it but the issue is that the New prometheus agent crd make us go over the 1MB secret limit of Kubernetes |
@GMartinez-Sisti and @monotek I tested this on existing clusters but this is quite a big change so I won't merge with newer approvals |
Signed-off-by: QuentinBisson <[email protected]>
Signed-off-by: Quentin Bisson <[email protected]>
- --server-side | ||
- --force-conflicts={{ $.Values.crds.forceConflicts }} | ||
- -f | ||
- https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/{{ $appVersion }}/example/prometheus-operator-crd/monitoring.coreos.com_{{ . }}.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also allow this URL to be customisable as some environments might not have external internet access and this can be easily checked into an internal artefact repository.
Ideally we would have CI automation to deploy the version on main and then the PR one over it. I can test this but it would take a couple of days. The logic looks good though, I like this approach 💪 . Left some comments. |
Signed-off-by: QuentinBisson <[email protected]>
## This defaults to non root user with uid 2000 and gid 2000. *v1.PodSecurityContext false | ||
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ | ||
## | ||
securityContext: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this could be made compatible with the restricted profile by default that would be great.
Signed-off-by: QuentinBisson <[email protected]>
Signed-off-by: Quentin Bisson <[email protected]>
We really need to reach a concensus here because we need to bump the major version to avoid issues with prometheus-operator that was upgraded in another PR. Either we:
@monotek I know you do not like that approach but would you have another one we can go with in your opinion? I would really like some help to move this forwards :( |
Personally I'm fine with any solution because I already don't use this chart for CRDs. I would say that moving the dashboards out of this chart is probably not an alternative but rather a necessary next step instead because I imagine that sooner or later this limit will be hit again if the dashboards remain in this chart. |
I'd suggest adding |
One thing to note is that Argo doesn't implement helm properly meaning the crds option present currently in this PR is something that Argo folks cannot use because they are implemented with a helm hook. I'm not using Argo so I'm not sure how important that is or if Argo users have a different means of managing crds that can keep up to date with this helm chart. |
Argo converts helm hooks to Argo hooks, pre-install and preupgrade become 'presync' which should be fine in this case I believe. |
This could be an option as
This would be my preferred option to keep things simple. People can use |
I'm for for deleting the CRDs from kube-prometheus-stack and shift the maintenance to prometheus-operator-crd helm chart. This also resolve issue that kubectl needs manually applied on major updates. However, please keep in mind, removing the CRDs from crds/ folder does not remove the CRD from cluster. This can cause can conflict that prometheus-operator-crd can't installed on existing clusters. We have to add a documentation to "migrate" the CRDs from kube-prometheus-stack to prometheus-operator-crd, for example that the CRDs needs to be annotated with |
@jkroepke I am not happy with that solution because of what I mentioned here[1] and my proceeding 3 comments. Flux is able to manage the CRDs just fine in the special [1] #3267 (comment) |
And what about non-flux users? I would personally not care about ArgoCD or flux here. Nice to see that the GitOps operators has some special feature to just fix helm, but we should looking forward for typical helm users. As I know, ArgoCD solves the CRDs issues with helm template | kubectl apply @onedr0p you can create a umbrella chart to bundle both helm chart to have the old behavior back. |
Documentation still stays the same, [1] #3267 (comment) Even if we take out the crds, leaving the dashboards in this chart will only lead to this issue down the road as more things are added. |
Yeah. I created #3416 as POC which minified all the dashboard json files. From
down to
which can have a potential save of 1MB data (or 1MB of pure whitespaces)... |
Helm already compresses all manifests inside the secret so not sure if minifying the json helps anything. Needs to be properly tested. |
Everyone is invited to test #3416, the CI is at least green. |
Ah I missed that you posted the secret sizes sorry, looks good! Tho |
I agree, that this is not a long term solution. We may need to discuss how to proceed there. However there a short-term fix for now to proceed as usual. I do not really understand, why CRDs are stored in a helm release while helm does not managed them. The helm guys are crazy. |
By the way, on a another test branch: Minify the CRDs (convert them from YAML to JSON) would also reduce the size to 811K in total.
While this is fine from Helm/Kubernetes point of view, I'm not aware of the downsides by deliver JSON manifests |
This will be closed in favor of #3416 but I will keep it open to make this into an issue to define the way forward |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set to "request changes" to block accidental merging it as changes are already implemented in #3416
Hi there, would it make sense to create an issue instead discuss in a PR? It feels like this topic is in sleep mode for know. I'm interrest into finding a solution before having the issues on new CRDs again. |
@jkroepke yes it would but I did not have the bandwith to write the issue down yet, you can do it if you want :) |
#3548 created. @QuentinBisson |
Thank you @jkroepke :) |
What this PR does / why we need it
Upgrades prometheus-operator to v0.65.1
Which issue this PR fixes
(optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close that issue when PR gets merged)Special notes for your reviewer
Checklist
[prometheus-couchdb-exporter]
)@monotek and @GMartinez-Sisti as it's my first major release, I'd like if you could take a look, especially as this one adds a new crd