Войти
 | |
| Автор (ы) | |
|---|---|
| Разработчик | Cloud Native Computing Foundation |
| Первоначальный выпуск | 7 июня 2014 г.; 6 лет назад (07.06.2014) |
| Стабильный выпуск | 1.19.1 / 9 сентября 2020 г.; 46 дней назад (09.09.2020) |
| Репозиторий |  |
| Написано на | Go |
| Тип | Программное обеспечение для управления кластером |
| Лицензия | Apache License 2.0 |
| Веб-сайт | kubernetes.io |
Kubernetes (обычно стилизованный как k8s ) является открытым исходным кодом контейнер - система оркестрации для автоматизации развертывания, масштабирования и управления компьютерных приложений.
Первоначально она была разработана Google и сейчас поддерживается Cloud Native Computing Foundation. Его цель - предоставить «платформу для автоматизации развертывания, масштабирования и операций контейнеров приложений в кластерах хостов». Он работает с рядом контейнерных инструментов, включая Docker.
. Многие облачные сервисы предлагают платформу или инфраструктуру на основе Kubernetes как услугу (PaaS или IaaS ), на котором Kubernetes может быть развернут как сервис, предоставляющий платформу. Многие поставщики также предоставляют собственные фирменные дистрибутивы Kubernetes.
Обсуждение Google Kubernetes Engine на Google Cloud Summit Kubernetes (κυβερνήτης, по-гречески «рулевой » или «пилот» "или" губернатор ", и этимологический корень кибернетики ) был основан Джо Беда, Бренданом Бернсом и Крейгом Маклакки, к которым быстро присоединились другие инженеры Google, включая Брайана Гранта и Тима Хокина, и были первыми объявлено Google в середина 2014 г. На его разработку и дизайн сильно повлияла система Google Borg, и многие из основных участников проекта ранее работали над Borg. Первоначальным кодовым названием Kubernetes в Google было Project 7, отсылка к бывшему персонажу Star Trek Borg Seven of Nine. Семь спиц на колесе логотипа Kubernetes являются отсылкой к этому кодовому имени. Первоначальный проект Borg был полностью написан на C ++, но переписанная система Kubernetes реализована в Go.
. Kubernetes v1.0 был выпущен 21 июля 2015 года. Наряду с выпуском Kubernetes v1.0 Google заключил партнерство с Linux. Foundation для создания Cloud Native Computing Foundation (CNCF) и предложил Kubernetes в качестве исходной технологии. В феврале 2016 года был выпущен пакетный менеджер Helm для Kubernetes. 6 марта 2018 года Kubernetes Project занял девятое место по количеству коммитов на GitHub и второе место по количеству авторов и выпусков для ядра Linux.
| Версия | Дата выпуска | Примечания |
|---|---|---|
| Старая версия, больше не поддерживается: 1.0 | 10 июля 2015 | Исходная версия |
| Старая версия, больше не поддерживается: 1.1 | 9 Ноябрь 2015 года | |
| Старая версия, больше не поддерживается: 1.2 | 16 марта 2016 | |
| Старая версия, больше не поддерживается: 1.3 | 1 июля 2016 года | |
| Старая версия, больше не поддерживается поддерживается: 1.4 | 26 сентября 2016 | |
| Старая версия, больше не поддерживается: 1.5 | 12 декабря 2016 | |
| Старая версия, больше не поддерживается: 1.6 | 28 Март 2017 г. | |
| Старая версия, больше не поддерживается: 1.7 | 30 июня 2017 г. | |
| Старая версия, больше не поддерживается: 1.8 | 28 августа 2017 г. | |
| Старая версия, больше не поддерживается поддерживается: 1,9 | 15 декабря 2017 г. | |
| Старая версия, больше не поддерживается: 1.10 | 28 марта 2018 г. | |
| Старая версия, больше не поддерживается: 1.11 | 3 июля 2018 | |
| Старая версия, больше не поддерживается: 1.12 | 27 сентября 2018 | |
| Старая версия, больше не поддерживается: 1.13 | 3 декабря 2018 | |
| Старая версия, больше не поддерживается: 1.14 | 25 марта 2019 | |
| Старая версия, больше не поддерживается: 1.15 | 20 июня 2019 | |
| Старая версия, больше не поддерживается: 1.16 | 22 октября 2019 г. | |
| Старая версия, но все еще поддерживается: 1.17 | 9 декабря 2019 г. | |
| Старая версия, но все еще поддерживается: 1.18 | 25 марта 2020 г. | |
| Текущая стабильная версия: 1.19 | 26 августа 2020 г. | Начиная с версии Kubernetes 1.19, окно поддержки будет увеличено до одного года |
| Условные обозначения: Старая версия Старая версия, все еще поддерживается Последняя версия Последняя предварительная версия Будущий выпуск | ||
До v1.18, Kubernetes следовали политике поддержки N-2 (это означает, что 3 последних второстепенных версии получают исправления безопасности и ошибок)
Начиная с версии 1.19 и далее wards, Kubernetes будет придерживаться политики поддержки N-3.
На диаграмме ниже показан период, в течение которого каждый выпуск поддерживался / поддерживался
Kubernetes определяет набор строительных блоков («примитивов»), которые в совокупности обеспечивают механизмы развертывания, поддерживать и масштабировать приложения на основе ЦП, памяти или настраиваемых показателей. Kubernetes слабо связан и расширяется для соответствия различным рабочим нагрузкам. Эта расширяемость в значительной степени обеспечивается API Kubernetes, который используется внутренними компонентами, а также расширениями и контейнерами, работающими в Kubernetes. Платформа осуществляет контроль над вычислительными ресурсами и ресурсами хранения, определяя ресурсы как объекты, которыми затем можно управлять как таковые. Ключевые объекты:
Pod - это более высокий уровень абстракции, группирующий контейнерные компоненты. Под состоит из одного или нескольких контейнеров, которые гарантированно размещаются на главном компьютере и могут совместно использовать ресурсы. Базовая единица планирования в Kubernetes - это под.
Каждому поду в Kubernetes назначается уникальный Pod IP-адрес в кластере, что позволяет приложениям использовать порты без риска конфликта. Внутри модуля все контейнеры могут ссылаться друг на друга на локальном хосте, но контейнер внутри одного модуля не имеет возможности напрямую обращаться к другому контейнеру в другом модуле; для этого он должен использовать IP-адрес модуля. Однако разработчик приложения никогда не должен использовать IP-адрес модуля для ссылки / вызова возможности в другом модуле, поскольку IP-адреса модуля являются эфемерными - конкретный модуль, на который они ссылаются, может быть назначен другому IP-адресу модуля при перезапуске. Вместо этого они должны использовать ссылку на Service, которая содержит ссылку на целевой модуль по определенному IP-адресу модуля.
Модуль может определять том, например каталог локального диска или сетевой диск, и предоставлять его контейнерам в модуле. Подами можно управлять вручную через Kubernetes API, или их управление можно делегировать контроллеру. Такие тома также являются основой для функций Kubernetes ConfigMaps (для обеспечения доступа к конфигурации через файловую систему, видимую для контейнера) и Secrets (для предоставления доступа к учетным данным, необходимым для безопасного доступа к удаленным ресурсам, путем предоставления этих учетных данных только в видимой файловой системе. в разрешенные контейнеры).
Цель ReplicaSet - поддерживать стабильный набор реплик Pod, работающих в любой момент времени. Таким образом, он часто используется, чтобы гарантировать доступность указанного количества идентичных модулей.
ReplicaSets также можно назвать механизмом группировки, который позволяет Kubernetes поддерживать количество экземпляров, объявленных для данный стручок. В определении набора реплик используется селектор, оценка которого приведет к идентификации всех связанных с ним подов.
Упрощенное представление, показывающее, как Сервисы взаимодействуют с сетью Pod в кластере Kubernetes Сервис Kubernetes - это набор модулей, которые работают вместе, например, один уровень многоуровневого приложение. Набор модулей, составляющих службу, определяется селектором меток. Kubernetes предоставляет два режима обнаружения служб : с использованием переменных среды или Kubernetes DNS. Обнаружение службы назначает стабильный IP-адрес и DNS-имя службе, а нагрузка распределяет трафик в режиме циклического перебора для сетевых подключений этого IP-адреса среди модулей, соответствующих селектору ( даже если из-за сбоев стручки перемещаются от машины к машине). По умолчанию служба предоставляется внутри кластера (например, модули серверной части могут быть сгруппированы в службу, с запросами от модулей интерфейса пользователя с балансировкой нагрузки между ними), но служба также может быть предоставлена за пределами кластера (например, для доступа клиентов к интерфейсным модулям).
Файловые системы в контейнере Kubernetes по умолчанию предоставляют временное хранилище. Это означает, что перезапуск модуля приведет к стиранию всех данных в таких контейнерах, и, следовательно, такая форма хранения весьма ограничивает все, кроме тривиальных приложений. Том Kubernetes предоставляет постоянное хранилище, которое существует в течение всего срока службы самого модуля. Это хранилище также можно использовать в качестве общего дискового пространства для контейнеров внутри модуля. Тома монтируются в определенных точках монтирования внутри контейнера, которые определяются конфигурацией модуля, и не могут монтироваться на другие тома или связываться с другими томами. Один и тот же том может быть смонтирован в разных точках дерева файловой системы разными контейнерами.
Kubernetes обеспечивает разделение ресурсов, которыми он управляет, на неперекрывающиеся наборы, называемые пространствами имен. Они предназначены для использования в средах с большим количеством пользователей, распределенных по нескольким командам или проектам, или даже в разделенных средах, таких как разработка, тестирование и производство.
Обычная проблема приложений - решить, где хранить и управлять конфигурационной информацией, некоторые из которых могут содержать конфиденциальные данные. Конфигурационные данные могут быть как мелкими, так и отдельными свойствами, или крупнозернистой информацией, например, целыми файлами конфигурации или документами JSON / XML. Kubernetes предоставляет два тесно связанных механизма для решения этой проблемы: «карты конфигурации» и «секреты», оба из которых позволяют вносить изменения в конфигурацию, не требуя сборки приложения. Данные из конфигурационных карт и секретов будут доступны каждому отдельному экземпляру приложения, к которому эти объекты были привязаны через развертывание. Секрет и / или конфигурационная карта отправляются на узел только в том случае, если это требуется модулю на этом узле. Kubernetes будет хранить его в памяти на этом узле. После удаления модуля, зависящего от секрета или карты конфигурации, также удаляются находящиеся в памяти копии всех связанных секретов и карт конфигурации. Данные доступны для модуля одним из двух способов: а) как переменные среды (которые будут созданы Kubernetes при запуске модуля) или б) доступны в файловой системе контейнера, которая видна только из модуля.
Сами данные хранятся на главном устройстве, которое является строго защищенной машиной, к которой никто не должен иметь доступа для входа в систему. Самая большая разница между секретом и конфигурационной картой заключается в том, что содержимое данных в секрете закодировано в base64. В последних версиях Kubernetes также была добавлена поддержка шифрования. Секреты часто используются для хранения таких данных, как сертификаты, пароли, секреты извлечения (учетные данные для работы с реестрами изображений) и ключи ssh.
Решить проблему масштабирования приложений без сохранения состояния очень просто: нужно просто добавить больше запущенных модулей - что Kubernetes делает очень хорошо. Рабочие нагрузки с отслеживанием состояния намного сложнее, потому что состояние должно сохраняться при перезапуске модуля, а если приложение масштабируется вверх или вниз, то состояние может потребоваться перераспределить. Базы данных являются примером рабочих нагрузок с отслеживанием состояния. При запуске в режиме высокой доступности многие базы данных имеют понятие первичного экземпляра и вторичного экземпляра (ов). В этом случае важно упорядочить экземпляры. Другие приложения, такие как Kafka, распределяют данные среди своих брокеров, поэтому один брокер отличается от другого. В этом случае важно понятие уникальности экземпляра. StatefulSets - это контроллеры (см. Controller Manager ниже), которые предоставляются Kubernetes, которые обеспечивают выполнение свойств уникальности и упорядоченности среди экземпляров модуля и могут использоваться для запуска приложений с отслеживанием состояния.
Обычно места, где запускаются поды, определяются алгоритмом, реализованным в планировщике Kubernetes. Однако в некоторых случаях может потребоваться запуск модуля на каждом узле кластера. Это полезно для таких случаев, как сбор журналов, контроллеры входящего трафика и службы хранения. Возможность выполнять этот вид планирования подов реализуется функцией под названием DaemonSets.
Kubernetes предоставляет некоторые механизмы, которые позволяют управлять, выбирать или манипулировать своими объектами.
Kubernetes позволяет клиентам (пользователям или внутренним компонентам) прикреплять ключи, называемые «метками», к любому объекту API в системе, например модулям и узлам. Соответственно, «селекторы меток» - это запросы к меткам, которые разрешаются в соответствующие объекты. Когда служба определена, можно определить селекторы меток, которые будут использоваться маршрутизатором службы / балансировщиком нагрузки для выбора экземпляров модуля, на которые будет направлен трафик. Таким образом, простое изменение меток модулей или изменение селекторов меток в службе можно использовать для управления тем, какие модули получают трафик, а какие нет, что может использоваться для поддержки различных шаблонов развертывания, таких как сине-зеленые развертывания или AB-тестирование. Эта возможность динамически контролировать использование службами реализующих ресурсов обеспечивает слабую связь в инфраструктуре.
Например, если модули приложения имеют метки для системного уровня(со значениями, такими как внешний интерфейс, внутренний интерфейс, например) и release_track(например, со значениями, такими как canary , production), затем операция для всех back-endи canaryузлы могут использовать селектор меток, например:
tier = back-end AND release_track = canary
Как и метки, селекторы полей также позволяют один выберите ресурсы Kubernetes. В отличие от меток, выбор основан на значениях атрибутов, присущих выбранному ресурсу, а не на определяемой пользователем категоризации. metadata.nameи metadata.namespace- это селекторы полей, которые будут присутствовать во всех объектах Kubernetes. Другие селекторы, которые можно использовать, зависят от типа объекта / ресурса.
A ReplicaSet объявляет количество необходимых экземпляров модуля, а контроллер репликации управляет системой таким образом, чтобы количество работающих работающих модулей соответствовало количеству поды, объявленные в ReplicaSet (определяемые путем оценки его селектора).
Развертывания - это механизм управления более высокого уровня для ReplicaSets. В то время как контроллер репликации управляет масштабом ReplicaSet, развертывания будут управлять тем, что происходит с ReplicaSet - нужно ли развернуть обновление или откатить его, и т. Д. Когда развертывания масштабируются вверх или вниз, это приводит к объявлению ReplicaSet change - и этим изменением объявленного состояния управляет контроллер репликации.
Принципы проектирования, лежащие в основе Kubernetes, позволяют программно создавать, настраивать и управлять кластерами Kubernetes. Эта функция предоставляется через API, называемый Cluster API. Ключевой концепцией, воплощенной в API, является представление о том, что кластер Kubernetes сам по себе является ресурсом / объектом, которым можно управлять так же, как любыми другими ресурсами Kubernetes. Точно так же машины, составляющие кластер, также рассматриваются как ресурс Kubernetes. API состоит из двух частей - основного API и реализации поставщика. Реализация провайдера состоит из специфичных для облачного провайдера функций, которые позволяют Kubernetes предоставлять кластерный API в виде, хорошо интегрированном с сервисами и ресурсами облачного провайдера.
Схема архитектуры Kubernetes Kubernetes следует архитектуре первичной / реплики. Компоненты Kubernetes можно разделить на те, которые управляют отдельным узлом , и те, которые являются частью плоскости управления.
Мастер Kubernetes является главный управляющий блок кластера, управляющий его рабочей нагрузкой и управляющий коммуникациями в системе. Плоскость управления Kubernetes состоит из различных компонентов, каждый из которых имеет собственный процесс, которые могут выполняться как на одном главном узле, так и на нескольких мастерах, поддерживающих кластеры высокой доступности. Различные компоненты плоскости управления Kubernetes следующие:
Узел, также известный как рабочий или миньон, - это машина, на которой контейнеры ( рабочие нагрузки) развернуты. На каждом узле в кластере должен быть запущен контейнер среда выполнения, например Docker, а также нижеперечисленные компоненты для связи с основным для сетевой конфигурации этих контейнеров.
Надстройки работают так же, как и любое другое приложение, работающее в кластере. : они реализуются через модули и службы, и отличаются только тем, что реализуют функции кластера Kubernetes. Модулями можно управлять с помощью Deployments, ReplicationControllers и т. Д. Дополнений много, и их список постоянно растет. Вот некоторые из наиболее важных:
Kubernetes обычно используется как способ размещения реализации на основе микросервисов, поскольку он и связанная с ним экосистема инструментов предоставляет все возможности, необходимые для решения основных проблем любой микросервисной архитектуры.
Контейнеры появились как способ сделать программное обеспечение переносимым. Контейнер содержит все пакеты, необходимые для запуска службы. Предоставленная файловая система делает контейнеры чрезвычайно портативными и простыми в использовании при разработке. Контейнер можно перемещать из стадии разработки в тестовую или производственную без изменения конфигурации или с относительно небольшим количеством изменений.
Исторически Kubernetes подходил только для сервисов без сохранения состояния. Однако у многих приложений есть база данных, которая требует постоянства, что приводит к созданию постоянного хранилища для Kubernetes. Внедрение постоянного хранилища для контейнеров - одна из главных задач администраторов Kubernetes, DevOps и облачных инженеров. Контейнеры могут быть эфемерными, но все больше и больше их данных - нет, поэтому необходимо обеспечить сохранность данных в случае завершения контейнера или отказа оборудования.
При развертывании контейнеров с Kubernetes или контейнерных приложений компании часто понимают, что им необходимо постоянное хранилище. Они должны обеспечивать быстрое и надежное хранение баз данных, корневых образов и других данных, используемых контейнерами.
В дополнение к ландшафту, Cloud Native Computing Foundation (CNCF) опубликовала другую информацию о постоянном хранилище Kubernetes, включая блог, помогающий определить шаблон хранилища, подключенного к контейнеру. Этот шаблон можно рассматривать как тот, который использует сам Kubernetes в качестве компонента системы хранения или службы.
Более подробную информацию об относительной популярности этих и других подходов можно найти в обзоре ландшафта CNCF, который показал, что OpenEBS от MayaData и Rook - проект оркестровки хранилищ - были двумя проектами, которые, скорее всего, будут оцениваться осенью 2019 года.
