🛞 Kubernetes может запускать Pod только на узле с нужным локальным условием
👁 Обычно планировщик Kubernetes смотрит на CPU, память, taint'ы и affinity. Но через nodeAffinity можно привязать Pod к собственным меткам узлов и использовать их как механизм автоматического размещения: например, отправлять тяжёлые задачи только на машины с NVMe, определённым типом сети или специальным системным ПО.
📝 Размечаем узлы под реальные возможности
Вместо жёсткой привязки к имени конкретного сервера добавляем метку, описывающую его возможность. Если узлы изменятся, Pod продолжит работать без изменения манифеста.
kubectl label node worker-01 storage.nvme=true
kubectl label node worker-02 storage.nvme=true
kubectl label node worker-03 storage.nvme=false
📝 Требуем нужную характеристику при планировании
requiredDuringSchedulingIgnoredDuringExecution превращает метку в обязательное условие планирования. Kubernetes не разместит Pod на узле, который ему не соответствует.
apiVersion: v1
kind: Pod
metadata:
name: fast-worker
spec:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: storage.nvme
operator: In
values:
- "true"
containers:
- name: worker
image: my-worker:latest
📝 Добавляем несколько вариантов размещения
Можно описать несколько допустимых условий. Например, Pod может работать либо на узле с NVMe, либо на узле с локальным SSD. Это позволяет сохранить гибкость кластера, не привязывая workload к конкретному железу.
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: storage.nvme
operator: In
values: ["true"]
- matchExpressions:
- key: storage.local
operator: In
values: ["true"]
❗️ Метки узлов можно использовать как слой абстракции над инфраструктурой: Kubernetes работает не с конкретными серверами, а с их возможностями. Это особенно полезно для кластеров с разным железом, GPU, быстрым локальным хранилищем, особой сетью и специализированными worker-узлами.
tags: #k8s #devops #полезно
🧭 @recura_tech 🌐 VK 🌐 MAX
