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
Borg used an explicit attribute to indicate this, called appclass, which is described by the Borg paper: https://ai.google/research/pubs/pub43438 …. This was translated to scheduling latency in LMCTFY: https://github.com/google/lmctfy/blob/master/include/lmctfy.proto#L142 …. In Kubernetes, it's inferred from resource requests and limits
In order to reallocate incompressible resources quickly, threads need to be killed, which is obviously not low impact. (For memory, in Linux this is done by the OOM killer.) This was why Borg used priority (production priority vs not) to make memory oversubscription decisions
Borg's resource reclamation approach is described by the paper: reservations based on observed usage were computed and oversubscribed resources (latency-tolerant cpu and non-production memory) were tallied against reservations whereas guaranteed ones used limits. Complicated.
Vertical autoscaling (VA) added even more complexity. VA changed limits, but left its own padding to provide slack for reaction time and observation of demand. Ad hoc mechanisms were added to disable limit enforcement for each resource, creating a notion similar to request in K8s
In K8s, I wanted something simpler, to directly convey the desire for oversubscription and bursting flexibility. The discussion started way back in http://issues.k8s.io/147 and http://issues.k8s.io/168 . The model we settled on was determined by looking at limits and requests
Request==Limit implies guaranteed resources (not oversubscribed). Request<Limit implies burstable (oversubscribed). Zero request implies best effort. Borg scheduled best effort using reservation, but no throughput guarantees could be made in practice
This is described in the resource model design (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/resources.md …) and the QoS proposal (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md …), including the mapping to OOM scores. The mapping to cgroup cpu shares is described in the pod resource design (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/pod-resource-management.md …).
Some work on Vertical Pod Autoscaling for Kubernetes has started: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/vertical-pod-autoscaler.md …. There have been proposals to implement oversubscription also (https://github.com/kubernetes/enhancements/issues/355 …). As for horizontal scaling, resource monitoring infrastructure is a prerequisite
If managing cluster-level sharing using ResourceQuota and LimitRange, oversubscription can be done at that level also. The original designs were described by https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/admission_control_limit_range.md … and https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/admission_control_resource_quota.md …, with improvements in https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/resource-quota-scoping.md …
Ok, this topic doesn't fit into a Twitter form factor very well. Maybe some day I'll get around to writing this up more in long form. For now, that's about all I have time for, but questions are welcome
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
