Простори імен
В Kubernetes простори імен (namespaces) забезпечують механізм для ізоляції груп ресурсів в межах одного кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Засноване на просторах імен обмеження застосовується лише до обʼєктів, які входять до простору імен (наприклад, Deployments, Services тощо), а не до обʼєктів, що поширюються на весь кластер (наприклад, StorageClass, Вузли, PersistentVolumes тощо).
Коли використовувати кілька просторів імен
Простори імен призначені для використання в середовищах з багатьма користувачами, розподіленими в різні команди чи проєкти. Для кластерів з кількома десятками користувачів вам, ймовірно, не потрібно створювати або думати про простори імен. Почніть використовувати простори імен, коли ви потребуєте функції, які вони забезпечують.
Простори імен визначають область імен. Назви ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен не можуть бути вкладені один в одного, і кожен ресурс Kubernetes може бути лише в одному просторі імен.
Простори імен — це спосіб розділити ресурси кластера між кількома користувачами (за допомогою квот ресурсів).
Не обовʼязково використовувати кілька просторів імен для відокремлення трохи відмінних ресурсів, таких як різні версії одного й того ж програмного забезпечення: використовуйте мітки для розрізнення ресурсів в межах одного простору імен.
Примітка:
Для промислового кластера розгляньте можливість не використовувати простір іменdefault. Замість цього створюйте і використовуйте інші простори імен.Початкові простори імен
Після запуску в Kubernetes є чотирьох початкових простори імен:
default- Kubernetes включає цей простір імен, щоб ви могли почати використовувати новий кластер без попереднього створення простору імен.
kube-node-lease- Цей простір імен містить обʼєкти Оренди, повʼязані з кожним вузлом. Обʼєкти оренди дозволяють kubelet відправляти імпульси, щоб панель управління могла виявити відмову вузла.
kube-public- Цей простір імен може бути прочитаний усіма клієнтами (включаючи тих, які не автентифіковані). Цей простір імен в основному призначений для внутрішнього використання кластером, у випадку, коли деякі ресурси повинні бути видимими та доступними публічно по всьому кластеру. Публічний аспект цього простору імен — це лише домовленість, яка не є обовʼязковою.
kube-system- Простір імен для обʼєктів, створених системою Kubernetes.
Робота з просторами імен
Створення та видалення просторів імен описано в документації з адміністрування просторів імен.
Примітка:
Уникайте створення просторів імен із префіксомkube-, оскільки він зарезервований для системних просторів імен Kubernetes.Перегляд просторів імен
Ви можете переглянути поточні простори імен у кластері за допомогою:
kubectl get namespace
NAME STATUS AGE
default Active 1d
kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
Встановлення простору імен для запиту
Щоб встановити простір імен для поточного запиту, використовуйте прапорець --namespace.
Наприклад:
kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>
Встановлення обраного простору імен
Ви можете постійно зберігати простір імен для всіх подальших команд kubectl в даному контексті.
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Перевірте його
kubectl config view --minify | grep namespace:
Простори імен та DNS
При створенні Service, створюється відповідний DNS запис. Цей запис має форму <service-name>.<namespace-name>.svc.cluster.local, що означає,
що якщо контейнер використовує тільки <service-name>, він буде звертатись до сервісу, який є локальним для простору імен. Це корисно для використання одного і того ж конфігураційного файлу в кількох просторах імен, таких як Development, Staging та Production. Якщо вам потрібно досягти обʼєкта в іншому просторі імен, вам слід використовувати повне кваліфіковане доменне імʼя (FQDN).
Отже, всі імена просторів імен повинні бути дійсними DNS-мітками згідно RFC 1123.
Попередження:
Створюючи простори імен із тими ж назвами, що і публічні домени верхнього рівня (TLD), Serviceʼи в цих просторах імен можуть мати короткі імена DNS, які перетинаються з публічними записами DNS. Завдання з будь-якого простору імен, яке виконує DNS-запит без крапки в кінці буде перенаправлено на ці сервіси, отримуючи перевагу над публічним DNS.
Для помʼякшення цього обмеження скоротіть привілеї для створення просторів імен довіреним користувачам. Якщо необхідно, ви можете додатково налаштувати сторонні перевірки на забезпечення безпеки, такі як обробники доступу, щоб блокувати створення будь-якого простору імен з іменем публічних TLD.
Не всі обʼєкти мають простори імен
Більшість ресурсів Kubernetes (наприклад, pods, services, replication controllers та інші) є в деяких просторах імен. Однак ресурси простору імен самі не перебувають в просторі імен. І ресурси низького рівня, такі як nodes та persistentVolumes, не перебувають в жодному просторі імен.
Щоб переглянути, які ресурси Kubernetes є в просторі імен, а які — ні:
# В просторі імен
kubectl api-resources --namespaced=true
# Не в просторі імен
kubectl api-resources --namespaced=false
Автоматичне маркування
Kubernetes 1.22 [stable]Панель управління Kubernetes встановлює незмінювану мітку kubernetes.io/metadata.name для всіх просторів імен. Значення мітки — це назва простору імен.
Що далі
- Дізнайтеся більше про створення нового простору імен.
- Дізнайтеся більше про видалення простору імен.