Merge pull request #1364 from mpetason/overview-docs-update

Updated wording in overview and updated spelling of vCluster

docs/pages/architecture/overview.mdx

@@ -3,11 +3,11 @@ title: Overview
 sidebar_label: Overview
 ---
 
-Virtual clusters are Kubernetes clusters that run on top of other Kubernetes clusters. Compared to fully separate "real" clusters, virtual clusters do not have their own node pools or networking. Instead, they are scheduling workloads inside the underlying cluster while having their own control plane.
+Virtual clusters are Kubernetes clusters that run on top of other Kubernetes clusters. Compared to fully separate "real" clusters, virtual clusters do not have their own node pools or networking. Instead, they schedule workloads inside the underlying cluster while having their own control plane.
 
 <figure>
-  <img src="/docs/media/diagrams/vcluster-architecture.svg" alt="vcluster Architecture" />
-  <figcaption>vcluster - Architecture</figcaption>
+  <img src="/docs/media/diagrams/vcluster-architecture.svg" alt="vCluster Architecture" />
+  <figcaption>vCluster - Architecture</figcaption>
 </figure>
 
 ## Components
@@ -17,9 +17,9 @@ By default, vClusters run as a single pod (scheduled by a StatefulSet) that cons
 - [**Syncer**](./syncer/syncer.mdx)
 
 ## Host Cluster & Namespace
-Every vCluster runs on top of another Kubernetes cluster, called host cluster. Each vCluster runs as a regular StatefulSet inside a namespace of the host cluster. This namespace is called host namespace. Everything that you create inside the vCluster lives either inside the vCluster itself or inside the host namespace. 
+Every vCluster runs on top of another Kubernetes cluster, called the host cluster. Each vCluster runs as a regular StatefulSet inside a namespace of the host cluster. This namespace is called the host namespace. Everything that you create inside the vCluster lives either inside the vCluster itself or inside the host namespace. 
 
-It is possible to run multiple vClusters inside the same namespace and you can even run vClusters inside another vCluster (vcluster nesting).
+It is possible to run multiple vClusters inside the same namespace and you can even run vClusters inside another vCluster (vCluster nesting).
 
 
 ## Kubernetes Resources
@@ -29,7 +29,7 @@ The core idea of virtual clusters is to provision isolated Kubernetes control pl
 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](../deploying-vclusters/persistence.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.
+To be able to actually start pods, 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.
 
 
 ## Design Principles
@@ -43,20 +43,20 @@ vClusters should be as lightweight as possible to minimize resource overhead ins
 ### 2. No Performance Degradation
 Workloads running inside a vCluster (even inside [nested vClusters](#host-cluster--namespace)) should run with the same performance as workloads that are running directly on the underlying host cluster. The computing power, the access to underlying persistent storage as well as the network performance should not be degraded at all.
 
-**Implementation:** This is mainly achieved by synchronizing pods which means that the pods are actually being scheduled and started just like regular pods of the underlying host cluster, i.e. if you run a pod inside the vCluster and you run the same pod directly on the host cluster will be exactly the same in terms of computing power, storage access, and networking. 
+**Implementation:** This is mainly achieved by synchronizing pods which means that the pods are actually being scheduled and started just like regular pods of the underlying host cluster, i.e. if you run a pod inside the vCluster and you run the same pod directly on the host cluster it will be exactly the same in terms of computing power, storage access, and networking. 
 
 ### 3. Reduce Requests On Host Cluster
 vClusters should greatly reduce the number of requests to the Kubernetes API server of the underlying [host cluster](#host-cluster--namespace) by ensuring that all high-level resources remain in the virtual cluster only without ever reaching the underlying host cluster.
 
-**Implementation:** This is mainly achieved by using a separate API server that handles all requests to the vCluster and a separate data store that stores all objects inside the vCluster. Only the syncer synchronizes very few low-level resources to the underlying cluster which requires very few API server requests. All of this happens in an asynchronous, non-blocking fashion (as pretty much everything in Kubernetes is designed to be).
+**Implementation:** This is mainly achieved by using a separate API server that handles all requests to the vCluster and a separate data store that stores all objects inside the vCluster. The syncer synchronizes only a few low-level resources to the underlying cluster which requires very few API server requests. All of this happens in an asynchronous, non-blocking fashion (as pretty much everything in Kubernetes is designed to be).
 
 ### 4. Flexible & Easy Provisioning
-vCluster should not make any assumptions about how it is being provisioned. Users should be able to create vClusters on top of any Kubernetes cluster without requiring the installation of any server-side component to provision the vClusters, i.e. provisioning should be possible with any client-only deployment tool (vcluster CLI, helm, kubectl, kustomize, ...). An operator or CRDs may be added to manage vClusters (e.g. using Argo to provision vClusters) but a server-side management plane should never be required for spinning up a vCluster.
+vCluster should not make any assumptions about how it is being provisioned. Users should be able to create vClusters on top of any Kubernetes cluster without requiring the installation of any server-side component to provision the vClusters, i.e. provisioning should be possible with any client-only deployment tool (vCluster CLI, helm, kubectl, kustomize, ...). An operator or CRDs may be added to manage vClusters (e.g. using Argo to provision vClusters) but a server-side management plane should never be required for spinning up a vCluster.
 
 **Implementation:** This is mainly achieved by making vCluster basically run as a simple StatefulSet + Service (see kubectl deployment method for details) which can be deployed using any Kubernetes tool.
 
 ### 5. No Admin Privileges Required
-To provision a vCluster, a user should never be required to have any cluster-wide permissions. If a user has the RBAC permissions to deploy a simple web application to a namespace, they should also be able to deploy vClusters to this namespace.
+To provision a vCluster, a user should never be required to have any cluster-wide permissions. If a user has the RBAC permissions to deploy a simple web application to a namespace, they should also be able to deploy vClusters to the namespace.
 
 **Implementation:** This is mainly achieved by making vCluster basically run as a simple StatefulSet + Service (see kubectl deployment method for details) which typically every user has the privilege to run if they have any Kubernetes access at all.