Использование платформы виртуализации Kubernetes непрерывно растёт. Согласно отчету Cloud Native Computing Foundation (CNCF) более 90% организаций, опрошенных этой организацией, использовали Kubernetes в 2020 году, причем рост к 2019 году составил 30%.

Kubernetes – это перемещаемая и расширяемая платформа на базе открытого ПО (open source), для управления контейнеризованными данными и приложениями, которые обеспечивают конфигурацию по декларативным указаниям, а также автоматизацию управления вычислительными системами. Это большая и постоянно растущая экосистема, сервисы, поддержка и средства которой широко доступны.

Kubernetes на греческом означает «рулевой». Сокращённое название – K8s, где цифра 8 означает количество букв между «K» и «s». Google представил открытый код проекта Kubernetes в 2014 году, который явился результатом 15-летнего опыта работы с различными нагрузками в дата-центрах Google.

Развитие проекта шло следующим образом.

Эра традиционных дата-центров (Traditional deployment): приложения запускались на базе физических серверов. Для приложений (App) невозможно было обозначить границы вычислительных ресурсов, которые каждое из них могло использовать. Если на одном физическом сервере запущено много приложений, то иногда одно приложение могло забирать себе большую часть ресурсов, что виляло на производительность остальных приложений. Конечно, можно запускать приложение по одному на каждом сервере. Но тогда ресурсы физического сервера будет недоиспользованы, что приводит к большим затратам организаций, в ведении которых находились физические серверы.

Эра виртуализованных сред дата-центров (Virtualized deployment): для решения этой проблемы было решено прибегнуть к виртуализации физических ресурсов (серверов и систем хранения) дата-центров. При этом стало возможным запускать несколько виртуальных машин, ВМ (Virtual Machines, VM) на одном процессоре физического сервера. Это дало возможность изолировать приложения в виртуальных машинах и обеспечить безопасность их работы, поскольку одно приложение не может свободно получать доступ к другому приложению.

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

Каждую ВМ можно представить как полноценный компьютер, включая его собственную операционную систему (Guest Operating System), которая работает поверх виртуализованного оборудования (Hardware) и операционной системы физического сервера (Host Operating System). Это делается при помощи специальной программы гипервизора (Hypervisor), которая работает поверх операционной системы физического сервера.

Эра контейнеров (Container deployment). Контейнеры похожи на виртуальные машины, однако, они имеют не такие строгие правила логической изоляции, как ВМ, и позволяют использовать ресурсы операционной системы для многих приложений. Контейнеры по объёму гораздо меньше виртуальных машин. Как и ВМ, контейнеры имеют свою собственную файловую систему (filesystem), они точно также, как и ВМ, совместно пользуются ресурсами процессора, памяти, пространства процесса (process space) и других. Поскольку они отделены от нижележащей инфраструктуры, то могут свободно перемещаться между облачными средами и копиями операционных систем физических серверов (Host Operating System).

Растущая популярность контейнеров обусловлена следующим факторами:

• Быстрое и эффективное создание приложений и их развёртывание (deployment), лучшее, чем у виртуальных машин.
• Непрерывный процесс разработки, интеграции и развёртывания: контейнерные среды обеспечивают надёжное и частое создание образов (image) контейнеров, а также их развёртывание с возможностью быстрого отката при необходимости, благодаря стабильности образов.
• Разделение обязанностей разработчиков и операционистов (Dev and Ops separation of concerns): создание образов контейнеров приложения во время строительства и выпуска (build/release time), а не во время развёртывания, что позволяет отделить приложения от нижележащей инфраструктуры.
• Наблюдаемость: контейнеры выводят не только информацию уровня ОС, но также состояния приложений (application health), и другие сигналы.
• Идентичность сред исполнения (runtime) при развёртывании, тестировании и продуктивном использовании: всё одинаково работает как на ноутбуке, так и в облаке.
• Хорошая переносимость, как между разными операционными системами, и между облачными средами: Ubuntu, RHEL, CoreOS, в большинстве публичных облаков и пр. 
• Управление, ориентированное на приложения: повышение уровня абстрагирования, что позволяет контейнеризованным приложениям работать как в среде операционных систем при виртуализации физического оборудования, так и в ОС с использованием логических ресурсов.
• Создание микросервисов, слабо зависящих друг от друга, распределённых и эластичных. При этом возможна разбивка приложения на несколько небольших независимых частей, которые могут развёртываться и управляться независимо – а не в виде монолитной неразборной конструкции, что было в случае виртуальных машин.
• Изоляция ресурсов обеспечивает предсказуемую производительность приложения.
• Использование ресурсов более эффективное и плотное, чем для виртуальных машин.

Почему нужны контейнеры Kubernetes и что они могут делать

Контейнеры – это хорошее средство для составления законченных наборов приложений и их запуска. При реальном использовании (production) необходимо управлять контейнерами, в которых работают приложения и обеспечивать отсутствие их простоев. Например, если контейнер отказывает, то вместо него нужно быстро запускать другой контейнер.

Именно в таких ситуациях Kubernetes приходит на помощь. Kubernetes обеспечивает фреймворк для резервирования распределённых систем и берет на себя задачу масштабирования и защитного переключения (failover), запущенного пользователем приложения. Он также предоставляет шаблоны развёртывания (deployment patterns) и многое другое. Например, Kubernetes может легко обеспечить т.н. «канареечное развёртывание» (canary deployment) для системы пользователя.

(«Канареечное развёртывание», canary deployment – термин, происходящий из угольной промышленности. Шахтёры раньше часто брали с собой в шахту канарейку в клетке, и, если концентрация вредных газов в глубокой шахте не превышала опасную величину, то канарейка оставалась живой и работа в шахте безопасна и для людей. Если канарейка умирала – это сигнал срочно покидать шахту, т.к. концентрация газов может быть опасной для людей. Точно также и в случае контейнеров – если пробное развёртывание на каком-то небольшом сегменте системы («канарейке») показывало себя хорошо, то нововведение можно безопасно масштабировать на всю систему).

Kubernetes обеспечивает следующее:

• Обнаружение сервисов (Service discovery) и балансировка нагрузки (load balancing). Kubernetes может экспонировать контейнеров при помощи доменного имени (DNS name) или использованием собственного IP-адреса. Если трафик к данному контейнеру высокий, то Kubernetes может производить балансировку нагрузки и распределять сетевой трафик таким образом, что данное развёртывание (deployment) будет стабильным.
• Оркестрация систем хранения (Storage orchestration). Kubernetes позволяет автоматическое монтирование системы хранения по выбору пользователя, например, локального хранилища, хранилища в публичном облаке, и других.
• Автоматический «накат» (rollout) и откат (rollback) контейнеров. Пользователь может описать желаемое состояние для развёртываемых контейнеров с использованием Kubernetes и изменять их реальное состояние на желаемое состояние в контролируемом темпе. Например, при помощи Kubernetes можно автоматизировать создание, новых контейнеров для данной среды (deployment), удалять существующие контейнеры и использовать их ресурсы для новых контейнеров.  
• Автоматическая упаковка бинарных файлов (bin[ary] packing). Пользователь может предоставить для Kubernetes кластер узлов, который можно будет использовать для контейнеризованных задач. Kubernetes может вмещать контейнеры в эти узлы для лучшего задействования ресурсов.
• Самовосстановление (Self—healing). Kubernetes перезапускает отказывавшие контейнеры, заменяет контейнеры, прекращает работу контейнеров, которые не отвечают на запросы проверку состояния работы приложения (health check) и не показывает их клиентским программам до их готовности к использованию.
• Управление конфиденциальностью и конфигурацией (Secret and configuration management). Kubernetes позволяет хранить и управлять чувствительной информацией, такой как пароли, токены OAuth и ключи SSH. Пользователь может развёртывать и модифицировать конфиденциальную информацию (secrets) и конфигурацию приложений без перестроения образа контейнера и без показа «секретов» для конфигурации системы.

Чем не являются Kubernetes

Kubernetes не является традиционной платформой разработки PaaS (Platform as a Service), которая содержит всё необходимое для процесса разработки. Поскольку Kubernetes работает на уровне контейнерной виртуализации, а не на уровне оборудования, он предоставляет некоторые общеприменимые функции, обычные для PaaS, такие как развёртывание (deployment), масштабирование (scaling), балансировку нагрузки (load balancing) и позволяет пользователям интегрировать их решения по логированию (logging), мониторингу (monitoring) и выдаче предупреждающих сообщений (alerting).

Однако, Kubernetes не является «монолитной» системой, и все эти решения являются опциональными и подключаемыми (pluggable). Kubernetes предоставляет «строительные блоки» для построения платформ разработки, но сохраняет выбор пользователя и гибкость там, где это важно.

• Kubernetes не ограничивает типы поддерживаемых приложений и поддерживает большое разнообразие нагрузок, включая нагрузки с сохранением состояния (stateful), без сохранения состояния (stateless) и нагрузки с обработкой данных (о stateful и stateless см. здесь). Если приложение может работать в контейнере, то оно прекрасно работает в Kubernetes.
• Kubernetes не развёртывает исходный код (source code) и не создаёт нужное приложение. Рабочие процессы CI/CD (Continuous Integration, Delivery, and Deployment) определяются культурой и предпочтениями организации, также техническими требованиями.
• Kubernetes не предоставляет сервисы уровня приложения, таких как middleware (например, шины сообщений, message buses), фреймворк обработки данных (например, Spark), баз данных (например, MySQL), кеширования данных, а также кластерных систем хранения (например Ceph), в виде встроенных сервисов. Такие компоненты работают в Kubernetes и к ним могут получать доступ приложения, работающие на Kubernetes через средства портирования (portable mechanisms), такие как Open Service Broker.
• Kubernetes не предписывает использовать какие-то решения логирования, мониторинга или выдачи предупреждающих сообщений (logging, monitoring, alerting). Он предоставляет некоторые интеграции как экспериментальные (proof of concept), а также средства для сбора и экспорта метрик.
• Kubernetes не предоставляет и не определяет конфигурацию языка системы (например, Jsonnet). Он предоставляет декларативный API, который может быть указан в разных формах декларативных спецификаций.
• Kubernetes не предоставляет и не принимает соответствующих конфигураций систем оборудования, обслуживания, управления или самовосстанавливающихся систем (self-healing systems).
• Кроме того, Kubernetes – не просто система оркестрации. Напротив, Kubernetes устраняет необходимость традиционной оркестрации. Технический смысл оркестрации состоит в выполнении определённого процесса (defined workflow): сначала сделать А, потом В, и после этого С. Напротив, Kubernetes состоит из набора независимых, составляемых процессов управления, которые непрерывно направляют текущее состояние в направлении желаемого состояния. При этом то, как осуществляется переход от А к С – неважно. Централизованного управления при этом также не требуется. В результате, мы получаем систему, которую легче использовать, которая более мощная, производительная, устойчивая и расширяемая.

Продолжение — Kubernetes (2)