add faq page

content/en/docs/concepts/add-on-extensibility/addon.md

@@ -22,7 +22,7 @@ addon should consist of two kinds of components:
   cluster like an ordinary kubernetes operator does.
 
 - __Addon Manager__: A kubernetes controller *in the hub cluster* that applies
-  manifests to the managed clusters via the [ManifestWork](../manifestwork)
+  manifests to the managed clusters via the [ManifestWork](../work-distribution/manifestwork)
   api. In addition to resource dispatching, the manager can optionally manage
   the lifecycle of CSRs for the addon agents or even the RBAC permission bond
   to the CSRs' requesting identity.

content/en/docs/concepts/cluster-inventory/managedcluster.md

@@ -199,7 +199,7 @@ ManagedCluster when it is not reachable. To be specific,
 
 Tolerations are applied to Placements, and allow Placements to select
 ManagedClusters with matching taints. Refer to [Placement
-Taints/Tolerations](../placement/#taintstolerations) to see how it is used for
+Taints/Tolerations](../content-placement/placement/#taintstolerations) to see how it is used for
 cluster selection.
 
 ### Cluster removal
@@ -261,5 +261,5 @@ identity. The following picture shows the automated certificate rotation works.
 ## What's next?
 
 Furthermore, we can do advanced cluster matching/selecting within a
-[managedclusterset](./managedclusterset.md) using the [placement](./placement.md)
+[managedclusterset](./managedclusterset) using the [placement](../content-placement/placement)
 module.

content/en/docs/concepts/cluster-inventory/managedclusterset.md

@@ -40,7 +40,7 @@ relationship:
   cluster set can be operated from all the bound namespaces at the same time.
 
 The cluster set admin can flexibly operate the member clusters in the workspace
-namespace using [Placement](../placement) API, etc.
+namespace using [Placement](../content-placement/placement) API, etc.
 
 The following picture shows the hierarchies of how the cluster set works:
 

content/en/docs/concepts/content-placement/placement.md

@@ -22,8 +22,8 @@ aliases:
 
 ## Overall
 
-`Placement` concept is used to dynamically select a set of [managedClusters](../managedcluster)
-in one or multiple [ManagedClusterSet](../managedclusterset) so that higher level
+`Placement` concept is used to dynamically select a set of [managedClusters](../cluster-inventory/managedcluster)
+in one or multiple [ManagedClusterSet](../cluster-inventory/managedclusterset) so that higher level
 users can either replicate Kubernetes resources to the member clusters or run
 their advanced workload i.e. __multi-cluster scheduling__.
 
@@ -48,7 +48,7 @@ multi-cluster scheduling is logically divided into two phases internally:
 
 ## Select clusters in ManagedClusterSet
 
-By following [the previous section](../managedclusterset) about
+By following [the previous section](../cluster-inventory/managedclusterset) about
 `ManagedClusterSet`, now we're supposed to have one or multiple valid cluster
 sets in the hub clusters. Then we can move on and create a placement in the
 "workspace namespace" by specifying `predicates` and `prioritizers` in the
@@ -62,7 +62,7 @@ sets in the hub clusters. Then we can move on and create a placement in the
 
 #### Label/Claim selection
 
-In the `predicates` section, you can select clusters by labels or [clusterClaims](../clusterclaim).
+In the `predicates` section, you can select clusters by labels or [clusterClaims](../cluster-inventory/clusterclaim).
 For instance, you can select 3 clusters with label `purpose=test` and
 clusterClaim `platform.open-cluster-management.io=aws` as seen in the following
 examples:
@@ -106,7 +106,7 @@ cluster.
 In OCM, Taints and Tolerations work together to allow users to control the
 selection of managed clusters more flexibly.
 
-[Taints](../managedcluster/#cluster-taints-and-tolerations) are properties of
+[Taints](../cluster-inventory/managedcluster/#cluster-taints-and-tolerations) are properties of
 ManagedClusters, they allow a Placement to repel a set of ManagedClusters in
 predicates stage.
 
@@ -494,7 +494,7 @@ metadata:
 
 ### Rollout Strategy
 
-Rollout Strategy [API](https://github.com/open-cluster-management-io/api/blob/main/cluster/v1alpha1/types_rolloutstrategy.go) facilitate the use of placement decision strategy with OCM workload applier APIs such as Policy, [Addon](https://open-cluster-management.io/concepts/addon/#add-on-rollout-strategy) and [ManifestWorkReplicaSet](https://open-cluster-management.io/concepts/manifestworkreplicaset/) to apply workloads.
+Rollout Strategy [API](https://github.com/open-cluster-management-io/api/blob/main/cluster/v1alpha1/types_rolloutstrategy.go) facilitate the use of placement decision strategy with OCM workload applier APIs such as Policy, [Addon](../add-on-extensibility/addon/#rollout-strategy) and [ManifestWorkReplicaSet](../work-distribution/manifestworkreplicaset/) to apply workloads.
 
 ```yaml
     placements:

content/en/docs/faq/_index.md

@@ -0,0 +1,43 @@
+---
+title: FAQ
+weight: 8
+---
+
+Welcome to our Frequently Asked Questions (FAQ) page! Here, you'll find answers to some of the most common questions we receive. If you have a question that isn't covered here, feel free to reach out to us directly.
+
+## Questions
+
+### What is the difference between Karmada and OCM? ###
+
+We have a post about this at CNCF blog: [Karmada and Open Cluster Management: two new approaches to the multicluster fleet management challenge](https://www.cncf.io/blog/2022/09/26/karmada-and-open-cluster-management-two-new-approaches-to-the-multicluster-fleet-management-challenge/).
+
+### What is the difference between ManifestWork, ManifestWorkReplicaset and AddOn? When to use them? ###
+
+**1. [Manifestwork](../concepts/work-distribution/manifestwork)**
+
+**_Definition:_** Manifestwork is a resource used to define a group of Kubernetes resources that should be applied to a managed cluster from a hub cluster. It allows for the deployment of various resources (like Deployments, Services, etc.) to a specific managed cluster. 
+
+**_Use Case:_** Use ManifestWork when you want to apply a specific set of resources to a single managed cluster. It is ideal for scenarios where you need to manage resources directly and track their status on that cluster.
+
+**_Example:_** Deploying a Deployment and a Service to a managed cluster. You can use [clusteradm](https://github.com/open-cluster-management-io/clusteradm) command `clusteradm create work work-example -f xxx.yaml --clusters cluster1` to wrap the kubernetes native resource with a ManifestWork and submit it to a sepecific managed cluster. 
+
+**2. [ManifestWorkReplicaSet](../concepts/work-distribution/manifestworkreplicaset)**
+
+**_Definition:_** ManifestWorkReplicaSet is an aggregator API that utilizes [Manifestwork](../concepts/work-distribution/manifestwork) and [Placement](../concepts/content-placement/placement) to create multiple ManifestWork resources for clusters selected by placements. It allows for the deployment of resources across multiple clusters based on defined rollout strategies.
+
+**_Use Case:_** Use ManifestWorkReplicaSet when you need to deploy the same resources to multiple clusters simultaneously, with the ability to control the rollout strategy (e.g., all at once, progressively, etc.). It is useful for managing deployments across a fleet of clusters.
+
+**_Example:_** Deploying a CronJob and Namespace to multiple clusters selected by a placement strategy.
+
+**3. [Add-On](../concepts/add-on-extensibility/addon)**
+
+**_Definition:_** An Add-On in Open Cluster Management is a mechanism that consists of an Addon Agent (running in managed clusters) and an Addon Manager (running in the hub cluster). It allows for the management of extensions that work with multiple clusters, providing a way to apply configurations and manage the lifecycle of resources across clusters by using the rollout strategy.
+
+**_Use Case:_** Use Add-Ons when you need to implement a more complex solution that requires ongoing management and configuration of resources across multiple clusters. 
+
+**_Example:_** A tool that collects alert events from managed clusters and sends them to the hub cluster.
+
+**Summary**
+- ManifestWork is for single cluster resource management.
+- ManifestWorkReplicaSet is for managing resources across multiple clusters with defined rollout strategies.
+- Add-On is for implementing extensions that require ongoing management and configuration across multiple clusters, leveraging both an agent and a manager. Also provide the ability to control the addon's lifecycle with rollout strategy.