Kustomise Installation

If you prefer plain Kubernetes manifests over Helm — for GitOps workflows, policy compliance, or simply greater transparency — CostPilot provides a complete set of Kustomise manifests alongside the Helm chart.

Both installation methods deploy identical resources. Choose whichever fits your team’s workflow.

How it works

The Kustomise manifests deploy the CostPilot Operator. Once running, the Operator reads the configuration ConfigMap and automatically creates and manages the agent ReplicaSet, RBAC, and mTLS certificates. You do not need to manage agent pods directly.

kubectl apply -k ...
       ↓
Operator Deployment       ← you deploy this
       ↓
Agent ReplicaSet (×3)     ← Operator creates and manages this

Prerequisites

Requirement	Minimum
Kubernetes	1.24+
kubectl	Any recent version
Kustomise	Built into kubectl 1.14+ (`kubectl apply -k`)
Cluster API key	Generated in Settings → Clusters

Step 1: Create the namespace

kubectl create namespace costpilot

Step 2: Create the API key Secret

The agent authenticates with CostPilot using a Cluster API Key. Store it as a Kubernetes Secret before applying the manifests:

kubectl create secret generic cp-agent-secret \
  --namespace costpilot \
  --from-literal=cluster-api-key=YOUR_API_KEY_HERE

⚠ Warning

The Secret must exist before applying the manifests. The Operator reads it on startup to authenticate with the CostPilot backend. If the Secret is missing, the Operator will log an error and retry until it becomes available.

✦ Tip

In a GitOps workflow, create the Secret separately from the application manifests — either via your secrets manager (e.g. External Secrets Operator, Sealed Secrets) or a namespace-scoped Secret resource in a restricted path of your repository.

Step 3: Apply the manifests

Option A — Apply the base directly

The quickest path. Clones the agent repository and applies the base manifests:

git clone https://github.com/smrt-devops/cost-pilot-agent.git
cd cost-pilot-agent
kubectl apply -k kustomize/base/

This deploys to the EU region by default. To use the US region, patch the ConfigMap before applying (see Customising the ConfigMap below).

Option B — Reference as a remote base (GitOps)

Reference the CostPilot base directly from your own Kustomisation file:

# my-cluster/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - github.com/smrt-devops/cost-pilot-agent//kustomize/base?ref=v0.1.0

patches:
  - target:
      kind: ConfigMap
      name: cp-agent-config
    patch: |-
      - op: replace
        path: /data/ingesterEndpoint
        value: "eu"

Pin to a specific release tag (?ref=v0.1.0) to avoid unintended updates.

Step 4: Verify the installation

# Check all pods are running
kubectl get pods -n costpilot

Expected output:

NAME                                 READY   STATUS    RESTARTS   AGE
cost-pilot-operator-7d9f8b-xxx       1/1     Running   0          60s
costpilot-agent-abc-aaa              1/1     Running   0          45s
costpilot-agent-abc-bbb              1/1     Running   0          45s
costpilot-agent-abc-ccc              1/1     Running   0          45s

The Operator creates agent pods within a few seconds of its own startup. If agent pods do not appear, check Operator logs:

kubectl logs -n costpilot -l app=cost-pilot-operator

Check that metrics are being shipped:

kubectl logs -n costpilot -l app=costpilot-agent --prefix

You should see lines like:

level=info msg="shipping metrics" pods=47 interval=15s
level=info msg="metrics shipped successfully" tenant=t_xxx cluster=c_yyy

Customising the ConfigMap

The ConfigMap cp-agent-config drives all agent configuration. The Operator watches it for changes and applies them automatically — no manual pod restarts required.

Key	Default	Description
`ingesterEndpoint`	`eu`	Ingester region: `eu` or `us`
`clusterApiKeySecretName`	`cp-agent-secret`	Name of the Secret holding `cluster-api-key`
`image`	`ghcr.io/smrt-devops/cost-pilot/agent:latest`	Container image for agent pods
`imagePullPolicy`	`IfNotPresent`	Kubernetes image pull policy
`intervalSeconds`	`15`	Metric collection interval in seconds (minimum: 15)
`replicas`	`3`	Number of agent replicas (minimum: 2 for production)

To change values without editing the base, use a Kustomise strategic merge patch or JSON 6902 patch in your overlay:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

images:
  - name: ghcr.io/smrt-devops/cost-pilot/agent
    newTag: "v0.1.0"

patches:
  - target:
      kind: ConfigMap
      name: cp-agent-config
    patch: |-
      - op: replace
        path: /data/ingesterEndpoint
        value: "us"

Upgrading

To upgrade to a new agent version:

Update the image tag in your overlay’s images block (or in base/deployment.yaml for base-only installs).
Re-apply the manifests:

kubectl apply -k deploy/kustomize/overlays/production/

The Operator detects the image change via its pod’s image SHA and automatically triggers a rolling restart of agent pods.

ℹ Note

The Operator compares its own running image SHA against the image configured in the ConfigMap. As soon as the new Operator pod is running, it will update the agent ReplicaSet’s pod template to use the new image — no separate agent rollout step is needed.

Uninstalling

kubectl delete -k deploy/kustomize/base/
kubectl delete namespace costpilot
kubectl delete clusterrole cost-pilot-operator
kubectl delete clusterrolebinding cost-pilot-operator

Cluster-scoped resources (ClusterRole, ClusterRoleBinding) must be deleted separately, as they are not namespaced.

⚠ Warning

Uninstalling the agent stops metric collection for that cluster. Historical data in CostPilot is retained. You can reinstall at any time and data collection will resume from the current point.

Helm vs Kustomise

	Helm	Kustomise
Templating	Values-driven Go templates	Patch-based overlays
Release management	Built-in (`helm list`, `helm rollback`)	Via `kubectl` and Git history
Secret handling	`--set secrets.agent.clusterApiKeySecretName`	Secret created separately
GitOps compatibility	Requires Flux HelmRelease or ArgoCD Application	Native `kubectl apply -k`
Audit trail	Helm release history	Git diff

Both methods deploy identical Kubernetes resources. Use Helm for richer lifecycle management; use Kustomise for plain-manifest GitOps pipelines.