Огляд
Редагування ресурсу за допомогою стандартного редактора.
Команда edit дозволяє вам безпосередньо редагувати будь-який ресурс API, який ви можете отримати за допомогою інструментів командного рядка. Вона відкриє редактор, визначений вашими змінними оточення KUBE_EDITOR або EDITOR, або відкриє "vi" для Linux чи "notepad" для Windows. Під час спроби відкрити редактор спочатку буде використано оболонку, визначену у змінній оточення 'SHELL'. Якщо її не визначено, буде використано стандартну оболонку, якою є "/bin/bash" для Linux або "cmd" для Windows.
Ви можете редагувати декілька обʼєктів, хоча зміни застосовуються по одній за раз. Команда приймає імена файлів, а також аргументи командного рядка, хоча файли, на які ви вказуєте, мають бути попередньо збереженими версіями ресурсів.
Редагування виконується за допомогою версії API, використаної для отримання ресурсу. Щоб редагувати з використанням певної версії API, повністю вкажіть ресурс, версію і групу.
Стандартний формат — YAML. Для редагування у форматі JSON вкажіть "-o json".
Прапорець --windows-line-endings може бути використаний для забезпечення примусового завершення рядків у форматі Windows, інакше буде використано типовий для вашої операційної системи.
Якщо під час оновлення виникне помилка, на диску буде створено тимчасовий файл, який міститиме ваші незастосовані зміни. Найпоширенішою помилкою при оновленні ресурсу є зміна ресурсу на сервері іншим редактором. У цьому випадку вам доведеться застосувати ваші зміни до новішої версії ресурсу або оновити вашу тимчасову збережену копію, щоб вона містила останню версію ресурсу.
kubectl edit (RESOURCE/NAME | -f FILENAME)
Приклади
# Змінити сервіс з назвою 'registry'
kubectl edit svc/registry
# Використовувати альтернативний редактор
KUBE_EDITOR="nano" kubectl edit svc/registry
# Редагувати job 'myjob' у форматі JSON з використанням формату API v1
kubectl edit job.v1.batch/myjob -o json
# Редагувати deployment 'mydeployment' в YAML і зберегти змінений конфіг в його анотації
kubectl edit deployment/mydeployment -o yaml --save-config
# Редагувати субресурс 'status' для deployment 'mydeployment'
kubectl edit deployment mydeployment --subresource='status'
Параметри
| --allow-missing-template-keys Типово: true | |
Якщо true, ігнорувати будь-які помилки в шаблонах, коли в шаблоні відсутнє поле або ключ map. Застосовується лише до форматів виводу golang та jsonpath. | |
| --field-manager string Типово: "kubectl-edit" | |
Імʼя менеджера, що використовується для відстеження права власності на поле. | |
| -f, --filename strings | |
Імʼя файлу, теки або URL до файлів, для редагування ресурсів | |
| -h, --help | |
Довідка edit | |
| -k, --kustomize string | |
Обробити теку kustomization. Цей прапорець не можна використовувати разом з -f або -R. | |
| -o, --output string | |
Формат виводу. Один з: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file). | |
| --output-patch | |
Вивести патч, якщо ресурс редагується. | |
| -R, --recursive | |
Рекурсивно обробити теку, вказану у -f, --filename. Корисно, якщо ви хочете керувати повʼязаними маніфестами, організованими в одній теці. | |
| --save-config | |
Якщо значення true, конфігурація поточного обʼєкта буде збережена в його анотації. В іншому випадку, анотацію буде збережено без змін. Цей прапорець корисно встановити, якщо ви хочете застосувати kubectl до цього обʼєкта у майбутньому. | |
| --show-managed-fields | |
Якщо true, зберігати managedFields при виводі обʼєктів у форматі JSON або YAML. | |
| --subresource string | |
Якщо вказано, редагування працюватиме з субресурсом запитуваного обʼєкта. Цей прапорець є бета-версією і може змінюватися у майбутньому. | |
| --template string | |
Рядок шаблону або шлях до файлу шаблону для використання з -o=go-template, -o=go-template-file. Формат шаблону — golang-шаблони [http://golang.org/pkg/text/template/#pkg-overview]. | |
| --validate string[="strict"] Типово: "strict" | |
Повинно бути одним із: strict (або true), warn, ignore (або false). "true" або "strict" буде використовувати схему для перевірки вводу і відхилятиме запит, якщо він невірний. Буде виконана перевірка на стороні сервера, якщо ServerSideFieldValidation увімкнено на api-server, але якщо ні, то повернеться до менш надійної перевірки на стороні клієнта. "warn" попередить про невідомі або повторювані поля, не блокуючи запит, якщо на боці сервера API увімкнено перевірку полів, і буде поводитися як " ignore" у протилежному випадку. "false" або "ignore" не виконуватимуть жодної перевірки схеми, мовчки відкидаючі будь-які невідомі або дубльовані поля. | |
| --windows-line-endings | |
Стандартно використовується закінчення рядка, притаманне вашій платформі. | |
Параметри батьківських команд
| --as string | |
Імʼя користувача, яке використовується для виконання операції. Користувач може бути звичайним користувачем або службовим обліковим записом в просторі імен. | |
| --as-group strings | |
Група, яка використовується для операції; цей прапорець можна повторити для вказівки декількох груп. | |
| --as-uid string | |
UID, який використовується для операції. | |
| --cache-dir string Типово: "$HOME/.kube/cache" | |
Типове розташування теки кешу | |
| --certificate-authority string | |
Шлях до файлу сертифіката для центра сертифікації | |
| --client-certificate string | |
Шлях до файлу клієнтського сертифіката для TLS | |
| --client-key string | |
Шлях до файлу ключа клієнта для TLS | |
| --cluster string | |
Назва файлу kubeconfig кластера, який слід використовувати | |
| --context string | |
Назва контексту kubeconfig, який слід використовувати | |
| --default-not-ready-toleration-seconds int Типово: 300 | |
Вказує tolerationSeconds для toleration notReady:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності. | |
| --default-unreachable-toleration-seconds int Типово: 300 | |
Вказує tolerationSeconds для toleration unreachable:NoExecute, який типово додається до кожного Pod, який ще не має такої толерантності. | |
| --disable-compression | |
Якщо true, відмовляється від стиснення відповіді для всіх запитів до сервера | |
| --insecure-skip-tls-verify | |
Якщо true, сертифікат сервера не буде перевірятися на дійсність. Це зробить ваші HTTPS-зʼєднання небезпечними | |
| --kubeconfig string | |
Шлях до файлу kubeconfig, який слід використовувати для CLI-запитів. | |
| --match-server-version | |
Вимагає, щоб версія сервера відповідала версії клієнта | |
| -n, --namespace string | |
Якщо присутній, простір імен для цього CLI-запиту | |
| --password string | |
Пароль для базової автентифікації на API-сервері | |
| --profile string Типово: "none" | |
Імʼя профілю для захоплення. Одне із (none|cpu|heap|goroutine|threadcreate|block|mutex) | |
| --profile-output string Типово: "profile.pprof" | |
Імʼя файлу, в який записується профіль | |
| --request-timeout string Типово: "0" | |
Час очікування перед відмовою у виконанні окремого запиту до сервера. Ненульові значення повинні містити відповідну одиницю часу (наприклад, 1s, 2m, 3h). Значення нуль означає відсутність тайм-ауту запитів. | |
| -s, --server string | |
Адреса та порт сервера API Kubernetes | |
| --storage-driver-buffer-duration duration Типово: 1m0s | |
Записи в драйвері зберігання будуть буферизовані на цей час і збережені в бекендах без памʼяті як одна транзакція | |
| --storage-driver-db string Типово: "cadvisor" | |
Назва бази даних | |
| --storage-driver-host string Типово: "localhost:8086" | |
Хост:порт бази даних | |
| --storage-driver-password string Типово: "root" | |
Пароль бази даних | |
| --storage-driver-secure | |
використовувати захищене зʼєднання з базою даних | |
| --storage-driver-table string Типово: "stats" | |
Назва таблиці | |
| --storage-driver-user string Типово: "root" | |
Імʼя користувача бази даних | |
| --tls-server-name string | |
Імʼя сервера, яке використовується для перевірки дійсності сертифіката сервера. Якщо воно не надане, використовується імʼя хоста, яке використовується для звʼязку з сервером | |
| --token string | |
Токен на предʼявника для автентифікації на API-сервері | |
| --user string | |
Імʼя користувача kubeconfig, яке слід використовувати | |
| --username string | |
Імʼя користувача для базової автентифікації на API-сервері | |
| --version version[=true] | |
--version, --version=raw виводить інформацію про версію та завершує роботу; --version=vX.Y.Z... задає відповідну версію | |
| --warnings-as-errors | |
Трактувати попередження, отримані від сервера, як помилки і виходити з ненульовим кодом виходу | |
Дивіться також
- kubectl — kubectl керує менеджером кластерів Kubernetes