``` kubectl debug buggypod --image debian --attach ``` --- # ✅ **Что делает эта команда?** Эта команда запускает **интерактивный отладочный контейнер (debug container)** рядом с существующим Pod `buggypod`. И ты попадаешь _внутрь_ этого нового контейнера, чтобы отлаживать проблемы. --- # 🔍 **Разбор по частям** ### **1️⃣ `kubectl debug`** Подкоманда, которая создаёт “отладочную среду” вокруг существующего Pod или Node. Это лучше и безопаснее, чем ломать рабочие контейнеры. --- ### **2️⃣ `buggypod`** Имя Pod, который ты хочешь исследовать. Отладочный контейнер привяжется именно к нему. --- ### **3️⃣ `--image debian`** Говорит Kubernetes: > Создай новый контейнер внутри Pod на основе образа Debian. Почему Debian? - там есть bash - там есть большинство утилит - удобно диагностировать В рабочем контейнере часто нет ничего (busybox, distroless). --- ### **4️⃣ `--attach`** Открывает интерактивную сессию **сразу после запуска** debug-контейнера. То есть ты сразу попадёшь внутрь: ``` root@debugger:/# ``` Без `--attach` он бы просто создал контейнер в Pod, но ты бы в него не вошёл. --- # 🧩 **Что важно понимать** ## 🔸 Debug-контейнер запускается _в том же namespace_ и _в том же Pod сетевом пространстве_, что и твой `buggypod`. Это означает: ✔ Ты видишь все тома ✔ Ты видишь файловую систему контейнера ✔ Ты можешь выполнять `curl`/`wget` к localhost ✔ Ты можешь проверять сети, DNS, environment Это идеальный способ быстро найти проблему. --- # 🔥 Пример реального использования ``` kubectl debug backend-7f9b4f5b4d-kmqbz --image debian --attach ``` А дальше: ``` apt update && apt install curl -y curl localhost:8080 cat /etc/resolv.conf ls /data ``` --- # 🧠 Итог `kubectl debug ...` = «запусти чистый Debian рядом с моим проблемным контейнером и подключи меня внутрь для отладки». --- Команда: ```bash kubectl debug buggypod --image debian --attach ``` Разберём по шагам, а потом отвечу на все четыре пункта. --- ## 1. Что делает эта команда - `kubectl debug` — запускает **отладочный контейнер/под**. - `buggypod` — имя проблемного pod’а, рядом с которым мы хотим дебажить. - `--image debian` — образ, из которого будет создан **debug-контейнер** (часто берут debian/ubuntu, чтобы были `curl`, `ping`, `tcpdump`, и т.д.). - `--attach` — сразу **подключиться к терминалу** этого debug-контейнера (как будто `kubectl exec -it ... -- bash`). В зависимости от версии `kubectl` и кластера, это либо: - создаёт **ephemeral container** внутри существующего pod`а` buggypod`, - либо создаёт **отдельный под-копию** (`buggypod-debug`) с тем же namespace/labels и shared-сеткой (если используешь `--copy-to`, но у тебя его нет). --- ## 2. Чем `kubectl debug` отличается от `kubectl exec` ### `kubectl exec` ```bash kubectl exec -it buggypod -- sh ``` - Заходит ВНУТРЬ уже существующего контейнера. - Ты ограничен: - тем образом, который там запущен; - тем набором утилит (если это `distroless` или `scratch`, то там вообще ничего нет). - Нельзя добавить новые бинарники без пересборки образа. ### `kubectl debug` ```bash kubectl debug buggypod --image debian --attach ``` - Создаёт **новый контейнер для отладки**: - либо как ephemeral container в существующем pod, - либо как отдельный debug pod (зависит от режима / версии). - Ты можешь выбрать **любой образ** (Debian, Ubuntu, Alpine, спец-образ с net-tools и т.п.). - И при этом: - можешь **разделить network namespace** с исходным pod (видеть его IP, порты), - получить доступ к тем же volume (в режиме copy-to), - проверять окружение, DNS и т.п., не ломая основной контейнер. 👉 Главное отличие: **`exec` = “залезть в существующий контейнер”** **`debug` = “создать рядом умный инструмент для отладки”**. --- ## 3. Как посмотреть контейнеры в debug pod ### 3.1. Посмотреть pod’ы с debug После запуска: ```bash kubectl debug buggypod --image debian --attach ``` Если создан отдельный pod (например, с `--copy-to`): ```bash kubectl get pods ``` Ты увидишь что-то вроде: ```text NAME READY STATUS RESTARTS AGE buggypod 1/1 Running 0 2d buggypod-debug 1/1 Running 0 1m ``` Тогда содержимое: ```bash kubectl describe pod buggypod-debug kubectl get pod buggypod-debug -o yaml | less ``` ### 3.2. Если это ephemeral container (внутри того же pod) Тогда отдельного pod не появится, но в `buggypod` появится секция `ephemeralContainers`: ```bash kubectl get pod buggypod -o yaml | less ``` или более точечно: ```bash kubectl get pod buggypod -o jsonpath='{.spec.ephemeralContainers}' | jq ``` Также можно: ```bash kubectl describe pod buggypod ``` Внизу будет блок **Ephemeral Containers**. --- ## 4. Почему `kubectl debug` иногда недоступен на k3s На k3s часто встреваются такие проблемы: 1. **Версия k3s / kube-apiserver старая** - `kubectl debug` и ephemeral containers нормально работают с определённых версий Kubernetes (1.18+ с фичегейтом, потом стабильно). - Если `server` слишком старый, kubectl будет ругаться, что команда недоступна. 2. **Версия `kubectl` сильно новее, чем кластер** - Например: `kubectl 1.29`, а k3s — 1.23. - Тогда некоторые фичи (в т.ч. debug) в клиенте есть, а на сервере — нет. 3. **Ephemeral containers отключены** - На некоторых сборках или манифестах k3s фича может быть не включена, особенно если кластер собран минималистично. 4. **Права (RBAC)** - Твой пользователь/ServiceAccount может не иметь права на создание ephemeral containers или debug-подов. - Тогда будут ошибки PermissionDenied / Forbidden. 5. **Ограниченная сборка k3s** - Иногда поставщики делают “облегчённые” сборки, вырезая часть фич. 👉 На практике, если `kubectl debug` не работает: ```bash kubectl version ``` и смотри различия `Client Version` vs `Server Version`. --- ## 5. Примеры для отладки сети, DNS, volume, environment Предположим, у нас есть проблемный pod `buggypod`. ### 5.1. Отладка сети / соединений Запускаем debug-контейнер c сеткой pod’а: ```bash kubectl debug buggypod -it --image=debian --share-processes -- bash ``` Внутри: ```bash apt update && apt install -y curl iproute2 dnsutils # Проверить доступность сервиса по IP: ping 10.43.0.1 # Проверить доступность внешнего сайта: curl -v https://google.com # Посмотреть открытые соединения: ss -tulnp ``` ### 5.2. Отладка DNS Внутри debug-контейнера: ```bash # Посмотреть DNS настройки cat /etc/resolv.conf # Проверить, резолвится ли сервис kubernetes nslookup kubernetes.default.svc.cluster.local # Проверить резолв внешнего домена nslookup books.thedevops.dev ``` Если `nslookup kubernetes.default` не работает — проблема с kube-dns/CoreDNS. ### 5.3. Отладка volume Если используешь режим копии pod (с `--copy-to` и теми же volume): ```bash kubectl debug buggypod --image=debian --copy-to=buggypod-debug -it -- bash ``` Внутри: ```bash # Посмотреть смонтированные файловые системы mount | grep /data # Проверить содержимое volume ls -lah /data df -h ``` Если volume не примонтирован или пустой — значит проблема в манифесте (Volume/VolumeMount) или в CSI/Longhorn. ### 5.4. Отладка environment (переменные окружения) Внутри debug-контейнера, если он разделяет process/namespace или создан как копия pod: ```bash env | sort ``` Смотри: - `DB_HOST`, `DB_PORT` - `POD_NAME`, `POD_NAMESPACE` - `SERVICE_*` --- ![[Pasted image 20251128083630.png]]