Вказання бюджету розладів для вашого застосунку

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

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

• Ви є власником застосунку, який працює на кластері Kubernetes і вимагає високої доступності.
• Вам слід знати, як розгорнути репліковані застосунки без збереження стану та/або репліковані застосунки зі збереженням стану.
• Ви повинні прочитати про розлади Podʼів.
• Ви повинні підтвердити з власником кластера або постачальником послуг, що вони дотримуються Бюджетів розладів Podʼів.

Захист застосунку за допомогою PodDisruptionBudget

1. Визначте, який застосунок ви хочете захистити за допомогою PodDisruptionBudget (PDB).
2. Подумайте про те, як ваш застосунок реагує на розлади.
3. Створіть визначення PDB у вигляді файлу YAML.
4. Створіть обʼєкт PDB з файлу YAML.

Визначення застосунку для захисту

Найбільш поширене використання полягає в захисті застосунку, який визначено одним із вбудованих контролерів Kubernetes:

• Deployment (Розгортання)
• ReplicationController (Контролер Реплікації)
• ReplicaSet (Набір Реплік)
• StatefulSet (Набір зі Станом)

У цьому випадку обовʼязково відзначте .spec.selector контролера; той самий селектор використовується в .spec.selector PDBs.

Починаючи з версії 1.15, PDB підтримують власні контролери, де включено підресурс масштабування.

Також можна використовувати PDB зі сторонніми Podʼами, які не контролюються одним із вищевказаних контролерів, або з довільними групами Podʼів, але є деякі обмеження, описані у Довільні робочі навантаження та довільні селектори.

Подумайте про реакцію вашого застосунку на відключення

Вирішіть, скільки екземплярів може бути вимкнено одночасно на короткий період часу через добровільні відключення.

• Фронтенди без збереження стану:
  • Застереження: не зменшуйте потужність обслуговування більш ніж на 10%.
    • Рішення: використовуйте PDB з minAvailable 90%, наприклад.
• Одноекземплярний застосунок зі збереженням стану:
  • Застереження: не закривайте цей застосунок без спілкування зі мною.
    • Можливе рішення 1: Не використовуйте PDB і терпіть випадковий простій.
    • Можливе рішення 2: Встановіть PDB з maxUnavailable=0. Маючи розуміння (поза Kubernetes), що оператор кластера повинен зв'язатися з вами перед закриттям. Коли оператор кластера звертається до вас, готуйтеся до простою, а потім видаліть PDB, щоб показати готовність до відключення. Після цього створіть новий.
• Багатоекземплярний застосунок зі збереженням стану, такий як Consul, ZooKeeper або etcd:
  • Застереження: не зменшуйте кількість екземплярів нижче кворуму, в іншому випадку записи будуть невдалі.
    • Можливе рішення 1: встановіть maxUnavailable на рівень 1 (працює з різними масштабами застосунку).
    • Можливе рішення 2: встановіть minAvailable рівним розміру кворуму (наприклад, 3 при масштабуванні 5). (Дозволяє більше відключень одночасно).
• Пакетне завдання (Job) з перезапуском:
  • Застереження: завдання повинно завершитися у разі добровільного відключення.
    • Можливе рішення: Не створюйте PDB. Контролер завдань створить Pod на заміну.

Логіка округлення при вказанні відсотків

Значення для minAvailable або maxUnavailable можуть бути виражені як цілі числа або як відсотки.

• Коли ви вказуєте ціле число, воно представляє кількість Podʼів. Наприклад, якщо ви встановите minAvailable на 10, то завжди повинно бути доступно 10 Podʼів, навіть під час відключення.
• Коли ви вказуєте відсоток, встановивши значення як рядкове представлення відсотка (наприклад, "50%"), воно представляє відсоток від загальної кількості Podʼів. Наприклад, якщо ви встановите minAvailable на "50%", то принаймні 50% Podʼів залишаться доступними під час відключення.

Коли ви вказуєте значення як відсоток, це може не відповідати точній кількості Podʼів. Наприклад, якщо у вас є 7 Podʼів і ви встановите minAvailable на "50%", то не зразу очевидно, чи має це означати, що повинно бути доступно 3 або 4 Podʼи. Kubernetes округлює до найближчого цілого числа, тому в цьому випадку повинно бути доступно 4 Podʼи. Коли ви вказуєте значення maxUnavailable як відсоток, Kubernetes округлює кількість Podʼів, які можуть бути відключені. Таким чином, відключення може перевищувати ваш визначений відсоток maxUnavailable. Ви можете ознайомитися з кодом, який керує такою поведінкою.

Вказання PodDisruptionBudget

PodDisruptionBudget має три поля:

• Селектор міток .spec.selector, щоб вказати набір Podʼів, до яких він застосовується. Це поле обовʼязкове.
• .spec.minAvailable — це опис кількості Podʼів з цього набору, які повинні залишитися доступними після відключення, навіть у відсутності відключеного Podʼа. minAvailable може бути абсолютним числом або відсотком.
• .spec.maxUnavailable (доступний у Kubernetes 1.7 та вище) — це опис кількості Podʼів з цього набору, які можуть бути недоступними після відключення. Це також може бути абсолютним числом або відсотком.

Ви можете вказати лише один із maxUnavailable або minAvailable в одному PodDisruptionBudget. maxUnavailable може бути використаний лише для контролю відключення Podʼів, які мають повʼязаний контролер, який керує ними. У наведених нижче прикладах, "бажані репліки" — це масштаб контролера, що керує Podʼами, які вибрані PodDisruptionBudget.

Приклад 1: З minAvailable 5, відключення дозволяються, поки залишаються 5 або більше справних Podʼів серед тих, які вибрані селектором PodDisruptionBudget.

Приклад 2: З minAvailable 30%, відключення дозволяються, якщо принаймні 30% від кількості бажаних реплік є справними.

Приклад 3: З maxUnavailable 5, відключення дозволяються, поки є не більше 5 несправних реплік серед загальної кількості бажаних реплік.

Приклад 4: З maxUnavailable 30%, відключення дозволяються, якщо кількість несправних реплік не перевищує 30% від загальної кількості бажаних реплік, округленої до найближчого цілого числа. Якщо загальна кількість бажаних реплік — лише одна, ця єдина репліка все ще допускається до відключення, що призводить до ефективної недоступності на 100%.

У типовому використанні один бюджет використовуватиметься для збірки Podʼів, керованих контролером — наприклад, Podʼів у одному ReplicaSet або StatefulSet.

Якщо ви встановите maxUnavailable на 0% або 0, або ви встановите minAvailable на 100% або рівну кількості реплік, ви вимагаєте нульових добровільних виселень. Коли ви встановлюєте нульові добровільні відключення для робочого навантаження, такого як ReplicaSet, тоді ви не зможете успішно вивести з експлуатації вузол, на якому працює один з цих Podʼів. Якщо ви намагаєтеся вивести з експлуатації вузол, де працює невиселяємий Pod, відключення ніколи не завершиться. Це допускається згідно з семантикою PodDisruptionBudget.

Ви можете знайти приклади визначення бюджетів відключення Podʼів нижче. Вони відповідають Podʼам з міткою app: zookeeper.

Приклад PDB з використанням minAvailable:

policy/zookeeper-pod-disruption-budget-minavailable.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Приклад PDB з використанням maxUnavailable:

policy/zookeeper-pod-disruption-budget-maxunavailable.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: zookeeper

Наприклад, якщо вищезгаданий обʼєкт zk-pdb вибирає Podʼи з StatefulSet розміром 3, обидві специфікації мають точно таке ж значення. Рекомендується використання maxUnavailable, оскільки він автоматично реагує на зміни кількості реплік відповідного контролера.

Створення обʼєкта PodDisruptionBudget

Для створення або оновлення обʼєкта PDB використовуйте наступну команду kubectl:

kubectl apply -f mypdb.yaml

Перевірка статусу обʼєкта PodDisruptionBudget

Щоб перевірити статус обʼєкта PDB, скористайтеся наступною командою kubectl.

Якщо в вашому просторі імен відсутні Podʼи, що відповідають мітці app: zookeeper, ви побачите щось подібне:

kubectl get poddisruptionbudgets

NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               0                     7s

Якщо є Podʼи, які відповідають умовам (скажімо, 3), то ви побачите щось на кшталт:

kubectl get poddisruptionbudgets

NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               1                     7s

Ненульове значення для ALLOWED DISRUPTIONS означає, що контролер відключення Podʼів бачив Podʼи, підрахував відповідні Podʼи і оновив статус PDB.

Ви можете отримати більше інформації про статус PDB за допомогою цієї команди:

kubectl get poddisruptionbudgets zk-pdb -o yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  annotations:
…
  creationTimestamp: "2020-03-04T04:22:56Z"
  generation: 1
  name: zk-pdb
…
status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

Справність Pod

Поточна реалізація вважає Podʼи справними, якщо вони мають елемент .status.conditions з type="Ready" і status="True". Ці Podʼи відстежуються через поле .status.currentHealthy в статусі PDB.

Політика виселення несправних Podʼів

PodDisruptionBudget, який охороняє застосунок, забезпечує, що кількість Podʼів зі статусом .status.currentHealthy не опуститься нижче, ніж кількість, вказана у .status.desiredHealthy, не дозволяючи видалення справних Podʼів. Використовуючи .spec.unhealthyPodEvictionPolicy, ви також можете визначити критерії, коли несправні Podʼи повинні розглядатися для видалення. Стандартна поведінка, коли політика не вказана, відповідає політиці IfHealthyBudget.

Політики:

IfHealthyBudget

Запущені Podʼи (.status.phase="Running"), але ще не справні, можуть бути виселені тільки якщо охоронюваний застосунок не відключений (.status.currentHealthy щонайменше дорівнює .status.desiredHealthy).

Ця політика забезпечує, що запущені Podʼи вже відключеного застосунку мають кращі шанси стати справними. Це має негативні наслідки для виведення вузлів з експлуатації, які можуть бути заблоковані неправильно працюючими застосунками, які охороняються PDB. Зокрема, застосунки з Podʼами у стані CrashLoopBackOff (через помилку або неправильну конфігурацію), або Podʼи, яким просто не вдається повідомити умову Ready.

AlwaysAllow

Запущені Podʼи (.status.phase="Running"), але ще не справні вважаються відключеними та можуть бути видалені незалежно від того, чи виконуються критерії в PDB.

Це означає, що майбутні запущені Podʼи відключеного застосунку можуть не мати можливості стати справними. Використовуючи цю політику, менеджери кластера можуть легко вивести з експлуатації неправильно працюючі застосунки, які охороняються PDB. Зокрема, застосунки з Podʼами у стані CrashLoopBackOff (через помилку або неправильну конфігурацію), або Podʼи, які просто не вдаються відправити умову Ready.

Довільні робочі навантаження та селектори

Ви можете пропустити цей розділ, якщо ви використовуєте PDB лише зі вбудованими ресурсами навантаження (Deployment, ReplicaSet, StatefulSet та ReplicationController) або з власними ресурсами, які реалізують підресурс scale, і де селектор PDB точно відповідає селектору власного ресурсу Podʼа.

Ви можете використовувати PDB з підпроцесами, керованими іншим ресурсом, "оператором" або голими підпроцесами, але з такими обмеженнями:

• можна використовувати лише .spec.minAvailable, а не .spec.maxUnavailable.
• можна використовувати лише ціле значення з .spec.minAvailable, а не відсоток.

Неможливо використовувати інші конфігурації доступності, оскільки Kubernetes не може вивести загальну кількість Podʼів без підтримуваного власного ресурсу.

Ви можете використовувати селектор, який вибирає підмножину або надмножину Podʼів, що належать ресурсу навантаження. Eviction API не дозволить виселення будь-якого Podʼа, покритого кількома PDB, тому більшість користувачів захочуть уникати перетинаючих селекторів. Одним розумним використанням перетинаючих PDB є перехід Podʼів з одного PDB до іншого.