mirror of
https://github.com/kubesphere/website.git
synced 2025-12-26 00:12:48 +00:00
update format and images in alerting, auditing, networkpolicy and servicemesh
Signed-off-by: Sherlock113 <sherlockxu@yunify.com>
This commit is contained in:
Sherlock113
parent
ff099e19d6
commit
67678ef75f
|
|
@ -1,15 +1,14 @@
|
|||
---
|
||||
title: "KubeSphere Alerting and Notification"
|
||||
keywords: "Kubernetes, alertmanager, KubeSphere, alerting, notification"
|
||||
description: "How to Enable Alerting and Notification"
|
||||
|
||||
description: "How to enable Alerting and Notification"
|
||||
linkTitle: "KubeSphere Alerting and Notification"
|
||||
weight: 6600
|
||||
---
|
||||
|
||||
## What are KubeSphere Alerting and Notification
|
||||
|
||||
Alerting and Notification are two important building blocks of observability, closely related monitoring and logging. The alerting system in KubeSphere, coupled with the proactive failure notification system, allows users to know activities of interest based on alert policies. When a predefined threshold of a certain metric is reached, an alert will be sent to preconfigured recipients, the notification method of which can be set by yourself, including Email, WeChat Work and Slack. 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 and Notification are two important building blocks 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 alert policies. When a predefined threshold of a certain metric is reached, an alert will be sent to preconfigured recipients, the notification method of which can be set by yourself, including Email, WeChat Work and Slack. 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.
|
||||
|
||||
For more information, see [Alerting Policy](../../project-user-guide/alerting/alerting-policy) and [Alerting Message](../../project-user-guide/alerting/alerting-message).
|
||||
|
||||
|
|
@ -25,14 +24,14 @@ It is recommended that you enable Alerting and Notification together so that use
|
|||
|
||||
When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
|
||||
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file **config-sample.yaml**. Modify the file by executing the following command:
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
|
||||
|
||||
```bash
|
||||
vi config-sample.yaml
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a config-sample.yaml file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Alerting and Notification in this mode (e.g. for testing purpose), refer to the following section to see how Alerting and Notification 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 Alerting and Notification in this mode (e.g. for testing purposes), refer to [the following section](#enable-alerting-and-notification-after-installation) to see how Alerting and Notification can be installed after installation.
|
||||
{{</ notice >}}
|
||||
|
||||
2. In this file, navigate to `alerting` and `notification` and change `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
|
@ -60,7 +59,7 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
vi cluster-configuration.yaml
|
||||
```
|
||||
|
||||
2. In this local cluster-configuration.yaml file, navigate to `alerting` and `notification` and enable them by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
2. In this local `cluster-configuration.yaml` file, navigate to `alerting` and `notification` and enable them by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
||||
```yaml
|
||||
alerting:
|
||||
|
|
@ -80,16 +79,18 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
## Enable Alerting and Notification after Installation
|
||||
|
||||
1. Log in the console as `admin`. Click **Platform** in the top-left corner and select **Clusters Management**.
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detailed page.
|
||||
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
|
||||
|
||||
{{< notice info >}}
|
||||
A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
|
||||
{{</ notice >}}
|
||||
|
||||
3. In **Resource List**, click the three dots on the right of `ks-installer` and select **Edit YAML**.
|
||||
|
||||
|
||||
|
||||
|
||||
4. In this yaml file, navigate to `alerting` and `notification` and change `false` to `true` for `enabled`. After you finish, click **Update** in the bottom-right corner to save the configuration.
|
||||
|
||||
|
|
@ -110,21 +111,21 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
|
|||
You can find the web kubectl tool by clicking the hammer icon in the bottom-right corner of the console.
|
||||
{{</ notice >}}
|
||||
|
||||
## Verify the Installation of Component
|
||||
## Verify the Installation of the Component
|
||||
|
||||
{{< tabs >}}
|
||||
|
||||
{{< tab "Verify the Component in Dashboard" >}}
|
||||
{{< tab "Verify the component on the dashboard" >}}
|
||||
|
||||
If you can see **Alerting Messages** and **Alerting Policies** in the image below, it means the installation succeeds as the two parts won't display until you install the component.
|
||||
|
||||
|
||||
|
||||
|
||||
{{</ tab >}}
|
||||
|
||||
{{< tab "Verify the Component through kubectl" >}}
|
||||
{{< tab "Verify the component through kubectl" >}}
|
||||
|
||||
Execute the following command to check the status of pods:
|
||||
Execute the following command to check the status of Pods:
|
||||
|
||||
```bash
|
||||
kubectl get pod -n kubesphere-alerting-system
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
title: "KubeSphere Auditing Logs"
|
||||
keywords: "Kubernetes, auditing, KubeSphere, logs"
|
||||
description: "How to enable KubeSphere Auditing Logs"
|
||||
|
||||
linkTitle: "KubeSphere Auditing Logs"
|
||||
weight: 6700
|
||||
---
|
||||
|
|
@ -19,14 +18,14 @@ For more information, see [Auditing Log Query](../../toolbox/auditing/auditing-q
|
|||
|
||||
When you implement multi-node installation KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
|
||||
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file **config-sample.yaml**. Modify the file by executing the following command:
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
|
||||
|
||||
```bash
|
||||
vi config-sample.yaml
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a config-sample.yaml file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Auditing in this mode (e.g. for testing purpose), refer to the following section to see how Auditing 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 Auditing in this mode (e.g. for testing purposes), refer to [the following section](#enable-auditing-logs-after-installation) to see how Auditing can be installed after installation.
|
||||
{{</ notice >}}
|
||||
|
||||
2. In this file, navigate to `auditing` and change `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
|
@ -37,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 Auditing 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 Auditing, 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 Auditing 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 Auditing, 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 >}}
|
||||
|
||||
```yaml
|
||||
|
|
@ -68,7 +67,7 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
vi cluster-configuration.yaml
|
||||
```
|
||||
|
||||
2. In this local cluster-configuration.yaml file, navigate to `auditing` and enable Auditing by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
2. In this local `cluster-configuration.yaml` file, navigate to `auditing` and enable Auditing by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
||||
```yaml
|
||||
auditing:
|
||||
|
|
@ -76,7 +75,7 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
```
|
||||
|
||||
{{< notice note >}}
|
||||
By default, ks-installer will install Elasticsearch internally if Auditing is enabled. For a production environment, it is highly recommended that you set the following values in **cluster-configuration.yaml** if you want to enable Auditing, especially `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information before installation, ks-installer will integrate your external Elasticsearch directly instead of installing an internal one.
|
||||
By default, ks-installer will install Elasticsearch internally if Auditing is enabled. For a production environment, it is highly recommended that you set the following values in `cluster-configuration.yaml` if you want to enable Auditing, especially `externalElasticsearchUrl` and `externalElasticsearchPort`. Once you provide the following information before installation, ks-installer will integrate your external Elasticsearch directly instead of installing an internal one.
|
||||
{{</ notice >}}
|
||||
|
||||
```yaml
|
||||
|
|
@ -102,16 +101,18 @@ By default, ks-installer will install Elasticsearch internally if Auditing is en
|
|||
## Enable Auditing Logs after Installation
|
||||
|
||||
1. Log in the console as `admin`. Click **Platform** in the top-left corner and select **Clusters Management**.
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detailed page.
|
||||
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
|
||||
|
||||
{{< notice info >}}
|
||||
A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
|
||||
{{</ notice >}}
|
||||
|
||||
3. In **Resource List**, click the three dots 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.
|
||||
|
||||
|
|
@ -146,23 +147,23 @@ By default, Elasticsearch will be installed internally if Auditing is enabled. F
|
|||
You can find the web kubectl tool by clicking the hammer icon in the bottom-right corner of the console.
|
||||
{{</ notice >}}
|
||||
|
||||
## Verify the Installation of Component
|
||||
## Verify the Installation of the Component
|
||||
|
||||
{{< tabs >}}
|
||||
|
||||
{{< tab "Verify the Component in Dashboard" >}}
|
||||
{{< tab "Verify the component on the dashboard" >}}
|
||||
|
||||
If you enable both Logging and Auditing, you can check the status of Auditing in **Logging** in **Components**. You may see an image as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
If you only enable Auditing without Logging installed, you cannot see the image above as the button **Logging** will not display.
|
||||
|
||||
{{</ tab >}}
|
||||
|
||||
{{< tab "Verify the Component through kubectl" >}}
|
||||
{{< tab "Verify the component through kubectl" >}}
|
||||
|
||||
Execute the following command to check the status of pods:
|
||||
Execute the following command to check the status of Pods:
|
||||
|
||||
```bash
|
||||
kubectl get pod -n kubesphere-logging-system
|
||||
|
|
|
|||
|
|
@ -1,39 +1,38 @@
|
|||
---
|
||||
title: "Network Policy"
|
||||
title: "Network Policies"
|
||||
keywords: "Kubernetes, KubeSphere, NetworkPolicy"
|
||||
description: "How to Enable Network Policy"
|
||||
|
||||
linkTitle: "Network Policy"
|
||||
description: "How to enable the Network Policy"
|
||||
linkTitle: "Network Policies"
|
||||
weight: 6900
|
||||
---
|
||||
|
||||
## What is Network Policy
|
||||
## What are Network Policies
|
||||
|
||||
Starting from v3.0.0, users can configure network policies of native Kubernetes in KubeSphere. Network Policies are an application-centric construct, enabling you to specify how a pod is allowed to communicate with various network entities over the network. With network policies, users can achieve network isolation within the same cluster, which means firewalls can be set up between certain instances (pods).
|
||||
Starting from v3.0.0, users can configure network policies of native Kubernetes in KubeSphere. Network Policies are an application-centric construct, enabling you to specify how a Pod is allowed to communicate with various network entities over the network. With network policies, users can achieve network isolation within the same cluster, which means firewalls can be set up between certain instances (Pods).
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- Please make sure that the CNI network plugin used by the cluster supports Network Policies before you enable it. 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 Policy.
|
||||
- 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.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
For more information, see [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/).
|
||||
|
||||
## Enable Network Policy before Installation
|
||||
## Enable the Network Policy before Installation
|
||||
|
||||
### Installing on Linux
|
||||
|
||||
When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
|
||||
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file **config-sample.yaml**. Modify the file by executing the following command:
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
|
||||
|
||||
```bash
|
||||
vi config-sample.yaml
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a config-sample.yaml file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Network Policy in this mode (e.g. for testing purpose), refer to the following section to see how Network Policy 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 the Network Policy in this mode (e.g. for testing purposes), refer to [the following section](#enable-network-policy-after-installation) to see how the Network Policy can be installed after installation.
|
||||
{{</ notice >}}
|
||||
|
||||
2. In this file, navigate to `networkpolicy` and change `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
|
@ -51,7 +50,7 @@ If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/),
|
|||
|
||||
### **Installing on Kubernetes**
|
||||
|
||||
The process of installing KubeSphere on Kubernetes is same as stated in the tutorial of [Installing KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/) except the optional component Network Polict needs to be enabled first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.0.0/cluster-configuration.yaml) file.
|
||||
The process of installing KubeSphere on Kubernetes is same as stated in the tutorial of [Installing KubeSphere on Kubernetes](../../installing-on-kubernetes/introduction/overview/) except the optional component Network Policy needs to be enabled first in the [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.0.0/cluster-configuration.yaml) file.
|
||||
|
||||
1. Download the file [cluster-configuration.yaml](https://github.com/kubesphere/ks-installer/releases/download/v3.0.0/cluster-configuration.yaml) and open it for editing.
|
||||
|
||||
|
|
@ -59,7 +58,7 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
vi cluster-configuration.yaml
|
||||
```
|
||||
|
||||
2. In this local cluster-configuration.yaml file, navigate to `networkpolicy` and enable Network Policy by changing `false` to `true` for `enabled`. Save the file after you finish..
|
||||
2. In this local `cluster-configuration.yaml` file, navigate to `networkpolicy` and enable it by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
||||
```yaml
|
||||
networkpolicy:
|
||||
|
|
@ -74,19 +73,21 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
kubectl apply -f cluster-configuration.yaml
|
||||
```
|
||||
|
||||
## Enable Network Policy after Installation
|
||||
## Enable the Network Policy after Installation
|
||||
|
||||
1. Log in the console as `admin`. Click **Platform** in the top-left corner and select **Clusters Management**.
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detailed page.
|
||||
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
|
||||
|
||||
{{< notice info >}}
|
||||
A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
|
||||
{{</ notice >}}
|
||||
|
||||
3. In **Resource List**, click the three dots on the right of `ks-installer` and select **Edit YAML**.
|
||||
|
||||
|
||||
|
||||
|
||||
4. In this yaml file, navigate to `networkpolicy` and change `false` to `true` for `enabled`. After you finish, click **Update** in the bottom-right corner to save the configuration.
|
||||
|
||||
|
|
@ -105,8 +106,8 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
|
|||
You can find the web kubectl tool by clicking the hammer icon in the bottom-right corner of the console.
|
||||
{{</ notice >}}
|
||||
|
||||
## Verify the Installation of Component
|
||||
## 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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "KubeSphere Service Mesh"
|
||||
keywords: "Kubernetes, istio, KubeSphere, service-mesh, microservices"
|
||||
description: "How to Enable KubeSphere Service Mesh"
|
||||
keywords: "Kubernetes, Istio, KubeSphere, service-mesh, microservices"
|
||||
description: "How to enable the KubeSphere Service Mesh"
|
||||
|
||||
linkTitle: "KubeSphere Service Mesh"
|
||||
weight: 6800
|
||||
|
|
@ -9,24 +9,24 @@ weight: 6800
|
|||
|
||||
## What is KubeSphere Service Mesh
|
||||
|
||||
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 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/), the 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 the Service Mesh without any code hacking, with the learning curve of Istio greatly reduced. All features of the 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 Service Mesh before Installation
|
||||
## Enable the Service Mesh before Installation
|
||||
|
||||
### Installing on Linux
|
||||
|
||||
When you implement multi-node installation of KubeSphere on Linux, you need to create a configuration file, which lists all KubeSphere components.
|
||||
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file **config-sample.yaml**. Modify the file by executing the following command:
|
||||
1. In the tutorial of [Installing KubeSphere on Linux](../../installing-on-linux/introduction/multioverview/), you create a default file `config-sample.yaml`. Modify the file by executing the following command:
|
||||
|
||||
```bash
|
||||
vi config-sample.yaml
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
If you adopt [All-in-one Installation](../../quick-start/all-in-one-on-linux/), you do not need to create a config-sample.yaml file as you can create a cluster directly. Generally, the all-in-one mode is for users who are new to KubeSphere and look to get familiar with the system. If you want to enable Service Mesh in this mode (e.g. for testing purpose), refer to the following section to see how Service Mesh 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 the Service Mesh in this mode (e.g. for testing purposes), refer to [the following section](#enable-service-mesh-after-installation) to see how the Service Mesh can be installed after installation.
|
||||
{{</ notice >}}
|
||||
|
||||
2. In this file, navigate to `servicemesh` and change `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
|
@ -52,7 +52,7 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
vi cluster-configuration.yaml
|
||||
```
|
||||
|
||||
2. In this local cluster-configuration.yaml file, navigate to `servicemesh` and enable Service Mesh by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
2. In this local `cluster-configuration.yaml` file, navigate to `servicemesh` and enable it by changing `false` to `true` for `enabled`. Save the file after you finish.
|
||||
|
||||
```yaml
|
||||
servicemesh:
|
||||
|
|
@ -67,19 +67,20 @@ The process of installing KubeSphere on Kubernetes is same as stated in the tuto
|
|||
kubectl apply -f cluster-configuration.yaml
|
||||
```
|
||||
|
||||
## Enable Service Mesh after Installation
|
||||
## Enable the Service Mesh after Installation
|
||||
|
||||
1. Log in the console as `admin`. Click **Platform** in the top-left corner and select **Clusters Management**.
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detailed page.
|
||||
|
||||
|
||||
|
||||
2. Click **CRDs** and enter `clusterconfiguration` in the search bar. Click the result to view its detail page.
|
||||
|
||||
{{< notice info >}}
|
||||
A Custom Resource Definition (CRD) allows users to create a new type of resources without adding another API server. They can use these resources like any other native Kubernetes objects.
|
||||
{{</ notice >}}
|
||||
|
||||
3. In **Resource List**, click the three dots 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.
|
||||
|
||||
|
|
@ -98,21 +99,21 @@ A Custom Resource Definition (CRD) allows users to create a new type of resource
|
|||
You can find the web kubectl tool by clicking the hammer icon in the bottom-right corner of the console.
|
||||
{{</ notice >}}
|
||||
|
||||
## Verify the Installation of Component
|
||||
## Verify the Installation of the Component
|
||||
|
||||
{{< tabs >}}
|
||||
|
||||
{{< tab "Verify the Component in Dashboard" >}}
|
||||
{{< tab "Verify the component on the dashboard" >}}
|
||||
|
||||
Go to **Components** and check the status of Istio. You may see an image as follows:
|
||||
Go to **Components** and check the status of **Istio**. You may see an image as follows:
|
||||
|
||||
|
||||
|
||||
|
||||
{{</ tab >}}
|
||||
|
||||
{{< tab "Verify the Component through kubectl" >}}
|
||||
{{< tab "Verify the component through kubectl" >}}
|
||||
|
||||
Execute the following command to check the status of pods:
|
||||
Execute the following command to check the status of Pods:
|
||||
|
||||
```bash
|
||||
kubectl get pod -n istio-system
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 111 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 191 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 251 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 117 KiB |
Loading…
Reference in New Issue