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

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

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

Для перевірки версії введіть 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 PDB.

Починаючи з версії 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 із можливістю перезапуску:
  • Застереження: Job має завершитися в разі добровільного порушення.
    • Можливе рішення: не створюйте PDB. Контролер Job створить 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 — опис кількості Podʼів із цього набору, які можуть бути недоступними після виселення. Це також може бути абсолютне число або відсоток.

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

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

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

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

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

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

Якщо ви встановите maxUnavailable на 0% або 0 чи minAvailable на 100% або на кількість реплік, ви вимагаєте нуль добровільних виселень. Якщо задати нуль добровільних виселень для обʼєкта робочого навантаження, як-от ReplicaSet, ви не зможете успішно виконати drain вузла, на якому працює один із цих Podʼів. Якщо спробувати виконати drain вузла, де працює Pod, який не можна виселити, drain ніколи не завершиться. Це дозволено семантикою 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, оскільки він автоматично реагує на зміни кількості реплік відповідного контролера.

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

Створити або оновити обʼєкт PDB можна за допомогою kubectl.

kubectl apply -f mypdb.yaml

Перевірка статусу PDB

Використайте kubectl, щоб перевірити, що ваш PDB створено.

Якщо у вашому просторі імен насправді немає 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ʼи й оновив статус 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

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

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

AlwaysAllow

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

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

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

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

Ви можете використовувати PDB з Podʼами, керованими іншим ресурсом, «оператором», або з окремими Podʼами, але з такими обмеженнями:

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

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

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