Словник для розв'язання проблем Kubernetes: зневадження термінів пояснено

Коли кластер Kubernetes поводиться неправильно, вам потрібно швидко і точно описати, що відбувається — в Slack, під час дзвінка або в каналі інциденту. Словниковий запас дуже багатий і повний складних слів, які не з’являються в жодному словнику. У цьому підручнику описано основні слова, які використовуються для розв’ язання проблем, а також наведено приклади речень, які ви можете використовувати.

---

Будівельні блоки

Перед тим, як почати розв’ язання проблеми, переконайтеся, що ви знаєте наступні правила:

• ** pod ** — найменший з можливих для розгортання об’ єктів; один або декілька контейнерів. * « Под застряг у стані очікування. » *
• ** вузол ** — робоча машина. * “Цей вузол знаходиться під тиском пам’ яті.” *
• deployment — керує набором ідентичних підрозділів. “Я відновив розгортання.”
• replica — одна копія підрозділу. “Ми запускаємо три репліки.”
• ** namespace ** — логічний розділ кластера.
• ** керуюча площина ** — головний мозок (сервер API, планувальник тощо).
• ** kubelet ** — агент на кожному вузлі. * « Кубелет припинив повідомлення ». *

Вимова: kubectl зазвичай вимовляється як «cube-control» або «cube-cuttle»; kubelet означає «cube-let». Будь- яке з них прийнято — оберіть одне і будьте послідовними.

---

Под-статути і що вони означають

Половина розв’ язання проблем полягає у зчитуванні і назві станів підсистем.

• ** Очікування ** — заплановано, але ще не запущено. * « Застряг у очікуванні — жоден вузол не має достатньої ємності. » *
• ** Запуск ** — принаймні один контейнер запущено.
• CrashLoopBackOff — контейнер постійно аварійно перезавантажується, з зростаючою затримкою. « Підрозділ знаходиться у стані CrashLoopBackOff — він не може бути запущено. »
• ImagePullBackOff — Kubernetes не може витягнути образ контейнера. “ImagePullBackOff — ймовірно, погана мітка або проблема з аутентифікацією реєстру.”
• ** Вихід** — завершення роботи. * « Под застряг Вихід. » *
• ** Завершено ** — завдання успішно завершено.
• ** Помилка / Спроба зазнала невдачі ** — завершено безуспішно.

Дієслово, яке слід використовувати, це stuck in a state: “It’s stuck in CrashLoopBackOff.”

---

Причини невдачі ти скажеш вголос

Це умови, які з’ являються в kubectl describe і events :

• OOMKilled — « закінчено через брак пам’ яті »; ядро вбило контейнер за перевищення обмеження пам’ яті. « Контейнер отримав OOMKilled — нам потрібно перевищити обмеження пам’ яті. »
• ** Викинуто ** — kubelet вилучив підрозділ, щоб відновити ресурси. * « Три підрозділи було викинуто під тиском диска. » *
• ** Обмеження** — використання процесора було обмежено до його межі. * « Контейнер обмежено — він досягає свого обмеження процесора. » *
• ** Backoff ** — збільшення затримки між повторними спробами. * “Це відновлення, тому перезапуски стають повільнішими.” *
• ** Liveness probe failed ** — перевірка стану не вдалася, тому Kubernetes перезавантажив контейнер. * « Liveness probe fails, so it keeps getting killed. » *
• ** Спроба визначення готовності завершилася невдало ** — модуль не готовий до обслуговування трафіку. * « Він працює, але не готовий — вимірювання готовності показує червоний колір. » *

«Под був OOMKilled двічі, потім увійшов в CrashLoopBackOff, тому що тайм-аут зонда живості при холодному старті»

---

Ресурси і планування

• ** запит ** — мінімальний ресурс, який резервує підсистема. * « Ми запитали замало пам’ яті. » *
• ** обмеження ** — обмеження, яке може використовувати підсистема. * « Він перевищив обмеження процесора і був пригнічений. » *
• ** тиск на ресурси ** — вузол, у якого закінчується пам’ ять або диск. * « У вузлі закінчується пам’ ять. » *
• ** to schedule ** — розташувати підрозділ на вузлі. * « Планувальник не може розташувати його ніде ». *
• ** taint / tolerance ** — правила, які не дозволяють підсистемам працювати з певними вузлами (або дозволяють їм працювати з ними). * « Не буде розкладено, оскільки вузол має забарвлення. » *
• ** affinity ** — правила щодо того, де слід виконувати підпрограми.
• ** to drain a node ** — вивести всі підсистеми для виконання обслуговування. * “Я виводжу з ладу вузол- 3 перед оновленням.” *
• ** to cordon ** — позначає вузол, який не можна розкладати. * « Спочатку закріпіть його, а потім витягніть ». *

---

Мережеві та зберігальні умови

• ** Служба ** — стабільна кінцева точка перед підсистемами. * « Служба не має кінцевих точок — немає здорових підсистем ». *
• Ingress — маршрутизує зовнішній вхідний трафік. “The Ingress is returning 502s.”
• ** endpoint ** — фактичні IP- адреси підсистеми, що стоять за Службою. * « Endpoints are empty. » *
• ** Розв’ язання DNS ** — * « Не розв’ язується DNS між просторами імен. » *
• ** PersistentVolumeClaim (PVC) ** — запит на зберігання. * « PVC застряг. Очікується — немає томів для прив’ язки. » *
• ** to bind ** — приєднати том до заперечення. * « PV не буде прив’ язано ». *

---

Дієслова для вирішення проблем

Ці дієслова дії роблять ваші речення звучать як у вашій мові:

• ** to roll back ** — повернути до попередньої версії. * « Давайте повернемо останнє розгортання. » *
• ** to roll out / restart ** — натиснути або перезапустити. * « Я зроблю перезапуск з перемиканням. » *
• ** to scale up / down ** — змінити кількість реплік. * « Зменшити до нуля і зберегти. » *
• ** to exec into ** — відкриває оболонку у контейнері. * « Дозвольте мені виконати команду у підсистемі і перевірити журнали ». *
• ** to tail the logs ** — дивитися журнали в реальному часі. * “Я зараз дивлюся журнали.” *
• ** to describe ** — перевірити події об’ єкта. * « Описати підрозділ — причина полягає у подіях. » *
• ** to reproduce ** — повторити ваду. * “Я не можу відтворити її локально.” *
• ** to bump ** — збільшити значення. * « Збільшити обмеження пам’ яті до 1 Гб ». *

Я влетів у капсулу, прослідкував за журналами, побачив, як вона вимикається, перевищив обмеження і зробив перезапуск

---

Фрази для каналу інциденту

• • « Підрозділ знаходиться у CrashLoopBackOff — перегляд подій зараз. » *
• *“Підтверджено OOMKilled. «Відновлення і відновлення» (фр
• “У Служби немає кінцевих точок, тому трафік є чорною дірою.”
• “Вузол-2 знаходиться під тиском пам’яті і викидає підшипники.”
• “Відновлення останнього зображення, що було знайдено.”
• “Зонд тремтить - проходит, потом не проходит, потом проходит.”

Дієслово flapping (швидке чергування станів) є дуже корисним: “Зонд готовності блискавично переміщується.”

---

Поширені помилки

• ** « Підрозділ не працює ». ** Будь ласка, вкажіть, чи відбувається це у режимі очікування, циклу аварійного завершення або завершення роботи? У кожного своя лікувальна сила.
• ** Плутанина між активністю і готовністю. ** * Неможливо активізувати * → перезапуск. * Неможливо активізувати * → немає потоку, але немає перезапуску.
• “Вбила себе”. Скажи, що вбило її: “Вбито, виселено, або вбито розслідуванням”.
• **Помилка у поєднанні запитів і обмежень. ** запит резервує, обмеження обмежує. Дротлінг і OOM пов’ язані з обмеженнями.
• ** Використання слова « контейнер », якщо ви маєте на увазі « піддон ». ** У піддоні може бути декілька контейнерів.

---

Ключевые вещи

• Навчання станів підсистеми холодно: ** Очікування, CrashLoopBackOff, ImagePullBackOff, Завершення. **
• Назва причини невдачі: **OOMKilled, Виключено, обмежено, невдало. **
• Розрізняйте запит проти обмеження і живість проти готовності.
• Використовувати національні дієслова: ** roll back, exec into, tail the logs, drain, bump. **
• У повідомленнях про події вкажіть стан, причину і вашу наступну дію.

Використовуйте цей словник, і зневадження Kubernetes — на будь- якому каналі — буде швидшим і зрозумілішим для всіх учасників розмови.

На практиці: Навігація нюансів для не-народжені мовці

Термінологія Kubernetes може здатися особливо щільною для розробників, чия перша мова не є англійською. Це не просто про знання * слів * самих; це розуміння тонких конотації, конкретні фрази, використовувані в комунікації, і як ці слова зазвичай розгортаються в професійному контексті. Розглянемо типовий сценарій: ви переглядаєте запит на захоплення, надісланий колегою, який є новим у команді. Вони ввели зміну в розгортання, яке зараз переживає часті перезапуски - конкретно, помилки CrashLoopBackOff.

Типовий коментар може виглядати так: « Цей підзаголовок застряг у CrashLoopBackOff. Досліджуйте журнали. » Хоча це технічно коректно, ця фраза може звучати досить тупо і потенційно залякати когось, хто все ще адаптується до технічної англійської. Більш конструктивним підходом було б: «Я помітив, що цей під неодноразово аварійно закривається — він показує стан CrashLoopBackOff. Не могли б ви, будь ласка, переглянути журнали контейнерів, щоб побачити, чи можемо ми визначити основну причину? Можливо, є проблема з обмеженнями ресурсів або залежністю, яка не спрацьовує. » Різниця полягає у рівні деталізації, пропозиції співпраці (« Чи можете ви…») і уникнення потенційно обвинувачувальної мови, на зразок « застряг ». Ці невеликі зміни у фразуваннях є * критичними * для ефективного спілкування всередині команди.

Інша поширена ситуація виникає під час розмов Slack під час зневадження проблеми. Уявіть, що хтось вводить: «Pod’s OOMKilled! Виправте це!», хоча це коротко, але не має контексту. Більш гладким повідомленням буде: « Под було завершено через стан « Недостатньо пам’ яті » (OOMKilled). Нам слід перевірити запити на ресурси і обмеження, визначені для контейнера, щоб визначити, чи вони належним чином налаштовані. » Знову ж таки, додавання деталей, наприклад, « Не вистачає пам’ яті », прояснює проблему, а визначення її як « * потреби * перевірити щось » (« нам потрібно перевірити ») заохочує до дії, а не просто вимагає виправлення. Ці невеликі доповнення демонструють глибше розуміння механіки, що лежить в основі проблеми.

Нарешті, при написанні описів PR, чітка і точна мова є найважливішою. Замість того, щоб вказати « Виправлено CrashLoopBackOff », розгляньте такий варіант: « Виправлено повторювані помилки CrashLoopBackOff за допомогою збільшення обмеження пам’ яті для контейнера до 2ГіБ, що сприяло вирішенню проблеми потенційної суперечки щодо ресурсів ». Це надає вам можливість побачити безпосередній контекст — * чому * було внесено зміну і яку проблему вона має вирішити.

kubectl describe pod my-pod -n default

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