Enhance karmadactl operation and maintenance experience

[zhzhuang-zju]

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.

[liangyuanpeng]

/priority important-longterm

[zhzhuang-zju]

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.

[zhzhuang-zju]

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

[zhzhuang-zju]

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

[zhzhuang-zju]

Here are the design principles I think karmadactl needs to adhere to:

1. 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.
2. View class commands require the ability to view the control plane and member cluster resources. And the viewing scope is configurable
3. Support configuring kubeconfig and context
4. The operation and display should be as consistent as possible with kubectl

[zhzhuang-zju]

Here are the design principles I think karmadactl needs to adhere to:

1. 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 #1568 (comment), 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.

[Affan-7]

Let me give it a try.
/assign

Feel free to collaborate on this issue.

[Affan-7]

For example, without presenting flag --cluster in the subcommand apply represents no specific cluster, but in the subcommand get pod it 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?

[XiShanYongYe-Chang]

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.

[Affan-7]

I think is should wait for the @zhzhuang-zju to propose a design.

[Affan-7]

@zhzhuang-zju

Can I work on the annotate command?

[zhzhuang-zju]

@zhzhuang-zju

Can I work on the annotate command?

Sure, very welcome~you can open an issue first to describe your design.

[zhzhuang-zju]

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

[chaosi-zju]

What subcommands do we expect to implement in this release (Karmada v1.11) ?

[zhzhuang-zju]

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.

[hulizhe]

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]

/close
Progress will be tracked in Enhance karmadactl operation and maintenance experience

[karmada-bot]

@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.