> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

<!--
Tab options on this page. Append to the .md URL to filter:
  ?tabs=<id,...>   select specific tabs (e.g. ?tabs=nodejs,shell)
  ?allTabs=true    include every tab
  (no param)       default: one tab per tabset

Available tabs:
  other tabs: kubectl-upgrade-procedure
-->

# Upgrade Atlas Kubernetes Operator v1.x to v2.x

Atlas Kubernetes Operator doesn't support Atlas Infinite Database clusters in public preview. To learn which features Atlas Infinite Database supports in public preview, see [Atlas Infinite Database Edition](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing/). To learn more about preview features, see [Preview Features](https://www.mongodb.com/docs/preview-features/).

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

### Kubectl

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` commands against each of these Kubernetes clusters. To simplify this, you can configure each of the Kubernetes contexts with the following commands:

   ```sh
   kubectl config set-cluster old --server=https://<OLD_CLUSTER_URL>
   kubectl config set-context old --cluster=old

   kubectl config set-cluster new --server=https://<NEW_CLUSTER_URL>
   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 provisioned Kubernetes cluster.

   ```sh
   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:

   ```sh
   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:

   ```yaml
   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:

   ```yaml
   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:

   ```sh
   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:

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