K8s Templates

Starter YAML skeletons for basecamp — Helm chart shape, Kustomize overlay pair, Flux HelmRelease wiring, Cilium NetworkPolicy, Pyrra SLO, workload custom-resource instances. Copy-paste starting points for any K8s-native project.

K8s Templates — Starter YAML for basecamp

Copy these into basecamp/ (or any K8s-native project) when bootstrapping a new service / overlay / SLO / NetworkPolicy / Workload.

The shapes here match what basecamp plan documents. Each template’s top-of-file comment names the apiVersion last verified — bump it when you re-verify against a cluster upgrade.

Contents

TemplateWhat it isPhase first touched
helm-chart-skeleton/Chart.yaml + values.yaml + templates/{deployment,service,configmap,_helpers}. The minimum-useful Helm chart shape.Y3 Phase 20
kustomize-overlay-pair/base/ + overlays/{k3s,eks}/ showing env-specific patching (replicas, image tag, namespace). GKE structurally identical to EKS.Y3 Phase 20, Phase 24 (multi-cloud)
flux-helmrelease.yamlThe four Flux CRDs that wire a chart into GitOps: GitRepository + HelmRepository + Kustomization + HelmRelease.Y3 Phase 20
cilium-networkpolicy.yamlDefault-deny + explicit-allow CiliumNetworkPolicy with L3/L4 + L7 (HTTP) rules.Y3 Phase 25
pyrra-slo.yamlA Pyrra ServiceLevelObjective — latency + availability SLIs.Y3 Phase 28
workload-cr-instance.yamlA platform.basecamp.io/v1alpha1 Workload CRD instance — what platform-ctl new service produces.Y3 Phase 26

How to use

  1. Copy the template into the appropriate basecamp location (per the basecamp plan repo layout).
  2. Search-replace placeholders: my-service, <user>, <namespace>, <owner>, <email> — find every one with grep -rn "<" . and substitute.
  3. Verify the apiVersion matches what your cluster supports: kubectl api-resources | grep <Kind> to confirm.
  4. Validate before committing:
    • Helm: helm template . --debug
    • Kustomize: kustomize build overlays/k3s/
    • Both: kubeconform <output>.yaml
  5. Update # Last verified: when you tune for current cluster versions.

How the templates compose

Developer runs:  platform-ctl new service my-app --language go --targets k3s,eks
   │
   ▼ creates
A Workload CRD instance  ──── [workload-cr-instance.yaml]
   │
   ▼ platform-ctl operator reconciles
   │
   ├──► Helm chart in Git           ── [helm-chart-skeleton/]
   ├──► Kustomize overlays per env  ── [kustomize-overlay-pair/]
   ├──► Flux HelmRelease + Kustom.  ── [flux-helmrelease.yaml]
   ├──► CiliumNetworkPolicy         ── [cilium-networkpolicy.yaml]
   ├──► Pyrra SLO                   ── [pyrra-slo.yaml]
   └──► Runbook stub                ── [meta/runbook-template]

Six YAML templates + one prose template = everything a new basecamp service needs.

Staleness discipline

YAML templates rot faster than prose. apiVersions are deprecated across Kubernetes minor versions; Helm chart conventions evolve; Cilium adds L7 capabilities each release; Pyrra schema changes.

Re-verify each template on:

  • Every major Kubernetes upgrade (1.30 → 1.31 → 1.32 …)
  • Every Cilium minor upgrade
  • Every Flux minor upgrade
  • Every Pyrra minor upgrade
  • Every Helm major version (v3 → v4 will require touch-ups)

Bump the # Last verified: comment when you do. Templates from 18 months ago need re-verification before use.

Public-safety

Every file in this directory is public-safe by audit. Placeholder values (<user>, <namespace>, <owner>, <email>) are generic; service names referenced (my-service, triage, llm-gateway) are /root project names from the public projects index.

Do NOT introduce real internal service names, real internal registries, real Apple-internal apiGroups. The /pre-publish-check Claude skill (configured in the repo root’s .claude/skills/pre-publish-check/SKILL.md) will catch them; the private INTERNAL-PARALLELS.md mapping (at the workspace root, never published) has the forbidden list.

Cross-references