Files
devops-infra-helm-charts-gcp/helm-overrides/gke-toolshed-prd-usc1/argocd-admin-prd/custom-values.yaml
T
Mukul SharmaandClaude Opus 5 41dd021d06 Upgrade Argo CD to chart 10.8.4 (v3.5.2)
Removes the cause of the diff failures that ServerSideDiff worked around:
v2.13.8 diffs against a Kubernetes schema compiled into its own binary,
and this cluster is newer than that schema.

Three things needed real changes, none of them mechanical:

- applicationSet.enabled no longer exists, and there is no replacement
  gate — unlike dex and notifications, the ApplicationSet controller's
  Deployment carries no conditional at all. Helm ignores unknown keys, so
  carrying the old value forward would have quietly started a controller
  nothing here uses. replicas: 0 is the only lever.

- The image tag pin is dropped rather than moved to v3.5.2. The chart's
  appVersion governs, so image and chart cannot drift; a pin outliving its
  chart is close to the failure being fixed here.

- server.insecure moved from server.extraArgs to configs.params, which is
  what the chart renders into argocd-cmd-params-cm. Caught by rendering:
  an earlier version of this commit deleted the extra arg on the strength
  of a comment claiming configs.params already set it, which it did not —
  Argo CD would have served its own TLS behind Contour and produced a
  redirect loop.

Verified in the rendered output: image v3.5.2 and no v2.13.8 anywhere,
server.insecure true, dex and notifications absent, ApplicationSet at zero
replicas, both HPAs intact with replicas omitted, ingress on Contour, repo
Secrets on cluster DNS.

Behaviour changes in v3 that apply here, none needing a values change:
logs RBAC is now enforced (jenkins-ci only syncs), update/delete no longer
inherit to sub-resources, and resource tracking moves from labels to
annotations, so the first sync re-stamps every managed resource.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
2026-09-12 15:24:49 +05:30

143 lines
5.5 KiB
YAML

argo-cd:
# GKE counterpart of helm-overrides/k8s-admin-prd-ase1/argocd-admin-prd.
#
# Installed once by hand with `helm install argocd-admin-prd` (namespace
# "argocd"), then manages itself through the argocd Application in
# devops-infra-argo-config-gcp, whose nameOverride matches that release.
# Deliberately no image tag pin, unlike the homelab: the chart's own
# appVersion (v3.5.2) governs, so the image cannot drift from the chart.
# A pin that outlives its chart is close to the failure this upgrade
# fixes — software older than the cluster it manages.
#
# Upgraded from chart 7.7.23 / Argo CD v2.13.8. Three v3 behaviour changes
# apply to this deployment, none of which needs a values change today:
# - logs RBAC is now enforced, so an account that reads pod logs needs
# an explicit `logs, get` policy. jenkins-ci below only syncs.
# - update/delete no longer inherit to an application's sub-resources.
# - resource tracking moves from labels to annotations, so the first
# sync after the upgrade re-stamps every managed resource.
# SSO still deferred, same as the homelab.
dex:
enabled: false
controller:
replicas: 1
resources:
requests:
cpu: 200m
memory: 400Mi
limits:
cpu: 500m
memory: 768Mi
redis-ha:
enabled: false
redis:
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
memory: 128Mi
# repo-server does the manifest rendering (helm template per Application),
# so it is the component that actually saturates when many apps sync at
# once. Stateless, safe to run several behind its Service. With
# autoscaling on, the chart omits `replicas` from the Deployment, so the
# HPA and ArgoCD's own self-management do not fight over the count.
#
# CPU only. The chart's default also scales on memory, but a Go process
# does not hand memory back promptly after a spike, so a memory target
# scales up and then never scales down. Setting it to null removes it.
repoServer:
autoscaling:
enabled: true
minReplicas: 1
maxReplicas: 3
targetCPUUtilizationPercentage: 70
targetMemoryUtilizationPercentage: null
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 300m
memory: 512Mi
# API/UI. Stateless, sessions live in Redis, so replicas are
# interchangeable. Same CPU-only reasoning as repoServer above.
server:
autoscaling:
enabled: true
minReplicas: 1
maxReplicas: 3
targetCPUUtilizationPercentage: 70
targetMemoryUtilizationPercentage: null
# --insecure is NOT set here as an extra arg: configs.params below
# carries server.insecure, which is the supported way to express it and
# is what the chart renders into argocd-cmd-params-cm. Setting both
# works but leaves two places to disagree.
ingress:
enabled: true
ingressClassName: contour
hostname: "argocd.35.238.248.203.nip.io"
resources:
requests:
cpu: 50m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi
# applicationSet.enabled no longer exists in this chart, and there is no
# replacement: unlike dex and notifications below, the ApplicationSet
# controller's Deployment has no conditional at all. replicas: 0 is the
# only lever — the Deployment exists but runs nothing. Carrying the old
# `enabled: false` forward would have quietly started the controller,
# since Helm ignores unknown keys.
#
# Nothing here uses the ApplicationSet CRD; Applications are rendered by
# generic-argo-apps-chart instead.
applicationSet:
replicas: 0
notifications:
enabled: false
configs:
# Contour terminates TLS in front of Argo CD; leaving Argo CD's own TLS
# on as well produces a redirect loop. This renders into
# argocd-cmd-params-cm, which the server actually reads.
#
# This file previously expressed it as server.extraArgs: [--insecure],
# inherited from the homelab. Both work, but only one should exist, and
# the rendered ConfigMap is the thing to check when it looks wrong.
params:
server.insecure: true
cm:
url: "http://argocd.35.238.248.203.nip.io"
timeout.reconciliation: 3m
timeout.reconciliation.jitter: 60s
# No Ingress health override, unlike the homelab: there Contour sat
# behind hostPort, so nothing ever wrote an Ingress's load balancer
# status. On GKE Envoy gets a real LoadBalancer Service and Contour
# writes that status, so ArgoCD's built-in check works as intended.
#
# Scoped account for Jenkins' syncArgoApp step — same as the homelab.
accounts.jenkins-ci: apiKey
accounts.jenkins-ci.enabled: "true"
rbac:
policy.csv: |
p, jenkins-ci, applications, sync, webapp/*, allow
p, jenkins-ci, applications, get, webapp/*, allow
# Reached over cluster DNS, never through Contour — which is what lets
# Contour itself be ArgoCD-managed. The repos are private on this
# public-facing Gitea, so ArgoCD reads them with a repo-creds Secret
# (created at bootstrap, covering everything under gitadmin/), not
# anonymously as in the homelab.
repositories:
devops-infra-helm-charts-gcp:
url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-helm-charts-gcp.git
devops-infra-argo-config-gcp:
url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-argo-config-gcp.git