Це багатосторінковий друкований вигляд цього розділу. Натисність щоб друкувати.

Повернутися до звичайного перегляду сторінки.

Адміністрування кластера

Дізнайтеся про поширені завдання адміністрування кластера.

1: Оновлення вузлів Linux
2: Оновлення вузлів Windows
3: Посилення безпеки динамічного виділення ресурсів у вашому кластері

1 - Оновлення вузлів Linux

Ця сторінка пояснює, як оновити робочі вузли Linux, створені за допомогою kubeadm.

Перш ніж ви розпочнете

Вам потрібен доступ до оболонки на всіх вузлах, а інструмент командного рядка kubectl має бути налаштований для звʼязку з вашим кластером. Рекомендується виконувати цей підручник у кластері, що має принаймні два вузли, які не є вузлами панелі управління.

Для перевірки версії введіть kubectl version.

Ознайомтеся з процесом оновлення решти вашого кластера kubeadm. Вам потрібно буде спочатку оновити вузли панелі управління перед оновленням робочих вузлів Linux.

Зміна репозиторію пакунків

Якщо ви використовуєте репозиторії пакунків, що належать спільноті (pkgs.k8s.io), вам потрібно увімкнути репозиторій пакунків для потрібного мінорного релізу Kubernetes. Це пояснено в документі Зміна репозиторію пакунків Kubernetes.

Примітка: Сховища застарілих пакунків (apt.kubernetes.io та yum.kubernetes.io) визнані застарілими та заморожені станом на 13 вересня 2023. Наполегливо рекомендується використання нових репозиторіїв пакунків, розміщених за адресою pkgs.k8s.io, які є обовʼязковими для встановлення версій Kubernetes, випущених після 13 вересня 2023 року. Застарілі репозиторії та їх вміст можуть бути видалені у будь-який момент у майбутньому без попереднього повідомлення. Нові репозиторії пакунків надають можливість завантаження версій Kubernetes, починаючи з v1.24.0.

Оновлення робочих вузлів

Оновлення kubeadm та kubectl

Оновіть kubeadm та kubectl:

Примітка:

kubectl має бути в межах однієї мінорної версії від kube-apiserver згідно з політикою розбіжності версій. Якщо ви оновлюєте панель управління через кілька мінорних версій перед оновленням робочих вузлів, локальний kubectl на вузлі може вийти за межі дозволеної розбіжності. Оновлення kubectl разом з kubeadm тут гарантує, що він залишається в межах підтримуваного діапазону версій протягом усього процесу оновлення вузла.

# замініть x у 1.37.x-* на останню версію патча
sudo apt-mark unhold kubeadm kubectl && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.37.x-*' kubectl='1.37.x-*' && \
sudo apt-mark hold kubeadm kubectl

Для систем з DNF4 (Fedora < 41, RHEL/CentOS < 10):

# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubeadm-'1.37.x-*' kubectl-'1.37.x-*' --disableexcludes=kubernetes

Для систем з DNF5:

# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubeadm-'1.37.x-*' kubectl-'1.37.x-*' --setopt=disable_excludes=kubernetes

Виклик "kubeadm upgrade"

Для робочих вузлів це оновлює локальну конфігурацію kubelet:

sudo kubeadm upgrade node

Виконайте drain вузла

Підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши робочі навантаження:

# виконайте цю команду на вузлі панелі управління
# замініть <node-to-drain> імʼям вузла, для якого ви виконуєте drain
kubectl drain <node-to-drain> --ignore-daemonsets

Оновлення kubelet

Оновіть kubelet:

# замініть x у 1.37.x-* на останню версію патча
sudo apt-mark unhold kubelet && \
sudo apt-get update && sudo apt-get install -y kubelet='1.37.x-*' && \
sudo apt-mark hold kubelet

Для систем з DNF4 (Fedora < 41, RHEL/CentOS < 10):

# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubelet-'1.37.x-*' --disableexcludes=kubernetes

Для систем з DNF5:

# замініть x у 1.37.x-* на останню версію патча
sudo dnf install -y kubelet-'1.37.x-*' --setopt=disable_excludes=kubernetes

Перезапустіть kubelet:

sudo systemctl daemon-reload
sudo systemctl restart kubelet

Виконайте uncordon вузла

Поверніть вузол в роботу, позначивши його як придатний для планування:

# виконайте цю команду на вузлі панелі управління
# замініть <node-to-uncordon> імʼям вашого вузла
kubectl uncordon <node-to-uncordon>

Що далі

Подивіться, як оновити вузли Windows.

2 - Оновлення вузлів Windows

СТАН ФУНКЦІОНАЛУ: Beta since Kubernetes v1.18

Ця сторінка пояснює, як оновити вузол Windows, створений за допомогою kubeadm.

Перш ніж ви розпочнете

Версія вашого Kubernetes сервера має бути не старішою ніж 1.17.

Для перевірки версії введіть kubectl version.

Ознайомтеся з процесом оновлення інших вузлів вашого кластера kubeadm. Вам слід оновити вузли панелі управління перед оновленням вузлів Windows.

Оновлення робочих вузлів

Оновлення kubeadm

З вузла Windows оновіть kubeadm:

# замініть 1.37.0 на вашу бажану версію
curl.exe -Lo <path-to-kubeadm.exe>  "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubeadm.exe"

Виконайте drain вузла

З машини з доступом до API Kubernetes підготуйте вузол до обслуговування, позначивши його як недоступний для планування та виселивши робочі навантаження:
```
# замініть <node-to-drain> імʼям вашого вузла, для якого ви виконуєте drain
kubectl drain <node-to-drain> --ignore-daemonsets
```
Ви повинні побачити подібний вивід:
```
node/ip-172-31-85-18 cordoned
node/ip-172-31-85-18 drained
```

Оновлення конфігурації kubelet

З вузла Windows виконайте таку команду, щоб синхронізувати нову конфігурацію kubelet:
```
kubeadm upgrade node
```

Оновлення kubelet та kube-proxy

З вузла Windows оновіть та перезапустіть kubelet:

stop-service kubelet
curl.exe -Lo <path-to-kubelet.exe> "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubelet.exe"
restart-service kubelet

З вузла Windows оновіть та перезапустіть kube-proxy.

stop-service kube-proxy
curl.exe -Lo <path-to-kube-proxy.exe> "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kube-proxy.exe"
restart-service kube-proxy

Примітка:

Якщо ви запускаєте kube-proxy в контейнері HostProcess всередині Podʼа, а не як службу Windows, ви можете оновити kube-proxy, застосувавши нову версію ваших маніфестів kube-proxy.

Виконайте uncordon вузла

З машини з доступом до API Kubernetes поверніть вузол в роботу, позначивши його як придатний для планування:
```
# замініть <node-to-drain> імʼям вашого вузла
kubectl uncordon <node-to-drain>
```

Що далі

Подивіться, як оновити вузли Linux.

3 - Посилення безпеки динамічного виділення ресурсів у вашому кластері

Ця сторінка показує адміністраторам кластера, як посилити авторизацію для динамічного виділення ресурсів (DRA) з акцентом на доступ з мінімальними привілеями для оновлень статусу ResourceClaim.

Перш ніж ви розпочнете

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
У вашому кластері налаштовано динамічне виділення ресурсів.
Ви можете редагувати ресурси RBAC та перезапускати або розгортати компоненти DRA.

Визначте компоненти DRA, які оновлюють статус

Задокументуйте, які ідентичності (зазвичай ServiceAccount) оновлюють статус ResourceClaim у вашому кластері. Типові компоненти, що записують статус:

kube-scheduler або власний контролер виділення
драйвери DRA, локальні для вузла
багатовузлові контролери статусу DRA

Надання мінімально необхідних дозволів для синтетичних субресурсів

Починаючи з Kubernetes v1.36, оновлення статусу DRA вимагають дозволів на синтетичні субресурси на додаток до resourceclaims/status.

Надання дозволів для планувальника та контролера виділення

Застосуйте роль, яка дозволяє оновлення, повʼязані з привʼязкою:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-binding-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/binding"]
    verbs: ["patch", "update"]

Надання дозволів для драйверів, локальних для вузла

Використовуйте вузлово-орієнтовані дієслова для драйверів, локальних для вузла:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-node-driver-status-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/driver"]
    verbs: ["associated-node:patch", "associated-node:update"]
    resourceNames: ["dra.example.com"]

Надання дозволів для багатовузлового контролера лише за потреби

Використовуйте arbitrary-node:* лише для компонентів, які повинні оновлювати статус з будь-якого вузла:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: dra-multinode-status-updater
rules:
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/status"]
    verbs: ["get", "patch", "update"]
  - apiGroups: ["resource.k8s.io"]
    resources: ["resourceclaims/driver"]
    verbs: ["arbitrary-node:patch", "arbitrary-node:update"]
    resourceNames: ["dra.example.com"]

Привʼязка ролей до конкретних ідентичностей

Створіть обʼєкти ClusterRoleBinding для кожної ідентичності компонента та уникайте спільного використання широкої ролі між не повʼязаними між собою компонентами DRA.

Обмежте правила resourceclaims/driver за допомогою resourceNames, де це можливо, щоб ідентичність могла оновлювати статус лише для конкретного драйвера DRA, яким вона керує.

Перевірка та моніторинг

Перевірте, що кожна ідентичність має лише необхідні дієслова та субресурси.
Підтвердіть, що оновлення статусу DRA працюють після розгортання.
Спостерігайте за подіями аудиту API-сервера щодо відхилених запитів resourceclaims/binding та resourceclaims/driver.