From b546c843aaebba24135ba594c5cb3878675a4492 Mon Sep 17 00:00:00 2001 From: Sherlock113 Date: Wed, 23 Dec 2020 15:41:35 +0800 Subject: [PATCH] cluster administration title fix Signed-off-by: Sherlock113 --- .../cluster-status-monitoring.md | 23 +++++++++---------- .../alerting-message.md | 13 +++++------ .../alerting-policy.md | 17 +++++++------- .../persistent-volume-and-storage-class.md | 11 ++++----- ...hut-down-and-restart-cluster-gracefully.md | 16 ++++++------- 5 files changed, 38 insertions(+), 42 deletions(-) diff --git a/content/en/docs/cluster-administration/cluster-status-monitoring.md b/content/en/docs/cluster-administration/cluster-status-monitoring.md index 636ccee3f..9c8727e07 100644 --- a/content/en/docs/cluster-administration/cluster-status-monitoring.md +++ b/content/en/docs/cluster-administration/cluster-status-monitoring.md @@ -2,7 +2,6 @@ title: "Cluster Status Monitoring" keywords: "Kubernetes, KubeSphere, status, monitoring" description: "Monitor cluster resources in KubeSphere" - linkTitle: "Cluster Status Monitoring" weight: 8200 --- @@ -27,7 +26,7 @@ You need an account granted a role including the authorization of **Clusters Man ![Cluster Status Monitoring](/images/docs/cluster-administration/cluster-status-monitoring/cluster-status-monitoring.png) -### Cluster Node Status +### Cluster node status 1. **Cluster Node Status** displays the status of all nodes, separately marking the active ones. You can go to the **Cluster Nodes** page shown below to view the real-time resource usage of all nodes by clicking **Node Online Status**. @@ -45,7 +44,7 @@ You need an account granted a role including the authorization of **Clusters Man You can customize the time range from the drop-down list in the top right corner to view historical data. {{}} -### Component Status +### Component status KubeSphere monitors the health status of various service components in the cluster. When a key component malfunctions, the system may become unavailable. The monitoring mechanism of KubeSphere ensures the platform can notify tenants of any occurring issues in case of a component failure, so that they can quickly locate the problem and take corresponding action. @@ -61,7 +60,7 @@ KubeSphere monitors the health status of various service components in the clust Components marked in orange may turn to green after a period of time, the reasons of which may be different, such as image pulling retries or pod recreations. You can click the component to see its service details. {{}} -### Cluster Resources Usage +### Cluster resources usage **Cluster Resources Usage** displays the information including **CPU Utilization, Memory Utilization, Disk Utilization, and Pod Quantity Trend** of all nodes in the cluster. Click the pie chart on the left to switch indicators, which shows the trend during a period in a line chart on the right. @@ -73,19 +72,19 @@ Monitoring data in **Physical Resources Monitoring** help users better observe t ![Physical Resources Monitoring](/images/docs/cluster-administration/cluster-status-monitoring/physical-resources-monitoring.png) -### CPU Utilization +### CPU utilization CPU utilization shows how CPU resources are used in a period. If you notice that the CPU usage of the platform during a certain period soars, you must first locate the process that is occupying CPU resources the most. For example, for Java applications, you may expect a CPU usage spike in the case of memory leaks or infinite loops in the code. ![CPU Utilization](/images/docs/cluster-administration/cluster-status-monitoring/cpu-utilization.png) -### Memory Utilization +### Memory utilization Memory is one of the important components on a machine, serving as a bridge for communications with the CPU. Therefore, the performance of memory has a great impact on the machine. Data loading, thread concurrency and I/O buffering are all dependent on memory when a program is running. The size of available memory determines whether the program can run normally and how it is functioning. Memory utilization reflects how memory resources are used within a cluster as a whole, displayed as a percentage of available memory in use at a given moment. ![Memory Utilization](/images/docs/cluster-administration/cluster-status-monitoring/memory-utilization.png) -### CPU Load Average +### CPU load average CPU load average is the average number of processes in the system in a runnable state and an uninterruptible state per unit time. Namely, it is the average number of active processes. Note that there is no direct relation between the CPU load average and the CPU utilization. Ideally, the load average should be equal to the number of CPUs. Therefore, you need to consider the number of CPUs when you look into the load average. A system is overloaded only when the load average is greater than the number of CPUs. @@ -97,7 +96,7 @@ KubeSphere provides users with three different time periods to view the load ave ![CPU Load Average](/images/docs/cluster-administration/cluster-status-monitoring/cpu-load-average.png) -### Disk Usage +### Disk usage KubeSphere workloads such as `StatefulSets` and `DaemonSets` all rely on persistent volumes. Some components and services also require a persistent volume. Such backend storage relies on disks, such as block storage or network shared storage. In this connection, providing a real-time monitoring environment for disk usage is an important part of maintaining the high reliability of data. @@ -105,7 +104,7 @@ In the daily management of the Linux system, platform administrators may encount ![Disk Usage](/images/docs/cluster-administration/cluster-status-monitoring/disk-usage.png) -### inode Utilization +### inode utilization Each file must have an inode, which is used to store the file's meta-information, such as the file's creator and creation date. The inode will also consume hard disk space, and many small cache files can easily lead to the exhaustion of inode resources. Also, the inode may be used up, but the hard disk is not full. In this case, new files cannot be created on the hard disk. @@ -113,7 +112,7 @@ In KubeSphere, the monitoring of inode utilization can help you detect such situ ![inode Utilization](/images/docs/cluster-administration/cluster-status-monitoring/inode-utilization.png) -### Disk Throughput +### Disk throughput The monitoring of disk throughput and IOPS is an indispensable part of disk monitoring, which is convenient for cluster administrators to adjust data layout and other management activities to optimize the overall performance of the cluster. Disk throughput refers to the speed of the disk transmission data stream (shown in MB/s), and the transmission data are the sum of data reading and writing. When large blocks of discontinuous data are being transmitted, this indicator is of great importance for reference. ![Disk Throughput](/images/docs/cluster-administration/cluster-status-monitoring/disk-throughput.png) @@ -124,13 +123,13 @@ The monitoring of disk throughput and IOPS is an indispensable part of disk moni ![IOPS](/images/docs/cluster-administration/cluster-status-monitoring/iops.png) -### Network Bandwidth +### Network bandwidth The network bandwidth is the ability of the network card to receive or send data per second, shown in Mbps (megabits per second). ![Network Bandwidth](/images/docs/cluster-administration/cluster-status-monitoring/netework-bandwidth.png) -### Pod Status +### Pod status Pod status displays the total number of pods in different states, including **Running**, **Completed** and **Warning**. The pod tagged **Completed** usually refers to a Job or a CronJob. The number of pods marked **Warning**, which means an abnormal state, requires special attention. diff --git a/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md b/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md index 77a769a4c..6e0926934 100644 --- a/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md +++ b/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md @@ -1,9 +1,8 @@ --- -title: "Alerting Message (Node Level)" +title: "Alerting Messages (Node Level)" keywords: 'KubeSphere, Kubernetes, Node, Alerting, Message, Notification' description: 'How to view alerting messages at the node level.' - -linkTitle: "Alerting Message (Node Level)" +linkTitle: "Alerting Messages (Node Level)" weight: 8540 --- @@ -15,7 +14,7 @@ You have created a node-level alert policy and received alert notifications of i ## Hands-on Lab -### Task 1: View Alert Message +### Task 1: View alert messages 1. Log in the console with one account granted the role `platform-admin`. @@ -33,13 +32,13 @@ You have created a node-level alert policy and received alert notifications of i ![alerting_message_node_level_detail](/images/docs/alerting/alerting_message_node_level_detail.png) -### Task 2: View Alert Policy +### Task 2: View alert policies Switch to **Alerting Policy** to view the alert policy corresponding to this alert message, and you can see the triggering rule of it set in the example of [Alert Policy (Node Level)](../alerting-policy/). ![alerting_message_node_level_policy](/images/docs/alerting/alerting_message_node_level_policy.png) -### Task 3: View Recent Notification +### Task 3: View recent notifications 1. Switch to **Recent Notification**. It can be seen that 3 notifications have been received, because the notification rule was set with a repetition period of `Alert once every 5 minutes` and retransmission of `Resend up to 3 times`. @@ -47,7 +46,7 @@ Switch to **Alerting Policy** to view the alert policy corresponding to this ale 2. Log in your email to see alert notification mails sent by the KubeSphere mail server. You have received a total of 3 emails. -### Task 4: Add Comment +### Task 4: Add comments Click **Comment** to add comments to current alert messages. For example, as memory utilization rate of the node is higher than the threshold set based on the alert rule, you can add a comment in the dialog below: `The node needs to be tainted and new pod is not allowed to be scheduled to it`. diff --git a/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md b/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md index 7b7417510..6dcb3f16f 100644 --- a/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md +++ b/content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md @@ -1,9 +1,8 @@ --- -title: "Alerting Policy (Node Level)" +title: "Alerting Policies (Node Level)" keywords: 'KubeSphere, Kubernetes, Node, Alerting, Policy, Notification' description: 'How to set alerting policies at the node level.' - -linkTitle: "Alerting Policy (Node Level)" +linkTitle: "Alerting Policies (Node Level)" weight: 8530 --- @@ -18,7 +17,7 @@ KubeSphere provides alert policies for nodes and workloads. This guide demonstra ## Hands-on Lab -### Task 1: Create an Alert Policy +### Task 1: Create an alert policy 1. Log in the console with one account granted the role `platform-admin`. @@ -32,7 +31,7 @@ KubeSphere provides alert policies for nodes and workloads. This guide demonstra ![alerting_policy_node_level_create](/images/docs/alerting/alerting_policy_node_level_create.png) -### Task 2: Provide Basic Information +### Task 2: Provide basic information In the dialog that appears, fill in the basic information as follows. Click **Next** after you finish. @@ -42,7 +41,7 @@ In the dialog that appears, fill in the basic information as follows. Click **Ne ![alerting_policy_node_level_basic_info](/images/docs/alerting/alerting_policy_node_level_basic_info.png) -### Task 3: Select Monitoring Targets +### Task 3: Select monitoring targets Select several nodes in the node list or use Node Selector to choose a group of nodes as the monitoring targets. Here a node is selected for the convenience of demonstration. Click **Next** when you finish. @@ -54,7 +53,7 @@ You can sort nodes in the node list from the drop-down menu through the followin {{}} -### Task 4: Add Alerting Rules +### Task 4: Add alerting rules 1. Click **Add Rule** to begin to create an alerting rule. The rule defines parameters such as metric type, check period, consecutive times, metric threshold and alert level to provide rich configurations. The check period (the second field under **Rule**) means the time interval between 2 consecutive checks of the metric. For example, `2 minutes/period` means the metric is checked every two minutes. The consecutive times (the third field under **Rule**) means the number of consecutive times that the metric meets the threshold when checked. An alert is only triggered when the actual time is equal to or is greater than the number of consecutive times set in the alert policy. @@ -76,7 +75,7 @@ You can create node-level alert policies for the following metrics: {{}} -### Task 5: Set Notification Rule +### Task 5: Set notification rules 1. **Effective Notification Time Range** is used to set sending time of notification emails, such as `09:00 ~ 19:00`. **Notification Channel** currently only supports **Email**. You can add email addresses of members to be notified to **Notification List**. @@ -92,7 +91,7 @@ You can create node-level alert policies for the following metrics: {{}} -### Task 6: View Alert Policy +### Task 6: View alert policies After an alert policy is successfully created, you can enter its detail information page to view the status, alert rules, monitoring targets, notification rule, alert history, etc. Click **More** and select **Change Status** from the drop-down menu to enable or disable this alert policy. 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 cc013392e..940fb7669 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,9 +1,8 @@ --- -title: "Persistent Volume and Storage Class" +title: "Persistent Volumes and Storage Classes" keywords: "storage, volume, pv, pvc, storage class, csi, Ceph RBD, Glusterfs, QingCloud, " description: "Persistent Volume and Storage Class Management" - -linkTitle: "Persistent Volume and Storage Class" +linkTitle: "Persistent Volumes and Storage Classes" weight: 8400 --- @@ -31,7 +30,7 @@ The table below summarizes common volume plugins for various provisioners (stora You need an account granted a role including the authorization of **Clusters Management**. For example, you can log in the console as `admin` directly or create a new role with the authorization and assign it to an account. -## Manage Storage Class +## Manage Storage Classes 1. Click **Platform** in the top left corner and select **Clusters Management**. ![clusters-management-select](/images/docs/cluster-administration/persistent-volume-and-storage-class/clusters-management-select.jpg) @@ -49,7 +48,7 @@ You need an account granted a role including the authorization of **Clusters Man ![create-storage-class-settings](/images/docs/cluster-administration/persistent-volume-and-storage-class/create-storage-class-settings.png) -### Common Settings +### 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 top right corner. Here are property descriptions of some commonly used fields in KubeSphere. @@ -142,7 +141,7 @@ Nevertheless, you can use [rbd provisioner](https://github.com/kubernetes-incuba For more information about StorageClass parameters, see [Ceph RBD in Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd). -### Custom Storage Class +### Custom storage classes You can create custom storage classes for your storage systems if they are not directly supported by KubeSphere. The following example shows you how to create a storage class for NFS on the KubeSphere console. diff --git a/content/en/docs/cluster-administration/shut-down-and-restart-cluster-gracefully.md b/content/en/docs/cluster-administration/shut-down-and-restart-cluster-gracefully.md index 639a15bdc..17db93aa8 100644 --- a/content/en/docs/cluster-administration/shut-down-and-restart-cluster-gracefully.md +++ b/content/en/docs/cluster-administration/shut-down-and-restart-cluster-gracefully.md @@ -19,7 +19,7 @@ Usually, it is recommended to maintain your nodes one by one instead of restarti - Take an [etcd backup](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md#snapshotting-the-keyspace) prior to shutting down a cluster. - SSH [passwordless login](https://man.openbsd.org/ssh.1#AUTHENTICATION) is set up between hosts. -## Shut Down Cluster +## Shut Down a Cluster {{< notice tip >}} - You must back up your etcd data before you shut down the cluster as your cluster can be restored if you encounter any issues when restarting the cluster. @@ -27,11 +27,11 @@ Usually, it is recommended to maintain your nodes one by one instead of restarti {{}} -### Step 1: Get Node List +### Step 1: Get the node list ```bash nodes=$(kubectl get nodes -o name) ``` -### Step 2: Shut Down All Nodes +### Step 2: Shut down all nodes ```bash for node in ${nodes[@]} do @@ -41,7 +41,7 @@ done ``` Then you can shut down other cluster dependencies, such as external storage. -## Restart Cluster Gracefully +## Restart a Cluster Gracefully You can restart a cluster gracefully after shutting down the cluster gracefully. ### Prerequisites @@ -56,17 +56,17 @@ Usually, a cluster can be used after restarting, but the cluster may be unavaila {{}} -### Step 1: Check All Cluster Dependencies' Status +### Step 1: Check all cluster dependencies' status Ensure all cluster dependencies are ready, such as external storage. -### Step 2: Power on Cluster Machines +### Step 2: Power on cluster machines Wait for the cluster to be up and running, which may take about 10 minutes. -### Step 3: Check All Master Nodes' Status +### Step 3: Check all master nodes' status Check the status of core components, such as etcd services, and make sure everything is ready. ```bash kubectl get nodes -l node-role.kubernetes.io/master ``` -### Step 4: Check All Worker Nodes' Status +### Step 4: Check all worker nodes' status ```bash kubectl get nodes -l node-role.kubernetes.io/worker ```