# Власники та Залежності

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

---

<!-- overview -->

В Kubernetes деякі <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> є
*власниками* інших обʼєктів. Наприклад, <a class='glossary-tooltip' title='ReplicaSet забезпечує наявність певної кількості реплік обʼєкта Pod в поточний момент часу' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/replicaset/' target='_blank' aria-label='ReplicaSet'>ReplicaSet</a> є власником групи Podʼів. Ці обʼєкти, якими володіють, є *залежними* від свого власника.

Власність відрізняється від [механізму міток та селекторів](/docs/concepts/overview/working-with-objects/labels/), який також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти `EndpointSlice`. Service використовує <a class='glossary-tooltip' title='Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='мітки'>мітки</a> щоби панель управління могла визначити, які обʼєкти `EndpointSlice` використовуються для цього Service. Крім міток, кожен `EndpointSlice`, який керується від імені Service, має посилання на власника. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують.

## Посилання на власника в специфікаціях обʼєктів {#owner-references-in-object-specifications}

Залежні обʼєкти мають поле `metadata.ownerReferences`, яке містить посилання на їх власника. Дійсне посилання на власника складається з назви обʼєкта та <a class='glossary-tooltip' title='Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/names' target='_blank' aria-label='UID'>UID</a> в межах того ж <a class='glossary-tooltip' title='Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/namespaces' target='_blank' aria-label='простору імен'>простору імен</a>, що й залежний обʼєкт. Kubernetes автоматично встановлює значення цього поля для обʼєктів, які є залежностями інших обʼєктів, таких як ReplicaSets, DaemonSets, Deployments, Jobs та CronJobs, та ReplicationControllers. Ви також можете налаштувати ці звʼязки вручну, змінивши значення цього поля. Однак зазвичай цього не потрібно робити, і можна дозволити Kubernetes автоматично керувати цими звʼязками.

Залежні обʼєкти також мають поле `ownerReferences.blockOwnerDeletion`, яке має булеве значення і контролює, чи можуть певні залежні обʼєкти блокувати збір сміття, що видаляє їх власника. Kubernetes автоматично встановлює це поле в `true`, якщо <a class='glossary-tooltip' title='Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/controller/' target='_blank' aria-label='контролер'>контролер</a> (наприклад, контролер Deployment) встановлює значення поля `metadata.ownerReferences`. Ви також можете встановити значення поля `blockOwnerDeletion` вручну, щоб контролювати, які залежні обʼєкти блокують збір сміття.

Контролер доступу Kubernetes контролює доступ користувачів для зміни цього поля для залежних ресурсів на основі прав видалення власника. Це керування перешкоджає несанкціонованим користувачам затримувати видалення обʼєкта-власника.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><p>Посилання на власника поза межами простору імен заборонені. Залежні обʼєкти в просторі імен можуть вказувати власників або на рівні кластера, або в тому ж просторі імен. Якщо цього не відбувається, посилання на власника розглядається як відсутнє, і залежний обʼєкт може бути видалений, якщо всі власники визначено як відсутні.</p>
<p>Залежні обʼєкти на рівні кластера можуть вказувати лише власників на рівні кластера. У версії v1.20+, якщо залежний обʼєкт на рівні кластера вказує тип з простором імен як власника, він розглядається як обʼєкт з нерозвʼязаним посиланням на власника і не може бути вилучений.</p>
<p>У v1.20+, якщо збирач сміття виявляє недійсний перехресний простір імен <code>ownerReference</code> або залежний обʼєкт на рівні кластера з <code>ownerReference</code>, що посилається на тип простору імен, зʼявляється повідомлення з попередженням з причиною <code>OwnerRefInvalidNamespace</code> та <code>involvedObject</code> про недійсного залежного. Ви можете перевірити наявність такого роду подій (Event), запустивши <code>kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace</code>.</p>
</div>


## Власність та завершувачі {#ownership-and-finalizers}

Коли ви наказуєте Kubernetes видалити ресурс, сервер API дозволяє керуючому контролеру обробити будь-які [правила завершувача](/docs/concepts/overview/working-with-objects/finalizers/) для ресурсу. <a class='glossary-tooltip' title='Ключ простору імен, який наказує Kubernetes чекати до виконання певних умов перед тим, як повністю видалити обʼєкт, позначений для видалення.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/finalizers/' target='_blank' aria-label='Завершувачі'>Завершувачі</a> запобігають випадковому видаленню ресурсів, які вашому кластеру можуть ще бути потрібні для коректної роботи. Наприклад, якщо ви намагаєтеся видалити [PersistentVolume](/docs/concepts/storage/persistent-volumes/), який все ще використовується Podʼом, видалення не відбувається негайно, оскільки `PersistentVolume` має завершувач `kubernetes.io/pv-protection`. Замість цього [том](/docs/concepts/storage/volumes/) залишається в стані `Terminating` до тих пір, поки Kubernetes не очистить завершувач, що відбувається тільки після того, як `PersistentVolume` більше не привʼязаний до Podʼа.

Kubernetes також додає завершувачів до ресурсу-власника, коли ви використовуєте або [каскадне видалення на передньому плані або каскадне видалення сиріт](/docs/concepts/architecture/garbage-collection/#cascading-deletion). При видаленні у передньому плані додається завершувач `foreground`, так що контролер повинен видалити залежні ресурси, які також мають `ownerReferences.blockOwnerDeletion=true`, перш ніж він видалить власника. Якщо ви вказуєте політику видалення покинутих ресурсів (сиріт), Kubernetes додає завершувач `orphan`, так що контролер ігнорує залежні ресурси після того, як він видаляє обʼєкт-власника.

## Що далі

* Дізнайтеся більше про [завершувачі Kubernetes](/docs/concepts/overview/working-with-objects/finalizers/).
* Дізнайтеся про [збір сміття](/docs/concepts/architecture/garbage-collection).
* Прочитайте API-довідник про [метадані обʼєкта](/docs/reference/kubernetes-api/common-definitions/object-meta/#System).