Запросить демо
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Оставить заявку
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Узнать стоимость
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Попробовать бесплатно
Я подтверждаю свое согласие на обработку компанией КРОК моих персональных данных, указанных в форме, в целях и пределах, установленных законодательством РФ о персональных данных в рамках проводимых мероприятий в течение неопределенного срока
Дополнительные услуги
Быть в теме

Kubernetes-введение

04.06.2018 8 минут 1501

What is Kubernetes? На официальном сайте проекта Kubernetes определяется как система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями. Важно сразу отметить, что эта система не “готовое на все случаи жизни решение”.

Kubernetes – это фреймворк, который на 90% готов помочь вам решить всего одну простую задачу – построить собственную отказоустойчивую и масштабируемую платформу управления контейнерами. Причем, построить свою платформу на базе Kubernetes можно на физических и виртуальных серверах, любой системе виртуализации, а также в публичном или частном облаке.

В настоящее время этот проект активно развивается, но не смотря на это, он вполне может использоваться компаниями любого уровня: малым и средним бизнесом, а также Enterprise.

Документация на Kubernetes очень подробная, полностью описывает принципы его работы, варианты инсталляции и использования, но ее разделы логически плохо связаны друг с другом, что делает ее достаточно сложной для понимания даже профессионалам. В этой статье будут пояснены основные составляющие Kubernetes и их назначение, чтобы максимально упростить вам дальнейшее знакомство с этой платформой.

Введение

Итак, для работы Kubernetes необходимы физические или виртуальные серверы, выполняющие следующие роли:


  • Master (мастер) — серверы с этой ролью отвечают за управление Kubernetes кластером. Серверы с этой ролью координируют все процессы в кластере: планирование размещения и поддержание требуемого состояния приложений, их масштабирование и обновление.
  • Node (узел) — серверы с этой ролью непосредственно обеспечивают работу приложений запущенных в кластере Kubernetes. На каждом сервере с ролью node запущен процесс Kubelet, управляющий этим сервером. Взаимодействие node и master серверов происходит через API. Помимо Kubelet на серверах с ролью node обычно также установлен Docker Engine, обеспечивающий работу с контейнерами.

Вся работа с контейнеризированными приложениями внутри Kubernetes описывается несколькими абстракциями (или сущностями), данные о которых хранятся в etcd. Вот некоторые из наиболее важных для понимания абстракций:


  • Deployment
  • Pod
  • Service
  • Volume
  • Namespace

Deployment

Это абстракция, описывающая для Kubernetes конечное состояние вашего приложения: из каких образов запускать контейнеры вашего приложения, а также какое количество и этих контейнеров должно быть в итоге. После создания объекта Deployment внутри Kubernetes Deployment-контроллер приводит ваше приложение к описанному состоянию, запуская новые или удаляя лишние контейнеры. Эта абстракция обеспечивает также восстановление работоспособности вашего приложения в случае, если узел, на котором располагались контейнеры вашего приложения, внезапно вышел из строя: нужное количество контейнеров, описанное в Deployment, будет снова запущено на свободных узлах кластера.

Pod

Важно отметить, что в процессе работы с Kubernetes вы не управляете непосредственно контейнерами вашего приложения. Вместо этого вы управляете абстракцией типа Pod, которая описывает один или несколько контейнеров вашего приложения, а также все ресурсы, которые эти контейнеры должны использовать совместно, например, виртуальные диски (Volume) или уникальный кластерный IP-адрес.

Внутри Pod могут быть запущены контейнеры с различными приложениями, которые тесно связаны друг с другом и могут совместно и без конфликтов использовать один выделенный на Pod сетевой адрес, диапазон портов или дисковое пространство. Например, Pod может содержать 2 контейнера: первый контейнер — это web-приложение, обслуживающее запросы ваших пользователей, а второй контейнер — сервис, например, сохраняющий для первого данные на общей файловой системе. Контейнеры, описанные в Pod управляются Kubernetes совместно: происходит их одновременный запуск, остановка или удаление. Все контейнеры, описанные в Pod, запускаются и существуют на одном и том же физическом сервере.

Сетевое взаимодействие между несколькими Pod, находящихся на разных серверах наглядно изображено на топологии flannel:

Service (Сервис)

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

Сервис — это абстракция, которая определяет логическую группу из нескольких Pod и то, как к ним обращаться.

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


Volume (Диск)

Абстракция Volume (диск) используется для предоставления контейнерам дисковых ресурсов с любого типа СХД. В отличии от Docker дисков, диски в Kubernetes имеют явно заданное время жизни, ровно столько же, сколько живет использующий их Pod. Таким образом, диск запросто может пережить перезапуск любого контейнера внутри Pod. Конечно, если Pod завершает работу и связанный с ним диск. Также важно, что Kubernetes поддерживает большое количество различных типов дисков, которые Pod может использовать их в любом количестве одновременно:


  • emptyDir
  • hostPath
  • gcePersistentDisk
  • awsElasticBlockStore
  • nfs
  • iscsi
  • flocker
  • glusterfs
  • rbd
  • cephfs
  • gitRepo
  • secret
  • persistentVolumeClaim
  • downwardAPI
  • azureFileVolume
  • azureDisk
  • vsphereVolume
  • Quobyte

Namespace (Пространства имен)

Kubernetes поддерживает возможность организации множества виртуальных кластеров, используя при этом одни и те же серверы, входящие в кластер. Эти виртуальные кластеры называются Namespaces (Пространства имен).

Пространства имен необходимы в окружениях, используемых несколькими пользователями, разделяемых между различными командами или проектами. Для кластеров, которые используются менее чем 10-ю пользователями, думать об использовании Пространств имен не нужно.

    Пространства имен:
  • Определяют область видимости имен: имена ресурсов должны быть уникальны в пределах одного пространства имен.
  • Являются способом разделить ресурсы кластера между несколькими пользователями.

Дополнительная информация

И еще один момент, о котором лучше знать в самом начале: в Kubernetes нет механизмов и решений, позволяющих заниматься балансировкой трафика на сервисы (Services) ваших приложений — для этого необходимо использовать сторонние балансировщики, например, Nginx, HAproxy, коммерческие программные или аппаратные решения или же балансировщики, предоставляемые вам облачным провайдером, т.к. AWS Elastic Load Balancer (ELB).


Если вы хотите использовать Nginx или HAproxy и решать этот вопрос самостоятельно, делать это придется с использованием confd. Суть решения в том, что confd будет забирать обновленную конфигурацию о сервисах из etcd, обновлять конфигурации Nginx или HAproxy и перезапускать их.

Сервисы упоминаемые в статье

  1. Публичное облако КРОК

Не пропустите самые важные, интересные и полезные статьи недели

Ваш e-mail успешно подписан.

Смотрите также