Repository navigation
Dramatically Simplify Kubernetes Cluster Creation (kubeadm umbrella issue). #11
Description
Description
Creating a new Kubernetes cluster is too hard. We need to simplify the number and types of actions to get a production cluster up and running.
Note that this is different from bringing up a development cluster (single node ala monokube or minikube) or automation around cluster creation (https://github.com/kubernetes/community/wiki/Roadmap:-Cluster-Deployment).
If we do this right, the number of manual steps to get a cluster running should be minimal. This will have the added benefit of making other deployment scenarios (dev cluster, cluster automation) simpler and smaller.
As part of this, we should make simplifying assumptions and have opinionated defaults. An example would be embedding etcd and picking an easy to use network technology. Certificates and trust should be established automatically.
Progress Tracker
- Before Alpha
- Design Approval
- Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: Proposal: Dramatically Simplify Kubernetes Cluster Creation kubernetes#30360
- Initial API review (if API). Maybe same PR as design doc. PR-NUMBER
- Any code that changes an API (
/pkg/apis/...) - cc @kubernetes/api
- Any code that changes an API (
- Write (code + tests + docs) then get them merged. kubeadm kubernetes#33262
- Code needs to be disabled by default. Verified by code OWNERS
- Minimal testing
- Minimal docs [WIP] kubeadm and add-on docs website#1265
- cc @kubernetes/docs on docs PR
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
- New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io
- Update release notes
- Design Approval
- Before Beta
- Testing is sufficient for beta
- User docs with tutorials
- Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
- cc @kubernetes/docs on docs PR
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
- Thorough API review
- cc @kubernetes/api
- Before Stable
- docs/proposals/foo.md moved to docs/design/foo.md
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
- Soak, load testing
- detailed user docs and examples
- cc @kubernetes/docs
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
- docs/proposals/foo.md moved to docs/design/foo.md
FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
- Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.
Coding
- Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
- As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos. - When you are done with the code, apply the "code-complete" label.
- When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.
Docs
- Write user docs and get them merged in.
- User docs go into http://github.com/kubernetes/kubernetes.github.io.
- When the feature has user docs, please add a comment mentioning @kubernetes/docs.
- When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.
Activity
jbeda commentedon Jun 22, 2016
Other related efforts/prior art:
[I'll update this comment with new links as they come in]
jbeda commentedon Jun 22, 2016
@mikedanese -- I know this is a lot of what you've been working on. I'd love to get that reflected here and scoped for 1.4. Do you mind shooting some pointers over?
philips commentedon Jun 22, 2016
cc @derekparker @aaronlevy @pbx0 from the CoreOS team working on https://github.com/coreos/bootkube and the self-hosted stuff with @mikedanese to realize a k8s driven creation and update story.
jbeda commentedon Jun 22, 2016
To be extra clear -- I'm proposing that we make this experience part of core kubernetes. The fact that core k8s is a set of things that have to be set up together is a powerful thing but it makes things look very very complex. We should be willing to have a sane set of defaults and embedded solutions built in to the main distribution.
Right now our "manual install" page is incredibly daunting. We should aim to reduce that (at least for a given set of integrated services) to a single screen without the crutch of automation tools that paper over the complexity.
mikedanese commentedon Jun 22, 2016
There is a class of infrastructure (that doesn't currently exist) that would benefit all deployment automations. We should try to enumerate what these items are, give them relative priorities and advocate for them in v1.4 planning. I started to create a list a couple days ago: kubernetes-retired/kube-deploy#123 cc @justinsb @errordeveloper @bgrant0607
pires commentedon Jun 22, 2016
@jbeda kubernetes/kubernetes#5472, kubernetes/kubernetes#16077 and kubernetes/kubernetes#5754 are related to this.
thockin commentedon Jun 22, 2016
Something that crossed my mind with docker 1.12 - built-in kvstoreeans that libnetwork's overlay driver might be viable for us. Having a built-in network mode for Docker installs that works anywhere and doesn't require extra components might be nice.
Might require some work to not assume prefixes per node.
klizhentas commentedon Jun 22, 2016
Just so I understand it better embedded etcd will be optional right? As in production we would want to still deploy etcd separate from the API/Scheduler/Controller
smarterclayton commentedon Jun 22, 2016
Network is the hardest part - you can ignore security and edge cases as long as pods can talk to each other. Leveraging libnetwork seems like a practical choice where possible (or just have a daemonset that drops in your favorite network auto provisioner via CNI). Once the node is started we can run any code.
jbeda commentedon Jun 22, 2016
@klizhentas Yes! The idea is to make small clusters super easy. Folks looking for large clusters will want to manage etcd independently. Users can choose to take on the complexity of breaking everything out but it'll be an advanced move.
jbeda commentedon Jun 22, 2016
@smarterclayton I think we just need to pick something to get going. The easiest zero-config option would be the way to go.
derekwaynecarr commentedon Jun 22, 2016
I think the model we present should not look that different from the
production model. I am a fan of making it easy to launch a Kubelet that
then has a static manifest with sensible defaults to launch control plane
that is not hidden in a mess of salt. On that model, etcd can still be a
pod as well as other parts of our control plane.
On Wednesday, June 22, 2016, Joe Beda notifications@github.com wrote:
klizhentas commentedon Jun 22, 2016
@jbeda so in the simple case
kube-controller-manager,kube-apiserver,kubelet+etcdwill be one go binary?jbeda commentedon Jun 22, 2016
@klizhentas @derekwaynecarr I don't know what the binaries will be that we ship. I do know that we have to make it dead easy to download a thing and get it up and running. If we can get stuff self hosted on the cluster in a container, that would be a good solution. The number of steps needs to be reduced to ~1 per node.
Let's start with the ideal set of things we want the end user to type. From there we can figure how to get there in a sustainable way (and with the opportunity to do everything in a more explicit way for advanced users).
derekwaynecarr commentedon Jun 22, 2016
I think we can demonstrate the composable nature of the platform without
having to build monolithic binaries that are contrary to the spirit of
microservice architecture.
There are two separate but related topics: ability to create a node (and
bring up control plane), ability to have a new node join an existing
cluster easily. I worry moving to monolithic binaries don't necessarily
help either cause.
I also think if we want to advocate being agnostic about a particular
container runtime, the setup process should follow suite. This is why I
like @mikedanese ideas in the space since they start with the Kubelet
(which could work with any container runtime it's pointed against) rather
than starting with a particular container runtime launching the Kubelet.
On Wednesday, June 22, 2016, Alexander Klizhentas notifications@github.com
wrote:
126 remaining items
neolit123 commentedon Dec 3, 2018
our docs and all our items for 1.13 are in place.
this tracking issue can finally be closed.
kubeadm is now GA. ð
/close
k8s-ci-robot commentedon Dec 3, 2018
@neolit123: Closing this issue.
Details
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/test-infra repository.
Merge pull request kubernetes#11 from enxebre/machine-instance-lifecycle
Merge pull request kubernetes#11 from abhiraut/minor-updates
Merge pull request kubernetes#11 from siyuanfoundation/compat-versions
Merge pull request kubernetes#11 from mshitrit/update-credentials-plaâĶ
Vendor github.com/square/go-jose@789a4c4bd4c118f7564954f441b29c153ccdâĶ
Merge pull request kubernetes#32190 from errordeveloper/vendor-go-jose
Merge pull request kubernetes#33262 from errordeveloper/kubeadm
Merge pull request kubernetes#42246 from jamiehannaford/add-etcd-flagâĶ