From 0b22648e76cc082f67049a3241c8c72c1a3de6f8 Mon Sep 17 00:00:00 2001 From: Piotr Zaniewski Date: Tue, 28 Jan 2025 16:42:49 +0100 Subject: [PATCH 1/4] infra: introduce column component --- src/components/Column/index.js | 17 +++++++++++++++++ src/components/Columns/index.js | 17 +++++++++++++++++ src/theme/MDXComponents.js | 11 +++++++++++ 3 files changed, 45 insertions(+) create mode 100644 src/components/Column/index.js create mode 100644 src/components/Columns/index.js create mode 100644 src/theme/MDXComponents.js diff --git a/src/components/Column/index.js b/src/components/Column/index.js new file mode 100644 index 000000000..5213dd1e6 --- /dev/null +++ b/src/components/Column/index.js @@ -0,0 +1,17 @@ +import React from 'react'; +// Import clsx library for conditional classes. +import clsx from 'clsx'; + +// Define the Column component as a function +// with children, className, style as properties +// Look https://infima.dev/docs/ for learn more +// Style only affects the element inside the column, but we could have also made the same distinction as for the classes. +export default function Column({ children , className, style }) { + return ( + +
+ {children} +
+ + ); +} \ No newline at end of file diff --git a/src/components/Columns/index.js b/src/components/Columns/index.js new file mode 100644 index 000000000..dfe7a0b91 --- /dev/null +++ b/src/components/Columns/index.js @@ -0,0 +1,17 @@ +import React from 'react'; +// Import clsx library for conditional classes. +import clsx from 'clsx'; +// Define the Columns component as a function +// with children, className, and style as properties +// className will allow you to pass either your custom classes or the native infima classes https://infima.dev/docs/layout/grid. +// Style" will allow you to either pass your custom styles directly, which can be an alternative to the "styles.module.css" file in certain cases. +export default function Columns({ children , className , style }) { + return ( + // This section encompasses the columns that we will integrate with children from a dedicated component to allow the addition of columns as needed +
+
+ {children} +
+
+ ); +} \ No newline at end of file diff --git a/src/theme/MDXComponents.js b/src/theme/MDXComponents.js new file mode 100644 index 000000000..077bba9ca --- /dev/null +++ b/src/theme/MDXComponents.js @@ -0,0 +1,11 @@ + import React from 'react'; + // Importing the original mapper + our components according to the Docusaurus doc + import MDXComponents from '@theme-original/MDXComponents'; + import Columns from '@site/src/components/Columns'; + import Column from '@site/src/components/Column'; + export default { + // Reusing the default mapping + ...MDXComponents, + Columns, + Column, + }; \ No newline at end of file From a655e7511c07b8b4fc23aac6183d08fcc0cecec7 Mon Sep 17 00:00:00 2001 From: Piotr Zaniewski Date: Tue, 28 Jan 2025 13:28:30 +0100 Subject: [PATCH 2/4] feat(migration): vcluster helm values comparison Adding a detailed comparison of the helm values between pre 0.19 and post 0.19 versions of vCluster. --- docs/_partials/0-20.migration.mdx | 539 ++++++++++++++++++ .../reference/migrations/0-20-migration.mdx | 181 +----- .../reference/migrations/0-20-migration.mdx | 181 +----- .../reference/migrations/0-20-migration.mdx | 181 +----- .../reference/migrations/0-20-migration.mdx | 181 +----- 5 files changed, 547 insertions(+), 716 deletions(-) create mode 100644 docs/_partials/0-20.migration.mdx diff --git a/docs/_partials/0-20.migration.mdx b/docs/_partials/0-20.migration.mdx new file mode 100644 index 000000000..9a44ed6a3 --- /dev/null +++ b/docs/_partials/0-20.migration.mdx @@ -0,0 +1,539 @@ + +import Columns from '@site/src/components/Columns'; + + +import Column from '@site/src/components/Column'; + +import DeployChanges from '../../vcluster/_partials/manage/deploy-changes.mdx' + + +As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring +a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. + +

+ +:::warning +Pre-v0.20.0 `values.yaml` files are not compatible with v0.20.0. You need to convert to the new format to use the new vCluster CLI and upgrade existing vCluster instances. +::: + + +Upgrade vCluster v0.19 to v0.20+ by following these steps: + +1. [Upgrade the vCluster CLI](#upgrade-the-cli). +1. [Convert your Helm values configuration file to the new `vcluster.yaml` configuration file](#convert-your-valuesyaml-to-vclusteryaml). +1. [Use your new `vcluster.yaml` file to upgrade your vCluster instance](#upgrade-your-vcluster-instance). + +## Supported legacy versions + +Loft Labs has tested the conversion path from v0.19.x to v0.20.0 and therefore recommends moving to v0.19.x before converting to v0.20.0. + +Conversions from vCluster versions prior to 0.19.x might work but have not been tested extensively. + +## Before you begin + +* Helm version is >= v.3.10.0. +* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. +* Review the [list of changes](/vcluster/cli/0-20-cli-changes) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. + +## Upgrade the CLI + +Before upgrading virtual cluster instances, upgrade to the latest version of the vCluster CLI. + +```BASH +vcluster upgrade --version +``` + +Replace: + +- `` with the version of vCluster you want to upgrade to. + + + +A new command has been added to support converting from the old `values.yaml` format to the new `vcluster.yaml`. + +```BASH +Usage: + vcluster convert config [flags] +Flags: + --distro string Kubernetes distro used + -f, --file string Path to the input file + -h, --help Help for config + -o, --output string Prints the output in the specified format. Allowed values: yaml, json (default "yaml") +``` + +## Get your previous `values.yaml` (Optional) + +If you have the existing `values.yaml` that you provided to your existing vCluster, you can skip this step. + +### Get the user-suppied values + +If you don't have the `values.yaml`, use Helm to retrieve the user defined configuration for your currently running virtual cluster. + +```bash +helm get values -n > values.yaml +``` + +Replace: + +- `` with the name of your vCluster instance. +- `` with the namespace that vCluster runs in. + +This uses `--revision 0` under the hood. Adjust this accordingly to receive the values of your latest revision. See the [Helm docs](https://helm.sh/docs/helm/helm_history/) for how to fetch revision history. + +### Get the default values + +If the `helm get` provides an empty file, then you used the default configuration to deploy your vCluster. You still need to +supply a `values.yaml` to the convert due to changes in defaults. + +```bash +helm get values -n --all > values.yaml +``` + +Replace: + +- `` with the name of your vCluster instance. +- `` with the namespace that vCluster runs in. + + +## Convert your `values.yaml` to `vcluster.yaml` + +Convert your `values.yaml` to the new `vcluster.yaml` configuration file format by running: + +```BASH +vcluster convert config --distro -f > vcluster.yaml +``` + +Replace: + +- `` with your virtual cluster's existing Kubernetes distribution. **You can't change the Kubernetes distribution or backing store during an upgrade**. +- `` with the path to the `values.yaml`file you used to configure your pre-v0.20 vCluster instance. + + +For example: + +```BASH +vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml +``` + +### Notes about Changes for your `vcluster.yaml` + + + +#### Scheduling of the StatefulSet + +Since the scheduling of the control plane pod changed in v0.20+, the converted `vcluster.yaml` includes retaining +the original scheduling pattern as it is can't be changed between upgrades. + +#### Image repository +By default, the conversion does not set the repo of the images to use the open source repo, but upgrade you to use +the vCluster Pro repo. This allows users to seamlessly test and adopt any vCluster Pro feature without disrupting their existing +open source features. The Pro features are integrated into the Pro image but remain inactive by default to ensure that your experience remains consistent with the open source version unless you specifically activate Pro features. + +If you want to continue using the open source image, you need to explicitly set the open source repository for your images. + +```yaml +controlPlane: + statefulSet: + image: + repository: loft-sh/vcluster-oss +``` + +#### Supporting EKS distributions + +The v0.20 removed the support of EKS as a virtual cluster distribution. + +:::note reminder +The Kubernetes distribution of the virtual cluster doesn't need to match the distribution of your host cluster. You can use any distribution of vCluster to deploy vCluster on EKS clusters. +::: + +In order to continue using your virtual clusters that have EKS as the distribution, you can convert to using the k8s distribution and replace the images with the EKS images. While this was tested when v0.20.0 was released, it is not continuously tested. It's recommended spinning up new virtual clusters with the k8s distribution and migrate your workloads to them. + +```bash +vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml +``` + +After the conversion, you need to update the `vcluster.yaml` and change the images to be used. Refer to the EKS registries for [kube-apiserver](https://gallery.ecr.aws/eks-distro/kubernetes/kube-apiserver), [controller-manager](https://gallery.ecr.aws/eks-distro/kubernetes/kube-controller-manager) and [kube-scheduler](https://gallery.ecr.aws/eks-distro/kubernetes/kube-scheduler) for the specific tags you might want to use. + +**Example using EKS v1.30:** + +```yaml +controlplane: + distro: + k8s: + enabled: true + apiserver: + image: + registry: "public.ecr.aws" + repository: "eks-distro/kubernetes/kube-apiserver" + tag: "v1.30.2-eks-1-30-10" + controllerManager: + image: + registry: "public.ecr.aws" + repository: "eks-distro/kubernetes/kube-controller-manager" + tag: "v1.30.2-eks-1-30-10" + scheduler: + image: + registry: "public.ecr.aws" + repository: "eks-distro/kubernetes/kube-scheduler" + tag: "v1.30.2-eks-1-30-10" +``` + +## Upgrade your vCluster instance + +:::warning Downgrading vCluster instances is NOT supported +While downgrading to an older version of the vCluster CLI is supported, you cannot downgrade virtual cluster instances to a prior version of vCluster (for example, from 0.20+ back to 0.19). Make sure you have tested the upgrade sufficiently before rolling out this change to critical systems. +::: + + + + +## Changes in the vCluster values between 0.19 and 0.20+ + +The following is a reference for how specific 0.19 fields map to (or have changed in) 0.20+. + +autoDeletePersistentVolumeClaims + + + **0.19**: + ```yaml + autoDeletePersistentVolumeClaims: false + ``` + + + **0.20+**: + ```yaml + controlPlane: + backingStore: + etcd: + deploy: + statefulSet: + persistence: + volumeClaim: + retentionPolicy: Delete + ``` + + + +fallbackHostDns + + + **0.19**: + ```yaml + fallbackHostDns: false + ``` + + + **0.20+**: + ```yaml + networking: + advanced: + fallbackHostCluster: true + ``` + + + +init Section + + + **0.19**: + ```yaml + init: + helm: [] + manifests: '---' + manifestsTemplate: "" + ``` + + + **0.20+**: + ```yaml + experimental: + deploy: + vcluster: + helm: [] + manifests: '---' + manifestsTemplate: "" + ``` + + + +isolation.nodeProxyPermission.enabled + + + **0.19**: + ```yaml + isolation: + nodeProxyPermission: + enabled: false + ``` + + + **0.20+**: + + This setting is removed. Instead, replicate the same RBAC permissions using `rbac.clusterRole.extraRules` or `rbac.clusterRole.overwriteRules`: + ```yaml + rbac: + clusterRole: + enabled: true + extraRules: + - apiGroups: [""] + resources: ["nodes/proxy"] + verbs: ["get", "watch", "list"] + ``` + + + +isolation.podSecurityStandard + + + **0.19**: + ```yaml + isolation: + podSecurityStandard: baseline + ``` + + + **0.20+**: + ```yaml + policies: + podSecurityStandard: Baseline + ``` + + + +mapServices, monitoring.serviceMonitor, noopSyncer, openshift + + + **0.19**: + ```yaml + mapServices: + fromHost: [] + fromVirtual: [] + monitoring: + serviceMonitor: + enabled: false + noopSyncer: + enabled: false + synck8sService: false + openshift: + enable: false + ``` + + + **0.20+**: + + mapServices → `networking.replicateServices`: + ```yaml + networking: + replicateServices: + fromHost: [] + fromVirtual: [] + ``` + monitoring.serviceMonitor.enabled → `controlPlane.serviceMonitor.enabled`: + ```yaml + controlPlane: + serviceMonitor: + enabled: false + ``` + noopSyncer → `experimental.syncSettings`: + ```yaml + experimental: + syncSettings: + disableSync: false + rewriteKubernetesService: false + ``` + openshift.enable → Replace with extra RBAC rules: + ```yaml + rbac: + role: + extraRules: + - apiGroups: [""] + resources: ["endpoints/restricted"] + verbs: ["create"] + ``` + + + + +pro / proLicenseSecret + + + + **0.19**: + ```yaml + pro: false + proLicenseSecret: "" + ``` + + + **0.20+**: + ```yaml + pro: false + # proLicenseSecret: ${namespace}/${name} + external: + platform: + apiKey: + secretName: ${name} + namespace: ${namespace} + ``` + + + +proxy, securityContext, and service + + + **0.19**: + ```yaml + proxy: + metricsServer: + nodes: + enabled: false + pods: + enabled: false + securityContext: + allowPrivilegeEscalation: false + runAsGroup: 0 + runAsUser: 0 + service: + externalIPs: [] + externalTrafficPolicy: "" + loadBalancerAnnotations: {} + loadBalancerClass: "" + loadBalancerIP: "" + loadBalancerSourceRanges: [] + type: ClusterIP + ``` + + + **0.20+**: + + proxy.metricsServer → `integrations.metricsServer`: + ```yaml + integrations: + metricsServer: + enabled: true + nodes: true + pods: true + ``` + securityContext → `controlPlane.statefulSet.security.containerSecurityContext`: + ```yaml + controlPlane: + statefulSet: + security: + containerSecurityContext: + allowPrivilegeEscalation: false + runAsGroup: 0 + runAsUser: 0 + ``` + service → `controlPlane.service.spec`: + ```yaml + controlPlane: + service: + annotations: {} + spec: + externalIPs: [] + externalTrafficPolicy: "" + type: ClusterIP + loadBalancerClass: "" + loadBalancerIP: "" + loadBalancerSourceRanges: [] + loadBalancerAnnotations: {} + ``` + + + +sync.fake-\* + + + **0.19**: + ```yaml + sync: + fake-nodes: + enabled: true + fake-persistentvolumes: + enabled: true + ``` + + + **0.20+**: + + Disable is an invers of enable and is acceptable in this context. + + `fake-nodes.enabled = true` → disable node sync from the host: + ```yaml + sync: + fromHost: + nodes: + enabled: false + ``` + `fake-persistentvolumes.enabled = true` → disable PV sync to the host: + ```yaml + sync: + toHost: + persistentVolumes: + enabled: false + ``` + + + + +### Quick reference table + +| Old (0.19) | New (0.20+) | +| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | +| `autoDeletePersistentVolumeClaims` | `controlPlane.backingStore.etcd.deploy.statefulSet.persistence.volumeClaim.retentionPolicy: Delete` | +| `fallbackHostDns` | `networking.advanced.fallbackHostCluster` | +| `init.helm/manifests/manifestsTemplate` | `experimental.deploy.vcluster.helm/manifests/manifestsTemplate` | +| `isolation.nodeProxyPermission.enabled` | Replaced by extra RBAC rules in `rbac.clusterRole.extraRules` | +| `isolation.podSecurityStandard` | `policies.podSecurityStandard` | +| `mapServices` | `networking.replicateServices` | +| `monitoring.serviceMonitor.enabled` | `controlPlane.serviceMonitor.enabled` | +| `noopSyncer` | `experimental.syncSettings` | +| `openshift.enable` | Add extra rules in `rbac.role.extraRules` | +| `proLicenseSecret` | `external.platform.apiKey.secretName` / `namespace` | +| `proxy.metricsServer.nodes/pods` | `integrations.metricsServer.enabled/nodes/pods` | +| `securityContext` | `controlPlane.statefulSet.security.containerSecurityContext` | +| `service.*` | `controlPlane.service.spec` | +| `sync.fake-nodes/fake-persistentvolumes` | `sync.fromHost.nodes.enabled = false` / `sync.toHost.persistentVolumes.enabled = false` | + + +## Compare Helm values between versions + +:::tip compare version values +You can easily compare values files between versions to see the changes. +::: + +You can spin up two virtual clusters, one at older version, such as 0.19 and one at newer version, for example 0.20+. +Retrieve their computed `values.yaml` files and compare them with a simple `diff`: + +```bash +VERSION_OLD="0.19.7" +VERSION_NEW="0.20.0" +NAMESPACE_OLD="vcluster-old" +NAMESPACE_NEW="vcluster-new" +RELEASE_OLD="vcluster-${VERSION_OLD//./-}" +RELEASE_NEW="vcluster-${VERSION_NEW//./-}" + +helm upgrade --install $RELEASE_OLD vcluster \ + --repo https://charts.loft.sh \ + --namespace $NAMESPACE_OLD \ + --repository-config='' \ + --version $VERSION_OLD \ + --create-namespace + +helm upgrade --install $RELEASE_NEW vcluster \ + --repo https://charts.loft.sh \ + --namespace $NAMESPACE_NEW \ + --repository-config='' \ + --version $VERSION_NEW \ + --create-namespace + +helm get values $RELEASE_OLD -n $NAMESPACE_OLD --all > ${VERSION_OLD}.yaml +helm get values $RELEASE_NEW -n $NAMESPACE_NEW --all > ${VERSION_NEW}.yaml + +diff -u ${VERSION_OLD}.yaml ${VERSION_NEW}.yaml > v${VERSION_OLD}-to-v${VERSION_NEW}.diff +``` + +## Related content + +- [vCluster config reference](/vcluster/configure/vcluster-yaml/) for full configuration details. + diff --git a/vcluster/reference/migrations/0-20-migration.mdx b/vcluster/reference/migrations/0-20-migration.mdx index 398a2e1cc..297d9fda6 100644 --- a/vcluster/reference/migrations/0-20-migration.mdx +++ b/vcluster/reference/migrations/0-20-migration.mdx @@ -4,183 +4,6 @@ description: How to migrate from pre-v0.20 to v0.20 release. sidebar_position: 2 --- -import DeployChanges from '../../_partials/manage/deploy-changes.mdx' +import MigrationGuide from '@site/docs/_partials/0-20.migration.mdx'; - -As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring -a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. - -

- -:::warning -Pre-v0.20.0 `values.yaml` files are not compatible with v0.20.0. You need to convert to the new format in order to use the new vCluster CLI and upgrade existing vCluster instances. -::: - - -Upgrade vCluster v0.19 to v0.20+ by following these steps: - -1. [Upgrade the vCluster CLI](#upgrade-the-cli). -1. [Convert your Helm values configuration file to the new `vcluster.yaml` configuration file](#convert-your-valuesyaml-to-vclusteryaml). -1. [Use your new `vcluster.yaml` file to upgrade your vCluster instance](#upgrade-your-vcluster-instance). - -## Supported legacy versions - -Loft Labs has tested the conversion path from v0.19.x to v0.20.0 and therefore recommends moving to v0.19.x before converting to v0.20.0. - -Conversions from vCluster versions prior to 0.19.x might work but have not been tested extensively. - -## Before you begin - -* Helm version is >= v.3.10.0. -* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. -* Review the [list of changes](../../cli/0-20-cli-changes/) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. - - -## Upgrade the CLI - -Before upgrading virtual cluster instances, upgrade to the latest version of the vCluster CLI. - -```BASH -vcluster upgrade --version -``` - -Replace: - -- `` with the version of vCluster you want to upgrade to. - - - -A new command has been added to support converting from the old `values.yaml` format to the new `vcluster.yaml`. - -```BASH -Usage: - vcluster convert config [flags] -Flags: - --distro string Kubernetes distro used - -f, --file string Path to the input file - -h, --help Help for config - -o, --output string Prints the output in the specified format. Allowed values: yaml, json (default "yaml") -``` - -## Get your previous `values.yaml` (Optional) - -If you have the existing `values.yaml` that you provided to your existing vCluster, you can skip this step. - -### Get the User-Suppied Values - -If you don't have the `values.yaml`, use Helm to retrieve the user defined configuration for your currently running virtual cluster. - -```bash -helm get values -n > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - -This uses `--revision 0` under the hood. Adjust this accordingly to receive the values of your latest revision. See the [Helm docs](https://helm.sh/docs/helm/helm_history/) for how to fetch revision history. - -### Get the Default Values - -If the `helm get` provides an empty file, then you used the default configuration to deploy your vCluster. You will still need to -supply a `values.yaml` to the convert due to changes in defaults. - -```bash -helm get values -n --all > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - - -## Convert your `values.yaml` to `vcluster.yaml` - -Convert your `values.yaml` to the new `vcluster.yaml` configuration file format by running: - -```BASH -vcluster convert config --distro -f > vcluster.yaml -``` - -Replace: - -- `` with your virtual cluster's existing Kubernetes distribution. **You can't change the Kubernetes distribution or backing store during an upgrade**. -- `` with the path to the `values.yaml`file you used to configure your pre-v0.20 vCluster instance. - - -For example: - -```BASH -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -### Notes about Changes for your `vcluster.yaml` - -#### Scheduling of the StatefulSet -Since the scheduling of the control plane pod changed in v0.20, the converted `vcluster.yaml` will include retaining -the original scheduling pattern as it is can't be changed between upgrades. - -#### Image Repository -By default, the conversion will not set the repo of the images to use the open source repo, but upgrade you to use -the vCluster Pro repo. This allows users to seamlessly test and adopt any vCluster Pro feature without disrupting their existing -open-source functionality. The Pro features are integrated into the Pro image but remain inactive by default to ensure that your experience remains consistent with the open-source version unless you specifically activate Pro features. - -If you want to continue using the open-source image, you will need to explicitly set the open source repository for your images. - -```yaml -controlPlane: - statefulSet: - image: - repository: loft-sh/vcluster-oss -``` - -#### Supporting EKS Distributions - -In v0.20, we have removed the support of EKS as a virtual cluster distribution. Reminder: The Kubernetes distribution of the virtual cluster doesn't need to match the the distribution of your host cluster. You can use any distribution of vCluster to deploy vCluster on EKS clusters. - -In order to continue using your virtual clusters that have EKS as the distribution, you can convert to using the k8s distribution and replace the images with the EKS images. While this was tested when v0.20.0 was released, it is not continuously tested. We recommend spinning up new virtual clusters with the k8s distribution and migrate your workloads to them. - -```bash -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -After the conversion, you will need to update the `vcluster.yaml` and change the images to be used. Refer to the EKS registries for [kube-apiserver](https://gallery.ecr.aws/eks-distro/kubernetes/kube-apiserver), [controller-manager](https://gallery.ecr.aws/eks-distro/kubernetes/kube-controller-manager) and [kube-scheduler](https://gallery.ecr.aws/eks-distro/kubernetes/kube-scheduler) for the specific tags you might want to use. - -**Example using EKS v1.30:** - -```yaml -controlplane: - distro: - k8s: - enabled: true - apiserver: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-apiserver" - tag: "v1.30.2-eks-1-30-10" - controllerManager: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-controller-manager" - tag: "v1.30.2-eks-1-30-10" - scheduler: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-scheduler" - tag: "v1.30.2-eks-1-30-10" -``` - -## Upgrade your vCluster instance - -:::warning Downgrading vCluster instances is NOT supported -While downgrading to an older version of the vCluster CLI is supported, you cannot downgrade virtual cluster instances to a prior version of vCluster (for example, from 0.20 back to 0.19). Make sure you have tested the upgrade sufficiently before rolling out this change to critical systems. -::: - - - - -## Related content - -- [vCluster config reference](/vcluster/configure/vcluster-yaml/) for full configuration details. + diff --git a/vcluster_versioned_docs/version-0.20.0/reference/migrations/0-20-migration.mdx b/vcluster_versioned_docs/version-0.20.0/reference/migrations/0-20-migration.mdx index 398a2e1cc..297d9fda6 100644 --- a/vcluster_versioned_docs/version-0.20.0/reference/migrations/0-20-migration.mdx +++ b/vcluster_versioned_docs/version-0.20.0/reference/migrations/0-20-migration.mdx @@ -4,183 +4,6 @@ description: How to migrate from pre-v0.20 to v0.20 release. sidebar_position: 2 --- -import DeployChanges from '../../_partials/manage/deploy-changes.mdx' +import MigrationGuide from '@site/docs/_partials/0-20.migration.mdx'; - -As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring -a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. - -

- -:::warning -Pre-v0.20.0 `values.yaml` files are not compatible with v0.20.0. You need to convert to the new format in order to use the new vCluster CLI and upgrade existing vCluster instances. -::: - - -Upgrade vCluster v0.19 to v0.20+ by following these steps: - -1. [Upgrade the vCluster CLI](#upgrade-the-cli). -1. [Convert your Helm values configuration file to the new `vcluster.yaml` configuration file](#convert-your-valuesyaml-to-vclusteryaml). -1. [Use your new `vcluster.yaml` file to upgrade your vCluster instance](#upgrade-your-vcluster-instance). - -## Supported legacy versions - -Loft Labs has tested the conversion path from v0.19.x to v0.20.0 and therefore recommends moving to v0.19.x before converting to v0.20.0. - -Conversions from vCluster versions prior to 0.19.x might work but have not been tested extensively. - -## Before you begin - -* Helm version is >= v.3.10.0. -* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. -* Review the [list of changes](../../cli/0-20-cli-changes/) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. - - -## Upgrade the CLI - -Before upgrading virtual cluster instances, upgrade to the latest version of the vCluster CLI. - -```BASH -vcluster upgrade --version -``` - -Replace: - -- `` with the version of vCluster you want to upgrade to. - - - -A new command has been added to support converting from the old `values.yaml` format to the new `vcluster.yaml`. - -```BASH -Usage: - vcluster convert config [flags] -Flags: - --distro string Kubernetes distro used - -f, --file string Path to the input file - -h, --help Help for config - -o, --output string Prints the output in the specified format. Allowed values: yaml, json (default "yaml") -``` - -## Get your previous `values.yaml` (Optional) - -If you have the existing `values.yaml` that you provided to your existing vCluster, you can skip this step. - -### Get the User-Suppied Values - -If you don't have the `values.yaml`, use Helm to retrieve the user defined configuration for your currently running virtual cluster. - -```bash -helm get values -n > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - -This uses `--revision 0` under the hood. Adjust this accordingly to receive the values of your latest revision. See the [Helm docs](https://helm.sh/docs/helm/helm_history/) for how to fetch revision history. - -### Get the Default Values - -If the `helm get` provides an empty file, then you used the default configuration to deploy your vCluster. You will still need to -supply a `values.yaml` to the convert due to changes in defaults. - -```bash -helm get values -n --all > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - - -## Convert your `values.yaml` to `vcluster.yaml` - -Convert your `values.yaml` to the new `vcluster.yaml` configuration file format by running: - -```BASH -vcluster convert config --distro -f > vcluster.yaml -``` - -Replace: - -- `` with your virtual cluster's existing Kubernetes distribution. **You can't change the Kubernetes distribution or backing store during an upgrade**. -- `` with the path to the `values.yaml`file you used to configure your pre-v0.20 vCluster instance. - - -For example: - -```BASH -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -### Notes about Changes for your `vcluster.yaml` - -#### Scheduling of the StatefulSet -Since the scheduling of the control plane pod changed in v0.20, the converted `vcluster.yaml` will include retaining -the original scheduling pattern as it is can't be changed between upgrades. - -#### Image Repository -By default, the conversion will not set the repo of the images to use the open source repo, but upgrade you to use -the vCluster Pro repo. This allows users to seamlessly test and adopt any vCluster Pro feature without disrupting their existing -open-source functionality. The Pro features are integrated into the Pro image but remain inactive by default to ensure that your experience remains consistent with the open-source version unless you specifically activate Pro features. - -If you want to continue using the open-source image, you will need to explicitly set the open source repository for your images. - -```yaml -controlPlane: - statefulSet: - image: - repository: loft-sh/vcluster-oss -``` - -#### Supporting EKS Distributions - -In v0.20, we have removed the support of EKS as a virtual cluster distribution. Reminder: The Kubernetes distribution of the virtual cluster doesn't need to match the the distribution of your host cluster. You can use any distribution of vCluster to deploy vCluster on EKS clusters. - -In order to continue using your virtual clusters that have EKS as the distribution, you can convert to using the k8s distribution and replace the images with the EKS images. While this was tested when v0.20.0 was released, it is not continuously tested. We recommend spinning up new virtual clusters with the k8s distribution and migrate your workloads to them. - -```bash -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -After the conversion, you will need to update the `vcluster.yaml` and change the images to be used. Refer to the EKS registries for [kube-apiserver](https://gallery.ecr.aws/eks-distro/kubernetes/kube-apiserver), [controller-manager](https://gallery.ecr.aws/eks-distro/kubernetes/kube-controller-manager) and [kube-scheduler](https://gallery.ecr.aws/eks-distro/kubernetes/kube-scheduler) for the specific tags you might want to use. - -**Example using EKS v1.30:** - -```yaml -controlplane: - distro: - k8s: - enabled: true - apiserver: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-apiserver" - tag: "v1.30.2-eks-1-30-10" - controllerManager: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-controller-manager" - tag: "v1.30.2-eks-1-30-10" - scheduler: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-scheduler" - tag: "v1.30.2-eks-1-30-10" -``` - -## Upgrade your vCluster instance - -:::warning Downgrading vCluster instances is NOT supported -While downgrading to an older version of the vCluster CLI is supported, you cannot downgrade virtual cluster instances to a prior version of vCluster (for example, from 0.20 back to 0.19). Make sure you have tested the upgrade sufficiently before rolling out this change to critical systems. -::: - - - - -## Related content - -- [vCluster config reference](/vcluster/configure/vcluster-yaml/) for full configuration details. + diff --git a/vcluster_versioned_docs/version-0.21.0/reference/migrations/0-20-migration.mdx b/vcluster_versioned_docs/version-0.21.0/reference/migrations/0-20-migration.mdx index 398a2e1cc..297d9fda6 100644 --- a/vcluster_versioned_docs/version-0.21.0/reference/migrations/0-20-migration.mdx +++ b/vcluster_versioned_docs/version-0.21.0/reference/migrations/0-20-migration.mdx @@ -4,183 +4,6 @@ description: How to migrate from pre-v0.20 to v0.20 release. sidebar_position: 2 --- -import DeployChanges from '../../_partials/manage/deploy-changes.mdx' +import MigrationGuide from '@site/docs/_partials/0-20.migration.mdx'; - -As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring -a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. - -

- -:::warning -Pre-v0.20.0 `values.yaml` files are not compatible with v0.20.0. You need to convert to the new format in order to use the new vCluster CLI and upgrade existing vCluster instances. -::: - - -Upgrade vCluster v0.19 to v0.20+ by following these steps: - -1. [Upgrade the vCluster CLI](#upgrade-the-cli). -1. [Convert your Helm values configuration file to the new `vcluster.yaml` configuration file](#convert-your-valuesyaml-to-vclusteryaml). -1. [Use your new `vcluster.yaml` file to upgrade your vCluster instance](#upgrade-your-vcluster-instance). - -## Supported legacy versions - -Loft Labs has tested the conversion path from v0.19.x to v0.20.0 and therefore recommends moving to v0.19.x before converting to v0.20.0. - -Conversions from vCluster versions prior to 0.19.x might work but have not been tested extensively. - -## Before you begin - -* Helm version is >= v.3.10.0. -* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. -* Review the [list of changes](../../cli/0-20-cli-changes/) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. - - -## Upgrade the CLI - -Before upgrading virtual cluster instances, upgrade to the latest version of the vCluster CLI. - -```BASH -vcluster upgrade --version -``` - -Replace: - -- `` with the version of vCluster you want to upgrade to. - - - -A new command has been added to support converting from the old `values.yaml` format to the new `vcluster.yaml`. - -```BASH -Usage: - vcluster convert config [flags] -Flags: - --distro string Kubernetes distro used - -f, --file string Path to the input file - -h, --help Help for config - -o, --output string Prints the output in the specified format. Allowed values: yaml, json (default "yaml") -``` - -## Get your previous `values.yaml` (Optional) - -If you have the existing `values.yaml` that you provided to your existing vCluster, you can skip this step. - -### Get the User-Suppied Values - -If you don't have the `values.yaml`, use Helm to retrieve the user defined configuration for your currently running virtual cluster. - -```bash -helm get values -n > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - -This uses `--revision 0` under the hood. Adjust this accordingly to receive the values of your latest revision. See the [Helm docs](https://helm.sh/docs/helm/helm_history/) for how to fetch revision history. - -### Get the Default Values - -If the `helm get` provides an empty file, then you used the default configuration to deploy your vCluster. You will still need to -supply a `values.yaml` to the convert due to changes in defaults. - -```bash -helm get values -n --all > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - - -## Convert your `values.yaml` to `vcluster.yaml` - -Convert your `values.yaml` to the new `vcluster.yaml` configuration file format by running: - -```BASH -vcluster convert config --distro -f > vcluster.yaml -``` - -Replace: - -- `` with your virtual cluster's existing Kubernetes distribution. **You can't change the Kubernetes distribution or backing store during an upgrade**. -- `` with the path to the `values.yaml`file you used to configure your pre-v0.20 vCluster instance. - - -For example: - -```BASH -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -### Notes about Changes for your `vcluster.yaml` - -#### Scheduling of the StatefulSet -Since the scheduling of the control plane pod changed in v0.20, the converted `vcluster.yaml` will include retaining -the original scheduling pattern as it is can't be changed between upgrades. - -#### Image Repository -By default, the conversion will not set the repo of the images to use the open source repo, but upgrade you to use -the vCluster Pro repo. This allows users to seamlessly test and adopt any vCluster Pro feature without disrupting their existing -open-source functionality. The Pro features are integrated into the Pro image but remain inactive by default to ensure that your experience remains consistent with the open-source version unless you specifically activate Pro features. - -If you want to continue using the open-source image, you will need to explicitly set the open source repository for your images. - -```yaml -controlPlane: - statefulSet: - image: - repository: loft-sh/vcluster-oss -``` - -#### Supporting EKS Distributions - -In v0.20, we have removed the support of EKS as a virtual cluster distribution. Reminder: The Kubernetes distribution of the virtual cluster doesn't need to match the the distribution of your host cluster. You can use any distribution of vCluster to deploy vCluster on EKS clusters. - -In order to continue using your virtual clusters that have EKS as the distribution, you can convert to using the k8s distribution and replace the images with the EKS images. While this was tested when v0.20.0 was released, it is not continuously tested. We recommend spinning up new virtual clusters with the k8s distribution and migrate your workloads to them. - -```bash -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -After the conversion, you will need to update the `vcluster.yaml` and change the images to be used. Refer to the EKS registries for [kube-apiserver](https://gallery.ecr.aws/eks-distro/kubernetes/kube-apiserver), [controller-manager](https://gallery.ecr.aws/eks-distro/kubernetes/kube-controller-manager) and [kube-scheduler](https://gallery.ecr.aws/eks-distro/kubernetes/kube-scheduler) for the specific tags you might want to use. - -**Example using EKS v1.30:** - -```yaml -controlplane: - distro: - k8s: - enabled: true - apiserver: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-apiserver" - tag: "v1.30.2-eks-1-30-10" - controllerManager: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-controller-manager" - tag: "v1.30.2-eks-1-30-10" - scheduler: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-scheduler" - tag: "v1.30.2-eks-1-30-10" -``` - -## Upgrade your vCluster instance - -:::warning Downgrading vCluster instances is NOT supported -While downgrading to an older version of the vCluster CLI is supported, you cannot downgrade virtual cluster instances to a prior version of vCluster (for example, from 0.20 back to 0.19). Make sure you have tested the upgrade sufficiently before rolling out this change to critical systems. -::: - - - - -## Related content - -- [vCluster config reference](/vcluster/configure/vcluster-yaml/) for full configuration details. + diff --git a/vcluster_versioned_docs/version-0.22.0/reference/migrations/0-20-migration.mdx b/vcluster_versioned_docs/version-0.22.0/reference/migrations/0-20-migration.mdx index 398a2e1cc..297d9fda6 100644 --- a/vcluster_versioned_docs/version-0.22.0/reference/migrations/0-20-migration.mdx +++ b/vcluster_versioned_docs/version-0.22.0/reference/migrations/0-20-migration.mdx @@ -4,183 +4,6 @@ description: How to migrate from pre-v0.20 to v0.20 release. sidebar_position: 2 --- -import DeployChanges from '../../_partials/manage/deploy-changes.mdx' +import MigrationGuide from '@site/docs/_partials/0-20.migration.mdx'; - -As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring -a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. - -

- -:::warning -Pre-v0.20.0 `values.yaml` files are not compatible with v0.20.0. You need to convert to the new format in order to use the new vCluster CLI and upgrade existing vCluster instances. -::: - - -Upgrade vCluster v0.19 to v0.20+ by following these steps: - -1. [Upgrade the vCluster CLI](#upgrade-the-cli). -1. [Convert your Helm values configuration file to the new `vcluster.yaml` configuration file](#convert-your-valuesyaml-to-vclusteryaml). -1. [Use your new `vcluster.yaml` file to upgrade your vCluster instance](#upgrade-your-vcluster-instance). - -## Supported legacy versions - -Loft Labs has tested the conversion path from v0.19.x to v0.20.0 and therefore recommends moving to v0.19.x before converting to v0.20.0. - -Conversions from vCluster versions prior to 0.19.x might work but have not been tested extensively. - -## Before you begin - -* Helm version is >= v.3.10.0. -* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. -* Review the [list of changes](../../cli/0-20-cli-changes/) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. - - -## Upgrade the CLI - -Before upgrading virtual cluster instances, upgrade to the latest version of the vCluster CLI. - -```BASH -vcluster upgrade --version -``` - -Replace: - -- `` with the version of vCluster you want to upgrade to. - - - -A new command has been added to support converting from the old `values.yaml` format to the new `vcluster.yaml`. - -```BASH -Usage: - vcluster convert config [flags] -Flags: - --distro string Kubernetes distro used - -f, --file string Path to the input file - -h, --help Help for config - -o, --output string Prints the output in the specified format. Allowed values: yaml, json (default "yaml") -``` - -## Get your previous `values.yaml` (Optional) - -If you have the existing `values.yaml` that you provided to your existing vCluster, you can skip this step. - -### Get the User-Suppied Values - -If you don't have the `values.yaml`, use Helm to retrieve the user defined configuration for your currently running virtual cluster. - -```bash -helm get values -n > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - -This uses `--revision 0` under the hood. Adjust this accordingly to receive the values of your latest revision. See the [Helm docs](https://helm.sh/docs/helm/helm_history/) for how to fetch revision history. - -### Get the Default Values - -If the `helm get` provides an empty file, then you used the default configuration to deploy your vCluster. You will still need to -supply a `values.yaml` to the convert due to changes in defaults. - -```bash -helm get values -n --all > values.yaml -``` - -Replace: - -- `` with the name of your vCluster instance. -- `` with the namespace that vCluster runs in. - - -## Convert your `values.yaml` to `vcluster.yaml` - -Convert your `values.yaml` to the new `vcluster.yaml` configuration file format by running: - -```BASH -vcluster convert config --distro -f > vcluster.yaml -``` - -Replace: - -- `` with your virtual cluster's existing Kubernetes distribution. **You can't change the Kubernetes distribution or backing store during an upgrade**. -- `` with the path to the `values.yaml`file you used to configure your pre-v0.20 vCluster instance. - - -For example: - -```BASH -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -### Notes about Changes for your `vcluster.yaml` - -#### Scheduling of the StatefulSet -Since the scheduling of the control plane pod changed in v0.20, the converted `vcluster.yaml` will include retaining -the original scheduling pattern as it is can't be changed between upgrades. - -#### Image Repository -By default, the conversion will not set the repo of the images to use the open source repo, but upgrade you to use -the vCluster Pro repo. This allows users to seamlessly test and adopt any vCluster Pro feature without disrupting their existing -open-source functionality. The Pro features are integrated into the Pro image but remain inactive by default to ensure that your experience remains consistent with the open-source version unless you specifically activate Pro features. - -If you want to continue using the open-source image, you will need to explicitly set the open source repository for your images. - -```yaml -controlPlane: - statefulSet: - image: - repository: loft-sh/vcluster-oss -``` - -#### Supporting EKS Distributions - -In v0.20, we have removed the support of EKS as a virtual cluster distribution. Reminder: The Kubernetes distribution of the virtual cluster doesn't need to match the the distribution of your host cluster. You can use any distribution of vCluster to deploy vCluster on EKS clusters. - -In order to continue using your virtual clusters that have EKS as the distribution, you can convert to using the k8s distribution and replace the images with the EKS images. While this was tested when v0.20.0 was released, it is not continuously tested. We recommend spinning up new virtual clusters with the k8s distribution and migrate your workloads to them. - -```bash -vcluster convert config --distro k8s -f /my/k8s/values.yaml > vcluster.yaml -``` - -After the conversion, you will need to update the `vcluster.yaml` and change the images to be used. Refer to the EKS registries for [kube-apiserver](https://gallery.ecr.aws/eks-distro/kubernetes/kube-apiserver), [controller-manager](https://gallery.ecr.aws/eks-distro/kubernetes/kube-controller-manager) and [kube-scheduler](https://gallery.ecr.aws/eks-distro/kubernetes/kube-scheduler) for the specific tags you might want to use. - -**Example using EKS v1.30:** - -```yaml -controlplane: - distro: - k8s: - enabled: true - apiserver: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-apiserver" - tag: "v1.30.2-eks-1-30-10" - controllerManager: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-controller-manager" - tag: "v1.30.2-eks-1-30-10" - scheduler: - image: - registry: "public.ecr.aws" - repository: "eks-distro/kubernetes/kube-scheduler" - tag: "v1.30.2-eks-1-30-10" -``` - -## Upgrade your vCluster instance - -:::warning Downgrading vCluster instances is NOT supported -While downgrading to an older version of the vCluster CLI is supported, you cannot downgrade virtual cluster instances to a prior version of vCluster (for example, from 0.20 back to 0.19). Make sure you have tested the upgrade sufficiently before rolling out this change to critical systems. -::: - - - - -## Related content - -- [vCluster config reference](/vcluster/configure/vcluster-yaml/) for full configuration details. + From a7027785f7d9e45f14286f392f650600fe300f76 Mon Sep 17 00:00:00 2001 From: Piotr Zaniewski Date: Wed, 29 Jan 2025 15:11:38 +0100 Subject: [PATCH 3/4] Update docs/_partials/0-20.migration.mdx Co-authored-by: Caleb Bron --- docs/_partials/0-20.migration.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_partials/0-20.migration.mdx b/docs/_partials/0-20.migration.mdx index 9a44ed6a3..44e3bc915 100644 --- a/docs/_partials/0-20.migration.mdx +++ b/docs/_partials/0-20.migration.mdx @@ -456,7 +456,7 @@ sync.fake-\* **0.20+**: - Disable is an invers of enable and is acceptable in this context. + Disable is an inverse of enable and is acceptable in this context. `fake-nodes.enabled = true` → disable node sync from the host: ```yaml From 94b1cfe4768bd17bf69df4466fd0aee6fdd7ed7b Mon Sep 17 00:00:00 2001 From: Piotr Zaniewski Date: Thu, 30 Jan 2025 10:03:15 +0100 Subject: [PATCH 4/4] Update docs/_partials/0-20.migration.mdx Co-authored-by: Russell Centanni --- docs/_partials/0-20.migration.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/_partials/0-20.migration.mdx b/docs/_partials/0-20.migration.mdx index 44e3bc915..fc64732a3 100644 --- a/docs/_partials/0-20.migration.mdx +++ b/docs/_partials/0-20.migration.mdx @@ -8,7 +8,7 @@ import DeployChanges from '../../vcluster/_partials/manage/deploy-changes.mdx' As part of the v0.20.0 release, Loft Labs introduced a new `vcluster.yaml` configuration file with a new structure. This file replaces your existing `values.yaml` configuration file. Previously, configuring -a virtual cluster had configuration options using CLI flags, anontations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source. +a virtual cluster had configuration options using CLI flags, annotations and different `values.yaml` options. With the new `vcluster.yaml`, all configuration options are now easily configured in a single source.

@@ -32,7 +32,7 @@ Conversions from vCluster versions prior to 0.19.x might work but have not been ## Before you begin * Helm version is >= v.3.10.0. -* Upgrade [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper) to v0.1.1-beta.1 or later for use with the new vcluster.yaml configuration file in v0.20. +* If you are using [vcluster-hostpath-mapper](https://github.com/loft-sh/vcluster-hostpath-mapper), upgrade it to to v0.1.1-beta.1 or later for compatibility with the new vcluster.yaml configuration file in v0.20. * Review the [list of changes](/vcluster/cli/0-20-cli-changes) in the vCluster CLI as commands, subcommands, and flags were removed, renamed or added. ## Upgrade the CLI