+
+ Revision
+
in the lower-right corner, click **kubectl**, and run the following command to edit `ks-installer` of the CRD `ClusterConfiguration`:
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. Add the following fields under `spec.authentication.jwtSecret`.
+
+ Example:
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ loginHistoryRetentionPeriod: 168h
+ maximumClockSkew: 10s
+ multipleLogin: true
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: LDAP
+ type: LDAPIdentityProvider
+ mappingMethod: auto
+ provider:
+ host: 192.168.0.2:389
+ managerDN: uid=root,cn=users,dc=nas
+ managerPassword: ********
+ userSearchBase: cn=users,dc=nas
+ loginAttribute: uid
+ mailAttribute: mail
+ ```
+
+ The fields are described as follows:
+
+ * `jwtSecret`: Secret used to sign user tokens. In a multi-cluster environment, all clusters must [use the same Secret](../../../multicluster-management/enable-multicluster/direct-connection/#prepare-a-member-cluster).
+ * `authenticateRateLimiterMaxTries`: Maximum number of consecutive login failures allowed during a period specified by `authenticateRateLimiterDuration`. If the number of consecutive login failures of a user reaches the limit, the user will be blocked.
+ * `authenticateRateLimiterDuration`: Period during which `authenticateRateLimiterMaxTries` applies.
+ * `loginHistoryRetentionPeriod`: Retention period of login records. Outdated login records are automatically deleted.
+ * `maximumClockSkew`: Maximum clock skew for time-sensitive operations such as token expiration validation. The default value is `10s`.
+ * `multipleLogin`: Whether multiple users are allowed to log in from different locations. The default value is `true`.
+ * `oauthOptions`: OAuth settings.
+ * `accessTokenMaxAge`: Access token lifetime. For member clusters in a multi-cluster environment, the default value is `0h`, which means access tokens never expire. For other clusters, the default value is `2h`.
+ * `accessTokenInactivityTimeout`: Access token inactivity timeout period. An access token becomes invalid after it is idle for a period specified by this field. After an access token times out, the user needs to obtain a new access token to regain access.
+ * `identityProviders`: Identity providers.
+ * `name`: Identity provider name.
+ * `type`: Identity provider type.
+ * `mappingMethod`: Account mapping method. The value can be `auto` or `lookup`.
+ * If the value is `auto` (default), you need to specify a new username. KubeSphere automatically creates a user according to the username and maps the user to a third-party account.
+ * If the value is `lookup`, you need to perform step 3 to manually map an existing KubeSphere user to a third-party account.
+ * `provider`: Identity provider information. Fields in this section vary according to the identity provider type.
+
+3. If `mappingMethod` is set to `lookup`, run the following command and add the labels to map a KubeSphere user to a third-party account. Skip this step if `mappingMethod` is set to `auto`.
+
+ ```bash
+ kubectl edit user in the lower-right corner, click **kubectl**, and run the following command to edit `ks-installer` of the CRD `ClusterConfiguration`:
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+ Example:
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ maximumClockSkew: 10s
+ multipleLogin: true
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: LDAP
+ type: LDAPIdentityProvider
+ mappingMethod: auto
+ provider:
+ host: 192.168.0.2:389
+ managerDN: uid=root,cn=users,dc=nas
+ managerPassword: ********
+ userSearchBase: cn=users,dc=nas
+ loginAttribute: uid
+ mailAttribute: mail
+ ```
+
+2. Configure fields other than `oauthOptions:identityProviders` in the `spec:authentication` section. For details, see [Set Up External Authentication](../set-up-external-authentication/).
+
+3. Configure fields in `oauthOptions:identityProviders` section.
+
+ * `name`: User-defined LDAP service name.
+ * `type`: To use an LDAP service as an identity provider, you must set the value to `LDAPIdentityProvider`.
+ * `mappingMethod`: Account mapping method. The value can be `auto` or `lookup`.
+ * If the value is `auto` (default), you need to specify a new username. KubeSphere automatically creates a user according to the username and maps the user to an LDAP user.
+ * If the value is `lookup`, you need to perform step 4 to manually map an existing KubeSphere user to an LDAP user.
+ * `provider`:
+ * `host`: Address and port number of the LDAP service.
+ * `managerDN`: DN used to bind to the LDAP directory.
+ * `managerPassword`: Password corresponding to `managerDN`.
+ * `userSearchBase`: User search base. Set the value to the DN of the directory level below which all LDAP users can be found.
+ * `loginAttribute`: Attribute that identifies LDAP users.
+ * `mailAttribute`: Attribute that identifies email addresses of LDAP users.
+
+4. If `mappingMethod` is set to `lookup`, run the following command and add the labels to map a KubeSphere user to an LDAP user. Skip this step if `mappingMethod` is set to `auto`.
+
+ ```bash
+ kubectl edit user in the lower-right corner, click **kubectl**, and run the following command to edit `ks-installer` of the CRD `ClusterConfiguration`:
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. Confiother than `oauthOptions:identityProviders` in the `spec:authentication` section. For details, see [Set Up External Authentication](../set-up-external-authentication/).
+
+3. Configure fields in `oauthOptions:identityProviders` section according to the identity provider plugin you have developed.
+
+ The following is a configuration example that uses GitHub as an external identity provider. For details, see the [official GitHub documentation](https://docs.github.com/en/developers/apps/building-oauth-apps) and the [source code of the GitHubIdentityProvider](https://github.com/kubesphere/kubesphere/blob/release-3.1/pkg/apiserver/authentication/identityprovider/github/github.go) plugin.
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: github
+ type: GitHubIdentityProvider
+ mappingMethod: auto
+ provider:
+ clientID: '******'
+ clgure fields ientSecret: '******'
+ redirectURL: 'https://ks-console/oauth/redirect/github'
+ ```
+
+ Similarly, you can also use Alibaba Cloud IDaaS as an external identity provider. For details, see the official [Alibaba IDaaS documentation](https://www.alibabacloud.com/help/product/111120.htm?spm=a3c0i.14898238.2766395700.1.62081da1NlxYV0) and the [source code of the AliyunIDaasProvider](https://github.com/kubesphere/kubesphere/blob/release-3.1/pkg/apiserver/authentication/identityprovider/github/github.go) plugin.
+
+4. After the fields are configured, save your changes, and wait until the restart of ks-installer is complete.
+
+ {{< notice note >}}
+
+ The KubeSphere web console is unavailable during the restart of ks-installer. Please wait until the restart is complete.
+
+ {{}}
+
+5. Go to the KubeSphere login page, click **Log In with XXX** (for example, **Log In with GitHub**).
+
+6. On the login page of the external identity provider, enter the username and password of a user configured at the identity provider to log in to KubeSphere.
+
+ 
+
diff --git a/content/en/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md b/content/en/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md
new file mode 100644
index 000000000..fbe355bf9
--- /dev/null
+++ b/content/en/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md
@@ -0,0 +1,57 @@
+---
+title: "Kubernetes Multi-tenancy in KubeSphere"
+keywords: "Kubernetes, KubeSphere, multi-tenancy"
+description: "Understand the multi-tenant architecture in KubeSphere."
+linkTitle: "Multi-tenancy in KubeSphere"
+weight: 12100
+---
+
+Kubernetes helps you orchestrate applications and schedule containers, greatly improving resource utilization. However, there are various challenges facing both enterprises and individuals in resource sharing and security as they use Kubernetes, which is different from how they managed and maintained clusters in the past.
+
+The first and foremost challenge is how to define multi-tenancy in an enterprise and the security boundary of tenants. [The discussion about multi-tenancy](https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY) has never stopped in the Kubernetes community, while there is no definite answer to how a multi-tenant system should be structured.
+
+## Challenges in Kubernetes Multi-tenancy
+
+Multi-tenancy is a common software architecture. Resources in a multi-tenant environment are shared by multiple users, also known as "tenants", with their respective data isolated from each other. The administrator of a multi-tenant Kubernetes cluster must minimize the damage that a compromised or malicious tenant can do to others and make sure resources are fairly allocated.
+
+No matter how an enterprise multi-tenant system is structured, it always comes with the following two building blocks: logical resource isolation and physical resource isolation.
+
+Logically, resource isolation mainly entails API access control and tenant-based permission control. [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in Kubernetes and namespaces provide logic isolation. Nevertheless, they are not applicable in most enterprise environments. Tenants in an enterprise often need to manage resources across multiple namespaces or even clusters. Besides, the ability to provide auditing logs for isolated tenants based on their behavior and event queries is also a must in multi-tenancy.
+
+The isolation of physical resources includes nodes and networks, while it also relates to container runtime security. For example, you can create [NetworkPolicy](../../pluggable-components/network-policy/) resources to control traffic flow and use PodSecurityPolicy objects to control container behavior. [Kata Containers](https://katacontainers.io/) provides a more secure container runtime.
+
+## Kubernetes Multi-tenancy in KubeSphere
+
+To solve the issues above, KubeSphere provides a multi-tenant management solution based on Kubernetes.
+
+
+
+In KubeSphere, the [workspace](../../workspace-administration/what-is-workspace/) is the smallest tenant unit. A workspace enables users to share resources across clusters and projects. Workspace members can create projects in an authorized cluster and invite other members to cooperate in the same project.
+
+A **user** is the instance of a KubeSphere account. Users can be appointed as platform administrators to manage clusters or added to workspaces to cooperate in projects.
+
+Multi-level access control and resource quota limits underlie resource isolation in KubeSphere. They decide how the multi-tenant architecture is built and administered.
+
+### Logical isolation
+
+Similar to Kubernetes, KubeSphere uses RBAC to manage permissions granted to users, thus logically implementing resource isolation.
+
+The access control in KubeSphere is divided into three levels: platform, workspace and project. You use roles to control what permissions users have at different levels for different resources.
+
+1. [Platform roles](/docs/v3.3/quick-start/create-workspace-and-project/): Control what permissions platform users have for platform resources, such as clusters, workspaces and platform members.
+2. [Workspace roles](/docs/v3.3/workspace-administration/role-and-member-management/): Control what permissions workspace members have for workspace resources, such as projects (i.e. namespaces) and DevOps projects.
+3. [Project roles](/docs/v3.3/project-administration/role-and-member-management/): Control what permissions project members have for project resources, such as workloads and pipelines.
+
+### Network isolation
+
+Apart from logically isolating resources, KubeSphere also allows you to set [network isolation policies](../../pluggable-components/network-policy/) for workspaces and projects.
+
+### Auditing
+
+KubeSphere also provides [auditing logs](../../pluggable-components/auditing-logs/) for users.
+
+### Authentication and authorization
+
+For a complete authentication and authorization chain in KubeSphere, see the following diagram. KubeSphere has expanded RBAC rules using the Open Policy Agent (OPA). The KubeSphere team looks to integrate [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) to provide more security management policies.
+
+
diff --git a/content/en/docs/v3.4/application-store/_index.md b/content/en/docs/v3.4/application-store/_index.md
new file mode 100644
index 000000000..348390088
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/_index.md
@@ -0,0 +1,16 @@
+---
+title: "App Store"
+description: "Getting started with the App Store of KubeSphere"
+layout: "second"
+
+
+linkTitle: "App Store"
+weight: 14000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+The KubeSphere App Store, powered by [OpenPitrix](https://github.com/openpitrix/openpitrix), an open-source platform that manages apps across clouds, provides users with enterprise-ready containerized solutions. You can upload your own apps through app templates or add app repositories that serve as an application tool for tenants to choose the app they want.
+
+The App Store features a highly productive integrated system for application lifecycle management, allowing users to quickly upload, release, deploy, upgrade and remove apps in ways that best suit them. This is how KubeSphere empowers developers to spend less time setting up and more time developing.
diff --git a/content/en/docs/v3.4/application-store/app-developer-guide/_index.md b/content/en/docs/v3.4/application-store/app-developer-guide/_index.md
new file mode 100644
index 000000000..3d1da2629
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/app-developer-guide/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Application Developer Guide"
+weight: 14400
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md b/content/en/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md
new file mode 100644
index 000000000..b7dc2f393
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md
@@ -0,0 +1,157 @@
+---
+title: "Helm Developer Guide"
+keywords: 'Kubernetes, KubeSphere, helm, development'
+description: 'Develop your own Helm-based app.'
+linkTitle: "Helm Developer Guide"
+weight: 14410
+---
+
+You can upload the Helm chart of an app to KubeSphere so that tenants with necessary permissions can deploy it. This tutorial demonstrates how to prepare Helm charts using NGINX as an example.
+
+## Install Helm
+
+If you have already installed KubeSphere, then Helm is deployed in your environment. Otherwise, refer to the [Helm documentation](https://helm.sh/docs/intro/install/) to install Helm first.
+
+## Create a Local Repository
+
+Execute the following commands to create a repository on your machine.
+
+```bash
+mkdir helm-repo
+```
+
+```bash
+cd helm-repo
+```
+
+## Create an App
+
+Use `helm create` to create a folder named `nginx`, which automatically creates YAML templates and directories for your app. Generally, it is not recommended to change the name of files and directories in the top level directory.
+
+```bash
+$ helm create nginx
+$ tree nginx/
+nginx/
+├── charts
+├── Chart.yaml
+├── templates
+│ ├── deployment.yaml
+│ ├── _helpers.tpl
+│ ├── ingress.yaml
+│ ├── NOTES.txt
+│ └── service.yaml
+└── values.yaml
+```
+
+`Chart.yaml` is used to define the basic information of the chart, including name, API, and app version. For more information, see [Chart.yaml File](../helm-specification/#chartyaml-file).
+
+An example of the `Chart.yaml` file:
+
+```yaml
+apiVersion: v1
+appVersion: "1.0"
+description: A Helm chart for Kubernetes
+name: nginx
+version: 0.1.0
+```
+
+When you deploy Helm-based apps to Kubernetes, you can edit the `values.yaml` file on the KubeSphere console directly.
+
+An example of the `values.yaml` file:
+
+```yaml
+# Default values for test.
+# This is a YAML-formatted file.
+# Declare variables to be passed into your templates.
+
+replicaCount: 1
+
+image:
+ repository: nginx
+ tag: stable
+ pullPolicy: IfNotPresent
+
+nameOverride: ""
+fullnameOverride: ""
+
+service:
+ type: ClusterIP
+ port: 80
+
+ingress:
+ enabled: false
+ annotations: {}
+ # kubernetes.io/ingress.class: nginx
+ # kubernetes.io/tls-acme: "true"
+ path: /
+ hosts:
+ - chart-example.local
+ tls: []
+ # - secretName: chart-example-tls
+ # hosts:
+ # - chart-example.local
+
+resources: {}
+ # We usually recommend not to specify default resources and to leave this as a conscious
+ # choice for the user. This also increases chances charts run on environments with little
+ # resources, such as Minikube. If you do want to specify resources, uncomment the following
+ # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
+ # limits:
+ # cpu: 100m
+ # memory: 128Mi
+ # requests:
+ # cpu: 100m
+ # memory: 128Mi
+
+nodeSelector: {}
+
+tolerations: []
+
+affinity: {}
+```
+
+Refer to [Helm Specifications](../helm-specification/) to edit files in the `nginx` folder and save them when you finish editing.
+
+## Create an Index File (Optional)
+
+To add a repository with an HTTP or HTTPS URL in KubeSphere, you need to upload an `index.yaml` file to the object storage in advance. Use Helm to create the index file by executing the following command in the previous directory of `nginx`.
+
+```bash
+helm repo index .
+```
+
+```bash
+$ ls
+index.yaml nginx
+```
+
+{{< notice note >}}
+
+- If the repository URL is S3-styled, an index file will be created automatically in the object storage when you add apps to the repository.
+
+- For more information about how to add repositories to KubeSphere, see [Import an Helm Repository](../../../workspace-administration/app-repository/import-helm-repository/).
+
+{{}}
+
+## Package the Chart
+
+Go to the previous directory of `nginx` and execute the following command to package your chart which creates a .tgz package.
+
+```bash
+helm package nginx
+```
+
+```bash
+$ ls
+nginx nginx-0.1.0.tgz
+```
+
+## Upload Your App
+
+Now that you have your Helm-based app ready, you can load it to KubeSphere and test it on the platform.
+
+## See Also
+
+[Helm Specifications](../helm-specification/)
+
+[Import an Helm Repository](../../../workspace-administration/app-repository/import-helm-repository/)
diff --git a/content/en/docs/v3.4/application-store/app-developer-guide/helm-specification.md b/content/en/docs/v3.4/application-store/app-developer-guide/helm-specification.md
new file mode 100644
index 000000000..ab16d028a
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/app-developer-guide/helm-specification.md
@@ -0,0 +1,130 @@
+---
+title: "Helm Specifications"
+keywords: 'Kubernetes, KubeSphere, Helm, specifications'
+description: 'Understand the chart structure and specifications.'
+linkTitle: "Helm Specifications"
+weight: 14420
+---
+
+Helm charts serve as a packaging format. A chart is a collection of files that describe a related set of Kubernetes resources. For more information, see the [Helm documentation](https://helm.sh/docs/topics/charts/).
+
+## Structure
+
+All related files of a chart is stored in a directory which generally contains:
+
+```text
+chartname/
+ Chart.yaml # A YAML file containing basic information about the chart, such as version and name.
+ LICENSE # (Optional) A plain text file containing the license for the chart.
+ README.md # (Optional) The description of the app and how-to guide.
+ values.yaml # The default configuration values for this chart.
+ values.schema.json # (Optional) A JSON Schema for imposing a structure on the values.yaml file.
+ charts/ # A directory containing any charts upon which this chart depends.
+ crds/ # Custom Resource Definitions.
+ templates/ # A directory of templates that will generate valid Kubernetes configuration files with corresponding values provided.
+ templates/NOTES.txt # (Optional) A plain text file with usage notes.
+```
+
+## Chart.yaml File
+
+You must provide the `chart.yaml` file for a chart. Here is an example of the file with explanations for each field.
+
+```yaml
+apiVersion: (Required) The chart API version.
+name: (Required) The name of the chart.
+version: (Required) The version, following the SemVer 2 standard.
+kubeVersion: (Optional) The compatible Kubernetes version, following the SemVer 2 standard.
+description: (Optional) A single-sentence description of the app.
+type: (Optional) The type of the chart.
+keywords:
+ - (Optional) A list of keywords about the app.
+home: (Optional) The URL of the app.
+sources:
+ - (Optional) A list of URLs to source code for this app.
+dependencies: (Optional) A list of the chart requirements.
+ - name: The name of the chart, such as nginx.
+ version: The version of the chart, such as "1.2.3".
+ repository: The repository URL ("https://example.com/charts") or alias ("@repo-name").
+ condition: (Optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (for example, subchart1.enabled ).
+ tags: (Optional)
+ - Tags can be used to group charts for enabling/disabling together.
+ import-values: (Optional)
+ - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
+ alias: (Optional) Alias to be used for the chart. It is useful when you have to add the same chart multiple times.
+maintainers: (Optional)
+ - name: (Required) The maintainer name.
+ email: (Optional) The maintainer email.
+ url: (Optional) A URL for the maintainer.
+icon: (Optional) A URL to an SVG or PNG image to be used as an icon.
+appVersion: (Optional) The app version. This needn't be SemVer.
+deprecated: (Optional, boolean) Whether this chart is deprecated.
+annotations:
+ example: (Optional) A list of annotations keyed by name.
+```
+
+{{< notice note >}}
+
+- The field `dependencies` is used to define chart dependencies which were located in a separate file `requirements.yaml` for `v1` charts. For more information, see [Chart Dependencies](https://helm.sh/docs/topics/charts/#chart-dependencies).
+- The field `type` is used to define the type of chart. Allowed values are `application` and `library`. For more information, see [Chart Types](https://helm.sh/docs/topics/charts/#chart-types).
+
+{{}}
+
+## Values.yaml and Templates
+
+Written in the [Go template language](https://golang.org/pkg/text/template/), Helm chart templates are stored in the `templates` folder of a chart. There are two ways to provide values for the templates:
+
+1. Make a `values.yaml` file inside of a chart with default values that can be referenced.
+2. Make a YAML file that contains necessary values and use the file through the command line with `helm install`.
+
+Here is an example of the template in the `templates` folder.
+
+```yaml
+apiVersion: v1
+kind: ReplicationController
+metadata:
+ name: deis-database
+ namespace: deis
+ labels:
+ app.kubernetes.io/managed-by: deis
+spec:
+ replicas: 1
+ selector:
+ app.kubernetes.io/name: deis-database
+ template:
+ metadata:
+ labels:
+ app.kubernetes.io/name: deis-database
+ spec:
+ serviceAccount: deis-database
+ containers:
+ - name: deis-database
+ image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}
+ imagePullPolicy: {{.Values.pullPolicy}}
+ ports:
+ - containerPort: 5432
+ env:
+ - name: DATABASE_STORAGE
+ value: {{default "minio" .Values.storage}}
+```
+
+The above example defines a ReplicationController template in Kubernetes. There are some values referenced in it which are defined in `values.yaml`.
+
+- `imageRegistry`: The Docker image registry.
+- `dockerTag`: The Docker image tag.
+- `pullPolicy`: The image pulling policy.
+- `storage`: The storage backend. It defaults to `minio`.
+
+An example `values.yaml` file:
+
+```text
+imageRegistry: "quay.io/deis"
+dockerTag: "latest"
+pullPolicy: "Always"
+storage: "s3"
+```
+
+## Reference
+
+[Helm Documentation](https://helm.sh/docs/)
+
+[Charts](https://helm.sh/docs/topics/charts/)
\ No newline at end of file
diff --git a/content/en/docs/v3.4/application-store/app-lifecycle-management.md b/content/en/docs/v3.4/application-store/app-lifecycle-management.md
new file mode 100644
index 000000000..7d2cd0003
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/app-lifecycle-management.md
@@ -0,0 +1,220 @@
+---
+title: "Kubernetes Application Lifecycle Management"
+keywords: 'Kubernetes, KubeSphere, app-store'
+description: 'Manage your app across the entire lifecycle, including submission, review, test, release, upgrade and removal.'
+linkTitle: 'Application Lifecycle Management'
+weight: 14100
+---
+
+KubeSphere integrates [OpenPitrix](https://github.com/openpitrix/openpitrix), an open-source multi-cloud application management platform, to set up the App Store, managing Kubernetes applications throughout their entire lifecycle. The App Store supports two kinds of application deployment:
+
+- **Template-Based Apps** provide a way for developers and independent software vendors (ISVs) to share applications with users in a workspace. You can also import third-party app repositories within a workspace.
+- **Composed Apps** help users quickly build a complete application using multiple microservices to compose it. KubeSphere allows users to select existing services or create new services to create a composed app on the one-stop console.
+
+Using [Redis](https://redis.io/) as an example application, this tutorial demonstrates how to manage the Kubernetes app throughout the entire lifecycle, including submission, review, test, release, upgrade and removal.
+
+## Prerequisites
+
+- You need to enable the [KubeSphere App Store (OpenPitrix)](../../pluggable-components/app-store/).
+- You need to create a workspace, a project and a user (`project-regular`). For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Create a customized role and two users
+
+You need to create two users first, one for ISVs (`isv`) and the other (`reviewer`) for app technical reviewers.
+
+1. Log in to the KubeSphere console with the user `admin`. Click **Platform** in the upper-left corner and select **Access Control**. In **Platform Roles**, click **Create**.
+
+2. Set a name for the role, such as `app-review`, and click **Edit Permissions**.
+
+3. In **App Management**, choose **App Template Management** and **App Template Viewing** in the permission list, and then click **OK**.
+
+ {{< notice note >}}
+
+ The user who is granted the role `app-review` has the permission to view the App Store on the platform and manage apps, including review and removal.
+
+ {{}}
+
+4. As the role is ready now, you need to create a user and grant the role `app-review` to it. In **Users**, click **Create**. Provide the required information and click **OK**.
+
+5. Similarly, create another user `isv`, and grant the role of `platform-regular` to it.
+
+6. Invite both users created above to an existing workspace such as `demo-workspace`, and grant them the role of `workspace-admin`.
+
+### Step 2: Upload and submit an application
+
+1. Log in to KubeSphere as `isv` and go to your workspace. You need to upload the example app Redis to this workspace so that it can be used later. First, download the app [Redis 11.3.4](https://github.com/kubesphere/tutorial/raw/master/tutorial%205%20-%20app-store/redis-11.3.4.tgz) and click **Upload Template** in **App Templates**.
+
+ {{< notice note >}}
+
+ In this example, a new version of Redis will be uploaded later to demonstrate the upgrade feature.
+
+ {{}}
+
+2. In the dialog that appears, click **Upload Helm Chart** to upload the chart file. Click **OK** to continue.
+
+3. Basic information of the app displays under **App Information**. To upload an icon for the app, click **Upload Icon**. You can also skip it and click **OK** directly.
+
+ {{< notice note >}}
+
+ The maximum accepted resolution of the app icon is 96 x 96 pixels.
+
+ {{}}
+
+4. The app displays in the template list with the status **Developing** after it is successfully uploaded, which means this app is under development. The uploaded app is visible to all members in the same workspace.
+
+5. Go to the detail page of the app template by clicking Redis from the list. You can edit the basic information of this app by clicking **Edit**.
+
+6. You can customize the app's basic information by specifying the fields in the pop-up window.
+
+7. Click **OK** to save your changes, then you can test this application by deploying it to Kubernetes. Click the draft version to expand the menu and click **Install**.
+
+ {{< notice note >}}
+
+ If you don't want to test the app, you can submit it for review directly. However, it is recommended that you test your app deployment and function first before you submit it for review, especially in a production environment. This helps you detect any problems in advance and accelerate the review process.
+
+ {{}}
+
+8. Select the cluster and project to which you want to deploy the app, set up different configurations for the app, and then click **Install**.
+
+ {{< notice note >}}
+
+ Some apps can be deployed with all configurations set in a form. You can use the toggle switch to see its YAML file, which contains all parameters you need to specify in the form.
+
+ {{}}
+
+9. Wait for a few minutes, then switch to the tab **App Instances**. You will find that Redis has been deployed successfully.
+
+10. After you test the app with no issues found, you can click **Submit for Release** to submit this application for release.
+
+ {{< notice note >}}
+
+The version number must start with a number and contain decimal points.
+
+{{}}
+
+11. After the app is submitted, the app status will change to **Submitted**. Now app reviewers can release it.
+
+### Step 3: Release the application
+
+1. Log out of KubeSphere and log back in as `app-reviewer`. Click **Platform** in the upper-left corner and select **App Store Management**. On the **App Release** page, the app submitted in the previous step displays under the tab **Unreleased**.
+
+2. To release this app, click it to inspect the app information, introduction, chart file and update logs from the pop-up window.
+
+3. The reviewer needs to decide whether the app meets the release criteria on the App Store. Click **Pass** to approve it or **Reject** to deny an app submission.
+
+### Step 4: Release the application to the App Store
+
+After the app is approved, `isv` can release the Redis application to the App Store, allowing all users on the platform to find and deploy this application.
+
+1. Log out of KubeSphere and log back in as `isv`. Go to your workspace and click Redis on the **Template-Based Apps** page. On its details page, expand the version menu, then click **Release to Store**. In the pop-up prompt, click **OK** to confirm.
+
+2. Under **App Release**, you can see the app status. **Activated** means it is available in the App Store.
+
+3. Click **View in Store** to go to its **Versions** page in the App Store. Alternatively, click **App Store** in the upper-left corner, and you can also see the app.
+
+ {{< notice note >}}
+
+ You may see two Redis apps in the App Store, one of which is a built-in app in KubeSphere. Note that a newly-released app displays at the beginning of the list in the App Store.
+
+ {{}}
+
+4. Now, users in the workspace can install Redis from the App Store. To install the app to Kubernetes, click the app to go to its **App Information** page, and click **Install**.
+
+ {{< notice note >}}
+
+ If you have trouble installing an application and the **Status** column shows **Failed**, you can hover your cursor over the **Failed** icon to see the error message.
+
+ {{}}
+
+### Step 5: Create an application category
+
+`app-reviewer` can create multiple categories for different types of applications based on their function and usage. It is similar to setting tags and categories can be used in the App Store as filters, such as Big Data, Middleware, and IoT.
+
+1. Log in to KubeSphere as `app-reviewer`. To create a category, go to the **App Store Management** page and click 
in **App Categories**.
+
+2. Set a name and icon for the category in the dialog, then click **OK**. For Redis, you can enter `Database` for the field **Name**.
+
+ {{< notice note >}}
+
+ Usually, an app reviewer creates necessary categories in advance and ISVs select the category in which an app appears before submitting it for review. A newly-created category has no app in it.
+
+ {{}}
+
+3. As the category is created, you can assign the category to your app. In **Uncategorized**, select Redis and click **Change Category**.
+
+4. In the dialog, select the category (**Database**) from the drop-down list and click **OK**.
+
+5. The app displays in the category as expected.
+
+### Step 6: Add a new version
+
+To allow workspace users to upgrade apps, you need to add new app versions to KubeSphere first. Follow the steps below to add a new version for the example app.
+
+1. Log in to KubeSphere as `isv` again and navigate to **Template-Based Apps**. Click the app Redis in the list.
+
+2. Download [Redis 12.0.0](https://github.com/kubesphere/tutorial/raw/master/tutorial%205%20-%20app-store/redis-12.0.0.tgz), which is a new version of Redis for demonstration in this tutorial. On the tab **Versions**, click **New Version** on the right to upload the package you just downloaded.
+
+3. Click **Upload Helm Chart** and click **OK** after it is uploaded.
+
+4. The new app version displays in the version list. You can click it to expand the menu and test the new version. Besides, you can also submit it for review and release it to the App Store, which is the same as the steps shown above.
+
+### Step 7: Upgrade an application
+
+After a new version is released to the App Store, all users can upgrade this application to the new version.
+
+{{< notice note >}}
+
+To follow the steps below, you must deploy an app of one of its old versions first. In this example, Redis 11.3.4 was already deployed in the project `demo-project` and its new version 12.0.0 was released to the App Store.
+
+{{}}
+
+1. Log in to KubeSphere as `project-regular`, navigate to the **Apps** page of the project, and click the app to upgrade.
+
+2. Click **More** and select **Edit Settings** from the drop-down list.
+
+3. In the window that appears, you can see the YAML file of application configurations. Select the new version from the drop-down list on the right. You can customize the YAML file of the new version. In this tutorial, click **Update** to use the default configurations directly.
+
+ {{< notice note >}}
+
+ You can select the same version from the drop-down list on the right as that on the left to customize current application configurations through the YAML file.
+
+ {{}}
+
+4. On the **Apps** page, you can see that the app is being upgraded. The status will change to **Running** when the upgrade finishes.
+
+### Step 8: Suspend an application
+
+You can choose to remove an app entirely from the App Store or suspend a specific app version.
+
+1. Log in to KubeSphere as `app-reviewer`. Click **Platform** in the upper-left corner and select **App Store Management**. On the **App Store** page, click Redis.
+
+2. On the detail page, click **Suspend App** and select **OK** in the dialog to confirm the operation to remove the app from the App Store.
+
+ {{< notice note >}}
+
+ Removing an app from the App Store does not affect tenants who are using the app.
+
+ {{}}
+
+3. To make the app available in the App Store again, click **Activate App**.
+
+4. To suspend a specific app version, expand the version menu and click **Suspend Version**. In the dialog that appears, click **OK** to confirm.
+
+ {{< notice note >}}
+
+ After an app version is suspended, this version is not available in the App Store. Suspending an app version does not affect tenants who are using this version.
+
+ {{}}
+
+5. To make the app version available in the App Store again, click **Activate Version**.
+
+
+
+
+
+
+
+
+
diff --git a/content/en/docs/v3.4/application-store/built-in-apps/_index.md b/content/en/docs/v3.4/application-store/built-in-apps/_index.md
new file mode 100644
index 000000000..2ee1bc0ca
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/built-in-apps/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Built-in Applications"
+weight: 14200
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/application-store/built-in-apps/deploy-chaos-mesh.md b/content/en/docs/v3.4/application-store/built-in-apps/deploy-chaos-mesh.md
new file mode 100644
index 000000000..9e10be832
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/built-in-apps/deploy-chaos-mesh.md
@@ -0,0 +1,82 @@
+---
+title: 'Deploy Chaos Mesh on KubeSphere'
+tag: 'KubeSphere, Kubernetes, Applications, Chaos Engineering, Chaos experiments, Chaos Mesh'
+keywords: 'Chaos Mesh, Kubernetes, Helm, KubeSphere'
+description: 'Learn how to deploy Chaos Mesh on KubeSphere and start running chaos experiments.'
+linkTitle: "Deploy Chaos Mesh on KubeSphere"
+---
+
+[Chaos Mesh](https://github.com/chaos-mesh/chaos-mesh) is a cloud-native Chaos Engineering platform that orchestrates chaos in Kubernetes environments. With Chaos Mesh, you can test your system's resilience and robustness on Kubernetes by injecting various types of faults into Pods, network, file system, and even the kernel.
+
+
+
+## Enable App Store on KubeSphere
+
+1. Make sure you have installed and enabled the [KubeSphere App Store](../../../pluggable-components/app-store/).
+
+2. You need to create a workspace, a project, and a user account (project-regular) for this tutorial. The account needs to be a platform regular user and to be invited as the project operator with the operator role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Chaos experiments with Chaos Mesh
+
+### Step 1: Deploy Chaos Mesh
+
+1. Login KubeSphere as `project-regular`, search for **chaos-mesh** in the **App Store**, and click on the search result to enter the app.
+
+ 
+
+2. In the **App Information** page, click **Install** on the upper right corner.
+
+ 
+
+3. In the **App Settings** page, set the application **Name,** **Location** (as your Namespace), and **App Version**, and then click **Next** on the upper right corner.
+
+ 
+
+4. Configure the `values.yaml` file as needed, or click **Install** to use the default configuration.
+
+ 
+
+5. Wait for the deployment to be finished. Upon completion, Chaos Mesh will be shown as **Running** in KubeSphere.
+
+ 
+
+
+### Step 2: Visit Chaos Dashboard
+
+1. In the **Resource Status** page, copy the **NodePort **of `chaos-dashboard`.
+
+ 
+
+2. Access the Chaos Dashboard by entering `${NodeIP}:${NODEPORT}` in your browser. Refer to [Manage User Permissions](https://chaos-mesh.org/docs/manage-user-permissions/) to generate a Token and log into Chaos Dashboard.
+
+ 
+
+### Step 3: Create a chaos experiment
+
+Before creating a chaos experiment, you should identify and deploy your experiment target, for example, to test how an application works under network latency. Here, we use a demo application `web-show` as the target application to be tested, and the test goal is to observe the system network latency. You can deploy a demo application `web-show` with the following command: `web-show`.
+
+```bash
+curl -sSL https://mirrors.chaos-mesh.org/latest/web-show/deploy.sh | bash
+```
+
+> Note: The network latency of the Pod can be observed directly from the web-show application pad to the kube-system pod.
+
+1. From your web browser, visit ${NodeIP}:8081 to access the **Web Show** application.
+
+ 
+
+2. Log in to Chaos Dashboard to create a chaos experiment. To observe the effect of network latency on the application, we set the **Target **as "Network Attack" to simulate a network delay scenario.
+
+ 
+
+ The **Scope** of the experiment is set to `app: web-show`.
+
+ 
+
+3. Start the chaos experiment by submitting it.
+
+ 
+
+Now, you should be able to visit **Web Show** to observe experiment results:
+
+
\ No newline at end of file
diff --git a/content/en/docs/v3.4/application-store/built-in-apps/etcd-app.md b/content/en/docs/v3.4/application-store/built-in-apps/etcd-app.md
new file mode 100644
index 000000000..f34455ffa
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/built-in-apps/etcd-app.md
@@ -0,0 +1,58 @@
+---
+title: "Deploy etcd on KubeSphere"
+keywords: 'Kubernetes, KubeSphere, etcd, app-store'
+description: 'Learn how to deploy etcd from the App Store of KubeSphere and access its service.'
+linkTitle: "Deploy etcd on KubeSphere"
+weight: 14210
+---
+
+Written in Go, [etcd](https://etcd.io/) is a distributed key-value store to store data that needs to be accessed by a distributed system or cluster of machines. In Kubernetes, it is the backend for service discovery and stores cluster states and configurations.
+
+This tutorial walks you through an example of deploying etcd from the App Store of KubeSphere.
+
+## Prerequisites
+
+- Please make sure you [enable the OpenPitrix system](../../../pluggable-components/app-store/).
+- You need to create a workspace, a project, and a user account (`project-regular`) for this tutorial. The account needs to be a platform regular user and to be invited as the project operator with the `operator` role. In this tutorial, you log in as `project-regular` and work in the project `demo-project` in the workspace `demo-workspace`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Deploy etcd from the App Store
+
+1. On the **Overview** page of the project `demo-project`, click **App Store** in the upper-left corner.
+
+2. Find etcd and click **Install** on the **App Information** page.
+
+3. Set a name and select an app version. Make sure etcd is deployed in `demo-project` and click **Next**.
+
+4. On the **App Settings** page, specify the size of the persistent volume for etcd and click **Install**.
+
+ {{< notice note >}}
+
+ To specify more values for etcd, use the toggle switch to see the app's manifest in YAML format and edit its configurations.
+
+ {{}}
+
+5. In **Template-Based Apps** of the **Apps** page, wait until etcd is up and running.
+
+### Step 2: Access the etcd service
+
+After the app is deployed, you can use etcdctl, a command-line tool for interacting with the etcd server, to access etcd on the KubeSphere console directly.
+
+1. Navigate to **StatefulSets** in **Workloads**, and click the service name of etcd.
+
+2. Under **Pods**, expand the menu to see container details, and then click the **Terminal** icon.
+
+3. In the terminal, you can read and write data directly. For example, execute the following two commands respectively.
+
+ ```bash
+ etcdctl set /name kubesphere
+ ```
+
+ ```bash
+ etcdctl get /name
+ ```
+
+4. For clients within the KubeSphere cluster, the etcd service can be accessed through `
in the upper-right corner to view the password. Make sure you copy it.
+
+### Step 4: Edit the hosts file
+
+1. Find the `hosts` file on your local machine.
+
+ {{< notice note >}}
+
+ The path of the `hosts` file is `/etc/hosts` for Linux, or `c:\windows\system32\drivers\etc\hosts` for Windows.
+
+ {{}}
+
+2. Add the following item into the `hosts` file.
+
+ ```
+ 192.168.4.3 gitlab.demo-project.svc.cluster.local
+ ```
+
+ {{< notice note >}}
+
+ - `192.168.4.3` and `demo-project` refer to the NodeIP and project name respectively where GitLab is deployed. Make sure you use your own NodeIP and project name.
+ - You can use any IP address of the nodes in your Kubernetes cluster.
+
+ {{}}
+
+### Step 5: Access GitLab
+
+1. Go to **Services** under **Application Workloads**, enter `nginx-ingress-controller` in the search box, and then press **Enter** on your keyboard to search the Service. You can see the Service has been exposed through port `31246`, which you can use to access GitLab.
+
+ {{< notice note >}}
+
+ The port number shown on your console may be different. Make sure you use your own port number.
+
+ {{}}
+
+2. Access GitLab through `http://gitlab.demo-project.svc.cluster.local:31246` using the root account and its initial password (`root/ojPWrWECLWN0XFJkGs7aAqtitGMJlVfS0fLEDE03P9S0ji34XDoWmxs2MzgZRRWF`).
+
+ 
+
+ 
+
+ {{< notice note >}}
+
+ You may need to open the port in your security groups and configure related port forwarding rules depending on where your Kubernetes cluster is deployed.
+
+ {{}}
diff --git a/content/en/docs/v3.4/application-store/external-apps/deploy-litmus.md b/content/en/docs/v3.4/application-store/external-apps/deploy-litmus.md
new file mode 100644
index 000000000..bd0b69c3c
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/external-apps/deploy-litmus.md
@@ -0,0 +1,140 @@
+---
+title: 'Deploy Litmus on KubeSphere'
+tag: 'KubeSphere, Kubernetes, Applications, Chaos engineering, Chaos experiments, Litmus'
+keywords: 'Litmus,LitmusChaos,Kubernetes,Helm,KubeSphere'
+description: 'Learn how to deploy Litmus on KubeSphere and create chaos experiments.'
+linkTitle: "Deploy Litmus on KubeSphere"
+Weight: 14350
+---
+
+[Litmus](https://litmuschaos.io/) is an open-source, cloud-native chaos engineering toolkit that focuses on simulating failure tests on Kubernetes clusters. It helps developers and SREs find vulnerabilities in clusters and programs, therefore improving the robustness of the system.
+
+The Litmus architecture is as follows. For details about the Litmus architecture, see [Litmus Docs](https://litmusdocs-beta.netlify.app/docs/architecture/).
+
+
+
+This tutorial demonstrates how to deploy Litmus on KubeSphere and create chaos experiments.
+
+## Prerequisites
+- You need to enable the [KubeSphere App Store (OpenPitrix)](https://v3-1.docs.kubesphere.io/docs/pluggable-components/app-store/).
+- You need to create a workspace, a project, and two accounts (`ws-admin` and `project-regular`). For more information, see [Create Workspaces, Projects, Accounts, and Roles](https://v3-1.docs.kubesphere.io/docs/quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Add an app repository
+1. In your workspace, go to **App Repositories** under **App Management**, and then click **Add**.
+
+2. In the dialog that appears, set a name for the repository (for example, `litmus`) and enter the URL `https://litmuschaos.github.io/litmus-helm/`. Click **Validate** to verify the URL. Click **OK** to continue.
+
+3. The app repository displays in the list after it is successfully imported.
+
+### Step 2: Deploy the Litmus portal
+1. Log out of the KubeSphere console and log back in as `project-regular`. In your project, go to **Apps** under **Application Workloads**, and then click **Create**.
+
+2. In the dialog that appears, choose **From App Template**.
+
+ - **From App Store**: Select apps from the official APP Store of Kubephere.
+
+ - **From App Template**: Select apps from workspace app templates and the third-party Helm app templates of App Repository.
+
+3. In the drop-down list, choose `litmus`, and then choose `litmus-2-0-0-beta`.
+
+4. You can view the app information and chart files. Under **Versions**, select a specific version and click **Install**.
+
+5. Under **Basic Information**, set a name for the app. Check the app version and the deployment location, and then click **Next**.
+
+6. Under **App Settings**, you can edit the yaml file or directly click **Install**.
+
+7. The app displays in the list after you create it successfully.
+
+ {{< notice note>}}
+
+ It may take a while before Litmus is running. Please wait for the deployment to finish.
+
+ {{}}
+
+### Step 3: Access Litmus portal
+
+1. Go to **Services** under **Application Workloads**, copy the `NodePort` of `litmusportal-frontend-service`.
+
+2. You can access Litmus `Portal` through `${NodeIP}:${NODEPORT}` using the default username and password (`admin`/`litmus`).
+
+ 
+
+ 
+
+ {{< notice note >}}
+ You may need to open the port in your security groups and configure port forwarding rules depending on where your Kubernetes cluster is deployed. Make sure you use your own `NodeIP`.
+ {{}}
+
+### Step 4: Deploy Agent (optional)
+
+The Litmus `Agent` can be classified into `Self-Agent` and `External-Agent`. By default, the cluster where Litmus is installed is automatically registered as `Self-Agent`, and `Portal` defaults to run chaos experiments in `Self-Agent`.
+
+
+
+For details about how to deploy External Agent, see [Litmus Docs](https://litmusdocs-beta.netlify.app/docs/agent-install).
+
+### Step 5: Create chaos experiments
+
+- **Experiment 1**
+
+1. You need to create a test application on your cluster. For example, you can deploy `nginx` using the following command:
+
+ ```bash
+ $ kubectl create deployment nginx --image=nginx --replicas=2 --namespace=default
+ ```
+
+2. Log in to Litmus `Portal`, and then click **Schedule workflow**.
+
+3. Choose an `Agent` (for example, `Self-Agent`), and then click **Next**.
+
+4. Choose **Create a new workflow using the experiments from MyHub**. In the drop-down list, select **Chaos Hub**, and then click **Next**.
+
+5. Set a name for the workflow (for example, `pod-delete`). You can also add a description for the workflow. Click **Next**.
+
+6. Click **Add a new experiment** to add a chaos experiment to the workflow. Click **Next**.
+
+7. Select an experiment (for example, `generic/pod-delete`), and then click **Done**.
+
+8. Select a point to adjust the weight of the experiment in the workflow. Click **Next**.
+
+9. Choose **Schedule now**, and then click **Next**.
+
+10. Verify the workflow, and then click **Finish**.
+
+ On the KubeSphere console, you can see that a Pod is being deleted and recreated.
+
+ On the Litmus `Portal`, you can see that the experiment is successful.
+
+ 
+
+ You can click a specific workflow node to view its detailed logs.
+
+ 
+
+
+- **Experiment 2**
+
+1. Perform steps 1 to 10 in **Experiment 1** to create a new chaos experiment (`pod-cpu-hog`).
+ 
+
+2. On the KubeSphere console, you can see that the pod CPU usage is close to 1 core.
+
+- **Experiment 3**
+
+1. Set the `nginx` replica to `1`. You can see there is only one pod left and view the Pod IP address.
+
+2. Perform steps 1 to 10 in **Experiment 1** to create a new chaos experiment (`pod-network-loss`).
+
+ 
+
+ You can ping the Pod IP address to test the packet loss rate.
+
+ 
+
+ {{< notice note >}}
+
+ The preceding experiments are conducted on Pods. You can also experiment on nodes and other Kubernetes components. For details about the chaos experiments, see [Litmus ChaosHub](https://hub.litmuschaos.io/).
+
+ {{}}
diff --git a/content/en/docs/v3.4/application-store/external-apps/deploy-metersphere.md b/content/en/docs/v3.4/application-store/external-apps/deploy-metersphere.md
new file mode 100644
index 000000000..1c5385df0
--- /dev/null
+++ b/content/en/docs/v3.4/application-store/external-apps/deploy-metersphere.md
@@ -0,0 +1,64 @@
+---
+title: "Deploy MeterSphere on KubeSphere"
+keywords: 'KubeSphere, Kubernetes, Applications, MeterSphere'
+description: 'Learn how to deploy MeterSphere on KubeSphere.'
+linkTitle: "Deploy MeterSphere on KubeSphere"
+weight: 14330
+---
+
+MeterSphere is an open-source, one-stop, and enterprise-level continuous testing platform. It features test tracking, interface testing, and performance testing.
+
+This tutorial demonstrates how to deploy MeterSphere on KubeSphere.
+
+## Prerequisites
+
+- You need to enable [the OpenPitrix system](../../../pluggable-components/app-store/).
+- You need to create a workspace, a project, and two user accounts (`ws-admin` and `project-regular`) for this tutorial. The account `ws-admin` must be granted the role of `workspace-admin` in the workspace, and the account `project-regular` must be invited to the project with the role of `operator`. If they are not ready, refer to [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Add an app repository
+
+1. Log in to KubeSphere as `ws-admin`. In your workspace, go to **App Repositories** under **App Management**, and then click **Add**.
+
+2. In the dialog that appears, enter `metersphere` for the app repository name and `https://charts.kubesphere.io/test` for the MeterSphere repository URL. Click **Validate** to verify the URL and you will see a green check mark next to the URL if it is available. Click **OK** to continue.
+
+3. Your repository displays in the list after it is successfully imported to KubeSphere.
+
+### Step 2: Deploy MeterSphere
+
+1. Log out of KubeSphere and log back in as `project-regular`. In your project, go to **Apps** under **Application Workloads** and click **Create**.
+
+2. In the dialog that appears, select **From App Template**.
+
+3. Select `metersphere` from the drop-down list, then click **metersphere-chart**.
+
+4. On the **App Information** tab and the **Chart Files** tab, you can view the default configuration from the console. Click **Install** to continue.
+
+5. On the **Basic Information** page, you can view the app name, app version, and deployment location. Click **Next** to continue.
+
+6. On the **App Settings** page, change the value of `imageTag` from `master` to `v1.6`, and then click **Install**.
+
+7. Wait for MeterSphere to be up and running.
+
+8. Go to **Workloads**, and you can see two Deployments and three StatefulSets created for MeterSphere.
+
+ {{< notice note >}}
+
+ It may take a while before all the Deployments and StatefulSets are up and running.
+
+ {{}}
+
+### Step 3: Access MeterSphere
+
+1. Go to **Services** under **Application Workloads**, and you can see the MeterSphere Service and its type is set to `NodePort` by default.
+
+2. You can access MeterSphere through `
or 
to scale up or scale down the number of replicas.
+7. Click the **Metadata** tab to view annotations of the cluster gateway.
+
+## View Project Gateways
+
+On the **Gateway Settings** page, click the **Project Gateway** tab to view project gateways.
+
+Click 
on the right of a project gateway to select an operation from the drop-down menu:
+
+- **Edit**: Edit configurations of the project gateway.
+- **Disable**: Disable the project gateway.
+
+{{< notice note >}}
+
+If a project gateway exists prior to the creation of a cluster gateway, the project gateway address may switch between the address of the cluster gateway and that of the project gateway. It is recommended that you should use either the cluster gateway or project gateway.
+
+{{}}
+
+For more information about how to create project gateways, see [Project Gateway](../../../project-administration/project-gateway/).
\ No newline at end of file
diff --git a/content/en/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md b/content/en/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md
new file mode 100644
index 000000000..e95527e5b
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md
@@ -0,0 +1,53 @@
+---
+title: "Cluster Visibility and Authorization"
+keywords: "Cluster Visibility, Cluster Management"
+description: "Learn how to set up cluster visibility and authorization."
+linkTitle: "Cluster Visibility and Authorization"
+weight: 8610
+---
+
+In KubeSphere, you can allocate a cluster to multiple workspaces through authorization so that workspace resources can all run on the cluster. At the same time, a workspace can also be associated with multiple clusters. Workspace users with necessary permissions can create multi-cluster projects using clusters allocated to the workspace.
+
+This guide demonstrates how to set cluster visibility.
+
+## Prerequisites
+* You need to enable the [multi-cluster feature](../../../multicluster-management/).
+* You need to have a workspace and a user that has the permission to create workspaces, such as `ws-manager`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Set Cluster Visibility
+
+### Select available clusters when you create a workspace
+
+1. Log in to KubeSphere with a user that has the permission to create a workspace, such as `ws-manager`.
+
+2. Click **Platform** in the upper-left corner and select **Access Control**. In **Workspaces** from the navigation bar, click **Create**.
+
+3. Provide the basic information for the workspace and click **Next**.
+
+4. On the **Cluster Settings** page, you can see a list of available clusters. Select the clusters that you want to allocate to the workspace and click **Create**.
+
+5. After the workspace is created, workspace members with necessary permissions can create resources that run on the associated cluster.
+
+ {{< notice warning >}}
+
+Try not to create resources on the host cluster to avoid excessive loads, which can lead to a decrease in the stability across clusters.
+
+{{}}
+
+### Set cluster visibility after a workspace is created
+
+After a workspace is created, you can allocate additional clusters to the workspace through authorization or unbind a cluster from the workspace. Follow the steps below to adjust the visibility of a cluster.
+
+1. Log in to KubeSphere with a user that has the permission to manage clusters, such as `admin`.
+
+2. Click **Platform** in the upper-left corner and select **Cluster Management**. Select a cluster from the list to view cluster information.
+
+3. In **Cluster Settings** from the navigation bar, select **Cluster Visibility**.
+
+4. You can see the list of authorized workspaces, which means the current cluster is available to resources in all these workspaces.
+
+5. Click **Edit Visibility** to set the cluster visibility. You can select new workspaces that will be able to use the cluster or unbind it from a workspace.
+
+### Make a cluster public
+
+You can check **Set as Public Cluster** so that platform users can access the cluster, in which they are able to create and schedule resources.
diff --git a/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md
new file mode 100644
index 000000000..275de2bb0
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Log Receivers"
+weight: 8620
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md
new file mode 100644
index 000000000..1b43c5c85
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md
@@ -0,0 +1,35 @@
+---
+title: "Add Elasticsearch as a Receiver"
+keywords: 'Kubernetes, log, elasticsearch, pod, container, fluentbit, output'
+description: 'Learn how to add Elasticsearch to receive container logs, resource events, or audit logs.'
+linkTitle: "Add Elasticsearch as a Receiver"
+weight: 8622
+---
+You can use Elasticsearch, Kafka, and Fluentd as log receivers in KubeSphere. This tutorial demonstrates how to add an Elasticsearch receiver.
+
+## Prerequisites
+
+- You need a user granted a role including the permission of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the permission and assign it to a user.
+
+- Before adding a log receiver, you need to enable any of the `logging`, `events` or `auditing` components. For more information, see [Enable Pluggable Components](../../../../pluggable-components/). `logging` is enabled as an example in this tutorial.
+
+## Add Elasticsearch as a Receiver
+
+1. Log in to KubeSphere as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+ {{< notice note >}}
+
+If you have enabled the [multi-cluster feature](../../../../multicluster-management/), you can select a specific cluster.
+
+{{}}
+
+2. On the navigation pane on the left, click **Cluster Settings** > **Log Receivers**.
+
+3. Click **Add Log Receiver** and choose **Elasticsearch**.
+
+4. Provide the Elasticsearch service address and port number.
+
+5. Elasticsearch will appear in the receiver list on the **Log Receivers** page, the status of which is **Collecting**.
+
+6. To verify whether Elasticsearch is receiving logs sent from Fluent Bit, click **Log Search** in the **Toolbox** in the lower-right corner and search logs on the console. For more information, read [Log Query](../../../../toolbox/log-query/).
+
diff --git a/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md
new file mode 100644
index 000000000..b674da974
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md
@@ -0,0 +1,154 @@
+---
+title: "Add Fluentd as a Receiver"
+keywords: 'Kubernetes, log, fluentd, pod, container, fluentbit, output'
+description: 'Learn how to add Fluentd to receive logs, events or audit logs.'
+linkTitle: "Add Fluentd as a Receiver"
+weight: 8624
+---
+You can use Elasticsearch, Kafka and Fluentd as log receivers in KubeSphere. This tutorial demonstrates:
+
+- How to deploy Fluentd as a Deployment and create the corresponding Service and ConfigMap.
+- How to add Fluentd as a log receiver to receive logs sent from Fluent Bit and then output to stdout.
+- How to verify if Fluentd receives logs successfully.
+
+## Prerequisites
+
+- You need a user granted a role including the permission of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the permission and assign it to a user.
+
+- Before adding a log receiver, you need to enable any of the `logging`, `events`, or `auditing` components. For more information, see [Enable Pluggable Components](../../../../pluggable-components/). `logging` is enabled as an example in this tutorial.
+
+## Step 1: Deploy Fluentd as a Deployment
+
+Usually, Fluentd is deployed as a DaemonSet in Kubernetes to collect container logs on each node. KubeSphere chooses Fluent Bit because of its low memory footprint. Besides, Fluentd features numerous output plugins. Hence, KubeSphere chooses to deploy Fluentd as a Deployment to forward logs it receives from Fluent Bit to more destinations such as S3, MongoDB, Cassandra, MySQL, syslog and Splunk.
+
+Run the following commands:
+
+{{< notice note >}}
+
+- The following commands create the Fluentd Deployment, Service, and ConfigMap in the `default` namespace and add a filter to the Fluentd ConfigMap to exclude logs from the `default` namespace to avoid Fluent Bit and Fluentd loop log collections.
+- Change the namespace if you want to deploy Fluentd into a different namespace.
+
+{{}}
+
+```yaml
+cat <- **Leader changes in 1 h** refers to the number of Leader changes seen by members of the cluster in 1 hour. Frequent Leader changes will significantly affect the performance of etcd. It also shows that the Leader is unstable, possibly due to network connection issues or excessive loads hitting the etcd cluster. | +|DB Size | The size of the underlying database (in MiB) of etcd. The current graph shows the average size of each member database of etcd. | +|Client Traffic|It includes the total traffic sent to the gRPC client and the total traffic received from the gRPC client. For more information about the indicator, see [etcd Network](https://github.com/etcd-io/etcd/blob/v3.2.17/Documentation/metrics.md#network). | +|gRPC Stream Message|The gRPC streaming message receiving rate and sending rate on the server side, which reflects whether large-scale data read and write operations are happening in the cluster. For more information about the indicator, see [go-grpc-prometheus](https://github.com/grpc-ecosystem/go-grpc-prometheus#counters).| +|WAL Fsync|The latency of WAL calling fsync. A `wal_fsync` is called when etcd persists its log entries to disk before applying them. For more information about the indicator, see [etcd Disk](https://etcd.io/docs/v3.3.12/metrics/#grpc-requests). | +|DB Fsync|The submission delay distribution of the backend calls. When etcd submits its most recent incremental snapshot to disk, a `backend_commit` will be called. Note that high latency of disk operations (long WAL log synchronization time or library synchronization time) usually indicates disk problems, which may cause high request latency or make the cluster unstable. For more information about the indicator, see [etcd Disk](https://etcd.io/docs/v3.3.12/metrics/#grpc-requests). | +|Raft Proposal|- **Proposal Commit Rate** records the rate of consensus proposals committed. If the cluster is healthy, this indicator should increase over time. Several healthy members of an etcd cluster may have different general proposals at the same time. A continuous large lag between a single member and its leader indicates that the member is slow or unhealthy.
- **Proposal Apply Rate** records the total rate of consensus proposals applied. The etcd server applies each committed proposal asynchronously. The difference between the **Proposal Commit Rate** and the **Proposal Apply Rate** should usually be small (only a few thousands even under high loads). If the difference between them continues to rise, it indicates that the etcd server is overloaded. This can happen when using large-scale queries such as heavy range queries or large txn operations.
- **Proposal Failure Rate** records the total rate of failed proposals, usually related to two issues: temporary failures related to leader election or longer downtime due to a loss of quorum in the cluster.
- **Proposal Pending Total** records the current number of pending proposals. An increase in pending proposals indicates high client loads or members unable to submit proposals.
Currently, the data displayed on the dashboard is the average size of etcd members. For more information about these indicators, see [etcd Server](https://etcd.io/docs/v3.3.12/metrics/#server). | + +## API Server Monitoring + +[API Server](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) is the hub for the interaction of all components in a Kubernetes cluster. The following table lists the main indicators monitored for the API Server. + +|Indicators|Description| +|---|---| +|Request Latency|Classified by HTTP request methods, the latency of resource request response in milliseconds.| +|Request per Second|The number of requests accepted by kube-apiserver per second.| + +## Scheduler Monitoring + +[Scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) monitors the Kubernetes API of newly created pods and determines which nodes these new pods run on. It makes this decision based on available data, including the availability of collected resources and the resource requirements of the Pod. Monitoring data for scheduling delays ensures that you can see any delays facing the scheduler. + +|Indicators|Description| +|---|---| +|Attempt Frequency|Include the number of scheduling successes, errors, and failures.| +|Attempt Rate|Include the scheduling rate of successes, errors, and failures.| +|Scheduling latency|End-to-end scheduling delay, which is the sum of scheduling algorithm delay and binding delay| + +## Resource Usage Ranking + +You can sort nodes in ascending and descending order by indicators such as CPU usage, average CPU load, memory usage, disk usage, inode usage, and Pod usage. This enables administrators to quickly find potential problems or identify a node's insufficient resources. diff --git a/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md new file mode 100644 index 000000000..2c511afda --- /dev/null +++ b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md @@ -0,0 +1,7 @@ +--- +linkTitle: "Cluster-wide Alerting and Notification" +weight: 8500 + +_build: + render: false +--- diff --git a/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md new file mode 100644 index 000000000..fe59103b8 --- /dev/null +++ b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md @@ -0,0 +1,28 @@ +--- +title: "Alerting Messages (Node Level)" +keywords: 'KubeSphere, Kubernetes, node, Alerting, messages' +description: 'Learn how to view alerting messages for nodes.' +linkTitle: "Alerting Messages (Node Level)" +weight: 8540 +--- + +Alerting messages record detailed information of alerts triggered based on the alerting policy defined. This tutorial demonstrates how to view alerting messages at the node level. + +## Prerequisites + +- You have enabled [KubeSphere Alerting](../../../pluggable-components/alerting/). +- You need to create a user (`cluster-admin`) and grant it the `clusters-admin` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/#step-4-create-a-role). +- You have created a node-level alerting policy and an alert has been triggered. For more information, refer to [Alerting Policies (Node Level)](../alerting-policy/). + +## View Alerting Messages + +1. Log in to the KubeSphere console as `cluster-admin` and go to **Alerting Messages** under **Monitoring & Alerting**. + +2. On the **Alerting Messages** page, you can see all alerting messages in the list. The first column displays the summary and details you have defined for the alert. To view details of an alerting message, click the name of the alerting policy and then click the **Alerting History** tab on the alerting policy details page. + +3. On the **Alerting History** tab, you can see alert severity, monitoring target, and activation time. + +## View Notifications + +If you also want to receive alert notifications (for example, email and Slack messages), you need to configure [a notification channel](../../../cluster-administration/platform-settings/notification-management/configure-email/) first. + diff --git a/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md new file mode 100644 index 000000000..33d379370 --- /dev/null +++ b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md @@ -0,0 +1,69 @@ +--- +title: "Alerting Policies (Node Level)" +keywords: 'KubeSphere, Kubernetes, Node, Alerting, Policy, Notification' +description: 'Learn how to set alerting policies for nodes.' +linkTitle: "Alerting Policies (Node Level)" +weight: 8530 +--- + +KubeSphere provides alerting policies for nodes and workloads. This tutorial demonstrates how to create alerting policies for nodes in a cluster. See [Alerting Policy (Workload Level)](../../../project-user-guide/alerting/alerting-policy/) to learn how to configure alerting policies for workloads. + +KubeSphere also has built-in policies which will trigger alerts if conditions defined for these policies are met. On the **Built-in Policies** tab, you can click a policy to see its details. Note that they cannot be directly deleted or edited on the console. + +## Prerequisites + +- You have enabled [KubeSphere Alerting](../../../pluggable-components/alerting/). +- To receive alert notifications, you must configure a [notification channel](../../../cluster-administration/platform-settings/notification-management/configure-email/) beforehand. +- You need to create a user (`cluster-admin`) and grant it the `clusters-admin` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/#step-4-create-a-role). +- You have workloads in your cluster. If they are not ready, see [Deploy and Access Bookinfo](../../../quick-start/deploy-bookinfo-to-k8s/) to create a sample app. + +## Create an Alerting Policy + +1. Log in to the console as `cluster-admin`. Click **Platform** in the upper-left corner, and then click **Cluster Management**. + +2. Go to **Alerting Policies** under **Monitoring & Alerting**, and then click **Create**. + +3. In the displayed dialog box, provide the basic information as follows. Click **Next** to continue. + + - **Name**. A concise and clear name as its unique identifier, such as `node-alert`. + - **Alias**. Help you distinguish alerting policies better. + - **Threshold Duration (min)**. The status of the alerting policy becomes Firing when the duration of the condition configured in the alerting rule reaches the threshold. + - **Severity**. Allowed values include **Warning**, **Error** and **Critical**, providing an indication of how serious an alert is. + - **Description**. A brief introduction to the alerting policy. + +4. On the **Rule Settings** tab, you can use the rule template or create a custom rule. To use the template, set the following parameters and click **Next** to continue. + + - **Monitoring Targets**. Select at lease a node in your cluster for monitoring. + - **Alerting Rule**. Define a rule for the alerting policy. The rules provided in the drop-down list are based on Prometheus expressions and an alert will be triggered when conditions are met. You can monitor objects such as CPU, and memory. + + {{< notice note >}} + + You can create a custom rule with PromQL by entering an expression in the **Monitoring Metrics** field (autocompletion supported). For more information, see [Querying Prometheus](https://prometheus.io/docs/prometheus/latest/querying/basics/). + + {{}} + +5. On the **Message Settings** tab, enter the summary and details of the alerting message, then click **Create**. + +6. An alerting policy will be **Inactive** when just created. If conditions in the rule expression are met, it will reach **Pending** first, and then turn to **Firing** if conditions keep to be met in the given time range. + +## Edit an Alerting Policy + +To edit an alerting policy after it is created, on the **Alerting Policies** page, click
on the right of the alerting policy.
+
+1. Click **Edit** from the drop-down list and edit the alerting policy following the same steps as you create it. Click **OK** on the **Message Settings** page to save it.
+
+2. Click **Delete** from the drop-down list to delete an alerting policy.
+
+## View an Alerting Policy
+
+Click the name of an alerting policy on the **Alerting Policies** page to see its detail information, including the alerting rule and alerting history. You can also see the rule expression which is based on the template you use when creating the alerting policy.
+
+Under **Monitoring**, the **Alert Monitoring** chart shows the actual usage or amount of resources over time. **Alerting Message** displays the customized message you set in notifications.
+
+{{< notice note >}}
+
+You can click 
in the upper-right corner to select or custom a time range for the alert monitoring chart.
+
+You can also click 
in the upper-right corner to manually refresh the alert monitoring chart.
+
+{{}}
diff --git a/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md
new file mode 100644
index 000000000..58e624f3c
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md
@@ -0,0 +1,37 @@
+---
+title: "Manage Alerts with Alertmanager in KubeSphere"
+keywords: 'Kubernetes, Prometheus, Alertmanager, alerting'
+description: 'Learn how to manage alerts with Alertmanager in KubeSphere.'
+linkTitle: "Alertmanager in KubeSphere"
+weight: 8510
+---
+
+Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts. For more details, refer to the [Alertmanager guide](https://prometheus.io/docs/alerting/latest/alertmanager/).
+
+KubeSphere has been using Prometheus as its monitoring service's backend from the first release. Starting from v3.0, KubeSphere adds Alertmanager to its monitoring stack to manage alerts sent from Prometheus as well as other components such as [kube-events](https://github.com/kubesphere/kube-events) and kube-auditing.
+
+
+
+## Use Alertmanager to Manage Prometheus Alerts
+
+Alerting with Prometheus is separated into two parts. Alerting rules in Prometheus servers send alerts to an Alertmanager. The Alertmanager then manages those alerts, including silencing, inhibition, aggregation and sending out notifications via methods such as emails, on-call notification systems, and chat platforms.
+
+Starting from v3.0, KubeSphere adds popular alert rules in the open source community to its Prometheus offering as built-in alert rules. And by default Prometheus in KubeSphere v3.0 evaluates these built-in alert rules continuously and then sends alerts to Alertmanager.
+
+## Use Alertmanager to Manage Kubernetes Event Alerts
+
+Alertmanager can be used to manage alerts sent from sources other than Prometheus. In KubeSphere v3.0 and above, users can use it to manage alerts triggered by Kubernetes events. For more details, refer to [kube-events](https://github.com/kubesphere/kube-events).
+
+## Use Alertmanager to Manage KubeSphere Auditing Alerts
+
+In KubeSphere v3.0 and above, users can also use Alertmanager to manage alerts triggered by Kubernetes/KubeSphere auditing events.
+
+## Receive Notifications for Alertmanager Alerts
+
+Generally, to receive notifications for Alertmanager alerts, users have to edit Alertmanager's configuration files manually to configure receiver settings such as Email and Slack.
+
+This is not convenient for Kubernetes users and it breaks the multi-tenant principle/architecture of KubeSphere. More specifically, alerts triggered by workloads in different namespaces, which should have been sent to different tenants, might be sent to the same tenant.
+
+To use Alertmanager to manage alerts on the platform, KubeSphere offers [Notification Manager](https://github.com/kubesphere/notification-manager), a Kubernetes native notification management tool, which is completely open source. It complies with the multi-tenancy principle, providing user-friendly experiences of Kubernetes notifications. It's installed by default in KubeSphere v3.0 and above.
+
+For more details about using Notification Manager to receive Alertmanager notifications, refer to [Notification Manager](https://github.com/kubesphere/notification-manager).
\ No newline at end of file
diff --git a/content/en/docs/v3.4/cluster-administration/nodes.md b/content/en/docs/v3.4/cluster-administration/nodes.md
new file mode 100644
index 000000000..19437c55e
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/nodes.md
@@ -0,0 +1,62 @@
+---
+title: "Node Management"
+keywords: "Kubernetes, KubeSphere, taints, nodes, labels, requests, limits"
+description: "Monitor node status and learn how to add node labels or taints."
+
+linkTitle: "Node Management"
+weight: 8100
+---
+
+Kubernetes runs your workloads by placing containers into Pods to run on nodes. A node may be a virtual or physical machine, depending on the cluster. Each node contains the services necessary to run Pods, managed by the control plane. For more information about nodes, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/architecture/nodes/).
+
+This tutorial demonstrates what a cluster administrator can view and do for nodes within a cluster.
+
+## Prerequisites
+
+You need a user granted a role including the authorization of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the authorization and assign it to a user.
+
+## Node Status
+
+Cluster nodes are only accessible to cluster administrators. Some node metrics are very important to clusters. Therefore, it is the administrator's responsibility to watch over these numbers and make sure nodes are available. Follow the steps below to view node status.
+
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. If you have enabled the [multi-cluster feature](../../multicluster-management/) with member clusters imported, you can select a specific cluster to view its nodes. If you have not enabled the feature, refer to the next step directly.
+
+3. Choose **Cluster Nodes** under **Nodes**, where you can see detailed information of node status.
+
+ - **Name**: The node name and subnet IP address.
+ - **Status**: The current status of a node, indicating whether a node is available or not.
+ - **Role**: The role of a node, indicating whether a node is a worker or the control plane.
+ - **CPU Usage**: The real-time CPU usage of a node.
+ - **Memory Usage**: The real-time memory usage of a node.
+ - **Pods**: The real-time usage of Pods on a node.
+ - **Allocated CPU**: This metric is calculated based on the total CPU requests of Pods on a node. It represents the amount of CPU reserved for workloads on this node, even if workloads are using fewer CPU resources. This figure is vital to the Kubernetes scheduler (kube-scheduler), which favors nodes with lower allocated CPU resources when scheduling a Pod in most cases. For more details, refer to [Managing Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
+ - **Allocated Memory**: This metric is calculated based on the total memory requests of Pods on a node. It represents the amount of memory reserved for workloads on this node, even if workloads are using fewer memory resources.
+
+ {{< notice note >}}
+**CPU** and **Allocated CPU** are different most times, so are **Memory** and **Allocated Memory**, which is normal. As a cluster administrator, you need to focus on both metrics instead of just one. It's always a good practice to set resource requests and limits for each node to match their real usage. Over-allocating resources can lead to low cluster utilization, while under-allocating may result in high pressure on a cluster, leaving the cluster unhealthy.
+ {{}}
+
+## Node Management
+On the **Cluster Nodes** page, you can perform the following operations:
+
+- **Cordon/Uncordon**: Click 
on the right of the cluster node, and then click **Cordon** or **Uncordon**. Marking a node as unschedulable is very useful during a node reboot or other maintenance. The Kubernetes scheduler will not schedule new Pods to this node if it's been marked unschedulable. Besides, this does not affect existing workloads already on the node.
+
+- **Open Terminal**：Click on the right of the cluster node, and then click **Open Terminal**. This makes it convenient for you to manage nodes, such as modifying node configurations and downloading images.
+
+- **Edit Taints**：Taints allow a node to repel a set of pods. To edit a taint, select the check box before the target node. On the **Edit Taints** that is displayed, you can add, delete, or modify taints.
+
+To view node details, click the node. On the details page, you can perform the following operations:
+
+- **Edit Labels**: Node labels can be very useful when you want to assign Pods to specific nodes. Label a node first (for example, label GPU nodes with `node-role.kubernetes.io/gpu-node`), and then add the label in **Advanced Settings** [when you create a workload](../../project-user-guide/application-workloads/deployments/#step-5-configure-advanced-settings) so that you can allow Pods to run on GPU nodes explicitly. To add node labels, select **More** > **Edit Labels**.
+
+- View the running status of nodes, pods, metadata, monitoring data, and events.
+
+ {{< notice note >}}
+Be careful when you add taints as they may cause unexpected behavior, leading to services unavailable. For more information, see [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
+ {{}}
+
+## Add and Remove Nodes
+
+Currently, you cannot add or remove nodes directly from the KubeSphere console, but you can do it by using [KubeKey](https://github.com/kubesphere/kubekey). For more information, see [Add New Nodes](../../installing-on-linux/cluster-operation/add-new-nodes/) and [Remove Nodes](../../installing-on-linux/cluster-operation/remove-nodes/).
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md
new file mode 100644
index 000000000..4d4e25b09
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Notification Management"
+weight: 8720
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md
new file mode 100644
index 000000000..b63db2076
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md
@@ -0,0 +1,38 @@
+---
+title: "Configure DingTalk Notifications"
+keywords: 'KubeSphere, Kubernetes, DingTalk, Alerting, Notification'
+description: 'Learn how to configure a Dingtalk conversation or chatbot to receive platform notifications sent by KubeSphere.'
+linkTitle: "Configure DingTalk Notifications"
+weight: 8723
+---
+
+[DingTalk](https://www.dingtalk.com/en) is an enterprise-grade communication and collaboration platform. It integrates messaging, conference calling, task management, and other features into a single application.
+
+This document describes how to configure a DingTalk conversation or chatbot to receive platform notifications sent by KubeSphere.
+
+## Prerequisites
+
+- You need to have a user with the `platform-admin` role, for example, the `admin` user. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+- You need to have a DingTalk account.
+- You need to create an applet on [DingTalk Admin Panel](https://oa.dingtalk.com/index.htm#/microApp/microAppList) and make necessary configurations according to [DingTalk API documentation](https://developers.dingtalk.com/document/app/create-group-session).
+
+## Configure DingTalk Conversation or Chatbot
+
+1. Log in to the KubeSphere console as `admin`.
+2. Click **Platform** in the upper-left corner and select **Platform Settings**.
+3. In the left navigation pane, click **Notification Configuration** under **Notification Management**.
+4. On the **DingTalk** page, select the **Conversation Settings** tab and configure the following parameters:
+ - **AppKey**: The AppKey of the applet created on DingTalk.
+ - **AppSecret**: The AppSecret of the applet created on DingTalk.
+ - **Conversation ID**: The conversation ID obtained on DingTalk. To add a conversation ID, enter your conversation ID and click **Add** to add it.
+5. (Optional) On the **DingTalk** page, select the **DingTalk Chatbot** tab and configure the following parameters:
+ - **Webhook URL**: The webhook URL of your DingTalk robot.
+ - **Secret**: The secret of your DingTalk robot.
+ - **Keywords**: The keywords you added to your DingTalk robot. To add a keyword, enter your keyword and click **Add** to add it.
+6. To specify notification conditions, select the **Notification Conditions** checkbox. Specify a label, an operator, and values and click **Add** to add it. You will receive only notifications that meet the conditions.
+7. After the configurations are complete, click **Send Test Message** to send a test message.
+8. If you successfully receive the test message, click **OK** to save the configurations.
+9. To enable DingTalk notifications, turn the toggle in the upper-right corner to **Enabled**.
+
+
+
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md
new file mode 100644
index 000000000..400629d3a
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md
@@ -0,0 +1,79 @@
+---
+title: "Configure Email Notifications"
+keywords: 'KubeSphere, Kubernetes, custom, platform'
+description: 'Configure a email server and add recipients to receive email notifications.'
+linkTitle: "Configure Email Notifications"
+weight: 8722
+---
+
+This tutorial demonstrates how to configure a email server and add recipients to receive email notifications of alerting policies.
+
+## Configure the Email Server
+
+1. Log in to the web console with a user granted the role `platform-admin`.
+
+2. Click **Platform** in the upper-left corner and select **Platform Settings**.
+
+3. Navigate to **Notification Configuration** under **Notification Management**, and then choose **Email**.
+
+4. Under **Server Settings**, configure your email server by filling in the following fields.
+
+ - **SMTP Server Address**: The SMTP server address that provides email services. The port is usually `25`.
+ - **Use SSL Secure Connection**: SSL can be used to encrypt emails, thereby improving the security of information transmitted by email. Usually you have to configure the certificate for the email server.
+ - **SMTP Username**: The SMTP account.
+ - **SMTP Password**: The SMTP account password.
+ - **Sender Email Address**: The sender's email address.
+
+5. Click **OK**.
+
+## Recepient Settings
+
+### Add recipients
+
+1. Under **Recipient Settings**, enter a recipient's email address and click **Add**.
+
+2. After it is added, the email address of a recipient will be listed under **Recipient Settings**. You can add up to 50 recipients and all of them will be able to receive email notifications.
+
+3. To remove a recipient, hover over the email address you want to remove, then click 
.
+
+### Set notification conditions
+
+1. Select the checkbox on the left of **Notification Conditions** to set notification conditions.
+
+ - **Label**: Name, severity, or monitoring target of an alerting policy. You can select a label or customize a label.
+ - **Operator**: Mapping between the label and the values. The operator includes **Includes values**, **Does not include values**, **Exists**, and **Does not exist**.
+ - **Values**: Values associated with the label.
+ {{< notice note >}}
+
+ - Operators **Includes values** and **Does not include values** require one or more label values. Use a carriage return to separate values.
+ - Operators **Exists** and **Does not exist** determine whether a label exists, and do not require a label value.
+
+ {{}}
+
+2. You can click **Add** to add notification conditions.
+
+3. You can click on the right of a notification condition to delete the condition.
+
+4. After the configurations are complete, you can click **Send Test Message** for verification.
+
+5. On the upper-right corner, you can turn on the **Disabled** toggle to enbale notifications, or turn off the **Enabled** toggle to diable them.
+
+ {{< notice note >}}
+
+ - After the notification conditions are set, the recepients will receive only notifications that meet the conditions.
+ - If you change the existing configuration, you must click **OK** to apply it.
+
+ {{}}
+
+## Receive Email Notifications
+
+After you configure the email server and add recipients, you need to enable [KubeSphere Alerting](../../../../pluggable-components/alerting/) and create an alerting policy for workloads or nodes. Once it is triggered, all the recipients can receive email notifications.
+
+{{< notice note >}}
+
+- If you update your email server configuration, KubeSphere will send email notifications based on the latest configuration.
+- By default, KubeSphere sends notifications for the same alert about every 12 hours. The notification repeat interval is mainly controlled by `repeat_interval` in the Secret `alertmanager-main` in the project `kubesphere-monitoring-system`. You can customize the interval as needed.
+- As KubeSphere has built-in alerting policies, if you do not set any customized alerting policies, your recipient can still receive email notifications once a built-in alerting policy is triggered.
+
+{{}}
+
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md
new file mode 100644
index 000000000..3094f65da
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md
@@ -0,0 +1,93 @@
+---
+title: "Configure Slack Notifications"
+keywords: 'KubeSphere, Kubernetes, Slack, notifications'
+description: 'Configure Slack notifications and add channels to receive notifications from alerting policies, kube-events, and kube-auditing.'
+linkTitle: "Configure Slack Notifications"
+weight: 8725
+---
+
+This tutorial demonstrates how to configure Slack notifications and add channels, which can receive notifications for alerting policies.
+
+## Prerequisites
+
+You have an available [Slack](https://slack.com/) workspace.
+
+## Obtain a Slack OAuth Token
+
+You need to create a Slack app first so that it can help you send notifications to Slack channels. To authenticate your app, you must create an OAuth token.
+
+1. Log in to Slack to [create an app](https://api.slack.com/apps).
+
+2. On the **Your Apps** page, click **Create New App**.
+
+3. In the dialog that appears, enter your app name and select a Slack workspace for it. Click **Create App** to continue.
+
+4. From the left navigation bar, select **OAuth & Permissions** under **Features**. On the **Auth & Permissions** page, scroll down to **Scopes** and click **Add an OAuth Scope** under **Bot Token Scopes** and **User Token Scopes** respectively. Select the **chart:write** permission for both scopes.
+
+5. Scroll up to **OAuth Tokens & Redirect URLs** and click **Install to Workspace**. Grant the permission to access your workspace for the app and you can find created tokens under **OAuth Tokens for Your Team**.
+
+## Configure Slack Notifications on the KubeSphere Console
+
+You must provide the Slack token on the console for authentication so that KubeSphere can send notifications to your channel.
+
+1. Log in to the web console with a user granted the role `platform-admin`.
+
+2. Click **Platform** in the top-left corner and select **Platform Settings**.
+
+3. Navigate to **Slack** under **Notification Management**.
+
+4. For **Slack Token** under **Server Settings**, you can enter either a User OAuth Token or a Bot User OAuth Token for authentication. If you use the User OAuth Token, it is the app owner that will send notifications to your Slack channel. If you use the Bot User OAuth Token, it is the app that will send notifications.
+
+5. Under **Channel Settings**, enter a Slack channel where you want to receive notifications and click **Add**.
+
+6. After it is added, the channel will be listed under **Channel List**. You can add up to 20 channels and all of them will be able to receive notifications of alerts.
+
+ {{< notice note >}}
+
+ To remove a channel from the list, click the cross icon next to the channel.
+
+ {{}}
+
+7. Click **Save**.
+
+8. Select the checkbox on the left of **Notification Conditions** to set notification conditions.
+
+ - **Label**: Name, severity, or monitoring target of an alerting policy. You can select a label or customize a label.
+ - **Operator**: Mapping between the label and the values. The operator includes **Includes values**, **Does not include values**, **Exists**, and **Does not exist**.
+ - **Values**: Values associated with the label.
+ {{< notice note >}}
+
+ - Operators **Includes values** and **Does not include values** require one or more label values. Use a carriage return to separate values.
+ - Operators **Exists** and **Does not exist** determine whether a label exists, and do not require a label value.
+
+ {{}}
+
+9. You can click **Add** to add notification conditions, or click on the right of a notification condition to delete the condition.
+
+10. After the configurations are complete, you can click **Send Test Message** for verification.
+
+11. To make sure notifications will be sent to a Slack channel, turn on **Receive Notifications** and click **Update**.
+
+ {{< notice note >}}
+
+ - After the notification conditions are set, the recepients will receive only notifications that meet the conditions.
+ - If you change the existing configuration, you must click **OK** to apply it.
+
+ {{}}
+
+9. If you want the app to be the notification sender, make sure it is in the channel. To add it in a Slack channel, enter `/invite @ on the right of a notification condition to delete the condition.
+
+7. After the configurations are complete, you can click **Send Test Message** for verification.
+
+8. On the upper-right corner, you can turn on the **Disabled** toggle to enbale notifications, or turn off the **Enabled** toggle to diable them.
+
+9. Click **OK** after you finish.
+
+ {{< notice note >}}
+
+ - After the notification conditions are set, the recepients will receive only notifications that meet the conditions.
+ - If you change the existing configuration, you must click **OK** to apply it.
+
+ {{}}
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md
new file mode 100644
index 000000000..0788a1b0b
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md
@@ -0,0 +1,33 @@
+---
+title: "Configure WeCom Notifications"
+keywords: 'KubeSphere, Kubernetes, WeCom, Alerting, Notification'
+description: 'Learn how to configure a WeCom server to receive platform notifications sent by KubeSphere.'
+linkTitle: "Configure WeCom Notifications"
+weight: 8724
+---
+
+[WeCom](https://work.weixin.qq.com/) is a communication platform for enterprises that includes convenient communication and office automation tools.
+
+This document describes how to configure a WeCom server to receive platform notifications sent by KubeSphere.
+
+## Prerequisites
+
+- You need to have a user with the `platform-admin` role, for example, the `admin` user. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+- You need to have a [WeCom account](https://work.weixin.qq.com/wework_admin/register_wx?from=myhome).
+- You need to create a self-built application on the [WeCom Admin Console](https://work.weixin.qq.com/wework_admin/loginpage_wx) and obtain its AgentId and Secret.
+
+## Configure WeCom Server
+
+1. Log in to the KubeSphere console as `admin`.
+2. Click **Platform** in the upper-left corner and select **Platform Settings**.
+3. In the left navigation pane, click **Notification Configuration** under **Notification Management**.
+4. On the **WeCom** page, set the following fields under **Server Settings**:
+ - **Corporation ID**: The Corporation ID of your WeCom account.
+ - **App AgentId**: The AgentId of the self-built application.
+ - **App Secret**: The Secret of the self-built application.
+5. To add notification recipients, select **User ID**, **Department ID**, or **Tag ID** under **Recipient Settings**, enter a corresponding ID obtained from your WeCom account, and click **Add** to add it.
+6. To specify notification conditions, select the **Notification Conditions** checkbox. Specify a label, an operator, and values and click **Add** to add it. You will receive only notifications that meet the conditions.
+7. After the configurations are complete, click **Send Test Message** to send a test message.
+8. If you successfully receive the test message, click **OK** to save the configurations.
+9. To enable WeCom notifications, turn the toggle in the upper-right corner to **Enabled**.
+
diff --git a/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md
new file mode 100644
index 000000000..04c1d60c6
--- /dev/null
+++ b/content/en/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md
@@ -0,0 +1,40 @@
+---
+title: "Customize Cluster Name in Notification Messages"
+keywords: 'KubeSphere, Kubernetes, Platform, Notification'
+description: 'Learn how to customize cluster name in notification messages sent by KubeSphere.'
+linkTitle: "Customize Cluster Name in Notification Messages"
+weight: 8721
+---
+
+This document describes how to customize your cluster name in notification messages sent by KubeSphere.
+
+## Prerequisites
+
+You need to have a user with the `platform-admin` role, for example, the `admin` user. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+## Customize Cluster Name in Notification Messages
+
+1. Log in to the KubeSphere console as `admin`.
+
+2. Click 
in the lower-right corner and select **Kubectl**.
+
+3. In the displayed dialog box, run the following command:
+
+ ```bash
+ kubectl edit nm notification-manager
+ ```
+
+4. Add a field `cluster` under `.spec.receiver.options.global` to customize your cluster name:
+
+ ```yaml
+ spec:
+ receivers:
+ options:
+ global:
+ cluster: 
on the top navigation bar.
+
+2. Go to the **Repositories** page and you can see that Nexus provides three types of repository.
+
+ - `proxy`: the proxy for a remote repository to download and store resources on Nexus as cache.
+ - `hosted`: the repository storing artifacts on Nexus.
+ - `group`: a group of configured Nexus repositories.
+
+3. You can click a repository to view its details. For example, click **maven-public** to go to its details page, and you can see its **URL**.
+
+### Step 2: Modify `pom.xml` in your GitHub repository
+
+1. Log in to GitHub. Fork [the example repository](https://github.com/devops-ws/learn-pipeline-java) to your own GitHub account.
+
+2. In your own GitHub repository of **learn-pipeline-java**, click the file `pom.xml` in the root directory.
+
+3. Click 
to modify the code segment of `| Code Repository | +Parameter | +
|---|---|
| GitHub | +Credential: Select the credential of the code repository. | +
| GitLab | +
+
|
+
| Bitbucket | +
+
|
+
| Git | +
+
|
+
on the right of the imported code repository, and you can perform the following operations:
+
+ - **Edit**: Edits the alias and description of the code repository and reselects a code repository.
+ - **Edit YAML**: Edits the YAML file of the code repository.
+ - **Delete**: Deletes the code repository.
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md
new file mode 100644
index 000000000..659544b43
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Continuous Deployments"
+weight: 11220
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md
new file mode 100755
index 000000000..affd5a948
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md
@@ -0,0 +1,404 @@
+---
+title: "Use GitOps to Achieve Continuous Deployment of Applications"
+keywords: 'Kubernetes, GitOps, KubeSphere, CI, CD'
+description: 'Describe how to use GitOps for continuous deployment on KubeSphere.'
+linkTitle: "Use GitOps to Achieve Continuous Deployment of Applications"
+weight: 11221
+---
+
+In KubeSphere 3.3, we introduce the GitOps concept, which is a way of implementing continuous deployment for cloud-native applications. The core component of GitOps is a Git repository that always stores applications and declarative description of the infrastructure for version control. With GitOps and Kubernetes, you can enable CI/CD pipelines to apply changes to any cluster, which ensures consistency in cross-cloud deployment scenarios.
+
+This section walks you through the process of deploying an application using a continuous deployment.
+## Prerequisites
+
+- You have a workspace, a DevOps project and a user (**project-regular**) invited to the DevOps project with the **operator** role. If they are not ready yet, please refer to [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+- You need to [enable the KubeSphere DevOps system](../../../../pluggable-components/devops/).
+
+
+## Import a Code Repository
+
+1. Log in to the KubeSphere console as **project-regular**. In the left-side navigation pane, click **DevOps Projects**.
+
+2. On the **DevOps Projects** page, click the DevOps project you created.
+
+3. In the left-side navigation pane, click **Code Repositories**.
+
+4. On the **Code Repositories** page on the left, click **Import**.
+
+5. In the **Import Code Repository** dialog box, enter the name of code repository, for example, **open-podcasts**, and select a code repository. Optionally, you can set an alias and add description.
+
+6. In the **Select Code Repository** dialog box, click **Git**. In **Code Repository URL**, enter the URL of the code repository, for example, **https://github.com/kubesphere-sigs/open-podcasts**, and click **OK**.
+
+ {{< notice note >}}
+
+ As the imported code repository is a public repository, it is not necessary to create a credential. However, if you add a private repository, a credential is required. For more information about how to create a credential, please refer to [Credential Management](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/).
+
+ {{}}
+
+## Create a Continuous Deployment
+
+1. In the left-side navigation pane, click **Continuous Deployments**.
+
+2. On the **Continuous Deployments** page, click **Create**.
+
+3. On the **Basic Information** tab, enter a name of the continuous deployment, for example, **open-podcasts**, and choose a code repository. Then, click **Next**. Optionally, you can set an alias and add description.
+
+4. In the **Deployment Location** section of the **Deployment Settings** tab, configure the cluster and project for which the continuous deployment will be deployed.
+
+5. In the **Code Repository Settings** section, specify a branch or tag of the repository and the manifest file path.
+
+ | Parameter | +Description | +
|---|---|
+ |
+
+
+
+ The commit ID, branch, or tag of the repository. For example, master, v1.2.0, 0a1b2c3, or HEAD. + |
+
+
+
+ Manifest File Path + |
+
+
+
+ The manifest file path. For example, config/default. + |
+
| Parameter | +Description | +
|---|---|
+
+
+ Prune resources + |
+
+
+
+ If checked, it will delete resources that are no longer defined in Git. By default and as a safety mechanism, auto sync will not delete resources. + |
+
+
+
+ Self-heal + |
+
+
+
+ If checked, it will force the state defined in Git into the cluster when a deviation in the cluster is detected. By default, changes that are made to the live cluster will not trigger auto sync. + |
+
| Parameter | +Description | +
|---|---|
+
+
+ Prune resources + |
+
+
+
+ If checked, it will delete resources that are no longer defined in Git. + By default and as a safety mechanism, manual sync will not delete resources, but mark the resource out-of-sync state. + |
+
+
+
+ Dry run + |
+
+
+
+ Preview apply without affecting the cluster. + |
+
+
+
+ Apply only + |
+
+
+
+ If checked, it will skip pre/post sync hooks and just run kubectl apply for application resources. + |
+
+
+
+ Force + |
+
+
+
+ If checked, it will use kubectl apply --force to sync resources. + |
+
| Parameter | +Description | +
|---|---|
+
+
+ Skip schema validation + |
+
+
+
+ Disables kubectl validation. --validate=false is added when kubectl apply runs. + |
+
+
+
+ Auto create project + |
+
+
+
+ Automatically creates projects for application resources if the projects do not exist. + |
+
+
+
+ Prune last + |
+
+
+
+ Resource pruning happened as a final, implicit wave of a sync operation, after other resources have been deployed and become healthy. + |
+
+
+
+ Selective sync + |
+
+
+
+ Syncs only out-of-sync resources. + |
+
| Parameter | +Description | +
|---|---|
+
+
+ foreground + |
+
+
+
+ Deletes dependent resources first, and then deletes the owner resource. + |
+
+
+
+ background + |
+
+
+
+ Deletes the owner resource immediately, and then deletes the dependent resources in the background. + |
+
+
+
+ orphan + |
+
+
+
+ Deletes the dependent resources that remain orphaned after the owner resource is deleted. + |
+
| Item | +Description | +
|---|---|
| Name | +Name of the continuous deployment. | +
| Health Status | +Health status of the continuous deployment, which includes the following: +
|
+
| Sync Status | +Synchronization status of the continuous deployment, which includes the following: +
|
+
| Deployment Location | +Cluster and project where resources are deployed. | +
| Update Time | +Time when resources are updated. | +
on the right of the continuous deployment, and you can perform the following:
+ - **Edit Information**: edits the alias and description.
+ - **Edit YAML**: edits the YAML file.
+ - **Sync**: triggers resources synchronization.
+ - **Delete**: deletes the continuous deployment.
+
+ {{< notice warning >}}
+
+ Deleting a continuous deployment also deletes resources associated with the continuous deployment. Therefore, exert caution when deleting the continuous deployment.
+
+ {{}}
+
+
+3. Click the created continuous deployment to go to its details page, where you can view the synchronization status and result.
+
+## Access the Created Application
+
+1. Go to the project where the continuous deployment resides, in the left-side navigation pane, click **Services**.
+
+2. On the **Services** page on the left, click on the right of the deployed application, and click **Edit External Access**.
+
+3. In **Access Mode**, select **NodePort**, and click **OK**.
+
+4. In the **External Access** column, check the exposed port, and access the application by **nodeIP: nodePort**.
+
+ {{< notice note >}}
+ Before accessing the service, open the exposed port in security groups.
+ {{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md
new file mode 100644
index 000000000..334bea7ee
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "DevOps Settings"
+weight: 11240
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md
new file mode 100644
index 000000000..0fdc74a62
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md
@@ -0,0 +1,28 @@
+---
+title: "Add a Continuous Deployment Allowlist"
+keywords: 'Kubernetes, GitOps, KubeSphere, CI/CD, Allowlist'
+description: 'Describe how to add a continuous deployment allowlist on KubeSphere.'
+linkTitle: "Add a Continuous Deployment Allowlist"
+weight: 11243
+---
+In KubeSphere 3.3, you can set an allowlist so that only specific code repositories and deployment locations can be used for continuous deployment.
+
+## Prerequisites
+
+- You have a workspace, a DevOps project and a user (`project-regular`) invited to the DevOps project with the `operator` role. If they are not ready yet, please refer to [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+- You need to [enable the KubeSphere DevOps system](../../../../pluggable-components/devops/).
+
+- You need to [import an code repository](../../../../devops-user-guide/how-to-use/code-repositories/import-code-repositories/).
+
+## Procedures
+
+1. Log in to the KubeSphere console as `project-regular`. In the navigation pane on the left, click **DevOps Projects**.
+
+2. On the **DevOps Projects** page, click the DevOps project you created.
+
+3. In the navigation pane on the left, choose **DevOps Project Settings > Basic Information**.
+
+4. In **Continuous Deployment Allowlist** on the right, click **Enable Allowlist**.
+
+5. In the **Edit Allowlist** dialog box, choose a code repository and the cluster and project where the code deployment will be deployed, and then click **OK**. You can click **Add** to add multiple code repositories and deployment locations.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md
new file mode 100644
index 000000000..48a8f955c
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md
@@ -0,0 +1,93 @@
+---
+title: "Credential Management"
+keywords: 'Kubernetes, Docker, Credential, KubeSphere, DevOps'
+description: 'Create credentials so that your pipelines can communicate with third-party applications or websites.'
+linkTitle: "Credential Management"
+weight: 11241
+---
+
+Credentials are objects containing sensitive information, such as usernames and passwords, SSH keys, and tokens. When a KubeSphere DevOps pipeline is running, it interacts with objects in external environments to perform a series of tasks, including pulling code, pushing and pulling images, and running scripts. During this process, credentials need to be provided accordingly while they do not appear explicitly in the pipeline.
+
+A DevOps project user with necessary permissions can configure credentials for Jenkins pipelines. Once the user adds or configures these credentials in a DevOps project, they can be used in the DevOps project to interact with third-party applications.
+
+Currently, you can create the following 4 types of credentials in a DevOps project:
+
+- **Username and password**: Username and password which can be handled as separate components or as a colon-separated string in the format `username:password`, such as accounts of GitHub and GitLab.
+- **SSH key**: Username with a private key, an SSH public/private key pair.
+- **Access token**: a token with certain access.
+- **kubeconfig**: It is used to configure cross-cluster authentication.
+
+This tutorial demonstrates how to create and manage credentials in a DevOps project. For more information about how credentials are used, see [Create a Pipeline Using a Jenkinsfile](../../../../devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-jenkinsfile/) and [Create a Pipeline Using Graphical Editing Panels](../../../../devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel/).
+
+## Prerequisites
+
+- You have enabled [KubeSphere DevOps System](../../../../pluggable-components/devops/).
+- You have a workspace, a DevOps project and a user (`project-regular`) invited to the DevOps project with the `operator` role. If they are not ready yet, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+## Create a Credential
+
+Log in to the console of KubeSphere as `project-regular`. Navigate to your DevOps project, select **Credentials** and click **Create**.
+1. Log in to the console of KubeSphere as `project-regular`.
+
+2. Navigate to your DevOps project. On the navigation pane on the left, choose **DevOps Project Settings > Credentials**.
+
+3. In the **Credentials** area on the right, click **Create**.
+
+4. On the **Create Credential** dialog box, enter the credential name and choose the credetial type. Parameters vary depneding on the type you select. For more information, refer to the following.
+### Create a username and password credential
+
+To set a GitHub credential, you need to set the following parameters:
+
+ - **Name**: Set a credential name, for example, `github-id`.
+ - **Type**: Select **Username and password**.
+ - **Username**: Enter your GitHub username.
+ - **Password/Token**: Enter your GitHub token.
+ - **Description**: Decribe the credential.
+
+{{< notice note >}}
+
+- Since August, 2021, GitHub has announced that it would require two factor authentication for users who contribute code on its service. Therefore, if you want to create a GitHub credential, you need to enter your GitHub token, instead of the password. For details about how to create a token, please refer to [Creating a personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token).
+
+- If there are any special characters such as `@` and `$` in your account or password, they can cause errors as a pipeline runs because they may not be recognized. In this case, you need to encode your account or password on some third-party websites first, such as [urlencoder](https://www.urlencoder.org/). After that, copy and paste the output for your credential information.
+
+{{}}
+### Create an SSH key credential
+
+You need to set the following parameters:
+
+- **Name**: Set a credential name.
+- **Type**: Select **SSH key**.
+- **Username**: Enter your username.
+- **Private Key**: Enter the SSH key.
+- **Passphrase**: Enter the passphrase. For enhanced security, you are avised to set this parameter.
+- **Description**: Decribe the credential.
+
+### Create an access token credential
+
+You need to set the following parameters:
+
+- **Name**: Set a credential name.
+- **Type**: Select **Access token**.
+- **Access token**: Enter the access token.
+- **Description**: Decribe the credential.
+
+### Create a kubeconfig credential
+
+You need to set the following parameters:
+
+- **Name**: Set a credential name, for example, `demo-kubeconfig`.
+- **Type**: Select **kubeconfig**.
+- **Content**: The system automatically fills in the content when you access the current Kubernetes cluster. and you do not need to change it. However, if you are accessing other clusters, you may need change the content of kubeconfig.
+- **Description**: Decribe the credential.
+
+{{< notice info >}}
+
+A file that is used to configure access to clusters is called a kubeconfig file. This is a generic way of referring to configuration files. For more information, see [the official documentation of Kubernetes](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).
+
+{{}}
+
+## View and Manage Credentials
+
+1. Click any of them to go to its details page, where you can see account details and all the events related to the credentials.
+
+2. You can also edit or delete credentials on this page. Note that when you edit credentials, KubeSphere does not display the existing username or password information. The previous one will be overwritten if you enter a new username and password.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md
new file mode 100644
index 000000000..4f63d7185
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md
@@ -0,0 +1,76 @@
+---
+title: "Role and Member Management In Your DevOps project"
+keywords: 'Kubernetes, KubeSphere, DevOps, role, member'
+description: 'Create and manage roles and members in DevOps projects.'
+linkTitle: "Role and Member Management"
+weight: 11242
+---
+
+This guide demonstrates how to manage roles and members in your DevOps project.
+
+In DevOps project scope, you can grant the following resources' permissions to a role:
+
+- Pipelines
+- Credentials
+- DevOps Settings
+- Access Control
+
+## Prerequisites
+
+At least one DevOps project has been created, such as `demo-devops`. Besides, you need a user of the `admin` role (for example, `devops-admin`) at the DevOps project level.
+
+## Built-in Roles
+
+In **DevOps Project Roles**, there are three available built-in roles as shown below. Built-in roles are created automatically by KubeSphere when a DevOps project is created and they cannot be edited or deleted.
+
+| Built-in Roles | Description |
+| ------------------ | ------------------------------------------------------------ |
+| viewer | The viewer who can view all resources in the DevOps project. |
+| operator | The normal member in a DevOps project who can create pipelines and credentials in the DevOps project. |
+| admin | The administrator in the DevOps project who can perform any action on any resource. It gives full control over all resources in the DevOps project. |
+
+## Create a DevOps Project Role
+
+1. Log in to the console as `devops-admin` and select a DevOps project (for example, `demo-devops`) on the **DevOps Projects** page.
+
+ {{< notice note >}}
+
+ The account `devops-admin` is used as an example. As long as the account you are using is granted a role including the permissions of **Member Viewing**, **Role Management** and **Role Viewing** in **Access Control** at DevOps project level, it can create a DevOps project role.
+
+ {{}}
+
+2. Go to **DevOps Project Roles** in **DevOps Project Settings**, click **Create** and set a **Name**. In this example, a role named `pipeline-creator` will be created. Click **Edit Permissions** to continue.
+
+3. In **Pipeline Management**, select the permissions that you want this role to contain. For example, **Pipeline Management** and **Pipeline Viewing** are selected for this role. Click **OK** to finish.
+
+ {{< notice note >}}
+
+ **Depends on** means the major permission (the one listed after **Depends on**) needs to be selected first so that the affiliated permission can be assigned.
+
+ {{}}
+
+4. Newly created roles will be listed in **DevOps Project Roles**. You can click on the right to edit it.
+
+ {{< notice note >}}
+
+ The role of `pipeline-creator` is only granted **Pipeline Management** and **Pipeline Viewing**, which may not satisfy your need. This example is only for demonstration purpose. You can create customized roles based on your needs.
+
+ {{}}
+
+## Invite a New Member
+
+1. In **DevOps Project Settings**, select **DevOps Project Members** and click **Invite**.
+
+2. Click 
to invite a user to the DevOps project. Grant the role of `pipeline-creator` to the account.
+
+ {{< notice note >}}
+
+ The user must be invited to the DevOps project's workspace first.
+
+ {{}}
+
+3. After you add a user to the DevOps project, click **OK**. In **DevOps Project Members**, you can see the newly invited member listed.
+
+4. You can also change the role of an existing member by editing it or remove it from the DevOps project.
+
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md
new file mode 100644
index 000000000..68b4d2791
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md
@@ -0,0 +1,49 @@
+---
+title: "Set a CI Node for Dependency Caching"
+keywords: 'Kubernetes, docker, KubeSphere, Jenkins, cicd, pipeline, dependency cache'
+description: 'Configure a node or a group of nodes specifically for continuous integration (CI) to speed up the building process in a pipeline.'
+linkTitle: "Set a CI Node for Dependency Caching"
+weight: 11245
+---
+
+Generally, different dependencies need to be pulled as applications are being built. This may cause some issues such as long pulling time and network instability, further resulting in build failures. To provide your pipeline with a more enabling and stable environment, you can configure a node or a group of nodes specifically for continuous integration (CI). These CI nodes can speed up the building process by using caches.
+
+This tutorial demonstrates how to set CI nodes so that KubeSphere schedules tasks of pipelines and S2I/B2I builds to these nodes.
+
+## Prerequisites
+
+You need a user granted a role including the permission of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the permission and assign it to a user.
+
+## Label a CI Node
+
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. If you have enabled the [multi-cluster feature](../../../../multicluster-management/) with Member clusters imported, you can select a specific cluster to view its nodes. If you have not enabled the feature, refer to the next step directly.
+
+3. Navigate to **Cluster Nodes** under **Nodes**, where you can see existing nodes in the current cluster.
+
+4. Select a node from the list to run CI tasks. Click the node name to go to its details page. Click **More** and select **Edit Labels**.
+
+5. In the displayed dialog box, you can see a label with the key `node-role.kubernetes.io/worker`. Enter `ci` for its value and click **Save**.
+
+ {{< notice note >}}
+
+ You can also click **Add** to add new labels based on your needs.
+
+ {{}}
+
+## Add a Taint to a CI Node
+
+Basically, pipelines and S2I/B2I workflows will be scheduled to this node according to [node affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity). If you want to make the node a dedicated one for CI tasks, which means other workloads are not allowed to be scheduled to it, you can add a [taint](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to it.
+
+1. Click **More** and select **Edit Taints**.
+
+2. Click **Add Taint** and enter a key `node.kubernetes.io/ci` without specifying a value. You can choose `Prevent scheduling`, `Prevent scheduling if possible`, or `Prevent scheduling and evict existing Pods` based on your needs.
+
+3. Click **Save**. KubeSphere will schedule tasks according to the taint you set. You can go back to work on your DevOps pipeline now.
+
+ {{< notice tip >}}
+
+ This tutorial also covers the operation related to node management. For detailed information, see [Node Management](../../../../cluster-administration/nodes/).
+
+ {{}}
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md
new file mode 100644
index 000000000..953661d62
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Pipelines"
+weight: 11210
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md
new file mode 100644
index 000000000..b9f1f58bd
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md
@@ -0,0 +1,134 @@
+---
+title: "Choose Jenkins Agent"
+keywords: 'Kubernetes, KubeSphere, Docker, DevOps, Jenkins, Agent'
+description: 'Specify the Jenkins agent and use the built-in podTemplate for your pipeline.'
+linkTitle: "Choose Jenkins Agent"
+weight: 112190
+---
+
+The `agent` section specifies where the entire Pipeline, or a specific stage, will execute in the Jenkins environment depending on where the `agent` section is placed. The section must be defined at the upper-level inside the `pipeline` block, but stage-level usage is optional. For more information, see [the official documentation of Jenkins](https://www.jenkins.io/doc/book/pipeline/syntax/#agent).
+
+## Built-in podTemplate
+
+A podTemplate is a template of a Pod that is used to create agents. Users can define a podTemplate to use in the Kubernetes plugin.
+
+As a pipeline runs, every Jenkins agent Pod must have a container named `jnlp` for communications between the Jenkins controller and Jenkins agent. In addition, users can add containers in the podTemplate to meet their own needs. They can choose to use their own Pod YAML to flexibly control the runtime, and the container can be switched by the `container` command. Here is an example.
+
+```groovy
+pipeline {
+ agent {
+ kubernetes {
+ //cloud 'kubernetes'
+ label 'mypod'
+ yaml """
+apiVersion: v1
+kind: Pod
+spec:
+ containers:
+ - name: maven
+ image: maven:3.3.9-jdk-8-alpine
+ command: ['cat']
+ tty: true
+"""
+ }
+ }
+ stages {
+ stage('Run maven') {
+ steps {
+ container('maven') {
+ sh 'mvn -version'
+ }
+ }
+ }
+ }
+}
+```
+
+At the same time, KubeSphere has some built-in podTemplates, so that users can avoid writing YAML files, greatly reducing learning costs.
+
+In the current version, there are 4 types of built-in podTemplates, i.e. `base`, `nodejs`, `maven` and `go`. KubeSphere also provides an isolated Docker environment in Pods.
+
+You can use the built-in podTemplate by specifying the label for an agent. For example, to use the nodejs podTemplate, you can set the label to `nodejs` when creating the Pipeline, as shown in the example below.
+
+
+
+```groovy
+pipeline {
+ agent {
+ node {
+ label 'nodejs'
+ }
+ }
+
+ stages {
+ stage('nodejs hello') {
+ steps {
+ container('nodejs') {
+ sh 'yarn -v'
+ sh 'node -v'
+ sh 'docker version'
+ sh 'docker images'
+ }
+ }
+ }
+ }
+}
+```
+
+### podTemplate base
+
+| Name | Type / Version |
+| --- | --- |
+|Jenkins Agent Label | base |
+|Container Name | base |
+| OS| centos-7 |
+|Docker| 18.06.0|
+|Helm | 2.11.0 |
+|Kubectl| Stable release|
+|Built-in tools | unzip, which, make, wget, zip, bzip2, git |
+
+
+### podTemplate nodejs
+
+| Name | Type / Version |
+| --- | --- |
+|Jenkins Agent Label | nodejs |
+|Container Name | nodejs |
+| OS| centos-7 |
+|Node | 9.11.2 |
+|Yarn | 1.3.2 |
+| Docker | 18.06.0 |
+| Helm | 2.11.0 |
+|Kubectl | Stable release|
+|Built-in tools| unzip, which, make, wget, zip, bzip2, git |
+
+
+### podTemplate maven
+
+| Name | Type / Version |
+| --- | --- |
+| Jenkins Agent Label | maven |
+| Container Name | maven |
+| OS| centos-7 |
+| Jdk | openjdk-1.8.0 |
+| Maven | 3.5.3|
+| Docker| 18.06.0 |
+| Helm | 2.11.0 |
+| Kubectl| Stable release |
+| Built-in tools | unzip, which, make, wget, zip, bzip2, git |
+
+
+### podTemplate go
+
+| Name | Type / Version |
+| --- | --- |
+| Jenkins Agent Label | go |
+| Container Name | go |
+| OS| centos-7 |
+| Go | 1.11 |
+| GOPATH | /home/jenkins/go |
+| GOROOT | /usr/local/go |
+| Docker | 18.06.0 |
+| Helm | 2.11.0 |
+| Kubectl | Stable release |
+| Built-in tools | unzip, which, make, wget, zip, bzip2, git |
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md
new file mode 100644
index 000000000..5640d4f8a
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md
@@ -0,0 +1,389 @@
+---
+title: "Create a Pipeline Using Graphical Editing Panels"
+keywords: 'KubeSphere, Kubernetes, jenkins, cicd, graphical pipelines'
+description: 'Learn how to create and run a pipeline by using the graphical editing panel of KubeSphere.'
+linkTitle: 'Create a Pipeline Using Graphical Editing Panels'
+weight: 11211
+---
+
+A graphical editing panel in KubeSphere contains all the necessary operations used in Jenkins [stages](https://www.jenkins.io/doc/book/pipeline/#stage) and [steps](https://www.jenkins.io/doc/book/pipeline/#step). You can directly define these stages and steps on the interactive panel without creating any Jenkinsfile.
+
+This tutorial demonstrates how to create a pipeline through graphical editing panels in KubeSphere. During the whole process, you do not need to create any Jenkinsfile manually as KubeSphere will automatically generate one based on your settings on the editing panels. When the pipeline runs successfully, it creates a Deployment and a Service accordingly in your development environment and pushes an image to Docker Hub.
+
+## Prerequisites
+
+- You need to [enable the KubeSphere DevOps System](../../../../pluggable-components/devops/).
+- You need to have a [Docker Hub](https://www.dockerhub.com/) account.
+- You need to create a workspace, a DevOps project, and a user (`project-regular`). This user must be invited to the DevOps project with the `operator` role. See [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/) if they are not ready.
+- Set CI dedicated nodes to run the pipeline. For more information, see [Set CI Node for Dependency Cache](../../../../devops-user-guide/how-to-use/devops-settings/set-ci-node/).
+- Configure your email server for pipeline notifications (optional). For more information, see [Set Email Server for KubeSphere Pipelines](../../../../devops-user-guide/how-to-use/pipelines/jenkins-email/).
+- Configure SonarQube to include code analysis as part of the pipeline (optional). For more information, see [Integrate SonarQube into Pipelines](../../../../devops-user-guide/how-to-integrate/sonarqube/).
+
+## Pipeline Overview
+
+This example pipeline includes the following six stages.
+
+
+
+{{< notice note >}}
+
+- **Stage 1. Checkout SCM**: Pull source code from a GitHub repository.
+- **Stage 2. Unit test**: It will not proceed with the next stage until the test is passed.
+- **Stage 3. Code analysis**: Configure SonarQube for static code analysis.
+- **Stage 4. Build and push**: Build an image and push it to Docker Hub with the tag `snapshot-$BUILD_NUMBER`, the `$BUILD_NUMBER` of which is the record serial number in the pipeline’s activity list.
+- **Stage 5. Artifacts**: Generate an artifact (JAR package) and save it.
+- **Stage 6. Deploy to DEV**: Create a Deployment and a Service in the development environment. It requires review in this stage. An email notification will be sent after the Deployment is successful.
+
+{{}}
+
+## Hands-on Lab
+
+### Step 1: Create credentials
+
+1. Log in to the KubeSphere console as `project-regular`. Go to your DevOps project and create the following credentials in **Credentials** under **DevOps Project Settings**. For more information about how to create credentials, see [Credential Management](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/).
+
+ {{< notice note >}}
+
+ If there are any special characters such as `@` and `$` in your account or password, they can cause errors as a pipeline runs because they may not be recognized. In this case, you need to encode your account or password on some third-party websites first, such as [urlencoder](https://www.urlencoder.org/). After that, copy and paste the output for your credential information.
+
+ {{}}
+
+ | Credential ID | Type | Where to use |
+ | --------------- | --------------------- | ------------ |
+ | dockerhub-id | Username and password | Docker Hub |
+ | demo-kubeconfig | kubeconfig | Kubernetes |
+
+2. You need to create an additional credential ID (`sonar-token`) for SonarQube, which is used in stage 3 (Code analysis) mentioned above. Refer to [Create SonarQube Token for New Project](../../../../devops-user-guide/how-to-integrate/sonarqube/#create-sonarqube-token-for-new-project) to enter your SonarQube token in the **Token** field for a credential of the **Access token** type. Click **OK** to finish.
+
+3. In total, you have three credentials in the list.
+
+### Step 2: Create a project
+
+In this tutorial, the example pipeline will deploy the [sample](https://github.com/kubesphere/devops-maven-sample/tree/sonarqube) app to a project. Hence, you must create the project (for example, `kubesphere-sample-dev`) in advance. The Deployment and Service of the app will be created automatically in the project once the pipeline runs successfully.
+
+You can use the user `project-admin` to create the project. Besides, this user is also the reviewer of the CI/CD pipeline. Make sure the account `project-regular` is invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+### Step 3: Create a pipeline
+
+1. Make sure you have logged in to KubeSphere as `project-regular`, and then go to your DevOps project. Click **Create** on the **Pipelines** page.
+
+2. In the displayed dialog box, name it `graphical-pipeline` and click **Next**.
+
+3. On the **Advanced Settings** page, click **Add** to add three string parameters as follows. These parameters will be used in the Docker command of the pipeline. Click **Create** when you finish adding.
+
+ | Parameter Type | Name | Value | Description |
+ | -------------- | ------------------- | --------------- | ------------------------------------------------------------ |
+ | String | REGISTRY | `docker.io` | This is the image registry address. This example uses `docker.io`. |
+ | String | DOCKERHUB_NAMESPACE | Docker ID | You Docker Hub account or the organization name under the account. |
+ | String | APP_NAME | `devops-sample` | The app name. |
+
+ {{< notice note >}}
+
+ For other fields, use the default values directly or refer to [Pipeline Settings](../pipeline-settings/) to customize the configuration.
+
+ {{}}
+
+4. The pipeline created is displayed in the list.
+
+### Step 4: Edit the pipeline
+
+Click the pipeline to go to its details page. To use graphical editing panels, click **Edit Pipeline** under the tab **Task Status**. In the displayed dialog box, click **Custom Pipeline**. This pipeline consists of six stages. Follow the steps below to set each stage.
+
+{{< notice note >}}
+
+- The pipeline details page shows **Sync Status**. It reflects the synchronization result between KubeSphere and Jenkins, and you can see the **Successful** icon if the synchronization is successful. You can also click **Edit Jenkinsfile** to create a Jenkinsfile manually for your pipeline.
+
+- You can also [use the built-in pipeline templates](../use-pipeline-templates/) provided by KubeSphere.
+
+{{}}
+
+#### Stage 1: Pull source code (Checkout SCM)
+
+A graphical editing panel includes two areas - **canvas** on the left and **content** on the right. It automatically generates a Jenkinsfile based on how you configure different stages and steps, which is much more user-friendly for developers.
+
+{{< notice note >}}
+
+Pipelines include [declarative pipelines](https://www.jenkins.io/doc/book/pipeline/syntax/#declarative-pipeline) and [scripted pipelines](https://www.jenkins.io/doc/book/pipeline/syntax/#scripted-pipeline). Currently, you can create declarative pipelines through the panel. For more information about pipeline syntax, see [Jenkins Documentation](https://jenkins.io/doc/book/pipeline/syntax/).
+
+{{}}
+
+1. On the graphical editing panel, select **node** from the **Type** drop-down list and select **maven** from the **Label** drop-down list.
+
+ {{< notice note >}}
+
+ `agent` is used to define the execution environment. The `agent` directive tells Jenkins where and how to execute the pipeline. For more information, see [Choose Jenkins Agent](../choose-jenkins-agent/).
+
+ {{}}
+
+ 
+
+2. To add a stage, click the plus icon on the left. Click the box above the **Add Step** area and set a name (for example, `Checkout SCM`) for the stage in the field **Name** on the right.
+
+ 
+
+3. Click **Add Step**. Select **git** from the list as the example code is pulled from GitHub. In the displayed dialog box, fill in the required field. Click **OK** to finish.
+
+ - **URL**. Enter the GitHub repository address `https://github.com/kubesphere/devops-maven-sample.git`. Note that this is an example and you need to use your own repository address.
+ - **Name**. You do not need to enter the Credential ID for this tutorial.
+ - **Branch**. It defaults to the master branch if you leave it blank. Enter `sonarqube` or leave it blank if you do not need the code analysis stage.
+
+ 
+
+4. The first stage is now set.
+
+ 
+
+#### Stage 2: Unit test
+
+1. Click the plus icon on the right of stage 1 to add a new stage to perform a unit test in the container. Name it `Unit Test`.
+
+ 
+
+2. Click **Add Step** and select **container** from the list. Name it `maven` and then click **OK**.
+
+ 
+
+3. Click **Add Nesting Steps** to add a nested step under the `maven` container. Select **shell** from the list and enter the following command in the command line. Click **OK** to save it.
+
+ ```shell
+ mvn clean -gs `pwd`/configuration/settings.xml test
+ ```
+
+ {{< notice note >}}
+
+ You can specify a series of [steps](https://www.jenkins.io/doc/book/pipeline/syntax/#steps) to be executed in a given stage directive on the graphical editing panel.
+
+ {{}}
+
+
+#### Stage 3: Code analysis (optional)
+
+This stage uses SonarQube to test your code. You can skip this stage if you do not need the analysis.
+
+1. Click the plus icon on the right of the `Unit Test` stage to add a stage for SonarQube code analysis in the container. Name it `Code Analysis`.
+
+ 
+
+2. Click **Add Step** under **Task** in **Code Analysis** and select **container**. Name it `maven` and click **OK**.
+
+ 
+
+3. Click **Add Nesting Steps** under the `maven` container to add a nested step. Click **withCredentials** and select the SonarQube token (`sonar-token`) from the **Name** list. Enter `SONAR_TOKEN` for **Text Variable**, then click **OK**.
+
+ 
+
+4. Under the **withCredentials** step, click **Add Nesting Steps** to add a nested step for it.
+
+ 
+
+5. Click **withSonarQubeEnv**. In the displayed dialog box, do not change the default name `sonar` and click **OK** to save it.
+
+ 
+
+6. Under the **withSonarQubeEnv** step, click **Add Nesting Steps** to add a nested step for it.
+
+ 
+
+7. Click **shell** and enter the following command in the command line for the sonarqube branch and authentication. Click **OK** to finish.
+
+ ```shell
+ mvn sonar:sonar -Dsonar.login=$SONAR_TOKEN
+ ```
+
+ 
+
+8. Click **Add Nesting Steps** (the third one) for the **container** step directly and select **timeout**. Enter `1` for time and select **Hours** for unit. Click **OK** to finish.
+
+ 
+
+ 
+
+9. Click **Add Nesting Steps** for the **timeout** step and select **waitForQualityGate**. Select **Start the follow-up task after the inspection** in the displayed dialog box. Click **OK** to save it.
+
+ 
+
+ 
+
+#### Stage 4: Build and push the image
+
+1. Click the plus icon on the right of the previous stage to add a new stage to build and push images to Docker Hub. Name it `Build and Push`.
+
+ 
+
+2. Click **Add Step** under **Task** and select **container**. Name it `maven`, and then click **OK**.
+
+ 
+
+3. Click **Add Nesting Steps** under the `maven` container to add a nested step. Select **shell** from the list, and enter the following command in the displayed dialog box. Click **OK** to finish.
+
+ ```shell
+ mvn -Dmaven.test.skip=true clean package
+ ```
+
+ 
+
+4. Click **Add Nesting Steps** again and select **shell**. Enter the following command in the command line to build a Docker image based on the [Dockerfile](https://github.com/kubesphere/devops-maven-sample/blob/sonarqube/Dockerfile-online). Click **OK** to confirm.
+
+ {{< notice note >}}
+
+ DO NOT omit the dot `.` at the end of the command.
+
+ {{}}
+
+ ```shell
+ docker build -f Dockerfile-online -t $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER .
+ ```
+
+ 
+
+5. Click **Add Nesting Steps** again and select **withCredentials**. Fill in the following fields in the displayed dialog box. Click **OK** to confirm.
+
+ - **Credential Name**: Select the Docker Hub credentials you created, such as `dockerhub-id`.
+ - **Password Variable**: Enter `DOCKER_PASSWORD`.
+ - **Username Variable**: Enter `DOCKER_USERNAME`.
+
+ {{< notice note >}}
+
+ For security reasons, the account information displays as variables in the script.
+
+ {{}}
+
+ 
+
+6. Click **Add Nesting Steps** (the first one) in the **withCredentials** step created above. Select **shell** and enter the following command in the displayed dialog box, which is used to log in to Docker Hub. Click **OK** to confirm.
+
+ ```shell
+ echo "$DOCKER_PASSWORD" | docker login $REGISTRY -u "$DOCKER_USERNAME" --password-stdin
+ ```
+
+ 
+
+7. Click **Add nesting steps** in the **withCredentials** step. Select **shell** and enter the following command to push the SNAPSHOT image to Docker Hub. Click **OK** to finish.
+
+ ```shell
+ docker push $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER
+ ```
+
+ 
+
+#### Stage 5: Generate the artifact
+
+1. Click the plus icon on the right of the **Build and Push** stage to add a new stage to save artifacts and name it `Artifacts`. This example uses a JAR package.
+
+ 
+
+2. With the **Artifacts** stage selected, click **Add Step** under **Task** and select **archiveArtifacts**. Enter `target/*.jar` in the displayed dialog box, which is used to set the archive path of artifacts in Jenkins. Click **OK** to finish.
+
+ 
+
+#### Stage 6: Deploy to development
+
+1. Click the plus icon on the right of the stage **Artifacts** to add the last stage. Name it `Deploy to Dev`. This stage is used to deploy resources to your development environment (namely, the project of `kubesphere-sample-dev`).
+
+ 
+
+2. Click **Add Step** under the **Deploy to Dev** stage. Select **input** from the list and enter `@project-admin` in the **Message** field, which means the account `project-admin` will review this pipeline when it runs to this stage. Click **OK** to save it.
+
+ 
+
+ {{< notice note >}}
+
+ In KubeSphere 3.3, the account that can run a pipeline will be able to continue or terminate the pipeline if there is no reviewer specified. Pipeline creators and the account you specify will be able to continue or terminate a pipeline.
+
+ {{}}
+
+3. Click **Add Step** under the **Deploy to Dev** stage again. Select **container** from the list, name it `maven`, and click **OK**.
+
+4. Click **Add Nesting Steps** in the `maven` container step. Select **withCredentials** from the list, fill in the following fields in the displayed dialog box, and click **OK**.
+
+ - **Credential Name**: Select the kubeconfig credential you created, such as `demo-kubeconfig`.
+ - **Kubeconfig Variable**: Enter `KUBECONFIG_CONTENT`.
+
+5. Click **Add Nesting Steps** in the **withCredentials** step. Select **shell** from the list, enter the following commands in the displayed dialog box, and click **OK**.
+
+ ```shell
+ mkdir ~/.kube
+ echo "$KUBECONFIG_CONTENT" > ~/.kube/config
+ envsubst < deploy/dev-ol/devops-sample-svc.yaml | kubectl apply -f -
+ envsubst < deploy/dev-ol/devops-sample.yaml | kubectl apply -f -
+ ```
+
+6. If you want to receive email notifications when the pipeline runs successfully, click **Add Step** and select **mail** to add email information. Note that configuring the email server is optional, which means you can still run your pipeline if you skip this step.
+
+ {{< notice note >}}
+
+ For more information on configuring your email server, see [Set Email Server for KubeSphere Pipelines](../jenkins-email/).
+
+ {{}}
+
+7. When you finish the steps above, click **Save** in the lower-right corner. You can see the pipeline now has a complete workflow with each stage clearly listed on the pipeline. When you define a pipeline using the graphical editing panel, KubeSphere automatically creates its corresponding Jenkinsfile. Click **Edit Jenkinsfile** to view the Jenkinsfile.
+
+ {{< notice note >}}
+
+ On the **Pipelines** page, you can click on the right side of the pipeline and then select **Copy** to create a copy of it. If you need to concurrently run multiple pipelines that don't contain multiple branches, you can select all of these pipelines and then click **Run** to run them in a batch.
+
+ {{}}
+
+### Step 5: Run a pipeline
+
+1. You need to manually run the pipeline that is created through the graphical editing panel. Click **Run**, and you can see three string parameters defined in Step 3. Click **OK** to run the pipeline.
+
+ 
+
+2. To see the status of a pipeline, go to the **Run Records** tab and click the record you want to view.
+
+3. Wait for a while and the pipeline stops at the stage **Deploy to Dev** if it runs successfully. As the reviewer of the pipeline, `project-admin` needs to approve it before resources are deployed to the development environment.
+
+ 
+
+4. Log out of KubeSphere and log back in to the console as `project-admin`. Go to your DevOps project and click the pipeline `graphical-pipeline`. Under the **Run Records** tab, click the record to be reviewed. To approve the pipeline, click **Proceed**.
+
+### Step 6: View pipeline details
+
+1. Log in to the console as `project-regular`. Go to your DevOps project and click the pipeline `graphical-pipeline`. Under the **Run Records** tab, click the record marked with **Successful** under **Status**.
+
+2. If everything runs successfully, you can see that all stages are completed.
+
+3. Click **View Logs** in the upper-right corner to inspect all the logs. Click each stage to see detailed logs of it. You can debug any problems based on the logs which also can be downloaded locally for further analysis.
+
+### Step 7: Download the artifact
+
+Click the **Artifacts** tab and then click the icon on the right to download the artifact.
+
+
+
+### Step 8: View code analysis results
+
+On the **Code Check** page, view the code analysis result of this example pipeline, which is provided by SonarQube. If you do not configure SonarQube in advance, this section is not available. For more information, see [Integrate SonarQube into Pipelines](../../../how-to-integrate/sonarqube/).
+
+
+
+### Step 9: Verify Kubernetes resources
+
+1. If every stage of the pipeline runs successfully, a Docker image will be automatically built and pushed to your Docker Hub repository. Ultimately, the pipeline automatically creates a Deployment and a Service in the project you set beforehand.
+
+2. Go to the project (for example, `kubesphere-sample-dev` in this tutorial), click **Workloads** under **Application Workloads**, and you can see the Deployment appears in the list.
+
+3. In **Services**, you can find the port number of the example Service is exposed through a NodePort. To access the Service, visit ` on the right side of the pipeline and then select **Copy** to create a copy of it. If you need to concurrently run multiple pipelines that don't contain multiple branches, you can select all of these pipelines and then click **Run** to run them in a batch.
+ - The pipeline details page shows **Sync Status**. It reflects the synchronization result between KubeSphere and Jenkins, and you can see the **Successful** icon if the synchronization is successful.
+
+ {{}}
+
+2. Under **Run Records**, three branches are being scanned. Click **Run** on the right and the pipeline runs based on the behavioral strategy you set. Select **sonarqube** from the drop-down list and add a tag number such as `v0.0.2`. Click **OK** to trigger a new activity.
+
+ {{< notice note >}}
+
+ - If you do not see any run records on this page, you need to refresh your browser manually or click **Scan Repository** from the drop-down menu (the **More** button).
+ - The tag name is used to generate releases and images with the tag in GitHub and Docker Hub. An existing tag name cannot be used again for the field `TAG_NAME`. Otherwise, the pipeline will not be running successfully.
+
+ {{}}
+
+3. Wait for a while, and you can see some activities stop and some fail. Click the first one to view details.
+
+ {{< notice note >}}
+
+ Activity failures may be caused by different factors. In this example, only the Jenkinsfile of the branch sonarqube is changed as you edit the environment variables in it in the steps above. On the contrary, these variables in the dependency and master branch remain changed (namely, wrong GitHub and Docker Hub account), resulting in the failure. You can click it and inspect its logs to see details. Other reasons for failures may be network issues, incorrect coding in the Jenkinsfile and so on.
+
+ {{}}
+
+4. The pipeline pauses at the stage `deploy to dev`. You need to click **Proceed** manually. Note that the pipeline will be reviewed three times as `deploy to dev`, `push with tag`, and `deploy to production` are defined in the Jenkinsfile respectively.
+
+ In a development or production environment, it requires someone who has higher authority (for example, release manager) to review the pipeline, images, as well as the code analysis result. They have the authority to determine whether the pipeline can go to the next stage. In the Jenkinsfile, you use the section `input` to specify who reviews the pipeline. If you want to specify a user (for example, `project-admin`) to review it, you can add a field in the Jenkinsfile. If there are multiple users, you need to use commas to separate them as follows:
+
+ ```groovy
+ ···
+ input(id: 'release-image-with-tag', message: 'release image with tag?', submitter: 'project-admin,project-admin1')
+ ···
+ ```
+
+ {{< notice note >}}
+
+ In KubeSphere 3.3, if you do not specify a reviewer, the user that can run a pipeline will be able to continue or terminate the pipeline. If you specify a reviewer, the user who created the pipeline and the user specified will be able to continue or terminate the pipeline.
+
+ {{}}
+
+### Step 6: Check pipeline status
+
+1. In **Task Status**, you can see how a pipeline is running. Please note that the pipeline will keep initializing for several minutes after it is just created. There are eight stages in the sample pipeline and they have been defined separately in [Jenkinsfile-online](https://github.com/kubesphere/devops-maven-sample/blob/sonarqube/Jenkinsfile-online).
+
+2. Check the pipeline running logs by clicking **View Logs** in the upper-right corner. You can see the dynamic log output of the pipeline, including any errors that may stop the pipeline from running. For each stage, you click it to inspect logs, which can be downloaded to your local machine for further analysis.
+
+### Step 7: Verify results
+
+1. Once you successfully executed the pipeline, click **Code Check** to check the results through SonarQube as follows.
+
+2. The Docker image built through the pipeline has also been successfully pushed to Docker Hub, as it is defined in the Jenkinsfile. In Docker Hub, you will find the image with the tag `v0.0.2` that is specified before the pipeline runs.
+
+3. At the same time, a new tag and a new release have been generated in GitHub.
+
+4. The sample application will be deployed to `kubesphere-sample-dev` and `kubesphere-sample-prod` with corresponding Deployments and Services created. Go to these two projects and here are the expected result:
+
+ | Environment | URL | Namespace | Deployment | Service |
+ | :--- | :--- | :--- | :--- | :--- |
+ | Development | `http://{$NodeIP}:{$30861}` | kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
+ | Production | `http://{$NodeIP}:{$30961}` | kubesphere-sample-prod | ks-sample | ks-sample |
+
+ {{< notice note >}}
+
+ You may need to open the port in your security groups so that you can access the app with the URL.
+
+ {{}}
+
+### Step 8: Access the example Service
+
+1. To access the Service, log in to KubeSphere as `admin` to use the **kubectl** from **Toolbox**. Go to the project `kubesphere-sample-dev`, and click `ks-sample-dev` in **Services** under **Application Workloads**. Obtain the endpoint displayed on the details page to access the Service.
+
+2. Use the **kubectl** from **Toolbox** in the lower-right corner by executing the following command:
+
+ ```bash
+ curl 10.233.120.230:8080
+ ```
+
+3. Expected output:
+
+ ```bash
+ Really appreciate your star, that's the power of our life.
+ ```
+
+ {{< notice note >}}
+
+ Use `curl` endpoints or {$Virtual IP}:{$Port} or {$Node IP}:{$NodePort}
+
+ {{}}
+
+4. Similarly, you can test the Service in the project `kubesphere-sample-prod` and you will see the same result.
+
+ ```bash
+ $ curl 10.233.120.236:8080
+ Really appreciate your star, that's the power of our life.
+ ```
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md
new file mode 100644
index 000000000..d5804ef58
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md
@@ -0,0 +1,70 @@
+---
+title: "Customize Jenkins Agent"
+keywords: "KubeSphere, Kubernetes, DevOps, Jenkins, Agent"
+description: "Learn how to customize a Jenkins agent on KubeSphere."
+linkTitle: "Customize Jenkins Agent"
+Weight: 112191
+---
+
+If you need to use a Jenkins agent that runs on a specific environment, for example, JDK 11, you can customize a Jenkins agent on KubeSphere.
+
+This document describes how to customize a Jenkins agent on KubeSphere.
+
+## Prerequisites
+
+- You have enabled [the KubeSphere DevOps System](../../../../pluggable-components/devops/).
+
+## Customize a Jenkins agent
+
+1. Log in to the web console of KubeSphere as `admin`.
+
+2. Click **Platform** in the upper-left corner, select **Cluster Management**, and click **Configmaps** under **Configuration** on the left navigation pane.
+
+3. On the **Configmaps** page, enter `jenkins-casc-config` in the search box and press **Enter**.
+
+4. Click `jenkins-casc-config` to go to its details page, click **More**, and select **Edit YAML**.
+
+5. In the displayed dialog box, enter the following code under the `data.jenkins_user.yaml:jenkins.clouds.kubernetes.templates` section and click **OK**.
+
+ ```yaml
+ - name: "maven-jdk11" # The name of the customized Jenkins agent.
+ label: "maven jdk11" # The label of the customized Jenkins agent. To specify multiple labels, use spaces to seperate them.
+ inheritFrom: "maven" # The name of the existing pod template from which this customzied Jenkins agent inherits.
+ containers:
+ - name: "maven" # The container name specified in the existing pod template from which this customzied Jenkins agent inherits.
+ image: "kubespheredev/builder-maven:v3.2.0jdk11" # This image is used for testing purposes only. You can use your own images.
+ ```
+
+ {{< notice note >}}
+
+ Make sure you follow the indentation in the YAML file.
+
+ {{}}
+
+6. Wait for at least 70 seconds until your changes are automatically reloaded.
+
+7. To use the custom Jenkins agent, refer to the following sample Jenkinsfile to specify the label and container name of the custom Jenkins agent accordingly when creating a pipeline.
+
+ ```groovy
+ pipeline {
+ agent {
+ node {
+ label 'maven && jdk11'
+ }
+ }
+ stages {
+ stage('Print Maven and JDK version') {
+ steps {
+ container('maven') {
+ sh '''
+ mvn -v
+ java -version
+ '''
+ }
+ }
+ }
+ }
+ }
+ ```
+
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md
new file mode 100644
index 000000000..3d4563fe9
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md
@@ -0,0 +1,129 @@
+---
+title: "Create a Multi-branch Pipeline with GitLab"
+keywords: 'KubeSphere, Kubernetes, GitLab, Jenkins, Pipelines'
+description: 'Learn how to create a multi-branch pipeline with GitLab on KubeSphere.'
+linkTitle: "Create a Multi-branch Pipeline with GitLab"
+weight: 11215
+---
+
+[GitLab](https://about.gitlab.com/) is an open source code repository platform that provides public and private repositories. It is a complete DevOps platform that enables professionals to perform their tasks in a project.
+
+In KubeSphere 3.1.x and later, you can create a multi-branch pipeline with GitLab in your DevOps project. This tutorial demonstrates how to create a multi-branch pipeline with GitLab.
+
+## Prerequisites
+
+- You need to have a [GitLab](https://gitlab.com/users/sign_in) account and a [Docker Hub](https://hub.docker.com/) account.
+- You need to [enable the KubeSphere DevOps system](../../../../pluggable-components/devops/).
+- You need to create a workspace, a DevOps project and a user (`project-regular`). This user must be invited to the DevOps project with the `operator` role. For more information, refer to [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Create credentials
+
+1. Log in to the KubeSphere console as `project-regular`. Go to your DevOps project and create the following credentials in **Credentials** under **DevOps Project Settings**. For more information about how to create credentials, see [Credential Management](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/).
+
+ {{< notice note >}}
+
+ If there are any special characters such as `@` and `$` in your account or password, they can cause errors as a pipeline runs because they may not be recognized. In this case, you need to encode your account or password on some third-party websites first, such as [urlencoder](https://www.urlencoder.org/). After that, copy and paste the output for your credential information.
+
+ {{}}
+
+ | Credential ID | Type | Where to use |
+ | --------------- | ------------------- | ------------ |
+ | dockerhub-id | Account Credentials | Docker Hub |
+ | gitlab-id | Account Credentials | GitLab |
+ | demo-kubeconfig | kubeconfig | Kubernetes |
+
+2. After creation, you can see the credentials in the list.
+
+### Step 2: Modify the Jenkinsfile in your GitLab repository
+
+1. Log in to GitLab and create a public project. Click **Import project/repository**, select **Repo by URL** to enter the URL of [devops-maven-sample](https://github.com/kubesphere/devops-maven-sample), select **Public** for **Visibility Level**, and then click **Create project**.
+
+2. In the project just created, create a new branch from the master branch and name it `gitlab-demo`.
+
+3. In the `gitlab-demo` branch, click the file `Jenkinsfile-online` in the root directory.
+
+4. Click **Edit**, change `GITHUB_CREDENTIAL_ID`, `GITHUB_ACCOUNT`, and `@github.com` to `GITLAB_CREDENTIAL_ID`, `GITLAB_ACCOUNT`, and `@gitlab.com` respectively, and then edit the following items. You also need to change the value of `branch` in the `push latest` and `deploy to dev` stages to `gitlab-demo`.
+
+ | Item | Value | Description |
+ | -------------------- | --------- | ------------------------------------------------------------ |
+ | GITLAB_CREDENTIAL_ID | gitlab-id | The **Name** you set in KubeSphere for your GitLab account. It is used to push tags to your GitLab repository. |
+ | DOCKERHUB_NAMESPACE | felixnoo | Replace it with your Docker Hub’s account name. It can be the Organization name under the account. |
+ | GITLAB_ACCOUNT | felixnoo | Replace it with your GitLab account name. It can also be the account’s Group name. |
+
+ {{< notice note >}}
+
+ For more information about the environment variables in the Jenkinsfile, refer to [Create a Pipeline Using a Jenkinsfile](../create-a-pipeline-using-jenkinsfile/#step-2-modify-the-jenkinsfile-in-your-github-repository).
+
+ {{}}
+
+5. Click **Commit changes** to update this file.
+
+### Step 3: Create projects
+
+You need to create two projects, such as `kubesphere-sample-dev` and `kubesphere-sample-prod`, which represent the development environment and the production environment respectively. For more information, refer to [Create a Pipeline Using a Jenkinsfile](../create-a-pipeline-using-jenkinsfile/#step-3-create-projects).
+
+### Step 4: Create a pipeline
+
+1. Log in to the KubeSphere web console as `project-regular`. Go to your DevOps project and click **Create** to create a new pipeline.
+
+2. Provide the basic information in the displayed dialog box. Name it `gitlab-multi-branch` and select a code repository.
+
+3. On the **GitLab** tab, select the default option `https://gitlab.com` for **GitLab Server Address**, enter the username of the GitLab project owner for **Project Group/Owner**, and then select the `devops-maven-sample` repository from the drop-down list for **Code Repository**. Click **√** in the lower-right corner and then click **Next**.
+
+ {{< notice note >}}
+
+ If you want to use a private repository from GitLab, refer to the following steps:
+
+ - Go to **User Settings > Access Tokens** on GitLab to create an access token with API and read_repository permissions.
+ - [Log in to the Jenkins dashboard](../../../how-to-integrate/sonarqube/#step-5-add-the-sonarqube-server-to-jenkins), go to **Manage Jenkins > Manage Credentials** to use your GitLab token to create a Jenkins credential for accessing GitLab, and go to **Manage Jenkins > Configure System** to add the credential in **GitLab Server**.
+ - In your DevOps project, select **DevOps Project Settings > Credentials** to use your GitLab token to create a credential. You have to specify the credential for **Credential** on the **GitLab** tab when creating a pipeline so that the pipeline can pull code from your private GitLab repository.
+
+ {{}}
+
+4. On the **Advanced Settings** tab, scroll down to **Script Path**. Change it to `Jenkinsfile-online` and then click **Create**.
+
+ {{< notice note >}}
+
+ The field specifies the Jenkinsfile path in the code repository. It indicates the repository’s root directory. If the file location changes, the script path also needs to be changed.
+
+ {{}}
+
+### Step 5: Run a pipeline
+
+1. After a pipeline is created, it is displayed in the list. Click its name to go to its details page.
+
+2. Click **Run** on the right. In the displayed dialog box, select **gitlab-demo** from the drop-down list and add a tag number such as `v0.0.2`. Click **OK** to trigger a new run.
+
+ {{< notice note >}}
+
+ The pipeline pauses at the stage `deploy to dev`. You need to click **Proceed** manually. Note that the pipeline will be reviewed three times as `deploy to dev`, `push with tag`, and `deploy to production` are defined in the Jenkinsfile respectively.
+
+ {{}}
+
+### Step 6: Check the pipeline status
+
+1. In the **Task Status** tab, you can see how a pipeline is running. Check the pipeline running logs by clicking **View Logs** in the upper-right corner.
+
+2. You can see the dynamic log output of the pipeline, including any errors that may stop the pipeline from running. For each stage, you can click it to inspect logs, which can also be downloaded to your local machine for further analysis.
+
+### Step 7: Verify results
+
+1. The Docker image built through the pipeline has been successfully pushed to Docker Hub, as it is defined in the Jenkinsfile. In Docker Hub, you will find the image with the tag `v0.0.2` that is specified before the pipeline runs.
+
+2. At the same time, a new tag is generated in GitLab.
+
+3. The sample application will be deployed to `kubesphere-sample-dev` and `kubesphere-sample-prod` with corresponding Deployments and Services created.
+
+ | Environment | URL | Namespace | Deployment | Service |
+ | ----------- | --------------------------- | ---------------------- | ------------- | ------------- |
+ | Development | `http://{$NodeIP}:{$30861}` | kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
+ | Production | `http://{$NodeIP}:{$30961}` | kubesphere-sample-prod | ks-sample | ks-sample |
+
+ {{< notice note >}}
+
+ You may need to open the port in your security groups so that you can access the app with the URL. For more information, refer to [Access the example Service](../create-a-pipeline-using-jenkinsfile/#step-8-access-the-example-service).
+
+ {{}}
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md
new file mode 100644
index 000000000..a94c5ff48
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md
@@ -0,0 +1,42 @@
+---
+title: "Set the Email Server for KubeSphere Pipelines"
+keywords: 'KubeSphere, Kubernetes, notification, jenkins, devops, ci/cd, pipeline, email server'
+description: 'Set the email server to receive notifications of your Jenkins pipelines.'
+linkTitle: "Set Email Server for KubeSphere Pipelines"
+Weight: 11218
+---
+
+
+The built-in Jenkins cannot share the same email configuration with the platform notification system. Thus, you need to configure email server settings for KubeSphere DevOps pipelines separately.
+
+## Prerequisites
+
+- You need to enable the [KubeSphere DevOps System](../../../../pluggable-components/devops/).
+- You need a user granted a role including the **Cluster Management** permission. For example, you can log in to the console as `admin` directly or create a new role with the permission and assign it to a user.
+
+## Set the Email Server
+
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. If you have enabled the [multi-cluster feature](../../../../multicluster-management/) with member clusters imported, you can select a specific cluster to view its nodes. If you have not enabled the feature, refer to the next step directly.
+
+3. Go to **Workloads** under **Application Workloads**, and select the project **kubesphere-devops-system** from the drop-down list. Click on the right of `devops-jenkins` and select **Edit YAML** to edit its YAML.
+
+4. Scroll down to the fields in the image below which you need to specify. Click **OK** when you finish to save changes.
+
+ {{< notice warning >}}
+
+ Once you modify the Email server in the `devops-jenkins` Deployment, it will restart itself. Consequently, the DevOps system will be unavailable for a few minutes. Please make such modification at an appropriate time.
+
+ {{}}
+
+ 
+
+ | Environment Variable Name | Description |
+ | ------------------------- | -------------------------------- |
+ | EMAIL\_SMTP\_HOST | SMTP server address |
+ | EMAIL\_SMTP\_PORT | SMTP server port (for example, 25) |
+ | EMAIL\_FROM\_ADDR | Email sender address |
+ | EMAIL\_FROM\_NAME | Email sender name |
+ | EMAIL\_FROM\_PASS | Email sender password |
+ | EMAIL\_USE\_SSL | SSL configuration enabled or not |
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md
new file mode 100644
index 000000000..daa858cad
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md
@@ -0,0 +1,50 @@
+---
+title: "Jenkins System Settings"
+keywords: 'Kubernetes, KubeSphere, Jenkins, CasC'
+description: 'Learn how to customize your Jenkins settings.'
+linkTitle: 'Jenkins System Settings'
+Weight: 11216
+---
+
+Jenkins is powerful and flexible and it has become the de facto standard for CI/CD workflows. Nevertheless, many plugins require users to set system-level configurations before they can be put to use.
+
+The KubeSphere DevOps System offers containerized CI/CD functions based on Jenkins. To provide users with a schedulable Jenkins environment, KubeSphere uses **Configuration as Code** for Jenkins system settings, which requires users to log in to the Jenkins dashboard and reload the configuration after it is modified. In the current release, Jenkins system settings are not available on the KubeSphere console, which will be supported in upcoming releases.
+
+This tutorial demonstrates how to set up Jenkins and reload configurations on the Jenkins dashboard.
+
+## Prerequisites
+
+You have enabled [the KubeSphere DevOps System](../../../../pluggable-components/devops/).
+
+## Jenkins Configuration as Code
+
+KubeSphere has the Jenkins Configuration as Code plugin installed by default to allow you to define the desired state of your Jenkins configuration through YAML files and makes it easy to reproduce your Jenkins configurations including plugin configurations. You can find descriptions about specific Jenkins configurations and example YAML files [in this directory](https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos).
+
+Besides, you can find the `formula.yaml` file in the repository [ks-jenkins](https://github.com/kubesphere/ks-jenkins), where you can view plugin versions and customize these versions based on your needs.
+
+
+
+## Modify the ConfigMap
+
+It is recommended that you configure Jenkins in KubeSphere through Configuration as Code (CasC). The built-in Jenkins CasC file is stored as a [ConfigMap](../../../../project-user-guide/configuration/configmaps/).
+
+1. Log in to KubeSphere as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. If you have enabled the [multi-cluster feature](../../../../multicluster-management/) with member clusters imported, you can select a specific cluster to edit the ConfigMap. If you have not enabled the feature, refer to the next step directly.
+
+3. On the left navigation pane, select **ConfigMaps** under **Configuration**. On the **ConfigMaps** page, select `kubesphere-devops-system` from the drop-down list and click `jenkins-casc-config`.
+
+4. On the details page, click **Edit YAML** from the **More** drop-down list.
+
+5. The configuration template for `jenkins-casc-config` is a YAML file under the `data.jenkins_user.yaml:` section. You can modify the container image, label, resource requests and limits, etc. in the broker (Kubernetes Jenkins agent) in the ConfigMap or add a container in the podTemplate. When you finish, click **OK**.
+
+6. Wait for at least 70 seconds until your changes are automatically reloaded.
+
+7. For more information about how to set up Jenkins via CasC, see the [Jenkins documentation](https://github.com/jenkinsci/configuration-as-code-plugin).
+
+ {{< notice note >}}
+
+ In the current version, not all plugins support CasC settings. CasC will only overwrite plugin configurations that are set up through CasC.
+
+ {{}}
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md
new file mode 100644
index 000000000..def58cf76
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md
@@ -0,0 +1,122 @@
+---
+title: "Use Jenkins Shared Libraries in a Pipeline"
+keywords: 'KubeSphere, Kubernetes, Jenkins, Shared Library, Pipelines'
+description: 'Learn how to use Jenkins shared libraries in a pipeline.'
+linkTitle: "Use Jenkins Shared Libraries in a Pipeline"
+weight: 11217
+---
+
+For Jenkins pipelines that contain the same stages or steps, one way to avoid repetition in the pipeline codes is to use Jenkins shared libraries in the Jenkinsfiles.
+
+This tutorial demonstrates how to use Jenkins shared libraries in KubeSphere DevOps pipelines.
+
+## Prerequisites
+
+- You need to [enable the KubeSphere DevOps system](../../../../pluggable-components/devops/).
+- You need to create a workspace, a DevOps project and a user (`project-regular`). This user must be invited to the DevOps project with the `operator` role. For more information, refer to [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+- You need to have a Jenkins shared library available. This tutorial uses the Jenkins shared library in [a GitHub repository](https://github.com/devops-ws/jenkins-shared-library) as an example.
+
+## Configure a Shared Library on the Jenkins Dashboard
+
+1. [Log in to the Jenkins dashboard](../../../how-to-integrate/sonarqube/#step-5-add-the-sonarqube-server-to-jenkins) and click **Manage Jenkins** in the left navigation pane.
+
+2. Scroll down and click **Configure System**.
+
+3. Scroll down to **Global Pipeline Libraries** and click **Add**.
+
+4. Configure the fields as below.
+
+ - **Name**. Set a name (for example, `demo-shared-library`) for the shared library so that you can import the shared library by referring to this name in a Jenkinsfile.
+
+ - **Default version**. Set a branch name from the repository where you put your shared library as the default branch for importing your shared library. Enter `master` for this tutorial.
+
+ - Under **Retrieval method**, select **Modern SCM**.
+
+ - Under **Source Code Management**, select **Git** and enter the URL of the example repository for **Project Repository**. You have to configure **Credentials** if you use your own repository that requires the credentials for accessing it.
+
+5. When you finish editing, click **Apply**.
+
+ {{< notice note >}}
+
+ You can also configure [Folder-level Shared Libraries](https://www.jenkins.io/doc/book/pipeline/shared-libraries/#folder-level-shared-libraries).
+
+ {{}}
+
+## Use the Shared Library in a Pipeline
+
+### Step 1: Create a pipeline
+
+1. Log in to the KubeSphere web console as `project-regular`. Go to your DevOps project and click **Create** on the **Pipelines** page.
+
+2. Set a name (for example, `demo-shared-library`) in the displayed dialog box and click **Next**.
+
+3. On the **Advanced Settings** tab, click **Create** to create a pipeline with the default settings.
+
+### Step 2: Edit the pipeline
+
+1. In the pipeline list, click the pipeline to go to its details page and click **Edit Jenkinsfile**.
+
+2. In the displayed dialog box, enter the following example Jenkinsfile. When you finish editing, click **OK**.
+
+ ```groovy
+ library identifier: 'devops-ws-demo@master', retriever: modernSCM([
+ $class: 'GitSCMSource',
+ remote: 'https://github.com/devops-ws/jenkins-shared-library',
+ traits: [[$class: 'jenkins.plugins.git.traits.BranchDiscoveryTrait']]
+ ])
+
+ pipeline {
+ agent any
+
+ stages {
+ stage('Demo') {
+ steps {
+ script {
+ mvn.fake()
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ {{< notice note >}}
+
+ You can specify a `label` for `agent` based on your needs.
+
+ {{}}
+
+3. Alternatively, you can use a Jenkinsfile starting with `@Library('
to edit the file. For example, change the value of `spec.replicas` to `3`.
+
+4. Click **Commit changes** at the bottom of the page.
+
+### Check the webhook deliveries
+
+1. On the **Webhooks** page of your own repository, click the webhook.
+
+2. Click **Recent Deliveries** and click a specific delivery record to view its details.
+
+### Check the pipeline
+
+1. Log in to the KubeSphere web console as `project-regular`. Go to your DevOps project and click the pipeline.
+
+2. On the **Run Records** tab, check that a new run is triggered by the pull request submitted to the `sonarqube` branch of the remote repository.
+
+3. Go to the **Pods** page of the project `kubesphere-sample-dev` and check the status of the 3 Pods. If the status of the 3 Pods is running, the pipeline is running properly.
+
+
+
diff --git a/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md
new file mode 100644
index 000000000..fcdb34cec
--- /dev/null
+++ b/content/en/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md
@@ -0,0 +1,104 @@
+---
+title: "Use Pipeline Templates"
+keywords: 'KubeSphere, Kubernetes, Jenkins, Graphical Pipelines, Pipeline Templates'
+description: 'Understand how to use pipeline templates on KubeSphere.'
+linkTitle: "Use Pipeline Templates"
+weight: 11213
+---
+
+KubeSphere offers a graphical editing panel where the stages and steps of a Jenkins pipeline can be defined through interactive operations. KubeSphere 3.3 provides built-in pipeline templates, such as Node.js, Maven, and Golang, to help users quickly create pipelines. Additionally, KubeSphere 3.3 also supports customization of pipeline templates to meet diversified needs of enterprises.
+
+This section describes how to use pipeline templates on KubeSphere.
+## Prerequisites
+
+- You have a workspace, a DevOps project and a user (`project-regular`) invited to the DevOps project with the `operator` role. If they are not ready yet, please refer to [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+- You need to [enable the KubeSphere DevOps system](../../../../pluggable-components/devops/).
+
+- You need to [create a pipeline](../../../how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel/).
+
+## Use a Built-in Pipeline Template
+
+The following takes Node.js as an example to show how to use a built-in pipeline template. Steps for using Maven and Golang pipeline templates are alike.
+
+
+1. Log in to the KubeSphere console as `project-regular`. In the navigation pane on the left, click **DevOps Projects**.
+
+2. On the **DevOps Projects** page, click the DevOps project you created.
+
+3. In the navigation pane on the left, click **Pipelines**.
+
+4. On the pipeline list on the right, click the created pipeline to go to its details page.
+
+5. On the right pane, click **Edit Pipeline**.
+
+6. On the **Create Pipeline** dialog box, click **Node.js**, and then click **Next**.
+
+
+7. On the **Parameter Settings** tab, set the parameters based on the actual situation, and then click **Create**.
+
+ | Parameter | Meaning |
+ | ----------- | ------------------------- |
+ | GitURL | URL of the project repository to clone |
+ | GitRevision | Revision to check out from |
+ | NodeDockerImage | Docker image version of Node.js |
+ | InstallScript | Shell script for installing dependencies |
+ | TestScript | Shell script for testing |
+ | BuildScript | Shell script for building a project |
+ | ArtifactsPath | Path where the artifacts reside |
+
+8. On the left pane, the system has preset several steps, and you can add more steps and parallel stages.
+
+9. Click a specific step. On the right pane, you can perform the following operations:
+ - Change the stage name.
+ - Delete a stage.
+ - Set the agent type.
+ - Add conditions.
+ - Edit or delete a task.
+ - Add steps or nested steps.
+
+ {{< notice note >}}
+
+ You can also customize the stages and steps in the pipeline templates based on your needs. For more information about how to use the graphical editing panel, refer to [Create a Pipeline Using Graphical Editing Panels](../create-a-pipeline-using-graphical-editing-panel/).
+ {{}}
+
+10. On the **Agent** area on the left, select an agent type, and click **OK**. The default value is **kubernetes**.
+
+ The following table explains the agent types.
+
+
+ | Agent Type | Description |
+ | --------------- | ------------------------- |
+ | any | Uses the default base pod template to create a Jenkins agent to run pipelines. |
+ | node | Uses a pod template with the specific label to create a Jenkins agent to run pipelines. Available labels include base, java, nodejs, maven, go, and more. |
+ | kubernetes | Use a yaml file to customize a standard Kubernetes pod template to create a jenkins agent to run pipelines. |
+
+11. On the pipeline details page, you can view the created pipeline template. Click **Run** to run the pipeline.
+
+## Legacy Built-in Pipeline Templates
+
+In earlier versions, KubeSphere also provides the CI and CI & CD pipeline templates. However, as the two templates are hardly customizable, you are advised to use the Node.js, Maven, or Golang pipeline template, or directly customize a template based on your needs.
+The following briefly introduces the CI and CI & CD pipeline templates.
+
+- CI pipeline template
+
+ 
+
+ 
+
+ The CI pipeline template contains two stages. The **clone code** stage checks out code and the **build & push** stage builds an image and pushes it to Docker Hub. You need to create credentials for your code repository and your Docker Hub registry in advance, and then set the URL of your repository and these credentials in corresponding steps. After you finish editing, the pipeline is ready to run.
+
+- CI & CD pipeline template
+
+ 
+
+ 
+
+ The CI & CD pipeline template contains six stages. For more information about each stage, refer to [Create a Pipeline Using a Jenkinsfile](../create-a-pipeline-using-jenkinsfile/#pipeline-overview), where you can find similar stages and the descriptions. You need to create credentials for your code repository, your Docker Hub registry, and the kubeconfig of your cluster in advance, and then set the URL of your repository and these credentials in corresponding steps. After you finish editing, the pipeline is ready to run.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/faq/_index.md b/content/en/docs/v3.4/faq/_index.md
new file mode 100644
index 000000000..753d10890
--- /dev/null
+++ b/content/en/docs/v3.4/faq/_index.md
@@ -0,0 +1,12 @@
+---
+title: "FAQ"
+description: "FAQ is designed to answer and summarize the questions users ask most frequently about KubeSphere."
+layout: "second"
+
+linkTitle: "FAQ"
+weight: 16000
+
+icon: "/images/docs/v3.3/docs.svg"
+---
+
+This chapter answers and summarizes the questions users ask most frequently about KubeSphere. You can find these questions and answers in their respective sections which are grouped based on KubeSphere functions.
diff --git a/content/en/docs/v3.4/faq/access-control/_index.md b/content/en/docs/v3.4/faq/access-control/_index.md
new file mode 100644
index 000000000..e36af958d
--- /dev/null
+++ b/content/en/docs/v3.4/faq/access-control/_index.md
@@ -0,0 +1,7 @@
+---
+title: "Access Control and Account Management FAQ"
+keywords: 'Kubernetes, KubeSphere, account, access control'
+description: 'Faq about access control and account management'
+layout: "second"
+weight: 16400
+---
diff --git a/content/en/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md b/content/en/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
new file mode 100644
index 000000000..e887f6b72
--- /dev/null
+++ b/content/en/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
@@ -0,0 +1,38 @@
+---
+title: "Add Existing Kubernetes Namespaces to a KubeSphere Workspace"
+keywords: "namespace, project, KubeSphere, Kubernetes"
+description: "Add your existing Kubernetes namespaces to a KubeSphere workspace."
+linkTitle: "Add existing Kubernetes namespaces to a KubeSphere Workspace"
+Weight: 16430
+---
+
+A Kubernetes namespace is a KubeSphere project. If you create a namespace object not from the KubeSphere console, the namespace does not appear directly in a certain workspace. But cluster administrators can still see the namespace on the **Cluster Management** page. At the same time, you can also place the namespace into a workspace.
+
+This tutorial demonstrates how to add an existing Kubernetes namespace to a KubeSphere workspace.
+
+## Prerequisites
+
+- You need a user granted a role including the permission of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the permission and assign it to a user.
+
+- You have an available workspace so that the namespace can be assigned to it. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Kubernetes Namespace
+
+Create an example Kubernetes namespace first so that you can add it to a workspace later. Execute the following command:
+
+```bash
+kubectl create ns demo-namespace
+```
+
+For more information about creating a Kubernetes namespace, see [Namespaces Walkthrough](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/).
+
+## Add the Namespace to a KubeSphere Workspace
+
+1. Log in to the KubeSphere console as `admin` and go to the **Cluster Management** page. Click **Projects**, and you can see all your projects running on the current cluster, including the one just created.
+
+2. The namespace created through kubectl does not belong to any workspace. Click 
on the right and select **Assign Workspace**.
+
+3. In the dialog that appears, select a **Workspace** and a **Project Administrator** for the project and click **OK**.
+
+4. Go to your workspace and you can see the project on the **Projects** page.
+
diff --git a/content/en/docs/v3.4/faq/access-control/cannot-login.md b/content/en/docs/v3.4/faq/access-control/cannot-login.md
new file mode 100644
index 000000000..ba0d8bd39
--- /dev/null
+++ b/content/en/docs/v3.4/faq/access-control/cannot-login.md
@@ -0,0 +1,141 @@
+---
+title: "User Login Failure"
+keywords: "login failure, user is not active, KubeSphere, Kubernetes"
+description: "How to solve the issue of login failure"
+linkTitle: "User Login Failure"
+Weight: 16440
+---
+
+KubeSphere automatically creates a default user (`admin/P@88w0rd`) when it is installed. A user cannot be used for login if the status is not **Active** or you use an incorrect password.
+
+Here are some of the frequently asked questions about user login failure.
+
+## User Not Active
+
+You may see an image below when the login fails. To find out the reason and solve the issue, perform the following steps:
+
+
+
+1. Execute the following command to check the status of the user.
+
+ ```bash
+ $ kubectl get users
+ NAME EMAIL STATUS
+ admin admin@kubesphere.io Active
+ ```
+
+2. Verify that `ks-controller-manager` is running and check if exceptions are contained in logs:
+
+ ```bash
+ kubectl -n kubesphere-system logs -l app=ks-controller-manager
+ ```
+
+Here are some possible reasons for this issue.
+
+### Admission webhooks malfunction in Kubernetes 1.19
+
+Kubernetes 1.19 uses Golang 1.15 in coding, requiring the certificate for admission webhooks to be updated. This causes the failure of `ks-controller` admission webhook.
+
+Related error logs:
+
+```bash
+Internal error occurred: failed calling webhook "validating-user.kubesphere.io": Post "https://ks-controller-manager.kubesphere-system.svc:443/validate-email-iam-kubesphere-io-v1alpha2-user?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
+```
+
+For more information about the issue and solution, see this [GitHub issue](https://github.com/kubesphere/kubesphere/issues/2928).
+
+### ks-controller-manager malfunctions
+
+`ks-controller-manager` relies on two stateful Services: OpenLDAP and Jenkins. When OpenLDAP or Jenkins goes down, `ks-controller-manager` will be in the status of `reconcile`.
+
+Execute the following commands to verify that OpenLDAP and Jenkins are running normally.
+
+```
+kubectl -n kubesphere-devops-system get po | grep -v Running
+kubectl -n kubesphere-system get po | grep -v Running
+kubectl -n kubesphere-system logs -l app=openldap
+```
+
+Related error logs:
+
+```bash
+failed to connect to ldap service, please check ldap status, error: factory is not able to fill the pool: LDAP Result Code 200 \"Network Error\": dial tcp: lookup openldap.kubesphere-system.svc on 169.254.25.10:53: no such host
+```
+
+```bash
+Internal error occurred: failed calling webhook “validating-user.kubesphere.io”: Post https://ks-controller-manager.kubesphere-system.svc:443/validate-email-iam-kubesphere-io-v1alpha2-user?timeout=4s: context deadline exceeded
+```
+
+#### Solution
+
+You need to restore OpenLDAP and Jenkins with good network connection, and then restart `ks-controller-manager`.
+
+```
+kubectl -n kubesphere-system rollout restart deploy ks-controller-manager
+```
+
+### Wrong code branch used
+
+If you used the incorrect version of ks-installer, the versions of different components would not match after the installation. Execute the following commands to check version consistency. Note that the correct image tag is `v3.3.2`.
+
+```
+kubectl -n kubesphere-system get deploy ks-installer -o jsonpath='{.spec.template.spec.containers[0].image}'
+kubectl -n kubesphere-system get deploy ks-apiserver -o jsonpath='{.spec.template.spec.containers[0].image}'
+kubectl -n kubesphere-system get deploy ks-controller-manager -o jsonpath='{.spec.template.spec.containers[0].image}'
+```
+
+## Wrong Username or Password
+
+
+
+Run the following command to verify that the username and the password are correct.
+
+```
+curl -u 
to save it.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/faq/console/console-web-browser.md b/content/en/docs/v3.4/faq/console/console-web-browser.md
new file mode 100644
index 000000000..3e632c6ae
--- /dev/null
+++ b/content/en/docs/v3.4/faq/console/console-web-browser.md
@@ -0,0 +1,11 @@
+---
+title: "Supported Browsers"
+keywords: "FAQ, console, KubeSphere, Kubernetes"
+description: "Use a supported web browser to access the console."
+linkTitle: "Supported Browsers"
+Weight: 16510
+---
+
+The KubeSphere web console supports major web browsers including **Chrome, Firefox, Safari, Opera, and Edge.** You only need to consider the supported versions of these browsers listed in the green box of the table below:
+
+
diff --git a/content/en/docs/v3.4/faq/console/edit-resources-in-system-workspace.md b/content/en/docs/v3.4/faq/console/edit-resources-in-system-workspace.md
new file mode 100644
index 000000000..d39e72e7d
--- /dev/null
+++ b/content/en/docs/v3.4/faq/console/edit-resources-in-system-workspace.md
@@ -0,0 +1,50 @@
+---
+title: "Edit System Resources on the Console"
+keywords: "system, resources, KubeSphere, Kubernetes"
+description: "Enable the editing function of system resources on the console."
+linkTitle: 'Edit System Resources on the Console'
+Weight: 16520
+---
+
+When you install KubeSphere, the workspace `system-workspace` is created where all KubeSphere system projects and Kubernetes system projects run. To avoid any misoperation on both systems, you are not allowed to edit resources in the workspace directly on the console. However, you can still make adjustments to resources using `kubectl`.
+
+This tutorial demonstrates how to enable the editing function of `system-workspace` resources.
+
+{{< notice warning >}}
+
+Editing resources in `system-workspace` may cause unexpected results, such as KubeSphere system and node failures, and your business may be affected. Please be extremely careful about the operation.
+
+{{}}
+
+## Edit the Console Configuration
+
+1. Log in to KubeSphere as `admin`. Click in the lower-right corner and select **Kubectl**.
+
+2. Execute the following command:
+
+ ```bash
+ kubectl -n kubesphere-system edit cm ks-console-config
+ ```
+
+3. Add the `systemWorkspace` field under `client` and save the file.
+
+ ```yaml
+ client:
+ version:
+ kubesphere: v3.3.2
+ kubernetes: v1.22.12
+ openpitrix: v3.3.2
+ enableKubeConfig: true
+ systemWorkspace: "$" # Add this line manually.
+ ```
+
+4. Redeploy `ks-console` by executing the following command and wait for Pods to be recreated.
+
+ ```bash
+ kubectl -n kubesphere-system rollout restart deployment ks-console
+ ```
+
+5. Refresh the KubeSphere console and you can see that editing buttons in projects in `system-workspace` appear.
+
+6. If you want to disable the editing function on the console, delete the field `systemWorkspace` by following the same steps above.
+
diff --git a/content/en/docs/v3.4/faq/devops/_index.md b/content/en/docs/v3.4/faq/devops/_index.md
new file mode 100644
index 000000000..79fb04523
--- /dev/null
+++ b/content/en/docs/v3.4/faq/devops/_index.md
@@ -0,0 +1,7 @@
+---
+title: "DevOps"
+keywords: 'Kubernetes, KubeSphere, DevOps, Jenkins'
+description: 'FAQ about DevOps in KubeSphere'
+layout: "second"
+weight: 16800
+---
diff --git a/content/en/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md b/content/en/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md
new file mode 100644
index 000000000..266f02a08
--- /dev/null
+++ b/content/en/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md
@@ -0,0 +1,106 @@
+---
+title: "Create a DevOps Kubeconfig on AWS"
+keywords: "KubeSphere, Kubernetes, DevOps, Kubeconfig, AWS"
+description: "How to create a DevOps kubeconfig on AWS"
+linkTitle: "Create a DevOps Kubeconfig on AWS"
+Weight: 16820
+---
+
+If you have trouble deploying applications into your project when running a pipeline on your AWS cluster with KubeSphere installed, it may be caused by the issue of DevOps kubeconfig. This tutorial demonstrates how to create a DevOps kubeconfig on AWS.
+
+## Prerequisites
+
+- You have an AWS cluster with KubeSphere installed. For more information about how to install KubeSphere on AWS, refer to [Deploy KubeSphere on AWS EKS](../../../installing-on-kubernetes/hosted-kubernetes/install-kubesphere-on-eks/).
+- You have enabled [the KubeSphere DevOps system](../../../pluggable-components/devops/).
+- You have a project available for deploying applications. This tutorial uses the project `kubesphere-sample-dev` as an example.
+
+## Create a DevOps Kubeconfig
+
+### Step 1: Create a Service Account
+
+1. Create a `devops-deploy.yaml` file on your AWS cluster and enter the following contents.
+
+ ```yaml
+ ---
+ apiVersion: v1
+ kind: ServiceAccount
+ metadata:
+ name: devops-deploy
+ namespace: kubesphere-sample-dev
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: Role
+ metadata:
+ name: devops-deploy-role
+ namespace: kubesphere-sample-dev
+ rules:
+ - apiGroups:
+ - "*"
+ resources:
+ - "*"
+ verbs:
+ - "*"
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: RoleBinding
+ metadata:
+ name: devops-deploy-rolebinding
+ namespace: kubesphere-sample-dev
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: Role
+ name: devops-deploy-role
+ subjects:
+ - kind: ServiceAccount
+ name: devops-deploy
+ namespace: kubesphere-sample-dev
+ ```
+
+2. Run the following command to apply the YAML file.
+
+ ```bash
+ kubectl apply -f devops-deploy.yaml
+ ```
+
+### Step 2: Get the Service Account Token
+
+1. Run the following command to get the Service Account token.
+
+ ```bash
+ export TOKEN_NAME=$(kubectl -n kubesphere-sample-dev get sa devops-deploy -o jsonpath='{.secrets[0].name}')
+ kubectl -n kubesphere-sample-dev get secret "${TOKEN_NAME}" -o jsonpath='{.data.token}' | base64 -d
+ ```
+
+2. The output is similar to the following:
+
+ 
+
+### Step 3: Create a DevOps kubeconfig
+
+1. Log in to your KubeSphere console of the AWS cluster and go to your DevOps project. Go to **Credentials** under **DevOps Project Settings**, and then click **Create**. You can name this kubeconfig based on your needs.
+
+2. In the **Content** text box, pay attention to the following contents:
+
+ ```
+ user:
+ client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FUR...
+ client-key-data: LS0tLS1CRUdJTiBQUk...
+ ```
+
+ You have to replace them with the token retrieved in step 2, then click **OK** to create the kubeconfig.
+
+ ```bash
+ user:
+ token:eyJhbGciOiJSUzI1NiIsImtpZCI6Ikl3UkhCay13dHpPY2Z6LW9VTlZKQVR6dVdmb2FHallJQ2E4VzJULUNjUzAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlc3BoZXJlLXNhbXBsZS1kZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGV2b3BzLWRlcGxveS10b2tlbi1kcGY2ZiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZXZvcHMtZGVwbG95Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMjM0ZTI4OTUtMjM3YS00M2Y5LTkwMTgtZDg4YjY2YTQyNzVmIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmVzcGhlcmUtc2FtcGxlLWRldjpkZXZvcHMtZGVwbG95In0.Ls6mkpgAU75zVw87FkcWx-MLEXGcJjlnb4rUVtT61Jmc_G6jkn4X45MK1V_HuLje3JZMFjL80QUl5ljHLiCUPQ7oE5AUZaUCdqZVdDYEhqeFuGQb_7Qlh8-UFVGGg8vrb0HeGiOlS0qq5hzwKc9C1OmsXHS92yhNwz9gIOujZRafnGKIsG6TL2hEVY2xI0vvmseDKmKg5o0TbeaTMVePHvECju9Qz3Z7TUYsr7HAOvCPtGutlPWLqGx5uOHenOdeLn71x5RoS98xguZoxYVollciPKCQwBlZ4zWK2hzsLSNNLb9cZpxtgUVyHE0AB0e86IHRngnnNrzpp1_pDxL5jw/
+ ```
+
+ {{< notice note >}}
+
+ Make sure you use your own token.
+
+ {{}}
+
+
+
+
+
diff --git a/content/en/docs/v3.4/faq/devops/install-jenkins-plugins.md b/content/en/docs/v3.4/faq/devops/install-jenkins-plugins.md
new file mode 100644
index 000000000..dfa608ee4
--- /dev/null
+++ b/content/en/docs/v3.4/faq/devops/install-jenkins-plugins.md
@@ -0,0 +1,67 @@
+---
+title: "Install Plugins to Jenkins in KubeSphere"
+keywords: "KubeSphere, Kubernetes, DevOps, Jenkins, Plugin"
+description: "How to install plugins to Jenkins in KubeSphere"
+linkTitle: "Install Plugins to Jenkins in KubeSphere"
+Weight: 16810
+---
+
+The KubeSphere DevOps System offers containerized CI/CD functions based on Jenkins. The primary means of enhancing the functionality of Jenkins is to install plugins. This tutorial demonstrates how to install plugins on the Jenkins dashboard.
+
+{{< notice warning >}}
+
+Not all Jenkins plugins have good maintaining support. Some plugins may lead to issues in Jenkins or even cause serious problems in KubeSphere. It is highly recommended that you make a backup before installing any plugin and run testing in another environment if you can.
+
+{{}}
+
+## Prerequisites
+
+You need to enable [the KubeSphere DevOps system](../../../pluggable-components/devops/).
+
+## Install Plugins
+
+### Step 1: Get the address of Jenkins
+
+1. Run the following command to get the address of Jenkins.
+
+ ```bash
+ export NODE_PORT=$(kubectl get --namespace kubesphere-devops-system -o jsonpath="{.spec.ports[0].nodePort}" services devops-jenkins)
+ export NODE_IP=$(kubectl get nodes --namespace kubesphere-devops-system -o jsonpath="{.items[0].status.addresses[0].address}")
+ echo http://$NODE_IP:$NODE_PORT
+ ```
+
+2. You can get the output similar to the following. You can access the Jenkins dashboard through the address with your own KubeSphere account and password (for example, `admin/P@88w0rd`).
+
+ ```
+ http://192.168.0.4:30180
+ ```
+
+ {{< notice note >}}
+
+ Make sure you use your own address of Jenkins. You may also need to open the port in your security groups and configure related port forwarding rules depending on where your KubeSphere cluster is deployed.
+
+ {{}}
+
+### Step 2: Install plugins on the Jenkins dashboard
+
+1. Log in to the Jenkins dashboard and click **Manage Jenkins**.
+
+2. On the **Manage Jenkins** page, scroll down to **Manage Plugins** and click it.
+
+3. Select the **Available** tab and you have to use the search field to search for the plugins you need. For example, you can enter `git` in the search field, check the checkbox next to the plugin you need, and then click **Install without restart** or **Download now and install after restart** based on your needs.
+
+ {{< notice note >}}
+
+ Jenkins plugins are inter-dependent. You may also need to install dependencies when you install a plugin.
+
+ {{}}
+
+4. If you downloaded an HPI file in advance, you can also select the **Advanced** tab and upload the HPI file to install it as a plugin.
+
+5. On the **Installed** tab, you can view all the plugins installed, and the plugins that are safe to uninstall will have the **Uninstall** button shown on the right.
+
+6. On the **Updates** tab, you can install the updates for plugins by checking the checkbox of a plugin and then click the **Download now and install after restart** button. You can also click the **Check now** button to check for updates.
+
+## See Also
+
+[Managing Plugins](https://www.jenkins.io/doc/book/managing/plugins/)
\ No newline at end of file
diff --git a/content/en/docs/v3.4/faq/installation/_index.md b/content/en/docs/v3.4/faq/installation/_index.md
new file mode 100644
index 000000000..3030de69b
--- /dev/null
+++ b/content/en/docs/v3.4/faq/installation/_index.md
@@ -0,0 +1,7 @@
+---
+title: "Installation"
+keywords: 'Kubernetes, KubeSphere, installation, FAQ'
+description: 'Faq about installation'
+layout: "second"
+weight: 16100
+---
diff --git a/content/en/docs/v3.4/faq/installation/configure-booster.md b/content/en/docs/v3.4/faq/installation/configure-booster.md
new file mode 100644
index 000000000..5c002d0b2
--- /dev/null
+++ b/content/en/docs/v3.4/faq/installation/configure-booster.md
@@ -0,0 +1,84 @@
+---
+title: "Configure a Booster for Installation"
+keywords: 'KubeSphere, booster, installation, faq'
+description: 'Set a registry mirror to speed up image downloads during installation.'
+linkTitle: "Configure a Booster for Installation"
+weight: 16200
+---
+
+If you have trouble downloading images from `dockerhub.io`, it is highly recommended that you configure a registry mirror (i.e. booster) beforehand to speed up downloads. You can refer to the [official documentation of Docker](https://docs.docker.com/registry/recipes/mirror/#configure-the-docker-daemon) or follow the steps below.
+
+## Get a Booster URL
+
+To configure the booster, you need a registry mirror address. See how you can [get a booster URL from Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/60750.htm?spm=a2c63.p38356.b99.18.4f4133f0uTKb8S).
+
+## Set the Registry Mirror
+
+You can configure the Docker daemon directly or use KubeKey to set the configuration.
+
+### Configure the Docker daemon
+
+{{< notice note >}}
+
+Docker needs to be installed in advance for this method.
+
+{{}}
+
+1. Run the following commands:
+
+ ```bash
+ sudo mkdir -p /etc/docker
+ ```
+
+ ```bash
+ sudo vi /etc/docker/daemon.json
+ ```
+
+2. Add the `registry-mirrors` key and value to the file.
+
+ ```json
+ {
+ "registry-mirrors": ["https://
on the right of `ks-installer` and select **Edit YAML**.
+
+5. Scroll down to the bottom of the file, add `telemetry_enabled: false`, and then click **OK**.
+
+
+{{< notice note >}}
+
+If you want to enable Telemetry again, you can update `ks-installer` by deleting `telemetry_enabled: false` or changing it to `telemetry_enabled: true`.
+
+{{}}
diff --git a/content/en/docs/v3.4/faq/multi-cluster-management/_index.md b/content/en/docs/v3.4/faq/multi-cluster-management/_index.md
new file mode 100644
index 000000000..05c8c18b9
--- /dev/null
+++ b/content/en/docs/v3.4/faq/multi-cluster-management/_index.md
@@ -0,0 +1,7 @@
+---
+title: "Multi-cluster Management"
+keywords: 'Kubernetes, KubeSphere, Multi-cluster Management, Host Cluster, Member Cluster'
+description: 'Faq about multi-cluster management in KubeSphere'
+layout: "second"
+weight: 16700
+---
diff --git a/content/en/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md b/content/en/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md
new file mode 100644
index 000000000..bd93b4c8b
--- /dev/null
+++ b/content/en/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md
@@ -0,0 +1,71 @@
+---
+title: "Restore the Host Cluster Access to A Member Cluster"
+keywords: "Kubernetes, KubeSphere, Multi-cluster, Host Cluster, Member Cluster"
+description: "Learn how to restore the Host Cluster access to a Member Cluster."
+linkTitle: "Restore the Host Cluster Access to A Member Cluster"
+Weight: 16720
+---
+
+KubeSphere features [multi-cluster maganement](../../../multicluster-management/introduction/kubefed-in-kubesphere/) and tenants with necessary permissions (usually cluster administrators) can access the central control plane from the Host Cluster to manage all the Member Clusters. It is highly recommended that you manage your resources across your cluster through the Host Cluster.
+
+This tutorial demomstrates how to restore the Host Cluster access to a Member Cluster.
+
+## Possible Error Message
+
+If you can't access a Member Cluster from the central control plane and your browser keeps redirecting you to the login page of KubeSphere, run the following command on that Member Cluster to get the logs of the ks-apiserver.
+
+```
+kubectl -n kubesphere-system logs ks-apiserver-7c9c9456bd-qv6bs
+```
+
+{{< notice note >}}
+
+`ks-apiserver-7c9c9456bd-qv6bs` refers to the Pod ID on that Member Cluster. Make sure you use the ID of your own Pod.
+
+{{}}
+
+You will probably see the following error message:
+
+```
+E0305 03:46:42.105625 1 token.go:65] token not found in cache
+E0305 03:46:42.105725 1 jwt_token.go:45] token not found in cache
+E0305 03:46:42.105759 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+E0305 03:46:52.045964 1 token.go:65] token not found in cache
+E0305 03:46:52.045992 1 jwt_token.go:45] token not found in cache
+E0305 03:46:52.046004 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+E0305 03:47:34.502726 1 token.go:65] token not found in cache
+E0305 03:47:34.502751 1 jwt_token.go:45] token not found in cache
+E0305 03:47:34.502764 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+```
+
+## Solution
+
+### Step 1: Verify the jwtSecret
+
+Run the following command on your Host Cluster and Member Cluser respectively to confirm whether their jwtSecrets are identical.
+
+```
+kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v “apiVersion” | grep jwtSecret
+```
+
+### Step 2: Modify `accessTokenMaxAge`
+
+Make sure the jwtSecrets are identical, then run the following command on that Member Cluster to get the value of `accessTokenMaxAge`.
+
+```
+kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v "apiVersion" | grep accessTokenMaxAge
+```
+
+If the value is not `0`, run the following command to modify the value of `accessTokenMaxAge`.
+
+```
+kubectl -n kubesphere-system edit cm kubesphere-config -o yaml
+```
+
+After you modified the value of `accessTokenMaxAge` to `0`, run the following command to restart the ks-apiserver.
+
+```
+kubectl -n kubesphere-system rollout restart deploy ks-apiserver
+```
+
+Now, you can access that Member Cluster from the central control plane again.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md b/content/en/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md
new file mode 100644
index 000000000..5bb132e42
--- /dev/null
+++ b/content/en/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md
@@ -0,0 +1,61 @@
+---
+title: "Manage a Multi-cluster Environment on KubeSphere"
+keywords: 'Kubernetes, KubeSphere, federation, multicluster, hybrid-cloud'
+description: 'Understand how to manage a multi-cluster environment on KubeSphere.'
+linkTitle: "Manage a Multi-cluster Environment on KubeSphere"
+weight: 16710
+---
+
+KubeSphere provides an easy-to-use multi-cluster feature to help you [build your multi-cluster environment on KubeSphere](../../../multicluster-management/). This guide illustrates how to manage a multi-cluster environment on KubeSphere.
+
+## Prerequisites
+
+- Make sure your Kubernetes clusters are installed with KubeSphere before you use them as your Host Cluster and Member Clusters.
+
+- Make sure the cluster role is set correctly on your Host Cluster and Member Clusters respectively, and the `jwtSecret` is the same between them.
+
+- It is recommended that your Member Cluster is in a clean environment where no resources have been created on it before it is imported to the Host Cluster.
+
+
+## Manage your KubeSphere Multi-cluster Environment
+
+Once you build a multi-cluster environment on KubeSphere, you can manage it through the central control plane from your Host Cluster. When creating resources, you can select a specific cluster while the Host Cluster should be avoided in case of overload. It is not recommended to log in to the KubeSphere web console of your Member Clusters to create resources on them as some resources (for example, workspaces) won't be synchronized to your Host Cluster for management.
+
+### Resource Management
+
+It is not recommended that you change a Host Cluster to a Member Cluster or the other way round. If a Member Cluster has been imported to a Host Cluster before, you have to use the same cluster name when importing it to a new Host Cluster after unbinding it from the previous Host Cluster.
+
+If you want to import the Member Cluster to a new Host Cluster while retaining existing projects, you can follow the steps as below.
+
+1. Run the following command on the Member Cluster to unbind the projects to be retained from your workspace.
+
+ ```bash
+ kubectl label ns on the right of ks-installer, and click **Edit YAML**.
+
+5. Search for **metrics_server**, and change the value of `enabled` from `false` to `true`.
+
+ ```yaml
+ metrics_server:
+ enabled: true # Change "false" to "true".
+ ```
+
+6. Click **OK** in the lower right corner to save the change.
+
+7. Open the `/etc/kubeedge/config` file, search for `edgeStream`, change `false` to `true`, and save the change.
+ ```bash
+ cd /etc/kubeedge/config
+ vi edgecore.yaml
+ ```
+
+ ```bash
+ edgeStream:
+ enable: true #Change "false" to "true".。
+ handshakeTimeout: 30
+ readDeadline: 15
+ server: xx.xxx.xxx.xxx:10004 #If port forwarding is not configured, change the port ID to 30004 here.
+ tlsTunnelCAFile: /etc/kubeedge/ca/rootCA.crt
+ tlsTunnelCertFile: /etc/kubeedge/certs/server.crt
+ tlsTunnelPrivateKeyFile: /etc/kubeedge/certs/server.key
+ writeDeadline: 15
+ ```
+
+8. Run the following command to restart `edgecore.service`.
+ ```bash
+ systemctl restart edgecore.service
+ ```
+
+9. If you still cannot see the monitoring data, run the following command:
+
+ ```bash
+ journalctl -u edgecore.service -b -r
+ ```
+
+ {{< notice note >}}
+
+ If `failed to check the running environment: kube-proxy should not running on edge node when running edgecore` is displayed, refer to Step 8 to restart `edgecore.service` again.
+
+ {{}}
+
+## Remove an Edge Node
+
+Before you remove an edge node, delete all your workloads running on it.
+
+1. On your edge node, run the following commands:
+
+ ```bash
+ ./keadm reset
+ ```
+
+ ```
+ apt remove mosquitto
+ ```
+
+ ```bash
+ rm -rf /var/lib/kubeedge /var/lib/edged /etc/kubeedge/ca /etc/kubeedge/certs
+ ```
+
+ {{< notice note >}}
+
+ If you cannot delete the tmpfs-mounted folder, restart the node or unmount the folder first.
+
+ {{}}
+
+2. Run the following command to remove the edge node from your cluster:
+
+ ```bash
+ kubectl delete node | Parameter | +Description | +
|---|---|
kubernetes |
+ |
version |
+ The Kubernetes version to be installed. If you do not specify a Kubernetes version, {{< contentLink "docs/installing-on-linux/introduction/kubekey" "KubeKey" >}} v3.0.7 will install Kubernetes v1.23.10 by default. For more information, see {{< contentLink "docs/installing-on-linux/introduction/kubekey/#support-matrix" "Support Matrix" >}}. | +
imageRepo |
+ The Docker Hub repository where images will be downloaded. | +
clusterName |
+ The Kubernetes cluster name. | +
masqueradeAll* |
+ masqueradeAll tells kube-proxy to SNAT everything if using the pure iptables proxy mode. It defaults to false. |
+
maxPods* |
+ The maximum number of Pods that can run on this Kubelet. It defaults to 110. |
+
nodeCidrMaskSize* |
+ The mask size for node CIDR in your cluster. It defaults to 24. |
+
proxyMode* |
+ The proxy mode to use. It defaults to ipvs. |
+
network |
+ |
plugin |
+ The CNI plugin to use. KubeKey installs Calico by default while you can also specify Flannel. Note that some features can only be used when Calico is adopted as the CNI plugin, such as Pod IP Pools. | +
calico.ipipMode* |
+ The IPIP Mode to use for the IPv4 POOL created at startup. If it is set to a value other than Never, vxlanMode should be set to Never. Allowed values are Always, CrossSubnet and Never. It defaults to Always. |
+
calico.vxlanMode* |
+ The VXLAN Mode to use for the IPv4 POOL created at startup. If it is set to a value other than Never, ipipMode should be set to Never. Allowed values are Always, CrossSubnet and Never. It defaults to Never. |
+
calico.vethMTU* |
+ The maximum transmission unit (MTU) setting determines the largest packet size that can be transmitted through your network. It defaults to 1440. |
+
kubePodsCIDR |
+ A valid CIDR block for your Kubernetes Pod subnet. It should not overlap with your node subnet and your Kubernetes Services subnet. | +
kubeServiceCIDR |
+ A valid CIDR block for your Kubernetes Services. It should not overlap with your node subnet and your Kubernetes Pod subnet. | +
registry |
+ |
registryMirrors |
+ Configure a Docker registry mirror to speed up downloads. For more information, see {{< contentLink "https://docs.docker.com/registry/recipes/mirror/#configure-the-docker-daemon" "Configure the Docker daemon" >}}. | +
insecureRegistries |
+ Set an address of insecure image registry. For more information, see {{< contentLink "https://docs.docker.com/registry/insecure/" "Test an insecure registry" >}}. | +
privateRegistry* |
+ Configure a private image registry for air-gapped installation (for example, a Docker local registry or Harbor). For more information, see {{< contentLink "docs/v3.3/installing-on-linux/introduction/air-gapped-installation/" "Air-gapped Installation on Linux" >}}. | +
+
+2. On the page that appears, only few parameters need to be changed. Click **Create new** under **Resource group** and enter a name such as `KubeSphereVMRG`.
+
+3. Enter **Admin Username**.
+
+4. Copy your public SSH key for the field **Admin Key**. Alternatively, create a new one with `ssh-keygen`.
+
+ 
+
+ {{< notice note >}}
+
+Password authentication is restricted in Linux configurations. Only SSH is acceptable.
+
+{{}}
+
+5. Click **Purchase** at the bottom to continue.
+
+### Review Azure resources in the Portal
+
+After successfully created, all the resources will display in the resource group `KubeSphereVMRG`. Record the public IP of the load balancer and the private IP addresses of the VMs. You will need them later.
+
+
+
+## Deploy Kubernetes and KubeSphere
+
+Execute the following commands on your device or connect to one of the Master VMs through SSH. During the installation, files will be downloaded and distributed to each VM.
+
+```bash
+# copy your private ssh to master-0
+scp -P 50200 ~/.ssh/id_rsa kubesphere@40.81.5.xx:/home/kubesphere/.ssh/
+
+# ssh to the master-0
+ssh -i .ssh/id_rsa2 -p50200 kubesphere@40.81.5.xx
+```
+
+### Download KubeKey
+
+[Kubekey](../../../installing-on-linux/introduction/kubekey/) is a brand-new installation tool which provides an easy, fast and flexible way to install Kubernetes and KubeSphere.
+
+1. Download it so that you can generate a configuration file in the next step.
+
+ {{< tabs >}}
+
+ {{< tab "Good network connections to GitHub/Googleapis" >}}
+
+Download KubeKey from its [GitHub Release Page](https://github.com/kubesphere/kubekey/releases) or use the following command directly:
+
+```bash
+curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+```
+
+{{}}
+
+{{< tab "Poor network connections to GitHub/Googleapis" >}}
+
+Run the following command first to make sure you download KubeKey from the correct zone.
+
+```bash
+export KKZONE=cn
+```
+
+Run the following command to download KubeKey:
+
+```bash
+curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+```
+
+{{< notice note >}}
+
+After you download KubeKey, if you transfer it to a new machine also with poor network connections to Googleapis, you must run `export KKZONE=cn` again before you proceed with the steps below.
+
+{{}}
+
+{{}}
+
+{{}}
+
+ {{< notice note >}}
+
+The commands above download the latest release of KubeKey. You can change the version number in the command to download a specific version.
+
+{{}}
+
+ Make `kk` executable:
+
+ ```bash
+ chmod +x kk
+ ```
+
+1. Create an example configuration file with default configurations. Here Kubernetes v1.22.12 is used as an example.
+
+ ```bash
+ ./kk create config --with-kubesphere v3.3.2 --with-kubernetes v1.22.12
+ ```
+
+ {{< notice note >}}
+
+- Recommended Kubernetes versions for KubeSphere 3.3: v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x. If you do not specify a Kubernetes version, KubeKey will install Kubernetes v1.23.10 by default. For more information about supported Kubernetes versions, see [Support Matrix](../../../installing-on-linux/introduction/kubekey/#support-matrix).
+
+- If you do not add the flag `--with-kubesphere` in the command in this step, KubeSphere will not be deployed unless you install it using the `addons` field in the configuration file or add this flag again when you use `./kk create cluster` later.
+- If you add the flag `--with-kubesphere` without specifying a KubeSphere version, the latest version of KubeSphere will be installed.
+
+{{}}
+
+### Example configurations
+
+```yaml
+spec:
+ hosts:
+ - {name: master-0, address: 40.81.5.xx, port: 50200, internalAddress: 10.0.1.4, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ - {name: master-1, address: 40.81.5.xx, port: 50201, internalAddress: 10.0.1.5, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ - {name: master-2, address: 40.81.5.xx, port: 50202, internalAddress: 10.0.1.6, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ - {name: node000000, address: 40.81.5.xx, port: 50100, internalAddress: 10.0.0.4, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ - {name: node000001, address: 40.81.5.xx, port: 50101, internalAddress: 10.0.0.5, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ - {name: node000002, address: 40.81.5.xx, port: 50102, internalAddress: 10.0.0.6, user: kubesphere, privateKeyPath: "~/.ssh/id_rsa"}
+ roleGroups:
+ etcd:
+ - master-0
+ - master-1
+ - master-2
+ control-plane:
+ - master-0
+ - master-1
+ - master-2
+ worker:
+ - node000000
+ - node000001
+ - node000002
+```
+For more information, see [this file](https://github.com/kubesphere/kubekey/blob/release-2.2/docs/config-example.md).
+
+### Configure the load balancer
+
+In addition to node information, you need to configure your load balancer in the same YAML file. For the IP address, you can find it in **Azure > KubeSphereVMRG > PublicLB**. Assume the IP address and listening port of the load balancer are `40.81.5.xx` and `6443` respectively, and you can refer to the following example.
+
+```yaml
+## Public LB config example
+## apiserver_loadbalancer_domain_name: "lb.kubesphere.local"
+ controlPlaneEndpoint:
+ domain: lb.kubesphere.local
+ address: "40.81.5.xx"
+ port: 6443
+```
+
+{{< notice note >}}
+
+The public load balancer is used directly instead of an internal load balancer due to Azure [Load Balancer limits](https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-troubleshoot#cause-4-accessing-the-internal-load-balancer-frontend-from-the-participating-load-balancer-backend-pool-vm).
+
+{{}}
+
+### Persistent storage plugin configurations
+
+See [Persistent Storage Configurations](../../../installing-on-linux/persistent-storage-configurations/understand-persistent-storage/) for details.
+
+### Configure the network plugin
+
+Azure Virtual Network doesn't support the IPIP mode used by [Calico](https://docs.projectcalico.org/reference/public-cloud/azure#about-calico-on-azure). You need to change the network plugin to `flannel`.
+
+```yaml
+ network:
+ plugin: flannel
+ kubePodsCIDR: 10.233.64.0/18
+ kubeServiceCIDR: 10.233.0.0/18
+```
+
+### Create a cluster
+
+1. After you complete the configuration, you can execute the following command to start the installation:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+2. Inspect the logs of installation:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+3. When the installation finishes, you can see the following message:
+
+ ```bash
+ #####################################################
+ ### Welcome to KubeSphere! ###
+ #####################################################
+ Console: http://10.128.0.44:30880
+ Account: admin
+ Password: P@88w0rd
+ NOTES：
+ 1. After you log into the console, please check the
+ monitoring status of service components in
+ the "Cluster Management". If any service is not
+ ready, please wait patiently until all components
+ are up and running.
+ 2. Please change the default password after login.
+ #####################################################
+ https://kubesphere.io 2020-xx-xx xx:xx:xx
+ ```
+
+4. Access the KubeSphere console using `
on the right of the member cluster, and click **Update KubeConfig**.
+
+3. In the **Update KubeConfig** dialog box that is diaplayed, enter the new kubeconfig，and click **update**.
+
+
+
diff --git a/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/_index.md b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/_index.md
new file mode 100644
index 000000000..92ba09b39
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Import Cloud-hosted Kubernetes Clusters"
+weight: 5300
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aliyun-ack.md b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aliyun-ack.md
new file mode 100644
index 000000000..abac113c6
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aliyun-ack.md
@@ -0,0 +1,70 @@
+---
+title: "Import an Alibaba Cloud Kubernetes (ACK) Cluster"
+keywords: 'Kubernetes, KubeSphere, multicluster, ACK'
+description: 'Learn how to import an Alibaba Cloud Kubernetes cluster.'
+titleLink: "Import an Alibaba Cloud Kubernetes (ACK) Cluster"
+weight: 5310
+---
+
+This tutorial demonstrates how to import an Alibaba Cloud Kubernetes (ACK) cluster through the [direct connection](../../../multicluster-management/enable-multicluster/direct-connection/) method. If you want to use the agent connection method, refer to [Agent Connection](../../../multicluster-management/enable-multicluster/agent-connection/).
+
+## Prerequisites
+
+- You have a Kubernetes cluster with KubeSphere installed, and prepared this cluster as the host cluster. For more information about how to prepare a host cluster, refer to [Prepare a host cluster](../../../multicluster-management/enable-multicluster/direct-connection/#prepare-a-host-cluster).
+- You have an ACK cluster with KubeSphere installed to be used as the member cluster.
+
+## Import an ACK Cluster
+
+### Step 1: Prepare the ACK Member Cluster
+
+1. In order to manage the member cluster from the host cluster, you need to make `jwtSecret` the same between them. Therefore, get it first by executing the following command on your host cluster.
+
+ ```bash
+ kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v "apiVersion" | grep jwtSecret
+ ```
+
+ The output is similar to the following:
+
+ ```yaml
+ jwtSecret: "QVguGh7qnURywHn2od9IiOX6X8f8wK8g"
+ ```
+
+2. Log in to the KubeSphere console of the ACK cluster as `admin`. Click **Platform** in the upper-left corner and then select **Cluster Management**.
+
+3. Go to **CRDs**, enter `ClusterConfiguration` in the search bar, and then press **Enter** on your keyboard. Click **ClusterConfiguration** to go to its detail page.
+
+4. Click 
on the right and then select **Edit YAML** to edit `ks-installer`.
+
+5. In the YAML file of `ks-installer`, change the value of `jwtSecret` to the corresponding value shown above and set the value of `clusterRole` to `member`. Click **Update** to save your changes.
+
+ ```yaml
+ authentication:
+ jwtSecret: QVguGh7qnURywHn2od9IiOX6X8f8wK8g
+ ```
+
+ ```yaml
+ multicluster:
+ clusterRole: member
+ ```
+
+ {{< notice note >}}
+
+ Make sure you use the value of your own `jwtSecret`. You need to wait for a while so that the changes can take effect.
+
+ {{}}
+
+### Step 2: Get the kubeconfig file
+
+Log in to the web console of Alibaba Cloud. Go to **Clusters** under **Container Service - Kubernetes**, click your cluster to go to its detail page, and then select the **Connection Information** tab. You can see the kubeconfig file under the **Public Access** tab. Copy the contents of the kubeconfig file.
+
+
+
+### Step 3: Import the ACK member cluster
+
+1. Log in to the KubeSphere console on your host cluster as `admin`. Click **Platform** in the upper-left corner and then select **Cluster Management**. On the **Cluster Management** page, click **Add Cluster**.
+
+2. Enter the basic information based on your needs and click **Next**.
+
+3. In **Connection Method**, select **Direct connection**. Fill in the kubeconfig file of the ACK member cluster and then click **Create**.
+
+4. Wait for cluster initialization to finish.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md
new file mode 100644
index 000000000..c1dc96bf9
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md
@@ -0,0 +1,171 @@
+---
+title: "Import an AWS EKS Cluster"
+keywords: 'Kubernetes, KubeSphere, multicluster, Amazon EKS'
+description: 'Learn how to import an Amazon Elastic Kubernetes Service cluster.'
+titleLink: "Import an AWS EKS Cluster"
+weight: 5320
+---
+
+This tutorial demonstrates how to import an AWS EKS cluster through the [direct connection](../../../multicluster-management/enable-multicluster/direct-connection/) method. If you want to use the agent connection method, refer to [Agent Connection](../../../multicluster-management/enable-multicluster/agent-connection/).
+
+## Prerequisites
+
+- You have a Kubernetes cluster with KubeSphere installed, and prepared this cluster as the host cluster. For more information about how to prepare a host cluster, refer to [Prepare a host cluster](../../../multicluster-management/enable-multicluster/direct-connection/#prepare-a-host-cluster).
+- You have an EKS cluster to be used as the member cluster.
+
+## Import an EKS Cluster
+
+### Step 1: Deploy KubeSphere on your EKS cluster
+
+You need to deploy KubeSphere on your EKS cluster first. For more information about how to deploy KubeSphere on EKS, refer to [Deploy KubeSphere on AWS EKS](../../../installing-on-kubernetes/hosted-kubernetes/install-kubesphere-on-eks/#install-kubesphere-on-eks).
+
+### Step 2: Prepare the EKS member cluster
+
+1. In order to manage the member cluster from the host cluster, you need to make `jwtSecret` the same between them. Therefore, get it first by executing the following command on your host cluster.
+
+ ```bash
+ kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v "apiVersion" | grep jwtSecret
+ ```
+
+ The output is similar to the following:
+
+ ```yaml
+ jwtSecret: "QVguGh7qnURywHn2od9IiOX6X8f8wK8g"
+ ```
+
+2. Log in to the KubeSphere console of the EKS cluster as `admin`. Click **Platform** in the upper-left corner and then select **Cluster Management**.
+
+3. Go to **CRDs**, enter `ClusterConfiguration` in the search bar, and then press **Enter** on your keyboard. Click **ClusterConfiguration** to go to its detail page.
+
+4. Click 
on the right and then select **Edit YAML** to edit `ks-installer`.
+
+5. In the YAML file of `ks-installer`, change the value of `jwtSecret` to the corresponding value shown above and set the value of `clusterRole` to `member`. Click **Update** to save your changes.
+
+ ```yaml
+ authentication:
+ jwtSecret: QVguGh7qnURywHn2od9IiOX6X8f8wK8g
+ ```
+
+ ```yaml
+ multicluster:
+ clusterRole: member
+ ```
+
+ {{< notice note >}}
+
+ Make sure you use the value of your own `jwtSecret`. You need to wait for a while so that the changes can take effect.
+
+ {{}}
+
+### Step 3: Create a new kubeconfig file
+
+1. [Amazon EKS](https://docs.aws.amazon.com/eks/index.html) doesn’t provide a built-in kubeconfig file as a standard kubeadm cluster does. Nevertheless, you can create a kubeconfig file by referring to this [document](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html). The generated kubeconfig file will be like the following:
+
+ ```yaml
+ apiVersion: v1
+ clusters:
+ - cluster:
+ server: 
on the right and then select **Edit YAML** to edit `ks-installer`.
+
+5. In the YAML file of `ks-installer`, change the value of `jwtSecret` to the corresponding value shown above and set the value of `clusterRole` to `member`.
+
+ ```yaml
+ authentication:
+ jwtSecret: QVguGh7qnURywHn2od9IiOX6X8f8wK8g
+ ```
+
+ ```yaml
+ multicluster:
+ clusterRole: member
+ ```
+
+ {{< notice note >}}
+
+ Make sure you use the value of your own `jwtSecret`. You need to wait for a while so that the changes can take effect.
+
+ {{}}
+
+### Step 3: Create a new kubeconfig file
+
+1. Run the following commands on your GKE Cloud Shell Terminal:
+
+ ```bash
+ TOKEN=$(kubectl -n kubesphere-system get secret $(kubectl -n kubesphere-system get sa kubesphere -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 -d)
+ kubectl config set-credentials kubesphere --token=${TOKEN}
+ kubectl config set-context --current --user=kubesphere
+ ```
+
+2. Retrieve the new kubeconfig file by running the following command:
+
+ ```bash
+ cat ~/.kube/config
+ ```
+
+ The output is similar to the following:
+
+ ```yaml
+ apiVersion: v1
+ clusters:
+ - cluster:
+ certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURLekNDQWhPZ0F3SUJBZ0lSQUtPRUlDeFhyWEdSbjVQS0dlRXNkYzR3RFFZSktvWklodmNOQVFFTEJRQXcKTHpFdE1Dc0dBMVVFQXhNa1pqVTBNVFpoTlRVdFpEZzFZaTAwWkdZNUxXSTVNR1V0TkdNeE0yRTBPR1ZpWW1VMwpNQjRYRFRJeE1ETXhNVEl5TXpBMU0xb1hEVEkyTURNeE1ESXpNekExTTFvd0x6RXRNQ3NHQTFVRUF4TWtaalUwCk1UWmhOVFV0WkRnMVlpMDBaR1k1TFdJNU1HVXROR014TTJFME9HVmlZbVUzTUlJQklqQU5CZ2txaGtpRzl3MEIKQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBdkVHVGtKRjZLVEl3QktlbXNYd3dPSnhtU3RrMDlKdXh4Z1grM0dTMwpoeThVQm5RWEo1d3VIZmFGNHNWcDFzdGZEV2JOZitESHNxaC9MV3RxQk5iSlNCU1ppTC96V3V5OUZNeFZMS2czCjVLdnNnM2drdUpVaFVuK0tMUUFPdTNUWHFaZ2tTejE1SzFOSU9qYm1HZGVWSm5KQTd6NTF2ZkJTTStzQWhGWTgKejJPUHo4aCtqTlJseDAvV0UzTHZEUUMvSkV4WnRCRGFuVFU0anpHMHR2NGk1OVVQN2lWbnlwRHk0dkFkWm5mbgowZncwVnplUXJqT2JuQjdYQTZuUFhseXZubzErclRqakFIMUdtU053c1IwcDRzcEViZ0lXQTNhMmJzeUN5dEJsCjVOdmJKZkVpSTFoTmFOZ3hoSDJNenlOUWVhYXZVa29MdDdPN0xqYzVFWlo4cFFJREFRQUJvMEl3UURBT0JnTlYKSFE4QkFmOEVCQU1DQWdRd0R3WURWUjBUQVFIL0JBVXdBd0VCL3pBZEJnTlZIUTRFRmdRVUVyVkJrc3MydGV0Qgp6ZWhoRi92bGdVMlJiM2N3RFFZSktvWklodmNOQVFFTEJRQURnZ0VCQUdEZVBVa3I1bDB2OTlyMHZsKy9WZjYrCitBanVNNFoyOURtVXFHVC80OHBaR1RoaDlsZDQxUGZKNjl4eXFvME1wUlIyYmJuTTRCL2NVT1VlTE5VMlV4VWUKSGRlYk1oQUp4Qy9Uaks2SHpmeExkTVdzbzVSeVAydWZEOFZob2ZaQnlBVWczajdrTFgyRGNPd1lzNXNrenZ0LwpuVUlhQURLaXhtcFlSSWJ6MUxjQmVHbWROZ21iZ0hTa3MrYUxUTE5NdDhDQTBnSExhMER6ODhYR1psSi80VmJzCjNaWVVXMVExY01IUHd5NnAwV2kwQkpQeXNaV3hZdFJyV3JFWUhZNVZIanZhUG90S3J4Y2NQMUlrNGJzVU1ZZ0wKaTdSaHlYdmJHc0pKK1lNc3hmalU5bm5XYVhLdXM5ZHl0WG1kRGw1R0hNU3VOeTdKYjIwcU5RQkxhWHFkVmY0PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+ server: https://130.211.231.87
+ name: gke_grand-icon-307205_us-central1-c_cluster-3
+ contexts:
+ - context:
+ cluster: gke_grand-icon-307205_us-central1-c_cluster-3
+ user: gke_grand-icon-307205_us-central1-c_cluster-3
+ name: gke_grand-icon-307205_us-central1-c_cluster-3
+ current-context: gke_grand-icon-307205_us-central1-c_cluster-3
+ kind: Config
+ preferences: {}
+ users:
+ - name: gke_grand-icon-307205_us-central1-c_cluster-3
+ user:
+ auth-provider:
+ config:
+ cmd-args: config config-helper --format=json
+ cmd-path: /usr/lib/google-cloud-sdk/bin/gcloud
+ expiry-key: '{.credential.token_expiry}'
+ token-key: '{.credential.access_token}'
+ name: gcp
+ - name: kubesphere
+ user:
+ token: eyJhbGciOiJSUzI1NiIsImtpZCI6InNjOFpIb3RrY3U3bGNRSV9NWV8tSlJzUHJ4Y2xnMDZpY3hhc1BoVy0xTGsifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlc3BoZXJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlc3BoZXJlLXRva2VuLXpocmJ3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmVzcGhlcmUiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIyMGFmZGI1Ny01MTBkLTRjZDgtYTAwYS1hNDQzYTViNGM0M2MiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXNwaGVyZS1zeXN0ZW06a3ViZXNwaGVyZSJ9.ic6LaS5rEQ4tXt_lwp7U_C8rioweP-ZdDjlIZq91GOw9d6s5htqSMQfTeVlwTl2Bv04w3M3_pCkvRzMD0lHg3mkhhhP_4VU0LIo4XeYWKvWRoPR2kymLyskAB2Khg29qIPh5ipsOmGL9VOzD52O2eLtt_c6tn-vUDmI_Zw985zH3DHwUYhppGM8uNovHawr8nwZoem27XtxqyBkqXGDD38WANizyvnPBI845YqfYPY5PINPYc9bQBFfgCovqMZajwwhcvPqS6IpG1Qv8TX2lpuJIK0LLjiKaHoATGvHLHdAZxe_zgAC2cT_9Ars3HIN4vzaSX0f-xP--AcRgKVSY9g
+ ```
+
+### Step 4: Import the GKE member cluster
+
+1. Log in to the KubeSphere console on your host cluster as `admin`. Click **Platform** in the upper-left corner and then select **Cluster Management**. On the **Cluster Management** page, click **Add Cluster**.
+
+2. Enter the basic information based on your needs and click **Next**.
+
+3. In **Connection Method**, select **Direct connection**. Fill in the new kubeconfig file of the GKE member cluster and then click **Create**.
+
+4. Wait for cluster initialization to finish.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/multicluster-management/introduction/_index.md b/content/en/docs/v3.4/multicluster-management/introduction/_index.md
new file mode 100644
index 000000000..0b97cbae9
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/introduction/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Introduction"
+weight: 5100
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/multicluster-management/introduction/kubefed-in-kubesphere.md b/content/en/docs/v3.4/multicluster-management/introduction/kubefed-in-kubesphere.md
new file mode 100644
index 000000000..d687f98ec
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/introduction/kubefed-in-kubesphere.md
@@ -0,0 +1,49 @@
+---
+title: "KubeSphere Federation"
+keywords: "Kubernetes, KubeSphere, federation, multicluster, hybrid-cloud"
+description: "Understand the fundamental concept of Kubernetes federation in KubeSphere, including member clusters and host clusters."
+linkTitle: "KubeSphere Federation"
+weight: 5120
+---
+
+The multi-cluster feature relates to the network connection among multiple clusters. Therefore, it is important to understand the topological relations of clusters.
+
+## How the Multi-cluster Architecture Works
+
+Before you use the central control plane of KubeSphere to manage multiple clusters, you need to create a host cluster, also known as **host** cluster. The host cluster, essentially, is a KubeSphere cluster with the multi-cluster feature enabled. It provides you with the control plane for unified management of member clusters, also known as **member** cluster. Member clusters are common KubeSphere clusters without the central control plane. Namely, tenants with necessary permissions (usually cluster administrators) can access the control plane from the host cluster to manage all member clusters, such as viewing and editing resources on member clusters. Conversely, if you access the web console of any member cluster separately, you cannot see any resources on other clusters.
+
+There can only be one host cluster while multiple member clusters can exist at the same time. In a multi-cluster architecture, the network between the host cluster and member clusters can be [connected directly](../../enable-multicluster/direct-connection/) or [through an agent](../../enable-multicluster/agent-connection/). The network between member clusters can be set in a completely isolated environment.
+
+If you are using on-premises Kubernetes clusters built through kubeadm, install KubeSphere on your Kubernetes clusters by referring to [Air-gapped Installation on Kubernetes](../../../installing-on-kubernetes/on-prem-kubernetes/install-ks-on-linux-airgapped/), and then enable KubeSphere multi-cluster management through direct connection or agent connection.
+
+
+
+## Vendor Agnostic
+
+KubeSphere features a powerful, inclusive central control plane so that you can manage any KubeSphere clusters in a unified way regardless of deployment environments or cloud providers.
+
+## Resource Requirements
+
+Before you enable multi-cluster management, make sure you have enough resources in your environment.
+
+| Namespace | kube-federation-system | kubesphere-system |
+| -------------- | ---------------------- | ----------------- |
+| Sub-component | 2 x controller-manager | tower |
+| CPU Request | 100 m | 100 m |
+| CPU Limit | 500 m | 500 m |
+| Memory Request | 64 MiB | 128 MiB |
+| Memory Limit | 512 MiB | 256 MiB |
+| Installation | Optional | Optional |
+
+{{< notice note >}}
+
+- The request and limit of CPU and memory resources all refer to single replica.
+- After the multi-cluster feature is enabled, tower and controller-manager will be installed on the host cluster. If you use [agent connection](../../../multicluster-management/enable-multicluster/agent-connection/), only tower is needed for member clusters. If you use [direct connection](../../../multicluster-management/enable-multicluster/direct-connection/), no additional component is needed for member clusters.
+
+{{}}
+
+## Use the App Store in a Multi-cluster Architecture
+
+Different from other components in KubeSphere, the [KubeSphere App Store](../../../pluggable-components/app-store/) serves as a global application pool for all clusters, including host cluster and member clusters. You only need to enable the App Store on the host cluster and you can use functions related to the App Store on member clusters directly (no matter whether the App Store is enabled on member clusters or not), such as [app templates](../../../project-user-guide/application/app-template/) and [app repositories](../../../workspace-administration/app-repository/import-helm-repository/).
+
+However, if you only enable the App Store on member clusters without enabling it on the host cluster, you will not be able to use the App Store on any cluster in the multi-cluster architecture.
diff --git a/content/en/docs/v3.4/multicluster-management/introduction/overview.md b/content/en/docs/v3.4/multicluster-management/introduction/overview.md
new file mode 100644
index 000000000..8568c836e
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/introduction/overview.md
@@ -0,0 +1,15 @@
+---
+title: "Kubernetes Multi-Cluster Management — Overview"
+keywords: 'Kubernetes, KubeSphere, multicluster, hybrid-cloud'
+description: 'Gain a basic understanding of multi-cluster management, such as its common use cases, and the benefits that KubeSphere can bring with its multi-cluster feature.'
+linkTitle: "Overview"
+weight: 5110
+---
+
+Today, it's very common for organizations to run and manage multiple Kubernetes clusters across different cloud providers or infrastructures. As each Kubernetes cluster is a relatively self-contained unit, the upstream community is struggling to research and develop a multi-cluster management solution. That said, Kubernetes Cluster Federation ([KubeFed](https://github.com/kubernetes-sigs/kubefed) for short) may be a possible approach among others.
+
+The most common use cases of multi-cluster management include service traffic load balancing, development and production isolation, decoupling of data processing and data storage, cross-cloud backup and disaster recovery, flexible allocation of computing resources, low latency access with cross-region services, and vendor lock-in avoidance.
+
+KubeSphere is developed to address multi-cluster and multi-cloud management challenges, including the scenarios mentioned above. It provides users with a unified control plane to distribute applications and its replicas to multiple clusters from public cloud to on-premises environments. KubeSphere also boasts rich observability across multiple clusters including centralized monitoring, logging, events, and auditing logs.
+
+
diff --git a/content/en/docs/v3.4/multicluster-management/unbind-cluster.md b/content/en/docs/v3.4/multicluster-management/unbind-cluster.md
new file mode 100644
index 000000000..e6dc92b65
--- /dev/null
+++ b/content/en/docs/v3.4/multicluster-management/unbind-cluster.md
@@ -0,0 +1,61 @@
+---
+title: "Remove a Member Cluster"
+keywords: 'Kubernetes, KubeSphere, multicluster, hybrid-cloud'
+description: 'Learn how to remove a member cluster from your cluster pool in KubeSphere.'
+linkTitle: "Remove a Member Cluster"
+weight: 5500
+---
+
+This tutorial demonstrates how to remove a member cluster on the KubeSphere web console.
+
+## Prerequisites
+
+- You have enabled multi-cluster management.
+- You need a user granted a role including the authorization of **Cluster Management**. For example, you can log in to the console as `admin` directly or create a new role with the authorization and assign it to a user.
+
+## Remove a Cluster
+
+You can remove a cluster by using either of the following methods:
+
+**Method 1**
+
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. In the **Member Clusters** area, click on the right of the the cluster that you want to remove from the control plane, and then click **Remove Cluster**.
+
+3. In the **Remove Cluster** dialog box that is displayed, read the risk alert carefully. If you still want to proceed, enter the name of the member cluster, and click **OK**.
+
+**Method 2**
+
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. In the **Member Clusters** area, click the name of the member cluster that you want to remove from the control plane.
+
+3. In the navigation tree on the left, select **Cluster Settings** > **Basic Information**.
+
+4. In the **Cluster Information** area, click **Manage** > **Remove Cluster**.
+
+5. In the **Remove Cluster** dialog box that is displayed, read the risk alert carefully. If you still want to proceed, enter the name of the member cluster, and click **OK**.
+
+ {{< notice warning >}}
+
+ * After the member cluster has been removed, existing resources of the removed member cluster will not be automatically cleaned up.
+
+ * After the member cluster has been removed, multi-cluster configuration data of the removed member cluster will not be automatically cleaned up, which results in data loss when you uninstall KubeSphere or delete associated resources.
+
+ {{}}
+
+6. Run the following command to clean up multi-cluster configuration data of the removed member cluster:
+
+ ```bash
+ for ns in $(kubectl get ns --field-selector status.phase!=Terminating -o jsonpath='{.items[*].metadata.name}'); do kubectl label ns $ns kubesphere.io/workspace- && kubectl patch ns $ns --type merge -p '{"metadata":{"ownerReferences":[]}}'; done
+ ```
+
+## Remove an Unhealthy Cluster
+
+On some occasions, you cannot remove a cluster by following the steps above. For example, you import a cluster with the wrong credentials, and you cannot access **Cluster Settings**. In this case, execute the following command to remove an unhealthy cluster:
+
+```bash
+kubectl delete cluster 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `alerting` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ alerting:
+ enabled: true # Change "false" to "true".
+ ```
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+If you can see **Alerting Messages** and **Alerting Policies** on the **Cluster Management** page, it means the installation is successful as the two parts won't display until the component is installed.
+
+
+
diff --git a/content/en/docs/v3.4/pluggable-components/app-store.md b/content/en/docs/v3.4/pluggable-components/app-store.md
new file mode 100644
index 000000000..09c41607f
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/app-store.md
@@ -0,0 +1,120 @@
+---
+title: "KubeSphere App Store"
+keywords: "Kubernetes, KubeSphere, app-store, OpenPitrix"
+description: "Learn how to enable the KubeSphere App Store to share data and apps internally and set industry standards of delivery process externally."
+linkTitle: "KubeSphere App Store"
+weight: 6200
+---
+
+As an open-source and app-centric container platform, KubeSphere provides users with a Helm-based App Store for application lifecycle management on the back of [OpenPitrix](https://github.com/openpitrix/openpitrix), an open-source web-based system to package, deploy and manage different types of apps. The KubeSphere App Store allows ISVs, developers, and users to upload, test, install, and release apps with just several clicks in a one-stop shop.
+
+Internally, the KubeSphere App Store can serve as a place for different teams to share data, middleware, and office applications. Externally, it is conducive to setting industry standards of building and delivery. After you enable this feature, you can add more apps with app templates.
+
+For more information, see [App Store](../../application-store/).
+
+## Enable the App Store Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by running the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable the App Store in this mode (for example, for testing purposes), refer to [the following section](#enable-app-store-after-installation) to see how the App Store can be installed after installation.
+ {{}}
+
+2. In this file, search for `openpitrix` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ openpitrix:
+ store:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable the KubeSphere App Store first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, search for `openpitrix` and enable the App Store by changing `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ openpitrix:
+ store:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Run the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+## Enable the App Store After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+
+{{}}
+
+3. In **Custom Resources**, click on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, search for `openpitrix` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ openpitrix:
+ store:
+ enabled: true # Change "false" to "true".
+ ```
+
+5. Use the web kubectl to check the installation process by running the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+
+{{}}
+
+## Verify the Installation of the Component
+
+After you log in to the console, if you can see **App Store** in the upper-left corner and apps in it, it means the installation is successful.
+
+{{< notice note >}}
+
+- You can even access the App Store without logging in to the console by visiting `
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `auditing` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ auditing:
+ enabled: true # Change "false" to "true".
+ ```
+
+ {{< notice note >}}
+By default, Elasticsearch will be installed internally if Auditing is enabled. For a production environment, it is highly recommended that you set the following values in this yaml file if you want to enable Auditing, especially `externalElasticsearchHost` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{}}
+
+ ```yaml
+ es: # Storage backend for logging, tracing, events and auditing.
+ elasticsearchMasterReplicas: 1 # The total number of master nodes. Even numbers are not allowed.
+ elasticsearchDataReplicas: 1 # The total number of data nodes.
+ elasticsearchMasterVolumeSize: 4Gi # The volume size of Elasticsearch master nodes.
+ elasticsearchDataVolumeSize: 20Gi # The volume size of Elasticsearch data nodes.
+ logMaxAge: 7 # Log retention day in built-in Elasticsearch. It is 7 days by default.
+ elkPrefix: logstash # The string making up index names. The index name will be formatted as ks-
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Verify that you can use the **Audit Log Search** function from the **Toolbox** in the lower-right corner.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Execute the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n kubesphere-logging-system
+```
+
+The output may look as follows if the component runs successfully:
+
+```yaml
+NAME READY STATUS RESTARTS AGE
+elasticsearch-logging-curator-elasticsearch-curator-159872n9g9g 0/1 Completed 0 2d10h
+elasticsearch-logging-curator-elasticsearch-curator-159880tzb7x 0/1 Completed 0 34h
+elasticsearch-logging-curator-elasticsearch-curator-1598898q8w7 0/1 Completed 0 10h
+elasticsearch-logging-data-0 1/1 Running 1 2d20h
+elasticsearch-logging-data-1 1/1 Running 1 2d20h
+elasticsearch-logging-discovery-0 1/1 Running 1 2d20h
+fluent-bit-6v5fs 1/1 Running 1 2d20h
+fluentbit-operator-5bf7687b88-44mhq 1/1 Running 1 2d20h
+kube-auditing-operator-7574bd6f96-p4jvv 1/1 Running 1 2d20h
+kube-auditing-webhook-deploy-6dfb46bb6c-hkhmx 1/1 Running 1 2d20h
+kube-auditing-webhook-deploy-6dfb46bb6c-jp77q 1/1 Running 1 2d20h
+```
+
+{{}}
+
+{{}}
diff --git a/content/en/docs/v3.4/pluggable-components/devops.md b/content/en/docs/v3.4/pluggable-components/devops.md
new file mode 100644
index 000000000..a090184a1
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/devops.md
@@ -0,0 +1,130 @@
+---
+title: "KubeSphere DevOps System"
+keywords: "Kubernetes, Jenkins, KubeSphere, DevOps, cicd"
+description: "Learn how to enable DevOps to further free your developers and let them focus on code writing."
+linkTitle: "KubeSphere DevOps System"
+weight: 6300
+---
+
+The KubeSphere DevOps System is designed for CI/CD workflows in Kubernetes. Based on [Jenkins](https://jenkins.io/), it provides one-stop solutions to help both development and Ops teams build, test and publish apps to Kubernetes in a straight-forward way. It also features plugin management, [Binary-to-Image (B2I)](../../project-user-guide/image-builder/binary-to-image/), [Source-to-Image (S2I)](../../project-user-guide/image-builder/source-to-image/), code dependency caching, code quality analysis, pipeline logging, and more.
+
+The DevOps System offers an automated environment for users as apps can be automatically released to the same platform. It is also compatible with third-party private image registries (for example, Harbor) and code repositories (for example, GitLab/GitHub/SVN/BitBucket). As such, it creates excellent user experience by providing users with comprehensive, visualized CI/CD pipelines which are extremely useful in air-gapped environments.
+
+For more information, see [DevOps User Guide](../../devops-user-guide/).
+
+## Enable DevOps Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by running the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable DevOps in this mode (for example, for testing purposes), refer to [the following section](#enable-devops-after-installation) to see how DevOps can be installed after installation.
+ {{}}
+
+2. In this file, search for `devops` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ devops:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable KubeSphere DevOps first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, search for `devops` and enable DevOps by changing `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ devops:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Run the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+## Enable DevOps After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+
+{{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, search for `devops` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ devops:
+ enabled: true # Change "false" to "true".
+ ```
+
+5. Use the web kubectl to check the installation process by running the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+
+{{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Go to **System Components** and check that all components on the **DevOps** tab page is in **Healthy** state.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Run the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n kubesphere-devops-system
+```
+
+The output may look as follows if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+devops-jenkins-5cbbfbb975-hjnll 1/1 Running 0 40m
+s2ioperator-0 1/1 Running 0 41m
+```
+
+{{}}
+
+{{}}
diff --git a/content/en/docs/v3.4/pluggable-components/events.md b/content/en/docs/v3.4/pluggable-components/events.md
new file mode 100644
index 000000000..f4454d145
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/events.md
@@ -0,0 +1,191 @@
+---
+title: "KubeSphere Events"
+keywords: "Kubernetes, events, KubeSphere, k8s-events"
+description: "Learn how to enable Events to keep track of everything that is happening on the platform."
+linkTitle: "KubeSphere Events"
+weight: 6500
+---
+
+KubeSphere events allow users to keep track of what is happening inside a cluster, such as node scheduling status and image pulling result. They will be accurately recorded with the specific reason, status and message displayed in the web console. To query events, users can quickly launch the web Toolkit and enter related information in the search bar with different filters (e.g keyword and project) available. Events can also be archived to third-party tools, such as Elasticsearch, Kafka, or Fluentd.
+
+For more information, see [Event Query](../../toolbox/events-query/).
+
+## Enable Events Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+
+If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Events in this mode (for example, for testing purposes), refer to [the following section](#enable-events-after-installation) to see how Events can be [installed after installation](#enable-events-after-installation).
+
+{{}}
+
+2. In this file, navigate to `events` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ events:
+ enabled: true # Change "false" to "true".
+ ```
+
+ {{< notice note >}}
+By default, KubeKey will install Elasticsearch internally if Events is enabled. For a production environment, it is highly recommended that you set the following values in `config-sample.yaml` if you want to enable Events, especially `externalElasticsearchHost` and `externalElasticsearchPort`. Once you provide the following information before installation, KubeKey will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{}}
+
+ ```yaml
+ es: # Storage backend for logging, tracing, events and auditing.
+ elasticsearchMasterReplicas: 1 # The total number of master nodes. Even numbers are not allowed.
+ elasticsearchDataReplicas: 1 # The total number of data nodes.
+ elasticsearchMasterVolumeSize: 4Gi # The volume size of Elasticsearch master nodes.
+ elasticsearchDataVolumeSize: 20Gi # The volume size of Elasticsearch data nodes.
+ logMaxAge: 7 # Log retention day in built-in Elasticsearch. It is 7 days by default.
+ elkPrefix: logstash # The string making up index names. The index name will be formatted as ks-
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `events` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ events:
+ enabled: true # Change "false" to "true".
+ ```
+
+ {{< notice note >}}
+
+By default, Elasticsearch will be installed internally if Events is enabled. For a production environment, it is highly recommended that you set the following values in this yaml file if you want to enable Events, especially `externalElasticsearchHost` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{}}
+
+ ```yaml
+ es: # Storage backend for logging, tracing, events and auditing.
+ elasticsearchMasterReplicas: 1 # The total number of master nodes. Even numbers are not allowed.
+ elasticsearchDataReplicas: 1 # The total number of data nodes.
+ elasticsearchMasterVolumeSize: 4Gi # The volume size of Elasticsearch master nodes.
+ elasticsearchDataVolumeSize: 20Gi # The volume size of Elasticsearch data nodes.
+ logMaxAge: 7 # Log retention day in built-in Elasticsearch. It is 7 days by default.
+ elkPrefix: logstash # The string making up index names. The index name will be formatted as ks-
in the lower-right corner of the console.
+
+{{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Verify that you can use the **Resource Event Search** function from the **Toolbox** in the lower-right corner.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Execute the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n kubesphere-logging-system
+```
+
+The output may look as follows if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+elasticsearch-logging-data-0 1/1 Running 0 155m
+elasticsearch-logging-data-1 1/1 Running 0 154m
+elasticsearch-logging-discovery-0 1/1 Running 0 155m
+fluent-bit-bsw6p 1/1 Running 0 108m
+fluent-bit-smb65 1/1 Running 0 108m
+fluent-bit-zdz8b 1/1 Running 0 108m
+fluentbit-operator-9b69495b-bbx54 1/1 Running 0 109m
+ks-events-exporter-5cb959c74b-gx4hw 2/2 Running 0 7m55s
+ks-events-operator-7d46fcccc9-4mdzv 1/1 Running 0 8m
+ks-events-ruler-8445457946-cl529 2/2 Running 0 7m55s
+ks-events-ruler-8445457946-gzlm9 2/2 Running 0 7m55s
+logsidecar-injector-deploy-667c6c9579-cs4t6 2/2 Running 0 106m
+logsidecar-injector-deploy-667c6c9579-klnmf 2/2 Running 0 106m
+```
+
+{{}}
+
+{{}}
+
diff --git a/content/en/docs/v3.4/pluggable-components/kubeedge.md b/content/en/docs/v3.4/pluggable-components/kubeedge.md
new file mode 100644
index 000000000..a45841309
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/kubeedge.md
@@ -0,0 +1,184 @@
+---
+title: "KubeEdge"
+keywords: "Kubernetes, KubeSphere, Kubeedge"
+description: "Learn how to enable KubeEdge to add edge nodes to your cluster."
+linkTitle: "KubeEdge"
+weight: 6930
+---
+
+[KubeEdge](https://kubeedge.io/en/) is an open-source system for extending native containerized application orchestration capabilities to hosts at edge. It supports multiple edge protocols and looks to provide unified management of cloud and edge applications and resources.
+
+KubeEdge has components running in two separate places - cloud and edge nodes. The components running on the cloud, collectively known as CloudCore, include Controllers and Cloud Hub. Cloud Hub serves as the gateway for the requests sent by edge nodes while Controllers function as orchestrators. The components running on edge nodes, collectively known as EdgeCore, include EdgeHub, EdgeMesh, MetadataManager, and DeviceTwin. For more information, see [the KubeEdge website](https://kubeedge.io/en/).
+
+After you enable KubeEdge, you can [add edge nodes to your cluster](../../installing-on-linux/cluster-operation/add-edge-nodes/) and deploy workloads on them.
+
+
+
+## Enable KubeEdge Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable KubeEdge in this mode (for example, for testing purposes), refer to [the following section](#enable-kubeedge-after-installation) to see how KubeEdge can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `edgeruntime` and `kubeedge`, and change the value of `enabled` from `false` to `true` to enable all KubeEdge components. Click **OK**.
+
+ ```yaml
+ edgeruntime: # Add edge nodes to your cluster and deploy workloads on edge nodes.
+ enabled: false
+ kubeedge: # kubeedge configurations
+ enabled: false
+ cloudCore:
+ cloudHub:
+ advertiseAddress: # At least a public IP address or an IP address which can be accessed by edge nodes must be provided.
+ - "" # Note that once KubeEdge is enabled, CloudCore will malfunction if the address is not provided.
+ service:
+ cloudhubNodePort: "30000"
+ cloudhubQuicNodePort: "30001"
+ cloudhubHttpsNodePort: "30002"
+ cloudstreamNodePort: "30003"
+ tunnelNodePort: "30004"
+ # resources: {}
+ # hostNetWork: false
+ ```
+
+3. Set the value of `kubeedge.cloudCore.cloudHub.advertiseAddress` to the public IP address of your cluster or an IP address that can be accessed by edge nodes. Save the file when you finish editing.
+
+4. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable KubeEdge first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `edgeruntime` and `kubeedge`, and change the value of `enabled` from `false` to `true` to enable all KubeEdge components. Click **OK**.
+
+ ```yaml
+ edgeruntime: # Add edge nodes to your cluster and deploy workloads on edge nodes.
+ enabled: false
+ kubeedge: # kubeedge configurations
+ enabled: false
+ cloudCore:
+ cloudHub:
+ advertiseAddress: # At least a public IP address or an IP address which can be accessed by edge nodes must be provided.
+ - "" # Note that once KubeEdge is enabled, CloudCore will malfunction if the address is not provided.
+ service:
+ cloudhubNodePort: "30000"
+ cloudhubQuicNodePort: "30001"
+ cloudhubHttpsNodePort: "30002"
+ cloudstreamNodePort: "30003"
+ tunnelNodePort: "30004"
+ # resources: {}
+ # hostNetWork: false
+ ```
+
+3. Set the value of `kubeedge.cloudCore.cloudHub.advertiseAddress` to the public IP address of your cluster or an IP address that can be accessed by edge nodes.
+
+4. Save the file and execute the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+## Enable KubeEdge After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `edgeruntime` and `kubeedge`, and change the value of `enabled` from `false` to `true` to enable all KubeEdge components. Click **OK**.
+
+ ```yaml
+ edgeruntime: # Add edge nodes to your cluster and deploy workloads on edge nodes.
+ enabled: false
+ kubeedge: # kubeedge configurations
+ enabled: false
+ cloudCore:
+ cloudHub:
+ advertiseAddress: # At least a public IP address or an IP address which can be accessed by edge nodes must be provided.
+ - "" # Note that once KubeEdge is enabled, CloudCore will malfunction if the address is not provided.
+ service:
+ cloudhubNodePort: "30000"
+ cloudhubQuicNodePort: "30001"
+ cloudhubHttpsNodePort: "30002"
+ cloudstreamNodePort: "30003"
+ tunnelNodePort: "30004"
+ # resources: {}
+ # hostNetWork: false
+ ```
+
+5. Set the value of `kubeedge.cloudCore.cloudHub.advertiseAddress` to the public IP address of your cluster or an IP address that can be accessed by edge nodes. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+6. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+On the **Cluster Management** page, verify that the **Edge Nodes** module has appeared under **Nodes**.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Execute the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n kubeedge
+```
+
+The output may look as follows if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+cloudcore-5f994c9dfd-r4gpq 1/1 Running 0 5h13m
+edge-watcher-controller-manager-bdfb8bdb5-xqfbk 2/2 Running 0 5h13m
+iptables-hphgf 1/1 Running 0 5h13m
+```
+
+{{}}
+
+{{}}
+
+{{< notice note >}}
+
+CloudCore may malfunction (`CrashLoopBackOff`) if `kubeedge.cloudCore.cloudHub.advertiseAddress` was not set when you enabled KubeEdge. In this case, run `kubectl -n kubeedge edit cm cloudcore` to add the public IP address of your cluster or an IP address that can be accessed by edge nodes.
+
+{{}}
diff --git a/content/en/docs/v3.4/pluggable-components/logging.md b/content/en/docs/v3.4/pluggable-components/logging.md
new file mode 100644
index 000000000..bbe764c7e
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/logging.md
@@ -0,0 +1,199 @@
+---
+title: "KubeSphere Logging System"
+keywords: "Kubernetes, Elasticsearch, KubeSphere, Logging, logs"
+description: "Learn how to enable Logging to leverage the tenant-based system for log collection, query and management."
+linkTitle: "KubeSphere Logging System"
+weight: 6400
+---
+
+KubeSphere provides a powerful, holistic, and easy-to-use logging system for log collection, query, and management. It covers logs at varied levels, including tenants, infrastructure resources, and applications. Users can search logs from different dimensions, such as project, workload, Pod and keyword. Compared with Kibana, the tenant-based logging system of KubeSphere features better isolation and security among tenants as tenants can only view their own logs. Apart from KubeSphere's own logging system, the container platform also allows users to add third-party log collectors, such as Elasticsearch, Kafka, and Fluentd.
+
+For more information, see [Log Query](../../toolbox/log-query/).
+
+## Enable Logging Before Installation
+
+### Installing on Linux
+
+When you install KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+
+- If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Logging in this mode (for example, for testing purposes), refer to [the following section](#enable-logging-after-installation) to see how Logging can be installed after installation.
+
+- If you adopt [Multi-node Installation](../../installing-on-linux/introduction/multioverview/) and are using symbolic links for docker root directory, make sure all nodes follow the exactly same symbolic links. Logging agents are deployed in DaemonSets onto nodes. Any discrepancy in container log path may cause collection failures on that node.
+
+{{}}
+
+2. In this file, navigate to `logging` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ logging:
+ enabled: true # Change "false" to "true".
+ containerruntime: docker
+ ```
+
+ {{< notice info >}}To use containerd as the container runtime, change the value of the field `containerruntime` to `containerd`. If you upgraded to KubeSphere 3.3 from earlier versions, you have to manually add the field `containerruntime` under `logging` when enabling KubeSphere Logging system.
+
+ {{}}
+
+ {{< notice note >}}By default, KubeKey will install Elasticsearch internally if Logging is enabled. For a production environment, it is highly recommended that you set the following values in `config-sample.yaml` if you want to enable Logging, especially `externalElasticsearchHost` and `externalElasticsearchPort`. Once you provide the following information before installation, KubeKey will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{}}
+
+ ```yaml
+ es: # Storage backend for logging, tracing, events and auditing.
+ elasticsearchMasterReplicas: 1 # The total number of master nodes. Even numbers are not allowed.
+ elasticsearchDataReplicas: 1 # The total number of data nodes.
+ elasticsearchMasterVolumeSize: 4Gi # The volume size of Elasticsearch master nodes.
+ elasticsearchDataVolumeSize: 20Gi # The volume size of Elasticsearch data nodes.
+ logMaxAge: 7 # Log retention day in built-in Elasticsearch. It is 7 days by default.
+ elkPrefix: logstash # The string making up index names. The index name will be formatted as ks-
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `logging` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ logging:
+ enabled: true # Change "false" to "true".
+ containerruntime: docker
+ ```
+
+ {{< notice info >}}To use containerd as the container runtime, change the value of the field `.logging.containerruntime` to `containerd`. If you upgraded to KubeSphere 3.3 from earlier versions, you have to manually add the field `containerruntime` under `logging` when enabling KubeSphere Logging system.
+
+ {{}}
+
+ {{< notice note >}}By default, Elasticsearch will be installed internally if Logging is enabled. For a production environment, it is highly recommended that you set the following values in this yaml file if you want to enable Logging, especially `externalElasticsearchHost` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{}}
+
+ ```yaml
+ es: # Storage backend for logging, tracing, events and auditing.
+ elasticsearchMasterReplicas: 1 # The total number of master nodes. Even numbers are not allowed.
+ elasticsearchDataReplicas: 1 # The total number of data nodes.
+ elasticsearchMasterVolumeSize: 4Gi # The volume size of Elasticsearch master nodes.
+ elasticsearchDataVolumeSize: 20Gi # The volume size of Elasticsearch data nodes.
+ logMaxAge: 7 # Log retention day in built-in Elasticsearch. It is 7 days by default.
+ elkPrefix: logstash # The string making up index names. The index name will be formatted as ks-
in the lower-right corner of the console.
+
+{{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Go to **System Components** and check that all components on the **Logging** tab page is in **Healthy** state.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Execute the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n kubesphere-logging-system
+```
+
+The output may look as follows if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+elasticsearch-logging-data-0 1/1 Running 0 87m
+elasticsearch-logging-data-1 1/1 Running 0 85m
+elasticsearch-logging-discovery-0 1/1 Running 0 87m
+fluent-bit-bsw6p 1/1 Running 0 40m
+fluent-bit-smb65 1/1 Running 0 40m
+fluent-bit-zdz8b 1/1 Running 0 40m
+fluentbit-operator-9b69495b-bbx54 1/1 Running 0 40m
+logsidecar-injector-deploy-667c6c9579-cs4t6 2/2 Running 0 38m
+logsidecar-injector-deploy-667c6c9579-klnmf 2/2 Running 0 38m
+```
+
+{{}}
+
+{{}}
diff --git a/content/en/docs/v3.4/pluggable-components/metrics-server.md b/content/en/docs/v3.4/pluggable-components/metrics-server.md
new file mode 100644
index 000000000..e82801df1
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/metrics-server.md
@@ -0,0 +1,113 @@
+---
+title: "Metrics Server"
+keywords: "Kubernetes, KubeSphere, Metrics Server"
+description: "Learn how to enable Metrics Server to use HPA to autoscale a Deployment."
+linkTitle: "Metrics Server"
+weight: 6910
+---
+
+KubeSphere supports Horizontal Pod Autoscalers (HPA) for [Deployments](../../project-user-guide/application-workloads/deployments/). In KubeSphere, the Metrics Server controls whether the HPA is enabled. You use an HPA object to autoscale a Deployment based on different types of metrics, such as CPU and memory utilization, as well as the minimum and maximum number of replicas. In this way, an HPA helps to make sure your application runs smoothly and consistently in different situations.
+
+## Enable the Metrics Server Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable the Metrics Server in this mode (for example, for testing purposes), refer to [the following section](#enable-devops-after-installation) to see how the Metrics Server can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `metrics_server` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ metrics_server:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable the Metrics Server first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `metrics_server` and enable it by changing `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ metrics_server:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Execute the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+ {{< notice note >}}
+
+If you install KubeSphere on some cloud hosted Kubernetes engines, it is probable that the Metrics Server is already installed in your environment. In this case, it is not recommended that you enable it in `cluster-configuration.yaml` as it may cause conflicts during installation.
+ {{}}
+
+## Enable the Metrics Server After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `metrics_server` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ metrics_server:
+ enabled: true # Change "false" to "true".
+ ```
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+Execute the following command to verify that the Pod of Metrics Server is up and running.
+
+```bash
+kubectl get pod -n kube-system
+```
+
+If the Metrics Server is successfully installed, your cluster may return the following output (excluding irrelevant Pods):
+
+```bash
+NAME READY STATUS RESTARTS AGE
+metrics-server-6c767c9f94-hfsb7 1/1 Running 0 9m38s
+```
\ No newline at end of file
diff --git a/content/en/docs/v3.4/pluggable-components/network-policy.md b/content/en/docs/v3.4/pluggable-components/network-policy.md
new file mode 100644
index 000000000..437190c87
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/network-policy.md
@@ -0,0 +1,109 @@
+---
+title: "Network Policies"
+keywords: "Kubernetes, KubeSphere, NetworkPolicy"
+description: "Learn how to enable Network Policies to control traffic flow at the IP address or port level."
+linkTitle: "Network Policies"
+weight: 6900
+---
+
+Starting from v3.0.0, users can configure network policies of native Kubernetes in KubeSphere. Network Policies are an application-centric construct, enabling you to specify how a Pod is allowed to communicate with various network entities over the network. With network policies, users can achieve network isolation within the same cluster, which means firewalls can be set up between certain instances (Pods).
+
+{{< notice note >}}
+
+- Please make sure that the CNI network plugin used by the cluster supports Network Policies before you enable the feature. There are a number of CNI network plugins that support Network Policies, including Calico, Cilium, Kube-router, Romana, and Weave Net.
+- It is recommended that you use [Calico](https://www.projectcalico.org/) as the CNI plugin before you enable Network Policies.
+
+{{}}
+
+For more information, see [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/).
+
+## Enable the Network Policy Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable the Network Policy in this mode (for example, for testing purposes), refer to [the following section](#enable-network-policy-after-installation) to see how the Network Policy can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `network.networkpolicy` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ network:
+ networkpolicy:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable the Network Policy first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `network.networkpolicy` and enable it by changing `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ network:
+ networkpolicy:
+ enabled: true # Change "false" to "true".
+ ```
+
+3. Execute the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+## Enable the Network Policy After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `network.networkpolicy` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ network:
+ networkpolicy:
+ enabled: true # Change "false" to "true".
+ ```
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+If you can see the **Network Policies** module in **Network**, it means the installation is successful as this part won't display until you install the component.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/pluggable-components/overview.md b/content/en/docs/v3.4/pluggable-components/overview.md
new file mode 100644
index 000000000..04f63b922
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/overview.md
@@ -0,0 +1,98 @@
+---
+title: "Enable Pluggable Components — Overview"
+keywords: "Kubernetes, KubeSphere, pluggable-components, overview"
+description: "Develop a basic understanding of key components in KubeSphere, including features and resource consumption."
+linkTitle: "Overview"
+weight: 6100
+---
+
+KubeSphere has decoupled some core feature components since v2.1.0. These components are designed to be pluggable which means you can enable them either before or after installation. By default, KubeSphere will be deployed with a minimal installation if you do not enable them.
+
+Different pluggable components are deployed in different namespaces. You can enable any of them based on your needs. It is highly recommended that you install these pluggable components to discover the full-stack features and capabilities provided by KubeSphere.
+
+For more information about how to enable each component, see respective tutorials in this chapter.
+
+## Resource Requirements
+
+Before you enable pluggable components, make sure you have enough resources in your environment based on the tables below. Otherwise, components may crash due to a lack of resources.
+
+{{< notice note >}}
+
+The following request and limit of CPU and memory resources are required by a single replica.
+
+{{}}
+
+### KubeSphere App Store
+
+| Namespace | openpitrix-system |
+| -------------- | ------------------------------------------------------------ |
+| CPU Request | 0.3 core |
+| CPU Limit | None |
+| Memory Request | 300 MiB |
+| Memory Limit | None |
+| Installation | Optional |
+| Notes | Provide an App Store with application lifecycle management. The installation is recommended. |
+
+### KubeSphere DevOps System
+
+| Namespace | kubesphere-devops-system | kubesphere-devops-system |
+| -------------- | ------------------------------------------------------------ | ------------------------------------------------------- |
+| Pattern | All-in-One installation | Multi-node installation |
+| CPU Request | 34 m | 0.47 core |
+| CPU Limit | None | None |
+| Memory Request | 2.69 G | 8.6 G |
+| Memory Limit | None | None |
+| Installation | Optional | Optional |
+| Notes | Provide one-stop DevOps solutions with Jenkins pipelines and B2I & S2I. | The memory of one of the nodes must be larger than 8 G. |
+
+### KubeSphere Monitoring System
+
+| Namespace | kubesphere-monitoring-system | kubesphere-monitoring-system | kubesphere-monitoring-system |
+| -------------- | ------------------------------------------------------------ | ---------------------------- | ---------------------------- |
+| Sub-component | 2 x Prometheus | 3 x Alertmanager | Notification Manager |
+| CPU Request | 100 m | 10 m | 100 m |
+| CPU Limit | 4 cores | None | 500 m |
+| Memory Request | 400 MiB | 30 MiB | 20 MiB |
+| Memory Limit | 8 GiB | None | 1 GiB |
+| Installation | Required | Required | Required |
+| Notes | The memory consumption of Prometheus depends on the cluster size. 8 GiB is sufficient for a cluster with 200 nodes/16,000 Pods. | - | - |
+
+{{< notice note >}}
+
+The KubeSphere monitoring system is not a pluggable component. It is installed by default. The resource request and limit of it are also listed on this page for your reference as it is closely related to other components such as logging.
+
+{{}}
+
+### KubeSphere Logging System
+
+| Namespace | kubesphere-logging-system | kubesphere-logging-system | kubesphere-logging-system | kubesphere-logging-system |
+| -------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| Sub-component | 3 x Elasticsearch | fluent bit | kube-events | kube-auditing |
+| CPU Request | 50 m | 20 m | 90 m | 20 m |
+| CPU Limit | 1 core | 200 m | 900 m | 200 m |
+| Memory Request | 2 G | 50 MiB | 120 MiB | 50 MiB |
+| Memory Limit | None | 100 MiB | 1200 MiB | 100 MiB |
+| Installation | Optional | Required | Optional | Optional |
+| Notes | An optional component for log data storage. The internal Elasticsearch is not recommended for the production environment. | The log collection agent. It is a required component after you enable logging. | Collecting, filtering, exporting and alerting of Kubernetes events. | Collecting, filtering and alerting of Kubernetes and KubeSphere auditing logs. |
+
+### KubeSphere Alerting and Notification
+
+| Namespace | kubesphere-alerting-system |
+| -------------- | ------------------------------------------------------------ |
+| CPU Request | 0.08 core |
+| CPU Limit | None |
+| Memory Request | 80 M |
+| Memory Limit | None |
+| Installation | Optional |
+| Notes | Alerting and Notification need to be enabled at the same time. |
+
+### KubeSphere Service Mesh
+
+| Namespace | istio-system |
+| -------------- | ------------------------------------------------------------ |
+| CPU Request | 1 core |
+| CPU Limit | None |
+| Memory Request | 3.5 G |
+| Memory Limit | None |
+| Installation | Optional |
+| Notes | Support grayscale release strategies, traffic topology, traffic management and distributed tracing. |
diff --git a/content/en/docs/v3.4/pluggable-components/pod-ip-pools.md b/content/en/docs/v3.4/pluggable-components/pod-ip-pools.md
new file mode 100644
index 000000000..b8df7f4aa
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/pod-ip-pools.md
@@ -0,0 +1,104 @@
+---
+title: "Pod IP Pools"
+keywords: "Kubernetes, KubeSphere, Pod, IP pools"
+description: "Learn how to enable Pod IP Pools to assign a specific Pod IP pool to your Pods."
+linkTitle: "Pod IP Pools"
+weight: 6920
+---
+
+A Pod IP pool is used to manage the Pod network address space, and the address space between each Pod IP pool cannot overlap. When you create a workload, you can select a specific Pod IP pool, so that created Pods will be assigned IP addresses from this Pod IP pool.
+
+## Enable Pod IP Pools Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Pod IP Pools in this mode (for example, for testing purposes), refer to [the following section](#enable-pod-ip-pools-after-installation) to see how Pod IP pools can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `network.ippool.type` and change `none` to `calico`. Save the file after you finish.
+
+ ```yaml
+ network:
+ ippool:
+ type: calico # Change "none" to "calico".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable Pod IP Pools first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `network.ippool.type` and enable it by changing `none` to `calico`. Save the file after you finish.
+
+ ```yaml
+ network:
+ ippool:
+ type: calico # Change "none" to "calico".
+ ```
+
+3. Execute the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+
+## Enable Pod IP Pools After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `network` and change `network.ippool.type` to `calico`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ network:
+ ippool:
+ type: calico # Change "none" to "calico".
+ ```
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+On the **Cluster Management** page, verify that you can see the **Pod IP Pools** module under **Network**.
+
+
+
diff --git a/content/en/docs/v3.4/pluggable-components/service-mesh.md b/content/en/docs/v3.4/pluggable-components/service-mesh.md
new file mode 100644
index 000000000..0b6685a4d
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/service-mesh.md
@@ -0,0 +1,157 @@
+---
+title: "KubeSphere Service Mesh"
+keywords: "Kubernetes, Istio, KubeSphere, service-mesh, microservices"
+description: "Learn how to enable KubeSphere Service Mesh to use different traffic management strategies for microservices governance."
+linkTitle: "KubeSphere Service Mesh"
+weight: 6800
+---
+
+On the basis of [Istio](https://istio.io/), KubeSphere Service Mesh visualizes microservices governance and traffic management. It features a powerful toolkit including **circuit breaking, blue-green deployment, canary release, traffic mirroring, tracing, observability, and traffic control**. Developers can easily get started with KubeSphere Service Mesh without any code hacking, which greatly reduces the learning curve of Istio. All features of KubeSphere Service Mesh are designed to meet users' demand for their business.
+
+For more information, see [Grayscale Release](../../project-user-guide/grayscale-release/overview/).
+
+## Enable KubeSphere Service Mesh Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable KubeSphere Service Mesh in this mode (for example, for testing purposes), refer to [the following section](#enable-service-mesh-after-installation) to see how KubeSphere Service Mesh can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `servicemesh` and change `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ servicemesh:
+ enabled: true # Change “false” to “true”.
+ istio: # Customizing the istio installation configuration, refer to https://istio.io/latest/docs/setup/additional-setup/customize-installation/
+ components:
+ ingressGateways:
+ - name: istio-ingressgateway # Used to expose a service outside of the service mesh using an Istio Gateway. The value is false by defalut.
+ enabled: false
+ cni:
+ enabled: false # When the value is true, it identifies user application pods with sidecars requiring traffic redirection and sets this up in the Kubernetes pod lifecycle’s network setup phase.
+ ```
+
+ {{< notice note >}}
+ - For more information about how to access service after enabling Ingress Gateway, please refer to [Ingress Gateway](https://istio.io/latest/docs/tasks/traffic-management/ingress/ingress-control/).
+ - For more information about the Istio CNI plugin, please refer to [Install Istio with the Istio CNI plugin](https://istio.io/latest/docs/setup/additional-setup/cni/).
+ {{}}
+
+3. Run the following command to create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable KubeSphere Service Mesh first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `servicemesh` and enable it by changing `false` to `true` for `enabled`. Save the file after you finish.
+
+ ```yaml
+ servicemesh:
+ enabled: true # Change “false” to “true”.
+ istio: # Customizing the istio installation configuration, refer to https://istio.io/latest/docs/setup/additional-setup/customize-installation/
+ components:
+ ingressGateways:
+ - name: istio-ingressgateway # Used to expose a service outside of the service mesh using an Istio Gateway. The value is false by defalut.
+ enabled: false
+ cni:
+ enabled: false # When the value is true, it identifies user application pods with sidecars requiring traffic redirection and sets this up in the Kubernetes pod lifecycle’s network setup phase.
+ ```
+
+3. Run the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+## Enable KubeSphere Service Mesh After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `servicemesh` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ servicemesh:
+ enabled: true # Change “false” to “true”.
+ istio: # Customizing the istio installation configuration, refer to https://istio.io/latest/docs/setup/additional-setup/customize-installation/
+ components:
+ ingressGateways:
+ - name: istio-ingressgateway # Used to expose a service outside of the service mesh using an Istio Gateway. The value is false by defalut.
+ enabled: false
+ cni:
+ enabled: false # When the value is true, it identifies user application pods with sidecars requiring traffic redirection and sets this up in the Kubernetes pod lifecycle’s network setup phase.
+ ```
+ ```
+
+5. Run the following command in kubectl to check the installation process:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Go to **System Components** and check whether all components on the **Istio** tab page is in **Healthy** state. If yes, the component is successfully installed.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Run the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n istio-system
+```
+
+The following is an example of the output if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+istio-ingressgateway-78dbc5fbfd-f4cwt 1/1 Running 0 9m5s
+istiod-1-6-10-7db56f875b-mbj5p 1/1 Running 0 10m
+jaeger-collector-76bf54b467-k8blr 1/1 Running 0 6m48s
+jaeger-operator-7559f9d455-89hqm 1/1 Running 0 7m
+jaeger-query-b478c5655-4lzrn 2/2 Running 0 6m48s
+kiali-f9f7d6f9f-gfsfl 1/1 Running 0 4m1s
+kiali-operator-7d5dc9d766-qpkb6 1/1 Running 0 6m53s
+```
+
+{{}}
+
+{{}}
diff --git a/content/en/docs/v3.4/pluggable-components/service-topology.md b/content/en/docs/v3.4/pluggable-components/service-topology.md
new file mode 100644
index 000000000..1dadea0bb
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/service-topology.md
@@ -0,0 +1,130 @@
+---
+title: "Service Topology"
+keywords: "Kubernetes, KubeSphere, Services, Topology"
+description: "Learn how to enable Service Topology to view contextual details of your Pods based on Weave Scope."
+linkTitle: "Service Topology"
+weight: 6915
+---
+
+You can enable Service Topology to integrate [Weave Scope](https://www.weave.works/oss/scope/), a visualization and monitoring tool for Docker and Kubernetes. Weave Scope uses established APIs to collect information to build a topology of your apps and containers. The Service topology displays in your project, providing you with visual representations of connections based on traffic.
+
+## Enable Service Topology Before Installation
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Service Topology in this mode (for example, for testing purposes), refer to [the following section](#enable-service-topology-after-installation) to see how Service Topology can be installed after installation.
+ {{}}
+
+2. In this file, navigate to `network.topology.type` and change `none` to `weave-scope`. Save the file after you finish.
+
+ ```yaml
+ network:
+ topology:
+ type: weave-scope # Change "none" to "weave-scope".
+ ```
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable Service Topology first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) file.
+
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. In this local `cluster-configuration.yaml` file, navigate to `network.topology.type` and enable it by changing `none` to `weave-scope`. Save the file after you finish.
+
+ ```yaml
+ network:
+ topology:
+ type: weave-scope # Change "none" to "weave-scope".
+ ```
+
+3. Execute the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+
+## Enable Service Topology After Installation
+
+1. Log in to the console as `admin`. Click **Platform** in the upper-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click 
on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, navigate to `network` and change `network.topology.type` to `weave-scope`. After you finish, click **OK** in the lower-right corner to save the configuration.
+
+ ```yaml
+ network:
+ topology:
+ type: weave-scope # Change "none" to "weave-scope".
+ ```
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice note >}}
+
+You can find the web kubectl tool by clicking 
in the lower-right corner of the console.
+ {{}}
+
+## Verify the Installation of the Component
+
+{{< tabs >}}
+
+{{< tab "Verify the component on the dashboard" >}}
+
+Go to one of your project, navigate to **Services** under **Application Workloads**, and you can see a topology of your Services on the **Service Topology** tab page.
+
+{{}}
+
+{{< tab "Verify the component through kubectl" >}}
+
+Execute the following command to check the status of Pods:
+
+```bash
+kubectl get pod -n weave
+```
+
+The output may look as follows if the component runs successfully:
+
+```bash
+NAME READY STATUS RESTARTS AGE
+weave-scope-agent-48cjp 1/1 Running 0 3m1s
+weave-scope-agent-9jb4g 1/1 Running 0 3m1s
+weave-scope-agent-ql5cf 1/1 Running 0 3m1s
+weave-scope-app-5b76897b6f-8bsls 1/1 Running 0 3m1s
+weave-scope-cluster-agent-8d9b8c464-5zlpp 1/1 Running 0 3m1s
+```
+
+{{}}
+
+{{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/pluggable-components/uninstall-pluggable-components.md b/content/en/docs/v3.4/pluggable-components/uninstall-pluggable-components.md
new file mode 100644
index 000000000..17c2cc4b1
--- /dev/null
+++ b/content/en/docs/v3.4/pluggable-components/uninstall-pluggable-components.md
@@ -0,0 +1,205 @@
+---
+title: "Uninstall Pluggable Components"
+keywords: "Installer, uninstall, KubeSphere, Kubernetes"
+description: "Learn how to uninstall each pluggable component in KubeSphere."
+linkTitle: "Uninstall Pluggable Components"
+Weight: 6940
+---
+
+After you [enable the pluggable components of KubeSphere](../../pluggable-components/), you can also uninstall them by performing the following steps. Please back up any necessary data before you uninstall these components.
+
+## Prerequisites
+
+You have to change the value of the field `enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration` before you uninstall any pluggable components except Service Topology and Pod IP Pools.
+
+Use either of the following methods to change the value of the field `enabled`:
+
+- Run the following command to edit `ks-installer`:
+
+ ```bash
+ kubectl -n kubesphere-system edit clusterconfiguration ks-installer
+ ```
+
+- Log in to the KubeSphere web console as `admin`, click **Platform** in the upper-left corner and select **Cluster Management**, and then go to **CRDs** to search for `ClusterConfiguration`. For more information, see [Enable Pluggable Components](../../../pluggable-components/).
+
+{{< notice note >}}
+
+After the value is changed, you need to wait until the updating process is complete before you continue with any further operations.
+
+{{}}
+
+## Uninstall KubeSphere App Store
+
+Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+## Uninstall KubeSphere DevOps
+
+1. To uninstall DevOps:
+
+ ```bash
+ helm uninstall -n kubesphere-devops-system devops
+ kubectl patch -n kubesphere-system cc ks-installer --type=json -p='[{"op": "remove", "path": "/status/devops"}]'
+ kubectl patch -n kubesphere-system cc ks-installer --type=json -p='[{"op": "replace", "path": "/spec/devops/enabled", "value": false}]'
+ ```
+2. To delete DevOps resources:
+
+ ```bash
+ # Remove all resources related with DevOps
+ for devops_crd in $(kubectl get crd -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | grep "devops.kubesphere.io"); do
+ for ns in $(kubectl get ns -ojsonpath='{.items..metadata.name}'); do
+ for devops_res in $(kubectl get $devops_crd -n $ns -oname); do
+ kubectl patch $devops_res -n $ns -p '{"metadata":{"finalizers":[]}}' --type=merge
+ done
+ done
+ done
+ # Remove all DevOps CRDs
+ kubectl get crd -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | grep "devops.kubesphere.io" | xargs -I crd_name kubectl delete crd crd_name
+ # Remove DevOps namespace
+ kubectl delete namespace kubesphere-devops-system
+ ```
+
+
+## Uninstall KubeSphere Logging
+
+1. Change the value of `logging.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. To disable only log collection:
+
+ ```bash
+ kubectl delete inputs.logging.kubesphere.io -n kubesphere-logging-system tail
+ ```
+
+ {{< notice note >}}
+
+ After running this command, you can still view the container's recent logs provided by Kubernetes by default. However, the container history logs will be cleared and you cannot browse them any more.
+
+ {{}}
+
+3. To uninstall the Logging system, including Elasticsearch:
+
+ ```bash
+ kubectl delete crd fluentbitconfigs.logging.kubesphere.io
+ kubectl delete crd fluentbits.logging.kubesphere.io
+ kubectl delete crd inputs.logging.kubesphere.io
+ kubectl delete crd outputs.logging.kubesphere.io
+ kubectl delete crd parsers.logging.kubesphere.io
+ kubectl delete deployments.apps -n kubesphere-logging-system fluentbit-operator
+ helm uninstall elasticsearch-logging --namespace kubesphere-logging-system
+ ```
+
+ {{< notice warning >}}
+
+ This operation may cause anomalies in Auditing, Events, and Service Mesh.
+
+ {{}}
+
+4. Run the following command:
+
+ ```bash
+ kubectl delete deployment logsidecar-injector-deploy -n kubesphere-logging-system
+ kubectl delete ns kubesphere-logging-system
+ ```
+
+## Uninstall KubeSphere Events
+
+1. Change the value of `events.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following command:
+
+ ```bash
+ helm delete ks-events -n kubesphere-logging-system
+ ```
+
+## Uninstall KubeSphere Alerting
+
+1. Change the value of `alerting.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following command:
+
+ ```bash
+ kubectl -n kubesphere-monitoring-system delete thanosruler kubesphere
+ ```
+
+ {{< notice note >}}
+
+ Notification is installed in KubeSphere 3.3 by default, so you do not need to uninstall it.
+
+ {{}}
+
+
+## Uninstall KubeSphere Auditing
+
+1. Change the value of `auditing.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following commands:
+
+ ```bash
+ helm uninstall kube-auditing -n kubesphere-logging-system
+ kubectl delete crd rules.auditing.kubesphere.io
+ kubectl delete crd webhooks.auditing.kubesphere.io
+ ```
+
+## Uninstall KubeSphere Service Mesh
+
+1. Change the value of `servicemesh.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following commands:
+
+ ```bash
+ curl -L https://istio.io/downloadIstio | sh -
+ istioctl x uninstall --purge
+
+ kubectl -n istio-system delete kiali kiali
+ helm -n istio-system delete kiali-operator
+
+ kubectl -n istio-system delete jaeger jaeger
+ helm -n istio-system delete jaeger-operator
+ ```
+
+## Uninstall Network Policies
+
+For the component NetworkPolicy, disabling it does not require uninstalling the component as its controller is now inside `ks-controller-manager`. If you want to remove it from the KubeSphere console, change the value of `network.networkpolicy.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+## Uninstall Metrics Server
+
+1. Change the value of `metrics_server.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following commands:
+
+ ```bash
+ kubectl delete apiservice v1beta1.metrics.k8s.io
+ kubectl -n kube-system delete service metrics-server
+ kubectl -n kube-system delete deployment metrics-server
+ ```
+
+## Uninstall Service Topology
+
+1. Change the value of `network.topology.type` from `weave-scope` to `none` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following command:
+
+ ```bash
+ kubectl delete ns weave
+ ```
+
+## Uninstall Pod IP Pools
+
+Change the value of `network.ippool.type` from `calico` to `none` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+## Uninstall KubeEdge
+
+1. Change the value of `kubeedge.enabled` and `edgeruntime.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
+
+2. Run the following commands:
+
+ ```bash
+ helm uninstall kubeedge -n kubeedge
+ kubectl delete ns kubeedge
+ ```
+
+ {{< notice note >}}
+
+ After uninstallation, you will not be able to add edge nodes to your cluster.
+
+ {{}}
+
diff --git a/content/en/docs/v3.4/project-administration/_index.md b/content/en/docs/v3.4/project-administration/_index.md
new file mode 100644
index 000000000..a8c3c7e20
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/_index.md
@@ -0,0 +1,13 @@
+---
+title: "Project Administration"
+description: "Help you to better manage KubeSphere projects"
+layout: "second"
+
+linkTitle: "Project Administration"
+weight: 13000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+A KubeSphere project is a Kubernetes namespace. There are two types of projects, the single-cluster project and the multi-cluster project. The former one is the regular Kubernetes namespace, while the latter is the federated namespace across multiple clusters. As a project administrator, you are responsible for project creation, limit range settings, network isolation configuration, and more.
diff --git a/content/en/docs/v3.4/project-administration/container-limit-ranges.md b/content/en/docs/v3.4/project-administration/container-limit-ranges.md
new file mode 100644
index 000000000..8fa82fa9d
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/container-limit-ranges.md
@@ -0,0 +1,47 @@
+---
+title: "Container Limit Ranges"
+keywords: 'Kubernetes, KubeSphere, resource, quotas, limits, requests, limit ranges, containers'
+description: 'Learn how to set default container limit ranges in a project.'
+linkTitle: "Container Limit Ranges"
+weight: 13400
+---
+
+A container can use as much CPU and memory as set by [the resource quota for a project](../../workspace-administration/project-quotas/). At the same time, KubeSphere uses requests and limits to control resource (for example, CPU and memory) usage for a container, also known as [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) in Kubernetes. Requests make sure the container can get the resources it needs as they are specifically guaranteed and reserved. On the contrary, limits ensure that container can never use resources above a certain value.
+
+When you create a workload, such as a Deployment, you configure resource [Kubernetes requests and limits](https://kubesphere.io/blogs/understand-requests-and-limits-in-kubernetes/) for the container. To make these request and limit fields pre-populated with values, you can set default limit ranges.
+
+This tutorial demonstrates how to set default limit ranges for containers in a project.
+
+## Prerequisites
+
+You have an available workspace, a project and a user (`project-admin`). The user must have the `admin` role at the project level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Set Default Limit Ranges
+
+1. Log in to the console as `project-admin` and go to a project. On the **Overview** page, you can see default limit ranges remain unset if the project is newly created. Click **Edit Quotas** next to **Default Container Quotas Not Set** to configure limit ranges.
+
+2. In the dialog that appears, you can see that KubeSphere does not set any requests or limits by default. To set requests and limits to control CPU and memory resources, use the slider to move to a desired value or enter numbers directly. Leaving a field blank means you do not set any requests or limits.
+
+ {{< notice note >}}
+
+ The limit can never be lower than the request.
+
+ {{}}
+
+3. Click **OK** to finish setting limit ranges.
+
+4. Go to **Basic Information** in **Project Settings**, and you can see default limit ranges for containers in a project.
+
+5. To change default limit ranges, click **Edit Project** on the **Basic Information** page and select **Edit Default Container Quotas**.
+
+6. Change limit ranges directly in the dialog and click **OK**.
+
+7. When you create a workload, requests and limits of the container will be pre-populated with values.
+ {{< notice note >}}
+ For more information, see **Resource Request** in [Container Image Settings](../../project-user-guide/application-workloads/container-image-settings/).
+
+ {{}}
+
+## See Also
+
+[Project Quotas](../../workspace-administration/project-quotas/)
diff --git a/content/en/docs/v3.4/project-administration/disk-log-collection.md b/content/en/docs/v3.4/project-administration/disk-log-collection.md
new file mode 100644
index 000000000..634317a22
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/disk-log-collection.md
@@ -0,0 +1,75 @@
+---
+title: "Log Collection"
+keywords: 'KubeSphere, Kubernetes, project, disk, log, collection'
+description: 'Enable log collection so that you can collect, manage, and analyze logs in a unified way.'
+linkTitle: "Log Collection"
+weight: 13600
+---
+
+KubeSphere supports multiple log collection methods so that Ops teams can collect, manage, and analyze logs in a unified and flexible way.
+
+This tutorial demonstrates how to collect logs for an example app.
+
+## Prerequisites
+
+- You need to create a workspace, a project and a user (`project-admin`). The user must be invited to the project with the role of `admin` at the project level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+- You need to enable [the KubeSphere Logging System](../../pluggable-components/logging/).
+
+## Enable Log Collection
+
+1. Log in to the web console of KubeSphere as `project-admin` and go to your project.
+
+2. From the left navigation bar, click **Log Collection** in **Project Settings**, and then click 
to enable the feature.
+
+## Create a Deployment
+
+1. From the left navigation bar, select **Workloads** in **Application Workloads**. Under the **Deployments** tab, click **Create**.
+
+2. In the dialog that appears, set a name for the Deployment (for example, `demo-deployment`) and click **Next**.
+
+3. Under **Containers**, click **Add Container**.
+
+4. Enter `alpine` in the search bar to use the image (tag: `latest`) as an example.
+
+5. Scroll down to **Start Command** and select the checkbox. Enter the following values for **Command** and **Parameters** respectively, click **√**, and then click **Next**.
+
+ **Command**
+
+ ```bash
+ /bin/sh
+ ```
+
+ **Parameters**
+
+ ```bash
+ -c,if [ ! -d /data/log ];then mkdir -p /data/log;fi; while true; do date >> /data/log/app-test.log; sleep 30;done
+ ```
+
+ {{< notice note >}}
+
+ The command and parameters above mean that the date information will be exported to `app-test.log` in `/data/log` every 30 seconds.
+
+ {{}}
+
+6. On the **Storage Settings** tab, click 
to enable **Collect Logs on Volumes** and click **Mount Volume**.
+
+7. On the **Temporary Volume** tab, enter a name for the volume (for example, `demo-disk-log-collection`) and set the access mode and path.
+
+ Click **√**, and then click **Next**.
+
+8. Click **Create** in **Advanced Settings** to finish the process.
+
+ {{< notice note >}}
+
+ For more information, see [Deployments](../../project-user-guide/application-workloads/deployments/).
+
+ {{}}
+
+## View Logs
+
+1. Under the **Deployments** tab, click the Deployment just created to go to its detail page.
+
+2. In **Resource Status**, you can click 
to view container details, and then click 
of `logsidecar-container` (filebeat container) to view logs.
+
+3. Alternatively, you can also click 
in the lower-right corner and select **Log Search** to view stdout logs. For example, use the Pod name of the Deployment for a fuzzy query.
+
diff --git a/content/en/docs/v3.4/project-administration/project-and-multicluster-project.md b/content/en/docs/v3.4/project-administration/project-and-multicluster-project.md
new file mode 100644
index 000000000..8a36c19d3
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/project-and-multicluster-project.md
@@ -0,0 +1,95 @@
+---
+title: "Projects and Multi-cluster Projects"
+keywords: 'KubeSphere, Kubernetes, project, multicluster-project'
+description: 'Learn how to create different types of projects.'
+linkTitle: "Projects and Multi-cluster Projects"
+weight: 13100
+---
+
+A project in KubeSphere is a Kubernetes [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which is used to organize resources into non-overlapping groups. It represents a logical partitioning capability as it divides cluster resources between multiple tenants.
+
+A multi-cluster project runs across clusters, empowering users to achieve high availability and isolate occurring issues to a certain cluster while not affecting your business. For more information, see [Multi-cluster Management](../../multicluster-management/).
+
+This tutorial demonstrates how to manage projects and multi-cluster projects.
+
+## Prerequisites
+
+- You need to create a workspace and a user (`project-admin`). The user must be invited to the workspace with the role of `workspace-self-provisioner`. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+- You must enable the multi-cluster feature through [Direction Connection](../../multicluster-management/enable-multicluster/direct-connection/) or [Agent Connection](../../multicluster-management/enable-multicluster/agent-connection/) before you create a multi-cluster project.
+
+## Projects
+
+### Create a project
+
+1. Go to the **Projects** page of a workspace and click **Create** on the **Projects** tab.
+
+ {{< notice note >}}
+
+- You can change the cluster where the project will be created on the **Cluster** drop-down menu. The list is only visible after you enable the multi-cluster feature.
+- If you cannot see the **Create** button, it means no cluster is available to use for your workspace. You need to contact the platform administrator or cluster administrator so that workspace resources can be created in the cluster. [To assign a cluster to a workspace](../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/), the platform administrator or cluster administrator needs to edit **Cluster Visibility** on the **Cluster Management** page.
+
+ {{}}
+
+2. In the **Create Project** window that appears, enter a project name and add an alias or description if necessary. Under **Cluster**, select the cluster where the project will be created (this option does not appear if the multi-cluster feature is not enabled), and click **OK**.
+
+3. A project created will display in the list. You can click the project name to go to its **Overview** page.
+
+### Edit a project
+
+1. Go to your project, navigate to **Basic Information** under **Project Settings** and click **Manage** on the right.
+
+2. Choose **Edit Information** from the drop-down menu.
+
+ {{< notice note >}}
+
+The project name cannot be edited. If you want to change other information, see relevant tutorials in the documentation.
+
+{{}}
+
+3. To delete a project, choose **Delete** from the drop-down menu. In the dialog that appears, enter the project name and click **OK** to confirm the deletion.
+
+{{< notice warning >}}
+
+A project cannot be recovered once deleted and resources in the project will be removed.
+
+{{}}
+
+## Multi-cluster Projects
+
+### Create a multi-cluster project
+
+1. Go to the **Projects** page of a workspace, click the **Multi-cluster Projects** tab and click **Create**.
+
+ {{< notice note >}}
+
+- If you cannot see the **Create** button, it means no cluster is available to use for your workspace. You need to contact the platform administrator or cluster administrator so that workspace resources can be created in the cluster. [To assign a cluster to a workspace](../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/), the platform administrator or cluster administrator needs to edit **Cluster Visibility** on the **Cluster Management** page.
+- Make sure at least two clusters are assigned to your workspace.
+
+ {{}}
+
+2. In the **Create Multi-cluster Project** window that appears, enter a project name and add an alias or description if necessary. Under **Clusters**, select multiple clusters for your project by clicking **Add Cluster**, and then click **OK**.
+3. A multi-cluster project created is displayed in the list. Click on the right of a multi-cluster project to select an operation from the drop-down menu:
+
+ - **Edit Information**: Edit the basic information of a multi-cluster project.
+ - **Add Cluster**: Select a cluster from the drop-down list in the displayed dialog box and click **OK** to add a cluster to a multi-cluster project.
+ - **Delete**: Delete a multi-cluster project.
+
+### Edit a multi-cluster project
+
+1. Go to your multi-cluster project, navigate to **Basic Information** under **Project Settings** and click **Manage** on the right.
+
+2. Choose **Edit Information** from the drop-down menu.
+
+ {{< notice note >}}
+
+The project name cannot be edited. If you want to change other information, see relevant tutorials in the documentation.
+
+{{}}
+
+3. To delete a multi-cluster project, choose **Delete Project** from the drop-down menu. In the dialog that appears, enter the project name and click **OK** to confirm the deletion.
+
+{{< notice warning >}}
+
+A multi-cluster project cannot be recovered once deleted and resources in the project will be removed.
+
+{{}}
diff --git a/content/en/docs/v3.4/project-administration/project-gateway.md b/content/en/docs/v3.4/project-administration/project-gateway.md
new file mode 100644
index 000000000..37cab408d
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/project-gateway.md
@@ -0,0 +1,66 @@
+---
+title: "Project Gateway"
+keywords: 'KubeSphere, Kubernetes, project, gateway, NodePort, LoadBalancer'
+description: 'Understand the concept of project gateway and how to manage it.'
+linkTitle: "Project Gateway"
+weight: 13500
+---
+
+A gateway in a KubeSphere project is an [NGINX Ingress controller](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). KubeSphere has a built‑in configuration for HTTP load balancing, called [Routes](../../project-user-guide/application-workloads/routes/). A Route defines rules for external connections to Services within a cluster. Users who need to provide external access to their Services create a Route resource that defines rules, including the URI path, backing service name, and other information.
+
+In addition to project gateways, KubeSphere also supports [cluster-scope gateway](../../cluster-administration/cluster-settings/cluster-gateway/) to let all projects share a global gateway.
+
+This tutorial demonstrates how to enable a project gateway on KubeSphere for external access to Services and Routes.
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-admin`). The user must be invited to the project with the role of `admin` at the project level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Enable a Gateway
+
+1. Log in to the KubeSphere web console as `project-admin` and go to your project. In **Project Settings** from the navigation bar, click **Gateway Settings**.
+
+2. Click **Enable Gateway**. In the pop-up window, you can select two access modes for the gateway.
+
+ **NodePort**: You can access Services with corresponding node ports through the gateway.
+
+ **LoadBalancer**: You can access Services with a single IP address through the gateway.
+
+3. You can also enable **Tracing** on the **Enable Gateway** page. You have to turn on **Application Governance** when you create composed applications so that you can use the Tracing feature and use [different grayscale release strategies](../../project-user-guide/grayscale-release/overview/). Once it is enabled, check whether an annotation (for example, `nginx.ingress.kubernetes.io/service-upstream: true`) is added for your route (Ingress) if the route is inaccessible.
+
+3. In **Configuration Options**, add key-value pairs to provide configurations for system components of NGINX Ingress controller. For more information, see [NGINX Ingress Controller documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#configuration-options).
+
+4. After you select an access method, click **OK**.
+
+## NodePort
+
+If you select **NodePort**, KubeSphere will set a port for http and https requests respectively. You can access your Service at `EIP:NodePort` or `Hostname:NodePort`.
+
+For example, to access your Service with an elastic IP address (EIP), visit:
+
+- `http://EIP:32734`
+- `https://EIP:32471`
+
+When you create a [Route](../../project-user-guide/application-workloads/routes/) (Ingress), you can customize a host name to access your Service. For example, to access your Service with the host name set in your Route, visit:
+
+- `http://demo.kubesphere.io:32734`
+- `https://demo.kubesphere.io:32471`
+
+{{< notice note >}}
+
+- You may need to open ports in your security groups and configure relevant port forwarding rules depending on your environment.
+
+- If you access your Service using the host name, make sure the domain name you set can be resolved to the IP address.
+- **NodePort** is not recommended for a production environment. You can use **LoadBalancer** instead.
+
+{{}}
+
+## LoadBalancer
+
+You must configure a load balancer in advance before you select **LoadBalancer**. The IP address of the load balancer will be bound to the gateway to provide access to internal Services and Routes.
+
+{{< notice note >}}
+
+Cloud providers often support load balancer plugins. If you install KubeSphere on major Kubernetes engines on their platforms, you may notice a load balancer is already available in the environment for you to use. If you install KubeSphere in a bare metal environment, you can use [OpenELB](https://github.com/kubesphere/openelb) for load balancing.
+
+{{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-administration/project-network-isolation.md b/content/en/docs/v3.4/project-administration/project-network-isolation.md
new file mode 100644
index 000000000..9624aef77
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/project-network-isolation.md
@@ -0,0 +1,206 @@
+---
+title: "Project Network Isolation"
+keywords: 'KubeSphere, Kubernetes, Calico, Network Policy'
+description: 'Understand the concept of network isolation and how to configure network policies for a project.'
+linkTitle: "Project Network Isolation"
+weight: 13300
+---
+
+KubeSphere project network isolation lets project administrators enforce which network traffic is allowed using different rules. This tutorial demonstrates how to enable network isolation among projects and set rules to control network traffic.
+
+## Prerequisites
+
+- You have already enabled [Network Policies](../../pluggable-components/network-policy/).
+- You must have an available project and a user of the `admin` role (`project-admin`) at the project level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+{{< notice note >}}
+
+For the implementation of the Network Policy, you can refer to [KubeSphere NetworkPolicy](https://github.com/kubesphere/community/blob/master/sig-network/concepts-and-designs/kubesphere-network-policy.md).
+
+{{}}
+
+## Enable/Disable Project Network Isolation
+
+1. Log in to KubeSphere as `project-admin`. Go to your project and select **Network Isolation** in **Project Settings**. By default, project network isolation is disabled.
+
+2. To enable project network isolation, click **Enable**.
+
+ {{< notice note >}}
+
+ When network isolation is turned on, egress traffic will be allowed by default, while ingress traffic will be denied for different projects. But when you add an egress network policy, only traffic that matches your policy will be allowed to go out.
+
+ {{}}
+
+3. You can also disable network isolation by toggling the **Enabled** button on this page.
+
+
+ {{< notice note >}}
+
+ When network isolation is turned off, any previously created network policies will be deleted as well.
+
+ {{}}
+
+## Set a Network Policy
+
+If the default policy does not meet your needs when network isolation is enabled, you can customize your network policy to meet your needs. Currently, you can add custom network policies in KubeSphere for traffic within the cluster or incoming traffic outside the cluster.
+
+### For internal traffic within the cluster
+
+Network policies at the project level within a cluster are used to control whether resources in this project can be accessed by other projects within the same cluster, and which Services you can access.
+
+Assume an NGINX Deployment workload has been created in another project `demo-project-2` and is exposed via the Service `nginx` on the port `80` with `TCP`. Here is an example of how to set ingress and egress traffic rules.
+
+{{< notice note >}}
+
+For more information about how to create workloads, see [Deployments](../../project-user-guide/application-workloads/deployments/) and [Services](../../project-user-guide/application-workloads/services/) respectively.
+
+{{}}
+
+#### Allow ingress traffic from workloads in a different project
+
+1. On the **Network Isolation** page of your current project, click **Internal Allowlist**.
+
+2. Click **Add Allowlist Entry**.
+
+3. Select **Ingress** under **Traffic Direction**.
+
+4. In **Project**, select the project `demo-project-2`.
+
+5. Click **OK**, and then you can see that the project is now in the allowlist.
+
+{{< notice note >}}
+
+If the network is not accessible after you set the network policy, then you need to check whether the peer project has a corresponding egress rule in it.
+
+{{}}
+
+#### Allow egress traffic to Services in a different project
+
+1. On the **Network Isolation** page of your current project, click **Internal Allowlist**.
+
+2. Click **Add Allowlist Entry**.
+
+3. Select **Egress** under **Traffic Direction**.
+
+4. Select the tab **Service** under **Type**.
+
+5. Select the project `demo-project-2` from the drop-down list.
+
+6. Select the Service that is allowed to receive egress traffic. In this case, select `nginx`.
+
+7. Click **OK**, and then you can see that the Service is now in the allowlist.
+
+{{< notice note >}}
+
+When creating a Service, you must make sure that the selectors of the Service are not empty.
+
+{{}}
+
+### For incoming traffic outside the cluster
+
+KubeSphere uses CIDR to distinguish between peers. Assume a Tomcat Deployment workload has been created in your current project and is exposed via the `NodePort` Service `demo-service` on the NodePort `80` with `TCP`. For an external client with the IP address `192.168.1.1` to access this Service, you need to add a rule for it.
+
+#### Allow ingress traffic from a client outside the cluster
+
+1. On the **Network Isolation** page of your current project, select **External Allowlist** and click **Add Allowlist Entry**.
+
+2. Select **Ingress** under **Traffic Direction**.
+
+3. Enter `192.168.1.1/32` for **Network Segment**.
+
+4. Select the protocol `TCP` and enter `80` as the port number.
+
+5. Click **OK**, and then you can see that the rule has been added.
+
+{{< notice note >}}
+
+It is recommended to set `spec.externalTrafficPolicy` in the Service configuration to `local`, so that the source address of the packet will not change. Namely, the source address of the packet is the source address of the client.
+
+{{}}
+
+Assume the IP address of an external client is `http://10.1.0.1:80`, then you need to set a rule for the egress traffic so that the internal Service can access it.
+
+#### Allow egress traffic to Services outside the cluster
+
+1. On the **Network Isolation** page of your current project, select **External Allowlist** and click **Add Allowlist Entry**.
+
+2. Select **Egress** under **Traffic Direction**.
+
+3. Enter `10.1.0.1/32` for **Network Segment**.
+
+4. Select the protocol `TCP` and enter `80` as the port number.
+
+5. Click **OK**, and you can see that the rule has been added.
+
+{{< notice note >}}
+
+In step 4, when you select **SCTP**, you must make sure SCTP is [enabled](https://kubernetes.io/docs/concepts/services-networking/network-policies/#sctp-support).
+
+{{}}
+
+### Best practices
+
+To ensure that all Pods in a project are secure, a best practice is to enable network isolation. When network isolation is on, the project cannot be accessed by other projects. If your workloads need to be accessed by others, you can follow these steps:
+
+1. Set a [gateway](../project-gateway/) in **Project Settings**.
+2. Expose workloads that need to be accessed to a gateway via a Service.
+3. Allow ingress traffic from the namespace where your gateway locates.
+
+If egress traffic is controlled, you should have a clear plan of what projects, Services, and IP addresses can be accessed, and then add them one by one. If you are not sure about what you want, it is recommended that you keep your network policy unchanged.
+
+## FAQs
+
+Q: Why cannot the custom monitoring system of KubeSphere get data after I enabled network isolation?
+
+A: After you enable custom monitoring, the KubeSphere monitoring system will access the metrics of the Pod. You need to allow ingress traffic for the KubeSphere monitoring system. Otherwise, it cannot access Pod metrics.
+
+KubeSphere provides a configuration item `allowedIngressNamespaces` to simplify similar configurations, which allows all projects listed in the configuration.
+
+```yaml
+root@node1:~# kubectl get -n kubesphere-system clusterconfigurations.installer.kubesphere.io ks-installer -o yaml
+apiVersion: installer.kubesphere.io/v1alpha1
+kind: ClusterConfiguration
+metadata:
+ ...
+ name: ks-installer
+ namespace: kubesphere-system
+ ...
+spec:
+ ...
+ networkpolicy:
+ enabled: true
+ nsnpOptions:
+ allowedIngressNamespaces:
+ - kubesphere-system
+ - kubesphere-monitoring-system
+ ...
+```
+
+Q: Why cannot I access a Service even after setting a network policy through the Service?
+
+A: When you add a network policy and access the Service via the cluster IP address, if the network is not
+ working, check the kube-proxy configuration to see if `masqueradeAll` is `false`.
+
+ ```yaml
+ root@node1:~# kubectl get cm -n kube-system kube-proxy -o yaml
+ apiVersion: v1
+ data:
+ config.conf: |-
+ ...
+ iptables:
+ masqueradeAll: false
+ ...
+ ...
+ kind: ConfigMap
+ metadata:
+ ...
+ labels:
+ app: kube-proxy
+ name: kube-proxy
+ namespace: kube-system
+ ...
+ ```
+
+Q: How do I determine the network segment when I set the ingress rule?
+
+A: In Kubernetes, the source IP address of the packet is often handled by NAT, so you need to figure out what the source address of the packet will be before you add the rule. For more information, refer to [Source IP](https://github.com/kubesphere/community/blob/master/sig-network/concepts-and-designs/kubesphere-network-policy.md#source-ip).
diff --git a/content/en/docs/v3.4/project-administration/role-and-member-management.md b/content/en/docs/v3.4/project-administration/role-and-member-management.md
new file mode 100644
index 000000000..8354b3606
--- /dev/null
+++ b/content/en/docs/v3.4/project-administration/role-and-member-management.md
@@ -0,0 +1,75 @@
+---
+title: "Project Role and Member Management"
+keywords: 'KubeSphere, Kubernetes, role, member, management, project'
+description: 'Learn how to manage access control for a project.'
+linkTitle: "Project Role and Member Management"
+weight: 13200
+---
+
+This tutorial demonstrates how to manage roles and members in a project. At the project level, you can grant permissions in the following modules to a role:
+
+- **Application Workloads**
+- **Storage**
+- **Configurations**
+- **Monitoring & Alerting**
+- **Access Control**
+- **Project Settings**
+
+## Prerequisites
+
+At least one project has been created, such as `demo-project`. Besides, you need a user of the `admin` role (for example, `project-admin`) at the project level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Built-in Roles
+
+In **Project Roles**, there are three available built-in roles as shown below. Built-in roles are created automatically by KubeSphere when a project is created and they cannot be edited or deleted. You can only view permissions included in a built-in role or assign it to a user.
+
+| Built-in Roles | +Description | +
|---|---|
viewer |
+ Project viewer who can view all resources in the project. | +
operator |
+ Project operator who can manage resources other than users and roles in the project. | +
admin |
+ Project administrator who has full control over all resources in the project. | +
on the right.
+
+## Invite a New Member
+
+1. Navigate to **Project Members** under **Project Settings**, and click **Invite**.
+
+2. Invite a user to the project by clicking 
on the right of it and assign a role to it.
+
+3. After you add the user to the project, click **OK**. In **Project Members**, you can see the user in the list.
+
+4. To edit the role of an existing user or remove the user from the project, click on the right and select the corresponding operation.
diff --git a/content/en/docs/v3.4/project-user-guide/_index.md b/content/en/docs/v3.4/project-user-guide/_index.md
new file mode 100644
index 000000000..7dc50ce3b
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/_index.md
@@ -0,0 +1,12 @@
+---
+title: "Project User Guide"
+description: "Help you to better manage resources in a KubeSphere project"
+layout: "second"
+
+linkTitle: "Project User Guide"
+weight: 10000
+
+icon: "/images/docs/v3.3/docs.svg"
+---
+
+In KubeSphere, project users with necessary permissions are able to perform a series of tasks, such as creating different kinds of workloads, configuring volumes, Secrets, and ConfigMaps, setting various release strategies, monitoring app metrics, and creating alerting policies. As KubeSphere features great flexibility and compatibility without any code hacking into native Kubernetes, it is very convenient for users to get started with any feature required for their testing, development and production environments.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/alerting/_index.md b/content/en/docs/v3.4/project-user-guide/alerting/_index.md
new file mode 100644
index 000000000..1b4523bc0
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/alerting/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Alerting"
+weight: 10700
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/alerting/alerting-message.md b/content/en/docs/v3.4/project-user-guide/alerting/alerting-message.md
new file mode 100644
index 000000000..507563542
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/alerting/alerting-message.md
@@ -0,0 +1,27 @@
+---
+title: "Alerting Messages (Workload Level)"
+keywords: 'KubeSphere, Kubernetes, Workload, Alerting, Message, Notification'
+description: 'Learn how to view alerting messages for workloads.'
+linkTitle: "Alerting Messages (Workload Level)"
+weight: 10720
+---
+
+Alerting messages record detailed information of alerts triggered based on the alerting policy defined. This tutorial demonstrates how to view alerting messages at the workload level.
+
+## Prerequisites
+
+- You have enabled [KubeSphere Alerting](../../../pluggable-components/alerting/).
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You have created a workload-level alerting policy and an alert has been triggered. For more information, refer to [Alerting Policies (Workload Level)](../alerting-policy/).
+
+## View Alerting Messages
+
+1. Log in to the console as `project-regular`, go to your project, and go to **Alerting Messages** under **Monitoring & Alerting**.
+
+2. On the **Alerting Messages** page, you can see all alerting messages in the list. The first column displays the summary and message you have defined in the notification of the alert. To view details of an alerting message, click the name of the alerting policy and click the **Alerting History** tab on the displayed page.
+
+3. On the **Alerting History** tab, you can see alert severity, monitoring targets, and activation time.
+
+## View Notifications
+
+If you also want to receive alert notifications (for example, email and Slack messages), you need to configure [a notification channel](../../../cluster-administration/platform-settings/notification-management/configure-email/) first.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/alerting/alerting-policy.md b/content/en/docs/v3.4/project-user-guide/alerting/alerting-policy.md
new file mode 100644
index 000000000..d46cea3bd
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/alerting/alerting-policy.md
@@ -0,0 +1,60 @@
+---
+title: "Alerting Policies (Workload Level)"
+keywords: 'KubeSphere, Kubernetes, Workload, Alerting, Policy, Notification'
+description: 'Learn how to set alerting policies for workloads.'
+linkTitle: "Alerting Policies (Workload Level)"
+weight: 10710
+---
+
+KubeSphere provides alerting policies for nodes and workloads. This tutorial demonstrates how to create alerting policies for workloads in a project. See [Alerting Policy (Node Level)](../../../cluster-administration/cluster-wide-alerting-and-notification/alerting-policy/) to learn how to configure alerting policies for nodes.
+
+## Prerequisites
+
+- You have enabled [KubeSphere Alerting](../../../pluggable-components/alerting/).
+- To receive alert notifications, you must configure a [notification channel](../../../cluster-administration/platform-settings/notification-management/configure-email/) beforehand.
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You have workloads in this project. If they are not ready, see [Deploy and Access Bookinfo](../../../quick-start/deploy-bookinfo-to-k8s/) to create a sample app.
+
+## Create an Alerting Policy
+
+1. Log in to the console as `project-regular` and go to your project. Go to **Alerting Policies** under **Monitoring & Alerting**, then click **Create**.
+
+2. In the displayed dialog box, provide the basic information as follows. Click **Next** to continue.
+
+ - **Name**. A concise and clear name as its unique identifier, such as `alert-demo`.
+ - **Alias**. Help you distinguish alerting policies better.
+ - **Description**. A brief introduction to the alerting policy.
+ - **Threshold Duration (min)**. The status of the alerting policy becomes `Firing` when the duration of the condition configured in the alerting rule reaches the threshold.
+ - **Severity**. Allowed values include **Warning**, **Error** and **Critical**, providing an indication of how serious an alert is.
+
+3. On the **Rule Settings** tab, you can use the rule template or create a custom rule. To use the template, fill in the following fields.
+
+ - **Resource Type**. Select the resource type you want to monitor, such as **Deployment**, **StatefulSet**, and **DaemonSet**.
+ - **Monitoring Targets**. Depending on the resource type you select, the target can be different. You cannot see any target if you do not have any workload in the project.
+ - **Alerting Rule**. Define a rule for the alerting policy. These rules are based on Prometheus expressions and an alert will be triggered when conditions are met. You can monitor objects such as CPU and memory.
+
+ {{< notice note >}}
+
+ You can create a custom rule with PromQL by entering an expression in the **Monitoring Metrics** field (autocompletion supported). For more information, see [Querying Prometheus](https://prometheus.io/docs/prometheus/latest/querying/basics/).
+
+ {{}}
+
+ Click **Next** to continue.
+
+4. On the **Message Settings** tab, enter the alert summary and message to be included in your notification, then click **Create**.
+
+5. An alerting policy will be **Inactive** when just created. If conditions in the rule expression are met, it reaches **Pending** first, then turn to **Firing** if conditions keep to be met in the given time range.
+
+## Edit an Alerting Policy
+
+To edit an alerting policy after it is created, on the **Alerting Policies** page, click 
on the right.
+
+1. Click **Edit** from the drop-down menu and edit the alerting policy following the same steps as you create it. Click **OK** on the **Message Settings** page to save it.
+
+2. Click **Delete** from the drop-down menu to delete an alerting policy.
+
+## View an Alerting Policy
+
+Click an alerting policy on the **Alerting Policies** page to see its detail information, including alerting rules and alerting history. You can also see the rule expression which is based on the template you use when creating the alerting policy.
+
+Under **Alert Monitoring**, the **Alert Monitoring** chart shows the actual usage or amount of resources over time. **Alerting Message** displays the customized message you set in notifications.
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/_index.md b/content/en/docs/v3.4/project-user-guide/application-workloads/_index.md
new file mode 100644
index 000000000..d73a9f85a
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Application Workloads"
+weight: 10200
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/container-image-settings.md b/content/en/docs/v3.4/project-user-guide/application-workloads/container-image-settings.md
new file mode 100644
index 000000000..f0a78fcae
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/container-image-settings.md
@@ -0,0 +1,268 @@
+---
+title: "Pod Settings"
+keywords: 'KubeSphere, Kubernetes, image, workload, setting, container'
+description: 'Learn different properties on the dashboard in detail as you set Pods for your workload.'
+linkTitle: "Pod Settings"
+weight: 10280
+---
+
+When you create Deployments, StatefulSets or DaemonSets, you need to specify a Pod. At the same time, KubeSphere provides users with various options to customize workload configurations, such as health check probes, environment variables and start commands. This page illustrates detailed explanations of different properties in **Pod Settings**.
+
+{{< notice tip >}}
+
+You can enable **Edit YAML** in the upper-right corner to see corresponding values in the manifest file (YAML format) of properties on the dashboard.
+
+{{}}
+
+## Pod Settings
+
+### Pod Replicas
+
+Set the number of replicated Pods by clicking 
or 
, indicated by the `.spec.replicas` field in the manifest file. This option is not available for DaemonSets.
+
+If you create Deployments in a multi-cluster project, select a replica scheduling mode under **Replica Scheduling Mode**:
+
+- **Specify Replicas**: select clusters and set the number of Pod replicas in each cluster.
+- **Specify Weights**: select clusters, set the total number of Pod replicas in **Total Replicas**, and specify a weight for each cluster. The Pod replicas will be proportionally scheduled to the clusters according to the weights. To change weights after a Deployment is created, click the name of the Deployment to go to its details page and change weights under **Weights** on the **Resource Status** tab.
+
+If you create StatefulSets in a multi-cluster project, select clusters and set the number of Pod replicas in each cluster under **Pod Replicas**.
+
+### Add Container
+
+Click **Add Container** to add a container.
+
+#### Image Search Box
+
+You can click 
on the right to select an image from the list or enter an image name to search it. KubeSphere provides Docker Hub images and your private image repository. If you want to use your private image repository, you need to create an Image Registry Secret first in **Secrets** under **Configuration**.
+
+{{< notice note >}}
+
+Remember to press **Enter** on your keyboard after you enter an image name in the search box.
+
+{{}}
+
+#### Image Tag
+
+You can enter a tag like `imagename:tag`. If you do not specify it, it will default to the latest version.
+
+#### Container Name
+
+The container name is automatically created by KubeSphere, which is indicated by `.spec.containers.name`.
+
+#### Container Type
+
+If you choose **Init container**, it means the init container will be created for the workload. For more information about init containers, please visit [Init Containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/?spm=a2c4g.11186623.2.19.16704b3e9qHXPb).
+
+#### Resource Request
+
+The resource quota reserved by the container includes both CPU and memory resources. It means the container monopolizes the resource, preventing other services or processes from competing for resources due to insufficient resources, causing the application to become unavailable.
+
+- The CPU request is indicated by `.spec.containers[].resources.requests.cpu` in the manifest file. The CPU request can be exceeded.
+- The memory request is indicated by `.spec.containers[].resources.requests.memory` in the manifest file. The memory request can be exceeded but the container may clear up when node memory is insufficient.
+
+#### Resource Limit
+
+You can specify the upper limit of the resources that the application can use, including CPU, memory, and GPU, to prevent excessive resources from being occupied.
+
+- The CPU limit is indicated by `.spec.containers[].resources.limits.cpu` in the manifest file. The CPU limit can be exceeded for a short time, and the container will not be stopped.
+- The memory limit is indicated by `.spec.containers[].resources.limits.memory` in the manifest file. The memory limit cannot be exceeded. If it exceeds, the container may be stopped or scheduled to another machine with sufficient resources.
+
+{{< notice note >}}
+
+The CPU resource is measured in CPU units, or **Core** in KubeSphere. The memory resource is measured in bytes, or **MiB** in KubeSphere.
+
+{{}}
+
+To set **GPU Type**, select a GPU type from the drop-down list, which defaults to `nvidia.com/gpu`. **GPU Limit** defaults to no limit.
+
+#### **Port Settings**
+
+You need to set the access protocol for the container as well as port information. To use the default setting, click **Use Default Ports**.
+
+#### **Image Pull Policy**
+
+This value is indicated by the `imagePullPolicy` field. On the dashboard, you can choose one of the following three options from the drop-down list.
+
+- **Use Local Image First**: It means that the image is pulled only if it does not exist locally.
+
+- **Pull Image Always**: It means that the image is pulled whenever the pod starts.
+
+- **Use Local Image Only**: It means that the image is not pulled no matter the image exists or not.
+
+{{< notice tip>}}
+
+- The default value is **Use Local Image First**, but the value of images tagged with `:latest` is **Pull Image Always** by default.
+- Docker will check it when pulling the image. If MD5 has not changed, it will not pull.
+- The `:latest` tag should be avoided as much as possible in the production environment, and the latest image can be automatically pulled by the `:latest` tag in the development environment.
+
+{{< /notice >}}
+
+#### **Health Check**
+
+Support liveness check, readiness check, and startup check.
+
+- **Liveness Check**: Liveness probes are used to know whether a container is running, indicated by `livenessProbe`.
+
+- **Readiness Check**: Readiness probes are used to know whether a container is ready to serve requests, indicated by `readinessProbe`.
+
+- **Startup Check**: Startup probes are used to know whether a container application has started, indicated by `startupProbe`.
+
+Liveness, Readiness and Startup Check include the configurations below:
+
+- **HTTP Request**: Perform an HTTP `Get` request on the specified port and path on the IP address of the container. If the response status code is greater than or equal to 200 and less than 400, the diagnosis is considered successful. The supported parameters include:
+
+ - **Path**: HTTP or HTTPS, specified by `scheme`, the path to access the HTTP server, specified by `path`, the access port or port name is exposed by the container. The port number must be between 1 and 65535. The value is specified by `port`.
+ - **Initial Delay (s)**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
+ - **Check Interval (s)**: The probe frequency (in seconds), specified by `periodSeconds`. It defaults to 10. The minimum value is 1.
+ - **Timeout (s)**: The number of seconds after which the probe times out, specified by `timeoutSeconds`. It defaults to 1. The minimum value is 1.
+ - **Success Threshold**: The minimum consecutive successes for the probe to be considered successful after having failed, specified by `successThreshold`. It defaults to 1 and must be 1 for liveness and startup. The minimum value is 1.
+ - **Failure Threshold**: The minimum consecutive failures for the probe to be considered failed after having succeeded, specified by `failureThreshold`. It defaults to 3. The minimum value is 1.
+
+- **TCP Port**: Perform a TCP check on the specified port on the IP address of the container. If the port is open, the diagnosis is considered successful. The supported parameters include:
+
+ - **Port**: The access port or port name is exposed by the container. The port number must be between 1 and 65535. The value is specified by `port`.
+ - **Initial Delay (s)**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
+ - **Check Interval (s)**: The probe frequency (in seconds), specified by `periodSeconds`. It defaults to 10. The minimum value is 1.
+ - **Timeouts**: The number of seconds after which the probe times out, specified by `timeoutSeconds`. It defaults to 1. The minimum value is 1.
+ - **Success Threshold**: The minimum consecutive successes for the probe to be considered successful after having failed, specified by `successThreshold`. It defaults to 1 and must be 1 for liveness and startup. The minimum value is 1.
+ - **Failure Threshold**: The minimum consecutive failures for the probe to be considered failed after having succeeded, specified by `failureThreshold`. It defaults to 3. The minimum value is 1.
+
+- **Command**: Execute the specified command in the container. If the return code is 0 when the command exits, the diagnosis is considered successful. The supported parameters include:
+
+ - **Command**: A detection command used to detect the health of the container, specified by `exec.command`.
+ - **Initial Delay (s)**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
+ - **Check Interval (s)**: The probe frequency (in seconds), specified by `periodSeconds`. It defaults to 10. The minimum value is 1.
+ - **Timeouts**: The number of seconds after which the probe times out, specified by `timeoutSeconds`. It defaults to 1. The minimum value is 1.
+ - **Success Threshold**: The minimum consecutive successes for the probe to be considered successful after having failed, specified by `successThreshold`. It defaults to 1 and must be 1 for liveness and startup. The minimum value is 1.
+ - **Failure Threshold**: The minimum consecutive failures for the probe to be considered failed after having succeeded, specified by `failureThreshold`. It defaults to 3. The minimum value is 1.
+
+ For more information about health checks, please visit [Container Probes](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
+
+#### **Start Command**
+
+By default, a container runs the default image command.
+
+- **Command** refers to the `command` field of containers in the manifest file.
+- **Parameters** refers to the `args` field of containers in the manifest file.
+
+For more information about the command, please visit [Define a Command and Arguments for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/).
+
+#### **Environment Variables**
+
+Configure environment variables for Pods in the form of key-value pairs.
+
+- name: The name of the environment variable, specified by `env.name`.
+- value: The value of the variable referenced, specified by `env.value`.
+- Click **From configmap** or **From secret** to use an existing ConfigMap or Secret.
+
+For more information about the command, please visit [Pod variable](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/?spm=a2c4g.11186623.2.20.16704b3e9qHXPb).
+
+#### **Container Security Context**
+
+A security context defines privilege and access control settings for a Pod or Container. For more information about the security context, please visit [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
+
+#### **Synchronize Host Timezone**
+
+The time zone of the container will be consistent with that of the host after synchronization.
+
+## **Update Strategy**
+
+### Pod Update
+
+Update strategies are different for different workloads.
+
+{{< tabs >}}
+
+{{< tab "Deployments" >}}
+
+The `.spec.strategy` field specifies the strategy used to replace old Pods with new ones. `.spec.strategy.type` can be `Recreate` or `Rolling Update`. `Rolling Update` is the default value.
+
+- **Rolling Update (recommended)**
+
+ A rolling update means the instance of the old version will be gradually replaced with new ones. During the upgrade process, the traffic will be load balanced and distributed to the old and new instances simultaneously, so the service will not be interrupted.
+
+- **Simultaneous Update**
+
+ All existing Pods will be killed before new ones are created. Please note that the service will be interrupted during the update process.
+
+For more information about update strategies, please visit [Strategy in Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy).
+
+{{}}
+
+{{< tab "StatefulSets" >}}
+
+The drop-down menu under **Update Strategy** is indicated by the `.spec.updateStrategy` field of a StatefulSet in the manifest file. It allows you to handle updates of Pod containers, tags, resource requests or limits, and annotations. There are two strategies:
+
+- **Rolling Update (recommended)**
+
+ If `.spec.template` is updated, the Pods in the StatefulSet will be automatically deleted with new pods created as replacements. Pods are updated in reverse ordinal order, sequentially deleted and created. A new Pod update will not begin until the previous Pod becomes up and running after it is updated.
+
+- **Update on Deletion**
+
+ If `.spec.template` is updated, the Pods in the StatefulSet will not be automatically updated. You need to manually delete old Pods so that the controller can create new Pods.
+
+For more information about update strategies, please visit [StatefulSet Update Strategies](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies).
+
+{{}}
+
+{{< tab "DaemonSets" >}}
+
+The drop-down menu under **Update Strategy** is indicated by the `.spec.updateStrategy` field of a DaemonSet in the manifest file. It allows you to handle updates of Pod containers, tags, resource requests or limits, and annotations. There are two strategies:
+
+- **Rolling Update (recommended)**
+
+ If `.spec.template` is updated, old DaemonSet pods will be killed with new pods created automatically in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process.
+
+- **Update on Deletion**
+
+ If `.spec.template` is updated, new DaemonSet pods will only be created when you manually delete old DaemonSet pods. This is the same behavior of DaemonSets in Kubernetes version 1.5 or before.
+
+For more information about update strategies, please visit [DaemonSet Update Strategy](https://kubernetes.io/docs/tasks/manage-daemon/update-daemon-set/#daemonset-update-strategy).
+
+{{}}
+
+{{}}
+
+### Rolling Update Settings
+
+{{< tabs >}}
+
+{{< tab "Deployments" >}}
+
+**Rolling Update Settings** in a Deployment is different from that of a StatefulSet.
+
+- **Maximum Unavailable Pods**: The maximum number of Pods that can be unavailable during the update, specified by `maxUnavailable`. The default value is 25%.
+- **Maximum Extra Pods**: The maximum number of Pods that can be scheduled above the desired number of Pods, specified by `maxSurge`. The default value is 25%.
+
+{{}}
+
+{{< tab "StatefulSets" >}}
+
+**Ordinal for Dividing Pod Replicas**: When you partition an update, all Pods with an ordinal greater than or equal to the value you set in Partition are updated when you update the StatefulSet’s Pod specification. This field is specified by `.spec.updateStrategy.rollingUpdate.partition`, whose default value is 0. For more information about partitions, please visit [Partitions](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#partitions).
+
+{{}}
+
+{{< tab "DaemonSets" >}}
+
+**Rolling Update Settings** in a DaemonSet is different from that of a StatefulSet.
+
+- **Maximum Unavailable Pods**: The maximum number of pods that can be unavailable during the update, specified by `maxUnavailable`. The default value is 20%.
+- **Minimum Running Time for Pod Readiness (s)**: The minimum number of seconds before a newly created Pod of DaemonSet is treated as available, specified by `minReadySeconds`. The default value is 0.
+
+{{}}
+
+{{}}
+
+### Pod Security Context
+
+A security context defines privilege and access control settings for a Pod or Container. For more information about Pod Security Policies, please visit [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
+
+### Pod Scheduling Rules
+
+You can select different deployment modes to switch between inter-pod affinity and inter-pod anti-affinity. In Kubernetes, inter-pod affinity is specified as field `podAffinity` of field `affinity` while inter-pod anti-affinity is specified as field `podAntiAffinity` of field `affinity`. In KubeSphere, both `podAffinity` and `podAntiAffinity` are set to `preferredDuringSchedulingIgnoredDuringExecution`. You can enable **Edit YAML** in the upper-right corner to see field details.
+
+- **Decentralized Scheduling** represents anti-affinity.
+- **Centralized Scheduling** represents affinity.
+- **Custom Rules** is to add custom scheduling rules based on your needs.
+
+For more information about affinity and anti-affinity, please visit [Pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/cronjobs.md b/content/en/docs/v3.4/project-user-guide/application-workloads/cronjobs.md
new file mode 100644
index 000000000..4dc4f89de
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/cronjobs.md
@@ -0,0 +1,105 @@
+---
+title: "CronJobs"
+keywords: "KubeSphere, Kubernetes, Jobs, CronJobs"
+description: "Learn basic concepts of CronJobs and how to create CronJobs on KubeSphere."
+linkTitle: "CronJobs"
+weight: 10260
+---
+
+CronJobs are useful for creating periodic and recurring tasks, like running backups or sending emails. CronJobs can also schedule individual tasks at a specific time or interval, such as scheduling a Job for when your cluster is likely to be idle.
+
+For more information, see [the official documentation of Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/).
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a CronJob
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Jobs** of a project, choose **CronJobs** and click **Create**.
+
+### Step 2: Enter basic information
+
+Enter the basic information. You can refer to the instructions below for each field. When you finish, click **Next**.
+
+- **Name**: The name of the CronJob, which is also the unique identifier.
+- **Alias**: The alias name of the CronJob, making resources easier to identify.
+- **Schedule**: It runs a Job periodically on a given time-based schedule. Please see [CRON](https://en.wikipedia.org/wiki/Cron) for grammar reference. Some preset CRON statements are provided in KubeSphere to simplify the input. This field is specified by `.spec.schedule`. For this CronJob, enter `*/1 * * * *`, which means it runs once per minute.
+
+ | Type | CRON |
+ | ----------- | ----------- |
+ | Every Hour | `0 * * * *` |
+ | Every Day | `0 0 * * *` |
+ | Every Week | `0 0 * * 0` |
+ | Every Month | `0 0 1 * *` |
+
+- **Advanced Settings**:
+
+ - **Maximum Start Delay (s)**. Specified by `.spec.startingDeadlineSeconds` in the manifest file, this optional field represents the maximum number of seconds that a ConJob can take to start if it misses the scheduled time for any reason. CronJobs that have missed executions will be counted as failed ones. If you do not specify this field, there is no deadline for the CronJob.
+ - **Successful Jobs Retained**. Specified by `.spec.successfulJobsHistoryLimit` in the manifest file, this field represents the number of successful CronJob executions to retain. This is a pointer to distinguish between explicit zero and not specified. It defaults to 3.
+ - **Failed Jobs Retained**. Specified by `.spec.failedJobsHistoryLimit` in the manifest file, this field represents the number of failed CronJob executions to retain. This is a pointer to distinguish between explicit zero and not specified. It defaults to 1.
+ - **Concurrency Policy**. Specified by `.spec.concurrencyPolicy`, it represents how to treat concurrent executions of a Job:
+ - **Run Jobs concurrently** (default): Run CronJobs concurrently.
+ - **Skip new Job**: Forbid concurrent runs and skip the next run if the previous run hasn't finished yet.
+ - **Skip old Job**: Cancels currently running Job and replaces it with a new one.
+
+{{< notice note >}}
+
+You can enable **Edit YAML** in the upper-right corner to see the YAML manifest of this CronJob.
+
+{{}}
+
+### Step 3: Strategy settings (Optional)
+
+Please refer to [Jobs](../jobs/#step-3-strategy-settings-optional).
+
+### Step 4: Set a Pod
+
+1. Click **Add Container** in **Containers**, enter `busybox` in the search box, and press **Enter**.
+
+2. Scroll down to **Start Command** and enter `/bin/sh,-c,date; echo "KubeSphere!"` in the box under **Parameters**.
+
+3. Click **√** to finish setting the image and **Next** to continue.
+
+ {{< notice note >}}
+
+- This example CronJob prints `KubeSphere`. For more information about setting images, see [Pod Settings](../container-image-settings/).
+- For more information about **Restart Policy**, see [Jobs](../jobs/#step-4-set-image).
+- You can skip **Storage Settings** and **Advanced Settings** for this tutorial. For more information, see [Mount Volumes](../deployments/#step-4-mount-volumes) and [Configure Advanced Settings](../deployments/#step-5-configure-advanced-settings) in Deployments.
+
+ {{}}
+
+### Step 5: Check results
+
+1. In the final step of **Advanced Settings**, click **Create** to finish. A new item will be added to the CronJob list if the creation is successful. Besides, you can also find Jobs under **Jobs** tab.
+
+2. Under the **ConJobs** tab, click this CronJob and go to the **Job Records** tab where you can see the information of each execution record. There are 3 successful CronJob executions as the field **Successful Jobs Retained** is set to 3.
+
+3. Click any of them and you will be directed to the Job details page.
+
+4. In **Resource Status**, you can inspect the Pod status. Click 
on the right and click 
to check the container log as shown below, which displays the expected output.
+
+## Check CronJob Details
+
+### Operations
+
+On the CronJob details page, you can manage the CronJob after it is created.
+
+- **Edit Information**: Edit the basic information except `Name` of the CronJob.
+- **Pause/Start**: Pause or start the Cronjob. Pausing a CronJob will tell the controller to suspend subsequent executions, which does not apply to executions that already start.
+- **Edit YAML**: Edit the CronJob's specification in YAML format.
+- **Delete**: Delete the CronJob, and return to the CronJob list page.
+
+### Job records
+
+Click the **Job Records** tab to view the records of the CronJob.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the CronJob.
+
+### Events
+
+Click the **Events** tab to view the events of the CronJob.
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/daemonsets.md b/content/en/docs/v3.4/project-user-guide/application-workloads/daemonsets.md
new file mode 100644
index 000000000..d8157ca37
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/daemonsets.md
@@ -0,0 +1,137 @@
+---
+title: "Kubernetes DaemonSets in KubeSphere"
+keywords: 'KubeSphere, Kubernetes, DaemonSet, workload'
+description: 'Learn basic concepts of DaemonSets and how to create DaemonSets in KubeSphere.'
+linkTitle: "DaemonSets"
+weight: 10230
+---
+
+A DaemonSet manages groups of replicated Pods while it ensures that all (or some) nodes run a copy of a Pod. As nodes are added to the cluster, DaemonSets automatically add Pods to the new nodes as needed.
+
+For more information, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
+
+## Use Kubernetes DaemonSets
+
+DaemonSets are very helpful in cases where you want to deploy ongoing background tasks that run on all or certain nodes without any user intervention. For example:
+
+- Run a log collection daemon on every node, such as Fluentd or Logstash.
+- Run a node monitoring daemon on every node, such as Prometheus Node Exporter, collectd, and AppDynamics Agent.
+- Run a cluster storage daemon and system program on every node, such as Glusterd, Ceph, kube-dns, and kube-proxy.
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a DaemonSet
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Application Workloads** of a project, select **Workloads**, and click **Create** under the tab **DaemonSets**.
+
+### Step 2: Enter basic information
+
+Specify a name for the DaemonSet (for example, `demo-daemonset`), select a project, and click **Next**.
+
+### Step 3: Set a Pod
+
+1. Click **Add Container**.
+
+2. Enter an image name from public Docker Hub or from a [private repository](../../configuration/image-registry/) you specified. For example, enter `fluentd` in the search box and press **Enter**.
+
+ {{< notice note >}}
+
+- Remember to press **Enter** on your keyboard after you enter an image name in the search box.
+- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configuration**.
+
+ {{}}
+
+3. Set requests and limits for CPU and memory resources based on your needs. For more information, see [Resource Request and Resource Limit in Container Image Settings](../container-image-settings/#add-container-image).
+
+4. Click **Use Default Ports** for **Port Settings** or you can customize **Protocol**, **Name** and **Container Port**.
+
+5. Select a policy for image pulling from the drop-down menu. For more information, see [Image Pull Policy in Container Image Settings](../container-image-settings/#add-container-image).
+
+6. For other settings (**Health Check**, **Start Command**, **Environment Variables**, **Container Security Context** and **Synchronize Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Pod Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the lower-right corner to continue.
+
+7. Select an update strategy from the drop-down menu. It is recommended you choose **Rolling Update**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
+
+8. Select a Pod scheduling rule. For more information, see [Pod Scheduling Rules](../container-image-settings/#pod-scheduling-rules).
+
+9. Click **Next** to continue when you finish setting the container image.
+
+### Step 4: Mount volumes
+
+You can add a volume directly or mount a ConfigMap or Secret. Alternatively, click **Next** directly to skip this step. For more information about volumes, visit [Volumes](../../storage/volumes/#mount-a-volume).
+
+{{< notice note >}}
+
+DaemonSets can't use a volume template, which is used by StatefulSets.
+
+{{}}
+
+### Step 5: Configure advanced settings
+
+You can add metadata in this section. When you finish, click **Create** to complete the whole process of creating a DaemonSet.
+
+- **Add Metadata**
+
+ Additional metadata settings for resources such as **Labels** and **Annotations**.
+
+## Check Kubernetes DaemonSet Details
+
+### Details page
+
+1. After a DaemonSet is created, it will be displayed in the list. You can click 
on the right and select the options from the menu to modify a DaemonSet.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create the DaemonSet.
+ - **Delete**: Delete the DaemonSet.
+
+2. Click the name of the DaemonSet and you can go to its details page.
+
+3. Click **More** to display what operations about this DaemonSet you can do.
+
+ - **Roll Back**: Select the revision to roll back.
+ - **Edit Settings**: Configure update strategies, containers and volumes.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create this DaemonSet.
+ - **Delete**: Delete the DaemonSet, and return to the DaemonSet list page.
+
+4. Click the **Resource Status** tab to view the port and Pod information of a DaemonSet.
+
+ - **Replica Status**: You cannot change the number of Pod replicas for a DaemonSet.
+ - **Pods**
+
+ - The Pod list provides detailed information of the Pod (status, node, Pod IP and resource usage).
+ - You can view the container information by clicking a Pod item.
+ - Click the container log icon to view output logs of the container.
+ - You can view the Pod details page by clicking the Pod name.
+
+### Revision records
+
+After the resource template of workload is changed, a new log will be generated and Pods will be rescheduled for a version update. The latest 10 versions will be saved by default. You can implement a redeployment based on the change log.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the DaemonSet.
+
+### Monitoring
+
+1. Click the **Monitoring** tab to view the CPU usage, memory usage, outbound traffic, and inbound traffic of the DaemonSet.
+
+2. Click the drop-down menu in the upper-right corner to customize the time range and sampling interval.
+
+3. Click 
/
in the upper-right corner to start/stop automatic data refreshing.
+
+4. Click 
in the upper-right corner to manually refresh the data.
+
+### Environment variables
+
+Click the **Environment Variables** tab to view the environment variables of the DaemonSet.
+
+### Events
+
+Click the **Events** tab to view the events of the DaemonSet.
+
+
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/deployments.md b/content/en/docs/v3.4/project-user-guide/application-workloads/deployments.md
new file mode 100644
index 000000000..062a03ec7
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/deployments.md
@@ -0,0 +1,139 @@
+---
+title: "Deployments"
+keywords: 'KubeSphere, Kubernetes, Deployments, workload'
+description: 'Learn basic concepts of Deployments and how to create Deployments in KubeSphere.'
+linkTitle: "Deployments"
+
+weight: 10210
+---
+
+A Deployment controller provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. As a Deployment runs a number of replicas of your application, it automatically replaces instances that go down or malfunction. This is how Deployments make sure app instances are available to handle user requests.
+
+For more information, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Deployment
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Application Workloads** of a project, select **Workloads**, and click **Create** under the tab **Deployments**.
+
+### Step 2: Enter basic information
+
+Specify a name for the Deployment (for example, `demo-deployment`), select a project, and click **Next**.
+
+### Step 3: Set a Pod
+
+1. Before you set an image, define the number of replicated Pods in **Pod Replicas** by clicking 
or 
, which is indicated by the `.spec.replicas` field in the manifest file.
+
+ {{< notice tip >}}
+You can see the Deployment manifest file in YAML format by enabling **Edit YAML** in the upper-right corner. KubeSphere allows you to edit the manifest file directly to create a Deployment. Alternatively, you can follow the steps below to create a Deployment via the dashboard.
+ {{}}
+
+2. Click **Add Container**.
+
+3. Enter an image name from public Docker Hub or from a [private repository](../../configuration/image-registry/) you specified. For example, enter `nginx` in the search box and press **Enter**.
+
+ {{< notice note >}}
+
+- Remember to press **Enter** on your keyboard after you enter an image name in the search box.
+- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configuration**.
+
+ {{}}
+
+4. Set requests and limits for CPU and memory resources based on your needs. For more information, see [Resource Request and Resource Limit in Container Image Settings](../container-image-settings/#add-container-image).
+
+5. Click **Use Default Ports** for **Port Settings** or you can customize **Protocol**, **Name** and **Container Port**.
+
+6. Select a policy for image pulling from the drop-down list. For more information, see [Image Pull Policy in Container Image Settings](../container-image-settings/#add-container-image).
+
+7. For other settings (**Health Check**, **Start Command**, **Environment Variables**, **Container Security Context** and **Synchronize Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Pod Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the lower-right corner to continue.
+
+8. Select an update strategy from the drop-down menu. It is recommended that you choose **Rolling Update**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
+
+9. Select a Pod scheduling rule. For more information, see [Pod Scheduling Rules](../container-image-settings/#pod-scheduling-rules).
+
+10. Click **Next** to continue when you finish setting the Pod.
+
+### Step 4: Mount volumes
+
+You can add a volume directly or mount a ConfigMap or Secret. Alternatively, click **Next** directly to skip this step. For more information about volumes, visit [Volumes](../../storage/volumes/#mount-a-volume).
+
+{{< notice note >}}
+
+Deployments can't use a volume template, which is used by StatefulSets.
+
+{{}}
+
+### Step 5: Configure advanced settings
+
+You can set a policy for node scheduling and add metadata in this section. When you finish, click **Create** to complete the whole process of creating a Deployment.
+
+- **Select Nodes**
+
+ Assign Pod replicas to run on specified nodes. It is specified in the field `nodeSelector`.
+
+- **Add Metadata**
+
+ Additional metadata settings for resources such as **Labels** and **Annotations**.
+
+## Check Deployment Details
+
+### Details page
+
+1. After a Deployment is created, it will be displayed in the list. You can click 
on the right and select options from the menu to modify your Deployment.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create the Deployment.
+ - **Delete**: Delete the Deployment.
+
+2. Click the name of the Deployment and you can go to its details page.
+
+3. Click **More** to display the operations about this Deployment you can do.
+
+ - **Roll Back**: Select the revision to roll back.
+ - **Edit Autoscaling**: Autoscale the replicas according to CPU and memory usage. If both CPU and memory are specified, replicas are added or deleted if any of the conditions is met.
+ - **Edit Settings**: Configure update strategies, containers and volumes.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create this Deployment.
+ - **Delete**: Delete the Deployment, and return to the Deployment list page.
+
+4. Click the **Resource Status** tab to view the port and Pod information of the Deployment.
+
+ - **Replica Status**: Click or to increase or decrease the number of Pod replicas.
+ - **Pods**
+
+ - The Pod list provides detailed information of the Pod (status, node, Pod IP and resource usage).
+ - You can view the container information by clicking a Pod item.
+ - Click the container log icon to view output logs of the container.
+ - You can view the Pod details page by clicking the Pod name.
+
+### Revision records
+
+After the resource template of workload is changed, a new log will be generated and Pods will be rescheduled for a version update. The latest 10 versions will be saved by default. You can implement a redeployment based on the change log.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the Deployment.
+
+### Monitoring
+
+1. Click the **Monitoring** tab to view the CPU usage, memory usage, outbound traffic, and inbound traffic of the Deployment.
+
+2. Click the drop-down menu in the upper-right corner to customize the time range and sampling interval.
+
+3. Click 
/
in the upper-right corner to start/stop automatic data refreshing.
+
+4. Click 
in the upper-right corner to manually refresh the data.
+
+### Environment variables
+
+Click the **Environment Variables** tab to view the environment variables of the Deployment.
+
+### Events
+
+Click the **Events** tab to view the events of the Deployment.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/horizontal-pod-autoscaling.md b/content/en/docs/v3.4/project-user-guide/application-workloads/horizontal-pod-autoscaling.md
new file mode 100755
index 000000000..663444f5c
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/horizontal-pod-autoscaling.md
@@ -0,0 +1,104 @@
+---
+title: "Kubernetes HPA (Horizontal Pod Autoscaling) on KubeSphere"
+keywords: "Horizontal, Pod, Autoscaling, Autoscaler"
+description: "How to configure Kubernetes Horizontal Pod Autoscaling on KubeSphere."
+weight: 10290
+
+---
+
+This document describes how to configure Horizontal Pod Autoscaling (HPA) on KubeSphere.
+
+The Kubernetes HPA feature automatically adjusts the number of Pods to maintain average resource usage (CPU and memory) of Pods around preset values. For details about how HPA functions, see the [official Kubernetes document](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
+
+This document uses HPA based on CPU usage as an example. Operations for HPA based on memory usage are similar.
+
+## Prerequisites
+
+- You need to [enable the Metrics Server](../../../pluggable-components/metrics-server/).
+- You need to create a workspace, a project and a user (for example, `project-regular`). `project-regular` must be invited to the project and assigned the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](/docs/v3.3/quick-start/create-workspace-and-project/).
+
+## Create a Service
+
+1. Log in to the KubeSphere web console as `project-regular` and go to your project.
+
+2. Choose **Services** in **Application Workloads** on the left navigation bar and click **Create** on the right.
+
+3. In the **Create Service** dialog box, click **Stateless Service**.
+
+4. Set the Service name (for example, `hpa`) and click **Next**.
+
+5. Click **Add Container**, set **Image** to `mirrorgooglecontainers/hpa-example` and click **Use Default Ports**.
+
+6. Set the CPU request (for example, 0.15 cores) for each container, click **√**, and click **Next**.
+
+ {{< notice note >}}
+
+ * To use HPA based on CPU usage, you must set the CPU request for each container, which is the minimum CPU resource reserved for each container (for details, see the [official Kubernetes document](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)). The HPA feature compares the average Pod CPU usage with a target percentage of the average Pod CPU request.
+ * For HPA based on memory usage, you do not need to configure the memory request.
+
+ {{}}
+
+7. Click **Next** on the **Storage Settings** tab and click **Create** on the **Advanced Settings** tab.
+
+## Configure Kubernetes HPA
+
+1. Select **Deployments** in **Workloads** on the left navigation bar and click the HPA Deployment (for example, hpa-v1) on the right.
+
+2. Click **More** and select **Edit Autoscaling** from the drop-down menu.
+
+3. In the **Horizontal Pod Autoscaling** dialog box, configure the HPA parameters and click **OK**.
+
+ * **Target CPU Usage (%)**: Target percentage of the average Pod CPU request.
+ * **Target Memory Usage (MiB)**: Target average Pod memory usage in MiB.
+ * **Minimum Replicas**: Minimum number of Pods.
+ * **Maximum Replicas**: Maximum number of Pods.
+
+ In this example, **Target CPU Usage (%)** is set to `60`, **Minimum Replicas** is set to `1`, and **Maximum Replicas** is set to `10`.
+
+ {{< notice note >}}
+
+ Ensure that the cluster can provide sufficient resources for all Pods when the number of Pods reaches the maximum. Otherwise, the creation of some Pods will fail.
+
+ {{}}
+
+## Verify HPA
+
+This section uses a Deployment that sends requests to the HPA Service to verify that HPA automatically adjusts the number of Pods to meet the resource usage target.
+
+### Create a load generator Deployment
+
+1. Select **Workloads** in **Application Workloads** on the left navigation bar and click **Create** on the right.
+
+2. In the **Create Deployment** dialog box, set the Deployment name (for example, `load-generator`) and click **Next**.
+
+3. Click **Add Container** and set **Image** to `busybox`.
+
+4. Scroll down in the dialog box, select **Start Command**, and set **Command** to `sh,-c` and **Parameters** to `while true; do wget -q -O- http://
on the right of the load generator Deployment (for example, load-generator-v1), and choose **Delete** from the drop-down list. After the load-generator Deployment is deleted, check the status of the HPA Deployment again. The number of Pods decreases to the minimum.
+
+{{< notice note >}}
+
+The system may require a few minutes to adjust the number of Pods and collect data.
+
+{{}}
+
+## Edit HPA Configuration
+
+You can repeat steps in [Configure HPA](#configure-hpa) to edit the HPA configuration.
+
+## Cancel HPA
+
+1. Choose **Workloads** in **Application Workloads** on the left navigation bar and click the HPA Deployment (for example, hpa-v1) on the right.
+
+2. Click on the right of **Autoscaling** and choose **Cancel** from the drop-down list.
+
+
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/jobs.md b/content/en/docs/v3.4/project-user-guide/application-workloads/jobs.md
new file mode 100644
index 000000000..cbfcf136f
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/jobs.md
@@ -0,0 +1,162 @@
+---
+title: "Jobs"
+keywords: "KubeSphere, Kubernetes, Docker, Jobs"
+description: "Learn basic concepts of Jobs and how to create Jobs on KubeSphere."
+linkTitle: "Jobs"
+
+weight: 10250
+---
+
+A Job creates one or more Pods and ensures that a specified number of them successfully terminates. As Pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (namely, Job) is complete. Deleting a Job will clean up the Pods it created.
+
+A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first Pod fails or is deleted (for example, due to a node hardware failure or a node reboot). You can also use a Job to run multiple Pods in parallel.
+
+The following example demonstrates specific steps of creating a Job (computing π to 2000 decimal places) on KubeSphere.
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Job
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Jobs** under **Application Workloads** and click **Create**.
+
+### Step 2: Enter basic information
+
+Enter the basic information. The following describes the parameters:
+
+- **Name**: The name of the Job, which is also the unique identifier.
+- **Alias**: The alias name of the Job, making resources easier to identify.
+- **Description**: The description of the Job, which gives a brief introduction of the Job.
+
+### Step 3: Strategy settings (optional)
+
+You can set the values in this step or click **Next** to use the default values. Refer to the table below for detailed explanations of each field.
+
+| Name | Definition | Description |
+| ----------------------- | ---------------------------- | ------------------------------------------------------------ |
+| Maximum Retries | `spec.backoffLimit` | It specifies the maximum number of retries before this Job is marked as failed. It defaults to 6. |
+| Complete Pods | `spec.completions` | It specifies the desired number of successfully finished Pods the Job should be run with. Setting it to nil means that the success of any Pod signals the success of all Pods, and allows parallelism to have any positive value. Setting it to 1 means that parallelism is limited to 1 and the success of that Pod signals the success of the Job. For more information, see [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). |
+| Parallel Pods | `spec.parallelism` | It specifies the maximum desired number of Pods the Job should run at any given time. The actual number of Pods running in a steady state will be less than this number when the work left to do is less than max parallelism ((`.spec.completions - .status.successful`) < `.spec.parallelism`). For more information, see [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). |
+| Maximum Duration (s) | `spec.activeDeadlineSeconds` | It specifies the duration in seconds relative to the startTime that the Job may be active before the system tries to terminate it; the value must be a positive integer. |
+
+### Step 4: Set a Pod
+
+1. Select **Re-create Pod** for **Restart Policy**. You can only specify **Re-create Pod** or **Restart container** for **Restart Policy** when the Job is not completed:
+
+ - If **Restart Policy** is set to **Re-create Pod**, the Job creates a new Pod when the Pod fails, and the failed Pod does not disappear.
+
+ - If **Restart Policy** is set to **Restart container**, the Job will internally restart the container when the Pod fails, instead of creating a new Pod.
+
+2. Click **Add Container** which directs you to the **Add Container** page. Enter `perl` in the image search box and press **Enter**.
+
+3. On the same page, scroll down to **Start Command**. Enter the following commands in the box which computes pi to 2000 places then prints it. Click **√** in the lower-right corner and select **Next** to continue.
+
+ ```bash
+ perl,-Mbignum=bpi,-wle,print bpi(2000)
+ ```
+
+ {{< notice note >}}For more information about setting images, see [Pod Settings](../container-image-settings/).{{}}
+
+### Step 5: Inspect the Job manifest (optional)
+
+1. Enable **Edit YAML** in the upper-right corner which displays the manifest file of the Job. You can see all the values are set based on what you have specified in the previous steps.
+
+ ```yaml
+ apiVersion: batch/v1
+ kind: Job
+ metadata:
+ namespace: demo-project
+ labels:
+ app: job-test-1
+ name: job-test-1
+ annotations:
+ kubesphere.io/alias-name: Test
+ kubesphere.io/description: A job test
+ spec:
+ template:
+ metadata:
+ labels:
+ app: job-test-1
+ spec:
+ containers:
+ - name: container-4rwiyb
+ imagePullPolicy: IfNotPresent
+ image: perl
+ command:
+ - perl
+ - '-Mbignum=bpi'
+ - '-wle'
+ - print bpi(2000)
+ restartPolicy: Never
+ serviceAccount: default
+ initContainers: []
+ volumes: []
+ imagePullSecrets: null
+ backoffLimit: 5
+ completions: 4
+ parallelism: 2
+ activeDeadlineSeconds: 300
+ ```
+
+2. You can make adjustments in the manifest directly and click **Create** or disable the **Edit YAML** and get back to the **Create** page.
+
+ {{< notice note >}}You can skip **Storage Settings** and **Advanced Settings** for this tutorial. For more information, see [Mount volumes](../deployments/#step-4-mount-volumes) and [Configure advanced settings](../deployments/#step-5-configure-advanced-settings).{{}}
+
+### Step 6: Check the result
+
+1. In the final step of **Advanced Settings**, click **Create** to finish. A new item will be added to the Job list if the creation is successful.
+
+2. Click this Job and go to **Job Records** where you can see the information of each execution record. There are four completed Pods since **Completions** was set to `4` in Step 3.
+
+ {{< notice tip >}}
+You can rerun the Job if it fails and the reason for failure is displayed under **Message**.
+ {{}}
+
+3. In **Resource Status**, you can inspect the Pod status. Two Pods were created each time as **Parallel Pods** was set to 2. Click 
on the right and click 
to check the container log, which displays the expected calculation result.
+
+ {{< notice tip >}}
+
+- In **Resource Status**, the Pod list provides the Pod's detailed information (for example, creation time, node, Pod IP and monitoring data).
+- You can view the container information by clicking the Pod.
+- Click the container log icon to view the output logs of the container.
+- You can view the Pod details page by clicking the Pod name.
+
+ {{}}
+
+## Check Job Details
+
+### Operations
+
+On the Job details page, you can manage the Job after it is created.
+
+- **Edit Information**: Edit the basic information except `Name` of the Job.
+- **Rerun**: Rerun the Job, the Pod will restart, and a new execution record will be generated.
+- **View YAML**: View the Job's specification in YAML format.
+- **Delete**: Delete the Job and return to the Job list page.
+
+### Execution records
+
+1. Click the **Job Records** tab to view the execution records of the Job.
+
+2. Click 
to refresh the execution records.
+
+### Resource status
+
+1. Click the **Resource Status** tab to view the Pods of the Job.
+
+2. Click to refresh the Pod information, and click 
/
to display/hide the containers in each Pod.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the Job.
+
+### Environment variables
+
+Click the **Environment Variables** tab to view the environment variables of the Job.
+
+### Events
+
+Click the **Events** tab to view the events of the Job.
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/routes.md b/content/en/docs/v3.4/project-user-guide/application-workloads/routes.md
new file mode 100644
index 000000000..586f5cee2
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/routes.md
@@ -0,0 +1,133 @@
+---
+title: "Routes"
+keywords: "KubeSphere, Kubernetes, Route, Ingress"
+description: "Learn basic concepts of Routes (i.e. Ingress) and how to create Routes in KubeSphere."
+weight: 10270
+---
+
+This document describes how to create, use, and edit a Route on KubeSphere.
+
+A Route on KubeSphere is the same as an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress) on Kubernetes. You can use a Route and a single IP address to aggregate and expose multiple Services.
+
+## Prerequisites
+
+- You need to create a workspace, a project and two users (for example, `project-admin` and `project-regular`). In the project, the role of `admin` must be `project-admin` and that of `project-regular` must be `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](/docs/v3.3/quick-start/create-workspace-and-project/).
+- If the Route is to be accessed in HTTPS mode, you need to [create a Secret](/docs/v3.3/project-user-guide/configuration/secrets/) that contains the `tls.crt` (TLS certificate) and `tls.key` (TLS private key) keys used for encryption.
+- You need to [create at least one Service](/docs/v3.3/project-user-guide/application-workloads/services/). This document uses a demo Service as an example, which returns the Pod name to external requests.
+
+## Configure the Route Access Method
+
+1. Log in to the KubeSphere web console as `project-admin` and go to your project.
+
+2. Select **Gateway Settings** in **Project Settings** on the left navigation bar and click **Enable Gateway** on the right.
+
+3. In the displayed dialog box, set **Access Mode** to **NodePort** or **LoadBalancer**, and click **OK**.
+
+ {{< notice note >}}
+
+ If **Access Mode** is set to **LoadBalancer**, you may need to enable the load balancer plugin in your environment according to the plugin user guide.
+
+ {{}}
+
+## Create a Route
+
+### Step 1: Configure basic information
+
+1. Log out of the KubeSphere web console, log back in as `project-regular`, and go to the same project.
+
+2. Choose **Routes** in **Application Workloads** on the left navigation bar and click **Create** on the right.
+
+3. On the **Basic Information** tab, configure the basic information about the Route and click **Next**.
+ * **Name**: Name of the Route, which is used as a unique identifier.
+ * **Alias**: Alias of the Route.
+ * **Description**: Description of the Route.
+
+### Step 2: Configure routing rules
+
+1. On the **Routing Rules** tab, click **Add Routing Rule**.
+
+2. Select a mode, configure routing rules, click **√**, and click **Next**.
+
+ * **Auto Generate**: KubeSphere automatically generates a domain name in the `
on the right to further edit it, such as its metadata (excluding **Name**), YAML, port, and Internet access.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Edit Service**: View the access type and set selectors and ports.
+ - **Edit External Access**: Edit external access method for the Service.
+ - **Delete**: When you delete a Service, associated resources will be displayed. If you check them, they will be deleted together with the Service.
+
+2. Click the name of the Service and you can go to its details page.
+
+ - Click **More** to expand the drop-down menu which is the same as the one in the Service list.
+ - The Pod list provides detailed information of the Pod (status, node, Pod IP and resource usage).
+ - You can view the container information by clicking a Pod item.
+ - Click the container log icon to view output logs of the container.
+ - You can view the Pod details page by clicking the Pod name.
+
+### Resource status
+
+1. Click the **Resource Status** tab to view information about the Service ports, workloads, and Pods.
+
+2. In the **Pods** area, click 
to refresh the Pod information, and click 
/
to display/hide the containers in each Pod.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the Service.
+
+### Events
+
+Click the **Events** tab to view the events of the Service.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/application-workloads/statefulsets.md b/content/en/docs/v3.4/project-user-guide/application-workloads/statefulsets.md
new file mode 100644
index 000000000..d5b160d06
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application-workloads/statefulsets.md
@@ -0,0 +1,148 @@
+---
+title: "Kubernetes StatefulSet in KubeSphere"
+keywords: 'KubeSphere, Kubernetes, StatefulSets, Dashboard, Service'
+description: 'Learn basic concepts of StatefulSets and how to create StatefulSets on KubeSphere.'
+linkTitle: "StatefulSets"
+weight: 10220
+---
+
+As a workload API object, a Kubernetes StatefulSet is used to manage stateful applications. It is responsible for the deploying, scaling of a set of Pods, and guarantees the ordering and uniqueness of these Pods.
+
+Like a Deployment, a StatefulSet manages Pods that are based on an identical container specification. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These Pods are created from the same specification, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
+
+If you want to use storage volumes to provide persistence for your workload, you can use a StatefulSet as part of the solution. Although individual Pods in a StatefulSet are susceptible to failure, the persistent Pod identifiers make it easier to match existing volumes to the new Pods that replace any that have failed.
+
+StatefulSets are valuable for applications that require one or more of the following.
+
+- Stable, unique network identifiers.
+- Stable, persistent storage.
+- Ordered, graceful deployment, and scaling.
+- Ordered, automated rolling updates.
+
+For more information, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/).
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Kubernetes StatefulSet
+
+In KubeSphere, a **Headless** service is also created when you create a StatefulSet. You can find the headless service in [Services](../services/) under **Application Workloads** in a project.
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Application Workloads** of a project, select **Workloads**, and click **Create** under the **StatefulSets** tab.
+
+### Step 2: Enter basic information
+
+Specify a name for the StatefulSet (for example, `demo-stateful`), select a project, and click **Next**.
+
+### Step 3: Set a Pod
+
+1. Before you set an image, define the number of replicated Pods in **Pod Replicas** by clicking 
or 
, which is indicated by the `.spec.replicas` field in the manifest file.
+
+ {{< notice tip >}}
+
+You can see the StatefulSet manifest file in YAML format by enabling **Edit YAML** in the upper-right corner. KubeSphere allows you to edit the manifest file directly to create a StatefulSet. Alternatively, you can follow the steps below to create a StatefulSet via the dashboard.
+
+ {{}}
+
+2. Click **Add Container**.
+
+3. Enter an image name from public Docker Hub or from a [private repository](../../configuration/image-registry/) you specified. For example, enter `nginx` in the search box and press **Enter**.
+
+ {{< notice note >}}
+
+- Remember to press **Enter** on your keyboard after you enter an image name in the search box.
+- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configuration**.
+
+ {{}}
+
+4. Set requests and limits for CPU and memory resources based on your needs. For more information, see [Resource Request and Resource Limit in Container Image Settings](../container-image-settings/#add-container-image).
+
+5. Click **Use Default Ports** for **Port Settings** or you can customize **Protocol**, **Name** and **Container Port**.
+
+6. Select a policy for image pulling from the drop-down list. For more information, see [Image Pull Policy in Container Image Settings](../container-image-settings/#add-container-image).
+
+7. For other settings (**Health Check**, **Start Command**, **Environment Variables**, **Container Security Context** and **Synchronize Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Pod Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the lower-right corner to continue.
+
+8. Select an update strategy from the drop-down menu. It is recommended you choose **Rolling Update**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
+
+9. Select a Pod scheduling rule. For more information, see [Pod Scheduling Rules](../container-image-settings/#pod-scheduling-rules).
+
+10. Click **Next** to continue when you finish setting the container image.
+
+### Step 4: Mount volumes
+
+StatefulSets can use the volume template, but you must create it in **Storage** in advance. For more information about volumes, visit [Volumes](../../storage/volumes/#mount-a-volume). When you finish, click **Next** to continue.
+
+### Step 5: Configure advanced settings
+
+You can set a policy for node scheduling and add StatefulSet metadata in this section. When you finish, click **Create** to complete the whole process of creating a StatefulSet.
+
+- **Select Nodes**
+
+ Assign Pod replicas to run on specified nodes. It is specified in the field `nodeSelector`.
+
+- **Add Metadata**
+
+ Additional metadata settings for resources such as **Labels** and **Annotations**.
+
+## Check Kubernetes StatefulSet Details
+
+### Details page
+
+1. After a StatefulSet is created, it will be displayed in the list. You can click 
on the right to select options from the menu to modify your StatefulSet.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create the StatefulSet.
+ - **Delete**: Delete the StatefulSet.
+
+2. Click the name of the StatefulSet and you can go to its details page.
+
+3. Click **More** to display what operations about this StatefulSet you can do.
+
+ - **Roll Back**: Select the revision to roll back.
+ - **Edit Service**: Set the port to expose the container image and the service port.
+ - **Edit Settings**: Configure update strategies, containers and volumes.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Re-create**: Re-create this StatefulSet.
+ - **Delete**: Delete the StatefulSet, and return to the StatefulSet list page.
+
+4. Click the **Resource Status** tab to view the port and Pod information of a StatefulSet.
+
+ - **Replica Status**: Click or to increase or decrease the number of Pod replicas.
+ - **Pods**
+
+ - The Pod list provides detailed information of the Pod (status, node, Pod IP and resource usage).
+ - You can view the container information by clicking a Pod item.
+ - Click the container log icon to view output logs of the container.
+ - You can view the Pod details page by clicking the Pod name.
+
+### Revision records
+
+After the resource template of workload is changed, a new log will be generated and Pods will be rescheduled for a version update. The latest 10 versions will be saved by default. You can implement a redeployment based on the change log.
+
+### Metadata
+
+Click the **Metadata** tab to view the labels and annotations of the StatefulSet.
+
+### Monitoring
+
+1. Click the **Monitoring** tab to view the CPU usage, memory usage, outbound traffic, and inbound traffic of the StatefulSet.
+
+2. Click the drop-down menu in the upper-right corner to customize the time range and sampling interval.
+
+3. Click 
/
in the upper-right corner to start/stop automatic data refreshing.
+
+4. Click 
in the upper-right corner to manually refresh the data.
+
+### Environment variables
+
+Click the **Environment Variables** tab to view the environment variables of the StatefulSet.
+
+### Events
+
+Click the **Events** tab to view the events of the StatefulSet.
+
diff --git a/content/en/docs/v3.4/project-user-guide/application/_index.md b/content/en/docs/v3.4/project-user-guide/application/_index.md
new file mode 100644
index 000000000..7e0d6b2b6
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Applications"
+weight: 10100
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/application/app-template.md b/content/en/docs/v3.4/project-user-guide/application/app-template.md
new file mode 100644
index 000000000..30958f0bc
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application/app-template.md
@@ -0,0 +1,33 @@
+---
+title: "App Templates"
+keywords: 'Kubernetes, Chart, Helm, KubeSphere, Application Template, Repository'
+description: 'Understand the concept of app templates and how they can help to deploy applications within enterprises.'
+linkTitle: "App Templates"
+weight: 10110
+---
+
+An app template serves as a way for users to upload, deliver, and manage apps. Generally, an app is composed of one or more Kubernetes workloads (for example, [Deployments](../../../project-user-guide/application-workloads/deployments/), [StatefulSets](../../../project-user-guide/application-workloads/statefulsets/) and [DaemonSets](../../../project-user-guide/application-workloads/daemonsets/)) and [Services](../../../project-user-guide/application-workloads/services/) based on how it functions and communicates with the external environment. Apps that are uploaded as app templates are built based on a [Helm](https://helm.sh/) package.
+
+## How App Templates Work
+
+You can deliver Helm charts to the public repository of KubeSphere or import a private app repository to offer app templates.
+
+The public repository, also known as the App Store on KubeSphere, is accessible to every tenant in a workspace. After [uploading the Helm chart of an app](../../../workspace-administration/upload-helm-based-application/), you can deploy your app to test its functions and submit it for review. Ultimately, you have the option to release it to the App Store after it is approved. For more information, see [Application Lifecycle Management](../../../application-store/app-lifecycle-management/).
+
+For a private repository, only users with required permissions are allowed to [add private repositories](../../../workspace-administration/app-repository/import-helm-repository/) in a workspace. Generally, the private repository is built based on object storage services, such as MinIO. After imported to KubeSphere, these private repositories serve as application pools to provide app templates.
+
+{{< notice note >}}
+
+[For individual apps that are uploaded as Helm charts](../../../workspace-administration/upload-helm-based-application/) to KubeSphere, they are displayed in the App Store together with built-in apps after approved and released. Besides, when you select app templates from private app repositories, you can also see **Current workspace** in the list, which stores these individual apps uploaded as Helm charts.
+
+{{}}
+
+KubeSphere deploys app repository services based on [OpenPitrix](https://github.com/openpitrix/openpitrix) as a [pluggable component](../../../pluggable-components/app-store/).
+
+## Why App Templates
+
+App templates enable users to deploy and manage apps in a visualized way. Internally, they play an important role as shared resources (for example, databases, middleware and operating systems) created by enterprises for the coordination and cooperation within teams. Externally, app templates set industry standards of building and delivery. Users can take advantage of app templates in different scenarios to meet their own needs through one-click deployment.
+
+In addition, as OpenPitrix is integrated to KubeSphere to provide application management across the entire lifecycle, the platform allows ISVs, developers and regular users to all participate in the process. Backed by the multi-tenant system of KubeSphere, each tenant is only responsible for their own part, such as app uploading, app review, release, test, and version management. Ultimately, enterprises can build their own App Store and enrich their application pools with their customized standards. As such, apps can also be delivered in a standardized fashion.
+
+For more information about how to use app templates, see [Deploy Apps from App Templates](../deploy-app-from-template/).
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/application/compose-app.md b/content/en/docs/v3.4/project-user-guide/application/compose-app.md
new file mode 100644
index 000000000..5a7e7bb27
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application/compose-app.md
@@ -0,0 +1,96 @@
+---
+title: "Create a Microservices-based App"
+keywords: 'KubeSphere, Kubernetes, service mesh, microservices'
+description: 'Learn how to compose a microservice-based application from scratch.'
+linkTitle: "Create a Microservices-based App"
+weight: 10140
+---
+
+With each microservice handling a single part of the app's functionality, an app can be divided into different components. These components have their own responsibilities and limitations, independent from each other. In KubeSphere, this kind of app is called **Composed App**, which can be built through newly created Services or existing Services.
+
+This tutorial demonstrates how to create a microservices-based app Bookinfo, which is composed of four Services, and set a customized domain name to access the app.
+
+## Prerequisites
+
+- You need to create a workspace, a project, and a user (`project-regular`) for this tutorial. The user needs to be invited to the project with the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- `project-admin` needs to [set the project gateway](../../../project-administration/project-gateway/) so that `project-regular` can define a domain name when creating the app.
+
+## Create Microservices that Compose an App
+
+1. Log in to the web console of KubeSphere and navigate to **Apps** in **Application Workloads** of your project. On the **Composed Apps** tab, click **Create**.
+
+2. Set a name for the app (for example, `bookinfo`) and click **Next**.
+
+3. On the **Service Settings** page, you need to create microservices that compose the app. Click **Create Service** and select **Stateless Service**.
+
+4. Set a name for the Service (e.g `productpage`) and click **Next**.
+
+ {{< notice note >}}
+
+ You can create a Service on the dashboard directly or enable **Edit YAML** in the upper-right corner to edit the YAML file.
+
+ {{}}
+
+5. Click **Add Container** under **Containers** and enter `kubesphere/examples-bookinfo-productpage-v1:1.13.0` in the search box to use the Docker Hub image.
+
+ {{< notice note >}}
+
+ You must press **Enter** in your keyboard after you enter the image name.
+
+ {{}}
+
+6. Click **Use Default Ports**. For more information about image settings, see [Pod Settings](../../../project-user-guide/application-workloads/container-image-settings/). Click **√** in the lower-right corner and **Next** to continue.
+
+7. On the **Storage Settings** page, [add a volume](../../../project-user-guide/storage/volumes/) or click **Next** to continue.
+
+8. Click **Create** on the **Advanced Settings** page.
+
+9. Similarly, add the other three microservices for the app. Here is the image information:
+
+ | Service | Name | Image |
+ | --------- | --------- | ------------------------------------------------ |
+ | Stateless | `details` | `kubesphere/examples-bookinfo-details-v1:1.13.0` |
+ | Stateless | `reviews` | `kubesphere/examples-bookinfo-reviews-v1:1.13.0` |
+ | Stateless | `ratings` | `kubesphere/examples-bookinfo-ratings-v1:1.13.0` |
+
+10. When you finish adding microservices, click **Next**.
+
+11. On the **Route Settings** page, click **Add Routing Rule**. On the **Specify Domain** tab, set a domain name for your app (for example, `demo.bookinfo`) and select `HTTP` in the **Protocol** field. For `Paths`, select the Service `productpage` and port `9080`. Click **OK** to continue.
+
+ {{< notice note >}}
+
+The button **Add Routing Rule** is not visible if the project gateway is not set.
+
+{{}}
+
+12. You can add more rules or click **Create** to finish the process.
+
+13. Wait for your app to reach the **Ready** status.
+
+
+## Access the App
+
+1. As you set a domain name for the app, you need to add an entry in the hosts (`/etc/hosts`) file. For example, add the IP address and hostname as below:
+
+ ```txt
+ 192.168.0.9 demo.bookinfo
+ ```
+
+ {{< notice note >}}
+
+ You must add your **own** IP address and hostname.
+
+ {{}}
+
+2. In **Composed Apps**, click the app you just created.
+
+3. In **Resource Status**, click **Access Service** under **Routes** to access the app.
+
+ {{< notice note >}}
+
+ Make sure you open the port in your security group.
+
+ {{}}
+
+4. Click **Normal user** and **Test user** respectively to see other **Services**.
+
diff --git a/content/en/docs/v3.4/project-user-guide/application/deploy-app-from-appstore.md b/content/en/docs/v3.4/project-user-guide/application/deploy-app-from-appstore.md
new file mode 100644
index 000000000..f9613b89c
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/application/deploy-app-from-appstore.md
@@ -0,0 +1,62 @@
+---
+title: "Deploy Apps from the App Store"
+keywords: 'Kubernetes, Chart, Helm, KubeSphere, Application, App Store'
+description: 'Learn how to deploy an application from the App Store.'
+linkTitle: "Deploy Apps from the App Store"
+weight: 10130
+---
+
+The [App Store](../../../application-store/) is also the public app repository on the platform, which means every tenant on the platform can view the applications in the Store regardless of which workspace they belong to. The App Store contains 16 featured enterprise-ready containerized apps and apps released by tenants from different workspaces on the platform. Any authenticated users can deploy applications from the Store. This is different from private app repositories which are only accessible to tenants in the workspace where private app repositories are imported.
+
+This tutorial demonstrates how to quickly deploy [NGINX](https://www.nginx.com/) from the KubeSphere App Store powered by [OpenPitrix](https://github.com/openpitrix/openpitrix) and access its service through a NodePort.
+
+## Prerequisites
+
+- You have enabled [OpenPitrix (App Store)](../../../pluggable-components/app-store/).
+- You need to create a workspace, a project, and a user (`project-regular`) for this tutorial. The user must be invited to the project and granted the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+### Step 1: Deploy NGINX from the App Store
+
+1. Log in to the web console of KubeSphere as `project-regular` and click **App Store** in the upper-left corner.
+
+ {{< notice note >}}
+
+ You can also go to **Apps** under **Application Workloads** in your project, click **Create**, and select **From App Store** to go to the App Store.
+
+ {{}}
+
+2. Search for NGINX, click it, and click **Install** on the **App Information** page. Make sure you click **Agree** in the displayed **Deployment Agreement** dialog box.
+
+3. Set a name and select an app version, confirm the location where NGINX will be deployed , and click **Next**.
+
+4. In **App Settings**, specify the number of replicas to deploy for the app and enable Ingress based on your needs. When you finish, click **Install**.
+
+ {{< notice note >}}
+
+ To specify more values for NGINX, use the toggle to see the app’s manifest in YAML format and edit its configurations.
+
+ {{}}
+
+5. Wait until NGINX is up and running.
+
+### Step 2: Access NGINX
+
+To access NGINX outside the cluster, you need to expose the app through a NodePort first.
+
+1. Go to **Services** in the created project and click the service name of NGINX.
+
+2. On the Service details page, click **More** and select **Edit External Access** from the drop-down menu.
+
+3. Select **NodePort** for **Access Method** and click **OK**. For more information, see [Project Gateway](../../../project-administration/project-gateway/).
+
+4. Under **Ports**, view the exposed port.
+
+5. Access NGINX through `
on the right and select the operation below from the drop-down list.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Edit Settings**: Modify the key-value pair of the ConfigMap.
+ - **Delete**: Delete the ConfigMap.
+
+2. Click the name of the ConfigMap to go to its details page. Under the tab **Data**, you can see all the key-value pairs you have added for the ConfigMap.
+
+3. Click **More** to display what operations about this ConfigMap you can do.
+
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Edit Settings**: Modify the key-value pair of the ConfigMap.
+ - **Delete**: Delete the ConfigMap, and return to the list page.
+
+4. Click **Edit Information** to view and edit the basic information.
+
+
+## Use a ConfigMap
+
+When you create workloads, [Services](../../../project-user-guide/application-workloads/services/), [Jobs](../../../project-user-guide/application-workloads/jobs/) or [CronJobs](../../../project-user-guide/application-workloads/cronjobs/), you may need to add environment variables for containers. On the **Add Container** page, check **Environment Variables** and click **From secret** to use a ConfigMap from the list.
diff --git a/content/en/docs/v3.4/project-user-guide/configuration/image-registry.md b/content/en/docs/v3.4/project-user-guide/configuration/image-registry.md
new file mode 100644
index 000000000..0cce22b71
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/configuration/image-registry.md
@@ -0,0 +1,104 @@
+---
+title: "Image Registries"
+keywords: 'KubeSphere, Kubernetes, docker, Secrets'
+description: 'Learn how to create an image registry on KubeSphere.'
+linkTitle: "Image Registries"
+weight: 10430
+---
+
+A Docker image is a read-only template that can be used to deploy container services. Each image has a unique identifier (for example, image name:tag). For example, an image can contain a complete package of an Ubuntu operating system environment with only Apache and a few applications installed. An image registry is used to store and distribute Docker images.
+
+This tutorial demonstrates how to create Secrets for different image registries.
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Secret
+
+When you create workloads, [Services](../../../project-user-guide/application-workloads/services/), [Jobs](../../../project-user-guide/application-workloads/jobs/), or [CronJobs](../../../project-user-guide/application-workloads/cronjobs/), you can select images from your private registry in addition to the public registry. To use images from your private registry, you must create a Secret for it so that the registry can be integrated to KubeSphere.
+
+### Step 1: Open the dashboard
+
+Log in to the web console of KubeSphere as `project-regular`. Go to **Configuration** of a project, select **Secrets** and click **Create**.
+
+### Step 2: Enter basic information
+
+Specify a name for the Secret (for example, `demo-registry-secret`) and click **Next** to continue.
+
+{{< notice tip >}}
+
+You can see the Secret's manifest file in YAML format by enabling **Edit YAML** in the upper-right corner. KubeSphere allows you to edit the manifest file directly to create a Secret. Alternatively, you can follow the steps below to create a Secret via the dashboard.
+
+{{}}
+
+### Step 3: Specify image registry information
+
+Select **Image registry information** for **Type**. To use images from your private registry as you create application workloads, you need to specify the following fields.
+
+- **Registry Address**. The address of the image registry that stores images for you to use when creating application workloads.
+- **Username**. The account name you use to log in to the registry.
+- **Password**. The password you use to log in to the registry.
+- **Email** (optional). Your email address.
+
+#### Add the Docker Hub registry
+
+1. Before you add your image registry in [Docker Hub](https://hub.docker.com/), make sure you have an available Docker Hub account. On the **Secret Settings** page, enter `docker.io` for **Registry Address** and enter your Docker ID and password for **User Name** and **Password**. Click **Validate** to check whether the address is available.
+
+2. Click **Create**. Later, the Secret is displayed on the **Secrets** page. For more information about how to edit the Secret after you create it, see [Check Secret Details](../../../project-user-guide/configuration/secrets/#check-secret-details).
+
+#### Add the Harbor image registry
+
+[Harbor](https://goharbor.io/) is an open-source trusted cloud-native registry project that stores, signs, and scans content. Harbor extends the open-source Docker Distribution by adding the functionalities usually required by users such as security, identity and management. Harbor uses HTTP and HTTPS to serve registry requests.
+
+**HTTP**
+
+1. You need to modify the Docker configuration for all nodes within the cluster. For example, if there is an external Harbor registry and its IP address is `http://192.168.0.99`, then you need to add the field `--insecure-registry=192.168.0.99` to `/etc/systemd/system/docker.service.d/docker-options.conf`:
+
+ ```bash
+ [Service]
+ Environment="DOCKER_OPTS=--registry-mirror=https://registry.docker-cn.com --insecure-registry=10.233.0.0/18 --data-root=/var/lib/docker --log-opt max-size=50m --log-opt max-file=5 \
+ --insecure-registry=192.168.0.99"
+ ```
+
+ {{< notice note >}}
+
+ - Replace the image registry address with your own registry address.
+
+ - `Environment` represents [dockerd options](https://docs.docker.com/engine/reference/commandline/dockerd/).
+
+ - `--insecure-registry` is required by the Docker daemon for the communication with an insecure registry. Refer to [Docker documentation](https://docs.docker.com/engine/reference/commandline/dockerd/#insecure-registries) for its syntax.
+
+ {{}}
+
+2. After that, reload the configuration file and restart Docker:
+
+ ```bash
+ sudo systemctl daemon-reload
+ ```
+
+ ```bash
+ sudo systemctl restart docker
+ ```
+
+3. Go back to the **Data Settings** page and select **Image registry information** for **Type**. Enter your Harbor IP address for **Registry Address** and enter the username and password.
+
+ {{< notice note >}}
+
+ If you want to use the domain name instead of the IP address with Harbor, you may need to configure the CoreDNS and nodelocaldns within the cluster.
+
+ {{}}
+
+4. Click **Create**. Later, the Secret is displayed on the **Secrets** page. For more information about how to edit the Secret after you create it, see [Check Secret Details](../../../project-user-guide/configuration/secrets/#check-secret-details).
+
+**HTTPS**
+
+For the integration of the HTTPS-based Harbor registry, refer to [Harbor Documentation](https://goharbor.io/docs/1.10/install-config/configure-https/). Make sure you use `docker login` to connect to your Harbor registry.
+
+## Use an Image Registry
+
+When you set images, you can select the private image registry if the Secret of it is created in advance. For example, click the arrow on the **Add Container** page to expand the registry list when you create a [Deployment](../../../project-user-guide/application-workloads/deployments/). After you choose the image registry, enter the image name and tag to use the image.
+
+If you use YAML to create a workload and need to use a private image registry, you need to manually add `kubesphere.io/imagepullsecrets` to `annotations` in your local YAML file, and enter the key-value pair in JSON format, where `key` must be the name of the container, and `value` must be the name of the secret, as shown in the following sample.
+
+
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/configuration/secrets.md b/content/en/docs/v3.4/project-user-guide/configuration/secrets.md
new file mode 100644
index 000000000..16e9dfd05
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/configuration/secrets.md
@@ -0,0 +1,121 @@
+---
+title: "Kubernetes Secrets in KubeSphere"
+keywords: 'KubeSphere, Kubernetes, Secrets'
+description: 'Learn how to create a Secret on KubeSphere.'
+linkTitle: "Secrets"
+weight: 10410
+---
+
+A Kubernetes [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) is used to store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. To use a Secret, a Pod needs to reference it in one of [the following ways](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets).
+
+- As a file in a volume mounted and consumed by containerized applications running in a Pod.
+- As environment variables used by containers in a Pod.
+- As image registry credentials when images are pulled for the Pod by the kubelet.
+
+This tutorial demonstrates how to create a Secret in KubeSphere.
+
+## Prerequisites
+
+You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Kubernetes Secret
+
+### Step 1: Open the dashboard
+
+Log in to the console as `project-regular`. Go to **Configuration** of a project, select **Secrets** and click **Create**.
+
+### Step 2: Enter basic information
+
+Specify a name for the Secret (for example, `demo-secret`) and click **Next** to continue.
+
+{{< notice tip >}}
+
+You can see the Secret's manifest file in YAML format by enabling **Edit YAML** in the upper-right corner. KubeSphere allows you to edit the manifest file directly to create a Secret. Alternatively, you can follow the steps below to create a Secret via the dashboard.
+
+{{}}
+
+### Step 3: Set a Secret
+
+1. Under the tab **Data Settings**, you must select a Secret type. In KubeSphere, you can create the following Kubernetes Secret types, indicated by the `type` field.
+
+ {{< notice note >}}
+
+ For all Secret types, values for all keys under the field `data` in the manifest must be base64-encoded strings. After you specify values on the KubeSphere dashboard, KubeSphere converts them into corresponding base64 character values in the YAML file. For example, if you enter `password` and `hello123` for **Key** and **Value** respectively on the **Edit Data** page when you create the default type of Secret, the actual value displaying in the YAML file is `aGVsbG8xMjM=` (namely, `hello123` in base64 format), automatically created by KubeSphere.
+
+ {{}}
+
+ - **Default**. The type of [Opaque](https://kubernetes.io/docs/concepts/configuration/secret/#opaque-secrets) in Kubernetes, which is also the default Secret type in Kubernetes. You can create arbitrary user-defined data for this type of Secret. Click **Add Data** to add key-value pairs for it.
+
+ - **TLS information**. The type of [kubernetes.io/tls](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) in Kubernetes, which is used to store a certificate and its associated key that are typically used for TLS, such as TLS termination of Ingress resources. You must specify **Credential** and **Private Key** for it, indicated by `tls.crt` and `tls.key` in the YAML file respectively.
+
+ - **Image registry information**. The type of [kubernetes.io/dockerconfigjson](https://kubernetes.io/docs/concepts/configuration/secret/#docker-config-secrets) in Kubernetes, which is used to store the credentials for accessing a Docker registry for images. For more information, see [Image Registries](../image-registry/).
+
+ - **Username and password**. The type of [kubernetes.io/basic-auth](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret) in Kubernetes, which is used to store credentials needed for basic authentication. You must specify **Username** and **Password** for it, indicated by `username` and `password` in the YAML file respectively.
+
+2. For this tutorial, select the default type of Secret. Click **Add Data** and enter the **Key** (`MYSQL_ROOT_PASSWORD`) and **Value** (`123456`) to specify a Secret for MySQL.
+
+3. Click **√** in the lower-right corner to confirm. You can continue to add key-value pairs to the Secret or click **Create** to finish the creation. For more information about how to use the Secret, see [Compose and Deploy WordPress](../../../quick-start/wordpress-deployment/#task-3-create-an-application).
+
+## Check Secret Details
+
+1. After a Secret is created, it will be displayed in the list. You can click 
on the right and select the operation from the menu to modify it.
+
+ - **Edit Information**: View and edit the basic information.
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Edit Settings**: Modify the key-value pair of the Secret.
+ - **Delete**: Delete the Secret.
+
+2. Click the name of the Secret and you can go to its details page. Under the tab **Data**, you can see all the key-value pairs you have added for the Secret.
+
+ {{< notice note >}}
+
+As mentioned above, KubeSphere automatically converts the value of a key into its corresponding base64 character value. To see the actual decoded value, click 
on the right.
+
+{{}}
+
+3. Click **More** to display what operations about this Secret you can do.
+
+ - **Edit YAML**: View, upload, download, or update the YAML file.
+ - **Edit Secret**: Modify the key-value pair of the Secret.
+ - **Delete**: Delete the Secret, and return to the list page.
+
+
+## How to Use a Kubernetes Secret
+
+Generally, you need to use a Secret when you create workloads, [Services](../../../project-user-guide/application-workloads/services/), [Jobs](../../../project-user-guide/application-workloads/jobs/) or [CronJobs](../../../project-user-guide/application-workloads/cronjobs/). For example, you can select a Secret for a code repository. For more information, see [Image Registries](../image-registry/).
+
+Alternatively, you may need to add environment variables for containers. On the **Container Image** page, select **Environment Variables** and click **From secret** to use a Secret from the list.
+
+## Create the Most Common Secrets
+
+This section shows how to create Secrets from your Docker Hub account and GitHub account.
+
+### Create the Docker Hub Secret
+
+1. Log in to KubeSphere as `project-regular` and go to your project. Select **Secrets** from the navigation bar and click **Create** on the right.
+
+2. Set a name, such as `dockerhub-id`, and click **Next**. On the **Data Settings** page, fill in the following fields and click **Validate** to verify whether the information provided is valid.
+
+ **Type**: Select **Image registry information**.
+
+ **Registry Address**: Enter the Docker Hub registry address, such as `docker.io`.
+
+ **Username**: Enter your Docker ID.
+
+ **Password**: Enter your Docker Hub password.
+
+3. Click **Create** to finish.
+
+### Create the GitHub Secret
+
+1. Log in to KubeSphere as `project-regular` and go to your project. Select **Secrets** from the navigation bar and click **Create** on the right.
+
+2. Set a name, such as `github-id`, and click **Next**. On the **Data Settings** page, fill in the following fields.
+
+ **Type**: Select **Username and password**.
+
+ **Username**: Enter your GitHub account.
+
+ **Password**: Enter your GitHub password.
+
+3. Click **Create** to finish.
diff --git a/content/en/docs/v3.4/project-user-guide/configuration/serviceaccounts.md b/content/en/docs/v3.4/project-user-guide/configuration/serviceaccounts.md
new file mode 100644
index 000000000..c7dca7108
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/configuration/serviceaccounts.md
@@ -0,0 +1,50 @@
+---
+title: "Service Accounts"
+keywords: 'KubeSphere, Kubernetes, Service Accounts'
+description: 'Learn how to create service accounts on KubeSphere.'
+linkTitle: "Service Accounts"
+weight: 10440
+---
+
+A [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) provides an identity for processes that run in a Pod. When accessing a cluster, a user is authenticated by the API server as a particular user account. Processes in containers inside Pods are authenticated as a particular service account when these processes contact the API server.
+
+This document describes how to create service accounts on KubeSphere.
+
+## Prerequisites
+
+You have created a workspace, a project, and a user (`project-regular`), invited the user to the project, and assigned it the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create a Service Account
+
+1. Log in to the KubeSphere console as `project-regular`, and click **Projects**.
+
+1. Select a project where you want to create a service account.
+
+1. On the left navigation pane, select **Configuration** > **Service Accounts**. You can see a service account `default` on the **Service Accounts** page, which is automatically created when the project is created.
+
+ {{< notice note >}}
+
+ If you have not specified any service account when creating workloads in a project, the service account `default` in the same project is automatically assigned.
+
+ {{}}
+
+2. Click **Create**. In the displayed **Create Service Account** dialog box, set the following parameters:
+
+- **Name** (mandatory): Specifies a unique identifier for the service account.
+- **Alias**: Specifies an alias for the service account to help you better identify the service account.
+- **Description**: Briefly introduces the service account.
+- **Project Role**: Selects a project role from the drop-down list for the service account. Different project roles have [different permissions](../../../project-administration/role-and-member-management/#built-in-roles).
+
+4. Click **Create** after you finish setting the parameters. The service account created is displayed on the **Service Accounts** page.
+
+## View the Details Page of a Service Account
+
+1. On the left navigation pane, select **Configuration** > **Service Accounts**. Click the service account created to go to its details page.
+
+2. Click **Edit Information** to edit its basic information, or click **More** to perform the following operations:
+ - **Edit YAML**: Views, updates, or downloads the YAML file.
+ - **Change Role**: Changes the project role of the service account.
+ - **Delete**: Deletes the service account.
+
+3. On the **Resource Status** tab on the right, view details of the Secret and the kubeconfig of the service account.
+
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/_index.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/_index.md
new file mode 100644
index 000000000..5e82ef007
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Custom Application Monitoring"
+weight: 10800
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/_index.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/_index.md
new file mode 100644
index 000000000..b06c2a50e
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Examples"
+weight: 10811
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md
new file mode 100644
index 000000000..5522caf7b
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md
@@ -0,0 +1,72 @@
+---
+title: "Monitor MySQL"
+keywords: 'monitoring, Prometheus, MySQL, MySQL Exporter'
+description: 'Deploy MySQL and MySQL Exporter and create a dashboard to monitor the app.'
+linkTitle: "Monitor MySQL"
+weight: 10812
+---
+From the [Introduction](../../introduction#indirect-exposing) section, you know it is not feasible to instrument MySQL with Prometheus metrics directly. To expose MySQL metrics in Prometheus format, you need to deploy MySQL Exporter first.
+
+This tutorial demonstrates how to monitor and visualize MySQL metrics.
+
+## Prerequisites
+
+- You need to [enable the App Store](../../../../pluggable-components/app-store/). MySQL and MySQL Exporter are available in the App Store.
+- You need to create a workspace, a project, and a user (`project-regular`) for this tutorial. The user needs to be invited to the project with the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/).
+
+## Step 1: Deploy MySQL
+
+To begin with, you need to [deploy MySQL from the App Store](../../../../application-store/built-in-apps/mysql-app/).
+
+1. Go to your project and click **App Store** in the upper-left corner.
+
+2. Click **MySQL** to go to its details page and click **Install** on the **App Information** tab.
+
+ {{< notice note >}}
+
+MySQL is a built-in app in the KubeSphere App Store, which means it can be deployed and used directly once the App Store is enabled.
+
+{{}}
+
+3. Under **Basic Information**, set a **Name** and select a **Version**. Select the project where the app is deployed under **Location** and click **Next**.
+
+4. Under **App Settings**, set a root password by uncommenting the `mysqlRootPassword` field and click **Install**.
+
+5. Wait until MySQL is up and running.
+
+## Step 2: Deploy MySQL Exporter
+
+You need to deploy MySQL Exporter in the same project on the same cluster. MySQL Exporter is responsible for querying the status of MySQL and reports the data in Prometheus format.
+
+1. Go to **App Store** and click **MySQL Exporter**.
+
+2. On the details page, click **Install**.
+
+3. Under **Basic Information**, set a **Name** and select a **Version**. Select the same project where MySQL is deployed under **Location** and click **Next**.
+
+4. Make sure `serviceMonitor.enabled` is set to `true`. The built-in MySQL Exporter sets it to `true` by default, so you don't need to manually change the value of `serviceMonitor.enabled`.
+
+ {{< notice warning >}}
+You must enable the ServiceMonitor CRD if you are using external exporter Helm charts. Those charts usually disable ServiceMonitors by default and require manual modification.
+ {{}}
+
+5. Modify MySQL connection parameters. MySQL Exporter needs to connect to the target MySQL. In this tutorial, MySQL is installed with the service name `mysql-dh3ily`. Navigate to `mysql` in the configuration file, and set `host` to `mysql-dh3ily`, `pass` to `testing`, and `user` to `root`. Note that your MySQL service may be created with **a different name**. After you finish editing the file, click **Install**.
+
+6. Wait until MySQL Exporter is up and running.
+
+## Step 3: Create a Monitoring Dashboard
+
+You can create a monitoring dashboard for MySQL and visualize real-time metrics.
+
+1. In the same project, go to **Custom Monitoring** under **Monitoring & Alerting** in the sidebar and click **Create**.
+
+2. In the displayed dialog box, set a name for the dashboard (for example, `mysql-overview`) and select the MySQL template. Click **Next** to continue.
+
+3. Save the template by clicking **Save Template** in the upper-right corner. A newly-created dashboard is displayed on the **Custom Monitoring Dashboards** page.
+
+ {{< notice note >}}
+
+- The built-in MySQL template is provided by KubeSphere to help you monitor MySQL metrics. You can also add more metrics on the dashboard as needed.
+
+- For more information about dashboard properties, see [Visualization](../../../../project-user-guide/custom-application-monitoring/visualization/overview/).
+ {{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md
new file mode 100644
index 000000000..1e74c3dde
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md
@@ -0,0 +1,72 @@
+---
+title: "Monitor a Sample Web Application"
+keywords: 'monitoring, prometheus, prometheus operator'
+description: 'Use a Helm chart to deploy a sample web app and create a dashboard to monitor the app.'
+linkTitle: "Monitor a Sample Web Application"
+weight: 10813
+---
+
+This section walks you through monitoring a sample web application. The application is instrumented with Prometheus Go client in its code. Therefore, it can expose metrics directly without the help of exporters.
+
+## Prerequisites
+
+- Please make sure you [enable the OpenPitrix system](../../../../pluggable-components/app-store/).
+- You need to create a workspace, a project, and a user account for this tutorial. For more information, see [Create Workspaces, Projects, Users and Roles](../../../../quick-start/create-workspace-and-project/). The account needs to be a platform regular user and to be invited to the workspace with the `self-provisioner` role. Namely, create a user `workspace-self-provisioner` of the `self-provisioner` role, and use this account to create a project (for example, `test`). In this tutorial, you log in as `workspace-self-provisioner` and work in the project `test` in the workspace `demo-workspace`.
+
+- Knowledge of Helm charts and [PromQL](https://prometheus.io/docs/prometheus/latest/querying/examples/).
+
+## Hands-on Lab
+
+### Step 1: Prepare the image of a sample web application
+
+The sample web application exposes a user-defined metric called `myapp_processed_ops_total`. It is a counter type metric that counts the number of operations that have been processed. The counter increases automatically by one every 2 seconds.
+
+This sample application exposes application-specific metrics via the endpoint `http://localhost:2112/metrics`.
+
+In this tutorial, you use the made-ready image `kubespheredev/promethues-example-app`. The source code can be found in [kubesphere/prometheus-example-app](https://github.com/kubesphere/prometheus-example-app). You can also follow [Instrument A Go Application For Prometheus](https://prometheus.io/docs/guides/go-application/) in the official documentation of Prometheus.
+
+### Step 2: Pack the application into a Helm chart
+
+Pack the Deployment, Service, and ServiceMonitor YAML template into a Helm chart for reuse. In the Deployment and Service template, you define the sample web container and the port for the metrics endpoint. A ServiceMonitor is a custom resource defined and used by Prometheus Operator. It connects your application and KubeSphere monitoring engine (Prometheus) so that the engine knows where and how to scrape metrics. In future releases, KubeSphere will provide a graphical user interface for easy operation.
+
+Find the source code in the folder `helm` in [kubesphere/prometheus-example-app](https://github.com/kubesphere/prometheus-example-app). The Helm chart package is made ready and is named `prometheus-example-app-0.1.0.tgz`. Please download the .tgz file and you will use it in the next step.
+
+### Step 3: Upload the Helm chart
+
+1. Go to the workspace **Overview** page of `demo-workspace` and navigate to **App Templates** under **App Management**.
+
+2. Click **Create** and upload `prometheus-example-app-0.1.0.tgz`.
+
+### Step 4: Deploy the sample web application
+
+You need to deploy the sample web application into `test`. For demonstration purposes, you can simply run a test deployment.
+
+1. Click `prometheus-example-app`.
+
+2. Expand the menu and click **Install**.
+
+3. Make sure you deploy the sample web application in `test` and click **Next**.
+
+4. Make sure `serviceMonitor.enabled` is set to `true` and click **Install**.
+
+5. In **Workloads** of the project `test`, wait until the sample web application is up and running.
+
+### Step 5: Create a monitoring dashboard
+
+This section guides you on how to create a dashboard from scratch. You will create a text chart showing the total number of processed operations and a line chart for displaying the operation rate.
+
+1. Navigate to **Custom Monitoring Dashboards** and click **Create**.
+
+2. Set a name (for example, `sample-web`) and click **Next**.
+
+3. Enter a title in the upper-left corner (for example, `Sample Web Overview`).
+
+4. Click 
on the left column to create a text chart.
+
+5. Type the PromQL expression `myapp_processed_ops_total` in the field **Monitoring Metric** and give a chart name (for example, `Operation Count`). Click **√** in the lower-right corner to continue.
+
+6. Click **Add Monitoring Item**, select **Line Chart**, and click **OK**.
+
+7. Enter the PromQL expression `irate(myapp_processed_ops_total[3m])` for **Monitoring Metric** and name the chart `Operation Rate`. To improve the appearance, you can set **Metric Name** to `{{service}}`. It will name each line with the value of the metric label `service`. Next, set **Decimal Places** to `2` so that the result will be truncated to two decimal places. Click **√** in the lower-right corner to continue.
+
+8. Click **Save Template** to save it.
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/introduction.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/introduction.md
new file mode 100644
index 000000000..04581f603
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/introduction.md
@@ -0,0 +1,53 @@
+---
+title: "Introduction to Custom Application Monitoring"
+keywords: 'monitoring, prometheus, prometheus operator'
+description: 'Introduce the KubeSphere custom monitoring feature and metric exposing, including exposing methods and ServiceMonitor CRD.'
+linkTitle: "Introduction"
+weight: 10810
+---
+
+Custom monitoring allows you to monitor and visualize custom application metrics in KubeSphere. The application can be either a third-party application, such as MySQL, Redis, and Elasticsearch, or your own application. This section introduces the workflow of this feature.
+
+The KubeSphere monitoring engine is powered by Prometheus and Prometheus Operator. To integrate custom application metrics into KubeSphere, you need to go through the following steps in general.
+
+- [Expose Prometheus-formatted metrics](#step-1-expose-prometheus-formatted-metrics) of your application.
+- [Apply ServiceMonitor CRD](#step-2-apply-servicemonitor-crd) to hook up your application with the monitoring target.
+- [Visualize metrics](#step-3-visualize-metrics) on the dashboard to view the trend of custom metrics.
+
+### Step 1: Expose Prometheus-formatted metrics
+
+First of all, your application must expose Prometheus-formatted metrics. The Prometheus exposition format is the de-facto format in the realm of cloud-native monitoring. Prometheus uses a [text-based exposition format](https://prometheus.io/docs/instrumenting/exposition_formats/). Depending on your application and use case, there are two ways to expose metrics:
+
+#### Direct exposing
+
+Directly exposing Prometheus metrics from applications is a common way among cloud-native applications. It requires developers to import Prometheus client libraries in their codes and expose metrics at a specific endpoint. Many applications, such as etcd, CoreDNS, and Istio, adopt this method.
+
+The Prometheus community offers client libraries for most programming languages. Find your language on the [Prometheus Client Libraries](https://prometheus.io/docs/instrumenting/clientlibs/) page. For Go developers, read [Instrumenting a Go application](https://prometheus.io/docs/guides/go-application/) to learn how to write a Prometheus-compliant application.
+
+The [sample web application](../examples/monitor-sample-web/) is an example demonstrating how an application exposes Prometheus-formatted metrics directly.
+
+#### Indirect exposing
+
+If you don’t want to modify your code or you cannot do so because the application is provided by a third party, you can deploy an exporter which serves as an agent to scrape metric data and translate them into Prometheus format.
+
+For most third-party applications, such as MySQL, the Prometheus community provides production-ready exporters. Refer to [Exporters and Integrations](https://prometheus.io/docs/instrumenting/exporters/) for available exporters. In KubeSphere, it is recommended to [enable OpenPitrix](../../../pluggable-components/app-store/) and deploy exporters from the App Store. Exporters for MySQL, Elasticsearch, and Redis are all built-in apps in the App Store.
+
+Please read [Monitor MySQL](../examples/monitor-mysql/) to learn how to deploy a MySQL exporter and monitor MySQL metrics.
+
+Writing an exporter is nothing short of instrumenting an application with Prometheus client libraries. The only difference is that exporters need to connect to applications and translate application metrics into Prometheus format.
+
+### Step 2: Apply ServiceMonitor CRD
+
+In the previous step, you expose metric endpoints in a Kubernetes Service object. Next, you need to inform the KubeSphere monitoring engine of your new changes.
+
+The ServiceMonitor CRD is defined by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator). A ServiceMonitor contains information about the metrics endpoints. With ServiceMonitor objects, the KubeSphere monitoring engine knows where and how to scape metrics. For each monitoring target, you apply a ServiceMonitor object to hook your application (or exporters) up to KubeSphere.
+
+In KubeSphere 3.3, you need to pack a ServiceMonitor with your applications (or exporters) into a Helm chart for reuse. In future releases, KubeSphere will provide graphical interfaces for easy operation.
+
+Please read [Monitor a Sample Web Application](../examples/monitor-sample-web/) to learn how to pack a ServiceMonitor with your application.
+
+### Step 3: Visualize Metrics
+
+Around two minutes, the KubeSphere monitoring engine starts to scape and store metrics. Then you can use PromQL to query metrics and design panels and dashboards.
+
+Please read [Querying](../visualization/querying/) to learn how to write a PromQL expression. For dashboard features, please read [Visualization](../visualization/overview/).
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/_index.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/_index.md
new file mode 100644
index 000000000..b5f6f3290
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Visualization"
+weight: 10814
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/overview.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/overview.md
new file mode 100644
index 000000000..51ad6ee56
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/overview.md
@@ -0,0 +1,71 @@
+---
+title: "Monitoring Dashboard — Overview"
+keywords: 'monitoring, prometheus, prometheus operator'
+description: 'Understand the general steps of creating a monitoring dashboard as well as its layout.'
+linkTitle: "Overview"
+weight: 10815
+---
+
+This section introduces monitoring dashboard features. You will learn how to visualize metric data in KubeSphere for your custom apps. If you do not know how to integrate your app metrics into the KubeSphere monitoring system, read [Introduction](../../introduction/) first.
+
+## Create a Monitoring Dashboard
+
+To create new dashboards for your app metrics, navigate to **Custom Monitoring** under **Monitoring & Alerting** in a project. There are three ways to create monitoring dashboards: built-in templates, blank templates for customization and YAML files.
+
+Built-in templates include MySQL, Elasticsearch, Redis, and more. These templates are for demonstration purposes and are updated with KubeSphere releases. Besides, you can choose to customize monitoring dashboards.
+
+A KubeSphere custom monitoring dashboard can be seen as simply a YAML configuration file. The data model is heavily inspired by [Grafana](https://github.com/grafana/grafana), an open-source tool for monitoring and observability. Please find KubeSphere monitoring dashboard data model design in [kubesphere/monitoring-dashboard](https://github.com/kubesphere/monitoring-dashboard). The configuration file is portable and sharable. You are welcome to contribute dashboard templates to the KubeSphere community via [Monitoring Dashboards Gallery](https://github.com/kubesphere/monitoring-dashboard/tree/master/contrib/gallery).
+
+### From a built-in template
+
+To help you quickly get started, KubeSphere provides built-in templates for MySQL, Elasticsearch, and Redis. If you want to create dashboards from built-in templates, select a template and then click **Next**.
+
+### From a blank template
+
+To start with a blank template, click **Next**.
+
+### From a YAML file
+
+Turn on **Edit YAML** in the upper-right corner and then paste your dashboard YAML file.
+
+## Dashboard Layout
+
+The monitoring dashboard is composed of four parts. Global settings are on the top of the page. The left-most column is for text-based charts showing the current value of metrics. The middle column contains chart collections for visualizing metrics over a specific period. The right-most column presents detailed information in charts.
+
+### Top bar
+
+On the top bar, you can configure the following settings: title, theme, time range, and refresh interval.
+
+### Text chart column
+
+You can add new text charts in the left-most column.
+
+### Chart display column
+
+You can view charts in the middle column.
+
+### Detail column
+
+You can view chart details in the right-most column. It shows the **max**, **min**, **avg**, and **last** value of metrics within the specific period.
+
+## Edit the monitoring dashboard
+
+You can modify an existing template by clicking **Edit Template** in the upper-right corner.
+
+### Add a chart
+
+To add text charts, click ➕ in the left column. To add charts in the middle column, click **Add Monitoring Item** in the lower-right corner.
+
+### Add a monitoring group
+
+To group monitoring items, you can click 
to drag and drop an item into the target group. To add a new group, click **Add Monitoring Group**. If you want to change the place of a group, hover over a group and click 
or 
arrow on the right.
+
+{{< notice note >}}
+
+The place of group on the right is consistent with the place of charts in the middle. In other words, if you change the order of groups, the place of their respective charts will also change accordingly.
+
+{{}}
+
+## Dashboard Templates
+
+Find and share dashboard templates in [Monitoring Dashboards Gallery](https://github.com/kubesphere/monitoring-dashboard/tree/master/contrib/gallery). It is a place for KubeSphere community users to contribute their masterpieces.
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/panel.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/panel.md
new file mode 100644
index 000000000..1dd9703d8
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/panel.md
@@ -0,0 +1,34 @@
+---
+title: "Charts"
+keywords: 'monitoring, Prometheus, Prometheus Operator'
+description: 'Explore dashboard properties and chart metrics.'
+linkTitle: "Charts"
+weight: 10816
+---
+
+KubeSphere currently supports two kinds of charts: text charts and graphs.
+
+## Text Chart
+
+A text chart is preferable for displaying a single metric value. The editing window for the text chart is composed of two parts. The upper part displays the real-time metric value, and the lower part is for editing. You can enter a PromQL expression to fetch a single metric value.
+
+- **Chart Name**: The name of the text chart.
+- **Unit**: The metric data unit.
+- **Decimal Places**: Accept an integer.
+- **Monitoring Metric**: Specify a monitoring metric from the drop-down list of available Prometheus metrics.
+
+## Graph Chart
+
+A graph chart is preferable for displaying multiple metric values. The editing window for the graph is composed of three parts. The upper part displays real-time metric values. The left part is for setting the graph theme. The right part is for editing metrics and chart descriptions.
+
+- **Chart Types**: Support basic charts and bar charts.
+- **Graph Types**: Support basic charts and stacked charts.
+- **Chart Colors**: Change line colors.
+- **Chart Name**: The name of the chart.
+- **Description**: The chart description.
+- **Add**: Add a new query editor.
+- **Metric Name**: Legend for the line. It supports variables. For example, `{{pod}}` means using the value of the Prometheus metric label `pod` to name this line.
+- **Interval**: The step value between two data points.
+- **Monitoring Metric**: A list of available Prometheus metrics.
+- **Unit**: The metric data unit.
+- **Decimal Places**: Accept an integer.
diff --git a/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/querying.md b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/querying.md
new file mode 100644
index 000000000..c9f6f40d4
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/custom-application-monitoring/visualization/querying.md
@@ -0,0 +1,13 @@
+---
+title: "Querying"
+keywords: 'monitoring, Prometheus, Prometheus Operator, querying'
+description: 'Learn how to specify monitoring metrics.'
+linkTitle: "Querying"
+weight: 10817
+---
+
+In the query editor, enter PromQL expressions in **Monitoring Metrics** to process and fetch metrics. To learn how to write PromQL, read [Query Examples](https://prometheus.io/docs/prometheus/latest/querying/examples/).
+
+
+
+
\ No newline at end of file
diff --git a/content/en/docs/v3.4/project-user-guide/grayscale-release/_index.md b/content/en/docs/v3.4/project-user-guide/grayscale-release/_index.md
new file mode 100644
index 000000000..f86106d9d
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/grayscale-release/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Grayscale Release"
+weight: 10500
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/grayscale-release/blue-green-deployment.md b/content/en/docs/v3.4/project-user-guide/grayscale-release/blue-green-deployment.md
new file mode 100644
index 000000000..4f5abe9a4
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/grayscale-release/blue-green-deployment.md
@@ -0,0 +1,74 @@
+---
+title: "Kubernetes Blue-Green Deployment on Kubesphere"
+keywords: 'KubeSphere, Kubernetes, Service Mesh, Istio, Grayscale Release, Blue-Green deployment'
+description: 'Learn how to release a blue-green deployment on KubeSphere.'
+linkTitle: "Blue-Green Deployment with Kubernetes"
+weight: 10520
+---
+
+
+The blue-green release provides a zero downtime deployment, which means the new version can be deployed with the old one preserved. At any time, only one of the versions is active serving all the traffic, while the other one remains idle. If there is a problem with running, you can quickly roll back to the old version.
+
+
+
+
+## Prerequisites
+
+- You need to enable [KubeSphere Service Mesh](../../../pluggable-components/service-mesh/).
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You need to enable **Application Governance** and have an available app so that you can implement the blue-green deployment for it. The sample app used in this tutorial is Bookinfo. For more information, see [Deploy Bookinfo and Manage Traffic](../../../quick-start/deploy-bookinfo-to-k8s/).
+
+## Create a Blue-green Deployment Job
+
+1. Log in to KubeSphere as `project-regular` and go to **Grayscale Release**. Under **Release Modes**, click **Create** on the right of **Blue-Green Deployment**.
+
+2. Set a name for it and click **Next**.
+
+3. On the **Service Settings** tab, select your app from the drop-down list and the Service for which you want to implement the blue-green deployment. If you also use the sample app Bookinfo, select **reviews** and click **Next**.
+
+4. On the **New Version Settings** tab, add another version (e.g `kubesphere/examples-bookinfo-reviews-v2:1.16.2`) as shown in the following figure and click **Next**.
+
+5. On the **Strategy Settings** tab, to allow the app version `v2` to take over all the traffic, select **Take Over** and click **Create**.
+
+6. The blue-green deployment job created is displayed under the **Release Jobs** tab. Click it to view details.
+
+7. Wait for a while and you can see all the traffic go to the version `v2`.
+
+8. The new **Deployment** is created as well.
+
+9. You can get the virtual service to identify the weight by running the following command:
+
+ ```bash
+ kubectl -n demo-project get virtualservice -o yaml
+ ```
+
+ {{< notice note >}}
+
+ - When you run the command above, replace `demo-project` with your own project (namely, namespace) name.
+ - If you want to run the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
+
+ {{}}
+
+10. Expected output:
+
+ ```yaml
+ ...
+ spec:
+ hosts:
+ - reviews
+ http:
+ - route:
+ - destination:
+ host: reviews
+ port:
+ number: 9080
+ subset: v2
+ weight: 100
+ ...
+ ```
+
+## Take a Job Offline
+
+After you implement the blue-green deployment, and the result meets your expectation, you can take the task offline with the version `v1` removed by clicking **Delete**.
+
+
diff --git a/content/en/docs/v3.4/project-user-guide/grayscale-release/canary-release.md b/content/en/docs/v3.4/project-user-guide/grayscale-release/canary-release.md
new file mode 100644
index 000000000..0aaa85250
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/grayscale-release/canary-release.md
@@ -0,0 +1,120 @@
+---
+title: "Canary Release"
+keywords: 'KubeSphere, Kubernetes, Canary Release, Istio, Service Mesh'
+description: 'Learn how to deploy a canary service on KubeSphere.'
+linkTitle: "Canary Release"
+weight: 10530
+---
+
+On the back of [Istio](https://istio.io/), KubeSphere provides users with necessary control to deploy canary services. In a canary release, you introduce a new version of a service and test it by sending a small percentage of traffic to it. At the same time, the old version is responsible for handling the rest of the traffic. If everything goes well, you can gradually increase the traffic sent to the new version, while simultaneously phasing out the old version. In the case of any occurring issues, KubeSphere allows you to roll back to the previous version as you change the traffic percentage.
+
+This method serves as an efficient way to test performance and reliability of a service. It can help detect potential problems in the actual environment while not affecting the overall system stability.
+
+
+
+## Prerequisites
+
+- You need to enable [KubeSphere Service Mesh](../../../pluggable-components/service-mesh/).
+- You need to enable [KubeSphere Logging](../../../pluggable-components/logging/) so that you can use the Tracing feature.
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You need to enable **Application Governance** and have an available app so that you can implement the canary release for it. The sample app used in this tutorial is Bookinfo. For more information, see [Deploy and Access Bookinfo](../../../quick-start/deploy-bookinfo-to-k8s/).
+
+## Step 1: Create a Canary Release Job
+
+1. Log in to KubeSphere as `project-regular` and navigate to **Grayscale Release**. Under **Release Modes**, click **Create** on the right of **Canary Release**.
+
+2. Set a name for it and click **Next**.
+
+3. On the **Service Settings** tab, select your app from the drop-down list and the Service for which you want to implement the canary release. If you also use the sample app Bookinfo, select **reviews** and click **Next**.
+
+4. On the **New Version Settings** tab, add another version of it (e.g `kubesphere/examples-bookinfo-reviews-v2:1.16.2`; change `v1` to `v2`) and click **Next**.
+
+5. You send traffic to these two versions (`v1` and `v2`) either by a specific percentage or by the request content such as `Http Header`, `Cookie` and `URI`. Select **Specify Traffic Distribution** and move the slider to the middle to change the percentage of traffic sent to these two versions respectively (for example, set 50% for either one). When you finish, click **Create**.
+
+## Step 2: Verify the Canary Release
+
+Now that you have two available app versions, access the app to verify the canary release.
+
+1. Visit the Bookinfo website and refresh your browser repeatedly. You can see that the **Book Reviews** section switching between v1 and v2 at a rate of 50%.
+
+2. The created canary release job is displayed under the tab **Release Jobs**. Click it to view details.
+
+3. You can see half of the traffic goes to each of them.
+
+4. The new Deployment is created as well.
+
+5. You can directly get the virtual Service to identify the weight by executing the following command:
+
+ ```bash
+ kubectl -n demo-project get virtualservice -o yaml
+ ```
+
+ {{< notice note >}}
+
+ - When you execute the command above, replace `demo-project` with your own project (namely, namespace) name.
+ - If you want to execute the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
+
+ {{}}
+
+6. Expected output:
+
+ ```bash
+ ...
+ spec:
+ hosts:
+ - reviews
+ http:
+ - route:
+ - destination:
+ host: reviews
+ port:
+ number: 9080
+ subset: v1
+ weight: 50
+ - destination:
+ host: reviews
+ port:
+ number: 9080
+ subset: v2
+ weight: 50
+ ...
+ ```
+
+## Step 3: View Network Topology
+
+1. Execute the following command on the machine where KubeSphere runs to bring in real traffic to simulate the access to Bookinfo every 0.5 seconds.
+
+ ```bash
+ watch -n 0.5 "curl http://productpage.demo-project.192.168.0.2.nip.io:32277/productpage?u=normal"
+ ```
+
+ {{< notice note >}}
+ Make sure you replace the hostname and port number in the above command with your own.
+ {{}}
+
+2. In **Traffic Monitoring**, you can see communications, dependency, health and performance among different microservices.
+
+3. Click a component (for example, **reviews**) and you can see the information of traffic monitoring on the right, displaying real-time data of **Traffic**, **Success rate**, and **Duration**.
+
+## Step 4: View Tracing Details
+
+KubeSphere provides the distributed tracing feature based on [Jaeger](https://www.jaegertracing.io/), which is used to monitor and troubleshoot microservices-based distributed applications.
+
+1. On the **Tracing** tab, you can see all phases and internal calls of requests, as well as the period in each phase.
+
+2. Click any item, and you can even drill down to see request details and where this request is being processed (which machine or container).
+
+## Step 5: Take Over All Traffic
+
+If everything runs smoothly, you can bring all the traffic to the new version.
+
+1. In **Release Jobs**, click the canary release job.
+
+2. In the displayed dialog box, click 
on the right of **reviews v2** and select **Take Over**. It means 100% of the traffic will be sent to the new version (v2).
+
+ {{< notice note >}}
+ If anything goes wrong with the new version, you can roll back to the previous version v1 anytime.
+ {{}}
+
+3. Access Bookinfo again and refresh the browser several times. You can find that it only shows the result of **reviews v2** (i.e. ratings with black stars).
+
diff --git a/content/en/docs/v3.4/project-user-guide/grayscale-release/overview.md b/content/en/docs/v3.4/project-user-guide/grayscale-release/overview.md
new file mode 100644
index 000000000..cf48a86f9
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/grayscale-release/overview.md
@@ -0,0 +1,39 @@
+---
+title: "Grayscale Release — Overview"
+keywords: 'Kubernetes, KubeSphere, grayscale release, overview, service mesh'
+description: 'Understand the basic concept of grayscale release.'
+linkTitle: "Overview"
+weight: 10510
+---
+
+Modern, cloud-native applications are often composed of a group of independently deployable components, also known as microservices. In a microservices architecture, developers are able to make adjustments to their apps with great flexibility as they do not affect the network of services each performing a specific function. This kind of network of microservices making up an application is also called **service mesh**.
+
+A KubeSphere service mesh, built on the open-source project of [Istio](https://istio.io/), controls how different parts of an app interact with one another. Among others, grayscale release strategies represent an important part for users to test and release new app versions without affecting the communication among microservices.
+
+## Grayscale Release Strategies
+
+A grayscale release in KubeSphere ensures smooth transition as you upgrade your apps to a new version. The specific strategy adopted may be different but the ultimate goal is the same - identify potential problems in advance without affecting your apps running in the production environment. This not only minimizes risks of a version upgrade but also tests the performance of new app builds.
+
+KubeSphere provides users with three grayscale release strategies.
+
+### [Blue-green Deployment](../blue-green-deployment/)
+
+A blue-green deployment provides an efficient method of releasing new versions with zero downtime and outages as it creates an identical standby environment where the new app version runs. With this approach, KubeSphere routes all the traffic to either version. Namely, only one environment is live at any given time. In the case of any issues with the new build, it allows you to immediately roll back to the previous version.
+
+### [Canary Release](../canary-release/)
+
+A canary deployment reduces the risk of version upgrades to a minimum as it slowly rolls out changes to a small subset of users. More specifically, you have the option to expose a new app version to a portion of production traffic, which is defined by yourself on the highly responsive dashboard. Besides, KubeSphere gives you a visualized view of real-time traffic as it monitors requests after you implement a canary deployment. During the process, you can analyze the behavior of the new app version and choose to gradually increase the percentage of traffic sent to it. Once you are confident of the build, you can route all the traffic to it.
+
+### [Traffic Mirroring](../traffic-mirroring/)
+
+Traffic mirroring copies live production traffic and sends it to a mirrored service. By default, KubeSphere mirrors all the traffic while you can also manually define the percentage of traffic to be mirrored by specifying a value. Common use cases include:
+
+- Test new app versions. You can compare the real-time output of mirrored traffic and production traffic.
+- Test clusters. You can use production traffic of instances for cluster testing.
+- Test databases. You can use an empty database to store and load data.
+
+{{< notice note >}}
+
+The current KubeSphere version does not support grayscale release strategies for multi-cluster apps.
+
+{{}}
diff --git a/content/en/docs/v3.4/project-user-guide/grayscale-release/traffic-mirroring.md b/content/en/docs/v3.4/project-user-guide/grayscale-release/traffic-mirroring.md
new file mode 100644
index 000000000..7d7568fd4
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/grayscale-release/traffic-mirroring.md
@@ -0,0 +1,81 @@
+---
+title: "Traffic Mirroring"
+keywords: 'KubeSphere, Kubernetes, Traffic Mirroring, Istio'
+description: 'Learn how to conduct a traffic mirroring job on KubeSphere.'
+linkTitle: "Traffic Mirroring"
+weight: 10540
+---
+
+Traffic mirroring, also called shadowing, is a powerful, risk-free method of testing your app versions as it sends a copy of live traffic to a service that is being mirrored. Namely, you implement a similar setup for acceptance test so that problems can be detected in advance. As mirrored traffic happens out of band of the critical request path for the primary service, your end users will not be affected during the whole process.
+
+## Prerequisites
+
+- You need to enable [KubeSphere Service Mesh](../../../pluggable-components/service-mesh/).
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You need to enable **Application Governance** and have an available app so that you can mirror the traffic of it. The sample app used in this tutorial is Bookinfo. For more information, see [Deploy Bookinfo and Manage Traffic](../../../quick-start/deploy-bookinfo-to-k8s/).
+
+## Create a Traffic Mirroring Job
+
+1. Log in to KubeSphere as `project-regular` and go to **Grayscale Release**. Under **Release Modes**, click **Create** on the right of **Traffic Mirroring**.
+
+2. Set a name for it and click **Next**.
+
+3. On the **Service Settings** tab, select your app from the drop-down list and the Service of which you want to mirror the traffic. If you also use the sample app Bookinfo, select **reviews** and click **Next**.
+
+4. On the **New Version Settings** tab, add another version of it (for example, `kubesphere/examples-bookinfo-reviews-v2:1.16.2`; change `v1` to `v2`) and click **Next**.
+
+5. On the **Strategy Settings** tab, click **Create**.
+
+6. The traffic mirroring job created is displayed under the **Release Jobs** tab. Click it to view details.
+
+7. You can see the traffic is being mirrored to `v2` with real-time traffic displayed in the line chart.
+
+8. The new **Deployment** is created as well.
+
+9. You can get the virtual service to view `mirror` and `weight` by running the following command:
+
+ ```bash
+ kubectl -n demo-project get virtualservice -o yaml
+ ```
+
+ {{< notice note >}}
+
+ - When you run the command above, replace `demo-project` with your own project (namely, namespace) name.
+ - If you want to run the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
+
+ {{}}
+
+10. Expected output:
+
+ ```bash
+ ...
+ spec:
+ hosts:
+ - reviews
+ http:
+ - route:
+ - destination:
+ host: reviews
+ port:
+ number: 9080
+ subset: v1
+ weight: 100
+ mirror:
+ host: reviews
+ port:
+ number: 9080
+ subset: v2
+ ...
+ ```
+
+ This route rule sends 100% of the traffic to `v1`. The `mirror` field specifies that you want to mirror to the service `reviews v2`. When traffic gets mirrored, the requests are sent to the mirrored service with their Host/Authority headers appended with `-shadow`. For example, `cluster-1` becomes `cluster-1-shadow`.
+
+ {{< notice note >}}
+
+These requests are mirrored as “fire and forget”, which means that the responses are discarded. You can specify the `weight` field to mirror a fraction of the traffic, instead of mirroring all requests. If this field is absent, for compatibility with older versions, all traffic will be mirrored. For more information, see [Mirroring](https://istio.io/v1.5/pt-br/docs/tasks/traffic-management/mirroring/).
+
+{{}}
+
+## Take a Job Offline
+
+You can remove the traffic mirroring job by clicking **Delete**, which does not affect the current app version.
diff --git a/content/en/docs/v3.4/project-user-guide/image-builder/_index.md b/content/en/docs/v3.4/project-user-guide/image-builder/_index.md
new file mode 100644
index 000000000..d10a9e339
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/image-builder/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Image Builder"
+weight: 10600
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/project-user-guide/image-builder/binary-to-image.md b/content/en/docs/v3.4/project-user-guide/image-builder/binary-to-image.md
new file mode 100644
index 000000000..63b377a2b
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/image-builder/binary-to-image.md
@@ -0,0 +1,141 @@
+---
+title: "Binary to Image: Publish an Artifact to Kubernetes"
+keywords: "KubeSphere, Kubernetes, Docker, B2I, Binary-to-Image"
+description: "Use B2I to import an artifact and push it to a target repository."
+linkTitle: "Binary to Image: Publish an Artifact to Kubernetes"
+weight: 10620
+---
+
+Binary-to-Image (B2I) is a toolkit and workflow for building reproducible container images from binary executables such as Jar, War, and binary packages. More specifically, you upload an artifact and specify a target repository such as Docker Hub or Harbor where you want to push the image. If everything runs successfully, your image will be pushed to the target repository and your application will be automatically deployed to Kubernetes if you create a Service in the workflow.
+
+In a B2I workflow, you do not need to write any Dockerfile. This not only reduces learning costs but improves release efficiency, which allows users to focus more on business.
+
+This tutorial demonstrates two different ways to build an image based on an artifact in a B2I workflow. Ultimately, the image will be released to Docker Hub.
+
+For demonstration and testing purposes, here are some example artifacts you can use to implement the B2I workflow:
+
+| Artifact Package | GitHub Repository |
+| ------------------------------------------------------------ | ------------------------------------------------------------ |
+| [b2i-war-java8.war](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-war-java8.war) | [spring-mvc-showcase](https://github.com/spring-projects/spring-mvc-showcase) |
+| [b2i-war-java11.war](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-war-java11.war) | [springmvc5](https://github.com/kubesphere/s2i-java-container/tree/master/tomcat/examples/springmvc5) |
+| [b2i-binary](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-binary) | [devops-go-sample](https://github.com/runzexia/devops-go-sample) |
+| [b2i-jar-java11.jar](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-jar-java11.jar) | [ java-maven-example](https://github.com/kubesphere/s2i-java-container/tree/master/java/examples/maven) |
+| [b2i-jar-java8.jar](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-jar-java8.jar) | [devops-maven-sample](https://github.com/kubesphere/devops-maven-sample) |
+
+## Prerequisites
+
+- You have enabled the [KubeSphere DevOps System](../../../pluggable-components/devops/).
+- You need to create a [Docker Hub](https://www.dockerhub.com/) account. GitLab and Harbor are also supported.
+- You need to create a workspace, a project and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- Set a CI dedicated node for building images. This is not mandatory but recommended for the development and production environment as it caches dependencies and reduces build time. For more information, see [Set a CI Node for Dependency Caching](../../../devops-user-guide/how-to-use/devops-settings/set-ci-node/).
+
+## Create a Service Using Binary-to-Image (B2I)
+
+The steps below show how to upload an artifact, build an image and release it to Kubernetes by creating a Service in a B2I workflow.
+
+
+
+### Step 1: Create a Docker Hub Secret
+
+You must create a Docker Hub Secret so that the Docker image created through B2I can be push to Docker Hub. Log in to KubeSphere as `project-regular`, go to your project and create a Secret for Docker Hub. For more information, see [Create the Most Common Secrets](../../../project-user-guide/configuration/secrets/#create-the-most-common-secrets).
+
+### Step 2: Create a Service
+
+1. In the same project, navigate to **Services** under **Application Workloads** and click **Create**.
+
+2. Scroll down to **Create Service from Artifact** and select **WAR**. This tutorial uses the [spring-mvc-showcase](https://github.com/spring-projects/spring-mvc-showcase) project as a sample and uploads a war artifact to KubeSphere. Set a name, such as `b2i-war-java8`, and click **Next**.
+
+3. On the **Build Settings** page, provide the following information accordingly and click **Next**.
+
+ **Service Type**: Select **Stateless Service** for this example. For more information about different Services, see [Service Type](../../../project-user-guide/application-workloads/services/#service-type).
+
+ **Artifact File**: Upload the war artifact ([b2i-war-java8](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-war-java8.war)).
+
+ **Build Environment**: Select **kubesphere/tomcat85-java8-centos7:v2.1.0**.
+
+ **Image Name**: Enter `
on the right of a record to see building logs. You can see `Build completed successfully` at the end of the log if everything runs normally.
+
+3. Go back to the **Services**, **Deployments**, and **Jobs** page, and you can see the corresponding Service, Deployment, and Job of the image have been all created successfully.
+
+4. In your Docker Hub repository, you can see that KubeSphere has pushed the image to the repository with the expected tag.
+
+### Step 4: Access the B2I Service
+
+1. On the **Services** page, click the B2I Service to go to its details page, where you can see the port number has been exposed.
+
+2. Access the Service at `http:// on the right of a record to see building logs. You can see `Build completed successfully` at the end of the log if everything runs normally.
+
+3. Go to the **Jobs** page, and you can see the corresponding Job of the image has been created successfully.
+
+4. In your Docker Hub repository, you can see that KubeSphere has pushed the image to the repository with the expected tag.
+
diff --git a/content/en/docs/v3.4/project-user-guide/image-builder/s2i-and-b2i-webhooks.md b/content/en/docs/v3.4/project-user-guide/image-builder/s2i-and-b2i-webhooks.md
new file mode 100644
index 000000000..3b89fba20
--- /dev/null
+++ b/content/en/docs/v3.4/project-user-guide/image-builder/s2i-and-b2i-webhooks.md
@@ -0,0 +1,81 @@
+---
+title: "Configure S2I and B2I Webhooks"
+keywords: 'KubeSphere, Kubernetes, S2I, Source-to-Image, B2I, Binary-to-Image, Webhook'
+description: 'Learn how to configure S2I and B2I webhooks.'
+linkTitle: "Configure S2I and B2I Webhooks"
+weight: 10650
+---
+
+KubeSphere provides Source-to-Image (S2I) and Binary-to-Image (B2I) features to automate image building and pushing and application deployment. In KubeSphere v3.1.x and later versions, you can configure S2I and B2I webhooks so that your Image Builder can be automatically triggered when there is any relevant activity in your code repository.
+
+This tutorial demonstrates how to configure S2I and B2I webhooks.
+
+## Prerequisites
+
+- You need to enable the [KubeSphere DevOps System](../../../pluggable-components/devops/).
+- You need to create a workspace, a project (`demo-project`) and a user (`project-regular`). The user must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+- You need to create an S2I Image Builder and a B2I Image Builder. For more information, refer to [Source to Image: Publish an App without a Dockerfile](../source-to-image/) and [Binary to Image: Publish an Artifact to Kubernetes](../binary-to-image/).
+
+## Configure an S2I Webhook
+
+### Step 1: Expose the S2I trigger Service
+
+1. Log in to the KubeSphere web console as `admin`. Click **Platform** in the upper-left corner and then select **Cluster Management**.
+
+2. In **Services** under **Application Workloads**, select **kubesphere-devops-system** from the drop-down list and click **s2ioperator-trigger-service** to go to its details page.
+
+3. Click **More** and select **Edit External Access**.
+
+4. In the displayed dialog box, select **NodePort** from the drop-down list for **Access Method** and then click **OK**.
+
+ {{< notice note >}}
+
+ This tutorial selects **NodePort** for demonstration purposes. You can also select **LoadBalancer** based on your needs.
+
+ {{}}
+
+5. You can view the **NodePort** on the details page. It is going to be included in the S2I webhook URL.
+
+### Step 2: Configure an S2I webhook
+
+1. Log out of KubeSphere and log back in as `project-regular`. Go to `demo-project`.
+
+2. In **Image Builders**, click the S2I Image Builder to go to its details page.
+
+3. You can see an auto-generated link shown in **Remote Trigger**. Copy `/s2itrigger/v1alpha1/general/namespaces/demo-project/s2ibuilders/felixnoo-s2i-sample-latest-zhd/` as it is going to be included in the S2I webhook URL.
+
+4. Log in to your GitHub account and go to the source code repository used for the S2I Image Builder. Go to **Webhooks** under **Settings** and then click **Add webhook**.
+
+5. In **Payload URL**, enter `http://
on the right of a record to see building logs. You can see `Build completed successfully` at the end of the log if everything runs normally.
+
+3. Go back to the **Services**, **Deployments**, and **Jobs** page, and you can see the corresponding Service, Deployment, and Job of the image have been all created successfully.
+
+4. In your Docker Hub repository, you can see that KubeSphere has pushed the image to the repository with the expected tag.
+
+### Step 5: Access the S2I Service
+
+1. On the **Services** page, click the S2I Service to go to its details page.
+
+2. To access the Service, you can either use the endpoint with the `curl` command or visit `| Parameter | +Description | +
|---|---|
| Name | +Name of the PV. It is specified by the field .metadata.name in the manifest file of the PV. | +
| Status | +
+ Current status of the PV. It is specified by the field .status.phase in the manifest file of the PV, including:
+
|
+
| Capacity | +Capacity of the PV. It is specified by the field .spec.capacity.storage in the manifest file of the PV. | +
| Access Mode | +
+ Access mode of the PV. It is specified by the field .spec.accessModes in the manifest file of the PV, including:
+
|
+
| Reclaim Policy | +
+ Reclaim policy of the PV. It is specified by the field .spec.persistentVolumeReclaimPolicy in the manifest file of the PV, including:
+
|
+
| Creation Time | +Time when the PV was created. | +
on the right of a PV, and you can perform the following:
+
+ - **Edit Information**: Edit information of the PV.
+ - **Edit YAML**: Edit the YAML file of the PV.
+ - **Delete**: Delete the PV. A PV in the **Bound** status cannot be deleted.
+
+### View the PV Details Page
+
+1. Click the name of a PV to go to its details page.
+
+2. On the details page, click **Edit Information** to edit the basic information of the PV.
+
+3. Click **More**, and you can perform the following:
+
+ - **View YAML**: View the YAML file of the PV.
+ - **Delete**: Delete the PV and return to the list page. A PV in the **Bound** status cannot be deleted.
+
+4. Click the **Resource Status** tab to view the PVC to which the PV is bound.
+
+5. Click the **Metadata** tab to view the labels and annotations of the PV.
+
+6. Click the **Events** tab to view the events of the PV.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/quick-start/_index.md b/content/en/docs/v3.4/quick-start/_index.md
new file mode 100644
index 000000000..5441c5300
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/_index.md
@@ -0,0 +1,16 @@
+---
+title: "Quickstarts"
+description: "Help you to better understand KubeSphere with detailed graphics and contents"
+layout: "second"
+
+linkTitle: "Quickstarts"
+
+weight: 2000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+Quickstarts include six hands-on lab exercises that help you quickly get started with KubeSphere. It is highly recommended that you go though all of these tutorials to explore the basic feature of KubeSphere.
+
+
diff --git a/content/en/docs/v3.4/quick-start/all-in-one-on-linux.md b/content/en/docs/v3.4/quick-start/all-in-one-on-linux.md
new file mode 100644
index 000000000..586d4ffad
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/all-in-one-on-linux.md
@@ -0,0 +1,259 @@
+---
+title: "All-in-One Installation of Kubernetes and KubeSphere on Linux"
+keywords: 'KubeSphere, Kubernetes, All-in-One, Installation'
+description: 'Install KubeSphere on Linux with a minimal installation package. The tutorial serves as a basic kick-starter for you to understand the container platform, paving the way for learning the following guides.'
+linkTitle: "All-in-One Installation on Linux"
+weight: 2100,
+showSubscribe: true
+---
+
+For those who are new to KubeSphere and looking for a quick way to discover the [container platform](https://kubesphere.io/), the all-in-one mode is your best choice to get started. It features rapid deployment and hassle-free configurations with KubeSphere and Kubernetes all provisioned on your machine.
+
+## Video Demonstration
+
+{{< youtube PtVQZVb3AgE >}}
+
+## Step 1: Prepare a Linux Machine
+
+To get started with all-in-one installation, you only need to prepare one host according to the following requirements for hardware and operating system.
+
+### Hardware recommendations
+
+| OS | +Minimum Requirements | +
|---|---|
| Ubuntu 16.04, 18.04, 20.04, 22.04 | +2 CPU cores, 4 GB memory, and 40 GB disk space | +
| Debian Buster, Stretch | +2 CPU cores, 4 GB memory, and 40 GB disk space | +
| CentOS 7.x | +2 CPU cores, 4 GB memory, and 40 GB disk space | +
| Red Hat Enterprise Linux 7 | +2 CPU cores, 4 GB memory, and 40 GB disk space | +
| SUSE Linux Enterprise Server 15/openSUSE Leap 15.2 | +2 CPU cores, 4 GB memory, and 40 GB disk space | +
| Supported Container Runtime | +Version | +
|---|---|
| Docker | +19.3.8 + | +
| containerd | +Latest | +
| CRI-O (experimental, not fully tested) | +Latest | +
| iSula (experimental, not fully tested) | +Latest | +
| Dependency | +Kubernetes Version ≥ 1.18 | +Kubernetes Version < 1.18 | +
|---|---|---|
socat |
+ Required | +Optional but recommended | +
conntrack |
+ Required | +Optional but recommended | +
ebtables |
+ Optional but recommended | +Optional but recommended | +
ipset |
+ Optional but recommended | +Optional but recommended | +
| Built-in Roles | +Description | +
|---|---|
platform-self-provisioner |
+ Create workspaces and become the admin of the created workspaces. | +
platform-regular |
+ Has no access to any resources before joining a workspace or cluster. | +
platform-admin |
+ Manage all resources on the platform. | +
| User | +Assigned Platform Role | +User Permissions | +
|---|---|---|
ws-admin |
+ platform-regular |
+ Manage all resources in a workspace after being invited to the workspace (This user is used to invite new members to a workspace in this example). | +
project-admin |
+ platform-regular |
+ Create and manage projects and DevOps projects, and invite new members to the projects. | +
project-regular |
+ platform-regular |
+ project-regular will be invited to a project or DevOps project by project-admin. This user will be used to create workloads, pipelines and other resources in a specified project. |
+
icon on the right of the username to enable or disable the user. Additionally, you can batch disable and enable users.
+
+ {{}}
+### Step 2: Create a workspace
+
+As the basic logic unit for the management of projects, DevOps projects and organization members, workspaces underpin the multi-tenant system of KubeSphere.
+
+1. In the navigation pane on the left, click **Workspaces**. You can see there is only one default workspace `system-workspace`, where system-related components and services run. Deleting this workspace is not allowed.
+
+2. On the **Workspaces** page on the right, click **Create**, set a name for the new workspace (for example, `demo-workspace`) and set user `ws-admin` as the workspace manager.
+
+3. Click **Create** after you finish.
+
+ {{< notice note >}}
+
+ If you have enabled the [multi-cluster feature](../../multicluster-management/), you need to [assign an available cluster](../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/#select-available-clusters-when-you-create-a-workspace) (or multiple clusters) to the workspace so that projects can be created on the cluster(s) later.
+
+ {{}}
+
+4. Log out of the console and log back in as `ws-admin`. In **Workspace Settings**, select **Workspace Members** and click **Invite**.
+
+5. Invite both `project-admin` and `project-regular` to the workspace. Assign them the role `workspace-self-provisioner` and `workspace-viewer` respectively and click **OK**.
+
+ {{< notice note >}}
+The actual role name follows a naming convention: `| User | +Assigned Workspace Role | +Role Permissions | +
|---|---|---|
ws-admin |
+ demo-workspace-admin |
+ Manage all resources under the workspace (use this user to invite new members to the workspace). | +
project-admin |
+ demo-workspace-self-provisioner |
+ Create and manage projects and DevOps projects, and invite new members to join the projects. | +
project-regular |
+ demo-workspace-viewer |
+ project-regular will be invited by project-admin to join a project or DevOps project. The user can be used to create workloads, pipelines, etc. |
+
to edit the role, edit the role permissions, or delete the role.
+
+6. On the **Users** page, you can assign the role to a user when you create a user or edit an existing user.
+
+
+### Step 5: Create a DevOps project (Optional)
+
+{{< notice note >}}
+
+To create a DevOps project, you must install the KubeSphere DevOps system in advance, which is a pluggable component providing CI/CD pipelines, Binary-to-image, Source-to-image, and more. For more information about how to enable DevOps, see [KubeSphere DevOps System](../../pluggable-components/devops/).
+
+{{}}
+
+1. Log in to the console as `project-admin`. In **DevOps Projects**, click **Create**.
+
+2. Enter the DevOps project name (for example, `demo-devops`) and click **OK**. You can also add an alias and description for the project.
+
+3. In **DevOps Projects**, click the project created just now to view its detailed information.
+
+4. Go to **Project Management** and select **Project Members**. Click **Invite** to invite user `project-regular` and grant the role `operator`, who is allowed to create pipelines and credentials.
+
+You are now familiar with the multi-tenant management system of KubeSphere. In other tutorials, user `project-regular` will also be used to demonstrate how to create applications and resources in a project or DevOps project.
diff --git a/content/en/docs/v3.4/quick-start/deploy-bookinfo-to-k8s.md b/content/en/docs/v3.4/quick-start/deploy-bookinfo-to-k8s.md
new file mode 100644
index 000000000..2d058ba5a
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/deploy-bookinfo-to-k8s.md
@@ -0,0 +1,94 @@
+---
+title: "Deploy and Access Bookinfo"
+keywords: 'KubeSphere, Kubernetes, Bookinfo, Istio'
+description: 'Explore the basics of KubeSphere service mesh by deploying an example application Bookinfo.'
+linkTitle: "Deploy and Access Bookinfo"
+weight: 2400
+---
+
+[Istio](https://istio.io/), as an open-source service mesh solution, provides powerful features of traffic management for microservices. The introduction of traffic management from the official website of [Istio](https://istio.io/latest/docs/concepts/traffic-management/) is as follows:
+
+*Istio’s traffic routing rules let you easily control the flow of traffic and API calls between services. Istio simplifies configuration of service-level properties like circuit breakers, timeouts, and retries, and makes it easy to set up important tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits. It also provides out-of-box failure recovery features that help make your application more robust against failures of dependent services or the network.*
+
+To provide consistent user experiences of managing microservices, KubeSphere integrates Istio on the container platform. This tutorial demonstrates how to deploy a sample application Bookinfo composed of four separate microservices and access it through a NodePort.
+
+## Prerequisites
+
+- You need to enable [KubeSphere Service Mesh](../../pluggable-components/service-mesh/).
+
+- You need to finish all tasks in [Create Workspaces, Projects, Users and Roles](../create-workspace-and-project/).
+
+- You need to enable **Application Governance**. For more information, see [Set a Gateway](../../project-administration/project-gateway/#set-a-gateway).
+
+ {{< notice note >}}
+
+ You need to enable **Application Governance** so that you can use the Tracing feature. Once it is enabled, check whether an annotation (for example, `nginx.ingress.kubernetes.io/service-upstream: true`) is added for your Route (Ingress) if the Route is inaccessible.
+ {{}}
+
+## What is Bookinfo
+
+Bookinfo is composed of the following four separate microservices. There are three versions of the **reviews** microservice.
+
+- The **productpage** microservice calls the **details** and **reviews** microservices to populate the page.
+- The **details** microservice contains book information.
+- The **reviews** microservice contains book reviews. It also calls the **ratings** microservice.
+- The **ratings** microservice contains book ranking information that accompanies a book review.
+
+The following figure shows the end-to-end architecture of the application. For more information, see [Bookinfo Application](https://istio.io/latest/docs/examples/bookinfo/).
+
+
+
+## Hands-on Lab
+
+### Step 1: Deploy Bookinfo
+
+1. Log in to the console as `project-regular` and go to your project (`demo-project`). Go to **Apps** under **Application Workloads**, and then click **Deploy Sample App** on the right of the page.
+
+2. Click **Next** in the displayed dialog box where required fields are pre-populated and relevant components are already set. You do not need to change the settings and just click **Create** on the final page.
+
+ {{< notice note >}}
+
+KubeSphere creates the hostname automatically. To change the hostname, hover over the default route rule and click 
to edit it. For more information, see [Create a Microservices-based App](../../project-user-guide/application/compose-app/).
+
+{{}}
+
+1. In **Workloads**, verify that the status of all four Deployments is `Running`, indicating that the app has been created successfully.
+
+ {{< notice note >}}It may take a few minutes before the Deployments are up and running.
+{{}}
+
+### Step 2: Access Bookinfo
+
+1. In **Apps**, go to **Composed Apps** and click the app `bookinfo` to see its details page.
+
+ {{< notice note >}}If you do not see the app in the list, refresh your page.
+ {{}}
+
+2. On the details page, record the hostname and port number of the app, which will be used to access Bookinfo.
+
+3. As the app will be accessed outside the cluster through a NodePort, you need to open the port in your security group for outbound traffic and set port forwarding rules if necessary.
+
+4. Edit your local host file (`/etc/hosts`) by adding an entry in it to map the hostname to the IP address. For example:
+
+ ```bash
+ 139.198.179.20 productpage.demo-project.192.168.0.2.nip.io
+ ```
+
+ {{< notice note >}}
+
+Do not copy the preceding content to your local host file. Replace it with your own IP address and hostname.
+ {{}}
+
+5. When you finish, click **Access Service** to access the app.
+
+6. On the app details page, click **Normal user** in the lower-left corner.
+
+7. In the following figure, you can notice that only **Reviewer1** and **Reviewer2** are displayed without any stars in the **Book Reviews** section. This is the status of this app version. To explore more features of traffic management, you can implement a [canary release](../../project-user-guide/grayscale-release/canary-release/) for this app.
+
+ 
+
+ {{< notice note >}}
+
+KubeSphere provides three kinds of grayscale strategies based on Istio, including [blue-green deployment](../../project-user-guide/grayscale-release/blue-green-deployment/), [canary release](../../project-user-guide/grayscale-release/canary-release/) and [traffic mirroring](../../project-user-guide/grayscale-release/traffic-mirroring/).
+ {{}}
+
diff --git a/content/en/docs/v3.4/quick-start/enable-pluggable-components.md b/content/en/docs/v3.4/quick-start/enable-pluggable-components.md
new file mode 100644
index 000000000..84a3e0369
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/enable-pluggable-components.md
@@ -0,0 +1,146 @@
+---
+title: "Enable Pluggable Components"
+keywords: 'KubeSphere, Kubernetes, pluggable, components'
+description: 'Install pluggable components of KubeSphere so that you can explore the container platform in an all-around way. Pluggable components can be enabled both before and after the installation.'
+linkTitle: "Enable Pluggable Components"
+weight: 2600
+---
+
+This tutorial demonstrates how to enable pluggable components of KubeSphere both before and after the installation. Refer to the table below for all pluggable components of KubeSphere.
+
+| Configuration | Component | Description |
+| ---------------- | ------------------------------------- | ------------------------------------------------------------ |
+| `alerting` | KubeSphere Alerting System | You can customize alerting policies for workloads and nodes. After an alerting policy is triggered, alert messages can be sent to your recipients through different channels (for example, email and Slack). |
+| `auditing` | KubeSphere Auditing Log System | Provide a security-relevant chronological set of records, recording the sequence of activities that happen in the platform, initiated by different tenants. |
+| `devops` | KubeSphere DevOps System | Provide an out-of-box CI/CD system based on Jenkins, and automated workflow tools including Source-to-Image and Binary-to-Image. |
+| `events` | KubeSphere Events System | Provide a graphical web console for the exporting, filtering and alerting of Kubernetes events in multi-tenant Kubernetes clusters. |
+| `logging` | KubeSphere Logging System | Provide flexible logging functions for log query, collection and management in a unified console. Additional log collectors can be added, such as Elasticsearch, Kafka and Fluentd. |
+| `metrics_server` | HPA | The Horizontal Pod Autoscaler automatically scales the number of Pods based on needs. |
+| `networkpolicy` | Network policy | Allow network isolation within the same cluster, which means firewalls can be set up between certain instances (Pods). |
+| `kubeedge` | KubeEdge | Add edge nodes to your cluster and run workloads on them. |
+| `openpitrix` | KubeSphere App Store | Provide an app store for Helm-based applications and allow users to manage apps throughout the entire lifecycle. |
+| `servicemesh` | KubeSphere Service Mesh (Istio-based) | Provide fine-grained traffic management, observability and tracing, and visualized traffic topology. |
+| `ippool` | Pod IP Pool | Create Pod IP pools and assign IP addresses from the Pools to your Pods. |
+| `topology` | Service Topology | Integrate [Weave Scope](https://www.weave.works/oss/scope/) to view service-to-service communication (topology) of your apps and containers. |
+
+For more information about each component, see [Overview of Enable Pluggable Components](../../pluggable-components/overview/).
+
+{{< notice note >}}
+
+- `multicluster` is not covered in this tutorial. If you want to enable this feature, you need to set a corresponding value for `clusterRole`. For more information, see [Multi-cluster Management](../../multicluster-management/).
+- Make sure your machine meets the hardware requirements before the installation. Here is the recommendation if you want to enable all pluggable components: CPU ≥ 8 Cores, Memory ≥ 16 G, Disk Space ≥ 100 G.
+
+{{}}
+
+## Enable Pluggable Components Before Installation
+
+For most of the pluggable components, you can follow the steps below to enable them. If you need to enable [KubeEdge](../../pluggable-components/kubeedge/), [Pod IP Pools](../../pluggable-components/pod-ip-pools/) and [Service Topology](../../pluggable-components/service-topology/), refer to the corresponding tutorials directly.
+
+### Installing on Linux
+
+When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
+
+1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
+
+ ```bash
+ vi config-sample.yaml
+ ```
+
+ {{< notice note >}}
+If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a `config-sample.yaml` file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable pluggable components in this mode (for example, for testing purpose), refer to the [following section](#enable-pluggable-components-after-installation) to see how pluggable components can be installed after installation.
+ {{}}
+
+2. In this file, enable the pluggable components you want to install by changing `false` to `true` for `enabled`. Here is [the complete file](https://github.com/kubesphere/kubekey/blob/release-2.2/docs/config-example.md) for your reference. Save the file after you finish.
+
+3. Create a cluster using the configuration file:
+
+ ```bash
+ ./kk create cluster -f config-sample.yaml
+ ```
+
+### Installing on Kubernetes
+
+When you install KubeSphere on Kubernetes, you need to use [ks-installer](https://github.com/kubesphere/ks-installer/) by applying two YAML files as below.
+
+1. First download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml) and edit it.
+
+ ```bash
+ vi cluster-configuration.yaml
+ ```
+
+2. To enable the pluggable component you want to install, change `false` to `true` for `enabled` under the component in this file.
+
+3. Save this local file and execute the following commands to start the installation.
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f cluster-configuration.yaml
+ ```
+
+Whether you install KubeSphere on Linux or on Kubernetes, you can check the status of the components you have enabled in the web console of KubeSphere after installation. Go to **System Components**, and you can see the component status.
+
+## Enable Pluggable Components After Installation
+
+The KubeSphere web console provides a convenient way for users to view and operate on different resources. To enable pluggable components after installation, you only need to make few adjustments on the console directly. For those who are accustomed to the Kubernetes command-line tool, kubectl, they will have no difficulty in using KubeSphere as the tool is integrated into the console.
+
+{{< notice note >}}
+
+If you need to enable [KubeEdge](../../pluggable-components/kubeedge/), [Pod IP Pools](../../pluggable-components/pod-ip-pools/) and [Service Topology](../../pluggable-components/service-topology/), refer to the corresponding tutorials directly.
+
+{{}}
+
+1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+
+2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
+
+ {{< notice info >}}
+A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
+ {{}}
+
+3. In **Custom Resources**, click the three dots on the right of `ks-installer` and select **Edit YAML**.
+
+4. In this YAML file, enable the pluggable components you want to install by changing `false` to `true` for `enabled`. After you finish, click **OK** to save the configuration.
+
+5. You can use the web kubectl to check the installation process by executing the following command:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+ {{< notice tip >}}
+
+You can find the web kubectl tool by clicking the hammer icon in the bottom-right corner of the console.
+
+{{}}
+
+6. The output will display a message as below if the component is successfully installed.
+
+ ```yaml
+ #####################################################
+ ### Welcome to KubeSphere! ###
+ #####################################################
+
+ Console: http://192.168.0.2:30880
+ Account: admin
+ Password: P@88w0rd
+
+ NOTES：
+ 1. After you log into the console, please check the
+ monitoring status of service components in
+ "Cluster Management". If any service is not
+ ready, please wait patiently until all components
+ are up and running.
+ 2. Please change the default password after login.
+
+ #####################################################
+ https://kubesphere.io 20xx-xx-xx xx:xx:xx
+ #####################################################
+ ```
+
+7. In **System Components**, you can see the status of different components.
+
+ {{< notice tip >}}
+
+If you do not see relevant components in the above image, some Pods may not be ready yet. You can execute `kubectl get pod --all-namespaces` through kubectl to see the status of Pods.
+ {{}}
diff --git a/content/en/docs/v3.4/quick-start/minimal-kubesphere-on-k8s.md b/content/en/docs/v3.4/quick-start/minimal-kubesphere-on-k8s.md
new file mode 100644
index 000000000..d65388114
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/minimal-kubesphere-on-k8s.md
@@ -0,0 +1,62 @@
+---
+title: "Minimal KubeSphere on Kubernetes"
+keywords: 'KubeSphere, Kubernetes, Minimal, Installation'
+description: 'Install KubeSphere on an existing Kubernetes cluster with a minimal installation package. Your Kubernetes cluster can be hosted on cloud or on-premises.'
+linkTitle: "Minimal KubeSphere on Kubernetes"
+weight: 2200,
+showSubscribe: true
+---
+
+In addition to installing KubeSphere on a Linux machine, you can also deploy it on existing Kubernetes clusters. This tutorial demonstrates the general steps of completing a minimal KubeSphere installation on Kubernetes. For more information, see [Installing on Kubernetes](../../installing-on-kubernetes/).
+
+## Prerequisites
+
+- To install KubeSphere 3.3 on Kubernetes, your Kubernetes version must be v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+- Make sure your machine meets the minimal hardware requirement: CPU > 1 Core, Memory > 2 GB.
+- A **default** Storage Class in your Kubernetes cluster needs to be configured before the installation.
+
+{{< notice note >}}
+
+- The CSR signing feature is activated in `kube-apiserver` when it is started with the `--cluster-signing-cert-file` and `--cluster-signing-key-file` parameters. See [RKE installation issue](https://github.com/kubesphere/kubesphere/issues/1925#issuecomment-591698309).
+- For more information about the prerequisites of installing KubeSphere on Kubernetes, see [Prerequisites](../../installing-on-kubernetes/introduction/prerequisites/).
+
+{{}}
+
+## Video Demonstration
+
+{{< youtube 6wdOBD4gyg4 >}}
+
+## Deploy KubeSphere
+
+After you make sure your machine meets the conditions, perform the following steps to install KubeSphere.
+
+1. Run the following commands to start installation:
+
+ ```bash
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/cluster-configuration.yaml
+ ```
+
+2. After KubeSphere is successfully installed, you can run the following command to view the installation logs:
+
+ ```bash
+ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f
+ ```
+
+3. Use `kubectl get pod --all-namespaces` to see whether all Pods are running normally in relevant namespaces of KubeSphere. If they are, check the port (`30880` by default) of the console by running the following command:
+
+ ```bash
+ kubectl get svc/ks-console -n kubesphere-system
+ ```
+
+4. Make sure port `30880` is opened in your security group and access the web console through the NodePort (`IP:30880`) with the default account and password (`admin/P@88w0rd`).
+
+5. After logging in to the console, you can check the status of different components in **System Components**. You may need to wait for some components to be up and running if you want to use related services.
+
+## Enable Pluggable Components (Optional)
+
+This guide is used only for the minimal installation by default. For more information about how to enable other components in KubeSphere, see [Enable Pluggable Components](../../pluggable-components/).
+
+## Code Demonstration
+
diff --git a/content/en/docs/v3.4/quick-start/wordpress-deployment.md b/content/en/docs/v3.4/quick-start/wordpress-deployment.md
new file mode 100644
index 000000000..8eab4069b
--- /dev/null
+++ b/content/en/docs/v3.4/quick-start/wordpress-deployment.md
@@ -0,0 +1,135 @@
+---
+title: "Compose and Deploy WordPress"
+keywords: 'KubeSphere, Kubernetes, app, WordPress'
+description: 'Learn the entire process of deploying an example application in KubeSphere, including credential creation, volume creation, and component settings.'
+linkTitle: "Compose and Deploy WordPress"
+weight: 2500
+---
+
+## WordPress Introduction
+
+WordPress is a free and open-source content management system written in PHP, allowing users to build their own websites. A complete WordPress application includes the following Kubernetes objects with MySQL serving as the backend database.
+
+
+
+## Objective
+
+This tutorial demonstrates how to create an application (WordPress as an example) in KubeSphere and access it outside the cluster.
+
+## Prerequisites
+
+An account `project-regular` is needed with the role of `operator` assigned in one of your projects (the user has been invited to the project). For more information, see [Create Workspaces, Projects, Users and Roles](../create-workspace-and-project/).
+
+## Estimated Time
+
+About 15 minutes.
+
+## Hands-on Lab
+
+### Step 1: Create Secrets
+
+#### Create a MySQL Secret
+
+The environment variable `WORDPRESS_DB_PASSWORD` is the password to connect to the database in WordPress. In this step, you need to create a Secret to store the environment variable that will be used in the MySQL Pod template.
+
+1. Log in to the KubeSphere console using the account `project-regular`. Go to the detail page of `demo-project` and navigate to **Configuration**. In **Secrets**, click **Create** on the right.
+
+2. Enter the basic information (for example, name it `mysql-secret`) and click **Next**. On the next page, select **Default** for **Type** and click **Add Data** to add a key-value pair. Enter the Key (`MYSQL_ROOT_PASSWORD`) and Value (`123456`) and click **√** in the lower-right corner to confirm. When you finish, click **Create** to continue.
+
+#### Create a WordPress Secret
+
+Follow the same steps above to create a WordPress Secret `wordpress-secret` with the key `WORDPRESS_DB_PASSWORD` and value `123456`. Secrets created display in the list.
+
+### Step 2: Create a PVC
+
+1. Go to **Persistent Volume Claims** under **Storage** and click **Create**.
+
+2. Enter the basic information of the Persistent Volume Claims (PVC), for example, `wordpress-pvc`, and click **Next**.
+
+3. In **Storage Settings**, you need to choose an available **Storage Class**, and set **Access Mode** and **Volume Capacity**. You can use the default value directly. Click **Next** to continue.
+
+4. For **Advanced Settings**, you do not need to add extra information for this step and click **Create** to finish.
+
+### Step 3: Create an application
+
+#### Add MySQL backend components
+
+1. Navigate to **Apps** under **Application Workloads**, select **Composed Apps** and click **Create**.
+
+2. Enter the basic information (for example, `wordpress` for **Name**) and click **Next**.
+
+3. In **Service Settings**, click **Create Service** to create a service in the app.
+
+4. Select **Stateful Service** to define the service type.
+
+5. Enter the name for the stateful service (for example, **mysql**) and click **Next**.
+
+6. In **Containers**, click **Add Container**.
+
+7. Enter `mysql:5.6` in the search box, press **Enter** and click **Use Default Ports**. After that, do not click **√** in the lower-right corner as the setting is not finished yet.
+
+ {{< notice note >}}
+
+In **Advanced Settings**, make sure the memory limit is no less than 1000 Mi or MySQL may fail to start due to a lack of memory.
+
+{{}}
+
+1. Scroll down to **Environment Variables** and click **From secret**. Enter the name `MYSQL_ROOT_PASSWORD` and choose the resource `mysql-secret` and the key `MYSQL_ROOT_PASSWORD` created in the previous step. Click **√** after you finish and **Next** to continue.
+
+2. Click **Add Persistent Volume Claim Template** under **Storage Settings**. Enter the PVC name prefix (`mysql`) and **Mount Path** (mode: `ReadAndWrite`, path: `/var/lib/mysql`).
+
+ Click **√** after you finish and click **Next** to continue.
+
+3. In **Advanced Settings**, you can click **Create** directly or set other options based on your needs.
+
+#### Add the WordPress frontend component
+
+12. In **Services** under **Application Workloads**, click **Create** again and select **Stateless Service** this time. Enter the name `wordpress` and click **Next**.
+
+13. Similar to previous steps, click **Add Container**, enter `wordpress:4.8-apache` in the search box, press **Enter** and click **Use Default Ports**.
+
+14. Scroll down to **Environment Variables** and click **From secret**. Two environment variables need to be added here. Enter the values as follows.
+
+ - For `WORDPRESS_DB_PASSWORD`, choose `wordpress-secret` and `WORDPRESS_DB_PASSWORD` created in Task 1.
+
+ - Click **Add Environment Variable**, and enter `WORDPRESS_DB_HOST` and `mysql` for the key and value.
+
+ {{< notice warning >}}
+
+For the second environment variable added here, the value must be the same as the name you set for MySQL in step 5. Otherwise, WordPress cannot connect to the corresponding database of MySQL.
+
+{{}}
+
+ Click **√** to save it and **Next** to continue.
+
+1. Under **Storage Settings**, click **Mount Volume**, and then click **Select Persistent Volume Claim**.
+
+2. Select `wordpress-pvc` created in the previous step, set the mode as `ReadAndWrite`, and enter `/var/www/html` as its mount path. Click **√** to save it, and then click **Next** to continue.
+
+3. In **Advanced Settings**, you can click **Create** directly or set other options based on your needs.
+
+4. The frontend component is also set now. Click **Next** to continue.
+
+5. You can set route rules (Ingress) here or click **Create** directly.
+
+6. The app will display in the list after you create it.
+
+### Step 4: Verify resources
+
+In **Workloads**, check the status of `wordpress-v1` and `mysql-v1` in **Deployments** and **StatefulSets** respectively. If they are running properly, it means WordPress has been created successfully.
+
+### Step 5: Access WordPress using NodePort
+
+1. To access the Service outside the cluster, in the navigation pane on the left, click **Application Workloads > Services** first. Click the three dots on the right of `wordpress` and select **Edit External Access**.
+
+2. Select `NodePort` for **Access Method** and click **OK**.
+
+3. Click the Service and you can see the port is exposed.
+
+4. Access this application at `{Node IP}:{NodePort}`.
+
+ {{< notice note >}}
+
+Make sure the port is opened in your security groups before you access the Service.
+
+{{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/reference/_index.md b/content/en/docs/v3.4/reference/_index.md
new file mode 100644
index 000000000..a30065be7
--- /dev/null
+++ b/content/en/docs/v3.4/reference/_index.md
@@ -0,0 +1,14 @@
+---
+title: "Reference"
+description: "The glossary used by KubeSphere and how to use the KubeSphere API to build your own application"
+layout: "second"
+
+linkTitle: "Reference"
+
+weight: 17000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+This chapter contains the glossary that is often used in KubeSphere and the information about the KubeSphere API.
diff --git a/content/en/docs/v3.4/reference/api-changes/_index.md b/content/en/docs/v3.4/reference/api-changes/_index.md
new file mode 100644
index 000000000..9df9ff639
--- /dev/null
+++ b/content/en/docs/v3.4/reference/api-changes/_index.md
@@ -0,0 +1,12 @@
+---
+title: "API Changes"
+description: "API Change Overview"
+layout: "single"
+
+linkTitle: "API Changes"
+
+weight: 17300
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
diff --git a/content/en/docs/v3.4/reference/api-changes/logging.md b/content/en/docs/v3.4/reference/api-changes/logging.md
new file mode 100644
index 000000000..2158ff499
--- /dev/null
+++ b/content/en/docs/v3.4/reference/api-changes/logging.md
@@ -0,0 +1,27 @@
+---
+title: "Logging"
+keywords: 'Kubernetes, KubeSphere, API, Logging'
+description: 'The API changes of the component **logging** in KubeSphere 3.3.'
+linkTitle: "Logging"
+weight: 17310
+---
+
+The API changes of the component **logging** in KubeSphere 3.3.
+
+## Time Format
+
+The time format of query parameters must be Unix timestamps (the number of seconds that has elapsed since the Unix epoch). Milliseconds are no longer allowed. The change affects the parameters `start_time` and `end_time`.
+
+## Deprecated APIs
+
+The following APIs are removed:
+
+- GET /workspaces/{workspace}
+- GET /namespaces/{namespace}
+- GET /namespaces/{namespace}/workloads/{workload}
+- GET /namespaces/{namespace}/pods/{pod}
+- The whole log setting API group
+
+## Fluent Operator
+
+In KubeSphere 3.3, the whole log setting APIs are removed from the KubeSphere core since the project Fluent Operator is refactored in an incompatible way. Please refer to [Fluent Operator docs](https://github.com/kubesphere/fluentbit-operator) for how to configure log collection in KubeSphere 3.3.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/reference/api-changes/monitoring.md b/content/en/docs/v3.4/reference/api-changes/monitoring.md
new file mode 100644
index 000000000..fea133380
--- /dev/null
+++ b/content/en/docs/v3.4/reference/api-changes/monitoring.md
@@ -0,0 +1,110 @@
+---
+title: "Monitoring"
+keywords: 'Kubernetes, KubeSphere, API, Monitoring'
+description: 'The API changes of the component **monitoring** in KubeSphere v3.3.2.'
+linkTitle: "Monitoring"
+weight: 17320
+---
+
+## API Version
+
+The monitoring API version is bumped to `v1alpha3`.
+
+## Time Format
+
+The time format of query parameters must be in Unix timestamps (the number of seconds that has elapsed since the Unix epoch). Decimals are no longer allowed. The change affects the parameters `start`, `end` and `time`.
+
+## Deprecated Metrics
+
+In KubeSphere 3.3, the metrics on the left have been renamed to the ones on the right.
+
+|V2.0|V3.3|
+|---|---|
+|workload_pod_cpu_usage | workload_cpu_usage|
+|workload_pod_memory_usage| workload_memory_usage|
+|workload_pod_memory_usage_wo_cache | workload_memory_usage_wo_cache|
+|workload_pod_net_bytes_transmitted | workload_net_bytes_transmitted|
+|workload_pod_net_bytes_received | workload_net_bytes_received|
+
+The following metrics have been deprecated and removed.
+
+|Deprecated Metrics|
+|---|
+|cluster_workspace_count|
+|cluster_account_count|
+|cluster_devops_project_count|
+|coredns_up_sum|
+|coredns_cache_hits|
+|coredns_cache_misses|
+|coredns_dns_request_rate|
+|coredns_dns_request_duration|
+|coredns_dns_request_duration_quantile|
+|coredns_dns_request_by_type_rate|
+|coredns_dns_request_by_rcode_rate|
+|coredns_panic_rate|
+|coredns_proxy_request_rate|
+|coredns_proxy_request_duration|
+|coredns_proxy_request_duration_quantile|
+|prometheus_up_sum|
+|prometheus_tsdb_head_samples_appended_rate|
+
+New metrics are introduced in KubeSphere 3.3.
+
+|New Metrics|
+|---|
+|kubesphere_workspace_count|
+|kubesphere_user_count|
+|kubesphere_cluser_count|
+|kubesphere_app_template_count|
+
+## Response Fields
+
+In KubeSphere 3.3, the response fields `metrics_level`, `status` and `errorType` are removed.
+
+In addition, the field name `resource_name` has been replaced with the specific resource type names. These types are `node`, `workspace`, `namespace`, `workload`, `pod`, `container` and `persistentvolumeclaim`. For example, instead of `resource_name: node1`, you will get `node: node1`. See the example response below:
+
+```json
+{
+ "results":[
+ {
+ "metric_name":"node_cpu_utilisation",
+ "data":{
+ "resultType":"vector",
+ "result":[
+ {
+ "metric":{
+ "__name__":"node:node_cpu_utilisation:avg1m",
+ "node":"master"
+ },
+ "value":[
+ 1588841175.979,
+ "0.04587499999997817"
+ ]
+ },
+ {
+ "metric":{
+ "__name__":"node:node_cpu_utilisation:avg1m",
+ "node":"node1"
+ },
+ "value":[
+ 1588841175.979,
+ "0.06379166666670245"
+ ]
+ },
+ {
+ "metric":{
+ "__name__":"node:node_cpu_utilisation:avg1m",
+ "node":"node2"
+ },
+ "value":[
+ 1588841175.979,
+ "0.19008333333367772"
+ ]
+ }
+ ]
+ }
+ }
+ ]
+}
+
+```
diff --git a/content/en/docs/v3.4/reference/api-changes/notification.md b/content/en/docs/v3.4/reference/api-changes/notification.md
new file mode 100644
index 000000000..692ec3dcf
--- /dev/null
+++ b/content/en/docs/v3.4/reference/api-changes/notification.md
@@ -0,0 +1,15 @@
+---
+title: "Notification"
+keywords: 'Kubernetes, KubeSphere, API, Notification'
+description: 'The API changes of the component **notification** in KubeSphere v3.1.0.'
+linkTitle: "Notification"
+weight: 17330
+---
+
+## API Version
+
+The notification API version is bumped to `v2alpha1`.
+
+## Deprecated API
+
+In KubeSphere 3.1.0, the APIs of version `v1` are deprecated:.
diff --git a/content/en/docs/v3.4/reference/api-docs.md b/content/en/docs/v3.4/reference/api-docs.md
new file mode 100644
index 000000000..e4e084d25
--- /dev/null
+++ b/content/en/docs/v3.4/reference/api-docs.md
@@ -0,0 +1,122 @@
+---
+title: "KubeSphere API"
+keywords: 'Kubernetes, KubeSphere, API'
+description: 'The REST API is the fundamental fabric of KubeSphere. This guide shows you how to access the KubeSphere API server.'
+linkTitle: "KubeSphere API"
+weight: 17200
+---
+
+## Architecture
+
+The KubeSphere API server validates and configures data for API objects. The API Server services REST operations and provides the frontend to the cluster's shared state through which all other components interact.
+
+
+
+## Use the KubeSphere API
+
+KubeSphere v3.0 moves the functionalities of **ks-apigateway** and **ks-account** into **ks-apiserver** to make the architecture more compact and clear. In order to use the KubeSphere API, you need to expose **ks-apiserver** to your client.
+
+
+### Step 1: Expose the KubeSphere API service
+
+If you are going to access KubeSphere inside the cluster, you can skip the following section and just use the KubeSphere API server endpoint **`http://ks-apiserver.kubesphere-system.svc`**.
+
+On the other hand, you need to expose the KubeSphere API server endpoint outside the cluster first.
+
+There are many ways to expose a Kubernetes service. For demonstration purposes, this example uses `NodePort`. Change the service type of `ks-apiserver` to `NodePort` by using the following command.
+
+```bash
+$ kubectl -n kubesphere-system patch service ks-apiserver -p '{"spec":{"type":"NodePort"}}'
+$ kubectl -n kubesphere-system get svc
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+etcd ClusterIP 10.233.34.220 + A logical unit to organize a tenant's workload projects (i.e. Kubernetes namespaces) and DevOps projects. It also features access control of different resources and allows team members to share information. +- **System workspace**
A special place to organize system projects of KubeSphere, Kubernetes and optional components such as App Store, service mesh and DevOps. +- **Workspace member**
The users that are invited to a workspace who have certain permissions to work in the workspace. +- **Project**
+ A project in KubeSphere is a Kubernetes namespace. +- **Multi-cluster project**
+ A project whose workloads are deployed across multiple clusters. +- **Project member**
+ The users that are invited to a project who have certain permissions to work in the project. +- **Workbench**
The landing page for a tenant. It displays authorized resources that the tenant can access such as workspaces and projects. +- **Volume**
+ A KubeSphere Volume is a Kubernetes PersistentVolumeClaim (PVC). +- **Public cluster**
+ Cluster administrators can set cluster visibility so that a cluster is available to certain workspaces. A public cluster means all platform users can access the cluster, in which they are able to create and schedule resources. +- **KubeKey**
+ A brand-new installation tool developed in Go. It is able to install KubeSphere and Kubernetes together or install Kubernetes only. It supports the deployment of cloud-native add-ons (YAML or Chart) as it creates a cluster. It can also be used to scale and upgrade a cluster. +- **ks-installer**
+ The package to deploy KubeSphere on existing Kubernetes clusters. + +## Applications and Workloads + +- **OpenPitrix**
+ An open-source system to package, deploy and manage different types of apps. + +- **App template**
+ A template for a specific application that tenants can use to deploy new application instances. + +- **App repository**
+ A web accessible repository that hosts different app templates. + +- **App Store**
+ A public place for different tenants to share various applications. + +- **Deployment**
You use a Deployment to describe a desired state. The Kubernetes Deployment controller changes the actual state to the desired state at a controlled rate. In other words, a Deployment runs multiple replicas of an application and replaces any instances if they fail. For more information, see [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). + +- **StatefulSet**
A StatefulSet is the workload object used to manage stateful applications, such as MySQL. For more information, see [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). + +- **DaemonSet**
A DaemonSet ensures that all (or some) nodes run a copy of a Pod, such as Fluentd and Logstash. For more information, see [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/). + +- **Job**
A Job creates one or more Pods and ensures that a specified number of them successfully terminate. For more information, see [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). + +- **CronJob**
A CronJob creates Jobs on a time-based schedule. A CronJob object is like one line of a crontab (cron table) file. It runs a Job periodically on a given schedule. For more information, see [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/). + +- **Service**
A Kubernetes Service is an abstraction object which defines a logical set of Pods and a policy by which to access them - sometimes called a microservice. For more information, see [Service](https://kubernetes.io/docs/concepts/services-networking/service/). + +## DevOps + +- **DevOps project**
+ A specific project for DevOps where you manage pipelines and credentials. + +- **SCM**
+ Source Control Management, such as GitHub and Gitlab. + +- **In-SCM**
+ The pipeline based on a Jenkinsfile that is hosted in SCM. + +- **Out-of-SCM**
+ The pipeline created through graphical editing panels without a Jenkinsfile. + +- **CI node**
+ A specific node for pipelines, S2I jobs or B2I jobs. Generally, applications often need to pull various dependencies during the building process. It might cause some issues like long pulling time, or unstable network causing failure. To build robust pipelines and speed up the building by using caches, you configure one or a set of CI nodes to which KubeSphere schedules the tasks of CI/CD pipelines and S2I/B2I. + +- **B2I**
+ Binary-to-Image. B2I is a toolkit and workflow for building reproducible container images from binary executables such as Jar, War, and binary packages. + +- **S2I**
Source-to-Image. S2I is a toolkit and workflow for building reproducible container images from source code. S2I produces ready-to-run images by injecting source code into a container image and letting the container prepare that source code for execution. + + +## Logging, Events and Auditing + +- **Exact query**
+ The method to search results that perfectly match the keyword entered. + +- **Fuzzy query**
The method to search results that partially match the keyword entered. + +- **Audit policy**
An audit policy defines a set of rules about what events should be recorded and what data they should include. + +- **Audit rule**
+ An auditing rule defines how to process auditing logs. + +- **Audit webhook**
+ The webhook that the Kubernetes auditing logs will be sent to. + +## Monitoring, Alert and Notification + +- **Cluster Status Monitoring**
+ The monitoring of related metrics such as node status, component status, CPU, memory, network, and disk of the cluster. + +- **Application Resource Monitoring**
+ The monitoring of application resources across the platform, such as the number of projects and DevOps projects, as well as the number of workloads and services of a specific type. + +- **Allocated CPU**
+ The metric is calculated based on the total CPU requests of Pods, for example, on a node. It represents the amount of CPU reserved for workloads on this node, even if workloads are using fewer CPU resources. + +- **Allocated Memory**
+ The metric is calculated based on the total memory requests of Pods, for example, on a node. It represents the amount of memory reserved for workloads on this node, even if workloads are using fewer memory resources. + +- **Log Collection**
+ The Log Collection function allows the system to collect container logs saved on volumes and send the logs to standard output. + +- **Notification Receiver**
+ The channel to receive notifications, such as email, DingTalk, WeCom, Slack, and webhook. + +## Network + +- **Route**
+ A KubeSphere Route is a Kubernetes Ingress. + +- **Gateway**
+ Before creating a route, you need to enable the Internet access gateway which forwards requests to the corresponding backend service. + +## Service Mesh + +- **Canary release**
+ A graceful application release method that introduces a new version of a service and tests it by sending a small percentage of traffic to it. At the same time, the old version is responsible for handling the rest of the traffic. If everything goes well, you can gradually increase the traffic sent to the new version, while simultaneously phasing out the old version. In the case of any occurring issues, it allows you to roll back to the previous version as you change the traffic percentage. + +- **Blue-green release/deployment**
+ A zero downtime application deployment where the new version can be deployed with the old one preserved. At any time, only one of the versions is active serving all the traffic, while the other one remains idle. If there is a problem with running, you can quickly roll back to the old version. + +- **Traffic mirroring**
+ A risk-free method of testing your app versions as it sends a copy of live traffic to a service that is being mirrored. It is also called shadowing. + +- **Application governance**
+ A switch to control the tracing of your application within a project. + +## Multi-cluster Management + +- **Host Cluster** **(H Cluster)**
+ The cluster that manages Member Clusters. The multi-cluster control plane is deployed on the Host Cluster. + +- **Member Cluster** **(M Cluster)**
+ A cluster serving as a member managed by the Host Cluster in a multi-cluster architecture. + +- **Direct connection**
+ A way to connect the Host Cluster and the Member Cluster when the kube-apiserver address of the Member Cluster is accessible on any node of the Host Cluster. + +- **Agent connection**
+ A way to connect the Host Cluster and the Member Cluster when the Host Cluster cannot access the Member Cluster directly. + +- **jwtSecret**
+ The secret needed for the Host Cluster and the Member Cluster to communicate with each other. + +- **Tower**
+ When you use agent connection, there is a proxy component installed on the Host Cluster and agent installed on the Member Cluster. Tower consists of both the proxy and the agent. + +- **Proxy service address**
+ The communication service address of the Host Cluster required by the tower agent in the Member Cluster when agent connection is adopted. diff --git a/content/en/docs/v3.4/reference/storage-system-installation/_index.md b/content/en/docs/v3.4/reference/storage-system-installation/_index.md new file mode 100644 index 000000000..1750262d2 --- /dev/null +++ b/content/en/docs/v3.4/reference/storage-system-installation/_index.md @@ -0,0 +1,12 @@ +--- +title: "Storage System Installation" +description: "Storage System Installation" +layout: "single" + +linkTitle: "Storage System Installation" + +weight: 17400 + +icon: "/images/docs/v3.3/docs.svg" + +--- diff --git a/content/en/docs/v3.4/reference/storage-system-installation/glusterfs-server.md b/content/en/docs/v3.4/reference/storage-system-installation/glusterfs-server.md new file mode 100644 index 000000000..3a2a6acc5 --- /dev/null +++ b/content/en/docs/v3.4/reference/storage-system-installation/glusterfs-server.md @@ -0,0 +1,516 @@ +--- + title: "Set up a GlusterFS Server" +keywords: 'Kubernetes, KubeSphere, GlusterFS' +description: 'How to set up a GlusterFS Server' +linkTitle: "Set up a GlusterFS Server" +weight: 17420 +--- + +As an open-source distributed file system, [GlusterFS](https://kubernetes.io/docs/concepts/storage/volumes/#glusterfs) allows you to mount `glusterfs` volumes to your Pods. If a `glusterfs` volume is pre-populated with data, they can be shared among your Pods in a Kubernetes cluster. + +This tutorial demonstrates how to configure GlusterFS on three server machines and install [Heketi](https://github.com/heketi/heketi) to manage your GlusterFS cluster. + +Once you have GlusterFS and Heketi set up, you can install GlusterFS on your client machine and use KubeKey to create a KubeSphere cluster with GlusterFS as a storage class. + +## Prepare GlusterFS Nodes + +There are three server machines of Ubuntu 16.04 in this example with each having one attached disk. + +| Hostname | IP Address | Operating System | Device | +| -------- | ----------- | ------------------------------------- | --------------- | +| server1 | 192.168.0.2 | Ubuntu 16.04, 4 Cores, 4 GB of Memory | /dev/vdd 300 GB | +| server2 | 192.168.0.3 | Ubuntu 16.04, 4 Cores, 4 GB of Memory | /dev/vdd 300 GB | +| server3 | 192.168.0.4 | Ubuntu 16.04, 4 Cores, 4 GB of Memory | /dev/vdd 300 GB | + +{{< notice note >}} + +- Heketi will be installed on `server1`, which provides a RESTful management interface to manage the lifecycle of GlusterFS volumes. You can install it on a separate machine as well. + +- Attach more block storage disks to your server machine if you need more storage space. +- Data will be saved to `/dev/vdd` (block device), which must be original without partitioning or formatting. + +{{}} + +## Set up Passwordless SSH Login + +### Configure root login + +1. Log in to `server1` and switch to the root user. + + ```bash + sudo -i + ``` + +2. Change the root user password: + + ```bash + passwd + ``` + + {{< notice note >}} + +Make sure password authentication is enabled in the file `/etc/ssh/sshd_config` (the value of `PasswordAuthentication` should be `yes`). + +{{}} + +3. Change the root user password of `server2` and `server3` as well. + +### Add hosts file entries + +1. Configure your DNS or edit the `/etc/hosts` file on all server machines to add their hostnames and IP addresses: + + ```bash + vi /etc/hosts + ``` + + ```txt + # hostname loopback address + 192.168.0.2 server1 + 192.168.0.3 server2 + 192.168.0.4 server3 + ``` + +2. Make sure you add the above entries to the `hosts` file of all server machines. + +### Configure passwordless SSH login + +1. On `server1`, create a key by running the following command. Press **Enter** directly for all the prompts. + + ```bash + ssh-keygen + ``` + +2. Copy the key to all GlusterFS nodes. + + ```bash + ssh-copy-id root@server1 + ``` + + ```bash + ssh-copy-id root@server2 + ``` + + ```bash + ssh-copy-id root@server3 + ``` + +3. Verify that you can access all server machines from `server1` through passwordless login. + + ```bash + ssh root@server1 + ``` + + ```bash + ssh root@server2 + ``` + + ```bash + ssh root@server3 + ``` + +## Install GlusterFS on All Server Machines + +1. On `server1`, run the following command to install `software-properties-common`. + + ```bash + apt-get install software-properties-common + ``` + +2. Add the community GlusterFS PPA. + + ```bash + add-apt-repository ppa:gluster/glusterfs-7 + ``` + +3. Make sure you are using the latest package. + + ```bash + apt-get update + ``` + +4. Install the GlusterFS server. + + ```bash + apt-get install glusterfs-server -y + ``` + +5. Make sure you run the above commands on `server2` and `server3` as well and verify the version on all machines. + + ```text + glusterfs -V + ``` + +{{< notice note >}} + +The above commands may be slightly different if you do no install GlusterFS on Ubuntu. For more information, see [the Gluster documentation](https://docs.gluster.org/en/latest/Install-Guide/Install/#installing-gluster). + +{{}} + +## Load Kernel Modules + +1. Run the following commands to load three necessary kernel modules on `server1`. + + ```bash + echo dm_thin_pool | sudo tee -a /etc/modules + ``` + + ```bash + echo dm_snapshot | sudo tee -a /etc/modules + ``` + + ```bash + echo dm_mirror | sudo tee -a /etc/modules + ``` + +2. Intall `thin-provisioning-tools`. + + ```bash + apt-get -y install thin-provisioning-tools + ``` + +3. Make sure you run the above commands on `server2` and `server3` as well. + +## Create a GlusterFS Cluster + +1. Run the following command on `server1` to add other nodes and create a cluster. + + ```bash + gluster peer probe server2 + ``` + + ``` + gluster peer probe server3 + ``` + +2. Verify that all nodes in the cluster are connected successfully. + + ```bash + gluster peer status + ``` + +3. Expected output: + + ```bash + Number of Peers: 2 + + Hostname: server2 + Uuid: e1192d6a-b65e-4ce8-804c-72d9425211a6 + State: Peer in Cluster (Connected) + + Hostname: server3 + Uuid: 9bd733e4-96d4-49d5-8958-6c947a2b4fa6 + State: Peer in Cluster (Connected) + ``` + +## Install Heketi + +As GlusterFS itself does not provide a way for API calls, you can install [Heketi](https://github.com/heketi/heketi) to manage the lifecycle of GlusterFS volumes with a RESTful API for Kubernetes calls. In this way, your Kubernetes cluster can dynamically provision GlusterFS volumes. Heketi v7.0.0 will be installed in this example. For more information about available Heketi versions, see its [Release Page](https://github.com/heketi/heketi/releases/). + +1. Download Heketi on `server1`. + + ```bash + wget https://github.com/heketi/heketi/releases/download/v7.0.0/heketi-v7.0.0.linux.amd64.tar.gz + ``` + + {{< notice note >}} + + You can also install Heketi on a separate machine. + + {{}} + +2. Unzip the file. + + ``` + tar -xf heketi-v7.0.0.linux.amd64.tar.gz + ``` + + ``` + cd heketi + ``` + + ``` + cp heketi /usr/bin + ``` + + ``` + cp heketi-cli /usr/bin + ``` + +3. Create a Heketi service file. + + ``` + vi /lib/systemd/system/heketi.service + ``` + + ``` + [Unit] + Description=Heketi Server + [Service] + Type=simple + WorkingDirectory=/var/lib/heketi + ExecStart=/usr/bin/heketi --config=/etc/heketi/heketi.json + Restart=on-failure + StandardOutput=syslog + StandardError=syslog + [Install] + WantedBy=multi-user.target + ``` + +4. Create Heketi folders. + + ```bash + mkdir -p /var/lib/heketi + ``` + + ``` + mkdir -p /etc/heketi + ``` + +5. Create a JSON file for Heketi configurations. + + ``` + vi /etc/heketi/heketi.json + ``` + + An example file: + + ```json + { + "_port_comment": "Heketi Server Port Number", + "port": "8080", + + "_use_auth": "Enable JWT authorization. Please enable for deployment", + "use_auth": false, + + "_jwt": "Private keys for access", + "jwt": { + "_admin": "Admin has access to all APIs", + "admin": { + "key": "123456" + }, + "_user": "User only has access to /volumes endpoint", + "user": { + "key": "123456" + } + }, + + "_glusterfs_comment": "GlusterFS Configuration", + "glusterfs": { + "_executor_comment": [ + "Execute plugin. Possible choices: mock, ssh", + "mock: This setting is used for testing and development.", + " It will not send commands to any node.", + "ssh: This setting will notify Heketi to ssh to the nodes.", + " It will need the values in sshexec to be configured.", + "kubernetes: Communicate with GlusterFS containers over", + " Kubernetes exec api." + ], + "executor": "ssh", + + "_sshexec_comment": "SSH username and private key file information", + "sshexec": { + "keyfile": "/root/.ssh/id_rsa", + "user": "root" + }, + + "_kubeexec_comment": "Kubernetes configuration", + "kubeexec": { + "host" :"https://kubernetes.host:8443", + "cert" : "/path/to/crt.file", + "insecure": false, + "user": "kubernetes username", + "password": "password for kubernetes user", + "namespace": "Kubernetes namespace", + "fstab": "Optional: Specify fstab file on node. Default is /etc/fstab" + }, + + "_db_comment": "Database file name", + "db": "/var/lib/heketi/heketi.db", + "brick_max_size_gb" : 1024, + "brick_min_size_gb" : 1, + "max_bricks_per_volume" : 33, + + + "_loglevel_comment": [ + "Set log level. Choices are:", + " none, critical, error, warning, info, debug", + "Default is warning" + ], + "loglevel" : "debug" + } + } + ``` + + {{< notice note >}} + + The account `admin` and its `key` value must be provided when you install GlusterFS as a storage class of your KubeSphere cluster. + + {{}} + +6. Start Heketi. + + ```bash + systemctl start heketi + ``` + +7. Check the status of Heketi. + + ```bash + systemctl status heketi + ``` + + If you can see `active (running)`, it means the installation is successful. Expected output: + + ```bash + ● heketi.service - Heketi Server + Loaded: loaded (/lib/systemd/system/heketi.service; disabled; vendor preset: enabled) + Active: active (running) since Tue 2021-03-09 13:04:30 CST; 4s ago + Main PID: 9282 (heketi) + Tasks: 8 + Memory: 6.5M + CPU: 62ms + CGroup: /system.slice/heketi.service + └─9282 /usr/bin/heketi --config=/etc/heketi/heketi.json + + Mar 09 13:04:30 server1 systemd[1]: Started Heketi Server. + Mar 09 13:04:30 server1 heketi[9282]: Heketi v7.0.0 + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 Loaded ssh executor + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 Adv: Max bricks per volume set to 33 + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 Adv: Max brick size 1024 GB + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 Adv: Min brick size 1 GB + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 GlusterFS Application Loaded + Mar 09 13:04:30 server1 heketi[9282]: [heketi] INFO 2021/03/09 13:04:30 Started Node Health Cache Monitor + Mar 09 13:04:30 server1 heketi[9282]: Listening on port 8080 + ``` + +8. Enable Heketi. + + ```bash + systemctl enable heketi + ``` + + Expected output: + + ```bash + Created symlink from /etc/systemd/system/multi-user.target.wants/heketi.service to /lib/systemd/system/heketi.service. + ``` + +9. Create a topology configuration file for Heketi. It contains the information of clusters, nodes, and disks added to Heketi. + + ```bash + vi /etc/heketi/topology.json + ``` + + An example file: + + ```json + { + "clusters": [ + { + "nodes": [ + { + "node": { + "hostnames": { + "manage": [ + "192.168.0.2" + ], + "storage": [ + "192.168.0.2" + ] + }, + "zone": 1 + }, + "devices": [ + "/dev/vdd" + ] + }, + { + "node": { + "hostnames": { + "manage": [ + "192.168.0.3" + ], + "storage": [ + "192.168.0.3" + ] + }, + "zone": 1 + }, + "devices": [ + "/dev/vdd" + ] + }, + { + "node": { + "hostnames": { + "manage": [ + "192.168.0.4" + ], + "storage": [ + "192.168.0.4" + ] + }, + "zone": 1 + }, + "devices": [ + "/dev/vdd" + ] + } + ] + } + ] + } + ``` + + {{< notice note >}} + + - Replace the IP addresses above with your own. + - Add your own disk name for `devices`. + + {{}} + +10. Load the Heketi JSON file. + + ```bash + export HEKETI_CLI_SERVER=http://localhost:8080 + ``` + + ```bash + heketi-cli topology load --json=/etc/heketi/topology.json + ``` + + Expected output: + + ```bash + Creating cluster ... ID: 2d9e11adede04fe6d07cb81c5a1a7ea4 + Allowing file volumes on cluster. + Allowing block volumes on cluster. + Creating node 192.168.0.2 ... ID: 0a9f240ab6fd96ea014948c5605be675 + Adding device /dev/vdd ... OK + Creating node 192.168.0.3 ... ID: 2468086cadfee8ef9f48bc15db81c88a + Adding device /dev/vdd ... OK + Creating node 192.168.0.4 ... ID: 4c21b33d5c32029f5b7dc6406977ec34 + Adding device /dev/vdd ... OK + ``` + +11. The above output displays both your cluster ID and node ID. Run the following command to view your cluster information. + + ```bash + heketi-cli cluster info 2d9e11adede04fe6d07cb81c5a1a7ea4 # Use your own cluster ID. + ``` + + Expected output: + + ```bash + Cluster id: 2d9e11adede04fe6d07cb81c5a1a7ea4 + Nodes: + 0a9f240ab6fd96ea014948c5605be675 + 2468086cadfee8ef9f48bc15db81c88a + 4c21b33d5c32029f5b7dc6406977ec34 + Volumes: + + Block: true + + File: true + ``` + diff --git a/content/en/docs/v3.4/reference/storage-system-installation/nfs-server.md b/content/en/docs/v3.4/reference/storage-system-installation/nfs-server.md new file mode 100644 index 000000000..b69cec05e --- /dev/null +++ b/content/en/docs/v3.4/reference/storage-system-installation/nfs-server.md @@ -0,0 +1,102 @@ +--- +title: "Set up an NFS Server" +keywords: 'Kubernetes, KubeSphere, NFS Server' +description: 'How to set up an NFS Server' +linkTitle: "Set up an NFS Server" +weight: 17410 +--- + +KubeSphere supports [NFS-client Provisioner](https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client) as a storage plugin. In order to use it, you must configure the NFS server in advance. With the NFS server in place, an NFS client mounts a directory on the server machine so that files residing on the NFS server are accessible to the NFS client. Namely, you need to create and export a directory that your client machine can access. + +Once your NFS server machine is ready, you can use [KubeKey](../../../installing-on-linux/introduction/kubekey/) to install NFS-client Provisioner by Helm charts together with Kubernetes and KubeSphere. The exported directory of your NFS server must be provided in your Chart configurations used by KubeKey during installation. + +{{< notice note >}} + +- You can also create the storage class of NFS-client after you install a KubeSphere cluster. +- NFS is incompatible with some applications, for example, Prometheus, which may result in pod creation failures. If you need to use NFS in the production environment, ensure that you have understood the risks. For more information, contact support@kubesphere.cloud. + +{{}} + +This tutorial demonstrates how to install the NFS server on Ubuntu 16.04 as an example. + +## Install and Configure an NFS Server + +### Step 1: Install the NFS kernel server + +To set up your server machine, you must install the NFS kernel server on it. + +1. Run the following command so that you will be using the latest package on Ubuntu for installation. + + ```bash + sudo apt-get update + ``` + +2. Install the NFS kernel server. + + ```bash + sudo apt install nfs-kernel-server + ``` + +### Step 2: Create an export directory + +Your NFS client will mount a directory on the server machine which has been exported by the NFS server. + +1. Run the following command to specify a mount folder name (for example, `/mnt/demo`). + + ```bash + sudo mkdir -p /mnt/demo + ``` + +2. For demonstration purposes, remove restrictive permissions of the folder so that all your clients can access the directory. + + ```bash + sudo chown nobody:nogroup /mnt/demo + ``` + + ```bash + sudo chmod 777 /mnt/demo + ``` + +### Step 3: Grant your client machine access to the NFS server + +1. Run the following command: + + ```bash + sudo nano /etc/exports + ``` + +2. Add your client information to the file. + + ```bash + /mnt/demo clientIP(rw,sync,no_subtree_check) + ``` + + If you have multiple client machines, you can add them all in the file. Alternatively, specify a subnet in the file so that all the clients within it can access the NFS server. For example: + + ```bash + /mnt/demo 192.168.0.0/24(rw,sync,no_subtree_check) + ``` + + {{< notice note >}} + + - `rw`: Read and write operations. The client machine will have both read and write access to the volume. + - `sync`: Changes will be written to disk and memory. + - `no_subtree_check`: Prevent subtree checking. It disables the security verification required for a client to mount permitted subdirectories. + + {{}} + +3. Save the file when you finish editing it. + +### Step 4: Apply the configuration + +1. Run the following command to export your shared directory. + + ```bash + sudo exportfs -a + ``` + +2. Restart the NFS kernel server. + + ```bash + sudo systemctl restart nfs-kernel-server + ``` diff --git a/content/en/docs/v3.4/release/_index.md b/content/en/docs/v3.4/release/_index.md new file mode 100644 index 000000000..fe9928658 --- /dev/null +++ b/content/en/docs/v3.4/release/_index.md @@ -0,0 +1,14 @@ +--- +title: "Release Notes" +description: "Release Notes of Different KubeSphere Versions" +layout: "second" + +linkTitle: "Release Notes" + +weight: 18000 + +icon: "/images/docs/v3.3/docs.svg" + +--- + +This chapter lists the release notes of all versions of KubeSphere, helping you gain a comprehensive understanding of upgrades and feature enhancements in every version release. diff --git a/content/en/docs/v3.4/release/release-v200.md b/content/en/docs/v3.4/release/release-v200.md new file mode 100644 index 000000000..93d303f89 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v200.md @@ -0,0 +1,92 @@ +--- +title: "Release Notes for 2.0.0" +keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus" +description: "KubeSphere release notes for 2.0.0." + +linkTitle: "Release Notes - 2.0.0" +weight: 18900 +--- + +KubeSphere 2.0.0 was released on **May 18th, 2019**. + +## What's New in 2.0.0 + +### Component Upgrades + +- Support Kubernetes [Kubernetes 1.13.5](https://github.com/kubernetes/kubernetes/releases/tag/v1.13.5) +- Integrate [QingCloud Cloud Controller](https://github.com/yunify/qingcloud-cloud-controller-manager). After installing load balancer, QingCloud load balancer can be created through KubeSphere console and the backend workload is bound automatically. +- Integrate [QingStor CSI v0.3.0](https://github.com/yunify/qingstor-csi/tree/v0.3.0) storage plugin and support physical NeonSAN storage system. Support SAN storage service with high availability and high performance. +- Integrate [QingCloud CSI v0.2.1](https://github.com/yunify/qingcloud-csi/tree/v0.2.1) storage plugin and support many types of volume to create QingCloud block services. +- Harbor is upgraded to 1.7.5. +- GitLab is upgraded to 11.8.1. +- Prometheus is upgraded to 2.5.0. + +### Microservice Governance + +- Integrate Istio 1.1.1 and support visualization of service mesh management. +- Enable the access to the project's external websites and the application traffic governance. +- Provide built-in sample microservice [Bookinfo Application](https://istio.io/docs/examples/bookinfo/). +- Support traffic governance. +- Support traffic images. +- Provide load balancing of microservice based on Istio. +- Support canary release. +- Enable blue-green deployment. +- Enable circuit breaking. +- Enable microservice tracing. + +### DevOps (CI/CD Pipeline) + +- CI/CD pipeline provides email notification and supports the email notification during construction. +- Enhance CI/CD graphical editing pipelines, and more pipelines for common plugins and execution conditions. +- Provide source code vulnerability scanning based on SonarQube 7.4. +- Support [Source to Image](https://github.com/kubesphere/s2ioperator) feature. + +### Monitoring + +- Provide Kubernetes component independent monitoring page including etcd, kube-apiserver and kube-scheduler. +- Optimize several monitoring algorithm. +- Optimize monitoring resources. Reduce Prometheus storage and the disk usage up to 80%. + +### Logging + +- Provide unified log console in terms of tenant. +- Enable accurate and fuzzy retrieval. +- Support real-time and history logs. +- Support combined log query based on namespace, workload, Pod, container, key words and time limit. +- Support detail page of single and direct logs. Pods and containers can be switched. +- [FluentBit Operator](https://github.com/kubesphere/fluentbit-operator) supports logging gathering settings: ElasticSearch, Kafka and Fluentd can be added, activated or turned off as log collectors. Before sending to log collectors, you can configure filtering conditions for needed logs. + +### Alerting and Notifications + +- Email notifications are available for cluster nodes and workload resources. +- Notification rules: combined multiple monitoring resources are available. Different warning levels, detection cycle, push times and threshold can be configured. +- Time and notifiers can be set. +- Enable notification repeating rules for different levels. + +### Security Enhancement + +- Fix RunC Container Escape Vulnerability [Runc container breakout](https://log.qingcloud.com/archives/5127) +- Fix Alpine Docker's image Vulnerability [Alpine container shadow breakout](https://www.alpinelinux.org/posts/Docker-image-vulnerability-CVE-2019-5021.html) +- Support single and multi-login configuration items. +- Verification code is required after multiple invalid logins. +- Enhance passwords' policy and prevent weak passwords. +- Others security enhancements. + +### Interface Optimization + +- Optimize multiple user experience of console, such as the switch between DevOps project and other projects. +- Optimize many Chinese-English webpages. + +### Others + +- Support Etcd backup and recovery. +- Support regular cleanup of the docker's image. + +## Bugs Fixes + +- Fix delay updates of the resource and deleted pages. +- Fix the left dirty data after deleting the HPA workload. +- Fix incorrect Job status display. +- Correct resource quota, Pod usage and storage metrics algorithm. +- Adjust CPU usage percentages. +- many more bugfix diff --git a/content/en/docs/v3.4/release/release-v201.md b/content/en/docs/v3.4/release/release-v201.md new file mode 100644 index 000000000..d4f043ec7 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v201.md @@ -0,0 +1,19 @@ +--- +title: "Release Notes for 2.0.1" +keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus" +description: "KubeSphere release notes for 2.0.1." + +linkTitle: "Release Notes - 2.0.1" +weight: 18800 +--- + +KubeSphere 2.0.1 was released on **June 9th, 2019**. + +## Bug Fix + +- Fix the issue that CI/CD pipeline cannot recognize correct special characters in the code branch. +- Fix CI/CD pipeline's issue of being unable to check logs. +- Fix no-log data output problem caused by index document fragmentation abnormity during the log query. +- Fix prompt exceptions when searching for logs that do not exist. +- Fix the line-overlap problem on traffic governance topology and fixed invalid image strategy application. +- Many more bugfix diff --git a/content/en/docs/v3.4/release/release-v202.md b/content/en/docs/v3.4/release/release-v202.md new file mode 100644 index 000000000..d655a0678 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v202.md @@ -0,0 +1,40 @@ +--- +title: "Release Notes for 2.0.2" +keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus" +description: "KubeSphere release notes for 2.0.2." + +linkTitle: "Release Notes - 2.0.2" +weight: 18700 +--- + +KubeSphere 2.0.2 was released on July 9, 2019, which fixes known bugs and enhances existing feature. If you have installed versions of 1.0.x, 2.0.0 or 2.0.1, please download KubeSphere installer v2.0.2 to upgrade. + +## What's New in 2.0.2 + +### Enhanced Features + +- [API docs](../../reference/api-docs/) are available on the official website. +- Block brute-force attacks. +- Standardize the maximum length of resource names. +- Upgrade the gateway of project (Ingress Controller) to the version of 0.24.1. Support Ingress grayscale release. + +## List of Fixed Bugs + +- Fix the issue that traffic topology displays resources outside of this project. +- Fix the extra service component issue from traffic topology under specific circumstances. +- Fix the execution issue when "Source to Image" reconstructs images under specific circumstances. +- Fix the page display problem when "Source to Image" job fails. +- Fix the log checking problem when Pod status is abnormal. +- Fix the issue that disk monitor cannot detect some types of volume mounting, such as LVM volume. +- Fix the problem of detecting deployed applications. +- Fix incorrect status of application component. +- Fix host node's number calculation errors. +- Fix input data loss caused by switching reference configuration buttons when adding environmental variables. +- Fix the rerun job issue that the Operator role cannot execute. +- Fix the initialization issue on IPv4 environment uuid. +- Fix the issue that the log detail page cannot be scrolled down to check past logs. +- Fix wrong APIServer addresses in KubeConfig files. +- Fix the issue that DevOps project's name cannot be changed. +- Fix the issue that container logs cannot specify query time. +- Fix the saving problem on relevant repository's secrets under certain circumstances. +- Fix the issue that application's service component creation page does not have image registry's secrets. diff --git a/content/en/docs/v3.4/release/release-v210.md b/content/en/docs/v3.4/release/release-v210.md new file mode 100644 index 000000000..87ddd7758 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v210.md @@ -0,0 +1,155 @@ +--- +title: "Release Notes for 2.1.0" +keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus" +description: "KubeSphere release notes for 2.1.0." + +linkTitle: "Release Notes - 2.1.0" +weight: 18600 +--- + +KubeSphere 2.1.0 was released on Nov 11th, 2019, which fixes known bugs, adds some new features and brings some enhancement. If you have installed versions of 2.0.x, please upgrade it and enjoy the better user experience of v2.1.0. + +## Installer Enhancement + +- Decouple some components and make components including DevOps, service mesh, app store, logging, alerting and notification optional and pluggable +- Add Grafana (v5.2.4) as the optional component +- Upgrade Kubernetes to 1.15.5. It is also compatible with 1.14.x and 1.13.x +- Upgrade [OpenPitrix](https://openpitrix.io/) to v0.4.5 +- Upgrade the log forwarder Fluent Bit to v1.3.2 +- Upgrade Jenkins to v2.176.2 +- Upgrade Istio to 1.3.3 +- Optimize the high availability for core components + +## App Store + +### Features + +Support upload / test / review / deploy / publish/ classify / upgrade / deploy and delete apps, and provide nine built-in applications + +### Upgrade & Enhancement + +- The application repository configuration is moved from global to each workspace +- Support adding application repository to share applications in a workspace + +## Storage + +### Features + +- Support Local Volume with dynamic provisioning +- Provide the real-time monitoring feature for QingCloud block storage + +### Upgrade & Enhancement + +QingCloud CSI is adapted to CSI 1.1.0, supports upgrade, topology, create or delete a snapshot. It also supports creating PVC based on a snapshot + +### BUG Fixes + +Fix the StorageClass list display problem + +## Observability + +### Features + +- Support for collecting the file logs on the disk. It is used for the Pod which preserves the logs as the file on the disk +- Support integrating with external ElasticSearch 7.x +- Ability to search logs containinh Chinese words +- Add initContainer log display +- Ability to export logs +- Support for canceling the notification from alerting + +### UPGRADE & ENHANCEMENT + +- Improve the performance of log search +- Refine the hints when the logging service is abnormal +- Optimize the information when the monitoring metrics request is abnormal +- Support pod anti-affinity rule for Prometheus + +### BUG FIXES + +- Fix the mistaken highlights in the logs search result +- Fix log search not matching phrases correctly +- Fix the issue that log could not be retrieved for a deleted workload when it is searched by workload name +- Fix the issue where the results were truncated when the log is highlighted +- Fix some metrics exceptions: node `inode`, maximum pod tolerance +- Fix the issue with an incorrect number of alerting targets +- Fix filter failure problem of multi-metric monitoring +- Fix the problem of no logging and monitoring information on taint nodes (Adjust the toleration attributes of node-exporter and fluent-bit to deploy on all nodes by default, ignoring taints) + +## DevOps + +### Features + +- Add support for branch exchange and git log export in S2I +- Add B2I, ability to build Binary/WAR/JAR package and release to Kubernetes +- Support dependency cache for the pipeline, S2I, and B2I +- Support delete Kubernetes resource action in `kubernetesDeploy` step +- Multi-branch pipeline supports trigger other pipelines when create or delete the branch + +### Upgrades & Enhancement + +- Support BitBucket in the pipeline +- Support Cron script validation in the pipeline +- Support Jenkinsfile syntax validation +- Support custom the link in SonarQube +- Support event trigger build in the pipeline +- Optimize the agent node selection in the pipeline +- Accelerate the start speed of the pipeline +- Use dynamical volume as the work directory of the Agent in the pipeline, also contributes to Jenkins [#589](https://github.com/jenkinsci/kubernetes-plugin/pull/598) +- Optimize the Jenkins kubernetesDeploy plugin, add more resources and versions (v1, app/v1, extensions/v1beta1、apps/v1beta2、apps/v1beta1、autoscaling/v1、autoscaling/v2beta1、autoscaling/v2beta2、networking.k8s.io/v1、batch/v1beta1、batch/v2alpha1), also contributes to Jenkins [#614](https://github.com/jenkinsci/kubernetes-plugin/pull/614) +- Add support for PV, PVC, Network Policy in deploy step of the pipeline, also contributes to Jenkins [#87](https://github.com/jenkinsci/kubernetes-cd-plugin/pull/87)、[#88](https://github.com/jenkinsci/kubernetes-cd-plugin/pull/88) + +### Bug Fixes + +- Fix the issue that 400 bad request in GitHub Webhook +- incompatible change: DevOps Webhook's URL prefix is changed from `/webhook/xxx` to `/devops_webhook/xxx` + +## Authentication and authority + +### Features + +Support sync and authenticate with AD account + +### Upgrades & Enhancement + +- Reduce the LDAP component's RAM consumption +- Add protection against brute force attacks + +### Bug Fixes + +- Fix LDAP connection pool leak +- Fix the issue where users could not be added in the workspace +- Fix sensitive data transmission leaks + +## User Experience + +### Features + +Ability to wizard management of projects (namespace) that are not assigned to the workspace + +### Upgrades & Enhancement + +- Support bash-completion in web kubectl +- Optimize the host information display +- Add connection test of the email server +- Add prompt on resource list page +- Optimize the project overview page and project basic information +- Simplify the service creation process +- Simplify the workload creation process +- Support real-time status update in the resource list +- optimize YAML editing +- Support image search and image information display +- Add the pod list to the workload page +- Update the web terminal theme +- Support container switching in container terminal +- Optimize Pod information display, and add Pod scheduling information +- More detailed workload status display + +### Bug Fixes + +- Fix the issue where the default request resource of the project is displayed incorrectly +- Optimize the web terminal design, make it much easier to find +- Fix the Pod status update delay +- Fix the issue where a host could not be searched based on roles +- Fix DevOps project quantity error in workspace detail page +- Fix the issue with the workspace list pages not turning properly +- Fix the problem of inconsistent result ordering after query on workspace list page diff --git a/content/en/docs/v3.4/release/release-v211.md b/content/en/docs/v3.4/release/release-v211.md new file mode 100644 index 000000000..270575452 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v211.md @@ -0,0 +1,122 @@ +--- +title: "Release Notes for 2.1.1" +keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus" +description: "KubeSphere release notes for 2.1.1." + +linkTitle: "Release Notes - 2.1.1" +weight: 18500 +--- + +KubeSphere 2.1.1 was released on Feb 23rd, 2020, which has fixed known bugs and brought some enhancements. For the users who have installed versions of 2.0.x or 2.1.0, make sure to read the user manual carefully about how to upgrade before doing that, and feel free to raise any questions on [GitHub](https://github.com/kubesphere/kubesphere/issues). + +## What's New in 2.1.1 + +## Installer + +### UPGRADE & ENHANCEMENT + +- Support Kubernetes v1.14.x、v1.15.x、v1.16.x、v1.17.x，also solve the issue of Kubernetes API Compatibility#[1829](https://github.com/kubesphere/kubesphere/issues/1829) +- Simplify the steps of installation on existing Kubernetes, and remove the step of specifying cluster's CA certification, also specifying Etcd certification is no longer mandatory step if users don't need Etcd monitoring metrics +- Backup the configuration of CoreDNS before upgrading + +### BUG FIXES + +- Fix the issue of importing apps to App Store + +## App Store + +### UPGRADE & ENHANCEMENT + +- Upgrade OpenPitrix to v0.4.8 + +### BUG FIXES + +- Fix the latest version display issue for the published app #[1130](https://github.com/kubesphere/kubesphere/issues/1130) +- Fix the column name display issue in app approval list page #[1498](https://github.com/kubesphere/kubesphere/issues/1498) +- Fix the searching issue by app name/workspace #[1497](https://github.com/kubesphere/kubesphere/issues/1497) +- Fix the issue of failing to create app with the same name of previously deleted app #[1821](https://github.com/kubesphere/kubesphere/pull/1821) #[1564](https://github.com/kubesphere/kubesphere/issues/1564) +- Fix the issue of failing to deploy apps in some cases #[1619](https://github.com/kubesphere/kubesphere/issues/1619) #[1730](https://github.com/kubesphere/kubesphere/issues/1730) + +## Storage + +### UPGRADE & ENHANCEMENT + +- Support CSI plugins of Alibaba Cloud and Tencent Cloud + +### BUG FIXES + +- Fix the paging issue of storage class list page #[1583](https://github.com/kubesphere/kubesphere/issues/1583) #[1591](https://github.com/kubesphere/kubesphere/issues/1591) +- Fix the issue that the value of imageFeatures parameter displays '2' when creating ceph storage class #[1593](https://github.com/kubesphere/kubesphere/issues/1593) +- Fix the issue that search filter fails to work in persistent volumes list page #[1582](https://github.com/kubesphere/kubesphere/issues/1582) +- Fix the display issue for abnormal persistent volume #[1581](https://github.com/kubesphere/kubesphere/issues/1581) +- Fix the display issue for the persistent volumes which associated storage class is deleted #[1580](https://github.com/kubesphere/kubesphere/issues/1580) #[1579](https://github.com/kubesphere/kubesphere/issues/1579) + +## Observability + +### UPGRADE & ENHANCEMENT + +- Upgrade Fluent Bit to v1.3.5 #[1505](https://github.com/kubesphere/kubesphere/issues/1505) +- Upgrade Kube-state-metrics to v1.7.2 +- Upgrade Elastic Curator to v5.7.6 #[517](https://github.com/kubesphere/ks-installer/issues/517) +- Fluent Bit Operator support to detect the location of soft linked docker log folder dynamically on host machines +- Fluent Bit Operator support to manage the instance of Fluent Bit by declarative configuration through updating the ConfigMap of Operator +- Fix the issue of sort orders in alert list page #[1397](https://github.com/kubesphere/kubesphere/issues/1397) +- Adjust the metric of container memory usage with 'container_memory_working_set_bytes' + +### BUG FIXES + +- Fix the lag issue of container logs #[1650](https://github.com/kubesphere/kubesphere/issues/1650) +- Fix the display issue that some replicas of workload have no logs on container detail log page #[1505](https://github.com/kubesphere/kubesphere/issues/1505) +- Fix the compatibility issue of Curator to support ElasticSearch 7.x #[517](https://github.com/kubesphere/ks-installer/issues/517) +- Fix the display issue of container log page during container initialization #[1518](https://github.com/kubesphere/kubesphere/issues/1518) +- Fix the blank node issue when these nodes are resized #[1464](https://github.com/kubesphere/kubesphere/issues/1464) +- Fix the display issue of components status in monitor center, to keep them up-to date #[1858](https://github.com/kubesphere/kubesphere/issues/1858) +- Fix the wrong monitoring targets number in alert detail page #[61](https://github.com/kubesphere/console/issues/61) + +## DevOps + +### BUG FIXES + +- Fix the issue of UNSTABLE state not visible in the pipeline #[1428](https://github.com/kubesphere/kubesphere/issues/1428) +- Fix the format issue of KubeConfig in DevOps pipeline #[1529](https://github.com/kubesphere/kubesphere/issues/1529) +- Fix the image repo compatibility issue in B2I, to support image repo of Alibaba Cloud #[1500](https://github.com/kubesphere/kubesphere/issues/1500) +- Fix the paging issue in DevOps pipelines' branches list page #[1517](https://github.com/kubesphere/kubesphere/issues/1517) +- Fix the issue of failing to display pipeline configuration after modifying it #[1522](https://github.com/kubesphere/kubesphere/issues/1522) +- Fix the issue of failing to download generated artifact in S2I job #[1547](https://github.com/kubesphere/kubesphere/issues/1547) +- Fix the issue of [data loss occasionally after restarting Jenkins]( https://ask.kubesphere.io/forum/d/283-jenkins) +- Fix the issue that only 'PR-HEAD' is fetched when binding pipeline with GitHub #[1780](https://github.com/kubesphere/kubesphere/issues/1780) +- Fix 414 issue when updating DevOps credential #[1824](https://github.com/kubesphere/kubesphere/issues/1824) +- Fix wrong s2ib/s2ir naming issue from B2I/S2I #[1840](https://github.com/kubesphere/kubesphere/issues/1840) +- Fix the issue of failing to drag and drop tasks on pipeline editing page #[62](https://github.com/kubesphere/console/issues/62) + +## Authentication and Authorization + +### UPGRADE & ENHANCEMENT + +- Generate client certification through CSR #[1449](https://github.com/kubesphere/kubesphere/issues/1449) + +### BUG FIXES + +- Fix content loss issue in KubeConfig token file #[1529](https://github.com/kubesphere/kubesphere/issues/1529) +- Fix the issue that users with different permission fail to log in on the same browser #[1600](https://github.com/kubesphere/kubesphere/issues/1600) + +## User Experience + +### UPGRADE & ENHANCEMENT + +- Support to edit SecurityContext in workload editing page #[1530](https://github.com/kubesphere/kubesphere/issues/1530) +- Support to configure init container in workload editing page #[1488](https://github.com/kubesphere/kubesphere/issues/1488) +- Add support of startupProbe, also add periodSeconds, successThreshold, failureThreshold parameters in probe editing page #[1487](https://github.com/kubesphere/kubesphere/issues/1487) +- Optimize the status update display of Pods #[1187](https://github.com/kubesphere/kubesphere/issues/1187) +- Optimize the error message report on console #[43](https://github.com/kubesphere/console/issues/43) + +### BUG FIXES + +- Fix the status display issue for the Pods that are not under running status #[1187](https://github.com/kubesphere/kubesphere/issues/1187) +- Fix the issue that the added annotation can't be deleted when creating service of QingCloud LoadBalancer #[1395](https://github.com/kubesphere/kubesphere/issues/1395) +- Fix the display issue when selecting workload on service editing page #[1596](https://github.com/kubesphere/kubesphere/issues/1596) +- Fix the issue of failing to edit configuration file when editing 'Job' #[1521](https://github.com/kubesphere/kubesphere/issues/1521) +- Fix the issue of failing to update the service of 'StatefulSet' #[1513](https://github.com/kubesphere/kubesphere/issues/1513) +- Fix the issue of image searching for QingCloud and Alibaba Cloud image repos #[1627](https://github.com/kubesphere/kubesphere/issues/1627) +- Fix resource ordering issue with the same creation timestamp #[1750](https://github.com/kubesphere/kubesphere/pull/1750) +- Fix the issue of failing to edit configuration file when editing service #[41](https://github.com/kubesphere/console/issues/41) diff --git a/content/en/docs/v3.4/release/release-v300.md b/content/en/docs/v3.4/release/release-v300.md new file mode 100644 index 000000000..f8ee049c2 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v300.md @@ -0,0 +1,207 @@ +--- +title: "Release Notes for 3.0.0" +keywords: "Kubernetes, KubeSphere, release-notes" +description: "KubeSphere release notes for 3.0.0." + +linkTitle: "Release Notes - 3.0.0" +weight: 18400 +--- + +## How to get v3.0.0 + +- [Install KubeSphere v3.0.0 on Linux](../../installing-on-linux/) +- [Install KubeSphere v3.0.0 on existing Kubernetes](../../installing-on-kubernetes/) + +## Release Notes + +## **Installer** + +### FEATURES + +- A brand-new installer: [KubeKey](https://github.com/kubesphere/kubekey), v1.0.0, which is a turnkey solution to installing Kubernetes with KubeSphere on different platforms. It is more easy to use and reduces the dependency on OS environment + +### UPGRADES & ENHANCEMENTS + +- Be compatible with Kubernetes 1.15.x, 1.16.x, 1.17.x and 1.18.x for [ks-installer](https://github.com/kubesphere/ks-installer), v3.0.0 +- [KubeKey](https://github.com/kubesphere/kubekey) officially supports Kubernetes 1.15.12, 1.16.13, 1.17.9 and 1.18.6 (Please avoid using KubeKey to install Kubernetes 1.15 to 1.15.5 and 1.16 to 1.16.2, because Kubernetes has an [API validation issue](https://github.com/kubernetes/kubernetes/issues/83778)) +- Add support for EulerOS, UOS and KylinOS +- Add support for Kunpeng and Phytium CPU +- Use ClusterConfiguration CRD to store ks-installer's configuration instead of ConfigMap + +## **Cluster Management** + +### FEATURES + +- Support management of multiple Kubernetes clusters +- Support Federated Deployment and Federated StatefulSet across multiple clusters + +## **Observability** + +### FEATURES + +- Support custom monitoring for 3rd-party application metrics in KubeSphere console +- Add Kubernetes and KubeSphere auditing support, including audit event archiving, searching and alerting +- Add Kubernetes event management support, including Kubernetes event archiving, searching and alerting based by [kube-events](https://github.com/kubesphere/kube-events) +- Add tenant control to auditing and support Kubernetes event searching. A tenant user can only search his or her own auditing logs and Kubernetes events +- Support archiving auditing logs and Kubernetes events to Elasticsearch, Kafka or Fluentd +- Add multi-tenant notification support by [Notification Manager](https://github.com/kubesphere/notification-manager) +- Support Alertmanager v0.21.0 + +### UPGRADES & ENHANCEMENTS + +- Upgrade Prometheus Operator to v0.38.3 (KubeSphere customized version ) +- Upgrade Prometheus to v2.20.1 +- Upgrade Node Exporter to v0.18.1 +- Upgrade kube-state-metrics to v1.9.6 +- Upgrade metrics server to v0.3.7 +- metrics-server is enabled by default (Disabled if KubeSphere is installed on existing Kubernetes) +- Upgrade Fluent Bit Operator to v0.2.0 +- Upgrade Fluent Bit to v1.4.6 +- Significantly improve log searching performance +- Allow platform admins to view pod logs from deleted namespaces +- Adjust the display style of log searching results in Toolbox +- Optimize log collection configuration for log files on pod's volume + +### BUG FIXES + +- Fix time skew in metric graphs for newly created namespaces (#[2868](https://github.com/kubesphere/kubesphere/issues/2868)) +- Fix workload-level alerting not working as expected (#[2834](https://github.com/kubesphere/kubesphere/issues/2834)) +- Fix no metric data for NotReady nodes + +## **DevOps** + +### FEATURES + +- Refactor DevOps framework, and use CRDs to manage DevOps resources + +### UPGRADES & ENHANCEMENTS + +- Remove Sonarqube from installer default packages, and support for external Sonarqube + +### BUG FIXES + +- Fix the issue that DevOps permission data is missing in a very limited number of cases + +- Fix the issue that the Button in the Stage page doesn't work (#[449](https://github.com/kubesphere/console/issues/449)) +- Fix the issue that the parameterized pipeline failed to send the parameter's value (#[2699](https://github.com/kubesphere/kubesphere/issues/2699)) + +## **App Store** + +### FEATURES + +- Support Helm V3 +- Support deploying application templates onto multiple clusters +- Support application template upgrade +- Users can view events that occur during repository synchronization + +### UPGRADES & ENHANCEMENTS + +- Users can use the same application repository name + +- Support the application template which contains CRDs + +- Merge all OpenPitrix services into one service + +- Support HTTP basic authentication when adding an application repository + +- Add and upgrade below apps in App Store: + + | App Name | App Version | Chart Version | + | ---------------------- | ----------- | :------------ | + | AWS EBS CSI Driver | 0.5.0 | 0.3.0 | + | AWS EFS CSI Driver | 0.3.0 | 0.1.0 | + | AWS FSX CSI Driver | 0.1.0 | 0.1.0 | + | Elasticsearch Exporter | 1.1.0 | 3.3.0 | + | etcd | 3.3.12 | 0.1.1 | + | Harbor | 2.0.0 | 1.4.0 | + | Memcached | 1.5.20 | 3.2.3 | + | Minio master | | 5.0.26 | + | MongoDB | 4.2.1 | 0.3.0 | + | MySQL | 5.7.30 | 1.6.6 | + | MySQL Exporter | 0.11.0 | 0.5.3 | + | Nginx | 1.18.0 | 1.3.2 | + | PorterLB | 0.3-alpha | 0.1.3 | + | PostgreSQL | 12.0 | 0.3.2 | + | RabbitMQ | 3.8.1 | 0.3.0 | + | Redis | 5.0.5 | 0.3.2 | + | Redis Exporter | 1.3.4 | 3.4.1 | + | Tomcat | 8.5.41 | 0.4.1+1 | + +### BUG FIXES + +- Fix the issue of insufficient length of attachment IDs + +## **Network** + +### FEATURES + +- Support project network isolation by adding controllers to manage custom project network policies +- Support workspace network isolation +- Support adding, viewing, modifying and deleting native Kubernetes network policies + +## **Service Mesh** + +### FEATURES + +- Support cleaning Jaeger ES Indexer + +### UPGRADES & ENHANCEMENTS + +- Upgrade Istio to v1.4.8 + +## **Storage** + +### FEATURES + +- Support volume snapshot management +- Support storage capacity management +- Support volume monitoring + +## **Security** + +### FEATURES + +- Support LDAP and OAuth login +- Support custom workspace roles +- Support custom DevOps project roles +- Support access control across multiple clusters +- Support pod security context (#[1453](https://github.com/kubesphere/kubesphere/issues/1453)) + +### UPGRADES & ENHANCEMENTS + +- Simplify the role definition +- Optimize built-in roles + +### BUG FIXES + +- Fix the issue of login failure due to node clock skew + +## **Globalization** + +### FEATURES + +- Add support for new languages in the web console, including Spanish and Traditional Chinese + +## **User Experience** + +### FEATURES + +- Add support for history record viewing in Toolbox. Users can re-visit the Clusters/Workspaces/Projects/DevOps Projects that they recently visited, which can also be launched through shortcut keys + +### UPGRADES & ENHANCEMENTS + +- Refactor global navigation +- Refactor breadcrumbs in detail pages +- Refactor data watching in the resources list +- Simplify project creation +- Refactor composing application creation, and support creating a composing application through YAML +- Support workload revision through YAML +- Optimize the display of log query results +- Refactor app store deployment form +- Support helm chart schema (#[schema-files](https://helm.sh/docs/topics/charts/#schema-files)) + +### BUG FIXES + +- Fix the error when editing ingress annotations (#[1931](https://github.com/kubesphere/kubesphere/issues/1931)) +- Fix container probes when editing in workload edit template modal +- Fix XSS security problems of the server-side templates \ No newline at end of file diff --git a/content/en/docs/v3.4/release/release-v310.md b/content/en/docs/v3.4/release/release-v310.md new file mode 100644 index 000000000..4028daeb7 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v310.md @@ -0,0 +1,175 @@ +--- +title: "Release Notes for 3.1.0" +keywords: "Kubernetes, KubeSphere, release notes" +description: "KubeSphere Release Notes for 3.1.0" +linkTitle: "Release Notes - 3.1.0" +weight: 18300 +--- + +## How to Install v3.1.0 + +- [Install KubeSphere v3.1.0 on Linux](https://github.com/kubesphere/kubekey) +- [Install KubeSphere v3.1.0 on an existing Kubernetes cluster](https://github.com/kubesphere/ks-installer) + +## New Features and Enhancements + +### Multi-cluster management + +- Simplified the steps to import Member Clusters with configuration validation (for example, `jwtSecret`) added. ([#3232](https://github.com/kubesphere/kubesphere/issues/3232)) +- Refactored the cluster controller and optimized the logic. ([#3234](https://github.com/kubesphere/kubesphere/issues/3234)) +- Upgraded the built-in web Kubectl, the version of which is now consistent with your Kubernetes cluster version. ([#3103](https://github.com/kubesphere/kubesphere/issues/3103)) +- Support customized resynchronization period of cluster controller. ([#3213](https://github.com/kubesphere/kubesphere/issues/3213)) +- Support lightweight installation of Member Clusters without components such as Redis and OpenLDAP. ([#3056](https://github.com/kubesphere/kubesphere/issues/3056)) +- Support high availability of Tower agent and server. ([#31](https://github.com/kubesphere/tower/issues/31)) + +### KubeEdge integration + +You can now enable KubeEdge in your cluster and manage edge nodes on the KubeSphere console. ([#3070](https://github.com/kubesphere/kubesphere/issues/3070)) + +- Support the installation of both cloud and edge modules of KubeEdge. +- Support adding KubeEdge through the KubeSphere console. +- Support the deployment of workloads on edge nodes. +- The logs and monitoring data of edge nodes can be collected. +- The network of edge nodes can be configured automatically as they join or leave a cluster. +- Taints can be added automatically as an edge node joins your cluster. +- You can use `nodeAffinity` to prevent cloud workloads (for example, DaemonSets) from being deployed to edge nodes. ([#1295](https://github.com/kubesphere/ks-installer/pull/1295), [#1297](https://github.com/kubesphere/ks-installer/pull/1297) and [#1300](https://github.com/kubesphere/ks-installer/pull/1300)) + +### Authorization and authentication management +- Added ServiceAccount management. ([#3211](https://github.com/kubesphere/kubesphere/issues/3211)) +- Improved the LDAP authentication plugin and added support for LDAPS and search filtering. ([#2970](https://github.com/kubesphere/kubesphere/issues/2970) and [#3766](https://github.com/kubesphere/kubesphere/issues/3766)) +- Improved the identify provider plugin and simplified the configuration of identify providers. ([#2970](https://github.com/kubesphere/kubesphere/issues/2970)) +- New users now see a prompt to change the old password when first logging in to KubeSphere. +- New users now need to confirm account information when logging in to KubeSphere through a third party. +- Support [CAS](https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol-Specification.html) as an available identity provider. ([#3047](https://github.com/kubesphere/kubesphere/issues/3047)) +- Support [OIDC](https://openid.net/specs/openid-connect-core-1_0.html) as an available identity provider. ([#2941](https://github.com/kubesphere/kubesphere/issues/2941)) +- Support IDaaS (Alibaba Cloud Identity as a Service) as an available identity provider. ([#2997](https://github.com/kubesphere/kubesphere/pull/2997)) + + +### Multi-tenant management +- Users now can configure departments in a workspace and assign users to the department. All users in the department can have the same role in a project or DevOps project. ([#2940](https://github.com/kubesphere/kubesphere/issues/2940)) +- Support workspace quotas which are used to manage resource usage of a workspace. ([#2939](https://github.com/kubesphere/kubesphere/issues/2939)) + +### Network + +- Added Kube-OVN. +- Support Calico IP pool management. ([#3057](https://github.com/kubesphere/kubesphere/issues/3057)) +- Support visual network topology. ([#3061](https://github.com/kubesphere/kubesphere/issues/3061) and [#583](https://github.com/kubesphere/kubesphere/issues/583)) +- A static IP address can be assigned to a Deployment now. ([#3058](https://github.com/kubesphere/kubesphere/issues/3058)) + +### Observability + +- Improved the current method of Prometheus integration. ([#3068](https://github.com/kubesphere/kubesphere/issues/3068) and [#1164](https://github.com/kubesphere/ks-installer/pull/1164); [guide](/docs/v3.3/faq/observability/byop/)) +- Added Thanos Ruler (Thanos v0.18.0) for the new alerting function. +- Upgraded Prometheus to v2.26.0. +- Upgraded Prometheus Operator to v0.42.1. +- Upgraded kube-state-metrics to v1.9.7. +- Upgraded metrics-server to v0.4.2. +- Upgraded Notification Manager to v1.0.0. ([Releases](https://github.com/kubesphere/notification-manager/releases)) +- Upgraded FluentBit Operator to v0.5.0. ([Releases](https://github.com/kubesphere/fluentbit-operator/releases)) +- Upgraded FluentBit to v1.6.9. +- Upgraded KubeEvents to v0.2.0. +- Upgraded Kube-Auditing to v0.1.2. + +#### Monitoring + +- Support configurations of ServiceMonitors on the KubeSphere console. ([#1031](https://github.com/kubesphere/console/pull/1301)) +- Support PromQL auto-completion and syntax highlighting. ([#1307](https://github.com/kubesphere/console/pull/1307)) +- Support customized monitoring at the cluster level. ([#3193](https://github.com/kubesphere/kubesphere/pull/3193)) +- Changed the HTTP ports of kube-scheduler and kube-controller-manager from `10251` and `10252` to the HTTPS ports of `10259` and `10257` respectively for data scraping. ([#1367](https://github.com/kubesphere/ks-installer/pull/1367)) + +#### Alerting + +- Prometheus-style alerting rules can be managed and configured now. ([#3181](https://github.com/kubesphere/kubesphere/pull/3181)) +- Support alerting rules at the platform level and project level. ([#3181](https://github.com/kubesphere/kubesphere/pull/3181)) +- Support real-time display of alerting rule status. ([#3181](https://github.com/kubesphere/kubesphere/pull/3181)) + +#### Notification management + +- Added new notification channels on the console including DingTalk, WeCom, Slack and Webhook to receive notifications. ([#3066](https://github.com/kubesphere/kubesphere/issues/3066)) + +#### Logging + +- Logs can be exported to [Loki](https://github.com/kubesphere/fluentbit-operator/blob/master/docs/plugins/output/loki.md) now. ([#39](https://github.com/kubesphere/fluentbit-operator/pull/39)) +- Support kubelet, Docker, and containerd log collection. ([#38](https://github.com/kubesphere/fluentbit-operator/pull/38)) +- Support [auditd](https://github.com/kubesphere/fluentbit-operator#auditd) log collection. ([#45](https://github.com/kubesphere/fluentbit-operator/pull/45)) + +### DevOps + +- Improved the error message of pipeline cron text. ([#2919](https://github.com/kubesphere/kubesphere/issues/2919)) +- Improved the interactive experience of creating pipelines. ([#1283](https://github.com/kubesphere/console/issues/1283)) +- Improved S2I error messages. ([#140](https://github.com/kubesphere/s2ioperator/issues/140)) +- Upgraded Jenkins to 2.249.1. ([#2618](https://github.com/kubesphere/kubesphere/issues/2618)) +- Added an approval mechanism for pipelines. Accounts with necessary permissions can review pipelines and approve them. ([#2483](https://github.com/kubesphere/kubesphere/issues/2483) and [#3006](https://github.com/kubesphere/kubesphere/issues/3006)) +- Multiple pipelines can be started and run at the same time. ([#1811](https://github.com/kubesphere/kubesphere/issues/1811)) +- The pipeline status can be viewed on the DevOps project **Pipelines** page. ([#3007](https://github.com/kubesphere/kubesphere/issues/3007)) +- Pipelines can be triggered by tags now. ([#3051](https://github.com/kubesphere/kubesphere/issues/3051)) +- Support pipeline cloning. ([#3053](https://github.com/kubesphere/kubesphere/issues/3053)) +- Support GitLab multi-branch pipelines. ([#3100](https://github.com/kubesphere/kubesphere/issues/3100)) +- Support S2I Webhook. ([#6](https://github.com/kubesphere/s2ioperator/issues/6)) +- Jenkins in KubeSphere is now deployed as a distribution ([#2182](https://github.com/kubesphere/kubesphere/issues/2182)). + +### App Store and apps + +- The reason for app template deployment failure is now available for check. ([#3036](https://github.com/kubesphere/kubesphere/issues/3036), [#3001](https://github.com/kubesphere/kubesphere/issues/3001) and [#2951](https://github.com/kubesphere/kubesphere/issues/2951)) +- Support batch deleting of app templates. +- Support editing of deployed app templates. +- A new built-in app [XenonDB](https://github.com/radondb/xenondb) is now available in the App Store. Based on MySQL, it is an open-source tool that provides high availability cluster solutions. + +### Microservices governance + +- The KubeSphere console now displays the traffic direction of microservices in composing apps. ([#3153](https://github.com/kubesphere/kubesphere/issues/3153)) +- Support Kiali. Users can now manage Istio directly through Kiali. ([#3106](https://github.com/kubesphere/kubesphere/issues/3106)) +- Support NGINX Ingress Gateway monitoring with NGINX Ingress Controller metrics added. ([#1205](https://github.com/kubesphere/ks-installer/pull/1205)) +- A route can be added now when an app is created. ([#1426](https://github.com/kubesphere/console/issues/1426)) +- Upgraded Istio to 1.6.10. ([#3326](https://github.com/kubesphere/kubesphere/issues/3236)) + +### Metering and billing + +- Users now can see resource consumption of different resources at different levels, such as clusters, workspaces, and apps. ([#3062](https://github.com/kubesphere/kubesphere/issues/3062)) +- The resource price can be set in a ConfigMap to provide billing information of resources on the console. + +### KubeSphere console UI + +- Improved homepage loading. +- Improved pipeline configurations on graphical editing panels. +- Improved error messages of pipeline status. +- Improved the way code repositories are filtered. +- Improved the configuration of node scheduling policies. +- Improved deployment configurations. +- Relocated the built-in web kubectl to a separate page. + +## Major Technical Adjustments + +- Upgraded Kubernetes version dependencies from v1.17 to v1.18. ([#3274](https://github.com/kubesphere/kubesphere/issues/3274)) +- Upgraded the Prometheus client_golang version dependency to v1.5.1 and Prometheus version dependency to v1.8.2. ([#3097](https://github.com/kubesphere/kubesphere/pull/3097)) +- Refactored OpenPitrix based on CRDs and fixed some issues caused by the original architecture. ([#3036](https://github.com/kubesphere/kubesphere/issues/3036), [#3001](https://github.com/kubesphere/kubesphere/issues/3001), [#2995](https://github.com/kubesphere/kubesphere/issues/2995), [#2981](https://github.com/kubesphere/kubesphere/issues/2981), [#2954](https://github.com/kubesphere/kubesphere/issues/2954), [#2951](https://github.com/kubesphere/kubesphere/issues/2951), [#2783](https://github.com/kubesphere/kubesphere/issues/2783), [#2713](https://github.com/kubesphere/kubesphere/issues/2713), [#2700](https://github.com/kubesphere/kubesphere/issues/2700) and [#1903](https://github.com/kubesphere/kubesphere/issues/1903)) +- Refactored the previous alerting system with old alerting rules deprecated and removed its dependency on MySQL, Redis, etcd and other components. The new alerting system works based on Thanos Ruler and the build-in rules of Prometheus. Old alerting rules in KubeSphere v3.0.0 will be automatically changed to new alerting rules in KubeSphere v3.1.0 after upgrading. +- Refactored the notification system and removed its dependency on MySQL, Redis, etcd and other components. Notification channels are now configured for the entire cluster based on [Notification Manager](https://github.com/kubesphere/notification-manager/) in CRDs. In a multi-cluster architecture, if a notification channel is set for the Host cluster, it works for all Member Clusters. + +## Deprecated or Removed Features + +- The legacy alerting and notification system dependent on MySQL, Redis, etcd and other components is replaced by the new alerting and notification function. +- Changed the container terminal WebSocket API. ([#3041](https://github.com/kubesphere/kubesphere/issues/3041)) + +## Bug Fixes +- Fixed account login failures. ([#3132](https://github.com/kubesphere/kubesphere/issues/3132) and [#3357](https://github.com/kubesphere/kubesphere/issues/3357)) +- Fixed an issue where ANSI colors were not supported in container logs. ([#1322](https://github.com/kubesphere/kubesphere/issues/3044)) +- Fixed an issue where the Istio-related monitoring data of a microservices-based app could not be scraped if its project name started with `kube`. ([#3126](https://github.com/kubesphere/kubesphere/issues/3162)) +- Fixed an issue where viewers at different levels could use the container terminal. ([#3041](https://github.com/kubesphere/kubesphere/issues/3041)) +- Fixed a deletion failure issue of cascade resources in a multi-cluster architecture. ([#2912](https://github.com/kubesphere/kubesphere/issues/2912)) +- Fixed the incompatibility issue with Kubernetes 1.19 and above. ([#2928](https://github.com/kubesphere/kubesphere/issues/2928) and [#2928](https://github.com/kubesphere/kubesphere/issues/2928)) +- Fixed the invalid button to view Service monitoring data. ([#1394](https://github.com/kubesphere/console/issues/1394)) +- Fixed an issue where the grayscale release Service name could not be the same as the app label. ([#3128](https://github.com/kubesphere/kubesphere/issues/3128)) +- Fixed an issue where the status of microservices-based app could not be updated. ([#3241](https://github.com/kubesphere/kubesphere/issues/3241)) +- Fixed an issue where a workspace in a Member Cluster would be deleted if its name was the same as a workspace in the Host Cluster. ([#3169](https://github.com/kubesphere/kubesphere/issues/3169)) +- Fixed the connection failure between clusters if agent connection is used. ([#3202](https://github.com/kubesphere/kubesphere/pull/3203)) +- Fixed a multi-cluster status display issue. ([#3135](https://github.com/kubesphere/kubesphere/issues/3135)) +- Fixed the workload deployment failure in DevOps pipelines. ([#3112](https://github.com/kubesphere/kubesphere/issues/3112)) +- Fixed an issue where the account with the `admin` role in a DevOps project could not download artifacts. ([#3088](https://github.com/kubesphere/kubesphere/issues/3083)) +- Fixed an issue of DevOps pipeline creation failure. ([#3105](https://github.com/kubesphere/kubesphere/issues/3105)) +- Fixed an issue of triggering pipelines in a multi-cluster architecture. ([#2626](https://ask.kubesphere.io/forum/d/2626-webhook-jenkins)) +- Fixed an issue of data loss when a pipeline was edited. ([#1270](https://github.com/kubesphere/console/issues/1270)) +- Fixed a display issue of **Docker Container Register Credentials**. ([#1269](https://github.com/kubesphere/console/issues/1269)) +- Fixed a localization issue of Chinese unit in the code analysis result. ([#1278](https://github.com/kubesphere/console/issues/1278)) +- Fixed a display issue caused by Boolean values in Jenkinsfiles. ([#3043](https://github.com/kubesphere/kubesphere/issues/3043)) +- Fixed a display issue on the **Storage Management** page caused by the lack of `StorageClassName` in a PVC. ([#1109](https://github.com/kubesphere/ks-installer/issues/1109)) diff --git a/content/en/docs/v3.4/release/release-v311.md b/content/en/docs/v3.4/release/release-v311.md new file mode 100644 index 000000000..7a7908ccf --- /dev/null +++ b/content/en/docs/v3.4/release/release-v311.md @@ -0,0 +1,168 @@ +--- +title: "Release Notes for 3.1.1" +keywords: "Kubernetes, KubeSphere, release notes" +description: "KubeSphere Release Notes for 3.1.1" +linkTitle: "Release Notes - 3.1.1" +weight: 18200 +--- + +## User Experience + +### Enhancements + +- Add the function of deleting related resources in batches during workload deletion. [kubesphere/console#1933](https://github.com/kubesphere/console/pull/1933) +- Optimize dialog boxes. [kubesphere/console#2016](https://github.com/kubesphere/console/pull/2016) +- Add the container terminal function to projects in the `system-workspace` workspace. [kubesphere/console#1921](https://github.com/kubesphere/console/pull/1921) + +### Bug Fixes + +- Remove the function of editing external network access of headless Services on the Service management page. [kubesphere/console#2055](https://github.com/kubesphere/console/issues/2055) +- Fix the incorrect environment variable placeholders displayed in workload creation. [kubesphere/console#2008](https://github.com/kubesphere/console/pull/2008) +- Fix an issue where the login page is not displayed when users log out from certain pages. [kubesphere/console#2009](https://github.com/kubesphere/console/pull/2009) +- Fix an issue on the Pod template editing page, where the protocol drop-down list is not completely displayed. [kubesphere/console#1944](https://github.com/kubesphere/console/pull/1944) +- Fix a probe format verification issue in workload creation. [kubesphere/console#1941](https://github.com/kubesphere/console/pull/1941) +- Fix the incorrect DevOps project list displayed on the workspace member details page. [#1936](https://github.com/kubesphere/console/pull/1936) +- Fix incorrect and missing UI text. [kubesphere/console#1879](https://github.com/kubesphere/console/pull/1879) [kubesphere/console#1880](https://github.com/kubesphere/console/pull/1880) [kubesphere/console#1895](https://github.com/kubesphere/console/pull/1895) + +## Observability + +### Enhancements + +- Optimize port format restrictions in notification settings. [#1885](https://github.com/kubesphere/console/pull/1885) +- Add the function of specifying an existing Prometheus stack during installation. [#1528](https://github.com/kubesphere/ks-installer/pull/1528) + +### Bug Fixes + +- Fix the mail server synchronization error. [#1969](https://github.com/kubesphere/console/pull/1969) +- Fix an issue where the notification manager is reset after installer restart. [#1564](https://github.com/kubesphere/ks-installer/pull/1564) +- Fix an issue where the alerting policy cannot be deleted after the monitored object is deleted. [#2045](https://github.com/kubesphere/console/pull/2045) +- Add a default template for monitoring resource creation. [#2029](https://github.com/kubesphere/console/pull/2029) +- Fix an issue where containers display only outdated logs. [#1972](https://github.com/kubesphere/console/issues/1972) +- Fix the incorrect timestamp in alerting information. [#1978](https://github.com/kubesphere/console/pull/1978) +- Optimize parameter rules in alerting policy creation. [#1958](https://github.com/kubesphere/console/pull/1958) +- Fix an issue in custom monitoring, where metrics are not completely displayed due to the incorrect height of the view area. [#1989](https://github.com/kubesphere/console/pull/1989) +- Adjust the limits of the node exporter and kube-state-metrics. [#1537](https://github.com/kubesphere/ks-installer/pull/1537) +- Adjust the selector of the etcdHighNumberOfFailedGRPCRequests rule to prevent incorrect etcd alerts. [#1540](https://github.com/kubesphere/ks-installer/pull/1540) +- Fix an issue during system upgrade, where the events ruler component is not upgraded to the latest version. [#1594](https://github.com/kubesphere/ks-installer/pull/1594) +- Fix bugs of the kube_node_status_allocatable_memory_bytes and kube_resourcequota selectors. [#1560](https://github.com/kubesphere/ks-installer/pull/1560) + +## Service Mesh + +### Enhancements + +- Add a time range selector to the Tracing tab. [#2022](https://github.com/kubesphere/console/pull/2022) + +### Bug Fixes + +- Fix an issue where the Tracing tab is incorrectly displayed. [kubesphere/console#1890](https://github.com/kubesphere/console/pull/1890) + +## DevOps + +### Enhancements + +- Add the function of filtering branches by branch name in GitLab multi-branch pipelines. [kubesphere/console#2077](https://github.com/kubesphere/console/pull/2077) +- Rename the **Rerun** button on the b2i page to **Run**. [kubesphere/console#1981](https://github.com/kubesphere/console/pull/1981) + +### Bug Fixes + +- Fix an issue where credential status cannot be synchronized. [kubesphere/console#1956](https://github.com/kubesphere/console/pull/1956) +- Fix incorrect image tags in CI automatic image pushing. [kubesphere/console#2037](https://github.com/kubesphere/console/pull/2037) +- Fix an issue on the pipeline details page, where users cannot return to the previous page. [kubesphere/console#1996](https://github.com/kubesphere/console/pull/1996) +- Fix the inconsistent dialog box names of the image builder. [kubesphere/console#1922](https://github.com/kubesphere/console/pull/1922) +- Fix an issue in DevOps projects, where the updates are reset when kubeconfig credentials are created. [kubesphere/console#1990](https://github.com/kubesphere/console/pull/1990) +- Fix incorrect trusted users in multi-branch pipelines. [kubesphere/console#1987](https://github.com/kubesphere/console/pull/1987) +- Fix an issue in DevOps project pipelines, where stage labels are reset when other settings are changed but not saved. [kubesphere/console#1979](https://github.com/kubesphere/console/pull/1979) +- Fix the incorrect shell and labels displayed in pipelines. [kubesphere/console#1970](https://github.com/kubesphere/console/pull/1970) +- Fix incorrect information displayed in the pipeline basic information dialog box. [kubesphere/console#1955](https://github.com/kubesphere/console/pull/1955) +- Fix the API error generated when multi-branch pipelines are run. [kubesphere/console#1954](https://github.com/kubesphere/console/pull/1954) +- Fix an issue in pipelines, where webhook pushing settings do not take effect. [kubesphere/console#1953](https://github.com/kubesphere/console/pull/1953) +- Optimize the UI text of the drag-and-drop function in the pipeline editor. [kubesphere/console#1949](https://github.com/kubesphere/console/pull/1949) +- Add default build environment settings for service build from source code. [kubesphere/console#1993](https://github.com/kubesphere/console/pull/1993) + +## Authentication and Authorization + +### Bug Fixes + +- Fix the incorrect last login time of users. [kubesphere/console#1881](https://github.com/kubesphere/console/pull/1881) +- Fix an issue in workspaces, where the `admin` user cannot view resource quotas. [kubesphere/ks-installer#1551](https://github.com/kubesphere/ks-installer/pull/1551) [kubesphere/console#2062](https://github.com/kubesphere/console/pull/2062) +- Fix an issue where project members cannot connect to container terminals. [kubesphere/console#2002](https://github.com/kubesphere/console/pull/2002) +- Fix an issue where the administrator cannot be specified when a project is assigned to a workspace. [kubesphere/console#1961](https://github.com/kubesphere/console/pull/1961) +- Fix the duplicate permission names in workspace role creation. [kubesphere/console#1945](https://github.com/kubesphere/console/pull/1945) + +## Multi-tenant Management + +### Bug Fixes + +- Fix an issue where deleted roles can be associated with user groups. [#1899](https://github.com/kubesphere/console/pull/1899) [#3897](https://github.com/kubesphere/kubesphere/pull/3897) +- Fix an issue where deletion of long usernames can cause system collapse. [kubesphere/ks-installer#1450](https://github.com/kubesphere/ks-installer/pull/1450) [kubesphere/kubesphere#3796](https://github.com/kubesphere/kubesphere/pull/3796) +- Fix an error generated when project roles are bound to user groups. [kubesphere/console#1967](https://github.com/kubesphere/console/pull/1967) +- Fix incorrect workspace quotas displayed in multi-cluster environments. [kubesphere/console#2013](https://github.com/kubesphere/console/pull/2013) + +## Multi-cluster Management + +### Enhancements + +- Optimize the error message generated when the configuration of a member cluster is incorrect. [kubesphere/console#2084](https://github.com/kubesphere/console/pull/2084) [kubesphere/console#1965](https://github.com/kubesphere/console/pull/1965) + +### Bug Fixes + +- Fix an issue where node labels in member clusters cannot be obtained. [kubesphere/console#1927](https://github.com/kubesphere/console/pull/1927) +- Fix an issue on the project list page, where multi-cluster projects are not correctly identified. [kubesphere/console#2059](https://github.com/kubesphere/console/pull/2059) +- Fix the incorrect gateway status displayed in multi-cluster projects. [kubesphere/console#1939](https://github.com/kubesphere/console/pull/1939) + +## Metering and Billing + +### Enhancements + +- Optimize the metering and billing UI. [#1896](https://github.com/kubesphere/console/pull/1896) +- Change the color of a button on the metering and billing page. [#1934](https://github.com/kubesphere/console/pull/1934) + +### Bug Fixes + +- Fix an issue where OpenPitrix resources are not included in metering and billing. [#3871](https://github.com/kubesphere/kubesphere/pull/3871) +- Fix an error generated in metering and billing for the `system-workspace` workspace. [#2083](https://github.com/kubesphere/console/pull/2083) +- Fix an issue where projects are not completely displayed in the multi-cluster metering and billing list. [#2066](https://github.com/kubesphere/console/pull/2066) +- Fix an error on the billing page generated when a dependent cluster is not loaded. [#2054](https://github.com/kubesphere/console/pull/2054) + +## App Store + +### Enhancements + +- Optimize the UI layout and text on the app template creation page. [kubesphere/console#2012](https://github.com/kubesphere/console/pull/2012) [kubesphere/console#2063](https://github.com/kubesphere/console/pull/2063) +- Optimize the app template import function. [kubesphere/openpitrix-jobs#18](https://github.com/kubesphere/openpitrix-jobs/pull/18) +- Add the RadonDB PostgreSQL app to the App Store. [kubesphere/openpitrix-jobs#17](https://github.com/kubesphere/openpitrix-jobs/pull/17) + +## Security + +### Enhancements + +- Switch the branch of jwt-go to fix CVE-2020-26160. [#3991](https://github.com/kubesphere/kubesphere/pull/3991) +- Upgrade the Protobuf version to v1.3.2 to fix CVE-2021-3121. [#3944](https://github.com/kubesphere/kubesphere/pull/3944) +- Upgrade the Crypto version to the latest version to fix CVE-2020-29652. [#3997](https://github.com/kubesphere/kubesphere/pull/3997) +- Remove the `yarn.lock` file to prevent incorrect CVE bug reports. [#2024](https://github.com/kubesphere/console/pull/2024) + +### Bug Fixes + +- Fix an issue where container terminal can be accessed without authorization. [kubesphere/kubesphere#3956](https://github.com/kubesphere/kubesphere/pull/3956) + +## Storage + +### Enhancements + +- Improve the concurrency performance of the S3 uploader. [#4011](https://github.com/kubesphere/kubesphere/pull/4011) +- Add preset CSI Provisioner CR settings. [#1536](https://github.com/kubesphere/ks-installer/pull/1536) + +### Bug Fixes + +- Remove the invalid function of automatic storage class detection. [#3947](https://github.com/kubesphere/kubesphere/pull/3947) +- Fix incorrect storage resource units of project quotas.[#3973](https://github.com/kubesphere/kubesphere/issues/3973) + +## KubeEdge Integration + +### Enhancements + +- Add support for KubeEdge v1.6.2. [#1527](https://github.com/kubesphere/ks-installer/pull/1527) [#1542](https://github.com/kubesphere/ks-installer/pull/1542) + +### Bug Fixes + +- Fix the incorrect `advertiseAddress` setting of the KubeEdge CloudCore component. [#1561](https://github.com/kubesphere/ks-installer/pull/1561) \ No newline at end of file diff --git a/content/en/docs/v3.4/release/release-v320.md b/content/en/docs/v3.4/release/release-v320.md new file mode 100644 index 000000000..6bdfd0402 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v320.md @@ -0,0 +1,177 @@ +--- +title: "Release Notes for 3.2.0" +keywords: "Kubernetes, KubeSphere, release notes" +description: "KubeSphere Release Notes for 3.2.0" +linkTitle: "Release Notes - 3.2.0" +weight: 18100 +--- + +## Multi-tenancy & Multi-cluster + +### New Features + +- Add support for setting the host cluster name in multi-cluster scenarios, which defaults to `host`. ([#4211](https://github.com/kubesphere/kubesphere/pull/4211), [@yuswift](https://github.com/yuswift)) +- Add support for setting the cluster name in single-cluster scenarios. ([#4220](https://github.com/kubesphere/kubesphere/pull/4220), [@yuswift](https://github.com/yuswift)) +- Add support for initializing the default cluster name by using globals.config. ([#2283](https://github.com/kubesphere/console/pull/2283), [@harrisonliu5](https://github.com/harrisonliu5)) +- Add support for scheduling Pod replicas across multiple clusters when creating a Deployment. ([#2191](https://github.com/kubesphere/console/pull/2191), [@weili520](https://github.com/weili520)) +- Add support for changing cluster weights on the project details page. ([#2192](https://github.com/kubesphere/console/pull/2192), [@weili520](https://github.com/weili520)) + +### Bug Fixes + +- Fix an issue in the **Create Deployment** dialog box in **Cluster Management**, where a multiple-cluster project can be selected by directly entering the project name. ([#2125](https://github.com/kubesphere/console/pull/2125), [@fuchunlan](https://github.com/fuchunlan)) +- Fix an error that occurs when workspace or cluster basic information is edited. ([#2188](https://github.com/kubesphere/console/pull/2188), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) +- Remove information about deleted clusters on the **Basic Information** page of the host cluster. ([#2211](https://github.com/kubesphere/console/pull/2211), [@fuchunlan](https://github.com/fuchunlan)) +- Add support for sorting Services and editing Service settings in multi-cluster projects. ([#2167](https://github.com/kubesphere/console/pull/2167), [@harrisonliu5](https://github.com/harrisonliu5)) +- Refactor the gateway feature of multi-cluster projects. ([#2275](https://github.com/kubesphere/console/pull/2275), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix an issue where multi-cluster projects cannot be deleted after the workspace is deleted. ([#4365](https://github.com/kubesphere/kubesphere/pull/4365), [@wansir](https://github.com/wansir)) + +## Observability + +### New Features + +- Add support for HTTPS communication with Elasticsearch. ([#4176](https://github.com/kubesphere/kubesphere/pull/4176), [@wanjunlei](https://github.com/wanjunlei)) +- Add support for setting GPU types when scheduling GPU workloads. ([#4225](https://github.com/kubesphere/kubesphere/pull/4225), [@zhu733756](https://github.com/zhu733756)) +- Add support for validating notification settings. ([#4216](https://github.com/kubesphere/kubesphere/pull/4216), [@wenchajun](https://github.com/wenchajun)) +- Add support for importing Grafana dashboards by specifying a dashboard URL or by uploading a Grafana dashboard JSON file. KubeSphere automatically converts Grafana dashboards into KubeSphere cluster dashboards. ([#4194](https://github.com/kubesphere/kubesphere/pull/4194), [@zhu733756](https://github.com/zhu733756)) +- Add support for creating Grafana dashboards in **Custom Monitoring**. ([#2214](https://github.com/kubesphere/console/pull/2214), [@harrisonliu5](https://github.com/harrisonliu5)) +- Optimize the **Notification Configuration** feature. ([#2261](https://github.com/kubesphere/console/pull/2261), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) +- Add support for setting a GPU limit in the **Edit Default Container Quotas** dialog box. ([#2253](https://github.com/kubesphere/console/pull/2253), [@weili520](https://github.com/weili520)) +- Add a default GPU monitoring dashboard.（[#2580](https://github.com/kubesphere/console/pull/2580), [@harrisonliu5](https://github.com/harrisonliu5)） +- Add the **Leader** tag to the etcd leader on the etcd monitoring page. ([#2445](https://github.com/kubesphere/console/pull/2445), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) + +### Bug Fixes + +- Fix the incorrect Pod information displayed on the **Alerting Messages** page and alerting policy details page. ([#2215](https://github.com/kubesphere/console/pull/2215), [@harrisonliu5](https://github.com/harrisonliu5)) + +## Authentication & Authorization + +### New Features + +- Add a built-in OAuth 2.0 server that supports OpenID Connect. ([#3525](https://github.com/kubesphere/kubesphere/pull/3525), [@wansir](https://github.com/wansir)) +- Remove information confirmation required when an external identity provider is used. ([#4238](https://github.com/kubesphere/kubesphere/pull/4238), [@wansir](https://github.com/wansir)) + +### Bug Fixes + +- Fix incorrect source IP addresses in the login history. ([#4331](https://github.com/kubesphere/kubesphere/pull/4331), [@wansir](https://github.com/wansir)) + +## Storage + +### New Features + +- Change the parameters that determine whether volume clone, volume snapshot, and volume expansion are allowed. ([#2199](https://github.com/kubesphere/console/pull/2199), [@weili520](https://github.com/weili520)) +- Add support for setting the volume binding mode during storage class creation. ([#2220](https://github.com/kubesphere/console/pull/2220), [@weili520](https://github.com/weili520)) +- Add the volume instance management feature. ([#2226](https://github.com/kubesphere/console/pull/2226), [@weili520](https://github.com/weili520)) +- Add support for multiple snapshot classes. Users are allowed to select a snapshot type when creating a snapshot. ([#2218](https://github.com/kubesphere/console/pull/2218), [@weili520](https://github.com/weili520)) + +### Bug Fixes + +- Change the volume access mode options on the **Storage Settings** tab page. ([#2348](https://github.com/kubesphere/console/pull/2348), [@live77](https://github.com/live77)) + +## Network + +### New Features + +- Add the Route sorting, routing rule editing, and annotation editing features on the Route list page. ([#2165](https://github.com/kubesphere/console/pull/2165), [@harrisonliu5](https://github.com/harrisonliu5)) +- Refactor the cluster gateway and project gateway features. ([#2262](https://github.com/kubesphere/console/pull/2262), [@harrisonliu5](https://github.com/harrisonliu5)) +- Add the service name auto-completion feature in routing rule creation. ([#2196](https://github.com/kubesphere/console/pull/2196), [@wengzhisong-hz](https://github.com/wengzhisong-hz)) +- DNS optimizations for ks-console: + - Use the name of the ks-apiserver Service directly instead of `ks-apiserver.kubesphere-system.svc` as the API URL. + - Add a DNS cache plugin (dnscache) for caching DNS results. ([#2435](https://github.com/kubesphere/console/pull/2435), [@live77](https://github.com/live77)) + +### Bug Fixes + +- Add a **Cancel** button in the **Enable Gateway** dialog box. ([#2245](https://github.com/kubesphere/console/pull/2245), [@weili520](https://github.com/weili520)) + +## Apps & App Store + +### New Features + +- Add support for setting a synchronization interval during app repository creation and editing. ([#2311](https://github.com/kubesphere/console/pull/2311), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) +- Add a disclaimer in the App Store. ([#2173](https://github.com/kubesphere/console/pull/2173), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) +- Add support for dynamically loading community-developed Helm charts into the App Store. ([#4250](https://github.com/kubesphere/kubesphere/pull/4250), [@xyz-li](https://github.com/xyz-li)) + +### Bug Fixes + +- Fix an issue where the value of `kubesphere_app_template_count` is always `0` when `GetKubeSphereStats` is called. ([#4130](https://github.com/kubesphere/kubesphere/pull/4130), [@Hanamichi](https://github.com/ks-ci-bohttps://github.com/x893675)) + +## DevOps + +### New Features + +- Set the system to hide the **Branch** column on the **Run Records** tab page when the current pipeline is not a multi-branch pipeline. ([#2379](https://github.com/kubesphere/console/pull/2379), [@live77](https://github.com/live77)) +- Add the feature of automatically loading Jenkins configurations from ConfigMaps. ([#75](https://github.com/kubesphere/ks-devops/pull/75), [@JohnNiang](https://github.com/JohnNiang)) +- Add support for triggering pipelines by manipulating CRDs instead of calling Jenkins APIs. ([#41](https://github.com/kubesphere/ks-devops/issues/41), [@rick](https://github.com/LinuxSuRen)) +- Add support for containerd-based pipelines. ([#171](https://github.com/kubesphere/ks-devops/pull/171), [@rick](https://github.com/LinuxSuRen)) +- Add Jenkins job metadata into pipeline annotations. ([#254](https://github.com/kubesphere/ks-devops/issues/254), [@JohnNiang](https://github.com/JohnNiang)) + +### Bug Fixes + +- Fix an issue where credential creation and update fails when the value length of a parameter is too long. ([#123](https://github.com/kubesphere/ks-devops/pull/123), [@shihh](https://github.com/shihaoH)) +- Fix an issue where ks-apiserver crashes when the **Run Records** tab page of a parallel pipeline is opened. ([#93](https://github.com/kubesphere/ks-devops/pull/93), [@JohnNiang](https://github.com/JohnNiang)) + +### Dependency Upgrades + +- Upgrade the version of Configuration as Code to 1.53. ([#42](https://github.com/kubesphere/ks-jenkins/pull/42), [@rick](https://github.com/LinuxSuRen)) + +## Installation + +### New Features + +- Add support for Kubernetes v1.21.5 and v1.22.1. ([#634](https://github.com/kubesphere/kubekey/pull/634), [@pixiake](https://github.com/pixiake)) +- Add support for automatically setting the container runtime. ([#738](https://github.com/kubesphere/kubekey/pull/738), [@pixiake](https://github.com/pixiake)) +- Add support for automatically updating Kubernetes certificates. ([#705](https://github.com/kubesphere/kubekey/pull/705), [@pixiake](https://github.com/pixiake)) +- Add support for installing Docker and conatinerd using a binary file. ([#657](https://github.com/kubesphere/kubekey/pull/657), [@pixiake](https://github.com/pixiake)) +- Add support for Flannel VxLAN and direct routing. ([#606](https://github.com/kubesphere/kubekey/pull/606), [@kinglong08](https://github.com/kinglong08)) +- Add support for deploying etcd using a binary file. ([#634](https://github.com/kubesphere/kubekey/pull/634), [@pixiake](https://github.com/pixiake)) +- Add an internal load balancer for deploying a high availability system. ([#567](https://github.com/kubesphere/kubekey/pull/567), [@24sama](https://github.com/24sama)) + +### Bug Fixes +- Fix a runtime.RawExtension serialization error. ([#731](https://github.com/kubesphere/kubekey/pull/731), [@pixiake](https://github.com/pixiake)) +- Fix the nil pointer error during cluster upgrade. ([#684](https://github.com/kubesphere/kubekey/pull/684), [@24sama](https://github.com/24sama)) +- Add support for updating certificates of Kubernetes v1.20.0 and later. ([#690](https://github.com/kubesphere/kubekey/pull/690), [@24sama](https://github.com/24sama)) +- Fix a DNS address configuration error. ([#637](https://github.com/kubesphere/kubekey/pull/637), [@pixiake](https://github.com/pixiake)) +- Fix a cluster creation error that occurs when no default gateway address exists. ([#661](https://github.com/kubesphere/kubekey/pull/661), [@liulangwa](https://github.com/liulangwa)) + +## User Experience +- Fix language mistakes and optimize wording. ([@Patrick-LuoYu](https://github.com/Patrick-LuoYu), [@Felixnoo](https://github.com/Felixnoo), [@serenashe](https://github.com/serenashe)) +- Fix incorrect function descriptions. ([@Patrick-LuoYu](https://github.com/Patrick-LuoYu), [@Felixnoo](https://github.com/Felixnoo), [@serenashe](https://github.com/serenashe)) +- Remove hard-coded and concatenated UI strings to better support UI localization and internationalization. ([@Patrick-LuoYu](https://github.com/Patrick-LuoYu), [@Felixnoo](https://github.com/Felixnoo), [@serenashe](https://github.com/serenashe)) +- Add conditional statements to display correct English singular and plural forms. ([@Patrick-LuoYu](https://github.com/Patrick-LuoYu), [@Felixnoo](https://github.com/Felixnoo), [@serenashe](https://github.com/serenashe)) +- Optimize the **Pod Scheduling Rules** area in the **Create Deployment** dialog box. ([#2170](https://github.com/kubesphere/console/pull/2170), [@qinyueshang](https://github.com/qinyueshang)) +- Fix an issue in the **Edit Project Quotas** dialog box, where the quota value changes to 0 when it is set to infinity. ([#2118](https://github.com/kubesphere/console/pull/2118), [@fuchunlan](https://github.com/fuchunlan)) +- Fix an issue in the **Create ConfigMap** dialog box, where the position of the hammer icon is incorrect when the data entry is empty. ([#2206](https://github.com/kubesphere/console/pull/2206), [@fuchunlan](https://github.com/fuchunlan)) +- Fix the incorrect default value of the time range drop-down list on the **Overview** page of projects. ([#2340](https://github.com/kubesphere/console/pull/2340), [@fuchunlan](https://github.com/fuchunlan)) +- Fix an error that occurs during login redirection, where redirection fails if the referer URL contains an ampersand (&). ([#2194](https://github.com/kubesphere/console/pull/2194), [@harrisonliu5](https://github.com/harrisonliu5)) +- Change **1 hours** to **1 hour** on the custom monitoring dashboard creation page. ([#2276](https://github.com/kubesphere/console/pull/2276), [@live77](https://github.com/live77)) +- Fix the incorrect Service types on the Service list page. ([#2178](https://github.com/kubesphere/console/pull/2178), [@xuliwenwenwen](https://github.com/xuliwenwenwen)) +- Fix the incorrect traffic data displayed in grayscale release job details. ([#2422](https://github.com/kubesphere/console/pull/2422), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix an issue in the **Edit Project Quotas** dialog box, where values with two decimal places and values greater than 8 cannot be set. ([#2127](https://github.com/kubesphere/console/pull/2127), [@weili520](https://github.com/weili520)) +- Allow the **About** dialog box to be closed by clicking other areas of the window. ([#2114](https://github.com/kubesphere/console/pull/2114), [@fuchunlan](https://github.com/fuchunlan)) +- Optimize the project title so that the cursor is changed into a hand when hovering over the project title. ([#2128](https://github.com/kubesphere/console/pull/2128), [@fuchunlan](https://github.com/fuchunlan)) +- Add support for creating ConfigMaps and Secrets in the **Environment Variables** area of the **Create Deployment** dialog box. ([#2227](https://github.com/kubesphere/console/pull/2227), [@harrisonliu5](https://github.com/harrisonliu5)) +- Add support for setting Pod annotations in the **Create Deployment** dialog box. ([#2129](https://github.com/kubesphere/console/pull/2129), [@harrisonliu5](https://github.com/harrisonliu5)) +- Allow domain names to start with an asterisk (*). ([#2432](https://github.com/kubesphere/console/pull/2432), [@wengzhisong-hz](https://github.com/wengzhisong-hz)) +- Add support for searching for Harbor images in the **Create Deployment** dialog box. ([#2132](https://github.com/kubesphere/console/pull/2132), [@wengzhisong-hz](https://github.com/wengzhisong-hz)) +- Add support for mounting volumes to init containers. ([#2166](https://github.com/kubesphere/console/pull/2166), [@Sigboom](https://github.com/Sigboom)) +- Remove the workload auto-restart feature in volume expansion. ([#4121](https://github.com/kubesphere/kubesphere/pull/4121), [@wenhuwang](https://github.com/wenhuwang)) + + +## APIs + +- Deprecate router API version v1alpha2. ([#4193](https://github.com/kubesphere/kubesphere/pull/4193), [@RolandMa1986](https://github.com/RolandMa1986)) +- Upgrade the pipeline API version from v2 to v3. ([#2323](https://github.com/kubesphere/console/pull/2323), [@harrisonliu5](https://github.com/harrisonliu5)) +- Change the Secret verification API. ([#2368](https://github.com/kubesphere/console/pull/2368), [@harrisonliu5](https://github.com/harrisonliu5)) +- Client credential is required for OAuth2 Token endpoint.（[#3525](https://github.com/kubesphere/kubesphere/pull/3525)，[@wansir](https://github.com/wansir)） + +## Component Changes + +- kubefed: v0.7.0 -> v0.8.1 +- prometheus-operator: v0.42.1 -> v0.43.2 +- notification-manager: v1.0.0 -> v1.4.0 +- fluent-bit: v1.6.9 -> v1.8.3 +- kube-events: v0.1.0 -> v0.3.0 +- kube-auditing: v0.1.2 -> v0.2.0 +- istio: 1.6.10 -> 1.11.1 +- jaeger: 1.17 -> 1.27 +- kiali: v1.26.1 -> v1.38 +- KubeEdge: v1.6.2 -> 1.7.2 \ No newline at end of file diff --git a/content/en/docs/v3.4/release/release-v321.md b/content/en/docs/v3.4/release/release-v321.md new file mode 100644 index 000000000..d11d74b2e --- /dev/null +++ b/content/en/docs/v3.4/release/release-v321.md @@ -0,0 +1,46 @@ +--- +title: "Release Notes for 3.2.1" +keywords: "Kubernetes, KubeSphere, release notes" +description: "KubeSphere Release Notes for 3.2.1" +linkTitle: "Release Notes - 3.2.1" +weight: 18099 +--- + +## Enhancements and Bug Fixes + +### Enhancements + +- Add support for filtering Pods by status. ([#4434](https://github.com/kubesphere/kubesphere/pull/4434), [@iawia002](https://github.com/iawia002), [#2620](https://github.com/kubesphere/console/pull/2620), [@weili520](https://github.com/weili520)) +- Add a tip in the image builder creation dialog box, which indicates that containerd is not supported. ([#2734](https://github.com/kubesphere/console/pull/2734), [@weili520](https://github.com/weili520)) +- Add information about available quotas in the **Edit Project Quotas** dialog box. ([#2619](https://github.com/kubesphere/console/pull/2619), [@weili520](https://github.com/weili520)) + +### Bug Fixes + +- Change the password verification rules to prevent passwords without uppercase letters. ([#4481](https://github.com/kubesphere/kubesphere/pull/4481), [@live77](https://github.com/live77)) +- Fix a login issue, where a user from an LDAP identity provider cannot log in if information about the user does not exist on KubeSphere. ([#4436](https://github.com/kubesphere/kubesphere/pull/4436), [@RolandMa1986](https://github.com/RolandMa1986)) +- Fix an issue where cluster gateway metrics cannot be obtained. ([#4457](https://github.com/kubesphere/kubesphere/pull/4457), [@RolandMa1986](https://github.com/RolandMa1986)) +- Fix incorrect access modes displayed in the volume list. ([#2686](https://github.com/kubesphere/console/pull/2686), [@weili520](https://github.com/weili520)) +- Remove the **Update** button on the **Gateway Settings** page. ([#2608](https://github.com/kubesphere/console/pull/2608), [@weili520](https://github.com/weili520)) +- Fix a display error of the time range selection drop-down list. ([#2715](https://github.com/kubesphere/console/pull/2715), [@weili520](https://github.com/weili520)) +- Fix an issue where Secret data text is not displayed correctly when the text is too long. ([#2600](https://github.com/kubesphere/console/pull/2600), [@weili520](https://github.com/weili520)) +- Fix an issue where StatefulSet creation fails when a volume template is mounted. ([#2730](https://github.com/kubesphere/console/pull/2730), [@weili520](https://github.com/weili520)) +- Fix an issue where cluster gateway information fails to be obtained when the user does not have permission to view cluster information. ([#2695](https://github.com/kubesphere/console/pull/2695), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix an issue where status and run records of pipelines are not automatically updated. ([#2594](https://github.com/kubesphere/console/pull/2594), [@harrisonliu5](https://github.com/harrisonliu5)) +- Add a tip for the kubernetesDeploy pipeline step, which indicates that the step is about to be deprecated. ([#2660](https://github.com/kubesphere/console/pull/2660), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix an issue where HTTP registry addresses of image registry Secrets cannot be validated. ([#2795](https://github.com/kubesphere/console/pull/2795), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix the incorrect URL of the Harbor image. ([#2784](https://github.com/kubesphere/console/pull/2784), [@harrisonliu5](https://github.com/harrisonliu5)) +- Fix a display error of log search results. ([#2598](https://github.com/kubesphere/console/pull/2598), [@weili520](https://github.com/weili520)) +- Fix an error in the volume instance YAML configuration. ([#2629](https://github.com/kubesphere/console/pull/2629), [@weili520](https://github.com/weili520)) +- Fix incorrect available workspace quotas displayed in the **Edit Project Quotas** dialog box. ([#2613](https://github.com/kubesphere/console/pull/2613), [@weili520](https://github.com/weili520)) +- Fix an issue in the **Monitoring** dialog box, where the time range selection drop-down list does not function properly. ([#2722](https://github.com/kubesphere/console/pull/2722), [@weili520](https://github.com/weili520)) +- Fix incorrect available quotas displayed in the Deployment creation page. ([#2668](https://github.com/kubesphere/console/pull/2668), [@weili520](https://github.com/weili520)) +- Change the documentation address to [kubesphere.io](https://kubesphere.io/) and [kubesphere.com.cn](https://kubesphere.com.cn/). ([#2628](https://github.com/kubesphere/console/pull/2628), [@weili520](https://github.com/weili520)) +- Fix an issue where Deployment volume settings cannot be modified. ([#2656](https://github.com/kubesphere/console/pull/2656), [@weili520](https://github.com/weili520)) +- Fix an issue where the container terminal cannot be accessed when the browser language is not English, Simplified Chinese, or Traditional Chinese. ([#2702](https://github.com/kubesphere/console/pull/2702), [@weili520](https://github.com/weili520)) +- Fix incorrect volume status displayed in the Deployment editing dialog box. ([#2622](https://github.com/kubesphere/console/pull/2622), [@weili520](https://github.com/weili520)) +- Remove labels displayed on the credential details page. ([#2621](https://github.com/kubesphere/console/pull/2621), [@123liubao](https://github.com/123liubao)) +- Fix the problem caused by non-ASCII branch names. ([#399](https://github.com/kubesphere/ks-devops/pull/399)) +- Fix the wrong handling of the choice parameter in Pipeline. ([#378](https://github.com/kubesphere/ks-devops/pull/378)) +- Fix the problem that could not proceed or break the pipeline created by others. [#408](https://github.com/kubesphere/ks-devops/pull/408) +- Fix messy sequence of pipeline run records. [#394](https://github.com/kubesphere/ks-devops/pull/394) +- Fix pipeline triggered by non-admin user but still display "Started by user admin". [#384](https://github.com/kubesphere/ks-devops/pull/384) diff --git a/content/en/docs/v3.4/release/release-v330.md b/content/en/docs/v3.4/release/release-v330.md new file mode 100644 index 000000000..e191f555c --- /dev/null +++ b/content/en/docs/v3.4/release/release-v330.md @@ -0,0 +1,90 @@ +--- +title: "Release Notes for 3.3.0" +keywords: "Kubernetes, KubeSphere, Release Notes" +description: "KubeSphere 3.3.0 Release Notes" +linkTitle: "Release Notes - 3.3.0" +weight: 18098 +--- + +## DevOps +### Features +- Add the Continuous Deployment feature, which supports GitOps and uses Argo CD as the backend, and users can view the status of continuous deployments in real time. +- Add the allowlist feature on the **Basic Information** page of a DevOps project to restrict the target repository and deployment location for continuous deployments. +- Add support for importing and managing code repositories. +- Add support for built-in CRD-based pipeline templates and parameter customization. +- Add support for viewing pipeline events. + +## Storage +### Features + +- Add support for tenant-level storage class permission management. +- Add the volume snapshot content management and volume snapshot class management features. +- Add support for automatic restart of deployments and statefulsets after a PVC has been changed. +- Add the PVC auto expansion feature, which automatically expands PVCs when remaining capacity is insufficient. + +## Multi-tenancy and Multi-cluster +### Features +- Add a notification to remind users when the kubeconfig certificate of a cluster is about to expire. +- Add the kubesphere-config configmap, which provides the name of the current cluster. +- Add support for cluster-level member and role management. + +## Observability + +### Features +- Add process and thread monitoring metrics for containers. +- Add disk monitoring metrics that provide usage of each disk. +- Add support for importing Grafana templates to create custom monitoring dashboards of a namespace scope. +- Add support for defining separate data retention periods for container logs, resource events, and audit logs. + +### Enhancements & Updates +- Upgrade Alertmanager from v0.21.0 to v0.23.0. +- Upgrade Grafana from 7.4.3 to 8.3.3. +- Upgrade kube-state-metrics from v1.9.7 to v2.3.0. +- Upgrade node-exporter from v0.18.1 to v1.3.1. +- Upgrade Prometheus from v2.26.0 to v2.34.0. +- Upgrade Prometheus Operator from v0.43.2 to v0.55.1. +- Upgrade kube-rbac-proxy from v0.8.0 to v0.11.0. +- Upgrade configmap-reload from v0.3.0 to v0.5.0. +- Upgrade Thanos from v0.18.0 to v0.25.2. +- Upgrade kube-events from v0.3.0 to v0.4.0. +- Upgrade Fluent Bit Operator from v0.11.0 to v0.13.0. +- Upgrade Fluent Bit from v1.8.3 to v1.8.11. + +## KubeEdge Integration +### Features +- Add support for logging in to common cluster nodes and edge nodes from the KubeSphere web console. +### Enhancements & Updates +- Upgrade KubeEdge from v1.7.2 to v1.9.2. +- Remove EdgeWatcher. + +## Network +### Enhancements & Updates +- Integrate OpenELB with KubeSphere for exposing LoadBalancer services. +### Bug Fixes +- Fix an issue where the gateway of a project is not deleted after the project is deleted. +## App Store +### Bug Fixes +- Fix a ks-controller-manager crash caused by Helm controller NPE errors. + +## Authentication & Authorization +### Features +- Add support for manually disabling and enabling users. +## User Experience +- Add a prompt when the audit log of Kubernetes has been enabled. +- Add the lifecycle management feature for containers. +- Add support for creating container environment variables in batches from secrets and configmaps. +- Add a time range selector on the **Traffic Monitoring** tab page. +- Add a message in the **Audit Log Search** dialog box, which prompts users to enable the audit logs feature. +- Add more Istio parameters in `ClusterConfiguration`. +- Add support for more languages, for example, Turkish. +- Set the **Token** parameter on the webhook settings page as mandatory. +- Prevent passwords without uppercase letters set through the backend CLI. +- Fix an issue where no data is displayed on the **Traffic Management** and **Tracing** tab pages in a multi-cluster project. +- Fix an app installation failure, which occurs when users click buttons too fast. +- Fix an issue where container probes are still displayed after they are deleted. +- Fix an issue where statefulset creation fails when a volume is mounted to an init container. +- Prevent ks-apiserver and ks-controller-manager from restarting when the cluster configuration is changed. +- Optimize some UI texts. +- Optimize display of the service topology on the **Service** page. + +For more information about issues and contributors of KubeSphere 3.3.0, see [GitHub](https://github.com/kubesphere/kubesphere/blob/master/CHANGELOG/CHANGELOG-3.3.md). \ No newline at end of file diff --git a/content/en/docs/v3.4/release/release-v331.md b/content/en/docs/v3.4/release/release-v331.md new file mode 100644 index 000000000..375e08f94 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v331.md @@ -0,0 +1,42 @@ +--- +title: "Release Notes for 3.3.1" +keywords: "Kubernetes, KubeSphere, Release Notes" +description: "KubeSphere 3.3.1 Release Notes" +linkTitle: "Release Notes - 3.3.1" +weight: 18096 +--- + +## DevOps +### Enhancements & Updates + +- Add support for editing the kubeconfig binding mode on the pipeline UI. + +### Bug Fixes + +- Fix an issue where users fail to check the CI/CD template. +- Remove the `Deprecated` tag from the CI/CD template and replace `kubernetesDeploy` with `kubeconfig binding` at the deployment phase. + +## Network +### Bug Fixes + +- Fix an issue where users fail to create routing rules in IPv6 and IPv4 dual-stack environments. + +## Storage +### Bug Fixes + +- Set `hostpath` as a required option when users are mounting volumes. + + +## Authentication & Authorization +### Bug Fixes + +- Delete roles `users-manager` and `workspace-manager`. +- Add role `platform-self-provisioner`. +- Block some permissions of custom roles. + +## User Experience + +- Add support for changing the number of items displayed on each page of a table. +- Add support for batch stopping workloads. + +For more information about issues and contributors of KubeSphere 3.3.1, see [GitHub](https://github.com/kubesphere/kubesphere/blob/master/CHANGELOG/CHANGELOG-3.3.1.md). \ No newline at end of file diff --git a/content/en/docs/v3.4/release/release-v332.md b/content/en/docs/v3.4/release/release-v332.md new file mode 100644 index 000000000..1c80c0d92 --- /dev/null +++ b/content/en/docs/v3.4/release/release-v332.md @@ -0,0 +1,92 @@ +--- +title: "Release Notes for 3.3.2" +keywords: "Kubernetes, KubeSphere, Release Notes" +description: "KubeSphere 3.3.2 Release Notes" +linkTitle: "Release Notes - 3.3.2" +weight: 18095 +--- + +## DevOps + +### Enhancements & Upgrades + +- Add the latest GitHub Actions. +- Save the PipelineRun results to the configmap. +- Modify the Chinese description of the status of ArgoCD applications. +- Add more information to continuous deployment parameters. +- Add a link for PipelineRun in the aborted state. +- Add an ID column for PipelineRun, and the ID will be displayed when users run kubectl commands. +- Remove the queued state from PipelineRun. + +### Bug Fixes + +- Fix an issue where webhook configurations are missing after users change and save pipeline configurations. +- Fix an issue where downloading DevOps pipeline artifacts fails. +- Fix an issue where the image address does not match when a service is created by using a JAR/WAR file. +- Fix an issue where the status of PipelineRun changes from `Cancelled` to `Not-Running`. +- Fix the automatic cleaning behavior of pipelines to keep it consistent with the cleaning configurations of Jenkins. + +## App Store + +### Bug Fixes + +- Fix an issue where the application icon is not displayed on the uploaded application template. +- Fix an issue where the homepage of an application is not displayed on the application information page. +- Fix an issue where importing built-in applications fails. +- Fix a UUID generation error in an IPv6-only environment. + +## Observability + +### Bug Fixes + +- Fix a parsing error in the configuration file of logsidecar-injector. + +## Service Mesh + +### Bug Fixes + +- Fix an issue that application governance of Bookinfo projects without service mesh enabled is not disabled by default. +- Fix an issue where the delete button is missing on the blue-green deployment details page. + +## Network + +### Bug Fixes + +- Restrict network isolation of projects within the current workspace. + +## Storage + +### Enhancements & Upgrades + +- Display the cluster to which system-workspace belongs in multi-cluster environments. +- Rename route to ingress. + +## Authentication & Authorization + +### Enhancements & Upgrades + +- Add dynamic options for cache. +- Remove the "Alerting Message Management" permission. + +### Bug Fixes + +- Fix an issue where platform roles with platform management permisions cannot manage clusters. + +## Development & Testing + +### Bug Fixes + +- Fix an issue where some data is in the `Out of sync` state after the live-reload feature is introduced. +- Fix an issue where the ks-apiserver fails when it is reloaded multiple times. +- Fix an issue where caching resources fails if some required CRDs are missing. +- Fix an issue where the ks-apiserver crashes in Kubernetes 1.24+ versions. +- Fix an issue where Goroutine leaks occur when the audit event sender times out. + +## User Experience + +- Limit the length of cluster names. +- Fix an issue where pod replicas of a federated service are not automatically refreshed. +- Fix an issue where related pods are not deleted after users delete a service. +- Fix an issue where the number of nodes and roles are incorrectly displayed when there is only one node. + +For more information about issues and contributors of KubeSphere 3.3.2, see [GitHub](https://github.com/kubesphere/kubesphere/blob/master/CHANGELOG/CHANGELOG-3.3.2.md). \ No newline at end of file diff --git a/content/en/docs/v3.4/toolbox/_index.md b/content/en/docs/v3.4/toolbox/_index.md new file mode 100644 index 000000000..6b060c70e --- /dev/null +++ b/content/en/docs/v3.4/toolbox/_index.md @@ -0,0 +1,13 @@ +--- +title: "Toolbox" +description: "Help you to better understand KubeSphere toolbox" +layout: "second" + +linkTitle: "Toolbox" + +weight: 15000 + +icon: "/images/docs/v3.3/docs.svg" +--- + +KubeSphere provides several important functionalities from the toolbox. This chapter demonstrates how to use the toolbox of KubeSphere to query events, logs, and auditing logs, view resource consumption information, and run commands with web kubectl. diff --git a/content/en/docs/v3.4/toolbox/auditing/_index.md b/content/en/docs/v3.4/toolbox/auditing/_index.md new file mode 100644 index 000000000..bbdbbccd6 --- /dev/null +++ b/content/en/docs/v3.4/toolbox/auditing/_index.md @@ -0,0 +1,7 @@ +--- +linkTitle: "Auditing" +weight: 15300 + +_build: + render: false +--- diff --git a/content/en/docs/v3.4/toolbox/auditing/auditing-query.md b/content/en/docs/v3.4/toolbox/auditing/auditing-query.md new file mode 100644 index 000000000..d3c2c9d90 --- /dev/null +++ b/content/en/docs/v3.4/toolbox/auditing/auditing-query.md @@ -0,0 +1,87 @@ +--- +title: "Auditing Log Query" +keywords: "Kubernetes, KubeSphere, auditing, log, query" +description: "Understand how you can perform quick auditing log queries to keep track of the latest auditing information of your cluster." +linkTitle: "Auditing Log Query" +weight: 15330 +--- + +KubeSphere supports the query of auditing logs among isolated tenants. This tutorial demonstrates how to use the query function, including the interface, search parameters and detail pages. + +## Prerequisites + +You need to enable [KubeSphere Auditing Logs](../../../pluggable-components/auditing-logs/). + +## Enter the Query Interface + +1. The query function is available for all users. Log in to the console with any user, hover over the
in the lower-right corner and select **Audit Log Search**.
+
+ {{< notice note >}}
+
+Any user has the permission to query auditing logs, while the logs that each user is able to see are different.
+
+- If a user has the permission to view resources in a project, it can see the auditing log that happens in this project, such as workload creation in the project.
+- If a user has the permission to list projects in a workspace, it can see the auditing log that happens in this workspace but not in projects, such as project creation in the workspace.
+- If a user has the permission to list projects in a cluster, it can see the auditing log that happens in this cluster but not in workspaces and projects, such as workspace creation in the cluster.
+
+{{}}
+
+2. In the pop-up window, you can view log trends in the last 12 hours.
+
+3. The **Audit Log Search** console supports the following query parameters:
+
+ | Parameter | +Description | +
|---|---|
| Cluster | +Cluster where the operation happens. It is enabled if the multi-cluster feature is turned on. | +
| Project | +Project where the operation happens. It supports exact query and fuzzy query. | +
| Workspace | +Workspace where the operation happens. It supports exact query and fuzzy query. | +
| Resource Type | +Type of resource associated with the request. It supports fuzzy query. | +
| Resource Name | +Name of the resource associated with the request. It supports fuzzy query. | +
| Verb | +Kubernetes verb associated with the request. For non-resource requests, this is the lower-case HTTP method. It supports exact query. | +
| Status Code | +HTTP response code. It supports exact query. | +
| Operation Account | +User who calls this request. It supports exact and fuzzy query. | +
| Source IP | +IP address from where the request originated and intermediate proxies. It supports fuzzy query. | +
| Time Range | +Time when the request reaches the apiserver. | +
- `None`: don't log events.
- `Metadata`: log request metadata (requesting user, timestamp, resource, verb, etc.) but not requests or response bodies.
- `Request`: log event metadata and request bodies but no response body. This does not apply to non-resource requests.
- `RequestResponse`: log event metadata, requests, and response bodies. This does not apply to non-resource requests. | `Metadata` + `k8sAuditingEnabled` | Whether to receive Kubernetes auditing logs. | `false` + `receivers` | The receivers to receive alerts. | + +{{< notice note >}} + +You can change the level of Kubernetes auditing logs by modifying the file `audit-policy.yaml`, then restart the Kubernetes apiserver. + +{{}} \ No newline at end of file diff --git a/content/en/docs/v3.4/toolbox/auditing/auditing-rule.md b/content/en/docs/v3.4/toolbox/auditing/auditing-rule.md new file mode 100644 index 000000000..17ba026e9 --- /dev/null +++ b/content/en/docs/v3.4/toolbox/auditing/auditing-rule.md @@ -0,0 +1,207 @@ +--- +title: "Auditing Rules" +keywords: "Kubernetes, docker, kubesphere, auditing" +description: "Understand the auditing rule and how to customize a rule for processing auditing logs." +linkTitle: "Auditing Rules" +weight: 15320 +--- + +An auditing rule defines the policy for processing auditing logs. KubeSphere Auditing Logs provide users with two CRD rules (`archiving-rule` and `alerting-rule`) for customization. + +After you enable [KubeSphere Auditing Logs](../../../pluggable-components/auditing-logs/), log in to the console with a user of `platform-admin` role. In **CRDs** on the **Cluster Management** page, enter `rules.auditing.kubesphere.io` in the search bar. Click the result **Rule** and you can see the two CRD rules. + +Below are examples of part of the rules. + +## archiving-rule + +```yaml +apiVersion: auditing.kubesphere.io/v1alpha1 +kind: Rule +metadata: + labels: + type: archiving + workspace: system-workspace + name: archiving-rule +spec: + rules: + - desc: all action not need to be audit + list: + - get + - list + - watch + name: ignore-action + type: list + - condition: Verb not in ${ignore-action} + desc: All audit event except get, list, watch event + enable: true + name: archiving + priority: DEBUG + type: rule +``` + +## alerting-rule + +```yaml +apiVersion: auditing.kubesphere.io/v1alpha1 +kind: Rule +metadata: + labels: + type: alerting + workspace: system-workspace + name: alerting-rule +spec: + rules: + - desc: all operator need to be audit + list: + - create + - delete + - update + - patch + name: action + type: list + - condition: Verb in ${action} + desc: audit the change of resource + enable: true + name: ResourceChange + priority: INFO + type: rule +``` + + Attributes | Description + --- | --- + `name` | The name of the rule. + `type` | The type of the rule; known values are `rule`, `macro`, `list`, and `alias`. + `desc` | The description of the rule. + `condition` | A filtering expression that is applied against auditing logs to check whether they match the rule. + `macro` | The conditions of the macro. + `list` | The value of list. + `alias` | The value of alias. + `enable` | If it is set to `false`, the rule will not be effective. + `output` | Specifies the message of alert. + `priority` | The priority of the rule. + +When an auditing log matches a rule in `archiving-rule` and the rule priority is no less than `archivingPriority`, it will be stored for further use. When an auditing log matches a rule in `alerting-rule`, if the priority of the rule is less than `alertingPriority`, it will be stored for further use; otherwise it will generate an alert which will be sent to the user. + + +## Rule Conditions + +A `Condition` is a filtering expression that can use comparison operators (=, !=, <, <=, >, >=, contains, in, like, and regex) and can be combined using Boolean operators (and, or and not) and parentheses. Here are the supported filters. + + Filter | Description + --- | --- + `Workspace` | The workspace where the audit event happens. + `Devops` | The DevOps project where the audit event happens. + `Level` | The level of auditing logs. + `RequestURI` | RequestURI is the request URI as sent by the client to a server. + `Verb` | The verb associated with the request. + `User.Username` | The name that uniquely identifies this user among all active users. + `User.Groups` | The names of groups this user is a part of. + `SourceIPs` | The source IP from where the request originated and intermediate proxies. + `ObjectRef.Resource` | The resource of the object associated with the request. + `ObjectRef.Namespace` | The namespace of the object associated with the request. + `ObjectRef.Name` | The name of the object associated with the request. + `ObjectRef.Subresource` | The subresource of the object associated with the request. + `ResponseStatus.code` | The suggested HTTP return code for the request. + `ResponseStatus.Status` | The status of the operation. + `RequestReceivedTimestamp` | The time the request reaches the apiserver. + `StageTimestamp` | The time the request reaches the current audit stage. + +For example, to match all logs in the namespace `test`: + +``` +ObjectRef.Namespace = "test" +``` + +To match all logs in the namespaces that start with `test`: + +``` +ObjectRef.Namespace like "test*" +``` + +To match all logs happening in the latest one hour: + +``` +RequestReceivedTimestamp >= "2020-06-12T09:23:28.359896Z" and RequestReceivedTimestamp <= "2020-06-12T10:23:28.359896Z" +``` + +## Macro + +A `macro` is a rule condition snippet that can be re-used inside rules and even other macros. Macros provide a way to name common patterns and factor out redundancies in rules. Here is an example of a macro. + +```yaml +apiVersion: auditing.kubesphere.io/v1alpha1 +kind: Rule +metadata: + name: alerting-rule + labels: + workspace: system-workspace + type: alerting +spec: + rules: + - name: pod + type: macro + desc: pod + macro: ObjectRef.Resource="pods" +``` + +{{< notice note >}} + +A `macro` can be used in rules or other macros like ${pod} or ${alerting-rule.pod}. The difference between these two methods is that ${pod} can only be used in the CRD Rule `alerting-rule`, while ${alerting-rule.pod} can be used in all CRD Rules. This principle also applies to lists and alias. + +{{}} + +## List + +A `list` is a collection of items that can be included in rules, macros, or other lists. Unlike rules and macros, lists cannot be parsed as filtering expressions. Here is an example of a list. + +```yaml +apiVersion: auditing.kubesphere.io/v1alpha1 +kind: Rule +metadata: + name: alerting-rule + labels: + workspace: system-workspace + type: alerting +spec: + rules: + - name: action + type: list + desc: all operator needs to be audit + list: + - create + - delete + - update + - patch +``` + +## Alias + +An `alias` is a short name of a filter field. It can be included in rules, macros, lists, and output strings. Here is an example of an alias. + +```yaml +apiVersion: auditing.kubesphere.io/v1alpha1 +kind: Rule +metadata: + name: alerting-rule + labels: + workspace: system-workspace + type: alerting +spec: + rules: + - name: namespace + type: alias + desc: the alias of the resource namespace + alias: ObjectRef.Namespace +``` + +## Output +The `Output` string is used to format the alerting message when an auditing log triggers an alert. The `Output` string can include lists and alias. Here is an example. + +```yaml +Output: ${user} ${verb} a HostNetwork Pod ${name} in ${namespace}. +``` +{{< notice note >}} + +The fields of `user`, `verb`, `namespace`, and `name` are all aliases. + +{{}} \ No newline at end of file diff --git a/content/en/docs/v3.4/toolbox/events-query.md b/content/en/docs/v3.4/toolbox/events-query.md new file mode 100644 index 000000000..de6a88c08 --- /dev/null +++ b/content/en/docs/v3.4/toolbox/events-query.md @@ -0,0 +1,39 @@ +--- +title: "Event Query" +keywords: 'KubeSphere, Kubernetes, Event, Query' +description: 'Understand how you can perform quick event queries to keep track of the latest events of your cluster.' +linkTitle: "Event Query" +weight: 15200 +--- + +Kubernetes events provide insight into what is happening inside a cluster, based on which KubeSphere adds longer historical query and aggregation capabilities, and also supports event query for tenant isolation. + +This guide demonstrates how you can do multi-level, fine-grained event queries to track the status of your components. + +## Prerequisites + +[KubeSphere Events](../../pluggable-components/events/) needs to be enabled. + +## Query Events + +1. The event query function is available for all users. Log in to the console with any account, hover over
in the lower-right corner and select **Resource Event Search**.
+
+2. In the displayed dialog box, you can view the number of events that the user has permission to view.
+
+ {{< notice note >}}
+
+- KubeSphere supports event queries on each cluster separately if you have enabled the [multi-cluster feature](../../multicluster-management/). You can click 
on the left of the search box and select a target cluster.
+
+- KubeSphere stores events for the last seven days by default.
+
+ {{}}
+
+3. You can click the search box and enter a condition to search for events by message, workspace, project, resource type, resource name, reason, category, or time range (for example, use `Time Range:Last 10 minutes` to search for events within the last 10 minutes).
+
+4. Click any one of the results from the list, and you can see raw information of it. It is convenient for developers in terms of debugging and analysis.
+
+{{< notice note >}}
+
+The event query interface supports dynamic refreshing every 5s, 10s or 15s.
+
+ {{}}
diff --git a/content/en/docs/v3.4/toolbox/log-query.md b/content/en/docs/v3.4/toolbox/log-query.md
new file mode 100644
index 000000000..f95bdfbd0
--- /dev/null
+++ b/content/en/docs/v3.4/toolbox/log-query.md
@@ -0,0 +1,59 @@
+---
+title: "Log Query"
+keywords: 'KubeSphere, Kubernetes, log, query'
+description: 'Query Kubernetes logs from toolbox'
+linkTitle: "Log Query"
+weight: 15100
+---
+
+The logs of applications and systems can help you better understand what is happening inside your cluster and workloads. The logs are particularly useful for debugging problems and monitoring cluster activities. KubeSphere provides a powerful and easy-to-use logging system which offers users the capabilities of log collection, query and management from the perspective of tenants. The tenant-based logging system is much more useful than Kibana since different tenants can only view their own logs, leading to better security. Moreover, the KubeSphere logging system filters out some redundant information so that tenants can only focus on logs that are useful to them.
+
+This tutorial demonstrates how to use the log query function, including the interface, search parameters and details pages.
+
+## Prerequisites
+
+You need to enable the [KubeSphere Logging System](../../pluggable-components/logging/).
+
+## Enter the Log Query Interface
+
+1. The log query function is available for all users. Log in to the console with any account, hover over 
in the lower-right corner and select **Log Search**.
+
+2. In the pop-up window, you can see a time histogram of log numbers, a cluster selection drop-down list, and a log search bar.
+
+ {{< notice note >}}
+
+- KubeSphere supports log queries on each cluster separately if you have enabled the [multi-cluster feature](../../multicluster-management/). You can click 
on the left of the search box and select a target cluster.
+
+- KubeSphere stores logs for last seven days by default.
+
+ {{}}
+
+3. You can customize the query time range by selecting **Time Range** in the log search bar. Alternatively, click on the bars in the time histogram, and KubeSphere will use the time range of that bar for log queries.
+
+{{< notice note >}}
+
+- The keyword field supports the query of keyword combinations. For example, you can use `Error`, `Fail`, `Fatal`, `Exception`, and `Warning` together to query all the exception logs.
+- The keyword field supports exact query and fuzzy query. The fuzzy query provides case-insensitive fuzzy matching and retrieval of full terms by the first half of a word or phrase based on the ElasticSearch segmentation rules. For example, you can retrieve the logs containing `node_cpu_total` by searching the keyword `node_cpu` instead of the keyword `cpu`.
+- Each cluster has its own log retention period which can be set separately. You can modify it in `ClusterConfiguration`. For more information, see [KubeSphere Logging System](../../pluggable-components/logging/).
+
+{{}}
+
+## Use Search Parameters
+
+1. You can provide as many fields as possible to narrow down your search results.
+
+2. Click any one of the results from the list. Drill into its detail page and inspect the log from this Pod, including the complete context on the right. It is convenient for developers in terms of debugging and analyzing.
+
+ {{< notice note >}}
+
+The log query interface supports dynamic refreshing with 5s, 10s or 15s, and allows users to export logs to a local file for further analysis (in the upper-right corner).
+
+ {{}}
+
+4. In the left panel, you can click 
to view the Pod details page or container details page.
+
+## Drill into the Details Page
+
+1. If the log looks abnormal, you can drill into the Pod detail page or container detail page to further inspect container logs, resource monitoring graphs, and events.
+
+2. Inspect the container detail page. At the same time, it allows you to open the terminal to debug the container directly.
diff --git a/content/en/docs/v3.4/toolbox/metering-and-billing/_index.md b/content/en/docs/v3.4/toolbox/metering-and-billing/_index.md
new file mode 100644
index 000000000..6fd17490c
--- /dev/null
+++ b/content/en/docs/v3.4/toolbox/metering-and-billing/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "Metering and Billing"
+weight: 15400
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/toolbox/metering-and-billing/enable-billing.md b/content/en/docs/v3.4/toolbox/metering-and-billing/enable-billing.md
new file mode 100644
index 000000000..468987a00
--- /dev/null
+++ b/content/en/docs/v3.4/toolbox/metering-and-billing/enable-billing.md
@@ -0,0 +1,84 @@
+---
+title: "Enable Billing"
+keywords: "Kubernetes, KubeSphere, ConfigMap, Billing"
+description: "Enable the billing function in KubeSphere to view the billing data of your resources during a period."
+linkTitle: "Enable Billing"
+weight: 15420
+---
+
+This tutorial demonstrates how to enable KubeSphere Billing to view the cost of different resources in your cluster. By default, the Billing function is disabled so you need to manually add the price information in a ConfigMap.
+
+Perform the following steps to enable KubeSphere Billing.
+
+1. Run the following command to edit the ConfigMap `kubesphere-config`:
+
+ ```bash
+ kubectl edit cm kubesphere-config -n kubesphere-system
+ ```
+
+2. Add the retention day and price information under `metering` in the ConfigMap. The following is an example for your reference:
+
+ ```yaml
+ $ kubectl get cm kubesphere-config -n kubesphere-system -oyaml
+ ...
+ alerting:
+ prometheusEndpoint: http://prometheus-operated.kubesphere-monitoring-system.svc:9090
+ thanosRulerEndpoint: http://thanos-ruler-operated.kubesphere-monitoring-system.svc:10902
+ thanosRuleResourceLabels: thanosruler=thanos-ruler,role=thanos-alerting-rules
+ ...
+ metering:
+ retentionDay: 7d
+ billing:
+ priceInfo:
+ currencyUnit: "USD"
+ cpuPerCorePerHour: 1.5
+ memPerGigabytesPerHour: 5
+ ingressNetworkTrafficPerMegabytesPerHour: 1
+ egressNetworkTrafficPerMegabytesPerHour: 1
+ pvcPerGigabytesPerHour: 2.1
+ kind: ConfigMap
+ ...
+ ```
+
+ The following table describes the parameters.
+
+ | Parameter | +Description | +
|---|---|
retentionDay |
+ retentionDay determines the date range displayed on the Metering and Billing page for users. The value of this parameter must be the same as the value of retention in Prometheus. |
+
currencyUnit |
+ The currency that is displayed on the Metering and Billing page. Currently allowed values are CNY (Renminbi) and USD (US dollars). If you specify other currencies, the console will display cost in USD by default. |
+
cpuCorePerHour |
+ The unit price of CPU per core/hour. | +
memPerGigabytesPerHour |
+ The unit price of memory per GB/hour. | +
ingressNetworkTrafficPerMegabytesPerHour |
+ The unit price of ingress traffic per MB/hour. | +
egressNetworkTrafficPerMegabytesPerHour |
+ The unit price of egress traffic per MB/hour. | +
pvcPerGigabytesPerHour |
+ The unit price of PVC per GB/hour. Note that KubeSphere calculates the total cost of volumes based on the storage capacity PVCs request regardless of the actual storage in use. | +
in the lower-right corner and select **Metering and Billing**.
+
+2. Click **View Consumption** in the **Cluster Resource Consumption** section.
+
+3. On the left side of the dashboard, you can see a cluster list containing your host cluster and all member clusters if you have enabled [multi-cluster management](../../../multicluster-management/). There is only one cluster called `default` in the list if it is not enabled.
+
+ On the right side, there are three parts showing resource consumption in different ways.
+
+ | Module | +Description | +
|---|---|
| Overview | +Displays a consumption overview of different resources in a cluster since its creation. You can also see the billing information if you have set prices for these resources in the ConfigMap kubesphere-config. |
+
| Consumption by Yesterday | +Displays the total resource consumption by yesterday. You can also customize the time range and internal to see data within a specific period. | +
| Current Resources Included | +Displays the consumption of resources included in the selected target object (in this case, all nodes in the selected cluster) over the last hour. | +
in the lower-right corner and select **Metering and Billing**.
+
+2. Click **View Consumption** in the **Workspace (Project) Resource Consumption** section.
+
+3. On the left side of the dashboard, you can see a list containing all the workspaces in the current cluster. The right part displays detailed consumption information in the selected workspace, the layout of which is basically the same as that of a cluster.
+
+ {{< notice note >}}
+
+ In a multi-cluster architecture, you cannot see the metering and billing information of a workspace if it does not have any available cluster assigned to it. For more information, see [Cluster Visibility and Authorization](../../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/).
+
+ {{}}
+
+4. Click a workspace on the left and dive deeper into a project or workload (for example, Deployment and StatefulSet) to see detailed consumption information.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/toolbox/web-kubectl.md b/content/en/docs/v3.4/toolbox/web-kubectl.md
new file mode 100644
index 000000000..54a51b1f6
--- /dev/null
+++ b/content/en/docs/v3.4/toolbox/web-kubectl.md
@@ -0,0 +1,44 @@
+---
+title: "Web Kubectl"
+keywords: 'KubeSphere, Kubernetes, kubectl, cli'
+description: 'The web kubectl tool is integrated into KubeSphere to provide consistent user experiences for Kubernetes users.'
+linkTitle: "Web Kubectl"
+weight: 15500
+---
+
+The Kubernetes command-line tool, kubectl, allows you to run commands on Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, view logs, and more.
+
+KubeSphere provides web kubectl on the console for user convenience. By default, in the current version, only the account granted the `platform-admin` role (such as the default account `admin`) has the permission to use web kubectl for cluster resource operation and management.
+
+This tutorial demonstrates how to use web kubectl to operate on and manage cluster resources.
+
+## Use Web Kubectl
+
+1. Log in to KubeSphere with a user granted the `platform-admin` role, hover over the **Toolbox** in the lower-right corner and select **Kubectl**.
+
+2. You can see the kubectl interface in the pop-up window. If you have enabled the multi-cluster feature, you need to select the target cluster first from the drop-down list in the upper-right corner. This drop-down list is not visible if the multi-cluster feature is not enabled.
+
+3. Enter kubectl commands in the command-line tool to query and manage Kubernetes cluster resources. For example, execute the following command to query the status of all PVCs in the cluster.
+
+ ```bash
+ kubectl get pvc --all-namespaces
+ ```
+
+ 
+
+4. Use the following syntax to run kubectl commands from your terminal window:
+
+ ```bash
+ kubectl [command] [TYPE] [NAME] [flags]
+ ```
+
+ {{< notice note >}}
+
+- Where `command`, `TYPE`, `NAME`, and `flags` are:
+ - `command`: Specifies the operation that you want to perform on one or more resources, such as `create`, `get`, `describe` and `delete`.
+ - `TYPE`: Specifies the [resource type](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms.
+ - `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, such as `kubectl get pods`.
+ - `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
+- If you need help, run `kubectl help` from the terminal window or refer to the [Kubernetes kubectl CLI documentation](https://kubernetes.io/docs/reference/kubectl/overview/).
+
+ {{}}
diff --git a/content/en/docs/v3.4/upgrade/_index.md b/content/en/docs/v3.4/upgrade/_index.md
new file mode 100644
index 000000000..a88033ba0
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/_index.md
@@ -0,0 +1,14 @@
+---
+title: "Upgrade"
+description: "Upgrade KubeSphere and Kubernetes"
+layout: "second"
+
+linkTitle: "Upgrade"
+
+weight: 7000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+This chapter demonstrates how cluster operators can upgrade KubeSphere to 3.3.2.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-ks-installer.md b/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-ks-installer.md
new file mode 100644
index 000000000..5a412910d
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-ks-installer.md
@@ -0,0 +1,182 @@
+---
+title: "Air-Gapped Upgrade with ks-installer"
+keywords: "Air-Gapped, upgrade, kubesphere, 3.3"
+description: "Use ks-installer and offline package to upgrade KubeSphere."
+linkTitle: "Air-Gapped Upgrade with ks-installer"
+weight: 7500
+---
+
+ks-installer is recommended for users whose Kubernetes clusters were not set up by [KubeKey](../../installing-on-linux/introduction/kubekey/), but hosted by cloud vendors or created by themselves. This tutorial is for **upgrading KubeSphere only**. Cluster operators are responsible for upgrading Kubernetes beforehand.
+
+
+## Prerequisites
+
+- You need to have a KubeSphere cluster running v3.2.x. If your KubeSphere version is v3.1.x or earlier, upgrade to v3.2.x first.
+- Read [Release Notes for 3.3.2](../../../v3.3/release/release-v332/) carefully.
+- Back up any important component beforehand.
+- A Docker registry. You need to have a Harbor or other Docker registries. For more information, see [Prepare a Private Image Registry](../../installing-on-linux/introduction/air-gapped-installation/#step-2-prepare-a-private-image-registry).
+- Supported Kubernetes versions of KubeSphere 3.3: v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+
+## Major Updates
+
+In KubeSphere 3.3.1, some changes have made on built-in roles and permissions of custom roles. Therefore, before you upgrade KubeSphere to 3.3.1, please note the following:
+
+ - Change of built-in roles: Platform-level built-in roles `users-manager` and `workspace-manager` are removed. If an existing user has been bound to `users-manager` or `workspace-manager`, its role will be changed to `platform-regular` after the upgrade is completed. Role `platform-self-provisioner` is added. For more information about built-in roles, refer to [Create a user](../../quick-start/create-workspace-and-project).
+
+ - Some permission of custom roles are removed:
+ - Removed permissions of platform-level custom roles: user management, role management, and workspace management.
+ - Removed permissions of workspace-level custom roles: user management, role management, and user group management.
+ - Removed permissions of namespace-level custom roles: user management and role management.
+ - After you upgrade KubeSphere to 3.3.1, custom roles will be retained, but removed permissions of the custom roles will be revoked.
+## Step 1: Prepare Installation Images
+
+As you install KubeSphere in an air-gapped environment, you need to prepare an image package containing all the necessary images in advance.
+
+1. Download the image list file `images-list.txt` from a machine that has access to Internet through the following command:
+
+ ```bash
+ curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/images-list.txt
+ ```
+
+ {{< notice note >}}
+
+ This file lists images under `##+modulename` based on different modules. You can add your own images to this file following the same rule. To view the complete file, see [Appendix](../../installing-on-linux/introduction/air-gapped-installation/#image-list-of-kubesphere-v310).
+
+ {{}}
+
+2. Download `offline-installation-tool.sh`.
+
+ ```bash
+ curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/offline-installation-tool.sh
+ ```
+
+3. Make the `.sh` file executable.
+
+ ```bash
+ chmod +x offline-installation-tool.sh
+ ```
+
+4. You can execute the command `./offline-installation-tool.sh -h` to see how to use the script:
+
+ ```bash
+ root@master:/home/ubuntu# ./offline-installation-tool.sh -h
+ Usage:
+
+ ./offline-installation-tool.sh [-l IMAGES-LIST] [-d IMAGES-DIR] [-r PRIVATE-REGISTRY] [-v KUBERNETES-VERSION ]
+
+ Description:
+ -b : save kubernetes' binaries.
+ -d IMAGES-DIR : the dir of files (tar.gz) which generated by `docker save`. default: ./kubesphere-images
+ -l IMAGES-LIST : text file with list of images.
+ -r PRIVATE-REGISTRY : target private registry:port.
+ -s : save model will be applied. Pull the images in the IMAGES-LIST and save images as a tar.gz file.
+ -v KUBERNETES-VERSION : download kubernetes' binaries. default: v1.17.9
+ -h : usage message
+ ```
+
+5. Pull images in `offline-installation-tool.sh`.
+
+ ```bash
+ ./offline-installation-tool.sh -s -l images-list.txt -d ./kubesphere-images
+ ```
+
+ {{< notice note >}}
+
+ You can choose to pull images as needed. For example, you can delete `##k8s-images` and related images under it in `images-list.text` if you already have a Kubernetes cluster.
+
+ {{}}
+
+## Step 2: Push Images to Your Private Registry
+
+Transfer your packaged image file to your local machine and execute the following command to push it to the registry.
+
+```bash
+./offline-installation-tool.sh -l images-list.txt -d ./kubesphere-images -r dockerhub.kubekey.local
+```
+
+{{< notice note >}}
+
+The domain name is `dockerhub.kubekey.local` in the command. Make sure you use your **own registry address**.
+
+{{}}
+
+## Step 3: Download ks-installer
+
+Similar to installing KubeSphere on an existing Kubernetes cluster in an online environment, you also need to download `kubesphere-installer.yaml`.
+
+1. Execute the following command to download ks-installer and transfer it to your machine that serves as the taskbox for installation.
+
+ ```bash
+ curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml
+ ```
+
+2. Verify that you have specified your private image registry in `spec.local_registry` in `cluster-configuration.yaml`. Note that if your existing cluster was installed in an air-gapped environment, you may already have this field specified. Otherwise, run the following command to edit `cluster-configuration.yaml` of your existing KubeSphere v3.1.x cluster and add the private image registry:
+
+ ```
+ kubectl edit cc -n kubesphere-system
+ ```
+
+ For example, `dockerhub.kubekey.local` is the registry address in this tutorial, then use it as the value of `.spec.local_registry` as below:
+
+ ```yaml
+ spec:
+ persistence:
+ storageClass: ""
+ authentication:
+ jwtSecret: ""
+ local_registry: dockerhub.kubekey.local # Add this line manually; make sure you use your own registry address.
+ ```
+
+3. Save `cluster-configuration.yaml` after you finish editing it. Replace `ks-installer` with your **own registry address** with the following command:
+
+ ```bash
+ sed -i "s#^\s*image: kubesphere.*/ks-installer:.*# image: dockerhub.kubekey.local/kubesphere/ks-installer:v3.1.0#" kubesphere-installer.yaml
+ ```
+
+ {{< notice warning >}}
+
+ `dockerhub.kubekey.local` is the registry address in the command. Make sure you use your own registry address.
+
+ {{}}
+
+## Step 4: Upgrade KubeSphere
+
+Execute the following command after you make sure that all steps above are completed.
+
+```bash
+kubectl apply -f kubesphere-installer.yaml
+```
+
+## Step 5: Verify Installation
+
+When the installation finishes, you can see the content as follows:
+
+```bash
+#####################################################
+### Welcome to KubeSphere! ###
+#####################################################
+
+Console: http://192.168.0.2:30880
+Account: admin
+Password: P@88w0rd
+
+NOTES：
+ 1. After you log into the console, please check the
+ monitoring status of service components in
+ the "Cluster Management". If any service is not
+ ready, please wait patiently until all components
+ are up and running.
+ 2. Please change the default password after login.
+
+#####################################################
+https://kubesphere.io 20xx-xx-xx xx:xx:xx
+#####################################################
+```
+
+Now, you will be able to access the web console of KubeSphere through `http://{IP}:30880` with the default account and password `admin/P@88w0rd`.
+
+{{< notice note >}}
+
+To access the console, make sure port 30880 is opened in your security group.
+
+{{}}
diff --git a/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-kubekey.md b/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-kubekey.md
new file mode 100644
index 000000000..8b431df14
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/air-gapped-upgrade-with-kubekey.md
@@ -0,0 +1,349 @@
+---
+title: "Air-Gapped Upgrade with KubeKey"
+keywords: "Air-Gapped, kubernetes, upgrade, kubesphere, 3.3.1"
+description: "Use the offline package to upgrade Kubernetes and KubeSphere."
+linkTitle: "Air-Gapped Upgrade with KubeKey"
+weight: 7400
+---
+Air-gapped upgrade with KubeKey is recommended for users whose KubeSphere and Kubernetes were both deployed by [KubeKey](../../installing-on-linux/introduction/kubekey/). If your Kubernetes cluster was provisioned by yourself or cloud providers, refer to [Air-gapped Upgrade with ks-installer](../air-gapped-upgrade-with-ks-installer/).
+
+## Prerequisites
+
+- You need to have a KubeSphere cluster running v3.2.x. If your KubeSphere version is v3.1.x or earlier, upgrade to v3.2.x first.
+- Your Kubernetes version must be v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+- Read [Release Notes for 3.3.2](../../../v3.3/release/release-v332/) carefully.
+- Back up any important component beforehand.
+- A Docker registry. You need to have a Harbor or other Docker registries.
+- Make sure every node can push and pull images from the Docker Registry.
+
+## Major Updates
+
+In KubeSphere 3.3.1, some changes have made on built-in roles and permissions of custom roles. Therefore, before you upgrade KubeSphere to 3.3.1, please note the following:
+
+ - Change of built-in roles: Platform-level built-in roles `users-manager` and `workspace-manager` are removed. If an existing user has been bound to `users-manager` or `workspace-manager`, its role will be changed to `platform-regular` after the upgrade is completed. Role `platform-self-provisioner` is added. For more information about built-in roles, refer to [Create a user](../../quick-start/create-workspace-and-project).
+
+ - Some permission of custom roles are removed:
+ - Removed permissions of platform-level custom roles: user management, role management, and workspace management.
+ - Removed permissions of workspace-level custom roles: user management, role management, and user group management.
+ - Removed permissions of namespace-level custom roles: user management and role management.
+ - After you upgrade KubeSphere to 3.3.1, custom roles will be retained, but removed permissions of the custom roles will be revoked.
+
+## Upgrade KubeSphere and Kubernetes
+
+Upgrading steps are different for single-node clusters (all-in-one) and multi-node clusters.
+
+{{< notice info >}}
+
+KubeKey upgrades Kubernetes from one MINOR version to the next MINOR version until the target version. For example, you may see the upgrading process going from 1.16 to 1.17 and to 1.18, instead of directly jumping to 1.18 from 1.16.
+
+{{}}
+
+
+### System Requirements
+
+| Systems | Minimum Requirements (Each node) |
+| --------------------------------------------------------------- | ------------------------------------------- |
+| **Ubuntu** *16.04, 18.04, 20.04* | CPU: 2 Cores, Memory: 4 G, Disk Space: 40 G |
+| **Debian** *Buster, Stretch* | CPU: 2 Cores, Memory: 4 G, Disk Space: 40 G |
+| **CentOS** *7.x* | CPU: 2 Cores, Memory: 4 G, Disk Space: 40 G |
+| **Red Hat Enterprise Linux** *7* | CPU: 2 Cores, Memory: 4 G, Disk Space: 40 G |
+| **SUSE Linux Enterprise Server** *15* **/openSUSE Leap** *15.2* | CPU: 2 Cores, Memory: 4 G, Disk Space: 40 G |
+
+{{< notice note >}}
+
+[KubeKey](https://github.com/kubesphere/kubekey) uses `/var/lib/docker` as the default directory where all Docker related files, including images, are stored. It is recommended you add additional storage volumes with at least **100G** mounted to `/var/lib/docker` and `/mnt/registry` respectively. See [fdisk](https://www.computerhope.com/unix/fdisk.htm) command for reference.
+
+{{}}
+
+
+### Step 1: Download KubeKey
+1. 1. Run the following commands to download KubeKey.
+ {{< tabs >}}
+
+ {{< tab "Good network connections to GitHub/Googleapis" >}}
+
+ Download KubeKey from its [GitHub Release Page](https://github.com/kubesphere/kubekey/releases) or use the following command directly.
+
+ ```bash
+ curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+ ```
+
+ {{}}
+
+ {{< tab "Poor network connections to GitHub/Googleapis" >}}
+
+ Run the following command first to make sure you download KubeKey from the correct zone.
+
+ ```bash
+ export KKZONE=cn
+ ```
+
+ Run the following command to download KubeKey:
+
+ ```bash
+ curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+ ```
+ {{}}
+
+ {{}}
+
+2. After you uncompress the file, execute the following command to make `kk` executable:
+
+ ```bash
+ chmod +x kk
+ ```
+
+### Step 2: Prepare installation images
+
+As you install KubeSphere and Kubernetes on Linux, you need to prepare an image package containing all the necessary images and download the Kubernetes binary file in advance.
+
+1. Download the image list file `images-list.txt` from a machine that has access to Internet through the following command:
+
+ ```bash
+ curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/images-list.txt
+ ```
+
+ {{< notice note >}}
+
+ This file lists images under `##+modulename` based on different modules. You can add your own images to this file following the same rule.
+
+ {{}}
+
+2. Download `offline-installation-tool.sh`.
+
+ ```bash
+ curl -L -O https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/offline-installation-tool.sh
+ ```
+
+3. Make the `.sh` file executable.
+
+ ```bash
+ chmod +x offline-installation-tool.sh
+ ```
+
+4. You can execute the command `./offline-installation-tool.sh -h` to see how to use the script:
+
+ ```bash
+ root@master:/home/ubuntu# ./offline-installation-tool.sh -h
+ Usage:
+
+ ./offline-installation-tool.sh [-l IMAGES-LIST] [-d IMAGES-DIR] [-r PRIVATE-REGISTRY] [-v KUBERNETES-VERSION ]
+
+ Description:
+ -b : save kubernetes' binaries.
+ -d IMAGES-DIR : the dir of files (tar.gz) which generated by `docker save`. default: /home/ubuntu/kubesphere-images
+ -l IMAGES-LIST : text file with list of images.
+ -r PRIVATE-REGISTRY : target private registry:port.
+ -s : save model will be applied. Pull the images in the IMAGES-LIST and save images as a tar.gz file.
+ -v KUBERNETES-VERSION : download kubernetes' binaries. default: v1.17.9
+ -h : usage message
+ ```
+
+5. Download the Kubernetes binary file.
+
+ ```bash
+ ./offline-installation-tool.sh -b -v v1.22.12
+ ```
+
+ If you cannot access the object storage service of Google, run the following command instead to add the environment variable to change the source.
+
+ ```bash
+ export KKZONE=cn;./offline-installation-tool.sh -b -v v1.22.12
+ ```
+
+ {{< notice note >}}
+
+ - You can change the Kubernetes version downloaded based on your needs. Recommended Kubernetes versions for KubeSphere 3.3 are v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x. If you do not specify a Kubernetes version, KubeKey will install Kubernetes v1.23.10 by default. For more information about supported Kubernetes versions, see [Support Matrix](../../installing-on-linux/introduction/kubekey/#support-matrix).
+
+ - After you run the script, a folder `kubekey` is automatically created. Note that this file and `kk` must be placed in the same directory when you create the cluster later.
+
+ {{}}
+
+6. Pull images in `offline-installation-tool.sh`.
+
+ ```bash
+ ./offline-installation-tool.sh -s -l images-list.txt -d ./kubesphere-images
+ ```
+
+ {{< notice note >}}
+
+ You can choose to pull images as needed. For example, you can delete `##k8s-images` and related images under it in `images-list.text` if you already have a Kubernetes cluster.
+
+ {{}}
+
+### Step 3: Push images to your private registry
+
+Transfer your packaged image file to your local machine and execute the following command to push it to the registry.
+
+```bash
+./offline-installation-tool.sh -l images-list.txt -d ./kubesphere-images -r dockerhub.kubekey.local
+```
+
+ {{< notice note >}}
+
+ The domain name is `dockerhub.kubekey.local` in the command. Make sure you use your **own registry address**.
+
+ {{}}
+
+### Air-gapped upgrade for all-in-one clusters
+
+#### Example machines
+| Host Name | IP | Role | Port | URL |
+| --------- | ----------- | -------------------- | ---- | ----------------------- |
+| master | 192.168.1.1 | Docker registry | 5000 | http://192.168.1.1:5000 |
+| master | 192.168.1.1 | master, etcd, worker | | |
+
+#### Versions
+
+| | Kubernetes | KubeSphere |
+| ------ | ---------- | ---------- |
+| Before | v1.18.6 | v3.2.x |
+| After | v1.22.12 | 3.3.x |
+
+#### Upgrade a cluster
+
+In this example, KubeSphere is installed on a single node, and you need to specify a configuration file to add host information. Besides, for air-gapped installation, pay special attention to `.spec.registry.privateRegistry`, which must be set to **your own registry address**. For more information, see the following sections.
+
+#### Create an example configuration file
+
+Execute the following command to generate an example configuration file for installation:
+
+```bash
+./kk create config [--with-kubernetes version] [--with-kubesphere version] [(-f | --file) path]
+```
+
+For example:
+
+```bash
+./kk create config --with-kubernetes v1.22.12 --with-kubesphere v3.3.2 -f config-sample.yaml
+```
+
+{{< notice note >}}
+
+Make sure the Kubernetes version is the one you downloaded.
+
+{{}}
+
+#### Edit the configuration file
+
+Edit the configuration file `config-sample.yaml`. Here is [an example for your reference](https://github.com/kubesphere/kubekey/blob/release-2.2/docs/config-example.md).
+
+ {{< notice warning >}}
+
+For air-gapped installation, you must specify `privateRegistry`, which is `dockerhub.kubekey.local` in this example.
+
+ {{}}
+
+ Set `hosts` of your `config-sample.yaml` file:
+
+```yaml
+ hosts:
+ - {name: ks.master, address: 192.168.1.1, internalAddress: 192.168.1.1, user: root, password: Qcloud@123}
+ roleGroups:
+ etcd:
+ - ks.master
+ control-plane:
+ - ks.master
+ worker:
+ - ks.master
+```
+
+Set `privateRegistry` of your `config-sample.yaml` file:
+```yaml
+ registry:
+ registryMirrors: []
+ insecureRegistries: []
+ privateRegistry: dockerhub.kubekey.local
+```
+
+#### Upgrade your single-node cluster to KubeSphere 3.3 and Kubernetes v1.22.12
+
+```bash
+./kk upgrade -f config-sample.yaml
+```
+
+To upgrade Kubernetes to a specific version, explicitly provide the version after the flag `--with-kubernetes`. Available versions are v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+
+### Air-gapped upgrade for multi-node clusters
+
+#### Example machines
+| Host Name | IP | Role | Port | URL |
+| --------- | ----------- | --------------- | ---- | ----------------------- |
+| master | 192.168.1.1 | Docker registry | 5000 | http://192.168.1.1:5000 |
+| master | 192.168.1.1 | master, etcd | | |
+| slave1 | 192.168.1.2 | worker | | |
+| slave1 | 192.168.1.3 | worker | | |
+
+
+#### Versions
+
+| | Kubernetes | KubeSphere |
+| ------ | ---------- | ---------- |
+| Before | v1.18.6 | v3.2.x |
+| After | v1.22.12 | 3.3.x |
+
+#### Upgrade a cluster
+
+In this example, KubeSphere is installed on multiple nodes, so you need to specify a configuration file to add host information. Besides, for air-gapped installation, pay special attention to `.spec.registry.privateRegistry`, which must be set to **your own registry address**. For more information, see the following sections.
+
+#### Create an example configuration file
+
+ Execute the following command to generate an example configuration file for installation:
+
+```bash
+./kk create config [--with-kubernetes version] [--with-kubesphere version] [(-f | --file) path]
+```
+
+ For example:
+
+```bash
+./kk create config --with-kubernetes v1.22.12 --with-kubesphere v3.3.2 -f config-sample.yaml
+```
+
+{{< notice note >}}
+
+Make sure the Kubernetes version is the one you downloaded.
+
+{{}}
+
+#### Edit the configuration file
+
+Edit the configuration file `config-sample.yaml`. Here is [an example for your reference](https://github.com/kubesphere/kubekey/blob/release-2.2/docs/config-example.md).
+
+ {{< notice warning >}}
+
+ For air-gapped installation, you must specify `privateRegistry`, which is `dockerhub.kubekey.local` in this example.
+
+ {{}}
+
+Set `hosts` of your `config-sample.yaml` file:
+
+```yaml
+ hosts:
+ - {name: ks.master, address: 192.168.1.1, internalAddress: 192.168.1.1, user: root, password: Qcloud@123}
+ - {name: ks.slave1, address: 192.168.1.2, internalAddress: 192.168.1.2, user: root, privateKeyPath: "/root/.ssh/kp-qingcloud"}
+ - {name: ks.slave2, address: 192.168.1.3, internalAddress: 192.168.1.3, user: root, privateKeyPath: "/root/.ssh/kp-qingcloud"}
+ roleGroups:
+ etcd:
+ - ks.master
+ control-plane:
+ - ks.master
+ worker:
+ - ks.slave1
+ - ks.slave2
+```
+Set `privateRegistry` of your `config-sample.yaml` file:
+```yaml
+ registry:
+ registryMirrors: []
+ insecureRegistries: []
+ privateRegistry: dockerhub.kubekey.local
+```
+
+#### Upgrade your multi-node cluster to KubeSphere 3.3 and Kubernetes v1.22.12
+
+```bash
+./kk upgrade -f config-sample.yaml
+```
+
+To upgrade Kubernetes to a specific version, explicitly provide the version after the flag `--with-kubernetes`. Available versions are v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
diff --git a/content/en/docs/v3.4/upgrade/overview.md b/content/en/docs/v3.4/upgrade/overview.md
new file mode 100644
index 000000000..df085801b
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/overview.md
@@ -0,0 +1,28 @@
+---
+title: "Upgrade — Overview"
+keywords: "Kubernetes, upgrade, KubeSphere, 3.3, upgrade"
+description: "Understand what you need to pay attention to before the upgrade, such as versions, and upgrade tools."
+linkTitle: "Overview"
+weight: 7100
+---
+
+## Make Your Upgrade Plan
+
+KubeSphere 3.3 is compatible with Kubernetes v1.20.x, v1.21.x, * v1.22.x, * v1.23.x, and * v1.24.x:
+
+- Before you upgrade your cluster to KubeSphere 3.3, you need to have a KubeSphere cluster running v3.2.x.
+- You can choose to only upgrade KubeSphere to 3.3 or upgrade Kubernetes (to a higher version) and KubeSphere (to 3.3) at the same time.
+- For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+## Before the Upgrade
+
+{{< notice warning >}}
+
+- You are supposed to implement a simulation for the upgrade in a testing environment first. After the upgrade is successful in the testing environment and all applications are running normally, upgrade your cluster in your production environment.
+- During the upgrade process, there may be a short interruption of applications (especially for those single-replica Pods). Please arrange a reasonable period of time for your upgrade.
+- It is recommended to back up etcd and stateful applications before in production. You can use [Velero](https://velero.io/) to implement the backup and migrate Kubernetes resources and persistent volumes.
+
+{{}}
+
+## Upgrade Tool
+
+Depending on how your existing cluster was set up, you can use KubeKey or ks-installer to upgrade your cluster. It is recommended that you [use KubeKey to upgrade your cluster](../upgrade-with-kubekey/) if it was created by KubeKey. Otherwise, [use ks-installer to upgrade your cluster](../upgrade-with-ks-installer/).
\ No newline at end of file
diff --git a/content/en/docs/v3.4/upgrade/upgrade-with-ks-installer.md b/content/en/docs/v3.4/upgrade/upgrade-with-ks-installer.md
new file mode 100644
index 000000000..6790aa41a
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/upgrade-with-ks-installer.md
@@ -0,0 +1,41 @@
+---
+title: "Upgrade with ks-installer"
+keywords: "Kubernetes, upgrade, KubeSphere, v3.3.2"
+description: "Use ks-installer to upgrade KubeSphere."
+linkTitle: "Upgrade with ks-installer"
+weight: 7300
+---
+
+ks-installer is recommended for users whose Kubernetes clusters were not set up by [KubeKey](../../installing-on-linux/introduction/kubekey/), but hosted by cloud vendors or created by themselves. This tutorial is for **upgrading KubeSphere only**. Cluster operators are responsible for upgrading Kubernetes beforehand.
+
+## Prerequisites
+
+- You need to have a KubeSphere cluster running v3.2.x. If your KubeSphere version is v3.1.x or earlier, upgrade to v3.2.x first.
+- Read [Release Notes for 3.3.2](../../../v3.3/release/release-v332/) carefully.
+- Back up any important component beforehand.
+- Supported Kubernetes versions of KubeSphere 3.3: v1.20.x, v1.21.x, * v1.22.x, * v1.23.x， and v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+
+## Major Updates
+
+In KubeSphere 3.3.1, some changes have made on built-in roles and permissions of custom roles. Therefore, before you upgrade KubeSphere to 3.3.1, please note the following:
+
+ - Change of built-in roles: Platform-level built-in roles `users-manager` and `workspace-manager` are removed. If an existing user has been bound to `users-manager` or `workspace-manager`, its role will be changed to `platform-regular` after the upgrade is completed. Role `platform-self-provisioner` is added. For more information about built-in roles, refer to [Create a user](../../quick-start/create-workspace-and-project).
+
+ - Some permission of custom roles are removed:
+ - Removed permissions of platform-level custom roles: user management, role management, and workspace management.
+ - Removed permissions of workspace-level custom roles: user management, role management, and user group management.
+ - Removed permissions of namespace-level custom roles: user management and role management.
+ - After you upgrade KubeSphere to 3.3.1, custom roles will be retained, but removed permissions of the custom roles will be revoked.
+
+## Apply ks-installer
+
+Run the following command to upgrade your cluster.
+
+```bash
+kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.3.2/kubesphere-installer.yaml --force
+```
+
+## Enable Pluggable Components
+
+You can [enable new pluggable components](../../pluggable-components/overview/) of KubeSphere 3.3 after the upgrade to explore more features of the container platform.
+
diff --git a/content/en/docs/v3.4/upgrade/upgrade-with-kubekey.md b/content/en/docs/v3.4/upgrade/upgrade-with-kubekey.md
new file mode 100644
index 000000000..35eef7615
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/upgrade-with-kubekey.md
@@ -0,0 +1,146 @@
+---
+title: "Upgrade with KubeKey"
+keywords: "Kubernetes, upgrade, KubeSphere, 3.3, KubeKey"
+description: "Use KubeKey to upgrade Kubernetes and KubeSphere."
+linkTitle: "Upgrade with KubeKey"
+weight: 7200
+---
+KubeKey is recommended for users whose KubeSphere and Kubernetes were both installed by [KubeKey](../../installing-on-linux/introduction/kubekey/). If your Kubernetes cluster was provisioned by yourself or cloud providers, refer to [Upgrade with ks-installer](../upgrade-with-ks-installer/).
+
+This tutorial demonstrates how to upgrade your cluster using KubeKey.
+
+## Prerequisites
+
+- You need to have a KubeSphere cluster running v3.2.x. If your KubeSphere version is v3.1.x or earlier, upgrade to v3.2.x first.
+- Read [Release Notes for 3.3.2](../../../v3.3/release/release-v332/) carefully.
+- Back up any important component beforehand.
+- Make your upgrade plan. Two scenarios are provided in this document for [all-in-one clusters](#all-in-one-cluster) and [multi-node clusters](#multi-node-cluster) respectively.
+
+## Major Updates
+
+In KubeSphere 3.3.1, some changes have made on built-in roles and permissions of custom roles. Therefore, before you upgrade KubeSphere to 3.3.1, please note the following:
+
+ - Change of built-in roles: Platform-level built-in roles `users-manager` and `workspace-manager` are removed. If an existing user has been bound to `users-manager` or `workspace-manager`, its role will be changed to `platform-regular` after the upgrade is completed. Role `platform-self-provisioner` is added. For more information about built-in roles, refer to [Create a user](../../quick-start/create-workspace-and-project).
+
+ - Some permission of custom roles are removed:
+ - Removed permissions of platform-level custom roles: user management, role management, and workspace management.
+ - Removed permissions of workspace-level custom roles: user management, role management, and user group management.
+ - Removed permissions of namespace-level custom roles: user management and role management.
+ - After you upgrade KubeSphere to 3.3.1, custom roles will be retained, but removed permissions of the custom roles will be revoked.
+
+## Download KubeKey
+
+Follow the steps below to download KubeKey before you upgrade your cluster.
+
+{{< tabs >}}
+
+{{< tab "Good network connections to GitHub/Googleapis" >}}
+
+Download KubeKey from its [GitHub Release Page](https://github.com/kubesphere/kubekey/releases) or use the following command directly.
+
+```bash
+curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+```
+
+{{}}
+
+{{< tab "Poor network connections to GitHub/Googleapis" >}}
+
+Run the following command first to make sure you download KubeKey from the correct zone.
+
+```bash
+export KKZONE=cn
+```
+
+Run the following command to download KubeKey:
+
+```bash
+curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
+```
+
+{{< notice note >}}
+
+After you download KubeKey, if you transfer it to a new machine also with poor network connections to Googleapis, you must run `export KKZONE=cn` again before you proceed with the steps below.
+
+{{}}
+
+{{}}
+
+{{}}
+
+{{< notice note >}}
+
+The commands above download the latest release of KubeKey. You can change the version number in the command to download a specific version.
+
+{{}}
+
+Make `kk` executable:
+
+```bash
+chmod +x kk
+```
+
+## Upgrade KubeSphere and Kubernetes
+
+Upgrading steps are different for single-node clusters (all-in-one) and multi-node clusters.
+
+{{< notice info >}}
+
+When upgrading Kubernetes, KubeKey will upgrade from one MINOR version to the next MINOR version until the target version. For example, you may see the upgrading process going from 1.16 to 1.17 and to 1.18, instead of directly jumping to 1.18 from 1.16.
+
+{{}}
+
+### All-in-one cluster
+
+Run the following command to use KubeKey to upgrade your single-node cluster to KubeSphere 3.3 and Kubernetes v1.22.12:
+
+```bash
+./kk upgrade --with-kubernetes v1.22.12 --with-kubesphere v3.3.2
+```
+
+To upgrade Kubernetes to a specific version, explicitly provide the version after the flag `--with-kubernetes`. Available versions are v1.20.x, v1.21.x, * v1.22.x, * v1.23.x， and v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+### Multi-node cluster
+
+#### Step 1: Generate a configuration file using KubeKey
+
+This command creates a configuration file `sample.yaml` of your cluster.
+
+```bash
+./kk create config --from-cluster
+```
+
+{{< notice note >}}
+
+It assumes your kubeconfig is allocated in `~/.kube/config`. You can change it with the flag `--kubeconfig`.
+
+{{}}
+
+#### Step 2: Edit the configuration file template
+
+Edit `sample.yaml` based on your cluster configuration. Make sure you replace the following fields correctly.
+
+- `hosts`: The basic information of your hosts (hostname and IP address) and how to connect to them using SSH.
+- `roleGroups.etcd`: Your etcd nodes.
+- `controlPlaneEndpoint`: Your load balancer address (optional).
+- `registry`: Your image registry information (optional).
+
+{{< notice note >}}
+
+For more information, see [Edit the configuration file](../../installing-on-linux/introduction/multioverview/#2-edit-the-configuration-file) or refer to the `Cluster` section of [the complete configuration file](https://github.com/kubesphere/kubekey/blob/release-2.2/docs/config-example.md) for more information.
+
+{{}}
+
+#### Step 3: Upgrade your cluster
+The following command upgrades your cluster to KubeSphere 3.3 and Kubernetes v1.22.12:
+
+```bash
+./kk upgrade --with-kubernetes v1.22.12 --with-kubesphere v3.3.2 -f sample.yaml
+```
+
+To upgrade Kubernetes to a specific version, explicitly provide the version after the flag `--with-kubernetes`. Available versions are v1.20.x, v1.21.x, * v1.22.x, * v1.23.x， and v1.24.x. For Kubernetes versions with an asterisk, some features of edge nodes may be unavailable due to incompatability. Therefore, if you want to use edge nodes, you are advised to install Kubernetes v1.21.x.
+
+{{< notice note >}}
+
+To use new features of KubeSphere 3.3, you may need to enable some pluggable components after the upgrade.
+
+{{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/upgrade/what-changed.md b/content/en/docs/v3.4/upgrade/what-changed.md
new file mode 100644
index 000000000..f799ef160
--- /dev/null
+++ b/content/en/docs/v3.4/upgrade/what-changed.md
@@ -0,0 +1,12 @@
+---
+title: "Changes after Upgrade"
+keywords: "Kubernetes, upgrade, KubeSphere, 3.3"
+description: "Understand what will be changed after the upgrade."
+
+linkTitle: "Changes after Upgrade"
+weight: 7600
+---
+
+This section covers the changes after upgrade for existing settings in previous versions. If you want to know all the new features and enhancements in KubeSphere 3.3, see [Release Notes for 3.3.0](../../../v3.3/release/release-v330/), [Release Notes for 3.3.1](../../../v3.3/release/release-v331/), and [Release Notes for 3.3.2](../../../v3.3/release/release-v332/).
+
+
diff --git a/content/en/docs/v3.4/workspace-administration/_index.md b/content/en/docs/v3.4/workspace-administration/_index.md
new file mode 100644
index 000000000..2024f8313
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/_index.md
@@ -0,0 +1,16 @@
+---
+title: "Workspace Administration and User Guide"
+description: "This chapter helps you to better manage KubeSphere workspaces."
+layout: "second"
+
+linkTitle: "Workspace Administration and User Guide"
+
+weight: 9000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+KubeSphere tenants work in a workspace to manage projects and apps. Among others, workspace administrators are responsible for the management of app repositories. Tenants with necessary permissions can further deploy and use app templates from app repositories. They can also leverage individual app templates which are uploaded and released to the App Store. Besides, administrators also control whether the network of a workspace is isolated from others'.
+
+This chapter demonstrates how workspace administrators and tenants work at the workspace level.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/workspace-administration/app-repository/_index.md b/content/en/docs/v3.4/workspace-administration/app-repository/_index.md
new file mode 100644
index 000000000..656e5cfaf
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/app-repository/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "App Repositories"
+weight: 9300
+
+_build:
+ render: false
+---
diff --git a/content/en/docs/v3.4/workspace-administration/app-repository/import-helm-repository.md b/content/en/docs/v3.4/workspace-administration/app-repository/import-helm-repository.md
new file mode 100644
index 000000000..4e9a017f1
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/app-repository/import-helm-repository.md
@@ -0,0 +1,52 @@
+---
+title: "Import a Helm Repository"
+keywords: "Kubernetes, Helm, KubeSphere, Application"
+description: "Import a Helm repository to KubeSphere to provide app templates for tenants in a workspace."
+linkTitle: "Import a Helm Repository"
+weight: 9310
+---
+
+KubeSphere builds app repositories that allow users to use Kubernetes applications based on Helm charts. App repositories are powered by [OpenPitrix](https://github.com/openpitrix/openpitrix), an open source platform for cross-cloud application management sponsored by QingCloud. In an app repository, every application serves as a base package library. To deploy and manage an app from an app repository, you need to create the repository in advance.
+
+To create a repository, you use an HTTP/HTTPS server or object storage solutions to store packages. More specifically, an app repository relies on external storage independent of OpenPitrix, such as [MinIO](https://min.io/) object storage, [QingStor object storage](https://github.com/qingstor), and [AWS object storage](https://aws.amazon.com/what-is-cloud-object-storage/). These object storage services are used to store configuration packages and index files created by developers. After a repository is registered, the configuration packages are automatically indexed as deployable applications.
+
+This tutorial demonstrates how to add an app repository to KubeSphere.
+
+## Prerequisites
+
+- You need to enable the [KubeSphere App Store (OpenPitrix)](../../../pluggable-components/app-store/).
+- You need to have an app repository. Refer to [the official documentation of Helm](https://v2.helm.sh/docs/developing_charts/#the-chart-repository-guide) to create repositories or [upload your own apps to the public repository of KubeSphere](../upload-app-to-public-repository/). Alternatively, use the example repository in the steps below, which is only for demonstration purposes.
+- You need to create a workspace and a user (`ws-admin`). The user must be granted the role of `workspace-admin` in the workspace. For more information, refer to [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Add an App Repository
+
+1. Log in to the web console of KubeSphere as `ws-admin`. In your workspace, go to **App Repositories** under **App Management**, and then click **Add**.
+
+2. In the dialog that appears, specify an app repository name and add your repository URL. For example, enter `https://charts.kubesphere.io/main`.
+
+ - **Name**: Set a simple and clear name for the repository, which is easy for users to identify.
+ - **URL**: Follow the RFC 3986 specification with the following three protocols supported:
+ - S3: The URL is S3-styled, such as `s3.
on the right of a user, and click **OK** for the displayed message to assign the user to the department.
+
+ {{< notice note >}}
+
+ * If permissions provided by the department overlap with existing permissions of the user, new permissions are added to the user. Existing permissions of the user are not affected.
+ * Users assigned to a department can perform operations according to the workspace role, project roles, and DevOps project roles associated with the department without being invited to the workspace, projects, and DevOps projects.
+
+ {{}}
+
+## Remove a User from a Department
+
+1. On the **Departments** page, select a department in the department tree on the left and click **Assigned** on the right.
+2. In the assigned user list, click 
on the right of a user, enter the username in the displayed dialog box, and click **OK** to remove the user.
+
+## Delete and Edit a Department
+
+1. On the **Departments** page, click **Set Departments**.
+
+2. In the **Set Departments** dialog box, on the left, click the upper level of the department to be edited or deleted.
+
+3. Click 
on the right of the department to edit it.
+
+ {{< notice note >}}
+
+ For details, see [Create a Department](#create-a-department).
+
+ {{}}
+
+4. Click on the right of the department, enter the department name in the displayed dialog box, and click **OK** to delete the department.
+
+ {{< notice note >}}
+
+ * If a department contains sub-departments, the sub-departments will also be deleted.
+ * After a department is deleted, the associated roles will be unbound from the users.
+
+ {{}}
\ No newline at end of file
diff --git a/content/en/docs/v3.4/workspace-administration/project-quotas.md b/content/en/docs/v3.4/workspace-administration/project-quotas.md
new file mode 100644
index 000000000..ad59de15f
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/project-quotas.md
@@ -0,0 +1,56 @@
+---
+title: "Project Quotas"
+keywords: 'KubeSphere, Kubernetes, projects, quotas, resources, requests, limits'
+description: 'Set requests and limits to control resource usage in a project.'
+linkTitle: "Project Quotas"
+weight: 9600
+---
+
+KubeSphere uses [Kubernetes requests and limits](https://kubesphere.io/blogs/understand-requests-and-limits-in-kubernetes/) to control resource (for example, CPU and memory) usage in a project, also known as [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/) in Kubernetes. Requests make sure a project can get the resources it needs as they are specifically guaranteed and reserved. On the contrary, limits ensure that a project can never use resources above a certain value.
+
+Besides CPU and memory, you can also set resource quotas for other objects separately such as Pods, [Deployments](../../project-user-guide/application-workloads/deployments/), [Jobs](../../project-user-guide/application-workloads/jobs/), [Services](../../project-user-guide/application-workloads/services/), and [ConfigMaps](../../project-user-guide/configuration/configmaps/) in a project.
+
+This tutorial demonstrates how to configure quotas for a project.
+
+## Prerequisites
+
+You have an available workspace, a project and a user (`ws-admin`). The user must have the `admin` role at the workspace level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+{{< notice note >}}
+
+If you use the user `project-admin` (a user of the `admin` role at the project level), you can set project quotas as well for a new project (i.e. its quotas remain unset). However, `project-admin` cannot change project quotas once they are set. Generally, it is the responsibility of `ws-admin` to set limits and requests for a project. `project-admin` is responsible for [setting limit ranges](../../project-administration/container-limit-ranges/) for containers in a project.
+
+{{}}
+
+## Set Project Quotas
+
+1. Log in to the console as `ws-admin` and go to a project. On the **Overview** page, you can see project quotas remain unset if the project is newly created. Click **Edit Quotas** to configure quotas.
+
+2. In the displayed dialog box, you can see that KubeSphere does not set any requests or limits for a project by default. To set
+limits to control CPU and memory resources, use the slider to move to a desired value or enter numbers directly. Leaving a field blank means you do not set any requests or limits.
+
+ {{< notice note >}}
+
+ The limit can never be lower than the request.
+
+ {{}}
+
+3. To set quotas for other resources, click **Add** under **Project Resource Quotas**, and then select a resource or enter a recource name and set a quota.
+
+4. Click **OK** to finish setting quotas.
+
+5. Go to **Basic Information** in **Project Settings**, and you can see all resource quotas for the project.
+
+6. To change project quotas, click **Edit Project** on the **Basic Information** page and select **Edit Project Quotas**.
+
+ {{< notice note >}}
+
+ For [a multi-cluster project](../../project-administration/project-and-multicluster-project/#multi-cluster-projects), the option **Edit Project Quotas** does not display in the **Manage Project** drop-down menu. To set quotas for a multi-cluster project, go to **Projects Quotas** under **Project Settings** and click **Edit Quotas**. Note that as a multi-cluster project runs across clusters, you can set resource quotas on different clusters separately.
+
+ {{}}
+
+7. Change project quotas in the dialog that appears and click **OK**.
+
+## See Also
+
+[Container Limit Ranges](../../project-administration/container-limit-ranges/)
diff --git a/content/en/docs/v3.4/workspace-administration/role-and-member-management.md b/content/en/docs/v3.4/workspace-administration/role-and-member-management.md
new file mode 100644
index 000000000..eeffc5f4c
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/role-and-member-management.md
@@ -0,0 +1,61 @@
+---
+title: "Workspace Role and Member Management"
+keywords: "Kubernetes, workspace, KubeSphere, multitenancy"
+description: "Customize a workspace role and grant it to tenants."
+linkTitle: "Workspace Role and Member Management"
+weight: 9400
+---
+
+This tutorial demonstrates how to manage roles and members in a workspace.
+
+## Prerequisites
+
+At least one workspace has been created, such as `demo-workspace`. Besides, you need a user of the `workspace-admin` role (for example, `ws-admin`) at the workspace level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+{{< notice note >}}
+
+The actual role name follows a naming convention: `workspace name-role name`. For example, for a workspace named `demo-workspace`, the actual role name of the role `admin` is `demo-workspace-admin`.
+
+{{}}
+
+## Built-in Roles
+
+In **Workspace Roles**, there are four available built-in roles. Built-in roles are created automatically by KubeSphere when a workspace is created and they cannot be edited or deleted. You can only view permissions included in a built-in role or assign it to a user.
+
+| Built-in Roles | Description |
+| ------------------ | ------------------------------------------------------------ |
+| `workspace-viewer` | Workspace viewer who can view all resources in the workspace. |
+| `workspace-self-provisioner` | Workspace regular member who can view workspace settings, manage app templates, and create projects and DevOps projects. |
+| `workspace-regular` | Workspace regular member who can view workspace settings. |
+| `workspace-admin` | Workspace administrator who has full control over all resources in the workspace. |
+
+To view the permissions that a role contains:
+
+1. Log in to the console as `ws-admin`. In **Workspace Roles**, click a role (for example, `workspace-admin`) and you can see role details.
+
+2. Click the **Authorized Users** tab to see all the users that are granted the role.
+
+## Create a Workspace Role
+
+1. Navigate to **Workspace Roles** under **Workspace Settings**.
+
+2. In **Workspace Roles**, click **Create** and set a role **Name** (for example, `demo-project-admin`). Click **Edit Permissions** to continue.
+
+3. In the pop-up window, permissions are categorized into different **Modules**. In this example, click **Project Management** and select **Project Creation**, **Project Management**, and **Project Viewing** for this role. Click **OK** to finish creating the role.
+
+ {{< notice note >}}
+
+ **Depends on** means the major permission (the one listed after **Depends on**) needs to be selected first so that the affiliated permission can be assigned.
+
+ {{}}
+
+4. Newly-created roles will be listed in **Workspace Roles**. To edit the information or permissions, or delete an existing role, click 
on the right.
+
+## Invite a New Member
+
+1. Navigate to **Workspace Members** under **Workspace Settings**, and click **Invite**.
+2. Invite a user to the workspace by clicking 
on the right of it and assign a role to it.
+
+3. After you add the user to the workspace, click **OK**. In **Workspace Members**, you can see the user in the list.
+
+4. To edit the role of an existing user or remove the user from the workspace, click on the right and select the corresponding operation.
\ No newline at end of file
diff --git a/content/en/docs/v3.4/workspace-administration/upload-helm-based-application.md b/content/en/docs/v3.4/workspace-administration/upload-helm-based-application.md
new file mode 100644
index 000000000..1a2236f91
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/upload-helm-based-application.md
@@ -0,0 +1,38 @@
+---
+title: "Upload Helm-based Applications"
+keywords: "Kubernetes, Helm, KubeSphere, OpenPitrix, Application"
+description: "Learn how to upload a Helm-based application as an app template to your workspace."
+linkTitle: "Upload Helm-based Applications"
+weight: 9200
+---
+
+KubeSphere provides full lifecycle management for applications. Among other things, workspace administrators can upload or create new app templates and test them quickly. Furthermore, they publish well-tested apps to the [App Store](../../application-store/) so that other users can deploy them with one click. To develop app templates, workspace administrators need to upload packaged [Helm charts](https://helm.sh/) to KubeSphere first.
+
+This tutorial demonstrates how to develop an app template by uploading a packaged Helm chart.
+
+## Prerequisites
+
+- You need to enable the [KubeSphere App Store (OpenPitrix)](../../pluggable-components/app-store/).
+- You need to create a workspace and a user (`project-admin`). The user must be invited to the workspace with the role of `workspace-self-provisioner`. For more information, refer to [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Hands-on Lab
+
+1. Log in to KubeSphere as `project-admin`. In your workspace, go to **App Templates** under **App Management**, and click **Create**.
+
+2. In the dialog that appears, click **Upload**. You can upload your own Helm chart or download the [Nginx chart](/files/application-templates/nginx-0.1.0.tgz) and use it as an example for the following steps.
+
+3. After the package is uploaded, click **OK** to continue.
+
+4. You can view the basic information of the app under **App Information**. To upload an icon for the app, click **Upload Icon**. You can also skip it and click **OK** directly.
+
+ {{< notice note >}}
+
+Maximum accepted resolutions of the app icon: 96 x 96 pixels.
+
+{{}}
+
+5. The app appears in the template list with the status **Developing** after successfully uploaded, which means this app is under development. The uploaded app is visible to all members in the same workspace.
+
+6. Click the app and the page opens with the **Versions** tab selected. Click the draft version to expand the menu, where you can see options including **Delete**, **Install**, and **Submit for Release**.
+
+7. For more information about how to release your app to the App Store, refer to [Application Lifecycle Management](../../application-store/app-lifecycle-management/#step-2-upload-and-submit-application).
diff --git a/content/en/docs/v3.4/workspace-administration/what-is-workspace.md b/content/en/docs/v3.4/workspace-administration/what-is-workspace.md
new file mode 100644
index 000000000..98e650db7
--- /dev/null
+++ b/content/en/docs/v3.4/workspace-administration/what-is-workspace.md
@@ -0,0 +1,83 @@
+---
+title: "Workspace Overview"
+keywords: "Kubernetes, KubeSphere, workspace"
+description: "Understand the concept of workspaces in KubeSphere and learn how to create and delete a workspace."
+
+linkTitle: "Workspace Overview"
+weight: 9100
+---
+
+A workspace is a logical unit to organize your [projects](../../project-administration/) and [DevOps projects](../../devops-user-guide/) and manage [app templates](../upload-helm-based-application/) and app repositories. It is the place for you to control resource access and share resources within your team in a secure way.
+
+It is a best practice to create a new workspace for tenants (excluding cluster administrators). A same tenant can work in multiple workspaces, while a workspace allows multiple tenants to access it in different ways.
+
+This tutorial demonstrates how to create and delete a workspace.
+
+## Prerequisites
+
+You have a user granted the role of `workspaces-manager`, such as `ws-manager` in [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
+
+## Create a Workspace
+
+1. Log in to the web console of KubeSphere as `ws-manager`. Click **Platform** on the upper-left corner, and then select **Access Control**. On the **Workspaces** page, click **Create**.
+
+
+2. For single-node cluster, on the **Basic Information** page, specify a name for the workspace and select an administrator from the drop-down list. Click **Create**.
+
+ - **Name**: Set a name for the workspace which serves as a unique identifier.
+ - **Alias**: An alias name for the workspace.
+ - **Administrator**: User that administers the workspace.
+ - **Description**: A brief introduction of the workspace.
+
+ For multi-node cluster, after the basic information about the workspace is set, click **Next** to continue. On the **Cluster Settings** page, select clusters to be used in the workspace, and then click **Create**.
+
+3. The workspace is displayed in the workspace list after it is created.
+
+4. Click the workspace and you can see resource status of the workspace on the **Overview** page.
+
+## Delete a Workspace
+
+In KubeSphere, you use a workspace to group and manage different projects, which means the lifecycle of a project is dependent on the workspace. More specifically, all the projects and related resources in a workspace will be deleted if the workspace is deleted.
+
+Before you delete a workspace, decide whether you want to unbind some key projects.
+
+### Unbind projects before deletion
+
+To delete a workspace while preserving some projects in it, run the following command first:
+
+```bash
+kubectl label ns 
to a desired value or enter numbers directly. Leaving a field blank means you do not set any requests or limits.
+
+ {{< notice note >}}
+
+ The limit can never be lower than the request.
+
+ {{}}
+
+5. Click **OK** to finish setting quotas.
+
+## See Also
+
+[Project Quotas](../project-quotas/)
+
+[Container Limit Ranges](../../project-administration/container-limit-ranges/)
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/_index.md b/content/zh/docs/v3.4/_index.md
new file mode 100644
index 000000000..89937bc3e
--- /dev/null
+++ b/content/zh/docs/v3.4/_index.md
@@ -0,0 +1,62 @@
+---
+title: "Documentation"
+css: "scss/docs.scss"
+isDocsRoot: true
+
+LinkTitle: "文档"
+
+
+section1:
+ title: KubeSphere 文档
+ content: 了解如何通过 KubeSphere 容器平台构建并管理云原生应用程序。获取文档、示例代码与教程等信息。
+ image: /images/docs/v3.3/banner.png
+
+sectionLink:
+ docs:
+ title: 常用文档
+ description: 通过快速入门、教程和示例等学习使用 KubeSphere。
+ list:
+ - /docs/v3.3/quick-start/all-in-one-on-linux
+ - /docs/v3.3/quick-start/minimal-kubesphere-on-k8s
+ - /docs/v3.3/quick-start/create-workspace-and-project
+ - /docs/v3.3/introduction/what-is-kubesphere
+ - /docs/v3.3/pluggable-components
+ - /docs/v3.3/installing-on-linux/introduction/multioverview
+ - /docs/v3.3/pluggable-components/app-store
+ - /docs/v3.3/pluggable-components/devops
+ - /docs/v3.3/multicluster-management
+ - /docs/v3.3/project-user-guide/configuration/image-registry
+ - /docs/v3.3/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-jenkinsfile
+ - /docs/v3.3/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel
+ - /docs/v3.3/project-user-guide/image-builder/source-to-image
+ - /docs/v3.3/application-store/app-lifecycle-management
+
+ videos:
+ title: 视频教程
+ description: 观看视频教程学习 KubeSphere。
+ list:
+ - link: https://www.bilibili.com/video/BV1KA411s7D3
+ text: All-in-One 模式安装 KubeSphere
+ - link: https://www.bilibili.com/video/BV16y4y1v7cn
+ text: 多节点安装 KubeSphere
+ - link: https://www.bilibili.com/video/BV1Pz4y1C7jr
+ text: 离线安装 KubeSphere
+
+section3:
+ title: 在云服务上运行 KubeSphere 与 Kubernetes 技术栈
+ description: 云厂商以托管的形式为用户提供 KubeSphere 服务，深度集成了公有云托管容器服务，用户可在几分钟内通过简单的步骤迅速构建高可用集群。您可在以下公有云上一键部署 KubeSphere。
+ list:
+ - image: /images/docs/v3.3/aws.jpg
+ content: AWS Quickstart
+ link: https://aws.amazon.com/quickstart/architecture/qingcloud-kubesphere/
+ - image: /images/docs/v3.3/microsoft-azure.jpg
+ content: Azure Marketplace
+ link: https://market.azure.cn/marketplace/apps/qingcloud.kubesphere
+ - image: /images/docs/v3.3/qingcloud.svg
+ content: QingCloud QKE
+ link: https://www.qingcloud.com/products/kubesphereqke/
+
+ titleRight: 想要在您的云上托管 KubeSphere?
+ btnContent: 与我们合作
+ btnLink: /partner/
+---
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/_index.md b/content/zh/docs/v3.4/access-control-and-account-management/_index.md
new file mode 100644
index 000000000..6bb2d9195
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/_index.md
@@ -0,0 +1,13 @@
+---
+title: "帐户管理和权限控制"
+description: "帐户管理和权限控制"
+layout: "second"
+
+linkTitle: "帐户管理和权限控制"
+weight: 12000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+KubeSphere 的多租户架构是运行在容器平台上的许多关键组件的基础。不同的租户被分配不同的角色，以便他们可以执行相关的任务。本章概述了 KubeSphere 的多租户系统，并演示了如何为第三方登录配置身份验证。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/_index.md b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/_index.md
new file mode 100644
index 000000000..fe7156336
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/_index.md
@@ -0,0 +1,8 @@
+---
+title: "外部身份验证"
+description: "了解如何在 KubeSphere 上配置第三方身份验证。"
+layout: "single"
+
+linkTitle: "外部身份验证"
+weight: 12200
+---
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/cas-identity-provider.md b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/cas-identity-provider.md
new file mode 100644
index 000000000..eb05799c6
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/cas-identity-provider.md
@@ -0,0 +1,58 @@
+---
+title: "CAS 身份提供者"
+keywords: "CAS, 身份提供者"
+description: "如何使用外部 CAS 身份提供者。"
+
+linkTitle: "CAS 身份提供者"
+weight: 12223
+---
+
+CAS (Central Authentication Service) 是耶鲁 Yale 大学发起的一个java开源项目，旨在为 Web应用系统提供一种可靠的 单点登录 解决方案（ Web SSO ）， CAS 具有以下特点：
+
+- 开源的企业级单点登录解决方案
+- CAS Server 为需要独立部署的 Web 应用----一个独立的Web应用程序(cas.war)。
+- CAS Client 支持非常多的客户端 ( 指单点登录系统中的各个 Web 应用 ) ，包括 Java, .Net, PHP, Perl, 等。
+
+
+## 准备工作
+
+您需要部署一个 Kubernetes 集群，并在集群中安装 KubeSphere。有关详细信息，请参阅[在 Linux 上安装](../../../installing-on-linux/)和[在 Kubernetes 上安装](../../../installing-on-kubernetes/)。
+
+## 步骤
+
+1. 以 `admin` 身份登录 KubeSphere，将光标移动到右下角 ，点击 **kubectl**，然后执行以下命令来编辑 CRD `ClusterConfiguration` 中的 `ks-installer`：
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. 在 `spec.authentication.jwtSecret` 字段下添加以下字段。
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: cas
+ type: CASIdentityProvider
+ mappingMethod: auto
+ provider:
+ redirectURL: "https://ks-console:30880/oauth/redirect/cas"
+ casServerURL: "https://cas.example.org/cas"
+ insecureSkipVerify: true
+ ```
+
+ 字段描述如下：
+
+ | 参数 | 描述 |
+ | -------------------- | ------------------------------------------------------------ |
+ | redirectURL | 重定向到 ks-console 的 URL，格式为：`https://<域名>/oauth/redirect/<身份提供者名称>`。URL 中的 `<身份提供者名称>` 对应 `oauthOptions:identityProviders:name` 的值。 |
+ | casServerURL | 定义cas 认证的url 地址 |
+ | insecureSkipVerify | 关闭 TLS 证书验证。 |
+
+
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/oidc-identity-provider.md b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/oidc-identity-provider.md
new file mode 100644
index 000000000..fa144bc98
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/oidc-identity-provider.md
@@ -0,0 +1,64 @@
+---
+title: "OIDC 身份提供者"
+keywords: "OIDC, 身份提供者"
+description: "如何使用外部 OIDC 身份提供者。"
+
+linkTitle: "OIDC 身份提供者"
+weight: 12221
+---
+
+## OIDC 身份提供者
+
+[OpenID Connect](https://openid.net/connect/) 是一种基于 OAuth 2.0 系列规范的可互操作的身份认证协议。使用简单的 REST/JSON 消息流，其设计目标是“让简单的事情变得简单，让复杂的事情成为可能”。与之前的任何身份认证协议（例如 Keycloak、Okta、Dex、Auth0、Gluu、Casdoor 等）相比，开发人员集成起来非常容易。
+
+## 准备工作
+
+您需要部署一个 Kubernetes 集群，并在集群中安装 KubeSphere。有关详细信息，请参阅[在 Linux 上安装](../../../installing-on-linux/)和[在 Kubernetes 上安装](../../../installing-on-kubernetes/)。
+
+## 步骤
+
+1. 以 `admin` 身份登录 KubeSphere，将光标移动到右下角 ，点击 **kubectl**，然后执行以下命令来编辑 CRD `ClusterConfiguration` 中的 `ks-installer`：
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. 在 `spec.authentication.jwtSecret` 字段下添加以下字段。
+
+ *使用 [Google Identity Platform](https://developers.google.com/identity/protocols/oauth2/openid-connect) 的示例*：
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: google
+ type: OIDCIdentityProvider
+ mappingMethod: auto
+ provider:
+ clientID: '********'
+ clientSecret: '********'
+ issuer: https://accounts.google.com
+ redirectURL: 'https://ks-console/oauth/redirect/google'
+ ```
+
+ 字段描述如下：
+
+ | 参数 | 描述 |
+ | -------------------- | ------------------------------------------------------------ |
+ | clientID | 客户端 ID。 |
+ | clientSecret | 客户端密码。 |
+ | redirectURL | 重定向到 ks-console 的 URL，格式为：`https://<域名>/oauth/redirect/<身份提供者名称>`。URL 中的 `<身份提供者名称>` 对应 `oauthOptions:identityProviders:name` 的值。 |
+ | issuer | 定义客户端如何动态发现有关 OpenID 提供者的信息。 |
+ | preferredUsernameKey | 可配置的密钥，包含首选用户声明。此参数为可选参数。 |
+ | emailKey | 可配置的密钥，包含电子邮件声明。此参数为可选参数。 |
+ | getUserInfo | 使用 userinfo 端点获取令牌的附加声明。非常适用于上游返回 “thin” ID 令牌的场景。此参数为可选参数。 |
+ | insecureSkipVerify | 关闭 TLS 证书验证。 |
+
+
+
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/set-up-external-authentication.md b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/set-up-external-authentication.md
new file mode 100644
index 000000000..bc880d62b
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/external-authentication/set-up-external-authentication.md
@@ -0,0 +1,112 @@
+---
+title: "设置外部身份验证"
+keywords: "LDAP, 外部, 第三方, 身份验证"
+description: "如何在 KubeSphere 上设置外部身份验证。"
+
+linkTitle: "设置外部身份验证"
+weight: 12210
+---
+
+本文档描述了如何在 KubeSphere 上使用外部身份提供者，例如 LDAP 服务或 Active Directory 服务。
+
+KubeSphere 提供了一个内置的 OAuth 服务。用户通过获取 OAuth 访问令牌以对 API 进行身份验证。作为 KubeSphere 管理员，您可以编辑 CRD `ClusterConfiguration` 中的 `ks-installer` 来配置 OAuth 并指定身份提供者。
+
+## 准备工作
+
+您需要部署一个 Kubernetes 集群，并在集群中安装 KubeSphere。有关详细信息，请参阅[在 Linux 上安装](../../../installing-on-linux/)和[在 Kubernetes 上安装](../../../installing-on-kubernetes/)。
+
+
+## 步骤
+
+1. 以 `admin` 身份登录 KubeSphere，将光标移动到右下角 ，点击 **kubectl**，然后执行以下命令来编辑 CRD `ClusterConfiguration` 中的 `ks-installer`：
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. 在 `spec.authentication.jwtSecret` 字段下添加以下字段。
+
+ 示例:
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ loginHistoryRetentionPeriod: 168h
+ maximumClockSkew: 10s
+ multipleLogin: true
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: LDAP
+ type: LDAPIdentityProvider
+ mappingMethod: auto
+ provider:
+ host: 192.168.0.2:389
+ managerDN: uid=root,cn=users,dc=nas
+ managerPassword: ********
+ userSearchBase: cn=users,dc=nas
+ loginAttribute: uid
+ mailAttribute: mail
+ ```
+
+ 字段描述如下：
+
+ * `jwtSecret`：签发用户令牌的密钥。在多集群环境下，所有的集群必须[使用相同的密钥](../../../multicluster-management/enable-multicluster/direct-connection/#prepare-a-member-cluster)。
+ * `authenticateRateLimiterMaxTries`：`authenticateLimiterDuration` 指定的期间内允许的最大连续登录失败次数。如果用户连续登录失败次数达到限制，则该用户将被封禁。
+ * `authenticateRateLimiterDuration`：`authenticateRateLimiterMaxTries` 适用的时间段。
+ * `loginHistoryRetentionPeriod`：用户登录记录保留期限，过期的登录记录将被自动删除。
+ * `maximumClockSkew`：时间敏感操作（例如验证用户令牌的过期时间）的最大时钟偏差，默认值为10秒。
+ * `multipleLogin`：是否允许多个用户同时从不同位置登录，默认值为 `true`。
+ * `oauthOptions`：
+ * `accessTokenMaxAge`：访问令牌有效期。对于多集群环境中的成员集群，默认值为 `0h`，这意味着访问令牌永不过期。对于其他集群，默认值为 `2h`。
+ * `accessTokenInactivityTimeout`：令牌空闲超时时间。该值表示令牌过期后，刷新用户令牌最大的间隔时间，如果不在此时间窗口内刷新用户身份令牌，用户将需要重新登录以获得访问权。
+ * `identityProviders`：
+ * `name`：身份提供者的名称。
+ * `type`：身份提供者的类型。
+ * `mappingMethod`：帐户映射方式，值可以是 `auto` 或者 `lookup`。
+ * 如果值为 `auto`（默认），需要指定新的用户名。通过第三方帐户登录时，KubeSphere 会根据用户名自动创建关联帐户。
+ * 如果值为 `lookup`，需要执行步骤 3 以手动关联第三方帐户与 KubeSphere 帐户。
+ * `provider`：身份提供者信息。此部分中的字段根据身份提供者的类型而异。
+
+3. 如果 `mappingMethod` 设置为 `lookup`，可以运行以下命令并添加标签来进行帐户关联。如果 `mappingMethod` 是 `auto` 可以跳过这个部分。
+
+ ```bash
+ kubectl edit user ，点击 **kubectl**，然后执行以下命令来编辑 CRD `ClusterConfiguration` 中的 `ks-installer`：
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+ 示例：
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ maximumClockSkew: 10s
+ multipleLogin: true
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: LDAP
+ type: LDAPIdentityProvider
+ mappingMethod: auto
+ provider:
+ host: 192.168.0.2:389
+ managerDN: uid=root,cn=users,dc=nas
+ managerPassword: ********
+ userSearchBase: cn=users,dc=nas
+ loginAttribute: uid
+ mailAttribute: mail
+ ```
+
+2. 在 `spec:authentication` 部分配置 `oauthOptions:identityProviders` 以外的字段信息请参阅[设置外部身份认证](../set-up-external-authentication/)。
+
+3. 在 `oauthOptions:identityProviders` 部分配置字段。
+
+ * `name`: 用户定义的 LDAP 服务名称。
+ * `type`: 必须将该值设置为 `LDAPIdentityProvider` 才能将 LDAP 服务用作身份提供者。
+ * `mappingMethod`: 帐户映射方式，值可以是 `auto` 或者 `lookup`。
+ * 如果值为 `auto`（默认），需要指定新的用户名。KubeSphere 根据用户名自动创建并关联 LDAP 用户。
+ * 如果值为 `lookup`，需要执行步骤 4 以手动关联现有 KubeSphere 用户和 LDAP 用户。
+ * `provider`:
+ * `host`: LDAP 服务的地址和端口号。
+ * `managerDN`: 用于绑定到 LDAP 目录的 DN 。
+ * `managerPassword`: `managerDN` 对应的密码。
+ * `userSearchBase`: 用户搜索基。设置为所有 LDAP 用户所在目录级别的 DN 。
+ * `loginAttribute`: 标识 LDAP 用户的属性。
+ * `mailAttribute`: 标识 LDAP 用户的电子邮件地址的属性。
+
+4. 如果 `mappingMethod` 设置为 `lookup`，可以运行以下命令并添加标签来进行帐户关联。如果 `mappingMethod` 是 `auto` 可以跳过这个部分。
+
+ ```bash
+ kubectl edit user ，点击 **kubectl**，然后执行以下命令来编辑 CRD `ClusterConfiguration` 中的 `ks-installer`：
+
+ ```bash
+ kubectl -n kubesphere-system edit cc ks-installer
+ ```
+
+2. 在 `spec:authentication` 部分配置的 `oauthOptions:identityProviders` 以外的字段信息请参阅[设置外部身份认证](../set-up-external-authentication/)。
+
+3. 根据开发的身份提供者插件来配置 `oauthOptions:identityProviders` 中的字段。
+
+ 以下是使用 GitHub 作为外部身份提供者的配置示例。详情请参阅 [GitHub 官方文档](https://docs.github.com/en/developers/apps/building-oauth-apps)和 [GitHubIdentityProvider 源代码](https://github.com/kubesphere/kubesphere/blob/release-3.1/pkg/apiserver/authentication/identityprovider/github/github.go) 。
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ authenticateRateLimiterMaxTries: 10
+ authenticateRateLimiterDuration: 10m0s
+ oauthOptions:
+ accessTokenMaxAge: 1h
+ accessTokenInactivityTimeout: 30m
+ identityProviders:
+ - name: github
+ type: GitHubIdentityProvider
+ mappingMethod: auto
+ provider:
+ clientID: '******'
+ clientSecret: '******'
+ redirectURL: 'https://ks-console/oauth/redirect/github'
+ ```
+
+ 同样，您也可以使用阿里云 IDaaS 作为外部身份提供者。详情请参阅[阿里云 IDaaS 文档](https://www.alibabacloud.com/help/product/111120.htm?spm=a3c0i.14898238.2766395700.1.62081da1NlxYV0)和 [AliyunIDaasProvider 源代码](https://github.com/kubesphere/kubesphere/blob/release-3.1/pkg/apiserver/authentication/identityprovider/aliyunidaas/idaas.go)。
+
+4. 字段配置完成后，保存修改，然后等待 ks-installer 完成重启。
+
+ {{< notice note >}}
+
+ KubeSphere Web 控制台在 ks-installer 重新启动期间不可用。请等待重启完成。
+
+ {{}}
+
+5. 进入 KubeSphere 登录界面，点击 **Log In with XXX** （例如，**Log In with GitHub**）。
+
+6. 在外部身份提供者的登录界面，输入身份提供者配置的用户名和密码，登录 KubeSphere 。
+
+ 
+
diff --git a/content/zh/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md b/content/zh/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md
new file mode 100644
index 000000000..a82d14e8e
--- /dev/null
+++ b/content/zh/docs/v3.4/access-control-and-account-management/multi-tenancy-in-kubesphere.md
@@ -0,0 +1,57 @@
+---
+title: "KubeSphere 中的多租户"
+keywords: "Kubernetes, KubeSphere, 多租户"
+description: "理解 KubeSphere 中的多租户架构。"
+linkTitle: "KubeSphere 中的多租户"
+weight: 12100
+---
+
+Kubernetes 解决了应用编排、容器调度的难题，极大地提高了资源的利用率。有别于传统的集群运维方式，在使用 Kubernetes 的过程中，企业和个人用户在资源共享和安全性方面均面临着诸多挑战。
+
+首当其冲的就是企业环境中多租户形态该如何定义，租户的安全边界该如何划分。Kubernetes 社区[关于多租户的讨论](https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY)从未停歇，但到目前为止最终的形态尚无定论。
+
+## Kubernetes 多租户面临的挑战
+
+多租户是一种常见的软件架构，简单概括就是在多用户环境下实现资源共享，并保证各用户间数据的隔离性。在多租户集群环境中，集群管理员需要最大程度地避免恶意租户对其他租户的攻击，公平地分配集群资源。
+
+无论企业的多租户形态如何，多租户都无法避免以下两个层面的问题：逻辑层面的资源隔离；物理资源的隔离。
+
+逻辑层面的资源隔离主要包括 API 的访问控制，针对用户的权限控制。Kubernetes 中的 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 和命名空间 (namespace) 提供了基本的逻辑隔离能力，但在大部分企业环境中并不适用。企业中的租户往往需要跨多个命名空间甚至是多个集群进行资源管理。除此之外，针对用户的行为审计、租户隔离的日志、事件查询也是不可或缺的能力。
+
+物理资源的隔离主要包括节点、网络的隔离，当然也包括容器运行时安全。您可以通过 [NetworkPolicy](../../pluggable-components/network-policy/) 对网络进行划分，通过 PodSecurityPolicy 限制容器的行为，[Kata Containers](https://katacontainers.io/) 也提供了更安全的容器运行时。
+
+## KubeSphere 中的多租户
+
+为了解决上述问题，KubeSphere 提供了基于 Kubernetes 的多租户管理方案。
+
+
+
+在 KubeSphere 中[企业空间](../../workspace-administration/what-is-workspace/)是最小的租户单元，企业空间提供了跨集群、跨项目（即 Kubernetes 中的命名空间）共享资源的能力。企业空间中的成员可以在授权集群中创建项目，并通过邀请授权的方式参与项目协同。
+
+**用户**是 KubeSphere 的帐户实例，可以被设置为平台层面的管理员参与集群的管理，也可以被添加到企业空间中参与项目协同。
+
+多级的权限控制和资源配额限制是 KubeSphere 中资源隔离的基础，奠定了多租户最基本的形态。
+
+### 逻辑隔离
+
+与 Kubernetes 相同，KubeSphere 通过 RBAC 对用户的权限加以控制，实现逻辑层面的资源隔离。
+
+KubeSphere 中的权限控制分为平台、企业空间、项目三个层级，通过角色来控制用户在不同层级的资源访问权限。
+
+1. [平台角色](../../quick-start/create-workspace-and-project/)：主要控制用户对平台资源的访问权限，如集群的管理、企业空间的管理、平台用户的管理等。
+2. [企业空间角色](../../workspace-administration/role-and-member-management/)：主要控制企业空间成员在企业空间下的资源访问权限，如企业空间下项目、DevOps 项目的管理等。
+3. [项目角色](../../project-administration/role-and-member-management/)：主要控制项目下资源的访问权限，如工作负载的管理、流水线的管理等。
+
+### 网络隔离
+
+除了逻辑层面的资源隔离，KubeSphere 中还可以针对企业空间和项目设置[网络隔离策略](../../pluggable-components/network-policy/)。
+
+### 操作审计
+
+KubeSphere 还提供了针对用户的[操作审计](../../pluggable-components/auditing-logs/)。
+
+### 认证鉴权
+
+KubeSphere 完整的认证鉴权链路如下图所示，可以通过 OPA 拓展 Kubernetes 的 RBAC 规则。KubeSphere 团队计划集成 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 以支持更为丰富的安全管控策略。
+
+
diff --git a/content/zh/docs/v3.4/application-store/_index.md b/content/zh/docs/v3.4/application-store/_index.md
new file mode 100644
index 000000000..26fc4d589
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/_index.md
@@ -0,0 +1,16 @@
+---
+title: "应用商店"
+description: "上手 KubeSphere 应用商店"
+layout: "second"
+
+
+linkTitle: "应用商店"
+weight: 14000
+
+icon: "/images/docs/v3.3/docs.svg"
+
+---
+
+KubeSphere 应用商店基于 [OpenPitrix](https://github.com/openpitrix/openpitrix) （一个跨云管理应用的开源平台）为用户提供企业就绪的容器化解决方案。您可以通过应用模板上传自己的应用，或者添加应用仓库作为应用工具，供租户选择他们想要的应用。
+
+应用商店为应用生命周期管理提供了一个高效的集成系统，用户可以用最合适的方式快速上传、发布、部署、升级和下架应用。因此，开发者借助 KubeSphere 就能减少花在设置上的时间，更多地专注于开发。
diff --git a/content/zh/docs/v3.4/application-store/app-developer-guide/_index.md b/content/zh/docs/v3.4/application-store/app-developer-guide/_index.md
new file mode 100644
index 000000000..cb4e2189f
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/app-developer-guide/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "应用开发者指南"
+weight: 14400
+
+_build:
+ render: false
+---
diff --git a/content/zh/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md b/content/zh/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md
new file mode 100644
index 000000000..3b2a72436
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/app-developer-guide/helm-developer-guide.md
@@ -0,0 +1,158 @@
+---
+title: "Helm 开发者指南"
+keywords: 'Kubernetes, KubeSphere, Helm, 开发'
+description: '开发基于 Helm 的应用。'
+linkTitle: "Helm 开发者指南"
+weight: 14410
+---
+
+您可以上传应用的 Helm Chart 至 KubeSphere，以便具有必要权限的租户能够进行部署。本教程以 NGINX 为示例演示如何准备 Helm Chart。
+
+## 安装 Helm
+
+如果您已经安装 KubeSphere，那么您的环境中已部署 Helm。如果未安装，请先参考 [Helm 文档](https://helm.sh/docs/intro/install/)安装 Helm。
+
+## 创建本地仓库
+
+执行以下命令在您的机器上创建仓库。
+
+```bash
+mkdir helm-repo
+```
+
+```bash
+cd helm-repo
+```
+
+## 创建应用
+
+使用 `helm create` 创建一个名为 `nginx` 的文件夹，它会自动为您的应用创建 YAML 模板和目录。一般情况下，不建议修改顶层目录中的文件名和目录名。
+
+```bash
+$ helm create nginx
+$ tree nginx/
+nginx/
+├── charts
+├── Chart.yaml
+├── templates
+│ ├── deployment.yaml
+│ ├── _helpers.tpl
+│ ├── ingress.yaml
+│ ├── NOTES.txt
+│ └── service.yaml
+└── values.yaml
+```
+
+`Chart.yaml` 用于定义 Chart 的基本信息，包括名称、API 和应用版本。有关更多信息，请参见 [Chart.yaml 文件](../helm-specification/#chartyaml-文件)。
+
+该 `Chart.yaml` 文件的示例：
+
+```yaml
+apiVersion: v1
+appVersion: "1.0"
+description: A Helm chart for Kubernetes
+name: nginx
+version: 0.1.0
+```
+
+当您向 Kubernetes 部署基于 Helm 的应用时，可以直接在 KubeSphere 控制台上编辑 `values.yaml` 文件。
+
+该 `values.yaml` 文件的示例：
+
+```yaml
+# 默认值仅供测试使用。
+# 此文件为 YAML 格式。
+# 对要传入您的模板的变量进行声明。
+
+replicaCount: 1
+
+image:
+ repository: nginx
+ tag: stable
+ pullPolicy: IfNotPresent
+
+nameOverride: ""
+fullnameOverride: ""
+
+service:
+ type: ClusterIP
+ port: 80
+
+ingress:
+ enabled: false
+ annotations: {}
+ # kubernetes.io/ingress.class: nginx
+ # kubernetes.io/tls-acme: "true"
+ path: /
+ hosts:
+ - chart-example.local
+ tls: []
+ # - secretName: chart-example-tls
+ # hosts:
+ # - chart-example.local
+
+resources: {}
+ # 通常不建议对默认资源进行指定，用户可以去主动选择是否指定。
+ # 这也有助于 Chart 在资源较少的环境上运行，例如 Minikube。
+ # 如果您要指定资源，请将下面几行内容取消注释，
+ # 按需调整，并删除 'resources:' 后面的大括号。
+ # limits:
+ # cpu: 100m
+ # memory: 128Mi
+ # requests:
+ # cpu: 100m
+ # memory: 128Mi
+
+nodeSelector: {}
+
+tolerations: []
+
+affinity: {}
+```
+
+请参考 [Helm 规范](../helm-specification/)对 `nginx` 文件夹中的文件进行编辑，完成编辑后进行保存。
+
+## 创建索引文件（可选）
+
+要在 KubeSphere 中使用 HTTP 或 HTTPS URL 添加仓库，您需要事先向对象存储上传一个 `index.yaml` 文件。在 `nginx` 的上一个目录中使用 Helm 执行以下命令，创建索引文件。
+
+```bash
+helm repo index .
+```
+
+```bash
+$ ls
+index.yaml nginx
+```
+
+{{< notice note >}}
+
+- 如果仓库 URL 是 S3 格式，您向仓库添加应用时会自动在对象存储中创建索引文件。
+
+- 有关何如向 KubeSphere 添加仓库的更多信息，请参见[导入 Helm 仓库](../../../workspace-administration/app-repository/import-helm-repository/)。
+
+{{}}
+
+## 打包 Chart
+
+前往 `nginx` 的上一个目录，执行以下命令打包您的 Chart，这会创建一个 .tgz 包。
+
+```bash
+helm package nginx
+```
+
+```bash
+$ ls
+nginx nginx-0.1.0.tgz
+```
+
+## 上传您的应用
+
+现在您已经准备好了基于 Helm 的应用，您可以将它上传至 KubeSphere 并在平台上进行测试。
+
+## 另请参见
+
+[Helm 规范](../helm-specification/)
+
+[导入 Helm 仓库](../../../workspace-administration/app-repository/import-helm-repository/)
+
diff --git a/content/zh/docs/v3.4/application-store/app-developer-guide/helm-specification.md b/content/zh/docs/v3.4/application-store/app-developer-guide/helm-specification.md
new file mode 100644
index 000000000..c33f28596
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/app-developer-guide/helm-specification.md
@@ -0,0 +1,131 @@
+---
+title: "Helm 规范"
+keywords: 'Kubernetes, KubeSphere, Helm, 规范'
+description: '了解 Chart 结构和规范。'
+linkTitle: "Helm 规范"
+weight: 14420
+---
+
+Helm Chart 是一种打包格式。Chart 是一个描述一组 Kubernetes 相关资源的文件集合。有关更多信息，请参见 [Helm 文档](https://helm.sh/zh/docs/topics/charts/)。
+
+## 结构
+
+Chart 的所有相关文件都存储在一个目录中，该目录通常包含：
+
+```text
+chartname/
+ Chart.yaml # 包含 Chart 基本信息（例如版本和名称）的 YAML 文件。
+ LICENSE # （可选）包含 Chart 许可证的纯文本文件。
+ README.md # （可选）应用说明和使用指南。
+ values.yaml # 该 Chart 的默认配置值。
+ values.schema.json # （可选）向 values.yaml 文件添加结构的 JSON Schema。
+ charts/ # 一个目录，包含该 Chart 所依赖的任意 Chart。
+ crds/ # 定制资源定义。
+ templates/ # 模板的目录，若提供相应值便可以生成有效的 Kubernetes 配置文件。
+ templates/NOTES.txt # （可选）包含使用说明的纯文本文件。
+```
+
+## Chart.yaml 文件
+
+您必须为 Chart 提供 `chart.yaml` 文件。下面是一个示例文件，每个字段都有说明。
+
+```yaml
+apiVersion: （必需）Chart API 版本。
+name: （必需）Chart 名称。
+version: （必需）版本，遵循 SemVer 2 标准。
+kubeVersion: （可选）兼容的 Kubernetes 版本，遵循 SemVer 2 标准。
+description: （可选）对应用的一句话说明。
+type: （可选）Chart 的类型。
+keywords:
+ - （可选）关于应用的关键字列表。
+home: （可选）应用的 URL。
+sources:
+ - （可选）应用源代码的 URL 列表。
+dependencies: （可选）Chart 必要条件的列表。
+ - name: Chart 的名称，例如 nginx。
+ version: Chart 的版本，例如 "1.2.3"。
+ repository: 仓库 URL ("https://example.com/charts") 或别名 ("@repo-name")。
+ condition: （可选）解析为布尔值的 YAML 路径，用于启用/禁用 Chart （例如 subchart1.enabled）。
+ tags: （可选）
+ - 用于将 Chart 分组，一同启用/禁用。
+ import-values: （可选）
+ - ImportValues 保存源值到待导入父键的映射。每一项可以是字符串或者一对子/父子列表项。
+ alias: （可选）Chart 要使用的别名。当您要多次添加同一个 Chart 时，它会很有用。
+maintainers: （可选）
+ - name: （必需）维护者姓名。
+ email: （可选）维护者电子邮件。
+ url: （可选）维护者 URL。
+icon: （可选）要用作图标的 SVG 或 PNG 图片的 URL。
+appVersion: （可选）应用版本。不需要是 SemVer。
+deprecated: （可选，布尔值）该 Chart 是否已被弃用。
+annotations:
+ example: （可选）按名称输入的注解列表。
+```
+
+{{< notice note >}}
+
+- `dependencies` 字段用于定义 Chart 依赖项，`v1` Chart 的依赖项都位于单独文件 `requirements.yaml` 中。有关更多信息，请参见 [Chart 依赖项](https://helm.sh/zh/docs/topics/charts/#chart-dependency)。
+- `type` 字段用于定义 Chart 的类型。允许的值有 `application` 和 `library`。有关更多信息，请参见 [Chart 类型](https://helm.sh/zh/docs/topics/charts/#chart-types)。
+
+{{}}
+
+## Values.yaml 和模板
+
+Helm Chart 模板采用 [Go 模板语言](https://golang.org/pkg/text/template/)编写并存储在 Chart 的 `templates` 文件夹。有两种方式可以为模板提供值：
+
+1. 在 Chart 中创建一个包含可供引用的默认值的 `values.yaml` 文件。
+2. 创建一个包含必要值的 YAML 文件，通过在命令行使用 `helm install` 命令来使用该文件。
+
+下面是 `templates` 文件夹中模板的示例。
+
+```yaml
+apiVersion: v1
+kind: ReplicationController
+metadata:
+ name: deis-database
+ namespace: deis
+ labels:
+ app.kubernetes.io/managed-by: deis
+spec:
+ replicas: 1
+ selector:
+ app.kubernetes.io/name: deis-database
+ template:
+ metadata:
+ labels:
+ app.kubernetes.io/name: deis-database
+ spec:
+ serviceAccount: deis-database
+ containers:
+ - name: deis-database
+ image: {{.Values.imageRegistry}}/postgres:{{.Values.dockerTag}}
+ imagePullPolicy: {{.Values.pullPolicy}}
+ ports:
+ - containerPort: 5432
+ env:
+ - name: DATABASE_STORAGE
+ value: {{default "minio" .Values.storage}}
+```
+
+上述示例在 Kubernetes 中定义 ReplicationController 模板，其中引用的一些值已在 `values.yaml` 文件中进行定义。
+
+- `imageRegistry`：Docker 镜像仓库。
+- `dockerTag`：Docker 镜像标签 (tag)。
+- `pullPolicy`：镜像拉取策略。
+- `storage`：存储后端，默认为 `minio`。
+
+下面是 `values.yaml` 文件的示例：
+
+```text
+imageRegistry: "quay.io/deis"
+dockerTag: "latest"
+pullPolicy: "Always"
+storage: "s3"
+```
+
+## 参考
+
+[Helm 文档](https://helm.sh/zh/docs/)
+
+[Chart](https://helm.sh/zh/docs/topics/charts/)
+
diff --git a/content/zh/docs/v3.4/application-store/app-lifecycle-management.md b/content/zh/docs/v3.4/application-store/app-lifecycle-management.md
new file mode 100644
index 000000000..020b0780c
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/app-lifecycle-management.md
@@ -0,0 +1,230 @@
+---
+title: "应用程序生命周期管理"
+keywords: 'Kubernetes, KubeSphere, 应用商店'
+description: '您可以跨整个生命周期管理应用，包括提交、审核、测试、发布、升级和下架。'
+linkTitle: '应用程序生命周期管理'
+weight: 14100
+---
+
+KubeSphere 集成了 [OpenPitrix](https://github.com/openpitrix/openpitrix)（一个跨云管理应用程序的开源平台）来构建应用商店，管理应用程序的整个生命周期。应用商店支持两种应用程序部署方式：
+
+- **应用模板**：这种方式让开发者和独立软件供应商 (ISV) 能够与企业空间中的用户共享应用程序。您也可以在企业空间中导入第三方应用仓库。
+- **自制应用**：这种方式帮助用户使用多个微服务来快速构建一个完整的应用程序。KubeSphere 让用户可以选择现有服务或者创建新的服务，用于在一站式控制台上创建自制应用。
+
+本教程使用 [Redis](https://redis.io/) 作为示例应用程序，演示如何进行应用全生命周期管理，包括提交、审核、测试、发布、升级和下架。
+
+## 视频演示
+
+
+
+## 准备工作
+
+- 您需要启用 [KubeSphere 应用商店 (OpenPitrix)](../../pluggable-components/app-store/)。
+- 您需要创建一个企业空间、一个项目以及一个用户 (`project-regular`)。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../quick-start/create-workspace-and-project/)。
+
+## 动手实验
+
+### 步骤一：创建自定义角色和帐户
+
+首先，您需要创建两个帐户，一个是 ISV 的帐户 (`isv`)，另一个是应用技术审核员的帐户 (`reviewer`)。
+
+1. 使用 `admin` 帐户登录 KubeSphere 控制台。点击左上角的**平台管理**，选择**访问控制**。转到**平台角色**，点击**创建**。
+
+2. 为角色设置一个名称，例如 `app-review`，然后点击**编辑权限**。
+
+3. 转到**应用管理**，选择权限列表中的**应用商店管理**和**应用商店查看**，然后点击**确定**。
+
+ {{< notice note >}}
+
+ 被授予 `app-review` 角色的用户能够查看平台上的应用商店并管理应用，包括审核和下架应用。
+
+ {{}}
+
+4. 创建角色后，您需要创建一个用户，并授予 `app-review` 角色。转到**用户**，点击**创建**。输入必需的信息，然后点击**确定**。
+
+5. 再创建另一个用户 `isv`，把 `platform-regular` 角色授予它。
+
+6. 邀请上面创建好的两个帐户进入现有的企业空间，例如 `demo-workspace`，并授予它们 `workspace-admin` 角色。
+
+### 步骤二：上传和提交应用程序
+
+1. 以 `isv` 身份登录控制台，转到您的企业空间。您需要上传示例应用 Redis 至该企业空间，供后续使用。首先，下载应用 [Redis 11.3.4](https://github.com/kubesphere/tutorial/raw/master/tutorial%205%20-%20app-store/redis-11.3.4.tgz)，然后转到**应用模板**，点击**上传模板**。
+
+ {{< notice note >}}
+
+ 在本示例中，稍后会上传新版本的 Redis 来演示升级功能。
+
+ {{}}
+
+2. 在弹出的对话框中，点击**上传 Helm Chart** 上传 Chart 文件。点击**确定**继续。
+
+3. **应用信息**下显示了应用的基本信息。要上传应用的图标，点击**上传图标**。您也可以跳过上传图标，直接点击**确定**。
+
+ {{< notice note >}}
+
+ 应用图标支持的最大分辨率为 96 × 96 像素。
+
+ {{}}
+
+4. 成功上传后，模板列表中会列出应用，状态为**开发中**，意味着该应用正在开发中。上传的应用对同一企业空间下的所有成员均可见。
+
+5. 点击列表中的 Redis 进入应用模板详情页面。您可以点击**编辑**来编辑该应用的基本信息。
+
+6. 您可以通过在弹出窗口中指定字段来自定义应用的基本信息。
+
+7. 点击**确定**保存更改，然后您可以通过将其部署到 Kubernetes 来测试该应用程序。点击待提交版本展开菜单，选择**安装**。
+
+ {{< notice note >}}
+
+ 如果您不想测试应用，可以直接提交审核。但是，建议您先测试应用部署和功能，再提交审核，尤其是在生产环境中。这会帮助您提前发现问题，加快审核过程。
+
+ {{}}
+
+8. 选择要部署应用的集群和项目，为应用设置不同的配置，然后点击**安装**。
+
+ {{< notice note >}}
+
+ 有些应用可以在表单中设置所有配置后进行部署。您可以使用拨动开关查看它的 YAML 文件，文件中包含了需要在表单中指定的所有参数。
+
+ {{}}
+
+9. 稍等几分钟，切换到**应用实例**选项卡。您会看到 Redis 已经部署成功。
+
+10. 测试应用并且没有发现问题后，便可以点击**提交发布**，提交该应用程序进行发布。
+
+ {{< notice note >}}
+
+版本号必须以数字开头并包含小数点。
+
+{{}}
+
+11. 应用提交后，它的状态会变成**已提交**。现在，应用审核员便可以进行审核。
+
+
+### 步骤三：发布应用程序
+
+1. 登出控制台，然后以 `reviewer` 身份重新登录 KubeSphere。点击左上角的**平台管理**，选择**应用商店管理**。在**应用发布**页面，上一步中提交的应用会显示在**待发布**选项卡下。
+
+2. 点击该应用进行审核，在弹出窗口中查看应用信息、介绍、配置文件和更新日志。
+
+3. 审核员的职责是决定该应用是否符合发布至应用商店的标准。点击**通过**来批准，或者点击**拒绝**来拒绝提交的应用。
+
+### 步骤四：发布应用程序至应用商店
+
+应用获批后，`isv` 便可以将 Redis 应用程序发布至应用商店，让平台上的所有用户都能找到并部署该应用程序。
+
+1. 登出控制台，然后以 `isv` 身份重新登录 KubeSphere。转到您的企业空间，点击**应用模板**页面上的 Redis。在详情页面上展开版本菜单，然后点击**发布到商店**。在弹出的提示框中，点击**确定**以确认操作。
+
+2. 在**应用发布**下，您可以查看应用状态。**已上架**意味着它在应用商店中可用。
+
+3. 点击**在商店查看**转到应用商店的**应用信息**页面，或者点击左上角的**应用商店**也可以查看该应用。
+
+ {{< notice note >}}
+
+ 您可能会在应用商店看到两个 Redis 应用，其中一个是 KubeSphere 中的内置应用。请注意，新发布的应用会显示在应用商店列表的开头。
+
+ {{}}
+
+4. 现在，企业空间中的用户可以从应用商店中部署 Redis。要将应用部署至 Kubernetes，请点击应用转到**应用信息**页面，然后点击**安装**。
+
+ {{< notice note >}}
+
+ 如果您在部署应用时遇到问题，**状态**栏显示为**失败**，您可以将光标移至**失败**图标上方查看错误信息。
+
+ {{}}
+
+### 步骤五：创建应用分类
+
+`reviewer` 可以根据不同类型应用程序的功能和用途创建多个分类。这类似于设置标签，可以在应用商店中将分类用作筛选器，例如大数据、中间件和物联网等。
+
+1. 以 `reviewer` 身份登录 KubeSphere。要创建分类，请转到**应用商店管理**页面，再点击**应用分类**页面中的 
。
+
+2. 在弹出的对话框中设置分类名称和图标，然后点击**确定**。对于 Redis，您可以将**分类名称**设置为 `Database`。
+
+ {{< notice note >}}
+
+ 通常，应用审核员会提前创建必要的分类，ISV 会选择应用所属的分类，然后提交审核。新创建的分类中没有应用。
+
+ {{}}
+
+3. 创建好分类后，您可以给您的应用分配分类。在**未分类**中选择 Redis，点击**调整分类**。
+
+4. 在弹出对话框的下拉列表中选择分类 (**Database**) 然后点击**确定**。
+
+5. 该应用便会显示在对应分类中。
+
+
+### 步骤六：添加新版本
+
+要让企业空间用户能够更新应用，您需要先向 KubeSphere 添加新的应用版本。按照下列步骤为示例应用添加新版本。
+
+1. 再次以 `isv` 身份登录 KubeSphere，点击**应用模板**，点击列表中的 Redis 应用。
+
+2. 下载 [Redis 12.0.0](https://github.com/kubesphere/tutorial/raw/master/tutorial%205%20-%20app-store/redis-12.0.0.tgz)，这是 Redis 的一个新版本，本教程用它来演示。在**版本**选项卡中点击右侧的**上传新版本**，上传您刚刚下载的文件包。
+
+3. 点击**上传 Helm Chart**，上传完成后点击**确定**。
+
+4. 新的应用版本会显示在版本列表中。您可以通过点击来展开菜单并测试新的版本。另外，您也可以提交审核并发布至应用商店，操作步骤和上面说明的一样。
+
+
+### 步骤七：升级
+
+新版本发布至应用商店后，所有用户都可以升级该应用程序至新版本。
+
+{{< notice note >}}
+
+要完成下列步骤，您必须先部署应用的一个旧版本。本示例中，Redis 11.3.4 已经部署至项目 `demo-project`，它的新版本 12.0.0 也已经发布至应用商店。
+
+{{}}
+
+1. 以 `project-regular` 身份登录 KubeSphere，搜寻到项目的**应用**页面，点击要升级的应用。
+
+2. 点击**更多操作**，在下拉菜单中选择**编辑设置**。
+
+3. 在弹出窗口中，您可以查看应用配置 YAML 文件。在右侧的下拉列表中选择新版本，您可以自定义新版本的 YAML 文件。在本教程中，点击**更新**，直接使用默认配置。
+
+ {{< notice note >}}
+
+ 您可以在右侧的下拉列表中选择与左侧相同的版本，通过 YAML 文件自定义当前应用的配置。
+
+ {{}}
+
+4. 在**应用**页面，您会看到应用正在升级中。升级完成后，应用状态会变成**运行中**。
+
+
+### 步骤八：下架应用程序
+
+您可以选择将应用完全从应用商店下架，或者下架某个特定版本。
+
+1. 以 `reviewer` 身份登录 KubeSphere。点击左上角的**平台管理**，选择**应用商店管理**。在**应用商店**页面，点击 Redis。
+
+2. 在详情页面，点击**下架应用**，在弹出的对话框中选择**确定**，确认将应用从应用商店下架的操作。
+
+ {{< notice note >}}
+
+ 将应用从应用商店下架不影响正在使用该应用的租户。
+
+ {{}}
+
+3. 要让应用再次在应用商店可用，点击**上架应用**。
+
+4. 要下架应用的特定版本，展开版本菜单，点击**下架版本**。在弹出的对话框中，点击**确定**以确认操作。
+
+ {{< notice note >}}
+
+ 下架应用版本后，该版本在应用商店将不可用。下架应用版本不影响正在使用该版本的租户。
+
+ {{}}
+
+5. 要让应用版本再次在应用商店可用，点击**上架版本**。
+
+
+
+
+
+
+
+
+
diff --git a/content/zh/docs/v3.4/application-store/built-in-apps/_index.md b/content/zh/docs/v3.4/application-store/built-in-apps/_index.md
new file mode 100644
index 000000000..49cf0ae27
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/built-in-apps/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "内置应用"
+weight: 14200
+
+_build:
+ render: false
+---
diff --git a/content/zh/docs/v3.4/application-store/built-in-apps/chaos-mesh-app.md b/content/zh/docs/v3.4/application-store/built-in-apps/chaos-mesh-app.md
new file mode 100644
index 000000000..8cdb60fa4
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/built-in-apps/chaos-mesh-app.md
@@ -0,0 +1,93 @@
+---
+title: "在 KubeSphere 中部署 Chaos Mesh"
+keywords: 'KubeSphere, Kubernetes, Chaos Mesh, Chaos Engineering'
+description: '了解如何在 KubeSphere 中部署 Chaos Mesh 并进行混沌实验。'
+linkTitle: "部署 Chaos Mesh"
+---
+
+[Chaos Mesh](https://github.com/chaos-mesh/chaos-mesh) 是一个开源的云原生混沌工程平台，提供丰富的故障模拟类型，具有强大的故障场景编排能力，方便用户在开发测试中以及生产环境中模拟现实世界中可能出现的各类异常，帮助用户发现系统潜在的问题。
+
+
+
+本教程演示了如何在 KubeSphere 上部署 Chaos Mesh 进行混沌实验。
+
+## **准备工作**
+
+* 部署 [KubeSphere 应用商店](../../../pluggable-components/app-store/)。
+* 您需要为本教程创建一个企业空间、一个项目和两个帐户（ws-admin 和 project-regular）。帐户 ws-admin 必须在企业空间中被赋予 workspace-admin 角色，帐户 project-regular 必须被邀请至项目中赋予 operator 角色。若还未创建好，请参考[创建企业空间、项目、用户和角色](https://kubesphere.io/zh/docs/quick-start/create-workspace-and-project/)。
+
+
+## **开始混沌实验**
+
+### 步骤1: 部署 Chaos Mesh
+
+1. 使用 `project-regular` 身份登陆，在应用市场中搜索 `chaos-mesh`，点击搜索结果进入应用。
+
+ 
+
+
+2. 进入应用信息页后，点击右上角**安装**按钮。
+
+ 
+
+3. 进入应用设置页面，可以设置应用**名称**（默认会随机一个唯一的名称）和选择安装的**位置**（对应的 Namespace) 和**版本**，然后点击右上角**下一步**。
+
+ 
+
+4. 根据实际需要编辑 `values.yaml` 文件，也可以直接点击**安装**使用默认配置。
+
+ 
+
+5. 等待 Chaos Mesh 开始正常运行。
+
+ 
+
+6. 访问**应用负载**， 可以看到 Chaos Mesh 创建的三个部署。
+
+ 
+
+### 步骤 2: 访问 Chaos Mesh
+
+1. 前往**应用负载**下服务页面，复制 chaos-dashboard 的 **NodePort**。
+
+ 
+
+2. 您可以通过 `${NodeIP}:${NODEPORT}` 方式访问 Chaos Dashboard。并参考[管理用户权限](https://chaos-mesh.org/zh/docs/manage-user-permissions/)文档，生成 Token，并登陆 Chaos Dashboard。
+
+ 
+
+### 步骤 3: 创建混沌实验
+
+1. 在开始混沌实验之前，需要先确定并部署您的实验目标，比如，测试某应用在网络延时下的工作状态。本文使用了一个 demo 应用 `web-show` 作为待测试目标，观测系统网络延迟。 你可以使用下面命令部署一个 Demo 应用 `web-show` ：
+
+ ```bash
+ curl -sSL https://mirrors.chaos-mesh.org/latest/web-show/deploy.sh | bash
+ ```
+
+ {{< notice note >}}
+
+ web-show 应用页面上可以直接观察到自身到 kube-system 命名空间下 Pod 的网络延迟。
+
+ {{}}
+
+2. 访问 **web-show** 应用程序。从您的网络浏览器，进入 `${NodeIP}:8081`。
+
+ 
+
+3. 登陆 Chaos Dashboard 创建混沌实验，为了更好的观察混沌实验效果，这里只创建一个独立的混沌实验，混沌实验的类型选择**网络攻击**，模拟网络延迟的场景：
+
+ 
+
+ 实验范围设置为 web-show 应用：
+
+ 
+
+4. 提交混沌实验后，查看实验状态：
+
+ 
+
+5. 访问 web-show 应用观察实验结果 ：
+
+ 
+
+更多详情参考 [Chaos Mesh 使用文档](https://chaos-mesh.org/zh/docs/)。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/application-store/built-in-apps/etcd-app.md b/content/zh/docs/v3.4/application-store/built-in-apps/etcd-app.md
new file mode 100644
index 000000000..ca74dfa5a
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/built-in-apps/etcd-app.md
@@ -0,0 +1,60 @@
+---
+title: "在 KubeSphere 中部署 etcd"
+keywords: 'Kubernetes, KubeSphere, etcd, 应用商店'
+description: '了解如何从 KubeSphere 应用商店中部署 etcd 并访问服务。'
+linkTitle: "在 KubeSphere 中部署 etcd"
+weight: 14210
+---
+
+[etcd](https://etcd.io/) 是一个采用 Go 语言编写的分布式键值存储库，用来存储供分布式系统或机器集群访问的数据。在 Kubernetes 中，etcd 是服务发现的后端，存储集群状态和配置。
+
+本教程演示如何从 KubeSphere 应用商店部署 etcd。
+
+## 准备工作
+
+- 请确保[已启用 OpenPitrix 系统](../../../pluggable-components/app-store/)。
+- 您需要创建一个企业空间、一个项目和一个用户帐户 (`project-regular`) 供本教程操作使用。该帐户需要是平台普通用户，并邀请至项目中赋予 `operator` 角色作为项目操作员。本教程中，请以 `project-regular` 身份登录控制台，在企业空间 `demo-workspace` 中的 `demo-project` 项目中进行操作。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+
+## 动手实验
+
+### 步骤 1：从应用商店中部署 etcd
+
+1. 在 `demo-project` 项目的**概览**页面，点击左上角的**应用商店**。
+
+2. 找到 etcd，点击**应用信息**页面上的**安装**。
+
+3. 设置名称并选择应用版本。请确保将 etcd 部署在 `demo-project` 中，点击**下一步**。
+
+4. 在**应用设置**页面，指定 etcd 的持久化持久卷大小，点击**安装**。
+
+ {{< notice note >}}
+
+ 要指定 etcd 的更多值，请使用右上角的**编辑YAML**查看 YAML 格式的应用清单文件，并编辑其配置。
+
+ {{}}
+
+5. 在**应用**页面的**基于模板的应用**选项卡下，稍等片刻待 etcd 启动并运行。
+
+
+### 步骤 2：访问 etcd 服务
+
+应用部署后，您可以在 KubeSphere 控制台上使用 etcdctl 命令行工具与 etcd 服务器进行交互，直接访问 etcd。
+
+1. 在**工作负载**的**有状态副本集**选项卡中，点击 etcd 的服务名称。
+
+2. 在**容器组**下，展开菜单查看容器详情，然后点击**终端**图标。
+
+3. 在终端中，您可以直接读写数据。例如，分别执行以下两个命令。
+
+ ```bash
+ etcdctl set /name kubesphere
+ ```
+
+ ```bash
+ etcdctl get /name
+ ```
+
+4. KubeSphere 集群内的客户端可以通过 `
查看密码。请确保将密码进行复制。
+
+
+### 步骤 4：编辑 hosts 文件
+
+1. 在本地机器上找到 hosts 文件。
+
+ {{< notice note >}}
+
+ 对于 Linux，hosts 文件的路径是 `/etc/hosts`；对于 Windows，则是 `c:\windows\system32\drivers\etc\hosts`。
+
+ {{}}
+
+2. 将以下条目添加进 hosts 文件中。
+
+ ```
+ 192.168.4.3 gitlab.demo-project.svc.cluster.local
+ ```
+
+ {{< notice note >}}
+
+ - `192.168.4.3` 和 `demo-project` 分别指的是部署 GitLab 的 NodeIP 和项目名称，请确保使用自己的 NodeIP 和项目名称。
+ - 您可以使用自己 Kubernetes 集群中任意节点的 IP 地址。
+
+ {{}}
+
+### 步骤 5：访问 GitLab
+
+1. 访问**应用负载**下的**服务**，在搜索栏输入 `nginx-ingress-controller`，然后按下键盘上的**回车键**搜索该服务，可以看到通过端口 `31246` 暴露的服务，您可以使用该端口访问 GitLab。
+
+ {{< notice note >}}
+
+ 在不同控制台上显示的端口号可能不同，请您确保使用自己的端口号。
+
+ {{}}
+
+2. 通过 `http://gitlab.demo-project.svc.cluster.local:31246` 使用 root 帐户及其初始密码 (`root/ojPWrWECLWN0XFJkGs7aAqtitGMJlVfS0fLEDE03P9S0ji34XDoWmxs2MzgZRRWF`) 访问 GitLab。
+
+ 
+
+ 
+
+ {{< notice note >}}
+
+ 根据您 Kubernetes 集群部署位置的不同，您可能需要在安全组中打开端口，并配置相关的端口转发规则。
+
+ {{}}
+
diff --git a/content/zh/docs/v3.4/application-store/external-apps/deploy-metersphere.md b/content/zh/docs/v3.4/application-store/external-apps/deploy-metersphere.md
new file mode 100644
index 000000000..bd7d91b0d
--- /dev/null
+++ b/content/zh/docs/v3.4/application-store/external-apps/deploy-metersphere.md
@@ -0,0 +1,65 @@
+---
+title: "在 KubeSphere 上部署 MeterSphere"
+keywords: 'KubeSphere, Kubernetes, 应用程序, MeterSphere'
+description: '了解如何在 KubeSphere 中部署 MeterSphere。'
+linkTitle: "在 KubeSphere 上部署 MeterSphere"
+weight: 14330
+---
+
+MeterSphere 是一站式的开源企业级连续测试平台，涵盖测试跟踪、界面测试和性能测试等功能。
+
+本教程演示了如何在 KubeSphere 上部署 MeterSphere。
+
+## 准备工作
+
+- 您需要启用 [OpenPitrix 系统](../../../pluggable-components/app-store/)。
+- 您需要为本教程创建一个企业空间、一个项目以及两个帐户（`ws-admin` 和 `project-regular`）。在企业空间中，`ws-admin` 帐户必须被赋予 `workspace-admin` 角色，`project-regular` 帐户必须被赋予 `operator` 角色。如果还未创建好，请参考[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+
+## **动手实验**
+
+### 步骤 1：添加应用仓库
+
+1. 以 `ws-admin` 身份登录 KubeSphere。在企业空间中，访问**应用管理**下的**应用仓库**，然后点击**添加**。
+
+2. 在出现的对话框中，输入 `metersphere` 作为应用仓库名称，输入 `https://charts.kubesphere.io/test` 作为应用仓库 URL。点击**验证**来验证 URL，如果可用，则会在 URL 右侧看到一个绿色的对号。点击**确定**继续操作。
+
+3. 仓库成功导入到 KubeSphere 后，会显示在列表里。
+
+
+### 步骤 2：部署 MeterSphere
+
+1. 登出 KubeSphere，再以 `project-regular` 登录。在您的项目中，访问**应用负载**下的**应用**，然后点击**创建**。
+
+2. 在出现的对话框中，选择**从应用模板**。
+
+3. 从下拉菜单中选择 `metersphere`，然后点击 **metersphere-chart**。
+
+4. 在**应用信息**选项卡和**Chart 文件**选项卡，可以看到控制台的默认配置。点击**安装**继续。
+
+5. 在**基本信息**页面，可以看到应用名称、应用版本以及部署位置。点击**下一步**继续。
+
+6. 在**应用设置**页面，将 `imageTag` 的值从 `master` 改为 `v1.6`，然后点击**安装**。
+
+7. 等待 MeterSphere 应用正常运行。
+
+8. 访问**工作负载**，可以看到为 MeterSphere 创建的所有部署和有状态副本集。
+
+ {{< notice note >}}
+
+ 可能需要过一段时间才能看到所有部署和有状态副本集正常运行。
+
+ {{}}
+
+### 步骤 3：访问 MeterSphere
+
+1. 问**应用负载**下的**服务**，可以看到 MeterSphere 服务，其服务类型默认设置为 `NodePort`。
+
+2. 您可以通过 ` 或 按钮，以增加或减少副本数量。
+7. 点击**元数据**选项卡，以查看集群网关的注解。
+
+## 查看项目网关
+
+在**网关设置**页面，点击**项目网关**选项卡，以查看项目网关。
+
+点击项目网关右侧的 ，从下拉菜单中选择操作：
+
+- **编辑**：编辑项目网关的配置。
+- **关闭**：关闭项目网关。
+
+{{< notice note >}}
+
+如果在创建集群网关之前存在项目网关，则项目网关地址可能会在集群网关地址和项目网关地址之间切换。建议您只使用集群网关或项目网关。
+
+{{}}
+
+关于如何创建项目网关的更多信息，请参见[项目网关](../../../project-administration/project-gateway/)。
+
diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md b/content/zh/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md
new file mode 100644
index 000000000..0b5c6b61c
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/cluster-settings/cluster-visibility-and-authorization.md
@@ -0,0 +1,53 @@
+---
+title: "集群可见性和授权"
+keywords: "集群可见性, 集群管理"
+description: "了解如何设置集群可见性和授权。"
+linkTitle: "集群可见性和授权"
+weight: 8610
+---
+
+在 KubeSphere 中，您可以通过授权将一个集群分配给多个企业空间，让企业空间资源都可以在该集群上运行。同时，一个企业空间也可以关联多个集群。拥有必要权限的企业空间用户可以使用分配给该企业空间的集群来创建多集群项目。
+
+本指南演示如何设置集群可见性。
+
+## 准备工作
+* 您需要启用[多集群功能](../../../multicluster-management/)。
+* 您需要有一个企业空间和一个拥有创建企业空间权限的帐户，例如 `ws-manager`。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+
+## 设置集群可见性
+
+### 在创建企业空间时选择可用集群
+
+1. 使用拥有创建企业空间权限的用户登录 KubeSphere，例如 `ws-manager`。
+
+2. 点击左上角的**平台管理**，选择**访问控制**。在左侧导航栏选择**企业空间**，然后点击**创建**。
+
+3. 输入企业空间的基本信息，点击**下一步**。
+
+4. 在**集群设置**页面，您可以看到可用的集群列表，选择要分配给企业空间的集群并点击**创建**。
+
+5. 创建企业空间后，拥有必要权限的企业空间成员可以创建资源，在关联集群上运行。
+
+ {{< notice warning >}}
+
+尽量不要在主集群上创建资源，避免负载过高导致多集群稳定性下降。
+
+{{}}
+
+### 在创建企业空间后设置集群可见性
+
+创建企业空间后，您可以通过授权向该企业空间分配其他集群，或者将集群从企业空间中解绑。按照以下步骤调整集群可见性。
+
+1. 使用拥有集群管理权限的帐户登录 KubeSphere，例如 `admin`。
+
+2. 点击左上角的**平台管理**，选择**集群管理**。从列表中选择一个集群查看集群信息。
+
+3. 在左侧导航栏找到**集群设置**，选择**集群可见性**。
+
+4. 您可以看到已授权企业空间的列表，这意味着所有这些企业空间中的资源都能使用当前集群。
+
+5. 点击**编辑可见性**设置集群可见性。您可以选择让新的企业空间使用该集群，或者将该集群从企业空间解绑。
+
+### 将集群设置为公开集群
+
+您可以打开**设置为公开集群**，以便平台用户访问该集群，并在该集群上创建和调度资源。
diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md
new file mode 100644
index 000000000..bce4fe493
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "日志接收器"
+weight: 8620
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md
new file mode 100644
index 000000000..70a1807f8
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-es-as-receiver.md
@@ -0,0 +1,34 @@
+---
+title: "添加 Elasticsearch 作为接收器"
+keywords: 'Kubernetes, 日志, Elasticsearch, Pod, 容器, Fluentbit, 输出'
+description: '了解如何添加 Elasticsearch 来接收容器日志、资源事件或审计日志。'
+linkTitle: "添加 Elasticsearch 作为接收器"
+weight: 8622
+---
+您可以在 KubeSphere 中使用 Elasticsearch、Kafka 和 Fluentd 日志接收器。本教程演示如何添加 Elasticsearch 接收器。
+
+## 准备工作
+
+- 您需要一个被授予**集群管理**权限的用户。例如，您可以直接用 `admin` 用户登录控制台，或创建一个具有**集群管理**权限的角色然后将此角色授予一个用户。
+- 添加日志接收器前，您需要启用组件 `logging`、`events` 或 `auditing`。有关更多信息，请参见[启用可插拔组件](../../../../pluggable-components/)。本教程启用 `logging` 作为示例。
+
+## 添加 Elasticsearch 作为接收器
+
+1. 以 `admin` 身份登录 KubeSphere 的 Web 控制台。点击左上角的**平台管理**，然后选择**集群管理**。
+
+ {{< notice note >}}
+
+如果您启用了[多集群功能](../../../../multicluster-management/)，您可以选择一个集群。
+
+{{}}
+
+2. 在左侧导航栏，选择**集群设置**下的**日志接收器**。
+
+3. 点击**添加日志接收器**并选择 **Elasticsearch**。
+
+4. 提供 Elasticsearch 服务地址和端口信息。
+
+5. Elasticsearch 会显示在**日志接收器**页面的接收器列表中，状态为**收集中**。
+
+6. 若要验证 Elasticsearch 是否从 Fluent Bit 接收日志，从右下角的**工具箱**中点击**日志查询**，在控制台中搜索日志。有关更多信息，请参阅[日志查询](../../../../toolbox/log-query/)。
+
diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md
new file mode 100644
index 000000000..dc90d4e52
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/cluster-settings/log-collections/add-fluentd-as-receiver.md
@@ -0,0 +1,154 @@
+---
+title: "添加 Fluentd 作为接收器"
+keywords: 'Kubernetes, 日志, Fluentd, 容器组, 容器, Fluentbit, 输出'
+description: '了解如何添加 Fluentd 来接收容器日志、资源事件或审计日志。'
+linkTitle: "添加 Fluentd 作为接收器"
+weight: 8624
+---
+您可以在 KubeSphere 中使用 Elasticsearch、Kafka 和 Fluentd 日志接收器。本教程演示：
+
+- 创建 Fluentd 部署以及对应的服务（Service）和配置字典（ConfigMap）。
+- 添加 Fluentd 作为日志接收器以接收来自 Fluent Bit 的日志，并输出为标准输出。
+- 验证 Fluentd 能否成功接收日志。
+
+## 准备工作
+
+- 您需要一个被授予**集群管理**权限的用户。例如，您可以直接用 `admin` 用户登录控制台，或创建一个具有**集群管理**权限的角色然后将此角色授予一个用户。
+
+- 添加日志接收器前，您需要启用组件 `logging`、`events` 或 `auditing`。有关更多信息，请参见[启用可插拔组件](../../../../pluggable-components/)。本教程启用 `logging` 作为示例。
+
+## 步骤 1：创建 Fluentd 部署
+
+由于内存消耗低，KubeSphere 选择 Fluent Bit。Fluentd 一般在 Kubernetes 中以守护进程集的形式部署，在每个节点上收集容器日志。此外，Fluentd 支持多个插件。因此，Fluentd 会以部署的形式在 KubeSphere 中创建，将从 Fluent Bit 接收到的日志发送到多个目标，例如 S3、MongoDB、Cassandra、MySQL、syslog 和 Splunk 等。
+
+执行以下命令：
+
+{{< notice note >}}
+
+- 以下命令将在默认命名空间 `default` 中创建 Fluentd 部署、服务和配置字典，并为该 Fluentd 配置字典添加 `filter` 以排除 `default` 命名空间中的日志，避免 Fluent Bit 和 Fluentd 重复日志收集。
+- 如果您想要将 Fluentd 部署至其他命名空间，请修改以下命令中的命名空间名称。
+
+{{}}
+
+```yaml
+cat <- **1 小时内 Leader 变更次数**表示集群成员观察到的 1 小时内 Leader 变更总次数。频繁变更 Leader 将显著影响 etcd 性能，同时这还表明 Leader 可能由于网络连接问题或 etcd 集群负载过高而不稳定。 | +| 库大小 | etcd 的底层数据库大小，单位为 MiB。图表中显示的是 etcd 的每个成员数据库的平均大小。 | +| 客户端流量 | 包括发送到 gRPC 客户端的总流量和从 gRPC 客户端接收的总流量。有关该指标的更多信息，请参阅[ etcd Network](https://github.com/etcd-io/etcd/blob/v3.2.17/Documentation/metrics.md#network)。 | +| gRPC 流式消息 | 服务器端的 gRPC 流消息接收速率和发送速率，反映集群内是否正在进行大规模的数据读写操作。有关该指标的更多信息，请参阅[ go-grpc-prometheus](https://github.com/grpc-ecosystem/go-grpc-prometheus#counters)。 | +| WAL 日志同步时间 | WAL 调用 fsync 的延迟。在应用日志条目之前，etcd 会在持久化日志条目到磁盘时调用 `wal_fsync`。有关该指标的更多信息，请参阅[ etcd Disk](https://etcd.io/docs/v3.3.12/metrics/#disk)。 | +| 库同步时间 | 后端调用提交延迟的分布。当 etcd 将其最新的增量快照提交到磁盘时，会调用 `backend_commit`。需要注意的是，磁盘操作延迟较大（WAL 日志同步时间或库同步时间较长）通常表示磁盘存在问题，这可能会导致请求延迟过高或集群不稳定。有关该指标的详细信息，请参阅[ etcd Disk](https://etcd.io/docs/v3.3.12/metrics/#disk)。 | +| Raft 提议 | - **提议提交速率**记录提交的协商一致提议的速率。如果集群运行状况良好，则该指标应随着时间的推移而增加。etcd 集群的几个健康成员可以同时具有不同的一般提议。单个成员与其 Leader 之间的持续较大滞后表示该成员缓慢或不健康。
- **提议应用速率**记录协商一致提议的总应用率。etcd 服务器异步地应用每个提交的提议。**提议提交速率**和**提议应用速率**的差异应该很小（即使在高负载下也只有几千）。如果它们之间的差异持续增大，则表明 etcd 服务器过载。当使用大范围查询或大量 txn 操作等大规模查询时，可能会出现这种情况。
- **提议失败速率**记录提议失败的总速率。这通常与两个问题有关：与 Leader 选举相关的临时失败或由于集群成员数目达不到规定数目而导致的长时间停机。
- **排队提议数**记录当前待处理提议的数量。待处理提议的增加表明客户端负载较高或成员无法提交提议。
目前，仪表板上显示的数据是 etcd 成员的平均数值。有关这些指标的详细信息，请参阅[ etcd Server](https://etcd.io/docs/v3.3.12/metrics/#server)。 | + +## API Server 监控 + +[API Server](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) 是 Kubernetes 集群中所有组件交互的中枢。下表列出了 API Server 的主要监控指标。 + +| 指标 | 描述 | +| --- | --- | +| 请求延迟 | 资源请求响应延迟，单位为毫秒。该指标按照 HTTP 请求方法进行分类。 | +| 每秒请求次数 | kube-apiserver 每秒接受的请求数。 | + +## 调度器监控 + +[调度器](https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-scheduler/)监控新建容器组的 Kubernetes API，并决定这些新容器组运行在哪些节点上。调度器根据收集资源的可用性和容器组的资源需求等数据进行决策。监控调度延迟的数据可确保您及时了解调度器的任何延迟。 + +| 指标 | 描述 | +| --- | --- | +| 调度次数 | 包括调度成功、错误和失败的次数。 | +| 调度频率 | 包括调度成功、错误和失败的频率。 | +| 调度延迟 | 端到端调度延迟，即调度算法延迟和绑定延迟之和。 | + +## 节点用量排行 + +您可以按 **CPU 用量**、**CPU 平均负载**、**内存用量**、**本地存储用量**、**Inode 用量**和**容器组用量**等指标对节点进行升序和降序排序。您可以利用这一功能快速发现潜在问题和节点资源不足的情况。 \ No newline at end of file diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md new file mode 100644 index 000000000..ade0b7a19 --- /dev/null +++ b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/_index.md @@ -0,0 +1,7 @@ +--- +linkTitle: "集群告警和通知" +weight: 8500 + +_build: + render: false +--- diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md new file mode 100644 index 000000000..1b5c0c490 --- /dev/null +++ b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md @@ -0,0 +1,27 @@ +--- +title: "告警消息（节点级别）" +keywords: 'KubeSphere, Kubernetes, 节点, 告警, 消息' +description: '了解如何查看节点的告警消息。' + +linkTitle: "告警消息（节点级别）" +weight: 8540 +--- + +告警消息会记录按照告警规则触发的告警的详细信息。本教程演示如何查看节点级别的告警消息。 +## 准备工作 + +- 您需要启用 [KubeSphere 告警系统](../../../pluggable-components/alerting/)。 +- 您需要创建一个用户 (`cluster-admin`) 并授予其 `clusters-admin` 角色。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/#step-4-create-a-role)。 +- 您已经创建节点级别的告警策略并已触发该告警。有关更多信息，请参考[告警策略（节点级别）](../alerting-policy/)。 + +## 查看告警消息 + +1. 使用 `cluster-admin` 帐户登录 KubeSphere 控制台，导航到**监控告警**下的**告警消息**。 + +2. 在**告警消息**页面，可以看到列表中的全部告警消息。第一列显示了为告警消息定义的概括和详情。如需查看告警消息的详细信息，点击告警策略的名称，然后点击告警策略详情页面上的**告警历史**选项卡。 + +3. 在**告警历史**选项卡，您可以看到告警级别、监控目标和告警激活时间。 + +## 查看通知 + +如果需要接收告警通知（例如，邮件和 Slack 消息），则须先配置[一个通知渠道](../../../cluster-administration/platform-settings/notification-management/configure-email/)。 \ No newline at end of file diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md new file mode 100644 index 000000000..84e44c2d3 --- /dev/null +++ b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md @@ -0,0 +1,70 @@ +--- +title: "告警策略（节点级别）" +keywords: 'KubeSphere, Kubernetes, 节点, 告警, 策略, 通知' +description: '了解如何为节点设置告警策略。' + +linkTitle: "告警策略（节点级别）" +weight: 8530 +--- + +KubeSphere 为节点和工作负载提供告警策略。本教程演示如何为集群中的节点创建告警策略。如需了解如何为工作负载配置告警策略，请参见[告警策略（工作负载级别）](../../../project-user-guide/alerting/alerting-policy/)。 + +KubeSphere 还具有内置策略，一旦满足为这些策略定义的条件，将会触发告警。 在**内置策略**选项卡，您可以点击任一策略查看其详情。请注意，这些策略不能直接在控制台上进行删除或编辑。 + +## 准备工作 + +- 您需要启用 [KubeSphere 告警系统](../../../pluggable-components/alerting)。 +- 如需接收告警通知，您需要预先配置[通知渠道](../../../cluster-administration/platform-settings/notification-management/configure-email/)。 +- 您需要创建一个用户 (`cluster-admin`) 并授予其 `clusters-admin` 角色。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/#step-4-create-a-role)。 +- 您需要确保集群中存在工作负载。如果尚未就绪，请参见[部署并访问 Bookinfo](../../../quick-start/deploy-bookinfo-to-k8s/) 创建一个示例应用。 + +## 创建告警策略 + +1. 使用 `cluster-admin` 用户登录控制台。点击左上角的**平台管理**，然后点击**集群管理**。 + +2. 前往**监控告警**下的**告警策略**，然后点击**创建**。 + +3. 在出现的对话框中，填写以下基本信息。点击**下一步**继续。 + + - **名称**：使用简明名称作为其唯一标识符，例如 `node-alert`。 + - **别名**：帮助您更好地识别告警策略。 + - **阈值时间（分钟）**：告警规则中设置的情形持续时间达到该阈值后，告警策略将变为触发中状态。 + - **告警级别**：提供的值包括**一般告警**、**重要告警**和**危险告警**，代表告警的严重程度。 + - **描述信息**：对告警策略的简要介绍。 + +4. 在**规则设置**选项卡，您可以使用规则模板或创建自定义规则。如需使用规则模板，请设置以下参数，然后点击**下一步**继续。 + + - **监控目标**：选择至少一个集群节点进行监控。 + - **告警规则**：为告警策略定义一个规则。下拉菜单中提供的规则基于 Prometheus 表达式，满足条件时将会触发告警。您可以对 CPU、内存等对象进行监控。 + + {{< notice note >}} + + 您可以在**监控指标**字段输入表达式（支持自动补全），以使用 PromQL 创建自定义规则。有关更多信息，请参见 [Querying Prometheus](https://prometheus.io/docs/prometheus/latest/querying/basics/)。 + + {{}} + +5. 在**消息设置**选项卡，输入告警消息的概括和详情，点击**创建**。 + +6. 告警策略刚创建后将显示为**未触发**状态；一旦满足规则表达式中的条件，则会首先达到**待触发**状态；满足告警条件的时间达到阈值时间后，将变为**触发中**状态。 + +## 编辑告警策略 + +如需在创建后编辑告警策略，在**告警策略**页面点击右侧的
。
+
+1. 点击下拉菜单中的**编辑**，根据与创建时相同的步骤来编辑告警策略。点击**消息设置**页面的**确定**保存更改。
+
+2. 点击下拉菜单中的**删除**以删除告警策略。
+
+## 查看告警策略
+
+在**告警策略**页面，点击一个告警策略的名称查看其详情，包括告警规则和告警历史。您还可以看到创建告警策略时基于所使用模板的告警规则表达式。
+
+在**监控**下，**告警监控**图显示一段时间内的实际资源使用情况或使用量。**告警消息**显示您在通知中设置的自定义消息。
+
+{{< notice note >}}
+
+您可以点击右上角的 
选择告警监控的时间范围或者自定义时间范围。
+
+您还可以点击右上角的 来手动刷新告警监控图。
+
+{{}}
diff --git a/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md
new file mode 100644
index 000000000..c56c69fe7
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md
@@ -0,0 +1,37 @@
+---
+title: "在 KubeSphere 中使用 Alertmanager 管理告警"
+keywords: 'Kubernetes, Prometheus, Alertmanager, 告警'
+description: '了解如何在 KubeSphere 中使用 Alertmanager 管理告警。'
+linkTitle: "KubeSphere 中的 Alertmanager"
+weight: 8510
+---
+
+Alertmanager 处理由客户端应用程序（例如 Prometheus 服务器）发出的告警。它会将告警去重、分组 (Grouping) 并路由至正确的接收器，例如电子邮件、PagerDuty 或者 OpsGenie。它还负责告警沉默 (Silencing) 和抑制 (Inhibition)。有关更多详细信息，请参考 [Alertmanager 指南](https://prometheus.io/docs/alerting/latest/alertmanager/)。
+
+从初次发布开始，KubeSphere 就一直使用 Prometheus 作为监控服务的后端。从 3.0 版本开始，KubeSphere 的监控栈新增了 Alertmanager 来管理从 Prometheus 和其他服务组件（例如 [kube-events](https://github.com/kubesphere/kube-events) 和 kube-auditing）发出的告警。
+
+
+
+## 使用 Alertmanager 管理 Prometheus 告警
+
+Prometheus 的告警分为两部分。Prometheus 服务器根据告警规则向 Alertmanager 发送告警。随后，Alertmanager 管理这些告警，包括沉默、抑制、聚合等，并通过不同方式发送通知，例如电子邮件、应需 (on-call) 通知系统以及聊天平台。
+
+从 3.0 版本开始，KubeSphere 向 Prometheus 添加了开源社区中流行的告警规则，用作内置告警规则。默认情况下，KubeSphere 3.3 中的 Prometheus 会持续评估这些内置告警规则，然后向 Alertmanager 发送告警。
+
+## 使用 Alertmanager 管理 Kubernetes 事件告警
+
+Alertmanager 可用于管理 Prometheus 以外来源发出的告警。在 3.0 版及更高版本的 KubeSphere 中，用户可以用它管理由 Kubernetes 事件触发的告警。有关更多详细信息，请参考 [kube-events](https://github.com/kubesphere/kube-events)。
+
+## 使用 Alertmanager 管理 KubeSphere 审计告警
+
+在 3.0 版及更高版本的 KubeSphere 中，用户还可以使用 Alertmanager 管理由 Kubernetes 或 KubeSphere 审计事件触发的告警。
+
+## 接收 Alertmanager 告警的通知
+
+一般来说，要接收 Alertmanager 告警的通知，用户需要手动编辑 Alertmanager 的配置文件，配置接收器（例如电子邮件和 Slack）的设置。
+
+这对 Kubernetes 用户来说并不方便，并且违背了 KubeSphere 的多租户规则/架构。具体来说，由不同命名空间中的工作负载所触发的告警可能会发送至同一个租户，然而这些告警信息本应发给不同的租户。
+
+为了使用 Alertmanager 管理平台上的告警，KubeSphere 提供了 [Notification Manager](https://github.com/kubesphere/notification-manager)，它是一个 Kubernetes 原生通知管理工具，完全开源。它符合多租户规则，提供用户友好的 Kubernetes 通知体验，3.0 版及更高版本的 KubeSphere 均默认安装 Notification Manager。
+
+有关使用 Notification Manager 接收 Alertmanager 通知的详细信息，请参考 [Notification Manager](https://github.com/kubesphere/notification-manager)。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/cluster-administration/nodes.md b/content/zh/docs/v3.4/cluster-administration/nodes.md
new file mode 100644
index 000000000..e16b6bd56
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/nodes.md
@@ -0,0 +1,64 @@
+---
+title: "节点管理"
+keywords: "Kubernetes, KubeSphere, 污点, 节点, 标签, 请求, 限制"
+description: "监控节点状态并了解如何添加节点标签和污点。"
+
+linkTitle: "节点管理"
+weight: 8100
+---
+
+Kubernetes 将容器放入容器组（Pod）中并在节点上运行，从而运行工作负载。取决于具体的集群环境，节点可以是虚拟机，也可以是物理机。每个节点都包含运行容器组所需的服务，这些服务由控制平面管理。有关节点的更多信息，请参阅[ Kubernetes 官方文档](https://kubernetes.io/zh/docs/concepts/architecture/nodes/)。
+
+本教程介绍集群管理员可查看的集群节点信息和可执行的操作。
+
+## 准备工作
+
+您需要一个被授予**集群管理**权限的用户。例如，您可以直接用 `admin` 用户登录控制台，或创建一个具有**集群管理**权限的角色然后将此角色授予一个用户。
+
+## 节点状态
+
+只有集群管理员可以访问集群节点。由于一些节点指标对集群非常重要，集群管理员应监控这些指标并确保节点可用。请按照以下步骤查看节点状态。
+
+1. 点击左上角的**平台管理**，然后选择**集群管理**。
+
+2. 如果您已启用了[多集群功能](../../multicluster-management/)并已导入了成员集群，您可以选择一个特定集群以查看其节点信息。如果尚未启用该功能，请直接进行下一步。
+
+3. 在左侧导航栏中选择**节点**下的**集群节点**，查看节点的状态详情。
+
+ - **名称**：节点的名称和子网 IP 地址。
+ - **状态**：节点的当前状态，标识节点是否可用。
+ - **角色**：节点的角色，标识节点是工作节点还是主节点。
+ - **CPU 用量**：节点的实时 CPU 用量。
+ - **内存用量**：节点的实时内存用量。
+ - **容器组**：节点的实时容器组用量。
+ - **已分配 CPU**：该指标根据节点上容器组的总 CPU 请求数计算得出。它表示节点上为工作负载预留的 CPU 资源。工作负载实际正在使用 CPU 资源可能低于该数值。该指标对于 Kubernetes 调度器 (kube-scheduler) 非常重要。在大多数情况下，调度器在调度容器组时会偏向配得 CPU 资源较少的节点。有关更多信息，请参阅[为容器管理资源](https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/)。
+ - **已分配内存**：该指标根据节点上容器组的总内存请求计算得出。它表示节点上为工作负载预留的内存资源。工作负载实际正在使用内存资源可能低于该数值。
+
+ {{< notice note >}}
+ 在大多数情况下，**CPU** 和**已分配 CPU** 的数值不同，**内存**和**已分配内存**的数值也不同，这是正常现象。集群管理员需要同时关注一对指标。最佳实践是根据节点的实际使用情况为每个节点设置资源请求和限制。资源分配不足可能导致集群资源利用率过低，而过度分配资源可能导致集群压力过大从而处于不健康状态。
+ {{}}
+
+## 节点管理
+
+在**集群节点**页面，您可以执行以下操作：
+
+- **停止调度/启用调度**：点击集群节点右侧的 ，然后点击**停止调度**或**启用调度**停止或启用调度节点。您可以在节点重启或维护期间将节点标记为不可调度。Kubernetes 调度器不会将新容器组调度到标记为不可调度的节点。但这不会影响节点上现有工作负载。
+
+- **打开终端**：点击集群节点右侧的 ,然后点击**打开终端**。该功能让您更加便捷地管理节点，如修改节点配置、下载镜像等。
+
+- **编辑污点**：污点允许节点排斥一些容器组。勾选目标节点前的复选框，在上方弹出的按钮中点击**编辑污点**。在弹出的**编辑污点**对话框，您可以添加或删除污点。
+
+同时，您也可以点击列表中的某个节点打开节点详情页面。除了**停止调度/启用调度**和**编辑污点**外，您还可以执行以下操作：
+
+- **编辑标签**：您可以利用节点标签将容器组分配给特定节点。首先标记节点（例如，用 `node-role.kubernetes.io/gpu-node` 标记 GPU 节点），然后在[创建工作负载](../../project-user-guide/application-workloads/deployments/#步骤-5配置高级设置)时在**高级设置**中添加此标签，从而使容器组在 GPU 节点上运行。要添加节点标签，请点击**更多操作** > **编辑标签**。
+
+- 查看节点运行状态、容器组、元数据、监控和事件。
+
+ {{< notice note >}}
+请谨慎添加污点，因为它们可能会导致意外行为从而导致服务不可用。有关更多信息，请参阅[污点和容忍度](https://kubernetes.io/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+ {{}}
+
+## 添加和删除节点
+
+当前版本不支持通过 KubeSphere 控制台添加或删除节点。您可以使用 [KubeKey](https://github.com/kubesphere/kubekey) 来进行此类操作。有关更多信息，请参阅[添加新节点](../../installing-on-linux/cluster-operation/add-new-nodes/)和[删除节点](../../installing-on-linux/cluster-operation/remove-nodes/)。
+
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md
new file mode 100644
index 000000000..97532a77f
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "通知管理"
+weight: 8720
+
+_build:
+ render: false
+---
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md
new file mode 100644
index 000000000..2eb1d0448
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-dingtalk.md
@@ -0,0 +1,127 @@
+---
+title: "配置钉钉通知"
+keywords: 'KubeSphere, Kubernetes, 钉钉, 通知, 告警'
+description: '配置钉钉通知并添加会话或群机器人来接收告警通知消息。'
+linkTitle: "配置钉钉通知"
+weight: 8723
+---
+
+本教程演示如何配置钉钉通知并添加会话或群机器人来接收告警策略的通知。
+
+## 准备工作
+
+您需要准备一个[钉钉帐号](https://www.dingtalk.com/oasite/register_new.htm?spm=a213l2.13146415.4929779444.97.7f1521c9FNlFDT&lwfrom=2020052015221741000&source=1008#/)。
+
+## 动手实验
+
+### 步骤 1：创建应用
+
+1. 登录[钉钉管理后台](https://oa.dingtalk.com/?spm=a213l2.13146415.4929779444.99.1c5521c9S8SsLf&lwfrom=2019051610283222000#/login)，前往**工作台**页面，点击**自建应用**。
+
+2. 在弹出页面中，将鼠标悬停至**应用开发**，选择**企业内部开发**。
+
+3. 选择**小程序**，然后点击**创建应用**。
+
+4. 在弹出对话框中，填写**应用名称**和**应用描述**，本教程均输入`通知测试`作为示例，**开发方式**选择**企业自助开发**，然后点击**确定创建**。
+
+5. 创建应用后，在基础信息页面可以查看此应用的 **AppKey** 和 **AppSecret**。
+
+6. 在**开发管理**页面，点击**修改**。
+
+7. 您需要在**服务器出口IP** 中输入所有节点的公网 IP，然后点击**保存**。
+
+8. 前往**权限管理**页面，在搜索框中搜索`根据手机号姓名获取成员信息的接口访问权限`，然后点击**申请权限**。
+
+9. 继续在搜索框中搜索`群会话`，勾选 **chat相关接口的管理权限**和 **chat相关接口的读取权限**，然后点击**批量申请（2）**。
+
+10. 在弹出对话框中，填写**联系人**、**联系方式**和**申请原因**，然后点击**申请**。待审核通过后，您需要在**权限管理**页面的**全部状态**中筛选**已开通**，点击**确定**，然后手动点击 **chat相关接口的管理权限**和 **chat相关接口的读取权限**右侧的**申请权限**。
+
+### 步骤 2：获取会话 ID
+
+目前钉钉官方仅提供一种途径来获取会话 ID，即通过创建会话时的返回值来获取。如果您已知会话 ID，或者不需要通过会话接收通知消息，可跳过此步骤。
+
+1. 登录[钉钉 API Explorer](https://open-dev.dingtalk.com/apiExplorer#/?devType=org&api=dingtalk.oapi.gettoken)，在**获取凭证**下的**获取企业凭证**页面，填写 **appkey** 和 **appsecret**，点击**发起调用**，即可在右侧获取 `access_token`。
+
+2. 在**通讯录管理**下的**用户管理**页面，选择**根据手机号获取userid**，**access_token** 已自动预先填写，在 **mobile** 中填写用户手机号，然后点击**发起调用**，即可在右侧获取 `userid`。
+
+ {{< notice note>}}
+
+ 您只需获取群主的 userid，待创建会话后再在客户端添加群成员。
+
+ {{}}
+
+3. 在**消息通知**下的**群消息**页面，选择**创建群会话**，**access_token** 已自动预先填写，在 **name**、**owner** 和 **useridlist** 中分别填写群名称（本教程使用 `test` 作为示例，您可以按需自行设置）、群主的 userid 和群成员的 userid，然后点击**发起调用**，即可在右侧获取 `chatid`。
+
+### 步骤 3：创建群机器人（可选）
+
+如果您不需要通过群机器人接收通知消息，可跳过此步骤。
+
+1. 登录钉钉电脑客户端，点击用户头像，选择**机器人管理**。
+
+2. 在弹出对话框中，选择**自定义**，然后点击**添加**。
+
+3. 在弹出对话框的**机器人名字**中输入名字（例如`告警通知`），在**添加到群组**中选择群组，在**安全设置**中设置**自定义关键词**和**加签**，勾选**我已阅读并同意《自定义机器人服务及免责条款》**，然后点击**完成**。
+
+ {{< notice note >}}
+
+ 机器人创建完成后不可修改群组。
+
+ {{}}
+
+4. 您可以在**机器人管理**页面点击已创建机器人右侧的 
，查看机器人的具体设置信息，例如 **Webhook**、**自定义关键词**和**加签**。
+
+### 步骤 4：在 KubeSphere 控制台配置钉钉通知
+
+您必须在 KubeSphere 控制台提供钉钉的通知设置，以便 KubeSphere 将通知发送至您的钉钉。
+
+1. 使用具有 `platform-admin` 角色的用户（例如，`admin`）登录 KubeSphere Web 控制台。
+
+2. 点击左上角的**平台管理**，选择**平台设置**。
+
+3. 前往**通知管理**下的**通知配置**，选择**钉钉**。
+
+4. 您可以在**会话设置**下的 **AppKey**、**AppSecret** 和**会话 ID** 中分别输入您的钉钉应用 AppKey、AppSecret、会话 ID，然后点击**添加**以添加会话 ID，您可以添加多个会话 ID。此外，您也可以在**群机器人设置**下的 **Webhook URL**、**关键词**和**密钥**中分别输入您的钉钉机器人 Webhook URL、关键词（输入关键词后请点击**添加**以添加关键词）、加签。操作完成后，点击**确定**。
+
+5. 勾选**通知条件**左侧的复选框即可设置通知条件。
+
+ - **标签**：告警策略的名称、级别或监控目标。您可以选择一个标签或者自定义标签。
+ - **操作符**：标签与值的匹配关系，包括**包含值**，**不包含值**，**存在**和**不存在**。
+ - **值**：标签对应的值。
+ {{< notice note >}}
+ - 操作符**包含值**和**不包含值**需要添加一个或多个标签值。使用回车分隔多个值。
+ - 操作符**存在**和**不存在**判断某个标签是否存在，无需设置标签值。
+ {{}}
+
+ 您可以点击**添加**来添加多个通知条件，或点击通知条件右侧的 来删除通知条件。
+
+6. 配置完成后，您可以点击右下角的**发送测试信息**进行验证。
+
+7. 在右上角，打开**未启用**开关来接收钉钉通知，或者关闭**已启用**开关来停用钉钉通知。
+
+ {{< notice note >}}
+
+ - 通知条件设置后，接收人只会接受符合条件的通知。
+ - 如果您更改了现有配置，则必须点击**确定**以应用更改。
+
+ {{}}
+
+### 步骤 5：接收钉钉通知
+
+配置钉钉通知并添加会话或群机器人后，您需要启用 [KubeSphere 告警系统](../../../../pluggable-components/alerting/)，并为[工作负载](../../../../project-user-guide/alerting/alerting-policy/)或[节点](../../../cluster-wide-alerting-and-notification/alerting-policy/)创建告警策略。告警触发后，您的钉钉将收到通知消息。
+
+请参考下方截图中的钉钉通知消息示例。
+
+
+
+
+
+{{< notice note >}}
+
+- 如果您更新了钉钉通知配置，KubeSphere 将根据最新配置发送通知。
+
+- 默认情况下，KubeSphere 大约每 12 小时针对同一告警发送通知。告警重复间隔主要由 `kubesphere-monitoring-system` 项目中 `alertmanager-main` 密钥的 `repeat_interval` 所控制。您可以按需自定义重复间隔。
+
+- KubeSphere 设有内置告警策略，在不设置任何自定义告警策略的情况下，只要内置告警策略被触发，您的钉钉仍能接收通知消息。
+
+{{}}
+
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md
new file mode 100644
index 000000000..232790990
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-email.md
@@ -0,0 +1,75 @@
+---
+title: "配置邮件通知"
+keywords: 'KubeSphere, Kubernetes, 自定义, 平台'
+description: '配置邮件服务器并添加接收人以接收邮件通知。'
+linkTitle: "配置邮件通知"
+weight: 8722
+---
+
+本教程演示如何配置邮件通知及添加接收人，以便接收告警策略的邮件通知。
+
+## 配置邮件服务器
+
+1. 使用具有 `platform-admin` 角色的用户登录 Web 控制台。
+
+2. 点击左上角的**平台管理**，选择**平台设置**。
+
+3. 导航至**通知管理**下的**通知配置**，选择**邮件**。
+
+4. 在**服务器设置**下，填写以下字段配置邮件服务器。
+
+ - **SMTP 服务器地址**：能够提供邮件服务的 SMTP 服务器地址。端口通常是 `25`。
+ - **使用 SSL 安全连接**：SSL 可以用于加密邮件，从而提高通过邮件传输的信息的安全性。通常来说，您必须为邮件服务器配置证书。
+ - **SMTP 用户名**：SMTP 用户的名称。
+ - **SMTP 密码**：SMTP 帐户的密码。
+ - **发件人邮箱**：发件人的邮箱地址。
+
+5. 点击**确定**。
+
+## 接收设置
+
+### 添加接收人
+
+1. 在**接收设置**下，输入接收人的邮箱地址，点击**添加**。
+
+2. 添加完成后，接收人的邮箱地址将在**接收设置**下列出。您最多可以添加 50 位接收人，所有接收人都将能收到通知。
+
+3. 若想移除接收人，请将鼠标悬停在想要移除的邮箱地址上，然后点击右侧的 。
+
+### 设置通知条件
+
+1. 勾选**通知条件**左侧的复选框即可设置通知条件。
+
+ - **标签**：告警策略的名称、级别或监控目标。您可以选择一个标签或者自定义标签。
+ - **操作符**：标签与值的匹配关系，包括**包含值**，**不包含值**，**存在**和**不存在**。
+ - **值**：标签对应的值。
+ {{< notice note >}}
+ - 操作符**包含值**和**不包含值**需要添加一个或多个标签值。使用回车分隔多个值。
+ - 操作符**存在**和**不存在**判断某个标签是否存在，无需设置标签值。
+ {{}}
+
+2. 您可以点击**添加**来添加多个通知条件。
+
+3. 您可以点击通知条件右侧的 来删除通知条件。
+
+4. 配置完成后，您可以点击右下角的**发送测试信息**进行验证。
+
+5. 在右上角，打开**未启用**开关来接收邮件通知，或者关闭**已启用**开关来停用邮件通知。
+
+ {{< notice note >}}
+ - 通知条件设置后，接收人只会接受符合条件的通知。
+ - 如果您更改了现有配置，则必须点击**确定**以应用更改。
+
+ {{}}
+
+## 接收邮件通知
+
+配置邮件通知并添加接收人后，您需要启用 [KubeSphere 告警](../../../../pluggable-components/alerting/)，并为工作负载或节点创建告警策略。告警触发后，所有接收人都将能收到邮件通知。
+
+{{< notice note >}}
+
+- 如果您更新了邮件服务器配置，KubeSphere 将根据最新配置发送邮件通知。
+- 默认情况下，KubeSphere 大约每 12 小时针对同一告警发送通知。告警重复间隔期主要由 `kubesphere-monitoring-system` 项目中 `alertmanager-main` 密钥的 `repeat_interval` 所控制。您可以按需自定义间隔期。
+- KubeSphere 拥有内置告警策略，在不设置任何自定义告警策略的情况下，只要内置告警策略被触发，您的接收人仍能收到邮件通知。
+
+{{}}
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md
new file mode 100644
index 000000000..46b53cb6a
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-slack.md
@@ -0,0 +1,90 @@
+---
+title: "配置 Slack 通知"
+keywords: 'KubeSphere, Kubernetes, Slack, 通知'
+description: '配置 Slack 通知及添加频道来接收告警策略、事件、审计等通知。'
+linkTitle: "配置 Slack 通知"
+weight: 8725
+---
+
+本教程演示如何配置 Slack 通知及添加频道，以便接收告警策略的通知。
+
+## 准备工作
+
+您需要准备一个可用的 [Slack](https://slack.com/) 工作区。
+
+## 获取 Slack OAuth 令牌 (Token)
+
+首先，您需要创建一个 Slack 应用，以便发送通知到 Slack 频道。若想认证您的应用，则必须创建一个 OAuth 令牌。
+
+1. 登录 Slack 以[创建应用](https://api.slack.com/apps)。
+
+2. 在 **Your Apps** 页面，点击 **Create New App**。
+
+3. 在出现的对话框中，输入应用名称并为其选择一个 Slack 工作区。点击 **Create App** 继续。
+
+4. 在左侧导航栏中，选择 **Features** 下的 **OAuth & Permissions**。在 **Auth & Permissions** 页面，下滑到 **Scopes**，分别点击 **Bot Token Scopes** 和 **User Token Scopes** 下的 **Add an OAuth Scope**，两者都选择 **chart:write** 权限。
+
+5. 上滑到 **OAuth Tokens & Redirect URLs**，点击 **Install to Workspace**。授予该应用访问您工作区的权限，您可以在 **OAuth Tokens for Your Team** 下看到已创建的令牌。
+
+## 在 KubeSphere 控制台上配置 Slack 通知
+
+您必须在 KubeSphere 控制台提供 Slack 令牌用于认证，以便 KubeSphere 将通知发送至您的频道。
+
+1. 使用具有 `platform-admin` 角色的用户登录 Web 控制台。
+
+2. 点击左上角的**平台管理**，选择**平台设置**。
+
+3. 导航到**通知管理**下的**通知配置**，选择 **Slack**。
+
+4. 对于**服务器设置**下的 **Slack 令牌**，您可以选择使用 User OAuth Token 或者 Bot User OAuth Token 进行认证。如果使用 User OAuth Token，将由应用所有者往您的 Slack 频道发送通知；如果使用 Bot User OAuth Token，将由应用发送通知。
+
+5. 在**接收频道设置**下，输入您想要收取通知的频道，点击**添加**。
+
+6. 添加完成后，该频道将在**已添加的频道**下列出。您最多可以添加 20 个频道，所有已添加的频道都将能够收到告警通知。
+
+ {{< notice note >}}
+
+ 若想从列表中移除频道，请点击频道右侧的 **×** 图标。
+
+ {{}}
+
+7. 点击**确定**。
+
+8. 勾选**通知条件**左侧的复选框即可设置通知条件。
+
+ - **标签**：告警策略的名称、级别或监控目标。您可以选择一个标签或者自定义标签。
+ - **操作符**：标签与值的匹配关系，包括**包含值**，**不包含值**，**存在**和**不存在**。
+ - **值**：标签对应的值。
+ {{< notice note >}}
+ - 操作符**包含值**和**不包含值**需要添加一个或多个标签值。使用回车分隔多个值。
+ - 操作符**存在**和**不存在**判断某个标签是否存在，无需设置标签值。
+ {{}}
+
+ 您可以点击**添加**来添加多个通知条件，或点击通知条件右侧的 来删除通知条件。
+
+9. 配置完成后，您可以点击右下角的**发送测试信息**进行验证。
+
+10. 在右上角，打开**未启用**开关来接收 Slack 通知，或者关闭**已启用**开关来停用 Slack 通知。
+
+ {{< notice note >}}
+
+ - 通知条件设置后，接收人只会接受符合条件的通知。
+ - 如果您更改了现有配置，则必须点击**确定**以应用更改。
+
+ {{}}
+
+11. 若想由应用发送通知，请确保将其加入频道。请在 Slack 频道中输入 `/invite @ 来删除条件。
+
+7. 配置完成后，可以点击**发送测试信息**进行验证。
+
+8. 在右上角，可以打开**未开启**开关以启用通知，或关闭**已开启**开关以禁用通知。
+
+9. 完成后点击**确定**。
+
+ {{< notice note >}}
+
+ - 设置通知条件后，接收方只会收到满足条件的通知。
+ - 如果更改现有配置，则必须点击**确定**才能应用修改后的配置。
+
+ {{}}
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md
new file mode 100644
index 000000000..6638b97d0
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/configure-wecom.md
@@ -0,0 +1,104 @@
+---
+title: "配置企业微信通知"
+keywords: 'KubeSphere, Kubernetes, 企业微信, 通知, 告警'
+description: '配置企业微信通知并添加相应 ID 来接收告警通知消息。'
+linkTitle: "配置企业微信通知"
+weight: 8724
+---
+
+本教程演示如何配置企业微信通知并添加相应 ID 来接收告警策略的通知。
+
+## 准备工作
+
+您需要准备一个[企业微信帐号](https://work.weixin.qq.com/wework_admin/register_wx?from=myhome)。
+
+## 动手实验
+
+### 步骤 1：创建应用
+
+1. 登录[企业微信管理后台](https://work.weixin.qq.com/wework_admin/loginpage_wx)，点击**应用管理**。
+
+2. 在**应用管理**页面，点击**自建**下的**创建应用**。
+
+3. 在**创建应用**页面，上传应用 Logo、输入应用名称（例如，`通知测试`），点击**选择部门 / 成员**编辑**可见范围**，然后点击**创建应用**。
+
+ {{< notice note >}}
+
+ 请确保将需要接收通知的用户、部门或标签加入可见范围中。
+
+ {{}}
+
+4. 应用创建完成后即可查看其详情页面，**AgentId** 右侧显示该应用的 ID。点击 **Secret** 右侧的**查看**，然后在弹出对话框中点击**发送**，便可以在企业微信客户端查看 Secret。此外，您还可以点击**编辑**来编辑可见范围。
+
+### 步骤 2：创建部门或标签
+
+1. 在**通讯录**页面的**组织架构**选项卡下，点击**测试**（本教程使用`测试`部门作为示例）右侧的 
，然后选择**添加子部门**。
+
+2. 在弹出对话框中，输入部门名称（例如`测试二组`），然后点击**确定**。
+
+3. 创建部门后，您可以点击右侧的**添加成员**、**批量导入**或**从其他部门移入**来添加成员。添加成员后，点击该成员进入详情页面，查看其帐号。
+
+4. 您可以点击`测试二组`右侧的 来查看其部门 ID。
+
+5. 点击**标签**选项卡，然后点击**添加标签**来创建标签。若管理界面无**标签**选项卡，请点击加号图标来创建标签。
+
+6. 在弹出对话框中，输入标签名称，例如`组长`。您可以按需指定**可使用人**，点击**确定**完成操作。
+
+7. 创建标签后，您可以点击右侧的**添加部门/成员**或**批量导入**来添加部门或成员。点击**标签详情**进入详情页面，可以查看此标签的 ID。
+
+8. 要查看企业 ID，请点击**我的企业**，在**企业信息**页面查看 ID。
+
+### 步骤 3：在 KubeSphere 控制台配置企业微信通知
+
+您必须在 KubeSphere 控制台提供企业微信的相关 ID 和凭证，以便 KubeSphere 将通知发送至您的企业微信。
+
+1. 使用具有 `platform-admin` 角色的用户（例如，`admin`）登录 KubeSphere Web 控制台。
+
+2. 点击左上角的**平台管理**，选择**平台设置**。
+
+3. 前往**通知管理**下的**通知配置**，选择**企业微信**。
+
+4. 在**服务器设置**下的**企业 ID**、**应用 AgentId** 以及**应用 Secret** 中分别输入您的企业 ID、应用 AgentId 以及应用 Secret。
+
+5. 在**接收设置**中，从下拉列表中选择**用户 ID**、**部门 ID** 或者**标签 ID**，输入对应 ID 后点击**添加**。您可以添加多个 ID。
+
+6. 勾选**通知条件**左侧的复选框即可设置通知条件。
+
+ - **标签**：告警策略的名称、级别或监控目标。您可以选择一个标签或者自定义标签。
+ - **操作符**：标签与值的匹配关系，包括**包含值**，**不包含值**，**存在**和**不存在**。
+ - **值**：标签对应的值。
+ {{< notice note >}}
+ - 操作符**包含值**和**不包含值**需要添加一个或多个标签值。使用回车分隔多个值。
+ - 操作符**存在**和**不存在**判断某个标签是否存在，无需设置标签值。
+ {{}}
+
+ 您可以点击**添加**来添加多个通知条件，或点击通知条件右侧的 来删除通知条件。
+
+7. 配置完成后，您可以点击右下角的**发送测试信息**进行验证。
+
+8. 在右上角，打开**未启用**开关来接收企业微信通知，或者关闭**已启用**开关来停用企业微信通知。
+
+ {{< notice note >}}
+
+ - 通知条件设置后，接收人只会接受符合条件的通知。
+ - 如果您更改了现有配置，则必须点击**确定**以应用更改。
+
+ {{}}
+
+### 步骤 4：接收企业微信通知
+
+配置企业微信通知并添加 ID 后，您需要启用 [KubeSphere 告警系统](../../../../pluggable-components/alerting/)，并为[工作负载](../../../../project-user-guide/alerting/alerting-policy/)或[节点](../../../cluster-wide-alerting-and-notification/alerting-policy/)创建告警策略。告警触发后，接收设置中添加的用户或部门将收到通知消息。
+
+请参考下方截图中的企业微信通知消息示例。
+
+
+
+{{< notice note >}}
+
+- 如果您更新了企业微信服务器配置，KubeSphere 将根据最新配置发送通知。
+
+- 默认情况下，KubeSphere 大约每 12 小时针对同一告警发送通知。告警重复间隔主要由 `kubesphere-monitoring-system` 项目中 `alertmanager-main` 密钥的 `repeat_interval` 所控制。您可以按需自定义重复间隔。
+
+- KubeSphere 设有内置告警策略，在不设置任何自定义告警策略的情况下，只要内置告警策略被触发，您的企业微信仍能接收通知消息。
+
+{{}}
diff --git a/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md
new file mode 100644
index 000000000..f02d264c8
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/platform-settings/notification-management/customize-cluster-name.md
@@ -0,0 +1,40 @@
+---
+title: "自定义通知消息中的集群名称"
+keywords: 'KubeSphere, Kubernetes, 平台, 通知'
+description: '了解如何自定义 KubeSphere 发送的通知消息中的集群名称。'
+linkTitle: "自定义通知消息中的集群名称"
+weight: 8721
+---
+
+本文档说明如何自定义 KubeSphere 发送的通知消息中的集群名称。
+
+## 准备工作
+
+您需要有一个具有 `platform-admin` 角色的用户，例如 `admin` 用户。有关更多信息，请参阅[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+## 自定义通知消息中的集群名称
+
+1. 以 `admin` 用户登录 KubeSphere 控制台。
+
+2. 点击右下角的 并选择 **Kubectl**。
+
+3. 在弹出的对话框中，执行以下命令：
+
+ ```bash
+ kubectl edit nm notification-manager
+ ```
+
+4. 在 `.spec.receiver.options.global` 下方添加 `cluster` 字段以自定义您的集群名称：
+
+ ```yaml
+ spec:
+ receivers:
+ options:
+ global:
+ cluster: <集群名称>
+ ```
+
+5. 完成操作后，请保存更改。
+
+
+
diff --git a/content/zh/docs/v3.4/cluster-administration/shut-down-and-restart-cluster-gracefully.md b/content/zh/docs/v3.4/cluster-administration/shut-down-and-restart-cluster-gracefully.md
new file mode 100644
index 000000000..9f09ff515
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/shut-down-and-restart-cluster-gracefully.md
@@ -0,0 +1,89 @@
+---
+title: "关闭和重启集群"
+description: "了解如何平稳地关闭和重启集群。"
+layout: "single"
+
+linkTitle: "关闭和重启集群"
+weight: 89000
+
+icon: "/images/docs/v3.3/docs.svg"
+---
+
+您可能需要临时关闭集群进行维护。本文介绍平稳关闭集群的流程以及如何重新启动集群。
+
+{{< notice warning >}}
+关闭集群是非常危险的操作。您必须完全了解该操作及其后果。请先进行 etcd 备份，然后再继续。通常情况下，建议您逐个维护节点，而不是重新启动整个集群。
+{{}}
+
+## 准备工作
+
+- 请先进行 [etcd 备份](https://etcd.io/docs/current/op-guide/recovery/#snapshotting-the-keyspace)，再关闭集群。
+- 主机之间已设置 SSH [免密登录](https://man.openbsd.org/ssh.1#AUTHENTICATION)。
+
+## 关闭集群
+
+{{< notice tip >}}
+
+- 关闭集群前，请您务必备份 etcd 数据，以便在重新启动集群时如果遇到任何问题，可以通过 etcd 还原集群。
+- 使用本教程中的方法可以平稳关闭集群，但数据损坏的可能性仍然存在。
+
+{{}}
+
+### 步骤 1：获取节点列表
+
+```bash
+nodes=$(kubectl get nodes -o name)
+```
+
+### 步骤 2：关闭所有节点
+
+```bash
+for node in ${nodes[@]}
+do
+ echo "==== Shut down $node ===="
+ ssh $node sudo shutdown -h 1
+done
+```
+
+然后，您可以关闭其他的集群依赖项，例如外部存储。
+
+## 平稳重启集群
+
+平稳关闭集群后，您可以平稳重启集群。
+
+### 准备工作
+
+您已平稳关闭集群。
+
+{{< notice tip >}}
+通常情况下，重新启动集群后可以继续正常使用，但是由于意外情况，该集群可能不可用。例如：
+
+- 关闭集群过程中 etcd 数据损坏。
+- 节点故障。
+- 不可预期的网络错误。
+
+{{}}
+
+### 步骤 1：检查所有集群依赖项的状态
+
+确保所有集群依赖项均已就绪，例如外部存储。
+
+### 步骤 2：打开集群主机电源
+
+等待集群启动并运行，这可能需要大约 10 分钟。
+
+### 步骤 3：检查所有主节点的状态
+
+检查核心组件（例如 etcd 服务）的状态，并确保一切就绪。
+
+```bash
+kubectl get nodes -l node-role.kubernetes.io/master
+```
+
+### 步骤 4：检查所有工作节点的状态
+
+```bash
+kubectl get nodes -l node-role.kubernetes.io/worker
+```
+
+如果您的集群重启失败，请尝试[恢复 etcd 集群](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster)。
diff --git a/content/zh/docs/v3.4/cluster-administration/snapshotclass.md b/content/zh/docs/v3.4/cluster-administration/snapshotclass.md
new file mode 100644
index 000000000..1fd4b9811
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/snapshotclass.md
@@ -0,0 +1,34 @@
+---
+title: "卷快照类"
+keywords: 'KubeSphere, Kubernetes, 持久卷声明, 快照'
+description: '了解如何在 KubeSphere 中管理卷快照类。'
+linkTitle: "卷快照类"
+weight: 8900
+---
+
+卷快照类（Volume Snapshot Class）用于定义卷快照的存储种类。本教程演示如何创建和使用卷快照类。
+
+## 准备工作
+
+- 您需要创建一个企业空间、一个项目和一个用户（例如 `project-regular`）。该用户必须已邀请至该项目，并具有 `operator` 角色。有关更多信息，请参阅[创建企业空间、项目、用户和角色](../../quick-start/create-workspace-and-project/)。
+
+- 您需要确保 Kubernetes 版本为 1.17 或更新版本。
+
+- 您需要确保底层存储插件支持快照。
+
+## 操作步骤
+
+1. 以 `project-regular` 用户登录 KubeSphere Web 控制台并进入项目。在左侧导航栏选择**存储**下的**卷快照类**。
+
+2. 在右侧的**卷快照类**页面，点击**创建**。
+
+3. 在弹出的对话框中，设置卷快照类的名称，点击**下一步**。您也可以设置别名和添加描述信息。
+
+
+4. 在**卷快照类设置**页签，选择供应者和删除策略。
+
+ 删除策略目前支持以下两种：
+
+ - Delete：底层的存储快照会和 VolumeSnapshotContent 对象一起删除。
+ - Retain：底层快照和 VolumeSnapshotContent 对象都会被保留。
+
diff --git a/content/zh/docs/v3.4/cluster-administration/storageclass.md b/content/zh/docs/v3.4/cluster-administration/storageclass.md
new file mode 100644
index 000000000..27b975334
--- /dev/null
+++ b/content/zh/docs/v3.4/cluster-administration/storageclass.md
@@ -0,0 +1,195 @@
+---
+title: "存储类"
+keywords: "存储, 持久卷声明, PV, PVC, 存储类, CSI, Ceph RBD, GlusterFS, 青云QingCloud, "
+description: "了解 PV、PVC 和存储类的基本概念，并演示如何在 KubeSphere 中管理存储类和 PVC。"
+linkTitle: "存储类"
+weight: 8800
+---
+
+本教程演示集群管理员如何管理 KubeSphere 中的存储类。
+
+## 介绍
+
+PV 是集群中的一块存储，可以由管理员事先供应，或者使用存储类来动态供应。和卷 (Volume) 一样，PV 通过卷插件实现，但是它的生命周期独立于任何使用该 PV 的容器组。PV 可以[静态](https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/#static)供应或[动态](https://kubernetes.io/zh/docs/concepts/storage/persistent-volumes/#dynamic)供应。
+
+PVC 是用户对存储的请求。它与容器组类似，容器组会消耗节点资源，而 PVC 消耗 PV 资源。
+
+KubeSphere 支持基于存储类的[动态卷供应](https://kubernetes.io/zh/docs/concepts/storage/dynamic-provisioning/)，以创建 PV。
+
+[存储类](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/)是管理员描述其提供的存储类型的一种方式。不同的类型可能会映射到不同的服务质量等级或备份策略，或由集群管理员制定的任意策略。每个存储类都有一个 Provisioner，用于决定使用哪个卷插件来供应 PV。该字段必须指定。有关使用哪一个值，请参阅 [Kubernetes 官方文档](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#provisioner)或与您的存储管理员确认。
+
+下表总结了各种 Provisioner（存储系统）常用的卷插件。
+
+| 类型 | 描述信息 |
+| -------------------- | ------------------------------------------------------------ |
+| In-tree | 内置并作为 Kubernetes 的一部分运行，例如 [RBD](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#ceph-rbd) 和 [GlusterFS](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#glusterfs)。有关此类插件的更多信息，请参见 [Provisioner](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#provisioner)。 |
+| External-provisioner | 独立于 Kubernetes 部署，但运行上类似于树内 (in-tree) 插件，例如 [NFS 客户端](https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/)。有关此类插件的更多信息，请参见 [External Storage](https://github.com/kubernetes-retired/external-storage)。 |
+| CSI | 容器存储接口，一种将存储资源暴露给 CO（例如 Kubernetes）上的工作负载的标准，例如 [QingCloud-CSI](https://github.com/yunify/qingcloud-csi) 和 [Ceph-CSI](https://github.com/ceph/ceph-csi)。有关此类插件的更多信息，请参见 [Drivers](https://kubernetes-csi.github.io/docs/drivers.html)。 |
+
+## 准备工作
+
+您需要一个拥有**集群管理**权限的帐户。例如，您可以直接以 `admin` 身份登录控制台，或者创建一个拥有该权限的新角色并将它分配至一个用户。
+
+## 创建存储类
+
+1. 点击左上角的**平台管理**，然后选择**集群管理**。
+
+2. 如果您启用了[多集群功能](../../multicluster-management/)并导入了成员集群，可以选择一个特定集群。如果您未启用该功能，请直接参考下一步。
+
+3. 在**集群管理**页面，点击**存储 > 存储类**。
+
+4. 在右侧的**存储类**页面，点击**创建**。
+
+5. 在弹出**创建存储类**对话框，输入存储类名称，点击**下一步**。您也可以设置别名和添加描述信息。
+
+6. 在**存储系统**页签，选择一个存储系统，点击**下一步**。
+
+ 在 KubeSphere 中，您可以直接为 `QingCloud-CSI`、`GlusterFS` 和 `Ceph RBD` 创建存储类。您也可以为其他存储系统创建自定义存储类。
+
+7. 在**存储类设置**页签，设置相关参数，点击**创建**以创建存储类。参数设置项随您选择的存储系统而异。
+
+## 设置存储类
+
+下表列举了几个通用存储类设置项。
+
+
+| 参数 | 描述信息 |
+| :---- | :---- |
+| 卷扩展 | 在 YAML 文件中由 `allowVolumeExpansion` 指定。 |
+| 回收机制 | 在 YAML 文件中由 `reclaimPolicy` 指定。 |
+| 访问模式 | 在 YAML 文件中由 `.metadata.annotations.storageclass.kubesphere.io/supported-access-modes` 指定。默认 `ReadWriteOnce`、`ReadOnlyMany` 和 `ReadWriteMany` 全选。 |
+| 供应者 | 在 YAML 文件中由 `provisioner` 指定。如果您使用 [NFS-Subdir 的 Chart](https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/) 来安装存储类型，可以设为 `cluster.local/nfs-subdir-external-provisioner/`。 |
+| 卷绑定模式 | 在 YAML 文件中由 `volumeBindingMode` 指定。它决定使用何种绑定模式。**延迟绑定**即持久性声明创建后，当使用此持久性声明的容器组被创建时，此持久性声明才绑定到一个持久卷。**立即绑定**即持久卷声明创建后，立即绑定到一个持久卷。 |
+### QingCloud CSI
+
+QingCloud CSI 是 Kubernetes 上的 CSI 插件，供青云QingCloud 存储服务使用。KubeSphere 控制台上可以创建 QingCloud CSI 的存储类。
+
+#### 准备工作
+
+- QingCloud CSI 在青云QingCloud 的公有云和私有云上均可使用。因此，请确保将 KubeSphere 安装至二者之一，以便可以使用云存储服务。
+- KubeSphere 集群上已经安装 QingCloud CSI 插件。有关更多信息，请参见[安装 QingCloud CSI](https://github.com/yunify/qingcloud-csi#installation)。
+
+#### 参数设置项
+
+
+| 参数 | 描述信息 |
+| :---- | :---- |
+| 类型 | 在青云云平台中，0 代表性能型硬盘；2 代表容量型硬盘；3 代表超高性能型硬盘；5 代表企业级分布式 SAN（NeonSAN）型硬盘；100 代表基础型硬盘；200 代表 SSD 企业型硬盘。 |
+| 容量上限 | 卷容量上限。 |
+| 步长 | 卷的增量值。 |
+| 容量下限 | 卷容量下限。 |
+| 文件系统类型 | 支持 ext3、ext4 和 XFS。默认类型为 ext4。 |
+| 标签 | 为卷添加标签。使用半角逗号（,）分隔多个标签。 |
+
+有关存储类参数的更多信息，请参见 [QingCloud CSI 用户指南](https://github.com/yunify/qingcloud-csi/blob/master/docs/user-guide.md#set-storage-class)。
+
+### GlusterFS
+
+GlusterFS 是 Kubernetes 上的一种树内存储插件，即您不需要额外安装卷插件。
+
+#### 准备工作
+
+已经安装 GlusterFS 存储系统。有关更多信息，请参见 [GlusterFS 安装文档](https://www.gluster.org/install/)。
+
+#### 参数设置项
+
+
+| 参数 | 描述 |
+| :---- | :---- |
+| REST URL | 供应卷的 Heketi REST URL，例如，<Heketi 服务集群 IP 地址>:<Heketi 服务端口号>。 |
+| 集群 ID | Gluster 集群 ID。 |
+| 开启 REST 认证 | Gluster 启用对 REST 服务器的认证。 |
+| REST 用户 | Gluster REST 服务或 Heketi 服务的用户名。 |
+| 密钥所属项目 | Heketi 用户密钥的所属项目。 |
+| 密钥名称 | Heketi 用户密钥的名称。 |
+| GID 最小值 | 卷的 GID 最小值。 |
+| GID 最大值 | 卷的 GID 最大值。 |
+| 卷类型 | 卷的类型。该值可为 none，replicate:<副本数>，或 disperse:<数据>:<冗余数>。如果未设置该值，则默认卷类型为 replicate:3。 |
+
+有关存储类参数的更多信息，请参见 [Kubernetes 文档中的 GlusterFS](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#glusterfs)。
+
+### Ceph RBD
+
+Ceph RBD 也是 Kubernetes 上的一种树内存储插件，即 Kubernetes 中已经安装该卷插件，但您必须在创建 Ceph RBD 的存储类之前安装其存储服务器。
+
+由于 **hyperkube** 镜像[自 1.17 版本开始已被弃用](https://github.com/kubernetes/kubernetes/pull/85094)，树内 Ceph RBD 可能无法在不使用 **hyperkube** 的 Kubernetes 上运行。不过，您可以使用 [RBD Provisioner](https://github.com/kubernetes-retired/external-storage/tree/master/ceph/rbd) 作为替代，它的格式与树内 Ceph RBD 相同。唯一不同的参数是 `provisioner`（即 KubeSphere 控制台上的**存储系统**）。如果您想使用 RBD Provisioner，`provisioner` 的值必须为 `ceph.com/rbd`（在**存储系统**中输入该值，如下图所示）。如果您使用树内 Ceph RBD，该值必须为 `kubernetes.io/rbd`。
+
+#### 准备工作
+
+- 已经安装 Ceph 服务器。有关更多信息，请参见 [Ceph 安装文档](https://docs.ceph.com/en/latest/install/)。
+- 如果您选择使用 RBD Provisioner，请安装插件。社区开发者提供了 [RBD Provisioner 的 Chart](https://github.com/kubesphere/helm-charts/tree/master/src/test/rbd-provisioner)，您可以通过 Helm 用这些 Chart 安装 RBD Provisioner。
+
+#### 参数设置项
+
+| 参数 | 描述 |
+| :---- | :---- |
+| MONITORS| Ceph 集群 Monitors 的 IP 地址。 |
+| ADMINID| Ceph 集群能够创建卷的用户 ID。 |
+| ADMINSECRETNAME| `adminId` 的密钥名称。 |
+| ADMINSECRETNAMESPACE| `adminSecret` 所在的项目。 |
+| POOL | Ceph RBD 的 Pool 名称。 |
+| USERID | Ceph 集群能够挂载卷的用户 ID。 |
+| USERSECRETNAME | `userId` 的密钥名称。 |
+| USERSECRETNAMESPACE | `userSecret` 所在的项目。 |
+| 文件系统类型 | 卷的文件系统类型。 |
+| IMAGEFORMAT | Ceph 卷的选项。该值可为 `1` 或 `2`，选择 `2` 后需要填写 `imageFeatures`。 |
+| IMAGEFEATURES| Ceph 集群的额外功能。仅当设置 `imageFormat` 为 `2` 时，才需要填写该值。 |
+
+有关存储类参数的更多信息，请参见 [Kubernetes 文档中的 Ceph RBD](https://kubernetes.io/zh/docs/concepts/storage/storage-classes/#ceph-rbd)。
+
+### 自定义存储类
+
+如果 KubeSphere 不直接支持您的存储系统，您可以为存储系统创建自定义存储类型。下面的示例向您演示了如何在 KubeSphere 控制台上为 NFS 创建存储类。
+
+#### NFS 介绍
+
+NFS（网络文件系统）广泛用于带有 [nfs-subdir-external-provisioner](https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/)（External-Provisioner 卷插件）的 Kubernetes。您可以点击**自定义**来创建 NFS-Subdir 的存储类型。
+
+{{< notice note >}}
+
+NFS 与部分应用不兼容（例如 Prometheus），可能会导致容器组创建失败。如果确实需要在生产环境中使用 NFS，请确保您了解相关风险或咨询 KubeSphere 技术支持 support@kubesphere.cloud。
+
+{{}}
+
+#### 准备工作
+
+- 有一个可用的 NFS 服务器。
+- 已经安装卷插件 NFS-Subdir。社区开发者提供了 [NFS-SUBDIR 的 Chart](https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/)，您可以通过 Helm 用这些 Chart 安装 NFS-SUBDIR。
+#### 参数设置项
+
+| 键 | 描述信息 | 值 |
+| :---- | :---- | :----|
+| archiveOnDelete | 删除时存档 PVC | `true` |
+
+## 管理存储类
+
+创建存储类型后，点击此存储类型的名称前往其详情页。在详情页点击**编辑 YAML** 来编辑此存储类型的清单文件。您也可以点击**更多操作**并在下拉菜单中选择一项操作：
+
+- **设为默认存储类**：将此存储类设为集群的默认存储类。一个 KubeSphere 集群中仅允许设置一个默认存储类。
+- **设置授权规则**：只允许特定项目和企业空间使用该存储类。
+- **设置卷操作**：管理持久卷声明，包括**卷克隆**、**卷快照创建**、**卷扩容**。开启任意功能前，请联系系统管理员确认存储系统是否支持这些功能。
+- **设置自动扩展**：设置系统在卷剩余空间低于阈值时自动扩容卷。您也可以开启是否自动重启工作负载。
+- **删除**：删除此存储类。
+
+在**持久卷声明**页签上，查看与此存储类相关联的持久卷声明。
diff --git a/content/zh/docs/v3.4/devops-user-guide/_index.md b/content/zh/docs/v3.4/devops-user-guide/_index.md
new file mode 100644
index 000000000..a2e254051
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/_index.md
@@ -0,0 +1,14 @@
+---
+title: "DevOps 用户指南"
+description: "开始使用 KubeSphere DevOps 项目"
+layout: "second"
+
+linkTitle: "DevOps 用户指南"
+weight: 11000
+
+icon: "/images/docs/v3.3/docs.svg"
+---
+
+您可以使用 KubeSphere DevOps 系统在 Kubernetes 集群上部署和管理 CI/CD 任务以及相关的工作负载。本章演示如何在 DevOps 项目中进行管理和操作，包括运行流水线、创建凭证和集成工具等等。
+
+您安装 DevOps 组件时，会自动部署 Jenkins。您可以在 KubeSphere 中像以前一样通过 Jenkinsfile 构建流水线，保持一致的用户体验。此外，KubeSphere 还提供图形编辑面板，可以将整个流程可视化，为您直观地呈现流水线在每个阶段的运行状态。
diff --git a/content/zh/docs/v3.4/devops-user-guide/devops-overview/_index.md b/content/zh/docs/v3.4/devops-user-guide/devops-overview/_index.md
new file mode 100644
index 000000000..a7a86a172
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/devops-overview/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "DevOps 项目"
+weight: 11100
+
+_build:
+ render: false
+---
diff --git a/content/zh/docs/v3.4/devops-user-guide/devops-overview/devops-project-management.md b/content/zh/docs/v3.4/devops-user-guide/devops-overview/devops-project-management.md
new file mode 100644
index 000000000..c1c719faa
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/devops-overview/devops-project-management.md
@@ -0,0 +1,49 @@
+---
+title: "DevOps 项目管理"
+keywords: 'Kubernetes, KubeSphere, DevOps, Jenkins'
+description: '创建并管理 DevOps 项目，了解 DevOps 项目中的各项基本元素。'
+linkTitle: "DevOps 项目管理"
+weight: 11120
+---
+
+本教程演示如何创建和管理 DevOps 项目。
+
+## 准备工作
+
+- 您需要创建一个企业空间和一个用户 (`project-admin`)，必须邀请该用户至该企业空间并赋予 `workspace-self-provisioner` 角色。有关更多信息，请参考[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+- 您需要启用 [KubeSphere DevOps 系统](../../../pluggable-components/devops/)。
+
+## 创建 DevOps 项目
+
+1. 以 `project-admin` 身份登录 KubeSphere 控制台，转到 **DevOps 项目**，然后点击**创建**。
+
+2. 输入 DevOps 项目的基本信息，然后点击**确定**。
+
+ - **名称**：此 DevOps 项目的简明名称，便于用户识别，例如 `demo-devops`。
+ - **别名**：此 DevOps 项目的别名。
+ - **描述信息**：此 DevOps 项目的简要介绍。
+ - **集群设置**：在当前版本中，DevOps 项目无法同时跨多个集群运行。如果您已启用[多集群功能](../../../multicluster-management/)，则必须选择一个集群来运行 DevOps 项目。
+
+3. DevOps 项目创建后，会显示在下图所示的列表中。
+
+## 查看 DevOps 项目
+
+点击刚刚创建的 DevOps 项目，转到其详情页面。具有不同权限的租户可以在 DevOps 项目中执行各种任务，包括创建 CI/CD 流水线和凭证以及管理帐户和角色。
+
+### 流水线
+
+流水线是一系列插件的集合，使您可以持续地测试和构建代码。流水线将持续集成 (CI) 和持续交付 (CD) 进行结合，提供精简的工作流，使您的代码可以自动交付给任何目标。
+
+### 凭证
+
+具有所需权限的 DevOps 项目用户可以为流水线配置凭证，以便与外部环境进行交互。用户在 DevOps 项目中添加凭证后，DevOps 项目就可以使用这些凭证与第三方应用程序（例如 GitHub、GitLab 和 Docker Hub）进行交互。有关更多信息，请参见[凭证管理](../../how-to-use/devops-settings/credential-management/)。
+
+### 成员和角色
+
+与项目相似，DevOps 项目也需要为用户授予不同的角色，然后用户才能在 DevOps 项目中工作。项目管理员（例如 `project-admin`）负责邀请租户并授予他们不同的角色。有关更多信息，请参见[角色和成员管理](../../how-to-use/devops-settings/role-and-member-management/)。
+
+## 编辑或删除 DevOps 项目
+
+1. 点击 **DevOps 项目设置**下的**基本信息**，您可以查看当前 DevOps 项目的概述，包括项目角色和项目成员的数量、项目名称和项目创建者。
+
+2. 点击右侧的 **DevOps 管理**，您可以编辑此 DevOps 项目的基本信息或删除 DevOps 项目。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/devops-overview/overview.md b/content/zh/docs/v3.4/devops-user-guide/devops-overview/overview.md
new file mode 100644
index 000000000..e5e5224b0
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/devops-overview/overview.md
@@ -0,0 +1,46 @@
+---
+title: "概述"
+keywords: 'Kubernetes, KubeSphere, DevOps, 概述'
+description: '了解 DevOps 的基本知识。'
+linkTitle: "概述"
+weight: 11110
+---
+
+DevOps 是一系列做法和工具，可以使 IT 和软件开发团队之间的流程实现自动化。其中，随着敏捷软件开发日趋流行，持续集成 (CI) 和持续交付 (CD) 已经成为该领域一个理想的解决方案。在 CI/CD 工作流中，每次集成都通过自动化构建来验证，包括编码、发布和测试，从而帮助开发者提前发现集成错误，团队也可以快速、安全、可靠地将内部软件交付到生产环境。
+
+不过，传统的 Jenkins Controller-Agent 架构（即多个 Agent 为一个 Controller 工作）有以下不足。
+
+- 如果 Controller 宕机，整个 CI/CD 流水线会崩溃。
+- 资源分配不均衡，一些 Agent 的流水线任务 (Job) 出现排队等待，而其他 Agent 处于空闲状态。
+- 不同的 Agent 可能配置环境不同，并需要使用不同的编码语言。这种差异会给管理和维护带来不便。
+
+## 了解 KubeSphere DevOps
+
+KubeSphere DevOps 项目支持源代码管理工具，例如 GitHub、Git 和 SVN。用户可以通过图形编辑面板 (Jenkinsfile out of SCM) 构建 CI/CD 流水线，或者从代码仓库 (Jenkinsfile in SCM) 创建基于 Jenkinsfile 的流水线。
+
+### 功能
+
+KubeSphere DevOps 系统为您提供以下功能：
+
+- 独立的 DevOps 项目，提供访问可控的 CI/CD 流水线。
+- 开箱即用的 DevOps 功能，无需复杂的 Jenkins 配置。
+- 支持 [Source-to-image (S2I)](../../../project-user-guide/image-builder/source-to-image/) 和 [Binary-to-image (B2I)](../../../project-user-guide/image-builder/binary-to-image/)，快速交付镜像。
+- [基于 Jenkinsfile 的流水线](../../../devops-user-guide//how-to-use/pipelines/create-a-pipeline-using-jenkinsfile)，提供一致的用户体验，支持多个代码仓库。
+- [图形编辑面板](../../../devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel/)，用于创建流水线，学习成本低。
+- 强大的工具集成机制，例如 [SonarQube](../../../devops-user-guide/how-to-integrate/sonarqube/)，用于代码质量检查。
+
+### KubeSphere CI/CD 流水线工作流
+
+KubeSphere CI/CD 流水线基于底层 Kubernetes Jenkins Agent 而运行。这些 Jenkins Agent 可以动态扩缩，即根据任务状态进行动态供应或释放。Jenkins Controller 和 Agent 以 Pod 的形式运行在 KubeSphere 节点上。Controller 运行在其中一个节点上，其配置数据存储在一个持久卷声明中。Agent 运行在各个节点上，但可能不会一直处于运行状态，而是根据需求动态创建并自动删除。
+
+当 Jenkins Controller 收到构建请求，会根据标签动态创建运行在 Pod 中的 Jenkins Agent 并注册到 Controller 上。当 Agent 运行完任务后，将会被释放，相关的 Pod 也会被删除。
+
+### 动态供应 Jenkins Agent
+
+动态供应 Jenkins Agent 有以下优势：
+
+**资源分配合理**：KubeSphere 动态分配已创建的 Agent 至空闲节点，避免因单个节点资源利用率高而导致任务排队等待。
+
+**高可扩缩性**：当 KubeSphere 集群因资源不足而导致任务长时间排队等待时，您可以向集群新增节点。
+
+**高可用性**：当 Jenkins Controller 故障时，KubeSphere 会自动创建一个新的 Jenkins Controller 容器，并将持久卷挂载至新创建的容器，保证数据不会丢失，从而实现集群高可用。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/examples/_index.md b/content/zh/docs/v3.4/devops-user-guide/examples/_index.md
new file mode 100644
index 000000000..aa3584278
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/examples/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "示例"
+weight: 11400
+
+_build:
+ render: false
+---
diff --git a/content/zh/docs/v3.4/devops-user-guide/examples/a-maven-project.md b/content/zh/docs/v3.4/devops-user-guide/examples/a-maven-project.md
new file mode 100644
index 000000000..e8697c978
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/examples/a-maven-project.md
@@ -0,0 +1,162 @@
+---
+title: "构建和部署 Maven 项目"
+keywords: 'Kubernetes, Docker, DevOps, Jenkins, Maven'
+description: '学习如何使用 KubeSphere 流水线构建并部署 Maven 项目。'
+linkTitle: "构建和部署 Maven 项目"
+weight: 11430
+---
+
+## 准备工作
+
+- 您需要[启用 KubeSphere DevOps 系统](../../../pluggable-components/devops/)。
+- 您需要有一个 [Docker Hub](http://www.dockerhub.com/) 帐户。
+- 您需要创建一个企业空间、一个 DevOps 项目和一个用户，并需要邀请该用户至 DevOps 项目中并赋予 `operator` 角色。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+
+## Maven 项目的工作流
+
+KubeSphere DevOps 中有针对 Maven 项目的工作流，如下图所示，它使用 Jenkins 流水线来构建和部署 Maven 项目。所有步骤均在流水线中进行定义。
+
+
+
+首先，Jenkins Master 创建一个 Pod 来运行流水线。Kubernetes 创建 Pod 作为 Jenkins Master 的 Agent，该 Pod 会在流水线完成之后销毁。主要流程包括克隆代码、构建和推送镜像以及部署工作负载。
+
+## Jenkins 中的默认配置
+
+### Maven 版本
+
+在 Maven 构建器 (Builder) 容器中执行以下命令获取版本信息。
+
+```bash
+mvn --version
+
+Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z)
+Maven home: /opt/apache-maven-3.5.3
+Java version: 1.8.0_232, vendor: Oracle Corporation
+Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.232.b09-0.el7_7.i386/jre
+Default locale: en_US, platform encoding: UTF-8
+```
+
+### Maven 缓存
+
+Jenkins Agent 通过节点上的 Docker 存储卷 (Volume) 挂载目录。流水线可以缓存一些特殊目录，例如 `/root/.m2`，这些特殊目录用于 Maven 构建并在 KubeSphere DevOps 中用作 Maven 工具的默认缓存目录，以便依赖项包下载和缓存到节点上。
+
+### Jenkins Agent 中的全局 Maven 设置
+
+Maven 设置的默认文件路径是 `maven`，配置文件路径是 `/opt/apache-maven-3.5.3/conf/settings.xml`。执行以下命令获取 Maven 的设置内容。
+
+```bash
+kubectl get cm -n kubesphere-devops-worker ks-devops-agent -o yaml
+```
+
+### Maven Pod 的网络
+
+具有 `maven` 标签的 Pod 使用 docker-in-docker 网络来运行流水线，即节点中的 `/var/run/docker.sock` 被挂载至该 Maven 容器。
+
+## Maven 流水线示例
+
+### Maven 项目准备工作
+
+- 确保您在开发设备上成功构建 Maven 项目。
+- 添加 Dockerfile 至项目仓库以构建镜像。有关更多信息，请参考 。
+
+2. 转到**仓库**页面，您可以看到 Nexus 提供了三种仓库类型。
+
+ - `proxy`：远程仓库代理，用于下载资源并将其作为缓存存储在 Nexus 上。
+
+ - `hosted`：在 Nexus 上存储制品的仓库。
+
+ - `group`：一组已配置好的 Nexus 仓库。
+
+3. 点击仓库查看它的详细信息。例如：点击 **maven-public** 进去详情页面，并且查看它的 **URL**。
+
+### 步骤 2：在 GitHub 仓库修改 `pom.xml`
+
+1. 登录 GitHub，Fork [示例仓库](https://github.com/devops-ws/learn-pipeline-java)到您的 GitHub 帐户。
+
+2. 在您的 **learn-pipline-java** GitHub 仓库中，点击根目录下的文件 `pom.xml`。
+
+3. 在文件中点击 
以修改 `| 代码仓库 | +参数 | +
|---|---|
| GitHub | +凭证：选择访问代码仓库的凭证。 | +
| GitLab | +
+
|
+
| Bitbucket | +
+
|
+
| Git | +
+
|
+
，您可以执行以下操作：
+
+ - 编辑：修改代码仓库别名和描述信息以及重新选择代码仓库。
+ - 编辑 YAML：编辑代码仓库 YAML 文件。
+ - 删除：删除代码仓库。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md
new file mode 100644
index 000000000..a025fafa8
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "持续部署"
+weight: 11220
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md
new file mode 100755
index 000000000..80cc93016
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/continuous-deployments/use-gitops-for-continous-deployment.md
@@ -0,0 +1,404 @@
+---
+title: "使用 GitOps 实现应用持续部署"
+keywords: 'Kubernetes, GitOps, KubeSphere, CI，CD, 持续集成，持续部署'
+description: '介绍如何在 KubeSphere 中使用 GitOps 实现持续部署。'
+linkTitle: "使用 GitOps 实现应用持续部署"
+weight: 11221
+---
+
+KubeSphere 3.3 引入了一种为云原生应用实现持续部署的理念 – GitOps。GitOps 的核心思想是拥有一个 Git 仓库，并将应用系统的申明式基础架构和应用程序存放在 Git 仓库中进行版本控制。GitOps 结合 Kubernetes 能够利用自动交付流水线将更改应用到指定的任意多个集群中，从而解决跨云部署的一致性问题。
+
+本示例演示如何创建持续部署实现应用的部署。
+
+## 准备工作
+
+- 您需要有一个企业空间、一个 DevOps 项目和一个用户 (**project-regular**)，并已邀请此帐户至 DevOps 项目中且授予 **operator** 角色。如果尚未准备好，请参考[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+- 您需要启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+## 导入代码仓库
+
+1. 以 **project-regular** 用户登录 KubeSphere 控制台，在左侧导航树，点击 **DevOps 项目**。
+
+2. 在右侧的 **DevOps 项目**页面，点击您创建的 DevOps 项目。
+
+3. 在左侧的导航树，点击**代码仓库**。
+
+4. 在右侧的**代码仓库**页面，点击**导入**。
+
+5. 在**导入代码仓库**对话框，输入代码仓库名称，如 **open-podcasts**，并选择代码仓库。您也可以为代码仓库设置别名和添加描述信息。
+
+
+6. 在**选择代码仓库**对话框，点击 **Git**，在**代码仓库地址**区域，输入代码仓库地址，如 **https://github.com/kubesphere-sigs/open-podcasts**，点击**确定**。
+
+ {{< notice note >}}
+
+ 此处导入的是公共仓库，因此不需要创建凭证。如果您添加的是私有仓库，则需要创建凭证。更多关于如何添加凭证的信息，请参阅[凭证管理](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/)。
+
+ {{}}
+
+## 创建持续部署
+
+1. 在左侧的导航树，点击**持续部署**。
+
+2. 在右侧的**持续部署**页面，点击**创建**。
+
+3. 在**基本信息**页签，输入持续部署名称，如 **open-podcasts**，并选择上一步创建的代码仓库，您也可以设置别名和添加描述信息，点击**下一步**。
+
+4. 在**部署设置**页签，选择持续部署的部署集群和项目。
+
+5. 在**代码仓库设置**区域，设置代码仓库的分支或标签以及 Kustomization 清单文件路径。
+
+ | 参数 | +描述 | +
|---|---|
+
+
+ 修订版本 + |
+
+
+
+ Git 仓库中的 commit ID、分支或标签。例如，master, v1.2.0, 0a1b2c3 或 HEAD。 + |
+
+
+
+ 清单文件路径 + |
+
+
+
+ 设置清单文件路径。例如，config/default。 + |
+
| 参数 | +描述 | +
|---|---|
+
+
+ 清理资源 + |
+
+
+
+ 如果勾选，自动同步时会删除 Git 仓库中不存在的资源。不勾选时，自动同步触发时不会删除集群中的资源。 + |
+
+
+
+ 自纠正 + |
+
+
+
+ 如果勾选，当检测到 Git 仓库中定义的状态与部署资源中有偏差时，将强制应用 Git 仓库中的定义。不勾选时，对部署资源做更改时不会触发自动同步。 + |
+
| 参数 | +描述 | +
|---|---|
+
+
+ 清理资源 + |
+
+
+
+ 如果勾选，同步会删除 Git 仓库中不存在的资源。不勾选时，同步不会删除集群中的资源，而是会显示 out-of-sync。 + |
+
+
+
+ 模拟运行 + |
+
+
+
+ 模拟同步，不影响最终部署资源。 + |
+
+
+
+ 仅执行 Apply + |
+
+
+
+ 如果勾选，同步应用资源时会跳过 pre/post 钩子，仅执行 kubectl apply。 + |
+
+
+
+ 强制 Apply + |
+
+
+
+ 如果勾选，同步时会执行 kubectl apply --force。 + |
+
| 参数 | +描述 | +
|---|---|
+
+
+ 跳过规范校验 + |
+
+
+
+ 跳过 kubectl 验证。执行 kubectl apply 时，增加 --validate=false 标识。 + |
+
+
+
+ 自动创建项目 + |
+
+
+
+ 在项目不存在的情况下自动为应用程序资源创建项目。 + |
+
+
+
+ 最后清理 + |
+
+
+
+ 同步操作时，其他资源都完成部署且处于健康状态后，再清理资源。 + |
+
+
+
+ 选择性同步 + |
+
+
+
+ 仅同步 out-of-sync 状态的资源。 + |
+
| 参数 | +描述 | +
|---|---|
+
+
+ foreground + |
+
+
+
+ 先删除依赖资源，再删除主资源。 + |
+
+
+
+ background + |
+
+
+
+ 先删除主资源，再删除依赖资源。 + |
+
+
+
+ orphan + |
+
+
+
+ 删除主资源，留下依赖资源成为孤儿。 + |
+
| 参数 | +描述信息 | +
|---|---|
| 名称 | +持续部署的名称。 | +
| 健康状态 | +持续部署的健康状态。主要包含以下几种状态： +
|
+
| 同步状态 | +持续部署的同步状态。主要包含以下几种状态： +
|
+
| 部署位置 | +资源部署的集群和项目。 | +
| 更新时间 | +资源更新的时间。 | +
，您可以执行以下操作：
+ - **编辑信息**：编辑别名和描述信息。
+ - **编辑 YAML**：编辑持续部署的 YAML 文件。
+ - **同步**：触发资源同步。
+ - **删除**：删除持续部署。
+
+ {{< notice warning >}}
+
+ 删除持续部署的同时会删掉和该持续部署关联的资源。请谨慎操作。
+
+ {{}}
+
+3. 点击已创建的持续部署进入详情页面，可以查看同步状态和同步结果。
+
+## 访问已创建的应用
+
+1. 进入持续部署所在的项目，在左侧导航栏，点击**服务**。
+
+2. 在右侧的**服务**区域，找到已部署的应用，并点击右侧 ，选择**编辑外部访问**。
+
+3. 在**访问模式**中选择 **NodePort**，点击**确定**。
+
+4. 在服务列表页面的**外部访问**列，查看暴露的端口，通过 {Node IP}:{NodePort} 访问此应用。
+
+ {{< notice note >}}
+ 在访问服务之前，请确保安全组中的端口已打开。
+ {{}}
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md
new file mode 100644
index 000000000..b51076766
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "DevOps 项目设置"
+weight: 11240
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md
new file mode 100644
index 000000000..e768f8258
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/add-cd-allowlist.md
@@ -0,0 +1,28 @@
+---
+title: "添加持续部署白名单"
+keywords: 'Kubernetes, GitOps, KubeSphere, 持续部署，白名单'
+description: '介绍如何在 KubeSphere 中添加持续部署白名单。'
+linkTitle: "添加持续部署白名单"
+weight: 11243
+---
+在 KubeSphere 3.3 中，您可以通过设置白名单限制资源持续部署的目标位置。
+
+## 准备工作
+
+- 您需要有一个企业空间、一个 DevOps 项目和一个用户 (`project-regular`)，并已邀请此帐户至 DevOps 项目中且授予 `operator` 角色。如果尚未准备好，请参考[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+- 您需要启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+- 您需要[导入代码仓库](../../../../devops-user-guide/how-to-use/code-repositories/import-code-repositories/)。
+
+## 操作步骤
+
+1. 以 `project-regular` 用户登录 KubeSphere 控制台，在左侧导航树，点击 **DevOps 项目**。
+
+2. 在右侧的 **DevOps 项目**页面，点击您创建的 DevOps 项目。
+
+3. 在左侧的导航树，选择 **DevOps 项目设置 > 基本信息**。
+
+4. 在右侧**基本信息**下的**持续部署白名单**区域，点击**编辑白名单**。
+
+5. 在弹出的**编辑白名单**对话框，选择代码仓库和部署集群和项目，点击**确定**。您可以继续点击**添加**以添加多个代码仓库和部署位置。
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md
new file mode 100644
index 000000000..3214a8f89
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/credential-management.md
@@ -0,0 +1,93 @@
+---
+title: "凭证管理"
+keywords: 'Kubernetes, Docker, 凭证, KubeSphere, DevOps'
+description: '创建凭证以便您的流水线可以与第三方应用程序或网站进行交互。'
+linkTitle: "凭证管理"
+weight: 11241
+---
+
+凭证是包含敏感信息的对象，例如用户名和密码、SSH 密钥和令牌 (Token)。当 KubeSphere DevOps 流水线运行时，会与外部环境中的对象进行交互，以执行一系列任务，包括拉取代码、推送和拉取镜像以及运行脚本等。此过程中需要提供相应的凭证，而这些凭证不会明文出现在流水线中。
+
+具有必要权限的 DevOps 项目用户可以为 Jenkins 流水线配置凭证。用户在 DevOps 项目中添加或配置这些凭证后，便可以在 DevOps 项目中使用这些凭证与第三方应用程序进行交互。
+
+目前，您可以在 DevOps 项目中创建以下 4 种类型的凭证：
+
+- **用户名和密码**：用户名和密码，可以作为单独的组件处理，或者作为用冒号分隔的字符串（格式为 `username:password`）处理，例如 GitHub 和 GitLab帐户。
+- **SSH 密钥**：带有私钥的用户名，SSH 公钥/私钥对。
+- **访问令牌**：具有访问权限的令牌。
+- **kubeconfig**：用于配置跨集群认证。
+
+本教程演示如何在 DevOps 项目中创建和管理凭证。有关如何使用凭证的更多信息，请参见[使用 Jenkinsfile 创建流水线](../../../../devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-jenkinsfile/)和[使用图形编辑面板创建流水线](../../../../devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel/)。
+
+## 准备工作
+
+- 您已启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 您需要有一个企业空间、一个 DevOps 项目和一个用户 (`project-regular`)，并已邀请此帐户至 DevOps 项目中且授予 `operator` 角色。如果尚未准备好，请参见[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+## 创建凭证
+
+1. 以 `project-regular` 身份登录 KubeSphere 控制台。
+
+2. 进入您的 DevOps 项目，在左侧导航栏，选择**DevOps 项目设置 > 凭证**。
+
+3. 在右侧的**凭证**区域，点击**创建**。
+
+4. 在弹出的**创建凭证**对话框，输入凭证名称，并选择凭证类型。不同的凭证类型需要设置的参数不同，具体请参考以下内容。
+### 创建用户名和密码凭证
+
+以创建 GitHub 用户凭证为例，您需要设置以下参数：
+
+- 名称：设置凭证名称，如 `github-id`。
+- 类型：选择**用户名和密码**。
+- 用户名：输入您的 GitHub 用户名。
+- 密码/令牌：输入您的 GitHub 令牌。
+- 描述：凭证的简介。
+
+{{< notice note >}}
+
+- 自 2021 年 8 月起，GitHub 要求使用基于令牌的身份验证，此处需要输入令牌，而非 GitHub 密码。关于如如何生成令牌，请参阅[创建个人访问令牌](https://docs.github.com/cn/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)。
+
+- 如果您的帐户或密码中包含任何特殊字符，例如 `@` 和 `$`，可能会因为无法识别而在流水线运行时导致错误。在这种情况下，您需要先在一些第三方网站（例如 [urlencoder](https://www.urlencoder.org/)）上对帐户或密码进行编码，然后将输出结果复制粘贴作为您的凭证信息。
+
+{{}}
+
+### 创建 SSH 密钥凭证
+
+您需要设置以下参数：
+
+- 名称：设置凭证名称。
+- 类型：选择**SSH 密钥**。
+- 用户名：输入您的用户名。
+- 私钥：输入您的 SSH 密钥。
+- 密码短语：输入密码短语。为了更好保护您的账户安全，建议设置该参数。
+- 描述：凭证的简介。
+
+### 创建访问令牌凭证
+
+您需要设置以下参数：
+
+- 名称：设置凭证名称。
+- 类型：选择**访问令牌**。
+- 令牌：输入您的令牌。
+- 描述：凭证的简介。
+
+### 创建 kubeconfig 凭证
+
+您需要设置以下参数：
+
+- 名称：设置凭证名称，例如 `demo-kubeconfig`。
+- 类型：选择**kubeconfig**。
+- 内容：系统自动获取当前 Kubernetes 集群的 kubeconfig 文件内容，并自动填充该字段，您无须做任何更改。但是访问其他集群时，您可能需要更改 kubeconfig。
+- 描述：凭证的简介。
+
+{{< notice info >}}
+
+用于配置集群访问的文件称为 kubeconfig 文件。这是引用配置文件的通用方法。有关更多信息，请参见 [Kubernetes 官方文档](https://kubernetes.io/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
+
+{{}}
+
+## 查看和管理凭证
+
+1. 点击已创建的凭证，进入其详情页面，您可以查看帐户详情和与此凭证相关的所有事件。
+
+2. 您也可以在此页面上编辑或删除凭证。请注意，编辑凭证时，KubeSphere 不会显示现有用户名或密码信息。如果输入新的用户名和密码，则前一个将被覆盖。
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md
new file mode 100644
index 000000000..82fbcb4ec
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/role-and-member-management.md
@@ -0,0 +1,76 @@
+---
+title: "角色和成员管理"
+keywords: 'Kubernetes, KubeSphere, DevOps, 角色, 成员'
+description: '在 DevOps 项目中创建并管理各种角色和成员。'
+linkTitle: "角色和成员管理"
+weight: 11242
+---
+
+本教程演示如何在 DevOps 项目中管理角色和成员。
+
+在 DevOps 项目范围内，您可以向角色授予以下资源的权限：
+
+- 流水线
+- 凭证
+- DevOps 项目设置
+- 访问控制
+
+## 准备工作
+
+至少已创建一个 DevOps 项目，例如 `demo-devops`。此外，您需要一个在 DevOps 项目级别具有 `admin` 角色的用户（例如 `devops-admin`）。
+
+## 内置角色
+
+在 **DevOps 项目角色**中，有三个可用的内置角色，如下所示。创建 DevOps 项目时，KubeSphere 会自动创建内置角色，并且无法编辑或删除这些角色。
+
+| 内置角色 | 描述信息 |
+| ------------------ | ------------------------------------------------------------ |
+| viewer | DevOps 项目观察者，可以查看 DevOps 项目下所有的资源。 |
+| operator | DevOps 项目普通成员，可以在 DevOps 项目下创建流水线凭证等。 |
+| admin | DevOps 项目管理员，可以管理 DevOps 项目下所有的资源。 |
+
+## 创建 DevOps 项目角色
+
+1. 以 `devops-admin` 身份登录控制台，然后前往 **DevOps 项目**页面选择一个 DevOps 项目（例如 `demo-devops`）。
+
+ {{< notice note >}}
+
+ 本教程使用 `devops-admin` 帐户作为示例。只要您使用的帐户被授予的角色包含 DevOps 项目级别**访问控制**中的**成员查看**、**角色管理**和**角色查看**的权限，此帐户便可以创建 DevOps 项目角色。
+
+ {{}}
+
+2. 转到 **DevOps 项目设置**中的 **DevOps 项目角色**，点击**创建**并设置**名称**。在本示例中，将创建一个名为 `pipeline-creator` 的角色。点击**编辑权限**继续。
+
+3. 在**流水线管理**中，选择您希望授予该角色的权限。例如，为此角色选择了**流水线管理**和**流水线查看**。点击**确定**完成操作。
+
+ {{< notice note >}}
+
+ **依赖于**表示首先需要选择主要权限（**依赖于**之后列出的），以便可以分配关联权限。
+
+ {{}}
+
+4. 新创建的角色将列在 **DevOps 项目角色**中。您可以点击右侧的 对其进行编辑。
+
+ {{< notice note >}}
+
+ `pipeline-creator` 角色仅被授予**流水线管理**和**流水线查看**权限，可能无法满足您的实际需求。本示例仅用于演示，您可以根据实际需要创建自定义角色。
+
+ {{}}
+
+## 邀请新成员
+
+1. 在 **DevOps 项目设置**中选择 **DevOps 项目成员**，然后点击**邀请**。
+
+2. 点击 邀请帐户加入此 DevOps 项目，并向此帐户授予 `pipeline-creator` 角色。
+
+ {{< notice note >}}
+
+ 必须先邀请用户加入 DevOps 项目所在的企业空间。
+
+ {{}}
+
+3. 点击**确定**将用户添加到此 DevOps 项目。在 **DevOps 项目成员**中，您可以看到列出了新邀请的成员。
+
+4. 您还可以通过编辑现有成员来更改其角色或将其从 DevOps 项目中删除。
+
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md
new file mode 100644
index 000000000..a84330ffa
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/devops-settings/set-ci-node.md
@@ -0,0 +1,49 @@
+---
+title: "为依赖项缓存设置 CI 节点"
+keywords: 'Kubernetes, Docker, KubeSphere, Jenkins, CICD, 流水线, 依赖项缓存'
+description: '配置专门用于持续集成 (CI) 的一个或一组节点，加快流水线中的构建过程。'
+linkTitle: "为依赖项缓存设置 CI 节点"
+weight: 11245
+---
+
+通常情况下，构建应用程序的过程中需要拉取不同的依赖项。这可能会导致某些问题，例如拉取时间长和网络不稳定，这会进一步导致构建失败。要为您的流水线提供更可靠和稳定的环境，您可以配置一个节点或一组节点，专门用于持续集成 (CI)。这些 CI 节点可以通过使用缓存来加快构建过程。
+
+本教程演示如何设置 CI 节点，以便 KubeSphere 将流水线的任务以及 S2I/B2I 构建的任务调度到这些节点。
+
+## 准备工作
+
+您需要一个具有**集群管理**权限的帐户。例如，您可以直接以 `admin` 身份登录控制台或者创建一个具有该权限的新角色并将该新角色其分配给一个用户。
+
+## 标记 CI 节点
+
+1. 点击左上角的**平台管理**，然后选择**集群管理**。
+
+2. 如果您已经启用[多集群功能](../../../../multicluster-management/)并已导入成员集群，那么您可以选择一个特定集群以查看其节点。如果尚未启用该功能，请直接参考下一步。
+
+3. 转到**节点**下的**集群节点**，您可以在其中查看当前集群中的现有节点。
+
+4. 从列表中选择一个节点用来运行 CI 任务。点击节点名称以转到其详情页面。点击**更多操作**，然后选择**编辑标签**。
+
+5. 在弹出的对话框中，您可以看到一个标签的键是 `node-role.kubernetes.io/worker`。输入 `ci` 作为此标签的值，然后点击**保存**。
+
+ {{< notice note >}}
+
+ 您也可以点击**添加**来按需添加新标签。
+
+ {{}}
+
+## 给 CI 节点添加污点
+
+流水线和 S2I/B2I 工作流基本上会根据[节点亲和性](https://kubernetes.io/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)调度到该节点。如果要将节点专用于 CI 任务，即不允许将其他工作负载调度到该节点，您可以在该节点上添加[污点](https://kubernetes.io/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
+
+1. 点击**更多操作**，然后选择**编辑污点**。
+
+2. 点击**添加污点**，然后输入键 `node.kubernetes.io/ci` 而不指定值。您可以根据需要选择 `阻止调度`、`尽可能阻止调度`或`阻止调度并驱逐现有容器组` 。
+
+3. 点击**保存**。KubeSphere 将根据您设置的污点调度任务。您现在可以回到 DevOps 流水线上进行操作。
+
+ {{< notice tip >}}
+
+ 本教程还涉及与节点管理有关的操作。有关详细信息，请参见[节点管理](../../../../cluster-administration/nodes/)。
+
+ {{}}
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md
new file mode 100644
index 000000000..a74613157
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/_index.md
@@ -0,0 +1,7 @@
+---
+linkTitle: "流水线"
+weight: 11210
+
+_build:
+ render: false
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md
new file mode 100644
index 000000000..2dc40dfe1
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/choose-jenkins-agent.md
@@ -0,0 +1,134 @@
+---
+title: "选择 Jenkins Agent"
+keywords: 'Kubernetes, KubeSphere, Docker, DevOps, Jenkins, Agent'
+description: '指定 Jenkins agent 并为流水线使用内置的 podTemplate。'
+linkTitle: "选择 Jenkins Agent"
+weight: 112190
+---
+
+`agent` 部分指定整个流水线或特定阶段 (Stage) 将在 Jenkins 环境中执行的位置，具体取决于该 `agent` 部分的放置位置。该部分必须在 `pipeline` 块的顶层进行定义，但是阶段级别的使用为可选。有关更多信息，请参见 [Jenkins 官方文档](https://www.jenkins.io/zh/doc/book/pipeline/syntax/#代理)。
+
+## 内置 podTemplate
+
+podTemplate 是一种 Pod 模板，该 Pod 用于创建 Agent。用户可以定义在 Kubernetes 插件中使用的 podTemplate。
+
+当流水线运行时，每个 Jenkins Agent Pod 必须具有一个名为 `jnlp` 的容器，用于 Jenkins Controller 和 Jenkins Agent 之间进行通信。另外，用户可以在 podTemplate 中添加容器以满足自己的需求。用户可以选择使用自己的 Pod YAML 来灵活地控制运行时环境 (Runtime)，并且可以通过 `container` 命令来切换容器。请参见以下示例。
+
+```groovy
+pipeline {
+ agent {
+ kubernetes {
+ //cloud 'kubernetes'
+ label 'mypod'
+ yaml """
+apiVersion: v1
+kind: Pod
+spec:
+ containers:
+ - name: maven
+ image: maven:3.3.9-jdk-8-alpine
+ command: ['cat']
+ tty: true
+"""
+ }
+ }
+ stages {
+ stage('Run maven') {
+ steps {
+ container('maven') {
+ sh 'mvn -version'
+ }
+ }
+ }
+ }
+}
+```
+
+同时，KubeSphere 内置了一些 podTemplate，用户无需编写 YAML 文件，极大降低学习成本。
+
+在目前版本中，KubeSphere 内置了 4 种类型的 podTemplate：`base`、`nodejs`、`maven` 和 `go`，并且在 Pod 中提供隔离的 Docker 环境。
+
+您可以通过指定 Agent 的标签来使用内置 podTempalte。例如，要使用 nodejs 的 podTemplate，您可以在创建流水线时指定标签为 `nodejs`，具体参见以下示例。
+
+
+
+```groovy
+pipeline {
+ agent {
+ node {
+ label 'nodejs'
+ }
+ }
+
+ stages {
+ stage('nodejs hello') {
+ steps {
+ container('nodejs') {
+ sh 'yarn -v'
+ sh 'node -v'
+ sh 'docker version'
+ sh 'docker images'
+ }
+ }
+ }
+ }
+}
+```
+
+### podTemplate base
+
+| 名称 | 类型 / 版本 |
+| --- | --- |
+|Jenkins Agent 标签 | base |
+|容器名称 | base |
+| 操作系统 | centos-7 |
+|Docker| 18.06.0|
+|Helm | 2.11.0 |
+|Kubectl| 稳定版 |
+|内置工具 | unzip、which、make、wget、zip、bzip2、git |
+
+
+### podTemplate nodejs
+
+| 名称 | 类型 / 版本 |
+| --- | --- |
+|Jenkins Agent 标签 | nodejs |
+|容器名称 | nodejs |
+| 操作系统 | centos-7 |
+|Node | 9.11.2 |
+|Yarn | 1.3.2 |
+| Docker | 18.06.0 |
+| Helm | 2.11.0 |
+|Kubectl | 稳定版 |
+|内置工具| unzip、which、make、wget、zip、bzip2、git |
+
+
+### podTemplate maven
+
+| 名称 | 类型 / 版本 |
+| --- | --- |
+| Jenkins Agent 标签 | maven |
+| 容器名称 | maven |
+| 操作系统 | centos-7 |
+| Jdk | openjdk-1.8.0 |
+| Maven | 3.5.3|
+| Docker| 18.06.0 |
+| Helm | 2.11.0 |
+| Kubectl| 稳定版 |
+| 内置工具 | unzip、which、make、wget、zip、bzip2、git |
+
+
+### podTemplate go
+
+| 名称 | 类型 / 版本 |
+| --- | --- |
+| Jenkins Agent 标签 | go |
+| 容器名称 | go |
+| 操作系统 | centos-7 |
+| Go | 1.11 |
+| GOPATH | /home/jenkins/go |
+| GOROOT | /usr/local/go |
+| Docker | 18.06.0 |
+| Helm | 2.11.0 |
+| Kubectl | 稳定版 |
+| 内置工具 | unzip、which、make、wget、zip、bzip2、git |
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md
new file mode 100644
index 000000000..f712d34c9
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel.md
@@ -0,0 +1,389 @@
+---
+title: "使用图形编辑面板创建流水线"
+keywords: 'KubeSphere, Kubernetes, Jenkins, CICD, 图形化流水线'
+description: '学习如何使用 KubeSphere 图形编辑面板创建并运行流水线。'
+linkTitle: '使用图形编辑面板创建流水线'
+weight: 11211
+---
+
+KubeSphere 中的图形编辑面板包含用于 Jenkins [阶段 (Stage)](https://www.jenkins.io/zh/doc/book/pipeline/#阶段) 和[步骤 (Step)](https://www.jenkins.io/zh/doc/book/pipeline/#步骤) 的所有必要操作。您可以直接在交互式面板上定义这些阶段和步骤，无需创建任何 Jenkinsfile。
+
+本教程演示如何在 KubeSphere 中使用图形编辑面板创建流水线。KubeSphere 在整个过程中将根据您在编辑面板上的设置自动生成 Jenkinsfile，您无需手动创建 Jenkinsfile。待流水线成功运行，它会相应地在您的开发环境中创建一个部署 (Deployment) 和一个服务 (Service)，并将镜像推送至 Docker Hub。
+
+## 准备工作
+
+- 您需要[启用 KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 您需要有一个 [Docker Hub](http://www.dockerhub.com/) 帐户。
+- 您需要创建一个企业空间、一个 DevOps 项目和一个用户 (`project-regular`)，必须邀请该用户至 DevOps 项目中并赋予 `operator` 角色。如果尚未创建，请参见[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+- 设置 CI 专用节点来运行流水线。有关更多信息，请参见[为缓存依赖项设置 CI 节点](../../../../devops-user-guide/how-to-use/devops-settings/set-ci-node/)。
+- 配置您的电子邮件服务器用于接收流水线通知（可选）。有关更多信息，请参见[为 KubeSphere 流水线设置电子邮件服务器](../../../../devops-user-guide/how-to-use/pipelines/jenkins-email/)。
+- 配置 SonarQube 将代码分析纳入流水线中（可选）。有关更多信息，请参见[将 SonarQube 集成到流水线](../../../../devops-user-guide/how-to-integrate/sonarqube/)。
+
+## 流水线概述
+
+本示例流水线包括以下六个阶段。
+
+
+
+{{< notice note >}}
+
+- **阶段 1：Checkout SCM**：从 GitHub 仓库拉取源代码。
+- **阶段 2：单元测试**：待该测试通过后才会进行下一阶段。
+- **阶段 3：代码分析**：配置 SonarQube 用于静态代码分析。
+- **阶段 4：构建并推送**：构建镜像并附上标签 `snapshot-$BUILD_NUMBER` 推送至 Docker Hub，其中 `$BUILD_NUMBER` 是流水线活动列表中的记录的序列号。
+- **阶段 5：制品**：生成一个制品（JAR 文件包）并保存。
+- **阶段 6：部署至开发环境**：在开发环境中创建一个部署和一个服务。该阶段需要进行审核，部署成功运行后，会发送电子邮件通知。
+
+{{}}
+
+## 动手实验
+
+### 步骤 1：创建凭证
+
+1. 以 `project-regular` 身份登录 KubeSphere 控制台。转到您的 DevOps 项目，在 **DevOps 项目设置**下的**凭证**页面创建以下凭证。有关如何创建凭证的更多信息，请参见[凭证管理](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/)。
+
+ {{< notice note >}}
+
+ 如果您的帐户或密码中有任何特殊字符，例如 `@` 和 `$`，可能会因为无法识别而在流水线运行时导致错误。在这种情况下，您需要先在一些第三方网站（例如 [urlencoder](https://www.urlencoder.org/)）上对帐户或密码进行编码，然后将输出结果复制粘贴作为您的凭证信息。
+
+ {{}}
+
+ | 凭证 ID | 类型 | 用途 |
+ | --------------- | ------------ | ---------- |
+ | dockerhub-id | 用户名和密码 | Docker Hub |
+ | demo-kubeconfig | kubeconfig | Kubernetes |
+
+2. 您还需要为 SonarQube 创建一个凭证 ID (`sonar-token`)，用于上述的阶段 3（代码分析）。请参阅[为新项目创建 SonarQube 令牌 (Token)](../../../../devops-user-guide/how-to-integrate/sonarqube/#create-sonarqube-token-for-new-project)，在**访问令牌**类型的凭证的**令牌**字段中输入 SonarQube 令牌。点击**确定**完成操作。
+
+3. 您可以在列表中看到已创建的三个凭证。
+
+### 步骤 2：创建项目
+
+在本教程中，示例流水线会将 [sample](https://github.com/kubesphere/devops-maven-sample/tree/sonarqube) 应用部署至一个项目。因此，您必须先创建一个项目（例如 `kubesphere-sample-dev`）。待流水线成功运行，会在该项目中自动创建该应用的部署和服务。
+
+您可以使用 `project-admin` 帐户创建项目。此外，该用户也是 CI/CD 流水线的审核员。请确保将 `project-regular` 帐户邀请至该项目并授予 `operator` 角色。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+### 步骤 3：创建流水线
+
+1. 请确保以 `project-regular` 身份登录 KubeSphere 控制台，转到您的 DevOps 项目。在**流水线**页面点击**创建**。
+
+2. 在弹出的对话框中，将它命名为 `graphical-pipeline`，点击**下一步**。
+
+3. 在**高级设置**页面，点击**添加**，添加以下三个字符串参数。这些参数将用于流水线的 Docker 命令。添加完成后，点击**创建**。
+
+ | 参数类型 | 名称 | 值 | 描述信息 |
+ | -------- | ------------------- | --------------- | ------------------------------------------ |
+ | 字符串 | REGISTRY | `docker.io` | 镜像仓库地址。本示例使用 `docker.io`。 |
+ | 字符串 | DOCKERHUB_NAMESPACE | Docker ID | 您的 Docker Hub 帐户或该帐户下的组织名称。 |
+ | 字符串 | APP_NAME | `devops-sample` | 应用名称。 |
+
+ {{< notice note >}}
+
+ 有关其他字段，请直接使用默认值或者参考[流水线设置](../pipeline-settings/)以自定义配置。
+
+ {{}}
+
+4. 创建的流水线会显示在列表中。
+
+### 步骤 4：编辑流水线
+
+- 点击流水线进入其详情页面。要使用图形编辑面板，请点击**任务状态**选项卡下的**编辑流水线**。在弹出的对话框中，点击**自定义流水线**。该流水线包括六个阶段，请按照以下步骤设置每个阶段。
+
+- 您也可以使用 KubeSphere 提供的[内置流水线模板](../use-pipeline-templates/)。
+
+{{< notice note >}}
+
+流水线详情页面会显示**同步状态**，它是 KubeSphere 和 Jenkins 之间的同步结果。若同步成功，您会看到**成功**图标。您也可以点击**编辑 Jenkinsfile** 手动为流水线创建一个 Jenkinsfile。
+
+{{}}
+
+#### 阶段 1：拉取源代码 (Checkout SCM)
+
+图形编辑面板包括两个区域：左侧的**画布**和右侧的**内容**。它会根据您对不同阶段和步骤的配置自动生成一个 Jenkinsfile，为开发者提供更加用户友好的操作体验。
+
+{{< notice note >}}
+
+流水线包括[声明式流水线](https://www.jenkins.io/zh/doc/book/pipeline/syntax/#声明式流水线)和[脚本化流水线](https://www.jenkins.io/zh/doc/book/pipeline/syntax/#脚本化流水线)。目前，您可以使用该面板创建声明式流水线。有关流水线语法的更多信息，请参见 [Jenkins 文档](https://www.jenkins.io/zh/doc/book/pipeline/syntax/)。
+
+{{}}
+
+1. 在图形编辑面板上，从**类型**下拉列表中选择 **node**，从 **Label** 下拉列表中选择 **maven**。
+
+ {{< notice note >}}
+
+ `agent` 用于定义执行环境。`agent` 指令指定 Jenkins 执行流水线的位置和方式。有关更多信息，请参见[选择 Jenkins Agent](../choose-jenkins-agent/)。
+
+ {{}}
+
+ 
+
+2. 请点击左侧的加号图标来添加阶段。点击**添加步骤**上方的文本框，然后在右侧的**名称**字段中为该阶段设置名称（例如 `Checkout SCM`）。
+
+ 
+
+3. 点击**添加步骤**。在列表中选择 **git**，以从 GitHub 拉取示例代码。在弹出的对话框中，填写必需的字段。点击**确定**完成操作。
+
+ - **URL**：输入 GitHub 仓库地址 `https://github.com/kubesphere/devops-maven-sample.git`。请注意，这里是示例地址，您需要使用您自己的仓库地址。
+ - **凭证 ID**：本教程中无需输入凭证 ID。
+ - **分支**：如果您将其留空，则默认为 master 分支。请输入 `sonarqube`，或者如果您不需要代码分析阶段，请将其留空。
+
+ 
+
+4. 第一阶段设置完成。
+
+ 
+
+#### 阶段 2：单元测试
+
+1. 点击阶段 1 右侧的加号图标添加新的阶段，以在容器中执行单元测试。将它命名为 `Unit Test`。
+
+ 
+
+2. 点击**添加步骤**，在列表中选择**指定容器**。将其命名为 `maven` 然后点击**确定**。
+
+ 
+
+3. 点击**添加嵌套步骤**，在 `maven` 容器下添加一个嵌套步骤。在列表中选择 **shell** 并在命令行中输入以下命令。点击**确定**保存操作。
+
+ ```shell
+ mvn clean -gs `pwd`/configuration/settings.xml test
+ ```
+
+ {{< notice note >}}
+
+ 您可以在图形编辑面板上指定在给定阶段指令中执行的一系列[步骤](https://www.jenkins.io/zh/doc/book/pipeline/syntax/#steps)。
+
+ {{}}
+
+
+#### 阶段 3：代码分析（可选）
+
+本阶段使用 SonarQube 来测试您的代码。如果您不需要代码分析，可以跳过该阶段。
+
+1. 点击 `Unit Test` 阶段右侧的加号图标添加一个阶段，以在容器中进行 SonarQube 代码分析。将它命名为 `Code Analysis`。
+
+ 
+
+2. 在 **Code Analysis** 中，点击**任务**下的**添加步骤**，选择**指定容器**。将其命名为 `maven` 然后点击**确定**。
+
+ 
+
+3. 点击 `maven` 容器下的**添加嵌套步骤**，以添加一个嵌套步骤。点击**添加凭证**并从**凭证 ID** 列表中选择 SonarQube 令牌 (`sonar-token`)。在**文本变量**中输入 `SONAR_TOKEN`，然后点击**确定**。
+
+ 
+
+4. 在**添加凭证**步骤下，点击**添加嵌套步骤**为其添加一个嵌套步骤。
+
+ 
+
+5. 点击 **Sonarqube 配置**，在弹出的对话框中保持默认名称 `sonar` 不变，点击**确定**保存操作。
+
+ 
+
+6. 在 **Sonarqube 配置**步骤下，点击**添加嵌套步骤**为其添加一个嵌套步骤。
+
+ 
+
+7. 点击 **shell** 并在命令行中输入以下命令，用于 sonarqube 分支和认证，点击**确定**完成操作。
+
+ ```shell
+ mvn sonar:sonar -Dsonar.login=$SONAR_TOKEN
+ ```
+
+ 
+
+8. 点击**指定容器**步骤下的**添加嵌套步骤**（第三个），选择**超时**。在时间中输入 `1` 并将单位选择为**小时**，点击**确定**完成操作。
+
+ 
+
+ 
+
+9. 点击**超时**步骤下的**添加嵌套步骤**，选择**代码质量检查 (SonarQube)**。在弹出的对话框中选择**检查通过后开始后续任务**。点击**确定**保存操作。
+
+ 
+
+ 
+
+#### 阶段 4：构建并推送镜像
+
+1. 点击前一个阶段右侧的加号图标添加一个新的阶段，以构建并推送镜像至 Docker Hub。将其命名为 `Build and Push`。
+
+ 
+
+2. 点击**任务**下的**添加步骤**，选择**指定容器**，将其命名为 `maven`，然后点击**确定**。
+
+ 
+
+3. 点击 `maven` 容器下的**添加嵌套步骤**添加一个嵌套步骤。在列表中选择 **shell** 并在弹出窗口中输入以下命令，点击**确定**完成操作。
+
+ ```shell
+ mvn -Dmaven.test.skip=true clean package
+ ```
+
+ 
+
+4. 再次点击**添加嵌套步骤**，选择 **shell**。在命令行中输入以下命令，以根据 [Dockerfile](https://github.com/kubesphere/devops-maven-sample/blob/sonarqube/Dockerfile-online) 构建 Docker 镜像。点击**确定**确认操作。
+
+ {{< notice note >}}
+
+ 请勿遗漏命令末尾的点 `.`。
+
+ {{}}
+
+ ```shell
+ docker build -f Dockerfile-online -t $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER .
+ ```
+
+ 
+
+5. 再次点击**添加嵌套步骤**，选择**添加凭证**。在弹出的对话框中填写以下字段，点击**确定**确认操作。
+
+ - **凭证名称**：选择您创建的 Docker Hub 凭证，例如 `dockerhub-id`。
+ - **密码变量**：输入 `DOCKER_PASSWORD`。
+ - **用户名变量**：输入 `DOCKER_USERNAME`。
+
+ {{< notice note >}}
+
+ 出于安全原因，帐户信息在脚本中显示为变量。
+
+ {{}}
+
+ 
+
+6. 在**添加凭证**步骤中点击**添加嵌套步骤**（第一个）。选择 **shell** 并在弹出窗口中输入以下命令，用于登录 Docker Hub。点击**确定**确认操作。
+
+ ```shell
+ echo "$DOCKER_PASSWORD" | docker login $REGISTRY -u "$DOCKER_USERNAME" --password-stdin
+ ```
+
+ 
+
+7. 在**添加凭证**步骤中点击**添加嵌套步骤**。选择 **shell** 并输入以下命令，将 SNAPSHOT 镜像推送至 Docker Hub。点击**确定**完成操作。
+
+ ```shell
+ docker push $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BUILD_NUMBER
+ ```
+
+ 
+
+#### 阶段 5：生成制品
+
+1. 点击 **Build and Push** 阶段右侧的加号图标添加一个新的阶段，以保存制品，将其命名为 `Artifacts`。本示例使用 JAR 文件包。
+
+ 
+
+2. 选中 **Artifacts** 阶段，点击**任务**下的**添加步骤**，选择**保存制品**。在弹出的对话框中输入 `target/*.jar`，用于设置 Jenkins 中制品的保存路径。点击**确定**完成操作。
+
+ 
+
+#### 阶段 6：部署至开发环境
+
+1. 点击 **Artifacts** 阶段右侧的加号图标添加最后一个阶段，将其命名为 `Deploy to Dev`。该阶段用于将资源部署至您的开发环境（即 `kubesphere-sample-dev` 项目）。
+
+ 
+
+2. 点击 **Deploy to Dev** 阶段下的**添加步骤**，在列表中选择**审核**，然后在**消息**字段中填入 `@project-admin`，即 `project-admin` 帐户在流水线运行到该阶段时会进行审核。点击**确定**保存操作。
+
+ 
+
+ {{< notice note >}}
+
+ 在 KubeSphere 3.3 中，能够运行流水线的帐户也能够继续或终止该流水线。此外，流水线创建者或者您指定的帐户也有权限继续或终止流水线。
+
+ {{}}
+
+3. 再次点击 **Deploy to Dev** 阶段下的**添加步骤**。在列表中选择**指定容器**，将其命名为 `maven` 然后点击**确定**。
+
+4. 点击 `maven` 容器步骤下的**添加嵌套步骤**。在列表中选择**添加凭证**，在弹出的对话框中填写以下字段，然后点击**确定**。
+
+ - 凭证名称：选择您创建的 kubeconfig 凭证，例如 `demo-kubeconfig`。
+ - kubeconfig 变量：输入 `KUBECONFIG_CONTENT`。
+
+5. 点击**添加凭证**步骤下的**添加嵌套步骤**。在列表中选择 **shell**，在弹出的对话框中输入以下命令，然后点击**确定**。
+
+ ```shell
+ mkdir ~/.kube
+ echo "$KUBECONFIG_CONTENT" > ~/.kube/config
+ envsubst < deploy/dev-ol/devops-sample-svc.yaml | kubectl apply -f -
+ envsubst < deploy/dev-ol/devops-sample.yaml | kubectl apply -f -
+ ```
+
+6. 如果您想在流水线成功运行时接收电子邮件通知，请点击**添加步骤**，选择**邮件**，以添加电子邮件信息。请注意，配置电子邮件服务器是可选操作，如果您跳过该步骤，依然可以运行流水线。
+
+ {{< notice note >}}
+
+ 有关配置电子邮件服务器的更多信息，请参见[为 KubeSphere 流水线设置电子邮件服务器](../jenkins-email/)。
+
+ {{}}
+
+7. 待您完成上述步骤，请在右下角点击**保存**。随后，您可以看到该流水线有完整的工作流，并且每个阶段也清晰列示。当您用图形编辑面板定义流水线时，KubeSphere 会自动创建相应的 Jenkinsfile。点击**编辑 Jenkinsfile** 查看该 Jenkinsfile。
+
+ {{< notice note >}}
+
+ 在**流水线**页面，您可以点击该流水线右侧的 ，然后选择**复制**来创建该流水线的副本。如果您需要同时运行多个不包含多分支的流水线，您可以全部选中这些流水线，然后点击**运行**来批量运行它们。
+
+ {{}}
+
+### 步骤 5：运行流水线
+
+1. 您需要手动运行使用图形编辑面板创建的流水线。点击**运行**，您可以在弹出的对话框中看到步骤 3 中已定义的三个字符串参数。点击**确定**来运行流水线。
+
+ 
+
+2. 要查看流水线的状态，请转到**运行记录**选项卡，点击您想查看的记录。
+
+3. 稍等片刻，流水线如果成功运行，则会在 **Deploy to Dev** 阶段停止。`project-admin` 作为流水线的审核员，需要进行审批，然后资源才会部署至开发环境。
+
+ 
+
+4. 登出 KubeSphere 控制台，以 `project-admin` 身份重新登录。转到您的 DevOps 项目，点击 `graphical-pipeline` 流水线。在**运行记录**选项卡下，点击要审核的记录。要批准流水线，请点击**继续**。
+
+### 步骤 6：查看流水线详情
+
+1. 以 `project-regular` 身份重新登录控制台。转到您的 DevOps 项目，点击 `graphical-pipeline` 流水线。在**运行记录**选项卡下，点击**状态**下标记为**成功**的记录。
+
+2. 如果所有配置都成功运行，您可以看到所有阶段都已完成。
+
+3. 在右上角点击**查看日志**，查看所有日志。点击每个阶段查看其详细日志。您可以根据日志排除故障和问题，也可以将日志下载到本地进行进一步分析。
+
+### 步骤 7：下载制品
+
+点击**制品**选项卡，然后点击右侧的图标下载该制品。
+
+
+
+### 步骤 8：查看代码分析结果
+
+在**代码检查**页面，可以查看由 SonarQube 提供的本示例流水线的代码分析结果。如果您没有事先配置 SonarQube，则该部分不可用。有关更多信息，请参见[将 SonarQube 集成到流水线](../../../how-to-integrate/sonarqube/)。
+
+
+
+### 步骤 9：验证 Kubernetes 资源
+
+1. 如果流水线的每个阶段都成功运行，则会自动构建一个 Docker 镜像并推送至您的 Docker Hub 仓库。最终，流水线将在您事先设置的项目中自动创建一个部署和一个服务。
+
+2. 前往该项目（本教程中即 `kubesphere-sample-dev`），请点击**应用负载**下的**工作负载**，您可以看到列表中显示的部署。
+
+3. 在**服务**页面，您可以看到示例服务通过 NodePort 暴露其端口号。要访问服务，请访问 `，然后选择**复制**来创建该流水线的副本。如需并发运行不包含多分支的多个流水线，您可以将这些流水线全选，然后点击**运行**来批量运行它们。
+ - 流水线详情页显示**同步状态**，即 KubeSphere 和 Jenkins 的同步结果。若同步成功，您会看到**成功**图标中打上绿色的对号。
+
+ {{}}
+
+2. 在**运行记录**选项卡下，正在扫描三个分支。点击右侧的**运行**，流水线将根据您设置的行为策略来运行。从下拉列表中选择 **sonarqube**，然后添加标签号，例如 `v0.0.2`。点击**确定**触发新活动。
+
+ {{< notice note >}}
+
+ - 如果您在此页面上未看到任何运行记录，则需要手动刷新浏览器或点击下拉菜单（**更多操作**按钮）中的**扫描远程分支**。
+ - 标签名称用于在 GitHub 和 Docker Hub 中指代新生成的发布版本和镜像。现有标签名称不能再次用于字段 `TAG_NAME`。否则，流水线将无法成功运行。
+
+ {{}}
+
+3. 稍等片刻，您会看到一些运行停止，一些运行失败。点击第一个活动查看其详细信息。
+
+ {{< notice note >}}
+
+ 活动失败可能由不同因素所引起。本示例中，在上述步骤中编辑分支环境变量时，仅更改了 sonarqube 分支的 Jenkinsfile。相反地，dependency 和 master 分支中的这些变量保持不变（使用了错误的 GitHub 和 Docker Hub 帐户），从而导致失败。您可以点击该活动，查看其日志中的详细信息。导致失败的其他原因可能是网络问题、Jenkinsfile 中的编码不正确等等。
+
+ {{}}
+
+4. 流水线在 `deploy to dev` 阶段暂停，您需要手动点击**继续**。请注意，在 Jenkinsfile 中分别定义了三个阶段 `deploy to dev`、`push with tag` 和 `deploy to production`，因此将对流水线进行三次审核。
+
+ 在开发或生产环境中，可能需要具有更高权限的人员（例如版本管理员）来审核流水线、镜像以及代码分析结果。他们有权决定流水线是否能进入下一阶段。在 Jenkinsfile 中，您可以使用 `input` 来指定由谁审核流水线。如果您想指定一个用户（例如 `project-admin`）来审核，您可以在 Jenkinsfile 中添加一个字段。如果有多个用户，则需要通过逗号进行分隔，如下所示：
+
+ ```groovy
+ ···
+ input(id: 'release-image-with-tag', message: 'release image with tag?', submitter: 'project-admin,project-admin1')
+ ···
+ ```
+
+ {{< notice note >}}
+
+ 在 KubeSphere 3.3 中，如果不指定审核员，那么能够运行流水线的帐户也能够继续或终止该流水线。如果指定审核员，流水线创建者或者您指定的审核员账户均有权限继续或终止流水线。
+
+ {{}}
+
+### 步骤 6：检查流水线状态
+
+1. 在**运行状态**中，您可以查看流水线的运行状态。请注意，流水线在刚创建后将继续初始化几分钟。示例流水线有八个阶段，它们已在 [Jenkinsfile-online](https://github.com/kubesphere/devops-maven-sample/blob/sonarqube/Jenkinsfile-online) 中单独定义。
+
+2. 点击右上角的**查看日志**来查看流水线运行日志。您可以看到流水线的动态日志输出，包括可能导致流水线无法运行的错误。对于每个阶段，您都可以点击该阶段来查看其日志，而且可以将日志下载到本地计算机进行进一步分析。
+
+### 步骤 7：验证结果
+
+1. 流水线成功运行后，点击**代码检查**通过 SonarQube 查看结果，如下所示。
+
+2. 按照 Jenkinsfile 中的定义，通过流水线构建的 Docker 镜像也已成功推送到 Docker Hub。在 Docker Hub 中，您会看到带有标签 `v0.0.2` 的镜像，该标签在流水线运行之前已指定。
+
+3. 同时，GitHub 中已生成一个新标签和一个新发布版本。
+
+4. 示例应用程序将部署到 `kubesphere-sample-dev` 和 `kubesphere-sample-prod`，并创建相应的部署和服务。转到这两个项目，预期结果如下所示：
+
+ | 环境 | URL | 命名空间 | 部署 | 服务 |
+ | :--- | :--- | :--- | :--- | :--- |
+ | Development | `http://{$NodeIP}:{$30861}` | kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
+ | Production | `http://{$NodeIP}:{$30961}` | kubesphere-sample-prod | ks-sample | ks-sample |
+
+ {{< notice note >}}
+
+ 您可能需要在您的安全组中放行该端口，以便通过 URL 访问应用程序。
+
+ {{}}
+
+### 步骤 8：访问示例服务
+
+1. 以 `admin` 身份登录 KubeSphere 并使用**工具箱**中的 **kubectl** 访问该服务。转到 `kubesphere-sample-dev` 项目，然后在**应用负载**下的**服务**中点击 `ks-sample-dev`。在详情页获取 Endpoint 用于访问该服务。
+
+2. 在右下角的**工具箱**中使用 **kubectl** 执行以下命令：
+
+ ```bash
+ curl 10.233.120.230:8080
+ ```
+
+3. 预期输出:
+
+ ```bash
+ Really appreciate your star, that's the power of our life.
+ ```
+
+ {{< notice note >}}
+
+ 使用 `curl` 访问 Endpoint，或者访问 {$Virtual IP}:{$Port} 或 {$Node IP}:{$NodePort}。
+
+ {{}}
+
+4. 同样地，您可以在项目 `kubesphere-sample-prod` 中测试服务，您将看到相同的输出结果。
+
+ ```bash
+ $ curl 10.233.120.236:8080
+ Really appreciate your star, that's the power of our life.
+ ```
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md
new file mode 100644
index 000000000..c1dd180c1
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/customize-jenkins-agent.md
@@ -0,0 +1,70 @@
+---
+title: "自定义 Jenkins Agent"
+keywords: "KubeSphere, Kubernetes, DevOps, Jenkins, Agent"
+description: "了解如何在 KubeSphere 上自定义 Jenkins Agent。"
+linkTitle: "自定义 Jenkins Agent"
+Weight: 112191
+---
+
+如果您需要使用运行特定环境（例如 JDK 11）的 Jenkins Agent，您可以在 KubeSphere 上自定义 Jenkins Agent。
+
+本文档描述如何在 KubeSphere 上自定义 Jenkins Agent。
+
+## 准备工作
+
+- 您需要启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+## 自定义 Jenkins Agent
+
+1. 以 `admin` 用户登录 KubeSphere Web 控制台。
+
+2. 点击左上角的**平台管理**，选择**集群管理**，然后在左侧导航栏点击**配置**下的**配置字典**。
+
+3. 在**配置字典**页面的搜索框中输入 `jenkins-casc-config` 并按**回车键**。
+
+4. 点击 `jenkins-casc-config` 进入其详情页面，点击**更多操作**，选择**编辑 YAML**。
+
+5. 在弹出的对话框中，搜寻至 `data.jenkins_user.yaml:jenkins.clouds.kubernetes.templates` 下方并输入以下代码，点击**确定**。
+
+ ```yaml
+ - name: "maven-jdk11" # 自定义 Jenkins Agent 的名称。
+ label: "maven jdk11" # 自定义 Jenkins Agent 的标签。若要指定多个标签，请用空格来分隔标签。
+ inheritFrom: "maven" # 该自定义 Jenkins Agent 所继承的现有容器组模板的名称。
+ containers:
+ - name: "maven" # 该自定义 Jenkins Agent 所继承的现有容器组模板中指定的容器名称。
+ image: "kubespheredev/builder-maven:v3.2.0jdk11" # 此镜像只用于测试。您可以使用自己的镜像。
+ ```
+
+ {{< notice note >}}
+
+ 请确保遵守 YAML 文件中的缩进。
+
+ {{}}
+
+6. 请至少等待 70 秒，您的改动会自动重新加载。
+
+7. 要使用自定义 Jenkins Agent，请参考下方的示例 Jenkinsfile，在创建流水线时指定自定义 Jenkins Agent 对应的标签和容器名。
+
+ ```groovy
+ pipeline {
+ agent {
+ node {
+ label 'maven && jdk11'
+ }
+ }
+ stages {
+ stage('Print Maven and JDK version') {
+ steps {
+ container('maven') {
+ sh '''
+ mvn -v
+ java -version
+ '''
+ }
+ }
+ }
+ }
+ }
+ ```
+
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md
new file mode 100644
index 000000000..e22d39590
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/gitlab-multibranch-pipeline.md
@@ -0,0 +1,129 @@
+---
+title: "使用 GitLab 创建多分支流水线"
+keywords: 'KubeSphere, Kubernetes, GitLab, Jenkins, 流水线'
+description: '了解如何使用 GitLab 在 KubeSphere 上创建多分支流水线。'
+linkTitle: "使用 GitLab 创建多分支流水线"
+weight: 11215
+---
+
+[GitLab](https://about.gitlab.com/) 是一个提供公开和私有仓库的开源代码仓库平台。它也是一个完整的 DevOps 平台，专业人士能够使用 GitLab 在项目中执行任务。
+
+在 KubeSphere 3.3 中，您可以使用 GitLab 在 DevOps 项目中创建多分支流水线。本教程介绍如何使用 GitLab 创建多分支流水线。
+
+## 准备工作
+
+- 您需要准备一个 [GitLab](https://gitlab.com/users/sign_in) 帐户以及一个 [Docker Hub](https://hub.docker.com/) 帐户。
+- 您需要[启用 KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 您需要创建一个企业空间、一个 DevOps 项目以及一个用户 (`project-regular`)，该用户必须被邀请至该 DevOps 项目中并赋予 `operator` 角色。有关更多信息，请参考[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+## 动手实验
+
+### 步骤 1：创建凭证
+
+1. 使用 `project-regular` 用户登录 KubeSphere 控制台。转到您的 DevOps 项目，在 **DevOps 项目设置**下的**凭证**中创建以下凭证。有关更多如何创建凭证的信息，请参见[凭证管理](../../../../devops-user-guide/how-to-use/devops-settings/credential-management/)。
+
+ {{< notice note >}}
+
+ 如果您的帐户或密码中包含任何特殊字符，例如 `@` 和 `$`，则可能会因为无法识别而在流水线运行时导致错误。在此情况下，您需要先在第三方网站（例如 [urlencoder](https://www.urlencoder.org/)）上对帐户或密码进行编码，然后将输出结果复制粘贴作为您的凭证信息。
+
+ {{}}
+
+ | 凭证 ID | 类型 | 用途 |
+ | --------------- | ---------- | ---------- |
+ | dockerhub-id | 用户名和密码 | Docker Hub |
+ | gitlab-id | 用户名和密码 | GitLab |
+ | demo-kubeconfig | kubeconfig | Kubernetes |
+
+2. 创建完成后，您可以在列表中看到创建的凭证。
+
+### 步骤 2：在 GitLab 仓库中编辑 Jenkinsfile
+
+1. 登录 GitLab 并创建一个公开项目。点击**导入项目**，选择**从 URL 导入仓库**，然后输入 [devops-maven-sample](https://github.com/kubesphere/devops-maven-sample) 的 URL。可见性级别选择**公开**，然后点击**新建项目**。
+
+2. 在刚刚创建的项目中，从 master 分支中创建一个新分支，命名为 `gitlab-demo`。
+
+3. 在 `gitlab-demo` 分支中，点击根目录中的 `Jenkinsfile-online` 文件。
+
+4. 点击**编辑**，分别将 `GITHUB_CREDENTIAL_ID`、`GITHUB_ACCOUNT` 以及 `@github.com` 更改为 `GITLAB_CREDENTIAL_ID`、`GITLAB_ACCOUNT` 以及 `@gitlab.com`，然后编辑下表所列条目。您还需要将 `push latest` 和 `deploy to dev` 中 `branch` 的值更改为 `gitlab-demo`。
+
+ | 条目 | 值 | 描述信息 |
+ | -------------------- | --------- | ------------------------------------------------------------ |
+ | GITLAB_CREDENTIAL_ID | gitlab-id | 您在 KubeSphere 中为自己的 GitLab 帐户设置的**名称**，用于推送标签至您的 GitLab 仓库。 |
+ | DOCKERHUB_NAMESPACE | felixnoo | 请将其替换为您自己的 Docker Hub 帐户名称，也可以使用该帐户下的组织名称。 |
+ | GITLAB_ACCOUNT | felixnoo | 请将其替换为您自己的 GitLab 帐户名称，也可以使用该帐户的用户组名称。 |
+
+ {{< notice note >}}
+
+ 有关 Jenkinsfile 中环境变量的更多信息，请参考[使用 Jenkinsfile 创建流水线](../create-a-pipeline-using-jenkinsfile/#步骤-2在-github-仓库中修改-jenkinsfile)。
+
+ {{}}
+
+5. 点击 **Commit changes** 更新该文件。
+
+### 步骤 3：创建项目
+
+您需要创建两个项目，例如 `kubesphere-sample-dev` 和 `kubesphere-sample-prod`，这两个项目分别代表开发环境和测试环境。有关更多信息，请参考[使用 Jenkinsfile 创建流水线](../create-a-pipeline-using-jenkinsfile/#步骤-3创建项目)。
+
+### 步骤 4：创建流水线
+
+1. 使用 `project-regular` 用户登录 KubeSphere Web 控制台。转到您的 DevOps 项目，点击**创建**来创建新流水线。
+
+2. 在出现的对话框中填写基本信息。将流水线的名称设置为 `gitlab-multi-branch` 并选择一个代码仓库。
+
+3. 在 **GitLab** 选项卡下的 **GitLab 服务器地址**中选择默认选项 `https://gitlab.com`，在**项目组/所有者**中输入该 GitLab 项目所属组的名称，然后从**代码仓库**的下拉菜单中选择 `devops-maven-sample` 仓库。点击右下角的 **√**，然后点击**下一步**。
+
+ {{< notice note >}}
+
+ 如需使用 GitLab 私有仓库，请参考以下步骤：
+
+ - 在 GitLab 上前往**用户设置 > 访问令牌**，创建拥有 API 和 read_repository 权限的个人访问令牌。
+ - [登录 Jenkins 面板](../../../how-to-integrate/sonarqube/#步骤-5将-sonarqube-服务器添加至-jenkins)，前往**系统管理 > Manage Credentials**，使用您的 GitLab 令牌创建 Jenkins 凭证，用于访问 GitLab。然后前往**系统管理 > 系统配置**，在 **GitLab 服务**中添加该凭证。
+ - 在您的 DevOps 项目中，选择 **DevOps 项目设置 > 凭证**，使用您的 GitLab 令牌创建一个凭证。然后在创建流水线时，您需要在 **GitLab** 页签上的**凭证**中指定该凭证，以便流水线能够从您的 GitLab 私有仓库中拉取代码。
+
+ {{}}
+
+4. 在**高级设置**选项卡中，下滑到**脚本路径**。将其更改为 `Jenkinsfile-online` 然后点击**创建**。
+
+ {{< notice note >}}
+
+ 该字段指定代码仓库中的 Jenkinsfile 路径，它表示该仓库的根目录。如果文件位置变更，则脚本路径也需要更改。
+
+ {{}}
+
+### 步骤 5：运行流水线
+
+1. 流水线创建后，会展示在列表中。点击流水线名称查看其详情页。
+
+2. 点击右侧的**运行**。在出现的对话框中，从下拉菜单中选择 **gitlab-demo** 并添加一个标签号，比如 `v0.0.2`。点击**确定**来触发一个新运行。
+
+ {{< notice note >}}
+
+ 流水线在 `deploy to dev` 阶段暂停，您需要手动点击**继续**。请注意，在 Jenkinsfile 中分别定义了三个阶段 `deploy to dev`、`push with tag` 和 `deploy to production`，因此将对流水线进行三次审核。
+
+ {{}}
+
+### 步骤 6：检查流水线状态
+
+1. 在**运行状态**选项卡，您可以看到流水线的运行过程。点击右上角的**查看日志**来查看流水线运行日志。
+
+2. 您可以看到流水线的动态日志输出，包括可能导致流水线无法运行的错误。对于每个阶段，您都可以点击该阶段来查看日志，而且可以将日志下载到本地计算机进行进一步分析。
+
+### 步骤 7：验证结果
+
+1. 如在 Jenkinsfile 中定义的那样，通过流水线构建的 Docker 镜像已成功推送到 Docker Hub。在 Docker Hub 中，您将看到在流水线运行前指定的带有标签 `v0.0.2` 的镜像。
+
+2. 同时，GitLab 中也已生成一个新标签。
+
+3. 示例应用程序将会被部署至 `kubesphere-sample-dev` 和 `kubesphere-sample-prod` 中，也会创建相应的部署和服务。
+
+ | 环境 | URL | 命名空间 | 部署 | 服务 |
+ | -------- | --------------------------- | ---------------------- | ------------- | ------------- |
+ | 开发环境 | `http://{$NodeIP}:{$30861}` | kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
+ | 生产环境 | `http://{$NodeIP}:{$30961}` | kubesphere-sample-prod | ks-sample | ks-sample |
+
+ {{< notice note >}}
+
+ 您可能需要在安全组中打开端口，以便使用 URL 访问该应用。有关更多信息，请参考[访问示例服务](../create-a-pipeline-using-jenkinsfile/#步骤-8访问示例服务)。
+
+ {{}}
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md
new file mode 100644
index 000000000..caf914543
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-email.md
@@ -0,0 +1,42 @@
+---
+title: "为 KubeSphere 流水线设置电子邮件服务器"
+keywords: 'KubeSphere, Kubernetes, 通知, Jenkins, DevOps, CI/CD, 流水线, 电子邮件服务器'
+description: '设置电子邮件服务器以接收有关您 Jenkins 流水线的通知。'
+linkTitle: "为 KubeSphere 流水线设置电子邮件服务器"
+Weight: 11218
+---
+
+
+内置 Jenkins 无法与平台通知系统共享相同的电子邮件配置。因此，您需要单独为 KubeSphere DevOps 流水线配置电子邮件服务器设置。
+
+## 准备工作
+
+- 您需要启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 您需要一个具有**集群管理**权限的帐户。例如，您可以直接以 `admin` 身份登录控制台或者创建具有该权限的新角色并将该角色分配给一个用户。
+
+## 设置电子邮件服务器
+
+1. 点击左上角的**平台管理**，然后选择**集群管理**。
+
+2. 如果您已经启用[多集群功能](../../../../multicluster-management/)并已导入成员集群，那么您可以选择一个特定集群以查看其节点。如果尚未启用该功能，请直接参考下一步。
+
+3. 转到**应用负载**下的**工作负载**，然后从下拉列表中选择 **kubesphere-devops-system** 项目。点击 `devops-jenkins` 右侧的 并选择**编辑 YAML** 以编辑其 YAML 配置文件。
+
+4. 向下滚动到下图所示的需要指定的字段。完成修改后，点击**确定**以保存。
+
+ {{< notice warning >}}
+
+ 在 `devops-jenkins` 部署 (Deployment) 中修改电子邮件服务器后，它会重新启动。因此，DevOps 系统将在几分钟内不可用，请在适当的时候进行此类修改。
+
+ {{}}
+
+ 
+
+ | 环境变量名称 | 描述信息 |
+ | ----------------- | ------------------------- |
+ | EMAIL\_SMTP\_HOST | SMTP 服务器地址 |
+ | EMAIL\_SMTP\_PORT | SMTP 服务器端口（如：25） |
+ | EMAIL\_FROM\_ADDR | 电子邮件发件人地址 |
+ | EMAIL\_FROM\_NAME | 电子邮件发件人姓名 |
+ | EMAIL\_FROM\_PASS | 电子邮件发件人密码 |
+ | EMAIL\_USE\_SSL | 是否启用 SSL 配置 |
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md
new file mode 100644
index 000000000..3671f7f18
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-setting.md
@@ -0,0 +1,50 @@
+---
+title: "设置 Jenkins 系统"
+keywords: 'Kubernetes, KubeSphere, Jenkins, CasC'
+description: '了解如何自定义您的 Jenkins 设置。'
+linkTitle: '设置 Jenkins 系统'
+Weight: 11216
+---
+
+Jenkins 强大而灵活，已经成为 CI/CD 工作流的事实标准。但是，许多插件要求用户先设置系统级配置，然后才能使用。
+
+KubeSphere DevOps 系统提供基于 Jenkins 的容器化 CI/CD 功能。为了向用户提供可调度的 Jenkins 环境，KubeSphere 使用 **Configuration as Code** 进行 Jenkins 系统设置，这要求用户登录 Jenkins 仪表板并在修改配置后重新加载。Jenkins 系统设置在 KubeSphere 当前版本的控制台上不可用，即将发布的版本将支持该设置。
+
+本教程演示如何在 Jenkins 仪表板上设置 Jenkins 并重新加载配置。
+
+## 准备工作
+
+您已启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+## Jenkins Configuration as Code
+
+KubeSphere 默认安装 Jenkins Configuration as Code 插件，您可以通过 YAML 文件定义 Jenkins 的期望状态，便于再现 Jenkins 的配置（包括插件配置）。您可以[在该目录中](https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos)查看具体的 Jenkins 配置和示例 YAML 文件。
+
+此外，您可以在 [ks-jenkins](https://github.com/kubesphere/ks-jenkins) 仓库中找到 `formula.yaml` 文件，查看插件版本并按需自定义这些版本。
+
+
+
+## 修改 ConfigMap
+
+建议您通过 Configuration as Code (CasC) 在 KubeSphere 中配置 Jenkins。内置 Jenkins CasC 文件存储为 [ConfigMap](../../../../project-user-guide/configuration/configmaps/)。
+
+1. 以 `admin` 身份登录 KubeSphere，点击左上角的**平台管理**，然后选择**集群管理**。
+
+2. 如果您已经启用[多集群功能](../../../../multicluster-management/)并已导入成员集群，您可以选择一个特定集群来编辑 ConfigMap。如果您尚未启用多集群功能，请直接参考下一步。
+
+3. 在左侧导航栏中选择**配置**下的**配置字典**。在**配置字典**页面上，从下拉列表中选择 `kubesphere-devops-system`，然后点击 `jenkins-casc-config`。
+
+4. 在详情页面上，点击**更多操作**，在下拉列表中选择**编辑 YAML**。
+
+5. `jenkins-casc-config` 的配置模板是一个 YAML 文件，位于 `data.jenkins_user.yaml:` 部分。您可以在 ConfigMap 的代理 (Kubernetes Jenkins Agent) 中修改容器镜像、标签、资源请求 (Request) 和限制 (Limit) 等内容，或者在 podTemplate 中添加容器。完成操作后，点击**确定**。
+
+6. 请至少等待 70 秒，您的改动会自动重新加载。
+
+7. 有关如何通过 CasC 设置 Jenkins 的更多信息，请参见 [Jenkins 文档](https://github.com/jenkinsci/configuration-as-code-plugin)。
+
+ {{< notice note >}}
+
+ 在当前版本中，并非所有插件都支持 CasC 设置。CasC 仅会覆盖通过 CasC 设置的插件配置。
+
+ {{}}
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md
new file mode 100644
index 000000000..56d505e81
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/jenkins-shared-library.md
@@ -0,0 +1,122 @@
+---
+title: "在流水线中使用 Jenkins 共享库"
+keywords: 'KubeSphere, Kubernetes, Jenkins, 共享库, 流水线'
+description: '学习如何在流水线中使用 Jenkins 共享库。'
+linkTitle: "在流水线中使用 Jenkins 共享库"
+weight: 11217
+---
+
+对于包含相同阶段或步骤的 Jenkins 流水线，在 Jenkinsfile 中使用 Jenkins 共享库避免流水线代码重复。
+
+本教程演示如何在 KubeSphere DevOps 流水线中使用 Jenkins 共享库。
+
+## 准备工作
+
+- [启用 KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 您需要创建一个企业空间、一个 DevOps 项目和一个用户 (`project-regular`)。必须邀请此帐户至 DevOps 项目中，并且授予 `operator` 角色。有关详细信息，请参阅[创建企业空间、项目、用户和角色](https://kubesphere.io/zh/docs/quick-start/create-workspace-and-project/)。
+- 您需要一个可用 Jenkins 共享库。本教程以 [GitHub 仓库](https://github.com/devops-ws/jenkins-shared-library)中的 Jenkins 共享库为例。
+
+## 在 Jenkins 仪表盘配置共享库
+
+1. [登录 Jenkins 仪表板](../../../how-to-integrate/sonarqube/#步骤-5将-sonarqube-服务器添加至-jenkins)并点击左侧导航栏中的**系统管理**。
+
+2. 向下滚动并点击**系统配置**。
+
+3. 向下滚动到 **Global Pipeline Libraries**，然后点击**新增**。
+
+4. 配置字段如下所示。
+
+ - **Name：** 为共享库设置名称（例如，``demo-shared-library``），以便在 Jenkinsfile 中引用此名称来导入共享库。
+
+ - **Default version：** 设置共享库所在仓库的一个分支名称，将其作为导入共享库的默认分支。本教程将使用 master。
+
+ - 在 **Retrieval method** 下，选择 **Modern SCM**。
+
+ - 在 **Source Code Management** 下，选择 **Git** 并为**项目仓库**输入示例仓库的 URL 。如果您使用自己的仓库且访问此仓库需要凭据，则需要配置**凭据**。
+
+5. 当您结束编辑，请点击**应用**。
+
+ {{< notice note >}}
+
+ 您还可以配置[文件夹级别的共享库](https://www.jenkins.io/zh/doc/book/pipeline/shared-libraries/#folder-level-shared-libraries)。
+
+ {{}}
+
+## 在流水线中使用共享库
+
+
+### 步骤 1： 创建流水线
+
+1. 用 `project-regular` 帐户登录 KubeSphere web 控制台。进入 DevOps 项目并点击**流水线**页面上的**创建**。
+
+2. 在弹出窗口中设置名称（例如，``demo-shared-library``），点击**下一步**。
+
+3. 在**高级设置**中，直接点击**创建**，使用默认设置创建流水线。
+
+### 步骤 2：编辑流水线
+
+1. 在流水线列表中，点击流水线以转到其详细信息页面，然后点击**编辑 Jenkinsfile**。
+
+2. 在显示的对话框中，输入以下示例 Jenkinsfile。完成编辑后，点击**确定**。
+
+ ```groovy
+ library identifier: 'devops-ws-demo@master', retriever: modernSCM([
+ $class: 'GitSCMSource',
+ remote: 'https://github.com/devops-ws/jenkins-shared-library',
+ traits: [[$class: 'jenkins.plugins.git.traits.BranchDiscoveryTrait']]
+ ])
+
+ pipeline {
+ agent any
+
+ stages {
+ stage('Demo') {
+ steps {
+ script {
+ mvn.fake()
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ {{< notice note >}}
+
+ 您可以根据需要为 `agent` 指定 `label`。
+
+ {{}}
+
+3. 或者，您可以使用以 `@Library('<配置好的共享库名称>') _ ` 开头的 Jenkinsfile。如果使用这种类型的 Jenkinsfile，则需要提前在 Jenkins 仪表板上配置共享库。在本教程中，您可以使用以下示例 Jenkinsfile。
+
+ ```groovy
+ @Library('demo-shared-library') _
+
+ pipeline {
+ agent any
+
+ stages {
+ stage('Demo') {
+ steps {
+ script {
+ mvn.fake()
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ {{< notice note >}}
+
+ 您可以使用 `@Library('demo-shared-library@<分支名称>') _` 来指定特定的分支。
+
+ {{}}
+
+### 步骤 3：运行流水线
+
+1. 您可以在**任务状态**选项卡下查看该阶段。点击**运行**运行它。
+
+2. 在一段时间后，流水线将成功运行。
+
+3. 您可以点击**运行记录**下的**成功**记录，然后点击**查看日志**查看日志详细信息。
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-settings.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-settings.md
new file mode 100644
index 000000000..6cc3a8a75
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-settings.md
@@ -0,0 +1,170 @@
+---
+title: "流水线设置"
+keywords: 'KubeSphere, Kubernetes, Docker, Jenkins, 流水线'
+description: '了解 DevOps 项目中流水线的各个属性。'
+linkTitle: "流水线设置"
+weight: 11214
+---
+
+创建流水线时，可以通过各种设置来自定义流水线配置。本文档对这些设置进行详细阐述。
+
+## 准备工作
+
+- 您需要创建一个企业空间、一个 DevOps 项目以及一个用户 (`project-regular`)，必须邀请该用户至该 DevOps 项目中并赋予 `operator` 角色。有关更多信息，请参考[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+- 您需要[启用 KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+## 基本信息
+
+在**基本信息**选项卡，您可以自定义以下信息：
+
+- **名称**：流水线的名称，同一个 DevOps 项目内的流水线不能重名。
+
+- **DevOps 项目**：流水线所属的 DevOps 项目。
+
+- **描述**：描述流水线的附加信息，描述信息不超过 256 个字符。
+
+- **代码仓库（可选）**：您可以选择一个代码仓库作为流水线的代码源。您可以选择 GitHub、GitLab、Bitbucket、Git 以及 SVN 作为代码源。
+
+ {{< tabs >}}
+
+ {{< tab "GitHub" >}}
+
+ 如果选择 **GitHub**，则必须指定用于访问 GitHub 的凭证。如果您已预先使用您的 GitHub 令牌创建了凭证，则可以从下拉菜单中选择已有凭证，或者点击**创建凭证**来创建新凭证。选择凭证后，点击**确定**，即可在右侧查看您的仓库。完成所有操作后，请点击 **√** 图标。
+
+ {{}}
+
+ {{< tab "GitLab" >}}
+
+ 如果选择 **GitLab**，则必须指定 GitLab 服务器地址、项目组/所有者和代码仓库。如果访问代码仓库需要凭证，则需要指定一个凭证。完成所有操作后，请点击 **√** 图标。
+
+ {{}}
+
+ {{< tab "Bitbucket" >}}
+
+ 如果选择 **Bitbucket**，则需要输入您的 Bitbucket 服务器地址。您可以预先使用您的 Bitbucket 用户名和密码创建一个凭证，或者点击**创建凭证**来创建一个新凭证。输入信息后点击**确定**，即可在右侧看到您的仓库。完成所有操作后，请点击 **√** 图标。
+
+ {{}}
+
+ {{< tab "Git" >}}
+
+ 如果选择 **Git**，则需要指定仓库 URL。如果访问代码仓库需要凭证，则需要指定一个凭证。您也可以点击**创建凭证**来添加新凭证。完成所有操作后，请点击 **√** 图标。
+
+ {{}}
+
+ {{< tab "SVN" >}}
+
+ 如果选择 **SVN**，则需要指定仓库地址和凭证。您也可以按需指定包括分支和排除分支。完成所有操作后，请点击 **√** 图标。
+
+ {{}}
+
+ {{}}
+
+## 指定代码仓库时的高级设置
+
+如果您指定一个代码仓库，则可以在**高级设置**选项卡上自定义以下配置：
+
+### 分支设置
+
+**删除旧分支**：自动删除旧分支。分支记录将一起被删除。分支记录包括控制台输出、存档制品以及与特定分支相关的其他元数据。保留较少的分支可以节省 Jenkins 所使用的磁盘空间。KubeSphere 提供两个选项来确定何时丢弃旧的分支：
+
+- **分支保留天数（天）**：超过保留期限的分支将被删除。
+
+- **分支最大数量**：如果分支数量超过最大数量，将删除最旧的分支。
+
+ {{< notice note >}}
+
+ **分支保留天数（天）**和**分支最大数量**同时适用于分支。只要分支满足任一字段的条件，则将被丢弃。例如，如果将保留分支的天数指定为 2，将保留分支的最大个数指定为 3，那么超过任一数目的分支将被丢弃。KubeSphere 默认用 7 和 5 预先填充这两个字段。
+
+ {{}}
+
+### 策略设置
+
+在**策略设置**中，KubeSphere 默认提供四种策略。Jenkins 流水线运行时，开发者提交的 PR (Pull Request) 也将被视为单独的分支。
+
+**发现分支**
+
+- **排除已提交 PR 的分支**：已提交 PR 的分支将被排除。
+- **只包括已提交 PR 的分支**：只拉取已提交 PR 的分支。
+- **包括所有分支**：从仓库中拉取所有分支。
+
+**发现标签**
+
+- **开启标签发现**：拥有指定标签的分支将被扫描。
+- **关闭标签发现**：拥有指定标签的分支不会被扫描。
+
+**从原仓库发现 PR**
+
+- **拉取 PR 合并后的代码**：PR 合并到目标分支后，将基于源代码创建并运行流水线。
+- **拉取 PR 提交时的代码**：根据 PR 本身的源代码创建并运行流水线。
+- **分别创建两个流水线**：KubeSphere 会创建两个流水线，一个流水线使用 PR 本身的源代码版本，一个流水线使用 PR 与目标分支合并后的源代码版本。
+
+**从 Fork 仓库发现 PR**
+
+- **拉取 PR 合并后的代码**：PR 合并到目标分支后，将基于源代码创建并运行流水线。
+- **拉取 PR 提交时的代码**：根据 PR 本身的源代码创建并运行流水线。
+- **分别创建两个流水线**：KubeSphere 会创建两个流水线，一个流水线使用 PR 本身的源代码版本，一个流水线使用 PR 与目标分支合并后的源代码版本。
+- **贡献者**：对 PR 做出贡献的用户。
+- **所有人**：每个可以访问 PR 的用户。
+- **具有管理员或有编辑权限的用户**：仅限于对 PR 具有管理员或编辑权限的用户。
+- **无**：如果选择此选项，那么无论在**拉取策略**中选择了哪个选项，都不会发现 PR。
+
+### 正则过滤
+
+勾选选框以指定正则表达式来过滤分支、PR 和标签。
+
+### 脚本路径
+
+**脚本路径**参数指定代码仓库中的 Jenkinsfile 路径，它指代仓库的根目录。如果文件位置发生更改，则脚本路径也需要更改。
+
+### 扫描触发器
+
+勾选**定时扫描**，并从下拉列表中设置扫描时间间隔。
+
+### 构建触发器
+
+您可以从**创建流水线时触发**和**删除流水线时触发**的下拉列表中选择一个流水线，以便在创建新的流水线或删除流水线时自动触发指定流水线中的任务。
+
+### 克隆设置
+
+- **克隆深度**：克隆时需要提取的 commit 数量。
+- **克隆超时时间（min）**：完成克隆过程所需要的时长（以分钟为单位）。
+- **开启浅克隆**：如果您开启浅克隆，则克隆的代码不会包含标签。
+
+### Webhook
+
+**Webhook** 能有效地让流水线发现远程代码仓库中的更改，并自动触发新一轮运行。Webhook 应成为触发 Jenkins 自动扫描 GitHub 和 Git（例如 GitLab）的主要方法。
+
+## 不指定代码仓库时的高级设置
+
+如果不指定代码仓库，则可以在**高级设置**选项卡上自定义以下配置：
+
+### 构建设置
+
+**删除过期构建记录**：确定何时删除分支下的构建记录。构建记录包括控制台输出、存档制品以及与特定构建相关的其他元数据。保留较少的构建可以节省 Jenkins 所使用的磁盘空间。KubeSphere 提供两个选项来确定应何时删除旧的构建：
+
+- **构建记录保留期限（天）**：超过保留期限的构建记录将被删除。
+
+- **构建记录最大数量**：当构建记录数量超过允许的最大数量，最早的构建记录将被删除。
+
+ {{< notice note >}}
+
+ 这两个条件同时适用于构建。如果首先满足任一条件，构建将会被删除。
+
+ {{}}
+
+- **不允许并发构建**：如果勾选此选项，则不能并发运行多个构建。
+
+### 构建参数
+
+参数化的构建过程允许您在开始运行流水线时传入一个或多个参数。KubeSphere 默认提供五种参数类型，包括**字符串**、**多行字符串**、**布尔值**、**选项** 以及**密码**。当参数化项目时，构建会被替换为参数化构建，其中将提示用户为每个定义的参数输入值。
+
+### 构建触发器
+
+**定时构建**：允许定期执行构建。点击**了解更多**来参照详细的 CRON 语法。
+
+
+
+
+
+
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-webhook.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-webhook.md
new file mode 100644
index 000000000..0288f5a5c
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/pipeline-webhook.md
@@ -0,0 +1,66 @@
+---
+title: "使用 Webhook 触发流水线"
+keywords: 'Kubernetes, DevOps, Jenkins, 流水线, Webhook'
+description: '学习如何使用 webhook 触发 Jenkins 流水线。'
+linkTitle: "使用 Webhook 触发流水线"
+weight: 11219
+---
+
+如果通过远程代码仓库创建基于 Jenkinsfile 的流水线，则可以在远程仓库中配置 webhook，以便对远程仓库进行变更时，自动触发流水线。
+
+本教程演示如何用 webhook 触发流水线。
+
+## 准备工作
+
+- [启用 KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+- 创建一个企业空间、一个 DevOps 项目和一个用户（例如，`project-regular`）。`project-regular` 需要被邀请至 DevOps 项目中并赋予 `operator` 角色。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+- 通过远程代码仓库创建一个基于 Jenkinsfile 的流水线。有关更多信息，请参见[使用 Jenkinsfile 创建流水线](../create-a-pipeline-using-jenkinsfile/)。
+
+## 配置 Webhook
+
+### 获取 webhook URL
+
+1. 使用 `project-regular` 帐户登录 Kubesphere Web 控制台。转到 DevOps 项目，点击流水线（例如，`jenkins-in-scm`）以查看详情页面。
+
+2. 点击**更多**，在下拉菜单中选择**编辑设置**。
+
+3. 在出现的会话框中，滑动至 **Webhook** 以获得 webhook push URL。
+
+### 在 GitHub 仓库中设置 webhook
+
+1. 登录您的 GitHub，并转到 `devops-maven-sample` 仓库。
+
+2. 点击 **Settings**，然后点击 **Webhooks**，然后点击 **Add webhook**。
+
+3. 在 **Payload URL** 中输入流水线中的 webhook push URL，然后点击 **Add webhook**。出于演示需要，本教程选择 **Just the push event**。您可以根据需要进行配置。有关更多信息，请参见 [GitHub 文档](https://docs.github.com/en/developers/webhooks-and-events/webhooks/creating-webhooks)。
+
+4. 配置好的 webhook 会展示在 **Webhooks** 页面。
+
+## 使用 Webhook 触发流水线
+
+### 提交拉取请求到仓库
+
+1. 在您仓库的 **Code** 页面，点击 **master** 然后选择 **sonarqube** 分支。
+
+2. 转到 `/deploy/dev-ol` 然后点击文件 `devops-sample.yaml`。
+
+3. 点击 
以编辑文件。 例如，将 `spec.replicas` 的值改变为 `3`。
+
+4. 在页面底部点击 **Commit changes**。
+
+### 检查 webhook 交付
+
+1. 在您仓库的 **Webhooks** 页面，点击 webhook。
+
+2. 点击 **Recent Deliveries**，然后点击一个具体交付记录查看详情。
+
+### 检查流水线
+
+1. 使用 `project-regular` 帐户登录 Kubesphere Web 控制台。转到 DevOps 项目，点击流水线。
+
+2. 在**运行记录**选项卡，检查提交到远程仓库 `sonarqube` 分支的拉取请求是否触发了新的运行。
+
+3. 转到 `kubesphere-sample-dev` 项目的 **Pods** 页面，检查 3 个 Pods 的状态。如果 3 个 Pods 为运行状态，表示流水线运行正常。
+
+
+
diff --git a/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md
new file mode 100644
index 000000000..4d7d6b9a2
--- /dev/null
+++ b/content/zh/docs/v3.4/devops-user-guide/how-to-use/pipelines/use-pipeline-templates.md
@@ -0,0 +1,92 @@
+---
+title: "使用流水线模板"
+keywords: 'KubeSphere, Kubernetes, Jenkins, 图形化流水线, 流水线模板'
+description: '了解如何在 KubeSphere 上使用流水线模板。'
+linkTitle: "使用流水线模板"
+weight: 11213
+---
+
+KubeSphere 提供图形编辑面板，您可以通过交互式操作定义 Jenkins 流水线的阶段和步骤。KubeSphere 3.3 中提供了内置流水线模板，如 Node.js、Maven 以及 Golang，使用户能够快速创建对应模板的流水线。同时，KubeSphere 3.3 还支持自定义流水线模板，以满足企业不同的需求。
+
+本文档演示如何在 KubeSphere 上使用流水线模板。
+
+## 准备工作
+
+- 您需要有一个企业空间、一个 DevOps 项目和一个用户 (`project-regular`)，并已邀请此帐户至 DevOps 项目中且授予 `operator` 角色。如果尚未准备好，请参考[创建企业空间、项目、用户和角色](../../../../quick-start/create-workspace-and-project/)。
+
+- 您需要启用 [KubeSphere DevOps 系统](../../../../pluggable-components/devops/)。
+
+- 您需要[创建流水线](../../../how-to-use/pipelines/create-a-pipeline-using-graphical-editing-panel/)。
+
+## 使用内置流水线模板
+
+下面以 Node.js 为例演示如何使用内置流水线模板。如果需要使用 Maven 以及 Golang 流水线模板，可参考该部分内容。
+
+1. 以 `project-regular` 用户登录 KubeSphere 控制台，在左侧导航树，点击 **DevOps 项目**。
+
+2. 在右侧的 **DevOps 项目**页面，点击您创建的 DevOps 项目。
+
+3. 在左侧的导航树，点击**流水线**。
+
+4. 在右侧的**流水线**页面，点击已创建的流水线。
+
+5. 在右侧的**任务状态**页签，点击**编辑流水线**。
+
+
+6. 在**创建流水线**对话框，点击 **Node.js**，然后点击**下一步**。
+
+7. 在**参数设置**页签，按照实际情况设置以下参数，点击**创建**。
+
+ | 参数 | 参数解释 |
+ | ----------- | ------------------------- |
+ | GitURL | 需要克隆的项目仓库的地址。 |
+ | GitRevision | 需要检出的分支。 |
+ | NodeDockerImage | Node.js 的 Docker 镜像版本。 |
+ | InstallScript | 安装依赖项的 Shell 脚本。 |
+ | TestScript | 项目测试的 Shell 脚本。 |
+ | BuildScript | 构建项目的 Sell 脚本。 |
+ | ArtifactsPath | 归档文件所在的路径。 |
+
+8. 在左侧的可视化编辑页面，系统默认已添加一系列步骤，您可以添加步骤或并行阶段.
+
+9. 点击指定步骤，在页面右侧，您可以执行以下操作：
+ - 修改阶段名称。
+ - 删除阶段。
+ - 设置代理类型。
+ - 添加条件。
+ - 编辑或删除某一任务。
+ - 添加步骤或嵌套步骤。
+
+ {{< notice note >}}
+
+ 您还可以按需在流水线模板中自定义步骤和阶段。有关如何使用图形编辑面板的更多信息，请参考[使用图形编辑面板创建流水线](../create-a-pipeline-using-graphical-editing-panel/)。
+
+ {{}}
+
+10. 在右侧的**代理**区域，选择代理类型，默认值为 **kubernetes**，点击**确定**。
+
+ | 代理类型 | 说明 |
+ | ----------- | ------------------------- |
+ | any | 调用默认的 base pod 模板创建 Jenkins agent 运行流水线。 |
+ | node | 调用指定类型的 pod 模板创建 Jenkins agent 运行流水线，可配置的 label 标签为 base、java、nodejs、maven、go 等。 |
+ | kubernetes | 通过 yaml 文件自定义标准的 kubernetes pod 模板运行 agent 执行流水线任务。 |
+
+11. 在弹出的页面，您可以查看已创建的流水线模板详情，点击**运行**即可运行该流水线。
+
+在之前的版本中，KubeSphere 还提供了 CI 以及 CI & CD 流水线模板，但是由于这两个模板难以满足定制化需求，因为建议您采用其它内置模板或直接自定义模板。下面分别介绍了这两个模板。
+
+- CI 流水线模板
+
+ 
+
+ 
+
+ CI 流水线模板包含两个阶段。**clone code** 阶段用于检出代码，**build & push** 阶段用于构建镜像并将镜像推送至 Docker Hub。您需要预先为代码仓库和 Docker Hub 仓库创建凭证，然后在相应的步骤中设置仓库的 URL 以及凭证。完成编辑后，流水线即可开始运行。
+
+- CI & CD 流水线模板
+
+ 
+
+ 
+
+ CI & CD 流水线模板包含六个阶段。有关每个阶段的更多信息，请参考[使用 Jenkinsfile 创建流水线](../create-a-pipeline-using-jenkinsfile/#流水线概述)，您可以在该文档中找到相似的阶段及描述。您需要预先为代码仓库、Docker Hub 仓库和集群的 kubeconfig 创建凭证，然后在相应的步骤中设置仓库的 URL 以及凭证。完成编辑后，流水线即可开始运行。
diff --git a/content/zh/docs/v3.4/faq/_index.md b/content/zh/docs/v3.4/faq/_index.md
new file mode 100644
index 000000000..af2e47209
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/_index.md
@@ -0,0 +1,12 @@
+---
+title: "常见问题"
+description: "FAQ is designed to answer and summarize the questions users ask most frequently about KubeSphere."
+layout: "second"
+
+linkTitle: "常见问题"
+weight: 16000
+
+icon: "/images/docs/v3.3/docs.svg"
+---
+
+本章节总结并回答了有关 KubeSphere 最常见的问题，问题根据 KubeSphere 的功能进行分类，您可以在对应部分找到有关的问题和答案。
diff --git a/content/zh/docs/v3.4/faq/access-control/_index.md b/content/zh/docs/v3.4/faq/access-control/_index.md
new file mode 100644
index 000000000..95af6334a
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/access-control/_index.md
@@ -0,0 +1,7 @@
+---
+title: "访问控制和帐户管理"
+keywords: 'Kubernetes, KubeSphere, 帐户, 访问控制'
+description: '关于访问控制和帐户管理的常见问题'
+layout: "second"
+weight: 16400
+---
diff --git a/content/zh/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md b/content/zh/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
new file mode 100644
index 000000000..d51d22ad7
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
@@ -0,0 +1,38 @@
+---
+title: "添加现有 Kubernetes 命名空间至 KubeSphere 企业空间"
+keywords: "命名空间, 项目, KubeSphere, Kubernetes"
+description: "将您现有 Kubernetes 集群中的命名空间添加至 KubeSphere 的企业空间。"
+linkTitle: "添加现有 Kubernetes 命名空间至 KubeSphere 企业空间"
+Weight: 16430
+---
+
+Kubernetes 命名空间即 KubeSphere 项目。如果您不是在 KubeSphere 控制台创建命名空间对象，则该命名空间不会直接在企业空间中显示。不过，集群管理员依然可以在**集群管理**页面查看该命名空间。同时，您也可以将该命名空间添加至企业空间。
+
+本教程演示如何添加现有 Kubernetes 命名空间至 KubeSphere 企业空间。
+
+## 准备工作
+
+- 您需要有一个具有**集群管理**权限的用户。例如，您可以直接以 `admin` 身份登录控制台，或者创建一个具有该权限的新角色并将其分配至一个用户。
+
+- 您需要有一个可用的企业空间，以便将命名空间分配至该企业空间。有关更多信息，请参见[创建企业空间、项目、用户和角色](../../../quick-start/create-workspace-and-project/)。
+
+## 创建 Kubernetes 命名空间
+
+首先，创建一个示例 Kubernetes 命名空间，以便稍后将其添加至企业空间。执行以下命令：
+
+```bash
+kubectl create ns demo-namespace
+```
+
+有关创建 Kubernetes 命名空间的更多信息，请参见[命名空间演练](https://kubernetes.io/zh/docs/tasks/administer-cluster/namespaces-walkthrough/)。
+
+## 添加命名空间至 KubeSphere 企业空间
+
+1. 以 `admin` 身份登录 KubeSphere 控制台，转到**集群管理**页面。点击**项目**，您可以查看在当前集群中运行的所有项目），包括前述刚刚创建的项目。
+
+2. 通过 kubectl 创建的命名空间不属于任何企业空间。请点击右侧的 
，选择**分配企业空间**。
+
+3. 在弹出的对话框中，为该项目选择一个**企业空间**和**项目管理员**，然后点击**确定**。
+
+4. 转到您的企业空间，可以在**项目**页面看到该项目已显示。
+
diff --git a/content/zh/docs/v3.4/faq/access-control/cannot-login.md b/content/zh/docs/v3.4/faq/access-control/cannot-login.md
new file mode 100644
index 000000000..266a96f96
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/access-control/cannot-login.md
@@ -0,0 +1,143 @@
+---
+title: "用户无法登录"
+keywords: "无法登录, 用户不活跃, KubeSphere, Kubernetes"
+description: "如何解决无法登录的问题"
+linkTitle: "用户无法登录"
+Weight: 16440
+---
+
+KubeSphere 安装时会自动创建默认用户 (`admin/P@88w0rd`)，密码错误或者用户状态不是**活跃**会导致无法登录。
+
+下面是用户无法登录时，一些常见的问题：
+
+## Account Not Active
+
+登录失败时，您可能看到以下提示。请根据以下步骤排查并解决问题：
+
+
+
+1. 执行以下命令检查用户状态：
+
+ ```bash
+ $ kubectl get users
+ NAME EMAIL STATUS
+ admin admin@kubesphere.io Active
+ ```
+
+2. 检查 `ks-controller-manager` 是否正常运行，是否有异常日志：
+
+ ```bash
+ kubectl -n kubesphere-system logs -l app=ks-controller-manager
+ ```
+
+以下是导致此问题的可能原因。
+
+### Kubernetes 1.19 中的 admission webhook 无法正常工作
+
+Kubernetes 1.19 使用了 Golang 1.15 进行编译，需要更新 admission webhook 用到的证书，该问题导致 `ks-controller` admission webhook 无法正常使用。
+
+相关错误日志：
+
+```bash
+Internal error occurred: failed calling webhook "validating-user.kubesphere.io": Post "https://ks-controller-manager.kubesphere-system.svc:443/validate-email-iam-kubesphere-io-v1alpha2-user?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
+```
+
+有关该问题和解决方式的更多信息，请参见[此 GitHub Issue](https://github.com/kubesphere/kubesphere/issues/2928)。
+
+### ks-controller-manager 无法正常工作
+
+`ks-controller-manager` 依赖 openldap、Jenkins 这两个有状态服务，当 openldap 或 Jenkins 无法正常运行时会导致 `ks-controller-manager` 一直处于 `reconcile` 状态。
+
+可以通过以下命令检查 openldap 和 Jeknins 服务是否正常:
+
+```
+kubectl -n kubesphere-devops-system get po | grep -v Running
+kubectl -n kubesphere-system get po | grep -v Running
+kubectl -n kubesphere-system logs -l app=openldap
+```
+
+相关错误日志：
+
+```bash
+failed to connect to ldap service, please check ldap status, error: factory is not able to fill the pool: LDAP Result Code 200 \"Network Error\": dial tcp: lookup openldap.kubesphere-system.svc on 169.254.25.10:53: no such host
+```
+
+```bash
+Internal error occurred: failed calling webhook “validating-user.kubesphere.io”: Post https://ks-controller-manager.kubesphere-system.svc:443/validate-email-iam-kubesphere-io-v1alpha2-user?timeout=4s: context deadline exceeded
+```
+
+**解决方式**
+
+您需要先恢复 openldap、Jenkins 这两个服务并保证网络的连通性，重启 `ks-controller-manager`。
+
+```
+kubectl -n kubesphere-system rollout restart deploy ks-controller-manager
+```
+
+### 使用了错误的代码分支
+
+如果您使用了错误的 ks-installer 版本，会导致安装之后各组件版本不匹配。
+
+通过以下方式检查各组件版本是否一致，正确的 image tag 应该是 v3.3.2。
+
+```
+kubectl -n kubesphere-system get deploy ks-installer -o jsonpath='{.spec.template.spec.containers[0].image}'
+kubectl -n kubesphere-system get deploy ks-apiserver -o jsonpath='{.spec.template.spec.containers[0].image}'
+kubectl -n kubesphere-system get deploy ks-controller-manager -o jsonpath='{.spec.template.spec.containers[0].image}'
+```
+
+## 用户名或密码错误
+
+
+
+通过以下命令检查用户密码是否正确：
+
+```
+curl -u 
保存设置。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/faq/console/console-web-browser.md b/content/zh/docs/v3.4/faq/console/console-web-browser.md
new file mode 100644
index 000000000..eba3d2c4e
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/console/console-web-browser.md
@@ -0,0 +1,11 @@
+---
+title: "支持的浏览器"
+keywords: "FAQ, 控制台, KubeSphere, Kubernetes"
+description: "使用支持的浏览器访问控制台。"
+linkTitle: "支持的浏览器"
+Weight: 16510
+---
+
+KubeSphere Web 控制台支持多种主流浏览器，包括 Chrome、Firefox、Safari 浏览器、Opera 和 Microsoft Edge。您需要使用以下表格内绿色框中的浏览器版本以访问 KubeSphere Web 控制台。
+
+
diff --git a/content/zh/docs/v3.4/faq/console/edit-resources-in-system-workspace.md b/content/zh/docs/v3.4/faq/console/edit-resources-in-system-workspace.md
new file mode 100644
index 000000000..f8d91826d
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/console/edit-resources-in-system-workspace.md
@@ -0,0 +1,49 @@
+---
+title: "在控制台上编辑系统资源"
+keywords: "系统, 资源, KubeSphere, Kubernetes"
+description: "在控制台上启用对系统资源的编辑功能。"
+linkTitle: '在控制台上编辑系统资源'
+Weight: 16520
+---
+
+当您安装 KubeSphere 时，企业空间 `system-workspace` 将被创建，用于运行所有 KubeSphere 系统项目和 Kubernetes 系统项目。为了避免对这两个系统的误操作，您不能直接在控制台上编辑该企业空间中的资源。但是，您仍然可以使用 `kubectl` 来修改资源。
+
+本教程演示如何启用 `system-workspace` 资源的编辑功能。
+
+{{< notice warning >}}
+
+编辑 `system-workspace` 中的资源可能会导致意外结果，例如 KubeSphere 系统和节点故障，并且可能对您的业务造成影响。执行此操作时请高度谨慎。
+
+{{}}
+
+## 编辑控制台配置
+
+1. 以 `admin` 用户登录 KubeSphere，点击右下角的 ，然后选择 **Kubectl**。
+
+2. 执行如下命令：
+
+ ```bash
+ kubectl -n kubesphere-system edit cm ks-console-config
+ ```
+
+3. 在 `client` 下添加 `systemWorkspace` 字段并保存文件。
+
+ ```yaml
+ client:
+ version:
+ kubesphere: v3.3.2
+ kubernetes: v1.22.12
+ openpitrix: v3.3.2
+ enableKubeConfig: true
+ systemWorkspace: "$" # 请手动添加此行。
+ ```
+
+4. 执行如下命令重新部署 `ks-console`，并等待容器组重建。
+
+ ```bash
+ kubectl -n kubesphere-system rollout restart deployment ks-console
+ ```
+
+5. 刷新 KubeSphere 控制台。`system-workspace` 中的项目将出现编辑按钮。
+
+6. 如需关闭控制台的编辑功能，请采用相同方法删除 `systemWorkspace` 字段。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/faq/devops/_index.md b/content/zh/docs/v3.4/faq/devops/_index.md
new file mode 100644
index 000000000..79fb04523
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/devops/_index.md
@@ -0,0 +1,7 @@
+---
+title: "DevOps"
+keywords: 'Kubernetes, KubeSphere, DevOps, Jenkins'
+description: 'FAQ about DevOps in KubeSphere'
+layout: "second"
+weight: 16800
+---
diff --git a/content/zh/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md b/content/zh/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md
new file mode 100644
index 000000000..758f35bc3
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/devops/create-devops-kubeconfig-on-aws.md
@@ -0,0 +1,106 @@
+---
+title: "在 AWS 上创建 DevOps Kubeconfig"
+keywords: "KubeSphere, Kubernetes, DevOps, Kubeconfig, AWS"
+description: "如何在 AWS 上创建 DevOps Kubeconfig"
+linkTitle: "在 AWS 上创建 DevOps Kubeconfig"
+Weight: 16820
+---
+
+在已安装 KubeSphere 的 AWS 集群上运行流水线时，如果无法将应用部署到项目中，可能是因 DevOps kubeconfig 出问题所导致。本教程介绍如何在 AWS 上创建 DevOps kubeconfig。
+
+## 准备工作
+
+- 您需要准备一个已安装 KubeSphere 的 AWS 集群。有关如何在 AWS 上安装 KubeSphere 的更多信息，请参考[在 AWS EKS 上部署 KubeSphere](../../../installing-on-kubernetes/hosted-kubernetes/install-kubesphere-on-eks/)。
+- 您需要启用 [KubeSphere DevOps 系统](../../../pluggable-components/devops/)。
+- 您需要准备一个可以部署应用的项目。本教程以 `kubesphere-sample-dev` 项目为例。
+
+## 创建 DevOps Kubeconfig
+
+### 步骤 1：创建 ServiceAccount
+
+1. 在您的 AWS 集群上创建 `devops-deploy.yaml` 文件并输入以下内容。
+
+ ```yaml
+ ---
+ apiVersion: v1
+ kind: ServiceAccount
+ metadata:
+ name: devops-deploy
+ namespace: kubesphere-sample-dev
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: Role
+ metadata:
+ name: devops-deploy-role
+ namespace: kubesphere-sample-dev
+ rules:
+ - apiGroups:
+ - "*"
+ resources:
+ - "*"
+ verbs:
+ - "*"
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: RoleBinding
+ metadata:
+ name: devops-deploy-rolebinding
+ namespace: kubesphere-sample-dev
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: Role
+ name: devops-deploy-role
+ subjects:
+ - kind: ServiceAccount
+ name: devops-deploy
+ namespace: kubesphere-sample-dev
+ ```
+
+2. 运行以下命令应用该 YAML 文件。
+
+ ```bash
+ kubectl apply -f devops-deploy.yaml
+ ```
+
+### 步骤 2：获取服务帐户令牌
+
+1. 运行以下命令获取服务帐户的令牌。
+
+ ```bash
+ export TOKEN_NAME=$(kubectl -n kubesphere-sample-dev get sa devops-deploy -o jsonpath='{.secrets[0].name}')
+ kubectl -n kubesphere-sample-dev get secret "${TOKEN_NAME}" -o jsonpath='{.data.token}' | base64 -d
+ ```
+
+2. 输出类似如下：
+
+ 
+
+### 步骤 3：创建 DevOps kubeconfig
+
+1. 登录 AWS 集群的 KubeSphere 控制台，访问您的 DevOps 项目。转到 **DevOps 项目设置**下的**凭证**，然后点击**创建**。您可以按需输入该 kubeconfig 的**凭证 ID**。
+
+2. 在 **Content** 文本框中，请注意以下内容：
+
+ ```
+ user:
+ client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FUR...
+ client-key-data: LS0tLS1CRUdJTiBQUk...
+ ```
+
+ 您需要将其替换为在步骤 2 中获取的令牌，然后点击**确定**创建 kubeconfig。
+
+ ```bash
+ user:
+ token:eyJhbGciOiJSUzI1NiIsImtpZCI6Ikl3UkhCay13dHpPY2Z6LW9VTlZKQVR6dVdmb2FHallJQ2E4VzJULUNjUzAifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlc3BoZXJlLXNhbXBsZS1kZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiZGV2b3BzLWRlcGxveS10b2tlbi1kcGY2ZiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJkZXZvcHMtZGVwbG95Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiMjM0ZTI4OTUtMjM3YS00M2Y5LTkwMTgtZDg4YjY2YTQyNzVmIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmVzcGhlcmUtc2FtcGxlLWRldjpkZXZvcHMtZGVwbG95In0.Ls6mkpgAU75zVw87FkcWx-MLEXGcJjlnb4rUVtT61Jmc_G6jkn4X45MK1V_HuLje3JZMFjL80QUl5ljHLiCUPQ7oE5AUZaUCdqZVdDYEhqeFuGQb_7Qlh8-UFVGGg8vrb0HeGiOlS0qq5hzwKc9C1OmsXHS92yhNwz9gIOujZRafnGKIsG6TL2hEVY2xI0vvmseDKmKg5o0TbeaTMVePHvECju9Qz3Z7TUYsr7HAOvCPtGutlPWLqGx5uOHenOdeLn71x5RoS98xguZoxYVollciPKCQwBlZ4zWK2hzsLSNNLb9cZpxtgUVyHE0AB0e86IHRngnnNrzpp1_pDxL5jw/
+ ```
+
+ {{< notice note >}}
+
+ 请确保使用您自己的令牌。
+
+ {{}}
+
+
+
+
+
diff --git a/content/zh/docs/v3.4/faq/devops/install-jenkins-plugins.md b/content/zh/docs/v3.4/faq/devops/install-jenkins-plugins.md
new file mode 100644
index 000000000..9849ce7f4
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/devops/install-jenkins-plugins.md
@@ -0,0 +1,67 @@
+---
+title: "为 KubeSphere 中的 Jenkins 安装插件"
+keywords: "KubeSphere, Kubernetes, DevOps, Jenkins, 插件"
+description: "了解如何为 KubeSphere 中的 Jenkins 安装插件。"
+linkTitle: "为 KubeSphere 中的 Jenkins 安装插件"
+Weight: 16810
+---
+
+KubeSphere DevOps 系统提供基于 Jenkins 的容器化 CI/CD 功能，而提升 Jenkins 功能的主要方法就是安装插件。本教程介绍如何在 Jenkins 面板上安装插件。
+
+{{< notice warning >}}
+
+并非所有的 Jenkins 插件都拥有良好的维护支持。一些插件可能会导致 Jenkins 出现问题，甚至导致 KubeSphere 出现严重问题。强烈建议您在安装任意插件之前进行备份，若条件允许，先在其他环境进行测试。
+
+{{}}
+
+## 准备工作
+
+您需要启用 [KubeSphere DevOps 系统](../../../pluggable-components/devops/)。
+
+## 安装插件
+
+### 步骤 1：获取 Jenkins 地址
+
+1. 运行以下命令获取 Jenkins 的地址。
+
+ ```bash
+ export NODE_PORT=$(kubectl get --namespace kubesphere-devops-system -o jsonpath="{.spec.ports[0].nodePort}" services devops-jenkins)
+ export NODE_IP=$(kubectl get nodes --namespace kubesphere-devops-system -o jsonpath="{.items[0].status.addresses[0].address}")
+ echo http://$NODE_IP:$NODE_PORT
+ ```
+
+2. 您会得到类似如下的输出。您可以通过输出的地址使用自己的 KubeSphere 用户和密码（例如 `admin/P@88w0rd`）访问 Jenkins 面板。
+
+ ```
+ http://192.168.0.4:30180
+ ```
+
+ {{< notice note >}}
+
+ 请确保使用自己的 Jenkins 地址。根据您 KubeSphere 集群部署位置的不同，您可能需要在安全组中打开端口，并配置相关的端口转发规则。
+
+ {{}}
+
+### 步骤 2：在 Jenkins 面板上安装插件
+
+1. 登录 Jenkins 面板，点击**系统管理**。
+
+2. 在**系统管理**页面，下滑到**插件管理**并点击。
+
+3. 点击**可选插件**选项卡，您必须使用搜索框来搜索所需插件。例如，您可以在搜索框中输入 `git`，勾选所需插件旁边的复选框，然后按需点击**直接安装**或**下载待重启后安装**。
+
+ {{< notice note >}}
+
+ Jenkins 的插件相互依赖。安装插件时，您可能还需要安装其依赖项。
+
+ {{}}
+
+4. 如果已预先下载 HPI 文件，您也可以点击**高级**选项卡，上传该 HPI 文件作为插件进行安装。
+
+5. 在**已安装**选项卡，可以查看已安装的全部插件。能够安全卸载的插件将会在右侧显示**卸载**按钮。
+
+6. 在**可更新**选项卡，先勾选插件左侧的复选框，再点击**下载待重启后安装**，即可安装更新的插件。您也可以点击**立即获取**按钮检查更新。
+
+## 另请参见
+
+[管理插件](https://www.jenkins.io/zh/doc/book/managing/plugins/)
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/faq/installation/_index.md b/content/zh/docs/v3.4/faq/installation/_index.md
new file mode 100644
index 000000000..bc0445e60
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/installation/_index.md
@@ -0,0 +1,7 @@
+---
+title: "安装"
+keywords: 'Kubernetes, KubeSphere, 安装, 常见问题'
+description: '关于安装的常见问题'
+layout: "second"
+weight: 16100
+---
diff --git a/content/zh/docs/v3.4/faq/installation/configure-booster.md b/content/zh/docs/v3.4/faq/installation/configure-booster.md
new file mode 100644
index 000000000..8a7cc6c3d
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/installation/configure-booster.md
@@ -0,0 +1,84 @@
+---
+title: "为安装配置加速器"
+keywords: 'KubeSphere, 加速器, 安装, FAQ'
+description: '设置仓库镜像地址加速安装时的镜像下载速度。'
+linkTitle: "为安装配置加速器"
+weight: 16200
+---
+
+如果您无法从 `dockerhub.io` 下载镜像，强烈建议您预先配置仓库的镜像地址（即加速器）以加快下载速度。您可以参考[ Docker 官方文档](https://docs.docker.com/registry/recipes/mirror/#configure-the-docker-daemon)，或执行以下步骤。
+
+## 获取加速器地址
+
+您需要获取仓库的一个镜像地址以配置加速器。您可以参考如何[从阿里云获取加速器地址](https://help.aliyun.com/document_detail/60750.html)。
+
+## 配置仓库镜像地址
+
+您可以直接配置 Docker 守护程序，也可以使用 KubeKey 进行配置。
+
+### 配置 Docker 守护程序
+
+{{< notice note >}}
+
+采用此方法，您需要预先安装 Docker。
+
+{{}}
+
+1. 执行如下命令：
+
+ ```bash
+ sudo mkdir -p /etc/docker
+ ```
+
+ ```bash
+ sudo vi /etc/docker/daemon.json
+ ```
+
+2. 在文件中添加 `registry-mirrors` 键值对。
+
+ ```json
+ {
+ "registry-mirrors": ["https://
，并选择**编辑 YAML**。
+
+5. 在文件末尾添加 `telemetry_enabled: false` 字段，点击**确定**。
+
+
+{{< notice note >}}
+
+如需重新启用 Telemetry，请删除 `telemetry_enabled: false` 字段或将其更改为 `telemetry_enabled: true`，并更新 `ks-installer`。
+
+{{}}
diff --git a/content/zh/docs/v3.4/faq/multi-cluster-management/_index.md b/content/zh/docs/v3.4/faq/multi-cluster-management/_index.md
new file mode 100644
index 000000000..57f23b873
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/multi-cluster-management/_index.md
@@ -0,0 +1,7 @@
+---
+title: "多集群管理"
+keywords: 'Kubernetes, KubeSphere, 多集群管理, 主集群, 成员集群'
+description: 'KubeSphere 多集群管理常见问题'
+layout: "second"
+weight: 16700
+---
diff --git a/content/zh/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md b/content/zh/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md
new file mode 100644
index 000000000..8f66b661b
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/multi-cluster-management/host-cluster-access-member-cluster.md
@@ -0,0 +1,71 @@
+---
+title: "恢复主集群对成员集群的访问权限"
+keywords: "Kubernetes, KubeSphere, 多集群, 主集群, 成员集群"
+description: "了解如何恢复主集群对成员集群的访问。"
+linkTitle: "恢复主集群对成员集群的访问权限"
+Weight: 16720
+---
+
+[多集群管理](../../../multicluster-management/introduction/kubefed-in-kubesphere/)是 KubeSphere 的一大特色，拥有必要权限的租户（通常是集群管理员）能够从主集群访问中央控制平面，以管理全部成员集群。强烈建议您通过主集群管理整个集群的资源。
+
+本教程演示如何恢复主集群对成员集群的访问权限。
+
+## 可能出现的错误信息
+
+如果您无法从中央控制平面访问成员集群，并且浏览器一直将您重新定向到 KubeSphere 的登录页面，请在该成员集群上运行以下命令来获取 ks-apiserver 的日志。
+
+```
+kubectl -n kubesphere-system logs ks-apiserver-7c9c9456bd-qv6bs
+```
+
+{{< notice note >}}
+
+`ks-apiserver-7c9c9456bd-qv6bs` 指的是该成员集群上的容器组 ID。请确保您使用自己的容器组 ID。
+
+{{}}
+
+您可能会看到以下错误信息：
+
+```
+E0305 03:46:42.105625 1 token.go:65] token not found in cache
+E0305 03:46:42.105725 1 jwt_token.go:45] token not found in cache
+E0305 03:46:42.105759 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+E0305 03:46:52.045964 1 token.go:65] token not found in cache
+E0305 03:46:52.045992 1 jwt_token.go:45] token not found in cache
+E0305 03:46:52.046004 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+E0305 03:47:34.502726 1 token.go:65] token not found in cache
+E0305 03:47:34.502751 1 jwt_token.go:45] token not found in cache
+E0305 03:47:34.502764 1 authentication.go:60] Unable to authenticate the request due to error: token not found in cache
+```
+
+## 解决方案
+
+### 步骤 1：验证 jwtSecret
+
+分别在主集群和成员集群上运行以下命令，确认它们的 jwtSecret 是否相同。
+
+```
+kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v “apiVersion” | grep jwtSecret
+```
+
+### 步骤 2：更改 `accessTokenMaxAge`
+
+请确保主集群和成员集群的 jwtSecret 相同，然后在该成员集群上运行以下命令获取 `accessTokenMaxAge` 的值。
+
+```
+kubectl -n kubesphere-system get cm kubesphere-config -o yaml | grep -v "apiVersion" | grep accessTokenMaxAge
+```
+
+如果该值不为 `0`，请运行以下命令更改 `accessTokenMaxAge` 的值。
+
+```
+kubectl -n kubesphere-system edit cm kubesphere-config -o yaml
+```
+
+将 `accessTokenMaxAge` 的值更改为 `0` 之后，运行以下命令重启 ks-apiserver。
+
+```
+kubectl -n kubesphere-system rollout restart deploy ks-apiserver
+```
+
+现在，您可以再次从中央控制平面访问该成员集群。
\ No newline at end of file
diff --git a/content/zh/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md b/content/zh/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md
new file mode 100644
index 000000000..d50fc8330
--- /dev/null
+++ b/content/zh/docs/v3.4/faq/multi-cluster-management/manage-multi-cluster.md
@@ -0,0 +1,60 @@
+---
+title: "在 KubeSphere 上管理多集群环境"
+keywords: 'Kubernetes，KubeSphere，联邦，多集群，混合云'
+description: '理解如何在 KubeSphere 上管理多集群环境。'
+linkTitle: "在 KubeSphere 上管理多集群环境"
+weight: 16710
+
+---
+
+KubeSphere 提供了易于使用的多集群功能，帮助您[在 KubeSphere 上构建多集群环境](../../../multicluster-management/)。本指南说明如何在 KubeSphere 上管理多集群环境。
+
+## 准备工作
+
+- 请确保您的 Kubernetes 集群在用作主集群和成员集群之前已安装 KubeSphere。
+- 请确保主集群和成员集群分别设置了正确的集群角色，并且在主集群和成员集群上的 `jwtSecret` 也相同。
+- 建议成员集群在导入主集群之前是干净环境，即没有创建任何资源。
+
+
+## 管理 KubeSphere 多集群环境
+
+当您在 KubeSphere 上创建多集群环境之后，您可以通过主集群的中央控制平面管理该环境。在创建资源的时候，您可以选择一个特定的集群，但是需要避免您的主集群过载。不建议您登录成员集群的 KubeSphere Web 控制台去创建资源，因为部分资源（例如：企业空间）将不会同步到您的主集群进行管理。
+
+### 资源管理
+
+不建议您将主集群转换为成员集群，或将成员集群转换成主集群。如果一个成员集群曾经被导入进主集群，您将该成员集群从先前的主集群解绑后，再导入进新的主集群时必须使用相同的集群名称。
+
+如果您想在将成员集群导入新的主集群时保留现有项目，请按照以下步骤进行操作。
+
+1. 在成员集群上运行以下命令将需要保留的项目从企业空间解绑。
+
+ ```bash
+ kubectl label ns