...
```
Використовуйте `kubectl delete`, щоб видалити Pod, коли ви закінчите:
```shell
kubectl delete pod ephemeral-demo
```
## Налагодження за допомогою копії Podʼа {#debugging-using-copy-of-the-pod}
Іноді параметри конфігурації Podʼа ускладнюють усунення несправностей у певних ситуаціях. Наприклад, ви не можете виконувати `kubectl exec`, щоб усунути несправності у вашому контейнері, якщо ваш образ контейнера не містить оболонки або якщо ваш застосунок аварійно завершується при запуску. У цих ситуаціях ви можете використовувати `kubectl debug`, щоб створити копію Podʼа зі зміненими значеннями конфігурації для полегшення налагодження.
### Копіювання Podʼа з додаванням нового контейнера {#copying-a-pod-while-adding-a-new-container}
Додавання нового контейнера може бути корисним, коли ваш застосунок працює, але не так, як ви очікували, і ви хочете додати додаткові засоби усунення несправностей до Podʼа.
Наприклад, можливо, образ контейнера вашого застосунку збудований на основі `busybox`, але вам потрібні засоби для налагодження, які не включені в `busybox`. Ви можете симулювати цей сценарій за допомогою `kubectl run`:
```shell
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
Виконайте цю команду, щоб створити копію `myapp` з назвою `myapp-debug`, яка додає новий контейнер Ubuntu для налагодження:
```shell
kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
```
```none
Defaulting debug container name to debugger-w7xmf.
If you don't see a command prompt, try pressing enter.
root@myapp-debug:/#
```
Примітка:
kubectl debug автоматично генерує назву контейнера, якщо ви не вибрали одну за допомогою прапорця --container.- Прапорець
-i стандартно призводить до приєднання kubectl debug до нового контейнера. Ви можете запобігти цьому, вказавши --attach=false. Якщо ваша сесія розірвана, ви можете повторно приєднатися за допомогою kubectl attach.
--share-processes дозволяє контейнерам в цьому Podʼі бачити процеси з інших контейнерів у Podʼі. Для отримання додаткової інформації про те, як це працює, див. Спільне використання простору імен процесу між контейнерами в Podʼі.
Примітка:
- Щоб змінити команду для конкретного контейнера, вам потрібно вказати його назву за допомогою
--container, інакше kubectl debug створить новий контейнер для виконання вказаної вами команди.
- Прапорець
-i призводить до того, що kubectl debug автоматично приєднується до контейнера. Ви можете це запобігти, вказавши --attach=false. Якщо ваша сесія розірвана, ви можете повторно приєднатися за допомогою kubectl attach.
Примітка:
Не забудьте прибрати Pod для налагодження, коли ви закінчите з ним:
kubectl delete pod node-debugger-mynode-pdx84
Примітка:
Якщо ви не вкажете --profile, стандартно використовується профіль legacy, але його планується найближчим часом визнати застарілим. Тому рекомендується використовувати інші профілі, такі як general.
Припустимо, що ви створюєте Pod і налагоджуєте його. Спочатку створіть Pod з назвою `myapp`, наприклад:
```shell
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
Потім, перевірте Pod за допомогою ефемерного контейнера. Якщо ефемерному контейнеру потрібно мати привілеї, ви можете використовувати профіль `sysadmin`:
```shell
kubectl debug -it myapp --image=busybox:1.28 --target=myapp --profile=sysadmin
```
```none
Targeting container "myapp". If you don't see processes from this container it may be because the container runtime doesn't support this feature.
Defaulting debug container name to debugger-6kg4x.
If you don't see a command prompt, try pressing enter.
/ #
```
Перевірте можливості процесу ефемерного контейнера, виконавши наступну команду всередині контейнера:
```shell
/ # grep Cap /proc/$$/status
```
```none
...
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
...
```
Це означає, що процес контейнера наділений усіма можливостями як привілейований контейнер завдяки застосуванню профілю `sysadmin`. Дивіться більше деталей про [можливості](/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container).
Ви також можете перевірити, що ефемерний контейнер був створений як привілейований контейнер:
```shell
kubectl get pod myapp -o jsonpath='{.spec.ephemeralContainers[0].securityContext}'
```
```none
{"privileged":true}
```
Очистіть Pod, коли ви закінчите з ним:
```shell
kubectl delete pod myapp
```
### Застосування профілю custom {#custom-profile}
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.32 [stable]
Ви можете визначити часткову специфікацію контейнера для налагодження як профіль custom у форматі JSON або YAML, та застосувати її з прапорцем `--custom`.
Примітка:
Профіль custom підтримує лише зміну специфікації контейнера, однак зміни полів name, image, command, lifecycle та volumeDevices не дозволяються. Також не підтримується зміна специфікації Podʼа.
Створіть Pod з назвою `myapp`, наприклад:
```shell
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
Створіть профіль custom у форматі JSON або YAML. Тут ми створимо файл `custom-profile.yaml` з наступним вмістом:
```yaml
env:
- name: ENV_VAR_1
value: value_1
- name: ENV_VAR_2
value: value_2
securityContext:
capabilities:
add:
- NET_ADMIN
- SYS_TIME
```
Виконайте наступну команду для налагодження Podʼа з використанням ефемерного контейнера з профілем custom:
```shell
kubectl debug -it myapp --image=busybox:1.28 --target=myapp --profile=general --custom=custom-profile.yaml
```
Ви можете перевірити, що ефемерний контейнер було додано до Podʼа з вказаним профілем custom:
```shell
kubectl get pod myapp -o jsonpath='{.spec.ephemeralContainers[0].env}'
```
```none
[{"name":"ENV_VAR_1","value":"value_1"},{"name":"ENV_VAR_2","value":"value_2"}]
```
```shell
kubectl get pod myapp -o jsonpath='{.spec.ephemeralContainers[0].securityContext}'
```
```none
{"capabilities":{"add":["NET_ADMIN","SYS_TIME"]}}
```
Закінчивши роботу, очистіть Pod:
```shell
kubectl delete pod myapp
```
