# Налагодження Podʼів LLMS index: [llms.txt](/llms.txt) --- Цей посібник допоможе користувачам налагодити програми, які розгорнуті у Kubernetes та які поводяться некоректно. Це *не* настанова для людей, які хочуть налагоджувати свій кластер. Для цього вам слід ознайомитися з [цим посібником](/docs/tasks/debug/debug-cluster). ## Діагностика проблеми {#diagnosing-the-problem} Перший крок у розвʼязанні проблем — перевірка. Що сталося? Проблема у ваших Podʼах, Контролері Реплікацій чи Service? * [Налагодження Podʼів](#debugging-pods) * [Налагодження Контролерів Реплікацій](#debugging-replication-controllers) * [Налагодження Services](#debugging-services) ### Налагодження Podʼів {#debugging-pods} Перший крок у налагоджені Podʼа — це його перевірка. Перевірте поточний стан Podʼа та останні події за допомогою наступної команди: ```shell kubectl describe pods ${POD_NAME} ``` Огляньте стан контейнерів у Podʼі. Чи всі вони `Running` (працюють)? Чи були нещодавні перезапуски? Продовжуйте налагодження, виходячи зі стану Podʼів. #### Мій Pod залишається в стані Pending {#my-pod-stays-pending} Якщо Pod застряг у стані `Pending`, це означає, що його не можна запланувати на вузол. Зазвичай це відбувається через недостатні ресурси одного типу чи іншого, які заважають плануванню. Подивіться на вивід команди `kubectl describe ...` вище. Там мають бути повідомлення від планувальника про причини, чому він не може запланувати ваш Pod. Причини включають: * **У вас недостатньо ресурсів**: Можливо, ви вичерпали запас CPU або памʼяті у вашому кластері, у цьому випадку вам потрібно видалити Podʼи, налаштувати запити на ресурси, або додати нові вузли до вашого кластера. Дивіться [документ про обчислювальні ресурси](/docs/concepts/configuration/manage-resources-containers/) для отримання додаткової інформації. * **Ви використовуєте `hostPort`**: Коли ви привʼязуєте Pod до `hostPort`, існує обмежена кількість місць, де можна запланувати цей Pod. У більшості випадків, `hostPort` не є необхідним, спробуйте використати обʼєкт Service для відкриття доступу вашому Podʼу. Якщо вам все ж потрібен `hostPort`, то ви можете запланувати лише стільки Podʼів, скільки у вас вузлів у кластері Kubernetes. #### Мій Pod залишається у стані Waiting {#my-pod-stays-waiting} Якщо Pod застряг у стані `Waiting`, то він був запланований на робочий вузол, але не може працювати на цій машині. Знову ж таки, вивід команди `kubectl describe ...` має бути інформативним. Найпоширенішою причиною Podʼів у стані `Waiting` є неможливість завантаження образу. Тут є три речі, які потрібно перевірити: * Переконайтеся, що ви правильно вказали імʼя образу. * Чи ви завантажили образ у реєстр? * Спробуйте вручну завантажити образ, щоб перевірити, чи можна його завантажити. Наприклад, якщо ви використовуєте Docker на вашому ПК, виконайте `docker pull `. #### Мій Pod залишається у стані Terminating {#my-pod-stays-terminating} Якщо Pod застряг у стані `Terminating` (завершення), це означає, що було видано наказ про видалення Podʼа, але панель управління не може видалити обʼєкт Pod. Це зазвичай відбувається, якщо у Podʼа є [завершувач](/docs/concepts/overview/working-with-objects/finalizers/) та встановлений [вебхук допуску](/docs/reference/access-authn-authz/extensible-admission-controllers/) у кластері, який перешкоджає панелі управління видалити завершувач. Щоб виявити цей сценарій, перевірте, чи у вашому кластері є вебхуки `ValidatingWebhookConfiguration` або `MutatingWebhookConfiguration`, які спрямовані на операції `UPDATE` для ресурсів `pods`. Якщо вебхук надається стороннім постачальником: * Переконайтеся, що ви використовуєте останню версію. * Вимкніть вебхук для операцій `UPDATE`. * Повідомте про проблему відповідного постачальника. Якщо ви є автором вебхуку: * Для мутуючого вебхуку переконайтеся, що він ніколи не змінює незмінні поля під час операцій `UPDATE`. Наприклад, зміни контейнерів зазвичай не дозволяються. * Для валідуючого вебхуку переконайтеся, що ваші політики валідації застосовуються лише до нових змін. Іншими словами, ви повинні дозволяти Podʼам з наявними порушеннями пройти валідацію. Це дозволяє Podʼам, які були створені до встановлення вебхуку валідації, продовжувати працювати. #### Мій Pod виходить з ладу або несправний іншим чином {#my-pod-is-crashing-or-otherwise-unhealthy} Як тільки ваш Pod був запланований, методи, описані в [Налагодження Запущених Подів](/docs/tasks/debug/debug-application/debug-running-pod/), доступні для налагодження. #### Мій Pod працює, але не робить те, що я йому сказав робити {#my-pod-is-running-but-not-doing-what-i-told-it-to-do} Якщо ваш Pod не поводиться так, як ви очікували, це може бути повʼязано з помилкою у вашому описі Podʼа (наприклад, файл `mypod.yaml` на вашому локальному компʼютері), і цю помилку було мовчки проігноровано під час створення Podʼа. Часто розділ опису Podʼа вкладено неправильно, або імʼя ключа набрано неправильно, і тому ключ ігнорується. Наприклад, якщо ви помилилися в написанні `command` як `commnd`, тоді Pod буде створено, але не використовуватиме командний рядок, який ви планували. Перша річ, яку варто зробити, — видалити свій Pod і спробувати створити його знову з опцією `--validate`. Наприклад, виконайте `kubectl apply --validate -f mypod.yaml`. Якщо ви помилилися в написанні `command` як `commnd`, то отримаєте помилку на кшталт цієї: ```shell I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842 pods/mypod ``` Наступне, що варто перевірити, — чи збігається Pod на апісервері з Podʼом, який ви збиралися створити (наприклад, у файлі YAML на вашому локальному компʼютері). Наприклад, виконайте `kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml` а потім вручну порівняйте оригінальний опис Podʼа, `mypod.yaml`, з тим, який ви отримали з апісервера, `mypod-on-apiserver.yaml`. Зазвичай деякі рядки в версії "апісервера" відсутні в оригінальній версії. Це очікувано. Однак, якщо є рядки в оригінальному описі, яких немає в версії апісервера, то це може свідчити про проблему з вашими специфікаціями Podʼа. ### Налагодження Контролерів Реплікацій {#debugging-replication-controllers} Контролери реплікацій досить прості. Вони можуть або створювати Podʼи, або не можуть. Якщо вони не можуть створювати Podʼи, будь ласка, зверніться до [інструкцій вище](#debugging-pods), щоб налагодити ваші Podʼи. Ви також можете використовувати `kubectl describe rc ${CONTROLLER_NAME}` для вивчення подій, що стосуються контролера реплікацій. ### Налагодження Serviceʼів {#debugging-services} Serviceʼи забезпечують балансування навантаження між набором Podʼів. Є кілька загальних проблем, які можуть призвести до неправильної роботи Serviceʼів. Наступні інструкції допоможуть дослідити проблеми з Serviceʼами. Спочатку перевірте, що для Service є точки доступу. Для кожного обʼєкта Service апісервер робить доступними один чи більше ресурсів `EndpointSlice`. Ви можете переглянути ці ресурси за допомогою: ```shell kubectl get endpointslices -l kubernetes.io/service-name=${SERVICE_NAME} ``` Переконайтеся, що точки доступу в EndpointSlices відповідають кількості Podʼів, які ви очікуєте бачити в складі вашого Service. Наприклад, якщо ваш Service для контейнера nginx має 3 репліки, ви очікуєте побачити три різних IP-адреси у зрізах точок доступу Serviceʼу. #### Мій Service відсутні точки доступу {#my-service-is-missing-endpoints} Якщо вам не вистачає точок доступу, спробуйте передивитись перелік Podʼів за допомогою міток, які використовує Service. Уявіть, що у вас є Service, де є такі мітки: ```yaml ... spec: - selector: name: nginx type: frontend ``` Ви можете використовувати: ```shell kubectl get pods --selector=name=nginx,type=frontend ``` щоб отримати перелік Podʼів, які відповідають цьому селектору. Перевірте, чи список відповідає Podʼам, які ви очікуєте бачити у вашому Service. Перевірте, чи `containerPort` Podʼа відповідає `targetPort` Serviceʼа. #### Мережевий трафік не переспрямовується {#network-traffic-is-not-forwarded} Будь ласка, див. [налагодження Service](/docs/tasks/debug/debug-application/debug-service/) для отримання додаткової інформації. ## Що далі Якщо жоден із вищезазначених методів не розвʼязує вашу проблему, слідуйте інструкціям у [документі про налагодження Serviceʼу](/docs/tasks/debug/debug-application/debug-service/) щоб переконатися, що ваш `Service` працює, має `Endpoints`, і ваші `Pod`ʼи фактично обслуговуються; DNS працює, встановлені правила iptables, і kube-proxy поводиться відповідно. Ви також можете відвідати [документ про налагодження](/docs/tasks/debug/) для отримання додаткової інформації.