48793a48d4
Automatic merge from submit-queue (batch tested with PRs 39093, 34273) start breaking up controller manager into two pieces This PR addresses: https://github.com/kubernetes/features/issues/88 This commit starts breaking the controller manager into two pieces, namely, 1. cloudprovider dependent piece 2. coudprovider agnostic piece the controller manager has the following control loops - - nodeController - volumeController - routeController - serviceController - replicationController - endpointController - resourceQuotaController - namespaceController - deploymentController etc.. among the above controller loops, - nodeController - volumeController - routeController - serviceController are cloud provider dependent. As kubernetes has evolved tremendously, it has become difficult for different cloudproviders (currently 8), to make changes and iterate quickly. Moreover, the cloudproviders are constrained by the kubernetes build/release lifecycle. This commit is the first step in moving towards a kubernetes code base where cloud providers specific code will move out of the core repository, and will be maintained by the cloud providers themselves. I have added a new cloud provider called "external", which signals the controller-manager that cloud provider specific loops are being run by another controller. I have added these changes in such a way that the existing cloud providers are not affected. This change is completely backwards compatible, and does not require any changes to the way kubernetes is run today. Finally, along with the controller-manager, the kubelet also has cloud-provider specific code, and that will be addressed in a different commit/issue. @alena1108 @ibuildthecloud @thockin @dchen1107 **Special notes for your reviewer**: @thockin - Im making this **WIP** PR to ensure that I don't stray too far from everyone's view of how we should make this change. As you can see, only one controller, namely `nodecontroller` can be disabled with the `--cloudprovider=external` flag at the moment. I'm working on cleaning up the `rancher-controller-manger` that I wrote to test this. Secondly, I'd like to use this PR to address cloudprovider specific code in kubelet and api-server. **Kubelet** Kubelet uses provider specific code for node registration and for checking node-status. I thought of two ways to divide the kubelet: - We could start a cloud provider specific kubelet on each host as a part of kubernetes, and this cloud-specific-kubelet does node registration and node-status checks. - Create a kubelet plugin for each provider, which will be started by kubelet as a long running service. This plugin can be packaged as a binary. I'm leaning towards the first option. That way, kubelet does not have to manage another process, and we can offload the process management of the cloud-provider-specific-kubelet to something like systemd. @dchen1107 @thockin what do you think? **Kube-apiserver** Kube-apiserver uses provider specific code for distributing ssh keys to all the nodes of a cluster. Do you have any suggestions about how to address this? **Release note**: ``` release-note ``` |
||
|---|---|---|
| .github | ||
| api | ||
| build | ||
| cluster | ||
| cmd | ||
| docs | ||
| examples | ||
| federation | ||
| Godeps | ||
| hack | ||
| hooks | ||
| logo | ||
| pkg | ||
| plugin | ||
| staging | ||
| test | ||
| third_party | ||
| vendor | ||
| .gazelcfg.json | ||
| .generated_docs | ||
| .generated_files | ||
| .gitattributes | ||
| .gitignore | ||
| BUILD.bazel | ||
| CHANGELOG.md | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| labels.yaml | ||
| LICENSE | ||
| Makefile | ||
| Makefile.generated_files | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| Vagrantfile | ||
| WORKSPACE | ||
Kubernetes
Introduction
Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF)
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.
Are you ...
- Interested in learning more about using Kubernetes?
- See our documentation on kubernetes.io
- Try our interactive tutorial
- Take a free course on Scalable Microservices with Kubernetes.
- Interested in developing the core Kubernetes code base, developing tools using the Kubernetes API or helping in anyway possible ? Keep reading!
Code of Conduct
The Kubernetes community abides by the CNCF code of conduct. Here is an excerpt:
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
Community
Do you want to help "shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented? ". If you are a company, you should consider joining the CNCF. For details about who's involved in CNCF and how Kubernetes plays a role, read the announcement. For general information about our community see the website community page.
Join us on social media (Twitter, Google+) and read our blog
Ask questions and help answer them on Slack or Stack Overflow
Attend our key events (kubecon, cloudnativecon, weekly community meeting)
Join a Special Interest Group (SIG)
Contribute
If you're interested in being a contributor and want to get involved in developing Kubernetes, get started with this reading:
- The community expectations
- The contributor guidelines
- The Kubernetes Developer Guide
You will then most certainly gain a lot from joining a SIG, attending the regular hangouts as well as the community meeting.
If you have an idea for a new feature, see the Kubernetes Features repository for a list of features that are coming in new releases as well as details on how to propose one.
Building Kubernetes for the impatient
If you want to build Kubernetes right away there are two options:
- You have a working Go environment.
$ go get -d k8s.io/kubernetes
$ cd $GOPATH/src/k8s.io/kubernetes
$ make
- You have a working Docker environment.
$ git clone https://github.com/kubernetes/kubernetes
$ cd kubernetes
$ make quick-release
If you are less impatient, head over to the developer's documentation.
Support
While there are many different channels that you can use to get hold of us (Slack, Stack Overflow, Issues, Forums/Mailing lists), you can help make sure that we are efficient in getting you the help that you need.
If you need support, start with the troubleshooting guide and work your way through the process that we've outlined.
That said, if you have questions, reach out to us one way or another. We don't bite!