"
- URL = "docs/"
+ name = "v3.2.x | OS | +Minimum Requirements | +
|---|---|
| Ubuntu 16.04, 18.04 | +2 CPU cores, 2 GB memory, and 40 GB disk space | +
| Debian Buster, Stretch | +2 CPU cores, 2 GB memory, and 40 GB disk space | +
| CentOS 7.x | +2 CPU cores, 2 GB memory, and 40 GB disk space | +
| Red Hat Enterprise Linux 7 | +2 CPU cores, 2 GB memory, and 40 GB disk space | +
| SUSE Linux Enterprise Server 15/openSUSE Leap 15.2 | +2 CPU cores, 2 GB memory, and 40 GB disk space | +
| 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 | +
version |
- The Kubernetes version to be installed. If you do not specify a Kubernetes version, {{< contentLink "docs/installing-on-linux/introduction/kubekey" "KubeKey" >}} v1.1.0 will install Kubernetes v1.19.8 by default. For more information, see {{< contentLink "docs/installing-on-linux/introduction/kubekey/#support-matrix" "Support Matrix" >}}. | +The Kubernetes version to be installed. If you do not specify a Kubernetes version, {{< contentLink "docs/installing-on-linux/introduction/kubekey" "KubeKey" >}} v1.2.1 will install Kubernetes v1.21.5 by default. For more information, see {{< contentLink "docs/installing-on-linux/introduction/kubekey/#support-matrix" "Support Matrix" >}}. |
imageRepo |
@@ -116,10 +116,11 @@ The below table describes the above parameters in detail.
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`.
+
+ ```yaml
+ spec:
+ authentication:
+ jwtSecret: ''
+ oauthOptions:
+ identityProviders:
+ - mappingMethod: auto
+ name: Okta
+ provider:
+ clientID: **** # Get from Otka
+ clientSecret: **** # Get from Otka
+ issuer: https://kubesphere.Okta.com # Your Okta domain
+ redirectURL: https://console.kubesphere.io/oauth/redirect/Okta
+ scopes:
+ - openid
+ - email
+ - profile
+ type: OIDCIdentityProvider
+ ```
+
+3. After the fields are configured, save your changes, and wait until the restart of ks-installer is complete. Okta login button is shown on the **Login** page of KubeSphere and you are redirected to Okta login page when clicking it. You will be required to register a valid username when log in to KubeSphere for the first time.
+
+ 
+
+4. After you successfully log in to KubeSphere, you can assign roles for the users.
+
+## Recap
+
+KubeSphere provides various ways to integrate with your existing identity providers. I believe OIDC is one of the easiest methods, which also enjoys support from many identity providers. Hope you can get a better understanding of how to integrate KubeSphere with Okta by following the steps in this article.
+
+Last but not the least, enjoy exploring KubeSphere!
diff --git a/content/en/blogs/kubernetes-fundamentals-part-1.md b/content/en/blogs/kubernetes-fundamentals-part-1.md
new file mode 100644
index 000000000..0d90c2e3b
--- /dev/null
+++ b/content/en/blogs/kubernetes-fundamentals-part-1.md
@@ -0,0 +1,100 @@
+---
+ title: 'Kubernetes Fundamental 1: Pods, Nodes, Deployments and Ingress'
+ tag: 'Kubernetes, fundamentals, beginners, guide'
+ keywords: 'Kubernetes, fundamentals, beginners, guide'
+ description: 'Kubernetes was born out of the necessity to make our sophisticated software more available, scalable, transportable, and deployable in small, independent modules.'
+ createTime: '2021-10-14'
+ author: 'Pulkit Singh'
+ snapshot: '/images/blogs/en/kubernetes-fundamentals-part-1/main-poster.png'
+---
+
+
+
+
+
+Hi! Today we'll discuss something that everyone is familiar with if they've heard the term "Containers." Yes, It's "Kubernetes"!!
+
+“Kubernetes was born out of the necessity to make our sophisticated software more available, scalable, transportable, and deployable in small, independent modules.”
+
+Kubernetes is gaining popularity as the future cloud software deployment and management standard. However, Kubernetes has a steep learning curve that comes with all of its capabilities. As a rookie, it can be tough to comprehend the concepts and core principles. There are a lot of pieces that make up the system, and determining which ones are vital for your scenario might be tough.
+
+So, what’s the need for it??
+
+
+## Do we need Kubernetes?
+
+
+
+Kubernetes is a platform for container-based application orchestration control resource allocation, and traffic management for applications and microservices in the Kubernetes ecosystem.
+
+As a result, many aspects of maintaining a service-oriented application infrastructure have been made easier. Kubernetes, when combined with modern continuous integration and continuous deployment (CI/CD) systems, provides the foundation for scaling these apps with minimal technical work.
+
+So now it's time to talk about Kubernetes' fundamental notions!
+
+Some concepts to understand:
+
+## Containers
+
+
+Containers solve a significant issue in application development. Programmers work in a development environment when they write code. When they're ready to put the code into production, this is where problems arise. The code that worked on their machine does not work in production. Differences in operating systems, dependencies, and libraries are only a few of the reasons for this.
+Containers solved this fundamental problem of portability by separating code from the infrastructure it operates on. Developers may choose to package their application into a small container image that contains all of the binaries and libraries it needs to run.
+Any computer with a containerization platform such as Docker or containerd can run that container in production.
+
+## Pods
+
+
+A Pod (as in a pod of whales or a pod of peas) is a group of one or more containers that share storage and network resources and operate according to a set of rules. A Pod's content is always co-located, scheduled, and executed in the same environment. A Pod is a "logical host" for an application that incorporates one or more tightly coupled application containers.
+In a non-cloud context, applications running on the same physical or virtual computer are analogous to cloud applications running on the same logical host.
+
+## Nodes
+
+
+A node is the smallest unit of computer hardware in Kubernetes. It's a representation of one of the computers in your cluster. Most production systems will have a node that is either a physical machine in a data center or a virtual machine housed on a cloud provider like Google Cloud Platform. Don't let traditions limit you; in theory, you can make a node out of almost anything.
+Thinking of a machine as a "node" adds another degree of abstraction. Instead of worrying about each machine's characteristics, we can now just see it as a collection of CPU and RAM resources that can be utilized. Any machine in a Kubernetes cluster can be used to replace any other machine in this approach
+In this, we have two terms known as:
+
+
+
+- Nodes ( Master )
+The master node controls the state of the cluster; for example, which applications are running and their corresponding container images.
+
+- Nodes ( Worker )
+Workloads execute in a container on physical or virtual servers.
+
+## Cluster
+
+
+A cluster is a collection of machines on which containerized applications are run. Containerizing apps encapsulates an app's dependencies as well as some essential services. They are lighter and more adaptable than virtual machines. In this approach, clusters make it easier to design, move, and maintain applications.
+Containers may run on numerous computers and environments, including virtual, physical, cloud-based, and on-premises, thanks to clusters. Unlike virtual machines, containers are not limited to a single operating system. Instead, they can share operating systems and execute from any location.
+clusters are comprised of one master node and several worker nodes.
+
+## Persistent Volumes
+
+
+Data can't be stored to any arbitrary location in the file system since programs operating on your cluster aren't guaranteed to run on a certain node. If a program attempts to store data to a file for later use but is then moved to a different node, the file will no longer be where the program expects it to be. As a result, each node's typical local storage is viewed as a temporary cache for holding programs, but any data saved locally cannot be expected to last.
+Persistent Volumes are used by Kubernetes to store data indefinitely. While the cluster successfully pools and manages the CPU and RAM resources of all nodes, persistent file storage is not. As a Persistent Volume, local or cloud disks can be linked to the cluster. This is similar to connecting an external hard disk to the cluster. Persistent Volumes are a file system that can be mounted on the cluster without being tied to a specific node. A user's request for storage is called a PersistentVolumeClaim (PVC). It looks like a Pod. Node resources are consumed by pods, and PV resources are consumed by PVCs. Pods can request specified resource levels (CPU and Memory). The specific size and access modes might be requested in claims.
+
+## Deployments
+
+
+The basic function of a deployment is to specify how many clones of a pod should be running at any given time. When you add deployment to the cluster, it will automatically start up the necessary number of Pods and monitor them. If a pod dies, the deployment will recreate it automatically.
+You don't have to deal with pods manually if you use a deployment. Simply describe the system's desired state, and it will be managed for you automatically.
+
+## Ingress
+
+
+Ingress offers HTTP and HTTPS routes to services within the cluster from outside the cluster. Rules established on the Ingress resource control traffic routing. An Ingress can be set up to provide Services with externally accessible URLs, load balance traffic, terminate SSL/TLS, and provide name-based virtual hosting. An Ingress controller is in charge of completing the Ingress, usually with a load balancer, but it may also configure your edge router or additional front ends to assist in traffic handling. An Ingress does not disclose any ports or protocols to the public. A service of type Service is often used to expose services other than HTTP and HTTPS to the internet.
+
+## Interactive hands-on tutorials
+So we have talked a lot about basic concepts, so now if you want to learn Kubernetes from scratch do take a look at these interactive tutorials, you can run Kubernetes and practice it in your browser.
+
+- [Learn Kubernetes using Interactive Browser-Based Scenarios](https://www.katacoda.com/courses/kubernetes)
+
+- [Install KubeSphere on Kubernetes cluster](https://www.katacoda.com/kubesphere/scenarios/install-kubesphere-on-kubernetes)
+
+
+
+## Conclusion
+So at last, we have discussed all the basic concepts you need to get started to work with Kubernetes. If you want to start experimenting with it, then do take a look at [Kubernetes getting started docs.](https://kubernetes.io/docs/setup/)
+
+so get started with it and stay tuned for more such content!
diff --git a/content/en/blogs/kubesphere-3.2.0-ga-announcement.md b/content/en/blogs/kubesphere-3.2.0-ga-announcement.md
new file mode 100644
index 000000000..c6b73e5e1
--- /dev/null
+++ b/content/en/blogs/kubesphere-3.2.0-ga-announcement.md
@@ -0,0 +1,145 @@
+---
+title: 'KubeSphere 3.2.0 GA: Bringing AI-oriented GPU Scheduling and Flexible Gateway'
+tag: 'KubeSphere, release'
+keyword: 'Kubernetes, KubeSphere, release, AI, GPU'
+description: 'KubeSphere 3.2.0 supports GPU resource scheduling and management and GPU usage monitoring, which further improves user experience in cloud-native AI scenarios. Moreover, enhanced features such as multi-cluster management, multi-tenant management, observability, DevOps, app store, and service mesh further perfect the interactive design for better user experience.'
+createTime: '2021-11-03'
+author: 'KubeSphere'
+snapshot: '/images/blogs/en/release-announcement3.2.0/v3.2.0-GA-cover.png'
+---
+
+
+
+No one would ever doubt that **Cloud Native** has become the most popular service technology. KubeSphere, a distributed operating system for cloud-native application management with Kubernetes as its kernel, is definitely one of the tide riders surfing the cloud-native currents. KubeSphere has always been upholding the commitment of 100% open source. Owing to support from the open-source community, KubeSphere has rapidly established a worldwide presence.
+
+On November 2, 2021, we are excited to announce KubeSphere 3.2.0 is generally available!
+
+In KubeSphere 3.2.0, **GPU resource scheduling and management** and GPU usage monitoring further improve user experience in cloud-native AI scenarios. Moreover, enhanced features such as **multi-cluster management**, **multi-tenant management** , **observability**, **DevOps**, **app store, and service mesh** further perfect the interactive design for better user experience.
+
+It's also worth pointing out that KubeSphere 3.2.0 would not be possible without participation and contribution from enterprises and users outside QingCloud. You are everywhere, from feature development, test, defect report, proposal, best practice collection, bug fixing, internationalization to documentation. We appreciate your help and will give an acknowledgement at the end of the article.
+
+## **What's New in KubeSphere 3.2.0**
+
+### **GPU scheduling and quota management**
+
+With the rapid development of artificial intelligence (AI) and machine learning, more and more AI companies are calling for GPU resource scheduling and management features for server clusters, especially monitoring of GPU usage and management of GPU resource quotas. To address users' pain points, KubeSphere 3.2.0 makes our original GPU management even easier.
+
+KubeSphere 3.2.0 allows you to create GPU workloads on the GUI, schedule GPU resources, and manage GPU resource quotas by tenant. Specifically, it can be used for NVIDIA GPU and vGPU solutions.
+
+
+
+### **Enhanced Kubernetes observability**
+
+Growing container and microservice technologies make it more complex to call components between systems, and the number of processes running in the system is also surging. With thousands of processes running in a distributed system, it is clear that conventional monitoring techniques are incapable of tracking the dependencies and calling paths between these processes, and this is where observability within the system becomes particularly important.
+
+***Observability is the ability to measure the internal states of a system by examining its outputs.*** A system is considered "observable" if the current state can be estimated by only using information from outputs, namely telemetry data collected by the three pillars of observability: logging, tracing and metrics.
+
+1. More powerful custom monitoring dashboards
+
+KubeSphere 3.1.0 has added the cluster-level custom monitoring feature, which allows you to generate custom Kubernetes monitoring dashboards by selecting a default template, uploading a template, or customizing a template. KubeSphere 3.2.0 provides a default template for creating a Grafana monitoring dashboard. You can import a Grafana monitoring dashboard by specifying the URL or uploading the JSON file of the dashboard, and then KubeSphere will automatically convert the Grafana monitoring dashboard into a custom monitoring dashboard.
+
+
+
+For GPU resources, KubeSphere 3.2.0 also provides a default monitoring template with a wealth of metrics, so that you don't need to customize a template or edit a YAML file.
+
+
+
+2. Alerting and logging
+
+- KubeSphere 3.2.0 supports communication with Elasticsearch through HTTPS.
+
+- In addition to the various notification channels such as email, DingTalk, WeCom, webhook, and Slack, KubeSphere 3.2.0 now also allows you to test and validate the notification channels you configure.
+
+
+
+3. On the etcd monitoring page, the system automatically adds the `Leader` tag to the etcd leader.
+
+### **Multi-cloud and multi-cluster management**
+
+CNCF Survey 2020 shows that over 80% of users run more than two Kubernetes clusters in their production environment. KubeSphere aims at addressing multi-cluster and multi-cloud challenges. It provides a unified control plane and supports distributing applications and replicas to multiple Kubernetes clusters deployed across public cloud and on-premises environments. Moreover, KubeSphere supports observability across clusters, including features such as multi-dimensional monitoring, logging, events, and auditing logs.
+
+
+
+KubeSphere 3.2.0 performs better in cross-cluster scheduling. When you are creating a federated Deployment across clusters, you can directly specify the number of replicas scheduled to each cluster. In addition, you can also specify the total number of replicas and weight of each cluster, and allow the system to automatically schedule replicas to each cluster according its weight. This feature is pretty helpful when you want to flexibly scale your Deployment and proportionally distribute replicas to multiple clusters.
+
+
+
+
+
+### **Operations-and-maintenance-friendly storage management**
+
+Enterprises running Kubernetes in production focus on persistent storage, as stable and reliable storage underpin their core data. On the KubeSphere 3.2.0 web console, the **Volumes** feature allows the administrator to decide whether to enable volume cloning, snapshot capturing, and volume expansion, making persistent storage operations and maintenance for stateful apps more convenient.
+
+
+
+The default immediate binding mode binds a volume to a backend storage device immediately when the volume is created. This mode does not apply to storage devices with topology limits and may cause Pod scheduling failures. KubeSphere 3.2.0 provides the delayed binding mode to address this issue, which guarantees that a volume (PVC) is bound to a volume instance (PV) only after the volume is mounted to a Pod. This feature ensures that resources are properly scheduled based on Pod resource requests.
+
+
+
+In addition to volume management, KubeSphere 3.2.0 now also supports Persistent Volume management, and you can view Persistent Volume information, edit Persistent Volumes, and delete Persistent Volumes on the web console.
+
+
+
+When you create a volume snapshot, you can specify the snapshot type (`VolumeSnapshotClass`) to use a specific storage backend.
+
+### **Cluster gateway**
+
+KubeSphere 3.1 supports only project gateways, which require multiple IP addresses when there are multiple projects. Additionally, gateways in different workspaces are independent.
+
+KubeSphere 3.2.0 provides a cluster gateway, which means that all projects can share the same gateway. Existing project gateways are not affected by the cluster gateway.
+
+
+
+The administrator can directly manage and configure all project gateways on the cluster gateway settings page without having to go to each workspace. The Kubernetes ecosystem provides many ingress controllers that can be used as the gateway solution. In KubeSphere 3.2.0, the gateway backend is refactored, which allows you to use any ingress controllers that support v1\\ingress as the gateway solution.
+
+
+
+### **Authentication and authorization**
+
+A unified and all-round identity management and authentication system is indispensable for logical isolation in a multi-tenant system. Apart from support for AD/LDAP and OAuth 2.0 identity authentication systems, KubeSphere 3.2.0 also provides a built-in authentication service based on OpenID Connect to provide authentication capability for other components. OpenID Connect is a simple user identity authentication protocol based on OAuth 2.0 with a bunch of features and security options to meet enterprise-grade business requirements.
+
+### **App Store open to community partners**
+
+The App Store and application lifecycle management are unique features of KubeSphere, which are based on self-developed and open-source [OpenPitrix](https://github.com/openpitrix/openpitrix).
+
+KubeSphere 3.2.0 adds the feature of **dynamically loading community-developed Helm charts into the KubeSphere App Store.** You can send a pull request containing the Helm chart of a new app to the App Store chart repository. After the pull request is merged, the app is automatically loaded to the App Store regardless of the KubeSphere version. Welcome to submit your Helm charts to https://github.com/kubesphere/helm-charts. Nocalhost and Chaos Mesh have integrated their Helms charts into KubeSphere 3.2.0 by using this method, and you can easily install them to your Kubernetes clusters by one click.
+
+
+
+### **More independent Kubernetes DevOps (on KubeSphere)**
+
+Kubernetes DevOps (on KubeSphere) has developed into an independent project [ks-devops](https://github.com/kubesphere/ks-devops) in KubeSphere v3.2.0, which is intended to allow users to run Kubernetes DevOps (on KubeSphere) in any Kubernetes clusters. Currently, you can use a Helm chart to install the backend components of ks-devops.
+
+Jenkins is a CI engine with a large user base and a rich plug-in ecosystem. In KubeSphere 3.2.0, we will let Jenkins do what it is good at—functioning only as an engine in the backend to provide stable pipeline management capability. A newly added CRD PipelineRun encapsulates run records of pipelines, which reduces the number of APIs required for directly interacting with Jenkins and boosts performance of CI pipelines.
+
+Starting from KubeSphere v3.2.0, Kubernetes DevOps (on KubeSphere) allows you to build images by using pipelines based on containerd. As an independent project, Kubernetes DevOps (on KubeSphere) will support independent deployment of the backend and frontend, introduce GitOps tools such as Tekton and ArgoCD, as well as integrate project management and test management platforms.
+
+### **Flexible Kubernetes cluster deployment**
+
+If you do not have a Kubernetes cluster, you can use KubeKey to install both Kubernetes and KubeSphere; if you already have a Kubernetes cluster, you can use ks-installer to install KubeSphere only.
+
+[KubeKey](https://github.com/kubesphere/kubekey) is an efficient open-source installer, which uses Docker as the default container runtime. It can also use CRI runtimes such as containerd, CRI-O, and iSula. You can use KubeKey to deploy an etcd cluster independent of Kubernetes for better flexibility.
+
+KubeKey provides the following new features:
+
+- Supports the latest Kubernetes version 1.22.1 (backward compatible with 4 earlier versions); supports deployment of K3s (experimental).
+
+- Supports automatic renewal of Kubernetes cluster certificates.
+
+- Supports a high availability deployment mode that uses an internal load balancer to reduce the complexity of cluster deployment.
+
+- Most of the integrated components such as Istio, Jaeger, Prometheus Operator, Fluent Bit, KubeEdge, and Nginx ingress controller have been updated to the latest. For more information, refer to [Release Notes 3.2.0](https://kubesphere.io/docs/release/release-v320/).
+
+### **Better user experience**
+
+To provide a user-friendly web console for global users, our SIG Docs members have refactored and optimized the UI text on the web console to deliver more professional and accurate UI text and terms. Hard-coded and concatenated UI strings are removed for better UI localization and internationalization support.
+
+Some heavy users in the KubeSphere community have participated in enhancing some frontend features. For example, KubeSphere now supports searching for images in a Harbor registry and mounting volumes to init containers, and the feature of automatic workload restart during volume expansion is removed.
+
+For more information about user experience optimization, enhanced features, and fixed bugs, please refer to [Release Notes 3.2.0](https://kubesphere.io/docs/release/release-v320/). You can download and install KubeSphere 3.2.0 by referring to [All-in-One on Linux](https://kubesphere.io/docs/quick-start/all-in-one-on-linux/ ) and [Minimal KubeSphere on Kubernetes](https://kubesphere.io/docs/quick-start/minimal-kubesphere-on-k8s/), and we will offer an offline installation solution in the KubeSphere community in one week.
+
+## **Acknowledgements**
+
+The KubeSphere team would like to acknowledge contributions from the people who make KubeSphere 3.2.0 possible. The following GitHub IDs are not listed in order. If you are not listed, please contact us.
+
+
diff --git a/content/en/blogs/openelb-joins-cncf-sandbox-project.md b/content/en/blogs/openelb-joins-cncf-sandbox-project.md
new file mode 100644
index 000000000..331181160
--- /dev/null
+++ b/content/en/blogs/openelb-joins-cncf-sandbox-project.md
@@ -0,0 +1,85 @@
+---
+title: 'OpenELB Joins the CNCF Sandbox, Making Service Exposure in Private Environments Easier'
+tag: 'CNCF'
+keyword: 'OpenELB, Kubernetes, LoadBalancer, Bare metal server'
+description: 'CNCF accepted OpenELB, a load balancer plugin open sourced by KubeSphere, into the CNCF Sandbox'
+createTime: '2021-11-24'
+author: 'KubeSphere'
+snapshot: 'https://kubesphere-community.pek3b.qingstor.com/images/4761636694917_.pic_hd.jpg'
+---
+
+
+
+On November 10, the Cloud Native Computing Foundation (CNCF) accepted OpenELB, a load balancer plugin open sourced by KubeSphere, into the CNCF Sandbox.
+
+
+
+OpenELB, formerly known as "PorterLB", is a load balancer plugin designed for bare metal servers, edge devices, and private environments. It serves as an LB plugin for Kubernetes, K3s, and KubeSphere to expose LoadBalancer services to outside the cluster. OpenELB provides the following core functions:
+- Load balancing in BGP mode and Layer 2 mode
+- ECMP-based load balancing
+- IP address pool management
+- BGP configurations using CRDs
+
+
+
+## Why Did We Initiate OpenELB
+In the KubeSphere community, we surveyed over 5,000 users to find out environments that they use to deploy Kubernetes, and the result shows that nearly 36% of the users deploy Kubernetes on bare metal servers, and many users install and use Kubernetes or K3s on air-gapped data centers or edge devices. In private environments, exposing LoadBalancer services is difficult.
+
+
+In Kubernetes clusters, LoadBalancer services can be used to expose backend workloads to outside the cluster. Cloud vendors usually provide cloud-based LB plugins, which requires users to deploy their clusters on specific IaaS platforms. However, most enterprise users deploy Kubernetes clusters on bare metal servers, especially when these clusters are used in production. For private environments with bare metal servers and edge clusters, Kubernetes does not provide a LoadBalancer solution.
+
+OpenELB is designed to expose LoadBalancer services in non-public-cloud Kubernetes clusters. It provides easy-to-use EIPs and makes IP address pool management easier for users in private environments.
+## OpenELB Adopters and Contributors
+Currently, OpenELB has been used in production environments by many enterprises, such as BENLAI, Suzhou TV, CVTE, Wisdom World, Jollychic, QingCloud, BAIWANG, Rocketbyte, and more. At the end of 2019, BENLAI has used an earlier version of OpenELB in production. Now, OpenELB has attracted 13 contributors and more than 100 community members.
+
+
+## Differences Between OpenELB and MetalLB
+MetalLB is also a CNCF Sandbox project. It was launched at the end of 2017, and has been widely accepted by the community up to now. As a relatively young project, OpenELB is more Kubernetes-native. Thanks to contributions from the community, OpenELB has released eight versions and supported multiple routing methods. The following describes differences between OpenELB and MetalLB.
+### Cloud-native architecture
+In OpenELB, you can use CRDs to manage IP addresses and BGP settings. OpenELB is user-friendly for those who are familiar with kubectl. You can also directly use Kubernetes APIs to further customize OpenELB. In MetalLB, you can only manage IP addresses and BGP settings by using configmaps and obtain their status from logs.
+### Flexible IP address management
+
+OpenELB manages IP addresses by using the Eip CRD. It defines the status sub-resource to store the assignment status of IP addresses, which prevents conflicts among replicas and simplifies the programming logic.
+
+### Advertise routes using GoBGP
+
+MetalLB implements BGP by itself, while OpenELB implements BGP by using GoBGP, which has the following advantages:
+
+- Low development cost and robust support from the GoBGP community
+- Rich features of GoBGP
+- Dynamic configuration of GoBGP by using the BgpConf and BgpPeer CRDs, and the latest configurations are automatically loaded without OpenELB restart
+- When GoBGP is used as a library, the community provides Protocol Buffers (Protobuf) APIs. OpenELB references these APIs when implementing the BgpConf and BgpPeer CRD and remains compatible with GoBGP
+- OpenELB also provides status to view configurations of the BGP neighbor, which provides rich status information
+
+### Simple architecture and less resources occupied
+
+You can create an OpenELB deployment of multiple pod replicas to ensure high availability. Established connections still work well even though some replicas crash.
+
+In BGP mode, all replicas advertise equal-cost routes to the router and usually two replicas are sufficient. In Layer 2 mode, a leader is elected among the replicas by using the leader election mechanism of Kubernetes to respond to ARP/NDP requests.
+
+## Installation and Use of OpenELB
+
+You can deploy OpenELB on any standard Kubernetes and K3s verions and their distributions by using a YAML file or Helm chart. Alternatively, you can deploy it from the App Store or an app repository on the KubeSphere web console. For more information, see [OpenELB Documentation](https://openelb.github.io/docs/getting-started/installation/).
+
+## Future Plan
+
+Backed by CNCF, OpenELB will maintain its commitment as an open-source project driven completely by the community. The following features are planned and you are always welcome to contribute and send feedbacks.
+
+- VIP mode that supports Kubernetes high availability based on Keepalived
+- Load balancing for kube-apiserver
+- BGP policy configuration
+- VIP Group
+- Support for IPv6
+- GUI for EIP and IP pool management
+- Integration to the KubeSphere web console and support for Prometheus metrics
+
+To make service exposure and IP address management in private environments easier, we will continuously launch a variety of community activities to attract more developers and users.
+
+## Commitment to Open Source
+
+ The KubeSphere team has always been upholding the "Upstream first" principle. In July, 2021, the KubeSphere team donated Fluentbit Operator as a CNCF sub-project to the Fluent community. Now OpenELB, which was initiated by the KubeSphere team, also joins the CNCF sandbox. In the future, the KubeSphere team will serve as one of participants of the OpenELB project and maintain its commitment to open source. We will continue to work closely with all partners in the containerization field to build a vendor-neutral and open-source OpenELB community and ecosystem. Join the OpenELB community, tell us your experience when using OpenELB, and contribute to the OpenELB project!
+
+- ✨ GitHub: [https://github.com/kubesphere/openelb/](https://github.com/kubesphere/openelb/)
+- 💻 Official website: [https://openelb.github.io/](https://openelb.github.io/)
+- 🙋 Slack channel: kubesphere.slack.com
+
diff --git a/content/en/blogs/serverless-way-for-kubernetes-log-alert.md b/content/en/blogs/serverless-way-for-kubernetes-log-alert.md
new file mode 100644
index 000000000..19b1d02d4
--- /dev/null
+++ b/content/en/blogs/serverless-way-for-kubernetes-log-alert.md
@@ -0,0 +1,428 @@
+---
+title: 'Serverless Use Case: Elastic Kubernetes Log Alerts with OpenFunction and Kafka'
+tag: 'OpenFunction, KubeSphere, Kubernetes'
+keywords: 'OpenFunction, Serverless, KubeSphere, Kubernetes, Kafka, FaaS'
+description: 'This blog post offers ideas for serverless log processing, which reduces the link cost while improving flexibility.'
+createTime: '2021-08-26'
+author: 'Fang Tian, Bettygogo'
+snapshot: '/images/blogs/en/Serverless-way-for-Kubernetes-Log-Alerting/kubesphere snapshot.png'
+---
+
+## Overview
+
+How do you handle container logs collected by the message server? You may face a dilemma: Deploying a dedicated log processing workload can be costly, and it is difficult to assess the number of standby log processing workloads required when the quantity of logs fluctuates sharply. This blog post offers ideas for serverless log processing, which reduces the link cost while improving flexibility.
+
+Our general design idea is to add a Kafka server as a log receiver, and then use the log input to the Kafka server as an event to drive the serverless workloads to handle logs. Roughly, the following steps are involved:
+
+1. Set up a Kafka server as the log receiver for Kubernetes clusters.
+2. Deploy OpenFunction to provide serverless capabilities for log processing workloads.
+3. Write log processing functions to grab specific logs to generate alerting messages.
+4. Configure [Notification Manager](https://github.com/kubesphere/notification-manager/) to send alerts to Slack.
+
+
+
+In this scenario, we will make use of the serverless capabilities of[ OpenFunction](https://github.com/OpenFunction/OpenFunction).
+
+> [OpenFunction](https://github.com/OpenFunction/OpenFunction) is an open-source FaaS (serverless) project initiated by the KubeSphere community. It is designed to allow users to focus on their business logic without the hassle of caring about the underlying operating environment and infrastructure. Currently, the project provides the following key capabilities:
+>
+> - Builds OCI images from Dockerfile or Buildpacks.
+> - Runs serverless workloads using Knative Serving or OpenFunctionAsync (backed by KEDA + Dapr) as a runtime.
+> - Equipped with a built-in event-driven framework.
+
+## Use Kafka as a Log Receiver
+
+First, enable the **logging** component for the KubeSphere platform (For more information, please refer to[ Enable Pluggable Components](https://kubesphere.io/docs/pluggable-components/). Next, we can use [strimzi-kafka-operator](https://github.com/strimzi/strimzi-kafka-operator) to build a minimal Kafka server.
+
+1. In the `default` namespace, install [strimzi-kafka-operator.](https://github.com/strimzi/strimzi-kafka-operator)
+
+ ```shell
+ helm repo add strimzi https://strimzi.io/charts/
+ helm install kafka-operator -n default strimzi/strimzi-kafka-operator
+ ```
+
+2. Run the following commands to create a Kafka cluster and a Kafka topic in the `default` namespace. The storage type of the created Kafka and ZooKeeper clusters is **ephemeral**. Here, we use `emptyDir` for demonstration.
+
+ > Note that we have created a topic named `logs` for follow-up use.
+
+ ```shell
+ cat <
in the bottom-right corner, click **Kubectl**, and run the following command to edit the `kubesphere-config` ConfigMap:
+1. Log in to KubeSphere as `admin`, move the cursor to 
in the bottom-right corner, click **Kubectl**, and run the following command to edit the `kubesphere-config` ConfigMap:
+1. Log in to KubeSphere as `admin`, move the cursor to 
in **App Categories**.
+1. Log in to KubeSphere as `app-reviewer`. To create a category, go to the **App Store Management** page and click 
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.
+1. Find the `hosts` file on your local machine.
{{< notice note >}}
- The path of hosts file is `/etc/hosts` for Linux, or `c:\windows\system32\drivers\etc\hosts` for Windows.
+ 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.
+2. Add the following item into the `hosts` file.
```
192.168.4.3 gitlab.demo-project.svc.cluster.local
@@ -126,9 +98,7 @@ This tutorial demonstrates how to deploy GitLab on KubeSphere.
### 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 is being exposed through port `31246`, which you can use to 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 >}}
diff --git a/content/en/docs/application-store/external-apps/deploy-litmus.md b/content/en/docs/application-store/external-apps/deploy-litmus.md
index baaf18f35..97304ef23 100644
--- a/content/en/docs/application-store/external-apps/deploy-litmus.md
+++ b/content/en/docs/application-store/external-apps/deploy-litmus.md
@@ -26,41 +26,36 @@ This tutorial demonstrates how to deploy Litmus on KubeSphere and create chaos e
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. You will see 
icon if the URL is available. Click **OK** to continue.
-3. The app repository will be displayed in the list after it is successfully imported.
+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**.
-### Step 2: Deploy 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 **Deploy New App**.
+2. In the dialog that appears, choose **From App Template**.
-2. In the dialog that appears, choose **From App Templates**.
+ - **From App Store**: Select apps from the official APP Store of Kubephere.
- - **From App Store**: select apps from the official APP Store of Kubephere.
-
- - **From App Templates**: select apps from workspace app templates and the third-party Helm app templates of App Repository.
+ - **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 **Deploy**.
+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 Configurations**, you can edit the yaml file or directly click **Deploy**.
+6. Under **App Settings**, you can edit the yaml file or directly click **Install**.
-7. The app will be displayed in the list after you create it.
-
- 
+7. The app displays in the list after you create it successfully.
{{< notice note>}}
- It make take a while before Litmus is running. Please wait for the deployment to finish.
+ It may take a while before Litmus is running. Please wait for the deployment to finish.
{{}}
-### Step 3: Access Litmus Portal
+### 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`).
@@ -69,8 +64,8 @@ This tutorial demonstrates how to deploy Litmus on KubeSphere and create chaos e
{{< 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`.
- {{}}
+ 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)
@@ -90,7 +85,7 @@ For details about how to deploy External Agent, see [Litmus Docs](https://litmus
$ kubectl create deployment nginx --image=nginx --replicas=2 --namespace=default
```
-2. Log in to Litmus `Portal`, and then click **Schedule a workflow**.
+2. Log in to Litmus `Portal`, and then click **Schedule workflow**.
3. Choose an `Agent` (for example, `Self-Agent`), and then click **Next**.
@@ -110,8 +105,6 @@ For details about how to deploy External Agent, see [Litmus Docs](https://litmus
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.
@@ -123,22 +116,16 @@ For details about how to deploy External Agent, see [Litmus Docs](https://litmus
- **Experiment 2**
-1. Perform step 1 to 10 in **Experiment 1** to create a new chaos experiment (`pod-cpu-hog`).
+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 step 1 to 10 in **Experiment 1** to create a new chaos experiment (`pod-network-loss`).
+2. Perform steps 1 to 10 in **Experiment 1** to create a new chaos experiment (`pod-network-loss`).
diff --git a/content/en/docs/application-store/external-apps/deploy-metersphere.md b/content/en/docs/application-store/external-apps/deploy-metersphere.md
index da8fac2f8..756ebd20a 100644
--- a/content/en/docs/application-store/external-apps/deploy-metersphere.md
+++ b/content/en/docs/application-store/external-apps/deploy-metersphere.md
@@ -13,7 +13,7 @@ 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, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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
@@ -21,51 +21,27 @@ This tutorial demonstrates how to deploy MeterSphere on KubeSphere.
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 successfully imported to KubeSphere.
-
- 
+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 **Deploy New App**.
+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 Templates**.
-
- 
+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 **Deploy** to continue.
-
- 
+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 Configurations** page, change the value of `imageTag` from `master` to `v1.6`, and then click **Deploy**.
-
- 
+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 >}}
@@ -77,8 +53,6 @@ This tutorial demonstrates how to deploy MeterSphere on KubeSphere.
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 `
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 **Update** on the **Notification Settings** page to save it.
+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 alerting rules and alerting messages. You can also see the rule expression which is based on the template you use when creating the 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. **Notification Settings** displays the customized message you set in notifications.
-
-
+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 >}}
diff --git a/content/en/docs/cluster-administration/nodes.md b/content/en/docs/cluster-administration/nodes.md
index 039455b6a..565464357 100644
--- a/content/en/docs/cluster-administration/nodes.md
+++ b/content/en/docs/cluster-administration/nodes.md
@@ -13,29 +13,23 @@ This tutorial demonstrates what a cluster administrator can view and do for node
## Prerequisites
-You need an account 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 an account.
+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 top-left corner and select **Cluster Management**.
-
- 
+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 master.
- - **CPU**: The real-time CPU usage of a node.
- - **Memory**: The real-time memory usage of a node.
+ - **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.
@@ -48,20 +42,10 @@ Cluster nodes are only accessible to cluster administrators. Some node metrics a
Click a node from the list and you can go to its detail page.
-
-
- **Cordon/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. In KubeSphere, you mark a node as unschedulable by clicking **Cordon** on the node detail page. The node will be schedulable if you click the button (**Uncordon**) again.
- **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, click **More** and select **Edit Labels**.
- 
-
- 
-
- 
-
-- **Taints**: Taints allow a node to repel a set of pods. You add or remove node taints on the node detail page. To add or delete taints, click **More** and select **Taint Management** from the drop-down menu.
-
- 
+- **Taints**: Taints allow a node to repel a set of pods. You add or remove node taints on the node detail page. To add or delete taints, click **More** and select **Edit Taints** from the drop-down menu.
{{< 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/).
diff --git a/content/en/docs/cluster-administration/persistent-volume-and-storage-class.md b/content/en/docs/cluster-administration/persistent-volume-and-storage-class.md
index 53ff3b973..a8688bae8 100644
--- a/content/en/docs/cluster-administration/persistent-volume-and-storage-class.md
+++ b/content/en/docs/cluster-administration/persistent-volume-and-storage-class.md
@@ -1,34 +1,34 @@
---
title: "Persistent Volumes and Storage Classes"
-keywords: "storage, volume, pv, pvc, storage class, csi, Ceph RBD, Glusterfs, QingCloud, "
+keywords: "storage, volume, pv, pvc, storage class, csi, Ceph RBD, GlusterFS, QingCloud, "
description: "Learn basic concepts of PVs, PVCs and storage classes, and demonstrate how to manage storage classes and PVCs in KubeSphere."
linkTitle: "Persistent Volumes and Storage Classes"
weight: 8400
---
-This tutorial describes the basic concepts of PVs, PVCs and storage classes and demonstrates how a cluster administrator can manage storage classes and persistent volumes in KubeSphere.
+This tutorial describes the basic concepts of PVs, PVCs, and storage classes and demonstrates how a cluster administrator can manage storage classes and persistent volumes in KubeSphere.
## Introduction
-A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. PVs can be provisioned either [statically](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static) or [dynamically](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic).
+A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using storage classes. PVs are volume plugins like volumes, but have a lifecycle independent of any individual Pod that uses the PV. PVs can be provisioned either [statically](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static) or [dynamically](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic).
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources.
KubeSphere supports [dynamic volume provisioning](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/) based on storage classes to create PVs.
-A [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes) provides a way for administrators to describe the classes of storage they offer. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators. Each StorageClass has a provisioner that determines what volume plugin is used for provisioning PVs. This field must be specified. For which value to use, please read [the official Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner) or check with your storage administrator.
+A [storage class](https://kubernetes.io/docs/concepts/storage/storage-classes) provides a way for administrators to describe the classes of storage they offer. Different classes might map to quality-of-service levels, or to backup policies, or to arbitrary policies determined by the cluster administrators. Each storage class has a provisioner that determines what volume plugin is used for provisioning PVs. This field must be specified. For which value to use, please read [the official Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner) or check with your storage administrator.
The table below summarizes common volume plugins for various provisioners (storage systems).
| Type | Description |
| -------------------- | ------------------------------------------------------------ |
-| In-tree | Built-in and run as part of Kubernetes, such as [RBD](https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd) and [Glusterfs](https://kubernetes.io/docs/concepts/storage/storage-classes/#glusterfs). For more plugins of this kind, see [Provisioner](https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner). |
+| In-tree | Built-in and run as part of Kubernetes, such as [RBD](https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd) and [GlusterFS](https://kubernetes.io/docs/concepts/storage/storage-classes/#glusterfs). For more plugins of this kind, see [Provisioner](https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner). |
| External-provisioner | Deployed independently from Kubernetes, but works like an in-tree plugin, such as [nfs-client](https://github.com/kubernetes-retired/external-storage/tree/master/nfs-client). For more plugins of this kind, see [External Storage](https://github.com/kubernetes-retired/external-storage). |
| CSI | Container Storage Interface, a standard for exposing storage resources to workloads on COs (for example, Kubernetes), such as [QingCloud-csi](https://github.com/yunify/qingcloud-csi) and [Ceph-CSI](https://github.com/ceph/ceph-csi). For more plugins of this kind, see [Drivers](https://kubernetes-csi.github.io/docs/drivers.html). |
## Prerequisites
-You need an account 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 an account.
+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.
## Manage Storage Classes
@@ -36,30 +36,25 @@ You need an account granted a role including the authorization of **Cluster Mana
2. If you have enabled the [multi-cluster feature](../../multicluster-management/) with member clusters imported, you can select a specific cluster. If you have not enabled the feature, refer to the next step directly.
-3. On the **Cluster Management** page, go to **Storage Classes** under **Storage**, where you can create, update and delete a storage class.
-
- 
+3. On the **Cluster Management** page, go to **Storage Classes** under **Storage**, where you can create, update, and delete a storage class.
4. To create a storage class, click **Create** and enter the basic information in the displayed dialog box. When you finish, click **Next**.
-5. In KubeSphere, you can create storage classes for `QingCloud-CSI`, `Glusterfs`, and `Ceph RBD`. Alternatively, you can also create customized storage classes for other storage systems based on your needs. Select a type and click **Next**.
-
- 
-
- 
+5. In KubeSphere, you can create storage classes for `QingCloud-CSI`, `GlusterFS`, and `Ceph RBD`. Alternatively, you can also create customized storage classes for other storage systems based on your needs. Select a type and click **Next**.
### Common settings
-Some settings are commonly used and shared among storage classes. You can find them as dashboard properties on the console, which are also indicated by fields or annotations in the StorageClass manifest. You can see the manifest file in YAML format by enabling **Edit Mode** in the upper-right corner.
+Some settings are commonly used and shared among storage classes. You can find them as dashboard parameters on the console, which are also indicated by fields or annotations in the StorageClass manifest. You can see the manifest file in YAML format by clicking **Edit YAML** in the upper-right corner.
-Here are property descriptions of some commonly used fields in KubeSphere.
+Here are parameter descriptions of some commonly used fields in KubeSphere.
-| Property | Description |
+| Parameter | Description |
| :---- | :---- |
-| Allow Volume Expansion | Specified by `allowVolumeExpansion` in the manifest. When it is set to `true`, PVs can be configured to be expandable. For more information, see [Allow Volume Expansion](https://kubernetes.io/docs/concepts/storage/storage-classes/#allow-volume-expansion). |
-| Reclaiming Policy | Specified by `reclaimPolicy` in the manifest. It can be set to `Delete` or `Retain` (default). For more information, see [Reclaim Policy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy). |
+| Volume Expansion | Specified by `allowVolumeExpansion` in the manifest. When it is set to `true`, PVs can be configured to be expandable. For more information, see [Allow Volume Expansion](https://kubernetes.io/docs/concepts/storage/storage-classes/#allow-volume-expansion). |
+| Reclaim Policy | Specified by `reclaimPolicy` in the manifest. For more information, see [Reclaim Policy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy). |
| Storage System | Specified by `provisioner` in the manifest. It determines what volume plugin is used for provisioning PVs. For more information, see [Provisioner](https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner). |
-| Supported Access Mode | Specified by `metadata.annotations[storageclass.kubesphere.io/supported-access-modes]` in the manifest. It tells KubeSphere which [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) is supported. |
+| Access Mode | Specified by `metadata.annotations[storageclass.kubesphere.io/supported-access-modes]` in the manifest. It tells KubeSphere which [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) is supported. |
+| Volume Binding Mode | Specified by `volumeBindingMode` in the manifest. It determines what binding mode is used. **Delayed binding** means that a volume, after it is created, is bound to a volume instance when a Pod using this volume is created. **Immediate binding** means that a volume, after it is created, is immediately bound to a volume instance. |
For other settings, you need to provide different information for different storage plugins, which, in the manifest, are always indicated under the field `parameters`. They will be described in detail in the sections below. You can also refer to [Parameters](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters) in the official documentation of Kubernetes.
@@ -74,40 +69,40 @@ QingCloud CSI is a CSI plugin on Kubernetes for the storage service of QingCloud
#### Settings
-
-
-| Property | Description |
+| Parameter | Description |
| :---- | :---- |
-| type | On the QingCloud platform, 0 represents high performance volumes. 2 represents high capacity volumes. 3 represents super high performance volumes. 5 represents Enterprise Server SAN. 100 represents standard volumes. 200 represents enterprise SSD. |
-| maxSize | The volume size upper limit. |
-| stepSize | The volume size increment. |
-| minSize | The volume size lower limit. |
-| fsType | Filesystem type of the volume: ext3, ext4 (default), xfs. |
-| tags | The ID of QingCloud Tag resource, split by commas. |
+| Type | On QingCloud Public Cloud Platform, 0 means high performance volume; 2 high capacity volume; 3 ultra-high performance volume; 5 enterprise server SAN (NeonSAN); 100 standard volume; 200 enterprise SSD. |
+| Maximum Size | Maximum size of the volume. |
+| Step Size | Step size of the volume. |
+| Minimum Size | Minimum size of the volume. |
+| File System Type | Supports ext3, ext4, and XFS. The default type is ext4. |
+| Tag | Add tags to the storage volume. Use commas to separate multiple tags. |
For more information about storage class parameters, see [QingCloud-CSI user guide](https://github.com/yunify/qingcloud-csi/blob/master/docs/user-guide.md#set-storage-class).
-### Glusterfs
+### GlusterFS
-Glusterfs is an in-tree storage plugin on Kubernetes, which means you don't need to install a volume plugin additionally.
+GlusterFS is an in-tree storage plugin on Kubernetes, which means you don't need to install a volume plugin additionally.
#### Prerequisites
-The Glusterfs storage system has already been installed. See [GlusterFS Installation Documentation](https://www.gluster.org/install/) for more information.
+The GlusterFS storage system has already been installed. See [GlusterFS Installation Documentation](https://www.gluster.org/install/) for more information.
#### Settings
-| Property | Description |
+| Parameter | Description |
| :---- | :---- |
-| resturl | The Gluster REST service/Heketi service url which provision gluster volumes on demand. |
-| clusterid | The ID of the cluster which will be used by Heketi when provisioning the volume. |
-| restauthenabled | Gluster REST service authentication boolean that enables authentication to the REST server. |
-| restuser | The Glusterfs REST service/Heketi user who has access to create volumes in the Glusterfs Trusted Pool. |
-| secretNamespace, secretName | The Identification of Secret instance that contains user password to use when talking to Gluster REST service. |
-| gidMin, gidMax | The minimum and maximum value of GID range for the StorageClass. |
-| volumetype | The volume type and its parameters can be configured with this optional value. |
+| REST URL | Heketi REST URL that provisions volumes, for example, <Heketi Service cluster IP Address>:<Heketi Service port number>. |
+| Cluster ID | Gluster cluster ID. |
+| REST Authentication | Gluster enables authentication to the REST server. |
+| REST User | Username of Gluster REST service or Heketi service. |
+| Secret Namespace/Secret Name | Namespace of the Heketi user secret. |
+| Secret Name | Name of the Heketi user secret. |
+| Minimum GID | Minimum GID of the volume. |
+| Maximum GID | Maximum GID of the volume. |
+| Volume Type | Type of volume. The value can be none, replicate:<Replicate count>, or disperse:<Data>:<Redundancy count>. If the volume type is not set, the default volume type is replicate:3. |
-For more information about StorageClass parameters, see [Glusterfs in Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#glusterfs).
+For more information about storage class parameters, see [GlusterFS in Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#glusterfs).
### Ceph RBD
@@ -117,8 +112,6 @@ but the storage server must be installed before you create the storage class of
As **hyperkube** images were [deprecated since 1.17](https://github.com/kubernetes/kubernetes/pull/85094), in-tree Ceph RBD may not work without **hyperkube**.
Nevertheless, you can use [rbd provisioner](https://github.com/kubernetes-incubator/external-storage/tree/master/ceph/rbd) as a substitute, whose format is the same as in-tree Ceph RBD. The only different parameter is `provisioner` (i.e **Storage System** on the KubeSphere console). If you want to use rbd-provisioner, the value of `provisioner` must be `ceph.com/rbd` (Enter this value in **Storage System** in the image below). If you use in-tree Ceph RBD, the value must be `kubernetes.io/rbd`.
-
-
#### Prerequisites
- The Ceph server has already been installed. See [Ceph Installation Documentation](https://docs.ceph.com/en/latest/install/) for more information.
@@ -126,19 +119,19 @@ Nevertheless, you can use [rbd provisioner](https://github.com/kubernetes-incuba
#### Settings
-| Property | Description |
+| Parameter | Description |
| :---- | :---- |
-| monitors| The Ceph monitors, comma delimited. |
-| adminId| The Ceph client ID that is capable of creating images in the pool. |
-| adminSecretName| The Secret Name for `adminId`. |
-| adminSecretNamespace| The namespace for `adminSecretName`. |
-| pool | The Ceph RBD pool. |
+| Monitors| IP address of Ceph monitors. |
+| adminId| Ceph client ID that is capable of creating images in the pool. |
+| adminSecretName| Secret name of `adminId`. |
+| adminSecretNamespace| Namespace of `adminSecretName`. |
+| pool | Name of the Ceph RBD pool. |
| userId | The Ceph client ID that is used to map the RBD image. |
| userSecretName | The name of Ceph Secret for `userId` to map RBD image. |
| userSecretNamespace | The namespace for `userSecretName`. |
-| fsType | The fsType that is supported by Kubernetes. |
-| imageFormat | The Ceph RBD image format, `1` or `2`. |
-| imageFeatures| This parameter is optional and should only be used if you set `imageFormat` to `2`. |
+| File System Type | File system type of the storage volume. |
+| imageFormat | Option of the Ceph volume. The value can be `1` or `2`. `imageFeatures` needs to be filled when you set imageFormat to `2`. |
+| imageFeatures| Additional function of the Ceph cluster. The value should only be set when you set imageFormat to `2`. |
For more information about StorageClass parameters, see [Ceph RBD in Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd).
@@ -164,14 +157,13 @@ It is not recommended that you use NFS storage for production (especially on Kub
#### Common Settings
-
-
-| Property | Description |
+| Parameter | Description |
| :---- | :---- |
+| Volume Expansion | Specified by `allowVolumeExpansion` in the manifest. Select `No`. |
+| Reclaim Policy | Specified by `reclaimPolicy` in the manifest. The value is `Delete` by default. |
| Storage System | Specified by `provisioner` in the manifest. If you install the storage class by [charts for nfs-client](https://github.com/kubesphere/helm-charts/tree/master/src/main/nfs-client-provisioner), it can be `cluster.local/nfs-client-nfs-client-provisioner`. |
-| Allow Volume Expansion | Specified by `allowVolumeExpansion` in the manifest. Select `No`. |
-| Reclaiming Policy | Specified by `reclaimPolicy` in the manifest. The value is `Delete` by default. |
-| Supported Access Mode | Specified by `.metadata.annotations.storageclass.kubesphere.io/supported-access-modes` in the manifest. `ReadWriteOnce`, `ReadOnlyMany` and `ReadWriteMany` all are selected by default. |
+| Access Mode | Specified by `.metadata.annotations.storageclass.kubesphere.io/supported-access-modes` in the manifest. `ReadWriteOnce`, `ReadOnlyMany` and `ReadWriteMany` are all selected by default. |
+| Volume Binding Mode | Specified by `volumeBindingMode` in the manifest. It determines what binding mode is used. **Delayed binding** means that a volume, after it is created, is bound to a volume instance when a Pod using this volume is created. **Immediate binding** means that a volume, after it is created, is immediately bound to a volume instance. |
#### Parameters
@@ -179,6 +171,55 @@ It is not recommended that you use NFS storage for production (especially on Kub
| :---- | :---- | :----|
| archiveOnDelete | Archive pvc when deleting | `true` |
+### Storage class details page
+
+After you create a storage class, click the name of the storage class to go to its details page. On the details page, click **Edit YAML** to edit the manifest file of the storage class, or click **More** to select an operation from the drop-down menu:
+
+- **Set as Default Storage Class**: Set the storage class as the default storage class in the cluster. Only one default storage class is allowed in a KubeSphere cluster.
+- **Volume Management**: Manage volume features, including: **Volume Clone**, **Volume Snapshot**, and **Volume Expansion**. Before enabling any features, you should contact your system administrator to confirm that the features are supported by the storage system.
+- **Delete**: Delete the storage class and return to the previous page.
+
+On the **Volumes** tab, view the volumes associated to the storage class.
+
## Manage Volumes
Once the storage class is created, you can create volumes with it. You can list, create, update and delete volumes in **Volumes** under **Storage** on the KubeSphere console. For more details, please see [Volume Management](../../project-user-guide/storage/volumes/).
+
+## Manage Volume Instances
+
+A volume in KubeSphere is a [persistent volume claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) in Kubernetes, and a volume instance is a [persistent volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) in Kubernetes.
+
+### Volume instance list page
+
+1. Log in to KubeSphere web console as `admin`. Click **Platform** in the upper-left corner, select **Cluster Management**, and click **Volumes** under **Storage**.
+2. Click the **Volume Instances** tab on the **Volumes** page to view the volume instance list page that provides the following information:
+ - **Name**: Name of the volume instance. It is specified by the field `.metadata.name` in the manifest file of the volume instance.
+ - **Status**: Current status of the volume instance. It is specified by the field `.status.phase` in the manifest file of the volume instance, including:
+ - **Available**: The volume instance is available and not yet bound to a volume.
+ - **Bound**: The volume instance is bound to a volume.
+ - **Terminating**: The volume instance is being deleted.
+ - **Failed**: The volume instance is unavailable.
+ - **Capacity**: Capacity of the volume instance. It is specified by the field `.spec.capacity.storage` in the manifest file of the volume instance.
+ - **Access Mode**: Access mode of the volume instance. It is specified by the field `.spec.accessModes` in the manifest file of the volume instance, including:
+ - **RWO**: The volume instance can be mounted as read-write by a single node.
+ - **ROX**: The volume instance can be mounted as read-only by multiple nodes.
+ - **RWX**: The volume instance can be mounted as read-write by multiple nodes.
+ - **Recycling Strategy**: Recycling strategy of the volume instance. It is specified by the field `.spec.persistentVolumeReclaimPolicy` in the manifest file of the volume instance, including:
+ - **Retain**: When a volume is deleted, the volume instance still exists and requires manual reclamation.
+ - **Delete**: Remove both the volume instance and the associated storage assets in the volume plugin infrastructure.
+ - **Recycle**: Erase the data on the volume instance and make it available again for a new volume.
+ - **Creation Time**: Time when the volume instance was created.
+3. Click 
.
-4. To make sure notifications will be sent to your recipients, turn on **Receive Notifications** and click **Update**.
+### 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 
to modify the code segment of `
on the right of **ks-jenkins** to edit its YAML.
+3. Go to **Workloads** under **Application Workloads**, and select the project **kubesphere-devops-system** from the drop-down list. Click 
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 **Activity** tab, check that a new run is triggered by the pull request submitted to the `sonarqube` branch of the remote repository.
-
- 
+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/devops-user-guide/how-to-use/set-ci-node.md b/content/en/docs/devops-user-guide/how-to-use/set-ci-node.md
index fe72badaa..660579e26 100644
--- a/content/en/docs/devops-user-guide/how-to-use/set-ci-node.md
+++ b/content/en/docs/devops-user-guide/how-to-use/set-ci-node.md
@@ -12,29 +12,23 @@ This tutorial demonstrates how to set CI nodes so that KubeSphere schedules task
## Prerequisites
-You need an account 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 an account.
+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 top-left corner and select **Cluster Management**.
+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 **Node Management**, where you can see existing nodes in the current cluster.
+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**.
-4. Choose a node from the list to run CI tasks. For example, select `node2` here and click it to go to its detail page. Click **More** and select **Edit Labels**.
-
- 
-
-5. In the dialog that appears, you can see a label with the key `node-role.kubernetes.io/worker`. Enter `ci` for its value and click **Save**.
-
- 
+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 Labels** to add new labels based on your needs.
+ You can also click **Add** to add new labels based on your needs.
{{}}
@@ -42,18 +36,12 @@ You need an account granted a role including the permission of **Cluster Managem
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 **Taint Management**.
+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 `NoSchedule` or `PreferNoSchedule` based on your needs.
-
- 
+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/devops-user-guide/how-to-use/use-pipeline-templates.md b/content/en/docs/devops-user-guide/how-to-use/use-pipeline-templates.md
index 8bf734029..3a150b79f 100644
--- a/content/en/docs/devops-user-guide/how-to-use/use-pipeline-templates.md
+++ b/content/en/docs/devops-user-guide/how-to-use/use-pipeline-templates.md
@@ -6,9 +6,9 @@ linkTitle: "Use Pipeline Templates"
weight: 11290
---
-KubeSphere offers a graphical editing panel where the stages and steps of a Jenkins pipeline can be defined through interactive operations. In KubeSphere v3.1, two built-in pipeline templates are provided as frameworks of continuous integration (CI) and continuous delivery (CD).
+KubeSphere offers a graphical editing panel where the stages and steps of a Jenkins pipeline can be defined through interactive operations. In KubeSphere 3.2.1, two built-in pipeline templates are provided as frameworks of continuous integration (CI) and continuous delivery (CD).
-When you have a pipeline created in your DevOps project on KubeSphere, you can click the pipeline to go to its detail page, and then click **Edit Pipeline** to select a pipeline template based on your needs. This document illustrates the concept of these two pipeline templates.
+When you have a pipeline created in your DevOps project on KubeSphere, you can click the pipeline to go to its details page, and then click **Edit Pipeline** to select a pipeline template based on your needs. This document illustrates the concept of these two pipeline templates.
## CI Pipeline Template
diff --git a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/devops-project-management.md b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/devops-project-management.md
index 6104d58ab..cc9df9f5e 100644
--- a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/devops-project-management.md
+++ b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/devops-project-management.md
@@ -10,33 +10,25 @@ This tutorial demonstrates how to create and manage DevOps projects.
## Prerequisites
-- You need to create a workspace and an account (`project-admin`). The account must be invited to the workspace with the role of `workspace-self-provisioner`. For more information, refer to [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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/).
- You need to enable the [KubeSphere DevOps system](../../../pluggable-components/devops/).
## Create a DevOps Project
1. Log in to the console of KubeSphere as `project-admin`. Go to **DevOps Projects** and click **Create**.
- 
-
2. Provide the basic information for the DevOps project and click **OK**.
- 
-
- **Name**: A concise and clear name for this DevOps project, which is convenient for users to identify, such as `demo-devops`.
- **Alias**: The alias name of the DevOps project.
- **Description**: A brief introduction to the DevOps project.
- **Cluster Settings**: In the current version, a DevOps project cannot run across multiple clusters at the same time. If you have enabled [the multi-cluster feature](../../../multicluster-management/), you must select the cluster where your DevOps project runs.
-3. A DevOps project will appear in the list below after created.
-
- 
+3. A DevOps project is displayed in the list below after created.
## View a DevOps Project
-Click the DevOps project just created to go to its detail page. Tenants with different permissions are allowed to perform various tasks in a DevOps project, including creating CI/CD pipelines and credentials, and managing accounts and roles.
-
-
+Click the DevOps project just created to go to its details page. Tenants with different permissions are allowed to perform various tasks in a DevOps project, including creating CI/CD pipelines and credentials, and managing accounts and roles.
### Pipelines
@@ -52,8 +44,6 @@ Similar to a project, a DevOps project also requires users to be granted differe
## Edit or Delete a DevOps Project
-1. Click **Basic Information** under **Project Management**, and you can see an overview of the current DevOps project, including the number of project roles and members, project name and project creator.
+1. Click **Basic Information** under **DevOps Project Settings**, and you can see an overview of the current DevOps project, including the number of project roles and members, project name and project creator.
-2. Click **Project Management** on the right, and you can edit the basic information of the DevOps project or delete it.
-
- 
\ No newline at end of file
+2. Click **Manage** on the right, and you can edit the basic information of the DevOps project or delete it.
diff --git a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/overview.md b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/overview.md
index 39c5532a3..da0eacb6f 100644
--- a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/overview.md
+++ b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/overview.md
@@ -8,9 +8,9 @@ weight: 11110
DevOps is a set of practices and tools that automate the processes between IT and software development teams. Among other things, as agile software development sees increasing popularity, continuous integration (CI) and continuous delivery (CD) have become an ideal solution in this connection. In a CI/CD workflow, every integration is tested through automatic building, including coding, releasing and testing. This helps developers to identify any integration errors beforehand and teams can deliver internal software to a production environment with speed, security, and reliability.
-Nevertheless, the traditional master-agent architecture of Jenkins (i.e. multiple agents work for a master) has the following shortcomings.
+Nevertheless, the traditional controller-agent architecture of Jenkins (i.e. multiple agents work for a controller) has the following shortcomings.
-- The entire CI/CD pipeline will crash once the master goes down.
+- The entire CI/CD pipeline will crash once the controller goes down.
- Resources are not allocated equally as some agents see pipeline jobs wait in queue while others remain idle.
- Different agents may be configured in different environments and require different coding languages. The disparity can cause inconvenience in management and maintenance.
@@ -29,15 +29,11 @@ The KubeSphere DevOps system provides you with the following features:
- [Graphical editing panels](../../../devops-user-guide/how-to-use/create-a-pipeline-using-graphical-editing-panel/) to create pipelines with a low learning curve.
- A powerful tool integration mechanism such as [SonarQube](../../../devops-user-guide/how-to-integrate/sonarqube/) for code quality check.
-
-
-
-
### KubeSphere CI/CD pipeline workflows
-A KubeSphere CI/CD pipeline runs on the back of the underlying Kubernetes Jenkins agents. These Jenkins agents can be dynamically scaled as they are dynamically provisioned or released based on the job status. The Jenkins master and agents run as Pods on KubeSphere nodes. The master runs on one of the nodes with its configuration data stored in a volume. Agents run across nodes while they may not be active all the time because they are created dynamically and deleted automatically as needed.
+A KubeSphere CI/CD pipeline runs on the back of the underlying Kubernetes Jenkins agents. These Jenkins agents can be dynamically scaled as they are dynamically provisioned or released based on the job status. The Jenkins controller and agents run as Pods on KubeSphere nodes. The controller runs on one of the nodes with its configuration data stored in a volume. Agents run across nodes while they may not be active all the time because they are created dynamically and deleted automatically as needed.
-When the Jenkins master receives a building request, it dynamically creates Jenkins agents that run in Pods according to labels. At the same time, Jenkins agents will be registered in the master. After agents finish their jobs, they will be released and related Pods will be deleted as well.
+When the Jenkins controller receives a building request, it dynamically creates Jenkins agents that run in Pods according to labels. At the same time, Jenkins agents will be registered in the controller. After agents finish their jobs, they will be released and related Pods will be deleted as well.
### Dynamically provision Jenkins agents
@@ -47,4 +43,4 @@ The advantages of dynamically provisioning Jenkins agents are:
**High scalability**. When a KubeSphere cluster has insufficient resources which lead to long waiting time of jobs in the queue, you can add new nodes to the cluster.
-**High availability**. When a Jenkins master fails, KubeSphere automatically creates a new Jenkins master container with the volume mounted to the new container. In this way, the data are secured with high availability achieved for the cluster.
+**High availability**. When a Jenkins controller fails, KubeSphere automatically creates a new Jenkins controller container with the volume mounted to the new container. In this way, the data are secured with high availability achieved for the cluster.
diff --git a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/role-and-member-management.md b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/role-and-member-management.md
index 4ea78a9e6..0f30c6567 100644
--- a/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/role-and-member-management.md
+++ b/content/en/docs/devops-user-guide/understand-and-manage-devops-projects/role-and-member-management.md
@@ -17,11 +17,11 @@ In DevOps project scope, you can grant the following resources' permissions to a
## Prerequisites
-At least one DevOps project has been created, such as `demo-devops`. Besides, you need an account of the `admin` role (for example, `devops-admin`) at the DevOps project level.
+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 **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.
+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 |
| ------------------ | ------------------------------------------------------------ |
@@ -35,27 +35,21 @@ In **Project Roles**, there are three available built-in roles as shown below. B
{{< 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 **Project Member Viewing**, **Project Role Management** and **Project Role Viewing** in **Access Control** at DevOps project level, it can create a DevOps project role.
+ 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 **Project Roles** in **Project Management**, click **Create** and set a **Name**. In this example, a role named `pipeline-creator` will be created. Click **Edit Permissions** to continue.
-
- 
+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 **Project Roles**. You can click 
on the right to edit it.
-
- 
+4. Newly created roles will be listed in **DevOps Project Roles**. You can click 
to invite an account to the DevOps project. Grant the role of `pipeline-creator` to the account.
-
- 
+2. Click 
to invite a user to the DevOps project. Grant the role of `pipeline-creator` to the account.
{{< notice note >}}
@@ -77,9 +69,8 @@ In **Project Roles**, there are three available built-in roles as shown below. B
{{}}
-3. After you add a user to the DevOps project, click **OK**. In **Project Members**, you can see the newly invited member listed.
+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/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md b/content/en/docs/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
index acefe87ac..3d8c868d1 100644
--- a/content/en/docs/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
+++ b/content/en/docs/faq/access-control/add-kubernetes-namespace-to-kubesphere-workspace.md
@@ -12,9 +12,9 @@ This tutorial demonstrates how to add an existing Kubernetes namespace to a Kube
## Prerequisites
-- You need an account 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 an account.
+- 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, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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
@@ -28,15 +28,11 @@ For more information about creating a Kubernetes namespace, see [Namespaces Walk
## 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 (i.e. namespaces) running on the current cluster, including the one just created.
+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 **Target Workspace** and a **Project Manager** for the project and click **OK**.
+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/faq/access-control/cannot-login.md b/content/en/docs/faq/access-control/cannot-login.md
index 2837a78bf..804e6e53c 100644
--- a/content/en/docs/faq/access-control/cannot-login.md
+++ b/content/en/docs/faq/access-control/cannot-login.md
@@ -1,22 +1,22 @@
---
-title: "Account Login Failure"
-keywords: "login failure, account is not active, KubeSphere, Kubernetes"
+title: "User Login Failure"
+keywords: "login failure, user is not active, KubeSphere, Kubernetes"
description: "How to solve the issue of login failure"
-linkTitle: "Account Login Failure"
+linkTitle: "User Login Failure"
Weight: 16440
---
-KubeSphere automatically creates a default account (`admin/P@88w0rd`) when it is installed. An account cannot be used for login if the status is not **Active** or you use an incorrect password.
+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 account login failure.
+Here are some of the frequently asked questions about user login failure.
-## Account Not Active
+## 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 your account.
+1. Execute the following command to check the status of the user.
```bash
$ kubectl get users
@@ -88,7 +88,7 @@ kubectl -n kubesphere-system get deploy ks-controller-manager -o jsonpath='{.spe
-Run the following command to verify that the account and the password are correct.
+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
+4. Click 
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 **Update**.
+5. Scroll down to the bottom of the file, add `telemetry_enabled: false`, and then click **OK**.
{{< notice note >}}
diff --git a/content/en/docs/faq/multi-cluster-management/manage-multi-cluster.md b/content/en/docs/faq/multi-cluster-management/manage-multi-cluster.md
index f10c4c2d0..5bb132e42 100644
--- a/content/en/docs/faq/multi-cluster-management/manage-multi-cluster.md
+++ b/content/en/docs/faq/multi-cluster-management/manage-multi-cluster.md
@@ -25,7 +25,7 @@ Once you build a multi-cluster environment on KubeSphere, you can manage it thro
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 (i.e. namespaces), you can follow the steps as below.
+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.
@@ -45,11 +45,11 @@ If you want to import the Member Cluster to a new Host Cluster while retaining e
kuebctl label ns 
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
@@ -63,20 +59,12 @@ Log in to the web console of Alibaba Cloud. Go to **Clusters** under **Container
-### Step 3: Import the ACK Member Cluster
+### 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**.
-
- 
+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**.
-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
+4. Wait for cluster initialization to finish.
\ No newline at end of file
diff --git a/content/en/docs/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md b/content/en/docs/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md
index 8cac5d377..1882a0ac9 100644
--- a/content/en/docs/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md
+++ b/content/en/docs/multicluster-management/import-cloud-hosted-k8s/import-aws-eks.md
@@ -10,18 +10,18 @@ This tutorial demonstrates how to import an AWS EKS cluster through the [direct
## 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.
+- 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
+### 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
+### 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.
+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
@@ -37,12 +37,8 @@ You need to deploy KubeSphere on your EKS cluster first. For more information ab
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
@@ -164,20 +160,12 @@ You need to deploy KubeSphere on your EKS cluster first. For more information ab
ip-10-0-8-148.cn-north-1.compute.internal Ready 
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
@@ -109,20 +105,12 @@ You need to deploy KubeSphere on your GKE cluster first. For more information ab
token: eyJhbGciOiJSUzI1NiIsImtpZCI6InNjOFpIb3RrY3U3bGNRSV9NWV8tSlJzUHJ4Y2xnMDZpY3hhc1BoVy0xTGsifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlc3BoZXJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJrdWJlc3BoZXJlLXRva2VuLXpocmJ3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Imt1YmVzcGhlcmUiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiIyMGFmZGI1Ny01MTBkLTRjZDgtYTAwYS1hNDQzYTViNGM0M2MiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZXNwaGVyZS1zeXN0ZW06a3ViZXNwaGVyZSJ9.ic6LaS5rEQ4tXt_lwp7U_C8rioweP-ZdDjlIZq91GOw9d6s5htqSMQfTeVlwTl2Bv04w3M3_pCkvRzMD0lHg3mkhhhP_4VU0LIo4XeYWKvWRoPR2kymLyskAB2Khg29qIPh5ipsOmGL9VOzD52O2eLtt_c6tn-vUDmI_Zw985zH3DHwUYhppGM8uNovHawr8nwZoem27XtxqyBkqXGDD38WANizyvnPBI845YqfYPY5PINPYc9bQBFfgCovqMZajwwhcvPqS6IpG1Qv8TX2lpuJIK0LLjiKaHoATGvHLHdAZxe_zgAC2cT_9Ars3HIN4vzaSX0f-xP--AcRgKVSY9g
```
-### Step 4: Import the GKE Member Cluster
+### 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**.
-
- 
+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**.
-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
+4. Wait for cluster initialization to finish.
\ No newline at end of file
diff --git a/content/en/docs/multicluster-management/import-on-prem-k8s/_index.md b/content/en/docs/multicluster-management/import-on-prem-k8s/_index.md
deleted file mode 100644
index 8d0aeb228..000000000
--- a/content/en/docs/multicluster-management/import-on-prem-k8s/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-linkTitle: "Import On-premises Kubernetes Clusters"
-weight: 5400
-
-_build:
- render: false
----
diff --git a/content/en/docs/multicluster-management/import-on-prem-k8s/import-kubeadm-k8s.md b/content/en/docs/multicluster-management/import-on-prem-k8s/import-kubeadm-k8s.md
deleted file mode 100644
index 9370f4355..000000000
--- a/content/en/docs/multicluster-management/import-on-prem-k8s/import-kubeadm-k8s.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: "Import Kubeadm Kubernetes Cluster"
-keywords: 'kubernetes, kubesphere, multicluster, kubeadm'
-description: 'Learn how to import a Kubernetes cluster created with kubeadm.'
-
-
-weight: 5410
----
-
-TBD
diff --git a/content/en/docs/multicluster-management/introduction/kubefed-in-kubesphere.md b/content/en/docs/multicluster-management/introduction/kubefed-in-kubesphere.md
index ffad56b3c..f4dcc4d82 100644
--- a/content/en/docs/multicluster-management/introduction/kubefed-in-kubesphere.md
+++ b/content/en/docs/multicluster-management/introduction/kubefed-in-kubesphere.md
@@ -1,7 +1,7 @@
---
title: "KubeSphere Federation"
keywords: 'Kubernetes, KubeSphere, federation, multicluster, hybrid-cloud'
-description: 'Understand the fundamental concept of Kubernetes federation in KubeSphere, including M clusters and H clusters.'
+description: 'Understand the fundamental concept of Kubernetes federation in KubeSphere, including member clusters and host clusters.'
linkTitle: "KubeSphere Federation"
weight: 5120
---
@@ -10,11 +10,11 @@ The multi-cluster feature relates to the network connection among multiple clust
## How the Multi-cluster Architecture Works
-Before you use the central control plane of KubeSphere to management multiple clusters, you need to create a Host Cluster, also known as **H** Cluster. The H 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 **M** Cluster. M 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 H Cluster to manage all M Clusters, such as viewing and editing resources on M Clusters. Conversely, if you access the web console of any M Cluster separately, you cannot see any resources on other clusters.
+Before you use the central control plane of KubeSphere to management 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.
-There can only be one H Cluster while multiple M Clusters can exist at the same time. In a multi-cluster architecture, the network between the H Cluster and M Clusters can be connected directly or through an agent. The network between M 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.
@@ -38,12 +38,12 @@ Before you enable multi-cluster management, make sure you have enough resources
{{< 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 H Cluster. If you use [agent connection](../../../multicluster-management/enable-multicluster/agent-connection/), only tower is needed for M Clusters. If you use [direct connection](../../../multicluster-management/enable-multicluster/direct-connection/), no additional component is needed for M Clusters.
+- 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 H Cluster and M Clusters. You only need to enable the App Store on the H Cluster and you can use functions related to the App Store on M Clusters directly (no matter whether the App Store is enabled on M Clusters or not), such as [app templates](../../../project-user-guide/application/app-template/) and [app repositories](../../../workspace-administration/app-repository/import-helm-repository/).
+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 M Clusters without enabling it on the H Cluster, you will not be able to use the App Store on any cluster in the multi-cluster architecture.
\ No newline at end of file
+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.
\ No newline at end of file
diff --git a/content/en/docs/multicluster-management/unbind-cluster.md b/content/en/docs/multicluster-management/unbind-cluster.md
index b3326402a..9f5dae030 100644
--- a/content/en/docs/multicluster-management/unbind-cluster.md
+++ b/content/en/docs/multicluster-management/unbind-cluster.md
@@ -11,20 +11,16 @@ This tutorial demonstrates how to unbind a cluster from the central control plan
## Prerequisites
- You have enabled multi-cluster management.
-- You need an account 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 an account.
+- 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.
## Unbind a Cluster
-1. Click **Platform** in the top-left corner and select **Cluster Management**.
+1. Click **Platform** in the upper-left corner and select **Cluster Management**.
-2. On the **Cluster Management** page, click the cluster that you want to remove from the central control plane.
-
- 
+2. On the **Cluster Management** page, click the cluster that you want to remove from the control plane.
3. Go to **Basic Information** under **Cluster Settings**, check **I confirm I want to unbind the cluster** and click **Unbind**.
- 
-
{{< notice note >}}
After you unbind the cluster, you cannot manage it from the control plane while Kubernetes resources on the cluster will not be deleted.
diff --git a/content/en/docs/pluggable-components/alerting.md b/content/en/docs/pluggable-components/alerting.md
index 0cce528fd..851e365b9 100644
--- a/content/en/docs/pluggable-components/alerting.md
+++ b/content/en/docs/pluggable-components/alerting.md
@@ -6,9 +6,9 @@ linkTitle: "KubeSphere Alerting"
weight: 6600
---
-Alerting is an important building block of observability, closely related to monitoring and logging. The alerting system in KubeSphere, coupled with the proactive failure notification system, allows users to know activities of interest based on alerting policies. When a predefined threshold of a certain metric is reached, an alert will be sent to preconfigured recipients. Therefore, you need to configure the notification method beforehand, including Email, Slack, DingTalk, WeCom and Webhook. With a highly functional alerting and notification system in place, you can quickly identify and resolve potential issues in advance before they affect your business.
+Alerting is an important building block of observability, closely related to monitoring and logging. The alerting system in KubeSphere, coupled with the proactive failure notification system, allows users to know activities of interest based on alerting policies. When a predefined threshold of a certain metric is reached, an alert will be sent to preconfigured recipients. Therefore, you need to configure the notification method beforehand, including Email, Slack, DingTalk, WeCom, and Webhook. With a highly functional alerting and notification system in place, you can quickly identify and resolve potential issues in advance before they affect your business.
-## Enable Alerting before Installation
+## Enable Alerting Before Installation
### Installing on Linux
@@ -39,9 +39,9 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
### Installing on Kubernetes
-As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable Alerting first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) file.
+As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/), you can enable Alerting first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -57,14 +57,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable Alerting after Installation
+## Enable Alerting After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -72,9 +72,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+3. In **Custom Resources**, click 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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -89,14 +89,12 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+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/pluggable-components/app-store.md b/content/en/docs/pluggable-components/app-store.md
index 279506b9d..1f8eb9601 100644
--- a/content/en/docs/pluggable-components/app-store.md
+++ b/content/en/docs/pluggable-components/app-store.md
@@ -6,15 +6,13 @@ 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, deploy and release apps with just several clicks in a one-stop shop.
+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. By default, there are 17 built-in apps in the App Store. After you enable this feature, you can add more apps with app templates.
-
-
+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
+## Enable the App Store Before Installation
### Installing on Linux
@@ -46,9 +44,9 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -65,14 +63,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable the App Store after Installation
+## Enable the App Store After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -82,9 +80,9 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{}}
-3. In **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+3. In **Custom Resources**, click on the right of `ks-installer` and select **Edit YAML**.
-4. In this YAML file, navigate to `openpitrix` and change `false` to `true` for `enabled`. After you finish, click **Update** in the bottom-right corner to save the configuration.
+4. In this YAML file, navigate to `openpitrix` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
```yaml
openpitrix:
@@ -100,25 +98,23 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+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 top-left corner and 17 built-in apps in it, it means the installation is successful.
-
-
+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**.
+3. In **Custom Resources**, click 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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -116,7 +116,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
```
{{< 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 `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
+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
@@ -127,7 +127,7 @@ By default, Elasticsearch will be installed internally if Auditing is enabled. F
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 bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
## Verify the Installation of the Component
@@ -148,9 +148,7 @@ You can find the web kubectl tool by clicking 
}}
-Verify that you can use the **Auditing Operating** function from the **Toolbox** in the bottom-right corner.
-
-
+Verify that you can use the **Audit Log Search** function from the **Toolbox** in the lower-right corner.
{{}}
diff --git a/content/en/docs/pluggable-components/devops.md b/content/en/docs/pluggable-components/devops.md
index fd06550b4..f8fcc858c 100644
--- a/content/en/docs/pluggable-components/devops.md
+++ b/content/en/docs/pluggable-components/devops.md
@@ -12,7 +12,7 @@ The DevOps System offers an enabling environment for users as apps can be automa
For more information, see [DevOps User Guide](../../devops-user-guide/).
-## Enable DevOps before Installation
+## Enable DevOps Before Installation
### Installing on Linux
@@ -43,9 +43,9 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -61,14 +61,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable DevOps after Installation
+## Enable DevOps After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -78,9 +78,9 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{}}
-3. In **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+3. In **Custom Resources**, click on the right of `ks-installer` and select **Edit YAML**.
-4. In this YAML file, navigate to `devops` and change `false` to `true` for `enabled`. After you finish, click **Update** in the bottom-right corner to save the configuration.
+4. In this YAML file, navigate to `devops` and change `false` to `true` for `enabled`. After you finish, click **OK** in the lower-right corner to save the configuration.
```yaml
devops:
@@ -95,7 +95,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
@@ -105,9 +105,7 @@ You can find the web kubectl tool by clicking }}
-Go to **Components** and check the status of **DevOps**. You may see an image as follows:
-
-
+Go to **System Components** and check that all components on the **DevOps** tab page is in **Healthy** state.
{{}}
@@ -123,7 +121,7 @@ The output may look as follows if the component runs successfully:
```bash
NAME READY STATUS RESTARTS AGE
-ks-jenkins-5cbbfbb975-hjnll 1/1 Running 0 40m
+devops-jenkins-5cbbfbb975-hjnll 1/1 Running 0 40m
s2ioperator-0 1/1 Running 0 41m
```
diff --git a/content/en/docs/pluggable-components/events.md b/content/en/docs/pluggable-components/events.md
index edff6744d..ce7927b25 100644
--- a/content/en/docs/pluggable-components/events.md
+++ b/content/en/docs/pluggable-components/events.md
@@ -6,11 +6,11 @@ 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.
+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
+## Enable Events Before Installation
### Installing on Linux
@@ -36,7 +36,7 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
```
{{< 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 `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information before installation, KubeKey will integrate your external Elasticsearch directly instead of installing an internal one.
+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
@@ -47,7 +47,7 @@ By default, KubeKey will install Elasticsearch internally if Events is enabled.
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**.
+3. In **Custom Resources**, click 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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -121,7 +121,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< 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 `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
+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
@@ -132,7 +132,7 @@ By default, Elasticsearch will be installed internally if Events is enabled. For
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 bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
@@ -154,9 +154,7 @@ You can find the web kubectl tool by clicking }}
-Verify that you can use the **Event Search** function from the **Toolbox** in the bottom-right corner.
-
-
+Verify that you can use the **Resource Event Search** function from the **Toolbox** in the lower-right corner.
{{}}
diff --git a/content/en/docs/pluggable-components/kubeedge.md b/content/en/docs/pluggable-components/kubeedge.md
index 66523b07e..368263895 100644
--- a/content/en/docs/pluggable-components/kubeedge.md
+++ b/content/en/docs/pluggable-components/kubeedge.md
@@ -14,7 +14,7 @@ After you enable KubeEdge, you can [add edge nodes to your cluster](../../instal
-## Enable KubeEdge before Installation
+## Enable KubeEdge Before Installation
### Installing on Linux
@@ -47,9 +47,9 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -67,14 +67,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable KubeEdge after Installation
+## Enable KubeEdge After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -82,7 +82,7 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+3. In **Custom Resources**, click on the right of `ks-installer` and select **Edit YAML**.
4. In this YAML file, navigate to `kubeedge.enabled` and enable it by setting it to `true`.
@@ -91,13 +91,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
enabled: true # Change "false" to "true".
```
-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 **Update** in the bottom-right corner to save the configuration.
-
- {{< notice note >}}
-
-The `kubeedge` section is not included in `cluster-configuration.yaml` if your cluster is upgraded from KubeSphere v3.0.0. For more information, see [how to enable KubeEdge after upgrade](#enable-kubeedge-after-upgrade).
-
- {{}}
+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:
@@ -107,57 +101,16 @@ The `kubeedge` section is not included in `cluster-configuration.yaml` if your c
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
-## Enable KubeEdge after Upgrade
-
-If your KubeSphere v3.1.0 cluster is upgraded from KubeSphere v3.0.0, add the following content in `cluster-configuration.yaml` (i.e. the `clusterconfiguration` CRD) and enable `kubeedge` as shown [in the steps above](#enable-kubeedge-after-installation).
-
-```yaml
- kubeedge:
- enabled: false
- cloudCore:
- nodeSelector: {"node-role.kubernetes.io/worker": ""}
- tolerations: []
- cloudhubPort: "10000"
- cloudhubQuicPort: "10001"
- cloudhubHttpsPort: "10002"
- cloudstreamPort: "10003"
- tunnelPort: "10004"
- cloudHub:
- advertiseAddress:
- - ""
- nodeLimit: "100"
- service:
- cloudhubNodePort: "30000"
- cloudhubQuicNodePort: "30001"
- cloudhubHttpsNodePort: "30002"
- cloudstreamNodePort: "30003"
- tunnelNodePort: "30004"
- edgeWatcher:
- nodeSelector: {"node-role.kubernetes.io/worker": ""}
- tolerations: []
- edgeWatcherAgent:
- nodeSelector: {"node-role.kubernetes.io/worker": ""}
- tolerations: []
-```
-
-{{< notice warning >}}
-
-Do not add the `kubeedge` section in `cluster-configuration.yaml` before the upgrade.
-
-{{}}
-
## Verify the Installation of the Component
{{< tabs >}}
{{< tab "Verify the component on the dashboard" >}}
-On the **Cluster Management** page, verify that the section **Edge Nodes** has appeared under **Node Management**.
-
-
+On the **Cluster Management** page, verify that the **Edge Nodes** module has appeared under **Nodes**.
{{}}
diff --git a/content/en/docs/pluggable-components/logging.md b/content/en/docs/pluggable-components/logging.md
index 4de1186de..cc90148e7 100644
--- a/content/en/docs/pluggable-components/logging.md
+++ b/content/en/docs/pluggable-components/logging.md
@@ -6,11 +6,11 @@ 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.
+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
+## Enable Logging Before Installation
### Installing on Linux
@@ -35,10 +35,14 @@ When you install KubeSphere on Linux, you need to create a configuration file, w
```yaml
logging:
enabled: true # Change "false" to "true".
+ containerruntime: docker
```
- {{< 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 `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information before installation, KubeKey will integrate your external Elasticsearch directly instead of installing an internal one.
+ {{< notice info >}}To use containerd as the container runtime, change the value of the field `containerruntime` to `containerd`. If you upgraded to KubeSphere 3.2.1 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
@@ -49,7 +53,7 @@ By default, KubeKey will install Elasticsearch internally if Logging is enabled.
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**.
+3. In **Custom Resources**, click 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 **Update** in the bottom-right corner to save the configuration.
+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 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 `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information, KubeSphere will integrate your external Elasticsearch directly instead of installing an internal one.
-
+ {{< 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.2.1 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.
@@ -133,7 +145,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
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 bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
@@ -155,9 +167,7 @@ You can find the web kubectl tool by clicking }}
-Go to **Components** and check the status of **Logging**. You may see an image as follows:
-
-
+Go to **System Components** and check that all components on the **Logging** tab page is in **Healthy** state.
{{}}
diff --git a/content/en/docs/pluggable-components/metrics-server.md b/content/en/docs/pluggable-components/metrics-server.md
index 63bfdfbf3..8a54187e4 100644
--- a/content/en/docs/pluggable-components/metrics-server.md
+++ b/content/en/docs/pluggable-components/metrics-server.md
@@ -8,7 +8,7 @@ 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
+## Enable the Metrics Server Before Installation
### Installing on Linux
@@ -39,9 +39,9 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -57,7 +57,7 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
@@ -67,9 +67,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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
+## Enable the Metrics Server After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -77,9 +77,9 @@ If you install KubeSphere on some cloud hosted Kubernetes engines, it is probabl
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -94,7 +94,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
## Verify the Installation of the Component
diff --git a/content/en/docs/pluggable-components/network-policy.md b/content/en/docs/pluggable-components/network-policy.md
index 21ca33e7c..4843e1efe 100644
--- a/content/en/docs/pluggable-components/network-policy.md
+++ b/content/en/docs/pluggable-components/network-policy.md
@@ -10,14 +10,14 @@ Starting from v3.0.0, users can configure network policies of native Kubernetes
{{< 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.
+- 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
+## Enable the Network Policy Before Installation
### Installing on Linux
@@ -49,9 +49,9 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -68,14 +68,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable the Network Policy after Installation
+## Enable the Network Policy After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -83,9 +83,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -101,11 +101,9 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+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 **Network Policies** in **Network** as the image below, it means the installation succeeds as this part won't display until you install the component.
-
-
\ No newline at end of file
+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/pluggable-components/pod-ip-pools.md b/content/en/docs/pluggable-components/pod-ip-pools.md
index 995630db7..195278fd5 100644
--- a/content/en/docs/pluggable-components/pod-ip-pools.md
+++ b/content/en/docs/pluggable-components/pod-ip-pools.md
@@ -1,14 +1,14 @@
---
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."
+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.
+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
+## Enable Pod IP Pools Before Installation
### Installing on Linux
@@ -21,7 +21,7 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
```
{{< 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.
+ 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.
@@ -40,9 +40,9 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -59,15 +59,15 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable Pod IP Pools after Installation
+## Enable Pod IP Pools After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -75,9 +75,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -93,14 +93,12 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+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 section **Pod IP Pools** under **Network**.
-
-
+On the **Cluster Management** page, verify that you can see the **Pod IP Pools** module under **Network**.
diff --git a/content/en/docs/pluggable-components/service-mesh.md b/content/en/docs/pluggable-components/service-mesh.md
index 29f2df4d8..364909eaa 100644
--- a/content/en/docs/pluggable-components/service-mesh.md
+++ b/content/en/docs/pluggable-components/service-mesh.md
@@ -6,11 +6,11 @@ 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, distributed tracing, observability and traffic control**. Developers can easily get started with KubeSphere Service Mesh without any code hacking, with the learning curve of Istio greatly reduced. All features of KubeSphere Service Mesh are designed to meet users' demand for their business.
+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, with the learning curve of Istio greatly reduced. 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
+## Enable KubeSphere Service Mesh Before Installation
### Installing on Linux
@@ -41,9 +41,9 @@ If you adopt [All-in-One Installation](../../quick-start/all-in-one-on-linux/),
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -59,14 +59,14 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable KubeSphere Service Mesh after Installation
+## Enable KubeSphere Service Mesh After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -74,9 +74,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -91,7 +91,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
## Verify the Installation of the Component
@@ -100,9 +100,7 @@ You can find the web kubectl tool by clicking }}
-Go to **Components** and check the status of **Istio**. You may see an image as follows:
-
-
+Go to **System Components** and check that all components on the **Istio** tab page is in **Healthy** state.
{{}}
diff --git a/content/en/docs/pluggable-components/service-topology.md b/content/en/docs/pluggable-components/service-topology.md
index aa1c9b1dc..db636cfa6 100644
--- a/content/en/docs/pluggable-components/service-topology.md
+++ b/content/en/docs/pluggable-components/service-topology.md
@@ -8,7 +8,7 @@ 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
+## Enable Service Topology Before Installation
### Installing on Linux
@@ -40,9 +40,9 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
### 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.1.1/cluster-configuration.yaml) file.
+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.2.1/cluster-configuration.yaml) file.
-1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml) and edit it.
+1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml) and edit it.
```bash
vi cluster-configuration.yaml
@@ -59,15 +59,15 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
3. Execute the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
kubectl apply -f cluster-configuration.yaml
```
-## Enable Service Topology after Installation
+## Enable Service Topology After Installation
-1. Log in to the console as `admin`. Click **Platform** in the top-left corner and select **Cluster Management**.
+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.
@@ -75,9 +75,9 @@ As you [install KubeSphere on Kubernetes](../../installing-on-kubernetes/introdu
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 **Resource List**, click 
on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** in the bottom-right corner to save the configuration.
+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:
@@ -93,7 +93,7 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
{{< notice note >}}
-You can find the web kubectl tool by clicking 
in the bottom-right corner of the console.
+You can find the web kubectl tool by clicking in the lower-right corner of the console.
{{}}
## Verify the Installation of the Component
@@ -102,9 +102,7 @@ You can find the web kubectl tool by clicking }}
-Go to one of your project, navigate to **Services** under **Application Workloads**, and you can see a topology of your **Services** on the **Topology** tab.
-
-
+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.
{{}}
diff --git a/content/en/docs/pluggable-components/uninstall-pluggable-components.md b/content/en/docs/pluggable-components/uninstall-pluggable-components.md
index caa23e46e..3226d27a2 100644
--- a/content/en/docs/pluggable-components/uninstall-pluggable-components.md
+++ b/content/en/docs/pluggable-components/uninstall-pluggable-components.md
@@ -1,8 +1,8 @@
---
-title: "Uninstall Pluggable Components from KubeSphere v3.1.x"
+title: "Uninstall Pluggable Components from KubeSphere 3.2.x"
keywords: "Installer, uninstall, KubeSphere, Kubernetes"
-description: "Learn how to uninstall each pluggable component in KubeSphere v3.1.x."
-linkTitle: "Uninstall Pluggable Components from KubeSphere v3.1.x"
+description: "Learn how to uninstall each pluggable component in KubeSphere 3.2.x."
+linkTitle: "Uninstall Pluggable Components from KubeSphere 3.2.x"
Weight: 6940
---
@@ -10,7 +10,7 @@ After you [enable the pluggable components of KubeSphere](../../pluggable-compon
{{< notice note >}}
-The methods of uninstalling certain pluggable components on KubeSphere v3.1.x are different from the methods on KubeSphere v3.0.0. For more information about the uninstallation methods on KubeSphere v3.0.0, see [Uninstall Pluggable Components from KubeSphere](https://v3-0.docs.kubesphere.io/docs/faq/installation/uninstall-pluggable-components/).
+The methods of uninstalling certain pluggable components on KubeSphere 3.2.x are different from the methods on KubeSphere v3.0.0. For more information about the uninstallation methods on KubeSphere v3.0.0, see [Uninstall Pluggable Components from KubeSphere](https://v3-0.docs.kubesphere.io/docs/faq/installation/uninstall-pluggable-components/).
{{}}
@@ -40,55 +40,30 @@ Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-ins
## Uninstall KubeSphere DevOps
-1. Change the value of `devops.enabled` from `true` to `false` in `ks-installer` of the CRD `ClusterConfiguration`.
-
-2. Run the command mentioned in [Prerequisites](#prerequisites) and then delete the code under `status.devops` in `ks-installer` of the CRD `ClusterConfiguration`.
-
-3. Run the following commands:
+1. To uninstall DevOps:
```bash
- helm -n kubesphere-devops-system delete ks-jenkins
- helm -n kubesphere-devops-system delete uc
+ 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
- # Delete DevOps projects
- for devopsproject in `kubectl get devopsprojects -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch devopsprojects $devopsproject -p '{"metadata":{"finalizers":null}}' --type=merge
+ # 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
-
- for pip in `kubectl get pipeline -A -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch pipeline $pip -n `kubectl get pipeline -A | grep $pip | awk '{print $1}'` -p '{"metadata":{"finalizers":null}}' --type=merge
- done
-
- for s2ibinaries in `kubectl get s2ibinaries -A -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch s2ibinaries $s2ibinaries -n `kubectl get s2ibinaries -A | grep $s2ibinaries | awk '{print $1}'` -p '{"metadata":{"finalizers":null}}' --type=merge
- done
-
- for s2ibuilders in `kubectl get s2ibuilders -A -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch s2ibuilders $s2ibuilders -n `kubectl get s2ibuilders -A | grep $s2ibuilders | awk '{print $1}'` -p '{"metadata":{"finalizers":null}}' --type=merge
- done
-
- for s2ibuildertemplates in `kubectl get s2ibuildertemplates -A -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch s2ibuildertemplates $s2ibuildertemplates -n `kubectl get s2ibuildertemplates -A | grep $s2ibuildertemplates | awk '{print $1}'` -p '{"metadata":{"finalizers":null}}' --type=merge
- done
-
- for s2iruns in `kubectl get s2iruns -A -o jsonpath="{.items[*].metadata.name}"`
- do
- kubectl patch s2iruns $s2iruns -n `kubectl get s2iruns -A | grep $s2iruns | awk '{print $1}'` -p '{"metadata":{"finalizers":null}}' --type=merge
- done
-
- kubectl delete devopsprojects --all 2>/dev/null
+ # 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
```
- ```bash
- kubectl delete ns kubesphere-devops-system
- ```
## Uninstall KubeSphere Logging
@@ -97,7 +72,7 @@ Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-ins
2. To disable only log collection:
```bash
- delete inputs.logging.kubesphere.io -n kubesphere-logging-system tail
+ kubectl delete inputs.logging.kubesphere.io -n kubesphere-logging-system tail
```
{{< notice note >}}
@@ -118,11 +93,18 @@ Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-ins
helm uninstall elasticsearch-logging --namespace kubesphere-logging-system
```
- {{< notice note >}}
+ {{< 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
@@ -146,7 +128,7 @@ Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-ins
{{< notice note >}}
- Notification is installed in KubeSphere v3.1.x by default, so you do not need to uninstall it.
+ Notification is installed in KubeSphere 3.2.1 by default, so you do not need to uninstall it.
{{}}
@@ -159,8 +141,8 @@ Change the value of `openpitrix.store.enabled` from `true` to `false` in `ks-ins
```bash
helm uninstall kube-auditing -n kubesphere-logging-system
- kubectl delete crd awh
- kubectl delete crd ar
+ kubectl delete crd rules.auditing.kubesphere.io
+ kubectl delete crd webhooks.auditing.kubesphere.io
```
## Uninstall KubeSphere Service Mesh
diff --git a/content/en/docs/project-administration/container-limit-ranges.md b/content/en/docs/project-administration/container-limit-ranges.md
index 17a81120f..8fa82fa9d 100644
--- a/content/en/docs/project-administration/container-limit-ranges.md
+++ b/content/en/docs/project-administration/container-limit-ranges.md
@@ -14,16 +14,14 @@ This tutorial demonstrates how to set default limit ranges for containers in a p
## Prerequisites
-You have an available workspace, a project and an account (`project-admin`). The account must have the `admin` role at the project level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+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 **Set** next to **Resource Default Request Not Set** to configure 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.
@@ -34,18 +32,12 @@ You have an available workspace, a project and an account (`project-admin`). The
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 **Manage Project** on the **Basic Information** page and select **Edit Resource Default Request**.
+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/).
{{}}
diff --git a/content/en/docs/project-administration/disk-log-collection.md b/content/en/docs/project-administration/disk-log-collection.md
index b0b0549c4..0491061c5 100644
--- a/content/en/docs/project-administration/disk-log-collection.md
+++ b/content/en/docs/project-administration/disk-log-collection.md
@@ -1,26 +1,25 @@
---
-title: "Disk Log Collection"
+title: "Log Collection"
keywords: 'KubeSphere, Kubernetes, project, disk, log, collection'
-description: 'Enable disk log collection so that you can collect, manage, and analyze logs in a unified way.'
-linkTitle: "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 disk logs for an example app.
+This tutorial demonstrates how to collect logs for an example app.
## Prerequisites
-- You need to create a workspace, a project and an account (`project-admin`). The account must be invited to the project with the role of `admin` at the project level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+- 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 Disk Log Collection
+## 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, select **Advanced Settings** in **Project Settings**. Under **Disk Log Collection**, click 
to enable the feature.
-
+2. From the left navigation bar, click **Log Collection** in **Project Settings**, and then click to enable the feature.
## Create a Deployment
@@ -28,15 +27,13 @@ This tutorial demonstrates how to collect disk logs for an example app.
2. In the dialog that appears, set a name for the Deployment (for example, `demo-deployment`) and click **Next**.
-3. Under **Container Image**, click **Add Container Image**.
+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**.
-5. Scroll down to **Start Command** and select the checkbox. Enter the following values for **Run Command** and **Parameters** respectively, click **√**, and then click **Next**.
-
- **Run Command**
+ **Command**
```bash
/bin/sh
@@ -54,15 +51,11 @@ This tutorial demonstrates how to collect disk logs for an example app.
{{}}
- 
+6. On the **Volume Settings** tab, click 
to enable **Collect Logs on Volumes** and click **Mount Volume**.
-6. On the **Mount Volumes** tab, click to enable **Disk Log Collection** and click **Add 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.
-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. Refer to the image below as an example.
-
- 
-
- Click **√**, and then click **Next** to continue.
+ Click **√**, and then click **Next**.
8. Click **Create** in **Advanced Settings** to finish the process.
@@ -76,9 +69,7 @@ This tutorial demonstrates how to collect disk logs for an example app.
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 disk logs.
+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:
-
- 
+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/project-administration/project-and-multicluster-project.md b/content/en/docs/project-administration/project-and-multicluster-project.md
index d6ab0e1cf..f9ac50c35 100644
--- a/content/en/docs/project-administration/project-and-multicluster-project.md
+++ b/content/en/docs/project-administration/project-and-multicluster-project.md
@@ -14,7 +14,7 @@ This tutorial demonstrates how to manage projects and multi-cluster projects.
## Prerequisites
-- You need to create a workspace and an account (`project-admin`). The account must be invited to the workspace with the role of `workspace-self-provisioner`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../docs/quick-start/create-workspace-and-project/).
+- 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](../../../docs/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
@@ -25,34 +25,30 @@ This tutorial demonstrates how to manage projects and multi-cluster projects.
{{< notice note >}}
-- You can change the cluster where the project will be created on the **Cluster** drop-down list. The list is only visible after you enable the multi-cluster feature.
+- 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 Settings**, 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**.
+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 as shown below. You can click the project name to go to its **Overview** page.
-
- 
+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 Project** on the right.
+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 Project** from the drop-down menu. In the dialog that appears, enter the project name and click **OK** to confirm the deletion.
+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 >}}
+{{< notice warning >}}
A project cannot be recovered once deleted and resources in the project will be removed.
@@ -71,20 +67,19 @@ A project cannot be recovered once deleted and resources in the project will be
{{}}
-2. In the **Create Multi-cluster Project** window that appears, enter a project name and add an alias or description if necessary. Under **Cluster Settings**, select multiple clusters for your project by clicking **Add Cluster**, and click **OK**.
+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:
-3. A multi-cluster project created will display in the list as shown below. You can click the project name to go to its **Overview** page.
-
- 
+ - **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 Project** on the right.
+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.
@@ -93,7 +88,7 @@ The project name cannot be edited. If you want to change other information, see
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 >}}
+{{< 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/project-administration/project-gateway.md b/content/en/docs/project-administration/project-gateway.md
index 9b05e4402..d87c3bc94 100644
--- a/content/en/docs/project-administration/project-gateway.md
+++ b/content/en/docs/project-administration/project-gateway.md
@@ -8,38 +8,34 @@ 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 KubeSphere 3.0, a project gateway works independently for itself. In other words, every project has its own Ingress controller. In the next release, KubeSphere will provide a cluster-scope gateway in addition to the project-scope gateway, allowing all projects to share the same gateway.
+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 set a gateway in KubeSphere for the external access to Services and Routes.
+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 an account (`project-admin`). The account must be invited to the project with the role of `admin` at the project level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../docs/quick-start/create-workspace-and-project/).
+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](../../../docs/quick-start/create-workspace-and-project/).
-## Set a Gateway
+## 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, select **Advanced Settings** and click **Set 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. In the pop-up window, you can select two access modes for the gateway.
-
- 
+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 **Application Governance** on the **Set Gateway** page. You need to enable **Application Governance** 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. 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.
-4. After you select an access method, click **Save**.
+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`
@@ -63,10 +59,8 @@ When you create a [Route](../../project-user-guide/application-workloads/routes/
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 [PorterLB](https://github.com/kubesphere/porter) for load balancing.
+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/project-administration/project-network-isolation.md b/content/en/docs/project-administration/project-network-isolation.md
index 6806efea4..9624aef77 100644
--- a/content/en/docs/project-administration/project-network-isolation.md
+++ b/content/en/docs/project-administration/project-network-isolation.md
@@ -11,7 +11,7 @@ KubeSphere project network isolation lets project administrators enforce which n
## Prerequisites
- You have already enabled [Network Policies](../../pluggable-components/network-policy/).
-- You must have an available project and an account of the `admin` role (`project-admin`) at the project level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+- 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 >}}
@@ -23,9 +23,7 @@ For the implementation of the Network Policy, you can refer to [KubeSphere Netwo
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 **On**.
+2. To enable project network isolation, click **Enable**.
{{< notice note >}}
@@ -33,9 +31,8 @@ For the implementation of the Network Policy, you can refer to [KubeSphere Netwo
{{}}
-3. You can also disable network isolation on this page.
+3. You can also disable network isolation by toggling the **Enabled** button on this page.
- 
{{< notice note >}}
@@ -61,21 +58,15 @@ For more information about how to create workloads, see [Deployments](../../proj
#### Allow ingress traffic from workloads in a different project
-1. On the **Network Isolation** page of your current project, select **Cluster Internal Allowlist**.
+1. On the **Network Isolation** page of your current project, click **Internal Allowlist**.
-2. Click **Add Allowlist**.
+2. Click **Add Allowlist Entry**.
-3. Select **Ingress** under **Direction**.
+3. Select **Ingress** under **Traffic Direction**.
-4. Select the tab **Project** under **Type**.
+4. In **Project**, select the project `demo-project-2`.
-5. Select the project `demo-project-2`.
-
- 
-
-6. Click **OK** and you can see that the project is now in the allowlist.
-
- 
+5. Click **OK**, and then you can see that the project is now in the allowlist.
{{< notice note >}}
@@ -85,11 +76,11 @@ If the network is not accessible after you set the network policy, then you need
#### Allow egress traffic to Services in a different project
-1. On the **Network Isolation** page of your current project, select **Cluster Internal Allowlist**.
+1. On the **Network Isolation** page of your current project, click **Internal Allowlist**.
-2. Click **Add Allowlist**.
+2. Click **Add Allowlist Entry**.
-3. Select **Egress** under **Direction**.
+3. Select **Egress** under **Traffic Direction**.
4. Select the tab **Service** under **Type**.
@@ -97,11 +88,7 @@ If the network is not accessible after you set the network policy, then you need
6. Select the Service that is allowed to receive egress traffic. In this case, select `nginx`.
- 
-
-7. Click **OK** and you can see that the Service is now in the allowlist.
-
- 
+7. Click **OK**, and then you can see that the Service is now in the allowlist.
{{< notice note >}}
@@ -113,21 +100,17 @@ When creating a Service, you must make sure that the selectors of the Service ar
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 an client outside the cluster
+#### Allow ingress traffic from a client outside the cluster
-1. On the **Network Isolation** page of your current project, select **Cluster External IP Address** and click **Add Rule**.
+1. On the **Network Isolation** page of your current project, select **External Allowlist** and click **Add Allowlist Entry**.
-2. Select **Ingress** under **Direction**.
+2. Select **Ingress** under **Traffic Direction**.
-3. Enter `192.168.1.1/32` for **CIDR**.
+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 you can see that the rule has been added.
-
- 
+5. Click **OK**, and then you can see that the rule has been added.
{{< notice note >}}
@@ -139,19 +122,15 @@ Assume the IP address of an external client is `http://10.1.0.1:80`, then you ne
#### Allow egress traffic to Services outside the cluster
-1. On the **Network Isolation** page of your current project, select **Cluster External IP Address** and click **Add Rule**.
+1. On the **Network Isolation** page of your current project, select **External Allowlist** and click **Add Allowlist Entry**.
-2. Select **Egress** under **Direction**.
+2. Select **Egress** under **Traffic Direction**.
-3. Enter `10.1.0.1/32` for **CIDR**.
+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.
-
- 
+5. Click **OK**, and you can see that the rule has been added.
{{< notice note >}}
@@ -171,9 +150,9 @@ If egress traffic is controlled, you should have a clear plan of what projects,
## FAQs
-Q: Why can't the custom monitoring system of KubeSphere get data after I enabled network isolation?
+Q: Why cannot the custom monitoring system of KubeSphere get data after I enabled network isolation?
-A: After you enabled 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.
+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.
@@ -197,7 +176,7 @@ spec:
...
```
-Q: Why can't I access a Service even after setting a network policy through the Service?
+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`.
@@ -222,6 +201,6 @@ A: When you add a network policy and access the Service via the cluster IP addre
...
```
-Q: How do I determine the CIDR when I set the ingress rule?
+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/project-administration/role-and-member-management.md b/content/en/docs/project-administration/role-and-member-management.md
index afc6b8766..8f16a866c 100644
--- a/content/en/docs/project-administration/role-and-member-management.md
+++ b/content/en/docs/project-administration/role-and-member-management.md
@@ -17,7 +17,7 @@ This tutorial demonstrates how to manage roles and members in a project. At the
## Prerequisites
-At least one project has been created, such as `demo-project`. Besides, you need an account of the `admin` role (for example, `project-admin`) at the project level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+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
@@ -30,31 +30,29 @@ In **Project Roles**, there are three available built-in roles as shown below. B
vieweroperatoradmin
on the right.
- 
-
## Invite a New Member
-1. Navigate to **Project Members** under **Project Settings**, and click **Invite 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/project-user-guide/alerting/alerting-message.md b/content/en/docs/project-user-guide/alerting/alerting-message.md
index a67c9af87..507563542 100644
--- a/content/en/docs/project-user-guide/alerting/alerting-message.md
+++ b/content/en/docs/project-user-guide/alerting/alerting-message.md
@@ -11,18 +11,16 @@ Alerting messages record detailed information of alerts triggered based on the a
## Prerequisites
- You have enabled [KubeSphere Alerting](../../../pluggable-components/alerting/).
-- You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 navigate to **Alerting Messages** under **Monitoring & Alerting**.
+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 Messages** tab on the page that appears.
+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 Messages** tab, you can see alert severity, target resources, and alert time.
+3. On the **Alerting History** tab, you can see alert severity, monitoring targets, and activation time.
## View Notifications
diff --git a/content/en/docs/project-user-guide/alerting/alerting-policy.md b/content/en/docs/project-user-guide/alerting/alerting-policy.md
index eb3fa3e8f..163a5d3d5 100644
--- a/content/en/docs/project-user-guide/alerting/alerting-policy.md
+++ b/content/en/docs/project-user-guide/alerting/alerting-policy.md
@@ -12,28 +12,26 @@ KubeSphere provides alerting policies for nodes and workloads. This tutorial dem
- 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 an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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. Navigate to **Alerting Policies** under **Monitoring & Alerting**, then click **Create**.
+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 dialog that appears, provide the basic information as follows. Click **Next** to continue.
+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.
- - **Duration (Minutes)**. An alert will be firing when the conditions defined for an alerting policy are met at any given point in the time range.
+ - **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 **Alerting Rule** tab, you can use the rule template or create a custom rule. To use the template, fill in the following fields.
+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 Target**. 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 Rules**. 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.
-
- 
+ - **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 >}}
@@ -43,24 +41,20 @@ KubeSphere provides alerting policies for nodes and workloads. This tutorial dem
Click **Next** to continue.
-4. On the **Notification Settings** tab, enter the alert summary and message to be included in your notification, then click **Create**.
+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 will reach **Pending** first, then turn to **Firing** if conditions keep to be met in the given time range.
+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 **Update** on the **Notification Settings** page to save it.
-
- 
+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 messages. You can also see the rule expression which is based on the template you use when creating the 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 **Monitoring**, the **Alert Monitoring** chart shows the actual usage or amount of resources over time. **Notification Settings** displays the customized message you set in notifications.
-
-
\ No newline at end of file
+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/project-user-guide/application-workloads/container-image-settings.md b/content/en/docs/project-user-guide/application-workloads/container-image-settings.md
index 279f5d061..d844dcc98 100644
--- a/content/en/docs/project-user-guide/application-workloads/container-image-settings.md
+++ b/content/en/docs/project-user-guide/application-workloads/container-image-settings.md
@@ -1,40 +1,43 @@
---
-title: "Container Image Settings"
+title: "Pod Settings"
keywords: 'KubeSphere, Kubernetes, image, workload, setting, container'
-description: 'Learn different properties on the dashboard in detail as you set container images for your workload.'
-linkTitle: "Container Image Settings"
+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 container image. 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 **Container Image**.
+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 Mode** in the upper-right corner to see corresponding values in the manifest file (YAML format) of properties on the dashboard.
+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.
{{}}
-## Container Image
+## 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**:
-### Add Container Image
+- **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.
-After you click **Add Container Image**, you will see an image as below.
+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
-#### Image Search Bar
+Click **Add Container** to add a container.
-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 **Configurations**.
+#### 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 bar.
+Remember to press **Enter** on your keyboard after you enter an image name in the search box.
{{}}
@@ -48,7 +51,7 @@ The container name is automatically created by KubeSphere, which is indicated by
#### 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).
+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
@@ -57,11 +60,9 @@ The resource quota reserved by the container includes both CPU and memory resour
- 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 and memory, to prevent excessive resources from being occupied.
+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.
@@ -72,7 +73,9 @@ The CPU resource is measured in CPU units, or **Core** in KubeSphere. The memory
{{}}
-#### **Port/Service Settings**
+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**.
@@ -80,67 +83,55 @@ You need to set the access protocol for the container as well as port informatio
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.
-- **Use Local Image First (ifNotPresent)**: 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.
-- **Redownload Image (Always)**: It means that the image is pulled whenever the pod starts.
-
-- **Only Use Local Image (Never)**: It means that the image is not pulled no matter the image exists or not.
+- **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 `IfNotPresent`, but the value of images tagged with `:latest` is `Always` by default.
+- 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 Checker**
+#### **Health Check**
-Support **Liveness**, **Readiness**, and **Startup**.
+Support liveness check, readiness check, and startup check.
-
+- **Liveness Check**: Liveness probes are used to know whether a container is running, indicated by `livenessProbe`.
-- **Container 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`.
-- **Container 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`.
-- **Container 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:
-Liveness, Readiness and Startup Check have all included 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:
-- **HTTPGetAction (HTTP Request Check)**: 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:
-
- 
-
- - **Scheme**: HTTP or HTTPS, specified by `scheme`.
- - **Path**: The path to access the HTTP server, specified by `path`.
- - **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 Delays**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
- - **Period Seconds**: 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.
+ - **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.
-- **TCPSocketAction (TCP Port Check)**: 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:
-
- 
+- **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 Delays**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
- - **Period Seconds**: The probe frequency (in seconds), specified by `periodSeconds`. It defaults to 10. The minimum value is 1.
+ - **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.
-- **ExecAction (Exec Command Check)**: 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**: 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 Delays**: The number of seconds after the container has started before liveness probes are initiated, specified by `initialDelaySeconds`. It defaults to 0.
- - **Period Seconds**: The probe frequency (in seconds), specified by `periodSeconds`. It defaults to 10. The minimum value is 1.
+ - **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.
@@ -149,11 +140,9 @@ Liveness, Readiness and Startup Check have all included the configurations below
#### **Start Command**
-By default, the container runs the default image command.
+By default, a container runs the default image command.
-
-
-- **Run Command** refers to the `command` field of containers in the manifest file.
+- **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/).
@@ -162,11 +151,9 @@ For more information about the command, please visit [Define a Command and Argum
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`.
-- type: The type of environment variables. It supports customization, configuration items, keys, and variable/variable references.
+- Click **Use ConfigMap or 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).
@@ -174,9 +161,7 @@ For more information about the command, please visit [Pod variable](https://kube
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/).
-
-
-#### **Sync Host Timezone**
+#### **Synchronize Host Timezone**
The time zone of the container will be consistent with that of the host after synchronization.
@@ -190,13 +175,13 @@ Update strategies are different for different workloads.
{{< tab "Deployments" >}}
-The `.spec.strategy` field specifies the strategy used to replace old Pods with new ones. `.spec.strategy.type` can be `Recreate` or `RollingUpdate`. `RollingUpdate` is the default value.
+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.
-- **RollingUpdate (Recommended)**
+- **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.
-- **Recreate**
+- **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.
@@ -208,11 +193,11 @@ For more information about update strategies, please visit [Strategy in Deployme
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:
-- **RollingUpdate (Recommended)**
+- **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.
-- **OnDelete**
+- **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.
@@ -224,11 +209,11 @@ For more information about update strategies, please visit [StatefulSet Update S
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:
-- **RollingUpdate (Recommended)**
+- **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.
-- **OnDelete**
+- **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.
@@ -238,31 +223,31 @@ For more information about update strategies, please visit [DaemonSet Update Str
{{}}
-### The Number of Pods When Updated
+### Rolling Update Settings
{{< tabs >}}
{{< tab "Deployments" >}}
-**The number of Pods when updated** in a Deployment is different from that of a StatefulSet.
+**Rolling Update Settings** in a Deployment is different from that of a StatefulSet.
-- **The maximum unavailable number of Pods**: The maximum number of Pods that can be unavailable during the update, specified by `maxUnavailable`. The default value is 25%.
-- **The maximum surge number of Pods**: The maximum number of Pods that can be scheduled above the desired number of Pods, specified by `maxSurge`. The default value is 25%.
+- **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" >}}
-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).
+**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" >}}
-**The number of Pods when updated** in a DaemonSet is different from that of a StatefulSet.
+**Rolling Update Settings** in a DaemonSet is different from that of a StatefulSet.
-- **The maximum unavailable number of Pods**: The maximum number of pods that can be unavailable during the update, specified by `maxUnavailable`. The default value is 20%.
-- **MinReadySeconds**: The minimum number of seconds before a newly created Pod of DaemonSet is treated as available, specified by `minReadySeconds`. The default value is 0.
+- **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.
{{}}
@@ -272,11 +257,12 @@ When you partition an update, all Pods with an ordinal greater than or equal to
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/).
-### Deployment Mode
+### 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 Mode** in the upper-right corner to see field details.
+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.
-- **Pod Decentralized Deployment** represents anti-affinity.
-- **Pod Aggregation Deployment** represents affinity.
+- **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/project-user-guide/application-workloads/cronjobs.md b/content/en/docs/project-user-guide/application-workloads/cronjobs.md
index 33bf2e289..0e7c0ba9a 100644
--- a/content/en/docs/project-user-guide/application-workloads/cronjobs.md
+++ b/content/en/docs/project-user-guide/application-workloads/cronjobs.md
@@ -1,7 +1,7 @@
---
title: "CronJobs"
-keywords: "KubeSphere, Kubernetes, jobs, cronjobs"
-description: "Learn basic concepts of CronJobs and how to create CronJobs in KubeSphere."
+keywords: "KubeSphere, Kubernetes, Jobs, CronJobs"
+description: "Learn basic concepts of CronJobs and how to create CronJobs on KubeSphere."
linkTitle: "CronJobs"
weight: 10260
---
@@ -12,7 +12,7 @@ For more information, see [the official documentation of Kubernetes](https://kub
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
@@ -20,13 +20,9 @@ You need to create a workspace, a project and an account (`project-regular`). Th
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 image below for each field. When you finish, click **Next**.
-
-
+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.
@@ -39,45 +35,39 @@ Enter the basic information. You can refer to the image below for each field. Wh
| Every Week | `0 0 * * 0` |
| Every Month | `0 0 1 * *` |
-- **Advanced Settings (Execution Parameters)**:
+- **Advanced Settings**:
- - **staringDeadlineSeconds**. 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.
- - **successfulJobsHistoryLimit**. 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.
- - **failedJobsHistoryLimit**. 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.
- - **concurrencyPolicy**. Specified by `.spec.concurrencyPolicy`, it represents how to treat concurrent executions of a Job. Valid values are:
- - **Allow** (default): It allows CronJobs to run concurrently.
- - **Forbid**: It forbids concurrent runs, skipping the next run if the previous run hasn't finished yet.
- - **Replace**: It cancels currently running Job and replaces it with a new one.
+ - **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 Mode** in the top-right corner to see the YAML manifest of this CronJob.
+You can enable **Edit YAML** in the upper-right corner to see the YAML manifest of this CronJob.
{{}}
-### Step 3: ConJob settings (Optional)
+### Step 3: Strategy settings (Optional)
-Please refer to [Jobs](../jobs/#step-3-job-settings-optional).
+Please refer to [Jobs](../jobs/#step-3-strategy-settings-optional).
-### Step 4: Set an image
+### Step 4: Set a Pod
-1. Click **Add Container Image** in **Container Image**, enter `busybox` in the search bar, and press **Enter**.
-
- 
+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 [Container Image Settings](../container-image-settings/).
+- 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 **Mount Volumes** 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.
+- You can skip **Volume 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.
{{}}
@@ -85,51 +75,31 @@ Please refer to [Jobs](../jobs/#step-3-job-settings-optional).
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.
-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 **successfulJobsHistoryLimit** is set to 3.
-
- 
-
-3. Click any of them and you will be directed to the Job detail page.
-
- 
-
-4. In **Resource Status**, you can inspect the Pod status. Click 
on the right and check the container log as shown below, which displays the expected output.
-
- 
-
- 
+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 detail page, you can manage the CronJob after it is created.
+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/project-user-guide/application-workloads/daemonsets.md b/content/en/docs/project-user-guide/application-workloads/daemonsets.md
index c01b99063..0c3159e77 100644
--- a/content/en/docs/project-user-guide/application-workloads/daemonsets.md
+++ b/content/en/docs/project-user-guide/application-workloads/daemonsets.md
@@ -1,5 +1,5 @@
---
-title: "DaemonSets"
+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"
@@ -10,7 +10,7 @@ A DaemonSet manages groups of replicated Pods while it ensures that all (or some
For more information, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
-## Use DaemonSets
+## 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:
@@ -20,7 +20,7 @@ DaemonSets are very helpful in cases where you want to deploy ongoing background
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
@@ -28,44 +28,34 @@ You need to create a workspace, a project and an account (`project-regular`). Th
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`) and click **Next** to continue.
-
+### Step 3: Set a Pod
-### Step 3: Set an image
+1. Click **Add Container**.
-1. Click **Add Container Image**.
-
- 
-
-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 bar and press **Enter**.
-
- 
+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 bar.
-- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configurations**.
+- 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 Checker**, **Start Command**, **Environment Variables**, **Container Security Context** and **Sync Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Container Image Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the lower-right corner to continue.
+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 **RollingUpdate**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
+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 deployment mode. For more information, see [Deployment Mode](../container-image-settings/#deployment-mode).
+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.
@@ -73,8 +63,6 @@ Specify a name for the DaemonSet (for example, `demo-daemonset`) and click **Nex
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.
@@ -85,52 +73,40 @@ DaemonSets can't use a volume template, which is used by StatefulSets.
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 DaemonSet Details
+## Check Kubernetes DaemonSet Details
-### Detail page
+### Details page
-1. After a DaemonSet is created, it will be displayed in the list as below. You can click 
on the right and select the options from the menu to modify a DaemonSet.
+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**: View and edit the basic information.
+ - **Edit Information**: View and edit the basic information.
- **Edit YAML**: View, upload, download, or update the YAML file.
- - **Redeploy**: Redeploy the DaemonSet.
+ - **Re-create**: Re-create the DaemonSet.
- **Delete**: Delete the DaemonSet.
-2. Click the name of the DaemonSet and you can go to its detail page.
-
- 
+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.
- 
-
- - **Revision Rollback**: Select the revision to roll back.
- - **Edit Config Template**: Configure update strategies, containers and volumes.
+ - **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.
- - **Redeploy**: Redeploy this DaemonSet.
+ - **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.
- - **Pod detail**
-
- 
+ - **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 detail page by clicking the Pod name.
+ - You can view the Pod details page by clicking the Pod name.
### Revision records
@@ -140,17 +116,11 @@ After the resource template of workload is changed, a new log will be generated
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 time interval.
-
- 
+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.
@@ -160,11 +130,8 @@ Click the **Metadata** tab to view the labels and annotations of the DaemonSet.
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/project-user-guide/application-workloads/deployments.md b/content/en/docs/project-user-guide/application-workloads/deployments.md
index cb6d87893..cba033e6a 100644
--- a/content/en/docs/project-user-guide/application-workloads/deployments.md
+++ b/content/en/docs/project-user-guide/application-workloads/deployments.md
@@ -13,7 +13,7 @@ For more information, see the [official documentation of Kubernetes](https://kub
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
@@ -21,61 +21,47 @@ You need to create a workspace, a project and an account (`project-regular`). Th
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`) and click **Next** to continue.
-
-
-### Step 3: Set an image
+### 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 Mode** 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.
+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**.
-2. Click **Add Container Image**.
-
- 
-
-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 bar and press **Enter**.
-
- 
+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 bar.
-- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configurations**.
+- 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 menu. For more information, see [Image Pull Policy in Container Image Settings](../container-image-settings/#add-container-image).
+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 Checker**, **Start Command**, **Environment Variables**, **Container Security Context** and **Sync Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Container Image Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the lower-right corner to continue.
+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 **RollingUpdate**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
+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 deployment mode. For more information, see [Deployment Mode](../container-image-settings/#deployment-mode).
+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.
+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.
@@ -86,11 +72,9 @@ Deployments can't use a volume template, which is used by StatefulSets.
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**
-- **Set Node Scheduling Policy**
-
- You can allow Pod replicas to run on specified nodes. It is specified in the field `nodeSelector`.
+ Assign Pod replicas to run on specified nodes. It is specified in the field `nodeSelector`.
- **Add Metadata**
@@ -98,65 +82,49 @@ You can set a policy for node scheduling and add metadata in this section. When
## Check Deployment Details
-### Detail page
+### Details page
-1. After a Deployment is created, it will be displayed in the list as below. You can click 
on the right and select options from the menu to modify your Deployment.
+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**: View and edit the basic information.
+ - **Edit Information**: View and edit the basic information.
- **Edit YAML**: View, upload, download, or update the YAML file.
- - **Redeploy**: Redeploy the Deployment.
+ - **Re-create**: Re-create the Deployment.
- **Delete**: Delete the Deployment.
-2. Click the name of the Deployment and you can go to its detail page.
-
- 
+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.
- 
-
- - **Revision Rollback**: Select the revision to roll back.
- - **Horizontal Pod 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 Config Template**: Configure update strategies, containers and volumes.
+ - **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.
- - **Redeploy**: Redeploy this Deployment.
+ - **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.
- - **Pod detail**
-
- 
+ - **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 detail page by clicking the Pod name.
+ - 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.
-### Matadata
+### 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 time interval.
-
- 
+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.
@@ -166,10 +134,6 @@ Click the **Metadata** tab to view the labels and annotations of the Deployment.
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
+Click the **Events** tab to view the events of the Deployment.
\ No newline at end of file
diff --git a/content/en/docs/project-user-guide/application-workloads/horizontal-pod-autoscaling.md b/content/en/docs/project-user-guide/application-workloads/horizontal-pod-autoscaling.md
index bb9fe21d8..262e2587a 100755
--- a/content/en/docs/project-user-guide/application-workloads/horizontal-pod-autoscaling.md
+++ b/content/en/docs/project-user-guide/application-workloads/horizontal-pod-autoscaling.md
@@ -15,7 +15,7 @@ This document uses HPA based on CPU usage as an example. Operations for HPA base
## Prerequisites
- You need to [enable the Metrics Server](https://kubesphere.io/docs/pluggable-components/metrics-server/).
-- You need to create a workspace, a project and an account (for example, `project-regular`). `project-regular` must be invited to the project and assigned the `operator` role. For more information, see [Create Workspaces, Projects, Accounts and Roles](/docs/quick-start/create-workspace-and-project/).
+- 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/quick-start/create-workspace-and-project/).
## Create a Service
@@ -23,19 +23,11 @@ This document uses HPA based on CPU usage as an example. Operations for HPA base
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 Image**, set **Image** to `mirrorgooglecontainers/hpa-example` and click **Use Default Ports**.
-
- 
+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**.
@@ -46,28 +38,22 @@ This document uses HPA based on CPU usage as an example. Operations for HPA base
{{}}
- 
-
-7. Click **Next** on the **Mount Volumes** tab and click **Create** on the **Advanced Settings** tab.
+7. Click **Next** on the **Volume Settings** tab and click **Create** on the **Advanced Settings** tab.
## Configure Kubernetes HPA
-1. Choose **Deployments** in **Workloads** on the left navigation bar and click the HPA Deployment (for example, hpa-v1) on the right.
+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 choose **Horizontal Pod Autoscaling** from the drop-down list.
-
- 
+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**.
- * **CPU Target Utilization**: Target percentage of the average Pod CPU request.
- * **Memory Target Usage**: Target average Pod memory usage in MiB.
- * **Min Replicas Number**: Minimum number of Pods.
- * **Max Replicas Number**: Maximum number of Pods.
+ * **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, **CPU Target Utilization** is set to `60`, **Min Replicas Number** is set to `1`, and **Max Replicas Number** is set to `10`.
+ 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 >}}
@@ -75,49 +61,29 @@ This document uses HPA based on CPU usage as an example. Operations for HPA base
{{}}
- 
-
## 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. Choose **Workloads** in **Application Workloads** on the left navigation bar and click **Create** on the right.
-
- 
+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`.
-3. Click **Add Container Image** and set **Image** to `busybox`.
-
- 
-
-4. Scroll down in the dialog box, select **Start Command**, and set **Run 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.
-
- 
+2. Choose **Workloads** in **Application Workloads** on the left navigation bar, click 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 >}}
@@ -133,7 +99,6 @@ You can repeat steps in [Configure HPA](#configure-hpa) to edit the HPA configur
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 **Horizontal Pod Autoscaling** and choose **Cancel** from the drop-down list.
+2. Click on the right of **Autoscaling** and choose **Cancel** from the drop-down list.
- 
diff --git a/content/en/docs/project-user-guide/application-workloads/jobs.md b/content/en/docs/project-user-guide/application-workloads/jobs.md
index 195ce4d2c..b60d34657 100644
--- a/content/en/docs/project-user-guide/application-workloads/jobs.md
+++ b/content/en/docs/project-user-guide/application-workloads/jobs.md
@@ -1,7 +1,7 @@
---
title: "Jobs"
-keywords: "KubeSphere, Kubernetes, docker, jobs"
-description: "Learn basic concepts of Jobs and how to create Jobs in KubeSphere."
+keywords: "KubeSphere, Kubernetes, Docker, Jobs"
+description: "Learn basic concepts of Jobs and how to create Jobs on KubeSphere."
linkTitle: "Jobs"
weight: 10250
@@ -15,7 +15,7 @@ The following example demonstrates specific steps of creating a Job (computing
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
@@ -23,8 +23,6 @@ You need to create a workspace, a project and an account (`project-regular`). Th
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. Refer to the image below as an example.
@@ -33,34 +31,26 @@ Enter the basic information. Refer to the image below as an example.
- **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)
-### Step 3: Job settings (optional)
-
-You can set the values in this step as below or click **Next** to use the default values. Refer to the table below for detailed explanations of each field.
-
-
+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 |
| ----------------------- | ---------------------------- | ------------------------------------------------------------ |
-| Back off Limit | `spec.backoffLimit` | It specifies the number of retries before this Job is marked failed. It defaults to 6. |
-| Completions | `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/). |
-| Parallelism | `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/). |
-| Active Deadline Seconds | `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. |
+| 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 an image
+### Step 4: Set a Pod
-1. Select **Never** for **Restart Policy**. You can only specify **Never** or **OnFailure** for **Restart Policy** when the Job is not completed:
+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 **Never**, the Job creates a new Pod when the Pod fails, and the failed Pod does not disappear.
+ - 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 **OnFailure**, the Job will internally restart the container when the Pod fails, instead of creating a new Pod.
+ - 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 Image** which directs you to the **Add Container** page. Enter `perl` in the image search bar and press **Enter**.
-
- 
+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.
@@ -68,13 +58,11 @@ You can set the values in this step as below or click **Next** to use the defaul
perl,-Mbignum=bpi,-wle,print bpi(2000)
```
- 
-
- {{< notice note >}}For more information about setting images, see [Container Image Settings](../container-image-settings/).{{}}
+ {{< notice note >}}For more information about setting images, see [Pod Settings](../container-image-settings/).{{}}
### Step 5: Inspect the Job manifest (optional)
-1. Enable **Edit Mode** 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.
+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
@@ -113,36 +101,28 @@ You can set the values in this step as below or click **Next** to use the defaul
activeDeadlineSeconds: 300
```
-2. You can make adjustments in the manifest directly and click **Create** or disable the **Edit Mode** and get back to the **Create Job** page.
+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 **Mount Volumes** 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).{{}}
+ {{< notice note >}}You can skip **Volume 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 **Execution 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.
-
- 
+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, the reason of which displays under **Messages**.
+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 **Parallelism** was set to 2. Click 
on the right and check the container log as shown below, which displays the expected calculation result.
-
- 
-
- 
+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 detail page by clicking the Pod name.
+- You can view the Pod details page by clicking the Pod name.
{{}}
@@ -150,20 +130,16 @@ You can rerun the Job if it fails, the reason of which displays under **Messages
### Operations
-On the Job detail page, you can manage the Job after it is created.
+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 Job**: Rerun the Job, the Pod will restart, and a new execution record will be generated.
+- **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 **Execution Records** tab to view the execution records of the Job.
-
- 
+1. Click the **Job Records** tab to view the execution records of the Job.
2. Click 
to refresh the execution records.
@@ -171,24 +147,16 @@ On the Job detail page, you can manage the Job after it is created.
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.
-
-
\ No newline at end of file
diff --git a/content/en/docs/project-user-guide/application-workloads/routes.md b/content/en/docs/project-user-guide/application-workloads/routes.md
index a0be0cf08..7addb2bb5 100644
--- a/content/en/docs/project-user-guide/application-workloads/routes.md
+++ b/content/en/docs/project-user-guide/application-workloads/routes.md
@@ -11,7 +11,7 @@ A Route on KubeSphere is the same as an [Ingress](https://kubernetes.io/docs/con
## Prerequisites
-- You need to create a workspace, a project and two accounts (for example, `project-admin` and `project-regular`). In the project, the role of `project-admin` must be `admin` and that of `project-regular` must be `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](/docs/quick-start/create-workspace-and-project/).
+- 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/quick-start/create-workspace-and-project/).
- If the Route is to be accessed in HTTPS mode, you need to [create a Secret](/docs/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/project-user-guide/application-workloads/services/). This document uses a demo Service as an example, which returns the Pod name to external requests.
@@ -19,28 +19,16 @@ A Route on KubeSphere is the same as an [Ingress](https://kubernetes.io/docs/con
1. Log in to the KubeSphere web console as `project-admin` and go to your project.
-2. Choose **Advanced Settings** in **Project Settings** on the left navigation bar and click **Set Gateway** on the right.
+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 the access method has been set, you can click **Edit** and choose **Edit Gateway** to change the access method.
+ 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.
{{}}
- 
-
-3. In the displayed **Set Gateway** dialog box, set **Access Method** to **NodePort** or **LoadBalancer**, and click **Save**.
-
- {{< notice note >}}
-
- If **Access Method** 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
@@ -49,34 +37,26 @@ A Route on KubeSphere is the same as an [Ingress](https://kubernetes.io/docs/con
2. Choose **Routes** in **Application Workloads** on the left navigation bar and click **Create** on the right.
- 
-
-3. On the **Basic Info** tab, configure the basic information about the Route and click **Next**.
+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
-### Step 2: Configure Route rules
+1. On the **Routing Rules** tab, click **Add Routing Rule**.
-1. On the **Route Rules** tab, click **Add Route Rule**.
-
-2. Select a mode, configure Route rules, click **√**, and click **Next**.
+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**: View and edit the basic information.
+ - **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 Internet Access**: Edit the service Internet access method.
+ - **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 detail page.
-
- 
+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 detail page by clicking the Pod name.
+ - 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.
-
- 
+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
+Click the **Events** tab to view the events of the Service.
\ No newline at end of file
diff --git a/content/en/docs/project-user-guide/application-workloads/statefulsets.md b/content/en/docs/project-user-guide/application-workloads/statefulsets.md
index f270ca0a4..833c7f925 100644
--- a/content/en/docs/project-user-guide/application-workloads/statefulsets.md
+++ b/content/en/docs/project-user-guide/application-workloads/statefulsets.md
@@ -1,12 +1,12 @@
---
-title: "StatefulSets"
-keywords: 'KubeSphere, Kubernetes, StatefulSets, dashboard, service'
-description: 'Learn basic concepts of StatefulSets and how to create StatefulSets in KubeSphere.'
+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 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.
+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.
@@ -23,64 +23,52 @@ For more information, see the [official documentation of Kubernetes](https://kub
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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 StatefulSet
+## 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 tab **StatefulSets**.
-
-
+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`) and click **Next** to continue.
-
-
-### Step 3: Set an image
+### 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 Mode** 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.
+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 Image**.
+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 bar and press **Enter**.
-
- 
+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 bar.
-- If you want to use your private image repository, you should [create an Image Registry Secret](../../configuration/image-registry/) first in **Secrets** under **Configurations**.
+- 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**.
-5. Click **Use Default Ports** for **Service 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).
-6. 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).
+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.
-7. For other settings (**Health Checker**, **Start Command**, **Environment Variables**, **Container Security Context** and **Sync Host Timezone**), you can configure them on the dashboard as well. For more information, see detailed explanations of these properties in [Container Image Settings](../container-image-settings/#add-container-image). When you finish, click **√** in the bottom-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).
-8. Select an update strategy from the drop-down menu. It is recommended you choose **RollingUpdate**. For more information, see [Update Strategy](../container-image-settings/#update-strategy).
-
-9. Select a deployment mode. For more information, see [Deployment Mode](../container-image-settings/#deployment-mode).
+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.
@@ -88,63 +76,49 @@ You can see the StatefulSet manifest file in YAML format by enabling **Edit Mode
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 metadata in this section. When you finish, click **Create** to complete the whole process of creating a StatefulSet.
+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**
-- **Set Node Scheduling Policy**
-
- You can allow Pod replicas to run on specified nodes. It is specified in the field `nodeSelector`.
+ 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 StatefulSet Details
+## Check Kubernetes StatefulSet Details
-### Detail page
+### Details page
-1. After a StatefulSet is created, it will be displayed in the list as below. You can click 
on the right to select options from the menu to modify your StatefulSet.
+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**: View and edit the basic information.
- - **Edit YAMl**: View, upload, download, or update the YAML file.
- - **Redeploy**: Redeploy the 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 detail page.
-
- 
+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.
- 
-
- - **Revision Rollback**: Select the revision to roll back.
+ - **Roll Back**: Select the revision to roll back.
- **Edit Service**: Set the port to expose the container image and the service port.
- - **Edit Config Template**: Configure update strategies, containers and volumes.
+ - **Edit Settings**: Configure update strategies, containers and volumes.
- **Edit YAML**: View, upload, download, or update the YAML file.
- - **Redeploy**: Redeploy this StatefulSet.
+ - **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.
- - **Pod detail**
-
- 
+ - **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 detail page by clicking the Pod name.
+ - You can view the Pod details page by clicking the Pod name.
### Revision records
@@ -154,17 +128,11 @@ After the resource template of workload is changed, a new log will be generated
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 time interval.
-
- 
+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.
@@ -174,11 +142,7 @@ Click the **Metadata** tab to view the labels and annotations of the StatefulSet
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/project-user-guide/application/app-template.md b/content/en/docs/project-user-guide/application/app-template.md
index a7e879a7d..30958f0bc 100644
--- a/content/en/docs/project-user-guide/application/app-template.md
+++ b/content/en/docs/project-user-guide/application/app-template.md
@@ -1,28 +1,24 @@
---
title: "App Templates"
-keywords: 'Kubernetes, chart, Helm, KubeSphere, application, repository, template'
+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.
+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 is also known as the App Store in KubeSphere, 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 the App Store after it is approved. For more information, see [Application Lifecycle Management](../../../application-store/app-lifecycle-management/).
-
-
+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 display 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 **From workspace** in the list, which stores these individual apps uploaded as Helm charts.
+[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.
{{}}
diff --git a/content/en/docs/project-user-guide/application/compose-app.md b/content/en/docs/project-user-guide/application/compose-app.md
index 2037dd63c..b2564950e 100644
--- a/content/en/docs/project-user-guide/application/compose-app.md
+++ b/content/en/docs/project-user-guide/application/compose-app.md
@@ -6,32 +6,32 @@ 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 **Composing App**, which can be built through newly created Services or existing Services.
+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 account (`project-regular`) for this tutorial. The account needs to be invited to the project with the `operator` role. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 **Composing Apps** tab, click **Create Composing 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 **Components** page, you need to create microservices that compose the app. Click **Add Service** and select **Stateless Service**.
+3. On the **Services** 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 Mode** in the top-right corner to edit the YAML file.
+ 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 Image** under **Container Image** and enter `kubesphere/examples-bookinfo-productpage-v1:1.13.0` in the search bar to use the Docker Hub image.
+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 >}}
@@ -39,11 +39,11 @@ This tutorial demonstrates how to create a microservices-based app Bookinfo, whi
{{}}
-6. Click **Use Default Ports**. For more information about image settings, see [Container Image Settings](../../../project-user-guide/application-workloads/container-image-settings/). Click **√** in the bottom-right corner and **Next** to continue.
+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 **Mount Volumes** page, [add a volume](../../../project-user-guide/storage/volumes/) or click **Next** to continue.
+7. On the **Volume Settings** page, [add a volume](../../../project-user-guide/storage/volumes/) or click **Next** to continue.
-8. Click **Add** on the **Advanced Settings** page directly.
+8. Click **Create** on the **Advanced Settings** page.
9. Similarly, add the other three microservices for the app. Here is the image information:
@@ -55,13 +55,11 @@ This tutorial demonstrates how to create a microservices-based app Bookinfo, whi
10. When you finish adding microservices, click **Next**.
-11. On the **Internet Access** page, click **Add Route 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.
-
- 
+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 Route Rule** is not visible if the project gateway is not set.
+The button **Add Routing Rule** is not visible if the project gateway is not set.
{{}}
@@ -84,13 +82,9 @@ The button **Add Route Rule** is not visible if the project gateway is not set.
{{}}
-2. In **Composing Apps**, click the app you just created.
+2. In **Composed Apps**, click the app you just created.
-3. In **Application Components**, click **Click to visit** to access the app.
-
- 
-
- 
+3. In **Resource Status**, click **Access Service** under **Routes** to access the app.
{{< notice note >}}
@@ -100,7 +94,3 @@ The button **Add Route Rule** is not visible if the project gateway is not set.
4. Click **Normal user** and **Test user** respectively to see other **Services**.
- 
-
-
-
diff --git a/content/en/docs/project-user-guide/application/deploy-app-from-appstore.md b/content/en/docs/project-user-guide/application/deploy-app-from-appstore.md
index b6d9d0493..f131f373c 100644
--- a/content/en/docs/project-user-guide/application/deploy-app-from-appstore.md
+++ b/content/en/docs/project-user-guide/application/deploy-app-from-appstore.md
@@ -13,70 +13,48 @@ This tutorial demonstrates how to quickly deploy [NGINX](https://www.nginx.com/)
## Prerequisites
- You have enabled [OpenPitrix (App Store)](../../../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 invited to the project with the `operator` role. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 top-left corner.
+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 **Deploy New App**, and select **From App Store** to go to the App Store.
+ 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. Find NGINX and click **Deploy** on the **App Information** page.
-
- 
-
- 
+2. Search for NGINX, click it, and click **Install** on the **App Information** page. Make sure you click **Agree** in the displayed **App Deploy Agreement** dialog box.
3. Set a name and select an app version. Make sure NGINX is deployed in `demo-project` and click **Next**.
- 
-
-4. In **App Configurations**, specify the number of replicas to deploy for the app and enable Ingress based on your needs. When you finish, click **Deploy**.
-
- 
-
- 
+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 switch to see the app’s manifest in YAML format and edit its configurations.
+ 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** and click the service name of NGINX.
+1. Go to **Services** in the project `demo-project` and click the service name of NGINX.
- 
-
-2. On the Service detail page, click **More** and select **Edit Internet Access** from the drop-down menu.
-
- 
+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 **Service Ports**, you can see the port is exposed.
-
- 
+4. Under **Ports**, view the exposed port.
5. Access NGINX through `
on the right and select the operation below from the drop-down list.
+1. After a ConfigMap is created, it is displayed on the **ConfigMaps** page. You can click on the right and select the operation below from the drop-down list.
- - **Edit**: View and edit the basic information.
+ - **Edit Information**: View and edit the basic information.
- **Edit YAML**: View, upload, download, or update the YAML file.
- - **Modify Config**: Modify the key-value pair of the ConfigMap.
+ - **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 detail page. Under the tab **Detail**, you can see all the key-value pairs you have added for 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.
- - **Modify Config**: Modify the key-value pair of the ConfigMap.
+ - **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.
@@ -72,6 +68,4 @@ You can see the ConfigMap manifest file in YAML format by enabling **Edit Mode**
## 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 **Container Image** page, check **Environment Variables** and click **Use ConfigMap or Secret** to use a ConfigMap from the list.
-
-
\ No newline at end of file
+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 **Use ConfigMap or Secret** to use a ConfigMap from the list.
diff --git a/content/en/docs/project-user-guide/configuration/image-registry.md b/content/en/docs/project-user-guide/configuration/image-registry.md
index 6bb20dae8..1469cbf9c 100644
--- a/content/en/docs/project-user-guide/configuration/image-registry.md
+++ b/content/en/docs/project-user-guide/configuration/image-registry.md
@@ -1,18 +1,18 @@
---
title: "Image Registries"
keywords: 'KubeSphere, Kubernetes, docker, Secrets'
-description: 'Learn how to create an image registry in KubeSphere.'
+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 (i.e. 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.
+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 an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
@@ -20,9 +20,7 @@ When you create workloads, [Services](../../../project-user-guide/application-wo
### Step 1: Open the dashboard
-Log in to the web console of KubeSphere as `project-regular`. Go to **Configurations** of a project, choose **Secrets** and click **Create**.
-
-
+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
@@ -30,30 +28,24 @@ Specify a name for the Secret (for example, `demo-registry-secret`) and click **
{{< notice tip >}}
-You can see the Secret's manifest file in YAML format by enabling **Edit Mode** 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.
+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 **kubernetes.io/dockerconfigjson (Image Registry Secret)** for **Type**. To use images from your private registry as you create application workloads, you need to specify the following fields.
+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 will be 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).
+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
@@ -75,7 +67,7 @@ Select **kubernetes.io/dockerconfigjson (Image Registry Secret)** for **Type**.
- `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 docs](https://docs.docker.com/engine/reference/commandline/dockerd/#insecure-registries) for its syntax.
+ - `--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.
{{}}
@@ -89,9 +81,7 @@ Select **kubernetes.io/dockerconfigjson (Image Registry Secret)** for **Type**.
sudo systemctl restart docker
```
-3. Go back to the **Secret Settings** page and select **kubernetes.io/dockerconfigjson (Image Registry Secret)** for **Type**. Enter your Harbor IP address for **Registry Address** and enter the username and password.
-
- 
+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 >}}
@@ -99,7 +89,7 @@ Select **kubernetes.io/dockerconfigjson (Image Registry Secret)** for **Type**.
{{}}
-4. Click **Create**. Later, the Secret will be 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).
+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**
@@ -107,6 +97,4 @@ For the integration of the HTTPS-based Harbor registry, refer to [Harbor Documen
## 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 **Container Image** 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.
-
-
\ No newline at end of file
+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.
diff --git a/content/en/docs/project-user-guide/configuration/secrets.md b/content/en/docs/project-user-guide/configuration/secrets.md
index 23f5f2968..c2043b065 100644
--- a/content/en/docs/project-user-guide/configuration/secrets.md
+++ b/content/en/docs/project-user-guide/configuration/secrets.md
@@ -1,7 +1,7 @@
---
-title: "Secrets"
+title: "Kubernetes Secrets in KubeSphere"
keywords: 'KubeSphere, Kubernetes, Secrets'
-description: 'Learn how to create a Secret in KubeSphere.'
+description: 'Learn how to create a Secret on KubeSphere.'
linkTitle: "Secrets"
weight: 10410
---
@@ -16,15 +16,13 @@ This tutorial demonstrates how to create a Secret in KubeSphere.
## Prerequisites
-You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+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
+## Create a Kubernetes Secret
### Step 1: Open the dashboard
-Log in to the console as `project-regular`. Go to **Configurations** of a project, choose **Secrets** and click **Create**.
-
-
+Log in to the console as `project-regular`. Go to **Configuration** of a project, select **Secrets** and click **Create**.
### Step 2: Enter basic information
@@ -32,17 +30,13 @@ Specify a name for the Secret (for example, `demo-secret`) and click **Next** to
{{< notice tip >}}
-You can see the Secret's manifest file in YAML format by enabling **Edit Mode** 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.
+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 **Secret Settings**, you must choose a Secret type. In KubeSphere, you can create the following types of Secrets, indicated by the `type` field.
-
- 
+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 >}}
@@ -50,42 +44,28 @@ You can see the Secret's manifest file in YAML format by enabling **Edit Mode**
{{}}
- - **Opaque (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.
+ - **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.
- - **kubernetes.io/tis (TLS)**. 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.
- - **kubernetes.io/dockerconfigjson (Image Registry Secret)**. 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/).
+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.
- 
-
- - **kubernetes.io/basic-auth (Account Password Secret)**. 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`) as below to specify a Secret for MySQL.
-
- 
-
-3. Click **√** in the bottom-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).
+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 as below. You can click 
on the right and select the operation from the menu to modify it.
+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**: View and edit the basic information.
+ - **Edit Information**: View and edit the basic information.
- **Edit YAML**: View, upload, download, or update the YAML file.
- - **Edit Seret**: Modify the key-value pair of the Secret.
+ - **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 detail page. Under the tab **Detail**, you can see all the key-value pairs you have added for 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 >}}
@@ -95,23 +75,17 @@ As mentioned above, KubeSphere automatically converts the value of a key into it
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.
-## Use a Secret
+## 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 **Use ConfigMap or 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.
@@ -120,9 +94,9 @@ This section shows how to create Secrets from your Docker Hub account and GitHub
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 **Secret Settings** page, fill in the following fields and click **Validate** to verify whether the information provided is valid.
+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 **kubernetes.io/dockerconfigjson (Image Registry Secret)**.
+ **Type**: Select **Image registry information**.
**Registry Address**: Enter the Docker Hub registry address, such as `docker.io`.
@@ -130,22 +104,18 @@ This section shows how to create Secrets from your Docker Hub account and GitHub
**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 **Secret Settings** page, fill in the following fields.
+2. Set a name, such as `github-id`, and click **Next**. On the **Data Settings** page, fill in the following fields.
- **Type**: Select **kubernetes.io/basic-auth (Account Password Secret)**.
+ **Type**: Select **Username and password**.
**Username**: Enter your GitHub account.
**Password**: Enter your GitHub password.
- 
-
-3. Click **Create** to finish.
\ No newline at end of file
+3. Click **Create** to finish.
diff --git a/content/en/docs/project-user-guide/configuration/serviceaccounts.md b/content/en/docs/project-user-guide/configuration/serviceaccounts.md
index 2e9384367..d05ffb2a9 100644
--- a/content/en/docs/project-user-guide/configuration/serviceaccounts.md
+++ b/content/en/docs/project-user-guide/configuration/serviceaccounts.md
@@ -1,9 +1,48 @@
---
title: "Service Accounts"
-keywords: 'KubeSphere, Kubernetes, ServiceAccounts'
-description: 'Learn how to create Service Accounts in KubeSphere.'
+keywords: 'KubeSphere, Kubernetes, Service Accounts'
+description: 'Learn how to create service accounts on KubeSphere.'
linkTitle: "Service Accounts"
weight: 10440
---
-TBD
\ No newline at end of file
+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 need to create a workspace, a project, and a user (`project-regular`), and invite the user to the project and assign it the `operator` role. For more information, see [Create Workspaces, Projects, Users and Roles](../../../quick-start/create-workspace-and-project/).
+
+## Create Service Account
+
+### Step 1: Log in to KubeSphere
+
+1. Log in to the KubeSphere console as `project-regular`. Go to **Configuration** of a project and click **Service Accounts**. A service account named `default` is displayed on the **Service Accounts** page as it is automatically created when the project is created.
+
+ {{< notice note >}}
+
+ If no service account is specified when creating workloads in a project, the service account `default` in the same project is automatically assigned.
+
+ {{}}
+
+2. Click **Create**.
+
+### Step 2: Set a service account
+
+1. In the displayed dialog box, set the following parameters:
+ - **Name**: A unique identifier for the service account.
+ - **Alias**: An alias for the service account to help you better identify the service account.
+ - **Description**: A brief introduction of the service account.
+ - **Project Role**: Select 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) in a project.
+2. Click **Create** after you finish setting the parameters. The service account created is displayed on the **Service Accounts** page.
+
+## Service Account Details Page
+
+1. Click the service account created to go to its details page.
+2. Click **Edit Information** to edit its basic information, or click **More** to select an operation from the drop-down menu.
+ - **Edit YAML**: View, update, or download the YAML file.
+ - **Change Role**: Change the project role of the service account.
+ - **Delete**: Delete the service account and return to the previous page.
+3. On the **Resource Status** tab, details about the corresponding Secret and the kubeconfig of the service account are displayed.
+
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md b/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md
index 771ba3df4..5522caf7b 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-mysql.md
@@ -11,16 +11,16 @@ 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 will be deployed from the App Store.
-- You need to create a workspace, a project, and an account (`project-regular`) for this tutorial. The account needs to be invited to the project with the `operator` role. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../../quick-start/create-workspace-and-project/).
+- 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 top-left corner.
+1. Go to your project and click **App Store** in the upper-left corner.
-2. Click **MySQL** to go to its product detail page and click **Deploy** on the **App Information** tab.
+2. Click **MySQL** to go to its details page and click **Install** on the **App Information** tab.
{{< notice note >}}
@@ -28,25 +28,21 @@ MySQL is a built-in app in the KubeSphere App Store, which means it can be deplo
{{}}
-3. Under **Basic Information**, set an **App Name** and select an **App Version**. Select the project where the app will be deployed under **Deployment Location** and click **Next**.
+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 Configurations**, set a root password by uncommenting the `mysqlRootPassword` field and click **Deploy**.
-
- 
+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 product detail page, click **Deploy**.
+2. On the details page, click **Install**.
-3. Under **Basic Information**, set an **App Name** and select an **App Version**. Select the same project where MySQL is deployed under **Deployment Location** and click **Next**.
+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`.
@@ -54,27 +50,19 @@ You need to deploy MySQL Exporter in the same project on the same cluster. MySQL
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` as below. Note that your MySQL service may be created with **a different name**.
-
- 
-
- Click **Deploy**.
+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 dialog that appears, set a name for the dashboard (for example, `mysql-overview`) and select the MySQL template. Click **Next** to continue.
+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 top-right corner. A newly-created dashboard will appear on the **Custom Monitoring Dashboards** page.
-
- 
+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 >}}
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md b/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md
index aac17352b..42b44242a 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/examples/monitor-sample-web.md
@@ -11,7 +11,7 @@ This section walks you through monitoring a sample web application. The applicat
## 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, Accounts 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 an account `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`.
+- 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/).
@@ -33,23 +33,9 @@ Find the source code in the folder `helm` in [kubesphere/prometheus-example-app]
### Step 3: Upload the Helm chart
-1. Go to the workspace **Overview** page of `demo-workspace` and navigate to **App Templates**.
+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` as images below.
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
+2. Click **Create** and upload `prometheus-example-app-0.1.0.tgz`.
### Step 4: Deploy the sample web application
@@ -57,62 +43,30 @@ You need to deploy the sample web application into `test`. For demonstration pur
1. Click `prometheus-example-app`.
- 
-
-2. Expand the menu and click **Test Deployment**.
-
- 
-
- 
+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 **Deploy**.
-
- 
-
- 
+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** and click **Create**.
+1. Navigate to **Custom Monitoring Dashboards** and click **Create**.
- 
+2. Set a name (for example, `sample-web`) and click **Next**.
-2. Set a name (for example, `sample-web`) and click **Create**.
+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.
-3. Enter a title in the top-left corner (for example, `Sample Web Overview`).
+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**.
-4. Click the **plus icon** on the left column to create a text chart.
-
- 
-
-5. Type the PromQL expression `myapp_processed_ops_total` in the field **Monitoring Metrics** and give a chart name (for example, `Operation Count`). Click **√** in the bottom-right corner to continue.
-
- 
-
-6. Click **Add Monitoring Item** to create a line chart.
-
- 
-
- 
-
-7. Type the PromQL expression `irate(myapp_processed_ops_total[3m])` for **Monitoring Metrics** 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.
-
- 
+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.
-
- 
\ No newline at end of file
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/introduction.md b/content/en/docs/project-user-guide/custom-application-monitoring/introduction.md
index 1d305c8b0..3f9dfbd29 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/introduction.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/introduction.md
@@ -20,7 +20,7 @@ First of all, your application must expose Prometheus-formatted metrics. The Pro
#### 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.
+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.
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/overview.md b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/overview.md
index 775859df7..61f57b748 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/overview.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/overview.md
@@ -16,8 +16,6 @@ There are three available built-in templates for MySQL, Elasticsearch, and Redis
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**.
@@ -28,9 +26,7 @@ To start with a blank template, click **Next**.
### From a YAML file
-Turn on **Edit Mode** in the upper-right corner and then paste your dashboard YAML file.
-
-
+Turn on **Edit YAML** in the upper-right corner and then paste your dashboard YAML file.
## Dashboard Layout
@@ -40,25 +36,17 @@ The monitoring dashboard is composed of four parts. Global settings are on the t
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.
-
-
+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
@@ -68,8 +56,6 @@ You can modify an existing template by clicking **Edit Template** in the upper-r
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.
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/panel.md b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/panel.md
index 282221549..1dd9703d8 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/panel.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/panel.md
@@ -15,23 +15,20 @@ A text chart is preferable for displaying a single metric value. The editing win
- **Chart Name**: The name of the text chart.
- **Unit**: The metric data unit.
- **Decimal Places**: Accept an integer.
-- **Monitoring Metrics**: A list of available Prometheus metrics.
+- **Monitoring Metric**: Specify a monitoring metric from the drop-down list of available Prometheus metrics.
-
+## Graph Chart
-## Graph
+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.
-A graph 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.
-
-- **Graph Types**: Support line charts and stacked charts.
+- **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 Metrics**: A list of available Prometheus metrics.
+- **Monitoring Metric**: A list of available Prometheus metrics.
- **Unit**: The metric data unit.
- **Decimal Places**: Accept an integer.
-
-
\ No newline at end of file
diff --git a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/querying.md b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/querying.md
index ac11c4048..11e5a2ccc 100644
--- a/content/en/docs/project-user-guide/custom-application-monitoring/visualization/querying.md
+++ b/content/en/docs/project-user-guide/custom-application-monitoring/visualization/querying.md
@@ -6,7 +6,7 @@ linkTitle: "Querying"
weight: 10817
---
-In the query editor, you can enter PromQL expressions to process and fetch metrics. To learn how to write PromQL, read [Query Examples](https://prometheus.io/docs/prometheus/latest/querying/examples/).
+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/).
diff --git a/content/en/docs/project-user-guide/grayscale-release/blue-green-deployment.md b/content/en/docs/project-user-guide/grayscale-release/blue-green-deployment.md
index c053d42af..1eb06f097 100644
--- a/content/en/docs/project-user-guide/grayscale-release/blue-green-deployment.md
+++ b/content/en/docs/project-user-guide/grayscale-release/blue-green-deployment.md
@@ -1,7 +1,7 @@
---
-title: "Kubernetes Blue-green Deployment in Kubesphere"
-keywords: 'KubeSphere, Kubernetes, service mesh, istio, release, blue-green deployment'
-description: 'Learn how to release a blue-green deployment in KubeSphere.'
+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
---
@@ -15,41 +15,27 @@ The blue-green release provides a zero downtime deployment, which means the new
## Prerequisites
- You need to enable [KubeSphere Service Mesh](../../../pluggable-components/service-mesh/).
-- You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 **Categories**, click **Create Job** on the right of **Blue-green Deployment**.
+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 **Grayscale Release Components** 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**.
+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 **Grayscale Release Version** tab, add another version (e.g `v2`) as shown in the following figure 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**.
- {{< notice note >}}
+6. The blue-green deployment job created is displayed under the **Release Jobs** tab. Click it to view details.
- The image version is `v2` in the screenshot.
-
- {{}}
-
-5. On the **Policy Config** tab, to allow the app version `v2` to take over all the traffic, select **Take over all traffic** and click **Create**.
-
-6. The blue-green deployment job created is displayed under the tab **Job Status**. Click it to view details.
-
- 
-
-7. Wait for a while and you can see all the traffic go to the version `v2`:
-
- 
+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
@@ -59,7 +45,7 @@ The blue-green release provides a zero downtime deployment, which means the new
{{< 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 account `admin`.
+ - If you want to run the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
{{}}
@@ -83,7 +69,6 @@ The blue-green release provides a zero downtime deployment, which means the new
## 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 **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/project-user-guide/grayscale-release/canary-release.md b/content/en/docs/project-user-guide/grayscale-release/canary-release.md
index 53d2669b6..d87aa11d9 100644
--- a/content/en/docs/project-user-guide/grayscale-release/canary-release.md
+++ b/content/en/docs/project-user-guide/grayscale-release/canary-release.md
@@ -1,7 +1,7 @@
---
title: "Canary Release"
-keywords: 'KubeSphere, Kubernetes, canary release, istio, service mesh'
-description: 'Learn how to deploy a canary service in KubeSphere.'
+keywords: 'KubeSphere, Kubernetes, Canary Release, Istio, Service Mesh'
+description: 'Learn how to deploy a canary service on KubeSphere.'
linkTitle: "Canary Release"
weight: 10530
---
@@ -16,30 +16,20 @@ This method serves as an efficient way to test performance and reliability of a
- 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 an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 **Categories**, click **Create Job** on the right of **Canary Release**.
+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 **Grayscale Release Components** 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**.
+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 **Grayscale Release Version** tab, add another version of it (e.g `kubesphere/examples-bookinfo-reviews-v2:1.13.0`; change `v1` to `v2`) as shown in the image below 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**.
- 
-
- {{< notice note >}}
-
- The image version is `v2` in the screenshot.
-
- {{}}
-
-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 **Forward by traffic ratio** and drag the icon in 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**.
-
- 
+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
@@ -47,20 +37,12 @@ Now that you have two available app versions, access the app to verify the canar
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.
-2. The created canary release job is displayed under the tab **Job Status**. Click it to view details.
-
- 
-
-3. You can see half of the traffic goes to each of them:
-
- 
+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
@@ -70,7 +52,7 @@ Now that you have two available app versions, access the app to verify the canar
{{< 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 account `admin`.
+ - If you want to execute the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
{{}}
@@ -110,40 +92,29 @@ Now that you have two available app versions, access the app to verify the canar
Make sure you replace the hostname and port number in the above command with your own.
{{}}
-2. In **Traffic Management**, you can see communications, dependency, health and performance among different microservices.
+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**.
-
- 
+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 clearly see all phases and internal calls of requests, as well as the period in each phase.
-
- 
+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 **Grayscale Release**, click the canary release job.
+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/project-user-guide/grayscale-release/traffic-mirroring.md b/content/en/docs/project-user-guide/grayscale-release/traffic-mirroring.md
index 61f341e94..7d7568fd4 100644
--- a/content/en/docs/project-user-guide/grayscale-release/traffic-mirroring.md
+++ b/content/en/docs/project-user-guide/grayscale-release/traffic-mirroring.md
@@ -1,7 +1,7 @@
---
title: "Traffic Mirroring"
-keywords: 'KubeSphere, Kubernetes, traffic mirroring, istio'
-description: 'Learn how to conduct a traffic mirroring job in KubeSphere.'
+keywords: 'KubeSphere, Kubernetes, Traffic Mirroring, Istio'
+description: 'Learn how to conduct a traffic mirroring job on KubeSphere.'
linkTitle: "Traffic Mirroring"
weight: 10540
---
@@ -11,41 +11,27 @@ Traffic mirroring, also called shadowing, is a powerful, risk-free method of tes
## Prerequisites
- You need to enable [KubeSphere Service Mesh](../../../pluggable-components/service-mesh/).
-- You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 **Categories**, click **Create Job** on the right of **Traffic Mirroring**.
+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 **Grayscale Release Components** 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**.
+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 **Grayscale Release Version** tab, add another version of it (for example, `v2`) as shown in the image below 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**.
- {{< notice note >}}
-
- The image version is `v2` in the screenshot.
-
- {{}}
-
-5. On the **Policy Config** tab, click **Create**.
-
-6. The traffic mirroring job created is displayed under the tab **Job Status**. Click it to view details.
-
- 
+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
@@ -55,7 +41,7 @@ Traffic mirroring, also called shadowing, is a powerful, risk-free method of tes
{{< 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 account `admin`.
+ - If you want to run the command from the web kubectl on the KubeSphere console, you need to use the user `admin`.
{{}}
@@ -92,6 +78,4 @@ These requests are mirrored as “fire and forget”, which means that the respo
## Take a Job Offline
-You can remove the traffic mirroring job by clicking **Job offline**, which does not affect the current app version.
-
-
\ No newline at end of file
+You can remove the traffic mirroring job by clicking **Delete**, which does not affect the current app version.
diff --git a/content/en/docs/project-user-guide/image-builder/binary-to-image.md b/content/en/docs/project-user-guide/image-builder/binary-to-image.md
index 31c2c39ab..5e5fd6a57 100644
--- a/content/en/docs/project-user-guide/image-builder/binary-to-image.md
+++ b/content/en/docs/project-user-guide/image-builder/binary-to-image.md
@@ -20,13 +20,13 @@ For demonstration and testing purposes, here are some example artifacts you can
| [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-java-sample](https://github.com/kubesphere/devops-java-sample) |
+| [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](http://www.dockerhub.com/) account. GitLab and Harbor are also supported.
-- You need to create a workspace, a project and an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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/set-ci-node/).
## Create a Service Using Binary-to-Image (B2I)
@@ -43,83 +43,52 @@ You must create a Docker Hub Secret so that the Docker image created through B2I
1. In the same project, navigate to **Services** under **Application Workloads** and click **Create**.
- 
-
-2. Scroll down to **Build a New Service through the 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**.
+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).
- **Upload Artifact**: Upload the war artifact ([b2i-war-java8](https://github.com/kubesphere/tutorial/raw/master/tutorial%204%20-%20s2i-b2i/b2i-war-java8.war)).
+ **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**.
- **imageName**: 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.
-2. Click this image to go to its detail page. Under **Job Records**, click 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 previous page, and you can see the corresponding Job, Deployment and Service of the image have all been created successfully.
-
- #### Service
-
- 
-
- #### Deployment
-
- 
-
- #### Job
-
- 
+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 detail page, where you can see the port number has been exposed.
-
- 
+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.
-2. Click this image to go to its detail page. Under **Job Records**, click 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 previous page, and you can see the corresponding Job of the image has been created successfully.
-
- 
+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/project-user-guide/image-builder/s2i-and-b2i-webhooks.md b/content/en/docs/project-user-guide/image-builder/s2i-and-b2i-webhooks.md
index d161a3b94..3b89fba20 100644
--- a/content/en/docs/project-user-guide/image-builder/s2i-and-b2i-webhooks.md
+++ b/content/en/docs/project-user-guide/image-builder/s2i-and-b2i-webhooks.md
@@ -6,33 +6,27 @@ 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, 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.
+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 an account (`project-regular`). The account must be invited to the project with the role of `operator`. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../../quick-start/create-workspace-and-project/).
+- 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 top-left corner and then select **Cluster Management**.
+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 detail page.
+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**.
-3. Click **More** and select **Edit Internet Access**.
-
- 
-
-4. In the window that appears, select **NodePort** from the drop-down list for **Access Method** and then click **OK**.
-
- 
+4. In the displayed dialog box, select **NodePort** from the drop-down list for **Access Method** and then click **OK**.
{{< notice note >}}
@@ -40,29 +34,19 @@ This tutorial demonstrates how to configure S2I and B2I webhooks.
{{}}
-5. You can view the **Node Port** on the detail page. It will be included in the S2I webhook URL.
-
- 
+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 Builder**, click the S2I Image Builder to go to its detail page.
+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 Link**. Copy `/s2itrigger/v1alpha1/general/namespaces/demo-project/s2ibuilders/felixnoo-s2i-sample-latest-zhd/` as it will be included in the S2I webhook URL.
-
- 
+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.
-2. Click this image to go to its detail page. Under **Job Records**, click 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 previous page, and you can see the corresponding Job, Deployment and Service of the image have been all created successfully.
-
- #### Service
-
- 
-
- #### Deployment
-
- 
-
- #### Job
-
- 
+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 detail page.
+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 `
to edit the role, edit the role permissions, or delete the role.
+5. On the **Platform Roles** page, you can click the name of the created role to view the role details and click 
to access the app.
+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.
diff --git a/content/en/docs/quick-start/enable-pluggable-components.md b/content/en/docs/quick-start/enable-pluggable-components.md
index 93f5de5fa..041a51d55 100644
--- a/content/en/docs/quick-start/enable-pluggable-components.md
+++ b/content/en/docs/quick-start/enable-pluggable-components.md
@@ -20,7 +20,7 @@ This tutorial demonstrates how to enable pluggable components of KubeSphere both
| `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. |
+| `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/).
@@ -32,7 +32,7 @@ For more information about each component, see [Overview of Enable Pluggable Com
{{}}
-## Enable Pluggable Components before Installation
+## 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.
@@ -50,7 +50,7 @@ When you implement multi-node installation of KubeSphere on Linux, you need to c
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-1.1/docs/config-example.md) for your reference. Save the file after you finish.
+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-1.2/docs/config-example.md) for your reference. Save the file after you finish.
3. Create a cluster using the configuration file:
@@ -73,16 +73,14 @@ When you install KubeSphere on Kubernetes, you need to use [ks-installer](https:
3. Save this local file and execute the following commands to start installation.
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/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 **Components**, and you can see an image below:
+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
+## 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.
@@ -100,9 +98,9 @@ If you need to enable [KubeEdge](../../pluggable-components/kubeedge/), [Pod IP
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 **Resource List**, click the three dots on the right of `ks-installer` and select **Edit YAML**.
+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 **Update** to save the configuration.
+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:
@@ -140,9 +138,7 @@ You can find the web kubectl tool by clicking the hammer icon in the bottom-righ
#####################################################
```
-7. In **Components**, you can see the status of different components.
-
- 
+7. In **System Components**, you can see the status of different components.
{{< notice tip >}}
diff --git a/content/en/docs/quick-start/minimal-kubesphere-on-k8s.md b/content/en/docs/quick-start/minimal-kubesphere-on-k8s.md
index 94e20b2d1..23de75e71 100644
--- a/content/en/docs/quick-start/minimal-kubesphere-on-k8s.md
+++ b/content/en/docs/quick-start/minimal-kubesphere-on-k8s.md
@@ -11,7 +11,7 @@ In addition to installing KubeSphere on a Linux machine, you can also deploy it
## Prerequisites
-- To install KubeSphere v3.1.1 on Kubernetes, your Kubernetes version must be v1.17.x, v1.18.x, v1.19.x or v1.20.x.
+- To install KubeSphere 3.2.1 on Kubernetes, your Kubernetes version must be v1.19.x, v1.20.x, v1.21.x or v1.22.x (experimental).
- 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.
@@ -33,9 +33,9 @@ After you make sure your machine meets the conditions, perform the following ste
1. Run the following commands to start installation:
```bash
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/kubesphere-installer.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/kubesphere-installer.yaml
- kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.1.1/cluster-configuration.yaml
+ kubectl apply -f https://github.com/kubesphere/ks-installer/releases/download/v3.2.1/cluster-configuration.yaml
```
2. After KubeSphere is successfully installed, you can run the following command to view the installation logs:
@@ -52,9 +52,7 @@ After you make sure your machine meets the conditions, perform the following ste
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 **Components**. You may need to wait for some components to be up and running if you want to use related services.
-
- 
+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)
diff --git a/content/en/docs/quick-start/wordpress-deployment.md b/content/en/docs/quick-start/wordpress-deployment.md
index ed8fa94e0..16c6e32fa 100644
--- a/content/en/docs/quick-start/wordpress-deployment.md
+++ b/content/en/docs/quick-start/wordpress-deployment.md
@@ -18,7 +18,7 @@ This tutorial demonstrates how to create an application (WordPress as an example
## 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, Accounts and Roles](../create-workspace-and-project/).
+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
@@ -32,31 +32,21 @@ About 15 minutes.
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 **Configurations**. In **Secrets**, click **Create** on the right.
+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 **Opaque (Default)** for **Type** and click **Add Data** to add a key-value pair. Enter the Key (`MYSQL_ROOT_PASSWORD`) and Value (`123456`) as below and click **√** in the bottom-right corner to confirm. When you finish, click **Create** to continue.
-
- 
+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 as below:
-
-
+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 volume
1. Go to **Volumes** under **Storage** and click **Create**.
- 
-
2. Enter the basic information of the volume (for example, name it `wordpress-pvc`) and click **Next**.
-3. In **Volume Settings**, you need to choose an available **Storage Class**, and set **Access Mode** and **Volume Capacity**. You can use the default value directly as shown below. Click **Next** to continue.
-
- 
+3. In **Volume 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.
@@ -64,31 +54,19 @@ Follow the same steps above to create a WordPress Secret `wordpress-secret` with
#### Add MySQL backend components
-1. Navigate to **Apps** under **Application Workloads**, select **Composing Apps** and click **Create Composing App**.
+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**.
-2. Enter the basic information (for example, `wordpress` for **App Name**) and click **Next**.
+3. In **Service Settings**, click **Create Service** to create a service in the app.
- 
-
-3. In **Components**, click **Add Service** to set a component in the app.
-
- 
-
-4. Define a service type for the component. Select **Stateful Service** here.
+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**.
-6. In **Container Image**, click **Add Container Image**.
-
- 
-
-7. Enter `mysql:5.6` in the search box, press **Enter** and click **Use Default Ports**. After that, do not click **√** in the bottom-right corner as the setting is not finished yet.
-
- 
+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 >}}
@@ -96,35 +74,21 @@ In **Advanced Settings**, make sure the memory limit is no less than 1000 Mi or
{{}}
-8. Scroll down to **Environment Variables** and click **Use ConfigMap or 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.
+1. Scroll down to **Environment Variables** and click **Use ConfigMap or 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.
- 
-
-9. Select **Add Volume Template** in **Mount Volumes**. Enter the value of **Volume Name** (`mysql`) and **Mount Path** (mode: `ReadAndWrite`, path: `/var/lib/mysql`) as below:
-
- 
+2. Click **Add Volume Template** under **Volume Templates**. Enter the value of **Volume Name** (`mysql`) and **Mount Path** (mode: `ReadAndWrite`, path: `/var/lib/mysql`).
Click **√** after you finish and click **Next** to continue.
-10. In **Advanced Settings**, you can click **Add** directly or select other options based on your needs.
-
- 
-
-11. The MySQL component has beed added as shown below:
-
- 
+3. In **Advanced Settings**, you can click **Create** directly or set other options based on your needs.
#### Add the WordPress frontend component
-12. Click **Add Service** again and select **Stateless Service** this time. Enter the name `wordpress` and click Next.
+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**.
-13. Similar to the step above, click **Add Container Image**, enter `wordpress:4.8-apache` in the search box, press **Enter** and click **Use Default Ports**.
-
- 
-
-14. Scroll down to **Environment Variables** and click **Use ConfigMap or Secret**. Two environment variables need to be added here. Enter the values according to the screenshot below.
+14. Scroll down to **Environment Variables** and click **Use ConfigMap or 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.
@@ -132,65 +96,37 @@ In **Advanced Settings**, make sure the memory limit is no less than 1000 Mi or
{{< notice warning >}}
-For the second environment variable added here, the value must be exactly the same as the name you set for MySQL in step 5. Otherwise, Wordpress cannot connect to the corresponding database of MySQL.
+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.
-15. In **Mount Volumes**, click **Add Volume** and select **Choose an existing volume**.
+1. Under **Volumes**, click **Mount Volume**, and then click **Select Volume**.
- 
+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.
-16. 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 **Next** to continue.
+4. The frontend component is also set now. Click **Next** to continue.
- 
+5. You can set route rules (Ingress) here or click **Create** directly.
-17. In **Advanced Settings**, you can click **Add** directly or select other options based on your needs.
-
- 
-
-18. The frontend component is also set now. Click **Next** to continue.
-
- 
-
-19. You can set route rules (Ingress) here or click **Create** directly.
-
- 
-
-20. The app will display in the list below after you create it.
-
- 
+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 as shown in the image below, it means WordPress has been created successfully.
-
-
-
-
+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 through a NodePort
-1. To access the Service outside the cluster, navigate to **Services** first. Click the three dots on the right of `wordpress` and select **Edit Internet Access**.
-
- 
+1. To access the Service outside the cluster, navigate to **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}` and you can see an image as below:
-
- 
+4. Access this application at `{Node IP}:{NodePort}`.
{{< notice note >}}
diff --git a/content/en/docs/reference/api-docs.md b/content/en/docs/reference/api-docs.md
index d91f7ce89..73a0ac115 100644
--- a/content/en/docs/reference/api-docs.md
+++ b/content/en/docs/reference/api-docs.md
@@ -45,12 +45,14 @@ curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
'http://[node ip]:31407/oauth/token' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=admin' \
- --data-urlencode 'password=P#$$w0rd'
+ --data-urlencode 'password=P#$$w0rd' \
+ --data-urlencode 'client_id=kubesphere' \
+ --data-urlencode 'client_secret=kubesphere'
```
{{< notice note >}}
-Replace `[node ip]` with your actual IP address.
+Replace `[node ip]` with your actual IP address. You can configure client credentials in `ClusterConfiguration`, there is a default client credential `client_id` and `client_secret` is `kubesphere`.
{{}}
diff --git a/content/en/docs/reference/glossary.md b/content/en/docs/reference/glossary.md
index efa74bf61..2337d3b2f 100644
--- a/content/en/docs/reference/glossary.md
+++ b/content/en/docs/reference/glossary.md
@@ -108,11 +108,11 @@ This glossary includes general terms and technical terms that are specific to Ku
- **Allocated Memory** 
in the lower-right corner and select **Auditing Operating**.
+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 **Event Search**.
+1. The event query function is available for all users. Log in to the console with any account, hover over 
on the left of the search box and select a target cluster.
-- KubeSphere stores events for last seven days by default.
+- 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.
-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 analyzing.
-
- 
-
- {{< notice note >}}
+{{< notice note >}}
The event query interface supports dynamic refreshing every 5s, 10s or 15s.
diff --git a/content/en/docs/toolbox/log-query.md b/content/en/docs/toolbox/log-query.md
index 6ff4228b7..48ee7489d 100644
--- a/content/en/docs/toolbox/log-query.md
+++ b/content/en/docs/toolbox/log-query.md
@@ -18,9 +18,7 @@ You need to enable the [KubeSphere Logging System](../../pluggable-components/lo
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 displayed dialog box, you can see a time histogram of log numbers, a cluster selection drop-down list and a log search box.
-
- 
+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 >}}
@@ -30,11 +28,9 @@ You need to enable the [KubeSphere Logging System](../../pluggable-components/lo
{{}}
-3. You can click the search box and enter a condition to search for logs by keyword, project, workload, Pod, container, or time range (for example, use `Time Range:Last 10 minutes` to search for logs within the last 10 minutes). Alternatively, click on the bars in the time histogram, and KubeSphere will use the time range of that bar for log queries.
+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 >}}
+{{< 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`.
@@ -44,32 +40,20 @@ You need to enable the [KubeSphere Logging System](../../pluggable-components/lo
## Use Search Parameters
-1. You can enter multiple conditions to narrow down your search results.
+1. You can provide as many fields as possible to narrow down your search results.
- 
-
-3. Click any one of the results from the list. Drill into its details 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.
-
- 
+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.
-- You can click 
in the upper-right corner to export logs to a local file for further analysis.
+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 switch between Pods and inspect its containers within the same project. In this case, you can detect if any abnormal Pods affect other Pods.
+ {{}}
+4. In the left panel, you can click 
to view the Pod details page or container details page.
## Drill into the Details Page
-In the left panel, you can click 
on the right of a user, and click **OK** for the displayed message to assign the user to the department.
+2. In the user list, click on the right of a user, and click **OK** for the displayed message to assign the user to the department.
{{< notice note >}}
@@ -59,9 +58,9 @@ A department in a workspace is a logical unit used for permission control. You c
## Delete and Edit a Department
-1. On the **Department Management** page, click **Set Department**.
+1. On the **Department Management** page, click **Set Departments**.
-2. In the **Set Department** dialog box, on the left, click the upper level of the department to be edited or deleted.
+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.
diff --git a/content/en/docs/workspace-administration/project-quotas.md b/content/en/docs/workspace-administration/project-quotas.md
index 9c4503af5..ad59de15f 100644
--- a/content/en/docs/workspace-administration/project-quotas.md
+++ b/content/en/docs/workspace-administration/project-quotas.md
@@ -6,52 +6,46 @@ 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 [ResourceQuotas](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.
+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.
+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 an account (`ws-admin`). The account must have the `admin` role at the workspace level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+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 account `project-admin` (an account 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.
+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 **Set** to configure 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 dialog that appears, you can see that KubeSphere does not set any requests or limits for a project by default. To set
+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 Quota Item** and select an object from the list.
-
- 
+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 **Manage Project** on the **Basic Information** page and select **Edit Quota**.
+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 Quota** does not display in the **Manage Project** drop-down menu. To set quotas for a multi-cluster project, go to **Quota Management** under **Project Settings** and click **Edit Quota**. Note that as a multi-cluster project runs across clusters, you can set resource quotas on different clusters separately.
+ 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.
{{}}
diff --git a/content/en/docs/workspace-administration/role-and-member-management.md b/content/en/docs/workspace-administration/role-and-member-management.md
index 084de5a32..b6c2bab04 100644
--- a/content/en/docs/workspace-administration/role-and-member-management.md
+++ b/content/en/docs/workspace-administration/role-and-member-management.md
@@ -6,17 +6,11 @@ linkTitle: "Workspace Role and Member Management"
weight: 9400
---
-This tutorial demonstrates how to manage roles and members in a workspace. At the workspace level, you can grant permissions in the following modules to a role:
-
-- **Project Management**
-- **DevOps Project Management**
-- **App Management**
-- **Access Control**
-- **Workspace Settings**
+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 an account of the `workspace-admin` role (for example, `ws-admin`) at the workspace level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+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 >}}
@@ -26,20 +20,18 @@ The actual role name follows a naming convention: `workspace name-role name`. Fo
## Built-in Roles
-In **Workspace Roles**, there are four available built-in roles as shown below. 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.
+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` | The viewer in the workspace who can view all resources in the workspace. |
-| `workspace-self-provisioner` | The regular user in the workspace who can create projects and DevOps projects. |
-| `workspace-regular` | The regular user in the workspace who cannot create projects or DevOps projects. |
-| `workspace-admin` | The administrator in the workspace who can perform any action on any resource. It gives full control over all resources in the workspace. |
+| `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 as shown below.
-
- 
+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.
@@ -57,20 +49,13 @@ To view the permissions that a role contains:
{{}}
-4. Newly-created roles will be listed in **Workspace Roles**. To edit an existing role, click 
on the right.
-
- 
+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 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.
-
- 
-
+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/workspace-administration/upload-helm-based-application.md b/content/en/docs/workspace-administration/upload-helm-based-application.md
index 685daf91a..1a2236f91 100644
--- a/content/en/docs/workspace-administration/upload-helm-based-application.md
+++ b/content/en/docs/workspace-administration/upload-helm-based-application.md
@@ -13,25 +13,17 @@ This tutorial demonstrates how to develop an app template by uploading a package
## Prerequisites
- You need to enable the [KubeSphere App Store (OpenPitrix)](../../pluggable-components/app-store/).
-- You need to create a workspace and a user account (`project-admin`). The account must be invited to the workspace with the role of `workspace-self-provisioner`. For more information, refer to [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+- 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 **Upload Template**.
+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 Helm Chart Package**. 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.
-
- 
+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.
-
- 
+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 >}}
@@ -39,12 +31,8 @@ Maximum accepted resolutions of the app icon: 96 x 96 pixels.
{{}}
-5. The app appears in the template list with the status **Draft** after successfully uploaded, which means this app is under development. The uploaded app is visible to all members in the same workspace.
+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 Version**, **Test Deployment**, and **Submit for Review**.
-
- 
+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/workspace-administration/what-is-workspace.md b/content/en/docs/workspace-administration/what-is-workspace.md
index 4dd4770d8..d110c0079 100644
--- a/content/en/docs/workspace-administration/what-is-workspace.md
+++ b/content/en/docs/workspace-administration/what-is-workspace.md
@@ -15,13 +15,11 @@ This tutorial demonstrates how to create and delete a workspace.
## Prerequisites
-You have an account granted the role of `workspaces-manager`, such as `ws-manager` in [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+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`. On the **Workspaces** page, you can see all workspaces on the platform. Click **Create**.
-
- 
+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**.
{{< notice note >}}
@@ -29,22 +27,18 @@ You have an account granted the role of `workspaces-manager`, such as `ws-manage
{{}}
-2. On the **Basic Information** page, specify a name for the workspace and select an administrator from the drop-down list. Click **Create** to continue.
-
- 
+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**: Account that administers the workspace.
+ - **Administrator**: User that administers the workspace.
- **Description**: A brief introduction of the workspace.
-3. The workspace created appears in the list as shown below.
+ 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 in the workspace on the **Overview** page.
-
- 
+4. Click the workspace and you can see resource status of the workspace on the **Overview** page.
## Delete a Workspace
@@ -78,15 +72,13 @@ Be extremely cautious about deleting a workspace if you use kubectl to delete wo
1. In your workspace, go to **Basic Information** under **Workspace Settings**. On the **Basic Information** page, you can see the general information of the workspace, such as the number of projects and members.
- 
-
{{< notice note >}}
On this page, you can click **Edit Information** to change the basic information of the workspace (excluding the workspace name) and turn on/off [Network Isolation](../../workspace-administration/workspace-network-isolation/).
{{}}
-2. To delete the workspace, check **Delete Workspace** and click **Delete**.
+2. To delete the workspace, click **Delete** under **Delete Workspace**. In the displayed dialog box, enter the name of the workspace, and then click **OK**.
{{< notice warning >}}
diff --git a/content/en/docs/workspace-administration/workspace-network-isolation.md b/content/en/docs/workspace-administration/workspace-network-isolation.md
index 13245136d..8bc7582da 100644
--- a/content/en/docs/workspace-administration/workspace-network-isolation.md
+++ b/content/en/docs/workspace-administration/workspace-network-isolation.md
@@ -10,7 +10,7 @@ weight: 9500
- You have already enabled [Network Policies](../../pluggable-components/network-policy/).
-- Use an account of the `workspace-admin` role. For example, use the account `ws-admin` created in [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+- Use a user of the `workspace-admin` role. For example, use the `ws-admin` user created in [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
{{< notice note >}}
@@ -22,8 +22,6 @@ weight: 9500
Workspace network isolation is disabled by default. You can turn on network isolation in **Basic Information** under **Workspace Settings**.
-
-
{{< notice note >}}
When network isolation is turned on, egress traffic will be allowed by default, while ingress traffic will be denied for different workspaces. If you need to customize your network policy, you need to turn on [Project Network Isolation](../../project-administration/project-network-isolation/) and add a network policy in **Project Settings**.
diff --git a/content/en/docs/workspace-administration/workspace-quotas.md b/content/en/docs/workspace-administration/workspace-quotas.md
index 24725c3e9..3a55c4bd2 100644
--- a/content/en/docs/workspace-administration/workspace-quotas.md
+++ b/content/en/docs/workspace-administration/workspace-quotas.md
@@ -14,19 +14,17 @@ This tutorial demonstrates how to manage resource quotas for a workspace.
## Prerequisites
-You have an available workspace and an account (`ws-manager`). The account must have the `workspaces-manager` role at the platform level. For more information, see [Create Workspaces, Projects, Accounts and Roles](../../quick-start/create-workspace-and-project/).
+You have an available workspace and a user (`ws-manager`). The user must have the `workspaces-manager` role at the platform level. For more information, see [Create Workspaces, Projects, Users and Roles](../../quick-start/create-workspace-and-project/).
## Set Workspace Quotas
1. Log in to the KubeSphere web console as `ws-manager` and go to a workspace.
-2. Navigate to **Quota Management** under **Workspace Settings**.
+2. Navigate to **Workspace Quotas** under **Workspace Settings**.
-3. The **Quota Management** page lists all the available clusters assigned to the workspace and their respective requests and limits of CPU and memory. Click **Edit Quota** on the right of a cluster.
+3. The **Workspace Quotas** page lists all the available clusters assigned to the workspace and their respective requests and limits of CPU and memory. Click **Edit Quotas** on the right of a cluster.
-4. In the dialog that appears, you can see that KubeSphere does not set any requests or limits for the workspace 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.
-
- 
+4. In the displayed dialog box, you can see that KubeSphere does not set any requests or limits for the workspace by default. To set requests and limits to control CPU and memory resources, move 
to a desired value or enter numbers directly. Leaving a field blank means you do not set any requests or limits.
{{< notice note >}}
diff --git a/content/en/news/_index.md b/content/en/news/_index.md
index 7e3f8ba08..e27d76f4f 100644
--- a/content/en/news/_index.md
+++ b/content/en/news/_index.md
@@ -10,6 +10,14 @@ section1:
section2:
news:
+ - title: 'Kubesphere Team will join the KubeCon China and bring 5 sessions'
+ description: KubeSphere Team brings 5 session to KubeCon China 2021
+ image: /images/news/kubecon-china-2021/banner.png
+ link: 'kubecon-china-2021/'
+ - title: 'Kubernetes Commnuity Days China 2021 Recap'
+ description: The first Kubernetes Community Days China was successfully held in Beijing
+ image: /images/news/kcd-china/kcd-china-event.png
+ link: 'kubernetes-community-days-china/'
- title: 'Announcing KubeSphere 3.1.0 on AWS Quick Start!'
description: KubeSphere Quick Start uses AWS CloudFormation templates to help users automatically provision an Amazon EKS cluster on the AWS Cloud. End users can manage Amazon EKS clusters through the KubeSphere console.
image: /images/news/aws-quick-start/quick-start-cover.png
diff --git a/content/en/news/kubecon-china-2021.md b/content/en/news/kubecon-china-2021.md
new file mode 100644
index 000000000..8b01623b2
--- /dev/null
+++ b/content/en/news/kubecon-china-2021.md
@@ -0,0 +1,80 @@
+---
+title: 'KubeSphere Team will join the KueCon China and bring 5 sessions'
+keywords: KubeCon, Meetup, Kubernetes
+description: KubeSphere brings 4 sessions and participte 1 office hour in KubeCon China2021
+createTime: '2021-12-09'
+author: 'Feynman, Lindsay'
+---
+
+Every year, the Cloud-Native Computing Foundation organizes its flagship conference KubeCon and CloudNativeCon, which gathers DevOps, SRE, developers, and technologists to meet leading open source and Cloud-Native communities. This year, KubeCon and CloudNativeCon China are coming! KubeSphere Team will bring 4 sessions and participate 1 office hours in this conference, you can join virtually from 9-10 December 2021.
+
+## Session 1: Kubernetes Multi-cluster and Multi-tenancy Management with RBAC and KubeFed
+
+## Abstract
+
+Soft multi-tenancy is a form of multi-tenancy that does not have strict isolation of the different users, workloads, or applications. When it comes to Kubernetes, soft multi-tenancy is usually isolated by RBAC and namespaces. There are many challenges when cluster administrators implement multi-tenancy across multiple Kubernetes clusters, such as authentication and authorization, resource quota, network policy, security policy, etc.
+
+In this talk, KubeSphere maintainers will share their experience and best practice in designing the multi-tenancy architecture: how to manage users and authentication across multiple clusters, how to manage resource quotas for tenants in different clusters, the resource isolation mechanism, and how to authorize resources across multiple clusters.
+
+## Speaker
+
+Hongming Wan - Senior Software Engineer, QingCloud Technologies.
+
+Hongming is the core contributor of KubeSphere, and leads the KubeSphere Multi-tenancy and Security team. He focuses on open source and cloud-native security areas.
+
+## Session 2: Ship Apps to Multi-cluster Environments from an App-centric Abstraction
+
+## Abstract
+
+Many application definitions and frameworks are emerging from the CNCF landscape. Helm Chart and Operator are the most popular ways to package and manage applications in the Kubernetes ecosystem. From the CNCF Survey 2020, the enterprise architecture represented by multi-cluster and multi-cloud has been a new trend in modern infrastructure. How can we leverage the app-centric concepts to provide self-service to deliver/deploy applications across multiple Kubernetes clusters and clouds? KubeSphere Team is building a unified control plane to enable users to deliver applications and cloud functions with a consistent workflow. In this talk, KubeSphere maintainers will talk about:
+
+- Uncomplicating the Helm Chart and Operator deployment using CRD
+- How to propagate a cloud native application across multiple clouds
+- How to manage Operator and its CRD across multiple clouds
+- How to extend your operator in an elegant interface
+
+## Speaker
+
+Zhengyi Lai - KubeSphere Dev Lead, QingCloud Technologies
+
+Zhengyi Lai is the maintainer of the KubeSphere. He has contributed to helm, virtual-kubelet, grpc-gateway, etc. Zhengyi is also maintaining the application store, network, and pluggable architecture in KubeSphere. His main work focuses on networking, multi-clustering, application delivery and cloud-native technologies such as Artifact Hub.
+
+## Session 3: Build a modern FaaS platform with Cloud Native Serverless technologies
+
+## Abstract
+
+As the core of Serverless, FaaS (Function-as-a-Service) has gained more and more attention. The emerging cloud native serverless technologies make it possible to build a robust modern FaaS platform by replacing the key components of a FaaS platform with more powerful cloud native alternatives. In this talk, OpenFunction maintainers will talk about:
+
+- The key components that make a FaaS platform, including function framework, function build, function serving, and function event management.
+- The advantage of the emerging cloud native serverless technologies in each of the key areas of FaaS including Knative Serving, Cloud Native Buildpacks, Shipwright, Tekton, KEDA, and Dapr.
+- How to build a powerful modern FaaS platform with these cloud native technologies by the example of OpenFunction
+- Why does event management matter for FaaS?
+- Why OpenFunction create its own event management system "OpenFunction Events" when there're already Knative eventing and Argo Events?
+
+## Speaker
+
+Benjamin Huo - Founder of OpenFunction
+
+Benjamin Huo led the KubeSphere Observability and Serverless team. He is the creator of FluentBit Operator and the founder of the FaaS project [OpenFunction]((https://github.com/OpenFunction/OpenFunction)), also the author and architect of several observability open source projects such as Kube-Events, Notification Manager, etc. He loves cloud-native and open source technologies and is the contributor of Prometheus.
+
+
+Wanjun Lei - KubeSphere Dev Lead, QingCloud Technologies.
+
+Wanjun Lei is the maintainer of OpenFunction and is responsible for developing OpenFunction. He is also the maintainer of FluentBit Operator, and a member of the KubeSphere Observability team, where he is responsible for the development of Notification Manager. He loves cloud native and open source technologies, and is a contributor to fluent bit and nats.
+
+## Session 4: KubeSphere use case sharing in the OpenEBS Office Hours
+
+
+In cloud-based Kubernetes clusters, persistent storage services are usually provided by cloud providers. When enterprises build an on-premise Kubernetes platform or adopt a Kuberntes distribution in production, persistent storage is the biggest challenge. OpenEBS automates the management of storage attached to the Kubernetes worker nodes and allow the storage to be used for dynamically provisioning OpenEBS PVs or Local PVs. KubeSphere is an open source container platform built on Kubernetes, it integrates OpenEBS as the default persistent storage to provide out-of-the-box persistent storage services for users.
+
+In this talk, Feynman Zhou and Stone Shi from KubeSphere Team will introduce how they leverage OpenEBS and Kubernetes to build a container platform and run stateful workloads on it.
+
+
+## Session 5: AWS invited KubeSphere Product Manager to speak at the interview
+
+
+
+
+## RSVP
+
+You can register the KubeCon and CloudNativeCon 2021 via this [link](https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/register/), join us virtually from 9-10 December 2021.
\ No newline at end of file
diff --git a/content/en/news/kubernetes-community-days-china.md b/content/en/news/kubernetes-community-days-china.md
new file mode 100644
index 000000000..5dd11074b
--- /dev/null
+++ b/content/en/news/kubernetes-community-days-china.md
@@ -0,0 +1,43 @@
+---
+title: "Kubernetes Community Days China Recap"
+keywords: " Community, Kubernetes"
+description: "The first Kubernetes Community Days China was successfully held in Beijing"
+createTime: "2021-11-02"
+author: "Lindsay"
+---
+
+## Kubernetes Community Days China
+
+
+
+ [Kubernetes Community Days (KCD)](https://community.cncf.io/kubernetes-community-days/about-kcd/) was initiated by the Cloud Native Computing Foundation (CNCF) and is jointly organized by local CNCF ambassadors, CNCF employees, and CNCF members across the world. KCD is currently being actively organized worldwide, gathering end users, contributors, and technical experts from the open-source community in the cloud-native field. This series of localized activities will help grow the Kubernetes Community and spread cloud-native technology more widely among end-users in different industries.
+
+Cloud-native technologies and Kubernetes have become more and more popular in China. According to Jim Zemlin, executive director of the Linux Foundation, China's contribution to the Kubernetes community ranks second in the world, next only to the United States. In the "[CNCF China Cloud Native Survey 2020](https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020/)", it is also mentioned that the proportion of Chinese companies using Kubernetes in the production environment has reached as high as 82%, and Chinese teams have contributed 13 open-source projects.
+
+## Event Organizers
+
+Collaborating with CNCF ambassadors from PingCAP, DaoCloud, Huawei Cloud, KubeSphere, and Cloud Native Community, CNCF hosted the first Kubernetes Community Days (KCD) in Beijing, focusing on open-source projects and technical practices in the cloud-native ecosystem.
+
+
+
+## Event at a Glance
+
+KCD Beijing set up 4 keynote speeches, 4 lightning talks and 1 panel session, in which CTOs and architects from many well-known companies such as Microsoft Azure, NGINX Community, Tencent, DaoCloud, VMware, Xinglan Technology, VIPKID, and maintainers of the open-source project brings a lot of inspiring ideas.
+
+
+
+On the day of the event, nearly 300 people signed up, and more than 150 people participated at the Microsoft Beijing office. Six online platforms provided real-time live broadcasts, attracting more than 5,000 people to watch.
+
+
+
+
+
+
+
+
+
+
+
+All the decks shared by speakers have been uploaded to CNCF/Presentations. Feel free to download or comment!
+
+Download: https://github.com/cncf/presentations/tree/master/chinese/kcd-china
\ No newline at end of file
diff --git a/content/en/privacy/_index.md b/content/en/privacy/_index.md
index 35aefb475..642765013 100644
--- a/content/en/privacy/_index.md
+++ b/content/en/privacy/_index.md
@@ -61,7 +61,7 @@ css: "scss/private.scss"
For the purpose of the GDPR, Service Providers are considered Data Processors.
Third-party Social Media Service refers to any website or any social network website through which a User can log in or create an account to use the Service.
+Third-party Social Media Service refers to any website or any social network website through which a User can log in or create a user to use the Service.
Usage Data refers to data collected automatically, either generated by the use of the Service or from the Service infrastructure itself (for example, the duration of a page visit).
diff --git a/content/tr/conferences/admin-quick-start.md b/content/tr/conferences/admin-quick-start.md index 09b4dd913..3bb7286c1 100644 --- a/content/tr/conferences/admin-quick-start.md +++ b/content/tr/conferences/admin-quick-start.md @@ -31,7 +31,7 @@ The role of cluster-admin is able to create accounts for other users and assign #### Step 1: Create roles and accounts -First, we will create a new role (user-manager), grants account management and role management authority to this role, then we will create an account and grant the user-manager role to this account. +First, we will create a new role (user-manager), grants account management and role management authority to this role, then we will create a user and grant the user-manager role to this account. | Account Name | Cluster Role | Responsibility | | ------------ | ------------ | --------------------------------- | @@ -47,7 +47,7 @@ First, we will create a new role (user-manager), grants account management and r  -1.4. Click **Platform**, then navigate to **Accounts** page and click **Create** to create an account. +1.4. Click **Platform**, then navigate to **Accounts** page and click **Create** to create a user.  diff --git a/content/zh/_index.md b/content/zh/_index.md index 3bae4d514..e6f882cde 100644 --- a/content/zh/_index.md +++ b/content/zh/_index.md @@ -90,7 +90,7 @@ section4: - name: 支持多种存储与网络方案 icon: /images/home/multi-tenant-management.svg - content: 支持 GlusterFS、Ceph、NFS、LocalPV，提供多个 CSI 插件对接公有云与企业级存储；提供面向物理机 Kubernetes 环境的负载均衡器 Porter，支持网络策略可视化，支持 Calico、Flannel、Cilium、Kube-OVN 等网络插件 + content: 支持 GlusterFS、Ceph、NFS、LocalPV，提供多个 CSI 插件对接公有云与企业级存储；提供面向物理机 Kubernetes 环境的负载均衡器 OpenELB，支持网络策略可视化，支持 Calico、Flannel、Cilium、Kube-OVN 等网络插件 features: - name: Kubernetes DevOps 系统 diff --git a/content/zh/blogs/DevOps-pipeline-remove-Docker-dependencies.md b/content/zh/blogs/DevOps-pipeline-remove-Docker-dependencies.md index e2a63893f..fd3694f1f 100644 --- a/content/zh/blogs/DevOps-pipeline-remove-Docker-dependencies.md +++ b/content/zh/blogs/DevOps-pipeline-remove-Docker-dependencies.md @@ -61,7 +61,7 @@ containerd github.com/containerd/containerd v1.4.3 269548fa27e0089a8b8278fc4 这里主要用于测试，因此没有将 Podman 安装到基础镜像中，而是在流水线中实时安装。生产环境，应该提前安装，以加快执行速度。 -以 [devops-java-sample](https://github.com/kubesphere/devops-java-sample) 为例，流水线中主要需要增加如下部分： +以 [devops-maven-sample](https://github.com/kubesphere/devops-maven-sample) 为例，流水线中主要需要增加如下部分： ```groovy stage ('install podman') { @@ -78,11 +78,11 @@ containerd github.com/containerd/containerd v1.4.3 269548fa27e0089a8b8278fc4 } ``` -相关脚本，已经更新到 [Podman](https://github.com/kubesphere/devops-java-sample/tree/podman) 分支中。 +相关脚本，已经更新到 [Podman](https://github.com/kubesphere/devops-maven-sample/tree/podman) 分支中。 -## 测试 devops-java-sample 项目 +## 测试 devops-maven-sample 项目 -使用 devops-java-sample 创建 SCM 流水线，Jenkinsfile 路径设置为 Jenkinsfile-online，并配置好相关的秘钥值。 +使用 devops-maven-sample 创建 SCM 流水线，Jenkinsfile 路径设置为 Jenkinsfile-online，并配置好相关的秘钥值。 最后执行时，在 Podman 分支上可以看到如下日志： diff --git a/content/zh/blogs/Kubernetes-multicluster-KubeSphere.md b/content/zh/blogs/Kubernetes-multicluster-KubeSphere.md index 270206cf4..42e1b0d59 100644 --- a/content/zh/blogs/Kubernetes-multicluster-KubeSphere.md +++ b/content/zh/blogs/Kubernetes-multicluster-KubeSphere.md @@ -1,10 +1,10 @@ --- title: '混合云下的 Kubernetes 多集群管理与应用部署' tag: 'KubeSphere, Kubernetes, 多集群管理' -keywords: 'KKubeSphere, Kubernetes, 多集群管理, Kubefed' +keywords: 'KubeSphere, Kubernetes, 多集群管理, Kubefed' description: '本文介绍了 Kubernetes 社区多集群方向的发展历程以及已有的多集群解决方案，分享在混合云的场景下, KubeSphere 如何基于 Kubefed 统一应用的分发与部署，以达到跨 region 的多活/容灾等目的。同时探讨未来多集群领域可能迈向的去中心化的架构。' createTime: '2021-05-26' -author: ' 李宇' +author: '李宇' snapshot: 'https://pek3b.qingstor.com/kubesphere-community/images/Kubernetes-multicluster-KubeSphere-banner.jpg' --- @@ -68,7 +68,7 @@ Kubernetes 内部分为 Master 和 Worker 两个角色。Master 上面有 API Se  当然 Kubefed 也不是银弹，也有其一定的局限性。从前面可以看到，其 API 定义复杂，容易出错，也只能使用 kubefedctl 加入和解绑集群，没有提供单独的 SDK。再就是它要求控制层集群到管控集群必须网络可达，单集群到多集群需要改造 API，旧版本也不支持联邦资源的状态收集。 -## KubeShere On Kubefed +## KubeSphere On Kubefed 接下来我们看看 KubeSphere 基于 Kubefed 如何实现并简化了多集群管理。 @@ -135,4 +135,3 @@ Virtual Kubelet 可以帮助你把自己的服务伪装成一个 Kubernetes 的 在 Liqo 里面，集群之间不存在联邦关系，左图里在 Kubefed 架构下 k2、k3 两个集群是 k1 的成员集群，资源下方需要经过一次 k1 的 push，而在右边的图里面，k2、k3 只是 k1 的一个节点，因此在部署应用的时候，完全不需要引入任何的 API，k2、k3 看起来就是 k1 的节点，这样业务就可以无感知的被部署到不同的集群上去，极大减少了单集群到多集群改造的复杂性。现在 Liqo 属于刚起步阶段，目前不支持两个集群以上的拓扑，在未来 KubeSphere 也会持续关注开源领域的一些其他的多集群管理方案。 - diff --git a/content/zh/blogs/Serverless-way-for-Kubernetes-Log-Alerting.md b/content/zh/blogs/Serverless-way-for-Kubernetes-Log-Alerting.md deleted file mode 100644 index 64fb25e96..000000000 --- a/content/zh/blogs/Serverless-way-for-Kubernetes-Log-Alerting.md +++ /dev/null @@ -1,426 +0,0 @@ ---- -title: 'OpenFunction 应用系列之一: 以 Serverless 的方式实现 Kubernetes 日志告警' -tag: 'OpenFunction, KubeSphere, Kubernetes' -keywords: 'penFunction, Serverless, KubeSphere, Kubernetes, Kafka, FaaS, 无服务器' -description: '本文提供了一种基于 Serverless 的日志处理思路，可以在降低该任务链路成本的同时提高其灵活性。' -createTime: '2021-08-26' -author: '方阗' -snapshot: 'https://pek3b.qingstor.com/kubesphere-community/images/202109031518797.png' ---- -## 概述 - -当我们将容器的日志收集到消息服务器之后，我们该如何处理这些日志？部署一个专用的日志处理工作负载可能会耗费多余的成本，而当日志体量骤增、骤降时亦难以评估日志处理工作负载的待机数量。本文提供了一种基于 Serverless 的日志处理思路，可以在降低该任务链路成本的同时提高其灵活性。 - -我们的大体设计是使用 Kafka 服务器作为日志的接收器，之后以输入 Kafka 服务器的日志作为事件，驱动 Serverless 工作负载对日志进行处理。据此的大致步骤为： - -1. 搭建 Kafka 服务器作为 Kubernetes 集群的日志接收器 -2. 部署 OpenFunction 为日志处理工作负载提供 Serverless 能力 -3. 编写日志处理函数，抓取特定的日志生成告警消息 -4. 配置 [Notification Manager](https://github.com/kubesphere/notification-manager/) 将告警发送至 Slack - - - -在这个场景中，我们会利用到 [OpenFunction](https://github.com/OpenFunction/OpenFunction) 带来的 Serverless 能力。 - -> [OpenFunction](https://github.com/OpenFunction/OpenFunction) 是 KubeSphere 社区开源的一个 FaaS（Serverless）项目，旨在让用户专注于他们的业务逻辑，而不必关心底层运行环境和基础设施。该项目当前具备以下关键能力： -> -> - 支持通过 dockerfile 或 buildpacks 方式构建 OCI 镜像 -> - 支持使用 Knative Serving 或 OpenFunctionAsync ( KEDA + Dapr ) 作为 runtime 运行 Serverless 工作负载 -> - 自带事件驱动框架 - -## 使用 Kafka 作为日志接收器 - -首先，我们为 KubeSphere 平台开启 **logging** 组件（可以参考 [启用可插拔组件](https://kubesphere.io/zh/docs/pluggable-components/) 获取更多信息）。然后我们使用 [strimzi-kafka-operator](https://github.com/strimzi/strimzi-kafka-operator) 搭建一个最小化的 Kafka 服务器。 - -1. 在 default 命名空间中安装 [strimzi-kafka-operator](https://github.com/strimzi/strimzi-kafka-operator) ： - - ```shell - helm repo add strimzi https://strimzi.io/charts/ - helm install kafka-operator -n default strimzi/strimzi-kafka-operator - ``` - -2. 运行以下命令在 default 命名空间中创建 Kafka 集群和 Kafka Topic，该命令所创建的 Kafka 和 Zookeeper 集群的存储类型为 **ephemeral**，使用 emptyDir 进行演示。 - - > 注意，我们此时创建了一个名为 “logs” 的 topic，后续会用到它 - - ```shell - cat <+> **译者：田璧州**
+> **注：本文已取得作者本人的翻译授权** + +去年 6 月，[Tigera](https://www.tigera.io/?utm_content=inline-mention) 宣布首次在 k8s 上支持用于集群内加密传输的开源 VPN，[WireGuard](https://www.wireguard.com/) 。我们从来不喜欢坐以待毙，所以我们一直在努力为这项技术开发一些令人兴奋的新功能，其中第一个功能是使用 [Azure 容器网络接口](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) (CNI) 在 [Azure Kubernetes 服务](https://azure.microsoft.com/en-us/services/kubernetes-service/) (AKS) 上支持 WireGuard。 + +首先，这里简单回顾一下什么是 WireGuard 以及我们如何在 Calico 中使用它。 + +WireGuard 是一种 VPN 技术，从 linux 5.6 内核开始默认包含在内核中，它被定位为 IPsec 和 OpenVPN 的替代品。它的目标是更加快速、安全、易于部署和管理。正如不断涌现的 SSL/TLS 的漏洞显示，密码的敏捷性会极大增加复杂性，这与 WireGuard 的目标不符，为此，WireGuard 故意将密码和算法的配置灵活性降低，以减少该技术的可攻击面和可审计性。它的目标是更加简单快速，所以使用标准的 Linux 网络命令便可以很容易的对它进行配置，并且只有约 4000 行代码，使得它的代码可读性高，容易理解和接受审查。 + +WireGuard 是一种 VPN 技术，通常被认为是 C/S 架构。它同样能在端对端的网格网络架构中配置使用，这就是 Tigera 设计的 WireGuard 可以在 Kubernetes 中启用的解决方案。使用 Calico，所有启用 WireGuard 的节点将端对端形成一个加密的网格。Calico 甚至支持在同一集群内同时包含启用 WireGuard 的节点与未启用 WireGuard 的节点，并且可以相互通信。 + + + +我们选择 WireGuard 并不是一个折中的方案。我们希望提供最简单、最安全、最快速的方式来加密传输 Kubernetes 集群中的数据，而无需使用 mTLS、IPsec 或其他复杂的配置。事实上，您可以把 WireGuard 看成是另一个具有加密功能的 Overlay。 + +用户只需一条命令就可以启用 WireGuard，而 Calico 负责完成剩余的工作，包括： + +- 在每个节点创建 WireGuard 的网络接口 +- 计算并编写最优的 MTU +- 为每个节点创建 WireGuard 公钥私钥对 +- 向每个节点添加公钥，以便在集群中共享资源 +- 为每个节点编写端对端节点 +- 使用防火墙标记（fwmark）编写 IP route、IP tables 和 Routing tables，以此正确处理各自节点上的路由 + +您仅需指明意图，其他的事情都由集群完成 + +## 使用 WireGuard 时的数据包流向 + +下图显示了启用 WireGuard 后集群中的各种数据包流量情况。 + + + +同一主机上的 Pod： + +- 数据包被路由到 WireGuard 表。 +- 如果目标 IP 是同一主机上的 Pod，Calico 则在 WireGuard 路由表中插入一个 “ throw ” 条目，将数据包引导回主路由表。由此，数据包将被定向到目标 Pod 匹配的 veth 接口，并且它将在未加密的情况下流动（在图中以绿色显示）。 + +不同节点上的 Pod： + +- 数据包被路由到 WireGuard 表。 + +- 路由条目与目标 Pod IP 匹配并发送到 WireGuard 组件： cali.wireguard + +- WireGuard 组件加密并封装数据包（在图中以红色显示）并设置 fwmark 以防止路由环路。 + +- WireGuard 组件使用与目标 Pod IP（允许的 IP）匹配的对等方的公钥对数据包进行加密，将其封装在 UDP 中，并使用特殊的 fwmark 对其进行标记以防止路由环路。 + +- 数据包通过 eth0 发送到目标节点并解密。 + +- 这也适用于主机流量（例如，节点联网的 Pod）。 + +在以下动画中，您可以看到 3 种流量： + +1. 同一主机上 Pod 到 Pod 未被加密的流量。 +2. 不同主机上的 Pod 到 Pod 被加密的流量。 +3. 主机到主机的流量也会被加密。 + +> 注意：绿色表示未加密流量，红色表示加密流量。 + ++ [动画演示](https://tigera.wistia.com/medias/ddl8bmhpgp?utm_source=thenewstack&utm_medium=website&utm_campaign=platform) + +## WireGuard 在 AKS 的应用 + +在 AKS 上使用 Azure CNI 支持使用 WireGuard 带来了一些非常有趣的挑战。 + +首先，使用 Azure CNI 意味着不使用 Calico IPAM（ IP 地址管理）和 CIDR（无类域间路由）块来分配 Pod IP 。相反，它们是采用与节点 IP 相同的分配方式从底层 VNet 进行分配。这对 WireGuard 路由来说是一个有趣的挑战，以往我们可以在 WireGuard 配置中的 Allowed IPs 列表中添加一个 CIDR 块，相比之下，我们现在必须写出该节点上所有 Pod IP。这需要 Calico 将 routeSource 的配置设为 workloadIPs。如果您使用的是我们的 operator 方式部署 AKS 集群，便无需额外配置。 + +使用 wireguard-tools 中优秀的工具 [wg](https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8)，可以查看集群内端对端节点允许通过的 IP 列表，其中包括每个节点的 Pod IP 和主机 IP（注意终端 IP 也在允许 IP 列表中）。在 AKS 集群上，WireGuard 提供了业务流量加密和主机到主机的加密。 + +```shell + interface: wireguard.cali + public key: bbcKpAY+Q9VpmIRLT+yPaaOALxqnonxBuk5LRlvKClA= + private key: (hidden) + listening port: 51820 + fwmark: 0x100000 + + peer: /r0PzTX6F0ZrW9ExPQE8zou2rh1vb20IU6SrXMiKImw= + endpoint: 10.240.0.64:51820 + allowed ips: 10.240.0.64/32, 10.240.0.65/32, 10.240.0.66/32 + latest handshake: 11 seconds ago + transfer: 1.17 MiB received, 3.04 MiB sent + + peer: QfUXYghyJWDcy+xLW0o+xJVsQhurVNdqtbstTsdOp20= + endpoint: 10.240.0.4:51820 + allowed ips: 10.240.0.4/32, 10.240.0.5/32, 10.240.0.6/32 + latest handshake: 46 seconds ago + transfer: 83.48 KiB received, 365.77 KiB sent +``` + +第二个挑战是正确处理 MTU（最大传输单元）。[Azure 设置的 MTU 是 1500](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning#azure-and-vm-mtu)，而 WireGuard 在数据包上设置了一个 DF（Don't Fragment）标记。如果没有正确调整 WireGuard MTU，我们会在启用 WireGuard 时发现有丢包和低带宽。我们可以在 AKS 中通过 Calico 设置为自动检测，从而为 WireGuard 配置正确的开销和 [MTU](https://docs.projectcalico.org/networking/mtu) 来优化。 + +我们还可以将节点 IP 本身添加为端对端节点允许通信的 IP ，并通过 AKS 中的 WireGuard 处理主机联网的 Pod 和主机到主机通信。主机到主机通信的方法是，当 [RPF](https://en.wikipedia.org/wiki/Reverse-path_forwarding)（反向路径转发）发生时，通过 WireGuard 接口获得路由返回的响应。通过在目的节点的接收数据包上设置一个标记，并配置内核确保遵守 sysctl 中的 RPF 标记来解决这个问题。 + +现在您使用 AKS 时，节点之间的业务流量和主机到主机通信都会被加密。您仅需指明意图，其他的事情都由集群完成。 \ No newline at end of file diff --git a/content/zh/blogs/changhong-kubernetes-autoscaling-canaryrelease.md b/content/zh/blogs/changhong-kubernetes-autoscaling-canaryrelease.md index ada0a3d9b..30a5183a6 100644 --- a/content/zh/blogs/changhong-kubernetes-autoscaling-canaryrelease.md +++ b/content/zh/blogs/changhong-kubernetes-autoscaling-canaryrelease.md @@ -107,13 +107,13 @@ CA 依赖于云平台的能力，而通过设置 HPA 可以触发 CA。在 KubeS 由于我们是先部署好 Kubernetes，在其上再安装 KubeSphere的，那么我们需要在安装后的 KubeSphere 启用该功能。 启用方法： -1. 在 KubeSphere 的集群管理界面，找到自定义资源 CRD +1. 在 KubeSphere 的集群管理界面，找到 CRD 2. 打开后输入 `clusterconfiguration` 进行搜索 3. 点击搜索结果，在打开的页面中点击 ks-installer 右侧的按钮，选择编辑配置文件 4. 在打开的 YAML 文件里找到 Metrics Server，在 enabled 一行将 false 更改为 true 5. 之后点击右下角的更新即可 - +  diff --git a/content/zh/blogs/cilium-1.11-release.md b/content/zh/blogs/cilium-1.11-release.md new file mode 100644 index 000000000..1ae6596b2 --- /dev/null +++ b/content/zh/blogs/cilium-1.11-release.md @@ -0,0 +1,307 @@ +--- +title: 'Cilium 1.11 发布，带来内核级服务网格、拓扑感知路由....' +tag: 'Cilium' +keywords: 'Cilium, Service Mesh, Istio, Kubernetes' +description: '几天前，我们发布了具有诸多新功能的 Cilium 1.11 版本，这是一个令人兴奋的版本。诸多新功能中也包括了万众期待的 Cilium Service Mesh 的 Beta 版本。在本篇文章中，我们将深入探讨其中的部分新功能。' +createTime: '2021-12-14' +author: 'Cilium 母公司 Isovalent 团队' +snapshot: 'https://pek3b.qingstor.com/kubesphere-community/images/202112141058286.png' +--- + +> 原文链接： https://isovalent.com/blog/post/2021-12-release-111 + +> **作者：Cilium 母公司 Isovalent 团队** +> **译者：范彬，狄卫华，米开朗基杨** +> +> 注：本文已取得作者本人的翻译授权！ + + + +Cilium 项目已逐渐成为万众瞩目之星，我们很自豪能够成为该项目的核心人员。几天前，我们发布了具有诸多新功能的 Cilium 1.11 版本，这是一个令人兴奋的版本。诸多新功能中也包括了万众期待的 Cilium Service Mesh 的 Beta 版本。在本篇文章中，我们将深入探讨其中的部分新功能。 + +## Service Mesh 测试版本（Beta） + +在探讨 1.11 版本之前，让我们先了解一下 Cilium 社区宣布的 Service Mesh 的新功能。 + + + +- **基于 eBPF 技术的 Service Mesh （Beta）版本**： 定义了新的服务网格能力，这包括 L7 流量管理和负载均衡、TLS 终止、金丝雀发布、追踪等诸多能力。 +- **集成了 Kubernetes Ingress (Beta) 功能**： 通过将 eBPF 和 Envoy 的强势联合，实现了对 Kubernetes Ingress 的支持。 + +Cilium 网站的一篇文章详细介绍了[Service Mesh Beta 版本](https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta)，其中也包括了如何参与到该功能的开发。当前，这些 Beta 功能是 Cilium 项目中的一部分，在单独[分支](https://github.com/cilium/cilium/tree/beta/service-mesh)进行开发，可独立进行测试、反馈和修改，我们期待在 2022 年初 Cilium 1.12 版本发布之前合入到 Cilium 主分支。 + +## Cilium 1.11 + +Cilium 1.11 版本包括了 Kubernetes 额外功能，及独立部署的负载均衡器。 + +- **OpenTelemetry 支持**：Hubble L3-L7 可观测性数据支持 OpenTelemetry 跟踪和度量（Metrics）格式的导出。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#opentelemetry)) +- **Kubernetes APIServer 策略匹配**：新的策略实体用于简单方便地创建进出 Kubernetes API Server 流量的策略模型。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#kubernetes-apiserver-policy-matching)) +- **拓扑感知的路由**：增强负载均衡能力，基于拓扑感知将流量路由到最近的端点，或保持在同一个地区（Region）内。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#topology-aware-hints)) +- **BGP 宣告 Pod CIDR**：使用 BGP 在网络中宣告 Pod CIDR 的 IP 路由。（[更多详情](https://isovalent.com/blog/post/2021-12-release-111#bgp-pod-cidr-announcements)) +- **服务后端流量的优雅终止**：支持优雅的连接终止，通过负载均衡向终止的 Pod 发送的流量可以正常处理后终止。([更多详情](https://isovalent.com/blog/post/2021-12-release-111#graceful-termination)) +- **主机防火墙稳定版**：主机防火墙功能已升级为生产可用的稳定版本。（[更多详情](https://isovalent.com/blog/post/2021-12-release-111#feature-status)） +- **提高负载均衡器扩展性**：Cilium 负载均衡支持超过 64K 的后端端点。([更多详情](https://isovalent.com/blog/post/2021-12-release-111#service-backend-scalability)) +- **提高负载均衡器设备支持**：负载均衡的加速 XDP 快速路径现在支持 bond 设备（[更多详情](https://isovalent.com/blog/post/2021-12-release-111#transparent-xdp-bonding-support)) 同时，可更普遍地用于多设备设置。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#xdp-multi-dev))。 +- **Kube-Proxy-replacement 支持 istio**：Cilium 的 kube-proxy 替代模式与 Istio sidecar 部署模式兼容。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#istio-kpr)) +- **Egress 出口网关的优化**：Egress 网关能力增强，支持其他数据路径模式。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#egress-gateway-improvements)) +- **托管 IPv4/IPv6 邻居发现**：对 Linux 内核和 Cilium 负载均衡器进行了扩展，删除了其内部 ARP 库，将 IPv4 的下一跳发现以及现在的 IPv6 节点委托给内核管理。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#managed-ipv4-ipv6-discovery)) +- **基于路由的设备检测**：外部网络设备基于路由的自动检测，以提高 Cilium 多设备设置的用户体验。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#route-based-device-detection)) +- **Kubernetes Cgroup 增强**：在 cgroup v2 模式下集成了 Cilium 的 kube-proxy-replacement 功能，同时，对 cgroup v1/v2 混合模式下的 Linux 内核进行了增强。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#kubernetes-cgroup)) +- **Cilium Endpoint Slices**：Cilium 基于 CRD 模式能够更加高效地与 Kubernetes 的控制平面交互，并且不需要专有 ETCD 实例，节点也可扩展到 1000+。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#cilium-endpoint-slices)) +- **集成 Mirantis Kubernetes 引擎**：支持 Mirantis Kubernetes 引擎。 ([更多详情](https://isovalent.com/blog/post/2021-12-release-111#mke-integration)) + +## 什么是 Cilium ？ + +Cilium 是一个开源软件，为基于 Kubernetes 的 Linux 容器管理平台上部署的服务，透明地提供服务间的网络和 API 连接及安全。 + +Cilium 底层是基于 Linux 内核的新技术 eBPF，可以在 Linux 系统中动态注入强大的安全性、可见性和网络控制逻辑。 Cilium 基于 eBPF 提供了多集群路由、替代 kube-proxy 实现负载均衡、透明加密以及网络和服务安全等诸多功能。除了提供传统的网络安全之外，eBPF 的灵活性还支持应用协议和 DNS 请求/响应安全。同时，Cilium 与 Envoy 紧密集成，提供了基于 Go 的扩展框架。因为 eBPF 运行在 Linux 内核中，所以应用所有 Cilium 功能，无需对应用程序代码或容器配置进行任何更改。 + +请参阅 **[Cilium 简介]** 部分，了解 Cilium 更详细的介绍。 + +## OpenTelemetry 支持 + + + +新版本增加了对 [OpenTelemetry](https://opentelemetry.io/) 的支持。 + +OpenTelemetry 是一个 CNCF 项目，定义了遥测协议和数据格式，涵盖了分布式跟踪、指标和日志。该项目提供了 SDK 和运行在 Kubernetes 上的收集器。通常，应用程序直接检测暴露 OpenTelemetry 数据，这种检测最常使用 OpenTelemetry SDK 在应用程序内实现。OpenTelemetry 收集器用于从集群中的各种应用程序收集数据，并将其发送到一个或多个后端。CNCF 项目 [Jaeger](https://jaegertracing.io/) 是可用于存储和呈现跟踪数据的后端之一。 + +[支持 OpenTelemetry 的 Hubble 适配器](https://github.com/cilium/hubble-otel)是一个附加组件，可以部署到运行 Cilium 的集群上（Cilium 版本最好是 1.11，当然也应该适用于旧版本）。该适配器是一个嵌入了 Hubble 接收器的 OpenTelemetry 收集器，我们推荐使用 [OpenTelemetry Operator](https://github.com/open-telemetry/opentelemetry-operator) 进行部署（详见[用户指南](https://github.com/cilium/hubble-otel/blob/main/USER_GUIDE_KIND.md)）。Hubble 适配器从 Hubble 读取流量数据，并将其转换为跟踪和日志数据。 + +Hubble 适配器添加到支持 OpenTelemetry 的集群中，可对网络事件和应用级别遥测提供有价值的可观测性。当前版本通过 OpenTelemetry SDK 提供了 HTTP 流量和 spans 的关联。 + +## 感知拓扑的负载均衡 + + + +Kubernetes 集群在跨多数据中心或可用区部署是很常见的。这不仅带来了高可用性好处，而且也带来了一些操作上的复杂性。 + +目前为止，Kubernetes 还没有一个内置的结构，可以基于拓扑级别描述 Kubernetes service 端点的位置。这意味着，Kubernetes 节点基于服务负载均衡决策选择的 service 端点，可能与请求服务的客户在不同的可用区。 这种场景下会带来诸多副作用，可能是云服务费用增加，通常由于流量跨越多个可用区，云提供商会额外收取费用，或请求延迟增加。更广泛地说，我们需要根据拓扑结构定义 service 端点的位置， 例如，服务流量应该在同一节点（node）、同一机架（rack）、同一故障分区（zone）、同一故障地区（region）、同云提供商的端点之间进行负载均衡。 + +Kubernetes v1.21 引入了一个称为[拓扑感知路由](https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints)的功能来解决这个限制。通过将 `service.kubernetes.io/topology-aware-hints` 注解被设置为 `auto` ，在 service 的 EndpointSlice 对象中设置端点提示，提示端点运行的分区。分区名从节点的 topology.kubernetes.io/zone 标签获取。 如果两个节点的分区标签值相同，则被认为处于同一拓扑级别。 + +该提示会被 Cilium 的 kube-proxy 替代来处理，并会根据 EndpointSlice 控制器设置的提示来过滤路由的端点，让负载均衡器优先选择同一分区的端点。 + +该 Kubernetes 功能目前处于 Alpha 阶段，因此需要使用--feature-gate 启用。更多信息请参考[官方文档](https://kubernetes.io/docs/concepts/services-networking/topology-aware-hints)。 + +## Kubernetes APIServer 策略匹配 + + + +托管 Kubernetes 环境，如 GKE、EKS 和 AKS 上，kube-apiserver 的 IP 地址是不透明的。在以前的 Cilium 版本中，没有提供正规的方式来编写 Cilium 网络策略，定义对 kube-apiserver 的访问控制。这涉及一些实现细节，如：Cilium 安全身份分配，kube-apiserver 是部署在集群内，还是部署在集群外。 + +为了解决这个问题，Cilium 1.11 增加了新功能，为用户提供一种方法，允许使用专用策略对象定义进出 apiserver 流量的访问控制。该功能的底层是实体选择器，能够解析预留的 kube-apiserver 标签含义， 并可自动应用在与 kube-apiserver 关联的 IP 地址上。 + +安全团队将对这个新功能特别感兴趣，因为它提供了一个简单的方法来定义对 pod 的 Cilium 网络策略，允许或禁止访问 kube-apiserver。下面 CiliumNetworkPolicy 策略片段定义了 kube-system 命名空间内的所有 Cilium 端点允许访问 kube-apiserver， 除此之外的所有 Cilium 端点禁止访问 kube-apiserver。 + +```yaml +apiVersion: cilium.io/v2 +kind: CiliumNetworkPolicy +metadata: + name: allow-to-apiserver + namespace: kube-system +spec: + endpointSelector: {} + egress: + - toEntities: + - kube-apiserver +``` + +## BGP 宣告 Pod CIDR + + + +随着私有 Kubernetes 环境的日益关注，我们希望与现存的数据中心网络基础设施很好地集成，它们通常是基于 BGP 协议进行路由分发的。 在上一个版本中，Cilium agent 已经开始集成了 BGP 协议, 可以通过 BGP 向 BGP 路由器[发布负载均衡器的 service 的 VIP](https://cilium.io/blog/2021/05/20/cilium-110#bgp)。 + +现在，Cilium 1.11 版本还引入了通过 BGP 宣告 Kubernetes Pod 子网的能力。Cilium 可与任何下游互联的 BGP 基础设施创建一个 BGP 对等体，并通告分配的 Pod IP 地址的子网。这样下游基础设施就可以按照合适方式来分发这些路由，以使数据中心能够通过各种私有/公共下一跳路由到 Pod 子网。 + +要开始使用此功能，运行 Cilium 的 Kubernetes 节点需要读取 BGP 的 ConfigMap 设置： + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: bgp-config + namespace: kube-system +data: + config.yaml: | + peers: + - peer-address: 192.168.1.11 + peer-asn: 64512 + my-asn: 64512 +``` + +同时，Cilium 应该使用以下参数进行安装 ： + +```bash +$ cilium install \ + --config="bgp-announce-pod-cidr=true" +``` + +Cilium 安装完后，它将会向 BGP 路由器发布 Pod CIDR 范围，即 `192.168.1.11`。 + +下面是最近的 Cilium [eCHO episode](https://www.youtube.com/watch?v=nsfbFUO8eu4&t=668s) 完整演示视频。 + +- https://www.youtube.com/watch?v=nsfbFUO8eu4 + +如果想了解更多，如：如何为 Kubernetes service 配置 LoadBalancer IP 宣告，如何通过 BGP 发布节点的 Pod CIDR 范围，请参见 [docs.cilium.io](https://docs.cilium.io/en/latest/gettingstarted/bgp/)。 + +## 托管 IPv4/IPv6 邻居发现 + + + +当 Cilium 启用 eBPF 替代 kube-proxy 时，Cilium 会执行集群节点的邻居发现，以收集网络中直接邻居或下一跳的 L2 地址。这是服务负载平衡所必需的，[eXpress Data Path](https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer) (XDP) 快速路径支持每秒数百万数据包的可靠高流量速率。在这种模式下，在技术上按需动态解析是不可能的，因为它需要等待相邻的后端被解析。 + +在 Cilium 1.10 及更早版本中，cilium agent 本身包含一个 ARP 解析库，其控制器触发发现和定期刷新新增集群节点。手动解析的邻居条目被推送到内核并刷新为 PERMANENT 条目，eBPF 负载均衡器检索这些条目，将流量定向到后端。cilium agent 的 ARP 解析库缺乏对 IPv6 邻居解析支持，并且，PERMANENT 邻居条目还有许多问题：举个例子，条目可能变得陈旧，内核拒绝学习地址更新，因为它们本质上是静态的，在某些情况下导致数据包在节点间被丢弃。此外，将邻居解析紧密耦合到 cilium agent 也有一个缺点，在 agent 启停周期时，不会发生地址更新的学习。 + +在 Cilium 1.11 中，邻居发现功能已被完全重新设计，Cilium 内部的 ARP 解析库已从 agent 中完全移除。现在 agent 依赖于 Linux 内核来发现下一跳或同一 L2 域中的主机。Cilium 现在可同时支持 IPv4 和 IPv6 邻居发现。对于 v5.16 或更新的内核，我们已经将今年 Linux Plumbers 会议期间共同组织的 [BPF & Networking Summit](https://lore.kernel.org/netdev/20211011121238.25542-1-daniel@iogearbox.net/) 上，提出的“管理”邻居条目工作提交到上游（[part1](https://lore.kernel.org/netdev/20211011121238.25542-1-daniel@iogearbox.net/), [part2](https://lore.kernel.org/netdev/20211013132140.11143-1-daniel@iogearbox.net/), [part3](https://lore.kernel.org/netdev/20211025154728.2161-1-daniel@iogearbox.net/)）。在这种情况下，agent 将新增集群节点的 L3 地址下推，并触发内核定期自动解析它们对应的 L2 地址。 + +这些邻居条目作为“外部学习”和“管理”邻居属性，基于 netlink 被推送到内核中。虽然旧属性确保在压力下这些邻居条目不会被内核的垃圾收集器处理，但是 "管理" 邻居属性会，在可行的情况下,内核需要自动将这些邻居属性保持在 `REACHABLE` 状态。这意思是，如果节点的上层堆栈没有主动向后端节点发送或接收流量，内核可以重新学习，将邻居属性保持在 `REACHABLE` 状态，然后通过内部内核工作队列定期触发显式邻居解析。对于没有 "管理" 邻居属性功能的旧内核，如果需要，agent controller 将定期督促内核触发新的解决方案。因此，Cilium 不再有 `PERMANENT` 邻居条目，并且在升级时，agent 将自动将旧条目迁移到动态邻居条目中，以使内核能够在其中学习地址更新。 + +此外，在多路径路由的情况下，agent 会做负载均衡，它现在可以在路由查找中查看失败的下一跳。这意味着，不是替代所有的路由，而是通过查看相邻子系统信息来避免失败的路径。总的来说，对于 Cilium agent 来说，这项修正工作显著促进了邻居管理，并且在网络中的节点或下一跳的邻居地址发生变化时，数据路径更易变化。 + +## XDP 多设备负载均衡器 + + + +在此版本前，基于 XDP 的负载均衡器加速只能在单个网络设备上启用，以发夹方式（hair-pinning）运行，即数据包转发离开的设备与数据包到达的设备相同。这个最初的限制是在[基于 XDP 层的 kube-proxy 替代](https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer)加速中加入的，原因是在 XDP（`XDP_REDIRECT`）下对多设备转发的驱动支持有限，而同设备转发（`XDP_TX`）是 Linux 内核中每个驱动的 XDP 都支持的。 + +这意味着多网络设备的环境下，我们需要使用 tc eBPF 机制，所以必须使用 Cilium 的常规 kube-proxy 替代。这种环境的一个典型例子是有两个网络设备的主机，其中一个是公网，接受来自外部对 Kubernetes service 的请求，而另一个是私有网络，用于 Kubernetes 节点之间的集群内通信。 + +由于在现代 LTS Linux 内核上，绝大多数 40G 和 100G 以上的上游网卡驱动都支持开箱即用的 `XDP_REDIRECT`，这种限制终于可以解除，因此，这个版本在 Cilium 的 kube-proxy 替代，及 Cilium 的独立负载均衡器上，实现了 XDP 层的多网络设备的负载均衡，这使得在更复杂的环境中也能保持数据包处理性能。 + +## XDP 透明支持 bond 设备 + +[](https://asciinema.org/a/zphe3HfuwbWb6Vu6Un3aTAbRj) + +在很多企业内部或云环境中，节点通常使用 bond 设备，设置外部流量的双端口网卡。随着最近 Cilium 版本的优化，如在 XDP 层的[ kube-proxy 替代](https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer) 或[独立负载均衡器](https://cilium.io/blog/2021/05/20/cilium-110#standalonelb)，我们从用户那里经常收到的一个问题是 XDP 加速是否可以与 bond 网络设备结合使用。虽然 Linux 内核绝大多数 10/40/100Gbit/s 网络驱动程序支持 XDP，但它缺乏在 bond（和 802.3ad）模式下透明操作 XDP 的能力。 + +其中的一个选择是在用户空间实现 802.3ad，并在 XDP 程序实现 bond 负载均衡，但这对 bond 设备管理是一个相当颇为繁琐努力，例如：对 netlink 链路事件的观测，另外还需要为编排器的本地和 bond 分别提供单独的程序。相反，本地内核实现解决了这些问题，提供了更多的灵活性，并且能够处理 eBPF 程序，而不需要改变或重新编译它们。内核负责管理 bond 设备组，可以自动传播 eBPF 程序。对于 v5.15 或更新的内核，我们已经在上游（[part1](https://lore.kernel.org/bpf/20210731055738.16820-1-joamaki@gmail.com/), [part2](https://lore.kernel.org/netdev/20210906085638.1027202-1-joamaki@gmail.com/)）实现了 XDP 对 bond 设备的支持。 + +当 XDP 程序连接到 bond 设备时，`XDP_TX` 的语义等同于 tc eBPF 程序附加到 bond 设备，这意味着从 bond 设备传输数据包使用 bond 配置的传输方法来选择从属设备。故障转移和链路聚合模式均可以在 XDP 操作下使用。对于通过 `XDP_TX` 将数据包从 bond 设备上回传，我们实现了轮循、主动备份、802.3ad 以及哈希设备选择。这种情况对于像 Cilium 这样的发夹式负载均衡器来说特别有意义。 + +## 基于路由的设备检测 + +1.11 版本显著的提升了设备的自动检测，可用于[ 使用 eBPF 替代 kube-proxy](https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer)、[带宽管理器](https://cilium.io/blog/2020/11/10/cilium-19#bwmanager)和[主机防火墙](https://cilium.io/blog/2020/06/22/cilium-18#policy)。 + +在早期版本中，Cilium 自动检测的设备需要有默认路由的设备，和有 Kubernetes NodeIP 的设备。展望未来，现在设备检测是根据主机命名空间的所有路由表的条目来进行的。也就是说，所有非桥接的、非 bond 的和有全局单播路由的非虚拟的设备，现在都能被检测到。 + +通过这项改进，Cilium 现在应该能够在更复杂的网络设置中自动检测正确的设备，而无需使用 `devices` 选项手动指定设备。使用后一个选项时，无法对设备名称进行一致性的命名规范，例如：无法使用共同前缀正则表达式对设备命名。 + +## 服务后端流量的优雅终止 + + + +Kubernetes 可以出于多种原因终止 Pod，如滚动更新、缩容或用户发起的删除。在这种情况下，重要的是要优雅地终止与 Pod 的活跃连接，让应用程序有时间完成请求以最大程度地减少中断。异常连接终止会导致数据丢失，或延迟应用程序的恢复。 + +Cilium agent 通过 "EndpointSlice" API 监听 service 端点更新。当一个 service 端点被终止时，Kubernetes 为该端点设置 `terminating` 状态。然后，Cilium agent 删除该端点的数据路径状态，这样端点就不会被选择用于新的请求，但该端点正在服务的当前连接，可以在用户定义的宽限期内被终止。 + +同时，Kubernetes 告知容器运行时向服务的 Pod 容器发送 `SIGTERM` 信号，并等待终止宽限期的到来。然后，容器应用程序可以启动活跃连接的优雅终止，例如，关闭 TCP 套接字。一旦宽限期结束，Kubernetes 最终通过 `SIGKILL` 信号对仍在 Pod 容器中运行的进程触发强制关闭。这时，agent 也会收到端点的删除事件，然后完全删除端点的数据路径状态。但是，如果应用 Pod 在宽限期结束前退出，Kubernetes 将立即发送删除事件，而不管宽限期设置。 + +更多细节请关注 [docs.cilium.io](https://docs.cilium.io/en/v1.11/gettingstarted/kubeproxy-free/#graceful-termination) 中的指南。 + +## Egress 出口网关的优化 + + + +简单的场景中，Kubernetes 应用只与其他 Kubernetes 应用进行通信，因此流量可通过网络策略等机制进行控制。但现实世界情况并非总是如此，例如：私有部署的一些应用程序没有被容器化，Kubernetes 应用程序需要与集群外的服务进行通信。这些传统服务通常配置的是静态 IP，并受到防火墙规则的保护。那么在此种情况下，应该如何对流量控制和审计呢？ + +Egress 出口 IP 网关功能在 [Cilium 1.10](https://cilium.io/blog/2021/05/20/cilium-110#egressgateway) 中被引入，通过 Kubernetes 节点充当网关用于集群出口流量来解决这类问题。用户使用策略来指定哪些流量应该被转发到网关节点，以及如何转发流量。这种情况下，网关节点将使用静态出口 IP 对流量进行伪装，因此可以在传统防火墙建立规则。 + +```yaml +apiVersion: cilium.io/v2alpha1 +kind: CiliumEgressNATPolicy +metadata: + name: egress-sample +spec: + egress: + - podSelector: + matchLabels: + app: test-app + destinationCIDRs: + - 1.2.3.0/24 + egressSourceIP: 20.0.0.1 +``` + +在上面的示例策略中，带有 `app: test-app` 标签的 Pod 和目标 CIDR 为 `1.2.3.0/24` 的流量，需要通过 `20.0.0.1` 网关节点的出口 IP（SNAT）与集群外部通信。 + +在 Cilium 1.11 开发周期中，我们投入了大量精力来稳定出口网关功能，使其可投入生产。现在， +出口网关现在可以工作在[直接路由](https://github.com/cilium/cilium/pull/17517)，[区分内部流量](https://github.com/cilium/cilium/pull/17639)（即 Kubernetes 重叠地址的 CIDR 的出口策略）及[在不同策略中使用相同出口 IP](https://github.com/cilium/cilium/pull/17773)下。一些问题，如[回复被错误描述为出口流量](https://github.com/cilium/cilium/pull/17869)和[其他](https://github.com/cilium/cilium/pull/17813)等已经修复，同时测试也得到了改进，以便及早发现潜在的问题。 + +## Kubernetes Cgroup 增强 + + + +Cilium 使用 [ eBPF 替代 kube-proxy ](https://cilium.io/blog/2020/06/22/cilium-18#kube-proxy-replacement-at-the-xdp-layer) 作为[独立负载均衡器](https://cilium.io/blog/2021/05/20/cilium-110#standalonelb)的优势之一是能够将 eBPF 程序附加到 socket hooks 上，例如 `connect(2)`、`bind(2)`、`sendmsg(2)` 以及其他各种相关的系统调用，以便透明地将本地的应用程序连接到后端服务。但是这些程序只能被附加到 cgroup v2。虽然 Kubernetes 正在努力迁移到 cgroup v2，但目前绝大多数用户的环境都是 cgroup v1 和 v2 混合使用。 + +Linux 在内核的 socket 对象中标记了 socket 与 cgroup 的关系，并且由于 6 年前的一个设定，cgroup v1 和 v2 的 socket 标签是互斥的。这就意味着，如果一个 socket 是以 cgroup v2 成员身份创建的，但后来通过具有 cgroup v1 成员身份的 `net_prio` 或 `net_cls` 控制器进行了标记，那么 cgroup v2 就不会执行附加在 Pod 子路径上的程序，而是回退执行附加到 cgroup v2 层次结构 (hierarchy) 根部的 eBPF 程序。这样就会导致一个很严重的后果，如果连 cgroup v2 根部都没有附加程序，那么整个 cgroup v2 层次结构 (hierarchy) 都会被绕过。 + +现如今，cgroup v1 和 v2 不能并行运行的假设不再成立，具体可参考今年早些时候的 [Linux Plumbers 会议演讲](https://linuxplumbersconf.org/event/11/contributions/953/)。只有在极少数情况下，当被标记为 cgroup v2 成员身份的 eBPF 程序附加到 cgroup v2 层次结构的子系统时，Kubernetes 集群中的 cgroup v1 网络控制器才会绕过该 eBPF 程序。为了在数据包处理路径上的尽量前面（early）的位置解决这个问题，Cilium 团队最近对 Linux 内核进行了修复，实现了在所有场景下允许两种 cgroup 版本 ([part1](https://lore.kernel.org/bpf/20210913230759.2313-1-daniel@iogearbox.net/), [part2](https://lore.kernel.org/bpf/20210927123921.21535-1-daniel@iogearbox.net/)) 之间相互安全操作。这个修复不仅使 Cilium 的 cgroup 操作完全健壮可靠，而且也造福了 Kubernetes 中所有其他 eBPF cgroup 用户。 + +此外，Kubernetes 和 Docker 等容器运行时最近开始陆续宣布支持 cgroup v2。在 cgroup v2 模式下，Docker 默认会切换到[私有 cgroup 命名空间](https://docs.docker.com/config/containers/runmetrics/#running-docker-on-cgroup-v2)，即每个容器（包括 Cilium）都在自己的私有 cgroup 命名空间中运行。Cilium 通过确保 eBPF 程序附加到正确的 cgroup 层次结构的 socket hooks 上，使 Cilium 基于套接字的负载均衡在 cgroup v2 环境中能正常工作。 + +## 增强负载均衡器的可扩展性 + +> 主要外部贡献者：Weilong Cui (Google) + +最近的测试表明，对于运行着 Cilium 且 Kubernetes Endpoints 超过 6.4 万的大型 Kubernetes 环境，Service 负载均衡器会受到限制。有两个限制因素： + +- Cilium 使用 eBPF 替代 kube-proxy 的独立负载均衡器的本地后端 ID 分配器仍被限制在 16 位 ID 空间内。 +- Cilium 用于 IPv4 和 IPv6 的 eBPF datapath 后端映射所使用的密钥类型被限制在 16 位 ID 空间内。 + +为了使 Kubernetes 集群能够扩展到超过 6.4 万 Endpoints，Cilium 的 ID 分配器以及相关的 datapath 结构已被转换为使用 32 位 ID 空间。 + +## Cilium Endpoint Slices + +> 主要外部贡献者：Weilong Cui (Google), Gobinath Krishnamoorthy (Google) + +在 1.11 版本中，Cilium 增加了对新操作模式的支持，该模式通过更有效的 Pod 信息广播方式大大提高了 Cilium 的扩展能力。 + + + +之前，Cilium 通过 watch `CiliumEndpoint (CEP)` 对象来广播 Pod 的 IP 地址和安全身份信息，这种做法在可扩展性方面会带来一定的挑战。每个 `CEP` 对象的创建/更新/删除都会触发 watch 事件的组播，其规模与集群中 Cilium-agent 的数量呈线性关系，而每个 Cilium-agent 都可以触发这样的扇出动作。如果集群中有 `N` 个节点，总 watch 事件和流量可能会以 `N^2` 的速率二次扩展。 + +Cilium 1.11 引入了一个新的 CRD `CiliumEndpointSlice (CES)`，来自同一命名空间下的 `CEPs` 切片会被 Operator 组合成 `CES` 对象。在这种模式下，Cilium-agents 不再 watch `CEP`，而是 watch `CES`，大大减少了需要经由 `kube-apiserver` 广播的 watch 事件和流量，进而减轻 `kube-apiserver` 的压力，增强 Cilium 的可扩展性。 + +由于 `CEP` 大大减轻了 `kube-apiserver` 的压力，Cilium 现在已经不再依赖专用的 ETCD 实例（KVStore 模式）。对于 Pod 数量剧烈变化的集群，我们仍然建议使用 KVStore，以便将 `kube-apiserver` 中的处理工作卸载到 ETCD 实例中。 + +这种模式权衡了“更快地传播 Endpoint 信息”和“扩展性更强的控制平面”这两个方面，并力求雨露均沾。注意，与 `CEP` 模式相比，在规模较大时，如果 Pod 数量剧烈变化（例如大规模扩缩容），可能会产生较高的 Endpoint 信息传播延迟，从而影响到远程节点。 + +GKE 最早采用了 `CES`，我们在 GKE 上进行了一系列“最坏情况”规模测试，发现 Cilium 在 `CES` 模式下的扩展性要比 `CEP` 模式强很多。从 1000 节点规模的负载测试来看，启用 `CES` 后，watch 事件的峰值从 CEP 的 `18k/s` 降低到 CES 的 `8k/s`，watch 流量峰值从 CEP 的 `36.6Mbps` 降低到 CES 的 `18.1Mbps`。在控制器节点资源使用方面，它将 CPU 的峰值使用量从 28 核/秒减少到 10.5 核/秒。 + + + + + +详情请参考 [Cilium 官方文档](https://docs.cilium.io/en/v1.11/gettingstarted/ciliumendpointslice/)。 + +## Kube-Proxy-Replacement 支持 Istio + + + +许多用户在 Kubernetes 中使用 eBPF 自带的负载均衡器来[替代 kube-proxy](https://docs.cilium.io/en/latest/gettingstarted/kubeproxy-free/)，享受基于 eBPF 的 datapath 带来的[高效处理方式](https://docs.cilium.io/en/v1.10/operations/performance/tuning/#tuning-guide)，避免了 kube-proxy 随着集群规模线性增长的 iptables 规则链条。 + +eBPF 对 Kubernetes Service 负载均衡的处理在架构上分为[两个部分](https://cilium.io/blog/2020/06/22/cilium-18#kubeproxy-removal)： + +- 处理进入集群的外部服务流量（南北方向） +- 处理来自集群内部的服务流量（东西方向） + +在 eBPF 的加持下，Cilium 在南北方向已经实现了尽可能靠近驱动层（例如通过 XDP）完成对每个数据包的处理；东西流量的处理则尽可能靠近 eBPF 应用层，处理方式是将应用程序的请求（例如 TCP `connect(2)`）从 Service 虚拟 IP 直接“连接”到后端 IP 之一，以避免每个数据包的 NAT 转换成本。 + +Cilium 的这种处理方式适用于大多数场景，但还是有一些例外，比如常见的服务网格解决方案（Istio 等）。Istio 依赖 iptables 在 Pod 的网络命名空间中插入额外的重定向规则，以便应用流量在离开 Pod 进入主机命名空间之前首先到达代理 Sidecar（例如 Envoy），然后通过 `SO_ORIGINAL_DST` 从其内部 socket 直接[查询](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/original_dst_filter) Netfilter 连接跟踪器，以收集原始服务目的地址。 + +所以在 Istio 等服务网格场景下，Cilium 改进了对 Pod 之间（东西方向）流量的处理方式，改成基于 eBPF 的 DNAT 完成对每个数据包的处理，而主机命名空间内的应用仍然可以使用基于 socket 的负载均衡器，以避免每个数据包的 NAT 转换成本。 + +要想开启这个特性，只需在新版 Cilium agent 的 Helm Chart 中设置 `bpf-lb-sock-hostns-only: true` 即可。详细步骤请参考 [Cilium 官方文档](https://docs.cilium.io/en/latest/gettingstarted/kubeproxy-free/#socket-loadbalancer-bypass-in-pod-namespace)。 + +## 特性增强与弃用 + +以下特性得到了进一步增强： + +- **主机防火墙** (Host Firewall) 从测试版 (beta) 转为稳定版 (stable)。主机防火墙通过允许 [CiliumClusterwideNetworkPolicies](https://CiliumClusterwideNetworkPolicies) 选择集群节点来保护主机网络命名空间。自从引入主机防火墙功能以来，我们已经大大增加了测试覆盖率，并修复了部分错误。我们还收到了部分社区用户的反馈，他们对这个功能很满意，并准备用于生产环境。 + +以下特性已经被弃用： + +- **Consul** 之前可以作为 Cilium 的 KVStore 后端，现已被弃用，推荐使用更经得起考验的 Etcd 和 Kubernetes 作为 KVStore 后端。之前 Cilium 的开发者主要使用 Consul 进行本地端到端测试，但在最近的开发周期中，已经可以直接使用 Kubernetes 作为后端来测试了，Consul 可以退休了。 +- **IPVLAN** 之前用来作为 veth 的替代方案，用于提供跨节点 Pod 网络通信。在 Cilium 社区的推动下，大大改进了 Linux 内核的性能，目前 veth 已经和 IPVLAN 性能相当。具体可参考这篇文章：[eBPF 主机路由](https://cilium.io/blog/2020/11/10/cilium-19#veth)。 +- **策略追踪 (Policy Tracing)** 在早期 Cilium 版本中被很多 Cilium 用户使用，可以通过 Pod 中的命令行工具 `cilium policy trace` 来执行。然而随着时间的推移，它没有跟上 Cilium 策略引擎的功能进展。Cilium 现在提供了更好的工具来追踪 Cilium 的策略，例如[网络策略编辑器](https://app.networkpolicy.io/)和 [Policy Verdicts](https://cilium.io/blog/2020/06/22/cilium-18#policyverdicts)。 \ No newline at end of file diff --git a/content/zh/blogs/create-pipeline-across-multi-clusters.md b/content/zh/blogs/create-pipeline-across-multi-clusters.md index 2de385f25..834253eaf 100644 --- a/content/zh/blogs/create-pipeline-across-multi-clusters.md +++ b/content/zh/blogs/create-pipeline-across-multi-clusters.md @@ -121,7 +121,7 @@ pipeline { REGISTRY = 'docker.io' DOCKERHUB_NAMESPACE = 'shaowenchen' - APP_NAME = 'devops-java-sample' + APP_NAME = 'devops-maven-sample' SONAR_CREDENTIAL_ID = 'sonar-token' TAG_NAME = "SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER" } @@ -129,16 +129,15 @@ pipeline { stage('checkout') { steps { container('maven') { - git branch: 'master', url: 'https://github.com/kubesphere/devops-java-sample.git' + git branch: 'master', url: 'https://github.com/kubesphere/devops-maven-sample.git' } } } stage('unit test') { steps { container('maven') { - sh 'mvn clean -o -gs `pwd`/configuration/settings.xml test' + sh 'mvn clean test' } - } } stage('sonarqube analysis') { @@ -146,7 +145,7 @@ pipeline { container('maven') { withCredentials([string(credentialsId: "$SONAR_CREDENTIAL_ID", variable: 'SONAR_TOKEN')]) { withSonarQubeEnv('sonar') { - sh "mvn sonar:sonar -o -gs `pwd`/configuration/settings.xml -Dsonar.login=$SONAR_TOKEN" + sh "mvn sonar:sonar -Dsonar.login=$SONAR_TOKEN" } } @@ -157,7 +156,7 @@ pipeline { stage('build & push') { steps { container('maven') { - sh 'mvn -o -Dmaven.test.skip=true -gs `pwd`/configuration/settings.xml clean package' + sh 'mvn -Dmaven.test.skip=true clean package' sh 'docker build -f Dockerfile-online -t $REGISTRY/$DOCKERHUB_NAMESPACE/$APP_NAME:SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER .' withCredentials([usernamePassword(passwordVariable : 'DOCKER_PASSWORD' ,usernameVariable : 'DOCKER_USERNAME' ,credentialsId : "$DOCKER_CREDENTIAL_ID" ,)]) { sh 'echo "$DOCKER_PASSWORD" | docker login $REGISTRY -u "$DOCKER_USERNAME" --password-stdin' @@ -179,19 +178,37 @@ pipeline { } stage('deploy to dev') { steps { - kubernetesDeploy(configs: 'deploy/dev-ol/**', enableConfigSubstitution: true, kubeconfigId: "$DEV_KUBECONFIG_CREDENTIAL_ID") + withCredentials([ + kubeconfigFile( + credentialsId: env.DEV_KUBECONFIG_CREDENTIAL_ID, + variable: 'KUBECONFIG') + ]) { + sh 'envsubst < deploy/dev-all-in-one/devops-sample.yaml | kubectl apply -f -' + } } } stage('deploy to staging') { steps { input(id: 'deploy-to-staging', message: 'deploy to staging?') - kubernetesDeploy(configs: 'deploy/prod-ol/**', enableConfigSubstitution: true, kubeconfigId: "$TEST_KUBECONFIG_CREDENTIAL_ID") + withCredentials([ + kubeconfigFile( + credentialsId: env.TEST_KUBECONFIG_CREDENTIAL_ID, + variable: 'KUBECONFIG') + ]) { + sh 'envsubst < deploy/prod-all-in-one/devops-sample.yaml | kubectl apply -f -' + } } } stage('deploy to production') { steps { input(id: 'deploy-to-production', message: 'deploy to production?') - kubernetesDeploy(configs: 'deploy/prod-ol/**', enableConfigSubstitution: true, kubeconfigId: "$PROD_KUBECONFIG_CREDENTIAL_ID") + withCredentials([ + kubeconfigFile( + credentialsId: env.PROD_KUBECONFIG_CREDENTIAL_ID, + variable: 'KUBECONFIG') + ]) { + sh 'envsubst < deploy/prod-all-in-one/devops-sample.yaml | kubectl apply -f -' + } } } } diff --git a/content/zh/blogs/debugging-envoy-and-istio.md b/content/zh/blogs/debugging-envoy-and-istio.md new file mode 100644 index 000000000..a253a44e3 --- /dev/null +++ b/content/zh/blogs/debugging-envoy-and-istio.md @@ -0,0 +1,741 @@ +--- +title: 'Istio 无法访问外部服务的故障排查' +tag: 'Kubernetes,Istio,Envoy' +keywords: 'Kubernetes, Istio, Envoy, Sidecar, istio-proxy' +description: '本文以一次生产事故为例，详细分析了 Istio 无法访问外部服务的原因，并给出了多种可选的解决方案。' +createTime: '2021-09-17' +author: '龙小虾' +snapshot: 'https://kubesphere-community.pek3b.qingstor.com/images/istio-debug.png' +--- + +## 事故起因 + +业务上新集群，本来以为"洒洒水"，11 点切，12 点就能在家睡觉了。流量切过来后，在验证过程中，发现网页能够正常打开，在登录时返回了 502，当场懵逼。在相关的容器日志发现一个高频的报错条目“7000 端口无法连接”，向业务组了解到这是 redis 集群中的一个端口，前后端是通过 redis 交互的，该集群同时还有 7001-7003 其它三个端口。 + +用 nc 命令对 redis 集群进行连接测试：向服务端发送 `keys *` 命令时，7000 端口返回的是 `HTTP/1.1 400 Bad Request`，其他三个端口是 redis 返回的 `-NOAUTH Authentication required`。 + +```bash +$ nc 10.0.0.6 7000 +keys * +HTTP/1.1 400 Bad Request +content-length: 0 +connection: close + +$ nc 10.0.0.6 7003 +keys * +-NOAUTH Authentication required +``` + +判断 7000 端口连接到了其他应用上，至少不是 redis。在宿主机上抓包发现没有抓到访问 7000 端口的流量，然后查看容器的 nf_conntrackb 表，发现 7000 端口的数据只有到本地的会话信息；7003 的有两条会话信息，一条到本机的，一条到目标服务器的。 + +```bash +$ grep 7000 /proc/net/nf_conntrack +ipv4 2 tcp 6 110 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=50498 dport=7000 src=127.0.0.1 dst=10.64.192.14 sport=15001 dport=50498 [ASSURED] mark=0 zone=0 use=2 + +$ grep 7003 /proc/net/nf_conntrack +ipv4 2 tcp 6 104 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=38952 dport=7003 src=127.0.0.1 dst=10.64.192.14 sport=15001 dport=38952 [ASSURED] mark=0 zone=0 use=2 +ipv4 2 tcp 6 104 TIME_WAIT src=10.64.192.14 dst=10.0.0.6 sport=38954 dport=7003 src=10.0.0.6 dst=10.64.192.14 sport=7003 dport=38954 [ASSURED] mark=0 zone=0 use=2 +``` + +由此判断出 istio 没有代理转发出 7000 的流量，这突然就触及到了我的知识盲区，一大堆人看着，办公室 26 度的空调，一直在冒汗。没办法了，在与业务商量后，只能先关闭 istio 注入，优先恢复了业务。回去后恶补 istio 的相关资料。终于将问题解决。记录下相关信息，以供日后参考。 + +## 背景知识补充 + +### istio Sidecar 的模式 + +istio 的 Sidecar 有两种模式： + +- **ALLOW_ANY**：istio 代理允许调用未知的服务，黑名单模式。 +- **REGISTRY_ONLY**：istio 代理会阻止任何没有在网格中定义的 HTTP 服务或 service entry 的主机，白名单模式。 + +### istio-proxy（Envoy）的配置结构 + +istio-proxy（Envoy）的代理信息大体由以下几个部分组成： + +- **Cluster**：在 Envoy 中，Cluster 是一个服务集群，Cluster 中包含一个到多个 endpoint，每个 endpoint 都可以提供服务，Envoy 根据负载均衡算法将请求发送到这些 endpoint 中。cluster 分为 inbound 和 outbound 两种，前者对应 Envoy 所在节点上的服务；后者占了绝大多数，对应 Envoy 所在节点的外部服务。可以使用如下方式分别查看 inbound 和 outbound 的 cluster。 +- **Listeners**：Envoy 采用 listener 来接收并处理 downstream 发过来的请求，可以直接与 Cluster 关联，也可以通过 rds 配置路由规则(Routes)，然后在路由规则中再根据不同的请求目的地对请求进行精细化的处理。 +- **Routes**：配置 Envoy 的路由规则。istio 下发的缺省路由规则中对每个端口(服务)设置了一个路由规则，根据 host 来对请求进行路由分发，routes 的目的为其他服务的 cluster。 +- **Endpoint**：cludter 对应的后端服务，可以通过 istio pc endpoint 查看 inbound 和 outbound 对应的 endpoint 信息。 + +### 服务发现类型 + +cluster 的服务发现类型主要有： + +- **ORIGINAL_DST**：类型的 Cluster，Envoy 在转发请求时会直接采用 downstream 请求中的原始目的地 IP 地址 +- **EDS**：EDS 获取到该 Cluster 中所有可用的 Endpoint，并根据负载均衡算法（缺省为 Round Robin）将 Downstream 发来的请求发送到不同的 Endpoint。**istio 会自动为集群中的 service 创建代理信息，listener 的信息从 service 获取，对应的 cluster 被标记为 EDS 类型** +- **STATIC**：缺省值，在集群中列出所有可代理的主机 Endpoints。当没有内容为空时，不进行转发。 +- **LOGICAL_DNS**：Envoy 使用 DNS 添加主机，但如果 DNS 不再返回时，也不会丢弃。 +- **STRICT_DNS**：Envoy 将监控 DNS，而每个匹配的 A 记录都将被认为是有效的。 + +### 两个特殊集群 + +**BlackHoleCluster**：黑洞集群，匹配此集群的流量将被不会被转发。 + +```json +{ + "name": "BlackHoleCluster", + "type": "STATIC", + "connectTimeout": "10s" +} +``` + +类型为 static，但是没有指定可代理的 Endpoint，所以流量不会被转发。 + +**PassthroughCluster**：透传集群，匹配此集群的流量数据包的目的 IP 不会改变。 + +```json +{ + "name": "PassthroughCluster", + "type": "ORIGINAL_DST", + "connectTimeout": "10s", + "lbPolicy": "CLUSTER_PROVIDED", + "circuitBreakers": { + "thresholds": [ + { + "maxConnections": 4294967295, + "maxPendingRequests": 4294967295, + "maxRequests": 4294967295, + "maxRetries": 4294967295 + } + ] + } +``` + +类型为 original_dst，流量将原样转发。 + +### 一个特殊的 Listener + +istio 中有一个特殊的 Listener 叫 **virtualOutbound**，定义如下： + +- **virtualOutbound**：每个 Sidecar 都有一个绑定到 0.0.0.0:15001 的 listener，该 listener 下关联了许多 virtual listener。iptables 会先将所有出站流量导入该 listener，该 listener 有一个字段 useOriginalDst 设置为 true，表示会使用最佳匹配原始目的地的方式将请求分发到 virtual listener，如果没有找到任何 virtual listener，将会直接发送到数据包原目的地的 PassthroughCluster。 + +useOriginalDst 字段的具体意义是，如果使用 iptables 重定向连接，则代理接收流量的目标地址可能与原始目标地址不同。当此标志设置为 **true** 时，侦听器会将重定向流量**转交给与原始目标地址关联的侦听器**。如果没有与原始目标地址关联的侦听器，则流量由接收它的侦听器处理。默认为 false。 + +virtualOutbound 的流量处理流程如图所示： + + + +这是 virtualOutbound 的部分配置： + +```json +{ + "name": "envoy.tcp_proxy", + "typedConfig": { + "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy", + "statPrefix": "PassthroughCluster", + "cluster": "PassthroughCluster" + } +} +…………… +"useOriginalDst": true +``` + +## istio 的 outbond 流量处理 + +开启流量治理后，pod 访问外部资源的流量转发路径如图所示： + + + +istio 注入后 istio-proxy 有一个监听在 15001 的端口，所有非 istio-proxy 用户进程产生的 outbond 流量，通过 iptables 规则被重定向到 15001。 + +```bash +# Sidecar 注入的 pod 监听的端口 +$ ss -tulnp +State Recv-Q Send-Q Local Address:Port Peer Address:Port +LISTEN 0 128 *:80 *:* +LISTEN 0 128 *:15090 *:* +LISTEN 0 128 127.0.0.1:15000 *:* +LISTEN 0 128 *:15001 *:* +LISTEN 0 128 *:15006 *:* +LISTEN 0 128 [::]:15020 [::]:* + +# Pod 内部的 iptables 表项 +$ iptables-save +# Generated by iptables-save v1.4.21 on Fri Sep 17 13:47:09 2021 +*nat +:PREROUTING ACCEPT [129886:7793160] +:INPUT ACCEPT [181806:10908360] +:OUTPUT ACCEPT [53409:3257359] +:POSTROUTING ACCEPT [53472:3261139] +:istio_INBOUND - [0:0] +:istio_IN_REDIRECT - [0:0] +:istio_OUTPUT - [0:0] +:istio_REDIRECT - [0:0] +-A PREROUTING -p tcp -j istio_INBOUND +-A OUTPUT -p tcp -j istio_OUTPUT +-A istio_INBOUND -p tcp -m tcp --dport 22 -j RETURN +-A istio_INBOUND -p tcp -m tcp --dport 15020 -j RETURN +-A istio_INBOUND -p tcp -j istio_IN_REDIRECT +-A istio_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15006 +-A istio_OUTPUT -s 127.0.0.6/32 -o lo -j RETURN +-A istio_OUTPUT ! -d 127.0.0.1/32 -o lo -j istio_IN_REDIRECT +-A istio_OUTPUT -m owner --uid-owner 1337 -j RETURN +-A istio_OUTPUT -m owner --gid-owner 1337 -j RETURN +-A istio_OUTPUT -d 127.0.0.1/32 -j RETURN +-A istio_OUTPUT -j istio_REDIRECT +-A istio_REDIRECT -p tcp -j REDIRECT --to-ports 15001 +COMMIT +# Completed on Fri Sep 17 13:47:09 2021 +``` + +istio-proxy 收到流量后，大致的处理步骤如下： + + + +- Proxy 在 ALLOW_ANY 模式下没有匹配上 listener 将被直接转发 +- listener 关联了 type 为 ORIGINAL_DST 的 cluster 将使用原始请求种的 IP 地址 +- 匹配上了 BlackHoleCluster，将不会被转发 + +被代理流量的匹配步骤大致如下： + + + +> 疑问：isito 为 svc 创建的 listener 地址是全零的，集群内部的端口是会存在复用的，那 istio 到底是怎么区分流量的呢？ + +关键就在于 route，route 由 virtual_host 条目组成，这些 virtual_host 条目就是根据 svc 的信息生成的，访问集群内部的 svc 时，在 route 里可以根据域名或者 svc 对应的 virtual_ip 进行精确匹配，所以完全不需要担心啦。 + +```bash +$ kubectl get svc -A | grep 8001 +NodePort 10.233.34.158
+> **译者：狄卫华**
+> **注：本文已取得作者本人的翻译授权** + +## 1. 前言 + +**有兴趣了解更多关于 eBPF 技术的底层细节？那么请继续移步，我们将深入研究 eBPF 的底层细节，从其虚拟机机制和工具，到在远程资源受限的嵌入式设备上运行跟踪。** + +注意：本系列博客文章将集中在 eBPF 技术，因此对于我们来讲，文中 BPF 和 eBPF 等同，可相互使用。BPF 名字/缩写已经没有太大的意义，因为这个项目的发展远远超出了它最初的范围。BPF 和 eBPF 在该系列中会交替使用。 + +- [第 1 部分](https://www.collabora.com/news-and-blog/blog/2019/04/05/an-ebpf-overview-part-1-introduction/)和[第 2 部分](https://www.collabora.com/news-and-blog/blog/2019/04/15/an-ebpf-overview-part-2-machine-and-bytecode/) 为新人或那些希望通过深入了解 eBPF 技术栈的底层技术来进一步了解 eBPF 技术的人提供了深入介绍。 +- [第 3 部分](https://www.collabora.com/news-and-blog/blog/2019/04/26/an-ebpf-overview-part-3-walking-up-the-software-stack/)是对用户空间工具的概述，旨在提高生产力，建立在第 1 部分和第 2 部分中介绍的底层虚拟机机制之上。 +- [第 4 部分](https://www.collabora.com/news-and-blog/blog/2019/05/06/an-ebpf-overview-part-4-working-with-embedded-systems/)侧重于在资源有限的嵌入式系统上运行 eBPF 程序，在嵌入式系统中完整的工具链技术栈（BCC/LLVM/python 等）是不可行的。我们将使用占用资源较小的嵌入式工具在 32 位 ARM 上交叉编译和运行 eBPF 程序。只对该部分感兴趣的读者可选择跳过其他部分。 +- [第 5 部分](https://www.collabora.com/news-and-blog/blog/2019/05/14/an-ebpf-overview-part-5-tracing-user-processes/)是关于用户空间追踪。到目前为止，我们的努力都集中在内核追踪上，所以是时候我们关注一下用户进程了。 + +如有疑问时，可使用该流程图： + + + +## 2. eBPF 是什么？ + +eBPF 是一个基于寄存器的虚拟机，使用自定义的 64 位 RISC 指令集，能够在 Linux 内核内运行即时本地编译的 "BPF 程序"，并能访问内核功能和内存的一个子集。这是一个完整的虚拟机实现，不要与基于内核的虚拟机（KVM）相混淆，后者是一个模块，目的是使 Linux 能够作为其他虚拟机的管理程序。eBPF 也是主线内核的一部分，所以它不像其他框架那样需要任何第三方模块（[LTTng](https://lttng.org/docs/v2.10/#doc-lttng-modules) 或 [SystemTap](https://kernelnewbies.org/SystemTap)），而且几乎所有的 Linux 发行版都默认启用。熟悉 DTrace 的读者可能会发现 [DTrace/BPFtrace 对比](http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux-2018.html)非常有用。 + +在内核内运行一个完整的虚拟机主要是考虑便利和安全。虽然 eBPF 程序所做的操作都可以通过正常的内核模块来处理，但直接的内核编程是一件非常危险的事情 - 这可能会导致系统锁定、内存损坏和进程崩溃，从而导致安全漏洞和其他意外的效果，特别是在生产设备上（eBPF 经常被用来检查生产中的系统），所以通过一个安全的虚拟机运行本地 JIT 编译的快速内核代码对于安全监控和沙盒、网络过滤、程序跟踪、性能分析和调试都是非常有价值的。部分简单的样例可以在这篇优秀的 [eBPF 参考](http://www.brendangregg.com/ebpf.html)中找到。 + +基于设计，eBPF 虚拟机和其程序有意地设计为**不是**图灵完备的：即不允许有循环（正在进行的工作是支持有界循环【译者注：已经支持有界循环，\#pragma unroll 指令】），所以每个 eBPF 程序都需要保证完成而不会被挂起、所有的内存访问都是有界和类型检查的（包括寄存器，一个 MOV 指令可以改变一个寄存器的类型）、不能包含空解引用、一个程序必须最多拥有 BPF_MAXINSNS 指令（默认 4096）、"主"函数需要一个参数（context）等等。当 eBPF 程序被加载到内核中，其指令被验证模块解析为有向环状图，上述的限制使得正确性可以得到简单而快速的验证。 + +> 译者注： BPF_MAXINSNS 这个限制已经被放宽至 100 万条指令（BPF_COMPLEXITY_LIMIT_INSNS），但是非特权执行的 BPF 程序这个限制仍然会保留。 + +历史上，eBPF (cBPF) 虚拟机只在内核中可用，用于过滤网络数据包，与用户空间程序没有交互，因此被称为 "伯克利数据包过滤器"【译者注：早期的 BPF 实现被称为经典 cBPF】。从内核 v3.18（2014 年）开始，该虚拟机也通过 [bpf() syscall](https://github.com/torvalds/linux/blob/v4.20/tools/lib/bpf) 和[uapi/linux/bpf.h](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h) 暴露在用户空间，这导致其指令集在当时被冻结，成为公共 ABI，尽管后来仍然可以（并且已经）添加新指令。 + +因为内核内的 eBPF 实现是根据 GPLv2 授权的，它不能轻易地被非 GPL 用户重新分发，所以也有一个替代的 Apache 授权的用户空间 eBPF 虚拟机实现，称为 "uBPF"。撇开法律条文不谈，基于用户空间的实现对于追踪那些需要避免内核-用户空间上下文切换成本的性能关键型应用很有用。 + + + +## 3. eBPF 是怎么工作的？ + +eBPF 程序在事件触发时由内核运行，所以可以被看作是一种函数挂钩或事件驱动的编程形式。从用户空间运行按需 eBPF 程序的价值较小，因为所有的按需用户调用已经通过正常的非 VM 内核 API 调用（"syscalls"）来处理，这里 VM 字节码带来的价值很小。事件可由 kprobes/uprobes、tracepoints、dtrace probes、socket 等产生。这允许在内核和用户进程的指令中钩住（hook）和检查任何函数的内存、拦截文件操作、检查特定的网络数据包等等。一个比较好的参考是 [Linux 内核版本对应的 BPF 功能](https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md)。 + +如前所述，事件触发了附加的 eBPF 程序的执行，后续可以将信息保存至 map 和环形缓冲区（ringbuffer）或调用一些特定 API 定义的内核函数的子集。一个 eBPF 程序可以链接到多个事件，不同的 eBPF 程序也可以访问相同的 map 以共享数据。一个被称为 "program array" 的特殊读/写 map 存储了对通过 bpf() 系统调用加载的其他 eBPF 程序的引用，在该 map 中成功的查找则会触发一个跳转，而且并不返回到原来的 eBPF 程序。这种 eBPF 嵌套也有限制，以避免无限的递归循环。 + +运行 eBPF 程序的步骤： + +1. 用户空间将字节码和程序类型一起发送到内核，程序类型决定了可以访问的内核区域【译者注：主要是 BPF 帮助函数的各种子集】。 +2. 内核在字节码上运行验证器，以确保程序可以安全运行（kernel/bpf/verifier.c）。 +3. 内核将字节码编译为本地代码，并将其插入（或附加到）指定的代码位置。【译者注：如果启用了 JIT 功能，字节码编译为本地代码】。 +4. 插入的代码将数据写入环形缓冲区或通用键值 map。 +5. 用户空间从共享 map 或环形缓冲区中读取结果值。 + +map 和环形缓冲区结构是由内核管理的（就像管道和 FIFO 一样），独立于挂载的 eBPF 或访问它们的用户程序。对 map 和环形缓冲区结构的访问是异步的，通过文件描述符和引用计数实现，可确保只要有至少一个程序还在访问，结构就能够存在。加载的 JIT 后代码通常在加载其的用户进程终止时被删除，尽管在某些情况下，它仍然可以在加载进程的生命期之后继续存在。 + +为了方便编写 eBPF 程序和避免进行原始的 bpf()系统调用，内核提供了方便的 [libbpf 库](https://github.com/torvalds/linux/blob/v4.20/tools/lib/bpf)，包含系统调用函数包装器，如 [bpf_load_program](https://github.com/torvalds/linux/blob/v4.20/tools/lib/bpf/bpf.c#L214) 和结构定义（如 [bpf_map](https://github.com/torvalds/linux/blob/v4.20/tools/lib/bpf/libbpf.c#L157)），在 LGPL 2.1 和 BSD 2-Clause 下双重许可，可以静态链接或作为 DSO。内核代码也提供了一些使用 libbpf 简洁的例子，位于目录 [samples/bpf/](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/) 中。 + + + +## 4. 样例学习 + +内核开发者非常可怜，因为内核是一个独立的项目，因而没有用户空间诸如 Glibc、LLVM、JavaScript 和 WebAssembly 诸如此类的好东西! - 这就是为什么内核中 eBPF 例子中会包含原始字节码或通过 libbpf 加载预组装的字节码文件。我们可以在 [sock_example.c](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c) 中看到这一点，这是一个简单的用户空间程序，使用 eBPF 来计算环回接口上统计接收到 TCP、UDP 和 ICMP 协议包的数量。 + +我们跳过微不足道的的 [main](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L98) 和 [open_raw_sock](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.h#L13) 函数，而专注于神奇的代码 [test_sock](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L35)。 + +```c +static int test_sock(void) +{ + int sock = -1, map_fd, prog_fd, i, key; + long long value = 0, tcp_cnt, udp_cnt, icmp_cnt; + + map_fd = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(key), sizeof(value), 256, 0); + if (map_fd < 0) {printf("failed to create map'%s'\n", strerror(errno)); + goto cleanup; + } + + struct bpf_insn prog[] = {BPF_MOV64_REG(BPF_REG_6, BPF_REG_1), + BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */), + BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */ + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */ + BPF_LD_MAP_FD(BPF_REG_1, map_fd), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2), + BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */ + BPF_RAW_INSN(BPF_STX | BPF_XADD | BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0), /* xadd r0 += r1 */ + BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */ + BPF_EXIT_INSN(),}; + size_t insns_cnt = sizeof(prog) / sizeof(struct bpf_insn); + + prog_fd = bpf_load_program(BPF_PROG_TYPE_SOCKET_FILTER, prog, insns_cnt, + "GPL", 0, bpf_log_buf, BPF_LOG_BUF_SIZE); + if (prog_fd < 0) {printf("failed to load prog'%s'\n", strerror(errno)); + goto cleanup; + } + + sock = open_raw_sock("lo"); + + if (setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd, sizeof(prog_fd)) < 0) {printf("setsockopt %s\n", strerror(errno)); + goto cleanup; + } +``` + +首先，通过 libbpf API 创建一个 BPF map，该行为就像一个最大 256 个元素的固定大小的数组。按 [IPROTO_*](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/in.h#L28) 定义的键索引网络协议（2 字节的 word），值代表各自的数据包计数（4 字节大小）。除了数组，eBPF 映射还实现了[其他数据结构类型](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L113)，如栈或队列。 + +接下来，eBPF 的字节码指令数组使用方便的[内核宏](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/bpf_insn.h)进行定义。在这里，我们不会讨论字节码的细节（这将在第 2 部分描述机器后进行）。更高的层次上，字节码从数据包缓冲区中读取协议字，在 map 中查找，并增加特定的数据包计数。 + +然后 BPF 字节码被加载到内核中，并通过 libbpf 的 bpf_load_program 返回 fd 引用来验证正确/安全。调用指定了 eBPF [程序类型](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L138)，这决定了它可以访问哪些内核子集。因为样例是一个 SOCKET_FILTER 类型，因此提供了一个指向当前网络包的参数。最后，eBPF 的字节码通过套接字层被附加到一个特定的原始套接字上，之后在原始套接字上接受到的每一个数据包运行 eBPF 字节码，无论协议如何。 + +剩余的工作就是让用户进程开始轮询共享 map 的数据。 + +```c + for (i = 0; i < 10; i++) { + key = IPPROTO_TCP; + assert(bpf_map_lookup_elem(map_fd, &key, &tcp_cnt) == 0); + + key = IPPROTO_UDP; + assert(bpf_map_lookup_elem(map_fd, &key, &udp_cnt) == 0); + + key = IPPROTO_ICMP; + assert(bpf_map_lookup_elem(map_fd, &key, &icmp_cnt) == 0); + + printf("TCP %lld UDP %lld ICMP %lld packets\n", + tcp_cnt, udp_cnt, icmp_cnt); + sleep(1); + } +} +``` + + + +## 5. 总结 + +第 1 部分介绍了 eBPF 的基础知识，我们通过如何加载字节码和与 eBPF 虚拟机通信的例子进行了讲述。由于篇幅限制，编译和运行例子作为留给读者的练习。我们也有意不去分析具体的 eBPF 字节码指令，因为这将是第 2 部分的重点。在我们研究的例子中，用户空间通过 libbpf 直接用 C 语言从内核虚拟机中读取 eBPF map 值（使用 10 次 1 秒的睡眠！），这很笨重，而且容易出错，而且很快就会变得很复杂，所以在第 3 部分，我们将研究更高级别的工具，通过脚本或特定领域的语言自动与虚拟机交互。 diff --git a/content/zh/blogs/ebpf-machine-bytecode.md b/content/zh/blogs/ebpf-machine-bytecode.md new file mode 100644 index 000000000..dc6548498 --- /dev/null +++ b/content/zh/blogs/ebpf-machine-bytecode.md @@ -0,0 +1,133 @@ +--- +title: 'eBPF 概述，第 2 部分：机器和字节码' +tag: 'eBPF' +keywords: 'eBPF' +description: '本系列的第二部分更深入地研究了第一部分中研究的 eBPF VM 和程序。' +createTime: '2021-10-21' +author: 'Adrian Ratiu' +snapshot: 'https://kubesphere-community.pek3b.qingstor.com/images/ebpf-guide-cover.png' +--- + +> 原文链接： https://www.collabora.com/news-and-blog/blog/2019/04/15/an-ebpf-overview-part-2-machine-and-bytecode/ + +> **作者：Adrian Ratiu**
+> **译者：狄卫华**
+> **注：本文已取得作者本人的翻译授权** + +在我们的[第一篇文章](https://kubesphere.com.cn/blogs/ebpf-guide/)中，我们介绍了 eBPF VM、它刻意的设计限制以及如何从用户空间进程与其交互。如果您还没有阅读它，您可能需要在继续阅读本篇文章之前阅读上一篇文章，因为如果没有适当了解，直接从机器和字节码细节开始学习可能会很困难。如有疑问，请参阅第一部分开头的流程图。 + +本系列的第二部分更深入地研究了第一部分中研究的 eBPF VM 和程序。掌握这种底层知识不是强制性的，但对于本系列的其余部分来说是非常有用的基础，我们将在其中检查建立在这些机制之上的更高级别的工具。 + +## 虚拟机 +eBPF 是一个 RISC 寄存器机，共有 [11 个 64 位寄存器](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L45)，一个程序计数器和一个 512 字节固定大小的堆栈。九个寄存器是通用读写的，一个是只读堆栈指针，程序计数器是隐式的，即我们只能跳转到计数器的某个偏移量。VM 寄存器始终为 64 位宽（即使在 32 位 ARM 处理器内核中运行！）并且如果最高有效的 32 位为零，则支持 32 位子寄存器寻址 - 这将在第四部分在嵌入式设备上交叉编译和运行 eBPF 程序非常有用。 + +这些寄存器是： + +| | | +| -------- | -------- | +| r0： | 存储函数调用和当前程序退出代码的返回值 | +|r1 - r5： |作为函数调用的参数，在程序开始时 r1 包含 “上下文” 参数指针 | +|r6 - r9： |这些在内核函数调用之间被保留 | +|r10： | 每个 eBPF 程序512字节堆栈的只读指针 | + +在加载时提供的 eBPF [程序类型](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L136)准确地决定了哪些内核函数子集可以调用，以及在程序启动时通过 r1 提供的 “上下文” 参数。r0 中存储的程序退出值的含义也是由程序类型决定的。 + +每个函数调用在寄存器 r1 - r5 中最多可以有 5 个参数；这适用于 eBPF 到 eBPF 和内核函数的调用。寄存器 r1 - r5 只能存储数字或指向堆栈的指针（作为参数传递给函数），从不直接指向任意内存的指针。所有内存访问都必须先将数据加载到 eBPF 堆栈中，然后才能在 eBPF 程序中使用它。此限制有助于 eBPF 验证器，它简化了内存模型以实现更轻松的正确性检查。 + +BPF 可访问的内核“辅助”函数由内核核心（不可通过模块扩展）通过类似于定义系统调用的 API 定义，使用 [BPF_CALL_*](https://github.com/torvalds/linux/blob/v4.20/include/linux/filter.h#L441) 宏。[bpf.h](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L420) 试图为所有 BPF 可访问的内核“辅助”函数提供参考。例如 [bpf_trace_printk](https://github.com/torvalds/linux/blob/v4.20/kernel/trace/bpf_trace.c#L163) 的定义使用 BPF_CALL_5 和 5 对类型/参数名称。定义[参数数据类型](https://github.com/torvalds/linux/blob/v4.20/kernel/trace/bpf_trace.c#L276)很重要，因为在每个 eBPF 程序加载时，eBPF 验证器确保寄存器数据类型与被调用方参数类型匹配。 + +eBPF 指令也是固定大小的 64 位编码，大约 100 条指令（目前...）分为 [8 类](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf_common.h#L5)。VM 支持来自通用内存（ map 、堆栈、“上下文”如数据包缓冲区等）的 1 - 8 字节加载/存储、向前/向后（非）条件跳转、算术/逻辑运算和函数调用。如需深入了解操作码格式，请参阅 Cilium 项目[指令集文档](https://cilium.readthedocs.io/en/latest/bpf/#instruction-set)。IOVisor 项目还维护了一个有用的[指令规范](https://github.com/iovisor/bpf-docs/blob/master/eBPF.md)。 + +在本系列第一部分研究的示例中，我们使用了一些有用的[内核宏](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/bpf_insn.h)来使用以下[结构](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/bpf.h#L64)创建 eBPF 字节码指令数组（所有指令都以这种方式编码）： + +```c +struct bpf_insn { + __u8 代码；/* opcode */ + __u8 dst_reg:4; /* dest register */ + __u8 src_reg:4; /* source register */ + __s16 off; /* signed offset */ + __s32 imm; /* signed immediate constant */ +}; + +msb lsb ++------------------------+----------------+----+----+--------+ +|immediate |offset |src |dst |opcode | ++------------------------+----------------+----+----+--------+ +``` + +让我们看一下 [BPF_JMP_IMM](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/bpf_insn.h#L167) 指令，它针对立即值对条件跳转进行编码。下面的宏注释对指令逻辑应该是不言自明的。操作码编码指令类 BPF_JMP 、操作（通过 BPF_OP 位域传递以确保正确性）和表示它是对立即数/常量值 BPF_K 的操作的标志进行编码。 + +```c +#define BPF_OP(code) ((code) & 0xf0) +#define BPF_K 0x00 + +/* 针对立即数的条件跳转，if (dst_reg 'op' imm32) goto pc + off16 */ + +#define BPF_JMP_IMM(OP, DST, IMM, OFF) \ + ((struct bpf_insn) { \ + .code = BPF_JMP | BPF_OP(OP) | BPF_K, \ + .dst_reg = DST, \ + .src_reg = 0 + , \ + .off = OFF, \ .imm = IMM }) + +``` + +如果我们计算值或反汇编包含 BPF_JMP_IMM ( BPF_JEQ , BPF_REG_0 , 0 , 2 ) 的 eBPF 字节码二进制文件，我们会发现它是 0x020015 格式。这个特定的字节码非常频繁地用于测试存储在 r0 中的函数调用的返回值；如果 r0 == 0，它会跳过接下来的 2 条指令。 + +## 重温我们的字节码 +现在我们已经掌握了必要的知识来完全理解本系列第一部分中使用的字节码 eBPF 示例，我们将逐步解释它。请记住，[sock_example.c](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c) 是一个简单的用户态程序，它使用 eBPF 来计算在环回接口上接收到的 TCP、UDP 和 ICMP 协议数据包的数量。 + +在高层次上，代码所做的是从接收到的数据包中读取协议编号，然后将其推送到 eBPF 堆栈上，用作 map_lookup_elem 调用的索引，该调用获取相应协议的数据包计数。map_lookup_elem 函数采用 r0 中的索引（或键）指针和 r1 中的 map 文件描述符。如果查找调用成功，r0 将包含一个指向存储在协议索引处的 map 值的指针。然后我们原子地增加 map 值并退出。 + +`BPF_MOV64_REG(BPF_REG_6, BPF_REG_1),` + +当 eBPF 程序启动时，上下文（在这种情况下是数据包缓冲区）由 r1 中的地址指向。r1 将在函数调用期间用作参数，因此我们也将其存储在 r6 中作为备份。 + +`BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol) /* R0 = ip->proto */),` + +该指令将一个字节（ BPF_B ）从上下文缓冲区（在本例中为网络数据包缓冲区）中的偏移量加载到 r0 中，因此我们提供要加载到 r0 的 [iphdr 结构](https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/ip.h#L86)中的协议字节的偏移量。 + +`BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */` + +将包含先前读取的协议的字 ( BPF_W ) 压入堆栈（由 r10 指向，以偏移量 -4 字节开头）。 + +```c= +BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), +BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */ +``` + +将堆栈地址指针移至 r2 并减去 4，因此现在 r2 指向协议值，用作下一次 map 键查找的参数。 + +`BPF_LD_MAP_FD(BPF_REG_1, map_fd),` + +将本地进程内的文件描述符引用包含协议包计数的 map 到 r1 寄存器。 + +`BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),` + +使用 r2 指向的堆栈中的协议值作为键执行 map 查找调用。结果存储在 r0 中：指向由键索引的值的指针地址。 + +`BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),` + +还记得 0x020015 格式吗？这与第一部分的字节码相同。如果 map 查找没有成功，则 r0 == 0 所以我们跳过接下来的两条指令。 + +```c= +BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */ +BPF_RAW_INSN(BPF_STX | BPF_XADD | BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0), /* xadd r0 += r1 */ +``` + +增加 r0 指向的地址处的 map 值。 + +```c= +BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */ +BPF_EXIT_INSN(), +``` + +将 eBPF retcode 设置为 0 并退出。 + +尽管这个 sock_example 逻辑非常简单（它只是在 map 中增加的一些数字），但在原始字节码中实现或理解是困难的。更复杂的任务在像这样的汇编程序中完成时变得极其困难。展望未来，我们将开始使用更高级的语言和工具，以更少的工作开启更强大的 eBPF 用例。 + +## 总结 +在这一部分中，我们仔细观察了 eBPF 虚拟机的寄存器和指令集，了解了 eBPF 可访问的内核函数是如何从字节码中调用的，以及它们是如何被核心内核通过类似 syscall 的特殊目的 API 定义的。我们也完全理解了第一部分例子中使用的字节码。还有一些未探索的领域，如创建多个 eBPF 程序函数或链式 eBPF 程序以绕过 Linux 发行版的 4096 条指令限制。也许我们会在以后的文章中探讨这些。 + +现在，主要的问题是编写原始字节码很困难的，这非常像编写汇编代码，而且编写效率低下。在第三部分中，我们将开始研究使用高级语言编译成 eBPF 字节码，到此为止我们已经了解了虚拟机工作的底层基础知识。 diff --git a/content/zh/blogs/ebpf-software-stack.md b/content/zh/blogs/ebpf-software-stack.md new file mode 100644 index 000000000..d4af5ebad --- /dev/null +++ b/content/zh/blogs/ebpf-software-stack.md @@ -0,0 +1,157 @@ +--- +title: 'eBPF 概述，第 3 部分：软件开发生态' +tag: 'eBPF' +keywords: 'eBPF' +description: '为了理解这些工具是如何工作的，我们先定义一下 eBPF 程序的高层次组件：后端、加载器、前端和数据结构等。开发方式包括 LLVM eBPF 编译器/BCC/BPFTrace/IOVisor 等实现。' +createTime: '2021-11-05' +author: 'Adrian Ratiu' +snapshot: 'https://kubesphere-community.pek3b.qingstor.com/images/ebpf-guide-cover.png' +--- + +> 原文链接： https://www.collabora.com/news-and-blog/blog/2019/04/26/an-ebpf-overview-part-3-walking-up-the-software-stack/ + +> **作者：Adrian Ratiu**
+> **译者：狄卫华**
+> **注：本文已取得作者本人的翻译授权** + +## 1. 前言 + +在本系列的[第 1 部分](https://kubesphere.com.cn/blogs/ebpf-guide/)和[第 2 部分](https://kubesphere.com.cn/blogs/ebpf-machine-bytecode/)中，我们对 eBPF 虚拟机进行了简洁的深入研究。阅读上述部分并不是理解第 3 部分的必修课，尽管很好地掌握了低级别的基础知识确实有助于更好地理解高级别的工具。为了理解这些工具是如何工作的，我们先定义一下 eBPF 程序的高层次组件： + +- **后端**：这是在内核中加载和运行的 eBPF 字节码。它将数据写入内核 map 和环形缓冲区的**数据结构**中。 +- **加载器：**它将字节码**后端**加载到内核中。通常情况下，当加载器进程终止时，字节码会被内核自动卸载。 +- **前端：**从**数据结构**中读取数据（由**后端**写入）并将其显示给用户。 +- **数据结构**：这些是**后端**和**前端**之间的通信手段。它们是由内核管理的 map 和环形缓冲区，可以通过文件描述符访问，并需要在**后端**被加载之前创建。它们会持续存在，直到没有更多的**后端**或**前端**进行读写操作。 + +在第 1 部分和第 2 部分研究的 [sock_example.c](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c) 中，所有的组件都被放置在一个 C 文件中，所有的动作都由用户进程完成。 + +- [第 40-45 行](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L40-L45)创建 map**数据结构**。 +- [第 47-61 行](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L47-L61)定义**后端**。 +- [第 63-76 行](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L63-L76)在内核中**加载**后端 +- [第 78-91 行](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L78-L91)是**前端**，负责将从 map 文件描述符中读取的数据打印给用户。 + +eBPF 程序可以更加复杂：多个**后端**可以由一个（或单独的多个！）**加载器**进程加载，写入多个**数据结构**，然后由多个**前端**进程读取，所有这些都可以发生在一个跨越多个进程的用户 eBPF 应用程序中。 + + + + + +## 2. 层级 1：容易编写的后端：LLVM eBPF 编译器 + +我们在前面的文章中看到，在内核中编写原始的 eBPF 字节码是不仅困难而且低效，这非常像用处理器的汇编语言编写程序，所以很自然地开发了一个能够将 LLVM 中间表示编译成 eBPF 程序的模块，并从 2015 年的 v3.7 开始发布（GCC 到现在为止仍然不支持 eBPF）。这使得多种高级语言如 C、Go 或 Rust 的子集可以被编译到 eBPF。最成熟和最流行的是基于 C 语言编写的方式，因为内核也是用 C 写的，这样就更容易复用现有的内核头文件。 + +LLVM 将 "受限制的 C" 语言（记住，没有无界循环，最大 4096 条指令等等，见第 1 部分开始）编译成 ELF 对象文件，其中包含特殊区块（section)，并可基于 bpf()系统调用，使用 libbpf 等库加载到内核中。这种设计有效地将**后端**定义从**加载器**和**前端**中分离出来，因为 eBPF 字节码包含在 ELF 文件中。 + +内核还在 [samples/bpf/](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/) 下提供了使用这种模式的例子：\*\_kern.c 文件被编译为 \*\_kern.o（**后端**代码），被 \*\_user.c（**装载器**和**前端**）加载。 + +将本系列第 1 和第 2 部分的 [sock_exapmle.c 原始字节码](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L47-L61) 转换为 "受限的 C" 代码“ [sockex1_kern.c](https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c#L47-L61)，这比原始字节码更容易理解和修改。 + +```c +#include
+> **译者：狄卫华**
+> **注：本文已取得作者本人的翻译授权** + +## 1. 前言 + +在之前的部分中，我们专注于 Linux 内核跟踪，在我们看来，基于 eBPF 的项目是最安全、最广泛可用和最有效的方法（eBPF 在 Linux 中完全是上游支持的，保证稳定的 ABI，在几乎所有的发行版中都默认启用，并可与所有其他跟踪机制集成）。 eBPF 成为内核工作的不二之选。 然而，到目前为止，我们故意避免深入讨论用户空间跟踪，因为它值得特别对待，因此我们在第 5 部分中专门讨论。 + +首先，我们将讨论为什么使用，然后我们将 eBPF 用户跟踪分为静态和动态两类分别讨论。 + +## 2. 为什么要在用户空间使用 eBPF？ + +最重要的用户问题是，既然有这么多其他的调试器/性能分析器/跟踪器，这么多针对特定语言或操作系统的工具为同样的任务而开发，为什么还要使用 eBPF 来跟踪用户空间进程？答案并不简单，根据不同的使用情况，eBPF 可能不是最佳解决方案；在庞大的用户空间生态系统中，并没有一个适合所有情况的调试/跟踪的项目。 + +eBPF 跟踪具有以下优势： + +- 它为内核和用户空间提供了一个统一的跟踪接口，与其他工具（[k,u]probe, (dtrace)tracepoint 等）使用的机制兼容。2015 年的文章[选择 linux 跟踪器](http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html)虽然有些过时，但其提供了很好的见解，说明使用所有不同的工具有多困难，要花多少精力。有一个统一的、强大的、安全的、可广泛使用的框架来满足大多数跟踪的需要，是非常有价值的。一些更高级别的工具，如 Perf/SystemTap/DTrace，正在 eBPF 的基础上重写（成为 eBPF 的前端），所以了解 eBPF 有助于使用它们。 + +- eBPF 是完全可编程的。Perf/ftrace 和其他工具都需要在事后处理数据，而 eBPF 可直接在内核/应用程序中运行自定义的高级本地编译的 C/Python/Go 检测代码。它可以在多个 eBPF 事件运行之间存储数据，例如以基于函数状态/参数计算每个函数调用统计数据。 + +- eBPF 可以跟踪系统中的一切，它并不局限于特定的应用程序。例如可以在共享库上设置 uprobes 并跟踪链接和调用它的所有进程。 + +- 很多调试器需要暂停程序来观察其状态或降低运行时性能，从而难以进行实时分析，尤其是在生产工作负载上。因为 eBPF 附加了 JIT 的本地编译的检测代码，它的性能影响是最小的，不需要长时间暂停执行。 + +诚然，eBPF 也有一些缺点： + +- eBPF 不像其他跟踪器那样可以移植。该虚拟机主要是在 Linux 内核中开发的（有一个正在进行的 BSD 移植），相关的工具是基于 Linux 开发的。 +- eBPF 需要一个相当新的内核。例如对于 MIPS 的支持是在 v4.13 中加入的，但绝大多数 MIPS 设备在运行的内核都比 v4.13 老。 +- 一般来说，eBPF 不容易像语言或特定应用的用户空间调试器那样提供一样多的洞察力。例如，Emacs 的核心是一个用 C 语言编写的 ELISP 解释器：eBPF 可以通过挂载在 Emacs 运行时的 C 函数调用来跟踪/调试 ELISP 程序，但它不了解更高级别的 ELISP 语言实现，因此使用 Emacs 提供的特殊 ELISP 语言特定跟踪器和调试器变得更加有用。另一个例子是调试在 Web 浏览器引擎中运行的 JavaScript 应用程序。 +- 因为 "普通 eBPF" 在 Linux 内核中运行，所以每次 eBPF 检测用户进程时都会发生内核 - 用户上下文切换。这对于调试性能关键的用户空间代码来说可能很昂贵（也许可以使用[用户空间 eBPF 虚拟机](https://github.com/iovisor/ubpf)项目来避免这种切换成本？）。这对于调试性能关键的用户空间代码来说是很昂贵的（也许[用户空间 eBPF VM](https://github.com/iovisor/ubpf) 项目可以用来避免这种切换成本？）。这种上下文切换比正常的调试器（或像 strace 这样的工具）要便宜得多，所以它通常可以忽略不计，但在这种情况下，像 LTTng 这样能够完全运行在用户空间的跟踪器可能更合适。 + +## 3. 静态跟踪点（USDT 探针） + +静态跟踪点（tracepoint），在用户空间也被称为 USDT（用户静态定义的跟踪）探针（应用程序中感兴趣的特定位置），跟踪器可以在此处挂载检查代码执行和数据。它们由开发人员在源代码中明确定义，通常在编译时用 "--enable-trace" 等标志启用。静态跟踪点的优势在于它们不会经常变化：开发人员通常会保持稳定的静态跟踪 ABI，所以跟踪工具在不同的应用程序版本之间工作，这很有用，例如当升级 PostgreSQL 安装并遇到性能降低时。 + +### 3.1 预定义的跟踪点 +[BCC-tools](https://github.com/iovisor/bcc/tree/master/tools) 包含很多有用的且经过测试的工具，可以与特定应用程序或语言运行时定义的跟踪点进行交互。对于我们的示例，我们将跟踪 Python 应用程序。确保你在构建了 python3 时启用了 "--enable-trace" 标识，并在 python 二进制文件或 libpython（取决于你构建方式）上运行 [tplist](https://github.com/iovisor/bcc/blob/master/tools/tplist.py) 以确认跟踪点被启用： + +```bash +$ tplist -l /usr/lib/libpython3.7m.so +b'/usr/lib/libpython3.7m.so' b'python':b'import__find__load__start' +b'/usr/lib/libpython3.7m.so' b'python':b'import__find__load__done' +b'/usr/lib/libpython3.7m.so' b'python':b'gc__start' +b'/usr/lib/libpython3.7m.so' b'python':b'gc__done' +b'/usr/lib/libpython3.7m.so' b'python':b'line' +b'/usr/lib/libpython3.7m.so' b'python':b'function__return' +b'/usr/lib/libpython3.7m.so' b'python':b'function__entry' +``` + +首先我们使用 BCC 提供的一个很酷的跟踪工具 [uflow](https://github.com/iovisor/bcc/blob/master/tools/lib/uflow_example.txt)，来跟踪 python 的[简单 http 服务器](https://github.com/python/cpython/blob/3.7/Lib/http/server.py)的执行流程。跟踪应该是不言自明的，箭头和缩进表示函数的进入/退出。我们在这个跟踪中看到的是一个工作线程如何在 CPU 3 上退出，而主线程则准备在 CPU 0 上为其他传入的 http 请求提供服务。 + +```bash +$ python -m http.server >/dev/null & sudo ./uflow -l python $! +[4] 11727 +Tracing method calls in python process 11727... Ctrl-C to quit. +CPU PID TID TIME(us) METHOD +3 11740 11757 7.034 /usr/lib/python3.7/_weakrefset.py._remove +3 11740 11757 7.034 /usr/lib/python3.7/threading.py._acquire_restore +0 11740 11740 7.034 /usr/lib/python3.7/threading.py.__exit__ +0 11740 11740 7.034 /usr/lib/python3.7/socketserver.py.service_actions +0 11740 11740 7.034 /usr/lib/python3.7/selectors.py.select +0 11740 11740 7.532 /usr/lib/python3.7/socketserver.py.service_actions +0 11740 11740 7.532 +``` + +接下来，我们希望在跟踪点被命中时运行我们的自定义代码，因此我们不完全依赖 BCC 提供的任何工具。 以下示例将自身挂钩到 python 的 function__entry 跟踪点（请参阅 [python 检测](https://docs.python.org/3/howto/instrumentation.html)文档）并在有人下载文件时通知我们： + +```python +#!/usr/bin/env python +from bcc import BPF, USDT +import sys + +bpf = """ +#include
+> **译者：狄卫华**
+> **注：本文已取得作者本人的翻译授权** + +## 1. 前言 + +在本系列的[第 1 部分](https://kubesphere.com.cn/blogs/ebpf-guide/)和[第 2 部分](https://kubesphere.com.cn/blogs/ebpf-machine-bytecode/)，我们介绍了 eBPF 虚拟机内部工作原理，在[第 3 部分](https://kubesphere.com.cn/blogs/ebpf-software-stack/)我们研究了基于底层虚拟机机制之上开发和使用 eBPF 程序的主流方式。 + +在这一部分中，我们将从另外一个视角来分析项目，尝试解决嵌入式 Linux 系统所面临的一些独特的问题：如需要非常小的自定义操作系统镜像，不能容纳完整的 BCC LLVM 工具链/python 安装，或试图避免同时维护主机的交叉编译（本地）工具链和交叉编译的目标编译器工具链，以及其相关的构建逻辑，即使在使用像 OpenEmbedded/Yocto 这样的高级构建系统时也很重要。 + +## 2. 关于可移植性 + +在第 3 部分研究的运行 eBPF/BCC 程序的主流方式中，可移植性并不是像在嵌入式设备上面临的问题那么大：eBPF 程序是在被加载的同一台机器上编译的，使用已经运行的内核，而且头文件很容易通过发行包管理器获得。嵌入式系统通常运行不同的 Linux 发行版和不同的处理器架构，与开发人员的计算机相比，有时具有重度修改或上游分歧的内核，在构建配置上也有很大的差异，或还可能使用了只有二进制的模块。 + +eBPF 虚拟机的字节码是通用的（并未与特定机器相关），所以一旦编译好 eBPF 字节码，将其从 x86_64 移动到 ARM 设备上并不会引起太多问题。当字节码探测内核函数和数据结构时，问题就开始了，这些函数和数据结构可能与目标设备的内核不同或者会不存在，所以至少目标设备的内核头文件必须存在于构建 eBPF 程序字节码的主机上。新的功能或 eBPF 指令也可能被添加到以后的内核中，这可以使 eBPF 字节码向前兼容，但不能在内核版本之间向后兼容（参见[内核版本与 eBPF 功能](https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md)）。建议将 eBPF 程序附加到稳定的内核 ABI 上，如跟踪点（tracepoint），这可以缓解常见的可移植性。 + +最近一个重要的工作已经开始，通过在 LLVM 生成的 eBPF 对象代码中嵌入数据类型信息，通过增加 BTF（BTF 类型格式）数据，以增加 eBPF 程序的可移植性（CO-RE 一次编译，到处运行）。更多信息见这里的[补丁](https://lwn.net/Articles/750695/)和[文章](https://lwn.net/Articles/773198/)。这很重要，因为 BTF 涉及到 eBPF 软件技术栈的所有部分（内核虚拟机和验证器、clang/LLVM 编译器、BCC 等），但这种方式可带来很大的便利，允许重复使用现有的 BCC 工具，而不需要特别的 eBPF 交叉编译和在嵌入式设备上安装 LLVM 或运行 BPFd。截至目前，CO-RE BTF 工作仍处于早期开发阶段，还需要付出相当多的工作才能可用【译者注：当前在高版本内核已经可以使用或者编译内核时启用了 BTF 编译选项】。也许我们会在其完全可用后再发表一篇博文。 + +## 3. BPFd + +[BPFd](https://lwn.net/Articles/744522/)（项目地址
+> +> 这是因为 Apache APISIX Ingress Controller 目前和 Apache APISIX 网关是强关联的（如下图所示），且目前通过 Apache APISIX Helm Charts 同时部署 Apache APISIX Gateway + Dashboard + Ingress Controller 是最方便的，因此本文推荐直接使用 Apache APISIX 的 Helm Chart 进行整套组件的部署。 +> +>  + +将应用命名为 `apisix` 以避免多个组件（Gateway, Dashboard, Ingress Controller）的工作负载及服务名称产生不匹配的情况；在安装步骤中编辑的「应用设置」的部分，请参照以下配置进行填写（**请特别注意带有【注意】标记的注释部分的说明，其余可以按需自行编辑修改**）。 + +```yaml +global: + imagePullSecrets: [] + +apisix: + enabled: true + customLuaSharedDicts: [] + image: + repository: apache/apisix + pullPolicy: IfNotPresent + tag: 2.10.1-alpine + replicaCount: 1 + podAnnotations: {} + podSecurityContext: {} + securityContext: {} + resources: {} + nodeSelector: {} + tolerations: [] + affinity: {} + podAntiAffinity: + enabled: false + +nameOverride: '' +fullnameOverride: '' + +gateway: + type: NodePort + externalTrafficPolicy: Cluster + http: + enabled: true + servicePort: 80 + containerPort: 9080 + tls: + enabled: false + servicePort: 443 + containerPort: 9443 + existingCASecret: '' + certCAFilename: '' + http2: + enabled: true + stream: + enabled: false + only: false + tcp: [] + udp: [] + ingress: + enabled: false + annotations: {} + hosts: + - host: apisix.local + paths: [] + tls: [] + +admin: + enabled: true + type: ClusterIP + externalIPs: [] + port: 9180 + servicePort: 9180 + cors: true + credentials: + admin: edd1c9f034335f136f87ad84b625c8f1 + viewer: 4054f7cf07e344346cd3f287985e76a2 + allow: + ipList: + - 0.0.0.0/0 + +plugins: + - api-breaker + - authz-keycloak + - basic-auth + - batch-requests + - consumer-restriction + - cors + - echo + - fault-injection + - grpc-transcode + - hmac-auth + - http-logger + - ip-restriction + - ua-restriction + - jwt-auth + - kafka-logger + - key-auth + - limit-conn + - limit-count + - limit-req + - node-status + - openid-connect + - authz-casbin + - prometheus + - proxy-cache + - proxy-mirror + - proxy-rewrite + - redirect + - referer-restriction + - request-id + - request-validation + - response-rewrite + - serverless-post-function + - serverless-pre-function + - sls-logger + - syslog + - tcp-logger + - udp-logger + - uri-blocker + - wolf-rbac + - zipkin + - traffic-split + - gzip + - real-ip + #【注意】添加此插件以配合 Dashboard 展示服务信息 + - server-info + +stream_plugins: + - mqtt-proxy + - ip-restriction + - limit-conn + +customPlugins: + enabled: true + luaPath: /opts/custom_plugins/?.lua + #【注意】如下配置保障 Prometheus 插件可对外暴露指标 + plugins: + - name: prometheus + attrs: + export_addr: + ip: 0.0.0.0 + port: 9091 + configMap: + name: prometheus + mounts: [] + +dns: + resolvers: + - 127.0.0.1 + - 172.20.0.10 + - 114.114.114.114 + - 223.5.5.5 + - 1.1.1.1 + - 8.8.8.8 + validity: 30 + timeout: 5 + +autoscaling: + enabled: false + minReplicas: 1 + maxReplicas: 100 + targetCPUUtilizationPercentage: 80 + targetMemoryUtilizationPercentage: 80 + +configurationSnippet: + main: '' + httpStart: '' + httpEnd: '' + httpSrv: '' + httpAdmin: '' + stream: '' + +etcd: + enabled: true + host: + - 'http://etcd.host:2379' + prefix: /apisix + timeout: 30 + auth: + rbac: + enabled: false + user: '' + password: '' + tls: + enabled: false + existingSecret: '' + certFilename: '' + certKeyFilename: '' + verify: true + service: + port: 2379 + replicaCount: 3 + +dashboard: + enabled: true + #【注意】为 Dashboard 开启 NodePort 方便后续使用 + service: + type: NodePort + +ingress-controller: + enabled: true + config: + apisix: + #【注意】一定要设置 gateway 所在的 namespace + serviceNamespace: apisix-system + serviceMonitor: + enabled: true + namespace: 'apisix-system' + interval: 15s +``` + +部署成功后，点击应用名称进入详情页面，可以在「资源状态」标签页下看到如下的服务部署和工作状态运行状态展示。 + + + +> 💡 Apache APISIX 项目另有的两个 Helm Chart 对应的默认配置参数可以分别参考：[Dashboard](https://github.com/apache/apisix-helm-chart/blob/master/charts/apisix-dashboard/values.yaml) 和 [Ingress Controller](https://github.com/apache/apisix-helm-chart/blob/master/charts/apisix-ingress-controller/values.yaml) 的 `values.yaml`。 + +### 使用 Apache APISIX Dashboard 了解系统信息 + +Apache APISIX 应用部署完成后，首先我们通过 Apache APISIX Dashboard 来检验一下 Apache APISIX 网关的当前状态。从「应用负载」的「服务」页面，我们可以找到 `apisix-dashboard` 的服务，由于我们在应用配置中已经为 Dashboard 开启了 NodePort，所以这里我们可以直接通过 NodePort 端口来访问 Dashboard。 + + + + +使用默认的用户名及密码 `admin` 登录 Apache APISIX Dashboard，可以进入「系统信息」页面即可查看到我们当前连接管理的「Apache APISIX 节点」的信息。 + + + +### 使用 Apache APISIX Ingress Controller + +让我们回到「应用路由」页面，另外新建一个路由（如 `apisix-httpbin`），设置路径为 `/*` `httpbin` `80` 并为其添加 `kubernetes.io/ingress.class`: `apisix` 的键值。 + + + + + +创建完成后如何验证应用路由生效呢？首先，我们可以回到 Apache APISIX Dashboard，进入「路由」页面，可以看到新建的应用路由已经被 Apache APISIX Ingress Controller 识别之后自动添加到了 Apache APISIX 网关中，在「上游」页面也可以看到自动创建的一个上游条目。 + + + + +然后我们回到 `apisix-system` 项目的「服务」页面，找到 `apisix-gateway` 服务对应的端口，由此访问 `
，点击 **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/access-control-and-account-management/external-authentication/set-up-external-authentication.md b/content/zh/docs/access-control-and-account-management/external-authentication/set-up-external-authentication.md
new file mode 100644
index 000000000..4c8a8fd53
--- /dev/null
+++ b/content/zh/docs/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