{"id":570,"date":"2025-05-02T15:38:34","date_gmt":"2025-05-02T15:38:34","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=570"},"modified":"2025-05-02T15:38:34","modified_gmt":"2025-05-02T15:38:34","slug":"argocd-metadata-annotations-too-long","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=570","title":{"rendered":"Metadata annotations Too long: must have at most 262144 bytes"},"content":{"rendered":"

In this blog I have added the solution for ArgoCD Metadata.annotations: Too long<\/code> Error.<\/p>\n

Issue – Annotation Exceeding Limit<\/h2>\n

When I tried to deploy the Prometheus-stack helm chart<\/a> using ArgoCD<\/a>, I faced the following error.<\/p>\n

metadata.annotations: Too long: must have at most 262144 bytes<\/code><\/pre>\n
This issue occurs because the size of the value of the annotation exceeds the Kubernetes<\/strong><\/a> 256\u202fKiB (262\u202f144\u202fbytes) limit. <\/strong>(Refer the code here<\/a>)<\/p>\n
That is a very good limit for storing many annotation. But here is why it exceeds in ArgoCD.<\/p>\n
When ArgoCD applies the YAML, it stores a copy inside the object itself under kubectl.kubernetes.io\/last-applied-configuration<\/code> annotation. That hidden copy counts toward the 256\u202fKB limit on metadata.annotations<\/code><\/p>\n
\u202fSo, if the object itself is large (big CRDs, Prometheus, Grafana\u2011dashboard ConfigMaps, etc.), the annotation pushes the total size over 256\u202fKiB and the API server rejects the object.<\/p>\n
You won’t face this issue when you try to deploy the helm chart directly using helm install<\/code> or kubectl apply<\/code><\/p>\n
Solution – Using ServerSideApply (SSA)<\/h2>\n
To solve this issue, you can use the ServerSideApply<\/code> option available on ArgoCD.<\/p>\n
This option tells Argo CD to let the Kubernetes API server<\/a> take care of the apply instead of storing the configuration in annotations. Meaning, SSA offloads the “apply” logic and state tracking (moving it from annotations to managedFields<\/code>) to the Kubernetes API server itself<\/p>\n
If you are using the declarative method<\/code> for deploying the application, you can specify the ServerSideApply<\/code> option under the syncPolicy<\/code> as given in the example below.<\/p>\n
apiVersion: argoproj.io\/v1alpha1\nkind: Application\nmetadata:\n  name: prometheus\n  namespace: argocd\nspec:\n  destination:\n    name: in-cluster\n    namespace: monitoring\n  project: default\n  source:\n    repoURL: '<your-repo>'\n    targetRevision: HEAD\n    path: kube-prometheus-stack\n    helm:\n      valueFiles:\n      - values.yaml\n  syncPolicy:\n    syncOptions:\n    - CreateNamespace=true\n    - ServerSideApply=true <\/code><\/pre>\n
If you are deploying using ArgoCD UI<\/code>, enable the Server-Side Apply<\/code> option under the SYNC OPTIONS<\/code> during the configuration.<\/p>\n
\"\"<\/figure>\n
\n
\ud83d\udca1<\/div>\n
Server-Side Apply<\/a> (SSA) is a native feature of Kubernetes.<\/p>\n
Traditionally, kubectl apply<\/code> uses client-side logic. This means your local kubectl<\/code> fetches the current state of a resource from the cluster, compares it to the desired state defined in your YAML file, calculates the differences locally, and then sends an update to the API server.<\/p>\n
With SSA, that entire process shifts to the server. You send the complete desired YAML to the API server, and it takes care of comparing the current and desired states. It also keeps track of which client owns which fields in a resource – a concept known as field ownership<\/strong><\/b>. In our case, ArgoCD is the owner managing these fields.<\/div>\n<\/div>\n
\n
Ngu\u1ed3n:<\/strong> Metadata annotations Too long: must have at most 262144 bytes \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Source: https:\/\/devopscube.com\/argocd-metadata-annotations-too-long\/<\/p>\n","protected":false},"author":1,"featured_media":571,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-570","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/570","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=570"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/570\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/571"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=570"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=570"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=570"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}