diff --git a/versioned_docs/version-1.2.0/application-layer/kiali.md b/versioned_docs/version-1.2.0/application-layer/kiali.md
new file mode 100644
index 00000000..540f27b7
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/kiali.md
@@ -0,0 +1,62 @@
+---
+sidebar_position: 8
+title: Use Kiali to visualize traffic graph under Kmesh
+---
+
+## Preparation
+
+1. Make default namespace managed by Kmesh.
+
+2. Deploy bookinfo as sample application and sleep as curl client.
+
+3. \[optional\] Install service granularity waypoint for service `reviews`.
+
+ _The above steps could refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation). When installing Istio, we recommend installing Istio ambient mode instead of only installing Istiod, because Kiali currently depends on Istio components to work._
+
+4. Deploy prometheus that record Kmesh metrics as Istio standard metrics.
+
+ _This Prometheus addon leverages the Prometheus recording rules and relabeling configurations to convert Kmesh L4 metrics into Istio standard metrics, so that Kiali could visualize these metrics._
+
+ ```bash
+ kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus_recording_istio.yaml
+ ```
+
+5. Deploy Kiali which reads metrics from the Prometheus.
+
+ ```bash
+ kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/kiali.yaml
+ ```
+
+## Generate some continuous traffic between applications in the mesh
+
+```bash
+kubectl exec deploy/sleep -- sh -c "while true; do curl -s http://productpage:9080/productpage | grep reviews-v.-; sleep 1; done"
+```
+
+## Use Kiali to visualize the traffic graph of services
+
+1. Use the port-forward command to forward traffic to kiali.
+
+ ```bash
+ kubectl port-forward --address 0.0.0.0 svc/kiali 20001:20001 -n kmesh-system
+ Forwarding from 0.0.0.0:20001 -> 20001
+ ```
+
+2. View the traffic graph in Kiali from browser.
+
+ Visit `Traffic Graph` panel. Select the `default` namespace at the top of left.
+
+ 
+
+ _In this traffic topology graph, the blue lines represent TCP traffic, which is proxied by Kmesh, while the green lines represent HTTP traffic, which is proxied by Waypoint. For more information about Kiali's traffic topology graph, please refer to [Kiali's documentation](https://kiali.io/docs/features/topology/)._
+
+## Cleanup
+
+1. Remove prometheus and grafana:
+
+ ```bash
+ kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus_recording_istio.yaml
+ kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/kiali.yaml
+ ```
+
+2. If you are not planning to explore any follow-on tasks, refer to the [Install Waypoint/Cleanup](/docs/application-layer/install_waypoint.md#cleanup) instructions to remove waypoint and shutdown the application.
diff --git a/versioned_docs/version-1.2.0/application-layer/locality-loadbalance.md b/versioned_docs/version-1.2.0/application-layer/locality-loadbalance.md
new file mode 100644
index 00000000..e4deacdf
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/locality-loadbalance.md
@@ -0,0 +1,373 @@
+---
+sidebar_position: 9
+title: Locality Load Balancing
+---
+
+This document explains how to use Locality Load Balancing with Istio in Kmesh.
+
+Note: Kmesh's current Locality Load Balancing operates at L4 and only supports [Locality Failover](https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/failover/).
+
+## What is Locality Load Balancing?
+
+A locality describes the geographic location of a workload instance in the mesh. Locality Load Balancing improves availability and performance by routing traffic based on the location of service instances.
+
+We strongly recommend reading https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/ for background on locality load balancing.
+
+## Supported Modes and Configuration Methods for Kmesh
+
+Currently, Istio's ambient mode supports specifying a fixed locality load-balancing policy via configuration. Kmesh supports two modes: PreferClose and Local.
+
+### 1. PreferClose
+
+Failover mode that uses NETWORK, REGION, ZONE, and SUBZONE as the routing preference.
+
+- With `spec.trafficDistribution` (k8s >= beta [1.31.0](https://kubernetes.io/docs/concepts/services-networking/service/), istio >= [1.23.1](https://istio.io/latest/news/releases/1.23.x/announcing-1.23/))
+
+ ```yaml
+ spec:
+ trafficDistribution: # spec.trafficDistribution
+ preferClose: true
+ ```
+
+- With annotation
+
+ ```yaml
+ metadata:
+ annotations:
+ networking.istio.io/traffic-distribution: PreferClose
+ ```
+
+### 2. Local
+
+Strict mode that restricts traffic to the current node.
+
+- Set `spec.internalTrafficPolicy: Local` (k8s >= beta 1.24 or >= 1.26)
+
+ ```yaml
+ spec:
+ internalTrafficPolicy: Local
+ ```
+
+## Experimental Testing
+
+### Prepare the environment
+
+- Refer to [develop with kind](/docs/setup/develop-with-kind.md).
+- A three-node kind cluster is required.
+- istio >= 1.23.1
+- k8s >= 1.31.0
+- Ensure sidecar injection is disabled: `kubectl label namespace default istio-injection-`
+- Required images:
+ - `docker.io/istio/examples-helloworld-v1`
+ - `curlimages/curl`
+
+```yaml
+kind create cluster --image=kindest/node:v1.31.0 --config=- < /dev/null || \
+ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=v1.4.0" | kubectl create -f -; }
+```
+
+Next, create a dedicated Waypoint proxy for the `httpbin` service and label the service to direct its traffic through this Waypoint.
+
+```sh
+kmeshctl waypoint apply -n default --name httpbin-waypoint --image ghcr.io/kmesh-net/waypoint:latest
+
+kubectl label service httpbin istio.io/use-waypoint=httpbin-waypoint
+```
+
+### 4. Deploy envoyFilter
+
+This `EnvoyFilter` resource injects a local rate-limit filter into the `httpbin` service's Waypoint proxy. The filter is configured with the following rules:
+
+- A request with the header `quota: low` will be limited to **1 request per 300 seconds**.
+- A request with the header `quota: medium` will be limited to **3 requests per 300 seconds**.
+- Other requests will be subject to a default limit of **10 requests per 300 seconds**.
+
+The `workloadSelector` ensures that this filter is applied only to the `httpbin-waypoint` proxy.
+
+```sh
+kubectl apply -f -<
+
+
diff --git a/versioned_docs/version-1.2.0/application-layer/try-request-routing.md b/versioned_docs/version-1.2.0/application-layer/try-request-routing.md
new file mode 100644
index 00000000..9bba610a
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/try-request-routing.md
@@ -0,0 +1,167 @@
+---
+sidebar_position: 4
+title: Try Request Routing
+---
+
+## Preparation
+
+1. Make default namespace managed by Kmesh
+2. Deploy bookinfo as sample application and sleep as curl client
+3. Install service granularity waypoint for reviews service
+
+ _The above steps could refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation)_
+
+## Apply version-based routing
+
+1. Run the following command to create the route rules:
+
+```bash
+kubectl apply -f -<reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+ ...
+ reviews-v1-598f9b58fc-jc25r
+ reviews-v1-598f9b58fc-jc25r
+```
+
+## Apply user-identity-based routing
+
+Next, you will change the route configuration so that all traffic from a specific user is routed to a specific service version. In this case, all traffic from a user named Jason will be routed to the service `reviews:v2`.
+
+This example is enabled by the fact that the `productpage` service adds a custom `end-user` header to all outbound HTTP requests to the reviews service.
+
+1. Run the following command to enable user-based routing:
+
+```bash
+kubectl apply -f -<
+
+
diff --git a/versioned_docs/version-1.2.0/application-layer/try-request-timeout.md b/versioned_docs/version-1.2.0/application-layer/try-request-timeout.md
new file mode 100644
index 00000000..66ab7d0f
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/try-request-timeout.md
@@ -0,0 +1,130 @@
+---
+sidebar_position: 7
+title: Try Request Timeouts
+---
+
+# Try Request Timeouts
+
+## Preparation
+
+1. Make default namespace managed by Kmesh
+
+2. Deploy bookinfo as sample application
+
+3. Install service granularity waypoint for reviews service
+
+ _The above steps could refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation)_
+
+4. And install waypoint for ratings service
+
+ ```bash
+ istioctl x waypoint apply -n default --name ratings-svc-waypoint
+ kubectl label service ratings istio.io/use-waypoint=ratings-svc-waypoint
+ kubectl annotate gateway ratings-svc-waypoint sidecar.istio.io/proxyImage=ghcr.io/kmesh-net/waypoint:latest
+ ```
+
+## Request timeouts
+
+A timeout for HTTP requests can be specified using a timeout field in a route rule. By default, the request timeout is disabled, but in this task you override the `reviews` service timeout to half a second. To see its effect, however, you also introduce an artificial 2 second delay in calls to the `ratings` service.
+
+1. Route requests to v2 of the `reviews` service, i.e., a version that calls the `ratings` service:
+
+ ```bash
+ kubectl apply -f - <
+
+
diff --git a/versioned_docs/version-1.2.0/application-layer/try-service-entry.md b/versioned_docs/version-1.2.0/application-layer/try-service-entry.md
new file mode 100644
index 00000000..40017c3a
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/try-service-entry.md
@@ -0,0 +1,466 @@
+---
+sidebar_position: 5
+title: Try Service Entry
+---
+
+Service Entry enables you to extend Istio's service registry by adding entries for external services. This allows applications in the mesh to discover, access, and apply traffic policies to services that are not automatically discovered in the service mesh. With Kmesh's DNS Controller for Workloads, Service Entry now supports dynamic DNS resolution, making it seamless to integrate external services with changing IP addresses.
+
+## What is Service Entry?
+
+Service Entry is a critical Istio resource that allows you to:
+
+- **Add external services** to the mesh's internal service registry
+- **Enable traffic management** (routing, load balancing, retries) for external services
+- **Support multiple resolution modes** including DNS, STATIC, and NONE
+- **Control egress traffic** with consistent policies
+
+Kmesh enhances Service Entry with intelligent DNS resolution that automatically handles hostname-to-IP address mapping for external services, ensuring seamless connectivity even when backend addresses change dynamically.
+
+## Preparation
+
+Before getting started, ensure you have completed the following steps:
+
+1. **Make default namespace managed by Kmesh**
+2. **Deploy Httpbin as sample application and Sleep as curl client**
+3. **Install waypoint for default namespace**
+
+ _For detailed instructions on the above steps, refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation)_
+
+## Verify Environment Setup
+
+Confirm that the httpbin and sleep applications are running properly:
+
+```bash
+kubectl get pods
+```
+
+You should see both services in Running state:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+httpbin-6f4464f6c5-h9x2p 1/1 Running 0 30s
+sleep-9454cc476-86vgb 1/1 Running 0 5m
+```
+
+## Understanding Service Entry Configuration
+
+### Basic Service Entry with DNS Resolution
+
+Let's create a Service Entry that defines a virtual external service. This example demonstrates how Kmesh's DNS Controller automatically resolves the backend hostname:
+
+```bash
+kubectl apply -f - </dev/null || true
+kubectl delete serviceentry multi-endpoint-svc -n default 2>/dev/null || true
+```
+
+If you're not planning to continue with subsequent experiments, refer to the [Install Waypoint/Cleanup](/docs/application-layer/install_waypoint.md#cleanup) section for instructions on removing the waypoint and cleaning up applications.
+
+## Summary
+
+Through this guide, you learned how to:
+
+1. **Add external services** to the Istio service mesh using Service Entry
+2. **Configure DNS-based resolution** leveraging Kmesh's intelligent DNS Controller
+3. **Use static IP endpoints** for services with fixed addresses
+4. **Set up multiple backends** with automatic load balancing
+5. **Access real external services** on the internet from within the mesh
+6. **Troubleshoot common issues** related to Service Entry configuration
+
+### Key Takeaways
+
+- **Service Entry extends your mesh** beyond automatically discovered services
+- **Kmesh's DNS Controller** provides dynamic, automatic hostname resolution
+- **Multiple resolution modes** (DNS, STATIC, NONE) support different use cases
+- **DNS resolution is asynchronous** and includes retry logic for reliability
+- **Service Entry works seamlessly** with other Istio features like traffic routing and policies
+
+Service Entry is an essential tool for managing external service dependencies in Istio, providing consistent visibility, control, and reliability for services outside your mesh.
diff --git a/versioned_docs/version-1.2.0/application-layer/try-traffic-shifting.md b/versioned_docs/version-1.2.0/application-layer/try-traffic-shifting.md
new file mode 100644
index 00000000..f14956a8
--- /dev/null
+++ b/versioned_docs/version-1.2.0/application-layer/try-traffic-shifting.md
@@ -0,0 +1,102 @@
+---
+sidebar_position: 5
+title: Try Traffic Shifting
+---
+
+## Preparation
+
+1. Make default namespace managed by Kmesh
+2. Deploy bookinfo as sample application and sleep as curl client
+3. Install service granularity waypoint for reviews service
+
+_The above steps could refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation)_
+
+## Apply weight-based routing
+
+Configure traffic routing to send 90% of requests to `reviews v1` and 10% to `reviews v2`:
+
+```bash
+[root@ ~]# kubectl apply -f -<reviews-v1-57c85f47fb-n9llm
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v2-64776cb9bd-grnd2
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v1-57c85f47fb-n9llm
+ ...
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v2-64776cb9bd-grnd2
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v1-57c85f47fb-n9llm
+ reviews-v2-64776cb9bd-grnd2
+```
+
+## Understanding what happened
+
+Because `default` namespace has been managed by Kmesh and we have deployed a waypoint proxy for service `bookinfo-reviews`, so all traffic sent to service `reviews` will be forwarded to waypoint by Kmesh. Waypoint will send 90% of requests to `reviews v1` and 10% to `reviews v2` according to the route rules we set.
+
+## Cleanup
+
+1. Remove the application routing rules:
+
+```bash
+kubectl delete virtualservice reviews
+kubectl delete destinationrules reviews
+```
+
+2. If you are not planning to explore any follow-on tasks, refer to the [Install Waypoint/Cleanup](/docs/application-layer/install_waypoint.md#cleanup) instructions to remove waypoint and shutdown the application.
+
+## Demo
+
+
+
+
diff --git a/versioned_docs/version-1.2.0/architecture/_category_.json b/versioned_docs/version-1.2.0/architecture/_category_.json
new file mode 100644
index 00000000..7d9d2cf5
--- /dev/null
+++ b/versioned_docs/version-1.2.0/architecture/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Architecture",
+ "position": 3,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/architecture/architecture.md b/versioned_docs/version-1.2.0/architecture/architecture.md
new file mode 100644
index 00000000..694d0e1a
--- /dev/null
+++ b/versioned_docs/version-1.2.0/architecture/architecture.md
@@ -0,0 +1,40 @@
+---
+title: Kmesh Architecture
+description: ""
+sidebar_position: 1
+---
+
+
+
+## Architecture Overview
+
+The software architecture of Kmesh consists of the following core components:
+
+| Component | Description |
+| ------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
+| Kmesh-daemon | The daemon responsible for eBPF Orchestration lifecycle management, xDS protocol integration, observability, and other functions |
+| eBPF Orchestration | The traffic orchestration implemented with eBPF, including dynamic routing, authorization, load balancing |
+| Waypoint | Based on istio's waypoint to adapt to Kmesh protocols, responsible for L7 traffic management |
+
+## Component Details
+
+### Kmesh-daemon
+
+- eBPF lifecycle management
+- xDS protocol integration
+- Observability and monitoring
+- Configuration management
+
+### eBPF Orchestration
+
+- Dynamic routing implementation
+- Authorization
+- Load balancing optimization
+- Traffic acceleration
+
+### Waypoint
+
+- L7 traffic management
+- Protocol adaptation for Kmesh
+- Service mesh integration
+- Traffic policy enforcement
diff --git a/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.png b/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.png
new file mode 100644
index 00000000..8acbdaea
Binary files /dev/null and b/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.png differ
diff --git a/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.svg b/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.svg
new file mode 100644
index 00000000..0dcd6925
--- /dev/null
+++ b/versioned_docs/version-1.2.0/architecture/images/kmesh-arch.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/architecture/roadmap.md b/versioned_docs/version-1.2.0/architecture/roadmap.md
new file mode 100644
index 00000000..7b937887
--- /dev/null
+++ b/versioned_docs/version-1.2.0/architecture/roadmap.md
@@ -0,0 +1,31 @@
+---
+title: Roadmap
+description: ""
+sidebar_position: 2
+---
+
+| Feature Domain | Feature | 2023.H1 | 2023.H2 | 2024.H1 | 2024.H2 |
+| --------------------------------- | -------------------------------------- | :-----: | :-----: | :-----: | :-----: |
+| **Traffic Management** | Sidecarless mesh | ✓ | | | |
+| | Sockmap | | ✓ | | |
+| | Programmable governance based on eBPF | ✓ | | | |
+| | HTTP1.1 protocol | ✓ | | | |
+| | HTTP2 protocol | | | | ✓ |
+| | gRPC protocol | | | | ✓ |
+| | QUIC protocol | | | | ✓ |
+| | TCP protocol | | ✓ | | |
+| | Retry | | | ✓ | |
+| | Routing | ✓ | | | |
+| | Load balancing | ✓ | | | |
+| | Fault injection | | | | ✓ |
+| | Gray release | ✓ | | | |
+| | Circuit Breaker | | | ✓ | |
+| | Rate Limits | | | ✓ | |
+| **Service Security** | SSL-based two-way authentication | | | | ✓ |
+| | L7 authorization | | | | ✓ |
+| | Cgroup-level isolation | ✓ | | | |
+| **Traffic Monitoring** | Governance indicator monitoring | | ✓ | | |
+| | End-to-end observability | | | | ✓ |
+| **Programmable** | Plug-in expansion capability | | | | ✓ |
+| **Ecosystem Collaboration** | Data plane collaboration (Envoy, etc.) | | ✓ | | |
+| **Operating Environment Support** | Container | ✓ | | | |
diff --git a/versioned_docs/version-1.2.0/community/_category_.json b/versioned_docs/version-1.2.0/community/_category_.json
new file mode 100644
index 00000000..0be74b38
--- /dev/null
+++ b/versioned_docs/version-1.2.0/community/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Community",
+ "position": 8,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/community/contribute.md b/versioned_docs/version-1.2.0/community/contribute.md
new file mode 100644
index 00000000..34cd548a
--- /dev/null
+++ b/versioned_docs/version-1.2.0/community/contribute.md
@@ -0,0 +1,34 @@
+---
+title: Contributing
+sidebar_position: 1
+---
+
+## Code of Conduct
+
+Kmesh follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [kmesh.net.dev@gmail.com](mailto:kmesh.net.dev@gmail.com).
+
+## Community Expectations
+
+Kmesh is a community project driven by its community which strives to promote a healthy, friendly and productive environment.
+The community's goal is to build a high-performance service governance framework that requires the support of communities with similar aspirations.
+
+- See [Community Membership](membership.md) for a list of various community roles. With gradual contributions, one can move up in the chain.
+
+## Preparation
+
+- Fork the repository on GitHub
+- Download the repository
+- Read [CONTRIBUTING](https://github.com/kmesh-net/kmesh/blob/main/CONTRIBUTING.md) for more details
+
+## Meeting Information
+
+We host regular community meetings where contributors, maintainers, and users can share updates, discuss ideas, and collaborate on ongoing work.
+
+- **Frequency:** Every 2 weeks on **Thursday**
+- **Time:** 16:00 China / 08:00 UTC / 13:30 India Standard Time [Convert to your timezone](https://dateful.com/time-zone-converter?t=14%3A30&tz=GMT%2B8&)
+- **Meeting Link:** [Joining Link](https://zoom-lfx.platform.linuxfoundation.org/meeting/99299011908?password=f4c31ddd-11ed-42ae-a617-3e0842c39c58)
+- **Meeting Notes & Agenda:** [Google Docs](https://docs.google.com/document/d/1fFqolwWMVMk92yXPHvWGrMgsrb8Xru_v4Cve5ummjbk/edit?tab=t.0#heading=h.o8pz6aqnzzgk)
+
+Everyone is welcome to join — whether you are an active contributor, an interested user, or someone evaluating Kmesh for your needs.
diff --git a/versioned_docs/version-1.2.0/community/feature-lifecycle.md b/versioned_docs/version-1.2.0/community/feature-lifecycle.md
new file mode 100644
index 00000000..c172b04d
--- /dev/null
+++ b/versioned_docs/version-1.2.0/community/feature-lifecycle.md
@@ -0,0 +1,82 @@
+---
+title: Feature Lifecycle
+sidebar_position: 2
+---
+
+This document is to clarify definitions and differences between features and corresponding APIs
+during different development stages (versions).
+
+Each version has different level of stability, support time,
+and requires different graduation criteria moving to next level:
+
+- [Alpha](#alpha)
+- [Beta](#beta)
+- [GA](#ga)
+
+## Alpha
+
+The feature may be changed/upgraded in incompatible ways in the later versions.
+
+The source code will be available in the release branch/tag as well as in the binaries.
+
+Support for the feature can be stopped any time without notice.
+
+The feature may have bugs.
+
+The feature may also induce bugs in other APIs/Features if enabled.
+
+The feature may not be completely implemented.
+
+The API version names will be like v1alpha1, v1alpha2, etc. The suffixed number will be incremented by 1 in each upgrade.
+
+### Graduation Criteria
+
+- Each feature will start at alpha level.
+- Should not break the functioning of other APIs/Features.
+
+## Beta
+
+The feature may not be changed/upgraded in incompatible ways in later versions,
+but if changed in incompatible ways then upgrade strategy will be provided.
+
+The source code will be available in the release branch/tag as well as in the binaries.
+
+Support for the feature will not be stopped without 2 minor releases notice and will be present in at least next 2 minor releases.
+
+The feature will have few bugs.
+
+The feature will not induce bugs in other APIs/Features if enabled.
+
+The feature will be completely implemented.
+
+The API version names will be like v1beta1, v1beta2, etc. The suffixed number will be incremented by 1 in each upgrade.
+
+### Graduation Criteria
+
+- Should have at least 50% coverage in e2e tests.
+- Project agrees to support this feature for at least next 2 minor releases and notice of at least 2 minor releases will be given before stopping the support.
+- Feature Owner should commit to ensure backward/forward compatibility in the later versions.
+
+## GA
+
+The feature will not be changed/upgraded in incompatible ways in the next couple of versions.
+
+The source code will be available in the release branch/tag as well as in the binaries.
+
+Support for the feature will not be stopped without 4 minor releases notice and will be present in at least next 4 minor releases.
+
+The feature will not have major bugs as it will be tested completely as well as have e2e tests.
+
+The feature will not induce bugs in other APIs/Features if enabled.
+
+The feature will be completely implemented.
+
+The API version names will be like v1, v2, etc.
+
+### Graduation Criteria
+
+- Should have complete e2e tests.
+- Code is thoroughly tested and is reported to be very stable.
+- Project will support this feature for at least next 4 minor releases and notice of at least 4 minor releases will be given before stopping support.
+- Feature Owner should commit to ensure backward/forward compatibility in the later versions.
+- Consensus from Kmesh Maintainers as well as Feature/API Owners who use/interact with the Feature/API.
diff --git a/versioned_docs/version-1.2.0/community/governance.md b/versioned_docs/version-1.2.0/community/governance.md
new file mode 100644
index 00000000..b9cda686
--- /dev/null
+++ b/versioned_docs/version-1.2.0/community/governance.md
@@ -0,0 +1,89 @@
+---
+title: Governance
+sidebar_position: 3
+---
+
+# Kmesh Project Governance
+
+Kmesh is a high-performance and low overhead service mesh data plane based on eBPF and programmable kernel.
+This governance explains how the project is run.
+
+- Kmesh Project Governance
+ - [Values](#values)
+ - [Membership](#membership)
+ - [Meetings](#meetings)
+ - [Code of Conduct](#code-of-conduct)
+ - [Security Response Team](#security-response-team)
+ - [Voting](#voting)
+ - [Modifying this Charter](#modifying-this-charter)
+
+## Values
+
+The Kmesh and its leadership embrace the following values:
+
+- Openness: Communication and decision-making happens in the open and is discoverable for future
+ reference. As much as possible, all discussions and work take place in public
+ forums and open repositories.
+
+- Fairness: All stakeholders have the opportunity to provide feedback and submit
+ contributions, which will be considered on their merits.
+
+- Community over Product or Company: Sustaining and growing our community takes
+ priority over shipping code or sponsors' organizational goals. Each
+ contributor participates in the project as an individual.
+
+- Inclusivity: We innovate through different perspectives and skill sets, which
+ can only be accomplished in a welcoming and respectful environment.
+
+- Participation: Responsibilities within the project are earned through
+ participation, and there is a clear path up the contributor ladder into leadership
+ positions.
+
+## Membership
+
+The [Community Membership](./membership.md)
+outlines responsibilities and requirements for different roles in Kmesh.
+
+Currently, the approvers are the governing body for the project. This may
+change as the community grows, such as by adopting an elected steering committee.
+
+## Meetings
+
+Regular meetings are described at [Community Meeting](https://github.com/kmesh-net/community/blob/main/README.md#community-meeting).
+
+approvers will also have closed meetings in order to discuss security reports
+or Code of Conduct violations. Such meetings should be scheduled by any
+approvers on receipt of a security issue or CoC report. All current approvers
+must be invited to such closed meetings, except for any approvers who is
+accused of a CoC violation.
+
+## Code of Conduct
+
+[Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
+violations by community members will be referred to the CNCF Code of Conduct
+Committee. Should the CNCF CoC Committee need to work with the project on resolution, the
+approvers will appoint a non-involved contributor to work with them.
+
+## Security Response Team
+
+The approvers will appoint a Security Response Team to handle security reports.
+This committee may simply consist of the approvers Council themselves. If this
+responsibility is delegated, the approvers will appoint a team of at least two contributors to handle it. The approvers will review who is assigned to this
+at least once a year.
+
+The Security Response Team is responsible for handling all reports of security
+holes and breaches according to the [security policy](https://github.com/kmesh-net/community/blob/main/security-team/SECURITY.md).
+
+## Voting
+
+While most business in Kmesh is conducted by "[lazy consensus](https://community.apache.org/committers/lazyConsensus.html)", periodically the approvers may need to vote on specific actions or changes.
+A vote can be taken on [the developer mailing list](https://groups.google.com/forum/#!forum/kmesh) or
+[community repo issue](https://github.com/kmesh-net/community/issues/new/choose) for security or conduct matters. Votes may also be taken at [the developer meeting](https://github.com/kmesh-net/community/blob/main/README.md#community-meeting).
+Any approvers may demand a vote be taken.
+
+Most votes require a simple majority of all approvers to succeed, except where
+otherwise noted. Two-thirds majority votes mean at least two-thirds of all existing approvers.
+
+## Modifying this Charter
+
+Changes to this Governance and its supporting documents may be approved by a 2/3 vote of the Approvers.
diff --git a/versioned_docs/version-1.2.0/community/membership.md b/versioned_docs/version-1.2.0/community/membership.md
new file mode 100644
index 00000000..f6185652
--- /dev/null
+++ b/versioned_docs/version-1.2.0/community/membership.md
@@ -0,0 +1,111 @@
+---
+title: Membership
+sidebar_position: 4
+---
+
+:::note
+This document keeps changing based on the status and feedback of the Kmesh Community.
+:::
+
+This document provides an overview of Kmesh community roles, along with their requirements, responsibilities, and privileges.
+
+| Role | Requirements | Responsibilities | Privileges |
+| ------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| [Member](#member) | Sponsor from 2 approvers, active in community, contributed to KMesh | Welcome and guide new contributors | KMesh GitHub organization Member |
+| [Reviewer](#reviewer) | History of review and authorship in a subproject | Review contributions from community members | Read access to specific packages in relevant repository |
+| [Approver](#approver) | Sponsor from 2 maintainers, has good experience and knowledge of domain, actively contributed to code and review | Review and approve contributions from community members | Write access to specific packages in relevant repository |
+| [Maintainer](#maintainer) | Sponsor from 2 owners, shown good technical judgment in feature design/development and PR review | Participate in release planning and feature development/maintenance | Top-level write access to relevant repository, name entry in Maintainers file of the repository |
+
+:::note
+All Kmesh community members must follow the Kmesh [Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
+:::
+
+## Member
+
+Members actively contribute by authoring PRs, reviewing issues/PRs, or participating in community discussions on Slack or the mailing list.
+
+### Requirements
+
+- Sponsor from 2 approvers
+- Enabled [two-factor authentication](https://help.github.com/articles/about-two-factor-authentication) on their GitHub account
+- Actively contributed to the community, including:
+ - Authoring PRs
+ - Reviewing issues/PRs from other members
+ - Participating in community discussions
+ - Attending Kmesh community meetings
+
+### Responsibilities and Privileges
+
+- Member of the Kmesh GitHub organization
+- Can be assigned to issues and PRs
+- Participate in assigned issues and PRs
+- Welcome and guide new contributors
+- Help new members contribute to Kmesh
+
+## Reviewer
+
+Reviewers ensure code quality and correctness for a subproject.
+
+### Requirements
+
+- Member for at least 1 month
+- Primary reviewer for at least 5 PRs
+- Reviewed or merged at least 10 substantial PRs
+- Knowledgeable about the codebase
+- Sponsored by a subproject approver
+- No objections from other approvers
+- Added to OWNERS file via PR
+- Self-nomination or nomination by an approver
+
+### Responsibilities and Privileges
+
+- Responsible for project quality control
+- Review code for quality, correctness, and testing
+- Respond to review requests
+- Assigned PRs and test bugs in their area of expertise
+- May receive a badge on PR and issue comments
+
+## Approver
+
+Approvers are experienced members who actively review PRs and have strong domain knowledge.
+
+### Requirements
+
+- Sponsor from 2 maintainers
+- Member for at least 2 months
+- Reviewed a substantial number of PRs
+- Good codebase knowledge
+
+### Responsibilities and Privileges
+
+- Maintain and improve code quality
+- Acknowledge and review community PRs
+- Approve contributions related to their expertise
+- Write access to specific packages in the repository
+- Guide and mentor other contributors
+
+## Maintainer
+
+Maintainers have demonstrated technical expertise and judgment in feature design and development.
+
+### Requirements
+
+- Sponsor from 2 owners
+- Approver for at least 2 months
+- Nominated by a project owner
+- Strong technical judgment in design/development
+
+### Responsibilities and Privileges
+
+- Participate in release planning
+- Maintain project code quality
+- Ensure API compatibility
+- Analyze and propose new features/enhancements
+- Mentor contributors and approvers
+- Top-level write access to the relevant repository
+- Listed in the Maintainers file
+- Lead design and development of multiple features
+
+:::note
+These roles apply only to the Kmesh GitHub organization and repositories. Currently, Kmesh does not have a formal review process for these roles, but one will be established soon.
+:::
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmesh-daemon-map-upgarde.md b/versioned_docs/version-1.2.0/developer-guide/Kmesh-daemon-map-upgarde.md
new file mode 100644
index 00000000..e839d4c6
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmesh-daemon-map-upgarde.md
@@ -0,0 +1,36 @@
+---
+sidebar_position: 4
+title: Kmesh daemon maps upgrades traffic without disruption
+---
+
+# Project Documentation: Kmesh daemon maps upgrades traffic without disruption
+
+## Current strategy
+
+On upgrade the Kmesh-daemon snapshots the current MapSpec (the `CollectionSpec` embedded by `bpf2go`) to disk. During an upgrade, the daemon reads the previously persisted snapshot as oldMapSpec and performs a strict comparison with the current MapSpec. If the maps are detected as compatible (same type and layout), the daemon reuses the existing pinned map. If they are incompatible, the daemon does not attempt complex live migration; instead it creates a new empty map which is initially pinned to a temporary path and then atomically replaces the original pin by unpinning the old map and renaming the temporary pin to the original path.
+
+## When traffic without disruption is guaranteed
+
+### Safe changes
+
+1. Adding a new map (no changes to existing maps’ properties).
+
+2. Increasing an existing map’s `MaxEntries` (capacity increase) without changing key/value layout or sizes.
+
+### Changes that will break traffic without disruption
+
+1. `Key` type or `Value` type changes, including changes to nested struct definitions.
+
+2. `KeySize` or `ValueSize` changes (e.g. from 4 bytes to 16 bytes).
+
+3. Field offset changes (field reorder, delete, rename) or nested struct layout changes that make the layout incompatible.
+
+4. MapType change (e.g. Hash → Array).
+
+5. Reducing `MaxEntries`.
+
+When any of the above changes are detected, the upgrade logic treats the old map as incompatible and creates a new empty map, which causes runtime state loss.
+
+## Test recommendations
+
+Package your new daemon build into an image and publish it. Set that image address in the environment variable KMESH_UPGRADE_IMAGE. In a fresh clone of the project , run the e2e test while skipping the test’s internal image build step by passing the --skip-build-daemonupgarde-image flag (this flag tells the test to use the externally supplied KMESH_UPGRADE_IMAGE). The TestKmeshUpgrade test will then perform a rolling upgrade of the daemonset and validate whether traffic continuity is preserved.
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/ kmeshctl-authz-disable.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/ kmeshctl-authz-disable.md
new file mode 100644
index 00000000..185ecb1d
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/ kmeshctl-authz-disable.md
@@ -0,0 +1,21 @@
+---
+title: kmeshctl authz disable
+sidebar_position: 2
+---
+
+```bash
+kmeshctl authz disable [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz disable
+kmeshctl authz disable pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for disable
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/_category_.json b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/_category_.json
new file mode 100644
index 00000000..4d4613e3
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Kmeshctl Authz",
+ "position": 7,
+ "link": {
+ "type": "generated-index",
+ "description": "Manage xdp authz eBPF program for Kmesh's authz offloading"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-enable.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-enable.md
new file mode 100644
index 00000000..82c9b121
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-enable.md
@@ -0,0 +1,21 @@
+---
+title: kmeshctl authz enable
+sidebar_position: 1
+---
+
+```bash
+kmeshctl authz enable [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz enable
+kmeshctl authz enable pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for enable
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-status.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-status.md
new file mode 100644
index 00000000..5dc5b17f
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh Authz/kmeshctl-authz-status.md
@@ -0,0 +1,21 @@
+---
+title: kmeshctl authz status
+sidebar_position: 3
+---
+
+```bash
+kmeshctl authz status [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz status
+kmeshctl authz status pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for status
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/_category_.json b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/_category_.json
new file mode 100644
index 00000000..8d75037c
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Kmeshctl Waypoint",
+ "position": 8,
+ "link": {
+ "type": "generated-index",
+ "description": "A group of commands used to manage waypoint configuration"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/configuration.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/configuration.md
new file mode 100644
index 00000000..100e266c
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/configuration.md
@@ -0,0 +1,36 @@
+---
+title: Configuration
+sidebar_position: 1
+---
+
+Manage waypoint configuration
+
+### Synopsis
+
+A group of commands used to manage waypoint configuration
+
+```bash
+kmeshctl waypoint [flags]
+```
+
+### Examples
+
+```bash
+ # Apply a waypoint to the current namespace
+ kmeshctl waypoint apply
+
+ # Generate a waypoint as yaml
+ kmeshctl waypoint generate --namespace default
+
+ # List all waypoints in a specific namespace
+ kmeshctl waypoint list --namespace default
+```
+
+### Options
+
+```bash
+ -h, --help help for waypoint
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-apply.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-apply.md
new file mode 100644
index 00000000..63293378
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-apply.md
@@ -0,0 +1,42 @@
+---
+title: kmeshctl waypoint apply
+sidebar_position: 2
+---
+
+Apply a waypoint configuration to the cluster
+
+```bash
+kmeshctl waypoint apply [flags]
+```
+
+### Examples
+
+```bash
+# Apply a waypoint to the current namespace
+kmeshctl waypoint apply
+
+# Apply a waypoint to a specific namespace and wait for it to be ready
+kmeshctl waypoint apply --namespace default --wait
+
+# Apply a waypoint to a specific pod
+kmeshctl waypoint apply -n default --name reviews-v2-pod-waypoint --for workload
+```
+
+### Options
+
+```bash
+ --enroll-namespace If set, the namespace will be labeled with the waypoint name
+ --for string Specify the traffic type [all none service workload] for the waypoint
+ -h, --help help for apply
+ --overwrite Overwrite the existing Waypoint used by the namespace
+ -r, --revision string The revision to label the waypoint with
+ -w, --wait Wait for the waypoint to be ready
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-delete.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-delete.md
new file mode 100644
index 00000000..24ba6d49
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-delete.md
@@ -0,0 +1,41 @@
+---
+title: kmeshctl waypoint delete
+sidebar_position: 3
+---
+
+Delete a waypoint configuration from the cluster
+
+```bash
+kmeshctl waypoint delete [flags]
+```
+
+### Examples
+
+```bash
+# Delete a waypoint from the default namespace
+kmeshctl waypoint delete
+
+# Delete a waypoint by name, which can obtain from kmeshctl waypoint list
+kmeshctl waypoint delete waypoint-name --namespace default
+
+# Delete several waypoints by name
+kmeshctl waypoint delete waypoint-name1 waypoint-name2 --namespace default
+
+# Delete all waypoints in a specific namespace
+kmeshctl waypoint delete --all --namespace default
+```
+
+### Options
+
+```bash
+ --all Delete all waypoints in the namespace
+ -h, --help help for delete
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-generate.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-generate.md
new file mode 100644
index 00000000..1178f6ed
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-generate.md
@@ -0,0 +1,36 @@
+---
+title: kmeshctl waypoint generate
+sidebar_position: 4
+---
+
+Generate a waypoint configuration as YAML
+
+```bash
+kmeshctl waypoint generate [flags]
+```
+
+### Examples
+
+```bash
+# Generate a waypoint as yaml
+kmeshctl waypoint generate --namespace default
+
+# Generate a waypoint that can process traffic for service in default namespace
+kmeshctl waypoint generate --for service -n default
+```
+
+### Options
+
+```bash
+ --for string Specify the traffic type [all none service workload] for the waypoint
+ -h, --help help for generate
+ -r, --revision string The revision to label the waypoint with
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-list.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-list.md
new file mode 100644
index 00000000..3e887840
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-list.md
@@ -0,0 +1,35 @@
+---
+title: kmeshctl waypoint list
+sidebar_position: 5
+---
+
+List managed waypoint configurations in the cluster
+
+```bash
+kmeshctl waypoint list [flags]
+```
+
+### Examples
+
+```bash
+# List all waypoints in a specific namespace
+kmeshctl waypoint list --namespace default
+
+# List all waypoints in the cluster
+kmeshctl waypoint list -A
+```
+
+### Options
+
+```bash
+ -A, --all-namespaces List all waypoints in all namespaces
+ -h, --help help for list
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-status.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-status.md
new file mode 100644
index 00000000..281abad6
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/Kmesh waypoint/kmeshctl-waypoint-status.md
@@ -0,0 +1,34 @@
+---
+title: kmeshctl waypoint status
+sidebar_position: 6
+---
+
+Show the status of waypoints for the namespace provided or default namespace if none is provided
+
+```bash
+kmeshctl waypoint status [flags]
+```
+
+### Examples
+
+```bash
+# Show the status of the waypoint in the default namespace
+kmeshctl waypoint status
+
+# Show the status of the waypoint in a specific namespace
+kmeshctl waypoint status --namespace default
+```
+
+### Options
+
+```bash
+ -h, --help help for status
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/_category_.json b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/_category_.json
new file mode 100644
index 00000000..af93a8a5
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/_category_.json
@@ -0,0 +1,8 @@
+{
+ "label": "Kmeshctl Usage",
+ "position": 3,
+ "link": {
+ "type": "generated-index",
+ "description": "Kmesh command line tools to operate and debug Kmesh"
+ }
+}
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/installation.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/installation.md
new file mode 100644
index 00000000..bfa31220
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/installation.md
@@ -0,0 +1,60 @@
+---
+title: Kmeshctl Installation
+sidebar_position: 1
+---
+
+## Installation
+
+### 1. From Release Binaries
+
+Pre-built binaries are available on our [releases page](https://github.com/kmesh-net/kmesh/releases).
+
+```bash
+# For AMD64 / x86_64
+[ $(uname -m) = x86_64 ] && curl -Lo ./kmeshctl https://github.com/kmesh-net/kmesh/releases/download/v1.0.0/kmeshctl-linux-amd64
+# For ARM64
+[ $(uname -m) = aarch64 ] && curl -Lo ./kmeshctl https://github.com/kmesh-net/kmesh/releases/download/v1.0.0/kmeshctl-linux-arm64
+chmod +x ./kmeshctl
+sudo mv ./kmeshctl /usr/local/bin/kmeshctl
+```
+
+### 2. From Source
+
+Kmeshctl is still in rapid development. If you want to try the latest features, you can directly build and install it from source.
+
+```bash
+# Clone source code from github
+git clone https://github.com/kmesh-net/kmesh.git
+
+# Build and install kmeshctl
+cd kmesh/
+make kmeshctl
+chmod +x ./kmeshctl
+sudo mv ./kmeshctl /usr/local/bin/kmeshctl
+```
+
+## Commands Reference
+
+### kmeshctl accesslog
+
+Enable or disable Kmesh's accesslog
+
+```bash
+kmeshctl accesslog [flags]
+```
+
+**Examples**
+
+```bash
+# Enable Kmesh's accesslog:
+kmeshctl accesslog enable
+
+# Disable Kmesh's accesslog:
+kmeshctl accesslog disable
+```
+
+**Options**
+
+```bash
+ -h, --help help for accesslog
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-dump.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-dump.md
new file mode 100644
index 00000000..58d3bf89
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-dump.md
@@ -0,0 +1,26 @@
+---
+title: Kmeshctl Dump
+sidebar_position: 3
+---
+
+Dump config of kernel-native or dual-engine mode
+
+```bash
+kmeshctl dump [flags]
+```
+
+### Examples
+
+```bash
+# Kernel Native mode:
+kmeshctl dump kernel-native
+
+# Dual Engine mode:
+kmeshctl dump dual-engine
+```
+
+### Options
+
+```bash
+ -h, --help help for dump
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-log.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-log.md
new file mode 100644
index 00000000..4108bbe4
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-log.md
@@ -0,0 +1,30 @@
+---
+title: Kmeshctl Log
+sidebar_position: 5
+---
+
+Get or set kmesh-daemon's logger level
+
+```bash
+kmeshctl log [flags]
+```
+
+### Examples
+
+```bash
+# Set default logger's level as "debug":
+kmeshctl log --set default:debug
+
+# Get all loggers' name
+kmeshctl log
+
+# Get default logger's level:
+kmeshctl log default
+```
+
+### Options
+
+```bash
+ -h, --help help for log
+ --set string Set the logger level (e.g., default:debug)
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-monitoring.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-monitoring.md
new file mode 100644
index 00000000..0e6e6866
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-monitoring.md
@@ -0,0 +1,50 @@
+---
+title: Kmeshctl Monitoring
+sidebar_position: 4
+---
+
+Control Kmesh's monitoring to be turned on as needed
+
+```bash
+kmeshctl monitoring [flags]
+```
+
+### Examples
+
+```bash
+# Enable/Disable Kmesh's accesslog:
+kmeshctl monitoring --accesslog enable/disable
+
+# Enable/Disable services' metrics and accesslog generated from bpf:
+kmeshctl monitoring --all enable/disable
+
+# Enable/Disable workload granularity metrics:
+kmeshctl monitoring --workloadMetrics enable/disable
+
+# Enable/Disable connection granularity metrics:
+kmeshctl monitoring --connectionMetrics enable/disable
+
+# If you want to change the monitoring functionality of all kmesh daemons in the cluster
+# Enable/Disable Kmesh's accesslog in each node:
+kmeshctl monitoring --accesslog enable/disable
+
+# Enable/Disable workload granularity metrics in each node:
+kmeshctl monitoring --workloadMetrics enable/disable
+
+# Enable/Disable connection granularity metrics in each node:
+kmeshctl monitoring --connectionMetrics enable/disable
+
+#Enable/Disable services', workloads' and 'connections' metrics and accesslog generated from bpf in each node:
+kmeshctl monitoring --all enable/disable
+```
+
+### Options
+
+```bash
+ --accesslog string Control accesslog enable or disable
+ --all string Control accesslog and services' and workloads' metrics enable or disable together
+
+ --connectionMetrics string Control connection granularity metrics enable or disable
+ -h, --help help for monitoring
+ --workloadMetrics string Control workload granularity metrics enable or disable
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-secret.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-secret.md
new file mode 100644
index 00000000..6066bb60
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-secret.md
@@ -0,0 +1,104 @@
+---
+title: kmeshctl secret
+sidebar_position: 6
+---
+
+### Use IPsec in Kmesh cluster
+
+IPsec is a mature and widely used encryption method for inter-node communication. This document explains how to enable IPsec to encrypt communication data between Kmesh-managed nodes.
+
+### kmeshctl secret command Examples
+
+The `kmeshctl secret` command provides management capabilities for IPsec secrets in Kmesh clusters. It supports the following subcommands:
+
+- `create`: Generate and store IPsec key and configuration
+- `get`: Retrieve current IPsec key and configuration (displayed in JSON format)
+- `delete`: Remove IPsec secret from the cluster
+
+#### Basic usage examples
+
+```bash
+# Create IPsec secret with random key
+kmeshctl secret create
+
+# Create IPsec secret with custom key
+kmeshctl secret create --key=$(echo -n "{36-character user-defined key here}" | xxd -p -c 64)
+
+# Get current IPsec configuration
+kmeshctl secret get
+
+# Delete IPsec secret
+kmeshctl secret delete
+```
+
+### How to enable IPsec in Kmesh
+
+#### Step 1: Generate an IPsec pre-shared key for Kmesh before starting Kmesh. Currently, only the rfc4106 (gcm(AES)) algorithm is supported. The key must be 36 bytes (32 bytes for the algorithm key and 4 bytes for the salt), provided as a 72-character hexadecimal string
+
+If you want to use a randomly generated key, you can use the following command:
+
+``` bash
+kmeshctl secret create
+```
+
+If you want to use a custom key, you can use the following command:
+
+``` bash
+kmeshctl secret create --key=$(echo -n "{36-character user-defined key here}" | xxd -p -c 64)
+```
+
+#### Step 2: Add the parameter --enable-ipsec=true to the Kmesh yaml
+
+```plaintext
+kmesh.yaml
+...
+args:
+[
+ "./start_kmesh.sh --mode=dual-engine --enable-bypass=false --enable-ipsec=true",
+]
+...
+```
+
+#### Step 3: Place pods or namespace under the management of Kmesh
+
+Only when both communicating pods are managed by Kmesh, will they enter the encryption process.
+
+``` bash
+kubectl label namespace default istio.io/dataplane-mode=Kmesh
+```
+
+#### Step 4: Test whether the data packet has been encrypted
+
+Use tcpdump on nodes to capture packets and check if IPsec has been used during data communication between nodes (determined by ESP packets)
+
+```plaintext
+tcpdump -i any |grep ESP
+...
+14:19:24.143654 ? Out IP master > node1: ESP(spi=0x00000001,seq=0x3da88), length 80
+14:19:24.143690 ? Out IP master > node1: ESP(spi=0x00000001,seq=0x3da89), length 80
+14:19:24.143707 ? In IP node1 > master: ESP(spi=0x00000001,seq=0x3c037), length 80
+14:19:24.143738 ? In IP node1 > master: ESP(spi=0x00000001,seq=0x3c038), length 172
+...
+```
+
+#### Step 5: Replace pre-shared key
+
+After a period of time, the pre-shared key of the cluster can be changed. After changing the pre-shared key, the ESP SPI number of the IPsec used for communication between nodes will be increased by 1 compared to the previous version. This can be observed again through using tcpdump. The initial IPsec SPI version number is 1.
+
+To replace the existing pre-shared key, run the `kmeshctl secret create` command again.
+
+```plaintext
+root@master:~/kmesh# tcpdump -i any |grep ESP
+...
+14:26:33.782665 ? Out IP master > node1: ESP(spi=0x00000002,seq=0x1aaa1), length 80
+14:26:33.782666 ? Out IP master > node1: ESP(spi=0x00000002,seq=0x1aaa2), length 80
+14:26:33.782667 ? In IP node1 > master: ESP(spi=0x00000002,seq=0x183d2), length 80
+14:26:33.782667 ? In IP node1 > master: ESP(spi=0x00000002,seq=0x183d3), length 80
+...
+```
+
+### Note
+
+1. IPsec encryption uses mark `0xe0` and `0xd0` as markers for IPsec encryption and decryption. Please ensure that no conflicting Mark is used on the host network, otherwise unknown behavior may occur
+
+2. Please ensure that `address MASQ` is not used on packets encrypted with IPsec. After address MASQ, IPsec cannot accurately match encryption and decryption rules, which can result in packet loss
diff --git a/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-version.md b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-version.md
new file mode 100644
index 00000000..faa32e6d
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Kmeshctl-usage/kmeshctl-version.md
@@ -0,0 +1,26 @@
+---
+title: Kmeshctl Version
+sidebar_position: 2
+---
+
+Prints out build version info
+
+```bash
+kmeshctl version [flags]
+```
+
+### Examples
+
+```bash
+# Show version of kmeshctl
+kmeshctl version
+
+# Show version info of a specific Kmesh daemon
+kmeshctl version
+```
+
+### Options
+
+```bash
+ -h, --help help for version
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-quickstart.md b/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-quickstart.md
new file mode 100644
index 00000000..ac0fe896
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-quickstart.md
@@ -0,0 +1,129 @@
+# Quickstart for Kmesh E2E Testing
+
+This document is designed to help developers quickly get started with writing and running end-to-end (E2E) tests for the Kmesh project. It covers the prerequisites, the test environment setup, a simple test function template, and instructions for running tests. By following this guide, you will be able to write and execute E2E tests efficiently, ensuring the stability and correctness of Kmesh features.
+
+## Prerequisites
+
+Before getting started, ensure the following tools are installed in your environment:
+
+- **Go**: For running the test framework.
+- **Docker**: For containerizing applications.
+- **kubectl**: For managing Kubernetes clusters.
+- **Kind**: For creating Kubernetes clusters locally.
+- **Helm**: For managing Kubernetes applications.
+
+## E2E Test Environment
+
+Kmesh E2E testing requires a two-node KinD cluster:
+
+- **Control Node**: Manages the cluster.
+- **Worker Node**: Runs the test services.
+
+At the start of the test, two services will be deployed:
+
+1. **service-with-waypoint-at-service-granularity**: A service with a Waypoint.
+2. **enrolled-to-kmesh**: A service without a Waypoint.
+
+Both services use Echo Pods, which are used to test different scenarios.
+
+## Writing E2E Tests
+
+Here is a simple E2E test function template with step-by-step explanations:
+
+```go
+func TestEchoCall(t *testing.T) {
+ // Create a new test suite for the current test
+ framework.NewTest(t).Run(func(t framework.TestContext) {
+ // Define a subtest for the Echo Call functionality
+ t.NewSubTest("Echo Call Test").Run(func(t framework.TestContext) {
+ // Retrieve the source service (with Waypoint) and destination service (without Waypoint)
+ src := apps.ServiceWithWaypointAtServiceGranularity[0]
+ dst := apps.EnrolledToKmesh
+
+ // Define test cases with a name and a checker to validate the response
+ cases := []struct {
+ name string
+ checker echo.Checker
+ }{
+ {
+ name: "basic call", // Name of the test case
+ checker: echo.And(
+ echo.ExpectOK(), // Expect the HTTP call to succeed
+ echo.ExpectBodyContains("Hello"), // Expect the response body to contain "Hello"
+ ),
+ },
+ }
+
+ // Iterate over each test case and execute it
+ for _, c := range cases {
+ t.NewSubTest(c.name).Run(func(t framework.TestContext) {
+ // Perform the HTTP call from the source to the destination
+ src.CallOrFail(t, echo.CallOptions{
+ Target: dst[0], // Target service
+ PortName: "http", // Port name to use for the call
+ Checker: c.checker, // Checker to validate the response
+ })
+ })
+ }
+ })
+ })
+}
+```
+
+### Explanation of Steps
+
+1. **`framework.NewTest(t).Run`**: Initializes a new test suite for the current test.
+2. **`t.NewSubTest("Echo Call Test").Run`**: Creates a subtest for the Echo Call functionality.
+3. **Retrieve Services**: The `src` variable represents the source service (with Waypoint), and the `dst` variable represents the destination service (without Waypoint).
+4. **Define Test Cases**: Each test case includes a name and a `checker` to validate the HTTP response. For example, `echo.ExpectOK()` ensures the HTTP call succeeds, and `echo.ExpectBodyContains("Hello")` checks the response body.
+5. **Iterate and Execute**: For each test case, the `src.CallOrFail` method performs the HTTP call from the source to the destination and validates the response using the specified `checker`.
+6. **`echo.CallOptions`**: Specifies the target service, port name, and checker for the HTTP call.
+
+### Resource Cleanup
+
+Use the `t.Cleanup` method to ensure test resources are cleaned up after the test completes. For example:
+
+```go
+t.Cleanup(func() {
+ // Clean up resources
+})
+```
+
+### Deploying Policies
+
+Use the `t.ConfigIstio` method to deploy policies required for the test. For example:
+
+```go
+t.ConfigIstio().YAML("test-namespace", `
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: allow-all
+spec:
+ rules:
+ - {}
+`).ApplyOrFail(t)
+```
+
+### Using echo.Checker
+
+`echo.Checker` is used to verify whether a test case passes. For example:
+
+```go
+// Example: Using echo.Checker to validate HTTP response
+src.CallOrFail(t, echo.CallOptions{
+ Target: dst[0],
+ PortName: "http",
+ Checker: echo.And(
+ echo.ExpectOK(), // Expect the HTTP call to succeed
+ echo.ExpectBodyContains("Hello"), // Expect the response body to contain "Hello"
+ echo.ExpectHeaders(map[string]string{
+ "Content-Type": "text/plain", // Expect the Content-Type header to be "text/plain"
+ }),
+ ),
+})
+```
+
+## Running Tests
+
+For detailed instructions on running tests, refer to the [E2E Test Guide](https://kmesh.net/docs/developer-guide/Tests/e2e-test).
diff --git a/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-test.md b/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-test.md
new file mode 100644
index 00000000..c53ee5db
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Tests/e2e-test.md
@@ -0,0 +1,108 @@
+---
+title: Run E2E test
+sidebar_position: 2
+---
+
+End-to-End (E2E) testing is a crucial component in modern software development, designed to simulate user interactions across the entire application to ensure all components and integrations function together seamlessly. By incorporating E2E testing, we can verify that changes in code do not disrupt existing functionalities, maintaining the integrity and reliability of the system even as it evolves.
+
+## Prerequisites
+
+Components that need to be installed by the user:
+
+- Go
+- Docker
+- Kubectl
+
+The following components will be installed while using the shell:
+
+- Kind
+- Helm
+- Istioctl
+
+## Usage
+
+To run the E2E tests, execute the `run_test.sh` script located in the `./test/e2e` directory. This script automates the following tasks:
+
+1. **Installing dependencies:** Tools like Kind, Helm and Istioctl ...
+2. **Deploying a local image registry:** A Docker container functions as the local image registry.
+3. **Building and pushing the Kmesh image:** The custom Kmesh Docker image is built and pushed to the local registry.
+4. **Deploying Kubernetes cluster, Istio, and Kmesh:** These components are necessary for the tests and are set up in this step.
+5. **Deploying test applications and executing the E2E tests.**
+
+## Command Line Flags
+
+When testing locally, you may want to skip some setup steps to save time, especially after the initial setup is complete. The following flags are available to customize the test execution:
+
+- **--skip-install-dep** : Skips the installation of dependencies.
+- **--skip-build** : Skips building and pushing the Kmesh image to the local image registry.
+- **--skip-setup** : Skips deploying the Kubernetes cluster, Istio, and Kmesh.
+- **--only-run-tests** : Skips all other steps and focuses only on deploying test applications and running E2E tests.
+- **--cluster** : Allows specifying a pre-existing KinD cluster by name.
+- **--ipv6** : Enables creating a KinD cluster with IPv6 networking and run E2E tests on it.
+- **--cleanup** : Cleans up the KinD cluster and local registry after tests are completed.
+- **--skip-cleanup-apps** : Skips the cleanup of test applications after the tests have been executed.
+- Directly use **go test** command-line arguments when running the tests
+
+### Example Commands
+
+#### Full Test Run (First time)
+
+```bash
+./test/e2e/run_test.sh
+```
+
+Use this command for the initial setup and test run to ensure everything is configured correctly.
+
+#### Subsequent Test Runs (Skipping all setup and only run tests)
+
+```bash
+./test/e2e/run_test.sh --only-run-tests
+```
+
+You might need different kinds of tests.
+
+#### Specifying a Pre-existing KinD Cluster
+
+```bash
+./test/e2e/run_test.sh --cluster
+```
+
+#### Create a IPv6 KinD cluster and Run Tests
+
+```bash
+./test/e2e/run_test.sh --ipv6
+```
+
+In some cases, you might want to clean up some resources after the tests, while in other cases, you might want to skip cleaning up test applications for further usage.
+
+#### Cleanup the KinD Cluster and Docker Registry After Tests
+
+```bash
+./test/e2e/run_test.sh --cleanup
+```
+
+#### Skip the Cleanup of Test Applications After Tests
+
+```bash
+./test/e2e/run_test.sh --skip-cleanup-apps
+```
+
+You can also directly use go test command-line arguments when running the tests. For example, you can filter specific tests, or control other aspects of the testing process directly from the command line.
+
+#### Selecting Specific Test Cases
+
+```bash
+./test/e2e/run_test.sh --only-run-tests -run "TestServices"
+```
+
+#### Controlling Test Verbosity
+
+```bash
+./test/e2e/run_test.sh -v
+```
+
+#### Repeat Test Cases Multiple Times
+
+```bash
+./test/e2e/run_test.sh -count=3
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Tests/ipsec-auth-e2e-test.md b/versioned_docs/version-1.2.0/developer-guide/Tests/ipsec-auth-e2e-test.md
new file mode 100644
index 00000000..b67c156f
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Tests/ipsec-auth-e2e-test.md
@@ -0,0 +1,319 @@
+# IPSec & Offload Authorization E2E Test Guide
+
+This document provides a step-by-step guide for executing the IPSec and Offload Authorization E2E tests for Kmesh. These tests ensure the reliability, security, and functionality of the IPSec feature and the Offload Authorization mechanisms.
+
+## Prerequisites
+
+Before running the tests, ensure the following:
+
+- **Kubernetes Cluster**: A two-node Kubernetes cluster with Kmesh installed.
+- **Tools**: `kubectl`, `tcpdump`, and `kmeshctl`.
+- **Applications**: `echo` and `sleep` applications deployed in the cluster.
+
+## Example YAML for Deployment
+
+**Sleep Application (save as `sleep.yaml`):**
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: sleep
+ labels:
+ app: sleep
+spec:
+ ports:
+ - port: 80
+ name: http
+ selector:
+ app: sleep
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: sleep
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: sleep
+ template:
+ metadata:
+ labels:
+ app: sleep
+ spec:
+ nodeName: kmesh-testing-control-plane
+ containers:
+ - name: sleep
+ image: curlimages/curl
+ command: ["/bin/sleep", "infinity"]
+```
+
+**Echo Application (save as `echo.yaml`):**
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: echo
+spec:
+ ports:
+ - name: http
+ port: 80
+ targetPort: 8080
+ selector:
+ app: echo
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: echo
+spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: echo
+ template:
+ metadata:
+ labels:
+ app: echo
+ spec:
+ containers:
+ - name: echo
+ image: gcr.io/istio-testing/app:latest
+ args:
+ - --port=8080
+ ports:
+ - containerPort: 8080
+```
+
+## IPSec E2E Tests
+
+### 1. Basic Connectivity Test
+
+This test verifies the establishment of IPSec tunnels and the correctness of encrypted communication.
+
+#### Steps
+
+1. Deploy the `sleep` and `echo` applications:
+
+ ```bash
+ kubectl apply -f sleep.yaml
+ kubectl apply -f echo.yaml
+ ```
+
+2. Verify connectivity between the applications:
+
+ ```bash
+ kubectl exec -- curl http://
+ ```
+
+ **Expected Output:**
+
+ ```plaintext
+ Hello version: v1, instance: echo-
+ ```
+
+3. Check IPSec state:
+
+ ```bash
+ ip xfrm state show
+ ```
+
+ **Expected Output:**
+
+ ```plaintext
+ src {{SRC_IP}} dst {{DST_IP}}
+ proto esp spi 0x{{SPI}} reqid 1 mode tunnel
+ replay-window 0
+ output-mark 0xd0/0xffffffff
+ aead rfc4106(gcm(aes)) {{KEY}} 128
+ anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
+ sel src ::/0 dst ::/0
+ ```
+
+4. Check IPSec policy:
+
+ ```bash
+ ip xfrm policy show
+ ```
+
+ **Expected Output:**
+
+ ```plaintext
+ src ::/0 dst {{DST_SUBNET}}
+ dir out priority 0
+ mark 0xe0/0xffffffff
+ tmpl src {{SRC_IP}} dst {{DST_IP}}
+ proto esp spi 0x{{SPI}} reqid 1 mode tunnel
+ ```
+
+5. Verify encryption using `tcpdump`:
+
+ ```bash
+ tcpdump -i any esp
+ ```
+
+ **Expected Output:** ESP packets should be visible during communication.
+
+### 2. Key Rotation Test
+
+This test ensures the reliability of the PSK update mechanism and validates service continuity during key changes.
+
+#### Steps
+
+1. Record the initial SPI:
+
+ ```bash
+ ip xfrm state show
+ ```
+
+ **Expected Output:**
+
+ ```plaintext
+ src {{SRC_IP}} dst {{DST_IP}}
+ proto esp spi 0x{{INITIAL_SPI}} reqid 1 mode tunnel
+ aead rfc4106(gcm(aes)) {{INITIAL_KEY}} 128
+ ```
+
+2. Send continuous traffic between the applications:
+
+ ```bash
+ kubectl exec -- curl http://
+ ```
+
+3. Update the pre-shared key:
+
+ ```bash
+ kmeshctl secret create --key=
+ ```
+
+4. Verify that the SPI and key are updated in the xfrm rules:
+
+ ```bash
+ ip xfrm state show
+ ```
+
+ **Expected Output:**
+
+ ```plaintext
+ src {{SRC_IP}} dst {{DST_IP}}
+ proto esp spi 0x{{INITIAL_SPI + 1}} reqid 1 mode tunnel
+ aead rfc4106(gcm(aes)) {{NEW_KEY}} 128
+ ```
+
+5. Ensure communication continuity and encryption status.
+
+## Offload Authorization E2E Tests
+
+### Unified Steps for Authorization Tests
+
+1. Apply the policy:
+
+ ```bash
+ kubectl apply -f .yaml
+ ```
+
+2. Test connectivity:
+
+ ```bash
+ kubectl exec -- curl http://
+ ```
+
+ **Expected Output:**
+
+ - **ALLOW Policy:** The curl command should succeed, and the HTTP response code should be `200`.
+ - **DENY Policy:** The curl command should fail, and no response should be received.
+
+### Example Policies
+
+#### IP Authorization Policy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: ip-allow-policy
+ namespace: test-ns1
+spec:
+ action: ALLOW
+ rules:
+ - from:
+ - source:
+ ipBlocks:
+ - "{{ALLOWED_IP}}"
+```
+
+#### Port Authorization Policy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: port-allow-policy
+ namespace: test-ns1
+spec:
+ action: ALLOW
+ rules:
+ - to:
+ - operation:
+ ports: ["{{ALLOWED_PORT}}"]
+```
+
+#### Header Authorization Policy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: header-allow-policy
+ namespace: test-ns1
+spec:
+ action: ALLOW
+ rules:
+ - when:
+ - key: request.headers["{{HEADER_NAME}}"]
+ values: ["{{HEADER_VALUE}}"]
+```
+
+#### Namespace Authorization Policy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: namespace-allow-policy
+ namespace: test-ns1
+spec:
+ action: ALLOW
+ rules:
+ - from:
+ - source:
+ namespaces: ["{{SOURCE_NAMESPACE}}"]
+```
+
+#### Host Authorization Policy
+
+```yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: host-allow-policy
+ namespace: test-ns1
+spec:
+ action: ALLOW
+ rules:
+ - to:
+ - operation:
+ hosts: ["{{TARGET_HOST}}"]
+```
+
+## Cleanup
+
+After completing the tests, clean up the resources:
+
+```bash
+kubectl delete -f sleep.yaml
+kubectl delete -f echo.yaml
+kubectl delete authorizationpolicy --all -n test-ns1
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/Tests/unit-test.md b/versioned_docs/version-1.2.0/developer-guide/Tests/unit-test.md
new file mode 100644
index 00000000..d4ce3ecb
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/Tests/unit-test.md
@@ -0,0 +1,119 @@
+---
+title: Run Unit test
+sidebar_position: 1
+---
+
+# Run Unit Test
+
+Compiling Kmesh directly in the operating system requires a certain [OS version](https://github.com/kmesh-net/kmesh/blob/main/docs/kmesh_support.md). Therefore, in order to allow all operating systems to run Kmesh's UT, Kmesh provides two ways to do so. One to run the go unit test in docker and one to run the go unit test locally.
+
+Developers of unsupported kernel version can run go unit test in docker through script. Developers of supported version can run go unit test locally through script.
+
+```sh
+cd $(Kmesh root directory)
+
+# Run kmesh ut through docker
+./hack/run-ut.sh --docker
+
+# Run kmesh ut locally
+./hack/run-ut.sh --local
+```
+
+Alternatively, you can execute the test by `make test`:
+
+```sh
+# Run kmesh ut through docker
+make test RUN_IN_CONTAINER=1
+
+# Run kmesh ut locally
+make test RUN_IN_CONTAINER=0
+```
+
+## Unit test
+
+This section describes the ut settings for Kmesh so that developers can run unit tests without using scripts.
+
+Because Kmesh uses eBPF, you need to set some environment variables when running Kmesh-related Unit Tests.
+
+```sh
+export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib:$ROOT_DIR/api/v2-c:$ROOT_DIR/bpf/deserialization_to_bpf_map
+export PKG_CONFIG_PATH=$ROOT_DIR/mk
+```
+
+Set `LD_LIBRARY_PATH` so that the system can find the .so files.
+
+Set `PKG_CONFIG_PATH` so that the system can find the .pc files that Kmesh compiled.
+
+In addition to this, you may also encounter a c header file not found error. Such errors can be resolved by setting `C_INCLUDE_PATH`. The header files needed for Kmesh are saved in the [bpf](https://github.com/kmesh-net/kmesh/tree/main/bpf) folder.
+
+Note the **multiple header file** problem.
+
+### Common Issues and Solutions for Running Unit Tests
+
+When running unit tests in the `/test/bpf_ut/bpftest` directory, you might encounter the following issues and their solutions. To avoid repeated settings, it is recommended to use a unified `sudo env` command to execute the tests.
+
+1. **`go` command not found**
+
+ In a `sudo` environment, the `go` command might not be found in the `PATH`.
+ * **Solution**: Explicitly pass the `PATH` environment variable in the `sudo` command, e.g., `PATH=$PATH:/usr/local/go/bin`.
+
+2. **Go module download issue (network timeout)**
+
+ For example, encountering `Get "https://proxy.golang.org/..." i/o timeout`. This is usually caused by network proxy or connection problems preventing Go modules from being downloaded.
+ * **Solution**: Set `GOPROXY` to use a domestic proxy and disable `GOSUMDB` verification, e.g., `GOPROXY=https://goproxy.cn,direct GOSUMDB=off`.
+
+3. **`No package 'api-v2-c' found`**
+
+ This indicates that `pkg-config` cannot find the `api-v2-c.pc` file.
+ * **Solution**: Find the actual path of the `api-v2-c.pc` file and add its directory to the `PKG_CONFIG_PATH` environment variable. In the Kmesh project, this file is usually located in the `mk/` directory.
+
+ ```sh
+ # Find the .pc file
+ find {your-project-path} -name "api-v2-c.pc"
+ # Example output: {your-project-path}/mk/api-v2-c.pc
+ # Set PKG_CONFIG_PATH
+ export PKG_CONFIG_PATH={your-project-path}/mk:$PKG_CONFIG_PATH
+ # Verify (optional)
+ pkg-config --cflags api-v2-c
+ ```
+
+4. **`libkmesh_api_v2_c.so: cannot open shared object file: No such file or directory` (Dynamic library not found)**
+
+ This usually happens at runtime when the system cannot find the `.so` dynamic library file compiled by Kmesh.
+ * **Solution**: Determine the directory where the `.so` file is located (e.g., `/usr/lib64`) and add it to the `LD_LIBRARY_PATH` environment variable, e.g., `LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH`.
+
+**Unified Unit Test Execution Command Example**:
+
+To resolve the above common issues, you can use the following command with all necessary environment variables to run unit tests:
+
+```sh
+sudo env \
+ PKG_CONFIG_PATH={your-project-path}/mk:$PKG_CONFIG_PATH \
+ GOPROXY=https://goproxy.cn,direct \
+ GOSUMDB=off \
+ PATH=$PATH:/usr/local/go/bin \
+ LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH \
+ make run
+```
+
+If you want to see more detailed test output, you can add the `-test.v` parameter:
+
+```sh
+sudo env \
+ PKG_CONFIG_PATH={your-project-path}/mk:$PKG_CONFIG_PATH \
+ GOPROXY=https://goproxy.cn,direct \
+ GOSUMDB=off \
+ PATH=$PATH:/usr/local/go/bin \
+ LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH \
+ go test ./bpftest -bpf-ut-path {your-project-path}/test/bpf_ut -test.v
+```
+
+Please adjust based on the actual root directory path of your Kmesh project (e.g., `{your-project-path}`) and the path to the `.so` dynamic library file (e.g., `/usr/lib64`).
+
+Besides the above issues, since Kmesh ut uses gomonkey, there may be a situation where monkey's functions are small and inlined during Go compilation optimization.
+
+We can solve this problem by adding the following parameter to the go test execution:
+
+```bash
+-gcflags="all=-N -l"
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/_category_.json b/versioned_docs/version-1.2.0/developer-guide/_category_.json
new file mode 100644
index 00000000..f1426c17
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Developer Guide",
+ "position": 7,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/developer-guide/build-guide.md b/versioned_docs/version-1.2.0/developer-guide/build-guide.md
new file mode 100644
index 00000000..7b8c8035
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/build-guide.md
@@ -0,0 +1,133 @@
+---
+sidebar_position: 1
+title: "How to build"
+---
+
+The Kmesh needs to be compiled and built in the Linux environment with the Kmesh kernel enhancement feature. Currently, Kmesh can be compiled and run in multiple OS versions, and the specific OS versions can see [Kmesh support system](https://github.com/kmesh-net/kmesh/blob/main/docs/kmesh_support.md).
+
+## Build
+
+### Prerequisite
+
+- Install docker-engine
+
+ ```sh
+ sudo apt-get update
+ (optional)sudo apt-get remove docker docker-engine docker.io
+ sudo apt install docker.io
+ ```
+
+ You can check the docker version to make sure that docker is installed.
+
+ ```sh
+ docker version
+ Client: Docker Engine - Community
+ Version: 26.0.1
+ API version: 1.45
+ Go version: go1.21.9
+ Git commit: d260a54
+ Built: Thu Apr 11 10:53:21 2024
+ OS/Arch: linux/amd64
+ Context: default
+
+ Server: Docker Engine - Community
+ Engine:
+ Version: 26.0.1
+ API version: 1.45 (minimum version 1.24)
+ Go version: go1.21.9
+ Git commit: 60b9add
+ Built: Thu Apr 11 10:53:21 2024
+ OS/Arch: linux/amd64
+ Experimental: false
+ containerd:
+ Version: 1.6.31
+ GitCommit: e377cd56a71523140ca6ae87e30244719194a521
+ runc:
+ Version: 1.1.12
+ GitCommit: v1.1.12-0-g51d5e94
+ docker-init:
+ Version: 0.19.0
+ GitCommit: de40ad0
+ ```
+
+- Download Kmesh-build image
+
+ To compile the Kmesh image, you need to prepare the Kmesh source code and the Kmesh-build image. The image can be obtained using the following command:
+
+ ```sh
+ docker pull ghcr.io/kmesh-net/kmesh-build-x86:latest
+ ```
+
+ Note: The `Kmesh-build` image needs to match the version of the source code.
+
+### Build Kmesh from Source
+
+Clong the source code from github.
+
+```sh
+git clone https://github.com/kmesh-net/kmesh.git
+```
+
+Code compilation
+
+- Compile Kmesh through build-image
+
+ ```sh
+ cd kmesh/
+ make build
+ ```
+
+- Compile Kmesh through script
+
+ Kmesh also provides a way to compile through scripts
+
+ ```sh
+ [root@dev] ./kmesh_compile.sh
+ ```
+
+ Note that if you use script to compile, you need to make sure that your os system version is one that [Kmesh supports system](https://github.com/kmesh-net/kmesh/blob/main/docs/kmesh_support.md)!
+
+When Kmesh compilation is finish, the build artifacts will be output to the `out` directory.
+
+```bash
+ls out/amd64/
+kmesh-daemon libbpf.so libbpf.so.0.8.1 libkmesh_deserial.so libprotobuf-c.so.1 mdacore
+kmesh-cni libboundscheck.so libbpf.so.0 libkmesh_api_v2_c.so libprotobuf-c.so libprotobuf-c.so.1.0.0
+```
+
+### Build Docker Image
+
+Execute `make docker` in the Kmesh source code directory.
+
+Users can specify parameters for building, as shown in the example below:
+
+```sh
+User-defined HUB, TARGET, TAG values. If not specified, default values will be used.
+HUB=ghcr.io/kmesh-net
+TARGET=kmesh
+TAG= #git sha
+
+[root@dev docker] make docker
+...
+Successfully tagged ghcr.io/kmesh-net/kmesh:b68790eb07830e757f4ce6d1c478d0046ee79730
+
+[root@dev docker] make docker HUB=ghcr.io/kmesh-net TARGET=kmesh TAG=latest
+...
+Successfully tagged ghcr.io/kmesh-net/kmesh:latest
+```
+
+Check the existing Kmesh image in the local image repository：
+
+```sh
+[root@dev docker]# docker images ls
+REPOSITORY TAG IMAGE ID CREATED SIZE
+ghcr.io/kmesh-net/kmesh latest 71aec5898c44 About an hour ago 506MB
+```
+
+### Compilation Cleanup
+
+You can use the following command to clean up the binaries.
+
+```sh
+[root@dev] make clean
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/traffic-spilt.md b/versioned_docs/version-1.2.0/developer-guide/traffic-spilt.md
new file mode 100644
index 00000000..bb2941df
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/traffic-spilt.md
@@ -0,0 +1,104 @@
+---
+sidebar_position: 2
+title: Traffic Split
+---
+
+### Before you begin
+
+#### Install Kmesh in Kernel-Native Mode
+
+1. Navigate to the [quickstart](/docs/setup/quick-start.md) documentation
+2. In the section titled `Change Kmesh Start Mode`
+3. Open the configuration file: `deploy/charts/kmesh-helm/values.yaml`
+4. Replace `--mode=dual-engine` with `--mode=kernel-native`
+
+This configuration change is required for the traffic split functionality to work properly.
+
+#### Deploy the Sample Applications
+
+```shell
+[root@master kmesh]# kubectl apply -f samples/sleep/sleep.yaml -n tcp-echo-test
+[root@master kmesh]# kubectl apply -f samples/tcp-echo/tcp-echo-services.yaml -n tcp-echo-test
+[root@master kmesh]# kubectl apply -f samples/tcp-echo/tcp-echo-virtualservice.yaml -n tcp-echo-test
+```
+
+### Apply weight-based Load Balance
+
+1. Let Kmesh manage the traffic of pods
+
+ ```shell
+ [root@master test]# kubectl label ns default istio.io/dataplane-moda=Kmesh
+ ```
+
+2. Confirm that the `tcp-echo` service is up and running by sending some TCP traffic.
+
+ ```shell
+ ##get tcp-echo service address
+ [root@master test]# kubectl get svc | grep tcp-
+ tcp-echo ClusterIP 10.96.128.249 9000/TCP,9001/TCP 43h
+ [root@master test]# for i in {1..20}; do kubectl exec sleep-78ff5975c6-cm8hd -c sleep -- sh -c "(date; sleep 1) | nc 10.96.128.249:9000;" done
+ two Sat Jul 6 08:46:45 UTC 2024
+ two Sat Jul 6 08:46:46 UTC 2024
+ one Sat Jul 6 08:46:47 UTC 2024
+ one Sat Jul 6 08:46:48 UTC 2024
+ two Sat Jul 6 08:46:49 UTC 2024
+ two Sat Jul 6 08:46:51 UTC 2024
+ two Sat Jul 6 08:46:52 UTC 2024
+ one Sat Jul 6 08:46:53 UTC 2024
+ two Sat Jul 6 08:46:54 UTC 2024
+ two Sat Jul 6 08:46:55 UTC 2024
+ one Sat Jul 6 08:46:56 UTC 2024
+ one Sat Jul 6 08:46:57 UTC 2024
+ two Sat Jul 6 08:46:58 UTC 2024
+ one Sat Jul 6 08:47:00 UTC 2024
+ two Sat Jul 6 08:47:01 UTC 2024
+ one Sat Jul 6 08:47:02 UTC 2024
+ two Sat Jul 6 08:47:03 UTC 2024
+ one Sat Jul 6 08:47:04 UTC 2024
+ one Sat Jul 6 08:47:05 UTC 2024
+ two Sat Jul 6 08:47:06 UTC 2024
+ ```
+
+### Dump the configuration information
+
+```shell
+[root@master kmesh]# ./kmeshctl dump kmesh-5f4fm kernel-native
+```
+
+After dump the configuration, we can see that the strategy is load balancing.
+
+```json
+{
+ "name": "outbound|9001||tcp-echo.default.svc.cluster.local",
+ "connectTimeout": 10,
+ "lbPolicy": "LEAST_REQUEST",
+ "loadAssignment": {
+ "clusterName": "outbound|9001||tcp-echo.default.svc.cluster.local",
+ "endpoints": [
+ {
+ "lbEndpoints": [
+ {
+ "address": {
+ "port": 10531,
+ "ipv4": 469890058
+ }
+ },
+ {
+ "address": {
+ "port": 10531,
+ "ipv4": 453112842
+ }
+ }
+ ],
+ "loadBalancingWeight": 2
+ }
+ ]
+ },
+ "circuitBreakers": {
+ "maxConnections": 4294967295,
+ "maxPendingRequests": 4294967295,
+ "maxRequests": 4294967295,
+ "maxRetries": 4294967295
+ }
+}
+```
diff --git a/versioned_docs/version-1.2.0/developer-guide/website/create-blog.md b/versioned_docs/version-1.2.0/developer-guide/website/create-blog.md
new file mode 100644
index 00000000..e6d9d7e8
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/website/create-blog.md
@@ -0,0 +1,240 @@
+---
+title: Create a Blog
+sidebar_position: 3
+---
+
+## Creating a Blog in Docusaurus: A Comprehensive Guide
+
+Docusaurus is a powerful static site generator that includes a built-in blog feature, making it easy to create and share blog posts. This guide will explain how to set up a blog, write posts, configure options, and maintain your content—all in a way that's approachable for beginners.
+
+### 1. What Is the Blog Feature in Docusaurus?
+
+The blog feature in Docusaurus allows you to:
+
+- Write blog posts as Markdown files.
+- Automatically generate a blog index page listing all your posts.
+- Create individual pages for each blog post.
+- Customize how your blog looks and behaves.
+
+It’s perfect for sharing project updates, tutorials, or any time-based content, with minimal setup required.
+
+### 2. Blog Folder Structure
+
+In a Docusaurus project, blog posts are stored in the `blog/` directory. Each post is a separate Markdown file, and the file name typically includes the publication date and a slug (a URL-friendly title). Here’s an example structure:
+
+```text
+blog/
+├── 2023-10-05-my-first-post.md
+└── 2023-10-06-another-post.md
+```
+
+- **Date**: The `YYYY-MM-DD` part (e.g., `2023-10-05`) sets the post’s publication date and order.
+- **Slug**: The part after the date (e.g., `my-first-post`) becomes part of the URL (e.g., `/blog/my-first-post`).
+
+You can keep all posts in the `blog/` directory or use subfolders for organization (though a flat structure works fine for most cases).
+
+### 3. Writing Blog Posts: Front Matter
+
+Every blog post starts with a **front matter** section—a YAML block at the top of the file, enclosed in triple dashes (`---`). This section contains metadata about the post. Here’s an example:
+
+```yaml
+---
+title: My First Blog Post
+date: 2023-10-05
+author: John Doe
+tags: ["example", "blog"]
+---
+```
+
+Key fields include:
+
+- **`title`**: The post’s title, shown on the post page and blog index.
+- **`date`**: The publication date (must match the file name’s date).
+- **`author`**: The author’s name (optional).
+- **`tags`**: A list of tags for categorization (optional).
+
+The front matter is essential for Docusaurus to recognize and display your post correctly.
+
+### 4. Writing Blog Post Content
+
+After the front matter, write your post’s content using Markdown. Docusaurus supports standard Markdown syntax—headings, lists, links, images, and more. Here’s an example:
+
+```markdown
+# My First Blog Post
+
+Welcome to my blog!
+
+## Why I Started This Blog
+
+I’m excited to share my experiences. Here’s why:
+
+- To document my progress
+- To connect with others
+- To learn from feedback
+
+## What’s Next?
+
+Look out for posts on:
+
+1. Project setup tips
+2. Coding best practices
+3. Fun experiments
+```
+
+Docusaurus also supports MDX, which lets you add React components to your posts for interactive elements (though this is optional for beginners).
+
+### 5. Configuring Your Blog
+
+You can customize your blog by editing the `docusaurus.config.js` file in your project’s root directory. The blog settings are typically defined in the `presets` section. Here’s an example:
+
+```javascript
+module.exports = {
+ // ...
+ presets: [
+ [
+ "@docusaurus/preset-classic",
+ {
+ blog: {
+ path: "blog", // Directory for blog posts
+ routeBasePath: "blog", // URL path for the blog
+ blogTitle: "My Blog", // Blog page title
+ blogDescription: "Thoughts and updates on my project", // Blog description
+ postsPerPage: 10, // Posts per index page
+ showReadingTime: true, // Show reading time for posts
+ },
+ },
+ ],
+ ],
+};
+```
+
+Key options:
+
+- **`path`**: Where your blog posts are stored (default: `blog`).
+- **`routeBasePath`**: The URL path for your blog (e.g., `/blog`).
+- **`blogTitle`**: The title shown on the blog index.
+- **`blogDescription`**: A short description for SEO and feeds.
+- **`postsPerPage`**: How many posts appear on each index page.
+- **`showReadingTime`**: Displays estimated reading time per post.
+
+Check the [Docusaurus blog documentation](https://docusaurus.io/docs/blog) for more options.
+
+### 6. Adding the Blog to Your Site Navigation
+
+To help users find your blog, add a link to it in the navigation bar or footer via `docusaurus.config.js`.
+
+#### Navigation Bar Example
+
+```javascript
+module.exports = {
+ // ...
+ themeConfig: {
+ navbar: {
+ items: [
+ {
+ to: "/blog",
+ label: "Blog",
+ position: "left",
+ },
+ ],
+ },
+ },
+};
+```
+
+#### Footer Example
+
+```javascript
+module.exports = {
+ // ...
+ themeConfig: {
+ footer: {
+ links: [
+ {
+ title: "Links",
+ items: [
+ {
+ label: "Blog",
+ to: "/blog",
+ },
+ ],
+ },
+ ],
+ },
+ },
+};
+```
+
+This makes your blog accessible from anywhere on your site.
+
+### 7. Previewing Your Blog Locally
+
+To see your blog in action, run the development server:
+
+```bash
+npm start
+```
+
+or
+
+```bash
+yarn start
+```
+
+Open `http://localhost:3000/blog` in your browser to view the blog index. Click any post to see its individual page.
+
+### 8. Best Practices for Managing Your Blog
+
+As your blog grows, keep it organized with these tips:
+
+- **File Naming**: Stick to a consistent format like `YYYY-MM-DD-title.md` for chronological ordering.
+- **Tags**: Use tags in the front matter to group related posts. Docusaurus creates tag pages (e.g., `/blog/tags/example`) automatically.
+- **Content Structure**: Keep posts focused and use headings for readability.
+- **Updates**: Regularly check front matter (e.g., dates, tags) to ensure accuracy.
+
+### 9. Example Blog Post
+
+Here’s a full example of a blog post file:
+
+```markdown
+---
+title: My First Blog Post
+date: 2023-10-05
+author: John Doe
+tags: ["example", "blog"]
+---
+
+# My First Blog Post
+
+Hi everyone!
+
+## Why I’m Here
+
+I started this blog to:
+
+- Share my project journey
+- Help others learn
+- Get community input
+
+## Coming Soon
+
+Next, I’ll write about:
+
+1. Setting up tools
+2. Writing clean code
+3. Cool ideas to try
+
+Thanks for reading!
+```
+
+This file includes front matter and Markdown content, ready to be processed by Docusaurus.
+
+### 10. Next Steps and Resources
+
+You now have a working blog in Docusaurus! To take it further, explore:
+
+- Adding an RSS feed for subscribers.
+- Customizing the blog’s design with CSS.
+- Using MDX for advanced features.
+
+For more details, visit the [official Docusaurus blog documentation](https://docusaurus.io/docs/blog).
diff --git a/versioned_docs/version-1.2.0/developer-guide/website/create-doc.md b/versioned_docs/version-1.2.0/developer-guide/website/create-doc.md
new file mode 100644
index 00000000..0641fe38
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/website/create-doc.md
@@ -0,0 +1,248 @@
+---
+title: Create a Document
+sidebar_position: 1
+---
+
+## Creating a Document in Docusaurus: A Beginner's Guide
+
+Docusaurus is a powerful tool for building documentation websites with ease. It uses Markdown files to generate static HTML pages, making it simple to create and maintain your project’s documentation. In this guide, we’ll cover everything you need to know to create a document in Docusaurus, from understanding the folder structure to configuring the sidebar navigation.
+
+### 1. Understanding the Docusaurus Folder Structure
+
+When you set up a Docusaurus project, it creates a specific folder structure to organize your site. The key folders and files related to documentation are:
+
+- **`docs/`**: This is where all your documentation files are stored. Each file in this folder is a Markdown file (with a `.md` or `.mdx` extension) that will be converted into a page on your documentation site.
+
+- **`docusaurus.config.js`**: This is the main configuration file for your Docusaurus site. It controls settings like the site title, navigation, and more.
+
+- **`sidebars.js`** (optional): This file allows you to manually configure the sidebar navigation for your documentation.
+
+- **`static/`**: This folder holds static assets like images, which can be referenced in your documentation.
+
+For example, a typical Docusaurus project might look like this:
+
+```text
+my-docusaurus-site/
+├── docs/
+│ ├── intro.md
+│ └── getting-started.md
+├── src/
+│ └── pages/
+├── static/
+│ └── img/
+├── docusaurus.config.js
+├── package.json
+└── sidebars.js
+```
+
+In this structure, the `docs/` folder is the central location for all documentation files. This is where you’ll create and store your documents.
+
+### 2. Parameters at the Start of the Docs (Front Matter)
+
+In Docusaurus, each Markdown file can have an optional **front matter** section at the top. The front matter is written in YAML format and is enclosed between triple dashes (`---`). It provides metadata about the document, allowing you to customize its behavior and appearance. Common parameters (fields) in the front matter include:
+
+- **`id`**: A unique identifier for the document. If not specified, it defaults to the file name without the extension (e.g., `my-doc` for `my-doc.md`).
+- **`title`**: The title of the document, displayed in the sidebar and page header. If omitted, Docusaurus uses the first heading in the file.
+- **`slug`**: A custom URL path for the document (e.g., `/my-custom-url`).
+- **`tags`**: Keywords for categorizing the document.
+
+Here’s an example of a front matter:
+
+```yaml
+---
+id: my-doc
+title: My Document
+slug: /my-custom-url
+tags:
+ - example
+ - documentation
+---
+```
+
+This front matter tells Docusaurus:
+
+- The document’s unique ID is `my-doc`.
+- The title is “My Document”.
+- The URL path is `/my-custom-url` instead of the default `/docs/my-doc`.
+- It’s tagged with “example” and “documentation”.
+
+Front matter is optional, but it’s highly recommended for better control over your documents.
+
+### 3. How Folder Structure Affects Paths and Sidebar Navigation
+
+The folder structure within the `docs/` directory determines both the URL paths of your documents and the sidebar navigation.
+
+- **URL Paths**: By default, the folder structure becomes part of the document’s URL. For example:
+
+ - `docs/intro.md` → `/docs/intro`
+ - `docs/architecture/overview.md` → `/docs/architecture/overview`
+ You can override this with the `slug` parameter in the front matter.
+
+- **Sidebar Navigation**: Docusaurus can automatically generate a sidebar based on your folder structure. Each subfolder in `docs/` becomes a category in the sidebar, and the files within that folder become links under that category. For example:
+
+ ```text
+ docs/
+ ├── intro.md
+ └── architecture/
+ ├── overview.md
+ └── components.md
+ ```
+
+ This structure might produce a sidebar like:
+
+ - Intro
+ - Architecture
+ - Overview
+ - Components
+
+ The folder name (e.g., `architecture`) doesn’t automatically become the category name unless configured. You can customize this behavior using sidebar configuration files.
+
+#### The `_category_.json` File
+
+Inside a subfolder, you can add a file named `_category_.json` to configure how that folder appears in the sidebar. This file defines properties for the category. Here’s an example from the query:
+
+```json
+{
+ "label": "Architecture",
+ "position": 3,
+ "link": {
+ "type": "generated-index"
+ }
+}
+```
+
+- **`label`**: The name displayed for the category in the sidebar (e.g., “Architecture”).
+- **`position`**: The order of this category in the sidebar (e.g., 3 means it’s the third item).
+- **`link`**: Defines what happens when the category is clicked. The value `"type": "generated-index"` tells Docusaurus to create an automatically generated index page for this category, listing all documents inside the folder (e.g., `overview.md` and `components.md`).
+
+This file gives you fine-grained control over the sidebar for that specific folder.
+
+### 4. Step-by-Step Process for Creating a Document (Beginner-Friendly)
+
+If you’re new to Docusaurus, follow these steps to create your first document:
+
+1. **Set Up Docusaurus**:
+
+ - Install Docusaurus by running this command in your terminal:
+
+ ```bash
+ npx create-docusaurus@latest my-site classic
+ ```
+
+ - This creates a new Docusaurus site in the `my-site` folder using the classic template.
+ - Navigate to your project folder:
+
+ ```bash
+ cd my-site
+ ```
+
+2. **Go to the Docs Folder**:
+
+ - Open the `docs/` folder in your project directory (e.g., `my-site/docs/`).
+
+3. **Create a Markdown File**:
+
+ - Create a new file, e.g., `my-doc.md`, using a text editor.
+
+4. **Add Front Matter (Optional)**:
+
+ - At the top of the file, add metadata like this:
+
+ ```yaml
+ ---
+ id: my-doc
+ title: My Document
+ ---
+ ```
+
+5. **Write Your Content**:
+
+ - Below the front matter, write your documentation using Markdown. For example:
+
+ ```markdown
+ # My Document
+
+ Welcome to my first Docusaurus document!
+
+ ## Features
+
+ - Easy to use
+ - Highly customizable
+ ```
+
+6. **Organize with Folders (Optional)**:
+
+ - To group related documents, create a subfolder (e.g., `docs/features/`) and move or create files inside it (e.g., `features/my-doc.md`).
+
+7. **Configure the Sidebar (Optional)**:
+
+ - For automatic sidebar generation, Docusaurus will use your folder structure.
+ - To customize a category, add a `_category_.json` file in the subfolder. For example, in `docs/features/`:
+
+ ```json
+ {
+ "label": "Features",
+ "position": 2,
+ "link": {
+ "type": "generated-index"
+ }
+ }
+ ```
+
+ - Alternatively, edit `sidebars.js` in the root directory for manual sidebar configuration.
+
+8. **Preview Your Site**:
+ - Start the development server by running:
+
+ ```bash
+ npm start
+ ```
+
+ or
+
+ ```bash
+ yarn start
+ ```
+
+ - Open your browser and go to `http://localhost:3000` to see your site.
+ - Check that your new document appears and the sidebar reflects your structure.
+
+### 5. Example `.md` File
+
+Here’s a complete example of a Markdown file you might create:
+
+```markdown
+---
+id: architecture-overview
+title: Architecture Overview
+slug: /architecture
+tags:
+ - architecture
+ - overview
+---
+
+# Architecture Overview
+
+This document provides an overview of the system's architecture.
+
+## Components
+
+- **Frontend**: Built with React.
+- **Backend**: Powered by Node.js.
+
+## Design Principles
+
+- Modularity
+- Scalability
+```
+
+- The front matter sets the ID, title, custom URL, and tags.
+- The content uses Markdown for structure and readability.
+
+### 6. Additional Resources
+
+For more details on creating and customizing documents in Docusaurus, visit the official documentation:
+
+- [https://docusaurus.io/docs/create-doc](https://docusaurus.io/docs/create-doc)
+
+This guide covers the essentials, but Docusaurus offers advanced features like versioning and multi-language support. As you grow comfortable, explore these to enhance your documentation site.
diff --git a/versioned_docs/version-1.2.0/developer-guide/website/versioning-doc.md b/versioned_docs/version-1.2.0/developer-guide/website/versioning-doc.md
new file mode 100644
index 00000000..038121a5
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/website/versioning-doc.md
@@ -0,0 +1,361 @@
+---
+title: Version management
+sidebar_position: 2
+---
+
+# Versioning Documentation in Docusaurus: A Comprehensive Guide
+
+Docusaurus offers robust built-in support for versioning documentation, a critical feature for projects that evolve over time. Versioning allows you to maintain multiple versions of your documentation, ensuring users can access information relevant to the specific version of your software they are using. This comprehensive document will walk you through the process of setting up, managing, and optimizing versioned documentation in Docusaurus.
+
+---
+
+## 1. Understanding Versioning in Docusaurus
+
+Docusaurus provides a straightforward system for versioning documentation:
+
+- **Current Version**: This is the latest, actively maintained version of your documentation, stored in the `docs/` folder. It typically represents the "Next" version or the most recent unreleased changes.
+- **Versioned Docs**: These are snapshots of your documentation at specific points in time, usually tied to software releases. They are stored in folders named `versioned_docs/version-/`, such as `versioned_docs/version-1.0/` for version 1.0.
+
+For example:
+
+```text
+// Project directory structure with versioning
+my-docusaurus-project/
+├── docs/ # Current version documentation
+├── versioned_docs/ # All versioned documentation
+│ ├── version-1.0/ # Version 1.0 documentation
+│ └── version-1.1/ # Version 1.1 documentation
+├── versioned_sidebars/ # Sidebars for each version
+│ ├── version-1.0-sidebars.json
+│ └── version-1.1-sidebars.json
+└── versions.json # List of all available versions
+```
+
+Each versioned set of documentation is a complete copy of the `docs/` folder at the time the version was created.
+
+---
+
+## 2. Setting Up Versioning
+
+To begin versioning your documentation in Docusaurus, follow these steps:
+
+### Step 1: Create Your First Version
+
+When you're ready to release a new version of your software, create a versioned snapshot of your current documentation:
+
+- Run the following command in your terminal:
+
+```bash
+# File: terminal command
+npm run docusaurus docs:version
+```
+
+or
+
+```bash
+# File: terminal command
+yarn docusaurus docs:version
+```
+
+Replace `` with your desired version number, e.g., `1.0`.
+
+- **What Happens**:
+ - Docusaurus duplicates the entire `docs/` folder into `versioned_docs/version-1.0/`.
+ - It updates the `versions.json` file, which tracks all versioned documentation.
+
+Example `versions.json` after creating version 1.0:
+
+```json
+// File: versions.json
+[
+ "1.0"
+]
+```
+
+### Step 2: Customize Version Labels
+
+By default, the version number (e.g., "1.0") appears in the sidebar and version selector. You can customize these labels in `docusaurus.config.js`:
+
+```javascript
+// File: docusaurus.config.js
+module.exports = {
+ // ... other configuration
+ themeConfig: {
+ // ... other theme configuration
+ docs: {
+ sidebar: {
+ versionLabels: {
+ '1.0': 'Version 1.0 (Legacy)',
+ '1.1': 'Version 1.1',
+ 'current': 'Next (Unreleased)'
+ },
+ },
+ },
+ },
+};
+```
+
+---
+
+## 3. Managing Versioned Documentation
+
+Once versioning is set up, you can manage your documentation as follows:
+
+### Updating Documentation
+
+- **Current Version**: Edit files in the `docs/` folder to reflect the latest changes and features.
+- **Versioned Docs**: To update a specific version (e.g., for corrections or clarifications), modify files in `versioned_docs/version-/`.
+
+**Note**: Limit changes to versioned docs to minor fixes. Major updates should go into the current version (`docs/`).
+
+### Adding New Versions
+
+When releasing a new software version:
+
+```bash
+# File: terminal command
+# 1. Update docs/ folder with latest content
+# 2. Run the versioning command
+npm run docusaurus docs:version 2.0
+```
+
+This creates a new snapshot in `versioned_docs/version-2.0/` and updates `versions.json`:
+
+```json
+// File: versions.json (after adding version 2.0)
+[
+ "2.0",
+ "1.0"
+]
+```
+
+### Removing Versions
+
+To delete a version:
+
+```bash
+# File: terminal command
+# 1. Remove the version folder
+rm -rf versioned_docs/version-1.0
+rm -rf versioned_sidebars/version-1.0-sidebars.json
+
+# 2. Update versions.json manually
+```
+
+Edit `versions.json` to remove the version:
+
+```json
+// File: versions.json (after removing version 1.0)
+[
+ "2.0"
+]
+```
+
+---
+
+## 4. Configuring the Sidebar for Versioned Docs
+
+Docusaurus handles sidebars for each version automatically, but you can customize them if needed.
+
+### Automatic Sidebar Generation
+
+When you create a version, Docusaurus automatically creates a sidebar configuration:
+
+```json
+// File: versioned_sidebars/version-1.0-sidebars.json (automatically generated)
+{
+ "version-1.0/docs": [
+ {
+ "type": "category",
+ "label": "Getting Started",
+ "items": [
+ {
+ "type": "doc",
+ "id": "version-1.0/intro"
+ },
+ {
+ "type": "doc",
+ "id": "version-1.0/installation"
+ }
+ ]
+ }
+ ]
+}
+```
+
+### Manual Sidebar Configuration
+
+For more control, you can modify the versioned sidebar file directly:
+
+```javascript
+// File: versioned_sidebars/version-1.0-sidebars.json (customized)
+{
+ "version-1.0/docs": [
+ {
+ "type": "category",
+ "label": "Getting Started",
+ "items": [
+ {
+ "type": "doc",
+ "id": "version-1.0/intro"
+ },
+ {
+ "type": "doc",
+ "id": "version-1.0/installation"
+ }
+ ]
+ },
+ {
+ "type": "category",
+ "label": "Advanced Topics",
+ "items": [
+ {
+ "type": "doc",
+ "id": "version-1.0/advanced/configuration"
+ }
+ ]
+ }
+ ]
+}
+```
+
+---
+
+## 5. Linking to Versioned Docs
+
+### Version Dropdown Component
+
+Docusaurus adds a version selector dropdown to your site navigation:
+
+```jsx
+// File: src/theme/Navbar.js (automatically handled by Docusaurus)
+import React from 'react';
+import VersionsDropdown from '@theme/VersionsDropdown';
+
+function Navbar() {
+ return (
+
+ );
+}
+```
+
+### Creating Custom Links to Specific Versions
+
+In your documentation, you can link to specific versions:
+
+```markdown
+
+
+Check our [installation guide for v1.0](/docs/1.0/installation) or the [latest installation guide](/docs/installation).
+```
+
+---
+
+## 6. Best Practices for Versioning
+
+- **Version Naming**: Use semantic versioning (e.g., 1.0, 1.1, 2.0) for clarity.
+
+ ```text
+ // Recommended version naming
+ 1.0, 1.1, 2.0 // ✓ Semantic versioning
+
+ // Not recommended
+ stable, beta, old // ✗ Ambiguous naming
+ ```
+
+- **Configuration Example** for managing version labels and visibility:
+
+ ```javascript
+ // File: docusaurus.config.js
+ module.exports = {
+ // ... other configuration
+ presets: [
+ [
+ '@docusaurus/preset-classic',
+ {
+ docs: {
+ // ... other docs configuration
+ lastVersion: 'current',
+ versions: {
+ current: {
+ label: 'Next',
+ path: 'next',
+ },
+ '2.0': {
+ label: '2.0',
+ path: '2.0',
+ },
+ '1.0': {
+ label: '1.0 (Legacy)',
+ path: '1.0',
+ banner: 'unmaintained', // Adds a banner indicating this version is no longer maintained
+ },
+ },
+ },
+ },
+ ],
+ ],
+ };
+ ```
+
+---
+
+## 7. Example Scenario
+
+Let's walk through versioning for a software project with two releases: 1.0 and 2.0.
+
+```bash
+# File: terminal commands for versioning workflow
+# Initial setup - create version 1.0
+npm run docusaurus docs:version 1.0
+
+# Result:
+# - versioned_docs/version-1.0/ contains a snapshot of docs/
+# - versioned_sidebars/version-1.0-sidebars.json is created
+# - versions.json now includes "1.0"
+
+# Later - update docs/ with changes for version 2.0 and create version 2.0
+npm run docusaurus docs:version 2.0
+
+# Result:
+# - versioned_docs/version-2.0/ is created
+# - versioned_sidebars/version-2.0-sidebars.json is created
+# - versions.json now includes "2.0" and "1.0"
+# - docs/ becomes the "Next" version
+```
+
+Final project structure:
+
+```text
+# File: Project structure after versioning
+my-docusaurus-project/
+├── docs/ # Current "Next" version
+├── versioned_docs/
+│ ├── version-2.0/ # Version 2.0 documentation
+│ └── version-1.0/ # Version 1.0 documentation
+├── versioned_sidebars/
+│ ├── version-2.0-sidebars.json
+│ └── version-1.0-sidebars.json
+└── versions.json # ["2.0", "1.0"]
+```
+
+The result is a site where users can easily navigate between versions through the dropdown menu:
+
+- **Next**: Latest unreleased changes
+- **2.0**: Documentation for version 2.0
+- **1.0 (Legacy)**: Documentation for version 1.0
+
+---
+
+## 8. Additional Resources
+
+For more in-depth information, refer to the official Docusaurus documentation:
+
+- [https://docusaurus.io/docs/versioning](https://docusaurus.io/docs/versioning)
+
+---
+
+This guide provides everything you need to create and manage versioned documentation in Docusaurus. By following these steps, you can ensure your users have access to the right documentation for their software version. Happy documenting!
diff --git a/versioned_docs/version-1.2.0/developer-guide/workflow-automation-guide.md b/versioned_docs/version-1.2.0/developer-guide/workflow-automation-guide.md
new file mode 100644
index 00000000..70ef51fb
--- /dev/null
+++ b/versioned_docs/version-1.2.0/developer-guide/workflow-automation-guide.md
@@ -0,0 +1,68 @@
+---
+sidebar_position: 3
+title: Automation Workflows
+---
+
+# Project Documentation: Automation Workflows
+
+This document outlines the automated workflows for the Kmesh project, designed to enhance documentation quality and streamline versioning.
+
+## 1. kmeshctl Sync Workflow
+
+**Purpose:** Automatically sync the kmeshctl CLI documentation from the kmesh repository to the kmesh-website repository via a Pull Request (PR).
+
+**Workflow Trigger:** A push to the main branch of the kmesh repository, specifically when changes are made to the `docs/ctl/` directory.
+
+### Steps
+
+1. **Checkout Repositories:** The workflow checks out both the kmesh-website and kmesh repositories.
+2. **Sync with rsync:** Uses the rsync command to synchronize the `docs/ctl/` directory from kmesh into the docs/kmeshctl/ directory of kmesh-website. The --delete flag ensures that deleted files are also removed.
+3. **Create Pull Request:** If changes are detected, the workflow commits them and uses the `peter-evans/create-pull-request` action to create a PR in the kmesh-website repository. The branch name includes a timestamp to ensure uniqueness and prevent conflicts.
+
+### Maintenance Notes
+
+- **Secrets:** The `WEBSITE_PAT` secret must have write access to both the `kmesh-net/kmesh` and kmesh-net/website repositories.
+- **Path Changes:** If the source or target directory paths change, update the `KMESH_CTL_DIR` and `WEBSITE_KMESHCTL_DIR` variables in the workflow.
+
+## 2. Docusaurus Versioning and i18n (Chinese) Handling
+
+The Docusaurus versioning system is designed to create new versions based on the content of the source docs/ directory. When the docusaurus docs:version command is executed, it automatically generates a new versioned folder (e.g., `versioned_docs/version-X.Y.Z/`) containing all the English documentation.
+
+### Chinese Documentation (i18n) Versioning
+
+- The Docusaurus versioning command does not automatically create a corresponding versioned folder for the Chinese translations located in `i18n/zh/docusaurus-plugin-content-docs/.`
+- As a result, when a new version is created, there is no `i18n/zh/docusaurus-plugin-content-docs/version-X.Y.Z/` folder.
+- This causes a "Page Not Found" error for users who have selected the Chinese language and navigate to the new version.
+
+### Solution: Custom 404 Page
+
+- To provide a seamless user experience, a custom 404 page has been implemented.
+- When a Chinese user encounters a missing page for a new version, they are presented with a helpful error page.
+- This page includes a prominent button that allows the user to easily redirect to the English version of the requested documentation or return to the homepage.
+- This approach ensures that users always have access to the information they need, even if the Chinese translation for the latest version is not yet available.
+
+This solution balances the need for up-to-date documentation with the practicalities of a multilingual site, where translation efforts may lag behind the release of new English content.
+
+### Maintenance Notes
+
+- This workflow relies on the `GITHUB_TOKEN` for PR creation.
+- Ensure the `npm install` command is used, as a `package-lock.json` file is not available.
+
+## 3. Chinese Grammar Check Workflow
+
+**Purpose:** Automatically check the grammar and spelling of Chinese documentation.
+
+**Workflow Trigger:** A push or pull request to the main branch, specifically when changes are made to files in the `docs/cn/zh/` directory.
+
+### Steps
+
+- **Checkout and Setup:** The workflow checks out the code and sets up a Python environment.
+- **Install Dependencies:** Installs the language-tool-python package.
+- **Run Grammar Check:** Uses the LanguageTool library to scan only the .md files within the `docs/cn/zh/` directory and its subdirectories for Chinese (zh-CN) content.
+- **Report Issues:** The script provides detailed, color-coded output for any issues found, including the file, line number, error type (spelling, grammar, style), context, and suggestions. It also creates GitHub warning annotations.
+
+### Maintenance Notes
+
+- The workflow is robust and includes retries for initializing the LanguageTool service.
+- It handles encoding errors gracefully.
+- The output is designed to be highly readable for developers, classifying errors and providing actionable feedback.
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl.md
new file mode 100644
index 00000000..2a0c1ead
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl.md
@@ -0,0 +1,19 @@
+## kmeshctl
+
+Kmesh command line tools to operate and debug Kmesh
+
+### Options
+
+```bash
+ -h, --help help for kmeshctl
+```
+
+### SEE ALSO
+
+* [kmeshctl authz](kmeshctl_authz.md) - Manage xdp authz eBPF program for Kmesh's authz offloading
+* [kmeshctl dump](kmeshctl_dump.md) - Dump config of kernel-native or dual-engine mode
+* [kmeshctl log](kmeshctl_log.md) - Get or set kmesh-daemon's logger level
+* [kmeshctl monitoring](kmeshctl_monitoring.md) - Control Kmesh's monitoring to be turned on as needed
+* [kmeshctl secret](kmeshctl_secret.md) - Use secrets to manage secret configuration data for IPsec
+* [kmeshctl version](kmeshctl_version.md) - Prints out build version info
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_accesslog.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_accesslog.md
new file mode 100644
index 00000000..85122d75
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_accesslog.md
@@ -0,0 +1,27 @@
+## kmeshctl accesslog
+
+Enable or disable Kmesh's accesslog
+
+```bash
+kmeshctl accesslog [flags]
+```
+
+### Examples
+
+```bash
+# Enable Kmesh's accesslog:
+kmeshctl accesslog enable
+
+# Disable Kmesh's accesslog:
+kmeshctl accesslog disable
+```
+
+### Options
+
+```bash
+ -h, --help help for accesslog
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz.md
new file mode 100644
index 00000000..f4a13364
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz.md
@@ -0,0 +1,16 @@
+## kmeshctl authz
+
+Manage xdp authz eBPF program for Kmesh's authz offloading
+
+### Options
+
+```bash
+ -h, --help help for authz
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
+* [kmeshctl authz disable](kmeshctl_authz_disable.md) - Disable xdp authz eBPF program for Kmesh's authz offloading
+* [kmeshctl authz enable](kmeshctl_authz_enable.md) - Enable xdp authz eBPF program for Kmesh's authz offloading
+* [kmeshctl authz status](kmeshctl_authz_status.md) - Display the current authorization status
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_disable.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_disable.md
new file mode 100644
index 00000000..b9a48540
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_disable.md
@@ -0,0 +1,24 @@
+## kmeshctl authz disable
+
+Disable xdp authz eBPF program for Kmesh's authz offloading
+
+```bash
+kmeshctl authz disable [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz disable
+kmeshctl authz disable pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for disable
+```
+
+### SEE ALSO
+
+* [kmeshctl authz](kmeshctl_authz.md) - Manage xdp authz eBPF program for Kmesh's authz offloading
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_enable.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_enable.md
new file mode 100644
index 00000000..79e95fa4
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_enable.md
@@ -0,0 +1,24 @@
+## kmeshctl authz enable
+
+Enable xdp authz eBPF program for Kmesh's authz offloading
+
+```bash
+kmeshctl authz enable [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz enable
+kmeshctl authz enable pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for enable
+```
+
+### SEE ALSO
+
+* [kmeshctl authz](kmeshctl_authz.md) - Manage xdp authz eBPF program for Kmesh's authz offloading
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_status.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_status.md
new file mode 100644
index 00000000..b4dbdbef
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_authz_status.md
@@ -0,0 +1,24 @@
+## kmeshctl authz status
+
+Display the current authorization status
+
+```bash
+kmeshctl authz status [podNames...] [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl authz status
+kmeshctl authz status pod1 pod2
+```
+
+### Options
+
+```bash
+ -h, --help help for status
+```
+
+### SEE ALSO
+
+* [kmeshctl authz](kmeshctl_authz.md) - Manage xdp authz eBPF program for Kmesh's authz offloading
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_dump.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_dump.md
new file mode 100644
index 00000000..eed76b69
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_dump.md
@@ -0,0 +1,27 @@
+## kmeshctl dump
+
+Dump config of kernel-native or dual-engine mode
+
+```bash
+kmeshctl dump [flags]
+```
+
+### Examples
+
+```bash
+# Kernel Native mode:
+kmeshctl dump kernel-native
+
+# Dual Engine mode:
+kmeshctl dump dual-engine
+```
+
+### Options
+
+```bash
+ -h, --help help for dump
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_log.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_log.md
new file mode 100644
index 00000000..8ab262b8
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_log.md
@@ -0,0 +1,31 @@
+## kmeshctl log
+
+Get or set kmesh-daemon's logger level
+
+```bash
+kmeshctl log [flags]
+```
+
+### Examples
+
+```bash
+# Set default logger's level as "debug":
+kmeshctl log --set default:debug
+
+# Get all loggers' name
+kmeshctl log
+
+# Get default logger's level:
+kmeshctl log default
+```
+
+### Options
+
+```bash
+ -h, --help help for log
+ --set string Set the logger level (e.g., default:debug)
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_monitoring.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_monitoring.md
new file mode 100644
index 00000000..5cec0dc4
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_monitoring.md
@@ -0,0 +1,50 @@
+## kmeshctl monitoring
+
+Control Kmesh's monitoring to be turned on as needed
+
+```bash
+kmeshctl monitoring [flags]
+```
+
+### Examples
+
+```bash
+# Enable/Disable Kmesh's accesslog:
+kmeshctl monitoring --accesslog enable/disable
+
+# Enable/Disable services' metrics and accesslog generated from bpf:
+kmeshctl monitoring --all enable/disable
+
+# Enable/Disable workload granularity metrics:
+kmeshctl monitoring --workloadMetrics enable/disable
+
+# Enable/Disable connection granularity metrics:
+kmeshctl monitoring --connectionMetrics enable/disable
+
+# If you want to change the monitoring functionality of all kmesh daemons in the cluster
+# Enable/Disable Kmesh's accesslog in each node:
+kmeshctl monitoring --accesslog enable/disable
+
+# Enable/Disable workload granularity metrics in each node:
+kmeshctl monitoring --workloadMetrics enable/disable
+
+# Enable/Disable connection granularity metrics in each node:
+kmeshctl monitoring --connectionMetrics enable/disable
+
+#Enable/Disable services', workloads' and 'connections' metrics and accesslog generated from bpf in each node:
+kmeshctl monitoring --all enable/disable
+```
+
+### Options
+
+```bash
+ --accesslog string Control accesslog enable or disable
+ --all string Control accesslog and services' and workloads' metrics enable or disable together
+ --connectionMetrics string Control connection granularity metrics enable or disable
+ -h, --help help for monitoring
+ --workloadMetrics string Control workload granularity metrics enable or disable
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret.md
new file mode 100644
index 00000000..01cdbdce
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret.md
@@ -0,0 +1,30 @@
+## kmeshctl secret
+
+Use secrets to manage secret configuration data for IPsec
+
+```bash
+kmeshctl secret [flags]
+```
+
+### Examples
+
+```bash
+# Use kmeshctl secret to manage secret configuration data for IPsec:
+kmeshctl secret create or kmeshctl secret create --key=$(echo -n "{36-character user-defined key here}" | xxd -p -c 64)
+kmeshctl secret get
+kmeshctl secret delete
+
+```
+
+### Options
+
+```bash
+ -h, --help help for secret
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
+* [kmeshctl secret create](kmeshctl_secret_create.md) - Generate IPsec key and configuration by kmeshctl
+* [kmeshctl secret delete](kmeshctl_secret_delete.md) - Delete IPsec key and configuration by kmeshctl
+* [kmeshctl secret get](kmeshctl_secret_get.md) - Get IPsec key and configuration by kmeshctl
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_create.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_create.md
new file mode 100644
index 00000000..63d82d95
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_create.md
@@ -0,0 +1,27 @@
+## kmeshctl secret create
+
+Generate IPsec key and configuration by kmeshctl
+
+```bash
+kmeshctl secret create [flags]
+```
+
+### Examples
+
+```bash
+# Generate IPsec configuration with random IPsec key:
+kmeshctl secret create
+# Generate IPsec configuration with user-defined key:
+kmeshctl secret create --key=$(echo -n "{36-character user-defined key here}" | xxd -p -c 64)
+```
+
+### Options
+
+```bash
+ -h, --help help for create
+ -k, --key string key of the encryption
+```
+
+### SEE ALSO
+
+* [kmeshctl secret](kmeshctl_secret.md) - Use secrets to manage secret configuration data for IPsec
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_delete.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_delete.md
new file mode 100644
index 00000000..90790edd
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_delete.md
@@ -0,0 +1,23 @@
+## kmeshctl secret delete
+
+Delete IPsec key and configuration by kmeshctl
+
+```bash
+kmeshctl secret delete [flags]
+```
+
+### Examples
+
+```bash
+kmeshctl secret delete
+```
+
+### Options
+
+```bash
+ -h, --help help for delete
+```
+
+### SEE ALSO
+
+* [kmeshctl secret](kmeshctl_secret.md) - Use secrets to manage secret configuration data for IPsec
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_get.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_get.md
new file mode 100644
index 00000000..5c792c9c
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_secret_get.md
@@ -0,0 +1,24 @@
+## kmeshctl secret get
+
+Get IPsec key and configuration by kmeshctl
+
+```bash
+kmeshctl secret get [flags]
+```
+
+### Examples
+
+```bash
+# Get IPsec key and configuration by kmeshctl. The results will be displayed in JSON format.
+kmeshctl secret get
+```
+
+### Options
+
+```bash
+ -h, --help help for get
+```
+
+### SEE ALSO
+
+* [kmeshctl secret](kmeshctl_secret.md) - Use secrets to manage secret configuration data for IPsec
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_version.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_version.md
new file mode 100644
index 00000000..388a9429
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_version.md
@@ -0,0 +1,27 @@
+## kmeshctl version
+
+Prints out build version info
+
+```bash
+kmeshctl version [flags]
+```
+
+### Examples
+
+```bash
+# Show version of all kmesh components
+kmeshctl version
+
+# Show version info of a specific kmesh daemon
+kmeshctl version
+```
+
+### Options
+
+```bash
+ -h, --help help for version
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint.md
new file mode 100644
index 00000000..6a7dc17c
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint.md
@@ -0,0 +1,42 @@
+## kmeshctl waypoint
+
+Manage waypoint configuration
+
+### Synopsis
+
+A group of commands used to manage waypoint configuration
+
+```bash
+kmeshctl waypoint [flags]
+```
+
+### Examples
+
+```bash
+ # Apply a waypoint to the current namespace
+ kmeshctl waypoint apply
+
+ # Generate a waypoint as yaml
+ kmeshctl waypoint generate --namespace default
+
+ # List all waypoints in a specific namespace
+ kmeshctl waypoint list --namespace default
+```
+
+### Options
+
+```bash
+ -h, --help help for waypoint
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl](kmeshctl.md) - Kmesh command line tools to operate and debug Kmesh
+* [kmeshctl waypoint apply](kmeshctl_waypoint_apply.md) - Apply a waypoint configuration
+* [kmeshctl waypoint delete](kmeshctl_waypoint_delete.md) - Delete a waypoint configuration
+* [kmeshctl waypoint generate](kmeshctl_waypoint_generate.md) - Generate a waypoint configuration
+* [kmeshctl waypoint list](kmeshctl_waypoint_list.md) - List managed waypoint configurations
+* [kmeshctl waypoint status](kmeshctl_waypoint_status.md) - Show the status of waypoints in a namespace
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_apply.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_apply.md
new file mode 100644
index 00000000..75244189
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_apply.md
@@ -0,0 +1,47 @@
+## kmeshctl waypoint apply
+
+Apply a waypoint configuration
+
+### Synopsis
+
+Apply a waypoint configuration to the cluster
+
+```bash
+kmeshctl waypoint apply [flags]
+```
+
+### Examples
+
+```bash
+ # Apply a waypoint to the current namespace
+ kmeshctl waypoint apply
+
+ # Apply a waypoint to a specific namespace and wait for it to be ready
+ kmeshctl waypoint apply --namespace default --wait
+
+ # Apply a waypoint to a specific pod
+ kmeshctl waypoint apply -n default --name reviews-v2-pod-waypoint --for workload
+```
+
+### Options
+
+```bash
+ --enroll-namespace If set, the namespace will be labeled with the waypoint name
+ --for string Specify the traffic type [all none service workload] for the waypoint
+ -h, --help help for apply
+ --overwrite Overwrite the existing Waypoint used by the namespace
+ -r, --revision string The revision to label the waypoint with
+ -w, --wait Wait for the waypoint to be ready
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_delete.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_delete.md
new file mode 100644
index 00000000..420ac3bc
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_delete.md
@@ -0,0 +1,46 @@
+## kmeshctl waypoint delete
+
+Delete a waypoint configuration
+
+### Synopsis
+
+Delete a waypoint configuration from the cluster
+
+```bash
+kmeshctl waypoint delete [flags]
+```
+
+### Examples
+
+```bash
+ # Delete a waypoint from the default namespace
+ kmeshctl waypoint delete
+
+ # Delete a waypoint by name, which can obtain from kmeshctl waypoint list
+ kmeshctl waypoint delete waypoint-name --namespace default
+
+ # Delete several waypoints by name
+ kmeshctl waypoint delete waypoint-name1 waypoint-name2 --namespace default
+
+ # Delete all waypoints in a specific namespace
+ kmeshctl waypoint delete --all --namespace default
+```
+
+### Options
+
+```bash
+ --all Delete all waypoints in the namespace
+ -h, --help help for delete
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_generate.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_generate.md
new file mode 100644
index 00000000..2029133f
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_generate.md
@@ -0,0 +1,41 @@
+## kmeshctl waypoint generate
+
+Generate a waypoint configuration
+
+### Synopsis
+
+Generate a waypoint configuration as YAML
+
+```bash
+kmeshctl waypoint generate [flags]
+```
+
+### Examples
+
+```bash
+ # Generate a waypoint as yaml
+ kmeshctl waypoint generate --namespace default
+
+ # Generate a waypoint that can process traffic for service in default namespace
+ kmeshctl waypoint generate --for service -n default
+```
+
+### Options
+
+```bash
+ --for string Specify the traffic type [all none service workload] for the waypoint
+ -h, --help help for generate
+ -r, --revision string The revision to label the waypoint with
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_list.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_list.md
new file mode 100644
index 00000000..b96a82c0
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_list.md
@@ -0,0 +1,40 @@
+## kmeshctl waypoint list
+
+List managed waypoint configurations
+
+### Synopsis
+
+List managed waypoint configurations in the cluster
+
+```bash
+kmeshctl waypoint list [flags]
+```
+
+### Examples
+
+```bash
+ # List all waypoints in a specific namespace
+ kmeshctl waypoint list --namespace default
+
+ # List all waypoints in the cluster
+ kmeshctl waypoint list -A
+```
+
+### Options
+
+```bash
+ -A, --all-namespaces List all waypoints in all namespaces
+ -h, --help help for list
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_status.md b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_status.md
new file mode 100644
index 00000000..942423a6
--- /dev/null
+++ b/versioned_docs/version-1.2.0/kmeshctl/kmeshctl_waypoint_status.md
@@ -0,0 +1,39 @@
+## kmeshctl waypoint status
+
+Show the status of waypoints in a namespace
+
+### Synopsis
+
+Show the status of waypoints for the namespace provided or default namespace if none is provided
+
+```bash
+kmeshctl waypoint status [flags]
+```
+
+### Examples
+
+```bash
+ # Show the status of the waypoint in the default namespace
+ kmeshctl waypoint status
+
+ # Show the status of the waypoint in a specific namespace
+ kmeshctl waypoint status --namespace foo
+```
+
+### Options
+
+```bash
+ -h, --help help for status
+```
+
+### Options inherited from parent commands
+
+```bash
+ --image string image of the waypoint
+ --name string name of the waypoint (default "waypoint")
+ -n, --namespace string Kubernetes namespace
+```
+
+### SEE ALSO
+
+* [kmeshctl waypoint](kmeshctl_waypoint.md) - Manage waypoint configuration
diff --git a/versioned_docs/version-1.2.0/performance/_category_.json b/versioned_docs/version-1.2.0/performance/_category_.json
new file mode 100644
index 00000000..a1f7c1ae
--- /dev/null
+++ b/versioned_docs/version-1.2.0/performance/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Performance",
+ "position": 4,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/performance/images/fortio_performance_test.png b/versioned_docs/version-1.2.0/performance/images/fortio_performance_test.png
new file mode 100644
index 00000000..893e4af7
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/fortio_performance_test.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/perf_network.png b/versioned_docs/version-1.2.0/performance/images/perf_network.png
new file mode 100644
index 00000000..7951459c
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/perf_network.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test1.png b/versioned_docs/version-1.2.0/performance/images/resource_test1.png
new file mode 100644
index 00000000..6321b3a5
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test1.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test2.png b/versioned_docs/version-1.2.0/performance/images/resource_test2.png
new file mode 100644
index 00000000..c92df042
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test2.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test3.png b/versioned_docs/version-1.2.0/performance/images/resource_test3.png
new file mode 100644
index 00000000..e82a8c06
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test3.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_env.png b/versioned_docs/version-1.2.0/performance/images/resource_test_env.png
new file mode 100644
index 00000000..19e1bd0b
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_env.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_memory.png b/versioned_docs/version-1.2.0/performance/images/resource_test_memory.png
new file mode 100644
index 00000000..b21e2c34
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_memory.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_result1.png b/versioned_docs/version-1.2.0/performance/images/resource_test_result1.png
new file mode 100644
index 00000000..c103cb4d
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_result1.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_result2.png b/versioned_docs/version-1.2.0/performance/images/resource_test_result2.png
new file mode 100644
index 00000000..958e1e3c
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_result2.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_result3.png b/versioned_docs/version-1.2.0/performance/images/resource_test_result3.png
new file mode 100644
index 00000000..f27cdb9e
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_result3.png differ
diff --git a/versioned_docs/version-1.2.0/performance/images/resource_test_result4.png b/versioned_docs/version-1.2.0/performance/images/resource_test_result4.png
new file mode 100644
index 00000000..55c20067
Binary files /dev/null and b/versioned_docs/version-1.2.0/performance/images/resource_test_result4.png differ
diff --git a/versioned_docs/version-1.2.0/performance/performance.md b/versioned_docs/version-1.2.0/performance/performance.md
new file mode 100644
index 00000000..a78650ba
--- /dev/null
+++ b/versioned_docs/version-1.2.0/performance/performance.md
@@ -0,0 +1,47 @@
+---
+title: Kmesh Performance
+sidebar_position: 1
+---
+
+## Observability Integrations
+
+Kmesh provides comprehensive monitoring capabilities through integration with industry-standard observability platforms:
+
+- **Prometheus**: Collects and stores metrics for Kmesh performance and operations
+- **Grafana**: Visualizes Kmesh metrics through customizable dashboards
+- **Jaeger**: Enables distributed tracing to analyze service mesh traffic patterns
+
+These integrations help monitor Kmesh's performance metrics, resource consumption, and traffic patterns in real-time.
+
+## Test Network Setup
+
+
+
+## How We Test
+
+### Testing Tools
+
+Kmesh uses two main testing tools:
+
+- **Fortio**: A microservice load testing tool that measures:
+ - Latency (TP90, TP99)
+ - Throughput (QPS)
+- **Dstat**: A system monitoring tool that tracks CPU usage during tests
+
+### Test Method
+
+Test a group of `fortio` performance data by using the number of concurrent connections as a variable parameter, and collect the CPU usage during the test. The [test script](https://github.com/kmesh-net/kmesh/tree/main/test/performance) has been archived.
+
+## Running the Tests
+
+```shell
+#Preparing the test environment
+[root@perf]# ./fortio_perf.sh
+# Generate a CSV table of test results in the directory.
+[root@perf]# ll
+-rw-r--r--. 1 root root 6.1K Nov 5 17:39 fortio_perf_test.csv
+```
+
+## Performance Results
+
+
diff --git a/versioned_docs/version-1.2.0/performance/resource-consumption.md b/versioned_docs/version-1.2.0/performance/resource-consumption.md
new file mode 100644
index 00000000..bb8be014
--- /dev/null
+++ b/versioned_docs/version-1.2.0/performance/resource-consumption.md
@@ -0,0 +1,222 @@
+---
+title: Kmesh Resource Consumption
+sidebar_position: 2
+---
+
+# Kmesh Resource Consumption
+
+## Background Information
+
+eBPF programs consume CPU and memory resources during execution. To better understand Kmesh's resource consumption under different workloads, we conducted several CPU and memory stress tests. These tests evaluate the limits of Kmesh's resource consumption in real-world usage scenarios.
+
+**Note: This documentation is based on Kmesh 0.4 kernel-native mode**
+
+## Environment Setup
+
+
+
+| Component | Version/Details |
+| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
+| K8S | v1.27 |
+| Kmesh | 0.4 kernel-native mode |
+| Kernel | 5.10 |
+| Node | 8U16G |
+| Testing tool | fortio |
+| Metric collection | [bpftop](https://github.com/Netflix/bpftop), [inspektor-gadget](https://github.com/inspektor-gadget/inspektor-gadget) |
+
+## Test Case 1: POD with CPU Limit
+
+### Scenario 1.1: Single App with CPU Limit
+
+
+
+We set a CPU limit of 1 (1 CPU) for App A and collected the corresponding Kmesh eBPF CPU consumption.
+
+:::note
+With the system having 8 cores and a CPU limit of 1, the POD can consume up to 12.5% of the total CPU.
+:::
+
+**Test Procedure:**
+
+1. Generated load using the fortio client:
+
+ ```bash
+ # !/bin/bash
+
+ client_address=`kubectl get pod | grep fortio-client | awk {'print $1'}`
+ echo "$client_address" | xargs -P 0 -I {} kubectl exec -it {} -- fortio load -quiet -c 1500 -t 100s -qps 0 -keepalive=false fortio-server.default.svc.cluster.local:80
+ ```
+
+2. Collected CPU usage with bpftop:
+
+ ```bash
+ ./bpftop
+ ```
+
+**Test Results:**
+
+
+
+The 12.99% shown in the figure means that 12.99% of one CPU core was consumed.
+
+**Conclusion:**
+When App A fully utilizes one CPU core, the eBPF program consumes 1.73% of the CPU (13.9% usage of one CPU core = 1.73% of 8 CPU cores), which is less than the POD CPU limit of 12.5%. There are two possible explanations:
+
+- App A and Kmesh eBPF share the POD CPU limit, with Kmesh eBPF CPU being restricted by the POD CPU limit
+- The eBPF CPU cost is relatively small compared to the application itself, and App A is not generating enough load to cause eBPF to exceed the CPU limit
+
+### Scenario 1.2: Multiple Apps with CPU Limits
+
+
+
+We deployed 4 instances of App A, with a CPU limit of 250m for each instance, totaling 1 CPU for all 4 instances.
+
+**Test Results:**
+
+
+
+The 13.42% shown in the figure means that 13.42% of one CPU core was consumed.
+
+**Conclusion:**
+When App A fully utilizes one CPU, the eBPF program consumes 1.81% of the CPU, which is less than the POD CPU limit of 12.5%.
+
+### Scenario 1.3: Modified eBPF Code to Increase CPU Usage
+
+We modified the eBPF code to decrease its performance, causing it to consume more CPU, to observe if it could exceed the POD CPU limit.
+
+**Implementation:**
+Added a for loop in the Kmesh eBPF code:
+
+```c
+SEC("cgroup/connect4")
+int cgroup_connect4_prog(struct bpf_sock_addr *ctx)
+{
+ struct kmesh_context kmesh_ctx = {0};
+ kmesh_ctx.ctx = ctx;
+ kmesh_ctx.orig_dst_addr.ip4 = ctx->user_ip4;
+ kmesh_ctx.dnat_ip.ip4 = ctx->user_ip4;
+ kmesh_ctx.dnat_port = ctx->user_port;
+
+ if (handle_kmesh_manage_process(&kmesh_ctx) || !is_kmesh_enabled(ctx)) {
+ return CGROUP_SOCK_OK;
+ }
+
+ // Add for loop to increase CPU usage
+ int i;
+ for (i = 0; i < 65535; i++) {
+ bpf_printk("increase cpu usage");
+ }
+
+ int ret = sock4_traffic_control(ctx);
+ return CGROUP_SOCK_OK;
+}
+```
+
+**Test Results:**
+
+
+
+When App A fully utilizes one CPU, the eBPF program consumes up to 12.1% of the CPU, which is still less than the POD CPU limit of 12.5%. After multiple rounds of testing, the eBPF's CPU consumption consistently remained below the POD CPU limit.
+
+**Conclusion:**
+Kmesh eBPF and the application share the POD CPU limit, with Kmesh eBPF CPU being constrained by the POD CPU limit.
+
+## Test Case 2: Scenarios without POD CPU Limits
+
+### Scenario 2.1: Testing eBPF CPU Consumption without Limits
+
+
+
+We created 8 instances of App A with no CPU limits. We gradually increased the number of processes generating load for App A until the node's CPU usage reached 100%, then collected the CPU usage of Kmesh eBPF.
+
+**Test Results (8-core CPU totaling 8000m):**
+
+| Threads | App A CPU Usage | eBPF CPU Usage |
+| ------- | --------------- | -------------- |
+| 100 | 12.3% | 1% |
+| 500 | 35% | 4.1% |
+| 1000 | 61.7% | 8.8% |
+| 3000 | 67% | 9.5% |
+
+With 3000 concurrent processes, the node reached 100% CPU utilization. At this point, App A consumed 67% of the CPU, while Kmesh eBPF consumed approximately 9.5%.
+
+**Conclusions:**
+
+- App A consumes significantly more CPU than eBPF, making it difficult to overload eBPF. In scenarios tested with Fortio, Kmesh eBPF consumed a maximum of 9.5% CPU.
+- Further testing is needed to determine the maximum CPU consumption limit for eBPF itself.
+
+### Scenario 2.2: eBPF CPU Stress Test
+
+The [eBPF official documentation](https://ebpf-docs.dylanreimerink.nl/linux/concepts/verifier/) indicates that eBPF programs have robust security mechanisms that automatically detect infinite loops and strictly limit the number of iterations in for loops. In the current Kernel version (v5.10), eBPF programs support a maximum of 65,535 iterations in for loops.
+
+We added 65,535 iterations to the for loop and tested it:
+
+```c
+SEC("cgroup/connect4")
+int cgroup_connect4_prog(struct bpf_sock_addr *ctx)
+{
+ struct kmesh_context kmesh_ctx = {0};
+ kmesh_ctx.ctx = ctx;
+ kmesh_ctx.orig_dst_addr.ip4 = ctx->user_ip4;
+ kmesh_ctx.dnat_ip.ip4 = ctx->user_ip4;
+ kmesh_ctx.dnat_port = ctx->user_port;
+
+ if (handle_kmesh_manage_process(&kmesh_ctx) || !is_kmesh_enabled(ctx)) {
+ return CGROUP_SOCK_OK;
+ }
+
+ // Add for loop to increase CPU usage
+ int i;
+ for (i=0;i<65535;i++) {
+ bpf_printk("increase cpu usage");
+ }
+
+ int ret = sock4_traffic_control(ctx);
+ return CGROUP_SOCK_OK;
+}
+```
+
+**Test Results:**
+
+
+
+When the node's CPU was running at 100%, Kmesh eBPF consumed approximately 99.3% of the CPU. This stress test ran for 10 minutes, during which the kernel and services within the cluster continued to operate stably.
+
+**Conclusion:**
+In the Kmesh eBPF component, when adding support for the maximum number of for loop iterations, eBPF can consume all available CPU resources. However, the kernel's security mechanisms ensure the stable operation of the system.
+
+## Kmesh eBPF Memory Limit Test
+
+The memory consumption of eBPF has an upper limit, as stated in the [official documentation](https://ebpf-docs.dylanreimerink.nl/linux/concepts/resource-limit/). This limit is set through the `memory.max` setting in cGroup configurations.
+
+However, based on the current implementation of Kmesh, memory is allocated at the start of Kmesh and does not increase during runtime. We conducted tests to verify the memory usage.
+
+### Test 1: Memory Usage with Varying Service Counts
+
+We created 1, 100, and 1000 services respectively in the cluster and recorded the eBPF memory consumption using [inspektor-gadget](https://github.com/inspektor-gadget/inspektor-gadget).
+
+**Monitoring Command:**
+
+```bash
+kubectl gadget top ebpf
+```
+
+
+
+**Test Results:**
+
+| Service Count | eBPF Memory Usage |
+| ------------- | ----------------- |
+| 1 | 23 MB |
+| 100 | 23 MB |
+| 1000 | 23 MB |
+
+**Conclusion:**
+The eBPF memory consumption of Kmesh is consistently 23 MB, regardless of the number of services.
+
+### Test 2: Memory Usage Under Load
+
+We created a service (App A) in the cluster, generated load, and observed eBPF memory consumption.
+
+**Test Results:**
+Kmesh eBPF memory consumption remained constant at 23 MB, regardless of the load.
diff --git a/versioned_docs/version-1.2.0/setup/_category_.json b/versioned_docs/version-1.2.0/setup/_category_.json
new file mode 100644
index 00000000..7ec8de9c
--- /dev/null
+++ b/versioned_docs/version-1.2.0/setup/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Setup",
+ "position": 2,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/setup/develop-with-kind.md b/versioned_docs/version-1.2.0/setup/develop-with-kind.md
new file mode 100644
index 00000000..ec6da076
--- /dev/null
+++ b/versioned_docs/version-1.2.0/setup/develop-with-kind.md
@@ -0,0 +1,171 @@
+---
+title: Deploy/Develop with Kind
+sidebar_position: 2
+---
+
+# Deploy/Develop with Kind
+
+[Kind](https://github.com/kubernetes-sigs/kind) is a convenient tool for quickly deploying kubernetes cluster locally. We can use `kind` to create an `istio` cluster and deploy `kmesh`.
+
+## Deploy Kmesh in Kind
+
+Let's start from setting up the required environment. You can follow the steps below:
+
+### Install kind
+
+Installing `kind` is very simple, because it's just a binary file. You can select the correct one according to the version and the architecture in the [github releases page](https://github.com/kubernetes-sigs/kind/releases). Take `linux` + `amd64` as example:
+
+```shell
+wget -O kind https://github.com/kubernetes-sigs/kind/releases/download/v0.23.0/kind-linux-amd64
+chmod +x kind
+mv kind /usr/bin/
+```
+
+### Create Kubernetes cluster using kind
+
+You can take reference from the [istio official document](https://istio.io/latest/docs/setup/platform-setup/kind/).
+
+If you want to specified multiple workers or node image, you can:
+
+```shell
+kind create cluster --image=kindest/node:v1.30.0 --config=- < **Note**: To use waypoint you need to install the Kubernetes Gateway API CRDs, which don't come installed by default on most Kubernetes clusters:
+
+```shell
+kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
+ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=444631bfe06f3bcca5d0eadf1857eac1d369421d" | kubectl apply -f -; }
+```
+
+### Only install Istiod
+
+Installing ambient mode istio by above steps will install additional istio components.
+
+The process of installing only `istiod` as the control plane for Kmesh is provided next.
+
+#### Install Istio CRDs
+
+```shell
+helm repo add istio https://istio-release.storage.googleapis.com/charts
+helm repo update
+```
+
+To install the chart with the release name `istio-base`:
+
+```shell
+kubectl create namespace istio-system
+helm install istio-base istio/base -n istio-system
+```
+
+#### Install Istiod
+
+To install the chart with the release name `istiod`:
+
+```shell
+helm install istiod istio/istiod --namespace istio-system --version 1.24.0 --set pilot.env.PILOT_ENABLE_AMBIENT=true
+```
+
+> **Important:** Must set `pilot.env.PILOT_ENABLE_AMBIENT=true`. otherwise Kmesh will not be able to establish grpc links with istiod! If you want to use the Waypoint feature, you should use the istio version 1.23 ~ 1.25.
+
+After installing istiod, it's time to install Kubernetes Gateway API CRDs.
+
+```shell
+kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
+ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=444631bfe06f3bcca5d0eadf1857eac1d369421d" | kubectl apply -f -; }
+```
+
+## Install Kmesh
+
+We offer several ways to install Kmesh:
+
+### Option 1: Install from OCI Registry (Recommended)
+
+You can install Kmesh directly from the GitHub Container Registry without cloning the repository:
+
+```shell
+helm install kmesh oci://ghcr.io/kmesh-net/kmesh-helm --version x.y.z -n kmesh-system --create-namespace
+```
+
+- Replace `x.y.z` with your desired version from [kmesh-helm packages](https://github.com/orgs/kmesh-net/packages/container/package/kmesh-helm):
+ - For stable releases, use a version like `v1.1.0`.
+ - For pre-releases, use a version like `v1.1.0-alpha`.
+ - Omit the `--version` flag to install the latest version (not recommended for production).
+
+### Option 2: Install from Helm
+
+```shell
+helm install kmesh ./deploy/charts/kmesh-helm -n kmesh-system --create-namespace
+```
+
+### Option 3: Install from Helm Chart Archive
+
+```shell
+helm install kmesh ./kmesh-helm-.tgz -n kmesh-system --create-namespace
+```
+
+- Download the `kmesh-helm-.tgz` archive from [GitHub Releases](https://github.com/kmesh-net/kmesh/releases). Replace `` in the command above with the version you downloaded (e.g., `v1.1.0`).
+
+### Option 4: Install from Yaml
+
+```shell
+kubectl create namespace kmesh-system
+kubectl apply -f ./deploy/yaml/
+```
+
+You can confirm the status of Kmesh with the following command:
+
+```shell
+kubectl get pod -n kmesh-system
+NAME READY STATUS RESTARTS AGE
+kmesh-v2frk 1/1 Running 0 18h
+```
+
+View the running status of Kmesh service:
+
+```log
+time="2024-04-25T13:17:40Z" level=info msg="bpf Start successful" subsys=manager
+time="2024-04-25T13:17:40Z" level=info msg="controller Start successful" subsys=manager
+time="2024-04-25T13:17:40Z" level=info msg="dump StartServer successful" subsys=manager
+time="2024-04-25T13:17:40Z" level=info msg="start write CNI config\n" subsys="cni installer"
+time="2024-04-25T13:17:40Z" level=info msg="kmesh cni use chained\n" subsys="cni installer"
+time="2024-04-25T13:17:41Z" level=info msg="Copied /usr/bin/kmesh-cni to /opt/cni/bin." subsys="cni installer"
+time="2024-04-25T13:17:41Z" level=info msg="kubeconfig either does not exist or is out of date, writing a new one" subsys="cni installer"
+time="2024-04-25T13:17:41Z" level=info msg="wrote kubeconfig file /etc/cni/net.d/kmesh-cni-kubeconfig" subsys="cni installer"
+time="2024-04-25T13:17:41Z" level=info msg="cni config file: /etc/cni/net.d/10-kindnet.conflist" subsys="cni installer"
+time="2024-04-25T13:17:41Z" level=info msg="command Start cni successful" subsys=manager
+```
+
+## Verify Installation
+
+After installing Kmesh, verify all components are functioning correctly:
+
+### 1. Verify Core Components
+
+Check Kmesh pod status:
+
+```shell
+kubectl get pod -n kmesh-system
+NAME READY STATUS RESTARTS AGE
+kmesh-v2frk 1/1 Running 0 18h
+```
+
+Check Istio components:
+
+```shell
+kubectl get pods -n istio-system
+NAME READY STATUS RESTARTS AGE
+istiod-5659cfbd55-9s92d 1/1 Running 0 18h
+```
+
+### 2. Verify Pod Integration
+
+Deploy a test pod and verify Kmesh annotation:
+
+```shell
+kubectl describe po | grep Annotations
+Annotations: kmesh.net/redirection: enabled
+```
+
+### 3. Verify Service Connectivity
+
+Test service access using the sleep pod:
+
+```shell
+kubectl exec sleep-7656cf8794-xjndm -c sleep -- curl -IsS "http://httpbin:8000/status/200"
+```
+
+Expected response should show HTTP 200 OK status.
+
+### 4. Verify Kmesh Service Logs
+
+Check for successful initialization messages:
+
+```shell
+kubectl logs -n kmesh-system $(kubectl get pods -n kmesh-system -o jsonpath='{.items.metadata.name}')
+```
+
+Look for these key messages:
+
+- "bpf Start successful"
+- "controller Start successful"
+- "dump StartServer successful"
+- "command Start cni successful"
+
+### 5. Verify CNI Configuration
+
+Check CNI binary installation:
+
+```shell
+ls -l /opt/cni/bin/kmesh-cni
+```
+
+Verify CNI configuration:
+
+```shell
+cat /etc/cni/net.d/kmesh-cni-kubeconfig
+```
+
+## Change Kmesh Start Mode
+
+Kmesh supports two start up modes: `dual-engine` and `kernel-native`.
+
+The specific mode to be used is defined in deploy/charts/kmesh-helm/values.yaml, and we can modify the startup parameters in that file.
+
+```yaml
+......
+ containers:
+ kmeshDaemonArgs: "--mode=dual-engine --enable-bypass=false"
+......
+```
+
+We can use the following command to make the modification:
+
+```shell
+sed -i 's/--mode=dual-engine/--mode=kernel-native/' deploy/charts/kmesh-helm/values.yaml
+```
+
+## Deploy the Sample Applications
+
+Kmesh can manage pods in a namespace with a label `istio.io/dataplane-mode=Kmesh`, and meanwhile the pod should have no `istio.io/dataplane-mode=none` label.
+
+```shell
+# Enable Kmesh for the specified namespace
+kubectl label namespace default istio.io/dataplane-mode=Kmesh
+```
+
+Apply the following configuration to deploy sleep and httpbin:
+
+```shell
+kubectl apply -f ./samples/httpbin/httpbin.yaml
+
+kubectl apply -f ./samples/sleep/sleep.yaml
+```
+
+Check the applications status:
+
+```shell
+kubectl get pod
+NAME READY STATUS RESTARTS AGE
+httpbin-65975d4c6f-96kgw 1/1 Running 0 3h38m
+sleep-7656cf8794-8tp9n 1/1 Running 0 3h38m
+```
+
+You can confirm if a pod is managed by Kmesh by looking at the pod's annotation.
+
+```shell
+kubectl describe po httpbin-65975d4c6f-96kgw | grep Annotations
+
+Annotations: kmesh.net/redirection: enabled
+```
+
+## Test Service Access
+
+After the applications have been manage by Kmesh, we can test that they can still communicate successfully.
+
+```shell
+kubectl exec sleep-7656cf8794-xjndm -c sleep -- curl -IsS "http://httpbin:8000/status/200"
+
+HTTP/1.1 200 OK
+Server: gunicorn/19.9.0
+Date: Sun, 28 Apr 2024 07:31:51 GMT
+Connection: keep-alive
+Content-Type: text/html; charset=utf-8
+Access-Control-Allow-Origin: *
+Access-Control-Allow-Credentials: true
+Content-Length: 0
+```
+
+Note: 10.244.0.21 is the IP of httpbin
+
+## Clean Up
+
+If you don't want to use Kmesh to manage the application anymore, you can remove the labels from the namespace.
+
+```shell
+kubectl label namespace default istio.io/dataplane-mode-
+kubectl delete pod httpbin-65975d4c6f-96kgw sleep-7656cf8794-8tp9n
+kubectl describe pod httpbin-65975d4c6f-h2r99 | grep Annotations
+
+Annotations:
+```
+
+### Delete Kmesh
+
+If you installed Kmesh using any of the Helm options above:
+
+```shell
+helm uninstall kmesh -n kmesh-system
+kubectl delete ns kmesh-system
+```
+
+If you installed Kmesh using yaml:
+
+```shell
+kubectl delete -f ./deploy/yaml/
+```
+
+To remove the sleep and httpbin applications:
+
+```shell
+kubectl delete -f samples/httpbin/httpbin.yaml
+kubectl delete -f samples/sleep/sleep.yaml
+```
+
+If you installed the Gateway API CRDs, remove them:
+
+```shell
+kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref=444631bfe06f3bcca5d0eadf1857eac1d369421d" | kubectl delete -f -
+```
diff --git a/versioned_docs/version-1.2.0/setup/troubleshooting.md b/versioned_docs/version-1.2.0/setup/troubleshooting.md
new file mode 100644
index 00000000..677219dd
--- /dev/null
+++ b/versioned_docs/version-1.2.0/setup/troubleshooting.md
@@ -0,0 +1,174 @@
+---
+title: Installation Troubleshooting Guide
+sidebar_position: 4
+---
+
+## Common Installation Issues
+
+### Port Conflicts
+
+When deploying Kmesh, you might encounter port conflicts, particularly with port 15006 which is used by default.
+
+| Error Code | Description | Impact | Solution |
+| --------------- | ------------------------- | ------------------------ | --------------------------------- |
+| ERR_PORT_IN_USE | Port 15006 already in use | Prevents Kmesh startup | Change port or free existing port |
+| MISSING_DEP | Missing libbpf dependency | BPF features unavailable | Install libbpf ≥0.8 |
+| CNI_CONFLICT | CNI plugin conflicts | Network setup fails | Verify CNI configuration |
+
+## Detailed Solutions
+
+### Port Conflict Resolution
+
+If you encounter **ERR_PORT_IN_USE**, follow these steps:
+
+1. **Diagnose the Conflict**:
+
+ ```shell
+ # Check what's using port 15006
+ sudo lsof -i :15006
+
+ # For systemd services
+ sudo ss -lptn 'sport = :15006'
+ ```
+
+2. **Resolution Options**:
+
+ a. Change Kmesh Port:
+
+ ```yaml
+ # kmesh-config.yaml
+ apiVersion: kmesh.net/v1
+ kind: KmeshConfig
+ metadata:
+ name: kmesh-config
+ namespace: kmesh-system
+ spec:
+ port: 15007
+ logLevel: info
+ enableMetrics: true
+ ```
+
+ b. Free Existing Port:
+
+ ```shell
+ # Identify and stop conflicting process
+ sudo fuser -k 15006/tcp
+ ```
+
+### Dependency Management
+
+#### Install libbpf
+
+Required for BPF functionality:
+
+```bash
+# Ubuntu/Debian systems
+sudo apt-get update
+sudo apt-get install -y \
+ libbpf-dev \
+ linux-headers-$(uname -r)
+
+# Verify installation
+dpkg -l | grep libbpf
+
+# CentOS/RHEL systems
+sudo yum install -y libbpf-devel kernel-devel
+```
+
+## Runtime Verification
+
+### System Requirements Check
+
+```shell
+# Kernel version check
+uname -r # Should be ≥ 5.10.0 for full features
+
+# BPF verification
+sudo bpftool prog list
+
+# Resource limits
+ulimit -n # Should be ≥ 65535
+```
+
+### Pod Management
+
+Verify Kmesh integration:
+
+```shell
+# Check pod annotations
+kubectl get pod -o jsonpath='{.metadata.annotations}' | jq
+
+# Enable Kmesh management
+kubectl label namespace default istio.io/dataplane-mode=Kmesh --overwrite
+
+# Verify Kmesh status
+kubectl -n kmesh-system get pods -l app=kmesh
+```
+
+### Logging and Debugging
+
+#### Enhanced Logging
+
+```shell
+# Enable debug logging
+kmeshctl accesslog --set default:debug
+
+# Monitor BPF events (kernel ≥ 5.10.0)
+kubectl exec -n kmesh-system -- kmesh-daemon log --set bpf:debug
+
+# Collect all logs
+kubectl logs -n kmesh-system -l app=kmesh --all-containers --tail=1000 > kmesh-debug.log
+```
+
+## Clean-up Procedures
+
+### Cleanup
+
+Remove Kmesh and its configurations:
+
+```shell
+# Using Helm
+helm uninstall kmesh -n kmesh-system
+
+# Using kubectl
+kubectl delete namespace kmesh-system
+kubectl delete -f kmesh-config.yaml
+
+# Clean CNI configurations
+sudo rm -f /etc/cni/net.d/kmesh-cni*
+```
+
+### Configuration Reset
+
+Reset to default settings:
+
+```shell
+# Remove namespace labels
+kubectl label namespace default istio.io/dataplane-mode-
+
+# Reset CNI
+kubectl -n kmesh-system delete pod -l app=kmesh-cni
+```
+
+## Health Verification
+
+### System Health Check
+
+```shell
+# Component status
+kubectl get componentstatuses
+
+# Event monitoring
+kubectl get events -n kmesh-system --sort-by='.lastTimestamp'
+
+# Resource usage
+kubectl top pod -n kmesh-system
+```
+
+## Additional Resources
+
+- [Kmesh Architecture Guide](/docs/architecture/architecture.md)
+- [Performance Tuning](/docs/performance/performance.md)
+- [Community Support](/docs/community/contribute.md)
+
+For more complex issues, please refer to our [GitHub Issues](https://github.com/kmesh-net/kmesh/issues) or join our community channels.
diff --git a/versioned_docs/version-1.2.0/setup/use-enhanced-kernel.md b/versioned_docs/version-1.2.0/setup/use-enhanced-kernel.md
new file mode 100644
index 00000000..5dee962f
--- /dev/null
+++ b/versioned_docs/version-1.2.0/setup/use-enhanced-kernel.md
@@ -0,0 +1,42 @@
+---
+title: Use Enhanced Kernel
+sidebar_position: 3
+---
+
+# Use Enhanced Kernel
+
+Some features of kmesh depend on enhanced kernel (e.g., L7 traffic control in `Kernel Native Mode`). To utilize it, you can use **openEuler 23.03**, which natively supports all features.
+
+You can follow the steps below to use enhanced kernel:
+
+## Download openEuler 23.03 image
+
+Download the image from: https://repo.openeuler.org/openEuler-23.03/ISO/
+
+## Install the operation system
+
+Here, we take [VMware](https://www.vmware.com/products/workstation-pro/html.html) for example (you can also use other VM management tools).
+
+
+
+> **Notice:** **openEuler 23.03**'s kernel version is **6.1.19**. So you should select **其他 Linux 6.x 内核 64 位** (**Linux 6.x kernel 64bit**).
+
+Then, you can follow the [official blog](https://www.openeuler.org/zh/blog/20240306vmware/20240306vmware.html) to install it.
+
+## Install kernel headers
+
+Kmesh determines whether the enhanced kernel is utilized according to some kernel headers (e.g., `bpf.h`). So, you should install kernel headers by:
+
+```shell
+yum install kernel-headers
+```
+
+Then, you should be able to find the kernel headers in the path `/usr/include/linux`.
+
+## Check whether you are ready to use enhanced kernel
+
+```shell
+grep -q "FN(parse_header_msg)" /usr/include/linux/bpf.h && echo "enhanced" || echo "unenhanced"
+```
+
+Now you can follow the [deploy and develop guide](/docs/setup/develop-with-kind.md) to explore kmesh's full features.
diff --git a/versioned_docs/version-1.2.0/transpot-layer/_category_.json b/versioned_docs/version-1.2.0/transpot-layer/_category_.json
new file mode 100644
index 00000000..75db4c40
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/_category_.json
@@ -0,0 +1,7 @@
+{
+ "label": "Transport layer",
+ "position": 5,
+ "link": {
+ "type": "generated-index"
+ }
+}
\ No newline at end of file
diff --git a/versioned_docs/version-1.2.0/transpot-layer/accesslog.md b/versioned_docs/version-1.2.0/transpot-layer/accesslog.md
new file mode 100644
index 00000000..4f4e0258
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/accesslog.md
@@ -0,0 +1,40 @@
+---
+sidebar_position: 6
+title: Access Logs
+---
+
+## Enable Kmesh access logging
+
+Kmesh accesslog can be enabled and disabled using kmeshctl.
+
+Please refer to the [Kmeshctl Monitoring Guide](../developer-guide/Kmeshctl-usage/kmeshctl-monitoring.md)
+
+## Detailed TCP Access Logs Generated by Kmesh
+
+Logs are generated by the Kmesh daemon during key stages of a TCP connection's lifecycle:
+
+- If the `connectionMetrics` is enabled, at regular 5-second intervals while the connection is active.
+
+- Upon connection closure
+
+Access Log Field Descriptions :
+
+| Name | Describe |
+| -------------- | ------------------------------------------------------------------------------------------------------------------ |
+| src.addr | Source address and port, source workload of the request |
+| src.workload | Name of the Pod that initiated the request |
+| src.namespace | Namespace of source worklaod |
+| dst.addr | Destination address and port, destination workload of the request |
+| dst.service | Hostname of deatination service |
+| dst.workload | Name of the Pod receiving the request |
+| dst.namespace | Namespace of destination workload |
+| direction | The direction of the traffic. INBOUND means into the destination service, OUTBOUND means out of the source service |
+| sent_bytes | Number of bytes sent for this connection |
+| received_bytes | Number of bytes received for this connection |
+| duration | Duration of this |
+
+An example log entry is shown below:
+
+```bash
+accesslog: 2025-04-24 08:54:40.971980208 +0000 UTC src.addr=10.244.2.79:41978, src.workload=ws-client, src.namespace=default, dst.addr=10.244.2.78:8080, dst.service=ws-server-service.default.svc.cluster.local, dst.workload=ws-server, dst.namespace=default, start_time=2025-04-24 08:53:50.919245381 +0000 UTC, direction=OUTBOUND, state=BPF_TCP_ESTABLISHED, sent_bytes=3, received_bytes=227, packet_loss=0, retransmissions=0, srtt=40515us, min_rtt=34us, duration=50052.734827ms
+```
diff --git a/versioned_docs/version-1.2.0/transpot-layer/images/grafana.png b/versioned_docs/version-1.2.0/transpot-layer/images/grafana.png
new file mode 100644
index 00000000..7fdd698c
Binary files /dev/null and b/versioned_docs/version-1.2.0/transpot-layer/images/grafana.png differ
diff --git a/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_deamon_monitoring.jpg b/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_deamon_monitoring.jpg
new file mode 100644
index 00000000..cb09218b
Binary files /dev/null and b/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_deamon_monitoring.jpg differ
diff --git a/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_map_and_operation_monitoring.jpg b/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_map_and_operation_monitoring.jpg
new file mode 100644
index 00000000..189abc89
Binary files /dev/null and b/versioned_docs/version-1.2.0/transpot-layer/images/kmesh_map_and_operation_monitoring.jpg differ
diff --git a/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-graph.png b/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-graph.png
new file mode 100644
index 00000000..c64fb45c
Binary files /dev/null and b/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-graph.png differ
diff --git a/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-table.png b/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-table.png
new file mode 100644
index 00000000..0e6e67b2
Binary files /dev/null and b/versioned_docs/version-1.2.0/transpot-layer/images/prometheus-table.png differ
diff --git a/versioned_docs/version-1.2.0/transpot-layer/l4-metrics.md b/versioned_docs/version-1.2.0/transpot-layer/l4-metrics.md
new file mode 100644
index 00000000..184c30d5
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/l4-metrics.md
@@ -0,0 +1,191 @@
+---
+sidebar_position: 2
+title: Querying L4 Metrics from Prometheus
+---
+
+## Preparation
+
+### 1. Install Kmesh
+
+Please refer to the [quickstart guide](/docs/setup/quick-start.md)
+
+> **Note:** The following should be added to the Kmesh annotation:
+>
+> ```yaml
+> annotations:
+> prometheus.io/path: "status/metric"
+> prometheus.io/port: "15020"
+> prometheus.io/scrape: "true"
+> ```
+
+### 2. Configure Kmesh to manage the `default` namespace
+
+```bash
+kubectl label namespace default istio.io/dataplane-mode=Kmesh
+```
+
+Expected output:
+
+```text
+namespace/default labeled
+```
+
+### 3. Install the Prometheus Addon
+
+Istio provides a basic sample installation to quickly get Prometheus up and running:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+```
+
+### 4. Deploy the tcp-echo and sleep applications
+
+```bash
+# Deploy tcp-echo application
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/tcp-echo/tcp-echo.yaml
+
+# Deploy sleep application
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/sleep/sleep.yaml
+
+# Verify deployments
+kubectl get po -A
+```
+
+Expected output:
+
+```bash
+NAMESPACE NAME READY STATUS RESTARTS AGE
+default sleep-bc9998558-pbfvk 1/1 Running 0 7m
+default tcp-echo-7f676db574-mzmql 1/1 Running 0 7m
+```
+
+> **Important:** Confirm that sleep and tcp-echo are indeed [managed by kmesh](/docs/setup/quick-start.md#deploy-the-sample-applications).
+
+### 5. Enable required metrics
+
+Kmesh prometheus metrics can be enabled and disabled using kmeshctl.
+Please refer to the [kmeshctl Guide](../developer-guide/Kmeshctl-usage/kmeshctl-monitoring.md)
+
+## Querying Metrics from Prometheus
+
+### Available Metrics
+
+Metrics monitored by Kmesh L4 at this stage:
+
+#### Workload Metrics
+
+Give information about traffic behavior and performance between workloads.
+
+| Name | Description |
+| ---------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| `kmesh_tcp_workload_connections_opened_total` | The total number of TCP connections opened to a workload |
+| `kmesh_tcp_workload_connections_closed_total` | The total number of TCP connections closed to a workload |
+| `kmesh_tcp_workload_received_bytes_total` | The size of the total number of bytes received in response to a workload over a TCP connection |
+| `kmesh_tcp_workload_sent_bytes_total` | The size of the total number of bytes sent in response to a workload over a TCP connection |
+| `kmesh_tcp_workload_conntections_failed_total` | The total number of TCP connections failed to a workload |
+| `kmesh_tcp_retrans_total` | Total number of retransmissions of the workload over the TCP connection |
+| `kmesh_tcp_packet_loss_total` | Total number of TCP packets lost between source and destination workload |
+
+#### Service Metrics
+
+Give information about traffic behavior and performance between services.
+
+| Name | Description |
+| ------------------------------------- | --------------------------------------------------------------------------------------------- |
+| `kmesh_tcp_connections_opened_total` | The total number of TCP connections opened to a service |
+| `kmesh_tcp_connections_closed_total` | The total number of TCP connections closed to a service |
+| `kmesh_tcp_received_bytes_total` | The size of the total number of bytes received in response to a service over a TCP connection |
+| `kmesh_tcp_sent_bytes_total` | The size of the total number of bytes sent in response to a service over a TCP connection |
+| `kmesh_tcp_conntections_failed_total` | The total number of TCP connections failed to a service |
+
+#### Connection Metrics
+
+Give information about traffic behavior and performance of a established tcp connection(duration > 5 seconds). These metrics are particularly valuable in clusters running workloads that establish long-lived TCP connections, such as databases, message brokers, audio/video streaming services, AI applications etc.
+It is recommended to set the scrape interval to 5 seconds to ensure connection metrics are reliably captured.
+
+| Name | Description |
+| ---------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| `kmesh_tcp_connection_sent_bytes_total` | The total number of bytes sent over established TCP connection |
+| `kmesh_tcp_connection_received_bytes_total` | The total number of bytes received over established TCP connection |
+| `kmesh_tcp_connection_packet_lost_total` | Total number of packets lost during transmission in a TCP connection |
+| `kmesh_tcp_connection_retrans_total` | The total number of retransmits over established TCP connection |
+
+### Querying Steps
+
+Here's how to view these metrics through Prometheus:
+
+#### 1. Verify that the Prometheus service is running in your cluster
+
+In Kubernetes environment, execute the following command:
+
+```bash
+kubectl -n kmesh-system get svc prometheus
+```
+
+Expected output:
+
+```bash
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+prometheus ClusterIP 10.96.18.252 9090/TCP 24h
+```
+
+#### 2. Establish a TCP connection between applications in the mesh
+
+Create a TCP link between `sleep` and `tcp-echo` with the `nc` command:
+
+```bash
+kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" \
+ -c sleep -- sh -c 'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && \
+ echo 'connection succeeded' || echo 'connection rejected'
+```
+
+Expected output:
+
+```text
+hello port 9000
+connection succeeded
+```
+
+#### 3. Open the Prometheus UI
+
+Use the port-forward command to forward the traffic to Prometheus:
+
+```bash
+kubectl port-forward --address 0.0.0.0 svc/prometheus 9090:9090 -n kmesh-system
+```
+
+Expected output:
+
+```text
+Forwarding from 0.0.0.0:9090 -> 9090
+Handling connection for 9090
+Handling connection for 9090
+```
+
+#### 4. Execute a Prometheus query
+
+In the "Expression" input box at the top of the web page, enter the text:
+
+```text
+kmesh_tcp_connections_opened_total
+```
+
+The results will be similar to:
+
+
+
+You can also see the query results graphically by selecting the Graph tab underneath the Execute button.
+
+
+
+## Cleanup
+
+1. Disable port-forward.
+
+2. Cleanup Prometheus:
+
+```bash
+kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+```
+
+If you are not planning to explore any follow-on tasks, refer to the [quickstart cleanup](/docs/setup/quick-start.md#clean-up) instructions to shutdown the application.
diff --git a/versioned_docs/version-1.2.0/transpot-layer/performace-monitoring.md b/versioned_docs/version-1.2.0/transpot-layer/performace-monitoring.md
new file mode 100644
index 00000000..115d2177
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/performace-monitoring.md
@@ -0,0 +1,63 @@
+---
+sidebar_position: 4
+title: Use Grafana to visualize kmesh performance monitoring
+---
+
+**NOTE:** This is an immature feature, so we turn it off by default, you can optionally turn it on.
+
+## Preparation
+
+1. Make default namespace managed by Kmesh
+2. Set relevant args:
+ - Modify `bpf/kmesh/probes/performance_probe.h` by changing `#define PERF_MONITOR 0` to `#define PERF_MONITOR 1`.
+ - Change `--profiling=false` to `--profiling=true` in `deploy/yaml/kmesh.yaml`. (The default value of `--profiling` is false.)
+3. Deploy bookinfo as sample application and sleep as curl client
+4. Install namespace granularity waypoint for default namespace
+
+ *The above steps could refer to [Install Waypoint | Kmesh](https://kmesh.net/docs/setup/quick-start)
+
+5. Refer to [quick start](https://kmesh.net/docs/setup/quick-start) to include test pods in kmesh management. Or include default namespace in kmesh management.
+
+6. Use `kmeshctl` to enable all of kmesh's monitoring functions:
+
+```sh
+kmeshctl monitoring --all enable
+```
+
+1. Deploy prometheus and garafana:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/grafana.yaml
+```
+
+## Generate some continuous traffic between applications in the mesh
+
+```bash
+kubectl exec deploy/sleep -- sh -c "while true; do curl -s http://productpage:9080/productpage | grep reviews-v.-; sleep 1; done"
+```
+
+## Use grafana to visualize kmesh performance monitoring
+
+1. Use the port-forward command to forward traffic to grafana:
+
+```bash
+kubectl port-forward --address 0.0.0.0 svc/grafana 3000:3000 -n kmesh-system
+# Forwarding from 0.0.0.0:3000 -> 3000
+```
+
+2. View the dashboard from browser
+
+ Visit `Dashboards > Kmesh > Kmesh performance monitoring`:
+
+ 
+ 
+
+## Cleanup
+
+1. Remove prometheus and grafana:
+
+```bash
+kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/grafana.yaml
+```
diff --git a/versioned_docs/version-1.2.0/transpot-layer/service-metrics.md b/versioned_docs/version-1.2.0/transpot-layer/service-metrics.md
new file mode 100644
index 00000000..6483b862
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/service-metrics.md
@@ -0,0 +1,51 @@
+---
+sidebar_position: 5
+title: Use Grafana to visualize service metrics
+---
+
+## Preparation
+
+1. Make default namespace managed by Kmesh
+2. Deploy bookinfo as sample application and sleep as curl client
+3. Install namespace granularity waypoint for default namespace
+
+ _The above steps could refer to [Install Waypoint | Kmesh](/docs/application-layer/install_waypoint.md#preparation)_
+
+4. Deploy prometheus and garafana:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+kubectl apply -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/grafana.yaml
+```
+
+## Generate some continuous traffic between applications in the mesh
+
+```bash
+kubectl exec deploy/sleep -- sh -c "while true; do curl -s http://productpage:9080/productpage | grep reviews-v.-; sleep 1; done"
+```
+
+## Use grafana to visualize service metrics
+
+1. Use the port-forward command to forward traffic to grafana:
+
+```bash
+kubectl port-forward --address 0.0.0.0 svc/grafana 3000:3000 -n kmesh-system
+# Forwarding from 0.0.0.0:3000 -> 3000
+```
+
+2. View the dashboard from browser
+
+ Visit `Dashboards > Kmesh > Kmesh Service Dashboard`:
+
+ 
+
+## Cleanup
+
+1. Remove prometheus and grafana:
+
+```bash
+kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/prometheus.yaml
+kubectl delete -f https://raw.githubusercontent.com/kmesh-net/kmesh/main/samples/addons/grafana.yaml
+```
+
+2. If you are not planning to explore any follow-on tasks, refer to the [Install Waypoint/Cleanup](/docs/application-layer/install_waypoint.md#cleanup) instructions to remove waypoint and shutdown the application.
diff --git a/versioned_docs/version-1.2.0/transpot-layer/tcp-authorization.md b/versioned_docs/version-1.2.0/transpot-layer/tcp-authorization.md
new file mode 100644
index 00000000..86d33070
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/tcp-authorization.md
@@ -0,0 +1,265 @@
+---
+sidebar_position: 1
+title: TCP Authorization
+---
+
+
+This guide shows you how to set up authorization policy for TCP traffic in Kmesh.
+
+## Before you begin
+
+- Understand the [AuthorizationPolicy](#authorizationpolicy) concept
+- Install Kmesh
+ - Please refer to the [quickstart guide](/docs/setup/quick-start.md)
+- Deploy the Sample Applications and configure them to be managed by Kmesh
+ - Please refer to [deploy applications](/docs/setup/quick-start.md#deploy-the-sample-applications)
+ - Modify the replicas to 2 in sleep deployment:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: sleep
+spec:
+ replicas: 2
+ selector:
+ matchLabels:
+ app: sleep
+ template:
+ metadata:
+ labels:
+ app: sleep
+ spec:
+ terminationGracePeriodSeconds: 0
+ serviceAccountName: sleep
+ containers:
+ - name: sleep
+ image: curlimages/curl
+ command: ["/bin/sleep", "infinity"]
+ imagePullPolicy: IfNotPresent
+ volumeMounts:
+ - mountPath: /etc/sleep/tls
+ name: secret-volume
+ volumes:
+ - name: secret-volume
+ secret:
+ secretName: sleep-secret
+ optional: true
+```
+
+- Verify application status to ensure the service application is managed by Kmesh:
+
+```bash
+# Check pod status
+kubectl get pod -o wide | grep sleep
+```
+
+Expected output:
+
+```bash
+NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
+sleep-78ff5975c6-phhll 1/1 Running 0 30h 10.244.2.22 ambient-worker
+sleep-78ff5975c6-plh7r 1/1 Running 0 30h 10.244.1.46 ambient-worker2
+```
+
+```bash
+# Verify Kmesh management
+kubectl describe pod httpbin-65975d4c6f-96kgw | grep Annotations
+```
+
+Expected output:
+
+```text
+Annotations: kmesh.net/redirection: enabled
+```
+
+## Configure ALLOW Authorization Policy
+
+1. Create an "allow-by-srcip" authorization policy for the httpbin workload:
+
+```bash
+kubectl apply -f - < This policy allows requests only from the specified IP address `10.244.1.46/32`, which corresponds to the pod `sleep-78ff5975c6-plh7r`.
+
+2. Verify that requests from the allowed IP are successful:
+
+```bash
+kubectl exec sleep-78ff5975c6-plh7r -- curl http://httpbin:8000/headers
+```
+
+Expected output:
+
+```json
+{
+ "headers": {
+ "Accept": "*/*",
+ "Host": "httpbin:8000",
+ "User-Agent": "curl/8.5.0"
+ }
+}
+```
+
+3. Verify that requests from other IPs are denied:
+
+```bash
+kubectl exec sleep-78ff5975c6-phhll -- curl http://httpbin:8000/headers
+```
+
+Expected output:
+
+```text
+curl: (56) Recv failure: Connection reset by peer
+```
+
+4. Clean up the AuthorizationPolicy:
+
+```bash
+kubectl delete AuthorizationPolicy allow-by-srcip -n default
+```
+
+## Configure DENY Authorization Policy
+
+1. Create a "deny-by-srcip" authorization policy for the httpbin workload:
+
+```bash
+kubectl apply -f - < This policy denies requests from the specified IP address `10.244.1.46/32`, which corresponds to the pod `sleep-78ff5975c6-plh7r`.
+
+2. Verify that requests from the denied IP are blocked:
+
+```bash
+kubectl exec sleep-78ff5975c6-plh7r -- curl "http://httpbin:8000/headers"
+```
+
+Expected output:
+
+```text
+curl: (56) Recv failure: Connection reset by peer
+```
+
+3. Verify that requests from other IPs are allowed:
+
+```bash
+kubectl exec sleep-78ff5975c6-phhll -- curl "http://httpbin:8000/headers"
+```
+
+Expected output:
+
+```json
+{
+ "headers": {
+ "Accept": "*/*",
+ "Host": "httpbin:8000",
+ "User-Agent": "curl/8.5.0"
+ }
+}
+```
+
+4. Clean up the AuthorizationPolicy:
+
+```bash
+kubectl delete AuthorizationPolicy deny-by-srcip -n default
+```
+
+## Clean up
+
+Please refer to the [cleanup guide](/docs/setup/quick-start.md#clean-up)
+
+## AuthorizationPolicy
+
+### AuthorizationPolicy Fields
+
+| Field | Type | Description | Required |
+|---------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -------- |
+| `rules` | `Rule[]` | Optional. A list of rules to match the request. A match occurs when at least one rule matches the request. If not set, the match will never occur. This is equivalent to setting a default of deny for the target workloads if the action is ALLOW. | No |
+
+### Rule
+
+Rule matches requests from a list of sources that perform a list of operations subject to a list of conditions. A match occurs when at least one source, one operation and all conditions match the request. An empty rule is always matched.
+
+| Field | Type | Description | Required |
+|--------|----------|---------------------------------------------------------------------------------------| -------- |
+| `from` | `From[]` | Optional. `from` specifies the source of a request. If not set, any source is allowed.| No |
+| `to` | `To[]` | Optional. `to` specifies the operation of a request. If not set, any operation is allowed. | No |
+
+#### Rule.From
+
+From includes a list of sources.
+
+| Field | Type | Description | Required |
+|----------|----------|-------------------------------------------| -------- |
+| `source` | `Source` | Source specifies the source of a request. | No |
+
+#### Rule.To
+
+To includes a list of operations.
+
+| Field | Type | Description | Required |
+|-------------|-------------|-------------------------------------------------| -------- |
+| `operation` | `Operation` | Operation specifies the operation of a request. | No |
+
+### Source
+
+Source specifies the source identities of a request. Fields in the source are ANDed together.
+
+For example, the following source matches if the principal is `admin` or `dev` AND the namespace is `prod` or `test` AND the ip is not `203.0.113.4`.
+
+```yaml
+principals: ["admin", "dev"]
+namespaces: ["prod", "test"]
+notIpBlocks: ["203.0.113.4"]
+```
+
+| Field | Type | Description | Required |
+|-----------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -------- |
+| `principals` | `string[]` | Optional. A list of peer identities derived from the peer certificate. The peer identity is in the format of `"/ns//sa/"`, for example, `"cluster.local/ns/default/sa/productpage"`. This field requires mTLS enabled and is the same as the `source.principal` attribute. If not set, any principal is allowed. | No |
+| `notPrincipals` | `string[]` | Optional. A list of negative match of peer identities. | No |
+| `namespaces` | `string[]` | Optional. A list of namespaces derived from the peer certificate. This field requires mTLS enabled and is the same as the `source.namespace` attribute. If not set, any namespace is allowed. | No |
+| `notNamespaces` | `string[]` | Optional. A list of negative match of namespaces. | No |
+| `ipBlocks` | `string[]` | Optional. A list of IP blocks, populated from the source address of the IP packet. Single IP (e.g. `203.0.113.4`) and CIDR (e.g. `203.0.113.0/24`) are supported. This is the same as the `source.ip` attribute. If not set, any IP is allowed. | No |
+| `notIpBlocks` | `string[]` | Optional. A list of negative match of IP blocks. | No |
+
+### Operation
+
+Operation specifies the operations of a request. Fields in the operation are ANDed together.
+
+| Field | Type | Description | Required |
+|------------|------------|-------------------------------------------------------------------------------------------| -------- |
+| `ports` | `string[]` | Optional. A list of ports as specified in the connection. If not set, any port is allowed.| No |
+| `notPorts` | `string[]` | Optional. A list of negative match of ports as specified in the connection. | No |
diff --git a/versioned_docs/version-1.2.0/transpot-layer/xdp-auth.md b/versioned_docs/version-1.2.0/transpot-layer/xdp-auth.md
new file mode 100644
index 00000000..cf07c791
--- /dev/null
+++ b/versioned_docs/version-1.2.0/transpot-layer/xdp-auth.md
@@ -0,0 +1,212 @@
+---
+sidebar_position: 3
+title: TCP Authorization in XDP
+---
+
+## Authorization in XDP
+
+Previously, we launched the [userspace authorization feature](/docs/transpot-layer/tcp-authorization.md), where authorization results were verified in userspace. This document explains how to enable authentication directly within the XDP program. Currently, XDP-based authentication supports verification based on port and IP addresses only.
+
+### How to enable XDP-based authentication
+
+We can use `kmeshctl` to enable XDP-based authentication:
+
+```bash
+./kmeshctl authz enable
+```
+
+To modify BPF log level:
+
+```bash
+./kmeshctl log <$kmeshnode1> --set bpf:debug
+```
+
+## Configure Deny Authorization Policies
+
+### Configure Destination Port Deny Authorization Policy
+
+Create a "deny-by-dstport" authorization policy for the Fortio workload that denies requests to the specified port address. In this example, traffic sent to port 8080 is denied:
+
+```yaml
+# deny-by-dstport.yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: deny-by-dstport
+spec:
+ selector:
+ matchLabels:
+ app: fortio-server
+ action: DENY
+ rules:
+ - to:
+ - operation:
+ ports:
+ - "8080"
+```
+
+Apply the policy:
+
+```bash
+kubectl apply -f deny-by-dstport.yaml
+```
+
+#### Testing the Policy
+
+The status code returned by the Fortio traffic confirms that traffic sent to port 8080 has been denied:
+
+```bash
+kubectl exec -it fortio-client-deployment-6966bf9488-tpwpj -- fortio load -c 1 -n 1 -qps 0 -jitter=true 10.244.0.7:8080
+```
+
+Expected output:
+
+```text
+...
+IP addresses distribution:
+10.244.0.7:8080: 1
+Code -1 : 1 (100.0 %)
+Response Header Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+Response Body/Total Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+All done 1 calls (plus 0 warmup) 3005.022 ms avg, 0.3 qps
+```
+
+Specific information will also be printed in the logs recorded by Kmesh:
+
+```bash
+kubectl logs -f kmesh-vlxhd -n kmesh-system
+```
+
+Expected output:
+
+```log
+...
+time="2024-12-25T15:23:12+08:00" level=info msg="[AUTH] DEBUG: port 8080 in destination_ports, matched" subsys=ebpf
+time="2024-12-25T15:23:12+08:00" level=info msg="[AUTH] DEBUG: rule matched, action: DENY" subsys=ebpf
+```
+
+### Configure Source IP Deny Authorization Policy
+
+Create a policy to deny traffic from a specific source IP:
+
+```yaml
+# deny-by-srcip.yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: allow-by-srcip1
+ namespace: default
+spec:
+ selector:
+ matchLabels:
+ app: fortio-server
+ action: DENY
+ rules:
+ - from:
+ - source:
+ ipBlocks:
+ - 10.244.1.36
+```
+
+Apply the policy:
+
+```bash
+kubectl apply -f deny-by-srcip.yaml
+```
+
+#### Testing the Policy
+
+The status code returned by the Fortio traffic confirms that traffic sent from IP 10.244.1.36 has been denied:
+
+```bash
+# The IP address of fortio-client-deployment-6966bf9488-m96qp is 10.244.1.36
+kubectl exec -it fortio-client-deployment-6966bf9488-m96qp -- fortio load -c 1 -n 1 -qps 0 -jitter=true 10.244.0.36:8080
+```
+
+Expected output:
+
+```text
+...
+IP addresses distribution:
+10.244.0.36:8080: 1
+Code -1 : 1 (100.0 %)
+Response Header Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+Response Body/Total Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+All done 1 calls (plus 0 warmup) 3005.563 ms avg, 0.3 qps
+```
+
+Specific information will also be printed in the logs recorded by Kmesh:
+
+```bash
+kubectl logs -f kmesh-vlxhd -n kmesh-system
+```
+
+Expected output:
+
+```log
+...
+time="2024-12-26T15:05:26+08:00" level=info msg="[AUTH] DEBUG: rule matched, action: DENY" subsys=ebpf
+time="2024-12-26T15:06:14+08:00" level=info msg="[AUTH] DEBUG: no ports configured, matching by default" subsys=ebpf
+time="2024-12-26T15:06:14+08:00" level=info msg="[AUTH] DEBUG: IPv4 match srcip: Rule IP: af40124, Prefix Length: 32, Target IP: af40124\n" subsys=ebpf
+```
+
+### Configure Destination IP Deny Authorization Policy
+
+Create a policy to deny traffic to a specific destination IP:
+
+```yaml
+# deny-by-dstip.yaml
+apiVersion: security.istio.io/v1beta1
+kind: AuthorizationPolicy
+metadata:
+ name: deny-dstip
+spec:
+ selector:
+ matchLabels:
+ app: fortio-server
+ action: DENY
+ rules:
+ - when:
+ - key: destination.ip
+ values: ["10.244.0.36"]
+```
+
+Apply the policy:
+
+```bash
+kubectl apply -f deny-by-dstip.yaml
+```
+
+#### Testing the Policy
+
+The status code returned by the Fortio traffic confirms that traffic sent to IP 10.244.0.36 has been denied:
+
+```bash
+kubectl exec -it fortio-client-deployment-6966bf9488-m96qp -- fortio load -c 1 -n 1 -qps 0 -jitter=true 10.244.0.36:8080
+```
+
+Expected output:
+
+```text
+...
+10.244.0.36:8080: 1
+Code -1 : 1 (100.0 %)
+Response Header Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+Response Body/Total Sizes : count 1 avg 0 +/- 0 min 0 max 0 sum 0
+All done 1 calls (plus 0 warmup) 3004.974 ms avg, 0.3 qps
+```
+
+Specific information will also be printed in the logs recorded by Kmesh:
+
+```bash
+kubectl logs -f kmesh-vlxhd -n kmesh-system
+```
+
+Expected output:
+
+```log
+...
+time="2024-12-26T15:05:22+08:00" level=info msg="[AUTH] DEBUG: rule matched, action: DENY" subsys=ebpf
+time="2024-12-26T15:05:26+08:00" level=info msg="[AUTH] DEBUG: no ports configured, matching by default" subsys=ebpf
+time="2024-12-26T15:05:26+08:00" level=info msg="[AUTH] DEBUG: IPv4 match dstip: Rule IP: af40024, Prefix Length: 32, Target IP: af40024\n" subsys=ebpf
+```
diff --git a/versioned_docs/version-1.2.0/welcome.md b/versioned_docs/version-1.2.0/welcome.md
new file mode 100644
index 00000000..de875103
--- /dev/null
+++ b/versioned_docs/version-1.2.0/welcome.md
@@ -0,0 +1,32 @@
+---
+sidebar_position: 1
+title: Welcome
+last_update:
+ date: "2025-02-22"
+---
+
+# Welcome to Kmesh: High-Performance and Low Overhead Service Mesh Data Plane
+
+Kmesh leverages eBPF and programmable kernels to offload traffic management to the OS, accelerating service mesh performance. Compared to traditional service meshes, it offers advantages such as low latency, being sidecarless, and low resource consumption.
+
+## Why Kmesh?
+
+- **Superior Performance**: Reduces service mesh latency through kernel-level optimizations
+- **Resource Efficiency**: Minimizes overhead by implementing service governance at the OS layer
+- **Simplified Operations**: Streamlines service mesh management with kernel-integrated traffic routing
+- **Cloud Native Integration**: Seamlessly works with existing cloud-native infrastructure
+
+## Core Benefits
+
+| Benefit | Description |
+| ----------------------- | ---------------------------------------------------------------------------- |
+| Latency Reduction | Direct kernel path routing reduces service-to-service communication overhead |
+| Resource Optimization | Lower CPU and memory usage through OS-layer implementation |
+| Simplified Architecture | Fewer hops in service access paths improve overall performance |
+
+In the following docs, we will explain:
+
+- The [architecture](/docs/architecture/) and highlights advantages of Kmesh.
+- The [quick start](/docs/setup/quick-start) of Kmesh.
+- The [performance](/docs/performance/) of Kmesh.
+- The [community](/docs/community/contribute.md) of Kmesh.
diff --git a/versioned_sidebars/version-1.2.0-sidebars.json b/versioned_sidebars/version-1.2.0-sidebars.json
new file mode 100644
index 00000000..caea0c03
--- /dev/null
+++ b/versioned_sidebars/version-1.2.0-sidebars.json
@@ -0,0 +1,8 @@
+{
+ "tutorialSidebar": [
+ {
+ "type": "autogenerated",
+ "dirName": "."
+ }
+ ]
+}
diff --git a/versions.json b/versions.json
new file mode 100644
index 00000000..6a2a2a1e
--- /dev/null
+++ b/versions.json
@@ -0,0 +1,3 @@
+[
+ "1.2.0"
+]
diff --git a/yarn.lock b/yarn.lock
index 71e8cc3c..3a6c6853 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -2276,10 +2276,10 @@
dependencies:
"@types/mdx" "^2.0.0"
-"@node-rs/jieba-darwin-arm64@2.0.1":
+"@node-rs/jieba-linux-x64-gnu@2.0.1":
version "2.0.1"
- resolved "https://registry.npmjs.org/@node-rs/jieba-darwin-arm64/-/jieba-darwin-arm64-2.0.1.tgz"
- integrity sha512-10+nwGQ6KzXXJlIL/sELA6Fi6m7eJ7xJksBiKuw1kxKUgaJwtVfAG0iqRF+NRQv0Sdq7r3k5ew9K9y0+IYaEcA==
+ resolved "https://registry.npmjs.org/@node-rs/jieba-linux-x64-gnu/-/jieba-linux-x64-gnu-2.0.1.tgz"
+ integrity sha512-sq3J6L2ANTE25I9eVFq/nb57OtXcvUIeUD1CTKJxwgTKIVmcB2LyOZpWf20AjHRUfbMER9Klqg5dgyyO+Six+w==
"@node-rs/jieba@^2.0.1":
version "2.0.1"
@@ -2322,10 +2322,10 @@
"@nodelib/fs.scandir" "2.1.5"
fastq "^1.6.0"
-"@parcel/watcher-darwin-arm64@2.5.1":
+"@parcel/watcher-linux-x64-glibc@2.5.1":
version "2.5.1"
- resolved "https://registry.npmjs.org/@parcel/watcher-darwin-arm64/-/watcher-darwin-arm64-2.5.1.tgz"
- integrity sha512-eAzPv5osDmZyBhou8PoF4i6RQXAfeKL9tjb3QzYuccXFMQU0ruIc/POh30ePnaOyD1UXdlKguHBmsTs53tVoPw==
+ resolved "https://registry.npmjs.org/@parcel/watcher-linux-x64-glibc/-/watcher-linux-x64-glibc-2.5.1.tgz"
+ integrity sha512-GcESn8NZySmfwlTsIur+49yDqSny2IhPeZfXunQi48DMugKeZ7uy1FX83pO0X22sHntJ4Ub+9k34XQCX+oHt2A==
"@parcel/watcher@^2.4.1":
version "2.5.1"