в kubernetes

Знакомство с Kubernetes. Часть 10: Неймспейсы (namespaces)


Kubernetes поддерживает несколько виртуальных кластеров, работающих в одном и том же физическом кластере. Эти виртуальные кластеры называются пространствами имен или неймспейсами (namespaces). Давайте разберемся!

Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.

Неймспейсы, как можно догадаться с названия, предоставляют набор (или область) имен для ресурсов. Имена ресурсов должны быть уникальными в пределах одного неймспейса, но не в пределах всего кластера. Кроме того, неймспейсы — это способ разделить ресурсы кластера между пользователями (с использованием квот).

Еще раз отмечу: нет необходимости использовать разные неймспейсы для разделения нескольких разных ресурсов, например, разных версий одного и того же ПО — здесь лучше воспользоваться метками и селекторами (для выделения ресурсов) в одном и том же пространстве имен.

По умолчанию в кластере Kubernetes будет создан неймспейс default, в котором и будут размещаться запускаемые объекты (поды, сервисы, развертывания и т.д.). Неймспейсы kube-public и kube-system используются для запуска служебных объектов Kubernetes, необходимых для корректной работы кластера.

Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:

kubectl get namespaces
NAME          STATUS    AGE
default       Active    46d
kube-public   Active    46d
kube-system   Active    46d

Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:

{
  "kind": "Namespace",
  "apiVersion": "v1",
  "metadata": {
    "name": "development",
    "labels": {
      "name": "development"
    }
  }
}

и выполним команду:

kubectl apply -f namespace-dev.json

Для второго неймспейса создадим файл с тем же содержимым, но заменим слова «development» на «production» и применим его:

kubectl apply -f namespace-prod.json

Убедимся, что неймспейсы успешно создались:

kubectl get namespaces --show-labels
NAME          STATUS    AGE       LABELS
default       Active    46d       <none>
development   Active    2m        name=development
kube-public   Active    46d       <none>
kube-system   Active    46d       <none>
production    Active    2m        name=production

Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:

kubectl config view
apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://localhost:6443
  name: docker-for-desktop-cluster
contexts:
- context:
    cluster: docker-for-desktop-cluster
    user: docker-for-desktop
  name: docker-for-desktop
current-context: docker-for-desktop
kind: Config
preferences: {}
users:
- name: docker-for-desktop
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
kubectl config current-context
docker-for-desktop

Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):

kubectl config set-context dev --namespace=development \
  --cluster=docker-for-desktop-cluster \
  --user=docker-for-desktop
kubectl config set-context prod --namespace=production \
  --cluster=docker-for-desktop-cluster \
  --user=docker-for-desktop

После выполнения этих двух команд к конфигурационном файле ~/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:

kubectl config use-context dev

и

kubectl config use-context prod

Кроме того, выполнять команды с конкретным неймспейсом можно даже не переключая контекст — достаточно использовать дополнительный параметр --namespace=, например:

kubectl --namespace=dev run nginx --image=nginx

или

kubectl --namespace=prod get pods

Напоследок стоит сказать, что при создании сервиса (service) в кластере Kubernetes создается соответствующая DNS-запись. Запись создается в формате <service-name>.<namespace-name>.svc.cluster.local, а это означает, что если вы используете только часть <service-name> то это позволит «достучаться» до сервиса только в пределах неймспейса. Если вам необходимо взаимодействовать с сервисом, запущенным в другом неймспейсе, следует использовать полное доменное имя (FQDN).

Добавить комментарий

  1. Спасибо Евгений за ваш, очень интересно читать Ваши статьи. А будет статейка о сохранении данных в kubernetes? И может какую нибудь статью в духе mysql в кластере.

    • Kubernetes изначально задумывался как система для stateless приложений, поэтому насчет «сохранения данных» ничего обещать не могу, это очень индивидуальные и рискованные кейсы.
      Но все может быть )