karmada
karmada copied to clipboard
karmada-io
Enhance karmadactl operation and maintenance experience
What would you like to be added:
In daily use of karmadactl, I found that karmadactl supports fewer subcommands and cannot be used completely without kubectl. And the designs of different subcommands are inconsistent. For example, without presenting flag --cluster in the subcommand apply represents no specific cluster, but in the subcommand get pod it represents all clusters. This will cause confusion for users.
So, in this issue, I hope to discuss how to improve the operation and maintenance experience of karmadactl and establish unified design principles. This will be a huge, long-term and interesting project.
Why is this needed: improve the operation and maintenance experience of karmadactl and establish unified design principles.
One of the goals of improving the operation and maintenance experience of karmadactl this time is to basically replace kubectl. Therefore, I investigated the common commands of kubectl and the current implementation of karmadactl. And the subcommands are simply divided into modification classes and viewing classes.
modification classes：
| command | kubectl | karmadactl |
|---|---|---|
| annotate | Add or update the annotations of one or more resources. | Not supported yet. Add/update annotations to one or more control plane resources |
| label | Add or update the labels of one or more resources. | Not supported yet. Add/update tags to one or more control plane resources |
| apply | Apply a configuration change to a resource from a file or stdin. | Support. Compared with kubectl, karmadactl transfers modifications to member clusters through propagationpolicy on the control plane. Problem: After propagationpolicy is made static(#4288), apply -f does not take effect immediately. |
| attach | Attach to a running container either to view the output stream or interact with the container (stdin). | Not supported yet. In a multi-cluster scenario, it is necessary to limit the resources that can only be attached to a certain cluster at the same time. |
| autoscale | Automatically scale the set of pods that are managed by a replication controller. | Not supported yet. References: https://karmada.io/docs/tutorials/autoscaling-with-federatedhpa |
| config | Modifies kubeconfig files. See the individual subcommands for details. | Not supported yet. It is necessary to support it. After karmada is installed, the default context is karmada-host, which needs to be set through the kubectl config use-context command. |
| cordon | Mark node as unschedulable. | Mark the cluster as unschedulable. Consider supporting marking nodes. |
| create | Create one or more resources from a file or stdin. | Not supported yet. |
| delete | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. | Not supported yet. |
| edit | Edit and update the definition of one or more resources on the server by using the default editor. | Not supported yet. |
| patch | Update one or more fields of a resource by using the strategic merge patch process. | Not supported yet. |
| run | Run a specified image on the cluster. | Not supported yet. |
| set | Configure application resources. | Not supported yet. |
| taint | Update the taints on one or more nodes. | Currently only clusters are supported. Consider adding scope of use |
| uncordon | Mark node as schedulable. | Currently only clusters are supported. Consider adding scope of use |
viewing classes:
| command | kubectl | karmadactl |
|---|---|---|
| api-resources | List the API resources that are available. | Not supported yet. Consider adding cluster distinction in multi-cluster scenarios |
| cluster-info | Display endpoint information about the master and services in the cluster. | Not supported yet. Consider adding cluster distinction in multi-cluster scenarios |
| describe | Display the detailed state of one or more resources. | Supported, but only in member clusters |
| exec | Execute a command against a container in a pod. | Supported, but only in member clusters |
| explain | Get documentation of various resources. For instance pods, nodes, services, etc. | Not supported yet. |
| get | List one or more resources. | Supported, but only in member clusters |
| logs | Print the logs for a container in a pod. | Supported, but only in member clusters |
| options | List of global command-line options, which apply to all commands. | Supported |
| top | Display resource usage information of node and Pod objects | Supported, but only in member clusters |
Here are the design principles I think karmadactl needs to adhere to:
- Because the behavior of member clusters cannot be fully controlled, it is not recommended that commands directly modify the resources of member clusters, otherwise it will incur high interpretation costs. Commands such as apply, create, and delete should only modify control plane resources. Changes in control plane resources will then lead to changes in member cluster resources.
- View class commands require the ability to view the control plane and member cluster resources. And the viewing scope is configurable
- Support configuring kubeconfig and context
- The operation and display should be as consistent as possible with kubectl
Here are the design principles I think karmadactl needs to adhere to:
- Because the behavior of member clusters cannot be fully controlled, it is not recommended that commands directly modify the resources of member clusters, otherwise it will incur high interpretation costs. Commands such as apply, create, and delete should only modify control plane resources. Changes in control plane resources will then lead to changes in member cluster resources.
Referring to https://github.com/karmada-io/karmada/issues/1568#issuecomment-1109763349, I agreed that it is not recommended to use the karmadactl command to modify resources in member cluster. But we still need introduce these commands to change the status of control plane resources. This principle also blocks the problem that after the Propagation Policy is made static, the command karmadactl apply -f cannot take effect immediately in the member cluster.
For example, without presenting flag
--clusterin the subcommandapplyrepresents no specific cluster, but in the subcommandget podit represents all clusters.
Hi @XiShanYongYe-Chang
Can you please share any ideas to address this inconsistency in the commands? I mean which behavior would be appropriate to implement to make the commands more consistent?
Hi @Affan-7 , Thank you for your positive attitude. Currently, @zhzhuang-zju is leading the design of this feature. We can wait for him to come up with a more detailed plan before we proceed with specific implementation tasks. Now we can provide some of your opinions to help expedite progress on this issue.
You can think from your perspective about what capabilities karmadactl should provide, and you can also refer to some implementations of kubectl.
@zhzhuang-zju
Can I work on the
annotatecommand?
Sure, very welcome~you can open an issue first to describe your design.
cc @hulizhe This is my previous summary of the current implementation of karmadactl, which may be a bit outdated and you can use for reference
What subcommands do we expect to implement in this release (Karmada v1.11) ?
What subcommands do we expect to implement in this release (Karmada v1.11) ?
I've implemented karmadactl top node before, and I think it's time to move forward with it.
cc @hulizhe This is my previous summary of the current implementation of
karmadactl, which may be a bit outdated and you can use for reference
thanks~ I will combine this issue to sort out the current implementation and expected performance of karmadactl.
@zhzhuang-zju: Closing this issue.
In response to this:
/close Progress will be tracked in Enhance karmadactl operation and maintenance experience
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
