如何访问并修改Kubernetes默认调度器代码（无需自定义调度器）

Hey there! Great question—modifying the default Kubernetes scheduler without spinning up a separate custom scheduler is totally feasible, though you’ll need to work with the official Kubernetes source code. Let me break down the process step by step for you:

The default scheduler is a core component of Kubernetes, so start by cloning the official repo and checking out the exact version matching your cluster (critical for compatibility):

git clone https://github.com/kubernetes/kubernetes.git
cd kubernetes
# Replace v1.28.0 with your cluster's Kubernetes version
git checkout v1.28.0

All scheduler-related logic lives in the pkg/scheduler/ directory. Here are the key subdirectories you’ll care about:

• framework/: The modern scheduling framework where most extension logic lives (plugins, extension points, and core scheduling hooks)
• framework/plugins/: Contains all built-in scheduler plugins (node affinity, node port checks, pod priority, etc.—this is where you’ll likely make tweaks)
• algorithm/: Legacy scheduling logic (predicates for filtering nodes, priorities for scoring nodes)
• scheduler.go: The main entry point for the scheduler process

For example, if you want to adjust how the scheduler checks for available node ports, you’d look at framework/plugins/nodeports/nodeports.go. If you need to tweak node affinity rules, head to framework/plugins/nodeaffinity/nodeaffinity.go.

Once you’ve found the code you want to change, make your edits. Keep these tips in mind:

• Follow the existing code style to avoid breaking anything (Kubernetes has strict linting rules, so run make lint if you want to validate)
• If adding new logic, align with the scheduling framework’s extension points to maintain compatibility with other scheduler features
• Test your changes locally using the unit tests in the same directory (look for files ending in _test.go—run make test WHAT=pkg/scheduler/framework/plugins/<plugin-name> to execute them)

After making your changes, compile the scheduler binary from the root of the Kubernetes repo:

# Build only the kube-scheduler binary to save time
make WHAT=cmd/kube-scheduler

Your compiled binary will be at _output/bin/kube-scheduler.

The default scheduler runs as a Pod in the kube-system namespace. You have two main options to replace it:

Option 1: Build a Custom Docker Image (Recommended for Production Clusters) #

Create a simple Dockerfile to package your modified binary:

# Use the official scheduler image as a base (match your cluster version)
FROM k8s.gcr.io/kube-scheduler:v1.28.0
# Copy your custom binary into the image
COPY _output/bin/kube-scheduler /usr/local/bin/kube-scheduler

Build and push the image to your container registry:

docker build -t your-registry/kube-scheduler:custom-v1.28.0 .
docker push your-registry/kube-scheduler:custom-v1.28.0

Then update the kube-scheduler Deployment in kube-system to use your custom image:

kubectl set image deployment/kube-scheduler -n kube-system kube-scheduler=your-registry/kube-scheduler:custom-v1.28.0

Option 2: Replace the Binary Directly (For Test/Single-Node Clusters) #

If you’re working on a test cluster, you can directly replace the scheduler binary on control plane nodes:

1. SSH into your control plane node
2. Back up the original binary: sudo cp /usr/bin/kube-scheduler /usr/bin/kube-scheduler-original
3. Copy your compiled binary to the node (e.g., using scp)
4. Replace the existing binary: sudo cp kube-scheduler /usr/bin/kube-scheduler
5. Restart the scheduler service: sudo systemctl restart kube-scheduler

Deploy a test Pod and check if the scheduling behavior matches your modifications:

• Use kubectl describe pod <test-pod-name> to view scheduling events
• Check the scheduler logs for any errors or custom logic execution: kubectl logs -n kube-system <kube-scheduler-pod-name>

• Version Match: Always use the exact Kubernetes version of your cluster—mismatches will cause unpredictable behavior
• Test First: Validate changes in a non-production cluster before rolling out to production
• Alternative: If your changes are more complex, consider using the scheduling framework’s plugin extension mechanism (you can build external plugins without modifying core scheduler code) instead of altering the default scheduler directly

内容的提问来源于stack exchange，提问作者Deens