KubeBlocks 0.9 and 1.0 added and enabled (will be removed in 1.0) some APIs, and the corresponding addons have also been adjusted. This document sorts out the adaptation work that kbcli needs to do according to the new APIs.
Cluster Related
Cluster Create
Currently, there are two ways to create a Cluster:
Specify the cd/cv method, e.g.
kbcli cluster create my --cluster-definition=mysql --cluster-version=... --set type=..,cpu=..,memory=..
Subcommand method, rendered through helm chart, e.g.
kbcli cluster create mysql --cpu=... --memory=...
In kbcli 1.0, we consider not supporting the first method anymore, and only support creating clusters through rendering cluster helm charts. In this way, kbcli needs to load the corresponding cluster helm chart, render command line parameters according to schema.json, and render the cluster object according to the parameters and helm. The design document refers to the KubeBlocks Interaction Interface Simplification and Unification Solution.
In kbcli 1.0, there are the following matters:
Unified cluster helm chart schema
From the perspective of user experience, form a unified schema specification, and the schema will eventually be reflected as command line parameters. Take apecloud-mysql as an example, the schema file mainly configures the CPU, memory, storage size, storage class, topology, replica number, and shard number of the cluster. For multi-component clusters, it needs to support configuring different components, such as sentinel.cpu, sentinel.memory, etc.
Flexibly use different versions of cluster helm charts
Currently, kbcli embeds a set of default supported engine cluster helm charts during compilation. The engine list can be specified in the Makfile file. The disadvantage of embedding cluster helm charts is that it cannot flexibly specify which cluster helm chart to use. If the corresponding engine's cluster helm chart is updated, kbcli needs to be recompiled to use the corresponding version of the helm chart. Possible improvement plans are as follows:
- Register the helm chart through kbcli cluster register and use it, e.g.
# Register cluster helm chart
kbcli cluster register mysql1 --source https://github.com/apecloud/helm-charts/releases/download/mysql-cluster-1.0.0-alpha.0/mysql-cluster-1.0.0-alpha.0.tgz
# Use
kbcli cluster create mysql1 -h
Currently, the cluster register command is supported, but this command cannot replace the built-in cluster helm chart. For example, the above command does not support registering mysql because mysql already exists.
- cluster register supports overriding existing built-in subcommands, prioritizing the use of the user-registered cluster helm chart, and using the built-in cluster helm chart if none is registered.
- Other solutions, such as no longer embedding the cluster chart, and using cluster helm charts from specific paths or repos.
Enrich cluster chart commands
- The cluster register command only supports obtaining the cluster helm chart by specifying the path through --source. Consider supporting specifying the helm repo and version to obtain the corresponding cluster helm chart, similar to the helm pull command, simplifying the process of obtaining the chart link
kbcli cluster register NAME --engine= --repo=... --version=...
A default repo can be built-in, referring to the logic of selecting the helm repo when kbcli kb install.
- Support displaying all supported engines
Currently, kbcli cluster create -h only displays built-in and registered engines, and cannot display all supported engines. Consider supporting the following command to get a list of all supported engines:
kbcli cluster list-engines
Obtain and display information of all cluster helm charts from the corresponding repo (or consider using addon information to display, similar to kbcli addon search)
- Support validating the cluster helm chart (there can be a separate command for validation, or validation during registration), verifying whether the chart complies with the specifications, such as whether it contains the schema.json file, and whether the schema.json file complies with the specifications
- Generate a cluster helm chart example, developers can write their own cluster helm chart based on this
Cluster Describe
The kbcli cluster describe command needs to adapt to the latest API, and obtain the cluster information such as Topology and Component according to the new API.
Cluster Connect
Adapt the implementation of kbcli cluster connect according to the adjustments of lorry.
Others
Ensure that other commands run correctly in the new API scenario:
kbcli cluster list-instances
kbcli cluster list-components
kbcli cluster update
Ops
Ensure that all Ops commands run correctly under the new API.
Playground
Consider no longer supporting the public cloud scenario for playground, and only support the local k3d playground. The public cloud playground requires maintaining the corresponding terraform code, and the terraform code also needs to be maintained as the public cloud updates and iterates, resulting in high maintenance costs and less usage scenarios. Users can purchase K8s instances on public clouds themselves and deploy KubeBlocks.
KubeBlocks
In KB 1.0, the logic of resource conversion and CRD update during the upgrade process is unified into the hooks of the helm chart. We can consider removing the relevant logic from kbcli and use the logic in the helm chart directly.
New Commands
Introduce new commands to query and display information related to the new APIs.
kbcli cmpd list // similar to kubectl get cmpd, can display more fields, such as Provider
kbcli cmpd describe CMPD-NAME // display detailed information of a specific cmpd
kbcli cmpv list // similar to kubectl get cmpv, can display more fields
kbcli cmpv describe CMPV-NAME // display detailed information of the specified cmpv
kbcli cd list // similar to kubectl get cd, additionally display topology information
kbcli cd describe CD-NAME // display detailed information of the specified CD, including topology information
Removed Commands
Consider removing the kbcli plugin command, as there is currently no use case.
Remove the kbcli clusterversion command, as the clusterVersion CRD will be removed in KB 1.0."
KubeBlocks 0.9 and 1.0 added and enabled (will be removed in 1.0) some APIs, and the corresponding addons have also been adjusted. This document sorts out the adaptation work that kbcli needs to do according to the new APIs.
Cluster Related
Cluster Create
Currently, there are two ways to create a Cluster:
Specify the cd/cv method, e.g.
kbcli cluster create my --cluster-definition=mysql --cluster-version=... --set type=..,cpu=..,memory=..Subcommand method, rendered through helm chart, e.g.
kbcli cluster create mysql --cpu=... --memory=...In kbcli 1.0, we consider not supporting the first method anymore, and only support creating clusters through rendering cluster helm charts. In this way, kbcli needs to load the corresponding cluster helm chart, render command line parameters according to schema.json, and render the cluster object according to the parameters and helm. The design document refers to the KubeBlocks Interaction Interface Simplification and Unification Solution.
In kbcli 1.0, there are the following matters:
Unified cluster helm chart schema
From the perspective of user experience, form a unified schema specification, and the schema will eventually be reflected as command line parameters. Take apecloud-mysql as an example, the schema file mainly configures the CPU, memory, storage size, storage class, topology, replica number, and shard number of the cluster. For multi-component clusters, it needs to support configuring different components, such as sentinel.cpu, sentinel.memory, etc.
Flexibly use different versions of cluster helm charts
Currently, kbcli embeds a set of default supported engine cluster helm charts during compilation. The engine list can be specified in the Makfile file. The disadvantage of embedding cluster helm charts is that it cannot flexibly specify which cluster helm chart to use. If the corresponding engine's cluster helm chart is updated, kbcli needs to be recompiled to use the corresponding version of the helm chart. Possible improvement plans are as follows:
Currently, the cluster register command is supported, but this command cannot replace the built-in cluster helm chart. For example, the above command does not support registering mysql because mysql already exists.
Enrich cluster chart commands
kbcli cluster register NAME --engine= --repo=... --version=...A default repo can be built-in, referring to the logic of selecting the helm repo when kbcli kb install.
Currently, kbcli cluster create -h only displays built-in and registered engines, and cannot display all supported engines. Consider supporting the following command to get a list of all supported engines:
kbcli cluster list-enginesObtain and display information of all cluster helm charts from the corresponding repo (or consider using addon information to display, similar to kbcli addon search)
Cluster Describe
The kbcli cluster describe command needs to adapt to the latest API, and obtain the cluster information such as Topology and Component according to the new API.
Cluster Connect
Adapt the implementation of kbcli cluster connect according to the adjustments of lorry.
Others
Ensure that other commands run correctly in the new API scenario:
Ops
Ensure that all Ops commands run correctly under the new API.
Playground
Consider no longer supporting the public cloud scenario for playground, and only support the local k3d playground. The public cloud playground requires maintaining the corresponding terraform code, and the terraform code also needs to be maintained as the public cloud updates and iterates, resulting in high maintenance costs and less usage scenarios. Users can purchase K8s instances on public clouds themselves and deploy KubeBlocks.
KubeBlocks
In KB 1.0, the logic of resource conversion and CRD update during the upgrade process is unified into the hooks of the helm chart. We can consider removing the relevant logic from kbcli and use the logic in the helm chart directly.
New Commands
Introduce new commands to query and display information related to the new APIs.
Removed Commands
Consider removing the kbcli plugin command, as there is currently no use case.
Remove the kbcli clusterversion command, as the clusterVersion CRD will be removed in KB 1.0."