Kubernetes - Schedule | Annotations
Manual Scheduler :
what happens when you do not have a scheduler in your cluster you probably do not want to rely on the build in scheduler and want to schedule the pods your self
Every pod has a nodeName that by default is not set you don't specify this when you create your pod manifest file. kubernetes adds it automatically.
The scheduler looks for all the Pods that do not have the property set they are the candidates for scheduling.
To manually schedule a Pod you can set this parameter in the pod definition file to manually schedule your pods to a node of your choice -nodeName
you can specify the nodename only during the creation time what if the Pod is already created
What if the Pods are already created
The way it to create a Binding Object and send a post request to the Pods biding API
In Kubernetes, a Binding object is created when a Pod needs to be assigned to a specific node. This object is used by the Kubernetes scheduler to bind a Pod to a particular Node. Here’s a brief overview of when and how this happens:
Pod Creation: When a Pod is created, it is initially in the Pending state. This indicates that the Pod has not yet been scheduled to a node.
Scheduling: The Kubernetes Scheduler is responsible for deciding which node the Pod should be assigned to. It does this based on various factors like resource availability, constraints, and policies.
Binding: Once the Scheduler has decided on a node for the Pod, it creates a Binding object. This object contains the information needed to bind the Pod to the chosen node, such as the Pod’s name and the name of the node.
API Server: The Binding object is then submitted to the Kubernetes API server. The API server updates the Pod's specification to indicate which node it has been bound to.
Pod Assignment: Finally, the Kubernetes control plane ensures that the Pod is scheduled on the specified node, and the Pod transitions from Pending to Running state on that node.
The Binding object is a key part of the scheduling process, ensuring that Pods are allocated to nodes correctly and efficiently.
bind.yml
apiVersion: v1
kind: Binding
metadata:
name: my-pod-binding
namespace: default
labels:
app: my-app
target:
apiVersion: v1
kind: Pod
name: my-pod
namespace: default
resourceVersion: "123456" # This should match the Pod's resource version
uid: d7b89c0e-1d2e-4e2e-9d6f-8a9c9e7a3d4e # This should match the Pod's UID
nodeName: my-node # The node to which you want to bind the Pod
Annotations
Annotations in Kubernetes are key-value pairs used to attach arbitrary metadata to objects. They are often used to store non-identifying information that is useful for tools and libraries interacting with Kubernetes objects, and they can be used by both Kubernetes components and external systems.
Key Points about Annotations
- Non-identifying Information: Unlike labels, which are used for identifying and selecting objects, annotations are meant to store additional, non-identifying data.
- Flexible Size: Annotations can be much larger than labels and can contain more detailed information.
- Read-Only: They are not intended to be used for modifying or querying Kubernetes objects' behavior directly.
Example of Annotations
Here’s an example of how you might use annotations in a Kubernetes Deployment YAML file:
============
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
annotations:
description: "This is a sample deployment"
team: "development"
deployment.kubernetes.io/revision: "1"
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-image:latest
ports:
- containerPort: 80
Comments
Post a Comment