Search for a command to run...
metadata.annotations: Too long: must have at most 262144 bytes
Cloud Native Pilgrim | Kubernetes Enthusiast | Serverless Believer | Customer Experience Architect @ Pulumi | (he/him) | CK{A,AD} |
Hey! Great article. I've been wondering is it safe to enable server-side-apply when we have workflows where prometheus-operator needs to constantly look at multiple configs and sync them. Does server-side-apply change the ownership/management of any of the resources?
Great to read this helped you!
GPU scheduling in Kubernetes has always felt like buying a mansion when you need a studio apartment. A small inference workload that needs 2GB of GPU memory gets scheduled on an entire 80GB A100, and there's nothing you can do about it. The device pl...
TL;DR: The code https://github.com/dirien/quick-bites Nothing is more controversial in the Kubernetes community than whether to use Helm or Kustomize. I always advocate the philosophy of using the right tool for the right job. It avoids the problem...
TL;DR Le code https://github.com/dirien/quick-bites Introduction This article is part three of my series on secret management on Kubernetes with the help of Pulumi. In my first article, we talked about the Sealed Secrets controller. The second arti...
With AWS Lambda
Disaster Recovery, Data Migration made easy!
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
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
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!
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.
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
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
