# Kubernetes v1.34: Налаштування користувача (kuberc) доступні для тестування в kubectl 1.34

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

---

Чи хотіли ви будь-коли, щоб ви могли мати стандартно увімкнене [інтерактивне видалення](https://kep.k8s.io/3895) у `kubectl`? Або, можливо, ви хочете визначити власні псевдоніми, але не обовʼязково [генерувати сотні з них вручну](https://github.com/ahmetb/kubectl-aliases)? Шукайте далі. [SIG-CLI](https://git.k8s.io/community/sig-cli/) наполегливо працює над додаванням [налаштувань користувача до kubectl](https://kep.k8s.io/3104), і ми раді оголосити, що ця функціональність досягає бета-версії в рамках випуску Kubernetes v1.34.

## Як це працює {#how-it-works}

Повний опис цієї функціональності доступний [в нашій офіційній документації](/docs/reference/kubectl/kuberc/), але в цьому дописі ми відповімо на обидва питання з початку цієї статті.

Перед тим, як зануритися в деталі, давайте швидко розглянемо, як виглядає файл налаштувань користувача та де його розмістити. Типово `kubectl` буде шукати файл `kuberc` у вашій стандартній теці [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), яка знаходиться за адресою `$HOME/.kube`. Альтернативно, ви можете вказати це місце за допомогою параметра `--kuberc` або змінної середовища `KUBERC`.

Як і кожен маніфест Kubernetes, файл `kuberc` почнеться з `apiVersion` та `kind`:

```yaml
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
# тут будуть відображатися налаштування користувача
```

### Defaults

Почнемо з налаштування стандартних значень для параметрів команд `kubectl`. Наша мета — завжди використовувати інтерактивне видалення, що означає, що ми хочемо, щоб параметр `--interactive` для `kubectl delete` завжди був встановлений на `true`. Це можна досягти, додавши наступний фрагмент до нашого файлу `kuberc`:

```yaml
defaults:
- command: delete
  options:
  - name: interactive
    default: "true"
```

В цьому прикладі ми представляємо секцію `defaults`, яка дозволяє користувачам визначати стандартні значення для параметрів `kubectl`. У цьому випадку ми встановлюємо параметр інтерактивності для `kubectl delete` на `true`. Це значення можна перевизначити, якщо користувач явно надає інше значення, наприклад, `kubectl delete --interactive=false`, в цьому випадку явний параметр має пріоритет.

Ще одне дуже рекомендоване типове значення від SIG-CLI — це використання [Server-Side Apply](/docs/reference/using-api/server-side-apply/). Щоб це зробити, ви можете додати наступний фрагмент до ваших налаштувань:

```yaml
# продовження розділу defaults
- command: apply
  options:
  - name: server-side
    default: "true"
```

### Aliases

Можливість визначати аліаси дозволяє нам заощаджувати дорогоцінні секунди під час введення команд. Я впевнений, що ви, напевно, маєте один визначений для `kubectl`, оскільки введення семи літер безумовно займає більше часу, ніж просто натискання `k`.

З цієї причини можливість визначати аліаси була обовʼязковою, коли ми вирішили реалізувати налаштування користувача, поряд з установкою стандартних значень. Щоб визначити аліас для будь-якої з вбудованих команд, розширте свій файл `kuberc` наступним:

```yaml
aliases:
- name: gns
  command: get
  prependArgs:
   - namespace
  options:
   - name: output
     default: json
```

Там багато чого відбувається, тому давайте розберемо це по черзі. По-перше, ми вводимо новий розділ: `aliases`. Тут ми визначаємо новий аліас `gns`, який відображається на команду `get`. Далі ми визначаємо аргументи (`namespace` ресурс), які будуть вставлені відразу після назви команди. Крім того, ми встановлюємо опцію `--output=json` для цього аліаса. Структура блоку `options` ідентична тій, що в розділі `defaults`.

Ви, напевно, помітили, що ми представили механізм для попереднього додавання аргументів, і ви можете запитати, чи є відповідне налаштування для їх додавання в кінці (іншими словами, додавання в кінець команди, після аргументів, наданих користувачем). Це можна досягти за допомогою блоку `appendArgs`, який представлений нижче:

```yaml
# продовження розділу aliases
- name: runx
  command: run
  options:
    - name: image
      default: busybox
    - name: namespace
      default: test-ns
  appendArgs:
    - --
    - custom-arg
```

Тут ми вводимо ще один аліас: `runx`, який викликає команду `kubectl run`, передаючи параметри `--image` і `--namespace` з попередньо визначеними значеннями, а також додаючи `--` і `custom-arg` в кінці виклику.

## Відлагодження {#debugging}

Ми сподіваємося, що налаштування користувача `kubectl` відкриє нові можливості для наших користувачів. Коли у вас виникають сумніви, не соромтеся запускати `kubectl` з підвищеною докладністю виводу. При `-v=5` ви повинні отримати всю можливу інформацію для відлагодження з цієї функції, що буде важливо при повідомленні про проблеми.

Щоб дізнатися більше, я закликаю вас ознайомитися з [нашою офіційною документацією](/docs/reference/kubectl/kuberc/) та [фактичною пропозицією](https://git.k8s.io/enhancements/keps/sig-cli/3104-introduce-kuberc/README.md).

## Долучайтесь {#get-involved}

Функція налаштувань користувача Kubectl досягла бета-версії, і ми дуже зацікавлені у ваших відгуках. Нам хотілося б почути, що вам подобається в ній і які проблеми ви хотіли б вирішити. Не соромтеся приєднуватися до [каналу SIG-CLI slack](https://kubernetes.slack.com/archives/C2GL57FJ4), або відкривати тікети в [репозиторії kubectl](https://git.k8s.io/kubectl/). Ви також можете приєднатися до наших [зустрічей спільноти](https://git.k8s.io/community/sig-cli/#meetings), які відбуваються кожну другу середу, і поділитися своїми історіями з нами.