Kubernetes Scheduler in Action 2025: Proven Strategies for How Pods Find Their Perfect Home

Post 6 of 70 in the series “Mastering Kubernetes: A Practical Journey from Beginner to CKA”

🔥 TL;DR

The kube-scheduler is Kubernetes’ intelligent placement engine that decides which node runs each pod
It evaluates resource requirements, node capacity, affinity rules, and constraints to make optimal placement decisions
Custom scheduling policies and multiple schedulers enable advanced workload placement strategies
Understanding scheduler behavior is crucial for optimizing cluster resource utilization and application performance
Scheduler bottlenecks can limit cluster scalability – proper tuning ensures efficient pod placement at scale

Introduction: Kubernetes Scheduler

Picture a master chef in a bustling restaurant kitchen who needs to assign each incoming order to the right cooking station. They consider the complexity of each dish, which stations are busy, what ingredients are available, special dietary requirements, and even which chefs work best together. The kube-scheduler performs this exact orchestration for your Kubernetes cluster – it’s the intelligent traffic controller that ensures every pod lands on the most suitable node.

What we’ll learn today:

How the scheduler evaluates thousands of placement options in milliseconds
Implementing custom scheduling policies for complex workload requirements
Debugging scheduler decisions when pods get stuck in “Pending” state
Building advanced scheduling scenarios with affinity, anti-affinity, and resource constraints

Why this matters: I’ve debugged production incidents where poor scheduling decisions caused cascading failures – like when all database replicas ended up on the same physical host, or when resource-hungry pods starved smaller workloads. Understanding the scheduler isn’t just academic; it’s what separates clusters that barely work from those that perform optimally under pressure. Companies like Spotify and Uber rely on sophisticated scheduling to pack thousands of services efficiently while maintaining performance isolation.

Series context: In our previous post, we explored how the API server validates and processes every cluster request. Now we’re examining the component that watches the API server for newly created pods and makes one of the most critical decisions in Kubernetes – where should this workload run? The scheduler is where resource management theory meets practical reality.

Prerequisites

What you need to know:

Kubernetes cluster architecture and pod lifecycle (covered in Posts #2 and #5)
Basic understanding of CPU and memory resource concepts
Familiarity with labels and selectors
Node management basics

📌 Quick Refresher: The kube-scheduler watches the API server for pods that have no assigned node (nodeName field is empty) and uses a two-phase process – filtering (finding eligible nodes) and scoring (ranking the best options) – to make placement decisions.

Tools required:

Access to a multi-node Kubernetes cluster
kubectl with cluster admin privileges
Ability to create and modify pods, nodes, and scheduler configurations

Previous posts to read:

Post #2: Kubernetes Architecture (essential for understanding scheduler’s role)
Post #5: Kube-APIServer (crucial for understanding how scheduler watches for new pods)

Estimated time: 40-50 minutes including hands-on scheduling experiments

Step-by-Step Tutorial

Theory First: Understanding the Scheduler’s Decision Process

The kube-scheduler isn’t just randomly placing pods – it’s running a sophisticated algorithm that happens in two main phases for every scheduling decision:

Kubernetes Scheduler flow - Kubernetes Scheduler in Action — Kubernetes Scheduler flow – Kubernetes Scheduler in Action

Why does the scheduler use a two-phase approach instead of a single algorithm?

The filtering phase quickly eliminates impossible placements (not enough resources, wrong architecture, policy violations), while the scoring phase ranks remaining options by desirability. This approach scales efficiently even with hundreds of nodes and complex constraints.

Step 1: Exploring Scheduler Components and Configuration

Let’s start by understanding what’s actually running in your cluster:

# Check scheduler pod status and configuration
kubectl get pods -n kube-system | grep scheduler

# Examine scheduler configuration
kubectl describe pod -n kube-system $(kubectl get pods -n kube-system | grep scheduler | awk '{print $1}')

# View scheduler logs to see decision-making in action
kubectl logs -n kube-system $(kubectl get pods -n kube-system | grep scheduler | awk '{print $1}') --tail=50

Analyzing scheduler metrics:

# If metrics are enabled, check scheduling performance
kubectl get --raw /metrics | grep scheduler_scheduling_algorithm_duration_seconds

# Check pending pods (scheduler's work queue)
kubectl get pods --all-namespaces | grep Pending

# Monitor scheduler's decision rate
kubectl get --raw /metrics | grep scheduler_pod_scheduling_attempts

Step 2: Understanding Resource-Based Scheduling

Here’s where scheduling gets practical – let’s see how resource requests and limits affect placement:

Creating resource-aware pods:

# Create a pod with specific resource requirements
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: resource-demo-cpu
  labels:
    app: resource-test
spec:
  containers:
  - name: cpu-intensive
    image: nginx:alpine
    resources:
      requests:
        cpu: "500m"      # Half a CPU core
        memory: "256Mi"  # 256 megabytes
      limits:
        cpu: "1000m"     # One full CPU core
        memory: "512Mi"  # 512 megabytes
EOF

Observing scheduling decisions:

# Watch the pod get scheduled
kubectl get pods -o wide

# Check which node was selected and why
kubectl describe pod resource-demo-cpu

# Look for scheduling events
kubectl get events --sort-by=.metadata.creationTimestamp | grep resource-demo-cpu

Testing resource exhaustion scenarios:

# Create a pod that requires more resources than any single node has
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: impossible-pod
spec:
  containers:
  - name: resource-hog
    image: nginx:alpine
    resources:
      requests:
        cpu: "100"      # 100 CPU cores (likely more than available)
        memory: "1000Gi"  # 1TB of memory
EOF

# This pod should remain in Pending state
kubectl get pod impossible-pod
kubectl describe pod impossible-pod

You’ll see events like: 0/3 nodes are available: 3 Insufficient cpu, 3 Insufficient memory.

Step 3: Node Affinity and Anti-Affinity Scheduling

Now let’s explore how to influence scheduling decisions with affinity rules:

Setting up node labels for affinity:

# Label nodes with different characteristics
kubectl label nodes <node-1> disk-type=ssd
kubectl label nodes <node-2> disk-type=hdd
kubectl label nodes <node-3> zone=us-west-1a

# Verify labels
kubectl get nodes --show-labels

Node affinity examples:

# Create a pod that MUST run on SSD nodes
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: ssd-required-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk-type
            operator: In
            values:
            - ssd
  containers:
  - name: app
    image: nginx:alpine
EOF

# Create a pod that PREFERS SSD but can run elsewhere
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: ssd-preferred-pod
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        preference:
          matchExpressions:
          - key: disk-type
            operator: In
            values:
            - ssd
  containers:
  - name: app
    image: nginx:alpine
EOF

Step 4: Pod Affinity and Anti-Affinity

This is where scheduling gets really sophisticated – placing pods relative to other pods:

Pod co-location (affinity):

# First, create a "database" pod
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: database
  labels:
    app: database
    tier: backend
spec:
  containers:
  - name: db
    image: redis:alpine
EOF

# Now create an app pod that wants to be near the database
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - database
        topologyKey: kubernetes.io/hostname  # Same node
  containers:
  - name: web
    image: nginx:alpine
EOF

Pod anti-affinity (spreading):

# Create multiple replicas that should NOT be on the same node
kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: distributed-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: distributed-app
  template:
    metadata:
      labels:
        app: distributed-app
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - distributed-app
            topologyKey: kubernetes.io/hostname
      containers:
      - name: app
        image: nginx:alpine
EOF

# Check how the replicas are distributed
kubectl get pods -o wide -l app=distributed-app

🧠 Knowledge Check

What happens if a pod has node affinity requirements that no node satisfies?

The pod remains in Pending state until a suitable node becomes available

Can you use both nodeAffinity and podAffinity on the same pod?

Yes, both constraints must be satisfied for successful scheduling, with required nodeAffinity taking precedence over preferred rules

What’s the difference between required and preferred affinity?

Required blocks scheduling if not satisfied; preferred influences scoring but allows scheduling elsewhere

Step 5: Custom Scheduling Policies and Multiple Schedulers

Here’s where advanced users can really customize behavior:

Creating a custom scheduler configuration:

⚠️ CRITICAL: Always test custom scheduler configurations in non-production environments first!

# custom-scheduler-config.yaml (updated to stable API)
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: custom-scheduler
  plugins:
    score:
      enabled:
      - name: NodeResourcesFit
        weight: 50
      - name: NodeAffinity
        weight: 30
      - name: PodTopologySpread
        weight: 20
  pluginConfig:
  - name: NodeResourcesFit
    args:
      scoringStrategy:
        type: LeastAllocated  # Prefer nodes with more available resources

Deploying a custom scheduler:

# Create RBAC for custom scheduler first (security requirement)
kubectl apply -f - << EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: custom-scheduler
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scheduler
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/binding"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-scheduler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scheduler
subjects:
- kind: ServiceAccount
  name: custom-scheduler
  namespace: kube-system
EOF

# Create a custom scheduler deployment
kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-scheduler
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: custom-scheduler
  template:
    metadata:
      labels:
        app: custom-scheduler
    spec:
      serviceAccount: custom-scheduler
      containers:
      - name: kube-scheduler
        image: registry.k8s.io/kube-scheduler:v1.28.0
        command:
        - kube-scheduler
        - --config=/etc/kubernetes/scheduler-config.yaml
        - --v=2
        volumeMounts:
        - name: config
          mountPath: /etc/kubernetes
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
      volumes:
      - name: config
        configMap:
          name: custom-scheduler-config
EOF

Using the custom scheduler:

# Create a pod that uses the custom scheduler
kubectl apply -f - << EOF
apiVersion: v1
kind: Pod
metadata:
  name: custom-scheduled-pod
spec:
  schedulerName: custom-scheduler  # Use our custom scheduler
  containers:
  - name: app
    image: nginx:alpine
EOF

# Verify which scheduler was used
kubectl describe pod custom-scheduled-pod | grep "Scheduled"

Step 6: Troubleshooting Scheduling Issues

Based on my experience debugging scheduling problems, here are the most effective approaches:

Common debugging workflow:

# 1. Check pod status and events
kubectl describe pod <stuck-pod-name>

# 2. Look for specific error messages
kubectl get events --sort-by=.metadata.creationTimestamp | grep <pod-name>

# 3. Check node resources with detailed output
kubectl describe nodes

# Example output showing resource allocation:
# Allocatable:
#   cpu: 3500m
#   memory: 12Gi
#   pods: 110
# Allocated resources:
#   cpu: 2100m (60%)
#   memory: 8Gi (66%)
#   pods: 15 (13%)

# 4. Verify resource requests vs. available capacity
kubectl top nodes
kubectl top pods --all-namespaces

# 5. Check for taints and tolerations issues
kubectl describe nodes | grep -A 5 Taints

Advanced scheduler debugging:

# Enable verbose scheduler logging (safely using deployment edit)
# ⚠️ CRITICAL: Use deployment edit for safer control plane modifications
kubectl edit deployment/kube-scheduler -n kube-system
# Add: --v=4 to see detailed scheduling decisions

# Watch scheduler logs in real-time
kubectl logs -n kube-system <scheduler-pod> -f

# Check scheduler metrics for performance issues
kubectl get --raw /metrics | grep scheduler_scheduling_algorithm_duration_seconds

# Enable scheduler profiling for performance analysis
kubectl proxy &
curl http://localhost:8001/api/v1/namespaces/kube-system/pods/<scheduler-pod>:10251/debug/pprof/scheduler

Verification Steps:

✅ You understand the two-phase scheduling process (filter + score)
✅ You can create pods with resource requirements and affinity rules
✅ You know how to debug scheduling failures
✅ You can implement custom scheduling policies
✅ You understand how to optimize cluster resource utilization

Real-World Scenarios

Scenario 1: E-commerce Platform During Black Friday

The Challenge: Last year, I worked with an e-commerce company preparing for Black Friday traffic. They needed to ensure their shopping cart service could scale rapidly while keeping database replicas distributed for resilience.

Scheduling strategy implemented:

# Shopping cart pods with intelligent placement
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shopping-cart
spec:
  replicas: 20
  template:
    spec:
      affinity:
        # Prefer nodes with SSD storage for performance
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            preference:
              matchExpressions:
              - key: disk-type
                operator: In
                values: ["ssd"]
        
        # Spread across availability zones
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: shopping-cart
            topologyKey: topology.kubernetes.io/zone
          
          # Prefer different nodes within the same zone (lower weight for preference)
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 30
            podAffinityTerm:
              labelSelector:
                matchLabels:
                  app: shopping-cart
              topologyKey: kubernetes.io/hostname
      
      containers:
      - name: cart-service
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Modern topology spread constraints:

# Alternative approach using topology spread constraints
apiVersion: apps/v1
kind: Deployment
metadata:
  name: distributed-service
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: distributed-service
      - maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: distributed-service

Results achieved:

Zero single points of failure during 10x traffic spike
Consistent sub-100ms response times due to SSD preference
Automatic scaling worked smoothly because scheduler could find optimal placement

Scenario 2: Machine Learning Training Workloads

Netflix’s GPU Scheduling Pattern (based on public engineering talks):

# ML training job with GPU requirements
apiVersion: batch/v1
kind: Job
metadata:
  name: model-training
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: accelerator
                operator: In
                values: ["nvidia-tesla-v100"]
              - key: gpu-memory
                operator: Gt
                values: ["16Gi"]
      
      containers:
      - name: training
        resources:
          requests:
            nvidia.com/gpu: 4  # Requires 4 GPUs
            memory: "64Gi"
            cpu: "16"
          limits:
            nvidia.com/gpu: 4
            memory: "128Gi"
            cpu: "32"
      
      # Prevent other workloads from interfering
      tolerations:
      - key: "gpu-exclusive"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

Key scheduling insights from enterprise ML workloads:

Resource isolation: GPU nodes often use taints to prevent non-GPU workloads
Topology awareness: Multi-GPU training prefers nodes with high-bandwidth GPU interconnects
Cost optimization: Use spot instances for training with appropriate tolerations
Priority scheduling: Production inference gets higher priority than training jobs

Common enterprise scheduling mistakes I’ve observed:

Not considering network locality for data-intensive workloads
Over-constraining affinity rules, leading to resource waste
Ignoring topology spread constraints, causing uneven load distribution
Insufficient resource requests, leading to node overcommitment

Troubleshooting Tips

Common Error 1: “0/X nodes are available: insufficient cpu/memory”

Issue: Pod resource requests exceed node capacity Solution:

# Check actual vs requested resources
kubectl describe nodes | grep -A 5 "Allocated resources"

# Find nodes with available capacity
kubectl top nodes

# Adjust pod resource requests or add more nodes
kubectl get pods --all-namespaces -o custom-columns=NAME:.metadata.name,CPU:.spec.containers[*].resources.requests.cpu,MEMORY:.spec.containers[*].resources.requests.memory

Common Error 2: “0/X nodes are available: node(s) had taints that the pod didn’t tolerate”

Issue: Nodes have taints that prevent scheduling Solution:

# Check node taints
kubectl describe nodes | grep -A 3 Taints

# Add appropriate tolerations to pod spec
kubectl patch pod <pod-name> -p '{"spec":{"tolerations":[{"key":"node-role.kubernetes.io/master","operator":"Exists","effect":"NoSchedule"}]}}'

# Or remove taints if appropriate
kubectl taint nodes <node-name> key:effect-

Common Error 3: Pods stuck in Pending with affinity/anti-affinity

Issue: Affinity rules cannot be satisfied Solution:

# Check existing pod distribution
kubectl get pods -o wide --all-namespaces

# Analyze affinity constraints
kubectl describe pod <pending-pod> | grep -A 10 "Node-Selectors\|Affinity"

# Temporarily relax constraints for testing
kubectl get pod <pod-name> -o yaml | sed 's/requiredDuringScheduling/preferredDuringScheduling/g' | kubectl replace -f -

Common Error 4: Scheduler performance issues

Issue: Slow scheduling causing pod startup delays Solution:

# Check scheduler performance metrics
kubectl get --raw /metrics | grep scheduler_scheduling_algorithm_duration_seconds

# Monitor scheduler queue depth
kubectl get --raw /metrics | grep scheduler_pending_pods

# Check for resource contention
kubectl top pod -n kube-system | grep scheduler

# Monitor scheduling attempt metrics
kubectl get --raw /metrics | grep scheduler_scheduling_attempts_total

# Consider scheduler tuning parameters
# --kube-api-qps=100 (increase API throughput)
# --kube-api-burst=200 (handle traffic spikes)

Debug Commands:

# Essential scheduler debugging commands
kubectl get pods --all-namespaces | grep Pending  # Find stuck pods
kubectl describe pod <pod-name> | grep Events     # Check scheduling events
kubectl get nodes --show-labels                   # Verify node labels
kubectl describe nodes | grep -A 5 Allocatable   # Check available resources
kubectl get events --sort-by=.metadata.creationTimestamp | tail -20  # Recent events

# Scheduler performance monitoring
kubectl get --raw /metrics | grep scheduler_scheduling_attempts_total
kubectl get --raw /metrics | grep scheduler_pod_scheduling_duration_seconds
kubectl logs -n kube-system <scheduler-pod> --tail=100  # Scheduler decisions

Where to get help:

Kubernetes Scheduler Documentation
Scheduling Framework Guide
CNCF Slack #kubernetes-scheduling channel

Next Steps

What’s coming next: In Post #7, we’ll explore “Kube-Controller-Manager: Ensuring Desired State.” You’ll discover how controllers watch the scheduler’s decisions and continuously work to maintain your declared intentions. We’ll build on your scheduling knowledge to understand how controllers respond when pods fail, nodes disappear, or configurations change.

Additional learning:

Experiment with scheduler plugin development
Explore advanced topology spread constraints

Practice challenges:

Resource optimization: Design affinity rules that maximize cluster utilization while ensuring application resilience
Custom scheduler: Build a scheduler plugin that considers application-specific metrics (latency, throughput)
Failure simulation: Test how scheduling behaves when nodes fail during different phases of pod lifecycle
Performance testing: Measure scheduling latency with different cluster sizes and constraint complexity
Multi-scheduler setup: Configure multiple schedulers for different workload types (batch, real-time, ML)

Community engagement: Share your scheduling victories and disasters! Have you solved interesting placement challenges with creative affinity rules? What scheduling patterns work best for your workloads? Your real-world experiences help others optimize their clusters more effectively.

FAQ Section

Can I change a pod’s node assignment after it’s been scheduled?

Not directly – pods are immutable once scheduled. You’d need to delete and recreate the pod, or use a deployment to trigger a rolling update that creates new pods with different scheduling constraints.

What happens if the scheduler crashes while pods are running?

Existing pods continue running normally. However, new pods will remain in Pending state until the scheduler is restored, as no component will make placement decisions.

How does the scheduler handle nodes that become unavailable?

The scheduler only places new pods – it doesn’t move existing ones. The controller-manager detects node failures and may recreate pods elsewhere, which then go through the scheduling process again.

Can I run multiple schedulers simultaneously?

Yes! Kubernetes supports multiple schedulers running concurrently. Pods specify which scheduler to use via the schedulerName field. This enables specialized scheduling for different workload types.

Why might a pod be scheduled on a node that doesn’t seem optimal?

The scheduler makes decisions based on the cluster state at scheduling time, resource requests (not actual usage), and multiple scoring factors. What appears suboptimal might reflect constraints you’re not seeing, or the scheduler might be optimizing for different criteria than you expect.

📂 Complete Custom Scheduler Example

# Complete custom scheduler configuration and deployment
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-scheduler-config
  namespace: kube-system
data:
  config.yaml: |
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    profiles:
    - schedulerName: performance-scheduler
      plugins:
        filter:
          enabled:
          - name: NodeResourcesFit
          - name: NodeAffinity
        score:
          enabled:
          - name: NodeResourcesFit
            weight: 60
          - name: NodeAffinity
            weight: 40
      pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: LeastAllocated
            requestedToCapacityRatio:
              shape:
              - utilization: 0
                score: 10
              - utilization: 100
                score: 0
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: performance-scheduler
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: performance-scheduler
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/binding"]
  verbs: ["create"]
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: performance-scheduler
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: performance-scheduler
subjects:
- kind: ServiceAccount
  name: performance-scheduler
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: performance-scheduler
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: performance-scheduler
  template:
    metadata:
      labels:
        app: performance-scheduler
    spec:
      serviceAccountName: performance-scheduler
      containers:
      - name: kube-scheduler
        image: registry.k8s.io/kube-scheduler:v1.28.0
        command:
        - kube-scheduler
        - --config=/etc/kubernetes/config.yaml
        - --v=2
        volumeMounts:
        - name: config
          mountPath: /etc/kubernetes
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi
      volumes:
      - name: config
        configMap:
          name: custom-scheduler-config

</details>

🔗 Series Navigation

Previous: Post #5 – Kube-APIServer: Your Gateway to Kubernetes
Next: Post #7 – Kube-Controller-Manager: Ensuring Desired State
Progress: You’re now 9% through the Kubernetes Fundamentals series! 🎉

💡 Pro Tip: Master the art of reading scheduler events and metrics – they’re your crystal ball for understanding why pods end up where they do. When troubleshooting performance issues, always check if the scheduler made suboptimal placement decisions first.

📧 Never miss an update: Subscribe to get notified when new posts in this series are published. Next, we’re diving into controllers – the components that turn scheduling decisions into reality and keep your applications running!

Tags: kubernetes, kube-scheduler, pod-scheduling, node-affinity, anti-affinity, resource-scheduling, custom-scheduler, cluster-optimization, cka-prep

Meta Description: Master Kubernetes scheduling with hands-on examples of affinity rules, resource constraints, and custom schedulers. Learn pod placement optimization and troubleshooting for production clusters.

Table of Contents