Skip to content

K
kubesphere

KubeSphere / kubesphere

通知 138
Star 32
Fork 5
K
kubesphere

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

提交 8c1f621d 编写于 作者: F FeynmanZhou
浏览文件
操作

refine readme, remove the out-of-date docs 

Signed-off-by: NFeynmanZhou <pengfeizhou@yunify.com>
上级 179fbdb6
隐藏空白更改
内联 并排
Showing with 39 addition and 1519 deletion
CONTRIBUTING.md
浏览文件 @ 8c1f621d
# Guide
This [document](docs/en/guides/README.md) walks you through how to get started contributing KubeSphere.
This [document](https://github.com/kubesphere/community) walks you through how to get started contributing KubeSphere.
README.md
浏览文件 @ 8c1f621d
......@@ -12,14 +12,10 @@
> English | [中文](README_zh.md)
[KubeSphere](https://kubesphere.io/) is a multi-tenant enterprise-grade container platform built on [Kubernetes](http://kubernetes.io), with full-stack automated IT operation and streamlined DevOps workflows. KubeSphere provides developer-friendly wizard web UI, helping enterprises to build out a more robust and feature-rich platform, which includes most common functionalities needed for enterprise Kubernetes strategy, such as the **Kubernetes resource management, DevOps (CI/CD), application lifecycle management, monitoring, logging, Service Mesh (Istio-based), multi-tenancy, alerting and notification, storage and networking, autoscaling, access control, GPU support, etc.**, as well as **multi-cluster management, Network Policy, registry management, more security enhancements** in upcoming releases. KubeSphere is a **distributed operating system with cloud native stack** with Kubernetes as its kernel, and will be very well architected for **plug-and-play integration for third-party applications to boost its ecosystem**.
[KubeSphere](https://kubesphere.io/) is a **distributed operating system providing cloud native stack** with [Kubernetes](https://kubernetes.io) as its kernel, and aims to be plug-and-play architecture for third-party applications seamless integration to boost its ecosystem. KubeSphere is also a multi-tenant enterprise-grade container platform with full-stack automated IT operation and streamlined DevOps workflows. It provides developer-friendly wizard web UI, helping enterprises to build out a more robust and feature-rich platform, which includes most common functionalities needed for enterprise Kubernetes strategy, see [Feature list](#features) for details.
KubeSphere provides a complete user experience around Kubernetes that incorporates a set of cloud native ecosystem tools, allowing developers and DevOps teams use their favorite tools in a unified console. KubeSphere delivers **consolidated views while integrating a wide breadth of ecosystem tools** around Kubernetes and offers consistent user experience to reduce complexity. Most importantly, these functionalities are loosely coupled with the platform since they are pluggable and optional at your will. Last but not least, it does not change Kubernetes itself anything. In another word, KubeSphere can be deployed on any existing version-compatible Kubernetes cluster.
![](docs/images/kubesphere-platform-overview.png)
> Note: The [Screenshots](docs/en/guides/screenshots.md) give a close insight into KubeSphere, see [What is KubeSphere](https://kubesphere.io/docs/v2.1/en/introduction/what-is-kubesphere) for details.
> Note: The [Screenshots](docs/en/guides/screenshots.md) give a close insight into KubeSphere, see [What is KubeSphere](https://kubesphere.io/docs/v2.1/en/introduction/what-is-kubesphere) for further information.
<table>
......@@ -28,16 +24,16 @@ KubeSphere provides a complete user experience around Kubernetes that incorporat
<td width="50%" align="center"><b>Project Resources</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112094014.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112094426.png"/></td>
<td><img src="docs/images/console.png"/></td>
<td><img src="docs/images/project.png"/></td>
</tr>
<tr>
<td width="50%" align="center"><b>CI/CD Pipeline</b></td>
<td width="50%" align="center"><b>Application Store</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925000712.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112095006.png"/></td>
<td><img src="docs/images/cicd.png"/></td>
<td><img src="docs/images/app-store.png"/></td>
</tr>
</table>
......@@ -45,6 +41,12 @@ KubeSphere provides a complete user experience around Kubernetes that incorporat
Using the account `demo1 / Demo123` to log in the [demo environment](https://demo.kubesphere.io/). Please note the account is granted viewer access. You can also have a quick view of [KubeSphere Demo Video](https://youtu.be/u5lQvhi_Xlc).
## Architecture
KubeSphere uses a loosely-coupled architecture that separates the [frontend](https://github.com/kubesphere/console) from the [backend](https://github.com/kubesphere/kubesphere), the back end can also be connected with external systems through the REST API, all components are designed as Docker containers. See [Architecture](https://kubesphere.io/docs/v2.1/en/introduction/architecture/) for details.
![](docs/images/architecture.png)
## Features
......@@ -67,10 +69,6 @@ Using the account `demo1 / Demo123` to log in the [demo environment](https://dem
----
## Architecture
KubeSphere uses a loosely-coupled architecture that separates the [frontend](https://github.com/kubesphere/console) from the [backend](https://github.com/kubesphere/kubesphere), the back end can also be connected with external systems through the REST API, all components are designed as Docker containers. See [Architecture](https://kubesphere.io/docs/v2.1/en/introduction/architecture/) for details.
## Latest Release
......@@ -78,7 +76,7 @@ KubeSphere 2.1.1 was released on **February 23th, 2020**. See the [Release Notes
## Installation
KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any Kubernetes distribution.
KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any version-compatible Kubernetes cluster.
### Deploy on Existing Kubernetes
......@@ -119,7 +117,9 @@ KubeSphere Installer can help you to install KubeSphere and Kubernetes on your l
- Hardware
- CPU：2 Core, Memory：4 G, Disk Space：100 G
##### All-in-One (QuickStart)
> Note: Please disable the firewall, or ensure your firewall meets the [port requirements](https://kubesphere.io/docs/installation/port-firewall/).
#### All-in-One (QuickStart)
```bash
curl -L https://kubesphere.io/download/stable/latest > installer.tar.gz \
......@@ -129,8 +129,6 @@ $ ./install.sh
Choose `"1) All-in-one"` to start the default minimal installation.
> Note: It's highly recommended to install [multi-node](https://kubesphere.io/docs/v2.1/en/installation/multi-node/) in production environment.
You can enable other components after installation, see [Pluggable Components Installation](https://kubesphere.io/docs/v2.1/en/installation/pluggable-components/).
......@@ -141,7 +139,7 @@ You can enable other components after installation, see [Pluggable Components In
## To start developing KubeSphere
The [development guide](CONTRIBUTING.md) hosts all information about building KubeSphere from source, git workflow, how to contribute code and how to test.
The [development guide](https://github.com/kubesphere/community/tree/master/developer-guide/development) hosts all information about building KubeSphere from source, git workflow, how to contribute code and how to test.
## RoadMap
......@@ -175,4 +173,4 @@ Please submit any KubeSphere bugs, issues, and feature requests to [KubeSphere G
## Contributing to the project
This [document](docs/en/guides/README.md) walks you through how to get started contributing KubeSphere.
This [document](https://github.com/kubesphere/community) walks you through how to get started contributing KubeSphere.
README_zh.md
浏览文件 @ 8c1f621d
......@@ -11,19 +11,11 @@
> [English](README.md) | 中文
[KubeSphere](https://kubesphere.io/) 是在 [Kubernetes](https://kubernetes.io) 之上构建的以**应用为中心的**多租户**容器平台**，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 提供了 **运维友好的向导式操作界面**，帮助企业快速构建一个强大和功能丰富的容器云平台，包括 **Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support** 等功能，未来还将提供 **多集群管理、Network Policy、镜像仓库管理** 等功能。KubeSphere 愿景是打造一个基于 Kubernetes 的云原生分布式操作系统，它的架构可以很方便地与云原生生态系统进行即插即用（plug-and-play）的集成。
[KubeSphere](https://kubesphere.com.cn) 是在 [Kubernetes](https://kubernetes.io) 之上构建的以**应用为中心的**多租户容器平台，提供全栈的 IT 自动化运维的能力，简化企业的 DevOps 工作流。KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台，包括 Kubernetes 资源管理、DevOps (CI/CD)、应用生命周期管理、微服务治理 (Service Mesh)、多租户管理、监控日志、告警通知、存储与网络管理、GPU support** 等功能，未来还将提供多集群管理、Network Policy、镜像仓库管理等功能。KubeSphere 愿景是打造一个基于 Kubernetes 的云原生分布式操作系统，它的架构可以很方便地与云原生生态系统进行即插即用（plug-and-play）的集成。
KubeSphere 作为一个**全栈的容器平台**，不仅支持**安装和纳管原生 Kubernetes**，还设计了一套完整的管理界面方便开发者与运维在一个**统一的平台**中安装与管理最常用的云原生工具，**从业务视角提供了一致的用户体验来降低复杂性**，并且所有功能组件都是可插拔的。
> 说明：KubeSphere 目前最新的版本为 2.1.1，所有版本 100% 开源，关于 KubeSphere 更详细的介绍与说明请参阅 [什么是 KubeSphere](https://kubesphere.com.cn/docs/zh-CN/introduction/intro/)。
![](docs/images/kubesphere-platform-overview.png)
KubeSphere 可以运行在任何私有或托管的 Kubernetes、私有云、公有云、VM 或物理环境之上。已大规模服务于社区用户，广泛地应用在以容器为中心的开发测试及生产环境，大量服务平稳地运行在 KubeSphere 之上。
> 说明：KubeSphere 目前最新的版本为 2.1.1，并且所有版本 100% 开源，关于 KubeSphere 更详细的介绍与说明请参阅 [什么是 KubeSphere](https://kubesphere.com.cn/docs/v2.1/zh-CN/introduction/intro/)。
点击 [KubeSphere 快览](docs/en/guides/screenshots.md) 快速查看 KubeSphere UI；
<table>
<tr>
......@@ -31,16 +23,16 @@ KubeSphere 可以运行在任何私有或托管的 Kubernetes、私有云、公
<td width="50%" align="center"><b>Project Resources</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112094014.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112094426.png"/></td>
<td><img src="docs/images/console.png"/></td>
<td><img src="docs/images/project.png"/></td>
</tr>
<tr>
<td width="50%" align="center"><b>CI/CD Pipeline</b></td>
<td width="50%" align="center"><b>Application Store</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925000712.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20191112095006.png"/></td>
<td><img src="docs/images/cicd.png"/></td>
<td><img src="docs/images/app-store.png"/></td>
</tr>
</table>
......@@ -48,6 +40,12 @@ KubeSphere 可以运行在任何私有或托管的 Kubernetes、私有云、公
使用体验账号 `demo1 / Demo123` 登录 [Demo 环境](https://demo.kubesphere.io/)，该账号仅授予了 viewer 权限，建议自行安装体验完整的管理功能。您还可以访问 Youtube 查看 [KubeSphere Demo 视频](https://youtu.be/u5lQvhi_Xlc)。
## 架构
KubeSphere 采用了前后端分离的架构设计，后端的各个功能组件可通过 REST API 对接外部系统，详见 [架构说明](https://kubesphere.com.cn/docs/zh-CN/introduction/architecture/)。本仓库仅包含后端代码，前端代码参考 [Console 项目](https://github.com/kubesphere/console)。
![](docs/images/architecture.png)
## 核心功能
|功能 |介绍 |
......@@ -65,18 +63,13 @@ KubeSphere 可以运行在任何私有或托管的 Kubernetes、私有云、公
| GPU support | 集群支持添加 GPU 与 vGPU，可运行 TensorFlow 等 ML 框架 |
> 以上功能说明详见 [产品功能](https://kubesphere.io/docs/v2.1/zh-CN/introduction/features/)。
> 以上功能说明详见 [产品功能](https://kubesphere.com.cn/docs/zh-CN/introduction/features/)。
----
## 架构
KubeSphere 采用了前后端分离的架构设计，后端的各个功能组件可通过 REST API 对接外部系统，详见 [架构说明](https://kubesphere.com.cn/docs/v2.1/zh-CN/introduction/architecture/)。本仓库仅包含后端代码，前端代码参考 [Console 项目](https://github.com/kubesphere/console)。
## 最新发布
KubeSphere 2.1.1 已于 2020 年 02 月 23 日 正式发布，点击 [Release Notes For 2.1.1](https://kubesphere.io/docs/v2.1/zh-CN/release/release-v211/) 查看 2.1.1 版本的更新详情。
KubeSphere 2.1.1 已于 2020 年 02 月 23 日 正式发布，点击 [Release Notes For 2.1.1](https://kubesphere.com.cn/docs/zh-CN/release/release-v211/) 查看 2.1.1 版本的更新详情。
## 快速安装
......@@ -101,14 +94,14 @@ curl -L https://kubesphere.io/download/stable/latest > installer.tar.gz \
./install.sh
```
直接选择 `"1) All-in-one"` 即可开始快速安装。默认仅开启最小安装，请参考 [开启可插拔功能功能组件](https://kubesphere.com.cn/docs/v2.1/zh-CN/installation/pluggable-components/) 按需开启其它功能组件。
直接选择 `"1) All-in-one"` 即可开始快速安装。默认仅开启最小安装，请参考 [开启可插拔功能功能组件](https://kubesphere.com.cn/docs/zh-CN/installation/pluggable-components/) 按需开启其它功能组件。
> 注意：All-in-One 仅适用于**测试环境**，**正式环境** 安装和使用请参考 [安装说明](https://kubesphere.com.cn/docs/v2.1/zh-CN/installation/intro/)。
> 注意：All-in-One 仅适用于**测试环境**，**正式环境** 安装和使用请参考 [安装说明](https://kubesphere.com.cn/docs/zh-CN/installation/intro/)。
### 部署在 Kubernetes
可参考 [前提条件](https://kubesphere.io/docs/v2.1/zh-CN/installation/prerequisites/) 验证是否满足以下条件：
可参考 [前提条件](https://kubesphere.com.cn/docs/zh-CN/installation/prerequisites/) 验证是否满足以下条件：
> - `Kubernetes` 版本： `1.15.x、1.16.x、1.17.x`；
> - `Helm`版本： `2.10.0 ≤ Helm Version ＜ 3.0.0`（不支持 helm 2.16.0 [#6894](https://github.com/helm/helm/issues/6894)），且已安装了 Tiller，参考 [如何安装与配置 Helm](https://devopscube.com/install-configure-helm-kubernetes/) （预计 3.0 支持 Helm v3）；
......@@ -142,7 +135,7 @@ kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l app=
## 开发 KubeSphere
[开发指南](CONTRIBUTING.md) 详细说明了如何从源码编译、KubeSphere 的 GitHub 工作流、如何贡献代码以及如何测试等。
[开发指南](https://github.com/kubesphere/community/tree/master/developer-guide/development) 详细说明了如何从源码编译、KubeSphere 的 GitHub 工作流、如何贡献代码以及如何测试等。
## 路线图
......@@ -169,15 +162,10 @@ KubeSphere 是 CNCF 基金会成员并且通过了 <a href="https://www.cncf.io/
## 技术社区
- [技术论坛](https://kubesphere.com.cn/forum/)
- [论坛](https://kubesphere.com.cn/forum/)
- [Slack Channel](https://join.slack.com/t/kubesphere/shared_invite/enQtNTE3MDIxNzUxNzQ0LTZkNTdkYWNiYTVkMTM5ZThhODY1MjAyZmVlYWEwZmQ3ODQ1NmM1MGVkNWEzZTRhNzk0MzM5MmY4NDc3ZWVhMjE)
- 微信群 (请备注 “公司 - 名字”）
<img width="150px" src="https://pek3b.qingstor.com/kubesphere-docs/png/20190902002055.png" />
## Bug 与建议反馈
KubeSphere 的日益完善与快速发展离不开社区用户的支持，KubeSphere 也一直在反哺社区，为开源用户提供更多的支持。若您安装使用时有任何建议问题、反馈或发现的 Bug，欢迎在 [GitHub Issue](https://github.com/kubesphere/kubesphere/issues) 提交 Issue。
欢迎在 [GitHub Issue](https://github.com/kubesphere/kubesphere/issues) 提交 Issue。
docs/cla.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere Contributor License Agreement
This KubeSphere Contributor License Agreement (CLA) applies to any contribution you make to any KubeSphere open source projects. If you are representing your employing organization to sign this agreement, please warrant that you have the authority to grant the agreement.
## Definitions
- "we", "our" and "us" means KubeSphere.
- "You" and "your" means you or the organization you are on behalf of.
- "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by you or the organization you represent to KubeSphere for inclusion in, or documentation of, any of the products owned or managed by KubeSphere.
## Grant of Copyright License
All rights of your Contribution submitted to KubeSphere in any manner are granted to KubeSphere and recipients of software distributed by KubeSphere. You waive any rights that my affect our ownership of the copyright and grant to us a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable, and sublicensable license to use, reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Contributions and any derivative works.
## Grant of Patent License
With respect to any patents you own or that you can license without payment to any third party, you grant to us and to any recipient of software distributed by us, a perpetual, worldwide, transferable, non-exclusive, no-charge, royalty-free, irrevocable patent license to make, have make, use, sell, offer to sell, import, and otherwise transfer the Contribution in whole or in part, alone or included in any product under any patent you own, or license from a third party, that is necessarily infringed by the Contribution or by combination of the Contribution with any Work.
## Your Representations and Warranties
You represent and warrant that:
- You represent that each of Your Contributions is Your original
creation that you can legally grant the rights set out in this agreement.
- the Contribution you submit and licenses you granted does not and will not, infringe the rights of any third party.
- you are not aware of any pending or threatened claims, suits, actions, or charges pertaining to the contributions. You also warrant to notify KubeSphere immediately if you become aware of any such actual or potential claims, suits, actions, allegations or charges.
docs/en/concepts-and-designs/README.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Concepts and Designs
Concepts and Designs help you to learn and understand the KubeSphere and the landscape.
## What is Kubesphere ?
- [Overview and Core concepts](overview.md). Provides a high-level description and introduction, including the problems the project solves.
- Project Goals. Provides the goals, which KubeSphere is trying to focus and provide features about them.
After you read the above documents, you should understand the KubeSphere basic goals. Now, you can choose which following parts you are interested, then dive in.
### KubeSphere Core
### KubeSphere Installer
### KubeSphere UI
TODO: UI opensource is on the way
### KubeSphere Application Management
TODO(@pengcong)
### KubeSphere Service Mesh
TODO(@zryfish)
## Porter
TODO(@magicsong)
### KubeSphere Networking
TODO
### KubeSphere DevOps
Read [DevOps Pipeline Overview](devops-pipeline-overview.md).
### KubeSphere S2I/B2I
Read [S2I/B2I Overview](s2i_b2i_overview.md)
### KubeSphere Monitoring
- [Overview](kubesphere-monitoring.md#Overview): Explains the architecture and key components behind the monitoring system.
- [Setup](kubesphere-monitoring.md#Setup): Introduces manifests related to Prometheus setup.
### KubeSphere Logging
- [Overview](kubesphere-logging.md#Overview): Explains the architecture and key components behind the logging system.
- [Log Collection and Forward](kubesphere-logging.md#Log-Collection-and-Forward): Introduces logging agent and the sidecar-based solution for collecting application logs on disk.
- [Log Store and Management](kubesphere-logging.md#Log-Store-and-Management): Introduces long-term log storage and management.
- [Log Search, Export and Visualization](kubesphere-logging.md#Log-Search,-Export-and-Visualization): Introduces log query and reporting.
### KubeSphere Altering
TODO
### KubeSphere Notification
TODO
docs/en/concepts-and-designs/devops-pipeline-overview.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere DevOps Pipeline Overview
KubeSphere DevOps Pipeline is aimed to meet the complex CI/CD requirements on Kubernetes.
With the KubeSphere DevOps Pipeline, you can quickly construct a complete CI/CD workflow and architecture by manipulating with the KubeSphere console.
## DevOps Pipeline Capabilities
* Build, Deploy, Launch services in Kubernetes
* Use Kubernetes dynamic agent to release the ability of Kubernetes to dynamically expand
* In SCM Pipeline and Out of SCM Pipeline
* Easy-to-use graphical pipeline editing panel
* Multi-tenant isolation
### DevOps Pipeline API
The KubeSphere DevOps Pipeline API will encapsulate the following APIs to provide a standardized REST API:
- Jenkins Core API
- Jenkins BlueOcean API
- Sonarqube API
- Other Plugins API
KubeSphere apiserver will provide multi-tenant API, pipeline API, credential API, code quality analysis API, etc.
![ks-devops-api](../../images/devops-api.png)
### Multi-tenant isolation
In the current version (v2.1.0), multi-tenancy in the DevOps part is done with the ability of the [role-strategy-plugin](https://github.com/jenkinsci/role-strategy-plugin) plugin. KubeSphere will automatically synchronize permission rules in this plugin.
In the future, KubeSphere DevOps will authentication based on [OPA](https://www.openpolicyagent.org/).
### Integration with Jenkins
KubeSphere integrates with standard Jenkins, customizing plugins and configurations.
#### Distribution of plugins
To meet the needs of users in private cloud environments, KubeSphere uses the built-in nginx as a jenkins update center. The jenkins update center is provided as a Docker image + [Helm Chart](https://github.com/kubesphere/ks-installer/tree/master/roles/ks-devops/jenkins-update-center).
#### Jenkins configuration
KubeSphere uses Docker Image, Jenkins update Center and Helm Chart to distribute Jenkins。
The list of plugins and configuration required by Jenkins will be provided by [Helm Chart](https://github.com/kubesphere/ks-installer/tree/master/roles/ks-devops/jenkins).
We use [Groovy Script](https://wiki.jenkins.io/display/JENKINS/Groovy+Hook+Script) and [JCasC](https://github.com/jenkinsci/configuration-as-code-plugin) to initialize Jenkins.
### Pipeline Builder Image And Jenkins PodTemplate
Jenkins does not include any agent configuration by default, KubeSphere provides some default agents (including docker image and podTemplate configuration).
The default agent image will be built based on the [builder base](https://github.com/kubesphere/builder-base), you can search the keyword of repository `builder xxx` in KubeSphere [github](https://github.com/kubesphere/).
### In SCM Pipeline and Out of SCM Pipeline
KubeSphere's pipeline syntax will be fully compatible with Jenkins' pipeline syntax. Jenkinsfile found in SCM will be supported with Jenkins plugin.
We will provide a plug-in SCM API, allowing users to graphically edit Jenkinsfile, Dockerfile and other configurations in SCM on KubeSphere.
### Sonarqube Integration
KubeSphere will retrieve Jenkins pipelines that have performed Sonarqube code analysis. And provide API to access analysis report.
### More
If you have more questions, you can create an issue on [github](https://github.com/kubesphere/kubesphere)
docs/en/concepts-and-designs/kubesphere-logging.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere Logging
## Overview
The KubeSphere logging system comprises many components that work together to achieve centralized log management. Once you enable the logging module during installation, a few components will be deployed or created within the namespace `kubesphere-logging-system`:
- Fluent Bit: log collector deployed on each node.
- Fluent-bit Operator: automates tasks for operating Fluent bit instances.
- Logsidecar Injector: injects sidecar into pods for streaming on-disk files to stdout.
- Elasticsearch Cluster: log storage backend.
- Curator: performs stale log cleanup.
The diagram below presents the overall logging architecture:
![](../../images/kubesphere-logging-overview.png)
The following sections will detail the design and functionality of each component.
## Log Collection and Forward
There are two types of logs produced by containers:
- stdout and stderr: written to `.log` files in the host's directory `/var/log/containers` by default.
- application logs: files on the pod's volume, file locations may vary.
Fluent Bit serves as the logging agent. It can access host's container log directory and streams log files to stdout. In KubeSphere, we forked and modified the origin Fluent Bit project fluent/fluent-bit. The difference between fluent/fluent-bit and [kubesphere/fluent-bit](https://github.com/kubesphere/fluent-bit) is that we add a reload interface to support dynamic configuration (see issue [#365](https://github.com/fluent/fluent-bit/issues/365)).
As shown in the diagram below, Fluent-bit controller implements the reload interface and is responsible for the life cycle of fluent-bit process.
![](../../images/kubesphere-logging-fluentbit.png)
The approach to collect container logs on a pod's volume is using a log forwarder sidecar. The sidecar container forwards on-disk application logs to its own stdout. In this way, KubeSphere manages log collection in a unified manner. Besides, [Logsidecar Injector](https://github.com/kubesphere/logsidecar-injector) comes to automate sidecar injection. It takes advantages of `MutatingAdmissionWebhook` to control log forwarder sidecar injection during pod creation.
Though Fluent Bit sends log to Elasticsearch by default in KubeSphere, you may change its output via editing the custom resource defined by the CustomResourceDefinition `fluentbits.logging.kubesphere.io`. The custom resource holds Fluent Bit input/filter/output configurations. Once changes detected, [Fluent-bit operator](https://github.com/kubesphere/fluentbit-operator) will trigger reloading and the new configuration will be used. The Operator pattern is the encouraged way to implement declarative configuration in Kubernetes.
## Log Store and Management
Fluent Bit supports a bunch of [output plugins](https://docs.fluentbit.io/manual/output) that you can choose from to configure how logs will be stored or forwarded. On KubeSphere console, you can easily setup [elasticsearch](https://docs.fluentbit.io/manual/output/elasticsearch), [kafka](https://docs.fluentbit.io/manual/output/kafka) and [fluentd](https://docs.fluentbit.io/manual/output/forward) as outputs.
Take Elasticsearch output for example. The default configuration writes that indices will be created daily with the prefix `ks-logstash-log`. It uses builtin Elasticsearch cluster whose address is `elasticsearch-logging-data.kubesphere-logging-system.svc`. For more details, please explore the custom resource `fluent-bit` (`kubectl get fluentbits.logging.kubesphere.io -n kubesphere-logging-system fluent-bit -oyaml`) .
To clean up stale logs, the Elasticsearch curator cronjob performs a daily check at the cluster level. See [Curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/current/index.html) for more information.
## Log Search, Export and Visualization
KubeSphere wraps Elasticsearch Search and Scroll APIs to support multi-tenancy. Users can use KubeSphere console to search and analyze logs as well as exporting logs to files.
docs/en/concepts-and-designs/kubesphere-monitoring.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere Monitoring
## Overview
The KubeSphere monitoring system comprises many components that work together to achieve overall monitoring functionality. KubeSphere defaults to installing the monitoring module. It will deploy or create a few components within the namespace `kubesphere-monitoring-system`:
- Prometheus Operator: automates tasks for operating Prometheus instances.
- Prometheus: scrapes metrics and provides monitoring service.
- Kube-state-metrics: exposes metrics for kubernetes objects like deployment, pod, namespace, etc.
- Node-exporter: exposes node metrics.
Besides, the monitoring stack includes CRD resources:
- ServiceMonitor: declaratively specifies how groups of services should be monitored.
- Prometheus: defines a desired Prometheus deployment.
- PrometheusRule: defines a desired Prometheus rule file.
In KubeSphere, Prometheus will monitor the following services by default:
- kube-state-metrics
- node-exporter
- kubelet
- s2i-operator
- etcd
- coredns
- kube-apiserver
- kube-scheduler
- kube-controller-manager
## Setup
The [contrib/kube-prometheus](https://github.com/kubesphere/prometheus-operator/tree/ks-v0.27.0/contrib/kube-prometheus) folder provides manifests for setting up the monitoring stack. The [kubernetes-mixin/rules](https://github.com/kubesphere/kubernetes-mixin/blob/ks-v0.27.0/rules/rules.libsonnet) project provides recording rule templates. KubeSphere monitoring backend serves as Prometheus client performing metrics query.
The diagram below presents the overall monitoring architecture:
![](../../images/kubesphere-monitoring-architecture.png)
docs/en/concepts-and-designs/overview.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Overview
KubeSphere is a multi-tenant cluster management platform which is based on Kubernetes. KubeSphere provides easy-to-use UI to reduce your learning cost for employing the container management platform and make it easier to develop, test and maintain your daily work. It's aimed to resolve the problems relating to Kubernetes’ storage, network, security and its usability.
In addition, the platform has integrated and optimized a range of functional modules which are suitable for containers. KubeSphere provides enterprises with a complete solution for development, automation operation and maintenance, microservice governance, multi-tanency management. Besides, our platform is also able to manage workload, container cluster, service and network, application orchestration as well as database mirroring and storage.
<table>
<tr>
<td width="50%" align="center"><b>KubeSphere Dashboard</b></td>
<td width="50%" align="center"><b>Project Resources</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925003707.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925003504.png"/></td>
</tr>
<tr>
<td width="50%" align="center"><b>CI/CD Pipeline</b></td>
<td width="50%" align="center"><b>Application Template</b></td>
</tr>
<tr>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925000712.png"/></td>
<td><img src="https://pek3b.qingstor.com/kubesphere-docs/png/20190925231623.png"/></td>
</tr>
</table>
## Architecture
KubeSphere adopts the separation of front and back ends, also realizes a cloud native design, the back ends' service components can communicate with external systems through the REST API, see [API documentation](https://kubesphere.io/docs/v2.0/api/kubesphere) for more details. All component are included in the architecture diagram below. KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any Kubernetes distribution.
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190810073322.png)
docs/en/concepts-and-designs/s2i_b2i_overview.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere S2I/B2I overview
## What is S2I/B2I
Kubesphere S2I(Source-to-Image) / B2I(Binary-to-Image) provides easy CI/CD functionalities, help developers to publish their service to Kubernetes without writing Dockefile.
## Workflow Example
![](https://pek3b.qingstor.com/kubesphere-docs/png/20191223103533.png)
## Principle
All resources of S2I/B2I will be installed in namespace `kubesphere-devops-system` by enable devops component.
In S2I, all resources and CI/CD steps are defined with [Custom Resource Defintion](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD). You can operate all s2i resources by call k8s api directly.
There are two mudules included in the S2I component:
1. S2I Operator: A Kubernetes CRD controller that provides easy Kubernetes-style resources for declaring CI/CD-style pipelines
2. S2IRun: It is the instance that executes the s2i build process in containers.
Besides, the S2I stack includes following CRD resources:
1. s2ibuildertemplates: defines information about S2I builder image.
2. s2ibuilders: all configuration information used in building are stored in this CRD.
3. s2iruns: defines an action about build
Here is a graph that describes the relationship about all CRD within S2I architecture:
​![](../../images/s2i_arch.png)
Also you can install S2I component in any kubernetes cluster without KubeSphere.
Want to see more about s2i, please jump to [S2I Operator](https://github.com/kubesphere/s2ioperator) and [S2IRun](https://github.com/kubesphere/s2irun)
docs/en/guides/Development-workflow.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Development Workflow
![ks-workflow](/docs/images/ks-workflow.png)
## 1 Fork in the cloud
1. Visit https://github.com/kubesphere/kubesphere
2. Click `Fork` button to establish a cloud-based fork.
## 2 Clone fork to local storage
Per Go's [workspace instructions](https://golang.org/doc/code.html#Workspaces), place KubeSphere' code on your `GOPATH` using the following cloning procedure.
1. Define a local working directory:
```bash
$ export working_dir=$GOPATH/src/kubesphere.io
$ export user={your github profile name}
```
2. Create your clone locally:
```bash
$ mkdir -p $working_dir
$ cd $working_dir
$ git clone https://github.com/$user/kubesphere.git
$ cd $working_dir/kubesphere
$ git remote add upstream https://github.com/kubesphere/kubesphere.git
# Never push to upstream master
$ git remote set-url --push upstream no_push
# Confirm that your remotes make sense:
$ git remote -v
```
## 3 Keep your branch in sync
```bash
git fetch upstream
git checkout master
git rebase upstream/master
```
## 4 Add new features or fix issues
Branch from it:
```bash
$ git checkout -b myfeature
```
Then edit code on the myfeature branch.
**Test and build**
Currently, make rules only contain simple checks such as vet, unit test, will add e2e tests soon.
**Using KubeBuilder**
- For Linux OS, you can download and execute this [KubeBuilder script](https://raw.githubusercontent.com/kubesphere/kubesphere/master/hack/install_kubebuilder.sh).
- For MacOS, you can install KubeBuilder by following this [guide](https://book.kubebuilder.io/quick-start.html).
**Run and test**
```bash
$ make all
# Run every unit test
$ make test
```
Run `make help` for additional information on these make targets.
### 5 Development in new branch
**Sync with upstream**
After the test is completed, suggest you to keep your local in sync with upstream which can avoid conflicts.
```
# Rebase your the master branch of your local repo.
$ git checkout master
$ git rebase upstream/master
# Then make your development branch in sync with master branch
git checkout new_feature
git rebase -i master
```
**Commit local changes**
```bash
$ git add <file>
$ git commit -s -m "add your description"
```
### 6 Push to your folk
When ready to review (or just to establish an offsite backup or your work), push your branch to your fork on github.com:
```
$ git push -f ${your_remote_name} myfeature
```
### 7 Create a PR
- Visit your fork at https://github.com/$user/kubesphere
- Click the` Compare & Pull Request` button next to your myfeature branch.
- Check out the [pull request process](pull-request.md) for more details and advice.
docs/en/guides/How-to-build.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# How to build KubeSphere?
This document walks you through how to get started with building KubeSphere in your local environment.
## Preparing the environment
### Go
KubeSphere development is based on [Kubernetes](https://github.com/kubernetes/kubernetes), both of them are written in [Go](http://golang.org/). If you don't have a Go development environment, please [set it up](http://golang.org/doc/code.html).
| Kubernetes | requires Go |
|----------------|-------------|
| 1.13+ | >= 1.12 |
> Tips:
> - Ensure your GOPATH and PATH have been configured in accordance with the Go
environment instructions.
> - It's recommended to install [macOS GNU tools](https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x) when using MacOS for development.
### Docker
KubeSphere components are often deployed as containers in Kubernetes. If you need to rebuild the KubeSphere components in the Kubernetes cluster, you'll need to [install Docker](https://docs.docker.com/install/) in advance.
### Dependency management
KubeSphere uses [Go Modules](https://github.com/golang/go/wiki/Modules) to manage dependencies in the `vendor/` tree.
> Note: KubeSphere uses `go module` to manage dependencies, but the development process still relies on `GOPATH`
> In the CRD development process, you need to use tools to automatically generate code. The tools used by KubeSphere still need to rely on `GOPATH`.
> For Chinese contributors who are going to pull the go module, we recommend you to use [goproxy.cn](https://goproxy.cn) as the proxy.
## Building KubeSphere Core on a local OS/shell environment
### For Quick Taste Binary
When you go get KubeSphere, you can choose the version you want to get: `go get kubesphere.io/kubesphere@version-you-want`
>For modules stored in source control repositories, the version suffix can
also be a commit hash, branch identifier, or other syntax known to the
source control system, as in 'go get golang.org/x/text@master'.
The version suffix @latest explicitly requests the default behavior
described above.
> Note: Before getting KubeSphere, you need to synchronize the contents of the `replace` section of the go.mod file of the KubeSphere you want to version.
```bash
mkdir ks-tmp
cd ks-tmp
echo 'module kubesphere' > go.mod
echo 'replace (
github.com/Sirupsen/logrus v1.4.1 => github.com/sirupsen/logrus v1.4.1
github.com/kiali/kiali => github.com/kubesphere/kiali v0.15.1-0.20190407071308-6b5b818211c3
github.com/kubernetes-sigs/application => github.com/kubesphere/application v0.0.0-20190518133311-b9d9eb0b5cf7
)' >> go.mod
GO111MODULE=on go get kubesphere.io/kubesphere@d649e3d0bbc64bfba18816c904819e4850d021e0
GO111MODULE=on go build -o ks-apiserver kubesphere.io/kubesphere/cmd/ks-apiserver # build ks-apiserver
GO111MODULE=on go build -o ks-apigateway kubesphere.io/kubesphere/cmd/ks-apigateway # build ks-apigateway
GO111MODULE=on go build -o ks-controller-manager kubesphere.io/kubesphere/cmd/controller-manager # build ks-controller-manager
GO111MODULE=on go build -o ks-iam kubesphere.io/kubesphere/cmd/ks-iam # build ks-iam
```
### For Building KubeSphere Core Images
KubeSphere components are often deployed as a container in a Kubernetes cluster, you may need to build a Docker image locally.
1. Clone repo to local.
```bash
git clone https://github.com/kubesphere/kubesphere.git
cd kubesphere
```
2. Run Docker command to build image.
```bash
# $REPO is the docker registry to push to
# $Tag is the tag name of the docker image
# The full go build process will be executed in the Dockerfile, so you may need to set GOPROXY in it.
docker build -f build/ks-apigateway/Dockerfile -t $REPO/ks-apigateway:$TAG .
docker build -f build/ks-apiserver/Dockerfile -t $REPO/ks-apiserver:$TAG .
docker build -f build/ks-iam/Dockerfile -t $REPO/ks-account:$TAG .
docker build -f build/ks-controller-manager/Dockerfile -t $REPO/ks-controller-manager:$TAG .
docker build -f ./pkg/db/Dockerfile -t $REPO/ks-devops:flyway-$TAG ./pkg/db/
```
### For KubeSphere Core local development building.
1. Create a `kubesphere` work directory under `GOPATH` and clone the source code.
```bash
mkdir -p $GOPATH/src/kubesphere.io/
cd $GOPATH/src/kubesphere.io/
git clone https://github.com/kubesphere/kubesphere
```
2. Use command `make` to build binary
```bash
make ks-apiserver # Build ks-apiserver binary
make ks-iam # Build ks-iam binary
make controller-manager # Build ks-controller-manager binary
make ks-apigateway # Build ks-apigateway binary
```
If you need to build a docker image, you can refer to the previous section.
### Test
It‘s recommended to use local Kubernetes clusters, such as [minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/), or to install an single-node [all-in-one](https://github.com/kubesphere/kubesphere#all-in-one) environment (Kubernetes-based) for quick testing.
> Tip: It also supports to use Docker for Desktop ships with Kubernetes as the test environment.
## Building Other Module of KubeSphere
Kubesphere has some pluggable modules such as ServiceMesh, DevOps, Logging, OpenPitrix ...
Some of these modules have their unique build methods, refer to the their documentation accordingly.
docs/en/guides/How-to-connect-remote-service.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Connect to remote service with telepresence
Telepresence is an open source tool that lets you run a single service locally, while connecting that service to a remote Kubernetes cluster.
We can use telepresence to help us running KubeSphere apiserver locally.
## 1. Install telepresence
You can read the [official installation documentation](https://www.telepresence.io/reference/install.html) to install telepresence.
## 2. Run telepresence
Open your command line and run the command `telepresence`, telepresence will help you to enter a bash connected to a remote Kubernetes cluster.
Test telepresence with KubeSphere apigateway:
```bash
@kubernetes-admin@cluster.local|bash-3.2$ curl http://ks-apigateway.kubesphere-system
401 Unauthorized
```
## 3. Run your module in bash
Now your module can easily connect to remote services.
```bash
go run cmd/ks-apiserver/apiserver.go
```
## 4. Further more
You can use telepresence to replace services in the cluster for debugging. For more information, please refer to the [official documentation](https://www.telepresence.io/discussion/overview).
docs/en/guides/How-to-run-KubeSphere-core.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# How to run KubeSphere core in local
This document will explain how to run KubeSphere apiserver locally.
> Modules similar to KubeSphere apiserver are KubeSphere controller-manageer, Kubesphere iam (also known as KubeSphere account), KubeSphere api-gateway.
> If you need to run these modules locally, you can refer to this document for configuration.
## Prepare: Build KubeSphere Core component
In the document [How-to-build](How-to-build.md) We learned how to build KubeSphere locally. Make sure you could build KubeSphere Core modules accordingly.
## 1. Set up a Kubernetes cluster with KubeSphere installed
KubeSphere relies on some external modules during development, and these modules are already included in the installed KubeSphere.
You can quickly install a KubeSphere cluster by referring to this [documentation] (https://kubesphere.io/en/install).
## 2. Use kubectl to access the development cluster locally
You can refer to this [document](https://kubernetes.io/docs/tasks/tools/install-kubectl/) to install and configure kubectl locally.
## 3. Understand KubeSphere Core's configuration
KubeSphere uses [viper](https://github.com/spf13/viper) to manage the configuration. KubeSphere supports setting up using command line arguments and configuration files.
> We recommend that you use a configuration file for configuration during local development.
KubeSphere apiserver needs to communicate with many modules. When you run Kubesphere, you can choose to configure the seperate modules only you care about.
During the development of KubeSphere apiserver, you must configure at least the relevant part of Kubernetes to ensure that KubeSphere apiserver can be started.
Below is a sample configuration of KubeSphere apiserver:
> Note: In the default configuration, we use Kubernetes service name to access the service.
> In a remote cluster, you may need to use external network exposure to connect to the cluster's internal services.
> Or you can refer to the [documentation](How-to-connect-remote-service.md) to use `telepresence` to connect to remote services
```yaml
kubernetes:
kubeconfig: "/Users/kubesphere/.kube/config"
master: https://192.168.0.8:6443
qps: 1e+06
burst: 1000000
ldap:
host: openldap.kubesphere-system.svc:389
managerDN: cn=admin,dc=kubesphere,dc=io
managerPassword: admin
userSearchBase: ou=Users,dc=kubesphere,dc=io
groupSearchBase: ou=Groups,dc=kubesphere,dc=io
redis:
host: redis.kubesphere-system.svc
port: 6379
password: ""
db: 0
s3:
endpoint: http://minio.kubesphere-system.svc:9000
region: us-east-1
disableSSL: true
forcePathStyle: true
accessKeyID: openpitrixminioaccesskey
secretAccessKey: openpitrixminiosecretkey
bucket: s2i-binaries
mysql:
host: mysql.kubesphere-system.svc:3306
username: root
password: password
maxIdleConnections: 100
maxOpenConnections: 100
maxConnectionLifeTime: 10s
devops:
host: http://ks-jenkins.kubesphere-devops-system.svc/
username: admin
password: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6ImFkbWluQGt1YmVzcGhlcmUuaW8iLCJleHAiOjE4MTYyMzkwMjIsInVzZXJuYW1lIjoiYWRtaW4ifQ.okmNepQvZkBRe1M8z2HAWRN0AVj9ooVu79IafHKCjZI
maxConnections: 100
sonarQube:
host: http://192.168.0.8:32297
token: 4e51de276f1fd0eb3a20b58e523d43ce76347302
openpitrix:
runtimeManagerEndpoint: "openpitrix-runtime-manager.openpitrix-system.svc:9103"
clusterManagerEndpoint: "openpitrix-cluster-manager.openpitrix-system.svc:9104"
repoManagerEndpoint: "openpitrix-repo-manager.openpitrix-system.svc:9101"
appManagerEndpoint: "openpitrix-app-manager.openpitrix-system.svc:9102"
categoryManagerEndpoint: "openpitrix-category-manager.openpitrix-system.svc:9113"
attachmentManagerEndpoint: "openpitrix-attachment-manager.openpitrix-system.svc:9122"
repoIndexerEndpoint: "openpitrix-repo-indexer.openpitrix-system.svc:9108"
monitoring:
endpoint: http://prometheus-k8s.kubesphere-monitoring-system.svc:9090
secondaryEndpoint: http://prometheus-k8s-system.kubesphere-monitoring-system.svc:9090
logging:
host: http://elasticsearch-logging-data.kubesphere-logging-system.svc.cluster.local:9200
indexPrefix: ks-logstash-log
alerting:
endpoint: http://alerting.kubesphere-alerting-system.svc
notification:
endpoint: http://notification.kubesphere-alerting-system.svc
```
## 4. Set Up KubeSphere Core's configuration
The KubeSphere Core module will read the `kubesphere.yaml` file in the current directory and the `kubesphere.yaml` file in the `/etc/kubesphere` directory, then load the configuration at startup.
You can choose a path to set your configuration locally.
## 5. Run KubeSphere apiserver
You can execute `go run cmd/ks-apiserver/apiserver.go` in the `$GOPATH/src/kubesphere.io/kubesphere` directory to start KubeSphere apiserver
> If you want to understand the specific meaning of each configuration, you can view it by `go run cmd/ks-apiserver/apiserver.go --help` or read the module's design and developer documentation.
docs/en/guides/Kubesphere-code-layout.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere File Tree
This document describes the directory structure of the KubeSphere repository.
```
├── api // Automatically generated API documentation
│   ├── api-rules
│   ├── ks-openapi-spec // REST API documentation provided by kubesphere apiserver
│   └── openapi-spec // REST API documentation provided by kubesphere apiserver
├── build // Dockerfile
│   ├── hypersphere
│   ├── ks-apigateway
│   ├── ks-apiserver
│   ├── ks-controller-manager
│   ├── ks-iam
│   └── ks-network
├── cmd // Main applications for KubeSphere.
│   ├── controller-manager // Kubesphere Controller Manger, used to reconcile KubeSphere CCRD
│   │   └── app
│   ├── hypersphere
│   ├── ks-apigateway // KubeSphere API gateway
│   │   └── app
│   ├── ks-apiserver // KubeSphere REST API server
│   │   └── app
│   ├── ks-iam // KubeSphere iam service
│   │   └── app
│   └── ks-network
├── config // CRD config files
│   ├── crds // CRD yaml files
│   ├── default // kustomization yaml files
│   ├── manager // controller manager yaml files
│   ├── rbac // rbac yaml files
│   ├── samples // CRD sample
│   └── webhook // webhppk yaml files
├── docs
│   ├── en
│   │   ├── concepts-and-designs
│   │   └── guides
│   └── images
├── hack // Script files to help people develop
│   └── lib
├── pkg // Library code.
│   ├── api // Structure definitions for REST APIs
│   │   ├── devops
│   │   ├── logging
│   │   └── monitoring
│   ├── apigateway
│   │   └── caddy-plugin
│   ├── apis // Structure definitions for CRDs
│   │   ├── devops
│   │   ├── network
│   │   ├── servicemesh
│   │   └── tenant
│   ├── apiserver // REST API parameter processing
│   │   ├── components
│   │   ├── devops
│   │   ├── git
│   │   ├── iam
│   │   ├── logging
│   │   ├── monitoring
│   │   ├── openpitrix
│   │   ├── operations
│   │   ├── quotas
│   │   ├── registries
│   │   ├── resources
│   │   ├── revisions
│   │   ├── routers
│   │   ├── runtime
│   │   ├── servicemesh
│   │   ├── tenant
│   │   ├── terminal
│   │   ├── workloadstatuses
│   │   └── workspaces
│   ├── client //Automatically generated CRD client
│   │   ├── clientset
│   │   ├── informers
│   │   └── listers
│   ├── constants // common constants
│   ├── controller // controller manger's reconciliation logic
│   │   ├── application
│   │   ├── clusterrolebinding
│   │   ├── destinationrule
│   │   ├── job
│   │   ├── namespace
│   │   ├── network
│   │   ├── s2ibinary
│   │   ├── s2irun
│   │   ├── storage
│   │   ├── virtualservice
│   │   └── workspace
│   ├── db // Database ORM Framework
│   │   ├── ddl
│   │   ├── schema
│   │   └── scripts
│   ├── gojenkins // Jenkins Go Client
│   │   ├── _tests
│   │   └── utils
│   ├── informers
│   ├── kapis // REST API registration
│   │   ├── devops
│   │   ├── iam
│   │   ├── logging
│   │   ├── monitoring
│   │   ├── openpitrix
│   │   ├── operations
│   │   ├── resources
│   │   ├── servicemesh
│   │   ├── tenant
│   │   └── terminal
│   ├── models // Data processing part of REST API
│   │   ├── components
│   │   ├── devops
│   │   ├── git
│   │   ├── iam
│   │   ├── kubeconfig
│   │   ├── kubectl
│   │   ├── log
│   │   ├── metrics
│   │   ├── nodes
│   │   ├── openpitrix
│   │   ├── quotas
│   │   ├── registries
│   │   ├── resources
│   │   ├── revisions
│   │   ├── routers
│   │   ├── servicemesh
│   │   ├── status
│   │   ├── storage
│   │   ├── tenant
│   │   ├── terminal
│   │   ├── workloads
│   │   └── workspaces
│   ├── server // Data processing part of REST API
│   │   ├── config
│   │   ├── errors
│   │   ├── filter
│   │   ├── options
│   │   └── params
│   ├── simple // common clients
│   │   └── client
│   ├── test
│   ├── utils // common utils
│   │   ├── hashutil
│   │   ├── idutils
│   │   ├── iputil
│   │   ├── jsonutil
│   │   ├── jwtutil
│   │   ├── k8sutil
│   │   ├── net
│   │   ├── readerutils
│   │   ├── reflectutils
│   │   ├── signals
│   │   ├── sliceutil
│   │   ├── stringutils
│   │   └── term
│   ├── version
│   └── webhook
├── test // e2e test code
│   ├── e2e
├── tools // tools to genereate API docs
│   ├── cmd
│   │   ├── crd-doc-gen // gen CRD API docs
│   │   └── doc-gen // gen REST API docs
│   └── lib
```
docs/en/guides/README.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Guides
There are many ways that you can help the KubeSphere community.
- Go through our documents, point out or fix unclear things. Translate the documents to other languages.
- Install our [releases](https://kubesphere.io/en/install), try to manage your `kubernetes` cluster with `kubesphere`, and feedback to us about
what you think.
- Read our source codes, Ask questions for details.
- Find kubesphere bugs, [submit issue](https://github.com/kubesphere/kubesphere/issues), and try to fix it.
- Find kubesphere installer bugs, [submit issue](https://github.com/kubesphere/ks-installer/issues), and try to fix it.
- Find [help wanted issues](https://github.com/kubesphere/kubesphere/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22),
which are good for you to start.
- Submit issue or start discussion through [GitHub issue](https://github.com/kubesphere/kubesphere/issues/new).
- See all forum discussion through [website](https://kubesphere.io/forum/).
## Contact Us
All the following channels are open to the community, you could choose the way you like.
* Submit an [issue](https://github.com/kubesphere/kubesphere/issues)
* See all forum discussion through [website](https://kubesphere.io/forum/).
* Join us at [Slack Channel](https://join.slack.com/t/kubesphere/shared_invite/enQtNTE3MDIxNzUxNzQ0LTZkNTdkYWNiYTVkMTM5ZThhODY1MjAyZmVlYWEwZmQ3ODQ1NmM1MGVkNWEzZTRhNzk0MzM5MmY4NDc3ZWVhMjE).
## For code developer
1. Learn about kubesphere's Concepts And Designs and how to build kubesphere locally
For developers, first step, read [Concepts And Designs](../concepts-and-designs/README.md) and [Compiling Guide](How-to-build.md).
Concepts And Designs describes the role of each component in kubesphere and the relationship between them.
Compiling Guide teaches developer how to build the project in local and set up the environment.
2. Understand the workflow of kubesphere development.
Read [Development Workflow](Development-workflow.md).
3. Learn KubeSphere code layout
Read [KubeSphere Code Layout](Kubesphere-code-layout.md).
4. Understand the best practices for submitting PR and our code of conduct
Read [best practices for submitting PR](pull-requests.md).
Read [code of conduct](code-of-conduct.md).
### KubeSphere Installer developer
### UI developer
TODO: UI opensource is on the way
### KubeSphere Application Management developer
TODO(@pengcong)
### KubeSphere Service Mesh developer
TODO(@zryfish)
### Porter developer
TODO(@magicsong)
### KubeSphere Networking developer
### KubeSphere DevOps developer
Users who are interested in DevOps Pipeline, you can read the documentation according to the [guidelines above](README.md#for-code-developer).
The function of KubeSphere DevOps is mainly provided by KubeSphere apiserver.
### KubeSphere S2I/B2I developer
1. If users who are interested in S2I/B2I, please read [S2I/B2I](https://github.com/kubesphere/s2ioperator#source-to-image-operator) to get start it.
2. For developers who want to contribute, see [Development Guide for S2I/B2I](https://github.com/kubesphere/s2ioperator/blob/master/docs/DEVELOPMENT.md)
### KubeSphere Monitoring developer
1. Read kubesphere's [Concepts And Designs for Monitoring](../concepts-and-designs/kubesphere-monitoring.md). Understand KubeSphere's monitoring stack.
2. For Prometheus and its wider eco-system setup, go to [kube-prometheus](https://github.com/kubesphere/prometheus-operator/tree/ks-v0.27.0/contrib/kube-prometheus).
3. For KubeSphere builtin metric rules, see [metrics_rules.go](https://github.com/kubesphere/kubesphere/blob/master/pkg/models/metrics/metrics_rules.go) and [kubernetes-mixin](https://github.com/kubesphere/kubernetes-mixin/blob/ks-v0.27.0/rules/rules.libsonnet).
4. For developers who are interested in KubeSphere monitoring backend, read [Development Guide for Monitoring](kubesphere-monitoring-development-guide.md) and [API doc](https://kubesphere.com.cn/docs/v2.1/api/kubesphere#tag/Cluster-Metrics).
### KubeSphere Logging developer
1. Read kubesphere's [Concepts And Designs for Logging](../concepts-and-designs/kubesphere-logging.md). Understand KubeSphere's logging stack.
2. Find the component you are interested in and start from its own repo: [Fluent Bit](https://github.com/kubesphere/fluent-bit), [Fluent-bit Operator](https://github.com/kubesphere/fluentbit-operator) and [Logsidecar Injector](https://github.com/kubesphere/logsidecar-injector).
3. For developers who are interested in KubeSphere logging backend, read [Development Guide for Logging](kubesphere-logging-devlopment-guide.md) and [API doc](https://kubesphere.com.cn/docs/v2.1/api/kubesphere#tag/Log-Query).
### KubeSphere Altering developer
TODO
### KubeSphere Notification developer
TODO
docs/en/guides/code-of-conduct.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere Code of Conduct
KubeSphere follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
# Best practices of committing code
Besides following above conduct from CNCF, we also hope every contributor in this project could help us to improve the quality of code, something you should know before checking in any new code:
- As gopher, make sure you already read [the conduct of Go language](https://golang.org/conduct) and [the instruction of writting Go](https://golang.org/doc/effective_go.html).
- Fork the project under your account and make the changes you want there.
- Execute 'go fmt' for every piece of new code.
- Every pulling request(PR) would be better constructed with only one commit, this could help code reviewer to go through your code efficiently, also helpful for every follower of this project to understand what happens in this PR. If you need to make any further code change to address the comments from reviewers, which means some new commits will be generated under this PR, you need to use 'git rebase' to combine those commits together.
- Every PR should only solve one problem or provide one feature, don't put several different fixes into one PR.
- At lease two code reviewers should involve into code reviewing process.
- Please introduce new third-party packages as little as possible to reduce the vendor dependency of this project. For example, don't import a full unit converting package but only use one function from it. For this case, you'd better write that function by yourself.
- more.
docs/en/guides/kubesphere-logging-devlopment-guide.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Logging
This documentation contains backend development guides for interaction with key components behind KubeSphere logging system. Logging backend provides the capabilities of:
- Log search
- Log export
- Log output configuration
- Multi-tenant isolation
## File Tree
The listing below covers all folders related to the logging backend.
```
/pkg
├─api
│ └─logging # declares structs for api responses
│ └─v1alpha2
├─apiserver # implements handler for http requests
│ ├─logging
│ └─tenant
├─kapis # registers APIs and routing
│ ├─logging
│ │ ├─install
│ │ └─v1alpha2
│ ├─tenant
│ │ ├─install
│ │ └─v1alpha2
├─models
│ ├─log # constants, utils and fluent-bit crd operation
│ │ ├─constants.go
│ │ ├─logcollector.go # some utils
│ │ ├─logcrd.go # interacts with fluent-bit crd
│ │ └─types.go
│ └─tenant
└─simple
├─factory.go # contains factory functions for es client options
└─client
├─elasticsearch # wraps es search apis
│ ├─esclient.go # constructs es search body
│ ├─interface.go # general interface methods for es clients
│ ├─options.go # es client options
│ └─versions # client code by es versions
│ ├─v5
│ ├─v6
│ └─v7
└─fluentbit # autogenerated client code for fluent-bit crd
```
## API Design
There are two types of APIs in logging. One for log query, and the other for interacting with the CustomResourceDefinition used by [Fluent-bit Operator](https://github.com/kubesphere/fluentbit-operator). For information about CRD and Fluent-bit Operator, please go to its own repo.
To support multi-tenant isolation, KubeSphere's logging query APIs have the format like below, though the underlying logic is using Elastic Search APIs:
```
GET /namespaces/{namespace}/pods/{pod}/containers/{container}
```
KubeSphere API gateway will decode the URL and conduct authorization. A person who doesn't belong to a namespace will be rejected to make a request.
docs/en/guides/kubesphere-monitoring-development-guide.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Monitoring
This documentation contains backend development guides for interaction with Prometheus. The monitoring backend provides the capabilities of:
- Metrics query
- Metrics sorting
- Multi-tenant isolation
## File Tree
The listing below covers all folders related to the monitoring backend.
```
/pkg
├─api
│ └─monitoring # declares structs for api responses
│ └─v1alpha2
├─apiserver # implements handler for http requests
│ └─monitoring
├─kapis # registers APIs and routing
│ └─monitoring
│ ├─install
│ └─v1alpha2
├─models
│ └─metrics
│ ├─constants.go
│ ├─metrics.go # proxies prometheus metrics query
│ ├─metrics_rules.go # promql expressions for builtin metrics
│ ├─namespaces.go # appends metric info to namespace resource request
│ ├─types.go
│ └─util.go # metrics sorting
└─simple
├─factory.go # factory functions for prometheus client options
└─client
└─prometheus
├─options.go # prometheus client options
└─prometheus.go # prometheus client code
```
## API Design
To support multi-tenant isolation, the monitoring backend proxies Prometheus query requests. KubeSphere's APIs have the format like below:
```
GET /namespaces/{namespace}/pods
GET /namespaces/{namespace}/pods/{pod}
```
KubeSphere API gateway will decode the URL and conduct authorization. A person who doesn't belong to a namespace will be rejected to make a request. Besides, note that the two examples above have slightly different meanings. The first is to retrieve all pod-level metrics in the namespace, while the latter is for a specific pod.
docs/en/guides/pull-requests.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# Pull Request Process
This doc explains the process and best practices for submitting a PR to the [KubeSphere project](https://github.com/kubeSphere/kubeSphere). It should serve as a reference for all contributors, and be useful especially to new and infrequent submitters.
- [Before You Submit a PR](#before-you-submit-a-pr)
* [Run Local Verifications](#run-local-verifications)
- [The PR Submit Process](#the-pr-submit-process)
* [Write Release Notes if Needed](#write-release-notes-if-needed)
* [The Testing and Merge Workflow](#the-testing-and-merge-workflow)
* [Marking Unfinished Pull Requests](#marking-unfinished-pull-requests)
* [Comment Commands Reference](#comment-commands-reference)
* [Automation](#automation)
* [How the e2e Tests Work](#how-the-e2e-tests-work)
- [Why was my PR closed?](#why-was-my-pr-closed)
- [Why is my PR not getting reviewed?](#why-is-my-pr-not-getting-reviewed)
- [Best Practices for Faster Reviews](#best-practices-for-faster-reviews)
* [0. Familiarize yourself with project conventions](#0-familiarize-yourself-with-project-conventions)
* [1. Is the feature wanted? Make a Design Doc or Sketch PR](#1-is-the-feature-wanted-make-a-design-doc-or-sketch-pr)
* [2. Smaller Is Better: Small Commits, Small PRs](#2-smaller-is-better-small-commits-small-prs)
* [3. Open a Different PR for Fixes and Generic Features](#3-open-a-different-pr-for-fixes-and-generic-features)
* [4. Comments Matter](#4-comments-matter)
* [5. Test](#5-test)
* [6. Squashing and Commit Titles](#6-squashing-and-commit-titles)
* [7. KISS, YAGNI, MVP, etc.](#7-kiss-yagni-mvp-etc)
* [8. It's OK to Push Back](#8-its-ok-to-push-back)
* [9. Common Sense and Courtesy](#9-common-sense-and-courtesy)
# Before You Submit a PR
This guide is for contributors who already have a PR to submit. If you're looking for information on setting up your developer environment and creating code to contribute to KubeSphere, see the [development guide](development.md).
**Make sure your PR adheres to our best practices. These include following project conventions, making small PRs, and commenting thoroughly. Please read the more detailed section on [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) at the end of this doc.**
## Run Local Verifications
You can run these local verifications before you submit your PR to predict the
pass or fail of continuous integration.
# The PR Submit Process
Merging a PR requires the following steps to be completed before the PR will be merged automatically. For details about each step, see the [The Testing and Merge Workflow](#the-testing-and-merge-workflow) section below.
- Make the PR
- Release notes - do one of the following:
- Add notes in the release notes block, or
- Update the release note label
- Pass all tests
- Get a `/lgtm` from a reviewer
- Get approval from an owner
If your PR meets all of the steps above, it will enter the submit queue to be merged. When it is next in line to be merged, the tests will run a second time. If all tests pass, the PR will be merged automatically.
## Write Release Notes if Needed
Release notes are required for any PR with user-visible changes, such as bug-fixes, feature additions, and output format changes.
If you don't add release notes in the PR template, the `do-not-merge/release-note-label-needed` label is added to your PR automatically after you create it. There are a few ways to update it.
To add a release-note section to the PR description:
For PRs with a release note:
```release-note
Your release note here
```
For PRs that require additional action from users switching to the new release, include the string "action required" (case insensitive) in the release note:
```release-note
action required: your release note here
```
For PRs that don't need to be mentioned at release time, just write "NONE" (case insensitive):
```release-note
NONE
```
The `/release-note-none` comment command can still be used as an alternative to writing "NONE" in the release-note block if it is left empty.
To see how to format your release notes, view the [PR template](https://github.com/) for a brief example. PR titles and body comments can be modified at any time prior to the release to make them friendly for release notes.
// PR template TODO
Release notes apply to PRs on the master branch. For cherry-pick PRs, see the [cherry-pick instructions](cherry-picks.md). The only exception to these rules is when a PR is not a cherry-pick and is targeted directly to the non-master branch. In this case, a `release-note-*` label is required for that non-master PR.
// cherry-pick TODO
Now that your release notes are in shape, let's look at how the PR gets tested and merged.
## The Testing and Merge Workflow
The KubeSphere merge workflow uses comments to run tests and labels for merging PRs.
NOTE: For pull requests that are in progress but not ready for review,
prefix the PR title with `WIP` or `[WIP]` and track any remaining TODOs
in a checklist in the pull request description.
Here's the process the PR goes through on its way from submission to merging:
1. Make the pull request
1. `@o8x-merge-robot` assigns reviewers //TODO
If you're **not** a member of the KubeSphere organization:
1. Reviewer/KubeSphere Member checks that the PR is safe to test. If so, they comment `/ok-to-test`
1. Reviewer suggests edits
1. Push edits to your PR branch
1. Repeat the prior two steps as needed
1. (Optional) Some reviewers prefer that you squash commits at this step
1. Owner is assigned and will add the `/approve` label to the PR
If you are a member, or a member comments `/ok-to-test`, the PR will be considered to be trusted. Then the pre-submit tests will run:
1. Automatic tests run. See the current list of tests on the
1. If tests fail, resolve issues by pushing edits to your PR branch
1. If the failure is a flake, anyone on trusted PRs can comment `/retest` to rerun failed tests
Once the tests pass, all failures are commented as flakes, or the reviewer adds the labels `lgtm` and `approved`, the PR enters the final merge queue. The merge queue is needed to make sure no incompatible changes have been introduced by other PRs since the tests were last run on your PR.
Either the [on call contributor](on-call-rotations.md) will manage the merge queue manually. //TODO
1. The PR enters the merge queue ([http://submit-queue.KubeSphere.io]())
1. The merge queue triggers a test re-run with the comment `/test all [submit-queue is verifying that this PR is safe to merge]`
1. Author has signed the CLA (`cncf-cla: yes` label added to PR)
1. No changes made since last `lgtm` label applied
1. If tests fail, resolve issues by pushing edits to your PR branch
1. If the failure is a flake, anyone can comment `/retest` if the PR is trusted
1. If tests pass, the merge queue automatically merges the PR
That's the last step. Your PR is now merged.
## Marking Unfinished Pull Requests
If you want to solicit reviews before the implementation of your pull request is complete, you should hold your pull request to ensure that the merge queue does not pick it up and attempt to merge it. There are two methods to achieve this:
1. You may add the `/hold` or `/hold cancel` comment commands
2. You may add or remove a `WIP` or `[WIP]` prefix to your pull request title
The GitHub robots will add and remove the `do-not-merge/hold` label as you use the comment commands and the `do-not-merge/work-in-progress` label as you edit your title. While either label is present, your pull request will not be considered for merging.
## Comment Commands Reference//TODO
[The commands doc]() contains a reference for all comment commands. //TODO
## Automation//TODO
The KubeSphere developer community uses a variety of automation to manage pull requests. This automation is described in detail [in the automation doc](automation.md). //TODO
## How the Tests Work//TODO
The tests will post the status results to the PR. If an e2e test fails,
`@o8x-ci-robot` will comment on the PR with the test history and the
comment-command to re-run that test. e.g.
> The following tests failed, say /retest to rerun them all.
# Why was my PR closed?
Pull requests older than 90 days will be closed. Exceptions can be made for PRs that have active review comments, or that are awaiting other dependent PRs. Closed pull requests are easy to recreate, and little work is lost by closing a pull request that subsequently needs to be reopened. We want to limit the total number of PRs in flight to:
* Maintain a clean project
* Remove old PRs that would be difficult to rebase as the underlying code has changed over time
* Encourage code velocity
# Why is my PR not getting reviewed?
A few factors affect how long your PR might wait for review.
If it's the last few weeks of a milestone, we need to reduce churn and stabilize.
Or, it could be related to best practices. One common issue is that the PR is too big to review. Let's say you've touched 39 files and have 8657 insertions. When your would-be reviewers pull up the diffs, they run away - this PR is going to take 4 hours to review and they don't have 4 hours right now. They'll get to it later, just as soon as they have more free time (ha!).
There is a detailed rundown of best practices, including how to avoid too-lengthy PRs, in the next section.
But, if you've already followed the best practices and you still aren't getting any PR love, here are some
things you can do to move the process along:
* Make sure that your PR has an assigned reviewer (assignee in GitHub). If not, reply to the PR comment stream asking for a reviewer to be assigned.
* Ping the assignee (@username) on the PR comment stream, and ask for an estimate of when they can get to the review.
* Ping the assignee on [Slack](http://KubeSphere.slack.com). Remember that a person's GitHub username might not be the same as their Slack username.
* Ping the assignee by email (many of us have publicly available email addresses).
* If you're a member of the organization ping the [team](https://github.com/orgs/KubeSphere/teams) (via @team-name) that works in the area you're submitting code.
* If you have fixed all the issues from a review, and you haven't heard back, you should ping the assignee on the comment stream with a "please take another look" (`PTAL`) or similar comment indicating that you are ready for another review.
Read on to learn more about how to get faster reviews by following best practices.
# Best Practices for Faster Reviews
Most of this section is not specific to KubeSphere, but it's good to keep these best practices in mind when you're making a PR.
You've just had a brilliant idea on how to make KubeSphere better. Let's call that idea Feature-X. Feature-X is not even that complicated. You have a pretty good idea of how to implement it. You jump in and implement it, fixing a bunch of stuff along the way. You send your PR - this is awesome! And it sits. And sits. A week goes by and nobody reviews it. Finally, someone offers a few comments, which you fix up and wait for more review. And you wait. Another week or two go by. This is horrible.
Let's talk about best practices so your PR gets reviewed quickly.
## 0. Familiarize yourself with project conventions
* [Development guide](code-of-conduct.md)
## 1. Is the feature wanted? Make a Design Doc or Sketch PR
Are you sure Feature-X is something the KubeSphere team wants or will accept? Is it implemented to fit with other changes in flight? Are you willing to bet a few days or weeks of work on it?
It's better to get confirmation beforehand. There are two ways to do this:
- Make a proposal doc (in docs/proposals; for example [the QoS proposal]()
- Coordinate your effort with [SIG Docs]() ahead of time. //TODO
- Make a sketch PR (e.g., just the API or Go interface). Write or code up just enough to express the idea and the design and why you made those choices
Or, do all of the above.
Be clear about what type of feedback you are asking for when you submit a proposal doc or sketch PR.
Now, if we ask you to change the design, you won't have to re-write it all.
## 2. Smaller Is Better: Small Commits, Small PRs
Small commits and small PRs get reviewed faster and are more likely to be correct than big ones.
Attention is a scarce resource. If your PR takes 60 minutes to review, the reviewer's eye for detail is not as keen in the last 30 minutes as it was in the first. It might not get reviewed at all if it requires a large continuous block of time from the reviewer.
**Breaking up commits**
Break up your PR into multiple commits, at logical break points.
Making a series of discrete commits is a powerful way to express the evolution of an idea or the
different ideas that make up a single feature. Strive to group logically distinct ideas into separate commits.
For example, if you found that Feature-X needed some prefactoring to fit in, make a commit that JUST does that prefactoring. Then make a new commit for Feature-X.
Strike a balance with the number of commits. A PR with 25 commits is still very cumbersome to review, so use
judgment.
**Breaking up PRs**
Or, going back to our prefactoring example, you could also fork a new branch, do the prefactoring there and send a PR for that. If you can extract whole ideas from your PR and send those as PRs of their own, you can avoid the painful problem of continually rebasing.
KubeSphere is a fast-moving codebase - lock in your changes ASAP with your small PR, and make merges be someone else's problem.
Multiple small PRs are often better than multiple commits. Don't worry about flooding us with PRs. We'd rather have 100 small, obvious PRs than 10 unreviewable monoliths.
We want every PR to be useful on its own, so use your best judgment on what should be a PR vs. a commit.
As a rule of thumb, if your PR is directly related to Feature-X and nothing else, it should probably be part of the Feature-X PR. If you can explain why you are doing seemingly no-op work ("it makes the Feature-X change easier, I promise") we'll probably be OK with it. If you can imagine someone finding value independently of Feature-X, try it as a PR. (Do not link pull requests by `#` in a commit description, because GitHub creates lots of spam. Instead, reference other PRs via the PR your commit is in.)
## 3. Open a Different PR for Fixes and Generic Features
**Put changes that are unrelated to your feature into a different PR.**
Often, as you are implementing Feature-X, you will find bad comments, poorly named functions, bad structure, weak type-safety, etc.
You absolutely should fix those things (or at least file issues, please) - but not in the same PR as your feature. Otherwise, your diff will have way too many changes, and your reviewer won't see the forest for the trees.
**Look for opportunities to pull out generic features.**
For example, if you find yourself touching a lot of modules, think about the dependencies you are introducing between packages. Can some of what you're doing be made more generic and moved up and out of the Feature-X package? Do you need to use a function or type from an otherwise unrelated package? If so, promote! We have places for hosting more generic code.
Likewise, if Feature-X is similar in form to Feature-W which was checked in last month, and you're duplicating some tricky stuff from Feature-W, consider prefactoring the core logic out and using it in both Feature-W and
Feature-X. (Do that in its own commit or PR, please.)
## 4. Comments Matter
In your code, if someone might not understand why you did something (or you won't remember why later), comment it. Many code-review comments are about this exact issue.
If you think there's something pretty obvious that we could follow up on, add a TODO.
Read up on [GoDoc](https://blog.golang.org/godoc-documenting-go-code) - follow those general rules for comments.
## 5. Test
Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few PRs can touch code and NOT touch tests.
If you don't know how to test Feature-X, please ask! We'll be happy to help you design things for easy testing or to suggest appropriate test cases.
## 6. Squashing and Commit Titles
Your reviewer has finally sent you feedback on Feature-X.
Make the fixups, and don't squash yet. Put them in a new commit, and re-push. That way your reviewer can look at the new commit on its own, which is much faster than starting over.
We might still ask you to clean up your commits at the very end for the sake of a more readable history, but don't do this until asked: typically at the point where the PR would otherwise be tagged `LGTM`.
Each commit should have a good title line (<70 characters) and include an additional description paragraph describing in more detail the change intended.
**General squashing guidelines:**
* Sausage => squash
Do squash when there are several commits to fix bugs in the original commit(s), address reviewer feedback, etc. Really we only want to see the end state and commit message for the whole PR.
* Layers => don't squash
Don't squash when there are independent changes layered to achieve a single goal. For instance, writing a code munger could be one commit, applying it could be another, and adding a precommit check could be a third. One could argue they should be separate PRs, but there's really no way to test/review the munger without seeing it applied, and there needs to be a precommit check to ensure the munged output doesn't immediately get out of date.
A commit, as much as possible, should be a single logical change.
## 7. KISS, YAGNI, MVP, etc.
Sometimes we need to remind each other of core tenets of software design - Keep It Simple, You Aren't Gonna Need It, Minimum Viable Product, and so on. Adding a feature "because we might need it later" is antithetical to software that ships. Add the things you need NOW and (ideally) leave room for things you might need later - but don't implement them now.
## 8. It's OK to Push Back
Sometimes reviewers make mistakes. It's OK to push back on changes your reviewer requested. If you have a good reason for doing something a certain way, you are absolutely allowed to debate the merits of a requested change. Both the reviewer and reviewee should strive to discuss these issues in a polite and respectful manner.
You might be overruled, but you might also prevail. We're pretty reasonable people. Mostly.
Another phenomenon of open-source projects (where anyone can comment on any issue) is the dog-pile - your PR gets so many comments from so many people it becomes hard to follow. In this situation, you can ask the primary reviewer (assignee) whether they want you to fork a new PR to clear out all the comments. You don't HAVE to fix every issue raised by every person who feels like commenting, but you should answer reasonable comments with an explanation.
## 9. Common Sense and Courtesy
No document can take the place of common sense and good taste. Use your best judgment, while you put
a bit of thought into how your work can be made easier to review. If you do these things your PRs will get merged with less friction.
docs/en/guides/screenshots.md 已删除 100644 → 0
浏览文件 @ 179fbdb6
# KubeSphere Screenshots
Screenshots of various KubeSphere dashboard views:
## Workbench Overview
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111625.png)
## Application Template
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111410.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111441.png)
## Project Resources Management
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710112617.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710112653.png)
## DevOps Project
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113123.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113153.png)
## Service Mesh
### Traffic Management
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002111.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002849.png)
### Tracing
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002331.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002424.png)
## Grayscale Release
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002554.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190713002641.png)
## Node Management
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111701.png)
## Service Components
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111734.png)
## Workspace Management
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710111851.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710112018.png)
## Monitoring Center
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113420.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113444.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113543.png)
## Log and Alert
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113300.png)
![](https://pek3b.qingstor.com/kubesphere-docs/png/20190710113650.png)
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或