Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/ /
Atlas Kubernetes Operator

Atlas Kubernetes Operator Dry Run

With the Atlas Kubernetes Operator Dry Run feature, you can see what Atlas Kubernetes Operator is going to change in Atlas, with those custom resources applied to the K8S cluster. The Atlas Kubernetes Operator emits events for every resource that it is going to create/update/delete in Atlas. Events emitted by the Atlas Kubernetes Operator running in Dry Run mode can be filtered by "Dry Run" reason. This feature is useful for upgrading your Atlas Operator resources.

In order to use the Atlas Kubernetes Operator Dry Run feature, you need to:

  • Have access to a new Kubernetes or OpenShift cluster.

  • Apply Atlas Kubernetes Operator custom resources to your new Kubernetes cluster. When you apply your resources, make sure you provide a secret with credentials. You need a new cluster, because upgrading CRDs on your existing Kubernetes cluster might leave Atlas Kubernetes Operator unable to reconcile existing custom resources. Moreover, the CRDs that are applied can be a newer version with potential breaking changes.

    Note

    Only one version of the AKO CRDs can exist in a specific Kubernetes cluster. This means that to test upgrading to a new version of the Atlas Kubernetes Operator, you need to deploy a new Kubernetes cluster (possibly a temporary cluster) to execute the dry run.

  • Install CRDs to your cluster for the version of the Atlas Kubernetes Operator you want to execute dry-run for.

  • Create a mongodb-atlas-operator service account in your Kubernetes cluster.

  • Create a role and rolebinding for your service account with the following permissions related to your Atlas Kubernetes Operator custom resources. You can either create these resources manually or with the Atlas CLI.

    • list

    • get

    • create

    • update

    • delete

The Dry Run process emits either the following message types, each of which can be either of the type Normal or Warning:

  • Would [verb] ([HTTP-Method]) [Atlas resource URL]

    • A description of a given Atlas Kubernetes Operator resource and the Kubernetes required Kubernetes process should the change be applied to your Atlas environment. When in Dry Run mode, Atlas Kubernetes Operator only emits dry-run events for HTTP verbs that would create/update/delete resources in Atlas, such as POST, PATCH, PUT, DELETE.

  • Done

    • No further dry-run events will be reported.

  • Finished

    • The Kubernetes Job running the dry-run process has completed.

1

Save the following example in a file called dry-run-job.yaml and apply it to your cluster by running kubectl apply -f dry-run-job.yaml. This will start Atlas Kubernetes Operator as a Kubernetes Job with the --dry-run parameter. Every reconciliation in the Atlas Kubernetes Operator will run only once, emitting events for each resource if there are changes between the resource spec and its state in Atlas.

You can run this command multiple times without making any changes to your Atlas resources.

1apiVersion: batch/v1
2kind: Job
3metadata:
4 name: ako-dry-run
5 namespace: mongodb-atlas-system
6spec:
7 backoffLimit: 1
8 template:
9 spec:
10 containers:
11 - args:
12 - --atlas-domain=https://cloud.mongodb.com/
13 - --log-level=info
14 - --log-encoder=json
15 - --dry-run
16 command:
17 - /manager
18 env:
19 - name: OPERATOR_POD_NAME
20 value: ako-dry-run
21 - name: OPERATOR_NAMESPACE
22 value: mongodb-atlas-system
23 - name: WATCH_NAMESPACE
24 value: mongodb-atlas-system
25 - name: JOB_NAME
26 value: ako-dry-run
27 image: quay.io/mongodb/mongodb-atlas-kubernetes-operator:2.8.0
28 imagePullPolicy: Always
29 livenessProbe:
30 failureThreshold: 3
31 httpGet:
32 path: /healthz
33 port: 8081
34 scheme: HTTP
35 initialDelaySeconds: 15
36 periodSeconds: 20
37 successThreshold: 1
38 timeoutSeconds: 1
39 name: ako-dry-run
40 restartPolicy: Never
41 serviceAccountName: mongodb-atlas-operator
2

When the Kubernetes Job is finished, you can list the events emitted by running the following command:

kubectl -n mongodb-atlas-system get events --field-selector reason=DryRun

This command will return output similar to the following:

LAST SEEN TYPE REASON OBJECT MESSAGE
103s Normal DryRun atlasproject/my-project Would delete (DELETE) /api/atlas/v1.0/groups/6558f184beba40022cbb2043/integrations/SLACK
101s Warning DryRun atlasproject/my-project finished dry run
1
atlas kubernetes operator install --targetNamespace=mongodb-atlas-system --config-only
2

Run the following Atlas CLI command to start the dry run process. You can run this command multiple times without making any changes to your Atlas resources.

atlas kubernetes dry-run --targetNamespace=mongodb-atlas-system --watch

Note

If the --watch flag is not provided, the Atlas CLI exits after completing the installation.

3

When the Kubernetes Job is finished, you can list the events emitted by running the following command:

kubectl -n mongodb-atlas-system get events --field-selector reason=DryRun

This command will return output similar to the following:

LAST SEEN TYPE REASON OBJECT MESSAGE
103s Normal DryRun atlasproject/my-project Would delete (DELETE) /api/atlas/v1.0/groups/6558f184beba40022cbb2043/integrations/SLACK
101s Warning DryRun atlasproject/my-project finished dry run

When --log-level is set to debug, the Atlas Kubernetes Operator provides a detailed diff of the changes that you make to Atlas resources that are managed by the Atlas Kubernetes Operator. This diff is particularly useful when used in conjunction with the Dry Run feature, as it allows you to see the differences between the current state of your Atlas Kubernetes Operator custom resources and the state that the Atlas Kubernetes Operator would apply to your Atlas environment.

This diff feature is informed by comparing the result of any PUT or PATCH requests sent to Atlas with the current state of the Atlas Kubernetes Operator custom resources in your Atlas environment.

Note

To facilitate this comparison, the Atlas Kubernetes Operator makes a GET request to Atlas to learn the current state of resources in Atlas. As such, we recommend that you only set the log level to debug in non-production environments, as this feature can increase the load on Atlas.

To see the differences, you need to set the --log-level=debug flag when running the Atlas Kubernetes Operator command. Because the Atlas Kubernetes Operator uses structured logging, we recommend analyzing the JSON diff in a structured logging viewer for better human readability. The following example shows a rendered Atlas Kubernetes Operator DEBUG log line in YAML format, as displayed in a structured logging viewer:

apiVersion: atlas.mongodb.com/v1
kind: AtlasDeployment
metadata:
name: test
namespace: flex
spec:
flexSpec:
name: test
providerSettings:
backingProviderName: AWS
regionName: US_EAST_1
terminationProtectionEnabled: true -> false
projectRef:
name: test
1 | diff: |
2 | {
3 | - "backupSettings": {
4 | - "enabled": true
5 | - },
6 | - "clusterType": "REPLICASET",
7 | - "connectionStrings": {
8 | - "standard": "...",
9 | - "standardSrv": "..."
10 | - },
11 | - "createDate": "2025-07-21T09:52:06Z",
12 | - "groupId": "687e0db8823af91...",
13 | - "id": "687e0dc6426db7026...",
14 | - "mongoDBVersion": "8.0.11",
15 | - "name": "test",
16 | - "providerSettings": {
17 | - "backingProviderName": "AWS",
18 | - "diskSizeGB": 5,
19 | - "providerName": "FLEX",
20 | - "regionName": "US_EAST_1"
21 | - },
22 | - "stateName": "IDLE",
23 | "tags": [
24 | ],
25 | - "terminationProtectionEnabled": false,
26 | + "terminationProtectionEnabled": true,
27 | - "versionReleaseSystem": "LTS"
28 | }
29 | level: DEBUG
30 | msg: JSON diff
31 | time: 2025-07-22T18:07:01.163+0200
32 | url: https://...

Back

Teams

On this page