Як обговорити інцидент з виселенням Kubernetes Pod англійською мовою

Виселення піддонів є одним з найбільш тривожних інцидентів, які потрібно пояснити, тому що «виселення» означає, що щось було насильно вилучено - що технічно правдоподібно, але зазвичай це контролюваний механізм безпеки, а не катастрофічна невдача. Вміння пояснити спокійно і точно англійською, чому кластер прийняв це рішення і що з ним робиться, не дає інциденту з тиском ресурсів звучати як системний зрив.

Ключовий словник

** Вилучення піду ** — процес, за допомогою якого kubelet вилучає під з вузла, щоб відновити ресурси, зазвичай, це відбувається під час тиску пам’ яті або диска. “Садки не руйнувалися самі по собі — кубелет вигнав їх, тому що у вузла закінчилася пам’ ять.”

** Ресурсний тиск (тиск пам’яті/диска) ** — стан вузла, коли вільна пам’ять або дискове місце опускається нижче налаштованого порогу, що спонукає Kubernetes почати відновлення ресурсів. “Як тільки вузол досяг тиску пам’яті, Kubernetes почав витісняти підсистеми з нижчим пріоритетом, щоб захистити сам вузол.”

** Запити і обмеження на ресурси ** — налаштовані мінімальна (запит) і максимальна (обмеження) кількість процесора або пам’ яті, яку може використовувати контейнер, і яку планувальник і kubelet використовують для прийняття рішень. “Ці підсистеми не мали встановлених обмежень пам’ яті, тому вони могли споживати набагато більше, ніж передбачалося, до того, як вузол вступив у дію.”

Клас QoS (Quality of Service) — рівень пріоритету (Гарантований, Неперервний або Найкращий), який Kubernetes використовує для вирішення, які підсистеми слід викинути першими під тиском.

• “Оскільки цей підрозділ був у категорії BestEffort, він був одним з перших, кого було виселено, коли вузол опинився під тиском.” *

** Поріг вилучення під тиском вузла ** — певний рівень ресурсів (наприклад, вільна пам’ ять менше 100Mi), який викликає початок вилучення підрозділів кубелетом.

• “Ми мали типовий поріг висилання, саме тому висилання почалося до того, як у вузла дійсно закінчилася пам’ ять.” *

Пояснення кореневої причини

• «Вузол не зламався — Kubernetes проактивно вигнав декілька піддонів, як тільки вільна пам’ять впала нижче налаштованого порогу»
• «Гаряча гаряча горішка працювала без встановлених обмежень пам’яті, тому вони могли споживати більше пам’яті, ніж ми планували, що підштовхнуло вузол під тиск»
• «Саме вигнання було Kubernetes, що працює так, як було спроектовано — захист вузла — справжня проблема була в тому, що наші обмеження ресурсів не були достатньо жорсткими, щоб запобігти ситуації»

Повідомлення про ліквідацію

• «Ми додаємо явні обмеження пам’яті до кожного розгортання в цьому просторі імен, тому жоден під не може споживати достатньо, щоб знову викликати тиск на весь вузол»
• «Ми збільшили обсяг пам’яті вузла і також ввімкнули горизонтальне автомасштабування, тому навантаження розподіляється по більшій кількості вузлів до того, як тиск зростає»
• «Захворілі піддони були автоматично переплановані на здорові вузли протягом приблизно дев’яноста секунд, тому вплив кінцевого користувача був обмежений цим вікном»

Захист від повторення

• «Ми додаємо попередження про тиск пам’яті вузла, а не тільки про перезапуски, тому ми ловимо це раніше наступного разу»
• «В майбутньому кожна нова служба потребує запитів на ресурси і обмежень, визначених до того, як вона може бути розгорнута — ми додаємо це як обов’язкову перевірку в нашому процесі перегляду»
• «Ми також переглядаємо наші завдання QoS, щоб переконатися, що критичні послуги встановлені на Гарантований, тому вони останні, хто буде виселений, а не перший»

Професійні поради

1. ** Відокремте «висилання» від «збою» явно. ** Сказавши «це був Kubernetes, що захищає вузол, а не аварія» переформулює інцидент точно і запобігає зацікавленим сторонам від припущення втрати даних або простою, що не сталося.
2. ** Назвіть відсутній захист, а не лише тригер. ** « Ми не встановили обмеження пам’ яті » є більш дійсним, ніж « у вузла закінчилася пам’ ять », оскільки це вказує безпосередньо на виправлення.
3. ** Оцініть час відновлення. ** Конкретна цифра, наприклад, “переплановано за дев’яносто секунд” заспокоює зацікавлених осіб набагато більше, ніж нечітке “воно швидко відновлюється.”

Практичні вправи

1. Напишіть два речення, які пояснять нетехнічним користувачам, чому « вилучення » підсистеми не є тим самим, що і аварія програми.
2. Написати коротке оновлення, в якому пояснюється, що обмеження ресурсів, а не сам механізм вигнання, були справжньою причиною.
3. Поясніть одним реченням, що таке клас QoS і чому він важливий під час інциденту з тиском на ресурси.

Національна мова: мова, що не є рідною для населення

Добре, отже, ви визначили вилучення піду Kubernetes — раптове вилучення контейнера з вузла. Це розчарування, розлад, і часто вказує на основну проблему. Але просто сказати, що «капу було виселено», недостатньо. Ключовим є чітке і чітке спілкування, особливо при роботі з колегами, які можуть розвивати свої професійні навички англійської мови. Давайте зосередимося на створенні словника, який виходить за рамки основних технічних термінів і дозволяє вам ефективно сформулювати ситуацію.

Однією з поширених пасток є використання надто неясної мови. Замість « під загинув » спробуйте щось на зразок « Під було насильно припинено планувальником Kubernetes через обмеження ресурсів ». Зауважте зміну — ми назвали * чому * це сталося: обмеження ресурсів. Це негайно обрамляє подію в конкретному технічному контексті і уникає потенційно тривожних термінів, таких як «помер», що може звучати менш професійно і може призвести до спекуляцій про системні помилки. Аналогічно, уникайте фраз на кшталт «щось пішло не так». Це надто широке розуміння. Будь точніше у своєму описі.

Іншою областю для поліпшення є формулювання, пов’язане з відповідальністю. Важливо показати, що ти береш на себе відповідальність за ситуацію. Замість того, щоб сказати «Я не знаю, чому це сталося», більш конструктивний підхід полягає в тому, що «Ми повинні розслідувати кореневу причину цього виселення. Початкові спостереження вказують на те, що вузол переживав високе використання ЦП, що викликало політику випередження планувальника. ” Використання фраз на кшталт «ми повинні дослідити» демонструє спільні зусилля і змінює фокус від звинувачення до вирішення проблеми. Також добре використовувати такі терміни, як «передупреждение» при обговоренні потенційних рішень - щось, що свідчить про те, що ви думаєте про те, як уникнути цього знову.

Нарешті, пам’ятайте, що активне слухання так само важливо, як і чітке мовлення. Коли хтось просить про пояснення, не повторюйте просто своє початкове твердження. Відповідайте такими фразами, як «Дозвольте мені розібратися в цьому пункті…» або «Щоб бути більш конкретним…» Це показує повагу до їхнього розуміння і дозволяє вам вдосконалити пояснення на основі їхніх запитань. Це хороша звичка запитувати їх, чи вони розуміють – «Чи має це сенс?» є простим, ефективним способом переконатися, що всі на одній сторінці.