Objects in Kubernetes

content/uk/docs/concepts/overview/working-with-objects/annotations.md

@@ -0,0 +1,80 @@
+---
+title: Анотації
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+Ви можете використовувати анотації Kubernetes, щоб додати довільні невизначені метадані до {{< glossary_tooltip text="обʼєктів" term_id="object" >}}.
+Клієнти, такі як інструменти та бібліотеки, можуть отримувати ці метадані.
+
+<!-- body -->
+
+## Додавання метаданих до обʼєктів {#attaching-metadata-to-objects}
+
+Ви можете використовувати як мітки, так і анотації для додавання метаданих до обʼєктів Kubernetes. Мітки можна використовувати для вибору обʼєктів та пошуку колекцій обʼєктів, які відповідають певним умовам. На відміну від цього, анотації не використовуються для ідентифікації та вибору обʼєктів. Метадані в анотації можуть бути невеликими або великими, структурованими або неструктурованими, і можуть включати символи, які не дозволяються міткам. Можна використовувати як мітки, так і анотації в метаданих того ж самого обʼєкта.
+
+Анотації, подібно до міток, є парами ключ/значення:
+
+```json
+"metadata": {
+  "annotations": {
+    "key1" : "value1",
+    "key2" : "value2"
+  }
+}
+```
+
+{{<note>}}
+Ключі та значення в парі повинні бути рядками. Іншими словами, ви не можете використовувати числові, булеві, спискові або інші типи як для ключів, так і для їх значень.
+{{</note>}}
+
+Ось кілька прикладів інформації, яку можна записати в анотаціях:
+
+* Поля, керовані декларативним рівнем конфігурації. Додавання цих полів як анотацій відмежовує їх від типових значень, встановлених клієнтами чи серверами, а також від автогенерованих полів та полів, встановлених системами автомасштабування.
+
+* Інформація про збірку, реліз чи образ, така як часові мітки, ідентифікатори релізу, гілка git, номера PR, хеші образу та адреса реєстру.
+
+* Вказівники на репозиторії логування, моніторингу, аналітики чи аудиту.
+
+* Інформація про клієнтську бібліотеку чи інструмент, яку можна використовувати для налагодження: наприклад, назва, версія та інформація про збірку.
+
+* Інформація про походження користувача чи інструменту/системи, така як URL-адреси повʼязаних обʼєктів з інших компонентів екосистеми.
+
+* Метадані інструменту легкого розгортання: наприклад, конфігурація чи контрольні точки.
+
+* Номери телефонів або пейджерів відповідальних осіб, чи записи в каталозі, які вказують, де можна знайти цю інформацію, наприклад, на вебсайті команди.
+
+* Директиви від кінцевого користувача до реалізації щодо зміни поведінки чи використання нестандартних функцій.
+
+Замість використання анотацій, ви можете зберігати цей тип інформації у зовнішній базі даних чи каталозі, але це ускладнило б створення загальних бібліотек та інструментів для впровадження, управління, інтроспекції, та подібного.
+
+## Синтаксис та набір символів {#syntax-and-character-set}
+
+_Анотації_ — це пари ключ/значення. Допустимі ключі анотацій мають два сегменти: необовʼязковий префікс і назва, розділені косою рискою (`/`). Назва є обовʼязковою та має містити не більше 63 символів, починаючи та закінчуючись буквено-цифровим символом (`[a-z0-9A-Z]`), тире (`-`), підкресленням (`_`), крапкою (`.`) та буквено-цифровими символами між ними. Префікс є необовʼязковим. Якщо вказано, префікс повинен бути піддоменом DNS: серією DNS-міток, розділених крапками (`.`), загальною довжиною не більше 253 символів, за якою слідує коса риска (`/`).
+
+Якщо префікс відсутній, ключ анотації вважається приватним для користувача. Автоматизовані компоненти системи (наприклад, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` чи інші автоматизовані засоби від сторонніх розробників), які додають анотації до обʼєктів кінцевого користувача, повинні вказати префікс.
+
+Префікси `kubernetes.io/` та `k8s.io/` зарезервовані для основних компонентів Kubernetes.
+
+Наприклад, ось маніфест для Pod, який має анотацію `imageregistry: https://hub.docker.com/`:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotations-demo
+  annotations:
+    imageregistry: "https://hub.docker.com/"
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.14.2
+    ports:
+    - containerPort: 80
+```
+
+## {{% heading "whatsnext" %}}
+
+* Дізнайтеся більше про [Мітки та Селектори](/docs/concepts/overview/working-with-objects/labels/).
+* Подивіться [Відомі мітки, Анотації та Позначення](/docs/reference/labels-annotations-taints/)

content/uk/docs/concepts/overview/working-with-objects/common-labels.md

@@ -0,0 +1,156 @@
+---
+title: Рекомендовані Мітки
+content_type: concept
+weight: 100
+---
+
+<!-- overview -->
+Ви можете візуалізувати та керувати обʼєктами Kubernetes за допомогою інших інструментів, ніж kubectl та панель інструментів (dashboard). Загальний набір міток дозволяє інструментам працювати між собою, описуючи обʼєкти спільним чином, який можуть розуміти всі інструменти.
+
+Крім підтримки інструментів, рекомендовані мітки описують застосунки так, що до них можна звертатись.
+
+<!-- body -->
+Метадані організовані навколо концепції _застосунку_. Kubernetes не є платформою як сервіс (PaaS) і не має формального поняття застосунку або його виконання. Замість цього застосунки є неформальними та описуються метаданими. Визначення того, що включає застосунок, є гнучким.
+
+{{< note >}}
+Це рекомендовані мітки. Вони полегшують управління застосунками, але не обовʼязкові для будь-яких основних інструментів.
+{{< /note >}}
+
+Спільні мітки та анотації мають спільний префікс: `app.kubernetes.io`. Мітки без префіксу є приватними для користувачів. Спільний префікс забезпечує, що спільні мітки не втручаються у власні мітки користувача.
+
+## Мітки {#labels}
+
+Щоб повною мірою скористатися цими мітками, їх слід застосовувати до кожного обʼєкта ресурсу.
+
+| Ключ                               | Опис                  | Приклад  | Тип |
+| ----------------------------------- | --------------------- | -------- | ---- |
+| `app.kubernetes.io/name`            | Назва застосунку         | `mysql` | рядок |
+| `app.kubernetes.io/instance`        | Унікальна назва, що ідентифікує екземпляр застосунку | `mysql-abcxzy` | рядок |
+| `app.kubernetes.io/version`         | Поточна версія застосунку (наприклад, [SemVer 1.0](https://semver.org/spec/v1.0.0.html), хеш ревізії і т.д.) | `5.7.21` | рядок |
+| `app.kubernetes.io/component`       | Компонент всередині архітектури | `database` | рядок |
+| `app.kubernetes.io/part-of`         | Назва вищого рівня застосунку, частину якого складає цей | `wordpress` | рядок |
+| `app.kubernetes.io/managed-by`      | Інструмент, який використовується для управління операцією застосунку | `helm` | рядок |
+
+Щоб проілюструвати ці мітки в дії, розгляньте наступний обʼєкт {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}:
+
+```yaml
+# Це уривок
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: mysql-abcxzy
+    app.kubernetes.io/version: "5.7.21"
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+    app.kubernetes.io/managed-by: helm
+```
+
+## Застосунки та екземпляри застосунків {#applications-and-application-instances}
+
+Застосунок можна встановити один або декілька разів в кластер Kubernetes і, у деяких випадках, в тому ж просторі імен. Наприклад, WordPress можна встановити більше одного разу, де різні вебсайти є різними екземплярами WordPress.
+
+Назва застосунку та назва екземпляра записуються окремо. Наприклад, у WordPress є `app.kubernetes.io/name` — `wordpress`, тоді як назва екземпляра представлена як `app.kubernetes.io/instance` зі значенням `wordpress-abcxzy`. Це дозволяє ідентифікувати застосунок та його екземпляр. Кожен екземпляр застосунку повинен мати унікальну назву.
+
+## Приклади {#examples}
+
+Щоб проілюструвати різні способи використання цих міток, наведено різні приклади складності.
+
+### Простий Stateless Service
+
+Розгляньте випадок простого Stateless Serviceʼу, розгорнутого за допомогою обʼєктів `Deployment` та `Service`. Наведені нижче два уривки представляють, як можуть бути використані мітки у їх найпростішій формі.
+
+`Deployment` використовується для нагляду за Podʼами, які виконують сам застосунок.
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+`Service` використовується для відкриття доступу до застосунку.
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: myservice
+    app.kubernetes.io/instance: myservice-abcxzy
+...
+```
+
+### Вебзастосунок із базою даних {#web-application-with-a-database}
+
+Розгляньмо трохи складніший застосунок: вебзастосунок (WordPress) із базою даних (MySQL), встановлений за допомогою Helm. Наведені нижче уривки ілюструють початок обʼєктів, які використовуються для розгортання цього застосунку.
+
+Початок цього `Deployment` використовується для WordPress:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+`Service` використовується для відкриття доступу до WordPress:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: wordpress
+    app.kubernetes.io/instance: wordpress-abcxzy
+    app.kubernetes.io/version: "4.9.4"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: server
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+MySQL представлено як `StatefulSet` з метаданими як для нього, так і для застосунку, до якого він належить:
+
+```yaml
+apiVersion: apps/v1
+kind: StatefulSet
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: mysql-abcxzy
+    app.kubernetes.io/version: "5.7.21"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+`Service` використовується для відкриття доступу до MySQL як частини WordPress:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/name: mysql
+    app.kubernetes.io/instance: mysql-abcxzy
+    app.kubernetes.io/version: "5.7.21"
+    app.kubernetes.io/managed-by: helm
+    app.kubernetes.io/component: database
+    app.kubernetes.io/part-of: wordpress
+...
+```
+
+З MySQL `StatefulSet` та `Service` ви побачите, що включена інформація як про MySQL, так і про WordPress.

content/uk/docs/concepts/overview/working-with-objects/field-selectors.md

@@ -0,0 +1,62 @@
+---
+title: Селектори полів
+content_type: concept
+weight: 70
+---
+
+_Селектори полів_ дозволяють вам вибирати обʼєкти Kubernetes на основі значень одного або кількох полів ресурсу. Ось кілька прикладів запитань для селекторів полів:
+
+* `metadata.name=my-service`
+* `metadata.namespace!=default`
+* `status.phase=Pending`
+
+Ця команда `kubectl` вибирає всі Podʼи, для яких значення поля [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) дорівнює `Running`:
+
+```shell
+kubectl get pods --field-selector status.phase=Running
+```
+
+{{< note >}}
+Селектори полів, по суті, є _фільтрами_ ресурсів. Типово селектори/фільтри не застосовуються, а це означає, що вибрані всі ресурси вказаного типу. Це робить запити kubectl `kubectl get pods` та `kubectl get pods --field-selector ""` еквівалентними.
+{{< /note >}}
+
+## Підтримувані поля {#supported-fields}
+
+Підтримувані селектори полів варіюються залежно від типу ресурсу Kubernetes. Усі типи ресурсів підтримують поля `metadata.name` та `metadata.namespace`. Використання селекторів до полів, що їх не підтримують, призводить до помилки. Наприклад:
+
+```shell
+kubectl get ingress --field-selector foo.bar=baz
+```
+
+```none
+Error from server  (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"
+```
+
+## Підтримувані оператори {#supported-operators}
+
+Ви можете використовувати оператори `=`, `==` та `!=` з селекторами полів (`=` та `==` означають те саме). Наприклад, ця команда `kubectl` вибирає всі сервіси Kubernetes, які не знаходяться в просторі імен `default`:
+
+```shell
+kubectl get services  --all-namespaces --field-selector metadata.namespace!=default
+```
+
+{{< note >}}
+[Оператори на основі множини](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)
+(`in`, `notin`, `exists`) не підтримуються для селекторів полів.
+{{< /note >}}
+
+## Ланцюжки селекторів {#chained-selectors}
+
+Як і з [мітками](/docs/concepts/overview/working-with-objects/labels) та іншими селекторами, селектори полів можна складати у список, розділений комами. Ця команда `kubectl` вибирає всі Podʼи, для яких значення `status.phase` не дорівнює `Running`, а поле `spec.restartPolicy` дорівнює `Always`:
+
+```shell
+kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always
+```
+
+## Кілька типів ресурсів {#multiple-resource-types}
+
+Ви можете використовувати селектори полів для кількох типів ресурсів. Ця команда `kubectl` вибирає всі Statefulsets та Services, які не знаходяться в просторі імен `default`:
+
+```shell
+kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
+```