✖


Jump to content

Кубернетес

(Перенаправлено с Google Borg )
Кубернетес
Оригинальный автор(ы) Google
Разработчик(и) Фонд облачных вычислений
Первоначальный выпуск 0.2 [1] / 9 сентября 2014 г .; 9 лет назад ( 09.09.2014 )
Стабильная версия
1.30.3 [2] Отредактируйте это в Викиданных / 17 июля 2024 г .; 19 дней назад ( 17 июля 2024 г. )
Репозиторий
Написано в Идти
Тип Программное обеспечение для управления кластером
Лицензия Лицензия Апач 2.0
Веб-сайт Кубернетес .что

Kubernetes ( / ˌ k ( j ) uː b ər ˈ n ɛ t ɪ s , - ˈ n eɪ t ɪ s , - ˈ n eɪ t iː z , - ˈ n ɛ t iː z / , K8s ) [3] — это с открытым исходным кодом контейнеров система оркестрации для автоматизации развертывания , масштабирования и управления программным обеспечением. [4] [5] Первоначально разработанный Google , проект теперь поддерживается мировым сообществом участников, а товарный знак принадлежит Cloud Native Computing Foundation .

Название Kubernetes происходит от греческого κυβερνήτης (kubernḗtēs), что означает правитель, « рулевой » или «пилот». Kubernetes часто сокращается до K8s , считая восемь букв между K и s ( нумероним ). [6]

Kubernetes объединяет один или несколько компьютеров, виртуальных машин или «голого железа» , в кластер , который может выполнять рабочие нагрузки в контейнерах. Он работает с различными средами выполнения контейнеров, такими какContainerd и CRI-O . [7] Его пригодность для запуска и управления рабочими нагрузками любого размера и стиля привела к его широкому распространению в облаках и центрах обработки данных. Существует несколько дистрибутивов этой платформы — от независимых поставщиков программного обеспечения (ISV), а также предложения, размещаемые в облаке, от всех основных поставщиков общедоступных облаков. [8]

Kubernetes — одна из наиболее широко используемых программных систем в мире. [9] используется в таких компаниях, как Google , Microsoft , Amazon , Apple , Meta , Nvidia , Reddit и Pinterest .

История

[ редактировать ]
Доклад Google Kubernetes Engine на Google Cloud Summit 2017

Kubernetes ( древнегреческий : κυβερνήτης , латинизированный : kubernḗtēs , « рулевой, навигатор » или « проводник » , и этимологический корень кибернетики ) [5] было объявлено Google 6 июня 2014 года. [10] Проект был задуман и создан сотрудниками Google Джо Беда, Бренданом Бернсом и Крейгом Маклаки. Вскоре к участию в проекте присоединились и другие сотрудники Google, в том числе Вилле Айкас, Дон Чен, Брайан Грант, Тим Хокин и Дэниел Смит. [11] [12] Вскоре к этим усилиям присоединились и другие компании, такие как Red Hat и CoreOS, а также такие известные участники, как Клейтон Коулман и Келси Хайтауэр. [10]

Дизайн и разработка Kubernetes были вдохновлены менеджером кластера Google Borg и основаны на теории обещаний . [13] [14] Многие из его ведущих участников ранее работали над Боргом; [15] [16] они назвали Kubernetes « Проект 7 » в честь «Звездного пути» бывшего Борга из персонажа Седьмой из девяти. [17] и присвоил своему логотипу корабельное колесо с семью спицами (разработанное Тимом Хокином). В отличие от Borg, написанного на C++ , [15] Kubernetes написан на языке Go .

Kubernetes был анонсирован в июне 2014 года, а версия 1.0 была выпущена 21 июля 2015 года. [18] Google работал с Linux Foundation для создания Cloud Native Computing Foundation (CNCF). [19] и предложил Kubernetes в качестве исходной технологии.

Google уже предлагал управляемый сервис Kubernetes, GKE , а Red Hat поддерживала Kubernetes как часть OpenShift с момента создания проекта Kubernetes в 2014 году. [20] В 2017 году основные конкуренты объединились вокруг Kubernetes и объявили о добавлении для него встроенной поддержки:

6 марта 2018 года Kubernetes Project вышел на девятое место в списке проектов GitHub по количеству коммитов , а также второе место по авторам и проблемам, после ядра Linux . [26]

До версии 1.18 Kubernetes следовал политике поддержки N-2, что означает, что три последние второстепенные версии получают обновления безопасности и исправления ошибок. [27] Начиная с версии 1.19, Kubernetes придерживается политики поддержки N-3. [28]

Концепции

[ редактировать ]
Схема архитектуры Kubernetes

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

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

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

[ редактировать ]

Главный узел Kubernetes управляет плоскостью управления Kubernetes кластера, управляя его рабочей нагрузкой и направляя обмен данными по всей системе. Плоскость управления Kubernetes состоит из различных компонентов, таких как шифрование TLS , RBAC и метод строгой аутентификации , разделение сети, каждый из которых представляет собой собственный процесс, который может выполняться как на одном главном узле, так и на нескольких главных узлах, поддерживающих кластеры высокой доступности . [32] Ниже приведены различные компоненты плоскости управления Kubernetes. [33]

И т.д.

[ редактировать ]

И т.д. [34] — это постоянное, легкое, распределенное хранилище данных «ключ-значение» (первоначально разработанное для Container Linux ). Он надежно хранит данные конфигурации кластера, представляющие общее состояние кластера в любой момент времени. etcd предпочитает согласованность доступности в случае разделения сети (см. теорему CAP ). Последовательность имеет решающее значение для правильного планирования и эксплуатации услуг.

API-сервер

[ редактировать ]

Сервер API Kubernetes, обслуживает API используя JSON через HTTP , который предоставляет как внутренний, так и внешний интерфейс для Kubernetes. [31] [35] Сервер API обрабатывает, проверяет запросы REST и обновляет состояние объектов API в etcd, тем самым позволяя клиентам настраивать рабочие нагрузки и контейнеры на рабочих узлах. [36] Сервер API использует API-интерфейс наблюдения etcd для мониторинга кластера, внесения критических изменений в конфигурацию или восстановления любых расхождений в состоянии кластера обратно в желаемое состояние, как заявлено в etcd.

Например, человек-оператор может указать, что должны быть запущены три экземпляра определенного «пода» (см. ниже), и etcd сохраняет этот факт. Если контроллер развертывания обнаружит, что запущены только два экземпляра (конфликтуя с объявлением etcd), [37] он планирует создание дополнительного экземпляра этого модуля. [32]

Планировщик

[ редактировать ]

Планировщик — это расширяемый компонент , который выбирает узел, на котором запускается незапланированный модуль (базовая единица планируемых рабочих нагрузок), на основе доступности ресурсов и других ограничений. Планировщик отслеживает распределение ресурсов на каждом узле, чтобы гарантировать, что рабочая нагрузка не будет запланирована сверх доступных ресурсов. Для этой цели планировщик должен знать требования к ресурсам, доступность ресурсов и другие введенные пользователем ограничения или директивы политики, такие как качество обслуживания, требования к сходству/анти-сходству и локальность данных. Роль планировщика состоит в том, чтобы сопоставить «предложение» ресурсов со «спросом» рабочей нагрузки. [38]

Kubernetes позволяет запускать несколько планировщиков в одном кластере. Таким образом, плагины планировщика могут разрабатываться и устанавливаться как внутрипроцессные расширения стандартного планировщика, запуская его как отдельный планировщик, если они соответствуют структуре планирования Kubernetes. [39] Это позволяет администраторам кластера расширять или изменять поведение планировщика Kubernetes по умолчанию в соответствии со своими потребностями.

Контроллеры

[ редактировать ]

Контроллер — это цикл согласования , который приводит фактическое состояние кластера в желаемое состояние, взаимодействуя с сервером API для создания, обновления и удаления ресурсов, которыми он управляет (например, модулей или конечных точек службы). [40] [35]

Примером контроллера является контроллер ReplicaSet, который управляет репликацией и масштабированием, запуская указанное количество копий модуля в кластере. Контроллер также обрабатывает создание заменяющих модулей в случае сбоя базового узла. [40] Другие контроллеры, являющиеся частью базовой системы Kubernetes, включают контроллер DaemonSet для запуска ровно одного модуля на каждой машине (или некотором подмножестве компьютеров) и контроллер заданий для запуска модулей, которые выполняются до завершения (например, как часть пакетного задания). . [41] Селекторы меток часто являются частью определения контроллера, определяющего набор модулей, которыми управляет контроллер. [42]

Диспетчер контроллеров — это единый процесс, который управляет несколькими основными контроллерами Kubernetes (включая описанные выше примеры), распространяется в рамках стандартной установки Kubernetes и реагирует на потерю узлов. [33]

В кластере также могут быть установлены пользовательские контроллеры, что позволяет расширять поведение и API Kubernetes при использовании в сочетании с настраиваемыми ресурсами (см. настраиваемые ресурсы, контроллеры и операторы ниже).

Узлы

[ редактировать ]

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

кубелет

[ редактировать ]

kubelet отвечает за рабочее состояние каждого узла, гарантируя работоспособность всех контейнеров на узле. Он отвечает за запуск, остановку и поддержку контейнеров приложений, организованных в модули в соответствии с указаниями плоскости управления. [31] [43] kubelet отслеживает состояние модуля, и если он не находится в желаемом состоянии, модуль повторно развертывается на том же узле. Статус узла передается каждые несколько секунд через контрольные сообщения на сервер API. Как только плоскость управления обнаруживает сбой узла, ожидается, что контроллер более высокого уровня заметит это изменение состояния и запустит модули на другом исправном узле. [44]

Время выполнения контейнера

[ редактировать ]

Среда выполнения контейнера отвечает за жизненный цикл контейнеров, включая запуск, согласование и уничтожение контейнеров. kubelet взаимодействует со средой выполнения контейнера через интерфейс времени выполнения контейнера (CRI), [45] [46] который отделяет обслуживание ядра Kubernetes от фактической реализации CRI.

Первоначально kubelet взаимодействовал исключительно со Docker. средой выполнения [47] через «докершим». Однако с ноября 2020 г. [48] до апреля 2022 года Kubernetes отказался от поддержки оболочки в пользу прямого взаимодействия с контейнером через контейнер или заменил Docker средой выполнения, совместимой с интерфейсом времени выполнения контейнера (CRI). [49] [45] [50] С выпуском версии 1.24 в мае 2022 года «докершим» был полностью удален. [51]

Примеры популярных сред выполнения контейнеров, совместимых с kubelet, включаютContainerd ( изначально поддерживается через Docker), rkt. [52] и ЦНИИ-О .

быть доверенным лицом

[ редактировать ]

kube-proxy — это реализация сетевого прокси и балансировщика нагрузки , которая поддерживает абстракцию сервиса наряду с другими сетевыми операциями. [31] Он отвечает за маршрутизацию трафика в соответствующий контейнер на основе IP и номера порта входящего запроса.

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

[ редактировать ]

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

Стручки

[ редактировать ]

Базовая единица планирования в Kubernetes — это модуль . [54] который состоит из одного или нескольких контейнеров, которые гарантированно будут размещены на одном узле. [31] Каждому поду в Kubernetes назначается уникальный IP-адрес внутри кластера, что позволяет приложениям использовать порты без риска конфликта. [55] Внутри модуля все контейнеры могут ссылаться друг на друга.

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

Рабочие нагрузки

[ редактировать ]

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

Наборы реплик, контроллеры репликации и развертывания

[ редактировать ]

Цель ReplicaSet . — поддерживать стабильный набор модулей реплик, работающих в любой момент времени Таким образом, он часто используется для гарантии доступности определенного количества идентичных модулей. [56] Можно также назвать ReplicaSet механизмом группировки, который позволяет Kubernetes поддерживать количество экземпляров, объявленных для данного модуля. В определении ReplicaSet используется селектор, оценка которого приведет к идентификации всех связанных с ним модулей.

ReplicationController , аналогичный ReplicaSet, служит той же цели и ведет себя аналогично ReplicaSet , то есть гарантирует, что всегда будет определенное желаемое количество реплик модуля. Рабочая нагрузка ReplicationController была предшественником ReplicaSet, но в конечном итоге была признана устаревшей в пользу ReplicaSet, чтобы использовать селекторы меток на основе наборов. [56]

Развертывания — это механизм управления более высокого уровня для наборов реплик. В то время как контроллер ReplicaSet управляет масштабом ReplicaSet, контроллер Deployment управляет тем, что происходит с ReplicaSet — нужно ли развертывать или откатывать обновление и т. д. Когда развертывания масштабируются вверх или вниз, это приводит к объявлению меняется ReplicaSet, и это изменение в объявленном состоянии управляется контроллером ReplicaSet. [37]

StatefulSets

[ редактировать ]

StatefulSets — это контроллеры, которые обеспечивают свойства уникальности и упорядочивания экземпляров модуля и могут использоваться для запуска с отслеживанием состояния . приложений [57] Хотя масштабирование приложений без сохранения состояния — это всего лишь вопрос добавления большего количества работающих модулей, сделать это для рабочих нагрузок с сохранением состояния сложнее, поскольку состояние необходимо сохранить, если модуль перезапускается. Если приложение масштабируется вверх или вниз, возможно, потребуется перераспределить состояние.

Базы данных являются примером рабочих нагрузок с отслеживанием состояния. При работе в режиме высокой доступности многие базы данных имеют понятие первичного экземпляра и вторичных экземпляров. В этом случае важно понятие упорядочения экземпляров. Другие приложения, такие как Apache Kafka, распределяют данные между своими брокерами; следовательно, один брокер не похож на другого. В этом случае важно понятие уникальности экземпляра.

Наборы демонов

[ редактировать ]

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

Услуги

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

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

Объемы

[ редактировать ]

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

ConfigMaps и секреты

[ редактировать ]

Распространенной проблемой приложения является принятие решения о том, где хранить информацию о конфигурации и управлять ею, часть которой может содержать конфиденциальные данные. Данные конфигурации могут быть как детальными, например отдельные свойства, так и более подробной информацией, например целыми файлами конфигурации, такими как документы JSON или XML . Kubernetes предоставляет два тесно связанных механизма для решения этой задачи, известные как ConfigMaps и Secrets , оба из которых позволяют вносить изменения в конфигурацию, не требуя пересборки приложения.

Данные из ConfigMaps и Secrets будут доступны каждому экземпляру приложения, к которому эти объекты были привязаны через развертывание. Секрет и/или ConfigMap отправляются на узел только в том случае, если этого требует модуль на этом узле, который будет храниться только в памяти на узле. После удаления модуля, который зависит от Secret или ConfigMap, копии всех связанных секретов и ConfigMap в памяти также удаляются.

Данные из ConfigMap или Secret доступны для модуля одним из следующих способов: [62]

  1. В качестве переменных окружения , которые будут потребляться kubelet из ConfigMap при запуске контейнера;
  2. Монтируется в том, доступный в файловой системе контейнера, который поддерживает автоматическую перезагрузку без перезапуска контейнера.

Самая большая разница между Secret и ConfigMap заключается в том, что секреты специально разработаны для хранения безопасных и конфиденциальных данных, хотя по умолчанию они не шифруются в состоянии покоя и требуют дополнительной настройки для полной защиты использования секретов в кластере. [63] Секреты часто используются для хранения конфиденциальных или конфиденциальных данных, таких как сертификаты, учетные данные для работы с реестрами изображений, пароли и SSH ключи .

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

[ редактировать ]

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

Например, если модули приложения имеют метки для системы tier (с такими значениями, как frontend, backend, например) и release_track (с такими значениями, как canary, production, например), то операция над всеми backend и canary узлы могут использовать селектор меток, например: [42]

tier=backend AND release_track=canary

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

Дополнения

[ редактировать ]

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

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

Хранилище

[ редактировать ]

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

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

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

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

Container Attached Storage — это тип хранилища данных, который появился, когда Kubernetes приобрел известность. Подход или шаблон Container Attached Storage опирается на сам Kubernetes для определенных возможностей, обеспечивая при этом в основном блочные, файловые, объектные и интерфейсы для рабочих нагрузок, выполняемых в Kubernetes. [67]

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

Интерфейс хранения контейнеров (CSI)

[ редактировать ]

В Kubernetes версии 1.9 была представлена ​​первоначальная альфа-версия Container Storage Interface (CSI). [70] Ранее плагины томов хранения были включены в дистрибутив Kubernetes. Благодаря созданию стандартизированного CSI код, необходимый для взаимодействия с внешними системами хранения, был отделен от основной базы кода Kubernetes. Всего год спустя функция CSI стала общедоступной (GA) в Kubernetes. [71]

API

[ редактировать ]

Ключевым компонентом плоскости управления Kubernetes является API-сервер, который предоставляет HTTP API, который может вызываться другими частями кластера, а также конечными пользователями и внешними компонентами. Этот API является REST API, имеет декларативный характер и представляет собой тот же API, доступный для плоскости управления. [72] Сервер API поддерживается etcd для постоянного хранения всех записей. [73]

Объекты API

[ редактировать ]

В Kubernetes все объекты служат « записями о намерениях » состояния кластера и могут определять желаемое состояние, в котором автор объекта желает, чтобы кластер находился. [74] Таким образом, большинство объектов Kubernetes имеют один и тот же набор вложенных полей, а именно:

  • spec: описывает желаемое состояние ресурса, которым могут управлять конечные пользователи или другие контроллеры более высокого уровня;
  • status: описывает текущее состояние ресурса, которое активно обновляется контроллером ресурса.

Все объекты в Kubernetes подчиняются одним и тем же соглашениям API. Некоторые из них включают в себя:

  • Должны иметь следующие метаданные в поле вложенного объекта metadata: [75]
    • namespace: метка, на которую подразделяются объекты;
    • name: строка, которая однозначно идентифицирует объект в определенном пространстве имен;
    • uid: уникальная строка, позволяющая различать объекты с одинаковым именем в пространстве и времени (даже при удалении и воссоздании объектов с тем же именем).
  • Может управляться другим контроллером, который определен в metadata.ownerReferences поле: [76]
    • Не более одного другого объекта должен быть управляющим контроллером контролируемого объекта, который определяется controller поле.
  • Может быть собран мусор, если владелец удален: [77]
    • При удалении объекта все зависимые объекты также могут быть удалены каскадным образом.

Пользовательские ресурсы, контроллеры и операторы

[ редактировать ]

API Kubernetes можно расширить с помощью Custom Resources , которые представляют собой объекты, не являющиеся частью стандартной установки Kubernetes. Эти настраиваемые ресурсы объявляются с помощью определений настраиваемых ресурсов (CRD), которые представляют собой своего рода ресурс, который можно динамически регистрировать и отменять регистрацию без выключения или перезапуска работающего в данный момент кластера. [78]

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

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

Примеры проблем, решаемых операторами, включают создание и восстановление резервных копий состояния этого приложения, а также обработку обновлений кода приложения наряду с соответствующими изменениями, такими как схемы базы данных или дополнительные параметры конфигурации. Несколько известных проектов в рамках инкубационной программы Cloud Native Computing Foundation следуют шаблону оператора для расширения Kubernetes, включая Argo, Open Policy Agent и Istio. [79]

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

[ редактировать ]

Kubernetes определяет следующие стратегии управления доступом к своему API. [80]

Транспортная безопасность

[ редактировать ]

Сервер Kubernetes API прослушивает TCP-порт , который обслуживает HTTPS- трафик, чтобы обеспечить безопасность транспортного уровня (TLS) с помощью сертификатов CA. [33]

В более старых версиях Kubernetes сервер API поддерживал прослушивание портов HTTP и HTTPS (при этом номер порта HTTP не имел никакой транспортной безопасности). Это устарело в версии 1.10, и в конечном итоге поддержка была прекращена в версии 1.20 Kubernetes. [81]

Аутентификация

[ редактировать ]

Ожидается, что все запросы к серверу API Kubernetes будут аутентифицированы и поддерживаются несколько стратегий аутентификации, некоторые из которых перечислены ниже: [82]

  1. X.509 Клиентские сертификаты
  2. Токены на предъявителя
  3. Токены сервисных учетных записей, предназначенные для программного доступа к API.

Обычно ожидается, что пользователи укажут и определят детали URL-адреса кластера вместе с необходимыми учетными данными в файле kubeconfig , которые изначально поддерживаются другими инструментами Kubernetes, такими как kubectl и официальными клиентскими библиотеками Kubernetes. [83]

Авторизация

[ редактировать ]

Kubernetes API поддерживает следующие режимы авторизации: [84]

  1. Режим авторизации узла : предоставляет фиксированный список операций запросов API, которые кубелетам разрешено выполнять для правильной работы.
  2. управления доступом на основе атрибутов (ABAC) Режим : предоставляет права доступа пользователям посредством использования определенных политик управления доступом, которые объединяют атрибуты вместе.
  3. управления доступом на основе ролей (RBAC) Режим : предоставляет пользователям права доступа на основе ролей, предоставленных пользователю, где каждая роль определяет список разрешенных действий.
  4. Режим веб-перехватчика : запрашивает службу REST API, чтобы определить, имеет ли пользователь право выполнить данное действие. [33]

API-клиенты

[ редактировать ]

Kubernetes поддерживает несколько официальных API-клиентов:

Кластерный API

[ редактировать ]

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

Использование

[ редактировать ]

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

Распределения

[ редактировать ]

Различные поставщики предлагают платформы на базе Kubernetes или инфраструктуру как услугу (IaaS), которые развертывают Kubernetes. [88] [89]

Обычно они подразделяются на дистрибутивы с открытым исходным кодом, коммерческие или управляемые. Ниже перечислены несколько известных дистрибутивов: [90]

Дистрибутивы с открытым исходным кодом

[ редактировать ]

Коммерческие дистрибутивы

[ редактировать ]

Управляемые дистрибутивы

[ редактировать ]
  • Alibaba Cloud ACK (Облачный контейнерный сервис Alibaba для Kubernetes)
  • Amazon EKS (сервис Elastic Kubernetes)
  • Canonical MicroK8 и Charmed Kubernetes
  • DigitalOcean Служба Kubernetes под управлением
  • Google GKE (движок Google Kubernetes)
  • Huawei CCE (Облачный контейнерный процессор Huawei)
  • IBM Cloud Kubernetes Службы
  • Microsoft AKS (службы Azure Kubernetes)
  • Mirantis Kubernetes Engine с управляемыми сервисами OpsCare Plus
  • Oracle Container Engine для Kubernetes
  • Управляемый Kubernetes с помощью Platform9
  • Wind River Systems Студия Wind River

График выпуска

[ редактировать ]
График выпуска
Версия Дата выпуска Дата окончания срока службы [91] Примечания
Старая версия, больше не поддерживается: 1.0. 10 июля 2015 г. Оригинальный выпуск
Старая версия, больше не поддерживается: 1.1. 9 ноября 2015 г. [92]
Старая версия, больше не поддерживается: 1.2. 16 марта 2016 г. 23 октября 2016 г. [93]
Старая версия, больше не поддерживается: 1.3. 1 июля 2016 г. 1 ноября 2016 г. [94]
Старая версия, больше не поддерживается: 1.4. 26 сентября 2016 г. 21 апреля 2017 г. [95]
Старая версия, больше не поддерживается: 1.5. 12 декабря 2016 г. 1 октября 2017 г. [96]
Старая версия, больше не поддерживается: 1.6. 28 марта 2017 г. 23 ноября 2017 г. [97]
Старая версия, больше не поддерживается: 1.7. 30 июня 2017 г. 4 апреля 2018 г. [98]
Старая версия, больше не поддерживается: 1.8. 28 августа 2017 г. 12 июля 2018 г. [99]
Старая версия, больше не поддерживается: 1.9. 15 декабря 2017 г. 29 сентября 2018 г. [100]
Старая версия, больше не поддерживается: 1.10. 28 марта 2018 г. 13 февраля 2019 г. [101]
Старая версия, больше не поддерживается: 1.11. 3 июля 2018 г. 1 мая 2019 г. [102]
Старая версия, больше не поддерживается: 1.12. 27 сентября 2018 г. 8 июля 2019 г. [103]
Старая версия, больше не поддерживается: 1.13. 3 декабря 2018 г. 15 октября 2019 г. [104]
Старая версия, больше не поддерживается: 1.14. 25 марта 2019 г. 11 декабря 2019 г. [105]
Старая версия, больше не поддерживается: 1.15. 20 июня 2019 г. 6 мая 2020 г. [106]
Старая версия, больше не поддерживается: 1.16. 22 октября 2019 г. 2 сентября 2020 г. [107]
Старая версия, больше не поддерживается: 1.17. 9 декабря 2019 г. 13 января 2021 г. [108]
Старая версия, больше не поддерживается: 1.18. 25 марта 2020 г. 18 июня 2021 г. [109]
Старая версия, больше не поддерживается: 1.19. 26 августа 2020 г. [110] 28 октября 2021 г. Начиная с версии Kubernetes 1.19, окно поддержки было расширено до одного года полной поддержки плюс два месяца периода обслуживания. [28]
[111]
Старая версия, больше не поддерживается: 1.20. 8 декабря 2020 г. 28 февраля 2022 г. [112]
Старая версия, больше не поддерживается: 1.21. 8 апреля 2021 г. 28 июня 2022 г. [113]
Старая версия, больше не поддерживается: 1.22. 4 августа 2021 г. 28 октября 2022 г. [114]
Старая версия, больше не поддерживается: 1.23. 7 декабря 2021 г. 28 февраля 2023 г. [115]
Старая версия, больше не поддерживается: 1.24. 3 мая 2022 г. 28 июля 2023 г. [116]
Старая версия, больше не поддерживается: 1.25. 23 августа 2022 г. 27 октября 2023 г. [117]
Старая версия, больше не поддерживается: 1.26. 9 декабря 2022 г. 24 февраля 2024 г. [118]
Старая версия, но все еще поддерживается: 1.27. 11 апреля 2023 г. 28 июня 2024 г. [119]
Старая версия, но все еще поддерживается: 1.28. 15 августа 2023 г. 28 октября 2024 г. [120]
Старая версия, но все еще поддерживается: 1.29. 13 декабря 2023 г. 28 февраля 2025 г. [121]
Текущая стабильная версия: 1.30. 17 апреля 2024 г. 28 июня 2025 г. [122]
Легенда:
Старая версия
Старая версия, все еще поддерживается
Последняя версия
Последняя предварительная версия
Будущий выпуск

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

[ редактировать ]

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

См. также

[ редактировать ]

Ссылки

[ редактировать ]
  1. ^ "v0.2" . github.com . 09.09.2014.
  2. ^ «Выпуск 1.30.3» . 17 июля 2024 г. Проверено 23 июля 2024 г.
  3. ^ «Репозиторий Kubernetes GitHub» . Гитхаб . 22 января 2021 г.
  4. ^ «кубернетес/кубернетес» . Гитхаб . Архивировано из оригинала 21 апреля 2017 г. Проверено 28 марта 2017 г.
  5. ^ Jump up to: а б «Что такое Кубернетес?» . Кубернетес . Проверено 31 марта 2017 г.
  6. ^ «Обзор Кубернетеса» . Кубернетес . Архивировано из оригинала 8 января 2023 г. Проверено 4 января 2022 г.
  7. ^ «Среды выполнения контейнеров» . Кубернетес . Проверено 14 ноября 2021 г.
  8. ^ «Облачные решения под ключ» . Документация Кубернетеса . Проверено 25 июля 2023 г.
  9. ^ «Ежегодный обзор CNCF 2022» . CNCF . 31 января 2023 г.
  10. ^ Jump up to: а б Мец, Кейд. «Google раскрывает свое секретное оружие в облачных вычислениях» . Проводной . Архивировано из оригинала 10 сентября 2015 года . Проверено 24 сентября 2015 г.
  11. ^ Мец, Кейд. «Google обнародовал свой секретный план по развитию своего облака» . Проводной . Архивировано из оригинала 1 июля 2016 г. Проверено 27 июня 2016 г.
  12. ^ Бернс, Брендан (20 июля 2018 г.), История Kubernetes и сообщества, стоящего за ним , заархивировано из оригинала 27 февраля 2022 г.
  13. ^ Kubernetes: Документальный фильм [ЧАСТЬ 1] , получено 14 декабря 2023 г.
  14. ^ «https://twitter.com/kelseyhightower/status/1527333243845873664» . X (ранее Twitter) . Проверено 14 декабря 2023 г. {{cite web}}: Внешняя ссылка в |title= ( помощь )
  15. ^ Jump up to: а б Абхишек Верма; Луис Педроса; Мадукар Р. Коруполу; Дэвид Оппенгеймер; Эрик Тьюн; Джон Уилкс (21–24 апреля 2015 г.). «Крупномасштабное управление кластерами в Google с помощью Borg» . Материалы Европейской конференции по компьютерным системам (EuroSys) . Архивировано из оригинала 27 июля 2017 г.
  16. ^ «Borg, Omega и Kubernetes — очередь ACM» . Queue.acm.org . Архивировано из оригинала 9 июля 2016 г. Проверено 27 июня 2016 г.
  17. ^ «Стартап Heptio на ранней стадии стремится сделать Kubernetes дружелюбным» . Проверено 6 декабря 2016 г.
  18. ^ «Поскольку Kubernetes выходит на версию 1.0, Google передает технологии недавно созданному Фонду облачных вычислений» . ТехКранч . 21 июля 2015 года. Архивировано из оригинала 23 сентября 2015 года . Проверено 24 сентября 2015 г.
  19. ^ «Фонд облачных вычислений» . Архивировано из оригинала 3 июля 2017 г.
  20. ^ «Red Hat и Google сотрудничают в Kubernetes для управления контейнерами Docker в большом масштабе» . 10 июля 2014 г. Проверено 6 августа 2022 г.
  21. ^ «VMware и Pivotal запускают Pivotal Container Service (PKS) и сотрудничают с Google Cloud, чтобы предоставить Kubernetes корпоративным клиентам» . 29 августа 2017 г. Проверено 6 августа 2022 г.
  22. ^ Лардинуа, Фредерик (06 сентября 2017 г.). «Mesphere добавляет поддержку Kubernetes в свою операционную систему центра обработки данных» . Проверено 6 августа 2022 г.
  23. ^ «Docker объявляет об усовершенствованиях платформы Docker, призванных упростить и усовершенствовать управление Kubernetes для корпоративных ИТ» . 17 октября 2017 г. Архивировано из оригинала 26 сентября 2020 г.
  24. ^ Монрой, Гейб (24 октября 2017 г.). «Представляем улучшения AKS (управляемый Kubernetes) и реестра контейнеров Azure» . Проверено 6 августа 2022 г.
  25. ^ «Представляем Amazon Elastic Container Service для Kubernetes (предварительная версия)» . 29.11.2017 . Проверено 6 августа 2022 г.
  26. ^ Конвей, Сара (6 марта 2018 г.). «Kubernetes — первый завершенный проект CNCF» . Фонд облачных вычислений . Архивировано из оригинала 29 октября 2018 года . Проверено 3 декабря 2018 г. По сравнению с 1,5 миллионами проектов на GitHub, Kubernetes занимает 9-е место по количеству коммитов и 2-е место по числу авторов/выпусков, уступая только Linux.
  27. ^ «Политика поддержки версий и неравномерности версий Kubernetes» . Кубернетес . Проверено 3 марта 2020 г.
  28. ^ Jump up to: а б «Объявление о выпуске Kubernetes 1.19 > Увеличьте период поддержки Kubernetes до одного года» . Кубернетес . 26 августа 2020 г. Проверено 28 августа 2020 г.
  29. ^ Шарма, Приянка (13 апреля 2017 г.). «Автомасштабирование на основе ЦП/памяти в Kubernetes — Часть II» . Технический блог Powerupcloud . Середина. Архивировано из оригинала 17 октября 2019 года . Проверено 27 декабря 2018 г.
  30. ^ «Настройка автомасштабирования Kubernetes с использованием пользовательских метрик» . Битнами . БитРок. 15 ноября 2018 года. Архивировано из оригинала 27 марта 2019 года . Проверено 27 декабря 2018 г.
  31. ^ Jump up to: а б с д и ж г час «Введение в Кубернетес» . Цифровой Океан . Архивировано из оригинала 1 октября 2015 года . Проверено 24 сентября 2015 г.
  32. ^ Jump up to: а б с «Инфраструктура Кубернетеса» . Документация сообщества OpenShift . Опеншифт. Архивировано из оригинала 6 июля 2015 года . Проверено 24 сентября 2015 г.
  33. ^ Jump up to: а б с д и «Руководство по усилению защиты Kubernetes» (PDF) . Министерство обороны США . Проверено 26 января 2024 г.
  34. ^ Контейнер Linux от CoreOS: Кластерная инфраструктура
  35. ^ Jump up to: а б Мархуби, Камаль (26 сентября 2015 г.). «Kubernetes с нуля: API-сервер» . kamalmarhubi.com. Архивировано из оригинала 29 октября 2015 г. Проверено 2 ноября 2015 г.
  36. ^ Эллингвуд, Джастин (2 мая 2018 г.). «Введение в Кубернетес» . Цифровой Океан . Архивировано из оригинала 5 июля 2018 года . Проверено 20 июля 2018 г. Одной из наиболее важных основных служб является сервер API. Это основная точка управления всем кластером, поскольку она позволяет пользователю настраивать рабочие нагрузки и организационные подразделения Kubernetes. Он также отвечает за согласованность данных хранилища etcd и сервисных данных развернутых контейнеров. Он действует как мост между различными компонентами для поддержания работоспособности кластера и распространения информации и команд.
  37. ^ Jump up to: а б «Развертывания» . Кубернетес . Проверено 27 февраля 2022 г.
  38. ^ «Три столпа оркестрации контейнеров Kubernetes — Rancher Labs» . rancher.com . 18 мая 2017 года. Архивировано из оригинала 24 июня 2017 года . Проверено 22 мая 2017 г.
  39. ^ «Структура планирования» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  40. ^ Jump up to: а б «Обзор контроллера репликации» . Документация . КореОС . Архивировано из оригинала 22 сентября 2015 г. Проверено 2 ноября 2015 г.
  41. ^ Сандерс, Джейк (2 октября 2015 г.). «Kubernetes: захватывающие экспериментальные возможности» . Ливвайер . Архивировано из оригинала 20 октября 2015 г. Проверено 2 ноября 2015 г.
  42. ^ Jump up to: а б «Введение: обучение Docker и Kubernetes — день 2» . Красная шляпа . 20 октября 2015 г. Архивировано из оригинала 29 октября 2015 г. Проверено 2 ноября 2015 г.
  43. ^ Мархуби, Камаль (27 августа 2015 г.). «Что [..] такое Кубелет?» . kamalmarhubi.com. Архивировано из оригинала 13 ноября 2015 г. Проверено 2 ноября 2015 г.
  44. ^ «Безопасность Kubernetes | Проблемы и лучшие практики | Snyk» . snyk.io . 26 июля 2020 г. Проверено 16 мая 2021 г.
  45. ^ Jump up to: а б «Представляем интерфейс времени выполнения контейнера (CRI) в Kubernetes» . Кубернетес . 19 декабря 2016 г. Проверено 16 мая 2021 г.
  46. ^ «Интерфейс времени выполнения контейнера (CRI)» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  47. ^ «Kubernetes v1.12: Представляем RuntimeClass» . kubernetes.io . 10 октября 2018 г.
  48. ^ «Устаревший Dockershim — репозиторий Kubernetes Github — PR 94624» . Гитхаб.com .
  49. ^ «Без паники: Kubernetes и Docker» . Блог Кубернетеса . 2 декабря 2020 г. Проверено 22 декабря 2020 г.
  50. ^ «кубернетес/сообщество» . Гитхаб . Проверено 16 мая 2021 г.
  51. ^ «Обновлено: Часто задаваемые вопросы по удалению Dockershim» . Блог Кубернетеса . 17 февраля 2022 г.
  52. ^ «rktnetes добавляет контейнерный движок rkt в Kubernetes» . kubernetes.io . 11 июля 2016 г.
  53. ^ «Пространства имен» . kubernetes.io .
  54. ^ «Косы» . kubernetes.io .
  55. ^ Jump up to: а б Лангемак, Джон (11 февраля 2015 г.). «Кубернетес 101 — Сеть» . Мигающий свет . Архивировано из оригинала 25 октября 2015 г. Проверено 2 ноября 2015 г.
  56. ^ Jump up to: а б «Набор реплик» . kubernetes.io . Проверено 3 марта 2020 г.
  57. ^ «Наборы состояний» . kubernetes.io .
  58. ^ «ДемонСет» . kubernetes.io .
  59. ^ "Услуга" . kubernetes.io .
  60. ^ Лангемак, Джон (15 февраля 2015 г.). «Kubernetes 101 — внешний доступ в кластер» . Das Blinken Lichten . Архивировано из оригинала 26 октября 2015 г. Проверено 2 ноября 2015 г.
  61. ^ «Объемы» . kubernetes.io .
  62. ^ «Конфигурационные карты» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  63. ^ «Секреты» . Кубернетес . Проверено 23 июля 2023 г.
  64. ^ «Хранилище, прикрепленное к контейнеру: введение» . Фонд облачных вычислений . 19 апреля 2018 г. Проверено 16 мая 2021 г.
  65. ^ «Dataore приобрела MayaData, оригинального разработчика OpenEBS» . datacore.com . 18 ноября 2021 г.
  66. ^ «ОБЗОР CNCF 2019» (PDF) . cncf.io. ​
  67. ^ «Хранилище, прикрепленное к контейнеру: введение» . Фонд облачных вычислений . 19 апреля 2018 г. Проверено 9 октября 2020 г.
  68. ^ «Контейнерное хранилище | SNIA» . www.snia.org . Проверено 9 октября 2020 г.
  69. ^ «Контрольный список приложений Cloud Native: Cloud Native Storage» . www.replex.io . Проверено 9 октября 2020 г.
  70. ^ «Представляем альфа-интерфейс хранилища контейнеров (CSI) для Kubernetes» . kubernetes.io . 10 января 2018 г.
  71. ^ «Интерфейс хранилища контейнеров (CSI) для Kubernetes GA» . kubernetes.io . 15 января 2019 г.
  72. ^ Маринеску, Дэн К. (01 января 2018 г.), Маринеску, Дэн К. (ред.), «Глава 8 — Облачное оборудование и программное обеспечение» , Cloud Computing (второе издание) , Морган Кауфманн, стр. 281–319, doi : 10.1016/b978-0-12-812810-7.00011-x , ISBN  978-0-12-812810-7 , получено 8 ноября 2023 г.
  73. ^ «Работа с кластерами etcd для Kubernetes» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  74. ^ «Объекты в Kubernetes» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  75. ^ «Конвенции API» . Гитхаб . Кубернетес . Проверено 24 июля 2023 г.
  76. ^ «Собственники и иждивенцы» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  77. ^ «Сбор мусора» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  78. ^ «Пользовательские ресурсы» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  79. ^ «Облачный родной пейзаж» . Фонд облачных вычислений . Проверено 24 июля 2023 г.
  80. ^ «Контроль доступа к API Kubernetes» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  81. ^ «Удалить небезопасный порт apiserver · Проблема № 91506 · kubernetes/kubernetes» . Гитхаб .
  82. ^ «Авторизация» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  83. ^ «Организация доступа к кластеру с помощью файлов kubeconfig» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  84. ^ «Обзор авторизации» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  85. ^ «Инструмент командной строки (kubectl)» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  86. ^ «Клиентские библиотеки» . Документация Кубернетеса . Проверено 24 июля 2023 г.
  87. ^ «Введение — Книга по кластерному API» . кластер-api.sigs.k8s.io .
  88. ^ «7 самых популярных дистрибутивов Kubernetes» . Проверено 28 декабря 2021 г.
  89. ^ МСВ, Джанакирам. «Почему экосистеме разработчиков Kubernetes нужен PaaS» . Форбс . Проверено 16 мая 2021 г.
  90. ^ «5 облачных тенденций, на которые следует обратить внимание в 2022 году» . Новый стек . 03.01.2022 . Проверено 3 февраля 2022 г.
  91. ^ Jump up to: а б «Выпуски исправлений Kubernetes» . Гитхаб . 4 мая 2022 г. Проверено 9 мая 2022 г.
  92. ^ «Повышение производительности Kubernetes 1.1, улучшенные инструменты и растущее сообщество» . kubernetes.io . 9 ноября 2015 г.
  93. ^ «Kubernetes 1.2: еще больше повышения производительности, а также упрощение развертывания приложений и управления ими» . kubernetes.io . 17 марта 2016 г.
  94. ^ «Kubernetes 1.3: объединение облачных и корпоративных рабочих нагрузок» . kubernetes.io . 6 июля 2016 г.
  95. ^ «Kubernetes 1.4: упрощаем запуск Kubernetes где угодно» . kubernetes.io . 26 сентября 2016 г.
  96. ^ «Kubernetes 1.5: Поддержка производственных рабочих нагрузок» . kubernetes.io . 13 декабря 2016 г.
  97. ^ «Kubernetes 1.6: многопользовательская работа с несколькими рабочими нагрузками в масштабе» . kubernetes.io . 28 марта 2017 г.
  98. ^ «Kubernetes 1.7: усиление безопасности, обновления приложений с отслеживанием состояния и расширяемость» . kubernetes.io . 30 июня 2017 г.
  99. ^ «Kubernetes 1.8: безопасность, рабочие нагрузки и глубина функций» . kubernetes.io . 29 сентября 2017 г.
  100. ^ «Kubernetes 1.9: общедоступные рабочие нагрузки приложений и расширенная экосистема» . kubernetes.io . 15 декабря 2017 г.
  101. ^ «Kubernetes 1.10: стабилизация хранилища, безопасности и сети» . kubernetes.io . 26 марта 2018 г.
  102. ^ «Kubernetes 1.11: балансировка нагрузки внутри кластера и плагин CoreDNS переходят в общедоступную версию» . kubernetes.io . 27 июня 2018 г.
  103. ^ «Kubernetes 1.12: Kubelet TLS Bootstrap и масштабируемые наборы виртуальных машин Azure (VMSS) переходят в общедоступную версию» . kubernetes.io . 27 сентября 2018 г.
  104. ^ «Kubernetes 1.13: упрощенное управление кластером с помощью Kubeadm, интерфейса хранилища контейнеров (CSI) и CoreDNS в качестве DNS по умолчанию теперь общедоступно» . kubernetes.io . 3 декабря 2018 г.
  105. ^ «Kubernetes 1.14: поддержка узлов Windows на производственном уровне, обновления Kubectl, постоянные локальные тома GA» . kubernetes.io . 25 марта 2019 г.
  106. ^ «Kubernetes 1.15: расширяемость и постоянное улучшение» . kubernetes.io . 19 июня 2019 г.
  107. ^ «Kubernetes 1.16: пользовательские ресурсы, обновленные метрики и расширения томов» . kubernetes.io . 18 сентября 2019 г.
  108. ^ «Кубернетес 1.17: Стабильность» . kubernetes.io . 9 декабря 2019 г.
  109. ^ «Kubernetes 1.18: настройка и завершение» . kubernetes.io . 25 марта 2020 г.
  110. ^ «Объявление о выпуске Kubernetes 1.19» . Кубернетес . 26 августа 2020 г. Проверено 28 августа 2020 г.
  111. ^ «Kubernetes 1.19: Акцентируйте внимание на лапах» . Кубернетес . 26 августа 2020 г. Проверено 13 января 2024 г.
  112. ^ «Kubernetes 1.20: Самый крутой релиз» . kubernetes.io . 8 декабря 2020 г.
  113. ^ «Kubernetes 1.21: Сила сообществу» . kubernetes.io . 8 апреля 2021 г.
  114. ^ «Kubernetes 1.22: Достижение новых вершин» . kubernetes.io . 4 августа 2021 г.
  115. ^ «Kubernetes 1.23: следующий рубеж» . kubernetes.io . 7 декабря 2021 г.
  116. ^ «Kubernetes 1.24: Звездочёт» . kubernetes.io . 3 мая 2022 г.
  117. ^ «Kubernetes v1.25: Объединитель» . kubernetes.io . 23 августа 2022 г.
  118. ^ «Kubernetes v1.26: Электрификация» . kubernetes.io . 9 декабря 2022 г.
  119. ^ «Kubernetes v1.27: прохладная атмосфера» . kubernetes.io . 11 апреля 2023 г.
  120. ^ «Kubernetes v1.28: Плантернетес» . kubernetes.io . 15 августа 2023 г.
  121. ^ «Kubernetes v1.29: Мандала» . kubernetes.io . 13 декабря 2023 г.
  122. ^ «Kubernetes v1.30: Uwubernetes» . kubernetes.io . 17 апреля 2024 г.
[ редактировать ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Kubernetes&oldid=1237735946"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 0f28acb5f39a6d79215a1c0b91c60799__1722397860
URL1:https://arc.ask3.ru/arc/aa/0f/99/0f28acb5f39a6d79215a1c0b91c60799.html
Заголовок, (Title) документа по адресу, URL1:
Kubernetes - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)