whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update components.md

Browse Source
This commit is contained in:
devin-donnelly
2017-03-21 11:49:23 -07:00
committed by GitHub
parent 6e657471d3
commit a5899fc2ff
1 changed files with 9 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/overview/components.md
+9 -13
View File
@@ -56,22 +56,18 @@ These controllers include:
### cloud-controller-manager ### cloud-controller-manager
cloud-controller-manager is a binary that runs controllers which interact with `cloud-controller-manager` is a binary that runs controllers that interact with the underlying cloud providers. The `cloud-controller-manager` binary is an alpha feature introduced in Kubernetes release 1.6.
the underlying cloudproviders. This binary was introduced in kubernetes release 1.6 as a alpha feature. This binary exclusively
runs cloud specific controller loops only. Since this binary runs the cloudprovider specific controllers, these controller loops
need to be turned off in the kube-controller-manager. This can be done by setting the `--cloud-provider` flag to "external" when starting the
kube-controller-manager.
This binary was introduced to allow cloud vendors and kubernetes core to evolve independent of each other. In the current model, kubernetes is `cloud-controller-manager` runs cloud provider-specific controller loops only. As such, you must disable these controller loops in the `kube-controller-manager`. You can disable the controller loops by setting the `--cloud-provider` flag to `external` when starting the kube-controller-manager.
dependent on cloudprovider specific code to function. This code is a part of the core of kubernetes. In the future, cloud vendor specific code
will be maintained by the cloud vendor themselves and linked to the cloud-controller-manager while running kubernetes.
The following controller have cloudprovider dependencies: `cloud-controller-manager` allows cloud vendors and kubernetes core to evolve independent of each other. In prior releases, the core Kubernetes code was dependent upon cloud provider-specific code for functionality. In future releases, code specific to cloud vendors should be maintained by the cloud vendor themselves, and linked to `cloud-controller-manager` while running Kubernetes.
* Node Controller: Responsible for checking cloudprovider to determine if a node has been deleted in the cloud after it stops responding The following controllers have cloud provider dependencies:
* Route Controller: Responsible for setting up routes in the underlying cloud infrastructure
* Service Controller: Responsible for creating, updating and deleting cloudprovider loadbalancers * Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
* Volume Controller: Responsible for creating, attaching, and mounting volumes. These also interact with the cloudprovider * Route Controller: For setting up routes in the underlying cloud infrastructure
* Service Controller: For creating, updating and deleting cloud provider load balancers
* Volume Controller: For creating, attaching, and mounting volumes, and interacting with the cloud provider
to orchestrate volumes to orchestrate volumes
### kube-scheduler ### kube-scheduler