Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
plugin: Rewrite to get state from Pod annotations
a.k.a. "Stateless Scheduler". This is effectively a full rewrite of the scheduler plugin. At a high level, the existing external interfaces are preserved: - The scheduler plugin still exposes an HTTP server for the autoscaler-agent (for now); and - The scheduler plugin is still a plugin. However, instead of storing the state for approved resources in-memory, in the scheduler plugin, we now treat annotations on the Pod as the source of truth for requested/approved resources. A brief overview of the internal changes to make this happen: 1. The state of resource reservations can be constructed entirely from Node and Pod objects. We *do* store that, and update as objects change, but it's only for convenience and not a strict requirement. One tricky piece is with scheduling. For that, we store a set of pods that have gone through the plugin methods but haven't actually had the spec.nodeName field set. For more info, the 'pkg/plugin/state' package contains all the pure logic for manipulating resources. 2. Each watch event on Node/Pod objects is now placed into a "reconcile" queue similar to the controller framework. Reconcile operations are a tuple of (object, event type, desired reconcile time) and are retried with backoff on error/panic. For a detailed look, the 'pkg/plugin/reconcile' package defines the reconcile queue and all its related machinery. 3. The handler for autoscaler-agent requests no longer accesses the internal state and instead directly patches the VirtualMachine object to set the annotation for requested resources, and then waits for that object to be updated. Once the autoscaler-agent is converted to read and write those annotations directly, we will remove the HTTP server. 4. 'pkg/util/watch' was changed to allow asking to be notified when there's changes to an object, via the new (*Store[T]).Listen() API. This was required to implement (3), and can be removed once (3) is no longer needed, if it doesn't become used in the autoscaler-agent. 5. 'pkg/util/watch' was changed to allow triggering no-op update events, which - for our usage - will trigger requeuing the object. This solves two problems: a. During initial startup, we need to defer resource approval until all Pods on the Node have been processed -- otherwise, we may end up unintentionally overcommitting resources based on partial information. So during startup, we track the set of Pods with deferred approvals, and then requeue them all once startup is over by triggering no-op update events in the watch store. b. Whenever we handle changes for some Pod, it's worthwhile to handle certain operations on the Node -- e.g., triggering live migration if the reserved resources are too high. While we *could* do this as part of the Pod reconciling, we get more fair behavior (and, better balancing under load) by instead triggering re-reconciling the Pod's Node. Why can't this be done elsewhere? In short, consistency. Fundamentally we need to use a consistent view of the object that we're reconciling (else, it might not be no-op), and the source of truth for the current value of an object *within the scheduler plugin* is the watch store.
- Loading branch information