address Benefits of Virtual Clusters feedback

changed section name
add links to internal and external docs
fix grammar nits

docs/pages/fragments/install/cli.mdx

@@ -19,6 +19,9 @@ import TabItem from "@theme/TabItem";
 brew install loft-sh/tap/vcluster
 ```
 
+If you installed the CLI using `brew install vlcuster`, you should `brew uninstall vcluster` and then install using the tap.
+The binaries in the tap are signed using the [Sigstore](https://docs.sigstore.dev/) framework for enhanced security.
+
 </TabItem>
 <TabItem value="mac">
 

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

@@ -46,30 +46,31 @@ Finally, virtual clusters can be configured independently of the physical cluste
     <figcaption>vCluster - Comparison</figcaption>
 </figure>
 
-## Benefits of Virtual Clusters
+## Benefits of vClusters
+
+vClusters provide immense benefits for large-scale Kubernetes deployments and multi-tenancy.
 
-Virtual clusters provide immense benefits for large-scale Kubernetes deployments and multi-tenancy:
 - **Full Admin Access**:
-    - Deploy operators with CRDs, create namespaces and other cluster scoped resources that's usually not possible in namespaces.
-    - Taint and label nodes without any influence on the host cluster.
+    - Deploy operators with CRDs, create namespaces and other cluster-scoped resources that you normally can't create inside a namespace.
+    - Taint and label nodes without influencing the host cluster. See [Nodes](./architecture/nodes.mdx) and [Pod Scheduling](./architecture/scheduling.mdx) for more information.
     - Reuse and share services across multiple virtual clusters with ease.
 - **Cost Savings:**
-    - You can create lightweight vClusters that share the underlying host cluster instead of creating separate "real" clusters.
-    - vClusters are just deployments, so they can be easily auto-scaled, purged, snapshotted and moved.
+    - Create lightweight vClusters that share the underlying host cluster instead of creating separate "real" clusters.
+    - Auto-scale, purge, snapshot, and move your vClusters, since they are Kubernetes deployments.
 - **Low Overhead:**
     - vClusters are super lightweight and only reside in a single namespace.
-    - vClusters run with K3s, a super low-footprint K8s distribution, but they can also run with "real" K8s.
-    - The control plane of a vCluster runs inside a single pod (+1 CoreDNS pod for vCluster-internal DNS capabilities).
-- **<u>No</u> Network Degradation:**
-    - Since the pods and services inside a vCluster are actually being synchronized down to the host cluster\*, they are effectively using the underlying cluster's pod and service networking and are therefore not a bit slower than any other pods in the underlying host cluster.
+    - vClusters run with [K3s](https://k3s.io/), a super low-footprint K8s distribution. You can use other [supported distributions](./deploying-vclusters/supported-distros) such as [K0s](https://k0sproject.io/), vanilla [Kubernetes](https://kubernetes.io/), and [AWS EKS](https://aws.amazon.com/eks/).
+    - The vCluster control plane runs inside a single pod. Open source vCluster also uses a CoreDNS pod for vCluster-internal DNS capabilities. With vCluster.Pro, however, you can [enable the integrated CoreDNS](https://www.vcluster.com/pro/docs/features/integrated_coredns) so you don't need the additional pod.
+- **No Network Degradation:**
+    - Since the pods and services inside a vCluster are actually being synchronized down to the host cluster, they are effectively using the underlying cluster's pod and service networking. The vCluster pods are as fast as other pods in the underlying host cluster.
 - **API Server Compatibility:**
-    - vClusters run with the K3s API server which is certified K8s distro which ensures 100% Kubernetes API server compliance.
-    - vCluster have their own API server, controller-manager and a separate, isolated data store (sqlite for easiest option but this is configurable, you can also deploy a full-blown etcd if needed).
+    - vClusters run with the API server from the Kubernetes distribution that you choose to use. This ensures 100% Kubernetes API server compliance.
+    - vCluster manages its API server, controller-manager, and a separate, isolated data store. Use the embedded SQLite or a full-blown etcd if that's what you need. See [Persisting vCluster data](./deploying-vclusters/persistence) for a list of supported data stores.
 - **Security:**
-    - vCluster users need much fewer permissions in the underlying host cluster / host namespace.
-    - vCluster users can manage their own CRDs independently and can even mess with RBAC inside their own vClusters.
-    - vClusters provide an extra layer of isolation because each vCluster has its own API server and control plane (much fewer requests to the underlying cluster that need to be secured\*).
+    - vCluster users need fewer permissions in the underlying host cluster / host namespace.
+    - vCluster users can manage their own CRDs independently and can even modify RBAC inside their own vClusters.
+    - vClusters provide an extra layer of isolation. Each vCluster manages its own API server and control plane, which means that fewer requests to the underlying cluster need to be secured.
 - **Scalability:**
-    - Less pressure / fewer requests on the K8s API server in large-scale cluster\*
-    - Higher scalability of cluster via cluster sharding / API server sharding into smaller vClusters
-    - No need for cluster admins to worry about conflicting CRDs or CRD versions with growing number of users and deployments
+    - Less pressure / fewer requests on the K8s API server in a large-scale cluster.
+    - Higher scalability of clusters via cluster sharding / API server sharding into smaller vClusters.
+    - No need for cluster admins to worry about conflicting CRDs or CRD versions with a growing number of users and deployments.