Merge pull request loft-sh#811 from FabianKramm/main

docs: add suffixes

docs/pages/architecture/basics.mdx

@@ -13,15 +13,15 @@ Virtual clusters are Kubernetes clusters that run on top of other Kubernetes clu
 ## Components
 
 By default, vclusters run as a single pod (scheduled by a StatefulSet) that consists of 2 containers:
-- [**Control Plane**](#vcluster-control-plane): This container contains API server, controller manager and a connection (or mount) of the data store. By default, vclusters use sqlite as data store and run the API server and controller manager of k3s, which is a certified Kubernetes distribution and CNCF sandbox project. You can also use a [different data store, such as etcd, mysql or postgresql](../operator/external-datastore). You are also able to use another Kubernetes distribution as backing virtual cluster, such as [k0s or vanilla k8s](../operator/other-distributions.mdx).
+- [**Control Plane**](#vcluster-control-plane): This container contains API server, controller manager and a connection (or mount) of the data store. By default, vclusters use sqlite as data store and run the API server and controller manager of k3s, which is a certified Kubernetes distribution and CNCF sandbox project. You can also use a [different data store, such as etcd, mysql or postgresql](../operator/external-datastore.mdx). You are also able to use another Kubernetes distribution as backing virtual cluster, such as [k0s or vanilla k8s](../operator/other-distributions.mdx).
 - [**Syncer**](#vcluster-syncer): What makes a vcluster virtual is the fact that it does not have actual worker nodes or network. Instead, it uses a so-called syncer which copies the pods that are created within the vcluster to the underlying host cluster. Then, the host cluster will actually schedule the pod and the vcluster will keep the vcluster pod and host cluster pod in sync.
 
 ### vcluster Control Plane
 Each vcluster has its own control plane consisting of:
 - **Kubernetes API** server (point your kubectl requests to this vcluster API server)
 - **Data store** (where the API stores all resources, real clusters run with etcd)
 - **Controller Manager** (creates pods objects in the data store according to replica number in ReplicaSets etc.)
-- **(Optional) Scheduler** (schedules workloads inside the virtual cluster. See [scheduling](./scheduling) for more info)
+- **(Optional) Scheduler** (schedules workloads inside the virtual cluster. See [scheduling](./scheduling.mdx) for more info)
 
 ### vcluster Syncer
 The vcluster uses a so-called syncer which copies the pods that are created within the vcluster to the underlying host cluster. Then, the host cluster will schedule the pod and the vcluster will keep the vcluster pod and host cluster pod in sync.
@@ -36,7 +36,7 @@ It is possible to run multiple vclusters inside the same namespace and you can e
 The core idea of virtual clusters is to provision isolated Kubernetes control planes (e.g. API servers) that run on top of "real" Kubernetes clusters. When working with the virtual cluster's API server, resources first only exist in the virtual cluster. However, some low-level Kubernetes resources need to be synchronized to the underlying cluster.
 
 ### High-Level = Purely Virtual
-Generally, all Kubernetes resource objects that you create using the vcluster API server are stored in the data store of the vcluster (sqlite by default, see [external datastore](../operator/external-datastore) for more options). That applies in particular to all higher level Kubernetes resources, such as Deployments, StatefulSets, CRDs, etc. These objects only exist inside the virtual cluster and never reach the API server or data store (etcd) of the underlying host cluster.
+Generally, all Kubernetes resource objects that you create using the vcluster API server are stored in the data store of the vcluster (sqlite by default, see [external datastore](../operator/external-datastore.mdx) for more options). That applies in particular to all higher level Kubernetes resources, such as Deployments, StatefulSets, CRDs, etc. These objects only exist inside the virtual cluster and never reach the API server or data store (etcd) of the underlying host cluster.
 
 ### Low-Level = Sync'd Resources
 To be able to actually start containers, the vcluster synchronizes certain low-level resources (e.g. Pods, ConfigMaps mounted in Pods) to the underlying host namespace, so that the scheduler of the underlying host cluster can schedule these pods.

docs/pages/architecture/scheduling.mdx

@@ -73,7 +73,7 @@ selector, as well as nodes running pod workloads.
 
 When using vcluster helm chart or CLI, there are two options for setting the `--node-selector` flag.
 
-This first option is recommended if you are not enabling node synchronization, and use [the fake nodes](./nodes), which are enabled by default. In such case, you would write a string representation of your node selector(e.g. "nodeLabel=labelValue") and set it as the value of `--node-selector` argument for syncer in your `values.yaml`:
+This first option is recommended if you are not enabling node synchronization, and use [the fake nodes](./nodes.mdx), which are enabled by default. In such case, you would write a string representation of your node selector(e.g. "nodeLabel=labelValue") and set it as the value of `--node-selector` argument for syncer in your `values.yaml`:
 ```
 syncer:
   extraArgs:
@@ -85,7 +85,7 @@ then create or upgrade the vcluster with:
 vcluster create my-vcluster --upgrade -f values.yaml
 ```
 
-This second option is recommended if you are enabling synchronization of [the real nodes](./nodes) via helm values. This is how you would then set the selector in your `values.yaml`:
+This second option is recommended if you are enabling synchronization of [the real nodes](./nodes.mdx) via helm values. This is how you would then set the selector in your `values.yaml`:
 ```
 sync:
   nodes:
@@ -99,7 +99,7 @@ vcluster create my-vcluster --upgrade -f values.yaml
 ```
 
 :::info
-When sync of the real nodes is enabled and nodeSelector is set, all nodes that match the selector will be synced into vcluster. Read more about Node sync modes on the [Nodes documentation page](./nodes).
+When sync of the real nodes is enabled and nodeSelector is set, all nodes that match the selector will be synced into vcluster. Read more about Node sync modes on the [Nodes documentation page](./nodes.mdx).
 ::: 
 
 

docs/pages/fragments/deploy-to-openshift.mdx

@@ -26,7 +26,7 @@ vcluster create my-vcluster -f values.yaml
 </TabItem>
 <TabItem value="helm">
 
-Update the `vcluster.yaml` file described in the [deployment guide](../getting-started/deployment). 
+Update the `vcluster.yaml` file described in the [deployment guide](../getting-started/deployment.mdx).
 
 You will need to add the `openshift` block as shown below:
 
@@ -35,7 +35,7 @@ openshift:
   enable: true
 ```
 
-Then, install helm chart using `vcluster.yaml` for chart values as described in the [deployment guide](../getting-started/deployment). 
+Then, install helm chart using `vcluster.yaml` for chart values as described in the [deployment guide](../getting-started/deployment.mdx).
 
 </TabItem>
 <TabItem value="kubectl">

docs/pages/fragments/high-availability.mdx

@@ -63,7 +63,7 @@ kubectl get ns
 
 ## Enable HA in rootless mode
 Rootless mode means running vcluster without root user privileges in container, making host k8s cluster more secure.
-You can find more about rootless mode [here](../operator/restricted-hosts).
+You can find more about rootless mode [here](../operator/restricted-hosts.mdx).
 
 Below is HA configuration for running rootless vcluster with vanilla Kubernetes distribution.
 ```

docs/pages/fragments/non-root-vcluster.mdx

@@ -27,7 +27,7 @@ vcluster create my-vcluster -f values.yaml
 </TabItem>
 <TabItem value="helm">
 
-Update the `vcluster.yaml` file described in the [deployment guide](../getting-started/deployment). 
+Update the `vcluster.yaml` file described in the [deployment guide](../getting-started/deployment.mdx).
 
 You will need to add the `securityContext` block as shown below:
 
@@ -37,7 +37,7 @@ securityContext:
   runAsNonRoot: true
 ```
 
-Then, install helm chart using `vcluster.yaml` for chart values as described in the [deployment guide](../getting-started/deployment). 
+Then, install helm chart using `vcluster.yaml` for chart values as described in the [deployment guide](../getting-started/deployment.mdx).
 
 </TabItem>
 <TabItem value="kubectl">

docs/pages/operator/cluster-api-provider.mdx

@@ -55,13 +55,13 @@ kubectl wait --for=condition=ready vcluster -n $CLUSTER_NAMESPACE $CLUSTER_NAME
 The cluster is ready to be used once the command above exits.
 
 ### Expose vcluster externally
-There are multiple methods for exposing your vcluster instance, and they are described on the ["Exposing vcluster (ingress etc.)" page](./external-access). 
+There are multiple methods for exposing your vcluster instance, and they are described on the [exposing vcluster page](./external-access).
 
 If the documentation instructs you to update your values.yaml file, you will need to update the `HELM_VALUES` environment variable, execute the clusterctl generate cluster again, and apply the updated output to your cluster.  
 Alternatively, you can edit the `.spec.helmRelease.values` field of the vcluster custom resource using `kubectl edit vcluster -n $CLUSTER_NAMESPACE $CLUSTER_NAME ` command. Be mindful of the formatting of the value: the string should be a valid YAML file, with the expected indentation for the various helm values. The vcluster provider is watching for the changes made to vcluster custom resource, and it will automatically update the vcluster instance when changes are detected.
 
 ### Connecting to your vcluster
-The recommended way of connecting to your vcluster is to use vcluster CLI as described in the ["Using the vcluster CLI" chapter of the "Accessing vcluster" page](./accessing-vcluster).
+The recommended way of connecting to your vcluster is to use vcluster CLI as described in the [accessing vcluster page](./accessing-vcluster).
 
 However, if your vcluster is created with the vcluster provider, and you expose your cluster externally, you have an alternative:  
 ```clusterctl get kubeconfig ${CLUSTER_NAME} --namespace ${CLUSTER_NAMESPACE} > ./kubeconfig.yaml```  

docs/pages/operator/restricted-hosts.mdx

@@ -20,7 +20,7 @@ And you are free to set other [securityContext fields](https://kubernetes.io/doc
 :::
 
 :::caution
-Running as non-root is currently supported only for the k3s distribution. While [other distributions provided by vcluster](./other-distributions) may make use of the `securityContext` field from the `values.yaml` file, we do not guarantee that they will work as expected.
+Running as non-root is currently supported only for the k3s distribution. While [other distributions provided by vcluster](./other-distributions.mdx) may make use of the `securityContext` field from the `values.yaml` file, we do not guarantee that they will work as expected.
 :::
 
 :::caution

docs/pages/plugins/generic-crd-sync.mdx

@@ -5,10 +5,10 @@ sidebar_label: "Generic CRD Sync Plugin"
 
 On this page, we will describe what is the [vcluster generic CRD sync plugin](https://github.com/loft-sh/vcluster-generic-crd-sync-plugin) and how you can create a custom configuration to suit your needs.
 
-You should already know how to [install a plugin](./overview#loading-and-installing-plugins-to-vcluster). And we assume that you are already familiar with the basic principles of how vcluster works, including its [components](../architecture/basics#components) and how it handles [certain Kubernetes resources](../architecture/basics#kubernetes-resources).
+You should already know how to [install a plugin](./overview.mdx#loading-and-installing-plugins-to-vcluster). And we assume that you are already familiar with the basic principles of how vcluster works, including its [components](../architecture/basics.mdx#components) and how it handles [certain Kubernetes resources](../architecture/basics.mdx#kubernetes-resources).
 
 ## Introduction
-Out-of-the-box vcluster can sync [certain Kubernetes resources](../architecture/synced-resources), but there are use cases where it could be useful to sync additional resource kinds as well. A popular reason for this is to utilize a controller(or operator) that is installed in the host cluster and avoid having to install it inside the vcluster. You could achieve this task by implementing a vcluster plugin, as is described in our [Development tutorial](./tutorial), and while this approach has its benefits, it requires certain level of Go knowledge and familiarity with Kubernetes libraries for Go.
+Out-of-the-box vcluster can sync [certain Kubernetes resources](../architecture/synced-resources.mdx), but there are use cases where it could be useful to sync additional resource kinds as well. A popular reason for this is to utilize a controller(or operator) that is installed in the host cluster and avoid having to install it inside the vcluster. You could achieve this task by implementing a vcluster plugin, as is described in our [Development tutorial](./tutorial.mdx), and while this approach has its benefits, it requires certain level of Go knowledge and familiarity with Kubernetes libraries for Go.
 
 The [vcluster generic CRD sync plugin](https://github.com/loft-sh/vcluster-generic-crd-sync-plugin) allows you to sync additional resources to, and from the host cluster where vcluster is installed, with just a few lines of a YAML configuration. With this approach, it is much easier to get started. You will need to declare which CRD Kinds you would like to sync from the virtual cluster to the host cluster, and the plugin will automatically copy the CRD definition from the host cluster into vcluster at the start. Then it will take care of watching the resources of the predefined Kinds and execute the synchronization logic based on the configuration provided to it.
 

docs/pages/what-are-virtual-clusters.mdx

@@ -20,7 +20,7 @@ Besides k3s, other Kubernetes distributions such as [k0s and vanilla k8s are sup
 * **Configmaps & Secrets**: ConfigMaps or secrets in the virtual cluster that are mounted to pods will be synced to the host cluster, all other configmaps or secrets will purely stay in the virtual cluster.
 * **Other Resources**: Deployments, statefulsets, CRDs, service accounts etc. are **NOT** synced to the host cluster and purely exist in the virtual cluster.
 
-See [synced resources](./architecture/synced-resources) for more information about what resources are synced exactly.
+See [synced resources](./architecture/synced-resources.mdx) for more information about what resources are synced exactly.
 
 In addition to the synchronization of virtual and host cluster resources, the hypervisor proxies certain Kubernetes API requests to the host cluster, such as pod port forwarding or container command execution. It essentially acts as a reverse proxy for the virtual cluster.