Merge pull request #3262 from liyun95/preview

update 2.6.0 upgrade guide

Author: liyun95

site/en/adminGuide/upgrade_milvus_cluster-helm.md

@@ -97,11 +97,8 @@ helm upgrade my-release zilliztech/milvus \
 Wait for the upgrade to complete:
 
 ```bash
-# Monitor the upgrade progress  
-kubectl get pods -l app.kubernetes.io/name=milvus -w
-
 # Verify all pods are ready
-kubectl get pods -l app.kubernetes.io/name=milvus
+kubectl get pods
 ```
 
 ### Step 3: Upgrade to v{{var.milvus_release_version}}
@@ -123,7 +120,7 @@ Confirm your cluster is running the new version:
 
 ```bash
 # Check pod status
-kubectl get pods -l app.kubernetes.io/name=milvus
+kubectl get pods
 
 # Verify Helm release
 helm list

site/en/adminGuide/upgrade_milvus_standalone-docker.md

@@ -22,7 +22,7 @@ Due to security concerns, Milvus upgrades its MinIO to RELEASE.2023-03-20T20-16-
 
 </div>
 
-## Upgrade Milvus by changing its image
+## Upgrade process
 
 In normal cases, you can upgrade Milvus as follows:
 
@@ -42,52 +42,6 @@ In normal cases, you can upgrade Milvus as follows:
     docker compose up -d
     ```
 
-## Migrate the metadata
-
-1. Stop all Milvus components.
-
-    ```
-    docker stop <milvus-component-docker-container-name>
-    ```
-
-2. Prepare the configuration file `migration.yaml` for meta migration.
-
-    ```yaml
-    # migration.yaml
-    cmd:
-      # Option: run/backup/rollback
-      type: run
-      runWithBackup: true
-    config:
-      sourceVersion: 2.1.4   # Specify your milvus version
-      targetVersion: {{var.milvus_release_version}}
-      backupFilePath: /tmp/migration.bak
-    metastore:
-      type: etcd
-    etcd:
-      endpoints:
-        - milvus-etcd:2379  # Use the etcd container name
-      rootPath: by-dev # The root path where data is stored in etcd
-      metaSubPath: meta
-      kvSubPath: kv
-    ```
-
-3. Run the migration container.
-
-    ```
-    # Suppose your docker-compose run with the default milvus network,
-    # and you put migration.yaml in the same directory with docker-compose.yaml.
-    docker run --rm -it --network milvus -v $(pwd)/migration.yaml:/milvus/configs/migration.yaml milvusdb/meta-migration:v2.2.0 /milvus/bin/meta-migration -config=/milvus/configs/migration.yaml
-    ```
-
-4. Start Milvus components again with the new Milvus image.
-
-    ```shell
-    // Run the following only after update the milvus image tag in the docker-compose.yaml
-    docker compose down
-    docker compose up -d
-    ```
-
 ## What's next
 - You might also want to learn how to:
   - [Scale a Milvus cluster](scaleout.md)

site/en/adminGuide/upgrade_milvus_standalone-helm.md

@@ -24,8 +24,10 @@ Upgrading from Milvus 2.5.x to {{var.milvus_release_version}} involves significa
 - **New components**: Introduction of Streaming Node and other new components
 - **Component optimizations**: Enhanced performance and streamlined architecture
 
+This upgrade process ensures proper migration to the new architecture. For more information on architecture changes, refer to <a href="architecture_overview.md">Milvus Architecture Overview</a>.
+
 <div class="alert note">
-This upgrade is <strong>irreversible</strong>. You cannot roll back to a previous version once the upgrade is completed. For details on architectural changes, refer to <a href="architecture_overview.md">Milvus Architecture Overview</a>.
+This upgrade is <strong>irreversible</strong>. You cannot roll back to a previous version once the upgrade is completed.
 </div>
 
 ### Requirements
@@ -61,10 +63,16 @@ The Milvus Helm Charts repo at <code>https://milvus-io.github.io/milvus-helm/</c
 
 ### Step 2: Upgrade to v2.5.16
 
+<div class="alert-note">
+
+Skip this step if your standalone deployment is already running v2.5.16 or higher.
+
+</div>
+
 Upgrade your Milvus standalone to v2.5.16:
 
 ```bash
-helm upgrade my-release milvus/milvus \
+helm upgrade my-release zilliztech/milvus \
   --set image.all.tag="v2.5.16" \
   --reset-then-reuse-values \
   --version={{var.milvus_helm_chart_version}}
@@ -73,9 +81,6 @@ helm upgrade my-release milvus/milvus \
 Wait for the upgrade to complete:
 
 ```bash
-# Monitor the upgrade progress
-kubectl get pods -w
-
 # Verify all pods are ready
 kubectl get pods
 ```
@@ -85,7 +90,7 @@ kubectl get pods
 Once v2.5.16 is running successfully, upgrade to v{{var.milvus_release_version}}:
 
 ```bash
-helm upgrade my-release milvus/milvus \
+helm upgrade my-release zilliztech/milvus \
   --set image.all.tag="v{{var.milvus_release_tag}}" \
   --reset-then-reuse-values \
   --version={{var.milvus_helm_chart_version}}
@@ -97,10 +102,7 @@ Confirm your standalone deployment is running the new version:
 
 ```bash
 # Check pod status
-kubectl get pods -l app.kubernetes.io/name=milvus
-
-# Verify Helm release
-helm list
+kubectl get pods
 ```
 
 For additional support, consult the [Milvus documentation](https://milvus.io/docs) or [community forum](https://github.com/milvus-io/milvus/discussions).

site/en/adminGuide/upgrade_milvus_standalone-operator.md

@@ -12,160 +12,116 @@ title: Upgrade Milvus Standalone with Milvus Operator
 
 # Upgrade Milvus Standalone with Milvus Operator
 
-This guide describes how to upgrade your Milvus standalone with Milvus operator. 
+This guide describes how to upgrade your Milvus standalone deployment from v2.5.x to v{{var.milvus_release_version}} using Milvus Operator.
 
-## Upgrade your Milvus operator
+## Before you start
 
-Run the following command to upgrade the version of your Milvus operator to v{{var.milvus_operator_version}}.
-
-```
-helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
-helm repo update zilliztech-milvus-operator
-helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
-```
-
-Once you have upgraded your Milvus operator to the latest version, you have the following choices:
+### What's new in v{{var.milvus_release_version}}
 
+Upgrading from Milvus 2.5.x to {{var.milvus_release_version}} involves significant architectural changes:
 
-- To upgrade Milvus from v2.2.3, you can [conduct a rolling upgrade](#Conduct-a-rolling-upgrade).
-- To upgrade Milvus from a minor release before v2.2.3 to {{var.milvus_release_version}}, you are advised to [upgrade Milvus by changing its image version](#Upgrade-Milvus-by-changing-its-image).
-- To upgrade Milvus from v2.1.x to {{var.milvus_release_version}}, you need to [migrate the metadata](#Migrate-the-metadata) before the actual upgrade.
+- **New components**: Introduction of Streaming Node and other new components
+- **Component optimizations**: Enhanced performance and streamlined architecture for standalone deployments
 
-> **Note**: It's highly recommended to upgrade one minor version at a time, and to use the latest stable release of that minor version. For example, if you are upgrading from v2.4.x to v2.6.x, you should first upgrade to the latest v2.4.x, then to the latest v2.5.x, and finally to v2.6.x. This ensures that you are using the latest stable release of each minor version, which is more likely to be compatible with your existing data and configurations.
+This upgrade process ensures proper migration to the new architecture. For more information on architecture changes, refer to <a href="architecture_overview.md">Milvus Architecture Overview</a>.
 
-## Conduct a rolling upgrade
+<div class="alert note">
+This upgrade is <strong>irreversible</strong>. You cannot roll back to a previous version once the upgrade is completed.
+</div>
 
-Since Milvus 2.2.3, you can configure Milvus coordinators to work in active-standby mode and enable the rolling upgrade feature for them, so that Milvus can respond to incoming requests during the coordinator upgrades. In previous releases, coordinators are to be removed and then created during an upgrade, which may introduce certain downtime of the service.
+### Requirements
 
-Based on the rolling update capabilities provided by Kubernetes, the Milvus operator enforces an ordered update of the deployments according to their dependencies. In addition, Milvus implements a mechanism to ensure that its components remain compatible with those depending on them during the upgrade, significantly reducing potential service downtime.
+**System requirements:**
+- Kubernetes cluster with Milvus standalone deployed via Milvus Operator
+- `kubectl` configured to access your cluster  
+- Helm 3.x installed
 
-The rolling upgrade feature is disabled by default. You need to explicitly enable it through a configuration file.
+**Compatibility requirements:**
+- Milvus v2.6.0-rc1 is **not compatible** with v{{var.milvus_release_version}}. Direct upgrades from release candidates are not supported.
+- You **must** upgrade to v2.5.16 before upgrading to v{{var.milvus_release_version}}.
 
-```yaml
-apiVersion: milvus.io/v1beta1
-kind: Milvus
-metadata:
-  name: my-release
-spec:
-  components:
-    enableRollingUpdate: true
-    imageUpdateMode: rollingUpgrade # Default value, can be omitted
-    image: milvusdb/milvus:v{{var.milvus_release_tag}}
-```
+## Upgrade process
 
-In this above configuration file, set `spec.components.enableRollingUpdate` to `true` and set `spec.components.image` to the desired Milvus version. 
+### Step 1: Upgrade Milvus Operator
 
-By default, Milvus performs a rolling upgrade for coordinators in an ordered way, in which it replaces the coordinator pod images one after another. To reduce the upgrade time, consider setting `spec.components.imageUpdateMode` to `all` so that Milvus replaces all pod images at the same time.
+First, upgrade your Milvus Operator to v{{var.milvus_operator_version}}:
 
-```yaml
-apiVersion: milvus.io/v1beta1
-kind: Milvus
-metadata:
-  name: my-release
-spec:
-  components:
-    enableRollingUpdate: true
-    imageUpdateMode: all
-    image: milvusdb/milvus:v{{var.milvus_release_tag}}
+```bash
+helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
+helm repo update zilliztech-milvus-operator
+helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
 ```
 
-You can set `spec.components.imageUpdateMode` to `rollingDowngrade` to have Milvus replace coordinator pod images with a lower version.
+Verify the operator upgrade:
 
-```yaml
-apiVersion: milvus.io/v1beta1
-kind: Milvus
-metadata:
-  name: my-release
-spec:
-  components:
-    enableRollingUpdate: true
-    imageUpdateMode: rollingDowngrade
-    image: milvusdb/milvus:<some-older-version>
+```bash
+kubectl -n milvus-operator get pods
 ```
 
-Then save your configuration as a YAML file (for example, `milvusupgrade.yaml`) and patch this configuration file to your Milvus instance as follows:
+### Step 2: Upgrade your Milvus standalone
 
-```shell
-kubectl patch -f milvusupgrade.yaml --patch-file milvusupgrade.yaml --type merge 
-```
+#### 2.1 Upgrade to v2.5.16
+
+<div class="alert-note">
 
-## Upgrade Milvus by changing its image
+Skip this step if your standalone deployment is already running v2.5.16 or higher.
 
-In normal cases, you can simply update your Milvus to the latest by changing its image. However, note that there will be a certain downtime when upgrading Milvus in this way.
+</div>
 
-Compose a configuration file as follows and save it as **milvusupgrade.yaml**:
+Create a configuration file `milvusupgrade.yaml` to upgrade to v2.5.16:
 
 ```yaml
 apiVersion: milvus.io/v1beta1
 kind: Milvus
 metadata:
-    name: my-release
-labels:
-    app: milvus
+  name: my-release  # Replace with your actual release name
 spec:
-  # Omit other fields ...
   components:
-   image: milvusdb/milvus:v{{var.milvus_release_tag}}
+    image: milvusdb/milvus:v2.5.16
 ```
 
-Then run the following to perform the upgrade:
+Apply the configuration:
 
-```shell
+```bash
 kubectl patch -f milvusupgrade.yaml --patch-file milvusupgrade.yaml --type merge
 ```
 
-## Migrate the metadata
+Wait for completion:
 
-Since Milvus 2.2.0, the metadata is incompatible with that in previous releases. The following example snippets assume an upgrade from Milvus 2.1.4 to Milvus v{{var.milvus_release_version}}.
+```bash
+# Verify all pods are ready
+kubectl get pods
+```
 
-### 1. Create a `.yaml` file for metadata migration
+#### 2.2 Upgrade to v{{var.milvus_release_version}}
 
-Create a metadata migration file. The following is an example. You need to specify the `name`, `sourceVersion`, and `targetVersion` in the configuration file. The following example sets the `name` to `my-release-upgrade`, `sourceVersion` to `v2.1.4`, and `targetVersion` to `v{{var.milvus_release_version}}`. This means that your Milvus instance will be upgraded from v2.1.4 to v{{var.milvus_release_version}}.
+Once v2.5.16 is running successfully, upgrade to v{{var.milvus_release_version}}:
 
-```
+Update your configuration file (`milvusupgrade.yaml` in this example):
+
+```yaml
 apiVersion: milvus.io/v1beta1
-kind: MilvusUpgrade
+kind: Milvus
 metadata:
-  name: my-release-upgrade
+  name: my-release  # Replace with your actual release name
 spec:
-  milvus:
-    namespace: default
-    name: my-release
-  sourceVersion: "v2.1.4"
-  targetVersion: "v{{var.milvus_release_version}}"
-  # below are some omit default values:
-  # targetImage: "milvusdb/milvus:v{{var.milvus_release_tag}}"
-  # toolImage: "milvusdb/meta-migration:v2.2.0"
-  # operation: upgrade
-  # rollbackIfFailed: true
-  # backupPVC: ""
-  # maxRetry: 3
+  components:
+    image: milvusdb/milvus:v{{var.milvus_release_tag}}
 ```
 
-### 2. Apply the new configuration
-
-Run the following command to apply the new configuration.
+Apply the final upgrade:
 
+```bash
+kubectl patch -f milvusupgrade.yaml --patch-file milvusupgrade.yaml --type merge
 ```
-$ kubectl create -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvusupgrade.yaml
-```
-
-
 
-### 3. Check the status of metadata migration
+## Verify the upgrade
 
-Run the following command to check the status of your metadata migration.
+Confirm your standalone deployment is running the new version:
 
+```bash
+# Check pod status
+kubectl get pods
 ```
-kubectl describe milvus release-name
-```
-
-The status of `ready` in the output means that the metadata migration is successful.
-
-Or, you can also run `kubectl get pod` to check all the pods. If all the pods are `ready`, the metadata migration is successful.
-
-
-
-### 4. Delete `my-release-upgrade`
 
-When the upgrade is successful, delete `my-release-upgrade` in the YAML file.
+For additional support, consult the <a href="https://milvus.io/docs">Milvus documentation</a> or <a href="https://github.com/milvus-io/milvus/discussions">community forum</a>.