You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
A simple example: Say the cluster autoscaler (https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler …) added a new node for new pods. If those pods were due to creation of a new Deployment or ReplicaSet, they could all land on the new node if there weren't enough space on existing nodes
From the experience in Borg, we knew the descheduler would be needed from the beginning of the Kubernetes project. I think it was first mentioned when discussing the addition of liveness and readiness probes:https://github.com/kubernetes/kubernetes/issues/620#issuecomment-50110653 …
This enabled us to establish a clear separation of concerns between pod creation and replacement by workload controllers, horizontal scaling by HPA, placement by the scheduler, and rebalancing across nodes and failure domains by the descheduler, which would respect PDB
That division was discussed when designing eviction for unresponsive nodes (https://github.com/kubernetes/kubernetes/issues/3885#issuecomment-71984989 …) and then in http://issues.k8s.io/12140 . The design docs can be found at https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md … and https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md …
Note that if churn in the cluster is sufficiently high and eviction is highly constrained due to PodDisruptionBudgets, it may not be possible for the descheduler to keep up. This is one reason why it may not be possible to achieve an "optimal" layout
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
