Знали ли вы, что в Kubernetes изначально не было встроенных функций для управления пользовательскими правами, а поддержка хранения данных на постоянной основе появилась только спустя четыре года после его создания?
Если нет, то вам, возможно, будет интересно погрузиться в историю Kubernetes в честь десятилетия этой open-source системы оркестрации контейнеров. В этой статье освещаются важные события в истории платформы, объясняется, как Kubernetes стал таким популярным, и даётся взгляд на то, что может ожидать Kubernetes в будущем.
Предыстория Kubernetes: Google Borg и Docker
Прежде чем углубляться в историю Kubernetes с момента его официального представления в 2014 году, давайте поговорим о том, что можно назвать предысторией Kubernetes. В частности, рассмотрим две ключевые платформы или технологии, которые сыграли важную роль в подготовке почвы для появления Kubernetes.
Borg, предшественник Kubernetes
Google объявила о Kubernetes как об open-source проекте 6 июня 2014 года — эта дата считается днем рождения Kubernetes. Однако, если посмотреть шире, история Kubernetes началась гораздо раньше, так как его концептуальные корни восходят к платформе под названием Borg.
Borg был кластерным менеджером, который Google использовала для оркестрации рабочих нагрузок на огромном количестве серверов. Google не раскрывала публично многие технические детали работы Borg, и, похоже, что на данный момент Kubernetes не использует его код. Но, согласно сообщению в блоге на сайте Kubernetes, опубликованному в 2015 году, многие основные концепции Kubernetes, такие как Pods, Services и Labels, возникли именно с Borg.
Таким образом, именно инженерам Google мы обязаны такими характерными идеями Kubernetes, как организация рабочих нагрузок в Pods и предоставление сетевых приложений в виде Services.
Появление Docker
История Kubernetes была бы неполной без упоминания Docker. Docker не является частью Kubernetes или его прямым предшественником, однако, как платформа, которая помогла вывести технологию контейнеров на массовый рынок, Docker сыграл важную роль в создании потребности в технологиях оркестрации контейнеров, которые Kubernetes был призван решить.
Контейнеры имеют долгую историю, уходящую корнями в 1970-е годы, и до появления Docker в 2013 году существовали другие фреймворки и технологии контейнеризации. Однако именно Docker сделал работу с контейнерами очень простой, способствуя популяризации идеи упаковки и развёртывания приложений внутри контейнеров.
С ростом числа пользователей, которые начали использовать Docker для разработки и запуска приложений в контейнерах, стало очевидно, что необходим способ эффективной оркестрации этих контейнеров. Это привело к появлению Kubernetes и множества других инструментов оркестрации контейнеров — включая оркестратор от Docker под названием Swarm, который появился только после запуска Kubernetes и, следовательно, не был доступен на ранних этапах для решения потребностей в оркестрации у пользователей Docker.
Зарождение Kubernetes
Теперь, когда мы рассмотрели исторический контекст, из которого появился Kubernetes, давайте поговорим о дебюте самого Kubernetes.
Первый релиз Kubernetes
Хотя о Kubernetes было объявлено в июне 2014 года, на выпуск первой стабильной версии проекта потребовалось более года. Kubernetes 1.0 вышел 21 июля 2015 года, когда разработчики Kubernetes посчитали платформу достаточно стабильной для использования в реальных условиях.
На тот момент Kubernetes поддерживал все основные функции, которые до сих пор знакомы администраторам Kubernetes. Можно было развертывать наборы контейнеров как Pods, распределять их по узлам и открывать доступ к приложениям через сеть в виде Services. Кроме того, всем этим можно было управлять с помощью kubectl, который до сих пор является основным инструментом командной строки во многих дистрибутивах Kubernetes.
Трудный релиз
Однако Kubernetes образца 2015 года был довольно сырым, мягко говоря. Часть проблемы заключалась в том, что многие концепции, лежащие в основе Kubernetes, оставались новыми для многих инженеров. Например, идея не знать (или даже не беспокоиться) о том, какой сервер размещает конкретное приложение, или представление об инфраструктуре как о «скоте», а не как о «домашних питомцах», были все еще новыми для большинства людей, привыкших разворачивать приложения напрямую на тщательно управляемых серверах. Таким образом, освоение Kubernetes требовало определенных навыков и знаний.
Недостаток обширной документации по Kubernetes, интеграций и дополнений также затруднял использование платформы на начальном этапе. Сегодня база документации Kubernetes, пожалуй, является одним из самых полных и хорошо написанных ресурсов документации в мире, и существует множество расширений и интеграций, которые дополняют основные возможности Kubernetes. Но в июле 2015 года был только Kubernetes 1.0.
Взлёт Kubernetes: конец 2010-х годов
С середины до конца 2010-х годов Kubernetes значительно развился и в итоге стал самым популярным оркестратором контейнеров. Однако в июле 2015 года ещё было не так очевидно, что это произойдёт.
Давайте рассмотрим некоторые факторы, которые объясняют, как Kubernetes так быстро созрел в свои первые, решающие годы существования.
Kubernetes и Cloud Native Computing Foundation (CNCF)
Одним из ключевых факторов успеха Kubernetes стала поддержка влиятельных компаний и организаций.
В тот же день, когда вышла версия Kubernetes 1.0, Google и Linux Foundation (некоммерческая организация, поддерживающая разработку ядра Linux и других крупных open-source технологий) объявили о создании Cloud Native Computing Foundation (CNCF). CNCF, организация под руководством Linux Foundation, была создана для продвижения нового поколения облачно-ориентированных open source платформ. Kubernetes стал первым проектом CNCF.
Связь между CNCF и Kubernetes не имеет особого значения с технической точки зрения, но она важна для понимания того, как Kubernetes быстро набрал популярность. Входящие в состав CNCF крупные компании, такие как Red Hat, VMware и IBM, помогли придать Kubernetes определённую легитимность с самого начала. Кроме того, CNCF способствовала развитию сообщества Kubernetes, организуя мероприятия KubeCon, на которые регулярно собирались тысячи разработчиков и пользователей Kubernetes, начиная с 2015 года.
Без поддержки CNCF и связи с Google, Kubernetes мог бы восприниматься многими как ещё один случайный open-source проект или как очередная платформа оркестрации, назначение которой было бы неясным, учитывая, что уже существовали альтернативные инструменты оркестрации, такие как Apache Mesos. (Docker Swarm появился осенью 2015 года, через несколько месяцев после выхода Kubernetes 1.0, поэтому Swarm не был доступен на момент дебюта Kubernetes.)
Войны оркестраторов: 2016-2017 годы
Период «войн оркестраторов» в 2016-2017 годах стал переломным моментом в развитии оркестрации контейнеров. В это время организации, стремившиеся масштабировать свои процессы и приложения, имели несколько вариантов для рассмотрения. Apache Mesos, еще один open-source проект, был популярен среди тех, кто нуждался в мощной масштабируемости, однако изначально он не был специально разработан для контейнеров. Kubernetes все еще находился на начальной стадии развития, тогда как Docker активно продвигал Docker Swarm как способ монетизации своей платформы.
Однако к концу 2017 и началу 2018 годов стало все более очевидно, что Kubernetes станет доминирующей силой в этой области. Этот сдвиг был обусловлен мощной поддержкой со стороны CNCF и крупных игроков отрасли, таких как Microsoft, AWS, VMware, Red Hat и Dell. Их поддержка сигнализировала о том, что Kubernetes (независимо от того, был ли он наилучшим решением или нет) станет де-факто отраслевым стандартом, подобно тому, как формат VHS победил в «войнах форматов видеокассет» в 1980-х годах. Этот консенсус укрепил позицию Kubernetes как ведущей платформы оркестрации контейнеров, определяя будущее облачно-ориентированных приложений.
Новые функции и возможности Kubernetes
Ещё одним важным фактором, объясняющим стремительный взлёт Kubernetes, стало появление в платформе важных новых функций.
Как упоминалось ранее, на начальном этапе Kubernetes был довольно простым. Он мог оркестрировать рабочие нагрузки на серверах, но на этом его возможности практически заканчивались. В Kubernetes отсутствовала развитая поддержка постоянного хранения данных, его сетевые возможности были ограничены, и в нём было мало встроенных средств безопасности.
Однако ситуация быстро изменилась, и в Kubernetes появились важные функции, такие как:
- Нативная модель управления доступом на основе ролей (RBAC), которая стала доступна в Kubernetes 1.8 в 2017 году. Функции RBAC позволяют управлять доступом пользователей и определять, кто и что может делать в Kubernetes, что значительно снижает многие риски, связанные с несанкционированным доступом.
- Расширенные сетевые возможности, такие как поддержка балансировки нагрузки внутри кластера и CoreDNS, которые появились в выпуске Kubernetes 1.11 в 2018 году. Эти функции сделали сетевое взаимодействие более гибким и мощным.
- Поддержка постоянных томов (persistent volumes), что облегчает постоянное хранение данных в Kubernetes и, соответственно, позволяет запускать состояния (stateful) рабочие нагрузки. Постоянные тома стали доступны с выпуском Kubernetes 1.14 в 2019 году.
Такие возможности помогли устранить недостатки ранних версий Kubernetes и сделали платформу жизнеспособным выбором для поддержки широкого спектра рабочих нагрузок в продуктовой среде.
Технологические гиганты обращают внимание
В то время как Kubernetes получал важные новые функции, он также начал привлекать внимание облачных провайдеров, которые активно создавали свои облачные сервисы на основе Kubernetes.
В 2017 году Microsoft выпустила Azure Kubernetes Service (AKS), управляемый Kubernetes-сервис в облаке Azure. Это было примечательно, потому что Microsoft изначально установила тесные отношения с Docker и, по сообщениям, даже пыталась купить эту компанию в середине 2010-х годов. Запуск AKS сигнализировал о том, что Microsoft видела будущее оркестрации контейнеров за Kubernetes, а не за Docker Swarm или другими инструментами Docker.
Аналогичным образом, в 2018 году Amazon представила Elastic Kubernetes Service (EKS), управляемый Kubernetes-сервис в облаке Amazon Web Services (AWS). Это также было значимым шагом, учитывая, что ранее Amazon создала собственный сервис оркестрации контейнеров Elastic Container Service (ECS). Компания не отказалась от ECS (который она поддерживает и сегодня), но решение Amazon создать платформу управления контейнерами на базе Kubernetes также отражало значимость, которую Kubernetes приобрел за несколько коротких лет с момента своего первоначального выпуска.
Не только облачные провайдеры сделали важные ранние ставки на Kubernetes. Red Hat также выразила уверенность в будущем этой платформы, начиная с 2015 года, когда внедрила Kubernetes в качестве основы для OpenShift, флагманской платформы Red Hat для разработки и развертывания приложений. Ранее OpenShift работал на основе собственных технологий. Последующее приобретение Red Hat компанией IBM в 2019 году добавило еще больше импульса OpenShift, так как это укрепило связь между Kubernetes и еще одним крупным технологическим брендом.
Схожая эволюция произошла с Rancher. Изначально Rancher была известна своей облегченой дистрибуцией Linux — RancherOS, и своим собственным оркестратором контейнеров. Однако около 2018 года Rancher сделала стратегический поворот, стандартизировав свои решения на Kubernetes, интегрировав его в ядро своей платформы. Это решение позволило Rancher использовать растущую популярность и экосистему Kubernetes.
Кроме того, Rancher разработала K3s, облегченную дистрибуцию Kubernetes, предназначенную для сред с ограниченными ресурсами, таких как пограничные устройства и IoT-приложения. K3s с тех пор стала популярным выбором для этих специализированных случаев использования, сохраняя приверженность Rancher к упрощению оркестрации контейнеров и адаптации к отраслевым тенденциям.
VMware также создала собственную дистрибуцию Kubernetes (TKG) и в 2018 году приобрела компанию Heptio, чтобы усилить свою платформу. Heptio была фирмой, предоставляющей услуги по Kubernetes, и была основана двумя из первоначальных создателей Kubernetes (в Google), что добавило дополнительную легитимность и техническую экспертизу в экосистему VMware.
Kubernetes после 2020 года
К 2020 году, а возможно и чуть раньше, стало очевидно, что Kubernetes одержал победу в так называемых «войнах оркестраторов контейнеров» — конкуренции между Kubernetes и другими оркестраторами, такими как Docker Swarm и Mesos, за статус де-факто платформы для управления контейнеризированными приложениями на кластерах серверов.
Данные за 2022 год показали, что к тому времени около 60% организаций, использующих контейнеры, оркестрировали их с помощью Kubernetes. С тех пор скорость внедрения Kubernetes только увеличивается.
В то же время, хотя Kubernetes продолжает приобретать новые функции, изменения уже не столь значительны, как в 2010-х годах, когда платформа развивалась скачкообразно. Большинство улучшений с 2020 года — это усовершенствования или улучшенные версии существующих функций.
Кроме того, последняя крупная версия Kubernetes, 1.30, хотя и не включает революционных новых функций, предлагает несколько возможностей, которые при правильном использовании могут помочь администраторам создавать и поддерживать более безопасные кластеры. Среди этих функций:
- Поддержка Common Expression Language (CEL) для управления доступом, что позволяет более детально регулировать запросы доступа напрямую через API Kubernetes.
- Бета-поддержка пространств имен пользователей на основе Linux в Pods, что может помочь ограничить риски безопасности.
Подобные изменения сами по себе не являются значительными, но они вводят полезные новые возможности, которые, будучи использованы вместе, открывают мощные возможности для улучшения безопасности Kubernetes. Однако многообразие дистрибутивов и установщиков Kubernetes усложняет рынок и создаёт потенциальные пробелы в безопасности. Эта фрагментация может привести к несоответствиям и уязвимостям, которые могут быть использованы злоумышленниками. Поэтому важно продолжать следить за развитием Kubernetes, как делает это Aqua Security, которая постоянно ищет способы улучшить свои решения по безопасности Kubernetes.
Что ждёт Kubernetes в будущем?
Когда Kubernetes вступает во второе десятилетие своего существования, становится очевидным, что эта платформа оркестрации никуда не исчезнет. Наоборот, Kubernetes настолько глубоко внедрился в облачные вычисления, что представить жизнь без него уже сложно. Если только не появится какая-то радикально новая технология, которая сделает Kubernetes устаревшим.
Тем не менее, у Kubernetes есть много возможностей для роста и улучшений, сохраняя баланс между богатством возможностей и простотой эксплуатации. Например, поддержка полноценных мультиоблачных кластеров могла бы значительно повысить ценность Kubernetes. Это означает возможность управлять единым кластером Kubernetes, узлы которого распределены по разным облакам или дата-центрам. Хотя это и возможно сделать сейчас, выполнять такие задачи хорошо — трудно, потому что Kubernetes изначально не был спроектирован для подобных сценариев использования.
Также была бы полезна большая согласованность между разными дистрибутивами Kubernetes. Множество различных дистрибутивов, включая некоторые с проприетарными расширениями или функциями, работающими только в рамках конкретной экосистемы, усложняют миграцию с одного дистрибутива на другой в некоторых случаях. Впрочем, такая фрагментация обычно происходит с любыми крупными платформами с открытым исходным кодом (например, множество дистрибутивов Linux), поэтому, возможно, сообщество мало что может с этим сделать.
Кроме того, в будущем будет уделяться больше внимания безопасности Kubernetes. Несмотря на наличие важных встроенных функций безопасности, таких как поддержка RBAC, более детализированные средства управления безопасностью будут приветствоваться администраторами Kubernetes, стремящимися быть на шаг впереди угроз безопасности.
Компания Aqua Security, основанная в 2015 году, была одной из первых платформ, сосредоточивших внимание на защите Kubernetes, контейнеров и других облачных технологий. С 2017 года она разрабатывает решения для обеспечения безопасности Kubernetes, внедряя концепции управления безопасностью Kubernetes (Kubernetes Security Posture Management — KSPM), предлагая комплексные политики и функции для автоматизации безопасной конфигурации и соблюдения стандартов, а также обширные средства защиты Kubernetes-приложений в режиме реального времени. Именно это новаторство позволяет Aqua смотреть в будущее и продолжать обеспечивать безопасность рабочих нагрузок Kubernetes в следующем десятилетии и далее.
Источник: https://www.aquasec.com/blog/kubernetes-history-how-it-conquered-cloud-native-orchestration/