Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

dynamic-config on Kubernetes

Annotate a pod; an agent appears in it that renders configuration from a remote store to a file the application watches. The agent-injector shape, for configuration.

metadata:
  annotations:
    dynamic-config.rs/inject: "true"
    dynamic-config.rs/source: "consul"
    dynamic-config.rs/endpoint: "http://consul:8500"
    dynamic-config.rs/key: "myapp/config.json"
    dynamic-config.rs/path: "/config/rendered.toml"

The application needs no store client, no store credential, and no code change: it reads a file, and if it reads it with any dynamic-config binding it also reloads on every re-render — the agent writes atomically, exactly the whole-file event a watcher wants.

When not to use this. The engine runs in-process everywhere; a Rust, Python or Node service that can hold a store credential should usually use its own binding's remote support and skip the sidecar entirely. This integration exists for the pods that want files rendered for them: Java services reading .properties, anything that must not carry store credentials in-process, and fleets standardising one injection pattern.

The three pieces, staged

pieceships intoday
agent0.1.0built and tested — consul, vault, config-server, firestore, git, redis; etcd, nats and s3 join in 0.2.0
webhook0.2.0golden-tested; the annotation contract is v1
operator0.3.0CRDs settled and generated; reconcilers land here