-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Establish guidelines for where commands should go #35226
Comments
@kubernetes/kubectl @kubernetes/sig-cli @kubernetes/sig-cluster-lifecycle @kubernetes/sig-cluster-federation @bgrant0607 Spawned by #34484 and previous discussions about where commands should go and who is impacted. I'd like to get opinions here quickly so we can unblock #34484. Since this crosses several sigs we all need to agree so as to be aligned. |
Considerations:
I want to see an ecosystem of tools develop, so I think that fostering a culture of monolithic tools is the wrong direction. We already have kubectl, kompose, helm, kubeadm, minikube, kops, oc, and oadm (for openshift). One could argue that some of those should be merged or killed, but I'd like to see 50 useful tools rather than just 1 or 2, most of which developed outside our github orgs.
To me, it makes more sense to add federation to a tool like kops than to kubeadm. Our current challenge is that both of those tools are pretty new and neither has a clear future. I'd prefer that for entirely new, especially optional areas such as federation start with their own separate tools, and then we can figure out whether/how to merge them with existing tools down the road. As for admin-oriented commands interacting with K8s APIs, such as drain and cordon, I could get behind a command group for those. The command surface is getting large enough that I agree we need to subdivide it in order to improve discoverability. (Commands that could apply to many resource types will continue to belong outside command groups, however.) I'd like to see the implementation of these commands moved out of the main repo. The extension proposal (#30086) isn't strictly necessary to do that, but it or some variant of it might help improve velocity in that area. |
I disagree with the characterization of For example, we have new support coming online for TLS bootstraping. That needs to be broken out as a separable command as it can be used in contexts beyond our "happy path" bootstrap. As for what belongs in the main repo -- what is the criteria there? Should we move cc @kubernetes/sig-cluster-lifecycle |
It looks like this issue also came up in #30237. |
Note that depending on how the design decision goes, we may end up with situations where more that one top-level command offers the same subcommand, unchanged. For example, both In that case, and having in mind that we eventually want to move |
This sounds like a good discussion topic for the @kubernetes/sig-cli meeting next wednesday. @smarterclayton would you like to bring this up, in which case I'd add it to the agenda? |
Re: splitting kubectl and controller managers and kubelet - it's been
discussed briefly as part of the "how do we cleanly transition to
versioned clients". Build infra is probably the challenge but would
also help velocity. We discussed splitting oc out into its own repo
to reduce cost of testing as well on openshift side.
|
sig-cli agenda item sounds good. On Mon, Oct 24, 2016 at 4:40 PM, Brian Grant notifications@github.com
|
And API machinery will be moved out of the main repo #2742, so that anything using it for configuration purposes should be able to use it. |
@fabianofranz @smarterclayton FYI the next SIG CLI meeting is scheduled during kubecon. |
The issue discussing a monolithic binary is somewhat relevant: #16508 |
@bgrant0607 @smarterclayton This needs to be triaged as a release-blocker or not for 1.5 |
Not. |
/sub |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
/remove-lifecycle stale |
/area code-organization |
/remove-kind design
|
/close |
@dims: Closing this issue. In response to this:
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. |
There's been some recent discussion prompted by the addition of
kubeadm
and howkubectl
will evolve w.r.t. which commands belong where.Questions to answer:
kubectl
? Underkubeadm
?kubectl
,kubeadm
, or separate?kubeadm
part of cluster lifecycle, or is it a general "Kubernetes administration command"?kubefed
)?Background
Today, many users of
kubectl
are single cluster admins (one or more devops people who use the whole cluster themselves). However, an increasingly large (and in the future, likely dominant) portion of users will be app-admins using a cluster hosted by someone else. eBay, Samsung, OpenShift customers, etc are all likely examples where a central ops team owns the cluster and then gives access to namespaces and subsets of the cluster for individual teams. The user spectrum of kubectl will range from very sophisticated cluster administrators all the way to individual developers making changes on their cluster who need to see the status of some resources.Points on the user spectrum:
Over time, we will continue to add administrative level functionality to Kube. Some of that functionality has overlap with actions users take (for instance, kubectl get and kubectl apply are used by all classes of user), but some of that is not relevant for unprivileged users, such as
drain
,taint
,cordon
, etc.Deciding which commands go where
Some goals we have had for kubectl:
We have not yet clarified our goals for kubeadm, but today it is focused on people deploying clusters and adding and removing new components. This heavily overlaps with the cluster-admin / single-cluster owner user, but does not overlap with the tenant-user case much.
Some useful experience from OpenShift (which has
oc
which wraps kubectl andoadm
which contains admin stuff, andoc adm
which embedsoadm
underoc
)oadm
command that handles: config generation, certificate signing, policy (specifically cluster level policy), installation, management level tasks like resource migration, and other actions that only cluster admins will have. I believe over time Kube will have all of these, so it's important to clarify that.Design
We should clarify where we add commands and what belongs where. Some possible options and rules:
kubectl
contains everythingkubeadm
is only for installationkubectl
is for generic cluster interaction (app admin level) and for tenant style applications,kubeadm
is for administrative actions on a cluster (install + configuration)kubeadm
is for installation and management of clusters,kubectl adm
is for administrative actions, andkubectl
is for tenant style applicationsFurther clarification for federation:
kubectl register
action, or should it bekubectl federation register
orkubeadm join-federation
?The text was updated successfully, but these errors were encountered: