У міру того, як ви починаєте створювати все більше і більше сервісів Kubernetes, прості на початку завдання починають ускладнюватися. Наприклад, команди розробників не можуть створювати служби або розгортання під тим самим ім'ям. Якщо у вас тисячі подів, їх простий перелік займе купу часу, не кажучи про те, щоб забезпечити нормальне управління. І це лише верхівка айсбергу.
Давайте розглянемо, як простір імен namespace полегшує керування ресурсами Kubernetes. Отже, що таке простір імен? Namespace можна розглядати як віртуальний кластер всередині вашого кластера Kubernetes. Ви можете мати кілька ізольованих один від одного просторів імен всередині одного кластера Kubernetes. Вони реально можуть допомогти вам та вашим командам з організацією, безпекою та навіть продуктивністю системи.
У більшості дистрибутивів Kubernetes кластер «виходить із коробки» з простором імен, що має назву «default». Насправді існує три простори імен, з якими Kubernetes має справу: default, kube-system та kube-public. В даний час Kube-public використовується не так часто.
Не чіпати простір імен kube - хороша ідея, особливо в такій системі, як Google Kubernetes Engine. Вона використовує простір імен "default" як місце, в якому створюються ваші сервіси та програми. У ньому немає абсолютно нічого особливого, за винятком того, що Kubernetes "з коробки" налаштований на його використання, і ви не можете його видалити. Це чудово підходить для початку роботи та систем з невеликою продуктивністю, але я б не рекомендував використовувати default namespace у великих prod-системах. В останньому випадку одна команда розробників може легко переписати чужий код та порушити роботу іншої команди, навіть не усвідомлюючи цього.
Тому слід створити кілька просторів імен та використовувати їх для сегментації ваших послуг у керовані ланки. Простір імен можна створити за допомогою однієї команди. Якщо ви хочете створити простір імен з іменем test, то використовуйте команду $kubectl create namespace test або просто створіть файл YAML і використовуйте його, як будь-який інший ресурс Kubernetes.
Переглянути всі простори імен можна за допомогою команди $kubectl get namespace.
Після її виконання ви побачите три вбудовані простори імен та новий простір імен під назвою «test». Давайте розглянемо простий файл YAML, призначений для створення pod. Можна помітити, що в ньому немає жодної згадки про простір імен.
Якщо ви застосуєте kubectl для запуску цього файлу, він створить модуль mypod у поточному активному просторі імен. Це буде простір імен за промовчанням, доки його не зміните. Існує два способи повідомити Kubernetes, в якому просторі імен ви хочете створити свій ресурс. Перший спосіб це використання прапора простору імен при створенні ресурсу.
Другий спосіб полягає у вказівці простору імен у декларації YAML.
Якщо ви вкажете простір імен YAML, то ресурс завжди буде створюватися в цьому просторі. Якщо ви спробуєте використовувати інший простір імен під час використання прапора простору імен, команда завершиться помилкою. Тепер якщо ви спробуєте знайти свій pod, то не зможете цього зробити.
Це тому, що всі команди виконуються поза поточним активним простором імен. Щоб знайти свій pod, вам потрібно використовувати прапор простору імен, проте це швидко набридає, особливо якщо ви працюєте розробником у групі, яка використовує свій власний простір імен і не хоче використовувати такий прапор для кожної окремої команди. Погляньмо, як це можна виправити.
З коробки ваш активний простір імен зветься default. Якщо ви не уточните простір імен в YAML ресурсу, всі команди Kubernetes будуть використовувати цей активний default namespace. На жаль, спроба керувати активним простором імен за допомогою kubectl може скінчитися невдачею. Однак існує дуже гарний інструмент під назвою Kubens, який набагато спрощує цей процес. Коли ви запускаєте команду kubens, то бачите всі простори імен із підсвіченим активним простором імен.
Для перемикання активного простору імен на простір імен test ви просто запускаєте команду $kubens test. Якщо після цього знову ввести команду $kubens, можна побачити, що тепер виділено новий активний простір імен – test.
Це означає, що вам не потрібний прапор простір імен, щоб побачити pod в просторі імен test.
Таким чином, простори імен приховані один від одного, але не ізольовані один від одного. Сервіс з одного namespace може досить легко спілкуватися із сервісом в іншому просторі імен, що часто буває дуже корисним. Можливість комунікації між різними просторами імен означає, що сервіс ваших розробників може взаємодіяти із сервісом іншої dev-команди в іншому просторі імен.
Зазвичай, коли ваша програма хоче отримати доступ до сервісу Kubernetes, ви використовуєте вбудовану службу виявлення DNS і просто вказуєте своєму застосунку ім'я сервісу. Однак при цьому ви можете створити сервіс під одним і тим же ім'ям у кількох просторах імен, що є неприпустимим.
На щастя, це легко обійти за допомогою розгорнутої форми DNS-адреси. Сервіси Kubernetes виставляють свої кінцеві точки, використовуючи загальний шаблон DNS. Це виглядає приблизно так:
Як правило, вам просто потрібне ім'я сервісу, і DNS автоматично визначить повну адресу.
Однак, якщо вам потрібно отримати доступ до сервісу в іншому просторі імен, просто використовуйте ім'я служби плюс ім'я простору імен:
Наприклад, якщо ви хочете підключитися до бази даних сервісу в тестовому просторі імен, ви можете використовувати базу адрес database.test
Якщо ви хочете підключитися до бази даних сервісу в просторі імен prod, ви використовуєте database.prod.
Якщо ви дійсно хочете ізолювати та обмежити доступ до простору імен, Kubernetes дозволяє це зробити за допомогою мережевих політик Kubernetes Network Policies. Про це я розповім у наступній серії.
Мені часто запитують, скільки просторів імен потрібно створювати і для яких цілей? Що ж є керований фрагмент даних?
Якщо ви створите занадто багато просторів імен, вони просто встануть у вас на шляху. Якщо їх буде занадто мало, ви втратите всі переваги такого рішення. Я думаю, що є чотири основні етапи, які проходить кожна компанія в процесі створення своєї організаційної структури. Залежно від етапу розвитку, на якому знаходиться ваш проект або компанія, ви можете використати відповідну стратегію створення простору імен.
Уявіть, що ви є частиною невеликої команди, яка працює над розробкою 5-10 мікросервісів і легко зможете зібрати всіх розробників в одній кімнаті. У цій ситуації є сенс запускати всі prod-сервіси у просторі імен default. Звичайно, для більшого простору дій ви можете використовувати 2 простори імен окремо для prod і dev. І найімовірніше, ви тестуєте свою розробку на локальному комп'ютері за допомогою чогось на зразок Minikube.
Припустимо, що умови змінилися і тепер у вас є команда, яка швидко зростає, яка одночасно працює над більш ніж 10 мікросервісами. Настає момент, коли необхідно використовувати кілька кластерів чи просторів імен, окремо для prod та dev. Можна розбити команду на кілька підгруп так, щоб кожна з них мала власні мікросервіси і кожна з цих команд могла б вибрати свій власний простір імен для полегшення процесу управління розробкою та випуском ПЗ.
У міру того, як кожен із членів команди отримує уявлення про те, як працює система в цілому, координувати кожну зміну з усіма іншими розробниками стає дедалі складніше. Спроба розкрутити повний стек на вашому локальному комп'ютері з кожним днем стає складнішою.
У великих компаніях розробники взагалі не знають, хто над чим працює. Команди спілкуються за допомогою сервісних контрактів або використовують технологію Service mesh, яка додає над мережею рівень абстракції типу інструменту конфігурації Istio. Спроба запустити весь стек локально просто неможлива. Я настійно рекомендую використовувати в Kubernetes таку платформу безперервної доставки (CD), як Spinnaker. Отже, настає момент, коли кожній команді безумовно потрібен власний простір імен. Кожна команда може навіть вибрати кілька просторів імен для середовища dev і середовища prod.
Нарешті, існують великі підприємницькі компанії, у яких одна група розробників навіть знає існування інших груп. Така компанія може взагалі найняти сторонніх розробників, які взаємодіють із через добре документовані API. У кожній такій групі є кілька команд та кілька мікросервісів. У цьому випадку необхідно використовувати всі інструменти, про які я говорив раніше.
Програмісти не повинні розгортати послуги вручну і не повинні мати доступу до просторів імен, які їх не стосуються. На цьому етапі доцільно мати кілька кластерів зменшення «радіуса вибуху» погано налаштованих додатків, спрощення процесів білінгу і управління ресурсами.
Таким чином, правильне використання просторів імен вашою організацією дозволяють зробити Kubernetes більш керованим, контрольованим, безпечним та гнучким.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com