A new cluster directory rather than edits to k8s-admin-prd-ase1, so no homelab value is ever reused for GCP by accident. Charts are the ones already vendored here (gitea 12.7.0, argo-cd 7.7.23, cert-manager v1.20.1); only the values are new. Verified with helm template. What differs from the homelab, and why: - gitea: storageClass standard-rwo, and Recreate for a different reason than the homelab's LevelDB lock — three nodes and a ReadWriteOnce disk mean a rolling update's new pod waits forever on Multi-Attach. The admin password comes from a Secret created at bootstrap instead of the chart's published default, which would otherwise be live on a public IP. Registration is disabled and webhooks are limited to private ranges, for the same reason. - argocd: single ingress host (no Tailscale), and the homelab's Ingress health override is dropped, since Contour writes real load balancer status here. server and repoServer autoscale 1-3 on CPU; the chart omits replicas when autoscaling is on, so the HPA and ArgoCD's own self-management do not fight over the count. Memory is deliberately not a scaling metric: Go does not return memory promptly, so a memory target scales up and never back down. - cert-manager: written fresh, not copied. The homelab file was never adapted from the fleet — it pulls from a private Meesho registry and pins pods to a node pool that does not exist here. The chart's own values.yaml carries that registry too, so imageRegistry and imageNamespace are overridden back to upstream's quay.io/jetstack. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N
114 lines
3.5 KiB
YAML
114 lines
3.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.
|
|
global:
|
|
image:
|
|
tag: "v2.13.8"
|
|
|
|
# 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
|
|
extraArgs:
|
|
- --insecure
|
|
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: false
|
|
notifications:
|
|
enabled: false
|
|
|
|
configs:
|
|
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
|