Kube-Prometheus-Stack and ArgoCD 2.5 – Server-Side Apply to the Rescue!
metadata.annotations: Too long: must have at most 262144 bytes
3 min read
The long journey
This error message in ArgoCD:
one or more objects failed to apply, reason: CustomResourceDefinition.apiextensions.k8s.io "prometheuses.monitoring.coreos.com" is invalid: metadata.annotations: Too long: must have at most 262144 bytes,unable to recognize "/dev/shm/987607118": no matches for kind "Prometheus" in version "monitoring.coreos.com/v1"
Made my write now three article, about workarounds and solutions on ArgoCD to deploy large CRDs with ArgoCD.
Here are the links to my old articles, if you want to understand the whole journey:
Now with ArgCD >
2.5, we have finally an option to deploy large CRDS without any workaround like using two ArgoCD applications. It's called: Server-Side Apply
What is Server-Side Apply?
Server-Side apply is a new feature that is meant to replace the current client-side apply feature implemented by
kubectl apply. The feature is a new merging strategy for declarative configuration of Kubernetes objects and went GA in Kubernetes 1.22
What is Client-Side Apply?
We talk about client-side apply, when we run
kubectl apply -f xyz.yaml. The declarative configuration you wrote is
stored in the field
metadata.annotations.kubectl.kubernetes.io/last-applied-configuration on the object.
If you then change something in the yaml file and run
kubectl diff -f xyz.yaml you will see the diff of what gets
changed. You won't get a diff if someone has run an imperative command like
kubectl scale deployment xyz --replicas=3 because it is not stored in the
last-applied-configuration field. So that makes it hard to track where the value is coming from.
When you run
kubectl apply -f xyz.yaml on an existing object, the client-side apply will make a strategic merge and
update the values that change from
last-applied-configuration. The configuration will not be replaced!
Server-Side Apply in action!
The idea behind server-side apply is to have a simple way to track changes to objects and see who is the owner of the field.
When using server-side apply, the declarative configuration is stored in the field
metadata.managedFields on the
managedFields enables conflict detection so Kubernetes knows when multiple actors are trying to change the same field. An actor can be a user, a controller, or another component of the system.
To use server-side apply, you need to use the
kubectl apply -f xyz --server-side flag.
How to use Server-Side Apply with ArgoCD?
To use server-side apply with ArgoCD, you need to add to the
syncOptions in the ArgoCD application the value
The new Application yaml looks like this:
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: finalizers: - resources-finalizer.argocd.argoproj.io name: kube-prometheus-stack namespace: argocd spec: destination: namespace: monitoring server: https://kubernetes.default.svc project: default source: chart: kube-prometheus-stack helm: values: |- prometheus-node-exporter: hostRootFsMount: enabled: false prometheusOperator: admissionWebhooks: failurePolicy: Ignore repoURL: https://prometheus-community.github.io/helm-charts targetRevision: 42.0.3 syncPolicy: syncOptions: - ServerSideApply=true - CreateNamespace=true
I think this is a great new feature in ArgoCD and will set the end of our triology of articles about the annoying error:
Too long: must have at most 262144 bytes