Kube-Prometheus-Stack and ArgoCD 2.5 – Server-Side Apply to the Rescue!

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 object. 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 ServerSideApply=true.

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

The End

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