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

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

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

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

• Ви є власником застосунку, який працює в кластері 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ʼів, які всі мають той самий повʼязаний контролер, який керує ними. У наведених нижче прикладах, "бажані репліки" — це scale контролера, що керує 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 до іншого.