Revise cloud-controller-manager documentation
This commit is contained in:
@@ -50,26 +50,29 @@ the same machine, and do not run user containers on this machine. See
|
||||
|
||||
These controllers include:
|
||||
|
||||
* Node Controller: Responsible for noticing and responding when nodes go down.
|
||||
* Replication Controller: Responsible for maintaining the correct number of pods for every replication
|
||||
* Node controller: Responsible for noticing and responding when nodes go down.
|
||||
* Replication controller: Responsible for maintaining the correct number of pods for every replication
|
||||
controller object in the system.
|
||||
* Endpoints Controller: Populates the Endpoints object (that is, joins Services & Pods).
|
||||
* Service Account & Token Controllers: Create default accounts and API access tokens for new namespaces.
|
||||
* Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
|
||||
* Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
|
||||
|
||||
### cloud-controller-manager
|
||||
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) runs controllers that interact with the underlying cloud providers. The cloud-controller-manager binary is an alpha feature introduced in Kubernetes release 1.6.
|
||||
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
||||
|
||||
cloud-controller-manager runs cloud-provider-specific controller loops only. 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.
|
||||
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
|
||||
If you are running Kubernetes on your own premises, or in a learning environment inside your
|
||||
own PC, the cluster does not have a cloud controller manager.
|
||||
|
||||
cloud-controller-manager allows the cloud vendor's code and the Kubernetes code to evolve independently 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.
|
||||
As with the kube-controller-manager, the cloud-controller-manager combines several logically
|
||||
independent control loops into a single binary that you run as a single process. You can
|
||||
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
|
||||
|
||||
The following controllers have cloud provider dependencies:
|
||||
The following controllers can have cloud provider dependencies:
|
||||
|
||||
* Node Controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* 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
|
||||
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
||||
* Route controller: For setting up routes in the underlying cloud infrastructure
|
||||
* Service controller: For creating, updating and deleting cloud provider load balancers
|
||||
|
||||
## Node Components
|
||||
|
||||
|
||||
Reference in New Issue
Block a user