Scheduling

Section Introduction

In this section, we will examine various concepts related to scheduling in Kubernetes. We saw how to install and configure a scheduler briefly in the previous section.

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

Some of the topics we will cover: We will start with manual Scheduling and see how you can schedule a pod manually. We then look at Daemon Sets, Labels and Selectors, how resource requests and limits play a role in scheduling.

We also see how to configure multiple schedulers and how to view the scheduler events.

Well let's get started.

Manual Scheduling

Hello and welcome to this lecture. In this lecture we look at the different ways of manually scheduling a POD on a node. What do you do when you do not have a scheduler in your cluster?

You, probably do not want to rely on the built in scheduler and instead want to schedule the PODs yourself.

So how exactly does a scheduler work in the backend.

Let's start with a simple pod definition file.

Every POD has a field called NodeName that, by default, is not set.

You don’t typically specify this field when you create the manifest file, Kubernetes adds it automtically.

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. So if there is no scheduler to monitor and schedule nodes what happens?

The pods continue to be in a pending state.

So what can you do about it?

You can manually assign pods to node yourself. Well without a scheduler, the easiest way to schedule a pod is to simply set the node name field to the name of the node in your pod specification while creating the POD.

The pod then gets assigned to the specified node. You can only specify the node name at creation time.

What if the pod is already created and you want to assign the pod to a node? Kubernetes won’t allow

you to modify the node Name property of a pod.

So another way to assign a note to an existing pod is to create a binding object and send a post request

to the pod binding API thus mimicking what the actual scheduler does. In the binding object you specify

a target node with the name of the node. Then send a post request to the pods binding API with the data

set to the binding object in a JSON format.

So you must convert the YAML file into its equivalent JSON format.

Well that's it for this lecture.

Head over to the practice test and practice manually scheduling pods on nodes.

Labels and Selectors

What do we know about labels and selectors already? Labels and selectors are a standard method to group things together.

Say you have a set of different species.

A user wants to be able to filter them based on different criteria such as based on their class or kind, if they are domestic or wild, or see by their color and not just group.

You want to be able to filter them based on a criteria such as all green animals or with multiple criteria such as everything green that is also a bird.

Whatever that classification may be, you need the ability to group things together and filter them based on your needs and the best way to do that is with labels. Labels or properties attached to each item.

So you add properties to each item for their class kind, and color selectors help you filter these items.

For example, when you say class equals mammal we get a list of mammals and when you say color equals green we get the green mammals.

Other Applications

We see labels and selectors used everywhere such as the keywords you tag to YouTube videos or blogs that help users filter and find the right content. We see labels added to items in an online store that help you add different kinds of filters to view your products.

So how are labels and selectors used in Kubernetes?

We have created a lot of different types of Objects in Kuberentes. Pods, Services, ReplicaSets and Deployments etc. For Kubernetes, all of these are different objects.

Over time you may end up having hundreds or thousands of these objects in your cluster.

Then you will need a way to filter and view different objects by different categories such as to group objects by their type, application or by their functionality whatever it may be.

You can group and select objects using labels and selectors for each object attach labels as per your needs, like app, function etc.

Then while selecting specify a condition to filter specific objects.

For example app == App1. So how exactly do you specify labels in kubernetes?

In a pod-definition file, under metadata, create a section called labels. Under that add the labels in a key value format like this.

pod-definition.yaml

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp
  labels:
    app: App1
    function: Front-end

spec:
  containers:
    - name: simple-webapp
      image: simple-webapp
      ports:
        - containerPort: 8080

You can add as many labels as you like.

Once the pod is created, to select the pod with the labels use the kubectl get pods command along with the selector option, and specify the condition like app=App1.

kubectl get pods --selector app=App1

Now this is one use case of labels and selectors. Kubernetes objects use labels and selectors internally to connect different objects together. For example to create a replicaset consisting of 3 different pods, we first label the pod definition and use selector in a replicaset to group the pods. In the replica-set set definition file. You will see labels defined in two places.

Note that this is an area where beginners attempt to make a mistake.

The labels defined under the template section are the labels configured on the pods. The labels you see

at the top are the labels of the replicas set itself.

replicaset-definition.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: simple-webapp
  labels:
    app: App1
    function: Front-end

spec:
  replicas: 3
  selector:
    matchLabels:
      app: App1
  template:
    metadata:
      labels:
        app: App1
        function: Front-end
    spec:
      containers:
        - name: simple-webapp
          image: simple-webapp

We're not really concerned about the labels of the replica set for now because we are trying to get the replica set to discover the pods.

The labels on the replica set will be used if you were to configure some other object to discover the replica set in order to connect the replica set to the pod we configure the selector field under the replica set specification to match the labels defined on the pod a single label will do if it matches correctly.

However if you feel there could be other pods with the same label but with a different function then you could specify both the labels to ensure that the right pods are discovered by the replica set on creation.

If the labels match, the replica set is created successfully. It works the same for other objects like a service when a service is created it uses the selector defined in the service definition file to match the labels set on the pods in the replica set definition file.

service-definition.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: App1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Finally let’s look at annotations. While labels and selectors are used to group and select objects, annotations are used to record other details for informatory purposes.

For example, tool details like name, version, build information etc. or contact details, phone numbers, email ids etc, that may be used for some kind of integration purpose.