Kubernetes deployment templates¶
Follow the Kubernetes deployment recipe to render these templates, supply protected configuration, migrate explicitly, and verify an authorized workflow. Begin with the cloud overview for AWS EKS, Azure AKS and Google GKE prerequisites.
Read the matrix before assigning a Secret: the migration Job receives owner authority, the API receives application/catalog authority, and the remote worker receives only its six API/identity/effect settings.
| Template | What it creates | Required replacement / configuration |
|---|---|---|
| migrate.yaml | One explicit, nonretrying migration Job | __WEAVE_SERVER_IMAGE__, unique __WEAVE_MIGRATION_JOB__, weave-migration Secret |
| api.yaml | One API Deployment and ClusterIP Service | __WEAVE_SERVER_IMAGE__, weave-api-runtime Secret |
| worker.yaml | Optional remote worker Deployment with zero replicas | __WEAVE_WORKER_IMAGE__, admitted release/current grants and weave-worker-runtime Secret |
The image placeholders require actual registry digest references. Do not apply the unrendered directory. Apply the migration, API and optional worker separately in the documented order; do not bulk-apply all three files as a startup script. The worker stays at zero replicas until explicitly scaled after admission checks.
All containers run as UID/GID 65532 with a read-only root filesystem, bounded
writable /tmp, dropped capabilities and no mounted Kubernetes API token.
Resource values are examples to measure and tune. The templates do not create
cloud infrastructure, database roles, provider identities, ingress, cloud IAM,
secret synchronization, network policies or registry pull credentials. Successful
managed-database migration rehearsal is a prerequisite, not an assumption.
No deployment or live cluster validation is implied by these files. Use the guide's server dry run and acceptance checks in your selected environment.