mirror of
https://github.com/kubesphere/website.git
synced 2025-12-28 13:43:18 +00:00
KubeSphere CI Bot
GitHub
commit
42f519b651
|
|
@ -3,7 +3,7 @@ title: "Advantages"
|
|||
keywords: "KubeSphere, Kubernetes, Advantages"
|
||||
description: "KubeSphere Advantages"
|
||||
|
||||
weight: 1400
|
||||
weight: 2400
|
||||
---
|
||||
|
||||
## Vision
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubesphere, kubernetes, docker, helm, jenkins, istio, prometheus, dev
|
|||
description: "KubeSphere architecture"
|
||||
|
||||
linkTitle: "Architecture"
|
||||
weight: 1300
|
||||
weight: 2300
|
||||
---
|
||||
|
||||
## Separation of frontend and backend
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "KubeSphere, Kubernetes, Docker, Jenkins, Istio, Features"
|
|||
description: "KubeSphere Key Features"
|
||||
|
||||
linkTitle: "Features"
|
||||
weight: 1200
|
||||
weight: 2200
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "Glossary"
|
|||
keywords: 'kubernetes, docker, helm, jenkins, istio, prometheus'
|
||||
description: ''
|
||||
|
||||
weight: 1500
|
||||
weight: 2600
|
||||
---
|
||||
|
||||
This document describes some frequently used glossaries in KubeSphere as shown below:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "Use Cases"
|
|||
keywords: 'KubeSphere, Kubernetes, Multi-cluster, Observability, DevOps'
|
||||
description: 'Applicable in a variety of scenarios, KubeSphere provides enterprises with containerized environments with a complete set of features for management and operation.'
|
||||
|
||||
weight: 1498
|
||||
weight: 2500
|
||||
---
|
||||
|
||||
KubeSphere is applicable in a variety of scenarios. For enterprises that deploy their business system on bare metal, their business modules are tightly coupled with each other. That means it is extremely difficult for resources to be horizontally scaled. In this connection, KubeSphere provides enterprises with containerized environments with a complete set of features for management and operation. It empowers enterprises to rise to the challenges in the middle of their digital transformation, including agile software development, automated operation and maintenance, microservices governance, traffic management, autoscaling, high availability, as well as DevOps and CI/CD.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "What is KubeSphere"
|
|||
keywords: 'Kubernetes, KubeSphere, Introduction'
|
||||
description: 'What is KubeSphere'
|
||||
|
||||
weight: 1100
|
||||
weight: 2100
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.0"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.0"
|
||||
weight: 500
|
||||
weight: 1111
|
||||
---
|
||||
|
||||
KubeSphere 2.0.0 was released on **May 18th, 2019**.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.1"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.1"
|
||||
weight: 400
|
||||
weight: 1110
|
||||
---
|
||||
|
||||
KubeSphere 2.0.1 was released on **June 9th, 2019**.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.2"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.2"
|
||||
weight: 300
|
||||
weight: 1109
|
||||
---
|
||||
|
||||
KubeSphere 2.0.2 was released on July 9, 2019, which fixes known bugs and enhances existing feature. If you have installed versions of 1.0.x, 2.0.0 or 2.0.1, please download KubeSphere installer v2.0.2 to upgrade.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.1.0"
|
||||
|
||||
linkTitle: "Release Notes - 2.1.0"
|
||||
weight: 200
|
||||
weight: 1108
|
||||
---
|
||||
|
||||
KubeSphere 2.1.0 was released on Nov 11th, 2019, which fixes known bugs, adds some new features and brings some enhancement. If you have installed versions of 2.0.x, please upgrade it and enjoy the better user experience of v2.1.0.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.1.1"
|
||||
|
||||
linkTitle: "Release Notes - 2.1.1"
|
||||
weight: 100
|
||||
weight: 1107
|
||||
---
|
||||
|
||||
KubeSphere 2.1.1 was released on Feb 23rd, 2020, which has fixed known bugs and brought some enhancements. For the users who have installed versions of 2.0.x or 2.1.0, make sure to read the user manual carefully about how to upgrade before doing that, and feel free to raise any questions on [GitHub](https://github.com/kubesphere/kubesphere/issues).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "Kubernetes, KubeSphere, release-notes"
|
|||
description: "KubeSphere Release Notes for 3.0.0"
|
||||
|
||||
linkTitle: "Release Notes - 3.0.0"
|
||||
weight: 50
|
||||
weight: 1106
|
||||
---
|
||||
|
||||
## How to get v3.0.0
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: "账户管理和权限控制"
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "账户管理和权限控制"
|
||||
weight: 4500
|
||||
weight: 13000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "Reference"
|
||||
|
||||
weight: 8100
|
||||
weight: 18000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
|
||||
linkTitle: "应用商店"
|
||||
weight: 4600
|
||||
weight: 15000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "集群管理"
|
||||
|
||||
weight: 4100
|
||||
weight: 9000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: "如何使用 KubeSphere DevOps"
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "DevOps 用户指南"
|
||||
weight: 4400
|
||||
weight: 12000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: "FAQ is designed to answer and summarize the questions users ask mo
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "FAQ"
|
||||
weight: 7000
|
||||
weight: 17000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: "演示如何在云或本地托管的现有 Kubernetes 集群上安
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "在 Kubernetes 上安装 KubeSphere"
|
||||
weight: 2500
|
||||
weight: 5000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: "演示如何在云上和本地 Linux 环境中安装 KubeSphere。
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "在 Linux 上安装 KubeSphere"
|
||||
weight: 2000
|
||||
weight: 4000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "产品介绍"
|
||||
|
||||
weight: 1000
|
||||
weight: 2000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "Advantages"
|
|||
keywords: "KubeSphere, Kubernetes, Advantages"
|
||||
description: "KubeSphere Advantages"
|
||||
|
||||
weight: 1400
|
||||
weight: 2400
|
||||
---
|
||||
|
||||
## Vision
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubesphere, kubernetes, docker, helm, jenkins, istio, prometheus, dev
|
|||
description: "KubeSphere 架构说明"
|
||||
|
||||
linkTitle: "架构说明"
|
||||
weight: 1300
|
||||
weight: 2300
|
||||
---
|
||||
|
||||
## 前后端分离
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "KubeSphere, Kubernetes, Docker, Jenkins, Istio, Features, 平台功
|
|||
description: "KubeSphere 平台功能"
|
||||
|
||||
linkTitle: "平台功能"
|
||||
weight: 1200
|
||||
weight: 2200
|
||||
---
|
||||
|
||||
## 概览
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "名词解释"
|
|||
keywords: 'kubernetes, docker, helm, jenkins, istio, prometheus，名词解释'
|
||||
description: 'KubeSphere中常用的词汇释义'
|
||||
|
||||
weight: 1500
|
||||
weight: 2600
|
||||
---
|
||||
|
||||
本文档介绍了KubeSphere中一些常用的词汇表，如下所示：
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "Use Cases"
|
|||
keywords: 'KubeSphere, Kubernetes, Multi-cluster, Observability, DevOps'
|
||||
description: 'Applicable in a variety of scenarios, KubeSphere provides enterprises with containerized environments with a complete set of features for management and operation.'
|
||||
|
||||
weight: 1498
|
||||
weight: 2500
|
||||
---
|
||||
|
||||
KubeSphere is applicable in a variety of scenarios. For enterprises that deploy their business system on bare metal, their business modules are tightly coupled with each other. That means it is extremely difficult for resources to be horizontally scaled. In this connection, KubeSphere provides enterprises with containerized environments with a complete set of features for management and operation. It empowers enterprises to rise to the challenges in the middle of their digital transformation, including agile software development, automated operation and maintenance, microservices governance, traffic management, autoscaling, high availability, as well as DevOps and CI/CD.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: "什么是 KubeSphere"
|
|||
keywords: 'Kubernetes, KubeSphere, 介绍'
|
||||
description: '什么是 KubeSphere'
|
||||
|
||||
weight: 1100
|
||||
weight: 2100
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "多集群管理"
|
||||
|
||||
weight: 3000
|
||||
weight: 6000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "启用可插拔组件"
|
||||
|
||||
weight: 3500
|
||||
weight: 7000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: "Project Administration"
|
||||
description: "Help you to better manage KubeSphere projects"
|
||||
layout: "single"
|
||||
|
||||
linkTitle: "Project Administration"
|
||||
weight: 14000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
---
|
||||
|
||||
A KubeSphere project is a Kubernetes namespace. There are two types of projects, the single-cluster project and the multi-cluster project. The former one is the regular Kubernetes namespace, while the latter one is the federation namespace across multiple clusters. As a project administrator, there are a bunch of work to do, such as setting project quotas, managing gateway, access control, etc.
|
||||
|
||||
## [Projects and Multi-cluster Projects](../project-administration/project-and-multicluster-project/)
|
||||
|
||||
Learn how to manage different types of projects.
|
||||
|
||||
## [Project Quotas](../project-administration/project-quota/)
|
||||
|
||||
Learn how to configure project quotas of resources such as workloads, CPU, memory.
|
||||
|
||||
## [Project Gateway](../project-administration/project-gateway/)
|
||||
|
||||
Understand the concept of project gateway and how to manage it.
|
||||
|
||||
## [Project Network Isolation](../project-administration/project-network-isolation/)
|
||||
|
||||
Understand the concept of network isolation and how to configure policies for a project.
|
||||
|
||||
## [Role and Member Management](../project-administration/role-and-member-management/)
|
||||
|
||||
Learn how to manage access control for a project.
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
---
|
||||
title: "Projects and Multi-cluster Projects"
|
||||
keywords: 'KubeSphere, Kubernetes, project, multicluster-project'
|
||||
description: 'This tutorial introduces projects and multi-cluster projects.'
|
||||
|
||||
linkTitle: "Projects and Multi-cluster Projects"
|
||||
weight: 2100
|
||||
---
|
||||
|
||||
A project in KubeSphere is a Kubernetes [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which is used to organize resources into non-overlapping groups. It represents a logical partitioning capability as it divides cluster resources between multiple tenants.
|
||||
|
||||
A multi-cluster project runs across clusters, empowering users to achieve high availability and isolate occurring issues to a certain cluster while not affecting your business. For more information, see [Multi-cluster Management](../../multicluster-management/).
|
||||
|
||||
This chapter demonstrates the basic operations of project administration, such as creation and deletion.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You have an available workspace.
|
||||
- You must have the authorization of **Projects Management**, which is included in the built-in role `workspace-self-provisioner`.
|
||||
- You must enable the multi-cluster feature through [Direction Connection](../../multicluster-management/enable-multicluster/direct-connection/) or [Agent Connection](../../multicluster-management/enable-multicluster/agent-connection/) before you create a multi-cluster project.
|
||||
|
||||
## Projects
|
||||
|
||||
### Create a project
|
||||
|
||||
1. Go to the **Projects** page of a workspace and click **Create**.
|
||||
|
||||
|
||||
|
||||
{{< 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.
|
||||
- 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, the platform administrator or cluster administrator needs to edit [**Cluster Visibility**](../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/) on the **Cluster Management** page.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
2. In the **Create Project** window that appears, enter a project name and add an alias or description if necessary. 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** to finish.
|
||||
|
||||
|
||||
|
||||
3. A project created will display in the list as shown below. You can click the project name to go to its **Overview** page.
|
||||
|
||||
|
||||
|
||||
### Edit project information
|
||||
|
||||
1. Navigate to **Basic Info** under **Project Settings** and click **Manage Project** on the right.
|
||||
|
||||
|
||||
|
||||
2. Choose **Edit Info** from the drop-down menu.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The project name cannot be edited. If you want to change other information, see relevant chapters in the documentation.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
### Delete a project
|
||||
|
||||
1. Navigate to **Basic Info** under **Project Settings** and click **Manage Project** on the right.
|
||||
|
||||
|
||||
|
||||
2. Choose **Delete Project** from the drop-down menu.
|
||||
|
||||
3. In the dialog that appears, enter the project name and click **OK** to confirm the deletion.
|
||||
|
||||
{{< notice warning >}}
|
||||
|
||||
A project cannot be recovered once deleted and resources in the project will be removed as well.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
## Multi-cluster Projects
|
||||
|
||||
### Create a multi-cluster project
|
||||
|
||||
1. Go to the **Projects** page of a workspace, choose **Multi-cluster Projects** and click **Create**.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- If you cannot see the **Create** button, it means no cluster is available to use for your workspace. You need to contact the platform administrator or cluster administrator so that workspace resources can be created in the cluster. To assign a cluster to a workspace, the platform administrator or cluster administrator needs to edit [**Cluster Visibility**](../../cluster-administration/cluster-settings/cluster-visibility-and-authorization/) on the **Cluster Management** page.
|
||||
- Make sure at least two clusters are assigned to your workspace.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
2. In the **Create Multi-cluster Project** window that appears, enter a project name and add an alias or description if necessary. Select multiple clusters for your project by clicking **Add Cluster**, and click **OK** to finish.
|
||||
|
||||
|
||||
|
||||
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 multi-cluster project information
|
||||
|
||||
1. Navigate to **Basic Info** under **Project Settings** and click **Manage Project** on the right.
|
||||
|
||||
|
||||
|
||||
2. Choose **Edit Info** from the drop-down menu.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The project name cannot be edited. If you want to change other information, see relevant chapters in the documentation.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
### Delete a multi-cluster project
|
||||
|
||||
1. Navigate to **Basic Info** under **Project Settings** and click **Manage Project** on the right.
|
||||
|
||||
|
||||
|
||||
2. Choose **Delete Project** from the drop-down menu.
|
||||
|
||||
3. In the dialog that appears, enter the project name and click **OK** to confirm the deletion.
|
||||
|
||||
{{< notice warning >}}
|
||||
|
||||
A multi-cluster project cannot be recovered once deleted and resources in the project will be removed as well.
|
||||
|
||||
{{</ notice >}}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: "Project Gateway"
|
||||
keywords: 'KubeSphere, kubernetes, docker, helm, jenkins, istio, prometheus'
|
||||
description: 'Project Gateway'
|
||||
|
||||
linkTitle: "Project Gateway"
|
||||
weight: 2130
|
||||
---
|
||||
|
||||
TBD
|
||||
|
|
@ -0,0 +1,181 @@
|
|||
---
|
||||
title: "Project Network Isolation"
|
||||
keywords: 'KubeSphere, kubernetes, Calico, Network Policy'
|
||||
description: 'Project Network Isolation'
|
||||
|
||||
linkTitle: "Project Network Isolation"
|
||||
weight: 2130
|
||||
---
|
||||
|
||||
KubeSphere project network isolation lets project administrators enforce which network traffic is allowed using rules.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You have already enabled Network Policy. Please refer to [network-policy](../../pluggable-components/network-policy) if it is not ready yet.
|
||||
- Use an account of the `admin` role at the project level. For example, use the account `project-admin` created in [Create Workspace, Project, Account and Role](../../quick-start/create-workspace-and-project/).
|
||||
|
||||
{{< notice note >}}
|
||||
For the implementation of the Network Policy, you can refer to [kubesphere-network-policy](https://github.com/kubesphere/community/blob/master/sig-network/concepts-and-designs/kubesphere-network-policy.md).
|
||||
{{</ notice >}}
|
||||
|
||||
## Enable/Disable Project Network Isolation
|
||||
|
||||
By default project network isolation is disabled, you can turn on network isolation via **Project Settings/Network Isolation**
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
When network isolation is turned on, egress traffic will be allowed by default, while ingress traffic will be denied for
|
||||
different projects. But when you add an egress network policy, only traffic that matches your policy will be allowed to go out.
|
||||
{{</ notice >}}
|
||||
|
||||
You can also disable network isolation via this path.
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
When network isolation is turned off, any previously created network policies will be deleted as well.
|
||||
{{</ notice >}}
|
||||
|
||||
## Setting Network Policy
|
||||
|
||||
If the default policy does not meet your needs when network isolation is enabled, you can customize your network policy
|
||||
to meet your needs. Currently, you can add custom network policies in KubeSphere from two perspectives:
|
||||
|
||||
- Cluster Internal
|
||||
- Cluster External
|
||||
|
||||
### Cluster Internal
|
||||
|
||||
Network policies at the project level within a cluster are used to control whether resources in this project can be accessed by other projects within the same cluster, and which services you can access.
|
||||
|
||||
Suppose a `nginx deployment` workload has been created in the other project `testProject` and is exposed via service `testService` on port `80` with `TCP`.
|
||||
|
||||
#### Allow ingress traffic from workloads in a different project
|
||||
|
||||
1. Select **Cluster Internal Allowlist**
|
||||
2. Click **Add Allowlist**
|
||||
3. Select type **Project**
|
||||
4. Select project `testProject`
|
||||
5. Select direction **Ingress**
|
||||
6. Click **OK**
|
||||
|
||||
{{< notice note >}}
|
||||
If the network still doesn't work after you set the network policy, then you need to check if peer has set the corresponding egress rule.
|
||||
{{</ notice >}}
|
||||
|
||||
#### Allow egress traffic to workloads selected by service
|
||||
|
||||
1. Select **Cluster Internal Allowlist**
|
||||
2. Click **Add Allowlist**
|
||||
3. Select type **Service**
|
||||
4. Select the project `testProject`
|
||||
5. Select the service `testService` that you want to allow
|
||||
6. Select direction **Egress**
|
||||
7. Click **OK**
|
||||
|
||||
{{< notice note >}}
|
||||
When creating a service you must make sure that the selectors of the service are not empty.
|
||||
{{</ notice >}}
|
||||
|
||||
### Cluster External
|
||||
|
||||
Outside the cluster we distinguish between the peers by CIDR.
|
||||
|
||||
Suppose a `tomcat deployment` workload has been created in this project and is exposed via `NodePort` service `testService` on NodePort `80` with `TCP`.
|
||||
A client with ip address `192.168.1.1` will access this service, and the service will have access to the address `http://10.1.0.1:80`.
|
||||
|
||||
#### Allow ingress traffic from client outside the cluster
|
||||
|
||||
1. Select **Cluster External IP Address**
|
||||
2. Select direction **Ingress**
|
||||
3. Fill CIDR `192.168.1.1/32`
|
||||
4. Select protocol `TCP` and fill port `80`
|
||||
5. Click **OK**
|
||||
|
||||
{{< notice note >}}
|
||||
It is best to set `spec.externalTrafficPolicy` in the service configuration to `local`, so that the source address of the packet will not change, i.e. the source address of the packet is the source address of the client.
|
||||
{{</ notice >}}
|
||||
|
||||
#### Allow egress traffic to service outside the cluster
|
||||
|
||||
1. Select **Cluster External IP Address**
|
||||
2. Select direction **Egress**
|
||||
3. Fill CIDR `10.1.0.1/32`
|
||||
4. Select protocol `TCP` and fill port `80`
|
||||
5. Click **OK**
|
||||
|
||||
{{< notice note >}}
|
||||
In step 4, when you select **SCTP**, you must make sure the SCTP is [enabled](https://kubernetes.io/docs/concepts/services-networking/network-policies/#sctp-support).
|
||||
{{</ notice >}}
|
||||
|
||||
### Best Practices
|
||||
|
||||
To ensure that all Pods in the project are secure, a best practice is to enable network isolation.
|
||||
|
||||
When network isolation is on, the project cannot be accessed by other projects. If your workloads need to be accessed by others, you can follow these steps:
|
||||
|
||||
1. Set gateway via **[Project Settings/Advanced Settings](../project-gateway/)**.
|
||||
2. Expose workloads that need to be accessed to a gateway via a service.
|
||||
3. Allow ingress traffic from the namespace where you gateway locate.
|
||||
|
||||
If egress traffic is controlled, you should have a clear plan of what projects, services, and IP addresses can be accessed, and then add them one by one.
|
||||
If you're not sure what you want, then you'd better keep your network policy unchanged.
|
||||
|
||||
## FAQs
|
||||
|
||||
Q: **Why can't the custom monitoring system of KubeSphere get data after I enabled network isolation?**
|
||||
|
||||
A: After you enabled custom monitoring, KubeSphere monitoring system will access the metrics of the Pod. You need to allow ingress traffic for KubeSphere monitoring system. Otherwise, it cannot access Pod metrics.
|
||||
|
||||
Here KubeSphere provides a configuration item `allowedIngressNamespaces`to simplify similar configurations, which allows you to allow all projects
|
||||
listed in the configuration.
|
||||
|
||||
```yaml
|
||||
root@node1:~# kubectl get -n kubesphere-system clusterconfigurations.installer.kubesphere.io ks-installer -o yaml
|
||||
apiVersion: installer.kubesphere.io/v1alpha1
|
||||
kind: ClusterConfiguration
|
||||
metadata:
|
||||
...
|
||||
name: ks-installer
|
||||
namespace: kubesphere-system
|
||||
...
|
||||
spec:
|
||||
...
|
||||
networkpolicy:
|
||||
enabled: true
|
||||
nsnpOptions:
|
||||
allowedIngressNamespaces:
|
||||
- kubesphere-system
|
||||
- kubesphere-monitoring-system
|
||||
...
|
||||
```
|
||||
|
||||
Q: **Why can't I access the service even after setting network policy through the service?**
|
||||
|
||||
A: When you add a network policy and access the service via cluster ip, if the network is not
|
||||
working, check the kube-proxy configuration to see if `masqueradeAll` is `false`.
|
||||
|
||||
```yaml
|
||||
root@node1:~# kubectl get cm -n kube-system kube-proxy -o yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
config.conf: |-
|
||||
...
|
||||
iptables:
|
||||
masqueradeAll: false
|
||||
...
|
||||
...
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
...
|
||||
labels:
|
||||
app: kube-proxy
|
||||
name: kube-proxy
|
||||
namespace: kube-system
|
||||
...
|
||||
```
|
||||
|
||||
Q: **How do I determine the CIDR when I set the ingress policy?**
|
||||
|
||||
A: In K8s, 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.
|
||||
Here you can refer to [Source IP](https://github.com/kubesphere/community/blob/master/sig-network/concepts-and-designs/kubesphere-network-policy.md#source-ip).
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: "Project Quotas"
|
||||
keywords: 'kubernetes, docker, helm, jenkins, istio, prometheus'
|
||||
description: 'Project Quotas'
|
||||
|
||||
linkTitle: "Project Quotas"
|
||||
weight: 2110
|
||||
---
|
||||
|
||||
TBD
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
---
|
||||
title: "Role and Member Management"
|
||||
keywords: 'KubeSphere, Kubernetes, role, member, management, project'
|
||||
description: 'Role and Member Management in a Project'
|
||||
|
||||
linkTitle: "Role and Member Management"
|
||||
weight: 2130
|
||||
---
|
||||
|
||||
This guide demonstrates how to manage roles and members in your project. For more information about KubeSphere roles, see Overview of Role Management.
|
||||
|
||||
In project scope, you can grant the following resources' permissions to a role:
|
||||
|
||||
- Application Workloads
|
||||
- Storage
|
||||
- Configurations
|
||||
- Monitoring & Alerting
|
||||
- Project Settings
|
||||
- Access Control
|
||||
|
||||
## Prerequisites
|
||||
|
||||
At least one project has been created, such as `demo-project`. Besides, you need an account of the `admin` role (e.g. `project-admin`) at the project level. See [Create Workspace, Project, Account and Role](../../quick-start/create-workspace-and-project/) if it is not ready yet.
|
||||
|
||||
## Built-in Roles
|
||||
|
||||
In **Project Roles**, there are three available built-in roles as shown below. Built-in roles are created automatically by KubeSphere when a project is created and they cannot be edited or deleted. You can only view permissions and authorized user list.
|
||||
|
||||
| Built-in Roles | Description |
|
||||
| ------------------ | ------------------------------------------------------------ |
|
||||
| viewer | The viewer who can view all resources in the project. |
|
||||
| operator | The maintainer of the project who can manage resources other than users and roles in the project. |
|
||||
| admin | The administrator in the project who can perform any action on any resource. It gives full control over all resources in the project. |
|
||||
|
||||
1. In **Project Roles**, click `admin` and you can see the role detail as shown below.
|
||||
|
||||
|
||||
|
||||
2. You can switch to **Authorized Users** tab to see all the users that are granted an `admin` role.
|
||||
|
||||
## Create a Project Role
|
||||
|
||||
1. Log in the console as `project-admin` and select a project (e.g. `demo-project`) under **Projects** list.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The account `project-admin` is used as an example. As long as the account you are using is granted a role including the authorization of **Project Members View**, **Project Roles Management** and **Project Roles View** in **Access Control** at project level, it can create a project role.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
2. Go to **Project Roles** in **Project Settings**, click **Create** and set a **Role Identifier**. In this example, a role named `project-monitor` will be created. Click **Edit Authorization** to continue.
|
||||
|
||||
|
||||
|
||||
3. Select the authorization that you want the user granted this role to have. For example, **Application Workloads View** in **Application Workloads**, and **Alerting Messages View** and **Alerting Policies View** in **Monitoring & Alerting** are selected for this role. Click **OK** to finish.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
**Depend on** means the major authorization (the one listed after **Depend on**) needs to be selected first so that the affiliated authorization can be assigned.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
4. Newly-created roles will be listed in **Project Roles**. You can click the three dots on the right to edit it.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The role of `project-monitor` is only granted limited permissions in **Monitoring & Alerting**, which may not satisfy your need. This example is only for demonstration purpose. You can create customized roles based on your needs.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
## Invite a New Member
|
||||
|
||||
1. In **Project Settings**, select **Project Members** and click **Invite Member**.
|
||||
2. Invite a user to the project. Grant the role of `project-monitor` to the user.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The user must be invited to the project's workspace first.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
3. After you add a user to the project, click **OK**. In **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 project.
|
||||
|
||||
|
||||
|
|
@ -4,7 +4,7 @@ description: "帮助您更好地管理 KubeSphere 项目中的资源"
|
|||
layout: "single"
|
||||
|
||||
linkTitle: "项目用户指南"
|
||||
weight: 4300
|
||||
weight: 11000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "快速入门"
|
||||
|
||||
weight: 1500
|
||||
weight: 3000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "Release Notes"
|
||||
|
||||
weight: 1
|
||||
weight: 1000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.0"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.0"
|
||||
weight: 500
|
||||
weight: 1111
|
||||
---
|
||||
|
||||
KubeSphere 2.0.0 was released on **May 18th, 2019**.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.1"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.1"
|
||||
weight: 400
|
||||
weight: 1110
|
||||
---
|
||||
|
||||
KubeSphere 2.0.1 was released on **June 9th, 2019**.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.0.2"
|
||||
|
||||
linkTitle: "Release Notes - 2.0.2"
|
||||
weight: 300
|
||||
weight: 1109
|
||||
---
|
||||
|
||||
KubeSphere 2.0.2 was released on July 9, 2019, which fixes known bugs and enhances existing feature. If you have installed versions of 1.0.x, 2.0.0 or 2.0.1, please download KubeSphere installer v2.0.2 to upgrade.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.1.0"
|
||||
|
||||
linkTitle: "Release Notes - 2.1.0"
|
||||
weight: 200
|
||||
weight: 1108
|
||||
---
|
||||
|
||||
KubeSphere 2.1.0 was released on Nov 11th, 2019, which fixes known bugs, adds some new features and brings some enhancement. If you have installed versions of 2.0.x, please upgrade it and enjoy the better user experience of v2.1.0.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "kubernetes, docker, kubesphere, jenkins, istio, prometheus"
|
|||
description: "KubeSphere Release Notes For 2.1.1"
|
||||
|
||||
linkTitle: "Release Notes - 2.1.1"
|
||||
weight: 100
|
||||
weight: 1007
|
||||
---
|
||||
|
||||
KubeSphere 2.1.1 was released on Feb 23rd, 2020, which has fixed known bugs and brought some enhancements. For the users who have installed versions of 2.0.x or 2.1.0, make sure to read the user manual carefully about how to upgrade before doing that, and feel free to raise any questions on [GitHub](https://github.com/kubesphere/kubesphere/issues).
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ keywords: "Kubernetes, KubeSphere, release-notes"
|
|||
description: "KubeSphere Release Notes for 3.0.0"
|
||||
|
||||
linkTitle: "Release Notes - 3.0.0"
|
||||
weight: 50
|
||||
weight: 1006
|
||||
---
|
||||
|
||||
## How to get v3.0.0
|
||||
|
|
|
|||
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
title: "Toolbox"
|
||||
description: "Help you to better understand KubeSphere toolbox"
|
||||
layout: "single"
|
||||
|
||||
linkTitle: "Toolbox"
|
||||
|
||||
weight: 16000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
---
|
||||
|
||||
KubeSphere provides several important functionalities from the toolbox. This chapter demonstrates how to use toolbox of KubeSphere to perform event, log, auditing log queries and run commands with web kubectl.
|
||||
|
||||
|
||||
|
||||
## [Log Query](../toolbox/log-query/)
|
||||
|
||||
Understand how you can perform quick log queries to keep track of the latest logs of your cluster.
|
||||
|
||||
## [Event Query](../toolbox/events-query/)
|
||||
|
||||
Understand how you can perform quick event queries to keep track of the latest events of your cluster.
|
||||
|
||||
## Auditing
|
||||
|
||||
### [Receive and Customize Auditing Logs](../toolbox/auditing/auditing-receive-customize/)
|
||||
|
||||
Learn how to receive and customize auditing logs.
|
||||
|
||||
### [Auditing Rule](../toolbox/auditing/auditing-rule/)
|
||||
|
||||
Understand the auditing rule and how to customize a rule for processing auditing logs.
|
||||
|
||||
### [Auditing Log Query](../toolbox/auditing/auditing-query/)
|
||||
|
||||
Understand how you can perform quick auditing log queries to keep track of the latest audits of your cluster.
|
||||
|
||||
## [Web Kubectl](../toolbox/web-kubectl/)
|
||||
|
||||
The web kubectl tool is integrated into KubeSphere to provide consistent user experiences for Kubernetes users.
|
||||
|
||||
## [History](../toolbox/history/)
|
||||
|
||||
Learn how to quickly switch between the resources you access in your workspace.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
linkTitle: "Auditing"
|
||||
weight: 5510
|
||||
|
||||
_build:
|
||||
render: false
|
||||
---
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
title: "Auditing Log Query"
|
||||
keywords: "Kubernetes, KubeSphere, auditing, log, query"
|
||||
description: "How to perform queries of auditing logs in KubeSphere."
|
||||
|
||||
linkTitle: "Auditing Log Query"
|
||||
weight: 4914
|
||||
---
|
||||
|
||||
KubeSphere supports the query of auditing logs among isolated tenants. In this tutorial, you will learn how to use the query function, including the interface, search parameters and detail pages.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need to enable [KubeSphere Auditing Logs](../../../pluggable-components/auditing-logs/).
|
||||
|
||||
## Enter Query Dashboard
|
||||
|
||||
1. The query function is available for all users. Log in the console with any account, hover over the **Toolbox** in the lower right corner and select **Auditing Operating**.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
Any account has the authorization to query auditing logs, while the logs each account is able to see are different.
|
||||
|
||||
- If an account has the authorization of viewing resources in a project, it can see the auditing log that happens in this project, such as workload creation in the project.
|
||||
- If an account has the authorization of listing projects in a workspace, it can see the auditing log that happens in this workspace but not in projects, such as project creation in the workspace.
|
||||
- If an account has the authorization of listing projects in a cluster, it can see the auditing log that happens in this cluster but not in workspaces and projects, such as workspace creation in the cluster.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
|
||||
|
||||
2. As shown in the pop-up window, you can see trends in the total number of auditing logs in the last 12 hours.
|
||||
|
||||
|
||||
|
||||
3. The **Auditing Operating** console supports the following query parameters:
|
||||
|
||||
|
||||
|
||||
Parameter | Description
|
||||
--- | ---
|
||||
Cluster | The cluster where the operation happens. It is enabled if the [multi-cluster feature](../../../multicluster-management/) is turned on.
|
||||
Project | The project where the operation happens. It supports exact query and fuzzy query.
|
||||
Workspace | The workspace where the operation happens. It supports exact query and fuzzy query.
|
||||
Resource Type | The type of resource associated with the request. It supports fuzzy query.
|
||||
Resource Name | The name of the resource associated with the request. It supports fuzzy query.
|
||||
Verb | The Kubernetes verb associated with the request. For non-resource requests, this is the lower-case HTTP method. It supports exact query.
|
||||
Status Code | The Http response code. It supports exact query.
|
||||
Operation Account | The user who calls this request. It supports exact and fuzzy query.
|
||||
Source IP | The IP address from where the request originated and intermediate proxies. It supports fuzzy query.
|
||||
Time Range | The time when the request reaches the apiserver.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- Fuzzy query supports case-insensitive fuzzy matching and retrieval of full terms by the first half of a word or phrase based on Elasticsearch segmentation rules.
|
||||
- KubeSphere stores logs for the last seven days by default. You can modify the retention period in the ConfigMap `elasticsearch-logging-curator`.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
## Enter Query Parameters
|
||||
|
||||
1. Select a filter and input the keyword you want to search. For example, query auditing logs containing the information of `user` changed as shown in the following screenshot:
|
||||
|
||||
|
||||
|
||||
2. Click any one of the results from the list, and you can see the detail of the auditing log.
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,181 @@
|
|||
---
|
||||
title: "Receive and Customize Auditing Logs"
|
||||
keywords: "Kubernetes, KubeSphere, auditing, log, customize, receive"
|
||||
description: "How to receive and customize KubeSphere and Kubernetes auditing logs."
|
||||
|
||||
linkTitle: "Receive and Customize Auditing Logs"
|
||||
weight: 4910
|
||||
---
|
||||
|
||||
KubeSphere Auditing Logs provide a security-relevant chronological set of records documenting the sequence of activities that have affected the system by individual users, administrators, or other components of the system. Each request to KubeSphere generates an event that is then written to a webhook and processed according to a certain rule. The event will be ignored, stored, or generate an alert based on different rules.
|
||||
|
||||
## Enable KubeSphere Auditing Logs
|
||||
|
||||
To enable auditing logs, see [KubeSphere Auditing Logs](../../../pluggable-components/auditing-logs/).
|
||||
|
||||
## Receive Auditing Logs from KubeSphere
|
||||
|
||||
KubeSphere Auditing Log system receives auditing logs only from KubeSphere by default, while it can also receive auditing logs from Kubernetes.
|
||||
|
||||
Users can stop receiving auditing logs from KubeSphere by changing the value of `auditing.enable` in ConfigMap `kubesphere-config` in the namespace `kubesphere-system` using the following command:
|
||||
|
||||
```bash
|
||||
kubectl edit cm -n kubesphere-system kubesphere-config
|
||||
```
|
||||
|
||||
Change the value of `auditing.enabled` as `false` to stop receiving auditing logs from KubeSphere.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
auditing:
|
||||
enabled: false
|
||||
```
|
||||
|
||||
It should restart the KubeSphere apiserver to make the changes effective.
|
||||
|
||||
## Receive Auditing Logs from Kubernetes
|
||||
|
||||
To make the KubeSphere Auditing Log system receive auditing logs from Kubernetes, you need to add a Kubernetes audit policy file and Kubernetes audit webhook config file to `/etc/kubernetes/manifests/kube-apiserver.yaml` as follows.
|
||||
|
||||
### Audit policy
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: kube-apiserver
|
||||
namespace: kube-system
|
||||
spec:
|
||||
containers:
|
||||
- command:
|
||||
- kube-apiserver
|
||||
- --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
|
||||
- --audit-webhook-config-file=/etc/kubernetes/audit/audit-webhook.yaml
|
||||
volumeMounts:
|
||||
- mountPath: /etc/kubernetes/audit
|
||||
name: k8s-audit
|
||||
readOnly: true
|
||||
volumes:
|
||||
- hostPath:
|
||||
path: /etc/kubernetes/audit
|
||||
type: DirectoryOrCreate
|
||||
name: k8s-audit
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
This operation will restart the Kubernetes apiserver.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
The file `audit-policy.yaml` defines rules about what events should be recorded and what data they should include. You can use a minimal audit policy file to log all requests at the Metadata level:
|
||||
|
||||
```yaml
|
||||
# Log all requests at the Metadata level.
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: Metadata
|
||||
```
|
||||
|
||||
For more information about the audit policy, see [Audit Policy](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/#audit-policy).
|
||||
|
||||
### Audit webhook
|
||||
|
||||
The file `audit-webhook.yaml` defines the webhook which the Kubernetes auditing logs will be sent to. Here is an example configuration of the Kube-Auditing webhook.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
clusters:
|
||||
- name: kube-auditing
|
||||
cluster:
|
||||
server: https://{ip}:443/audit/webhook/event
|
||||
insecure-skip-tls-verify: true
|
||||
contexts:
|
||||
- context:
|
||||
cluster: kube-auditing
|
||||
user: ""
|
||||
name: default-context
|
||||
current-context: default-context
|
||||
preferences: {}
|
||||
users: []
|
||||
```
|
||||
|
||||
The `ip` is the `CLUSTER-IP` of Service `kube-auditing-webhook-svc` in the namespace `kubesphere-logging-system`. You can get it using this command.
|
||||
|
||||
```bash
|
||||
kubectl get svc -n kubesphere-logging-system
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
It should restart the Kubernetes apiserver to make the changes effective after you modified these two files.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
Edit the CRD Webhook `kube-auditing-webhook`, and change the value of `k8sAuditingEnabled` to `true` through the following commands.
|
||||
|
||||
```bash
|
||||
kubectl edit webhooks.auditing.kubesphere.io kube-auditing-webhook
|
||||
```
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
auditing:
|
||||
k8sAuditingEnabled: true
|
||||
```
|
||||
{{< notice tip >}}
|
||||
|
||||
You can also use an account of `platform-admin` role to log in the console, search `Webhook` in **CRDs** on the **Cluster Management** page, and edit `kube-auditing-webhook` directly.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
To stop receiving auditing logs from Kubernetes, remove the configuration of auditing webhook backend, then change the value of `k8sAuditingEnabled` to `false`.
|
||||
|
||||
## Customize Auditing Logs
|
||||
|
||||
KubeSphere Auditing Log system provides a CRD Webhook `kube-auditing-webhook` to customize auditing logs. Here is an example yaml file:
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Webhook
|
||||
metadata:
|
||||
name: kube-auditing-webhook
|
||||
spec:
|
||||
auditLevel: RequestResponse
|
||||
auditSinkPolicy:
|
||||
alertingRuleSelector:
|
||||
matchLabels:
|
||||
type: alerting
|
||||
archivingRuleSelector:
|
||||
matchLabels:
|
||||
type: persistence
|
||||
image: kubesphere/kube-auditing-webhook:v0.1.0
|
||||
archivingPriority: DEBUG
|
||||
alertingPriority: WARNING
|
||||
replicas: 2
|
||||
receivers:
|
||||
- name: alert
|
||||
type: alertmanager
|
||||
config:
|
||||
service:
|
||||
namespace: kubesphere-monitoring-system
|
||||
name: alertmanager-main
|
||||
port: 9093
|
||||
```
|
||||
|
||||
Parameter | Description | Default
|
||||
--- | --- | ---
|
||||
`replicas` | The replica number of the Kube-Auditing webhook. | 2
|
||||
`archivingPriority` | The priority of the archiving rule. The known audit types are `DEBUG`, `INFO`, and `WARNING`. | `DEBUG`
|
||||
`alertingPriority` | The priority of the alerting rule. The known audit types are `DEBUG`, `INFO`, and `WARNING`. | `WARNING`
|
||||
`auditLevel` | The level of auditing logs. The known levels are: <br> - `None`: don't log events. <br> - `Metadata`: log request metadata (requesting user, timestamp, resource, verb, etc.) but not requests or response bodies. <br> - `Request`: log event metadata and request bodies but no response body. This does not apply to non-resource requests. <br> - `RequestResponse`: log event metadata, requests, and response bodies. This does not apply to non-resource requests. | `Metadata`
|
||||
`k8sAuditingEnabled` | Whether to receive Kubernetes auditing logs. | `false`
|
||||
`receivers` | The receivers to receive alerts. |
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
You can change the level of Kubernetes auditing logs by modifying the file `audit-policy.yaml`, then restart the Kubernetes apiserver.
|
||||
|
||||
{{</ notice >}}
|
||||
|
|
@ -0,0 +1,212 @@
|
|||
---
|
||||
title: "Auditing Rule"
|
||||
keywords: "Kubernetes, docker, kubesphere, auditing"
|
||||
description: "Kubernetes and KubeSphere operation auditing"
|
||||
|
||||
linkTitle: "Auditing Rule"
|
||||
weight: 4912
|
||||
---
|
||||
|
||||
An auditing rule defines the policy for processing auditing logs. KubeSphere Auditing Logs provide users with two CRD rules (`archiving-rule` and `alerting-rule`) for customization.
|
||||
|
||||
After you enable [KubeSphere Auditing Logs](../../../pluggable-components/auditing-logs/), log in the console with an account of `platform-admin` role. In **CRDs** on the **Cluster Management** page, input `rules.auditing.kubesphere.io` in the search bar. Click the result **Rule** as below and you can see the two CRD rules.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Below are examples of part of the rules.
|
||||
|
||||
## archiving-rule
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Rule
|
||||
metadata:
|
||||
labels:
|
||||
type: archiving
|
||||
workspace: system-workspace
|
||||
name: archiving-rule
|
||||
spec:
|
||||
rules:
|
||||
- desc: all action not need to be audit
|
||||
list:
|
||||
- get
|
||||
- list
|
||||
- watch
|
||||
name: ignore-action
|
||||
type: list
|
||||
- condition: Verb not in ${ignore-action}
|
||||
desc: All audit event except get, list, watch event
|
||||
enable: true
|
||||
name: archiving
|
||||
priority: DEBUG
|
||||
type: rule
|
||||
```
|
||||
|
||||
## alerting-rule
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Rule
|
||||
metadata:
|
||||
labels:
|
||||
type: alerting
|
||||
workspace: system-workspace
|
||||
name: alerting-rule
|
||||
spec:
|
||||
rules:
|
||||
- desc: all operator need to be audit
|
||||
list:
|
||||
- create
|
||||
- delete
|
||||
- update
|
||||
- patch
|
||||
name: action
|
||||
type: list
|
||||
- condition: Verb in ${action}
|
||||
desc: audit the change of resource
|
||||
enable: true
|
||||
name: ResourceChange
|
||||
priority: INFO
|
||||
type: rule
|
||||
```
|
||||
|
||||
Attributes | Description
|
||||
--- | ---
|
||||
`name` | The name of the rule.
|
||||
`type` | The type of the rule; known values are `rule`, `macro`, `list`, and `alias`.
|
||||
`desc` | The description of the rule.
|
||||
`condition` | A filtering expression that is applied against auditing logs to check whether they match the rule.
|
||||
`macro` | The conditions of the macro.
|
||||
`list` | The value of list.
|
||||
`alias` | The value of alias.
|
||||
`enable` | If it is set to `false`, the rule will not be effective.
|
||||
`output` | Specifies the message of alert.
|
||||
`priority` | The priority of the rule.
|
||||
|
||||
When an auditing log matches a rule in `archiving-rule` and the rule priority is no less than `archivingPriority`, it will be stored for further use. When an auditing log matches a rule in `alerting-rule`, if the priority of the rule is less than `alertingPriority`, it will be stored for further use; otherwise it will generate an alert which will be sent to the user.
|
||||
|
||||
|
||||
## Rule Condition
|
||||
|
||||
A `Condition` is a filtering expression that can use comparison operators (=, !=, <, <=, >, >=, contains, in, like, and regex) and can be combined using Boolean operators (and, or and not) and parentheses. Here are the supported filters.
|
||||
|
||||
Filter | Description
|
||||
--- | ---
|
||||
`Workspace` | The workspace where the audit event happens.
|
||||
`Devops` | The DevOps project where the audit event happens.
|
||||
`Level` | The level of auditing logs.
|
||||
`RequestURI` | RequestURI is the request URI as sent by the client to a server.
|
||||
`Verb` | The verb associated with the request.
|
||||
`User.Username` | The name that uniquely identifies this user among all active users.
|
||||
`User.Groups` | The names of groups this user is a part of.
|
||||
`SourceIPs` | The source IP from where the request originated and intermediate proxies.
|
||||
`ObjectRef.Resource` | The resource of the object associated with the request.
|
||||
`ObjectRef.Namespace` | The namespace of the object associated with the request.
|
||||
`ObjectRef.Name` | The name of the object associated with the request.
|
||||
`ObjectRef.Subresource` | The subresource of the object associated with the request.
|
||||
`ResponseStatus.code` | The suggested HTTP return code for the request.
|
||||
`ResponseStatus.Status` | The status of the operation.
|
||||
`RequestReceivedTimestamp` | The time the request reaches the apiserver.
|
||||
`StageTimestamp` | The time the request reaches the current audit stage.
|
||||
|
||||
For example, to match all logs in the namespace `test`:
|
||||
|
||||
```
|
||||
ObjectRef.Namespace = "test"
|
||||
```
|
||||
|
||||
To match all logs in the namespaces that start with `test`:
|
||||
|
||||
```
|
||||
ObjectRef.Namespace like "test*"
|
||||
```
|
||||
|
||||
To match all logs happening in the latest one hour:
|
||||
|
||||
```
|
||||
RequestReceivedTimestamp >= "2020-06-12T09:23:28.359896Z" and RequestReceivedTimestamp <= "2020-06-12T10:23:28.359896Z"
|
||||
```
|
||||
|
||||
## Macro
|
||||
|
||||
A `macro` is a rule condition snippet that can be re-used inside rules and even other macros. Macros provide a way to name common patterns and factor out redundancies in rules. Here is an example of a macro.
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Rule
|
||||
metadata:
|
||||
name: alerting-rule
|
||||
labels:
|
||||
workspace: system-workspace
|
||||
type: alerting
|
||||
spec:
|
||||
rules:
|
||||
- name: pod
|
||||
type: macro
|
||||
desc: pod
|
||||
macro: ObjectRef.Resource="pods"
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
A `macro` can be used in rules or other macros like ${pod} or ${alerting-rule.pod}. The difference between these two methods is that ${pod} can only be used in the CRD Rule `alerting-rule`, while ${alerting-rule.pod} can be used in all CRD Rules. This principle also applies to lists and alias.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
## List
|
||||
|
||||
A `list` is a collection of items that can be included in rules, macros, or other lists. Unlike rules and macros, lists cannot be parsed as filtering expressions. Here is an example of a list.
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Rule
|
||||
metadata:
|
||||
name: alerting-rule
|
||||
labels:
|
||||
workspace: system-workspace
|
||||
type: alerting
|
||||
spec:
|
||||
rules:
|
||||
- name: action
|
||||
type: list
|
||||
desc: all operator needs to be audit
|
||||
list:
|
||||
- create
|
||||
- delete
|
||||
- update
|
||||
- patch
|
||||
```
|
||||
|
||||
## Alias
|
||||
|
||||
An `alias` is a short name of a filter field. It can be included in rules, macros, lists, and output strings. Here is an example of an alias.
|
||||
|
||||
```yaml
|
||||
apiVersion: auditing.kubesphere.io/v1alpha1
|
||||
kind: Rule
|
||||
metadata:
|
||||
name: alerting-rule
|
||||
labels:
|
||||
workspace: system-workspace
|
||||
type: alerting
|
||||
spec:
|
||||
rules:
|
||||
- name: namespace
|
||||
type: alias
|
||||
desc: the alias of the resource namespace
|
||||
alias: ObjectRef.Namespace
|
||||
```
|
||||
|
||||
## Output
|
||||
The `Output` string is used to format the alert message when an auditing log triggers an alert. The `Output` string can include lists and alias. Here is an example.
|
||||
|
||||
```yaml
|
||||
Output: ${user} ${verb} a HostNetwork Pod ${name} in ${namespace}.
|
||||
```
|
||||
{{< notice note >}}
|
||||
|
||||
The fields of `user`, `verb`, `namespace`, and `name` are all aliases.
|
||||
|
||||
{{</ notice >}}
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
title: "Event Query"
|
||||
keywords: 'KubeSphere, Kubernetes, Event, Query'
|
||||
description: 'How to perform event query in KubeSphere.'
|
||||
|
||||
linkTitle: "Event Query"
|
||||
weight: 4900
|
||||
---
|
||||
|
||||
## Objective
|
||||
|
||||
Kubernetes events provide insight into what is happening inside a cluster, based on which KubeSphere adds longer historical query and aggregation capabilities, and also supports event query for tenant isolation. This guide demonstrates how you will do multi-level, fine-grained event queries to track the state of your components.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- [KubeSphere Events](../../pluggable-components/events/) needs to be enabled.
|
||||
|
||||
## Hands-on Lab
|
||||
|
||||
1. The event query function is available for all users. Log in the console with any account, hover over the **Toolbox** in the lower right corner and select **Event Search**.
|
||||
|
||||
|
||||
|
||||
2. As shown in the pop-up window, you can see the number of events that the account has permission to view.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- KubeSphere supports event queries on each cluster separately if you have enabled the multi-cluster feature. You can switch the target cluster using the drop-down list next to the search bar.
|
||||
|
||||
- Supported fields in the search bar:
|
||||
- Workspace
|
||||
- Project
|
||||
- Resource Type
|
||||
- Resource Name
|
||||
- Reason
|
||||
- Message
|
||||
- Category
|
||||
- Time Range
|
||||
- You can customize the query time range by selecting **Time Range** in the search bar. KubeSphere stores events for last seven days by default.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
3. Here is an example to query events in the project `test` whose **Message** contains `container` within last 1 hour as shown in the following screenshot. It returns 84 rows of results with the corresponding time, project, and message all displayed.
|
||||
|
||||
|
||||
|
||||
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 >}}
|
||||
|
||||
The event query interface supports dynamic refreshing every 5s, 10s or 15s.
|
||||
|
||||
{{</ notice >}}
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: "History"
|
||||
keywords: 'KubeSphere, Kubernetes, history'
|
||||
description: 'Use browser history from toolbox'
|
||||
|
||||
linkTitle: "History"
|
||||
weight: 5520
|
||||
---
|
||||
|
||||
When you work in multiple workspaces or projects, your web browser will record the latest path you visited. You can check your history using F1, Win+K, or Command +K, which helps you quickly switch between the resources you access.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
title: "Log Query"
|
||||
keywords: 'KubeSphere, Kubernetes, log'
|
||||
description: 'Query Kubernetes logs from toolbox'
|
||||
|
||||
linkTitle: "Log Query"
|
||||
weight: 4190
|
||||
---
|
||||
|
||||
The logs of applications and systems can help you better understand what is happening inside your cluster and workloads. The logs are particularly useful for debugging problems and monitoring cluster activities. KubeSphere provides a powerful and easy-to-use logging system which offers users the capabilities of log collection, query and management from the perspective of tenants. The tenant-based logging system is much more useful than Kibana since different tenants can only view their own logs, leading to better security. Moreover, KubeSphere logging system filters out some redundant information so that tenants can only focus on logs that are useful to them.
|
||||
|
||||
## Objective
|
||||
|
||||
In this tutorial, you will learn how to use the log query function, including the interface, search parameters and detail pages.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You need to enable [KubeSphere Logging System](../../pluggable-components/logging/).
|
||||
|
||||
## Enter Log Query Interface
|
||||
|
||||
1. The log query function is available for all users. Log in the console with any account, hover over the **Toolbox** in the lower right corner and select **Log Search**.
|
||||
|
||||
|
||||
|
||||
2. As shown in the pop-up window, you can see a time histogram of log numbers, a cluster selection drop-down list and a log search bar.
|
||||
|
||||
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- KubeSphere supports log queries on each cluster separately if you have enabled the multi-cluster feature. You can switch the target cluster using the drop-down list next to the log search bar.
|
||||
- Supported fields in the log search bar:
|
||||
- Keyword
|
||||
- Project
|
||||
- Workload
|
||||
- Pod
|
||||
- Container
|
||||
- Time Range
|
||||
- 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`.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
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 >}}
|
||||
|
||||
- KubeSphere stores logs for last seven days by default.
|
||||
- Each cluster has its own log retention period which can be set separately. You can modify it in `ClusterConfiguration`. Refer to [KubeSphere Logging System](../../pluggable-components/logging/) for more details.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
## Use Search Parameters
|
||||
|
||||
1. You can provide as many fields as possible to narrow down your search results. Below is an example of a log query on the cluster `product` with the keyword `error` in the project `kubesphere-system` within `last 12 hours`.
|
||||
|
||||
|
||||
|
||||
2. It returns logs of 13 rows with the corresponding time, project, pod and container information all displayed.
|
||||
|
||||
3. Click any one of the results from the list. Drill into its detail page and inspect the log from this pod, including the complete context on the right. It is convenient for developers in terms of debugging and analyzing.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
The log query interface supports dynamic refreshing with 5s, 10s or 15s, and allows users to export logs to a local file for further analysis (in the top-right corner).
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
|
||||
|
||||
4. As you can see from the left panel, you can switch between pods and inspect its containers within the same project from the drop-down list. In this case, you can detect if any abnormal pods affect other pods.
|
||||
|
||||
|
||||
|
||||
## Drill into Detail Page
|
||||
|
||||
1. If the log looks abnormal, you can drill into the pod detail page or container detail page to further inspect container logs, resource monitoring graphs and events.
|
||||
|
||||
|
||||
|
||||
2. Inspect the container detail page as follows. At the same time, it allows you to open the terminal to debug the container directly.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
title: "Web Kubectl"
|
||||
keywords: 'KubeSphere, Kubernetes, kubectl, cli'
|
||||
description: 'Use kubectl from toolbox'
|
||||
|
||||
linkTitle: "Web Kubectl"
|
||||
weight: 5515
|
||||
---
|
||||
|
||||
The Kubernetes command-line tool, kubectl, allows you to run commands on Kubernetes clusters. You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs.
|
||||
|
||||
KubeSphere provides web kubectl on the console for user convenience. By default, in the current version, only the account granted the `platform-admin` role (such as the default account `admin`) has the permission to use web kubectl for cluster resource operation and management.
|
||||
|
||||
## Objective
|
||||
|
||||
In this tutorial, you will learn how to use web kubectl to operate on and manage cluster resources.
|
||||
|
||||
## Use Web Kubectl
|
||||
|
||||
1. Log in KubeSphere with an account granted the `platform-admin` role, hover over the **Toolbox** in the lower right corner and select **Kubectl**.
|
||||
|
||||
|
||||
|
||||
2. You can see the kubectl interface as shown in the pop-up window. If you have enabled the multi-cluster feature, you need to select the target cluster first from the drop-down list in the upper right corner. This drop-down list is not visible if the multi-cluster feature is not enabled.
|
||||
|
||||
|
||||
|
||||
3. Enter kubectl commands in the command-line tool to query and manage Kubernetes cluster resources. For example, execute the following command to query the status of all PVCs in the cluster.
|
||||
|
||||
```bash
|
||||
kubectl get pvc --all-namespaces
|
||||
```
|
||||
|
||||
|
||||
|
||||
4. Use the following syntax to run kubectl commands from your terminal window:
|
||||
|
||||
```bash
|
||||
kubectl [command] [TYPE] [NAME] [flags]
|
||||
```
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
- Where `command`, `TYPE`, `NAME`, and `flags` are:
|
||||
- `command`: Specifies the operation that you want to perform on one or more resources, such as `create`, `get`, `describe` and `delete`.
|
||||
- `TYPE`: Specifies the [resource type](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms.
|
||||
- `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, such as `kubectl get pods`.
|
||||
- `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.
|
||||
- If you need help, run `kubectl help` from the terminal window or refer to the [Kubernetes kubectl CLI documentation](https://kubernetes.io/docs/reference/kubectl/overview/).
|
||||
|
||||
{{</ notice >}}
|
||||
|
|
@ -5,7 +5,7 @@ layout: "single"
|
|||
|
||||
linkTitle: "Workspace Administration"
|
||||
|
||||
weight: 4200
|
||||
weight: 10000
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue