Kubernetes For Beginners : 3

Scheduling — K8s Series

Hello Everyone,

Let’s continue the series of “Kubernetes For Beginners”

This is the third article of the series and I will be covering various concepts related to scheduling in Kubernetes.

Here we take a closer look at the various options available for customizing and configuring the way the scheduler behaves through a set of examples.

Manual Scheduling -

• We look at the different ways of manually scheduling a pod on a node. Every pod has a field called nodeName that, by default, is not set.

• We don’t typically specify this field when we create the pod manifest file. Kubernetes adds it automatically. The scheduler goes through all the pods and looks for those that do not have this property set. Those are the candidates for scheduling.

• It then identifies the right node for the pod by running the scheduling algorithm. Once identified, it schedules the pod on the node by setting the node name property to the name of the node by creating a binding object.

• The nodeName field is set to node-1, which indicates that the pod should be scheduled on a node with the name node-1.

• It’s important to note that using nodeName restricts the scheduling of the pod to the specified node and overrides any other scheduling mechanisms like node affinity or resource constraints.

• If the specified node is unavailable or doesn't exist, the pod will remain unscheduled until the node becomes available or a suitable node is found.

• Also remember if there is no scheduler to monitor and schedule nodes ?The pods continue to be in a pending state.

Labels & Selectors -

Labels and selectors are key concepts in Kubernetes that allow you to organize and categorize objects, such as pods, services, and nodes, and perform targeted operations on them. Labels are key-value pairs attached to Kubernetes objects, while selectors are used to filter and select objects based on their labels. Labels and selectors are a standard method to group things together.

Labels -

• Labels are arbitrary key-value pairs attached to Kubernetes objects to identify and categorize them.

• They are typically used to express metadata about objects, such as their purpose, environment, version, or any other relevant information.

• Labels are defined within the metadata section of an object and can have multiple labels assigned to a single object.

Selectors -

• Selectors are used to filter and select objects based on their labels.

• They define criteria to match labels and identify a set of objects that meet those criteria.

• Selectors are used in various scenarios, such as selecting objects for deployment, scaling, or applying policies.

• There are two types of selectors commonly used in Kubernetes: equality-based (=,==,!=) selectors and set-based (in,notin and exists) selectors.

Taints & Tolerations -

• With taints and tolerations, you can control pod scheduling and enforce certain constraints in your cluster.

• Taints and tolerations are used to control which pods can be scheduled onto specific nodes in a cluster.

• Taints are applied to nodes, marking them as “tainted” with certain restrictions, while tolerations are set on pods, allowing them to tolerate or accept the taints and be scheduled on tainted nodes.

• This mechanism provides a way to influence pod placement and enforce specific constraints.

• We can apply more than one taint to a single node and more than one toleration to a single Pod.

Taints:

• The common taints syntax is: key=value:Effect

• Three different values can be assigned to effect :

1. NoSchedule: If there is at least one un-ignored taint with effect NoSchedule then Kubernetes will not schedule the pod onto that node. Already existing Pods which doesn't tolerate this taint, will not be evicted or deleted from this node. But no more pods will be scheduled on this node unless have matching tolerations. It's a hard constraint.

2. PreferNoSchedule: Kubernetes will try not to schedule the Pod on the node if at least one un-tolerated taint has a PreferNoSchedule effect. But if there is a pod which tolerates one taint, it can be scheduled. It's a soft constraint.

3. NoExecute: If there is at least one un-ignored taint with effect NoExecute then the pod will be evicted from the node (if it is already running on the node), and will not be scheduled onto the node (if it is not yet running on the node). It's a strong constraint.

• To add a taint to a node:

  kubectl taint nodes node-1 key=value:taint-effect

• To remove a taint from a node:

  kubectl taint nodes node-1 key=value:taint-effect-

Tolerations:

• Tolerations are set on pods to indicate that they can tolerate or accept specific taints on nodes.

• A pod can have multiple tolerations defined.

• Tolerations are defined within the pod’s specification.

• Here’s an example of a toleration specified in a pod manifest:

Node Selector -

Node Selector is a simple mechanism that allows you to constrain pod scheduling by selecting nodes based on their labels. It enables you to specify which nodes should be eligible for hosting a particular pod based on the presence of specific labels on the nodes. Kubernetes only schedules the Pod onto nodes that have each of the labels you specify.

• Label the Nodes: We need to label the nodes in our Kubernetes cluster. example: env=production

• Specify Node Selector in Pod Manifest: We can specify the Node Selector using the nodeSelector field. This field defines the labels that must be present on a node for the pod to be scheduled on it.

• Scheduling Behavior: It tries to find nodes that satisfy the Node Selector criteria. If a node matches the Node Selector, the pod is scheduled on that node. If no suitable nodes are found, the pod remains in a pending state until a matching node becomes available.

I am Kunal Shah, AWS Certified Solutions Architect, helping clients to achieve optimal solutions on the Cloud. Cloud Enabler by choice, DevOps Practitioner having 7+ Years of overall experience in the IT industry.

I love to talk about Cloud Technology, DevOps, Digital Transformation, Analytics, Infrastructure, Dev Tools, Operational efficiency, Serverless, Cost Optimization, Cloud Networking & Security.

aws #community #builders #devops #kubernetes #scheduling #labels #nodes #pods #selector #taints #tolerations #eks #infrastructure #webapplication #acloudguy

You can reach out to me @ acloudguy.in