Update README.md and Scenarios page

README.md

@@ -118,6 +118,14 @@ You can observe that:
   kubectl get pods -n liqo-demo -o wide  
 ``` 
 
+### Going Further
+
+If you want to understand and get more in details with Liqo, you can explore the documentation website:
+
+* Continue the Liqo journey by continuing to explore the [Liqo playground](https://doc.liqo.io/user/gettingstarted/play/)
+* Find out how to install Liqo on [your clusters](https://doc.liqo.io/user/install/)
+* Read more about the [Liqo architecture](https://doc.liqo.io/architecture/)
+
 ## Installation
 
 Liqo can be installed by using Helm. The configuration depends on the cluster type (K8s, K3s, managed) and the provider. Possible scenarios can be found [here](https://doc.liqo.io/user/scenarios/).
@@ -128,10 +136,10 @@ Once you identified your scenario, follow the instructions for the proper instal
 
 Planned features for the next release (v0.3, expected mid-July, 2021) are the following:
 
-* Support for deployments spanning across more than two clusters
-* Support for a more balanced scheduling mechanism to distribute jobs across clusters
-* Support for Amazon Elastic Kubernetes Service
-* Support for more-granular permission control over remote cluster resources
+* Support for deployments spanning across more than two clusters.
+* Support for a more balanced scheduling mechanism to distribute jobs across clusters.
+* Support for Amazon Elastic Kubernetes Service.
+* Support for more-granular permission control over remote cluster resources.
 
 ## Contributing
 

docs/pages/User/Install/_index.md

@@ -6,7 +6,7 @@ weight: 4
 ### Pre-Installation
 
 Liqo can be used with different topologies and scenarios. This impacts several installation parameters you will configure (e.g., API Server, Authentication). In
-the [scenarios pages](../scenarios), we present some common patterns used to expose and interconnect clusters.
+the [scenarios pages](./pre-install), we present some common patterns used to expose and interconnect clusters.
 
 ### Installation
 

docs/pages/User/Install/platforms/aks.md

@@ -9,7 +9,7 @@ Azure Kubernetes Service (AKS) is a managed Kubernetes service available on the
 
 #### Scenarios
 
-This guide will show you how to install Liqo on your AKS cluster. AKS clusters have by default an Internet-exposed API Server and can easily expose LoadBalancer services using public IPs. As discussed in [Scenarios](/user/scenarios) section, those latter are the requirements to have a "public-exposed" cluster, which can be accessed by other Liqo instances.
+This guide will show you how to install Liqo on your AKS cluster. AKS clusters have by default an Internet-exposed API Server and can easily expose LoadBalancer services using public IPs. As discussed in [Scenarios](/user/install/pre-install) section, those latter are the requirements to have a "public-exposed" cluster, which can be accessed by other Liqo instances.
 
 Liqo may be installed on newly created clusters or existing ones.
 

docs/pages/User/Install/platforms/gke.md

@@ -14,7 +14,7 @@ Google Kubernetes Engine (GKE) is a managed Kubernetes service available on the
 
 ### Scenarios
 
-This guide will show you how to install Liqo on your GKE cluster. GKE clusters have by default an Internet-exposed API Service and can easily expose LoadBalancer services. As discussed in [Scenarios](/user/scenarios) section, those latter are the requirements to have a "public-exposed" cluster, which can be accessed by other Liqo instances.
+This guide will show you how to install Liqo on your GKE cluster. GKE clusters have by default an Internet-exposed API Service and can easily expose LoadBalancer services. As discussed in [Scenarios](/user/install/pre-install) section, those latter are the requirements to have a "public-exposed" cluster, which can be accessed by other Liqo instances.
 
 Liqo may be installed on a newly created clusters or on existing ones.
 

docs/pages/User/Install/platforms/k8s.md

@@ -5,7 +5,8 @@ weight: 3
 
 ### About Kubeadm
 
-[Kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) is a tool built by the Kubernetes community to provision Kubernetes clusters. Kubeadm is used as the basis of most Kubernetes deployments and makes it easier to create conformant clusters.
+[Kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) is a tool built by the Kubernetes community to provision Kubernetes clusters. Kubeadm is used as the basis of most Kubernetes deployments and makes it easier to create K8s clusters.
+
 ### CNI Compatibility Matrix
 
 Kubeadm does not install any CNI plugin by default, and it must be deployed after the initialization of the cluster.

docs/pages/User/Install/pre-install.md

@@ -0,0 +1,77 @@
+---
+title: Pre-Install
+weight: 2
+---
+
+### Introduction
+
+Liqo can be installed either in private or local clusters. Its configuration depends on the type of connectivity between the two clusters. Before installing Liqo, you have to consider how your clusters can connect to each other and can peer together.
+
+### Peering Requirements
+
+Liqo requires the following services to be reciprocally accessible to perform cluster peerings:
+
+* **Authentication server** used to authenticate other clusters (i.e. `liqo-auth`).
+* The **Kubernetes API server** you want to peer.
+* **Network gateway** used to establish interconnection between clusters (i.e. `liqo-gateway`)
+
+Those services have to be accessible from the other clusters to peer with them. This may change the way you would like to have them exposed.
+Below it is possible to find some common scenarios that Liqo can handle. Once you identify yours, you can go have to the *table* of each section to find the right values you should specify when installing Liqo using the chart.
+
+### Cloud to cloud
+
+![](/images/scenarios/cloud-to-cloud.svg)
+
+Two managed clusters peered together through the internet. It is possible to have a multi-cloud setup (AKS to AKS, GKE to GKE, and AKS to GKE). In this scenario, the services to exposes should be exposed using Public IPs/URLs.
+
+|  | Cluster A (Cloud) | Cluster B (Cloud) |
+| --------- | -------- |  ---------       | |
+| **Auth Server** |  LoadBalancer/ingress | LoadBalancer/ingress |
+| **API server** | Provided | Provided |
+| **Network gateway** | LoadBalancer/Node Port | LoadBalancer/Node Port |
+
+Considering the Network Gateway, at least one among Cluster A and Cluster B should have the **Network Gateway** IP accessible from the other one (e.g.; Public IP).
+
+### On-premise to cloud
+
+![](/images/scenarios/on-prem-to-cloud.svg)
+
+On-premise cluster (K3s or K8s) exposed through the Internet peered with a Managed cluster (AKS or GKE).
+
+|  | Cluster A (On-prem) | Cluster B (Cloud) |
+| --------- | -------- |  ---------       |
+| **Auth Server** |  LoadBalancer/Ingress | LoadBalancer/Ingress |
+| **API server** | Ingress/Public IP | Provided |
+| **Network gateway** | LoadBalancer/Node Port | LoadBalancer/Node Port |
+
+Clusters API Server should be mutually accessible and so should be for the Auth Service.
+Considering the Network Gateway, at least one among Cluster A and Cluster B should have the **Network Gateway** IP accessible from the other one (e.g.; Public IP).
+
+#### On-premise behind NAT to cloud
+
+![](/images/scenarios/on-prem-nat-to-cloud.svg)
+
+When the On-premise cluster is exposed through a NAT, the configuration slightly changes:
+
+|  | Cluster A (On-prem behind NAT) | Cluster B (Cloud) |
+| --------- | -------- |  ---------       |
+| **Auth Server** |  NodePort with port-forwarding | LoadBalancer/ingress |
+| **API server** | Port-forwarding | Provided |
+| **Network gateway** | NodePort with port-forwarding | LoadBalancer |
+
+In this situation, the "cloud" cluster should have the Network Gateway exposed as a **LoadBalancer**. A couple of port-forwardings should be also configured for the Auth Server and K8s API Server to make them accessible from the Cloud B.
+
+### Clusters in the same LAN
+
+![](/images/scenarios/on-prem-to-on-prem.svg)
+
+Clusters (K3s or K8s) in the same LAN may rely on the mDNS-based Liqo discovery mechanism.
+In fact, the Liqo discovery mechanism based on mDNS will handle the discovery automatically. If you have your clusters in different L3 domains, you have to manually [create](/user/post-install/discovery#forging-the-foreigncluster) a *foreign_cluster* resource or rely on [DNS discovery](/user/post-install/discovery#manual-configuration).
+
+|  | Cluster A (On-prem) | Cluster B (On-prem) |
+| --------- | -------- |  ---------       |
+| **Auth Server** |  NodePort | NodePort |
+| **API server** | Exposed | Exposed |
+| **Network gateway** | NodePort | NodePort |
+
+This configuration is provided using the standard values of the Liqo chart.