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

Это создаёт гигантское поощрение к разбиению монолитного приложения на микрослужбы. Основные преимущества очевидны:

Когда монолитное приложение разбивается на большое число микрослужб, это увеличивает сложность развёртывания и управления на стороне DevOps. Основная сложность очевидна; микрослужбы обычно пишутся на различных языках программирования, которые требуют различных времени исполнения или интерпретации, причём с различными пакетами зависимости, различными конфигурациями и так далее, не говоря уж о взаимозависимости между микрослужбами. Это самое время для того, чтобы Docker вписался в общую картину.

Давайте взглянем на эволюцию Docker. На протяжении длительного времени изоляция процесса была частью Linux в виде Control Groups (cgroups) и namespaces (пространств имён). При помощи настроек cgroups каждый процесс обладает ограниченными ресурсами (ЦПУ, памятью и тому подобным) для применения. Обладая выделенным пространством имён процесса, этот процесс внутри пространства имён не знает ничего о прочих запущенных в том же самом узле, но в иных пространствах имён процессах. Имея выделенное им пространство сетевых имён, процессы не способны взаимодействовать с иными процессами без надлежащей настройки сетевой среды, причём даже когда они запущены в одном и том же самом узле.

Docker упростил управление процессом для инженеров инфраструктуры и DevOps. В 2013 компания Docker выпустила свой проект Docker с открытым исходным кодом. Вместо управления пространствами имён и cgroup, через механизм Docker DevOps управляют контейнерами. Контейнеры Docker усиливают такой механизм изоляции в Linux запуска микрослужб и управления ими.

Всё же остаётся сложность взаимодействия. Тем, что предпринимает попытку решения этой задачи являются платформы оркестрации. Docker также предложила режим Docker Swarm (позднее переименованный в Enterprise Edition Docker, или EE Docker) для сопровождения построения кластера контейнеров, причём примерно в то же самое время, что и Kubernetes.

Согласно проведённому в 2019 Sysdig отчёту использования контейнеров (https://sysdig.com/blog/sysdig-2019-container-usage-report), производители безопасности и оркестрации контейнеров заявили, что Kubernetes забрал колоссальные 77% доли применяемой оркестрации. Если сюда включить OpenShift (разновидность Kubernetes от Red Hat), то доля рынка окажется близкой к 90%.

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

Кластер Kubernetes составляется из большого числа машин (либо виртуальных машин, ВМ) или узлов.Существуют два типа узлов: узлы хозяева (master) и узлы исполнители (worker). Самая основная панель управления, такая как kube-apiserver, запускается на узлах хозяев. Тот агент, который запускается на каждом узле исполнителя, носит название kubelet, работающий в качестве прислужников kube-apiserver и запускаемых на узлах исполнителей. Типичный рабочий поток Kubernetes запускается неким пользователем (например, DevOps), который взаимодействует с kube-apiserver в установленном узле хозяина, а kube-apiserver елегирует соответствующее задание развёртывания в свои узлы исполнителей. В своём следующем разделе мы дадим более подробное введение в kube-apiserver и kubelet.

Наша предыдущая схема показывает как пользователь отправляет запрос на развёртывание в свой узел хозяина (kube-apiserver), а kube-apiserver делегирует выполнение развёртывания в kubelet в некоторые из узлов исполнителей.

Kubernetes следует архитектуре клиент- сервер. В Kubernetes множество узлов хозяев контролирует множество узлов исполнителей. Каждый хозяин и исполнитель обладает набором компонентов, которые требуются для корректной работы всего кластера. Узел хозяина обычно обладает kube-apiserver, хранилищем etcd, kube-controller-manager, cloud-controller-manager и kube-scheduler. Узлы исполнителей имеют компоненты kube-scheduler, kube-proxy, Container Runtime Interface (CRI), Container Storage Interface (CSI) и тому подобные. Сейчас мы пройдём по ним более подробно:

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

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

 

Сетевой интерфейс контейнера

Kubernetes обладает установленным по умолчанию поставщиком сетевой среды, kubenet, который ограничен в возможностях. kubenet поддерживает лишь 50 узлов в кластере, что, очевидно, не способно соответствовать никаким требованиям развёртываний крупного масштаба. Между тем Kubernetes усиливается контейнерным сетевым интерфейсом (CNI, Kubernetes ) в качестве общего интерфейса между поставщиками сетевых ресурсов и сетевыми компонентами Kubernetes для поддержки сетевого взаимодействия в кластере крупного масштаба. В данный момент поддерживаемые поставщики включают в свой состав Calico, Flannel, kube-router и тому подобное.

 

Интерфейс хранилища контейнера

Kubernetes ввёл интерфейс хранилища своего контейнера в v1.13. Вплоть до 1.13 новые подключаемые модули тома являлись частью кода самого ядра Kubernetes. Такой интерфейс хранилища контейнера предоставляет некое взаимодействие для выставления в Kubernetes произвольных блочных и файловых хранилищ. При помощи подключаемых модулей CSI (container storage interface) поставщики облачных решений способны выставлять в Kubernetes современные файловые системы. Среди администраторов кластеров популярны такие подключаемые модули как MapR и Snapshot.

 

Интерфейс времени исполнения контейнера

На самом нижнем уровне Kubernetes, среда времени исполнения контейнера обеспечивает запуск, работу и останов. Наиболее популярной средой времени исполнения является Docker. Имеющийся интерфейс времени исполнения контейнера предоставляет администраторам кластеров применять и прочие среды времени исполнения, например, frakti, rktlet и cri-o.

Ресурсы хранения и вычислений рассматриваемой системы классифицируются по различным объектам, которые отражают текущее состояние данного кластера. Объекты определяются при помощи спецификаций .yaml, а для создания самих объектов и управления имии применяется API Kubernetes. Мы намерены более подробно рассмотреть некоторые распространённые объекты Kubernetes.

Под (pod, стручок) это основной строительный блок кластера Kubernetes. Это группа из одного или более контейнеров, которые, как ожидается, будут сосуществовать в неком отдельном хосте. Контейнеры внутри некого пода могут ссылаться друг на друга пр помощи localhost или IPC (inter-process communications).

Развёртывания (deployments) Kubernetes помогают масштабировать поды вверх и вниз на основе меток или селекторов. Соответствующая спецификация YAML для некого развёртывания состоит из replicas (реплик), которые являются тем числом экземпляров подов, которое необходимо, а template (шаблон) идентичен спецификации пода.

Служба (service) Kubernetes это некая абстракция какого- то приложения. Служба делает возможным сетевой доступ к подам. Службы и развёртывания работают в тесном сплетении для облегчения процессов управления и взаимодействия между различными подами некого приложения.

Набор реплик (replica set) обеспечивает запуск в некой системе заданного числа подов в каждый обределённый момент времени. Лучше применять развёртывания поверх наборов реплик. Развёртывания инкапсулируют наборы реплик и поды. Кроме того, развёртывания предоставляют определённую способность заботиться об раскрутке обновлений.

Хранилище контейнера эфемерно. Когда конкретный контейнер разрушается или выполняет перезагрузку, он запускается со своего первоначального состояния на старте. В решении этой задачи помогают тома (volumes) Kubernetes. Контейнер способен применять тома для сохранения некого состояния. Том Kubernetes имеет время жизни пода; как только под погибает, его том также вычищается. Некоторые поддерживаемые тома включают в свой состав awsElasticBlockStore, azureDisk, flocker, nfs и gitRepo.

Пространства имён (namespaces) способствуют подразделению некого физического кластера на множество виртуальных кластеров. Внутри различных пространств имён может изолироваться множество объектов. По умолчанию Kubernetes поставляется с тремя пространствами имён: default, kube-system и kube-public

Тем подам, которым требуется взаимодействовать с kube-apiserver, используют учётные записи служб (service accounts) для собственной идентификации. По умолчанию, Kubernetes предоставляет некий список устанавливаемых по умолчанию учётных записей служб: kube-proxy, kube-dns, node-controller и тому подобных. Для усиления контроля над доступом потребителей могут создаваться дополнительные учётные записи служб.

Политики сетевой среды (network policy) задают некий набор правил того, как какой-то группе подов допускается взаимодействовать друг с другом и прочими терминальными пунктами. Все входящие и исходящие сетевые соединения шлюзуются установленной сетевой политикой. По умолчанию, некий под имеет возможность взаимодействия со всеми подами.

Политики безопасности подов (pod security policy) это ресурс уровня кластера,который определяет некий набор условий, которые, в свою очередь, должны выполняться для запуска некого пода в заданной системе. Политики безопасности пода задают необходимую конфигурацию чувствительности к безопасности для некого пода. Эти политики должны быть доступны для запроса пользователя или учётной записи службы, чтобы выполнялся определённый целевой под.

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

Minikube это версия Kubernetes для кластера из одного узла, которая может запускаться в платформах Linux, macOS и Windows. Minikube поддерживает стандартные функциональные возможности Kubernetes, таки как LoadBalancer, службы, PersistentVolume, Ingress, среды времени исполнения контейнеров и дружественные разработчику свойства, такие как добавления и поддержка GPU.

Minikube это великолепная отправная точка для получения практических навыков с Kubernetes. Это также достойное место для локального запуска тестов, в особенности зависимости от кластера или работ по проверке концепций.

K3s это облегчённая платформа Kubernetes. Её общий размер менее 40 МБ. Она великолепно подходит для Edge, Internet of Tings (IoT), а также архитектур ARM, изначально Advanced RISC Machine, появившихся как Acorn RISC Machine, некого семейства reduced instruction set computing (RISC, архитектур со сниженным числом набора инструкций) для вычислительных процессоров, настраиваемых в разнообразных средах. Предполагается её полная совместимость с Kubernetes. Одним из существенных отличий от Kubernetes является то, что она применяет в качестве определяемого по умолчанию механизма хранения sqlite, в то время как Kubernetes пользуется в качестве сервера хранения по умолчанию etcd.

OpenShif версии 3 адаптирует в качестве технологии контейнероа Docker, а Kubernetes как технологию оркестрации контейнеров. В версии 4 OpenShift в качестве устанавливаемого механизма времени исполнения переключается на CRI-O. Можно полагать, что OpenShift должен быть тем же самым что и Kubernetes; тем не менее, имеется ряд отличий.

 

Сопоставление OpenShift и Kubernetes

Изначально могут показаться теми же самыми соединения между Linux и Red Hat Linux, как и между OpenShift и Kubernetes. Теперь, давайте рассмотрим некоторые из основных отличий.

 

Именование

Название объектов в Kubernetes может отличаться от имён в OpenShift, хотя порой их функциональность аналогична. К примеру, пространства имён из Keberenetes носят название проектов в OpenShift и создание проектов получается с объектами по умолчанию. Ingress из Kubernetes именуется маршрутами (routes) в OpenShift. В действительности, маршруты были введены раньше нежели объекты Ingress. В своей основе маршруты OpenShift реализуются через HAProxy, в то время как в Kubernetes имеется множество вариантов контроллеров ingress. Развёртывание в Kubernetes носит название deploymentConfig. Однако, собственно лежащая в основе реализация достаточно отличается.

 

Безопасность

Kubernetes по умолчанию открыт и менее безопасен. OpenShift относительно закрыт т предлагает пригоршню хороших механизмов безопасности для обеспечения ими кластера. Например, при создании кластера OpenShift, DevOps может включить соответствующий внутренний реестр образов, который не выставляется вовне. В то же самое время, такой внутренний реестр образов обслуживается как доверенный реестр, из которого будут вытаскиваться и развёртываться необходимые образы. Имеется ещё один момент, который проект OpenShift выполняет лучше нежели пространства имён kubernetes - при создании некого проекта в OpenShift вы способны изменять устанавливаемый шаблон проекта и добавлять дополнительные объекты, например, такие как NetworkPolicy в качестве квот по умолчанию в данные проект для совместимости с политиками вашей компании. Это также способствует по умолчанию упрочнению.

 

Стоимость

OpenShif это предлагаемый Red Hat продукт, хотя и имеется некая версия сообщества проекта с названием OpenShif Origin. Когда люди обсуждают OpenShif, они обычно подразумевают тот вариант, который предполагает платный вариант продукта OpenShif с поддержкой от Red Hat. Kubernetes является полностью бесплатным проектом с открытым исходным кодом.

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

Упаковка в контейнеры превращает приложения в более переносимые, а потому замыкание на конкретного поставщика облачных решений становится маловероятным. Хотя и имеется ряд великолепных инструментов с открытым исходным кодом, таких как kubeadm и kops, которые способны содействовать DevOps в создании кластеров Kubernetes, Kubernetes в качестве службы предлагаемый поставщиками облачных ришений всё ещё звучит притягательно. В качестве первоначального создателя Kubernetes, Google предлагает Kubernetes в качестве службы начиная с 2014 года. Она носит название Google Kubernetes Engine (GKE). В 2017 Microsoft предложила свою собственную службу Kubernetes, именуемую Azure Kubernetes Service (AKS). AWS предложил в 2018 Elastic Kubernetes Service (EKS).

Kubedex позаботился о великом сопоставлении представленных служб Kubernetes. Некоторые отличия между этими тремя перечислены в приводимой ниже таблице:

Таблица 1-1. Сопоставление облачных решений Kubernetes

Параметры	Google GKE	Amazon EKS	Microsoft ФЛЫ
Год запуска (GA)	2014	2018	2017
Версии Kubernetes GA	1.14/ 1.15	1.14	1.13 и 1.14
Год запуска	2014	2018	2017
Поддерживаемые регионы	По всему миру	Северная америка, Ирландия, Лондон, Франкфурт, Сингапур, Сидней, Токио, Сеул и Париж	Почти по всему миру
Время создания кластера	3 минуты	20 минут	15 минут
Стоимость	бесплатно	20 центов за час для хозяина	бесплатно
Kubernetes Marketplace	Да	Нет	Нет
Интеграция	Экосистема GCP	Экосистема AWS	Экосистема Azure
Управление узлами исполнителей	Да	Нет	Да
Шифрование секрета прикладного уровня	Да	Нет	Нет
Поддержка сетевой политики	Да (Calico)	Да (Calico)	Да (kube-router и Calico)
Интеграция мониторинга	Да (Stackdriver)	Да (Container Insights)	Да
Поддерхка Sandbox (например, gVisor)?	Да (бета)	Нет	Нет
Поддержка бинарной авторизации	Да (бета)	Нет	Нет
Управление SSL сертификатами Ingress	Да	Нет	Нет
Высвобождение каналов	Да (стабильное, регулярное и быстрое)	Нет	Нет
Совместимость	PCI DSS, ISO, SOC, HIPAA	HIPAA, PCI DSS, ISO	PCI DSS, ISO, SOC, HIPAA
Максимальное число узлов в кластере	5000	500+	100
Балансировка нагрузки по регионам	Да	Нет	Нет

Вот некоторые основные моменты, которые следует выделить в предыдущем перечне:

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

Если вы хотите иметь некий кластер Kubernetes с доступом ко всем узлам кластера, вам может помочь инструментарий с открытым исходным кодом - kops.

Kubernetes Operations (kops) способствует созданию, удалению, обновлению и сопровождению решения промышленного уровня из командной строки, причём для кластеров с высокой доступностью. Он официально поддерживается AWS и в бета версии поддерживает GCE и OpenStack. Основное отличие от предоставления кластера Kubernetes в некой облачной службе Kubernetes заключается в том, что такая поддержка начинается с уровня имеющихся ВМ. Это означает, что при помощи kops вы можете контролировать какой образ ОС вы желаете применять и настраивать свой собственный ключ SSH администратора для доступа как к узлам хозяев, так и к узлам исполнителей. Вот некий пример создания кластера Kubernetes s AWS:

  # Create a cluster in AWS that has HA masters. This cluster
  # will be setup with an internal networking in a private VPC.
  # A bastion instance will be setup to provide instance access.
  export NODE_SIZE=${NODE_SIZE:-m4.large}
  export MASTER_SIZE=${MASTER_SIZE:-m4.large}
  export ZONES=${ZONES:-'us-east-1d,us-east-1b,us-east-1c'}
  export KOPS_STATE_STORE='s3://my-state-store'
  kops create cluster k8s-clusters.example.com \
  --node-count 3 \
  --zones $ZONES \
  --node-size $NODE_SIZE \
  --master-size $MASTER_SIZE \
  --master-zones $ZONES \
  --networking weave \
  --topology private \
  --bastion='true' \
  --yes
 	   

С помощью предыдущей команды kops создаётся кластер Kubernetes из трёх узлов исполнителей. Его пользовтель имеет возможность выбора значения размера узла хозяина и предпочтительный подключаемый модуль CNI.

Kubernetes в целом был доступен в 2018 и всё ещё быстро эволюционирует. Существуют функциональные возможности, которые всё ещё пребывают в разработке и не пребывают в состоянии GA (general availability, вместо этого либо альфа, либо бета). Это некий указатель на то, что Kubrenetes сам по себе ещё пока далёк от зрелости, по крайней мере с точки зрения безопасности. Однако это не основная причина, по которой стоит сосредоточиться на безопасности Kubernetes.

Брюс Шнейер суммировал это в 1999,когда сказал "Сложность это наихудший враг безопасности" в эссе, озаглавленном Иск в отношении безопасности, верно предсказав те проблемы кибербезопасности, с которыми мы столкнулись в наши дни. Чтобы решить все основные требования оркестрации стабильности, масштабируемости, гибкости и безопасности, Kubernetes был разработан сложным, но связанным способом. Несомненно, такая сложность привносит некие вопросы безопасности.

Способность к конфигурированию является одним из наивысших преимуществ таких платформ Kubernetes для разработчиков. Разработчики и поставщики облачных решений вольны в настройке своих кластеров для подгонки под их потребности. Эта характерная черта Kubernetes выступает одной из основных причин для возрастания подлежащих рассмотрению вопросов безопасности для корпораций. Всё ещё растущие код Kubernetes и число компонентов кластера Kubernetes превращают его в вызов для DevOps в вопросе осознания верного конфигурирования. Устанавливаемые по умолчанию конфигурации обычно не обладают безопасностью (открытость не привносит преимуществ DevOps в апробации новых функциональных возможностей).

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

Недавнее анкетирование The New Stack отражает, что безопасность становится первейшим подлежащим рассмотрению вопросом запуска корпоративного Kubernetes:

По умолчанию Kubernetes не обладает безопfсностью. Мы будем пояснять это в наших последующих главах. Совершенно логично, безопасноcть превращается в первейшую заботу пользователей. Эта та проблема, которую требуется решать должным образом, как и в случае с прочими инфраструктурами и платформами.

Основная тенденция микрослужб и появление Docker позволили Kubernetes де факто стать основной платформой DevOps для развёртывания, масштабирования и управления заключёнными в контейнеры приложениями. Kubernetes абстрагирует ресурсы хранения и вычисления как объекты Kubernetes, которые управляются такими компонентами как kube-apiserver, kubelet, etcd и тому подобными.

может создаваться в неком частном центре обработки данных или в облачном решении, либо быть гибридным. Это позволяет DevOps работать со множеством поставщиков облачных решений и не замыкаться на одном из них. Хотя Kubernetes и пребывает в GA (общей доступности) c 2018, он всё ещё очень юн и очень быстро эволюционирует. По мере того как Kubernetes привлекает всё больше и больше внимания, более заметным становится и целевая направленность злоумышленников в отношении Kubernetes.

В своей следующей главе мы намерены рассмотреть модель сетевых сред Kubernetes и разобраться как же микрослужбы взаимодействуют в Kubernetes друг с другом.

Приводимые ниже ссылки содержат более подробные сведения относительно Kubernetes, kops

и платформе OpenShift. Вы найдёте их полезными когда приступите к сборке кластера Kubernetes: