Kubernetes Operator: Dev Database Pod Metadata

AtlasSchema and AtlasMigration accept a devDB.metadata block that sets labels and annotations on the dev database pod the operator creates.

To normalize schemas and compute diffs, the Atlas Kubernetes Operator creates a dev database Deployment in the cluster. The pod template of that Deployment now takes custom labels and annotations from the new devDB.metadata block, available on both AtlasSchema and AtlasMigration resources.

apiVersion: db.atlasgo.io/v1alpha1
kind: AtlasSchema
metadata:
  name: myapp
spec:
  urlFrom:
    secretKeyRef:
      key: url
      name: myapp-db
  devDB:
    metadata:
      labels:
        team: platform
      annotations:
        example.com/purpose: schema-analysis
  schema:
    sql: |
      create table users (
        id int not null,
        primary key (id)
      );

No Custom Pod Spec Required

devDB.spec is optional. Setting only devDB.metadata keeps the generated dev database configuration, so no devURL is needed. Both fields can also be combined, in which case the metadata is applied to the custom pod spec:

spec:
  devURL: mysql://root:pass@localhost:3306/dev
  devDB:
    metadata:
      labels:
        team: platform
    spec:
      containers:
        - name: mysql-dev
          image: mysql:latest
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: pass
            - name: MYSQL_DATABASE
              value: dev
          ports:
            - containerPort: 3306
              name: mysql

Precedence and Scope

• Labels are applied to the pod template only, not to the Deployment selector.
• Operator-managed labels (atlasgo.io/engine, app.kubernetes.io/*) and the atlasgo.io/conntmpl annotation take precedence over custom values with the same key.
• Metadata is applied when the dev database Deployment is created. Existing Deployments are not updated.