Glossary

This glossary includes general terms and technical terms that are specific to KubeSphere.

General

• Workspace
  A logical unit to organize a tenant's workload projects (i.e. Kubernetes namespaces) and DevOps projects. It also features access control of different resources and allows team members to share information.
• System workspace
  A special place to organize system projects of KubeSphere, Kubernetes and optional components such as App Store, service mesh and DevOps.
• Workspace member
  The users that are invited to a workspace who have certain permissions to work in the workspace.
• Project
  A project in KubeSphere is a Kubernetes namespace.
• Multi-cluster project
  A project whose workloads are deployed across multiple clusters.
• Project member
  The users that are invited to a project who have certain permissions to work in the project.
• Workbench
  The landing page for a tenant. It displays authorized resources that the tenant can access such as workspaces and projects.
• Volume
  A KubeSphere Volume is a Kubernetes PersistentVolumeClaim (PVC).
• Public cluster
  Cluster administrators can set cluster visibility so that a cluster is available to certain workspaces. A public cluster means all platform users can access the cluster, in which they are able to create and schedule resources.
• KubeKey
  A brand-new installation tool developed in Go. It is able to install KubeSphere and Kubernetes together or install Kubernetes only. It supports the deployment of cloud-native add-ons (YAML or Chart) as it creates a cluster. It can also be used to scale and upgrade a cluster.
• ks-installer
  The package to deploy KubeSphere on existing Kubernetes clusters.

Applications and Workloads

• OpenPitrix
  An open-source system to package, deploy and manage different types of apps.

• App template
  A template for a specific application that tenants can use to deploy new application instances.

• App repository
  A web accessible repository that hosts different app templates.

• App Store
  A public place for different tenants to share various applications.

• Deployment
  You use a Deployment to describe a desired state. The Kubernetes Deployment controller changes the actual state to the desired state at a controlled rate. In other words, a Deployment runs multiple replicas of an application and replaces any instances if they fail. For more information, see Deployments.

• StatefulSet
  A StatefulSet is the workload object used to manage stateful applications, such as MySQL. For more information, see StatefulSets.

• DaemonSet
  A DaemonSet ensures that all (or some) nodes run a copy of a Pod, such as Fluentd and Logstash. For more information, see DaemonSets.

• Job
  A Job creates one or more Pods and ensures that a specified number of them successfully terminate. For more information, see Jobs.

• CronJob
  A CronJob creates Jobs on a time-based schedule. A CronJob object is like one line of a crontab (cron table) file. It runs a Job periodically on a given schedule. For more information, see CronJob.

• Service
  A Kubernetes Service is an abstraction object which defines a logical set of Pods and a policy by which to access them - sometimes called a microservice. For more information, see Service.

DevOps

• DevOps project
  A specific project for DevOps where you manage pipelines and credentials.

• SCM
  Source Control Management, such as GitHub and Gitlab.

• In-SCM
  The pipeline based on a Jenkinsfile that is hosted in SCM.

• Out-of-SCM
  The pipeline created through graphical editing panels without a Jenkinsfile.

• CI node
  A specific node for pipelines, S2I jobs or B2I jobs. Generally, applications often need to pull various dependencies during the building process. It might cause some issues like long pulling time, or unstable network causing failure. To build robust pipelines and speed up the building by using caches, you configure one or a set of CI nodes to which KubeSphere schedules the tasks of CI/CD pipelines and S2I/B2I.

• B2I
  Binary-to-Image. B2I is a toolkit and workflow for building reproducible container images from binary executables such as Jar, War, and binary packages.

• S2I
  Source-to-Image. S2I is a toolkit and workflow for building reproducible container images from source code. S2I produces ready-to-run images by injecting source code into a container image and letting the container prepare that source code for execution.

Logging, Events and Auditing

• Exact query
  The method to search results that perfectly match the keyword entered.

• Fuzzy query
  The method to search results that partially match the keyword entered.

• Audit policy
  An audit policy defines a set of rules about what events should be recorded and what data they should include.

• Audit rule
  An auditing rule defines how to process auditing logs.

• Audit webhook
  The webhook that the Kubernetes auditing logs will be sent to.

Monitoring, Alert and Notification

• Cluster Status Monitoring
  The monitoring of related metrics such as node status, component status, CPU, memory, network, and disk of the cluster.

• Application Resource Monitoring
  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
  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
  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.

• Log Collection
  The Log Collection function allows the system to collect container logs saved on volumes and send the logs to standard output.

• Notification Receiver
  The channel to receive notifications, such as email, DingTalk, WeCom, Slack, and webhook.

Network

• Route
  A KubeSphere Route is a Kubernetes Ingress.

• Gateway
  Before creating a route, you need to enable the Internet access gateway which forwards requests to the corresponding backend service.

Service Mesh

• Canary release
  A graceful application release method that introduces a new version of a service and tests 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/deployment
  A zero downtime application deployment where 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
  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
  A switch to control the tracing of your application within a project.

Multi-cluster Management

• Host Cluster (H Cluster)
  The cluster that manages Member Clusters. The multi-cluster control plane is deployed on the Host Cluster.

• Member Cluster (M Cluster)
  A cluster serving as a member managed by the Host Cluster in a multi-cluster architecture.

• Direct connection
  A way to connect the Host Cluster and the Member Cluster when the kube-apiserver address of the Member Cluster is accessible on any node of the Host Cluster.

• Agent connection
  A way to connect the Host Cluster and the Member Cluster when the Host Cluster cannot access the Member Cluster directly.

• jwtSecret
  The secret needed for the Host Cluster and the Member Cluster to communicate with each other.

• Tower
  When you use agent connection, there is a proxy component installed on the Host Cluster and agent installed on the Member Cluster. Tower consists of both the proxy and the agent.

• Proxy service address
  The communication service address of the Host Cluster required by the tower agent in the Member Cluster when agent connection is adopted.

Thanks for the feedback. If you have a specific question about how to use KubeSphere, ask it on Slack. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.