Kubernetes поддерживает и продвигает несколько концепций: * pods – группы контейнеров, которые развертываются и планируются совместно. В Kubernetes такие группы образуют неделимую единицу планирования в противоположность отдельным контейнерам в других системах. Группа обычно содержит от 1 до 5 контейнеров, совместно обеспечивающих работу некоторого сервиса. В дополнение к этим пользовательским контейнерам Kubernetes запускает вспомогательные контейнеры для сервисов ведения журналов и контроля. В Kubernetes такие группы считаются непостоянными – в процессе развития системы они могут создаваться и уничтожаться * flat networking space – в Kubernetes функционирование сетевой среды значительно отличается от работы сети с Docker-шлюзом, принимаемой по умолчанию. В сетевой среде Docker по умолчанию контейнеры существуют в закрытой подсети и не могут напрямую обмениваться данными с контейнерами на других хостах без перенаправления портов на хосте или без использования механизма прокси. В Kubernetes контейнеры в одной группе (pod) совместно используют один IP-адрес, но все адресное пространство является «плоским» для всех групп (pods), таким образом, все группы (pods) могут обмениваться информацией друг с другом без какого-либо преобразования сетевых адресов (NAT). Это существенно упрощает управление многохостовыми кластерами, но при этом не поддерживаются внутренние каналы связи, а организация сетевой среды для одного хоста (или, более точно, для одной группы) становится чуть более сложной. Поскольку контейнеры одной группы (pod) совместно используют общий IP-адрес, они могут обмениваться данными, используя порты по адресу localhost (это означает, что вы сами должны управлять использованием портов внутри группы (pod)). * labels – ярлыки представляют собой пары ключ-значение, закрепленные за объектами в Kubernetes, в основном за группами (pods), и используемые для определения идентификационных характеристик объекта (например, version:devилиtier:frontend). Обычно ярлыки могут быть повторяющимися, предполагается, что они идентифицируют группы контейнеров. Селекторы ярлыков (label selectors) могут использоваться для определения объектов или групп объектов (например, все группы внешних сервисов системы с окружением, предназначенным для промышленной эксплуатации). Использование ярлыков упрощает объединение однотипных задач, таких как распределение групп контейнеров (pods), по более крупным группам, созданным для балансировки нагрузки, или динамическое перемещение групп контейнеров; * services – сервисы являются стабильными точками входа, к которым можно обращаться по имени. Сервисы могут устанавливать соединения с группами контейнеров (pods), используя селекторы ярлыков. Например, мой сервис cache может установить соединение с несколькими группами (pods) redis, определяемыми по селектору ярлыка"type":"redis". Этот сервис будет автоматически посылать циклические запросы, распределяемые по заданным группам (pods). Таким образом, сервисы можно использовать для соединения различных частей системы. Применение сервисов обеспечивает такой уровень абстракции, при котором приложению не нужно знать внутренних подробностей сервисов, к которым оно обращается. Например, код приложения, выполняемый внутри группы (pods), для обращения к базе данных должен знать только имя и порт соответствующего сервиса, при этом не имеет никакого значения, сколько групп контейнеров (pods) образуют эту базу данных или с какой группой (pod) производился обмен данными во время предыдущего сеанса связи. Kubernetes настраивает для кластера DNS-сервер, который отслеживает появление новых сервисов и обеспечивает обращение к ним по имени как в коде приложения, так и в файлах конфигурации. Контроллеры репликации (replication controllers) представляют собой обычный способ создания экземпляров групп контейнеров в Kubernetes (как правило, при работе в Kubernetes вы не используете интерфейса командной строки Docker). Эти контроллеры предназначены для управления и отслеживания больших количеств работающих групп контейнеров (называемых репликами (replicas)), связанных с некоторым сервисом. Например, контроллер репликации может отвечать за поддержку в рабочем состоянии пяти групп Redis. Если одна из групп становится неработоспособной, то контроллер немедленно запускает в работу новую группу. Если количество реплик нужно сократить, контроллер остановит работу всех лишних групп. Несмотря на то что применение контроллеров репликации для управления всеми экземплярами групп добавляет еще один уровень конфигурации, тем не менее при этом значительно улучшаются устойчивость к критическим сбоям и надежность системы. Пример кластера Kubernetes ![Структура данных буферного кэша](https://whoisdeveloper.ru/static/img/docker1.png) На рисунке показана часть кластера Kubernetes с двумя группами контейнеров, созданными контроллером репликации и объявленными некоторым сервисом. Сервис посылает циклические запросы, распределяемые по этим группам, которые выбираются по значению ярлыка tier. Внутри группы все контейнеры совместно используют один IP-адрес. Контейнеры внутри группы могут обмениваться данными, используя порты по адресу localhost. Сервису присвоен отдельный IP-адрес, доступ к которому открыт для всех. ### Тома в Kubernetes В Kubernetes тома отличаются от томов Docker. Главное различие состоит в том, что тома объявляются на уровне групп (pods), а не на уровне контейнера, и могут совместно использоваться всеми контейнерами группы. Kubernetes предлагает несколько типов томов для различных вариантов использования: • emptyDir – в группе инициализируется пустой каталог, в который могут писать контейнеры данной группы. При удалении группы удаляется и каталог. Это удобно для хранения временных данных, требуемых только в течение жизненного цикла группы, или для данных, которые регулярно копируются в другое, более надежное постоянное хранилище; • gcePersistentDisk – для пользователей GKE. Этот том можно использовать для хранения данных в Google Cloud. Данные сохраняются и после завершения жизненного цикла группы; • awsElasticBlockStore – для пользователей AWS. Этот том можно использовать для хранения данных в Amazon's Elastic Block Store (EBS). Данные сохраняются и после завершения жизненного цикла группы; • nfs – для доступа к файлам, совместно используемым в сетевой файловой системе Network File System (NFS). И в этом случае данные будут сохранены после завершения жизненного цикла группы; • secret – для хранения важной закрытой информации, такой как пароли и API- токены, используемые группой. Тома типа secret обязательно должны создаваться только через Kubernetes API. Они хранятся в файловой системе tmpfs, которая существует исключительно в оперативной памяти и никогда не записывается на диск.