`, використовуючи структуру KubeSchedulerConfiguration [v1](/docs/reference/config-api/kube-scheduler-config.v1/).
Мінімальна конфігурація виглядає наступним чином:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
```
Примітка:
KubeSchedulerConfiguration v1beta3 є застарілим у v1.26 і видалений у v1.29. Будь ласка, перейдіть на KubeSchedulerConfiguration
v1.
Примітка:
Точка розширення score увімкнена, коли ввімкнена функція StorageCapacityScoring. Вона надає пріоритет найменшим PV, які можуть відповідати запитуваному розміру тому.
- `VolumeRestrictions`: Перевіряє, чи задовольняють томи, змонтовані на вузлі, обмеження, специфічні для постачальника томів. Точки розширення: `filter`.
- `VolumeZone`: Перевіряє, чи задовольняють запитувані томи будь-які вимоги до зони, які вони можуть мати. Точки розширення: `filter`.
- `NodeVolumeLimits`: Перевіряє, чи можуть бути задоволені ліміти томів CSI для вузла. Цей втулок також може запобігти розміщенню подів на вузлі, якщо на ньому не встановлено драйвер CSI, що вимагає увімкнення функції `VolumeLimitScaling`. Він також дозволяє кластерному автомасштабувальнику точно розрахувати кількість вузлів, необхідних для планування очікуючих подів з приєднуваними томами CSI. Точки розширення: `filter`.
- `EBSLimits`: Перевіряє, чи можуть бути задоволені ліміти томів AWS EBS для вузла. Точки розширення: `filter`.
- `GCEPDLimits`: Перевіряє, чи можуть бути задоволені ліміти томів GCP-PD для вузла. Точки розширення: `filter`.
- `AzureDiskLimits`: Перевіряє, чи можуть бути задоволені ліміти томів дисків Azure для вузла. Точки розширення: `filter`.
- `InterPodAffinity`: Реалізує [між-Podʼову спорідненість та антиспорідненість](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity). Точки розширення: `preFilter`, `filter`, `preScore`, `score`.
- `PrioritySort`: Забезпечує стандартне сортування за пріоритетами. Точки розширення: `queueSort`.
- `DefaultBinder`: Забезпечує стандартний механізм привʼязки. Точки розширення: `bind`.
- `DefaultPreemption`: Забезпечує стандартний механізм витіснення. Точки розширення: `postFilter`.
- `TopologyPlacement`: Забезпечує стандартний механізм генерації розміщень для обмежень топології PodGroup. Точки розширення: `placementGenerate`.
- `PodGroupPodsCount`: Забезпечує алгоритм оцінки розміщень на основі кількості Podʼів, які можуть бути заплановані в даному розміщенні. Точки розширення: `placementScore`.
Ви також можете ввімкнути наступні втулки через API конфігурації компонентів, які не увімкнені стандартно:
- `CinderLimits`: Перевіряє, чи можуть бути задоволені ліміти томів [OpenStack Cinder](https://docs.openstack.org/cinder/) для вузла. Точки розширення: `filter`.
### Декілька профілів {#multiple-profiles}
Ви можете налаштувати `kube-scheduler` для роботи з декількома профілями. Кожен профіль має повʼязане імʼя планувальника і може мати різний набір втулків, налаштованих у його [точках розширення](#extension-points).
З наступною зразковою конфігурацією, планувальник буде працювати з двома профілями: один зі стандартними втулками і один з усіма вимкненими втулками скорінгу.
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
- schedulerName: no-scoring-scheduler
plugins:
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
Podʼи, які хочуть бути заплановані відповідно до певного профілю, можуть включати відповідне імʼя планувальника у своїй `.spec.schedulerName`.
Стандартно створюється один профіль з іменем планувальника `default-scheduler`. Цей профіль включає стандартні втулки, описані вище. При оголошенні більше одного профілю для кожного з них потрібно унікальне імʼя планувальника.
Якщо Pod не вказує імʼя планувальника, kube-apiserver встановить його на `default-scheduler`. Таким чином, для планування цих Podʼів повинен існувати профіль з цим імʼям планувальника.
Примітка:
Події планування Podʼа мають .spec.schedulerName як свій reportingController. Події для вибору лідера використовують імʼя планувальника з першого профілю в списку.
Для отримання додаткової інформації, будь ласка, зверніться до розділу reportingController в Довідці API Event.
Примітка:
Усі профілі повинні використовувати той самий втулок у точці розширення queueSort і мати однакові параметри конфігурації (якщо це застосовується). Це повʼязано з тим, що планувальник має лише одну чергу Podʼів в очікуванні.
### Втулки, які застосовуються до декількох точок розширення {#multipoint}
Починаючи з `kubescheduler.config.k8s.io/v1beta3`, у конфігурації профілю є додаткове поле `multiPoint`, яке дозволяє легко увімкнути або вимкнути втулок для кількох точок розширення. Метою конфігурації `multiPoint` є спрощення конфігурації для користувачів і адміністраторів при використанні користувацьких профілів.
Розглянемо втулок `MyPlugin`, який реалізує точки розширення `preScore`, `score`, `preFilter` і `filter`. Щоб увімкнути `MyPlugin` для всіх доступних точок розширення, конфігурація профілю виглядає так:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: MyPlugin
```
Це рівносильно ручному ввімкненню `MyPlugin` для всіх його точок розширення, як показано нижче:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
preScore:
enabled:
- name: MyPlugin
score:
enabled:
- name: MyPlugin
preFilter:
enabled:
- name: MyPlugin
filter:
enabled:
- name: MyPlugin
```
Однією з переваг використання `multiPoint` є те, що якщо `MyPlugin` реалізує іншу точку розширення в майбутньому, конфігурація `multiPoint` автоматично увімкне його для нової точки розширення.
Конкретні точки розширення можна виключити з розширення `MultiPoint` за допомогою поля `disabled` для цієї точки розширення. Це працює з відключенням стандартних втулків, нестандартних втулків або з підстановним знаком (`'*'`) для відключення всіх втулків. Приклад цього, відключення `Score` і `PreScore`, виглядає так:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: non-multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'MyPlugin'
preScore:
disabled:
- name: '*'
score:
disabled:
- name: '*'
```
Починаючи з `kubescheduler.config.k8s.io/v1beta3`, усі [стандартні втулки](#scheduling-plugins) ввімкнені внутрішньо через `MultiPoint`. Однак окремі точки розширення все ще доступні, щоб забезпечити гнучке переналаштування стандартних значень (наприклад, порядок і ваги Score). Наприклад, розглянемо два втулки Score `DefaultScore1` і `DefaultScore2`, кожен з вагою `1`. Їх можна змінити місцями з різними вагами так:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
score:
enabled:
- name: 'DefaultScore2'
weight: 5
```
У цьому прикладі не потрібно явно вказувати втулки в `MultiPoint`, оскільки вони є стандартними втулками. І єдиний втулок, вказаний у `Score`, це `DefaultScore2`. Це тому, що втулки, встановлені через конкретні точки розширення, завжди матимуть пріоритет перед втулками `MultiPoint`. Таким чином, цей фрагмент по суті змінює порядок втулків без необхідності вказувати їх усіх.
Загальна ієрархія для пріоритету при налаштуванні втулків `MultiPoint` є наступною:
1. Специфічні точки розширення працюють першими, і їх налаштування переважатимуть над налаштуваннями, встановленими деінде.
2. Втулки, налаштовані вручну через `MultiPoint`, і їх налаштування.
3. Стандартні втулки та їх стандартні налаштування.
Щоб продемонструвати наведені вище ієрархії, наступний приклад базується на цих втулках:
|Втулок|Точки розширення|
|---|---|
|`DefaultQueueSort`|`QueueSort`|
|`CustomQueueSort`|`QueueSort`|
|`DefaultPlugin1`|`Score`, `Filter`|
|`DefaultPlugin2`|`Score`|
|`CustomPlugin1`|`Score`, `Filter`|
|`CustomPlugin2`|`Score`, `Filter`|
Дійсна конфігурація (для зразка) для цих втулків виглядає так:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
multiPoint:
enabled:
- name: 'CustomQueueSort'
- name: 'CustomPlugin1'
weight: 3
- name: 'CustomPlugin2'
disabled:
- name: 'DefaultQueueSort'
filter:
disabled:
- name: 'DefaultPlugin1'
score:
enabled:
- name: 'DefaultPlugin2'
```
Зверніть увагу, що немає помилки при повторній декларації втулка `MultiPoint` у конкретній точці розширення. Повторна декларація ігнорується (і логується), оскільки конкретні точки розширення мають пріоритет.
Крім збереження більшості конфігурацій в одному місці, цей приклад виконує кілька речей:
- Увімкнено спеціальний втулок `queueSort` і вимкнено стандартний
- Увімкнено `CustomPlugin1` і `CustomPlugin2`, які будуть виконуватися першими для всіх своїх точок розширення
- Вимкнено `DefaultPlugin1`, але тільки для `filter`
- Змінено порядок виконання `DefaultPlugin2` для роботи першої в `score` (навіть перед власними втулками)
У версіях конфігурації до `v1beta3`, без `multiPoint`, наведений вище фрагмент рівнозначний цьому:
```yaml
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: multipoint-scheduler
plugins:
# Вимкнути стандартний втулок QueueSort
queueSort:
enabled:
- name: 'CustomQueueSort'
disabled:
- name: 'DefaultQueueSort'
# Увімкнути спеціальні втулки Filter
filter:
enabled:
- name: 'CustomPlugin1'
- name: 'CustomPlugin2'
- name: 'DefaultPlugin2'
disabled:
- name: 'DefaultPlugin1'
# Увімкнути та змінити порядок спеціальних втулків score
score:
enabled:
- name: 'DefaultPlugin2'
weight: 1
- name: 'DefaultPlugin1'
weight: 3
```
Хоча це складний приклад, він демонструє гнучкість конфігурації `MultiPoint`, а також її безшовну інтеграцію з наявними методами налаштування точок розширення.
## Міграції конфігурації планувальника {#scheduler-configuration-migrations}
-
З версією конфігурації v1beta2 можна використовувати нове розширення для втулка NodeResourcesFit. Нове розширення поєднує функціонал втулків NodeResourcesLeastAllocated, NodeResourcesMostAllocated та RequestedToCapacityRatio. Наприклад, якщо ви раніше використовували втулок NodeResourcesMostAllocated, то тепер ви можете використовувати NodeResourcesFit (стандартно увімкнено) і додати pluginConfig зі scoreStrategy, яка виглядає наступним чином:
apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- pluginConfig:
- args:
scoringStrategy:
resources:
- name: cpu
weight: 1
type: MostAllocated
name: NodeResourcesFit
-
Втулок планувальника NodeLabel застарілий; натомість використовуйте втулок NodeAffinity (стандартно увімкнено), щоб досягти схожої поведінки.
-
Втулок планувальника ServiceAffinity застарілий; натомість використовуйте втулок InterPodAffinity (стандартно увімкнено), щоб досягти схожої поведінки.
-
Втулок планувальника NodePreferAvoidPods застарілий; натомість використовуйте node taints, щоб досягти схожої поведінки.
-
Втулок, увімкнений у конфігураційному файлі v1beta2, має пріоритет над стандартною конфігурацією для цього втулка.
-
Недійсні host або port, налаштовані для адреси привʼязки healthz і метрик планувальника, спричинять невдачу валідації.
- Втулок планувальника
SelectorSpread видалений; натомість використовуйте втулок PodTopologySpread (стандартно увімкнено), щоб досягти схожої поведінки.