Re-design 'k2s system ssh' and 'k2s system scp' Commands #787
jgriegershs
started this conversation in
Ideas
Replies: 2 comments
-
Thinking about the copy command, we might need to continue distinguishing between copying to and from, so we might end up with something like:
What do you think? |
Beta Was this translation helpful? Give feedback.
0 replies
-
@jgriegershs Thank you for writing down the proposal. I agree to the proposal with some comments.
Just to be consistent with other tools out there but not a show stopper. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Problems
k2s system ssh
andk2s system scp
are tightly coupled to one control-plane (i.e.kubemaster
) and a worker node inmulti-vm
setup. In the near future, K2s will support multiple worker nodes.k2s system ssh [m|w] [-- <remote-command>]
confuses users.Solution Proposal
Re-design the aforementioned commands to align with the new
k2s node
command group, e.g.:k2s node connect --ip 172.19.1.100
--> this would create an interactive SSH-based session to the control-planek2s node exec --ip 172.19.1.100 -c "echo 'hello'"
--> this would run a batch command on the control-plane using SSH batch execution without interactivityk2s node copy --ip 172.19.1.100 --source "c:\temp\my.file" --target "/tmp/"
--> this would copy to control-plane using SCPTo display K8s node information, a user can run
kgn
which results in outputs like:In future implementations, we could add flags like
-n kubemaster
or-r control-plane
as well to determine the target node.Beta Was this translation helpful? Give feedback.
All reactions