volcano-scheduler-config

Files (2)

• SKILL.md
• get-scheduler-config.sh · scripts/

SKILL.md (first lines)

# Volcano Scheduler Configuration

View Volcano scheduler configuration to understand scheduling policies, enabled plugins, and actions. This skill helps diagnose configuration-related scheduling behaviors.

**Scope:** This skill is for **diagnosis only**. It retrieves configuration for analysis but does not modify any cluster state.

## Usage

```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh [options]
```

## Parameters

| Parameter | Required | Description |
|-----------|----------|-------------|
| `--section SECTION` | no | Show specific section: actions, plugins, tiers, all (default: all) |
| `--format FORMAT` | no | Output format: yaml, json, summary (default: summary) |
| `--raw` | no | Show raw ConfigMap data without parsing |

## Examples

Get summary of scheduler configuration:
```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh
```

View actions configuration only:
```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh --section actions
```

View plugins configuration:
```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh --section plugins
```

Show full YAML configuration:
```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh --format yaml
```

Get raw ConfigMap:
```bash
bash skills/core/volcano-scheduler-config/scripts/get-scheduler-config.sh --raw
```

## Understanding Scheduler Configuration

### Configuration Location

The Volcano scheduler configuration is stored in:
- **Namespace:** `volcano-system`
- **ConfigMap:** `volcano-scheduler-configmap`
- **Key:** `volcano-scheduler.conf`

### Configuration Structure

```yaml
actions: "enqueue, allocate, backfill"  # Pipeline order
tiers:
- plugins:
  - name: priority
  - name: gang
  - name: conformance
- plugins:
  - name: overcommit
  - name: drf
  - name: predicates
  - name: proportion
  - name: nodeorder
  - name: binpack
```

### Actions

Actions define the **two-phase scheduling pipeline**:
1. **Enqueue phase** — PodGroup is admitted to the queue based on queue capacity (does the queue have enough deserved resources?)
2. **Allocate phase** — Individual pods are placed on nodes based on node resources, affinity, taints, etc.

A job can pass enqueue (PodGroup moves to `Inqueue`) but fail allocation (pods stay `Pending`) if node-level constraints block placement. This two-phase model explains the common scenario: "queue has capacity but pods won't schedule."

Actions in order:

| Action | Required | Purpose |
|--------|----------|---------|
| `enqueue` | Yes | Admit pod groups to queue |
| `allocate` | Yes | Allocate resources to pods |
| `backfill` | No | Fill idle resources with best-effort pods |
| `preempt` | No | Evict low-priority pods for high-priority |
| `reclaim` | No | Reclaim resources from over-allocated queues |
| `elect` | No | Select target workload (removed in v1.6+) |

### Tiers

Tiers divide plugins into priority levels:
- **Tier 1:** First to evaluate, results cannot be overridden
- **Tier 2:** Second to evaluate, lower priority

Common tier organization:
- **Tier 1:** Critical plugins (priority, gang, conformance)
- **Tier 2:** Resource and optimization plugins

### Plugins

#### Critical Plugins

| Plugin | Function | Critical For |
|--------|----------|--------------|
| `gang` | Gang scheduling | Batch jobs, ML training |
| `priority` | Priority sorting | Workload prioritization |
| `conformance` | Protect critical pods | System stability |

#### Resource Plugins

| Plugin | Function | Use Case |
|--------|----------|----------|
| `proportion` | Fair share allocation | Multi-tenant clusters |
| `drf` | Dominant Resource Fairness | Fair GPU/CPU sharing |

From scitix/siclaw, Apache-2.0.

More from scitix/siclaw