Kubernetes-введение

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

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

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

• Deployment
• Pod
• Service
• Volume
• Namespace

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

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

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

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

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

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

Абстракция 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

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

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

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

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