Kubernetes - Kubernetes

Kubernetes

Автор (ы) оригинала	Google
Разработчики)	Фонд облачных вычислений
Первый выпуск	7 июня 2014 г . ; 7 лет назад ( 2014-06-07 )
Стабильный выпуск	1.22.2 / 4 августа 2021 г . ; 2 месяца назад ( 2021-08-04 )
Репозиторий
Написано в	Идти
Тип	Программное обеспечение для управления кластером
Лицензия	Лицензия Apache 2.0
Веб-сайт	kubernetes .io

Kubernetes ( / ˌ к ( J ) ¯u б ər п ɛ т ɪ с , - п eɪ т ɪ с , - п eɪ т я г / , обычно стилизованные под K8S ) является открытым исходным кодом контейнера - гармоническая система автоматизация развертывания компьютерных приложений , масштабирования и управления. Первоначально он был разработан Google, а сейчас поддерживается Cloud Native Computing Foundation . Его цель - предоставить «платформу для автоматизации развертывания, масштабирования и операций систем управления базами данных». Он работает с рядом инструментов для работы с контейнерами и запускает контейнеры в кластере, часто с образами, созданными с помощью Docker . Первоначально Kubernetes взаимодействовал со средой выполнения Docker через Dockershim; однако с тех пор прокладка не рекомендуется в пользу прямого взаимодействия с контейнером через containerd или замены Docker средой выполнения, совместимой с интерфейсом времени выполнения контейнера (CRI), введенным Kubernetes в 2016 году.

Многие облачные сервисы предлагают платформу на основе Kubernetes или инфраструктуру как услугу ( PaaS или IaaS ), на которой Kubernetes может быть развернут как сервис, предоставляющий платформу. Многие поставщики также предоставляют собственные фирменные дистрибутивы Kubernetes.

История

Выступление Google Kubernetes Engine на саммите Google Cloud

Kubernetes ( κυβερνήτης , греческий язык для « кормчий » или «пилот» или «губернатором», и этимологический корень кибернетике ) была основана Вилле Aikas, Джо Беды, Брендан Бернс, и Крейг McLuckie, которые быстро присоединились и другие инженеры Google , включая Брайан Грант и Тим Хокин, и Google впервые объявил о нем в середине 2014 года. На его разработку и дизайн сильно повлияла система Borg от Google , и многие ведущие участники проекта ранее работали над Borg. Первоначальным кодовым названием Kubernetes в Google было Project 7, отсылка к персонажу Seven of Nine из сериала Star Trek, бывшему Боргу . Семь спиц на колесе логотипа 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.18 Kubernetes придерживался политики поддержки N-2 (это означает, что 3 последних дополнительных версии получают исправления безопасности и ошибок).

Начиная с версии 1.19, Kubernetes будет следовать политике поддержки N-3.

Окна поддержки

На диаграмме ниже показан период, в течение которого поддерживается / поддерживался каждый выпуск.

Концепции

Схема архитектуры Kubernetes

Kubernetes определяет набор строительных блоков («примитивов»), которые в совокупности предоставляют механизмы для развертывания, обслуживания и масштабирования приложений на основе ЦП, памяти или настраиваемых показателей. Kubernetes слабо связан и расширяем для удовлетворения различных рабочих нагрузок. Эта расширяемость в значительной степени обеспечивается API Kubernetes, который используется внутренними компонентами, а также расширениями и контейнерами, работающими в Kubernetes. Платформа осуществляет контроль над вычислительными ресурсами и ресурсами хранения, определяя ресурсы как объекты, которыми затем можно управлять как таковые.

Kubernetes следует архитектуре первичной / реплики . Компоненты Kubernetes можно разделить на те, которые управляют отдельным узлом, и те, которые являются частью плоскости управления.

Объекты кластера

Плоскость управления

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

• etcd: etcd - это постоянное, легкое, распределенное хранилище данных типа "ключ-значение", разработанное CoreOS, которое надежно хранит данные конфигурации кластера, представляющие общее состояние кластера в любой заданный момент времени. Так же, как Apache ZooKeeper , etcd - это система, которая отдает предпочтение согласованности, а не доступности в случае сетевого раздела (см. Теорему CAP ). Эта согласованность имеет решающее значение для правильного планирования и эксплуатации сервисов. Сервер API Kubernetes использует API-интерфейс etcd для мониторинга кластера и развертывания критических изменений конфигурации или просто восстановления любых отклонений состояния кластера до того, что было заявлено разработчиком. Например, если разработчик указал, что необходимо запустить три экземпляра определенного модуля, этот факт сохраняется в etcd. Если обнаруживается, что запущены только два экземпляра, эта дельта будет обнаружена путем сравнения с данными etcd, и Kubernetes будет использовать это для планирования создания дополнительного экземпляра этого модуля.
• Сервер API: сервер API является ключевым компонентом и обслуживает API Kubernetes с использованием JSON через HTTP , который обеспечивает как внутренний, так и внешний интерфейс для Kubernetes. Сервер API обрабатывает и проверяет запросы REST и обновляет состояние объектов API в etcd, тем самым позволяя клиентам настраивать рабочие нагрузки и контейнеры на рабочих узлах.
• Планировщик: Планировщик - это подключаемый компонент, который выбирает, на каком узле запускается незапланированный модуль (базовый объект, управляемый планировщиком), в зависимости от доступности ресурсов. Планировщик отслеживает использование ресурсов на каждом узле, чтобы гарантировать, что рабочая нагрузка не запланирована сверх доступных ресурсов. Для этой цели планировщик должен знать требования к ресурсам, доступность ресурсов и другие предоставляемые пользователем ограничения и директивы политики, такие как требования к качеству обслуживания, соответствия / анти-соответствия, локальность данных и т. Д. По сути, роль планировщика состоит в том, чтобы согласовать «предложение» ресурсов с «спросом» рабочей нагрузки.
• Диспетчер контроллеров: контроллер - это цикл согласования, который приводит фактическое состояние кластера к желаемому состоянию кластера, взаимодействуя с сервером API для создания, обновления и удаления ресурсов, которыми он управляет (модули, конечные точки служб и т. Д.). Диспетчер контроллеров - это процесс, который управляет набором основных контроллеров Kubernetes. Один из видов контроллера - это контроллер репликации, который обрабатывает репликацию и масштабирование путем запуска определенного количества копий модуля в кластере. Он также обрабатывает создание заменяющих модулей в случае сбоя базового узла. Другие контроллеры, которые являются частью основной системы Kubernetes, включают контроллер DaemonSet для запуска ровно одного модуля на каждой машине (или некотором подмножестве машин) и контроллер заданий для запуска модулей, которые выполняются до завершения, например, как часть пакетного задания. Набор модулей, которыми управляет контроллер, определяется селекторами меток, которые являются частью определения контроллера.

Узлы

Узел, также известный как Worker или Minion, - это машина, на которой развертываются контейнеры (рабочие нагрузки). На каждом узле в кластере должна быть запущена среда выполнения контейнера, такая как Docker , а также нижеперечисленные компоненты для связи с основным для сетевой конфигурации этих контейнеров.

• Kubelet: Kubelet отвечает за рабочее состояние каждого узла, обеспечивая работоспособность всех контейнеров на узле. Он заботится о запуске, остановке и обслуживании контейнеров приложений, организованных в поды в соответствии с указаниями уровня управления.

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

• Kube-proxy: Kube-proxy - это реализация сетевого прокси и балансировщика нагрузки , который поддерживает абстракцию службы наряду с другими сетевыми операциями. Он отвечает за маршрутизацию трафика в соответствующий контейнер на основе IP-адреса и номера порта входящего запроса.
• Среда выполнения контейнера: контейнер находится внутри модуля. Контейнер - это самый низкий уровень микросервиса, который содержит работающее приложение, библиотеки и их зависимости. Контейнеры могут быть доступны миру через внешний IP-адрес. Kubernetes поддерживает контейнеры Docker с момента своей первой версии, а в июле 2016 года был добавлен движок контейнеров rkt .

Пространства имён

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

DaemonSets

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

Объекты рабочей нагрузки

Стручки

Базовая единица планирования в Kubernetes - это под . Pod - это группа контейнерных компонентов. Под состоит из одного или нескольких контейнеров, которые гарантированно будут размещены на одном узле.

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

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

ReplicaSets

Цель ReplicaSet - поддерживать стабильный набор реплик Pod, работающих в любой момент времени. Таким образом, он часто используется, чтобы гарантировать доступность определенного количества идентичных модулей.

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

Услуги

Упрощенное представление, показывающее, как службы взаимодействуют с сетью Pod в кластере Kubernetes

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

Объемы

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

ConfigMaps и секреты

Распространенная проблема приложений - решить, где хранить информацию о конфигурации и управлять ею, некоторые из которых могут содержать конфиденциальные данные. Конфигурационные данные могут быть как детализированными, так и отдельными свойствами, или крупнозернистой информацией, например, целыми файлами конфигурации или документами JSON / XML. Kubernetes предоставляет два тесно связанных механизма для решения этой проблемы: «карты конфигурации» и «секреты», оба из которых позволяют вносить изменения в конфигурацию, не требуя сборки приложения. Данные из конфигурационных карт и секретов будут доступны каждому экземпляру приложения, к которому эти объекты были привязаны через развертывание. Секрет и / или конфигурационная карта отправляются на узел только в том случае, если это требуется модулю на этом узле. Kubernetes будет хранить его в памяти на этом узле. После удаления модуля, зависящего от секрета или карты конфигурации, также удаляются находящиеся в памяти копии всех связанных секретов и карт конфигурации. Данные доступны для модуля одним из двух способов: а) как переменные среды (которые будут созданы Kubernetes при запуске модуля) или б) доступны в файловой системе контейнера, которая видна только внутри модуля.

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

StatefulSets

Решить проблему масштабирования приложений без сохранения состояния очень просто: нужно просто добавить больше запущенных модулей - что Kubernetes делает очень хорошо. Рабочие нагрузки с отслеживанием состояния намного сложнее, потому что состояние должно сохраняться при перезапуске модуля, а если приложение масштабируется вверх или вниз, то состояние может потребоваться перераспределить. Базы данных являются примером рабочих нагрузок с отслеживанием состояния. При запуске в режиме высокой доступности многие базы данных имеют понятие первичного экземпляра и вторичного экземпляра (ов). В этом случае важно упорядочить экземпляры. Другие приложения, такие как Kafka, распределяют данные между своими брокерами, поэтому один брокер не совпадает с другим. В этом случае важно понятие уникальности экземпляра. StatefulSets - это контроллеры (см. Диспетчер контроллеров выше), предоставляемые Kubernetes, которые обеспечивают выполнение свойств уникальности и упорядочения среди экземпляров модуля и могут использоваться для запуска приложений с отслеживанием состояния.

Контроллеры репликации и развертывания

ReplicaSet объявляет количество экземпляров стручка , которые необходимы, и контроллер репликации управляет системой таким образом , что число здоровых стручков, работающих матчи число стручков , заявленных в ReplicaSet (определяется путем оценки его выбора).

Развертывания - это механизм управления более высокого уровня для ReplicaSets. В то время как контроллер репликации управляет масштабом ReplicaSet, развертывания будут управлять тем, что происходит с ReplicaSet - нужно ли развернуть обновление или откатить его и т. Д. Когда развертывания масштабируются вверх или вниз, это приводит к объявлению Изменение ReplicaSet - и это изменение объявленного состояния управляется Контроллером репликации.

Ярлыки и селекторы

Kubernetes позволяет клиентам (пользователям или внутренним компонентам) прикреплять ключи, называемые «метками», к любому объекту API в системе, например модулям и узлам . Соответственно, «селекторы меток» - это запросы к меткам, которые разрешаются к совпадающим объектам. Когда служба определена, можно определить селекторы меток, которые будут использоваться маршрутизатором службы / балансировщиком нагрузки для выбора экземпляров модуля, на которые будет маршрутизироваться трафик. Таким образом, простое изменение меток модулей или изменение селекторов меток в сервисе можно использовать для управления тем, какие модули получают трафик, а какие нет, что можно использовать для поддержки различных шаблонов развертывания, таких как сине-зеленые развертывания или AB-тестирование . Эта возможность динамически контролировать, как службы используют реализующие ресурсы, обеспечивает слабую связь в инфраструктуре.

Например, если стручки приложения , имеют метки для системы tier(со значениями , такими как front-end, back-endнапример) , и release_track(со значениями , такими как canary, productionнапример), то операция на все back-endи canaryузлах можно использовать селектор меток, например в качестве:

tier=back-end AND release_track=canary

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

Дополнения

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

• DNS: все кластеры Kubernetes должны иметь кластерный DNS; это обязательная функция. Кластерный DNS - это DNS-сервер в дополнение к другим DNS-серверам в вашей среде, который обслуживает записи DNS для служб Kubernetes. Контейнеры, запускаемые Kubernetes, автоматически включают этот DNS-сервер в свои поисковые запросы DNS.
• Веб-интерфейс: это универсальный веб-интерфейс для кластеров Kubernetes. Он позволяет пользователям управлять приложениями, работающими в кластере, а также самим кластером и устранять их неполадки.
• Мониторинг ресурсов контейнера: обеспечение надежной среды выполнения приложения и возможность масштабирования его вверх или вниз в ответ на рабочие нагрузки означает возможность непрерывно и эффективно отслеживать производительность рабочих нагрузок. Мониторинг ресурсов контейнеров обеспечивает эту возможность путем записи показателей контейнеров в центральную базу данных и предоставляет пользовательский интерфейс для просмотра этих данных. CAdvisor - это компонент на подчиненном узле, который обеспечивает ограниченные возможности мониторинга метрик. Также существуют конвейеры полных показателей, такие как Prometheus, которые могут удовлетворить большинство потребностей в мониторинге.
• Ведение журнала на уровне кластера: журналы должны иметь отдельное хранилище и жизненный цикл независимо от узлов, модулей или контейнеров. В противном случае сбои узла или модуля могут вызвать потерю данных о событии. Возможность сделать это называется ведением журнала на уровне кластера, и такие механизмы отвечают за сохранение журналов контейнеров в центральном хранилище журналов с интерфейсом поиска / просмотра. Kubernetes не предоставляет собственного хранилища для данных журналов, но можно интегрировать многие существующие решения для ведения журналов в кластер Kubernetes.

Место хранения

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

Исторически Kubernetes подходил только для сервисов без сохранения состояния. Однако у многих приложений есть база данных, которая требует постоянства, что приводит к созданию постоянного хранилища для Kubernetes. Внедрение постоянного хранилища для контейнеров - одна из главных задач администраторов Kubernetes, DevOps и облачных инженеров. Контейнеры могут быть эфемерными, но все больше и больше их данных - нет, поэтому необходимо обеспечить сохранение данных в случае завершения контейнера или отказа оборудования. При развертывании контейнеров с Kubernetes или контейнерных приложений компании часто понимают, что им необходимо постоянное хранилище. Они должны обеспечивать быстрое и надежное хранилище для баз данных, корневых образов и других данных, используемых контейнерами.

В дополнение к ландшафту, Cloud Native Computing Foundation (CNCF) опубликовала другую информацию о постоянном хранилище Kubernetes, в том числе блог, помогающий определить шаблон хранилища, подключенного к контейнеру. Этот шаблон можно рассматривать как тот, который использует сам Kubernetes как компонент системы хранения или службы.

Более подробную информацию об относительной популярности этих и других подходов можно найти в обзоре ландшафта CNCF, который показал, что OpenEBS от MayaData и Rook - проект оркестровки хранилищ - были двумя проектами, которые, скорее всего, будут оцениваться осенью. 2019 года.

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

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

API

Ключевым компонентом плоскости управления Kubernetes является сервер API, который предоставляет HTTP API, который может быть вызван другими частями кластера, а также конечными пользователями и внешними компонентами. Этот API является REST API и носит декларативный характер. Есть два типа ресурсов API. Большинство ресурсов API в Kubernetes API являются объектами. Они представляют собой конкретный экземпляр концепции в кластере, например модуль или пространство имен. Небольшое количество типов ресурсов API являются «виртуальными». Они представляют собой операции, а не объекты, такие как проверка разрешений с использованием ресурса «subjectaccessreviews». Ресурсы API, соответствующие объектам, будут представлены в кластере с уникальными идентификаторами для объектов. Виртуальные ресурсы не имеют уникальных идентификаторов.

Операторы

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

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

Кластерный API

Те же принципы проектирования API использовались для определения API для программного создания, настройки и управления кластерами Kubernetes. Это называется Cluster API. Ключевой концепцией, воплощенной в API, является представление о том, что кластер Kubernetes сам по себе является ресурсом / объектом, которым можно управлять так же, как и любыми другими ресурсами Kubernetes. Точно так же машины, составляющие кластер, также рассматриваются как ресурс Kubernetes. API состоит из двух частей - основного API и реализации поставщика. Реализация провайдера состоит из функций, специфичных для облачного провайдера, которые позволяют Kubernetes предоставлять кластерный API в форме, которая хорошо интегрирована с сервисами и ресурсами облачного провайдера.

Использует

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

Смотрите также

• Фонд облачных вычислений
• Докер (программное обеспечение)
• Список программного обеспечения для управления кластером
• Открытая сервисная сетка
• OpenShift

использованная литература

внешние ссылки

• Официальный веб-сайт
• Kubernetes на GitHub