-
Notifications
You must be signed in to change notification settings - Fork 41.5k
Closed
Labels
area/build-releasepriority/awaiting-more-evidenceLowest priority. Possibly useful, but not yet enough support to actually get it done.Lowest priority. Possibly useful, but not yet enough support to actually get it done.sig/cluster-lifecycleCategorizes an issue or PR as relevant to SIG Cluster Lifecycle.Categorizes an issue or PR as relevant to SIG Cluster Lifecycle.
Description
We need to dramatically simplify deploying Kubernetes.
Task list to reduce/eliminate the bash/salt necessary for getting a cluster up and running:
- Provide an 'all-in-one' binary for server components. This was started in Create a standalone k8s binary, capable of running a full cluster #2121 but we should let users specify individual components (i.e. kube-proxy) or a batch of servers (node, master)
- Integrate etcd so that it isn't necessary to download/start separately. Users should be able to easily turn this off and use an existing etcd.
- Integrate flannel so that there is a networking solution that works out of the box. This eliminates the need to statically assign container subnets to nodes.
- Integrate flannel-route-manager so that more advanced configurations (GCE) are supported easily.
- Allow for kubelets to securely nominate themselves to join the cluster
- Lock down kubelet auth via a TLS CA flow.
- Have the kubelet register itself with the apiserver. Update the kubelet with the ability to register itself with the master. #2435 is a start at this.
- Stock policies to auto approve/reject CA signing requests.
- Implement the bootstrap API. (Defined below but should be broken out into a new issue).
- Finish definition of the bootstrap API
- Implement a new binary/mode for serving the bootstrap API
- Host the bootstrap API on k8s.io
- Have the unified binary race to be the master via the bootstrap API. Have it publish it's location.
- Have the minion use the bootstrap API to find the api server and self-register
- Have kubectl use the bootstrap API to find the api server (and CA for the api server).
- Reduce/eliminate command line flags. These don't work well in a clustered environment. Thoughts in Store master and node config in API #1627.
- Have initial config of cluster come from bootstrap API
- Recast add-ons as post-cluster deploy scripts/tools that run on top of kubernetes. Try to eliminate any node configuration that isn't done through the kubernetes API
- Node monitoring
- Cluster monitoring
- Node logging
- DNS
The end result is that we'd love for something like this to work:
Once per cluster start up:
$ kubernetes cluster-create
Creating new cluster via https://k8s.io/
Cluster ID: f95e695d6eac75b7
Admin certificate saved to ~/.k8s/f95e695d6eac75b7/admin.crt
Admin key saved to ~/.k8s/f95e695d6eac75b7/admin.key
Launch kubernetes on multiple machines with:
kubernetes --bootstrap=https://k8s.io/k/f95e695d6eac75b7 --bootstrap-key=041fb4965cd31be8
And then on every node in the cluster:
kubernetes --bootstrap=https://k8s.io/k/f95e695d6eac75b7 --bootstrap-key=041fb4965cd31be8
docker -d $(cat /var/run/kube-docker-flags)
And then from the client, you can use the same URL to auth to the servers as an 'admin' user. It'll use the bootstrap url to get admin keys, certs and such. If you connect to a mode and it isn't the master, it'll return a redirect to who is currently the master. This way updating the bootstrap URL can lag actual master election.
kubectl --bootstrap=https://k8s.io/k/f95e695d6eac75b7 list pods
Metadata
Metadata
Assignees
Labels
area/build-releasepriority/awaiting-more-evidenceLowest priority. Possibly useful, but not yet enough support to actually get it done.Lowest priority. Possibly useful, but not yet enough support to actually get it done.sig/cluster-lifecycleCategorizes an issue or PR as relevant to SIG Cluster Lifecycle.Categorizes an issue or PR as relevant to SIG Cluster Lifecycle.