# Назви та Ідентифікатори Обʼєктів

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

---

<!-- overview -->

Кожен <a class='glossary-tooltip' title='Сутність у системі Kubernetes, що представляє частину стану вашого кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/#kubernetes-objects' target='_blank' aria-label='обʼєкт'>обʼєкт</a> у вашому кластері має [_Назву (імʼя)_](#names), яка є унікальною для цього типу ресурсу. Кожен обʼєкт Kubernetes також має [_UID_](#uids), який є унікальним в усьому вашому кластері.

Наприклад, ви можете мати лише один обʼєкт Pod із назвою `myapp-1234` в одному й тому ж [просторі імен](/docs/concepts/overview/working-with-objects/namespaces/), а також ви можете мати один обʼєкт Pod та один Deployment із назвами `myapp-1234` кожен.

Для неунікальних атрибутів, наданих користувачем, Kubernetes надає [мітки (labels)](/docs/concepts/overview/working-with-objects/labels/) та [анотації (annotations)](/docs/concepts/overview/working-with-objects/annotations/).

<!-- body -->

## Назви {#names}

<p>Наданий клієнтом рядок, який посилається на обʼєкт в URL <a class='glossary-tooltip' title='Сутність Kubernetes, що представляє точку доступу сервера Kubernetes API.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/using-api/api-concepts/#standard-api-terminology' target='_blank' aria-label='ресурсу'>ресурсу</a>, наприклад <code>/api/v1/pods/some-name</code>.</p>
<p>Тільки один обʼєкт вказаного виду (kind) може мати вказану назву одночасно. Проте, якщо ви видаляєте обʼєкт, ви можете створити новий обʼєкт з такою ж назвою.</p>

Назви повинні бути унікальними між усіма [версіями API](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) того ж самого ресурсу.

Kubernetes унікально ідентифікує обʼєкти за допомогою комбінації чотирьох атрибутів:

* **API група** (наприклад, `apps`)
* **Тип ресурсу** (наприклад, `deployments`)
* **Простір імен** (для ресурсів із просторами імен)
* **Назва**

Хоча ви можете отримати доступ до ресурсу через різні версії API (наприклад, `v1` або `v1beta1`), версія є просто іншим представленням того самого базового обʼєкта. Оскільки версія не є частиною унікальної ідентифікації, ви не можете створити два обʼєкти з однаковою назвою та типом ресурсу в одному просторі імен, використовуючи різні версії API.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>У випадках, коли обʼєкти представляють фізичний обʼєкт, наприклад, Node, що представляє фізичний хост, коли хост перестворюється з тією ж самою назвою без видалення та перестворення Node, Kubernetes розглядає новий хост як старий, що може призвести до неузгодженостей.</div>


Сервер може згенерувати імʼя, якщо в запиті на створення ресурсу замість `name` вказати `generateName`. Коли використовується `generateName`, надане значення використовується як префікс імені, до якого сервер додає згенерований суфікс. Навіть якщо імʼя згенеровано, воно може конфліктувати з наявними іменами, що призведе до відповіді HTTP 409. Це стало набагато менш імовірним в Kubernetes v1.31 і пізніших версіях, оскільки сервер зробить до 8 спроб згенерувати унікальне імʼя перед тим, як повернути відповідь HTTP 409.

Нижче наведено чотири типи обмежень на назви ресурсів, які часто використовуються.

### Назви DNS-піддоменів {#dns-subdomain-names}

Більшість типів ресурсів потребують назви, яку можна використовувати як DNS-піддомен згідно з [RFC 1123](https://tools.ietf.org/html/rfc1123). Це означає, що назва повинна:

- містити не більше 253 символів
- містити лише буквено-цифрові символи, '-' чи '.' в нижньому регістрі
- починатися буквено-цифровим символом
- закінчуватися буквено-цифровим символом

### Назви міток RFC 1123 {#dns-label-names}

Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в [RFC 1123](https://tools.ietf.org/html/rfc1123). Це означає, що назва повинна:

- містити не більше 63 символів
- містити лише буквено-цифрові символи чи '-' в нижньому регістрі
- починатися алфавітним символом
- закінчуватися буквено-цифровим символом


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Коли увімкнено <code>RelaxedServiceNameValidation</code>, назви обʼєктів Service можуть починатися з цифри.</div>


### Назви міток RFC 1035 {#rfc-1035-label-names}

Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в [RFC 1035](https://tools.ietf.org/html/rfc1035). Це означає, що назва повинна:

- містити не більше 63 символів
- містити лише буквено-цифрові символи чи '-' в нижньому регістрі
- починатися алфавітним символом
- закінчуватися буквено-цифровим символом


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Хоча RFC 1123 технічно дозволяє міткам починатися з цифри, поточна реалізація Kubernetes вимагає, щоб мітки як RFC 1035, так і RFC 1123 починалися з літери. Винятком є увімкнення <code>RelaxedServiceNameValidation</code> для обʼєктів Service,
що дозволяє назвам Service починатися з цифри.</div>


### Назви сегментів шляху {#path-segment-names}

Деякі типи ресурсів вимагають, щоб їх назви можна було безпечно кодувати як сегмент шляху. Іншими словами, назва не може бути "." або "..", і вона не може
містити "/" або "%".

Ось приклад маніфесту для Pod із назвою `nginx-demo`.

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
```


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Деякі типи ресурсів мають додаткові обмеження на їх назви.</div>


## UID {#uids}

<p>Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів.</p>
<p>Кожен обʼєкт, створений протягом усього життя кластера Kubernetes, має відмінний UID. Він призначений для відмінності між історичними випадками схожих сутностей.</p>

UID Kubernetes — це унікальні ідентифікатори, також відомі як UUID (узгоджені універсальні ідентифікатори). UUID стандартизовані згідно з ISO/IEC 9834-8 та ITU-T X.667.

## Що далі

- Дізнайтеся більше про [мітки (labels)](/docs/concepts/overview/working-with-objects/labels/) та [анотації (annotations)](/docs/concepts/overview/working-with-objects/annotations/) в Kubernetes.
- Перегляньте документ [Ідентифікатори та Назви в Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md).