K8s Q A Namespaces - История изменений

Sirmax в 14:15, 8 января 2024

2024-01-08T14:15:32Z

← Предыдущая		Версия 14:15, 8 января 2024
Строка 24:		Строка 24:
	</PRE>		</PRE>
	Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:		Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:
		+	<PRE>
−
	{		{
	"kind": "Namespace",		"kind": "Namespace",
Строка 35:		Строка 35:
	}		}
	}		}
		+	</PRE>
	и выполним команду:		и выполним команду:

	kubectl apply -f namespace-dev.json		kubectl apply -f namespace-dev.json
		+	<BR>
	Для второго неймспейса создадим файл с тем же содержимым, но заменим слова “development” на “production” и применим его:		Для второго неймспейса создадим файл с тем же содержимым, но заменим слова “development” на “production” и применим его:

	kubectl apply -f namespace-prod.json		kubectl apply -f namespace-prod.json
		+	<BR>
	Убедимся, что неймспейсы успешно создались:		Убедимся, что неймспейсы успешно создались:
		+	<PRE>
−
	kubectl get namespaces --show-labels		kubectl get namespaces --show-labels
	NAME STATUS AGE LABELS		NAME STATUS AGE LABELS
Строка 50:		Строка 53:
	kube-system Active 46d <none>		kube-system Active 46d <none>
	production Active 2m name=production		production Active 2m name=production
		+	</PRE>
	Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:		Далее, для удобства, для каждого из созданных неймспейсов сделаем отдельный контекст. Для начала, посмотрим текущие настройки:
		+	<PRE>
−
	kubectl config view		kubectl config view
	apiVersion: v1		apiVersion: v1
Строка 72:		Строка 76:
	client-certificate-data: REDACTED		client-certificate-data: REDACTED
	client-key-data: REDACTED		client-key-data: REDACTED
		+	<PRE>
	kubectl config current-context		kubectl config current-context
	docker-for-desktop		docker-for-desktop
		+	<BR>
	Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):		Создаем два отдельных контекста (они будут отличаться неймспейсами, а значения полей cluster и user будут скопированы с текущего контекста):
		+	<PRE>
−
	kubectl config set-context dev --namespace=development \		kubectl config set-context dev --namespace=development \
	--cluster=docker-for-desktop-cluster \		--cluster=docker-for-desktop-cluster \
Строка 82:		Строка 88:
	--cluster=docker-for-desktop-cluster \		--cluster=docker-for-desktop-cluster \
	--user=docker-for-desktop		--user=docker-for-desktop
		+	</PRE>
	После выполнения этих двух команд к конфигурационном файле ~/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:		После выполнения этих двух команд к конфигурационном файле ~/.kube/config будут созданы дополнительные контексты. Теперь можно с легкостью переключаться между ними используя команды:

−	kubectl config use-context dev	+	kubectl config use-context dev <BR>
	и		и

−	kubectl config use-context prod	+	kubectl config use-context prod <BR>
		+
	Кроме того, выполнять команды с конкретным неймспейсом можно даже не переключая контекст - достаточно использовать дополнительный параметр --namespace=, например:		Кроме того, выполнять команды с конкретным неймспейсом можно даже не переключая контекст - достаточно использовать дополнительный параметр --namespace=, например:

Строка 94:		Строка 102:

	kubectl --namespace=prod get pods		kubectl --namespace=prod get pods
		+
⚫	Напоследок стоит сказать, что при создании сервиса (service) в кластере Kubernetes создается соответствующая DNS-запись. Запись создается в формате <service-name>.<namespace-name>.svc.cluster.local, а это означает, что если вы используете только часть <service-name> то это позволит “достучаться” до сервиса только в пределах неймспейса. Если вам необходимо взаимодействовать с сервисом, запущенным в другом неймспейсе, следует использовать полное доменное имя (FQDN).
		+	Напоследок стоит сказать, что при создании сервиса (service) в кластере Kubernetes создается соответствующая DNS-запись. (КЕМ? В КАКОМ КЛАСТЕРЕ?)
		+	<BR>
		⚫	Запись создается в формате <service-name>.<namespace-name>.svc.cluster.local, а это означает, что если вы используете только часть <service-name> то это позволит “достучаться” до сервиса только в пределах неймспейса. Если вам необходимо взаимодействовать с сервисом, запущенным в другом неймспейсе, следует использовать полное доменное имя (FQDN).

Sirmax в 14:05, 8 января 2024

2024-01-08T14:05:29Z

← Предыдущая		Версия 14:05, 8 января 2024
Строка 2:		Строка 2:
	[[Категория:K8s_Вопросы_И_Ответы]]		[[Категория:K8s_Вопросы_И_Ответы]]

−	Kubernetes поддерживает несколько виртуальных кластеров, ~~работающих~~ в одном и том же физическом кластере. Эти виртуальные кластеры называются пространствами имен или неймспейсами (namespaces)~~. Давайте разберемся!~~	+	Kubernetes поддерживает несколько "виртуальных кластеров" (c натяжкой),
		+	работающих в одном и том же физическом кластере.
−
		+	<BR>
		+	Эти виртуальные кластеры называются пространствами имен или namespaces.
		+	<BR>
	Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.		Неймспейсы предназначены для использования в окружениях с множеством пользователей, распределенных между несколькими командами или проектами. Для кластеров Kubernetes с небольшим количеством пользователей (несколько десятков) создавать несколько разных неймспейсов не имеет смысла. Неймспейсы стоит начинать использовать в тот момент, когда понадобится функционал, который они предоставляют.
		+	<BR>
−
	Неймспейсы, как можно догадаться с названия, предоставляют набор (или область) имен для ресурсов. Имена ресурсов должны быть уникальными в пределах одного неймспейса, но не в пределах всего кластера. Кроме того, неймспейсы - это способ разделить ресурсы кластера между пользователями (с использованием квот).		Неймспейсы, как можно догадаться с названия, предоставляют набор (или область) имен для ресурсов. Имена ресурсов должны быть уникальными в пределах одного неймспейса, но не в пределах всего кластера. Кроме того, неймспейсы - это способ разделить ресурсы кластера между пользователями (с использованием квот).
		+	<BR>
−
	Еще раз отмечу: нет необходимости использовать разные неймспейсы для разделения нескольких разных ресурсов, например, разных версий одного и того же ПО - здесь лучше воспользоваться метками и селекторами (для выделения ресурсов) в одном и том же пространстве имен.		Еще раз отмечу: нет необходимости использовать разные неймспейсы для разделения нескольких разных ресурсов, например, разных версий одного и того же ПО - здесь лучше воспользоваться метками и селекторами (для выделения ресурсов) в одном и том же пространстве имен.
		+	<BR>
−
	По умолчанию в кластере Kubernetes будет создан неймспейс default, в котором и будут размещаться запускаемые объекты (поды, сервисы, развертывания и т.д.). Неймспейсы kube-public и kube-system используются для запуска служебных объектов Kubernetes, необходимых для корректной работы кластера.		По умолчанию в кластере Kubernetes будет создан неймспейс default, в котором и будут размещаться запускаемые объекты (поды, сервисы, развертывания и т.д.). Неймспейсы kube-public и kube-system используются для запуска служебных объектов Kubernetes, необходимых для корректной работы кластера.
		+	<BR>
−
	Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:		Посмотреть список неймспейсов в вашем кластере можно с помощью такой команды:
		+	<PRE>
−
	kubectl get namespaces		kubectl get namespaces
	NAME STATUS AGE		NAME STATUS AGE
Строка 19:		Строка 22:
	kube-public Active 46d		kube-public Active 46d
	kube-system Active 46d		kube-system Active 46d
		+	</PRE>
	Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:		Чтобы создать отдельный неймспейс, создадим файл namespace-dev.json (да, для разнообразия используем .json, а не .yaml) следующего содержания:

Sirmax в 14:04, 8 января 2024

2024-01-08T14:04:07Z

← Предыдущая		Версия 14:04, 8 января 2024
Строка 1:		Строка 1:
	[[Категория:K8s]]		[[Категория:K8s]]
	[[Категория:K8s_Вопросы_И_Ответы]]		[[Категория:K8s_Вопросы_И_Ответы]]
		+
		+	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).

Sirmax: Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы»

2024-01-08T14:03:27Z

Новая страница: «Категория:K8s Категория:K8s_Вопросы_И_Ответы»

Новая страница

[[Категория:K8s]]
[[Категория:K8s_Вопросы_И_Ответы]]