GKE: values for gitea, argocd and cert-manager on gke-toolshed-prd-usc1

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
2026-09-12 13:16:11 +05:30
parent 91550dd640
commit 66c30cfaf4
3 changed files with 254 additions and 0 deletions
@@ -0,0 +1,113 @@
+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
@@ -0,0 +1,66 @@
+# GKE values for the vendored cert-manager chart (helm-templates/cert-manager,
+# v1.20.1). Written fresh rather than copied from k8s-admin-prd-ase1, whose
+# file was never adapted from the fleet: it pulls images from a private
+# Meesho Artifact Registry and pins pods to a "dedicated: devops" node pool
+# that does not exist here.
+#
+# Installed once by hand with `helm install cert-manager` (namespace
+# "cert-manager"), then adopted by the cert-manager Application in
+# devops-infra-argo-config-gcp.
+#
+# Its job here is Harbor's certificate, issued from the private registry CA
+# that toolshed-gke-infra's 10-infra creates and the node pool trusts. The
+# CA key pair reaches the cluster as the "registry-ca" Secret in this
+# namespace (kubectl, from terraform output); the ClusterIssuer that uses it
+# lives with Harbor's config, not here.
+# The vendored chart's own values.yaml was edited in the fleet to pull every
+# image from Meesho's private Artifact Registry, which these nodes cannot
+# reach. Back to upstream's registry (quay.io/jetstack/cert-manager-*).
+imageRegistry: quay.io
+imageNamespace: jetstack
+
+crds:
+  enabled: true
+  # A helm uninstall must not take every Certificate in the cluster with it.
+  keep: true
+
+replicaCount: 1
+resources:
+  requests:
+    cpu: 50m
+    memory: 96Mi
+  limits:
+    memory: 256Mi
+
+webhook:
+  replicaCount: 1
+  resources:
+    requests:
+      cpu: 20m
+      memory: 48Mi
+    limits:
+      memory: 128Mi
+
+cainjector:
+  enabled: true
+  replicaCount: 1
+  resources:
+    requests:
+      cpu: 20m
+      memory: 96Mi
+    limits:
+      memory: 256Mi
+
+startupapicheck:
+  enabled: true
+  resources:
+    requests:
+      cpu: 10m
+      memory: 32Mi
+    limits:
+      memory: 64Mi
+
+prometheus:
+  enabled: true
+  servicemonitor:
+    enabled: false
@@ -0,0 +1,75 @@
+gitea:
+  # GKE counterpart of helm-overrides/k8s-admin-prd-ase1/gitea — same
+  # SQLite/no-cache shape, with what differs on GKE called out inline.
+  #
+  # Installed once by hand with `helm install gitea` (release "gitea",
+  # namespace "gitea"), then adopted by ArgoCD via the nameOverride in
+  # devops-infra-argo-config-gcp's values file. Gitea has to exist before
+  # ArgoCD can read anything, since both config repos live inside it.
+
+  # Recreate for a different reason than the homelab's LevelDB lock: on
+  # three nodes with a ReadWriteOnce persistent disk, the chart's default
+  # RollingUpdate (maxUnavailable: 0) starts the new pod first, and if it
+  # lands on another node it waits forever on Multi-Attach.
+  strategy:
+    type: Recreate
+
+  persistence:
+    size: 10Gi
+    # GKE's default class (pd-balanced), in place of the homelab's
+    # local-path. Counts against the project's 250GB SSD quota.
+    storageClass: standard-rwo
+
+  postgresql:
+    enabled: false
+  postgresql-ha:
+    enabled: false
+  valkey:
+    enabled: false
+  valkey-cluster:
+    enabled: false
+
+  resources:
+    requests:
+      cpu: 100m
+      memory: 300Mi
+    limits:
+      memory: 500Mi
+
+  gitea:
+    config:
+      database:
+        DB_TYPE: sqlite3
+      actions:
+        ENABLED: true
+      server:
+        ROOT_URL: http://gitea.35.238.248.203.nip.io/
+      service:
+        # The homelab sat on a LAN; this Gitea is on a public IP. Open
+        # registration would let anyone on the internet create an account.
+        DISABLE_REGISTRATION: true
+      security:
+        # The homelab allowed "*" because every host was on a private LAN.
+        # Here "*" would also allow webhooks to the node metadata server,
+        # so this is narrowed to private ranges — which still covers every
+        # in-cluster Service (Jenkins included) reached over cluster DNS.
+        ALLOWED_HOST_LIST: private
+    admin:
+      username: gitadmin
+      # Created by hand with kubectl at bootstrap, because Vault and ESO
+      # are not running yet. Same Secret name as the homelab so the
+      # ExternalSecret (secretstores/gitea-admin-credentials.yaml) can take
+      # it over unchanged once Vault is up.
+      existingSecret: gitea-admin-credentials
+      email: "admin@local.lab"
+
+  # Contour does not exist yet at bootstrap — the Ingress just sits unused
+  # until ArgoCD installs it. One host only: no Tailscale on GKE.
+  ingress:
+    enabled: true
+    className: contour
+    hosts:
+      - host: gitea.35.238.248.203.nip.io
+        paths:
+          - path: /
+            pathType: Prefix