Модуль 1.8: Простори імен та мітки

Складність: [ШВИДКИЙ] — концепції організації. Час на проходження: 35-40 хвилин. Передумови: Модулі 1.5-1.7. Це базовий модуль, але він свідомо розглядає простори імен та мітки як інструменти надійності у виробничому середовищі, а не як картки для зазубрювання термінів.

Цей модуль передбачає Kubernetes 1.35 або новішої версії та використовує k як короткий псевдонім для kubectl. Якщо ваша оболонка ще не визначає його, виконайте alias k=kubectl перед практичним розділом, щоб команди збігалися з прикладами, а ваша м’язова пам’ять починала формуватися навколо того самого компактного робочого процесу, який оператори використовують під час усунення несправностей.

Результати навчання

Після завершення цього модуля ви зможете робити вибір щодо просторів імен та метаданих, який витримає звичайні релізи, спільне володіння кількома командами та налагодження під час збоїв. Кожен результат нижче пізніше оцінюється через сценарні запитання або практичну вправу зі зміщенням селекторів.

1. Спроєктувати стратегію просторів імен, яка відокремлює команди, середовища та застосунки, не помиляючись та не сприймаючи простори імен як повноцінні межі безпеки.
2. Порівняти ресурси, обмежені простором імен, та ресурси рівня кластера, а потім діагностувати, чому команда чи політика застосовується в одній області, але не в іншій.
3. Впровадити узгоджену схему міток та анотацій, яка підтримує Сервіси, Деплойменти, NetworkPolicies, аудити та людське володіння.
4. Оцінити селектори міток на основі рівності та на основі множин, що використовуються Сервісами, Деплойментами та NetworkPolicies за реалістичних сценаріїв змін.
5. Налагодити збої маршрутизації чи розгортання, спричинені зміщенням селекторів, помилками в мітках та невдало розміщеними метаданими.

Чому цей модуль важливий

Гіпотетичний сценарій: Під час святкового замороження релізів команда платежів вносить те, що виглядало як нешкідливе очищення метаданих Деплойменту. Поди залишалися справними, Деплоймент повідомляв бажану кількість реплік, а на нодах було вдосталь потужностей, проте клієнтський трафік оформлення замовлень раптово почав повертати помилки, оскільки виробничий Сервіс більше не мав жодних ендпоінтів. Сама зміна була крихітною: мітку шаблону Пода перемістили з app: payment на app: payment-v2, тоді як селектор Сервісу продовжував шукати app: payment.

Кожен рівень над Kubernetes бачив лише відсутній бекенд, а не очевидний збій. Журнали застосунку мовчали, перевірки справності всередині Подів проходили, а площина управління зробила точно те, що їй наказали. Збій жив на рівні організації кластера, де імена, мітки, селектори та область вирішують, які ресурси належать один одному, а які ресурси ніколи не повинні стикатися.

Простори імен та мітки легко описати й напрочуд легко використати неправильно. Простори імен розділяють спільний кластер на іменовані робочі зони, а мітки прикріплюють до об’єктів усередині та поза цими зонами ідентичність, яку можна запитувати. Іспит KCNA очікує, що ви розпізнаєте ці примітиви, але справжня операційна робота потребує більшого: ви маєте передбачати радіус ураження зміни мітки, знати, коли межі просторів імен допомагають, а коли ні, і обирати метадані анотацій, не перетворюючи випадково API-сервер на гучний пошуковий індекс.

Простори імен як межі спільного кластера

Уявіть склад із 10 000 коробок без жодних міток, секцій чи системи організації. Знайти потрібне було б неможливо, а запобігання тому, щоб одна команда переміщала матеріали іншої команди, залежало б від удачі, а не від задуму. Kubernetes без просторів імен має той самий операційний душок: кожен Под, Сервіс, ConfigMap та Secret можуть накопичуватися у просторі імен default, доки імена не зіткнуться, дозволи не розмиються, а очищення не стане ризикованим.

Щоб навести лад на цьому складі, перший крок — це побудова окремих кімнат чи зон. У Kubernetes простір імен — це логічний розділ усередині одного фізичного кластера, а не окремий кластер з окремими нодами та компонентами площини управління. Простір імен змінює область імен і дає політикам місце для прикріплення, але API-сервер, планувальник, ноди, середовище виконання контейнерів та мережева тканина залишаються спільною інфраструктурою.

┌─────────────────────────────────────────────────────────────┐
│              NAMESPACES                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                   CLUSTER                            │   │
│  │                                                      │   │
│  │  ┌─────────────────────────────────────────────┐    │   │
│  │  │  Namespace: production                       │    │   │
│  │  │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐          │    │   │
│  │  │  │ Pod │ │ Svc │ │ Dep │ │ CM  │          │    │   │
│  │  │  └─────┘ └─────┘ └─────┘ └─────┘          │    │   │
│  │  └─────────────────────────────────────────────┘    │   │
│  │                                                      │   │
│  │  ┌─────────────────────────────────────────────┐    │   │
│  │  │  Namespace: staging                          │    │   │
│  │  │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐          │    │   │
│  │  │  │ Pod │ │ Svc │ │ Dep │ │ CM  │          │    │   │
│  │  │  └─────┘ └─────┘ └─────┘ └─────┘          │    │   │
│  │  └─────────────────────────────────────────────┘    │   │
│  │                                                      │   │
│  │  ┌─────────────────────────────────────────────┐    │   │
│  │  │  Namespace: development                      │    │   │
│  │  │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐          │    │   │
│  │  │  │ Pod │ │ Svc │ │ Dep │ │ CM  │          │    │   │
│  │  │  └─────┘ └─────┘ └─────┘ └─────┘          │    │   │
│  │  └─────────────────────────────────────────────┘    │   │
│  │                                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Простір імен передусім дає вам область імен. Дві команди можуть обидві запускати Деплоймент з ім’ям backend, тому що повна ідентичність фактично є production/backend або staging/backend, а не просто backend. Це звучить дрібно, доки ви не побачите спільний простір імен default, де кожна команда має app-config, web та Job db-migration, і ніхто не впевнений, який із них безпечно перезапустити під час інциденту.

Кожен кластер Kubernetes починається з кількох вбудованих просторів імен, і знання їхнього призначення допомагає уникнути двох поширених помилок. Вам не варто сприймати default як межу виробничого застосунку, і вам не варто бездумно розгортати застосункові навантаження у kube-system лише тому, що там живуть системні Поди. Вбудовані простори імен існують, щоб кластер міг організувати сам себе, перш ніж ви додасте власні простори імен для команд, середовищ чи застосунків.

Простір імен	Призначення
default	Типовий простір імен для ресурсів без зазначеного простору імен
kube-system	Системні компоненти Kubernetes (API-сервер, CoreDNS тощо)
kube-public	Публічно читані ресурси (рідко використовуються, переважно для інформації про кластер)
kube-node-lease	Оренди серцебиття нод для відстеження справності нод

Простори імен стають потужними у поєднанні з іншими засобами контролю Kubernetes. RBAC Roles та RoleBindings можуть надати команді доступ усередині одного простору імен, не надаючи дозволів на рівні всього кластера. ResourceQuotas можуть обмежити, скільки CPU, пам’яті, кількості об’єктів чи сховища споживає простір імен, а LimitRanges можуть встановлювати типові запити чи ліміти, щоб забуте поле не перетворилося на інцидент із гучним сусідом.

┌─────────────────────────────────────────────────────────────┐
│              NAMESPACE BENEFITS                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. NAME SCOPING                                           │
│     • Same resource name in different namespaces: OK       │
│     • "backend" in production ≠ "backend" in staging      │
│                                                             │
│  2. ACCESS CONTROL                                         │
│     • RBAC can be namespace-scoped                         │
│     • "Team A can only access namespace-a"                 │
│                                                             │
│  3. RESOURCE QUOTAS                                        │
│     • Limit CPU/memory per namespace                       │
│     • Prevent one team from using all resources           │
│                                                             │
│  4. ORGANIZATION                                           │
│     • Logical separation of applications                   │
│     • Environments (dev/staging/prod)                     │
│     • Teams (team-a, team-b)                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться й передбачте: дві команди використовують спільний кластер Kubernetes, і Команда A випадково розгортає Под з ім’ям backend, який, схоже, конфліктує з Подом backend Команди B. Як простори імен могли б цьому запобігти, і які інші переваги ізоляції вони б надали? Ключове передбачення полягає в тому, що зіткнення імен зникає, коли кожен backend живе в окремому просторі імен, а RBAC і квоти можна потім прикріпити до цих меж просторів імен для контролю доступу та споживання.

Стратегія просторів імен — це архітектурний вибір, а не вправа з найменування. Невелика компанія може використовувати dev, staging та prod, оскільки команди тісно координуються, і перемагає найпростіша ментальна модель. Більша організація може віддати перевагу payments-prod, payments-dev, search-prod та search-dev, бо біллінг, RBAC, NetworkPolicy та радіус ураження інцидентів — усе це має узгоджуватися як із володінням, так і з середовищем.

Стратегія	Переваги	Недоліки	Найкраще підходить для
Простір імен на середовище (наприклад, dev, staging, prod)	Просто зрозуміти, легко встановити глобальні квоти.	Команди можуть заважати одна одній усередині середовища.	Невеликі організації з кількома інженерними командами.
Простір імен на команду (наприклад, team-frontend, team-data)	Чудова ізоляція між командами, чіткий біллінг та RBAC.	Складніше відокремити виробничий трафік від dev усередині команди.	Середні організації, де команди керують власним повним стеком.
Простір імен на застосунок/середовище (наприклад, payment-prod, payment-dev)	Максимально гранулярний контроль, вузький радіус ураження.	Розростання. Ви можете опинитися перед керуванням сотнями просторів імен.	Великі підприємства зі складними, критичними мікросервісами.

Компроміс полягає в адміністративному навантаженні. Більше просторів імен дають вам жорсткіший контроль та чіткіше володіння, але вони також створюють більше об’єктів для налаштування, моніторингу, документування та очищення. Якщо кожна гілка попереднього перегляду створює простір імен, вам потрібна автоматизація для квот, RBAC, міток, типових мережевих політик та видалення, інакше ваш кластер перетвориться на звалище покинутих середовищ.

Найчистіший спосіб думати про дизайн просторів імен — це запитати, що має бути правдою під час інциденту. Якщо команда баз даних каже: «покажіть мені все, чого може торкнутися виробниче оформлення замовлень», розкладка просторів імен має робити перший пошук очевидним, а не змушувати людей пам’ятати племінні правила найменування. Якщо команда безпеки каже: «які розробники можуть змінювати виробничі Secrets», RoleBindings мають вказувати на чіткі межі просторів імен, а не на одне спільне відро зі складними винятками.

Усередині кожної стратегії просторів імен також ховається питання життєвого циклу. Простір імен, створений для довгоживучого виробничого застосунку, слід розглядати як довговічну інфраструктуру, з придатними для перегляду маніфестами та чітким володінням. Простір імен, створений для короткоживучого середовища попереднього перегляду, має мати шлях до завершення, оскільки покинуті простори імен усе ще споживають людську увагу, навіть коли їхні Поди зникли. Надійні платформи роблять ці відмінності життєвого циклу явними, замість того щоб покладатися на день очищення через місяці.

Ви часто бачитимете, що платформи комбінують стратегії замість того, щоб обирати лише одну. Компанія може запускати platform-system для спільних платформних контролерів, payments-prod для критичного сервісу, payments-dev для розробки команди та ефемерні простори імен payments-pr-123 для попередніх переглядів запитів на злиття. Це виглядає як розростання, доки платформа не автоматизує застосування політик та видалення; тоді додаткові імена стають точною мапою відповідальності, ризику та очікуваного часу життя.

Деякі ресурси взагалі не живуть усередині просторів імен, оскільки вони описують спільну основу кластера. Нода представляє машину, яка може запускати Поди з багатьох просторів імен, PersistentVolume представляє ємність сховища, яку пізніше може запитати об’єкт із простору імен, а ClusterRole описує дозволи, які можна прив’язати в багатьох просторах імен. Саме тому k get nodes -n production концептуально неправильний, навіть якщо CLI у деяких контекстах приймає чи ігнорує прапорець простору імен.

Різниця в області найбільше важить, коли ви прикріплюєте політику. Role надає дозволи в межах простору імен, тоді як ClusterRole описує дозволи, які можуть застосовуватися на рівні всього кластера або бути прив’язані до простору імен через RoleBinding. ResourceQuota обмежує споживання в одному просторі імен, тоді як ємність нод та обмеження планування обробляються через інші API. Коли команда вас дивує, запитайте, чи об’єкт обмежений застосунком, чи інфраструктурою, перш ніж припускати, що Kubernetes проігнорував ваш намір.

Рівень кластера	Чому
Nodes	Фізичні/віртуальні машини є спільною інфраструктурою.
PersistentVolumes	Активи сховища представляють ємність на рівні всього кластера.
Namespaces	Простір імен не може містити інший простір імен.
ClusterRoles	Дозволи, що застосовуються в усіх просторах імен.
StorageClasses	Конфігурації того, як сховище надається глобально.

Зупиніться й передбачте: перелічіть, які з цих ресурсів обмежені рівнем кластера, а які — простором імен: Pod, Node, PersistentVolume, ConfigMap, Secret, Namespace, Service та StorageClass. Поди, ConfigMaps, Secrets та Сервіси належать простору імен, оскільки вони описують поведінку чи конфігурацію на рівні застосунку. Ноди, PersistentVolumes, Namespaces та StorageClasses обмежені рівнем кластера, бо вони описують інфраструктуру, межі розподілу або глобальну політику.

Корисна діагностична звичка — читати область об’єкта з іменника, перш ніж тягнутися до прапорця команди. Якщо об’єкт представляє щось, чим володіє застосунок, як-от ConfigMap, Secret, Сервіс, Под чи Деплоймент, очікуйте область простору імен, якщо документація не каже інакше. Якщо об’єкт представляє спільну інфраструктуру, глобальну політику чи саму систему просторів імен, очікуйте область кластера. Ця звичка запобігає несподівано великій кількості розслідувань хибним шляхом, особливо для запитань KCNA, які змішують імена ресурсів із прапорцями просторів імен.

Мітки, анотації та ідентичність, яку можна запитувати

Тепер, коли в нас є кімнати на складі, нам потрібен спосіб класифікувати окремі коробки всередині них. Мітки — це ті стікери, але в Kubernetes вони більші за людську оздобу, бо контролери та API використовують їх як селектори. Сервіс не веде написаний від руки список імен Подів, оскільки Поди часто замінюються; він запитує в API Поди, чиї мітки збігаються з його селектором.

Мітки — це пари «ключ-значення», що зберігаються під metadata.labels. Вони мають представляти стабільну ідентичність, яку можна запитувати, як-от ім’я застосунку, середовище, рівень, компонент, версія чи команда-власник. Вони навмисно невеликі, бо Kubernetes індексує та обчислює їх; якщо ви зберігаєте довгі нотатки про збірку чи унікальні позначки часу як мітки, ви просите площину управління оптимізувати дані, які селектори ніколи не повинні використовувати.

metadata:
  labels:
    app: frontend
    environment: production
    team: platform
    version: v2.1.0

Найважливіше правило дизайну — позначати мітками для рішень, які, як ви очікуєте, прийматимуть Kubernetes, автоматизація чи оператори. Якщо ви добиратимете всі виробничі Поди, маршрутизуватимете трафік до застосунку frontend, обмежуватимете мережевий вхід до рівня backend чи звітуватимете про витрати за командою, це кандидати на мітки. Якщо вам потрібен хеш коміту Git, URL збірки, канал пейджера чи довгий опис, це належить до анотацій, якщо тільки селектору справді не потрібне інше.

Гарні мітки також потребують контрольованого словника. env=prod, environment=production та stage=live можуть усі означати те саме для людей, але це різні факти для Kubernetes. Якщо три команди вигадають три імені для того самого поняття, селектори стануть крихкими, а дашборди — неповними. Зрілі кластери зазвичай вирішують це через шаблони, помічники Helm-чартів, стартові набори платформи чи політику допуску, яка відхиляє об’єкти без обов’язкових міток.

Кардинальність — ще одна практична турбота. Мітка з невеликим набором повторюваних значень, як-от team=payments чи tier=frontend, легко запитується й піддається осмисленню. Мітка, чиє значення унікальне на кожному Поді, як-от повний хеш коміту чи позначка часу, зазвичай є поганим матеріалом для селектора, бо вона створює багато крихітних груп, які контролерам рідко потрібні. Факти з високою кардинальністю усе ще можуть бути цінними, але анотації зазвичай є для них правильним місцем.

Сервіси, Деплойменти та NetworkPolicies не відстежують Поди за їхніми IP-адресами чи точними іменами, бо Поди є одноразовими. Деплоймент створює ReplicaSets, ReplicaSets створюють Поди, Сервіси створюють списки ендпоінтів, а NetworkPolicies дозволяють чи забороняють трафік, запитуючи, які Поди збігаються із селектором у певний момент часу. Мітки — це спільний словник, який дозволяє цим незалежним контролерам погодитися щодо тієї самої групи об’єктів.

┌─────────────────────────────────────────────────────────────┐
│              LABEL SELECTORS                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Service selecting Pods:                                   │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  Service:                   Pods:                          │
│  selector:                  ┌─────────────────────┐        │
│    app: web                 │ labels:             │ ✓ Match│
│                             │   app: web          │        │
│                             │   env: prod         │        │
│                             └─────────────────────┘        │
│                             ┌─────────────────────┐        │
│                             │ labels:             │ ✓ Match│
│                             │   app: web          │        │
│                             │   env: staging      │        │
│                             └─────────────────────┘        │
│                             ┌─────────────────────┐        │
│                             │ labels:             │ ✗ No   │
│                             │   app: api          │        │
│                             │   env: prod         │        │
│                             └─────────────────────┘        │
│                                                             │
│  Only Pods with "app: web" are selected                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

На діаграмі показано селектор лише з app: web, тож і виробничі, і staging-Поди збігаються, якщо вони мають цю мітку в тій самій області селектора. Це може бути правильним для демонстрації й небезпечним у виробництві, залежно від стратегії просторів імен та дизайну Сервісу. Якщо production та staging працюють в окремих просторах імен, Сервіс в одному просторі імен зазвичай добирає Поди в тому просторі імен, але якщо обидва середовища ділять один простір імен, широкий селектор може змішати трафік у спосіб, якого застосунок ніколи не очікував.

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

Анотації — це також метадані «ключ-значення», але вони не призначені для добирання. Контролери, вебхуки допуску, інструменти розгортання, люди та системи документації часто читають анотації заради додаткового контексту чи підказок щодо конфігурації. Практична різниця не в тому, чи виглядає значення важливим; різниця в тому, чи має значення брати участь у групуванні, маршрутизації, політиці чи операціях запиту.

Анотації усе ще можуть впливати на поведінку, коли конкретний контролер вирішує їх прочитати, тож «не використовується для добирання» не означає «ніколи не використовується програмним забезпеченням». Контролери Ingress, сервісні сітки, інструменти резервного копіювання та системи розгортання часто використовують анотації як поверхні конфігурації. Різниця в тому, що селектори міток Kubernetes не використовують значення анотацій для рішення про членство в групі. Сприймайте анотації як насичені нотатки про об’єкт чи специфічні для інструмента налаштування, а мітки — як індексовану мову ідентичності API.

┌─────────────────────────────────────────────────────────────┐
│              LABELS vs ANNOTATIONS                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  LABELS:                       ANNOTATIONS:                │
│  ─────────────────────────────────────────────────────────  │
│  • For identification          • For metadata              │
│  • Used in selectors           • NOT used in selectors     │
│  • Short values                • Can be longer             │
│  • Meaningful to K8s           • For tools/humans          │
│                                                             │
│  Label example:                Annotation example:         │
│  labels:                       annotations:                │
│    app: frontend                 description: "Main web UI"│
│    version: v2                   git-commit: "abc123..."   │
│                                  contact: "team@example.com"│
│                                                             │
│  Use labels for:               Use annotations for:        │
│  • Selection                   • Build info                │
│  • Organization                • Contact info              │
│  • Grouping                    • Configuration hints       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться й передбачте: мітка чи анотація? Класифікуйте app=web, git-commit=8a3f9b, environment=staging, build-date=2023-10-25, tier=backend та on-call-slack=#team-alpha. app, environment та tier — це мітки, бо ви обґрунтовано добирали б, групували, маршрутизували чи звітували б за ними. Хеш коміту, дата збірки та канал контакту — це анотації, бо вони описують походження та володіння, а не ідентичність для добирання.

Kubernetes рекомендує поширені мітки застосунків, щоб інструменти могли погодитися щодо того, що означають імена. Helm-чарт, дашборд, звіт про витрати та сценарій інциденту — усі стають кориснішими, коли можуть покладатися на app.kubernetes.io/name для застосунку, app.kubernetes.io/instance для конкретної інсталяції та app.kubernetes.io/part-of для більшого продукту. Ви усе ще можете тримати коротші мітки на кшталт app чи env, але стандартизовані мітки роблять багатоінструментні операції менш крихкими.

Мітка	Призначення	Приклад
app.kubernetes.io/name	Ім’я застосунку	mysql
app.kubernetes.io/instance	Унікальна інсталяція	mysql-prod-us-east
app.kubernetes.io/version	Версія	5.7.21
app.kubernetes.io/component	Архітектурний рівень	database
app.kubernetes.io/part-of	Система вищого рівня	ecommerce-platform
app.kubernetes.io/managed-by	Інструмент провізіювання	helm

Гарна схема міток нудна в найкращому сенсі. Вона дає кожному навантаженню достатньо ідентичності, щоб відповісти на поширені запитання, не змушуючи операторів пам’ятати специфічні для команди домовленості. Коли починається інцидент, k get pods -A -l app.kubernetes.io/part-of=checkout корисний лише в тому разі, якщо кожна команда застосувала мітку послідовно до інциденту, а не після того, як хтось почав пошук.

Стандартні мітки також зменшують зчеплення між командами та платформними інструментами. Дашборду не має бути потрібно знати, що одна команда використовує service=checkout, інша — app_name=checkout, а третя — component=checkout-api для тієї самої категорії. Коли платформа публікує спільний контракт міток, продуктові команди можуть рухатися швидше, бо їхні ресурси автоматично з’являються у видах інвентаризації, звітах про витрати, маршрутах сповіщень та мапах володіння.

Один тонкий вибір у дизайні міток — чи мітка описує сам об’єкт, чи систему навколо нього. app.kubernetes.io/name=payment-web описує навантаження, тоді як app.kubernetes.io/part-of=checkout-platform описує більший продукт. Обидві корисні, але вони відповідають на різні запитання. Під час інциденту з платежами ви можете почати з мітки продукту, щоб знайти всю поверхню оформлення замовлень, а потім звузити до мітки застосунку, коли знатимете, який компонент поводиться неправильно.

Селектори як контракти між контролерами

Селектори — це контракти, що перетворюють мітки на поведінку. Селектори на основі рівності просять точних збігів, тоді як селектори на основі множин виражають членство, виключення, наявність чи відсутність. Обидва є логічними фільтрами, і коли разом з’являється кілька вимог, вони зазвичай поєднуються як логічне І, що означає: кожна вимога має збігтися, щоб об’єкт було дібрано.

# EQUALITY-BASED (Simple exact match)
# Give me Pods where the 'app' label exactly equals 'frontend'
selector:
  app: frontend

# Or using the formal matchLabels syntax:
selector:
  matchLabels:
    app: frontend
    env: production    # Must match BOTH (Logical AND)

Селектори рівності чіткі та читані, що робить їх чудовими для Сервісів, які мають знайти один рівень застосунку. Селектор Сервісу на кшталт app: frontend легко перевірити під час збою, а селектор Деплойменту, що збігається з мітками шаблону його Пода, легко осмислити. Слабкість — це виразність: селектори рівності не можуть сказати «frontend або backend» чи «будь-що, крім development» без додавання додаткових міток чи окремих об’єктів.

Уявна простота може приховувати контракт, суворіший, ніж люди очікують. У формальній формі matchLabels кожен зазначений ключ та значення мають збігтися. Якщо селектор Сервісу містить app=frontend та env=production, Под, у якого бракує лише мітки env, невидимий для цього Сервісу, навіть якщо кожна інша деталь правильна. Під час налагодження не запитуйте, чи має Под «загалом правильні мітки»; запитайте, чи задовольняє він точно кожну вимогу селектора.

Іноді вам потрібна складніша логіка. NetworkPolicy може потребувати дозволу трафіку від рівнів або frontend, або api, виключаючи при цьому експериментальні навантаження, чи оператору може знадобитися перелічити Поди, що належать кільком компонентам під час міграції. Селектори на основі множин обробляють це за допомогою операторів на кшталт In, NotIn, Exists та DoesNotExist.

Селектори на основі множин потужні, бо вони виражають намір без множення об’єктів. Одна NetworkPolicy може дозволити кілька довірених рівнів, а один CLI-запит може знайти всі навантаження, у яких бракує очікуваної мітки, за допомогою перевірок наявності. Компроміс — це читаність: щойно селектор має кілька виразів, операторам потрібно сповільнитися й оцінити кожну вимогу. Короткий коментар у маніфесті чи зрозуміла назва політики можуть зекономити час пізніше.

# SET-BASED (More powerful expressions)
selector:
  matchExpressions:
  - key: app
    operator: In
    values: [frontend, backend]    # App is EITHER frontend OR backend
  - key: env
    operator: NotIn
    values: [development]          # Env is NOT development

Перш ніж це запускати, який вивід ви очікуєте від k get pods -l 'app in (frontend,backend),env notin (development)', якщо один Под має app=frontend,env=production, інший — app=backend,env=development, а третій — app=api,env=production? Має з’явитися лише перший Под, бо другий не проходить виключення середовища, а третій не проходить перевірку членства застосунку. Ця вправа з передбачення важлива, бо селектори часто виглядають дозвільними, доки ви не застосуєте повне логічне І.

Сервіси та Деплойменти обидва використовують селектори, але вони використовують їх з різними наслідками. Селектор Деплойменту визначає Поди, що належать до бажаного стану цього Деплойменту, і в API apps/v1 селектор фактично є частиною ідентичності контролера. Селектор Сервісу визначає живі бекенди трафіку, тож зміна селектора може миттєво додати чи видалити ендпоінти, навіть якщо жоден Под не перезапускався.

Ця відмінність пояснює, чому зміна мітки може здаватися непослідовною. Якщо ви зміните лише мітку шаблону Пода, від якої залежить селектор Деплойменту, Kubernetes може відхилити зміну чи створити плутанину з володінням, бо Деплоймент має вміти розпізнавати Поди, якими він керує. Якщо ви зміните селектор Сервісу, Kubernetes може прийняти зміну й негайно перерахувати ендпоінти. Обидві поведінки логічні, щойно ви згадаєте, який контролер використовує селектор і яким відношенням він керує.

┌─────────────────────────────────────────────────────────────┐
│              LABELS IN ACTION                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Deployment:                                               │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  name: frontend                                      │   │
│  │  selector:                                           │   │
│  │    matchLabels:                                      │   │
│  │      app: frontend    ─────────┐                    │   │
│  │  template:                      │                    │   │
│  │    metadata:                    │                    │   │
│  │      labels:                    │ Must match!       │   │
│  │        app: frontend  ←────────┘                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Service:                                                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  name: frontend-service                              │   │
│  │  selector:                                           │   │
│  │    app: frontend      → Finds Pods with this label  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  The chain:                                                │
│  Deployment.selector → Pod template labels                │
│  Service.selector → Pod labels                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться й подумайте: Сервіс використовує селектор app: frontend, щоб знайти свої Поди. Якщо ви додасте нову мітку version: v2 до деяких Подів, але не до інших, Сервіс усе одно маршрутизує до всіх Подів, що зберігають app: frontend, бо додаткові мітки не шкодять збігу. Якщо ви зміните селектор Сервісу, щоб він вимагав і app: frontend, і version: v2, Сервіс негайно звузиться лише до версійних Подів, що може бути контрольованим канарковим розгортанням чи випадковим частковим збоєм.

Селектор найбезпечніший, коли дібрана мітка стабільна впродовж життя відношення. Мітки ідентичності застосунку, компонента та інсталяції зазвичай стабільні; мітки версії релізу змінюються часто. Саме тому багато команд використовують стабільні мітки для добирання Сервісом, а мітки версії — для спостережуваності, відстеження розгортання чи тимчасового аналізу, а не для головного виробничого селектора Сервісу.

Існують законні винятки, як-от канаркові Сервіси, які навмисно добирають track=canary чи version=v2 для обмеженого шляху трафіку. Суть не в тому, що мітки версії заборонені в селекторах; суть у тому, що їх слід використовувати свідомо там, де форма трафіку залежить від версії. Стабільний виробничий Сервіс та експериментальний канарковий Сервіс можуть співіснувати, якщо їхні призначення та селектори зрозумілі.

Операції з просторами імен та мітками за допомогою k

Механіка проста, але важить операційна звичка: завжди робіть область видимою під час огляду ресурсів. k get pods показує лише поточний простір імен, тоді як k get pods -A показує всі простори імен. У реагуванні на інциденти відсутній -n чи відсутній -A можуть відправити вас на пошуки не в ту кімнату, особливо коли кілька середовищ використовують ті самі імена ресурсів.

alias k=kubectl
k get namespaces
k create namespace payments-dev
k get pods -n payments-dev
k get pods -A -l app.kubernetes.io/name=checkout

Створення простору імен — це лише початок корисної межі. У справжній платформі створення простору імен зазвичай обгорнуте автоматизацією, яка також застосовує мітки власника, типові NetworkPolicies, ResourceQuotas, LimitRanges та RoleBindings. Без цих супровідних об’єктів ви маєте іменоване відро, але ще не маєте надійного операційного контракту для команди чи застосунку.

Ця автоматизація може бути такою ж простою, як зафіксований у репозиторії маніфест простору імен для невеликої команди, чи такою ж формальною, як платформне API, яке створює простори імен через процес запиту. Важлива частина — це повторюваність. Якщо виробничі простори імен завжди отримують ту саму базову політику заборони, форму квот, мітки власника та анотації підтримки, тоді оператори можуть довіряти середовищу, а не реконструювати його щоразу, коли з’являється новий сервіс.

apiVersion: v1
kind: Namespace
metadata:
  name: payments-dev
  labels:
    app.kubernetes.io/part-of: checkout-platform
    environment: development
    team: payments

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

Мітки простору імен особливо корисні для наскрізних платформних завдань. Контролер політики може шукати простори імен з міткою environment=production та вимагати суворіших налаштувань, тоді як звіт про витрати може групувати всі простори імен з міткою team=payments. Це прив’язує вираз політики до задекларованих метаданих, а не до вручну підтримуваного списку імен просторів імен. Якщо простір імен змінює володіння, оновлення мітки змінює те, як його бачить платформна автоматизація.

k label namespace payments-dev cost-center=cc-1234
k annotate namespace payments-dev owner-email=payments-team@example.com
k get namespaces -l team=payments

Команди k label та k annotate зручні, але зміна живих міток заслуговує на обережність. Додавання мітки зазвичай безпечне, коли від неї не залежить жоден селектор, тоді як зміна чи видалення мітки селектора може миттєво змінити поведінку контролера. Перш ніж змінювати мітки на Подах, керованих Деплойментом, краще змінюйте шаблон Деплойменту через версійні маніфести, щоб бажаний стан та майбутні Поди залишалися узгодженими.

Пряме позначення окремого Пода міткою часто є ярликом для налагодження, а не довговічним виправленням. Якщо Под належить Деплойменту, наступний Под-заміна походить від шаблону Деплойменту й може не нести вашу ручну зміну. Довговічні метадані належать до шаблону контролера чи до джерела маніфесту, що створює об’єкт. Це ще одна причина, чому оператори оглядають і мітки живого Пода, і шаблон Деплойменту, коли з’являється проблема із селектором.

k get svc -n production payment -o yaml
k get endpointslice -n production -l kubernetes.io/service-name=payment
k get pods -n production -l app=payment --show-labels

Ці три команди формують практичний ланцюг налагодження Сервісу. Спершу огляньте селектор Сервісу, потім огляньте згенеровані EndpointSlices, потім перелічіть Поди з тим самим селектором та видимими мітками. Якщо Сервіс не має ендпоінтів, але збіжні Поди існують, шукайте гейти готовності чи невідповідності портів; якщо збіжних Подів немає, селектор та мітки розійшлися.

EndpointSlices корисні, бо вони показують результат добирання після того, як площина управління обробила стан Сервісу та Пода. Маніфест Сервісу каже вам про намір, мітки Пода кажуть про кандидатів, а EndpointSlices кажуть, що Kubernetes насправді публікує для трафіку. Коли ці три види не збігаються, ви різко звузили проблему. Це різниця між вгадуванням мережі та слідуванням за відношеннями об’єктів.

Розгорнутий приклад: наскрізне позначення мікросервісного застосунку мітками

Розгляньмо, як ми пов’язуємо це все докупи для дворівневого застосунку з вебінтерфейсом та кешем Redis. Веб-Поди отримують app: web, tier: frontend та env: prod, тоді як Поди Redis отримують app: redis, tier: backend та env: prod. Це дає Сервісам стабільну мітку застосунку та дає NetworkPolicies мітку рівня, яку вони можуть використовувати без жорсткого прописування окремих імен Подів.

Веб-Сервіс має балансувати трафік лише між веб-Подами, тож його селектором може бути app: web. Сервіс Redis має спрямовувати внутрішній трафік до Подів кешу, тож його селектором може бути app: redis. Ці селектори навмисно достатньо вузькі, щоб уникнути перетину меж застосунків, але не настільки вузькі, щоб звичайне розгортання версії прибрало справні Поди з обслуговування.

Якщо команда пізніше додасть другий веб-Деплоймент для канаркового трафіку, у неї є вибір. Вона може тримати і стабільні, і канаркові Поди за головним Сервісом, зберігаючи app: web, чи може ввести селектори track=stable та track=canary для окремих Сервісів. Жоден вибір не є універсально правильним. Правильна відповідь залежить від того, чи належить розподіл трафіку до Сервісів Kubernetes, контролера ingress, сервісної сітки чи системи релізів застосунку.

NetworkPolicy додає друге застосування для тієї самої схеми. Якщо Redis має приймати вхід лише з рівня frontend, політика може добирати Поди Redis як призначення та дозволяти джерела, чиї мітки кажуть, що вони є навантаженнями frontend. Саме тут окупається узгоджений словник міток, бо мережеве правило може виражати намір, не називаючи кожен Деплоймент, який може масштабуватися чи розгортатися впродовж дня.

Небезпека в тому, що мітка, використана для безпеки, стає сигналом дозволу. Якщо будь-який розробник може позначити будь-який Под міткою tier=frontend, тоді політика, що дозволяє трафік frontend, настільки ж міцна, наскільки міцне врядування навколо міток. Виробничі кластери часто поєднують NetworkPolicies з RBAC, політиками допуску чи шаблонами розгортання, щоб команди не могли бездумно надати собі мережевий доступ, редагуючи метадані. Мітки потужні саме тому, що контролери їм вірять.

matchExpressions:
- key: tier
  operator: In
  values: [frontend]

Проєктуючи узгоджену схему позначення мітками, мережа, маршрутизація та масштабування стають на місце автоматично. Проєктуючи недбалу, ви створюєте кластер, де кожна команда має заново відкривати, які мітки безпечно добирати, а які мітки додано для одноразової міграції. Різниця не академічна; це різниця між двохвилинною діагностикою ендпоінтів та довгим збоєм, де кожен об’єкт виглядає справним сам по собі.

Розгорнутий приклад також має включати мислення про збої. Запитайте, що зламалося б, якби Поди Redis випадково використали app: web, чи якби веб-Поди пропустили tier: frontend. Перша помилка могла б спрямувати трафік кешу до неправильних Подів, якби селектор Сервісу був надто широким, тоді як друга могла б заблокувати законний доступ до Redis за NetworkPolicy. Мітки — це малі поля, але вони лежать прямо на шляху рішень про маршрутизацію, володіння та політику.

Гіпотетичний сценарій: друга година ночі п’ятниці, і виробничий платіжний Сервіс раптово припиняє маршрутизувати трафік. Поди працюють, ноди справні, а Деплоймент повідомляє бажану кількість, але запити зазнають невдачі, бо список ендпоінтів Сервісу порожній. Розробник змінив мітку шаблону Пода з app: payment на app: payment-v2, щоб показати новий реліз, тоді як Сервіс усе ще добирав app: payment; одне зміщення мітки спричинило повний збій, доки не відновили контракт селектора.

Який підхід ви б обрали тут і чому: чи команді варто змінити селектор Сервісу на app: payment-v2, чи варто відновити стабільну мітку app: payment та додати version: v2 як окрему мітку? Безпечніший типовий вибір — тримати стабільну мітку застосунку для маршрутизації та додати версію як окремі метадані, бо ідентичність релізу змінюється частіше, ніж ідентичність застосунку. Ви усе ще можете використовувати мітки версії для канарок, метрик та тимчасового аналізу, не прив’язуючи головний Сервіс до кожного імені релізу.

Патерни та антипатерни

Гарний дизайн просторів імен та міток зазвичай дотримується кількох повторюваних патернів. Перший патерн — це стабільна ідентичність маршрутизації: Сервіси добирають мітки, що описують, чим є навантаження, а не яка збірка випадково запущена сьогодні. Другий патерн — це межі просторів імен, видимі власнику: кожен простір імен несе мітки та анотації, що ідентифікують команду, середовище, продукт та життєвий цикл. Третій патерн — це готова до політики таксономія: мітки на кшталт tier, environment та app.kubernetes.io/part-of присутні до того, як вони знадобляться NetworkPolicies, квотам чи звітам про витрати.

Ці патерни працюють, бо вони роблять бажані відношення очевидними в метаданих об’єкта. Селектор Сервісу читається як призначена група бекендів, мітка простору імен читається як власник та середовище, а анотація читається як контекст підтримки. Коли метадані розповідають узгоджену історію, нові оператори можуть вивчати кластер із самого API, а не залежати від окремої електронної таблиці, що може бути застарілою.

Патерн	Коли його використовувати	Чому він працює	Міркування щодо масштабування
Стабільні мітки селектора Сервісу	Будь-яке навантаження, що приймає трафік через Сервіс	Не дає розгортанням спорожняти ендпоінти, коли версії змінюються	Резервуйте мітки версії для спостережуваності чи контрольованих канаркових селекторів
Простір імен на застосунок/середовище	Критичні сервіси з окремими потребами володіння та радіуса ураження	Узгоджує RBAC, квоти, політику та область інциденту	Автоматизуйте початкове налаштування простору імен, щоб політика залишалася узгодженою
Рекомендовані мітки застосунків	Спільні інструменти, керовані Helm застосунки, дашборди та аудити	Дає інструментам спільний словник для групування ресурсів	Забезпечуйте через шаблони чи перевірки допуску, а не пам’ять
Анотація для походження	Хеші збірок, URL джерел, контакти та нотатки розгортання	Тримає довгі метадані поза індексами селекторів	Вирішіть, які анотації обов’язкові для реагування на інциденти

Антипатерни зазвичай з’являються, коли команди розглядають мітки як декоративні рядки замість контрактів контролерів. Широкий селектор на кшталт app: web усередині змішаного простору імен може об’єднати непов’язані середовища. Унікальна мітка на кшталт pod-template-hash може змусити Сервіс слідувати лише за одним ReplicaSet, коли надійде наступне розгортання. Простір імен з ім’ям prod без RBAC, квот чи мережевих правил може створити хибну впевненість, бо межа виглядає значущою, але сама по собі робить мало.

Соціальна причина зазвичай — це швидкість. Хтось випускає першу версію лише з достатньою кількістю міток, щоб Сервіс запрацював, наступна команда копіює той маніфест, а через шість місяців платформа має фактичний стандарт, якого ніхто не проєктував. Виправлення — це не перейменувати все за один ризикований ривок. Почніть із документування цільової схеми, додайте нові мітки поряд зі старими, обережно мігруйте селектори та видаляйте застарілі мітки лише після того, як контролери та дашборди більше від них не залежать.

Антипатерн	Що йде не так	Краща альтернатива
Використання default для спільних виробничих застосунків	Імена стикаються, дозволи розмиваються, а очищення ризиковане	Створюйте явні простори імен із мітками власника та середовища
Добирання трафіку за версією релізу за замовчуванням	Звичайні розгортання можуть прибрати справні Поди із Сервісу	Добирайте стабільну ідентичність застосунку та відстежуйте версію окремо
Розміщення метаданих збірки в мітках	Довгі чи високої кардинальності значення марнують орієнтовані на селектори метадані	Розміщуйте хеші комітів, URL збірок та контакти в анотаціях
Припущення, що простори імен ізолюють мережевий трафік	Поди можуть усе одно спілкуватися між просторами імен, якщо політика не каже інакше	Додайте NetworkPolicies та явно перевіряйте дозволені шляхи

Коли це не застосовується: крихітні локальні кластери, що використовуються для одного посібника, можуть запускати багато прикладів у default, бо швидкість важить більше за операційні межі. Ризик починається, коли звичка з ноутбукового кластера переходить у спільне середовище. Щойно кілька людей, сервісів, середовищ чи політик ділять кластер, дизайн просторів імен та міток перестає бути необов’язковим прибиранням і стає частиною моделі надійності системи.

Є ще один антипатерн, вартий згадки: надмірне моделювання. Початківець іноді реагує на помилки з мітками, вигадуючи дюжину обов’язкових міток, перш ніж організація дізнається, які рішення ці мітки підтримують. Це створює власний дрейф, бо команди заповнюють обов’язкові поля низькоякісними значеннями. Краще мати невелике обов’язкове ядро, що підтримує справжні селектори, володіння та звітність, а потім додавати спеціалізовані мітки, коли контролер, політика чи операційний робочий процес їх потребують.

Рамка прийняття рішень

Почніть із запитання, на яке ви намагаєтеся відповісти, а не з поля метаданих, яке хочете заповнити. Якщо запитання — «хто може мати доступ до цих об’єктів?» чи «скільки ємності може споживати ця група?», ви, ймовірно, проєктуєте межу простору імен плюс RBAC чи квоту. Якщо запитання — «які об’єкти має добирати цей контролер, Сервіс, політика чи звіт?», ви проєктуєте мітки. Якщо запитання — «яку додаткову деталь мають бачити люди чи інструменти після добирання об’єкта?», ви проєктуєте анотації.

Той самий ресурс може використовувати всі три механізми одночасно. Деплоймент може жити у просторі імен payments-prod, нести мітки, що кажуть, що він є частиною оформлення замовлень та реалізує рівень frontend, та містити анотації, що вказують на runbook та походження збірки. Це не дублювання, коли кожен рівень відповідає на різне запитання. Простір імен задає область політики та імен, мітки підтримують групування та селектори, а анотації зберігають пояснювальну деталь.

Рішення	Використовуйте простір імен, коли…	Використовуйте мітку, коли…	Використовуйте анотацію, коли…
Організація володіння	Команді чи застосунку потрібна власна межа дозволів та квот	Вам потрібно запитувати ресурси, якими володіє команда, через області	Вам потрібне посилання на контакт, тікет чи runbook
Розділення середовищ	Dev, staging та production потребують різних політик	Один простір імен містить кілька категорій середовищ	Нотатка про збірку чи розгортання описує один об’єкт
Маршрутизація трафіку	Сервіс та Поди мають чітку область простору імен	Сервіс має знаходити збіжні Поди за стабільною ідентичністю	Ніколи; анотації не добирають ендпоінти
Налагодження інцидентів	Вам потрібно швидко обмежити область пошуку	Вам потрібно перелічити всі збіжні навантаження чи ендпоінти	Вам потрібне походження після знаходження об’єкта

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

Коли ви не впевнені, уявіть, що значення змінюється під час релізу. Якщо його зміна має перемістити трафік, змінити членство в політиці чи змінити запит інвентаризації, це, ймовірно, мітка, і вона заслуговує на ретельне планування розгортання. Якщо його зміна має лише оновити пояснення, прикріплене до об’єкта, це, ймовірно, анотація. Якщо зміна має перевизначити, хто володіє робочим простором чи які політики застосовуються до групи ресурсів, ви, ймовірно, дивитеся на дизайн просторів імен.

Чи знали ви?

• Простори імен не забезпечують мережевої ізоляції за замовчуванням — Поди в різних просторах імен часто можуть спілкуватися, якщо NetworkPolicies та сумісний мережевий плагін не обмежать шлях.
• Ключі та значення міток мають задокументовані правила розміру — Сегмент імені мітки обмежений 63 символами, а необов’язкова частина DNS-префікса може мати до 253 символів.
• Селектори можна використовувати безпосередньо з CLI — k get pods -l app=frontend,env=prod повертає Поди, що збігаються з обома мітками, що є логічним І.
• Імена просторів імен дотримуються правил DNS-міток — Вони мають бути в нижньому регістрі та DNS-сумісними, тому імена на кшталт Payments_Prod відхиляються.

Типові помилки

Помилка	Чому це стається	Як це виправити
Думати, що простори імен ізолюють мережевий трафік	Слово «простір імен» звучить як жорстка межа безпеки, а RBAC може бути обмежений простором імен.	Сприймайте простори імен як точки організації та прикріплення політик, а потім додавайте NetworkPolicies для ізоляції трафіку.
Зміна стабільної мітки селектора Сервісу під час розгортання	Команди хочуть, щоб мітки відображали новий реліз, і випадково мутують ідентичність маршрутизації.	Тримайте мітки на кшталт app: payment стабільними, а потім додавайте version чи рекомендовані мітки застосунків для деталей релізу.
Розміщення кожного навантаження в default	Посібники та швидкі експерименти використовують default, і ця звичка переноситься у спільні кластери.	Створюйте явні простори імен для команд, застосунків чи середовищ перед розгортанням спільних навантажень.
Використання міток для довгих метаданих	Мітки видимі й легко додаються, тож команди розміщують там хеші збірок, позначки часу та контактні дані.	Використовуйте анотації для походження, контактів, runbook та метаданих збірки, які селектори не мають запитувати.
Забування, що деякі ресурси обмежені рівнем кластера	Команди з -n здаються універсальними, тож оператори очікують, що кожен об’єкт живе у просторі імен.	Вивчіть область Nodes, PersistentVolumes, StorageClasses, Namespaces та ClusterRoles перед застосуванням політики.
Написання надто широких селекторів	Короткий селектор працює в малій демонстрації й пізніше збігається з непов’язаними Подами у спільному просторі імен.	Включайте стабільні мітки, що розрізняють застосунок, інсталяцію, середовище чи компонент за потреби.
Припущення, що збіжна мітка означає готовність трафіку	Селектор Сервісу може збігтися з Подами, які не готові чи відкривають неправильний порт.	Оглядайте селектори Сервісу, EndpointSlices, готовність Подів та цільові порти разом під час налагодження.

Тест

Ваша компанія має три команди, що ділять один кластер Kubernetes. Команда A скаржиться, що Команда B випадково видалила їхній ConfigMap, бо обидві команди назвали його `app-config` у просторі імен `default`. Як би ви реструктурували кластер, і що б ще додали?

Створіть окремі простори імен для кожної команди чи для кожної комбінації команда/середовище, як-от team-a-dev та team-a-prod, якщо розділення середовищ важить. Простори імен забезпечують область імен, тож обидві команди можуть володіти ConfigMap з ім’ям app-config без зіткнення. Додайте RoleBindings, щоб кожна команда могла керувати лише своїми просторами імен, та додайте ResourceQuotas, щоб одна команда не могла безконтрольно споживати спільний кластер. Цей дизайн задовольняє результат стратегії просторів імен, бо він поєднує організацію із засобами контролю доступу та ємності, які можна забезпечити.

Новий інженер хоче встановити ResourceQuotas рівня простору імен на Nodes, щоб обмежити CPU на фізичний сервер. Чому цей план не спрацює, і як вам пояснити проблему області?

Ноди — це ресурси, обмежені рівнем кластера, а не простором імен, тож ResourceQuota простору імен не може прикріпитися до окремої Ноди. ResourceQuotas обмежують споживання в межах простору імен, як-от Поди та їхні запитані CPU чи пам’ять усередині простору імен. Сама Нода — це спільна інфраструктура, яка може запускати Поди з багатьох просторів імен одночасно. Щоб діагностувати цей клас проблем, спершу вирішіть, чи належить ресурс до області застосунку, чи до області інфраструктури кластера.

Ваша команда розгортає `payment-v2`, змінює мітки Подів з `app=payment` на `app=payment-v2`, і Сервіс втрачає кожен ендпоінт. Що ви перевіряєте першим, і яке довговічне виправлення?

Перевірте селектор Сервісу, потім перелічіть Поди з тим самим селектором та видимими мітками за допомогою k get pods -n production -l app=payment --show-labels. Імовірний збій — це зміщення селектора: Сервіс усе ще добирає app=payment, але нові Поди більше не несуть цю стабільну мітку. Відновіть app=payment як ідентичність маршрутизації та додайте version=v2 чи рекомендовані мітки версії застосунку як окремі метадані. Це виправлення не дає майбутнім розгортанням ламати контракт Сервісу.

NetworkPolicy має добрати Поди або з рівня `frontend`, або з рівня `api`, виключаючи навантаження з міткою `track=experimental`. Який механізм селектора вам слід використати і чому?

Використовуйте matchExpressions на основі множин, бо matchLabels на основі рівності не може виразити перевірку членства АБО чи виключення. Вимога рівня потребує operator: In зі значеннями на кшталт [frontend, api], а виключення треку потребує operator: NotIn з [experimental]. Пам’ятайте, що обидва вирази поєднуються як логічне І, тож Под має задовольнити дозволений рівень та уникнути експериментального треку. Це оцінює результат селектора, а не лише пригадування імен операторів.

Сценарію аудиту потрібно знайти всі ресурси оформлення замовлень через простори імен, тоді як тим, хто реагує на інциденти, потрібні коміт Git та runbook для кожного об'єкта. Які метадані належать до міток, а які — до анотацій?

Групування продукту, ім’я застосунку, компонент, середовище та команда мають бути мітками, бо сценарію аудиту потрібно добирати та групувати за ними. Коміт Git, URL збірки, посилання на runbook та контактні дані мають бути анотаціями, бо вони надають деталь після того, як ресурс знайдено. Це розділення тримає ідентичність, яку можна запитувати, малою та стабільною, водночас зберігаючи насичений операційний контекст. Воно також уникає значень високої кардинальності чи довгих значень у мітках.

Керівник платформи каже: «Ми розмістили production та development в окремих просторах імен, тож середовища ізольовані». Що в цьому твердженні точне, і чого бракує?

Твердження точне щодо області імен та як основа для RBAC, квот та прикріплення політик. Воно неповне, бо простори імен не блокують автоматично мережевий трафік між Подами в різних просторах імен. Якщо production та development потребують мережевої ізоляції, команді потрібні NetworkPolicies, забезпечені реалізацією мережі кластера. Гарна відповідь розрізняє організаційну ізоляцію та ізоляцію трафіку, а не сприймає простори імен як магічні стіни.

Ви запускаєте `k get pods -n production -l app=web` і бачите і стабільні, і канаркові Поди. Головний Сервіс має надсилати трафік лише до стабільних Подів. Яка зміна селектора розумна, і який ризик вам слід перевірити?

Сервіс міг би добирати і app=web, і track=stable, якщо кожен стабільний Под несе цю мітку, а канаркові Поди несуть інший трек. Перш ніж робити зміну, перевірте, що стабільна мітка існує на всіх призначених бекендах; інакше Сервіс може втратити ємність чи всі ендпоінти. Також підтвердіть, що селектор Деплойменту та мітки шаблону Пода залишаються узгодженими, бо володіння контролера та маршрутизація Сервісу — пов’язані, але окремі контракти. Це проблема оцінювання, бо правильний селектор залежить від моделі розгортання та поточних міток.

Практична вправа

У цій вправі ви створите невелику модель просторів імен та позначення мітками для платіжного застосунку, а потім використаєте селектори, щоб довести, які Поди та Сервіси належать один одному. Використовуйте одноразовий локальний кластер на кшталт kind, minikube чи віддалений тренувальний кластер, де ви маєте дозвіл створювати простори імен та Деплойменти. Мета — не побудувати виробничий застосунок; мета — попрактикувати точний ланцюг огляду, який вам потрібен, коли область простору імен чи зміщення селектора спричиняють плутанину.

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

Налаштування

Виконайте ці команди з оболонки, де k вказує на kubectl. Маніфести використовують nginx, бо контейнер швидко стартує й тримає вправу зосередженою на організації об’єктів Kubernetes, а не на коді застосунку. Якщо у вас уже є простір імен payments-dev з іншої лабораторної, видаліть його лише в тому разі, якщо це безпечно у вашому середовищі, чи послідовно оберіть інше ім’я простору імен.

alias k=kubectl
k create namespace payments-dev
k label namespace payments-dev team=payments environment=development app.kubernetes.io/part-of=checkout-platform

Застосуйте Деплоймент та Сервіс зі стабільними мітками маршрутизації плюс метаданими версії. Зверніть увагу, що селектор Сервісу використовує лише app: payment-web, тоді як шаблон Пода також містить tier, environment та version. Це розділення дозволяє Сервісу зберігати маршрутизацію під час звичайної зміни мітки версії.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-web
  namespace: payments-dev
  labels:
    app.kubernetes.io/name: payment-web
    app.kubernetes.io/part-of: checkout-platform
spec:
  replicas: 2
  selector:
    matchLabels:
      app: payment-web
  template:
    metadata:
      labels:
        app: payment-web
        tier: frontend
        environment: development
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.29
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: payment-web
  namespace: payments-dev
spec:
  selector:
    app: payment-web
  ports:
  - port: 80
    targetPort: 80

k apply -f - <<'YAML'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-web
  namespace: payments-dev
  labels:
    app.kubernetes.io/name: payment-web
    app.kubernetes.io/part-of: checkout-platform
spec:
  replicas: 2
  selector:
    matchLabels:
      app: payment-web
  template:
    metadata:
      labels:
        app: payment-web
        tier: frontend
        environment: development
        version: v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.29
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: payment-web
  namespace: payments-dev
spec:
  selector:
    app: payment-web
  ports:
  - port: 80
    targetPort: 80
YAML

Завдання

• Перелічіть простір імен з його мітками, потім поясніть, які мітки описують володіння, а які — середовище.
• Перелічіть Поди в payments-dev з --show-labels, потім визначте мітки, від яких залежить Сервіс.
• Використайте селектор рівності, щоб перелічити лише Поди app=payment-web, та селектор на основі множин, щоб перелічити Поди, де tier in (frontend) та environment notin (production).
• Огляньте Сервіс та EndpointSlices, потім поясніть, чому ендпоінти з’являються, коли селектор та мітки Пода узгоджені.
• Додайте анотацію з ім’ям runbook та значенням https://example.com/runbooks/payment-web, потім поясніть, чому це не мітка.
• Пропатчте селектор Сервісу контрольованим чином, щоб він вимагав version: v2, поспостерігайте вплив на ендпоінти та відновіть оригінальний селектор.

Посібник із розв'язання

Почніть із перевірки ідентичності простору імен за допомогою k get namespace payments-dev --show-labels. Мітки володіння на кшталт team=payments та мітки продукту на кшталт app.kubernetes.io/part-of=checkout-platform допомагають платформним інструментам групувати простір імен, тоді як environment=development каже вам про роль життєвого циклу. Потім виконайте k get pods -n payments-dev --show-labels та підтвердіть, що app=payment-web з’являється на кожному Поді, бо Сервіс залежить від цієї стабільної мітки.

Використайте k get pods -n payments-dev -l app=payment-web для селектора рівності. Використайте k get pods -n payments-dev -l 'tier in (frontend),environment notin (production)' для селектора на основі множин. Ті самі Поди мають збігтися з обома фільтрами в цій малій лабораторній, але фільтри відповідають на різні операційні запитання: один просить ідентичність застосунку, тоді як інший просить роль навантаження та виключення середовища.

Огляньте маршрутизацію за допомогою k get svc -n payments-dev payment-web -o yaml та k get endpointslice -n payments-dev -l kubernetes.io/service-name=payment-web. EndpointSlices мають включати готові ендпоінти, бо селектор Сервісу збігається з мітками Пода, а Поди стають готовими. Додайте анотацію за допомогою k annotate deployment -n payments-dev payment-web runbook=https://example.com/runbooks/payment-web, потім огляньте її за допомогою k get deployment -n payments-dev payment-web -o yaml.

Щоб безпечно поспостерігати зміщення селектора, пропатчте Сервіс за допомогою k patch service -n payments-dev payment-web --type merge -p '{"spec":{"selector":{"app":"payment-web","version":"v2"}}}'. EndpointSlices мають втратити збіжні ендпоінти, бо жоден поточний Под не має version=v2. Відновіть селектор за допомогою k patch service -n payments-dev payment-web --type merge -p '{"spec":{"selector":{"app":"payment-web"}}}', потім підтвердіть, що ендпоінти повертаються. Приберіть за собою за допомогою k delete namespace payments-dev, коли лабораторну завершено й безпечно видаляти.

Критерії успіху

• Ви можете пояснити, чому payments-dev є межею простору імен, але не автоматичною межею мережевої ізоляції.
• Ви можете вказати на точну мітку Пода, яку селектор Сервісу використовує для маршрутизації.
• Ви можете виконати запити селекторів і на основі рівності, і на основі множин за допомогою k.
• Ви можете пояснити, чому URL runbook є анотацією, а не міткою.
• Ви можете відтворити та виправити проблему зі зміщенням селектора, не змінюючи непов’язані ресурси.

Джерела

• Документація Kubernetes: Namespaces
• Документація Kubernetes: Labels and Selectors
• Документація Kubernetes: Annotations
• Документація Kubernetes: Recommended Labels
• Документація Kubernetes: Services
• Документація Kubernetes: Deployments
• Документація Kubernetes: Network Policies
• Документація Kubernetes: Resource Quotas
• Документація Kubernetes: RBAC Authorization
• Довідник kubectl Kubernetes: label

Наступний модуль

Частина 2: Оркестрація контейнерів — Як Kubernetes планує навантаження, реагує на ємність та підтримує застосунки в робочому стані на рівні кластера.