#k8s
Емкое слово pod, означающее в английском то ли стручок бобового растения (см. «шапку поста»), то ли группу (стаю) морских млекопитающих, вроде дельфинов или китов (см. лого Docker), в некоторых плохих переводах неплохих тематических книг обозначается как МОДУЛЬ. Скажите мне, зачем переводить на русский язык технические термины?
Но это тема для отдельного поста.
Нас же интересует, что за сущность такая в Kubernetes pod и какую задачу она решает. Почему вообще оркестратор контейнеров работает не с контейнерами как таковыми, а с pod’ами, которые в свою очередь эти контейнеры содержат?
Неправильный ответ на вопрос, что такое pod, мог бы звучать как-то так:
Под в Kubernetes — это особый контейнер, который может содержать несколько других контейнеров, но обычно содержит только один. Фактически это всё тот же контейнер, только с дополнительной k8s спецификой.
Контейнер — это среда для одного процесса, а pod — среда для контейнеров. Как контейнер обеспечивает изоляцию процесса, так pod обеспечивает изоляцию одного или нескольких контейнеров. При этом pod даёт размещённым внутри него контейнерам общий контекст: снабжает их общими ресурсами и упрощает взаимодействие.
Аналогия, объясняющая pod как «logical host» для приложения, мне нравится. Идея в том, что контейнер предназначен для запуска только одного процесса: каждому процессу — свой контейнер. А значит, для группировки и связывания контейнеров нам необходима конструкция более высокого уровня.
У нас есть несколько родственных процессов, которые требуется обеспечить (почти) одинаковой средой выполнения и одним и тем же контекстом. Вместо того чтобы запускать все процессы в одном контейнере, мы разделяем их на независимые, но тесно связанные, контейнеры и помещаем внутрь pod. Так достигается комбинация изоляции — с одной стороны — и удобной интеграции — с другой.
В следующих постах попытаемся расширить тему. В частности, попробуем понять, каким контейнерам удобно подобное «внутриподовое» соседство, поговорим о pod lifecycle, о pod статусах и о многом другом, а потом пойдём вверх по иерархии и поймём, что управляет самими pod’ами.
