From 5a93651841344193723e530f2221ce5dcd24b9b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bojanowski?= Date: Wed, 19 Feb 2025 09:33:48 +0100 Subject: [PATCH] address PR feedback about capitalization of k8s resources, basic example at the top, bullet point list of assumptions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Paweł Bojanowski --- .../sync-from-host-configmap-example.mdx | 38 +++++++------- ...st-namespaced-custom-resources-example.mdx | 24 ++++----- .../sync-from-host-secret-example.mdx | 40 +++++++-------- .../sync/from-host/configmaps.mdx | 37 +++++++++----- .../sync/from-host/custom-resources.mdx | 51 ++++++++++++------- .../vcluster-yaml/sync/from-host/secrets.mdx | 40 +++++++++------ 6 files changed, 130 insertions(+), 100 deletions(-) diff --git a/vcluster/_fragments/sync-from-host-configmap-example.mdx b/vcluster/_fragments/sync-from-host-configmap-example.mdx index ef80a2d3..6b436dfa 100644 --- a/vcluster/_fragments/sync-from-host-configmap-example.mdx +++ b/vcluster/_fragments/sync-from-host-configmap-example.mdx @@ -33,11 +33,11 @@ You can find your contexts by running `kubectl config get-contexts` ::: -### Enable from host syncing for config map +### Enable from host syncing for ConfigMap -Enable the from host syncing for config maps in your virtual cluster configuration: +Enable the from host syncing for ConfigMap in your virtual cluster configuration: -```yaml title="Enable from host syncing for a config map" +```yaml title="Enable from host syncing for a ConfigMap" sync: fromHost: configMaps: @@ -49,20 +49,20 @@ sync: This configuration: -- Enables from host syncing of the config map named `config` in the namespace `foobar2`. -- Automatically configures RBAC permissions for vCluster, so it can access this config map (you need to re-deploy vCluster for it to take place) -- Makes this config map accessible as `config` in the `my-namespace` in your vCluster. +- Enables from host syncing of the ConfigMap named `config` in the namespace `foobar2`. +- Automatically configures RBAC permissions for vCluster, so it can access this ConfigMap (you need to re-deploy vCluster for it to take place) +- Makes this ConfigMap accessible as `config` in the `my-namespace` in your vCluster. :::tip create virtual cluster Create or update a `virtual Cluster` following the [vCluster quick start guide](/vcluster/#deploy-vcluster). ::: -### Sync config map to virtual and use it in pod +### Sync ConfigMap to virtual and use it in pod - First, you create a config map that you want to sync in the host cluster: + First, you create a ConfigMap that you want to sync in the host cluster: Copy this file and save it locally as `config.json` @@ -73,30 +73,30 @@ guide](/vcluster/#deploy-vcluster). } ``` - then, create a config map containing this file in the host cluster: + then, create a ConfigMap containing this file in the host cluster: - ```bash title="Create config map in the host" + ```bash title="Create ConfigMap in the host" kubectl --context="${HOST_CTX}" create configmap config \ --namespace=foobar2 \ --from-file=config.json=config.json ``` - #### Ensure that config map got synced to the vCluster + #### Ensure that ConfigMap got synced to the vCluster - Your config map should be now accessible in the virtual cluster. + Your ConfigMap should be now accessible in the virtual cluster. Keep in mind, that any edit made in the virtual object is overwritten by the host object data. - Check config map in the virtual cluster: + Check ConfigMap in the virtual cluster: - ```bash title="Get synced config map" + ```bash title="Get synced ConfigMap" kubectl --context="${VCLUSTER_CTX}" get configmap --namespace my-namespace config -o yaml ``` you should see similar output: - ```yaml title="config map contents" + ```yaml title="ConfigMap contents" apiVersion: v1 data: config.json: | @@ -120,7 +120,7 @@ guide](/vcluster/#deploy-vcluster). - Now, your can create a new pod in the `my-namespace` namespace and specify this config map as a volume and mount it in the container. + Now, your can create a new pod in the `my-namespace` namespace and specify this ConfigMap as a volume and mount it in the container. Save this pod locally to the file called `pod.yaml`: ```yaml title="pod.yaml" @@ -166,7 +166,7 @@ guide](/vcluster/#deploy-vcluster). ```bash title="Check mounted file" kubectl --context="${VCLUSTER_CTX}" exec -it --namespace my-virtual-namespace my-pod -- cat /tmp/config.json ``` - you should see environment successfully injected from the config map: + you should see environment successfully injected from the ConfigMap: ```json title="Config from ConfigMap" { @@ -181,8 +181,8 @@ guide](/vcluster/#deploy-vcluster). #### Summary - From host config map syncing allow you to make specific config map(s) from host clusters accessible inside your virtual clusters. You can make them accessible from different namespaces and/or with different names in the virtual cluster. - They are always synced from host to the virtual, so it is also possible to sync one host config map to the multiple virtual ones. + From host ConfigMap syncing allow you to make specific ConfigMap(s) from host clusters accessible inside your virtual clusters. You can make them accessible from different namespaces and/or with different names in the virtual cluster. + They are always synced from host to the virtual, so it is also possible to sync one host ConfigMap to the multiple virtual ones. They can also be used as a volume or env source in your workloads. diff --git a/vcluster/_fragments/sync-from-host-namespaced-custom-resources-example.mdx b/vcluster/_fragments/sync-from-host-namespaced-custom-resources-example.mdx index cc98e7ca..ab9fc92d 100644 --- a/vcluster/_fragments/sync-from-host-namespaced-custom-resources-example.mdx +++ b/vcluster/_fragments/sync-from-host-namespaced-custom-resources-example.mdx @@ -4,9 +4,9 @@ import Flow, { Step } from "@site/src/components/Flow"; -## From host namespaced custom resource example +## From host namespaced CustomResource example -This guide shows how to sync k8s namespaced custom resources from host cluster. +This guide shows how to sync k8s namespaced CustomResources from host cluster. Example CRD is used in this guide. ### Prerequisites @@ -34,7 +34,7 @@ You can find your contexts by running `kubectl config get-contexts` ::: -### Create custom resource definition in the host +### Create CustomResourceDefinition in the host Saved following Custom Resource Definition: @@ -82,11 +82,11 @@ save this file locally and then apply it in the host cluster: kubectl --context="${HOST_CTX}" create -f example-crd.yaml ``` -### Enable from host syncing for your custom resource +### Enable from host syncing for your CustomResource -Enable the from host syncing for examples custom resources in your virtual cluster configuration: +Enable the from host syncing for Example CustomResources in your virtual cluster configuration: -```yaml title="Enable from host syncing for custom resource" +```yaml title="Enable from host syncing for CustomResource" sync: fromHost: customResources: @@ -109,7 +109,7 @@ Create or update a `virtual Cluster` following the [vCluster quick start guide](/vcluster/#deploy-vcluster). ::: -### Sync namespaced custom resource to vCluster +### Sync namespaced CustomResource to vCluster @@ -135,15 +135,15 @@ guide](/vcluster/#deploy-vcluster). ``` - #### Ensure that custom resource got synced to vCluster + #### Ensure that CustomResource got synced to vCluster - Your custom resource should be now accessible in the virtual cluster. + Your CustomResource should be now accessible in the virtual cluster. Keep in mind, that any edit made in the virtual object is overwritten by the host object data. - Check custom resource in the virtual cluster: + Check CustomResource in the virtual cluster: - ```bash title="Get synced custom resource" + ```bash title="Get synced CustomResource" kubectl --context="${VCLUSTER_CTX}" et examples.demo.loft.sh --namespace default ``` @@ -157,7 +157,7 @@ guide](/vcluster/#deploy-vcluster). - #### Edit custom resource in the host + #### Edit CustomResource in the host diff --git a/vcluster/_fragments/sync-from-host-secret-example.mdx b/vcluster/_fragments/sync-from-host-secret-example.mdx index 546eaebc..1a553738 100644 --- a/vcluster/_fragments/sync-from-host-secret-example.mdx +++ b/vcluster/_fragments/sync-from-host-secret-example.mdx @@ -6,9 +6,9 @@ import Flow, { Step } from "@site/src/components/Flow"; -## From host secret sync example +## From host Secret sync example -This guide shows how to sync Kubernetes secret from host clusters and how you can use them in your workload running inside virtual clusters. +This guide shows how to sync Kubernetes Secret from host clusters and how you can use them in your workload running inside virtual clusters. ### Prerequisites @@ -35,11 +35,11 @@ You can find your contexts by running `kubectl config get-contexts` ::: -### Enable from host syncing for secret +### Enable from host syncing for Secret Enable the from host syncing for secrets in your virtual cluster configuration: -```yaml title="Enable from host syncing for a secret" +```yaml title="Enable from host syncing for a Secret" sync: fromHost: secrets: @@ -51,22 +51,22 @@ sync: This configuration: -- Enables from host syncing of the secret `shared-user-env` in the namespace `foobar`. -- Automatically configures RBAC permissions for vCluster, so it can access this secret (you need to re-deploy vCluster for it to take place) -- Makes this secret accessible as `user-env` in the `my-namespace` in your vCluster. +- Enables from host syncing of the Secret `shared-user-env` in the namespace `foobar`. +- Automatically configures RBAC permissions for vCluster, so it can access this Secret (you need to re-deploy vCluster for it to take place) +- Makes this Secret accessible as `user-env` in the `my-namespace` in your vCluster. :::tip create virtual cluster Create or update a `virtual Cluster` following the [vCluster quick start guide](/vcluster/#deploy-vcluster). ::: -### Sync secret to virtual and use it in pod +### Sync Secret to virtual and use it in pod - First, create a secret which you want to sync in the host cluster: + First, create a Secret which you want to sync in the host cluster: - ```bash title="Create secret in the host" + ```bash title="Create Secret in the host" kubectl --context="${HOST_CTX}" create secret generic shared-user-env \ --namespace=foobar \ --from-literal=MY_ENV_1=foo \ @@ -74,21 +74,21 @@ guide](/vcluster/#deploy-vcluster). ``` - #### Ensure that secret got synced to the vCluster + #### Ensure that Secret got synced to the vCluster - Your secret should be now accessible in the virtual cluster. + Your Secret should be now accessible in the virtual cluster. Keep in mind, that any edit made in the virtual object is overwritten by the host object data. - Check if the secret is accessible in the virtual cluster: + Check if the Secret is accessible in the virtual cluster: - ```bash title="Get synced secret" + ```bash title="Get synced Secret" kubectl --context="${VCLUSTER_CTX}" get secrets --namespace my-namespace user-env -o yaml ``` you should see similar output: - ```yaml title="secret contents" + ```yaml title="Secret contents" apiVersion: v1 data: MY_ENV_1: Zm9v @@ -110,7 +110,7 @@ guide](/vcluster/#deploy-vcluster). - Now, you can create a new pod in the `my-namespace` namespace and specify this secret as a source for environment variables. + Now, you can create a new pod in the `my-namespace` namespace and specify this Secret as a source for environment variables. Save this pod locally to the file called `pod.yaml`: ```yaml title="pod.yaml" @@ -157,9 +157,9 @@ guide](/vcluster/#deploy-vcluster). ```bash title="Check environment variables" kubectl --context="${VCLUSTER_CTX}" exec -it --namespace my-namespace my-pod -- printenv | grep "MY_ENV" ``` - you should see environment successfully injected from the secret: + you should see environment successfully injected from the Secret: - ```bash title="Environment variables from secret" + ```bash title="Environment variables from Secret" MY_ENV_1=foo MY_ENV_2=bar ``` @@ -169,8 +169,8 @@ guide](/vcluster/#deploy-vcluster). #### Summary - From host secret syncing allow you to make specific secret(s) from host clusters accessible inside your virtual clusters. You can make them accessible from different namespaces and/or with different names in the virtual cluster. - They are always synced from host to the virtual, so it is also possible to sync one host secret to the multiple virtual ones. + From host Secret syncing allow you to make specific Secret(s) from host clusters accessible inside your virtual clusters. You can make them accessible from different namespaces and/or with different names in the virtual cluster. + They are always synced from host to the virtual, so it is also possible to sync one host Secret to the multiple virtual ones. They can also be used as a volume or env source in your workloads. diff --git a/vcluster/configure/vcluster-yaml/sync/from-host/configmaps.mdx b/vcluster/configure/vcluster-yaml/sync/from-host/configmaps.mdx index a8dde74c..11d1fc00 100644 --- a/vcluster/configure/vcluster-yaml/sync/from-host/configmaps.mdx +++ b/vcluster/configure/vcluster-yaml/sync/from-host/configmaps.mdx @@ -12,24 +12,34 @@ import FromHostConfigMapExample from '../../../../_fragments/sync-from-host-conf By default, this is turned off. :::info No need to configure RBAC -vCluster automatically adds the required cluster RBAC permissions for retrieving the config maps and syncing the resources from the host to the virtual cluster. +vCluster automatically adds the required cluster RBAC permissions for retrieving the ConfigMaps and syncing the resources from the host to the virtual cluster. ::: Enabling this allows you to sync ConfigMaps from the specified namespaces in the host to the specified namespaces in the vCluster. +```yaml title="vcluster.yaml" +sync: + fromHost: + configMaps: + enabled: true + selector: + mappings: + # syncs all ConfigMaps from "foo" namespace + # to the "bar" namespace in vCluster. ConfigMaps names are unchanged. + "foo/*": "bar/*" +``` -It is also possible to modify the name of the synced resource in the virtual cluster. - -There is no option to sync from all namespaces in the host. - -Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. When you delete a virtual object, vCluster re-creates it if the host object still exist. -When you delete a host object, vCluster deletes the corresponding virtual object. +- It is also possible to modify the name of the synced resource in the virtual cluster. +- There is no option to sync from all namespaces in the host. +- Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. +- When you delete a virtual object, vCluster re-creates it if the host object still exist. +- When you delete a host object, vCluster deletes the corresponding virtual object. Namespaces in the virtual cluster are created automatically during the sync (if they do not exist already). It is not possible to sync ConfigMaps that were already synced from virtual to host, they are skipped by vCluster. -:::info kube-root-ca configmap is skipped +:::info kube-root-ca ConfigMap is skipped ConfigMaps named `kube-root-ca.crt` are skipped in the from host sync (even if they match the mappings specified in `vcluster.yaml`). ::: @@ -39,7 +49,7 @@ You can use synced ConfigMaps in your workloads as an environment variables sour All the specified namespaces have to exist in the host at the vCluster startup. -## Sync all config maps from host namespace +## Sync all ConfigMaps from host namespace To sync all ConfigMaps from a given namespace in the host to the given namespace in the virtual cluster, “namespace/*” wildcard can be used, e.g.: ```yaml @@ -54,7 +64,7 @@ sync: "foo/*": "bar/*" ``` -## Sync only specific config maps from host namespace +## Sync only specific ConfigMaps from host namespace To sync only specific ConfigMaps from namespaces, you need to provide `namespace/name` as the key and value: ```yaml @@ -69,7 +79,7 @@ sync: "foo/cm-name": "bar/cm-name" ``` -## Sync all config maps from vCluster's host namespace +## Sync all ConfigMaps from vCluster's host namespace There is also a handy syntax to sync all ConfigMaps from vCluster’s own host namespace to the virtual namespace. As vCluster’s namespace is not always known upfront (e.g. when vCluster is created by the platform), `""` (empty string) is treated as “vCluster’s own host namespace”. ```yaml @@ -84,7 +94,7 @@ sync: "": "my-virtual" ``` -## Sync specific config map from vCluster's host namespace +## Sync specific ConfigMap from vCluster's host namespace you can also specify only a few ConfigMaps from vCluster’s own host namespace this way: ```yaml @@ -99,7 +109,7 @@ sync: "/my-cm": "my-virtual/my-cm" ``` -## Modify synced config map namespace and name in the virtual cluster +## Modify synced ConfigMap namespace and name in the virtual cluster It’s also possible to modify ConfigMap name during the sync: ```yaml @@ -136,7 +146,6 @@ sync: "default/my-cm": "barfoo2/cm-my" patches: - path: metadata.annotations[*] - #expression: '"my-prefix-"+value' # optional reverseExpression to reverse the change from the host cluster reverseExpression: "value.startsWith('www.') ? value.slice(4) : value" ``` diff --git a/vcluster/configure/vcluster-yaml/sync/from-host/custom-resources.mdx b/vcluster/configure/vcluster-yaml/sync/from-host/custom-resources.mdx index 2bdb281a..8a5debf0 100644 --- a/vcluster/configure/vcluster-yaml/sync/from-host/custom-resources.mdx +++ b/vcluster/configure/vcluster-yaml/sync/from-host/custom-resources.mdx @@ -12,14 +12,14 @@ import NamespacedCustomResourcesExample from '../../../../_fragments/sync-from-h -vCluster allows you to sync custom resources from the host cluster to the virtual cluster. Resources are only be read by vCluster and then synced in read-only mode into the vCluster. vCluster copies the CRD itself in the beginning from the host to the virtual cluster and then start syncing the resources into the vCluster. This is especially helpful if you want to show certain resources inside the vCluster, such as ClusterIssuers (for [cert-manager](https://cert-manager.io/)) or ClusterStores (for [external-secrets](https://external-secrets.io/latest/)). +vCluster allows you to sync CustomResources from the host cluster to the virtual cluster. Resources are only be read by vCluster and then synced in read-only mode into the vCluster. vCluster copies the CRD itself in the beginning from the host to the virtual cluster and then start syncing the resources into the vCluster. This is especially helpful if you want to show certain resources inside the vCluster, such as ClusterIssuers (for [cert-manager](https://cert-manager.io/)) or ClusterStores (for [external-secrets](https://external-secrets.io/latest/)). If you are looking to sync resources from the vCluster to the host cluster, see [syncing custom resources to the host cluster](../to-host/advanced/custom-resources) :::info No need to configure RBAC -vCluster automatically adds the required cluster RBAC permissions for retrieving the custom resource definition and syncing the resources from the host to the virtual cluster. +vCluster automatically adds the required cluster RBAC permissions for retrieving the CustomResourceDefinition and syncing the resources from the host to the virtual cluster. ::: -## Cluster scope example +## Cluster scoped example To configure vCluster to sync ClusterIssuers from the host cluster (from [cert-manager](https://cert-manager.io/)): ```yaml @@ -30,38 +30,52 @@ sync: enabled: true scope: Cluster ``` - -## Namespaced scope custom resource definitions + +## Namespace scoped CustomResourceDefinitions + By default, this is turned off. Enabling this allow you to sync namespaced CustomResources from the specified namespaces in the host to the specified namespaces in the vCluster. +```yaml title="vcluster.yaml" +sync: + fromHost: + customResources: + certificaterequests.cert-manager.io: + enabled: true + scope: Namespaced + selector: + mappings: + # syncs all CertificateRequests from "foo" namespace + # to the "bar" namespace in vCluster. CertificateRequests names are unchanged. + "foo/*": "bar/*" +``` -It is also possible to modify the name of the synced resource in the virtual cluster. - -There is no option to sync from all namespaces in the host. - -Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. When you delete virtual object, vCluster re-creates it if the host object still exist. +- It is also possible to modify the name of the synced resource in the virtual cluster. +- There is no option to sync from all namespaces in the host. +- Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. +- When you delete virtual object, vCluster re-creates it if the host object still exist. +- When you delete host object, vCluster deletes virtual object. -When you delete host object, vCluster deletes virtual object. +Namespaces in the virtual cluster are created automatically during the sync (if they do not exist already). ### Prerequisites * All the specified namespaces have to exist in the host at the vCluster startup. -* Custom Resource Definition needs to exist in the host at the vCluster startup. +* CustomResourceDefinition needs to exist in the host at the vCluster startup. ### Example :::info No need to configure RBAC -vCluster automatically adds the required cluster RBAC permissions for retrieving the custom resource definition and syncing the resources from the host to the virtual cluster. +vCluster automatically adds the required cluster RBAC permissions for retrieving the CustomResourceDefinition and syncing the resources from the host to the virtual cluster. ::: -For Namespaced Scoped Custom Resources, you need to specify `selector.mappings` in the config. This tells vCluster which host resources should be synced and where (in the virtual cluster). +For Namespace scoped CustomResources, you need to specify `selector.mappings` in the config. This tells vCluster which host resources should be synced and where (in the virtual cluster). Namespaces in the virtual cluster are created automatically during the sync (if they do not exist already). -It is not possible to sync Custom Resources that were already synced from virtual to host, they are skipped by vCluster. +It is not possible to sync CustomResources that were already synced from virtual to host, they are skipped by vCluster. -Here is an example with cert-manager’s CertificateRequest custom resource. +Here is an example with cert-manager’s CertificateRequest CustomResource. To sync all CustomResources from a given namespace in the host to the given namespace in the virtual cluster, “namespace/*” wildcard can be used, e.g.: @@ -74,8 +88,8 @@ sync: scope: Namespaced selector: mappings: - # syncs all CertificateRequests from "foo" namespace - # to the "bar" namespace in vCluster. CertificateRequests names are unchanged. + # syncs all CertificateRequests from "foo" namespace + # to the "bar" namespace in vCluster. CertificateRequests names are unchanged. "foo/*": "bar/*" ``` @@ -165,7 +179,6 @@ sync: "default/my-cm": "barfoo2/cm-my" patches: - path: metadata.annotations[*] - #expression: '"my-prefix-"+value' # optional reverseExpression to reverse the change from the host cluster reverseExpression: "value.startsWith('www.') ? value.slice(4) : value" ``` diff --git a/vcluster/configure/vcluster-yaml/sync/from-host/secrets.mdx b/vcluster/configure/vcluster-yaml/sync/from-host/secrets.mdx index 3e7b5086..34450cc7 100644 --- a/vcluster/configure/vcluster-yaml/sync/from-host/secrets.mdx +++ b/vcluster/configure/vcluster-yaml/sync/from-host/secrets.mdx @@ -12,30 +12,39 @@ import FromHostSecretExample from '../../../../_fragments/sync-from-host-secret- By default, this is turned off. :::info No need to configure RBAC -vCluster automatically adds the required cluster RBAC permissions for retrieving the secrets and syncing the resources from the host to the virtual cluster. +vCluster automatically adds the required cluster RBAC permissions for retrieving the Secrets and syncing the resources from the host to the virtual cluster. ::: Enabling this allows you to sync Secrets from the specified namespaces in the host to the specified namespaces in the vCluster. +```yaml title="vcluster.yaml" +sync: + fromHost: + secrets: + enabled: true + selector: + mappings: + # syncs all Secrets from "foo" namespace + # to the "bar" namespace in vCluster. Secrets names are unchanged. + "foo/*": "bar/*" +``` -It is also possible to modify the name of the synced resource in the virtual cluster. - -There is no option to sync from all namespaces in the host. - -Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. When you delete a virtual object, vCluster re-creates it if the host object still exist. - -When you delete a host object, vCluster deletes the corresponding virtual object. - -You can use synced Secrets in your workloads as an environment variables source or a volume. +- It is also possible to modify the name of the synced resource in the virtual cluster. +- There is no option to sync from all namespaces in the host. +- Sync is one-directional, from host to virtual. If you modify an object in the host, vCluster syncs the change to virtual object. +- When you delete a virtual object, vCluster re-creates it if the host object still exist. +- When you delete a host object, vCluster deletes the corresponding virtual object. It is not possible to sync Secrets that were already synced from virtual to host, they are skipped by vCluster. Namespaces in the virtual cluster are created automatically during the sync (if they do not exist already). +You can use synced Secrets in your workloads as an environment variables source or a volume. + ## Prerequisites All the specified namespaces have to exist in the host at the vCluster startup. -## Sync all secrets from host namespace +## Sync all Secrets from host namespace To sync all Secrets from a given namespace in the host to the given namespace in the virtual cluster, “namespace/*” wildcard can be used, e.g.: ```yaml @@ -51,7 +60,7 @@ sync: ``` -## Sync only specific secrets from host namespace +## Sync only specific Secrets from host namespace To sync only specific Secrets from namespaces, you need to provide `namespace/name` as the key and value: ```yaml @@ -67,7 +76,7 @@ sync: ``` -## Sync all secrets from vCluster's host namespace +## Sync all Secrets from vCluster's host namespace There is also a handy syntax to sync all Secrets from vCluster’s own host namespace to the virtual namespace. As vCluster’s namespace is not always known upfront (e.g. when vCluster is created by the platform), `""` (empty string) is treated as “vCluster’s own host namespace”. ```yaml @@ -83,7 +92,7 @@ sync: ``` -## Sync specific secret from vCluster's host namespace +## Sync specific Secret from vCluster's host namespace you can also specify only a few Secrets from vCluster’s own host namespace this way: ```yaml @@ -98,7 +107,7 @@ sync: "/my-cm": "my-virtual/my-cm" ``` -## Modify synced secret namespace and name in the virtual cluster +## Modify synced Secret namespace and name in the virtual cluster It’s also possible to modify Secret name during the sync: ```yaml @@ -135,7 +144,6 @@ sync: "default/my-cm": "barfoo2/cm-my" patches: - path: metadata.annotations[*] - #expression: '"my-prefix-"+value' # optional reverseExpression to reverse the change from the host cluster reverseExpression: "value.startsWith('www.') ? value.slice(4) : value" ```