Docs Menu
Docs Home
/
MongoDB Atlas
/
MongoDB Atlas Kubernetes Operator

Upgrade Atlas Kubernetes Operator v1.x to v2.x

You can upgrade from a v1.x Atlas Kubernetes Operator deployment by following this upgrade procedure. To do so, you will need to update your existing MongoDB custom resource specification, as YAML field names in v2.x have changed and all credentials are now passed as Kubernetes Secrets. Moreover, you must spin up a new Kubernetes cluster, deploy Atlas Kubernetes Operator v2.x there, and then transition the management of your existing Mongodb Atlas database instance to this new Atlas Kubernetes Operator v2.x deployment.

Procedure

1

Deploy a new Kubernetes cluster.

With this new cluster deployed, you now have two Kubernetes clusters. The following steps require that you run kubectl commmands against each of these Kubernetes clusters. To simplify this, you can configure each of the Kubernetes contexts with the following commands:

kubectl config set-cluster old --server=https://<OLD_CLUSTER_ULR>
kubectl config set-context old --cluster=old
kubectl config set-cluster new --server=https://<NEW_CLUSTER_ULR>
kubectl config set-context new --cluster=new
2

Deploy Atlas Kubernetes Operator v2.x to your new K8s cluster.

Replace the <version> placeholder in the following command with your desired Atlas Kubernetes Operator version, and run the command to deploy Atlas Kubernetes Operator to your newly provsioned Kubernetes cluster.

kubectl use-context new
kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/<version>/deploy/all-in-one.yaml
3

Scale the replica count of your v1.x Atlas Kubernetes Operator to zero.

Scale the replica count in your v1.x Atlas Kubernetes Operator deployment to 0 in your "old" Kubernetes cluster, so that it will no longer monitor and update the associated MongoDB Atlas deployment by running:

kubectl use-context old
kubectl scale --replicas=0 deployment.apps/mongodb-atlas-operator -n mongodb-atlas-system
4

Update existing AtlasProject CR definitions.

Update your existing YAML definitions to align with the following example, so they reference the following API secrets and credentials as needed:

CR Section
Cloud Provider
v1.x
v2.x
.spec.alertConfiguration.notifications
APIToken
APITokenRef
DatadogAPIKey
DatadogAPIKeyRef
FlowdockTokenAPI
FlowdockTokenAPIRef
OpsGenieAPIKey
OpsGenieAPIKeyRef
VictorOpsAPIKey
VictorOpsSecretRef
VictorOpsRoutingKey
VictorOpsSecretRef (expected to have both VictorOps values)
.spec.encryptionAtRest
AWS
AccessKeyID, SecretAccessKey, CustomerMasterKeyID, RoleID
CloudProviderAccessRoles
Azure
SubscriptionID, KeyVaultName, KeyIdentifier, Secret
secretRef
GCP
ServiceAccountKey, KeyVersionResourceID
secretRef

As a result of the updates you made in the previous steps, your resulting CRD might look similar to the following example:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
  labels:
    app.kubernetes.io/version: 1.6.0
spec:
  name: Test Atlas Operator Project
  projectIpAccessList:
    - cidrBlock: "<Public-CIDR-of-K8s-Cluster>"
      comment: "This CIDR is added to your Atlas Project's Access List."
5

Update existing AtlasDeployment CR definitions.

  • If your existing YAML definition includes an advancedDeploymentSpec, rename that section to deploymentSpec.

  • If your existing YAML definition includes a deploymentSpec, update that section to align with the following deploymentSpec example.

  • If your existing YAML definition includes a serverlessSpec, no changes are required.

As a result of the updates you made in the previous steps, your resulting CRD might look similar to the following example:

deploymentSpec:
  clusterType: REPLICASET
  name: advanced-deployment-2
  mongoDBMajorVersion: "5.0"
  replicationSpecs:
    - regionConfigs:
        regionName: EASTERN_US
        - electableSpecs:
            nodeCount: 4
            instanceSize: M10
          autoScaling:
            compute:
              scaleDownEnabled: true
              enabled: true
              minInstanceSize: M10
              maxInstanceSize: M20
          providerName: GCP
          backingProviderName: GCP
          priority: 7
        regionName: US_EAST_2
        - electableSpecs:
            nodeCount: 1
            instanceSize: M10
          autoScaling:
            compute:
              scaleDownEnabled: true
              enabled: true
              minInstanceSize: M10
              maxInstanceSize: M20
          providerName: AWS
          backingProviderName: AWS
          priority: 6
6

Apply the newly generated AKO 2.x compatible resources in your new Kubernetes cluster.

Run the following command to deploy your updated Atlas Kubernetes Operator resources:

kubectl use-context new
kubectl apply -f resource.yaml
7

Scale up the number of replica set members in the upgraded deployment.

Set the replica count to 1 in your Atlas Kubernetes Operator 2.x deployment, so that the new Atlas Kubernetes Operator picks up migrated resources. Because these resources are semantically equal to your existing AKO 1.9.x custom resources, your MongoDB Atlas resources themselves won't change.

8

Verify new resource statuses.

Run the following commands to verify the statuses of your newly deployed custom resources:

kubectl use-context new
kubectl describe atlasprojects <your-project-name>
kubectl describe atlasdeployments <your-deployment-name>

Back

Changelog