Знакомство с Kubernetes. Часть 10: Неймспейсы (namespaces)
Jul 2, 2018 07:02 · 515 words · 3 minute read
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).