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

Sirmax в 08:08, 9 января 2024

2024-01-09T08:08:22Z

← Предыдущая		Версия 08:08, 9 января 2024
Строка 1:		Строка 1:
−	[[Категория:~~k8s~~]]	+	[[Категория:K8s]]
		+	[[Категория:K8s_Вопросы_И_Ответы]]
		+	[[Категория:Требуется форматирование текста]]
		+
	=Что такое POD=		=Что такое POD=
	Эта страница - часть документации для подготовки к прохождению собеседования		Эта страница - часть документации для подготовки к прохождению собеседования

Sirmax в 08:07, 9 января 2024

2024-01-09T08:07:44Z

← Предыдущая		Версия 08:07, 9 января 2024
Строка 151:		Строка 151:
	* Приложение сливает существующее соединение.		* Приложение сливает существующее соединение.
	* Приложение отключается.		* Приложение отключается.
		+
		+
		+	=Ссылки=
		+	* https://habr.com/ru/companies/slurm/articles/783708/

Sirmax: /* Что происходит, когда вы создаёте Pod в Kubernetes? */

2024-01-09T08:07:05Z

Что происходит, когда вы создаёте Pod в Kubernetes?

← Предыдущая		Версия 08:07, 9 января 2024
Строка 89:		Строка 89:
	Но под капотом скрывается сложный рабочий процесс, который затрагивает несколько компонентов кластера.		Но под капотом скрывается сложный рабочий процесс, который затрагивает несколько компонентов кластера.

		+	==kubectl==
	Начнем с очевидного: kubectl отправляет определение YAML на сервер API.		Начнем с очевидного: kubectl отправляет определение YAML на сервер API.
	На этом этапе kubectl:		На этом этапе kubectl:
Строка 96:		Строка 97:
	* Выдает запрос.		* Выдает запрос.

		+	==API==
	Когда запрос попадает к API, он проходит следующие этапы:		Когда запрос попадает к API, он проходит следующие этапы:
	* Аутентификация и авторизация.		* Аутентификация и авторизация.
Строка 101:		Строка 103:
	* На последнем этапе он сохраняется в etcd.		* На последнем этапе он сохраняется в etcd.

		+	==Scheduler==
	После этого pod добавляется в очередь планировщика.		После этого pod добавляется в очередь планировщика.
	* Планировщик фильтрует и оценивает узлы, чтобы найти лучший.		* Планировщик фильтрует и оценивает узлы, чтобы найти лучший.
Строка 108:		Строка 111:
	На данный момент pod существует только в etcd в виде записи.		На данный момент pod существует только в etcd в виде записи.
	Инфраструктура еще не создала ни одного контейнера.		Инфраструктура еще не создала ни одного контейнера.
		+
		+	==kubelet==
	Здесь за дело берется kubelet.		Здесь за дело берется kubelet.

Строка 132:		Строка 137:
	* CoreDNS для обновления записей DNS.		* CoreDNS для обновления записей DNS.
	* Контроллеры входа для настройки нисходящих потоков.		* Контроллеры входа для настройки нисходящих потоков.
−
	* Сервисные сетки.		* Сервисные сетки.
	* И другие операторы.		* И другие операторы.
⚫	Как только добавляется конечная точка, компоненты получают уведомления.

		⚫	Как только добавляется конечная точка, компоненты получают уведомления.
		+	<BR>
	Когда конечная точка (IP:порт) будет передана, вы наконец-то сможете начать использовать Pod!		Когда конечная точка (IP:порт) будет передана, вы наконец-то сможете начать использовать Pod!

Sirmax в 08:05, 9 января 2024

2024-01-09T08:05:49Z

← Предыдущая		Версия 08:05, 9 января 2024
Строка 81:		Строка 81:
	<BR>		<BR>
	<code>kubectl create -f single-example-pod.yml</code>		<code>kubectl create -f single-example-pod.yml</code>
		+
		+
		+
		+	=Что происходит, когда вы создаёте Pod в Kubernetes?=
		+
		+	Создание Pod в Kubernetes — простая задача.
		+	Но под капотом скрывается сложный рабочий процесс, который затрагивает несколько компонентов кластера.
		+
		+	Начнем с очевидного: kubectl отправляет определение YAML на сервер API.
		+	На этом этапе kubectl:
		+	* Обнаруживает эндпоинты API с помощью OpenAPI (Swagger).
		+	* Согласовывает версию ресурса.
		+	* Проверяет YAML.
		+	* Выдает запрос.
		+
		+	Когда запрос попадает к API, он проходит следующие этапы:
		+	* Аутентификация и авторизация.
		+	* Контроллеры допуска. (admission controllers)
		+	* На последнем этапе он сохраняется в etcd.
		+
		+	После этого pod добавляется в очередь планировщика.
		+	* Планировщик фильтрует и оценивает узлы, чтобы найти лучший.
		+	* И, наконец, привязывает pod к ноде.
		+	* Привязка записывается в etcd.
		+
		+	На данный момент pod существует только в etcd в виде записи.
		+	Инфраструктура еще не создала ни одного контейнера.
		+	Здесь за дело берется kubelet.
		+
		+	Kubelet извлекает Pod definition и приступает к делегированию:
		+
		+	* Создание сети на CNI (например, Cilium).
		+	* Создание контейнера - CRI (например, containerd).
		+	* Создание хранилища - CSI (например, OpenEBS).
		+
		+	Кроме всего прочего, Kubelet будет выполнять проверки Pod и,
		+	если Pod запущен, сообщать его IP-адрес в control plane.
		+	Этот IP-адрес и порты контейнеров хранятся в etcd как эндпоинты.
		+
		+	Подождите... эндпоинты?
		+	В Kubernetes:
		+
		+	* endpoint - это пара 10.0.0.2:3000 (IP:порт).
		+	* Endpoint - это коллекция конечных точек (список пар IP:порт).
		+
		+	Для каждого сервиса в кластере Kubernetes создает объект Endpoint с конечными точками.
		+
		+	Эндпоинты (IP:порт) используются:
		+	* kube-proxy для установки правил iptables.
		+	* CoreDNS для обновления записей DNS.
		+	* Контроллеры входа для настройки нисходящих потоков.
		+
		+	* Сервисные сетки.
		+	* И другие операторы.
		+	Как только добавляется конечная точка, компоненты получают уведомления.
		+
		+	Когда конечная точка (IP:порт) будет передана, вы наконец-то сможете начать использовать Pod!
		+
		+	==Что происходит, когда вы удаляете Pod?==
		+	Точно такой же процесс, но в обратном порядке.
		+	Правильная последовательность такова:
		+	* Приложение перестает принимать соединения.
		+	* Контроллеры (kube-proxy, ingress и т. д.) удаляют конечную точку.
		+	* Приложение сливает существующее соединение.
		+	* Приложение отключается.

Sirmax: /* Работа POD */

2024-01-02T16:40:43Z

Работа POD

← Предыдущая		Версия 16:40, 2 января 2024
Строка 79:		Строка 79:
	</PRE>		</PRE>
	Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl:		Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl:
−	<~~PRE~~>	+	<BR>
	<code>kubectl create -f single-example-pod.yml</code>		<code>kubectl create -f single-example-pod.yml</code>

Sirmax: /* Хранилище */

2024-01-02T16:40:30Z

Хранилище

← Предыдущая		Версия 16:40, 2 января 2024
Строка 38:		Строка 38:
	* ConfigMap ?		* ConfigMap ?
	* Secret?		* Secret?
		+
		+	=Работа POD=
	<BR>		<BR>
	Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:		Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:

Sirmax: /* Что такое POD */

2024-01-02T16:39:56Z

Что такое POD

← Предыдущая		Версия 16:39, 2 января 2024
Строка 6:		Строка 6:
	* одного или нескольких контейнеров		* одного или нескольких контейнеров
	* TODO: init container?		* TODO: init container?
		+	* TODO: sidecar container?
	* хранилища (storage)		* хранилища (storage)
	* отдельного IP-адреса		* отдельного IP-адреса

Sirmax в 16:39, 2 января 2024

2024-01-02T16:39:31Z

@@ Строка 37: / Строка 37: @@
 * ConfigMap ?
 * Secret?
 Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:
-не завершится процесс внутри Pod'а (например, если это одноразовая задача);
+* не завершится процесс внутри Pod'а (например, если это одноразовая задача);
-Pod не будет удален вручную;
+* Pod не будет удален вручную;
-Pod не будет “выселен” с ноды из-за нехватки ресурсов;
+* Pod не будет “выселен” с ноды из-за нехватки ресурсов;
-нода не выйдет из строя.
+* нода не выйдет из строя.
 apiVersion: v1
 kind: Pod
@@ Строка 66: / Строка 74: @@
     image: busybox
     command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
 Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl:
-kubectl create -f single-example-pod.yml
+<code>kubectl create -f single-example-pod.yml</code>

Sirmax в 16:37, 2 января 2024

2024-01-02T16:37:02Z

@@ Строка 1: / Строка 1: @@
 [[Категория:k8s]]
 Важно Kubernetes управляет Pod'ами, а не контейнерами напрямую.
 В кластере Kubernetes Pod'ы используются двумя способами:
 Каждый Pod предназначен для запуска одного экземпляра конкретного приложения. Если есть необходимость горизонтального масштабирования, то можно запустить несколько экземпляров Pod'а - в терминологии Kubernetes это называется репликацией. Реплицированные Pod'ы создаются и управляются как единая группа абстракцией, которая называется контроллер (Controller).
-Pod'ы спроектированы для поддержки множества взаимодействующих процессов (например, контейнеров), которые образуют отдельный сервис (единицу обслуживания). Контейнеры внутри Pod'а автоматически размещаются и управляются на одной и той же физической (или виртуальной) ноде кластера. Контейнеры в Pod'е могут совместно использовать ресурсы и зависимости, взаимодействовать друг с другом и определять, когда и как они будут завершаться.
+Pod'ы спроектированы для поддержки множества взаимодействующих процессов (например, контейнеров)
 Pod'ы предоставляют запущенным внутри контейнерам два типа общих ресурсов: сеть и хранилище.
-Сеть
+=Сеть=
-Каждому Pod'у присваивается уникальный IP-адрес. Внутри Pod'а каждый контейнер использует общее пространство имен (namespace) сети, включая IP-адрес и сетевые порты. Между собой внутри Pod'а контейнеры взаимодействуют через localhost. При взаимодействии с объектами, находящимися за пределами Pod'а, контейнеры “договариваются” между собой и координируют использование общих сетевых ресурсов (таких как порты).
+* Внутри Pod'а каждый контейнер использует общее пространство имен (namespace) сети, включая IP-адрес и сетевые порты.
 Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:

Sirmax: Новая страница: «Категория:k8s Pod (переводится с английского как стручок) состоит обычно из одного или не...»

2024-01-02T16:29:57Z

Новая страница: «Категория:k8s Pod (переводится с английского как стручок) состоит обычно из одного или не...»

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

[[Категория:k8s]]

Pod (переводится с английского как стручок) состоит обычно из одного или нескольких контейнеров, хранилища (storage), отдельного IP-адреса и опций, которые определяют, как именно контейнер(ы) должны запускаться. Также Pod представляет собой некий запущенный процесс в кластере Kubernetes.

Чаще всего в Pod'ах используются docker-контейнеры (что и не удивительно), но можно использовать и другие контейнеры (например, rkt от CoreOS).

Важно Kubernetes управляет Pod'ами, а не контейнерами напрямую.

В кластере Kubernetes Pod'ы используются двумя способами:

Pod из одного контейнера - наиболее распространенный случай использования. В этом варианте Pod можно представить как обертку вокруг одного контейнера;
Pod из нескольких контейнеров, работающих сообща - контейнеры в данном случае образуют отдельную единицу (сервис) и используют общие ресурсы - например, файлы из одного хранилища (storage). При этом, отдельный контейнер Pod'а может обновлять эти файлы.
Каждый Pod предназначен для запуска одного экземпляра конкретного приложения. Если есть необходимость горизонтального масштабирования, то можно запустить несколько экземпляров Pod'а - в терминологии Kubernetes это называется репликацией. Реплицированные Pod'ы создаются и управляются как единая группа абстракцией, которая называется контроллер (Controller).

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

К слову, группировка и запуск нескольких контейнеров в Pod'е считается “продвинутым” вариантом использования, и применять этот шаблон нужно только при реальной необходимости. Например, у вас может быть контейнер с web-сервером, использующий файлы из общего (относительно Pod'а) хранилища, и отдельный контейнер, который обновляет эти файлы из удаленного источника.

Pod'ы предоставляют запущенным внутри контейнерам два типа общих ресурсов: сеть и хранилище.

Сеть

Каждому Pod'у присваивается уникальный IP-адрес. Внутри Pod'а каждый контейнер использует общее пространство имен (namespace) сети, включая IP-адрес и сетевые порты. Между собой внутри Pod'а контейнеры взаимодействуют через localhost. При взаимодействии с объектами, находящимися за пределами Pod'а, контейнеры “договариваются” между собой и координируют использование общих сетевых ресурсов (таких как порты).

Хранилище

Pod может определить набор общих томов (volumes) для хранения данных. Контейнеры внутри Pod'а могут работать с этими томами и, таким образом, обмениваться данными между собой. Благодаря использованию томов, можно сохранить данные, если один из контейнеров Pod'а (которому нужны эти данные для корректной работы) должен быть перезапущен. Время жизни томов совпадает с временем жизни самого Pod'а.

Что касается работы в кластере Kubernetes, то редко когда приходится создавать и запускать отдельные Pod'ы вручную (варианты запуска при ознакомлении с Kubernetes мы в расчет не берем). Связано это с тем, что Pod'ы изначально проектировались как эфемерные объекты, минимальные единицы, “строительные блоки” для сущностей более высокого уровня (например, контроллеров). Когда Pod создается (не важно, вручную вами или контроллером), он по плану (за это отвечает scheduler) запускается на одной из нод кластера Kubernetes. На этой ноде Pod остается до тех пор, пока:

не завершится процесс внутри Pod'а (например, если это одноразовая задача);
Pod не будет удален вручную;
Pod не будет “выселен” с ноды из-за нехватки ресурсов;
нода не выйдет из строя.
Примечание Перезапуск контейнера внутри Pod'а не следует путать с перезапуском самого Pod'а.

Сами по себе Pod'ы не являются “самолечащимися” (self-healing) объектами. Если запуск Pod'а запланирован на ноде, которая вышла из строя, или сама операция запуска потерпела крах, то Pod удаляется. Точно также, при нехватке ресурсов на ноде (когда Pod'ы “выселяются”) или при переводе ноды в режим обслуживания, Pod'ы не будут запущены на других узлах и удалятся. Для обеспечения запуска на других нодах (и управления Pod'ами в целом) в Kubernetes используются абстракции более высокого уровня, называемые контроллерами - в основном именно с ними и приходится иметь дело.

Контроллер может управлять несколькими экземплярами Pod'ов - в том числе обеспечивать репликацию и самовосстановление в пределах кластера (при выходе из строя ноды, идентичный экземпляр Pod'а будет запущен на другой ноде). Примером контроллера, который содержит в себе один или несколько экземпляров Pod'а могут быть:

Deployment
StatefulSet
DaemonSet
Для обеспечения такого функционала контроллеры используют шаблоны Pod'ов (Pod Templates). Шаблон Pod'а - спецификация, которая используется контроллерами и другими объектами (например, заданиями - Jobs/CronJob) для запуска настоящего, реального Pod'а. Ниже приведен пример простой спецификации (ее еще иногда называют манифестом), описывающей контейнер, который напечатает сообщение при запуске и “уснет” на час:

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
Предложенный манифест (спецификацию) можно сохранить в файле single-example-pod.yml и запустить Pod с помощью утилиты командной строки kubectl:

kubectl create -f single-example-pod.yml