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

## The long journey

![so-annoying-war-dogs.gif](https://cdn.hashnode.com/res/hashnode/image/upload/v1669467817789/PUooX3gxR.gif align="center")

This error message in ArgoCD:

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1669464760616/sIPli7b3W.png align="center")

```bash
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:

%[https://blog.ediri.io/kube-prometheus-stack-and-argocd-how-workarounds-are-born]

%[https://blog.ediri.io/kube-prometheus-stack-and-argocd-23-how-to-remove-a-workaround]

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**

![hPK.gif](https://cdn.hashnode.com/res/hashnode/image/upload/v1669467900113/WIdKOg23a.gif align="center")

## 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!

![frink-professor-frink.gif](https://cdn.hashnode.com/res/hashnode/image/upload/v1669468082608/e9QFB0EaS.gif align="center")

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:

```yaml
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
```

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1669468664662/gmFbxc71N.png align="center")

## 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`

![giphy.gif](https://cdn.hashnode.com/res/hashnode/image/upload/v1669468141031/cI86NC3Cg.gif align="center")