A Kubernetes rollout and a feature flag rollout answer different questions. The Deployment decides which image runs in which pods. The flag decides which users get the new code path inside those pods. rollfuse handles the second question only: it doesn't create, scale or roll back pods, and it doesn't control what share of pods a canary receives.
What rollfuse does inside a cluster is short to wire. Each deployment gets a credential for the environment it belongs to, and the SDK in the pod evaluates that environment's flags locally.
One environment, one credential
Environments belong to a project, and you create them in the console or through the API:
POST /v1/projects/{project_id}/environments
{
"name": "Production",
"slug": "production"
}
A service credential is issued for exactly one environment (POST /v1/environments/{environment_id}/credentials) and can't read or change any other. An SDK only needs the config:read scope. Because the credential already determines the environment, there is no separate setting to tell the SDK which environment it's in: a staging deployment and a production deployment differ only in which credential they mount.
Passing the credential to the pod
Keep the credential in a Kubernetes Secret and expose it to the container as an environment variable:
env:
- name: ROLLFUSE_SERVICE_CREDENTIAL
valueFrom:
secretKeyRef:
name: rollfuse-credential
key: ROLLFUSE_SERVICE_CREDENTIAL
The variable name is your choice. The SDK never reads environment variables on its own; your code reads the value and passes it to the client, as in rollfuse.NewClient("https://api.rollfuse.com", credential) with the Go SDK.
Ready only when flags can be evaluated
client.Start(ctx) blocks until the first configuration fetch succeeds. If your service opens its port only after that call and points the readinessProbe at an endpoint served from then on, a pod never receives traffic before it can evaluate a flag.
Changing who sees a feature without touching pods
Evaluation happens in the process, against a cached configuration. The Go SDK (v0.2.1) keeps that configuration current by polling the rollfuse API, every 30 seconds by default. Changing a rollout percentage or turning a flag off therefore needs no new image, no new Deployment revision and no restart.
Where the guardrail fits
A guardrail watches a metric during a flag rollout. If the metric crosses its threshold, rollfuse aborts the rollout and the flag goes back to serving its default variation to 100% of that environment. The Deployment is left alone: the new image keeps running, and only the code path behind the flag stops being served. Rolling back the Deployment itself stays with Kubernetes or your deploy tool. The Prometheus page shows how a metric reaches a guardrail.
Try it on a cluster
The public examples-kubernetes repository runs a flagged checkout service on any cluster with plain manifests (Deployment, Service, ConfigMap and Secret) and a local stand-in for the rollfuse API, so it needs no rollfuse account. Editing the rollout split in its ConfigMap changes which variation the two replicas serve, with no restart.