Merge pull request #24415 from sftim/20201007_remove_cluster_management_task
Remove cluster management task
This commit is contained in:
@@ -92,9 +92,8 @@ Controllers that interact with external state find their desired state from
|
||||
the API server, then communicate directly with an external system to bring
|
||||
the current state closer in line.
|
||||
|
||||
(There actually is a controller that horizontally scales the
|
||||
nodes in your cluster. See
|
||||
[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)).
|
||||
(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
|
||||
that horizontally scales the nodes in your cluster.)
|
||||
|
||||
The important point here is that the controller makes some change to bring about
|
||||
your desired state, and then reports current state back to your cluster's API server.
|
||||
|
||||
@@ -338,5 +338,4 @@ for more information.
|
||||
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
|
||||
section of the architecture design document.
|
||||
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
|
||||
|
||||
|
||||
@@ -39,8 +39,6 @@ Before choosing a guide, here are some considerations:
|
||||
|
||||
## Managing a cluster
|
||||
|
||||
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
|
||||
|
||||
* Learn how to [manage nodes](/docs/concepts/architecture/nodes/).
|
||||
|
||||
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
|
||||
|
||||
@@ -321,9 +321,7 @@ Pod may be created that fits on the same Node. In this case, the scheduler will
|
||||
schedule the higher priority Pod instead of the preemptor.
|
||||
|
||||
This is expected behavior: the Pod with the higher priority should take the place
|
||||
of a Pod with a lower priority. Other controller actions, such as
|
||||
[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling),
|
||||
may eventually provide capacity to schedule the pending Pods.
|
||||
of a Pod with a lower priority.
|
||||
|
||||
### Higher priority Pods are preempted before lower priority pods
|
||||
|
||||
|
||||
Reference in New Issue
Block a user