# Правила використання kubectl

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->
Рекомендовані правила використання `kubectl`.

<!-- body -->

## Використання `kubectl` у багаторазових скриптах {#using-kubectl-in-reusable-scripts}

Для стабільного виводу у скрипті:

* Використовуйте одну з машинно-орієнтованих форм виводу, таких як `-o name`, `-o json`, `-o yaml`, `-o go-template`, або `-o jsonpath`.
* Повністю вказуйте версію. Наприклад, `jobs.v1.batch/myjob`. Це гарантує, що kubectl не використовуватиме свою стандартну версію, яка може змінюватися з часом.
* Не покладайтеся на контекст, налаштування або інші неявні стани.

## Субресурси {#subresources}

* Ви можете використовувати аргумент `--subresource` для команд kubectl, таких як `get`, `patch`, `edit`, `apply` та `replace` для отримання та оновлення субресурсів для всіх ресурсів, які їх підтримують. В Kubernetes версії 1.36 підтримуються лише субресурси `status`, `scale` та `resize`.
  * Для `kubectl edit`, субресурс `scale` не підтримується. Якщо ви використовуєте `--subresource` з `kubectl edit` і вказуєте `scale` як субресурс, команда викличе помилку.
* Контракт API для субресурсу ідентичний до повного ресурсу. Оновлюючи субресурс `status` до нового значення, майте на увазі, що субресурс може бути потенційно узгоджений контролером до іншого значення.

## Рекомендації {#best-practices}

### `kubectl run`

Для того, щоб `kubectl run` відповідав принципу інфраструктури як код:

* Присвойте образу версію зі специфічним теґом і не переносіть цей теґ на нову версію. Наприклад, використовуйте `:v1234`, `v1.2.3`, `r03062016-1-4`, а не `:latest` (Для отримання додаткової інформації дивіться [Поради щодо конфігурації Kubernetes](/blog/2025/11/25/configuration-good-practices/)).
* Перевірте в скрипті наявність образу з великою кількістю параметрів.
* Перейдіть до файлів конфігурації, перевірених у контролі вихідного коду, для отримання можливостей, які є необхідними, але не можуть бути виражені за допомогою прапорців `kubectl run`.

Ви можете використовувати прапорець `--dry-run=client`, щоб переглянути обʼєкт, який буде відправлений до вашого кластера, без реального його надсилання.

### `kubectl proxy`

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Увага:</h4><p>Перегляд ненадійних точок доступу подів або сервісів через <code>kubectl proxy</code> є небезпечним, оскільки обслуговуваний вміст має неявний доступ до API Kubernetes за допомогою облікових даних проксі. Будьте обережні та уникайте доступу до ненадійних точок доступу під час використання привілейованих облікових даних.</p>
<p>Щоб зменшити ризик:</p>
<ul>
<li>Уникайте перегляду ненадійних подів або сервісів через <code>kubectl proxy</code>.</li>
<li>Використовуйте <code>--reject-methods='POST,PUT,PATCH,DELETE'</code>, щоб обмежити проксі лише операціями читання, коли вам потрібно лише переглядати ресурси.</li>
<li>Використовуйте <code>--reject-paths</code>, щоб обмежити, які шляхи API проксі відкриває.</li>
<li>Не запускайте <code>kubectl proxy</code> з обліковими даними cluster-admin, якщо це не необхідно.</li>
</ul>
</div>


### `kubectl apply`

* Ви можете використовувати `kubectl apply` для створення або оновлення ресурсів. Для отримання додаткової інформації про використання kubectl apply для оновлення ресурсів, дивіться [Kubectl Book](https://kubectl.docs.kubernetes.io).