Kubernetes uses Requests and Limits values to determine where and how to execute pods. This presentation pretends to cover these concepts besides Quality of Services classes. It also points to a demo that uses Virtlet to share CPU workload.

1. K8s Resource Allocation
Victor Morales

2. Agenda
• Lifecycle of a Pod
• Request and Limits
• Quality of Service Classes
• Best Effort
• Burstable
• Guaranteed
• Demo – Virtlet VM with Burstable QoS class
• Demo – Virtlet VM with Guaranteed QoS class
• CPU Management Policies

3. Lifecycle of a Pod
Requests are important at schedule time, and limits are important at run time.

4. Requests and Limits
• Request is a critical input to
the scheduler.
• Limit is important to Kubelet
(the daemon on each node that is
responsible for pod health). Exceeding
a memory limit makes your
container process a candidate
for oom-killing. But
Kubernetes does not
terminate pods for exceeding
CPU limits.

5. Quality of Service Classes
Pods that need to stay up and consistently good can request guaranteed
resources, while pods with less exacting requirements can use
resources with less/no guarantee.

6. Best Effort
Pods are dangerous because Kubernetes has no idea where to put
them and when to kill so it’s forced to guess.
https://medium.com/better-programming/the-kubernetes-quality-of-service-conundrum-eebbbb5f89cf

7. Burstable
• Pods are good for cost optimization.
• Reduces the possibility of node CPU starvation.
• If one pod expands out (noisy neighbor) at one time is OK.

8. Guarantee
• Pods are considered top-priority
and are not be killed until they
exceed their limits.
• They remove the possibility of
scaling out into more CPU, but it
reserves the exact amount that
your containers are going to
need.

9. Demo
https://github.com/electrocucaracha/k8s-SuspendResume-demo

10. Demo – Virtlet VM with Burstable QoS class

11. Demo – Virtlet VM with Burstable QoS class
Create Virtlet VM
Create Linux Pod
Destroy Linux Pod
Suspend Virtlet VM
Create Linux Pod

12. Demo – Virtlet VM with Guaranteed QoS class

13. Demo – Virtlet VM with Guaranteed QoS class
Create Virtlet VM
Create Linux Pod
Destroy Virtlet VM

14. Resources
Requests and Limits
• https://www.noqcks.io/notes/2018/02/03/understanding-kubernetes-resources/
• https://mcrthr.com/kubernetes-cpu-limits
• https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-memory-
6b41e9a955f9
• https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-
9eff74d3161b
Quality of Service
• https://medium.com/better-programming/the-kubernetes-quality-of-service-conundrum-
eebbbb5f89cf
• https://www.weave.works/blog/kubernetes-pod-resource-limitations-and-quality-of-service
• https://medium.com/google-cloud/quality-of-service-class-qos-in-kubernetes-bb76a89eb2c6
• https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

15. Backup
CPU Management Policies & CriticalPodAdmissionHandler

16. CPU Management Policies
Enables better placement of sensitive workloads in the Kubelet by
allocating exclusive CPUs to certain pod containers.
• none: Provides no affinity beyond what the OS scheduler does
automatically (CFS quota). Default
• static: Allocates exclusive CPUs to pod containers in the Guaranteed
QoS class with integer CPUs requests.
https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/
https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/

17. CriticalPodAdmissionHandler
IsCriticalPod returns true if the pod bears the critical pod annotation key or if pod's priority
is greater than or equal to SystemCriticalPriority. Both the default scheduler and the
kubelet use this function to make admission and scheduling decisions.
CriticalPodAdmissionHandler is an AdmissionFailureHandler that handles admission failure
for Critical Pods. If the ONLY admission failures are due to insufficient resources, then
CriticalPodAdmissionHandler evicts pods so that the critical pod can be admitted. For
evictions, the CriticalPodAdmissionHandler evicts a set of pods that frees up the required
resource requests. The set of pods is designed to minimize impact, and is prioritized
according to the ordering:
minimal impact for guaranteed pods > minimal impact for burstable pods > minimal impact
for besteffort pods.
minimal impact is defined as follows: fewest pods evicted > fewest total requests of pods.
finding the fewest total requests of pods is considered besteffort.