Resource Managment Flashcards
What does the K8s Scheduler do?
The Kubernetes scheduler is one of the main components that is hosted in the control plane. The scheduler allows Kubernetes to make placement decisions for pods deployed to the cluster. It deals with optimization of resources based on constraints of the cluster as well as user-specified constraints. It uses a scoring algorithm that is based on predicates and priorities.
What are predicates in the K8s Scheduler?
The first function Kubernetes uses to make a scheduling decision is the predicate function, which determines what nodes the pods can be scheduled on. It implies a hard constraint, so it returns a value of true or false. An example would be when a pod requests 4 GB of memory and a node cannot satisfy this requirement.
What are priorities in the K8s scheduler?
Whereas predicates indicate a true or false value and dismiss a node for scheduling, the priority value ranks all of the valid nodes based on a relative value.
The scores will be added, and then a node is given its final score to indicate its priority.
If nodes are returned with the same priority, the scheduler will use a selectHost() function, which selects a node in a round-robin fashion.
What are advanced scheduling techniques in K8s?
For most cases, Kubernetes does a good job of optimally scheduling pods for you. It takes into account pods that are placed only on nodes that have sufficient resources. It also tries to spread pods from the same ReplicaSet across nodes to increase availabilty and will balance resource utilization. When this is not good enough, Kubernetes gives you the flexibility to influence how resources are scheduled.
Techniques are:
- Pod Affinity
- Node Selector
- Taints and Tolerations
How does Pod Affinity work?
Pod affinity and anti-affinity let you set rules to place pods relative to other pods. These rules allow you to modify the scheduling behavior and override the scheduler’s placement decisions.
For example, an anti-affinity rule would allow you to spread pods from a ReplicaSet across multiple datacenter zones. It does this by utilizing keylabels set on the pods. Setting the key/value pairs instructs the scheduler to schedule the pods on the same node (affinity) or prevent the pods from scheduling on the same nodes (anti-affinity).
How does Node Selector work?
A nodeSelector is the easiest way to schedule pods to a particular node. It uses label selectors with key/value pairs to make the scheduling decision. For example, you might want to schedule pods to a specific node that has specialized hardware, such as a GPU.
How do taints and tolerations work?
Taints are used on nodes to repel pods from being scheduled on them. But isn’t that what anti-affinity is for? Yes, but taints take a different approach than pod anti-affinity and serve a different use case. For example, you might have pods that require a specific performance profile, and you do not want to schedule any other pods to the specific node. Taints work in conjunction with tolerations, which allow you to over‐ride tainted nodes. The combination of the two gives you fine-grained control over anti-affinity rules.
There are multiple taint types that affect scheduling and running containers:
- NoSchedule
A hard taint that prevents scheduling on the node - PreferNoSchedule
Schedules only if pods cannot be scheduled on other nodes - NoExecute
Evicts already-running pods on the node - NodeCondition
Taints a node if it meets a specific condition
What is Pod Resource Management and why is it important?
Managing pod resources consists of managing CPU
and memory to optimize the overall utilization of your Kubernetes cluster. You can manage these resources at the container level and at the namespace level.
There are other resources, such as network and storage, but Kubernetes doesn’t yet have a way to set requests and limits for those resources.
For the scheduler to optimize resources and make intelligent placement decisions, it needs to understand the requirements of an application. As an example, if a container (application) needs a minimum of 2 GB to perform, we need to define this in our pod specification, so the scheduler knows that the container requires 2 GB of memory on the host to which it schedules the container.
What is a Resource Request?
A Kubernetes resource request defines that a container requires X amount of CPU or memory to be scheduled.
apiVersion: v1
kind: Pod
metadata:
name: memory-request
spec:
containers:
- name: memory-request
image: polinux/stress
resources:
requests:
memory: “8000Mi”
What are Resource Limits?
Kubernetes resource limits define the maximum CPU or memory that a pod is given. When you specify limits for CPU and memory, each takes a different action when it reaches the specified limit. With CPU limits, the container is throttled from using more than its specified limit. With memory limits, the pod is restarted if it reaches its limit. The pod might be restarted on the same host or a different host within the cluster.
What is the Quality of Service (QoS) of a pod?
When a pod is created, it’s assigned one of the following Quality of Service (QoS) classes:
* Guaranteed
* Burstable
* Best effort
The pod is assigned a QoS of guaranteed when CPU and memory both have request and limits that match. A burstable QoS is when the limits are set higher than the request, meaning that the container is guaranteed its request, but it can also burst to the limit set for the container. A pod is assigned best effort when no request or limits are set for the containers in the pod.
What are PodDisruptionBudgets ?
At some point in time, Kubernetes might need to evict pods from a host. There are two types of evictions: voluntary and involuntary disruptions. Involuntary disruptions can be caused by hardware failure, network partitions, kernel panics, or a node being out of resources.
Voluntary evictions can be caused by performing maintenance on the cluster, the Cluster Autoscaler deallocating nodes, or updating pod templates. To minimize the impact to your application, you can set a PodDisruptionBudget to ensure uptime of the application when pods need to be evicted.
A PodDisruption Budget allows you to set a policy on the minimum available and maximum unavailable pods during voluntary eviction events.
For example, you might specify that no more than 20% of pods belonging to your application can be down at a given time. You could also specify this policy in terms of X number of replicas that must always be available.
What namespaces are created by default in K8s?
Namespaces in Kubernetes give you a nice logical separation of resources deployed to a cluster. This allows you to set resource quotas per namespace, Role-Based Access Control (RBAC) per namespace, and also network policies per namespace.
kube-system
Kubernetes internal components are deployed here, such as coredns, kube- proxy, and metrics-server.
default
This is the default namespace that is used when you don’t specify a namespace in the resource object.
kube-public
Used for anonymous and unauthenticated content, and reserved for system usage.
You’ll want to avoid using the default namespace because it can make it really easy to
make mistakes when managing resources within your cluster.
What is a LimitRange?
We’ve discussed setting request and limits at the container level, but what happens if the user forgets to set these in the pod specification? Kubernetes provides an admission controller that allows you to automatically set these when there are none indicated in the specification.
Apply a LimitRange to the namespace to apply defaultRequest in limits:
apiVersion: v1
kind: LimitRange
metadata:
name: team-1-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: Container
How do you scale an application in K8s?
Kubernetes provides multiple ways to scale applications in your cluster. You can scale an application by manually changing the number of replicas within a deployment.
You can also change the ReplicaSet or replication controller, but we don’t recommend managing your applications through those implementations.
Manual scaling is perfectly fine for workloads that are static or when you know the times that the workload spikes, but for workloads that experience sudden spikes or workloads that are not static, manual scaling is not ideal for the application. Happily, Kubernetes also provides a Horizontal Pod Autoscaler (HPA) to automatically scale workloads for you.
