mirror of
https://github.com/kubesphere/website.git
synced 2025-12-29 15:42:49 +00:00
KubeSphere CI Bot
GitHub
commit
df77713423
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
title: "API Glossary"
|
||||
keywords: 'kubernetes, docker, helm, jenkins, istio, prometheus'
|
||||
description: 'KubeSphere AOI Glossary documentation'
|
||||
|
||||
|
||||
weight: 240
|
||||
---
|
||||
|
||||
## DevOps
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|DevOps|DevOps 工程|
|
||||
|Workspace| 企业空间|
|
||||
|Pipeline|流水线|
|
||||
|Credential|凭证|
|
||||
|Artifact |制品|
|
||||
|Stage|流水线执行过程中的阶段|
|
||||
|Step|阶段中的步骤|
|
||||
|Branch|分支|
|
||||
|SCM|源代码管理工具，例如github、gitlab等|
|
||||
|sonar|代码质量分析工具 sonarqube|
|
||||
|
||||
## Monitoring
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|Metric|指标|
|
||||
|Usage|用量|
|
||||
|Utilisation|利用率|
|
||||
|Throughput|吞吐量|
|
||||
|Capacity|容量|
|
||||
|Proposal|Etcd 提案|
|
||||
|
||||
## Logging
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|Fuzzy Matching |模糊匹配|
|
||||
|
||||
|
||||
## Router
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|Gateway|网关|
|
||||
|Route|应用路由|
|
||||
|
||||
## Service Mesh
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|ServiceMesh|服务网格|
|
||||
|Tracing|追踪(分布式追踪)|
|
||||
|Canary Release| 金丝雀发布|
|
||||
|Traffic mirroring|流量镜像|
|
||||
|BlueGreen Release|蓝绿发布|
|
||||
|
||||
## Notification
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|addresslist|通知地址列表|
|
||||
|
||||
## Multi Cluster
|
||||
|
||||
|English/英文| Chinese/中文|
|
||||
|---|---|
|
||||
|Host Cluster|主集群/管理集群|
|
||||
|Member Cluster|成员集群|
|
||||
|Direct Connection|直接连接|
|
||||
|Agent Connection|代理连接|
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
---
|
||||
title: "Glossary"
|
||||
keywords: 'kubernetes, kubesphere, devops, docker, helm, jenkins, istio, prometheus'
|
||||
description: 'KubeSphere Glossary documentation'
|
||||
|
||||
|
||||
weight: 240
|
||||
---
|
||||
|
||||
This glossary includes technical terms that are specific to KubeSphere, as well as more general terms that provide useful context.
|
||||
|
||||
## General
|
||||
|
||||
- **Workspace** <br>
|
||||
A logical unit to organize a tenant's workload projects / Kubernetes namespaces, DevOps projects, manage resource access and share information within the team.
|
||||
|
||||
- **System Workspace** <br>
|
||||
The special place to organize system projects from KubeSphere, Kubernetes and optional components such as OpenPitrix, Istio, monitorng etc.
|
||||
|
||||
- **Workspace member** <br>
|
||||
The users that are invited into the workspace who have certain priviledge to work in the workspace.
|
||||
|
||||
- **Project** <br>
|
||||
A project in KubeSphere is a Kubernetes namespace
|
||||
|
||||
- **Multi-cluster Project** <br>
|
||||
A project whose workload is deployed into multiple clusters.
|
||||
|
||||
- **Project memeber** <br>
|
||||
The users that are invited into the project who have certain priviledge to access the project.
|
||||
|
||||
- **Workbench** <br>
|
||||
The landing page for a tenant where contains authorized resources to access including workspaces, App Store, etc.
|
||||
|
||||
- **Volume** <br>
|
||||
A KubeSphere Volume is a Kubernetes Persistent Volume Claim (PVC)
|
||||
|
||||
- **Public Cluster** <br>
|
||||
Platform admin can set the cluster visibility, meaning who can access the cluster. A public cluster means all platform users can access the cluster, in which they are able to create and schedule resources.
|
||||
|
||||
- **KubeKey** <br>
|
||||
A brand-new installation tool developed in Go. It can install KubeSphere and Kubernetes separately or install them at one time.
|
||||
|
||||
- **ks-installer** <br>
|
||||
The package to deploy KubeSphere on existing Kubernetes clusters.
|
||||
|
||||
## Application
|
||||
|
||||
- **OpenPitirx** <br>
|
||||
An open-source system to package, deploy and manage different types of apps.
|
||||
|
||||
- **App Template** <br>
|
||||
A template for a specific application that other users can deploy new application instances based on the template.
|
||||
|
||||
- **App Repo** <br>
|
||||
A web accessible repo that hosts a bunch of application templates.
|
||||
|
||||
- **App Store** <br>
|
||||
A public place for different users to share various applications.
|
||||
|
||||
## DevOps
|
||||
|
||||
- **DevOps Project** <br>
|
||||
A project specific for DevOps where you can manage your pipelines and related information.
|
||||
|
||||
- **SCM** <br>
|
||||
Source Control Management, such as GitHub, Gitlab, etc.
|
||||
|
||||
- **In-SCM** <br>
|
||||
The pipeline based on a Jenkinsfile that is hosted in SCM.
|
||||
|
||||
- **Out-of-SCM** <br>
|
||||
The pipeline created by using graphical editing panel, which means no Jenkinsfile needed.
|
||||
|
||||
- **CI Node** <br>
|
||||
The specific node for pipeline or S2I, B2I. Generally, applications often need to pull a lot of dependencies during the build process. It might cause some issues like long pulling time, or unstable network causing failure. In order to make build robust, and to speed up the build by using cache, we recommend you configure one or a set of CI nodes which the system schedules the task of CI/CD pipelines or S2I/B2I builds running on.
|
||||
|
||||
- **B2I** <br>
|
||||
Binary to Image. As similar as S2I, B2I is a toolkit and automated workflow for building reproducible container images from binary (e.g. Jar, War, Binary package).
|
||||
|
||||
## Logging, Events and Auditing
|
||||
|
||||
- **Exact Query** <br>
|
||||
The query method that exactly matches the keywords you type to search
|
||||
|
||||
- **Fuzzy Query** <br>
|
||||
The query method that partially matches the keywords you type to search
|
||||
|
||||
- **Audit Policy** <br>
|
||||
Audit Policy defines a set of rules about what events should be recorded and what data they should include.
|
||||
|
||||
- **Audit Rule** <br>
|
||||
An auditing rule defines how to process auditing logs.
|
||||
|
||||
- **Audit Webhook** <br>
|
||||
The webhook that the Kubernetes auditing logs will be sent to.
|
||||
|
||||
## Monitoring, Alert and Notification
|
||||
|
||||
- **Cluster Status Monitoring** <br>
|
||||
The monitoring of related metrics such as node status, component status, CPU, memory, network, and disk of the cluster.
|
||||
|
||||
- **Application Resource Monitoring** <br>
|
||||
The monitoring of application resources across the platform, such as the number of projects and DevOps projects, as well as the number of workloads and services of a specific type.
|
||||
|
||||
- **Allocated CPU** <br>
|
||||
The metric is calculated based on the total CPU requests of Pods, for example, on a node. It represents the amount of CPU reserved for workloads on this node, even if workloads are using fewer CPU resources.
|
||||
|
||||
- **Allocated Memory** <br>
|
||||
The metric is calculated based on the total memory requests of Pods, for example, on a node. It represents the amount of memory reserved for workloads on this node, even if workloads are using fewer memory resources.
|
||||
|
||||
- **Disk Log Collection** <br>
|
||||
The capability to collect disk logs in a container and export to stdout, which will then be collected by the system log collector.
|
||||
|
||||
- **Notification Receiver** <br>
|
||||
The channel to receive notification, such as email, wechat work, slack, webhook, etc.
|
||||
|
||||
## Router
|
||||
|
||||
- **Route** <br>
|
||||
A KubeSphere Route is a Kubernetes Ingress.
|
||||
|
||||
- **Gateway** <br>
|
||||
Before creating a route, you need to enable the Internet access gateway which forwards the request to the corresponding backend service.
|
||||
|
||||
## Service Mesh
|
||||
|
||||
- **Canary Release** <br>
|
||||
A graceful applicaiton release method that introduces a new version of a service and test it by sending a small percentage of traffic to it. At the same time, the old version is responsible for handling the rest of the traffic. If everything goes well, you can gradually increase the traffic sent to the new version, while simultaneously phasing out the old version. In the case of any occurring issues, it allows you to roll back to the previous version as you change the traffic percentage.
|
||||
|
||||
- **Blue Green Release** <br>
|
||||
A zero downtime application deployment in that the new version can be deployed with the old one preserved. At any time, only one of the versions is active serving all the traffic, while the other one remains idle. If there is a problem with running, you can quickly roll back to the old version.
|
||||
|
||||
- **Traffic Mirroring** <br>
|
||||
A risk-free method of testing your app versions as it sends a copy of live traffic to a service that is being mirrored. It is also called shadowing.
|
||||
|
||||
- **Application Governance** <br>
|
||||
A switch to control the tracing of your application within a project.
|
||||
|
||||
## Multi Cluster
|
||||
|
||||
- **Host Cluster** <br>
|
||||
The cluster used to manage member clusters. The multi-cluster control plane is deployed on the host cluster.
|
||||
|
||||
- **Member Cluster** <br>
|
||||
A cluster as a member of the group of the multiple clusters.
|
||||
|
||||
- **Direct Connection** <br>
|
||||
The connection method between host cluster and member cluster when the kube-apiserver address of the member cluster is accessible on any node of the host cluster.
|
||||
|
||||
- **Agent Connection** <br>
|
||||
The connection method between host cluster and member cluster when the host cluster cannot access the member cluster.
|
||||
|
||||
- **jwtSecret** <br>
|
||||
The secret needed for host cluster and member cluster to communicate with each other.
|
||||
|
||||
- **Tower** <br>
|
||||
When using agent connection, there is a proxy component installed on host cluster and agent installed on member cluster. A tower consists of the proxy and the agent.
|
||||
|
||||
- **Proxy Service Address** <br>
|
||||
The communication service address of the host cluster required by the tower agent in member cluster when using agent connection.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: "KubeSphere API"
|
||||
description: "How to use KubeSphere API to build your own application"
|
||||
layout: "single"
|
||||
|
||||
linkTitle: "API Documentation"
|
||||
|
||||
weight: 8100
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
---
|
||||
|
||||
## [API Documentation](./kubesphere-api/)
|
||||
|
||||
The REST API is the fundamental fabric of KubeSphere. This page show you how to access KubeSphere API server.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: "API Changes"
|
||||
description: "API Change Overview"
|
||||
layout: "single"
|
||||
|
||||
linkTitle: "API Changes"
|
||||
|
||||
weight: 8200
|
||||
|
||||
icon: "/images/docs/docs.svg"
|
||||
|
||||
---
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: "Logging"
|
||||
keywords: 'Kubernetes, KubeSphere, API, Logging'
|
||||
description: 'Logging'
|
||||
|
||||
|
||||
weight: 250
|
||||
---
|
||||
|
||||
## Time format
|
||||
|
||||
The time format for query parameters must be in Unix timestamp, which is the number of seconds that have elapsed since the Unix epoch. Millisecond is no longer allowed. The change affects the parameters `start_time` and `end_time`.
|
||||
|
||||
## Deprecated APIs
|
||||
|
||||
The following APIs are removed:
|
||||
|
||||
- GET /workspaces/{workspace}
|
||||
- GET /namespaces/{namespace}
|
||||
- GET /namespaces/{namespace}/workloads/{workload}
|
||||
- GET /namespaces/{namespace}/pods/{pod}
|
||||
- The whole log setting API group
|
||||
|
||||
## Fluent Bit Operator
|
||||
|
||||
In KubeSphere 3.0.0, the whole log setting APIs are removed from the KubeSphere core since the project Fluent Bit Operator is refactored in an incompatible way. Please refer to [Fluent Bit Operator docs](https://github.com/kubesphere/fluentbit-operator) for how to configure log collection in KubeSphere 3.0.0.
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
---
|
||||
title: "Monitoring"
|
||||
keywords: 'Kubernetes, KubeSphere, API, Monitoring'
|
||||
description: 'Monitoring'
|
||||
|
||||
|
||||
weight: 260
|
||||
---
|
||||
|
||||
## API Version
|
||||
|
||||
The monitoring API version is bumped to `v1alpha3`.
|
||||
|
||||
## Time format
|
||||
|
||||
The time format for query parameters must be in Unix timestamp, which is the number of seconds that have elapsed since the Unix epoch. Decimal is no longer allowed. The change affects the parameters `start`, `end` and `time`.
|
||||
|
||||
## Deprecated Metrics
|
||||
|
||||
In KubeSphere 3.0.0, the metrics on the left have been renamed into the ones on the right.
|
||||
|
||||
|V2.0|V3.0|
|
||||
|---|---|
|
||||
|workload_pod_cpu_usage | workload_cpu_usage|
|
||||
|workload_pod_memory_usage| workload_memory_usage|
|
||||
|workload_pod_memory_usage_wo_cache | workload_memory_usage_wo_cache|
|
||||
|workload_pod_net_bytes_transmitted | workload_net_bytes_transmitted|
|
||||
|workload_pod_net_bytes_received | workload_net_bytes_received|
|
||||
|
||||
The following metrics have been deprecated and removed.
|
||||
|
||||
|Deprecated Metrics|
|
||||
|---|
|
||||
|cluster_workspace_count|
|
||||
|cluster_account_count|
|
||||
|cluster_devops_project_count|
|
||||
|coredns_up_sum|
|
||||
|coredns_cache_hits|
|
||||
|coredns_cache_misses|
|
||||
|coredns_dns_request_rate|
|
||||
|coredns_dns_request_duration|
|
||||
|coredns_dns_request_duration_quantile|
|
||||
|coredns_dns_request_by_type_rate|
|
||||
|coredns_dns_request_by_rcode_rate|
|
||||
|coredns_panic_rate|
|
||||
|coredns_proxy_request_rate|
|
||||
|coredns_proxy_request_duration|
|
||||
|coredns_proxy_request_duration_quantile|
|
||||
|prometheus_up_sum|
|
||||
|prometheus_tsdb_head_samples_appended_rate|
|
||||
|
||||
New metrics are introduced in KubeSphere 3.0.0.
|
||||
|
||||
|New Metrics|
|
||||
|---|
|
||||
|kubesphere_workspace_count|
|
||||
|kubesphere_user_count|
|
||||
|kubesphere_cluser_count|
|
||||
|kubesphere_app_template_count|
|
||||
|
||||
## Response Fields
|
||||
|
||||
In KubeSphere 3.0.0, the response fields `metrics_level`, `status` and `errorType` are removed.
|
||||
|
||||
In addition, the field name `resource_name` has been replaced with the specific resource type names. These types are `node`, `workspace`, `namespace`, `workload`, `pod`, `container` and `persistentvolumeclaim`. For example, instead of `resource_name: node1`, you will get `node: node1`. See the example response below:
|
||||
|
||||
```json
|
||||
{
|
||||
"results":[
|
||||
{
|
||||
"metric_name":"node_cpu_utilisation",
|
||||
"data":{
|
||||
"resultType":"vector",
|
||||
"result":[
|
||||
{
|
||||
"metric":{
|
||||
"__name__":"node:node_cpu_utilisation:avg1m",
|
||||
"node":"master"
|
||||
},
|
||||
"value":[
|
||||
1588841175.979,
|
||||
"0.04587499999997817"
|
||||
]
|
||||
},
|
||||
{
|
||||
"metric":{
|
||||
"__name__":"node:node_cpu_utilisation:avg1m",
|
||||
"node":"node1"
|
||||
},
|
||||
"value":[
|
||||
1588841175.979,
|
||||
"0.06379166666670245"
|
||||
]
|
||||
},
|
||||
{
|
||||
"metric":{
|
||||
"__name__":"node:node_cpu_utilisation:avg1m",
|
||||
"node":"node2"
|
||||
},
|
||||
"value":[
|
||||
1588841175.979,
|
||||
"0.19008333333367772"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
---
|
||||
title: "KubeSphere API"
|
||||
keywords: 'Kubernetes, KubeSphere, API'
|
||||
description: 'KubeSphere API documentation'
|
||||
|
||||
|
||||
weight: 240
|
||||
---
|
||||
|
||||
In KubeSphere v3.0, we move the functionalities of _ks-apigateway_, _ks-account_ into _ks-apiserver_ to make the architecture more compact and straight forward. In order to use KubeSphere API, you need to expose _ks-apiserver_ to your client.
|
||||
|
||||
## Expose KubeSphere API service
|
||||
If you are going to access KubeSphere inside the cluster, you can skip the following section and just using the KubeSphere API server endpoint **`http://ks-apiserver.kubesphere-system.svc`**.
|
||||
|
||||
But if not, you need to expose the KubeSphere API server endpoint to the outside of the cluster first.
|
||||
|
||||
There are many ways to expose a Kubernetes service, for simplicity, we use _NodePort_ in our case. Change service `ks-apiserver` type to NodePort by using following command, and then you are done.
|
||||
```bash
|
||||
root@master:~# kubectl -n kubesphere-system patch service ks-apiserver -p '{"spec":{"type":"NodePort"}}'
|
||||
root@master:~# kubectl -n kubesphere-system get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
etcd ClusterIP 10.233.34.220 <none> 2379/TCP 44d
|
||||
ks-apiserver NodePort 10.233.15.31 <none> 80:31407/TCP 49d
|
||||
ks-console NodePort 10.233.3.45 <none> 80:30880/TCP 49d
|
||||
```
|
||||
|
||||
Now, you can access `ks-apiserver` outside the cluster through URL like `http://[node ip]:31407`, where `[node ip]` means IP of any node in your cluster.
|
||||
|
||||
## Generate a token
|
||||
There is one more thing to do before calling the API, authorization. Any clients that talk to the KubeSphere API server need to identify themselves first, only after successful authorization will the server respond to the call.
|
||||
|
||||
Let's say now a user `jeff` with password `P#$$w0rd` want to generate a token. He/She can issue a request like the following:
|
||||
```bash
|
||||
root@master:~# curl -X POST -H 'Content-Type: application/x-www-form-urlencoded' \
|
||||
'http://[node ip]:31407/oauth/token' \
|
||||
--data-urlencode 'grant_type=password' \
|
||||
--data-urlencode 'username=admin' \
|
||||
--data-urlencode 'password=P#$$w0rd'
|
||||
```
|
||||
If the identity is correct, the server will response something like the following. `access_token` is the token what we need to access the KubeSphere API Server.
|
||||
```json
|
||||
{
|
||||
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwidWlkIjoiYTlhNjJmOTEtYWQ2Yi00MjRlLWIxNWEtZTFkOTcyNmUzNDFhIiwidG9rZW5fdHlwZSI6ImFjY2Vzc190b2tlbiIsImV4cCI6MTYwMDg1MjM5OCwiaWF0IjoxNjAwODQ1MTk4LCJpc3MiOiJrdWJlc3BoZXJlIiwibmJmIjoxNjAwODQ1MTk4fQ.Hcyf-CPMeq8XyQQLz5PO-oE1Rp1QVkOeV_5J2oX1hvU",
|
||||
"token_type": "Bearer",
|
||||
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwidWlkIjoiYTlhNjJmOTEtYWQ2Yi00MjRlLWIxNWEtZTFkOTcyNmUzNDFhIiwidG9rZW5fdHlwZSI6InJlZnJlc2hfdG9rZW4iLCJleHAiOjE2MDA4NTk1OTgsImlhdCI6MTYwMDg0NTE5OCwiaXNzIjoia3ViZXNwaGVyZSIsIm5iZiI6MTYwMDg0NTE5OH0.PerssCLVXJD7BuCF3Ow8QUNYLQxjwqC8m9iOkRRD6Tc",
|
||||
"expires_in": 7200
|
||||
}
|
||||
```
|
||||
> **Note**: Please substitue `[node ip]:31407` with the real ip address.
|
||||
|
||||
## Make the call
|
||||
|
||||
Now you got everything you need to access api server, make the call using the access token just acquire :
|
||||
```bash
|
||||
root@master1:~# curl -X GET -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwidWlkIjoiYTlhNjJmOTEtYWQ2Yi00MjRlLWIxNWEtZTFkOTcyNmUzNDFhIiwidG9rZW5fdHlwZSI6ImFjY2Vzc190b2tlbiIsImV4cCI6MTYwMDg1MjM5OCwiaWF0IjoxNjAwODQ1MTk4LCJpc3MiOiJrdWJlc3BoZXJlIiwibmJmIjoxNjAwODQ1MTk4fQ.Hcyf-CPMeq8XyQQLz5PO-oE1Rp1QVkOeV_5J2oX1hvU" \
|
||||
-H 'Content-Type: application/json' \
|
||||
'http://10.233.15.31/kapis/resources.kubesphere.io/v1alpha3/nodes'
|
||||
|
||||
{
|
||||
"items": [
|
||||
{
|
||||
"metadata": {
|
||||
"name": "node3",
|
||||
"selfLink": "/api/v1/nodes/node3",
|
||||
"uid": "dd8c01f3-76e8-4695-9e54-45be90d9ec53",
|
||||
"resourceVersion": "84170589",
|
||||
"creationTimestamp": "2020-06-18T07:36:41Z",
|
||||
"labels": {
|
||||
"a": "a",
|
||||
"beta.kubernetes.io/arch": "amd64",
|
||||
"beta.kubernetes.io/os": "linux",
|
||||
"gitpod.io/theia.v0.4.0": "available",
|
||||
"gitpod.io/ws-sync": "available",
|
||||
"kubernetes.io/arch": "amd64",
|
||||
"kubernetes.io/hostname": "node3",
|
||||
"kubernetes.io/os": "linux",
|
||||
"kubernetes.io/role": "new",
|
||||
"node-role.kubernetes.io/worker": "",
|
||||
"topology.disk.csi.qingcloud.com/instance-type": "Standard",
|
||||
"topology.disk.csi.qingcloud.com/zone": "ap2a"
|
||||
},
|
||||
"annotations": {
|
||||
"csi.volume.kubernetes.io/nodeid": "{\"disk.csi.qingcloud.com\":\"i-icjxhi1e\"}",
|
||||
"kubeadm.alpha.kubernetes.io/cri-socket": "/var/run/dockershim.sock",
|
||||
"node.alpha.kubernetes.io/ttl": "0",
|
||||
....
|
||||
```
|
||||
|
||||
## API Reference
|
||||
KubeSpehre API swagger json can be found in repo https://github.com/kubesphere/kubesphere/blob/master/api/
|
||||
|
||||
- KubeSphere specified API [swagger json](https://github.com/kubesphere/kubesphere/blob/master/api/ks-openapi-spec/swagger.json). It contains all the API that only applied to KubeSphere.
|
||||
- KubeSphere specified CRD [swagger json](https://github.com/kubesphere/kubesphere/blob/master/api/openapi-spec/swagger.json). Contains all the generated CRD api documentation, it's same with Kubernetes api objects.
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
---
|
||||
title: "Glossary"
|
||||
keywords: 'kubernetes, kubesphere, devops, docker, helm, jenkins, istio, prometheus'
|
||||
description: 'KubeSphere Glossary documentation'
|
||||
|
||||
|
||||
weight: 240
|
||||
---
|
||||
|
||||
This glossary includes technical terms that are specific to KubeSphere, as well as more general terms that provide useful context.
|
||||
|
||||
## General
|
||||
|
||||
- **Workspace** <br>
|
||||
A logical unit to organize a tenant's workload projects / Kubernetes namespaces, DevOps projects, manage resource access and share information within the team.
|
||||
|
||||
- **System Workspace** <br>
|
||||
The special place to organize system projects from KubeSphere, Kubernetes and optional components such as OpenPitrix, Istio, monitorng etc.
|
||||
|
||||
- **Workspace member** <br>
|
||||
The users that are invited into the workspace who have certain priviledge to work in the workspace.
|
||||
|
||||
- **Project** <br>
|
||||
A project in KubeSphere is a Kubernetes namespace
|
||||
|
||||
- **Multi-cluster Project** <br>
|
||||
A project whose workload is deployed into multiple clusters.
|
||||
|
||||
- **Project memeber** <br>
|
||||
The users that are invited into the project who have certain priviledge to access the project.
|
||||
|
||||
- **Workbench** <br>
|
||||
The landing page for a tenant where contains authorized resources to access including workspaces, App Store, etc.
|
||||
|
||||
- **Volume** <br>
|
||||
A KubeSphere Volume is a Kubernetes Persistent Volume Claim (PVC)
|
||||
|
||||
- **Public Cluster** <br>
|
||||
Platform admin can set the cluster visibility, meaning who can access the cluster. A public cluster means all platform users can access the cluster, in which they are able to create and schedule resources.
|
||||
|
||||
- **KubeKey** <br>
|
||||
A brand-new installation tool developed in Go. It can install KubeSphere and Kubernetes separately or install them at one time.
|
||||
|
||||
- **ks-installer** <br>
|
||||
The package to deploy KubeSphere on existing Kubernetes clusters.
|
||||
|
||||
## Application
|
||||
|
||||
- **OpenPitirx** <br>
|
||||
An open-source system to package, deploy and manage different types of apps.
|
||||
|
||||
- **App Template** <br>
|
||||
A template for a specific application that other users can deploy new application instances based on the template.
|
||||
|
||||
- **App Repo** <br>
|
||||
A web accessible repo that hosts a bunch of application templates.
|
||||
|
||||
- **App Store** <br>
|
||||
A public place for different users to share various applications.
|
||||
|
||||
## DevOps
|
||||
|
||||
- **DevOps Project** <br>
|
||||
A project specific for DevOps where you can manage your pipelines and related information.
|
||||
|
||||
- **SCM** <br>
|
||||
Source Control Management, such as GitHub, Gitlab, etc.
|
||||
|
||||
- **In-SCM** <br>
|
||||
The pipeline based on a Jenkinsfile that is hosted in SCM.
|
||||
|
||||
- **Out-of-SCM** <br>
|
||||
The pipeline created by using graphical editing panel, which means no Jenkinsfile needed.
|
||||
|
||||
- **CI Node** <br>
|
||||
The specific node for pipeline or S2I, B2I. Generally, applications often need to pull a lot of dependencies during the build process. It might cause some issues like long pulling time, or unstable network causing failure. In order to make build robust, and to speed up the build by using cache, we recommend you configure one or a set of CI nodes which the system schedules the task of CI/CD pipelines or S2I/B2I builds running on.
|
||||
|
||||
- **B2I** <br>
|
||||
Binary to Image. As similar as S2I, B2I is a toolkit and automated workflow for building reproducible container images from binary (e.g. Jar, War, Binary package).
|
||||
|
||||
## Logging, Events and Auditing
|
||||
|
||||
- **Exact Query** <br>
|
||||
The query method that exactly matches the keywords you type to search
|
||||
|
||||
- **Fuzzy Query** <br>
|
||||
The query method that partially matches the keywords you type to search
|
||||
|
||||
- **Audit Policy** <br>
|
||||
Audit Policy defines a set of rules about what events should be recorded and what data they should include.
|
||||
|
||||
- **Audit Rule** <br>
|
||||
An auditing rule defines how to process auditing logs.
|
||||
|
||||
- **Audit Webhook** <br>
|
||||
The webhook that the Kubernetes auditing logs will be sent to.
|
||||
|
||||
## Monitoring, Alert and Notification
|
||||
|
||||
- **Cluster Status Monitoring** <br>
|
||||
The monitoring of related metrics such as node status, component status, CPU, memory, network, and disk of the cluster.
|
||||
|
||||
- **Application Resource Monitoring** <br>
|
||||
The monitoring of application resources across the platform, such as the number of projects and DevOps projects, as well as the number of workloads and services of a specific type.
|
||||
|
||||
- **Allocated CPU** <br>
|
||||
The metric is calculated based on the total CPU requests of Pods, for example, on a node. It represents the amount of CPU reserved for workloads on this node, even if workloads are using fewer CPU resources.
|
||||
|
||||
- **Allocated Memory** <br>
|
||||
The metric is calculated based on the total memory requests of Pods, for example, on a node. It represents the amount of memory reserved for workloads on this node, even if workloads are using fewer memory resources.
|
||||
|
||||
- **Disk Log Collection** <br>
|
||||
The capability to collect disk logs in a container and export to stdout, which will then be collected by the system log collector.
|
||||
|
||||
- **Notification Receiver** <br>
|
||||
The channel to receive notification, such as email, wechat work, slack, webhook, etc.
|
||||
|
||||
## Router
|
||||
|
||||
- **Route** <br>
|
||||
A KubeSphere Route is a Kubernetes Ingress.
|
||||
|
||||
- **Gateway** <br>
|
||||
Before creating a route, you need to enable the Internet access gateway which forwards the request to the corresponding backend service.
|
||||
|
||||
## Service Mesh
|
||||
|
||||
- **Canary Release** <br>
|
||||
A graceful applicaiton release method that introduces a new version of a service and test it by sending a small percentage of traffic to it. At the same time, the old version is responsible for handling the rest of the traffic. If everything goes well, you can gradually increase the traffic sent to the new version, while simultaneously phasing out the old version. In the case of any occurring issues, it allows you to roll back to the previous version as you change the traffic percentage.
|
||||
|
||||
- **Blue Green Release** <br>
|
||||
A zero downtime application deployment in that the new version can be deployed with the old one preserved. At any time, only one of the versions is active serving all the traffic, while the other one remains idle. If there is a problem with running, you can quickly roll back to the old version.
|
||||
|
||||
- **Traffic Mirroring** <br>
|
||||
A risk-free method of testing your app versions as it sends a copy of live traffic to a service that is being mirrored. It is also called shadowing.
|
||||
|
||||
- **Application Governance** <br>
|
||||
A switch to control the tracing of your application within a project.
|
||||
|
||||
## Multi Cluster
|
||||
|
||||
- **Host Cluster** <br>
|
||||
The cluster used to manage member clusters. The multi-cluster control plane is deployed on the host cluster.
|
||||
|
||||
- **Member Cluster** <br>
|
||||
A cluster as a member of the group of the multiple clusters.
|
||||
|
||||
- **Direct Connection** <br>
|
||||
The connection method between host cluster and member cluster when the kube-apiserver address of the member cluster is accessible on any node of the host cluster.
|
||||
|
||||
- **Agent Connection** <br>
|
||||
The connection method between host cluster and member cluster when the host cluster cannot access the member cluster.
|
||||
|
||||
- **jwtSecret** <br>
|
||||
The secret needed for host cluster and member cluster to communicate with each other.
|
||||
|
||||
- **Tower** <br>
|
||||
When using agent connection, there is a proxy component installed on host cluster and agent installed on member cluster. A tower consists of the proxy and the agent.
|
||||
|
||||
- **Proxy Service Address** <br>
|
||||
The communication service address of the host cluster required by the tower agent in member cluster when using agent connection.
|
||||
Loading…
Reference in New Issue