Введение в Кубебенты: какие проблемы это решает?

Обложка изображения по Manuel Nägeli. на Бессмысленно

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

Давайте представим, что мы знаем, что мы знаем, что используйте машину времени и вернитесь во время 2000-х годов (чтобы помочь вам с этим, постарайтесь напомнить, какую музыкальную группу вы слушали тогда или какую одежду вы носили). Мы работаем в большой компании, в отделе разработки программного обеспечения. И у нас есть новая блестящая идея для приложения.

Так что же нам делать? Можем ли мы сразу начать кодирование, запустить приложение и показать его потенциальным пользователям? Это зависит от проекта, но, вероятно, нет. Но почему?

Это будет зависеть от компании, но в целом это не было тривиальной задачей. В основном потому, что в крупных организациях инфраструктура программного обеспечения/аппаратного обеспечения была либо не очень хорошо организована, либо в процессе запрашивания программных инструментов, серверов, баз данных и т. Д. Была так долго, что он блокирует новые проекты прямо с самого начала. Команды разработки вместо того, чтобы сосредоточиться на доставке бизнес-значений с первого дня, были вынуждены первым ответом на такие вопросы, как: Где и как запустить базу данных?, Как развернуть приложение на сервере? Как настроить сетевой трафик? и так далее. Выяснение, это может занять месяцы ожидания команд инфраструктуры для ее решения.

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

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

Другими словами, Amazon Пытался найти способ запуска и развертывания приложений за очень короткое время.

И вот как Amazon Web Services (AWS) был рожден. Сначала это был как внутренний инструмент, но В августе 2006 года они решили сделать его публичным , что делает его первым Инфраструктура как услуга оказание услуг.

После этого другие компании также начали создавать свои собственные облака, как Microsoft Azure , Google Cloud , IBM Облако , Оракул облако , Облако Alibaba , Red Hat Openshift Online Отказ Также появились новые, меньшие компании, как Heroku или Цифровой океан Отказ Но никто из них не так, пока не имеет такой большой доли рынка, как AWS имеет.

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

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

Так что здесь мы наконец добрались до двух основных проблем, которые у нас есть:

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

Чтобы спешить, в течение многих лет два основных концепция начали получать тяги — распределенные системы ( микросервисы ) и контейнеров (с Docker в частности).

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

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

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

Но перед погружением в него позвольте мне только что сказали, что Кубернаны не единственный, так называемый Инструмент для оркестрации контейнера . Есть другие, такие как Докер Рой , Apache Mesos. или Ранчо Отказ Некоторое время назад он не был уверен, какой из них появится в качестве технологии лидера, но сегодня мы можем сказать, что Кубернаны стать де-факто стандартный Это становится даже частью Облачный родной вычислительный фонд — Организация, которая помогает установить стандартную инструмент для программного обеспечения, используемого в облаке.

Рождение Кубератесов

Кубернаны был создан на Google в 2014. Нет фактической даты создания этого проекта, но обычно он передается Первый коммит на Github Отказ

С самого начала он был разработан как проект с открытым исходным кодом, который перекрывает функциональность Googles ‘ Внутренний инструмент под названием Борг . Как Кубернеты , Borg был создан для управления (оркестровыми) контейнерными приложениями во время, когда контейнеры еще не имели столько тяги или Докер не было даже там. Давайте столкнемся в этом, Google является одной из крупнейших компаний, с огромным движением и необходимым иметь умный способ управлять огромным количеством приложений.

На основании этого опыта пара Google Developers решила создать новый инструмент с открытым исходным кодом, который будет делать аналогичную работу, но в лучшую, более свежий путь.

Как это работает?

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

Чтобы сделать его более понятным, давайте рассмотрим следующий сценарий.

Вы хотели бы создать свой собственный Кубернаны кластер. В вашем подвале вы нашли 3, старые стажировки:

Raspberry Pi (ЦП: 1 ГБ, ОЗУ: 100 МБ),
Старый ноутбук (ЦП: 2 ГБ, ОЗУ: 200 МБ),
и «древний» сервер (процессор: 3 ГБ, ОЗУ: 300 МБ)

Примечание. Пожалуйста, не обращайте внимания на определенные значения CPU & RAMS, это только для целей презентации 😉.

Как только вы получили их и запустите, вы можете установить и настроить * Kubernetes, * так в результате вы должны иметь аппаратную инфраструктуру, которая имеет 3 узла (узел, является отдельной машиной, которая может быть физической или виртуальной).

Теперь, если вы хотите развернуть приложение к этому кластеру, вам не нужно думать, на каком машине ее следует установить, потому что K8s (более короткая форма для Kubernetes ) позаботится об этом. Для того, чтобы общаться с Кубернаны Вы можете использовать либо Инструмент командной строки, kubectl или HTTP API Отказ

И еще одна прохладная вещь состоит в том, что все ресурсы всех узлов внутри кластера могут рассматриваться как пул, сумма всех базовых узлов.

Архитектура Куберанес

Глядя внутрь Кубернаны С точки зрения архитектуры мы можем увидеть две основные части: Управляющий самолет и Рабочие узлы Отказ

Источник: kubernetes.io

Первый ответственность за управление всей кластером и последним несет ответственность за приложения для хостинга (контейнеров).

Управляющий самолет Решит, на каком уземе рабочего узла запускают каждый контейнер, проверяет состояние здоровья кластера, обеспечивает API для связи с кластером и многое другое. Если один из узлов будет спущен, и если некоторые контейнеры работали на этой сломанной машине, он * * будет позаботиться о переизложении этих приложений на других узлах.

Внутри самолета управления мы можем найти несколько, меньших компонентов:

Kube-API-сервер — Он несет ответственность за предоставление API к кластеру, он обеспечивает конечные точки, подтверждает запросы и делегирует их на другие компоненты,
Kube-планировщик — постоянно проверяет, есть ли новые приложения ( Стручки , быть конкретным, самые маленькие объекты в K8S, представляющие приложения) и назначают их узлам,
Kube-Controller-Manager — содержит кучу Контроллеры , которые наблюдают за состоянием кластера, проверяют, является ли государство желания такое же, как текущее состояние, и если нет, они общаются с Kube-API-сервер изменить его; Этот процесс называется петлем управления, и это касается нескольких Кубернаны объекты (как узлы, реплики стручка и многое другое); для каждого K8s объект есть один контроллер, который управляет своим жизненным циклом,
etcd — Это надежная база данных магазина клавиш, которая хранит данные конфигурации для всего кластера,
Менеджер контроллера облака — Удерживает контроллеры, которые специфики для облачных провайдеров, это доступно только тогда, когда вы используете хотя бы одну облачную службу в кластере.

Также другой компонент, который не упоминается на приведенной выше картинке, но очень важно, это Днс . Он позволяет приложениям внутри кластера, чтобы иметь возможность взаимодействовать с каждым конкретным (читаемым человеком) именами, а не IP-адресами.

Помимо Управляющий самолет каждый Кластер Kubernetes * может иметь один или несколько * Узелки работоспособности на какое приложение работает. Интегрировать их с K8S, каждый из них имеет:

Кублет — отвечает за управление Стручки Внутри узла и общение с плоскостью управления (оба компонента друг с другом, когда необходимо изменять состояние кластера),
Kube-Proxy — Берегите сеть внутри кластера, внесите конкретные правила и т. Д.

Кубернаные предметы

В предыдущем разделе я упомянул что-то называемое Кубернаны объекта Так что давайте быстро посмотрим на то, что они.

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

Есть несколько типов объектов, но я хочу упомянуть только пару из них, которые являются наиболее важными:

Стручки — как упоминалось ранее, Стручки самые маленькие Кубернаны Объекты, представляющие собой приложение. То, что стоит упомянуть, Стручки не контейнеры. Они обертки для одного или нескольких контейнеров, которые содержат не только рабочее приложение, но и некоторые метаданные.
Развертывание — несут ответственность за жизненный цикл Подвигание . Они заботятся о создании Стручки С Обновление и масштабирование их.
Услуги — позаботься о сетевых задачах, общение между Стручки внутри кластера. Причина этого, потому что Стручок Жизнь очень коротка. Они могут быть созданы и убиты за очень короткое время. И каждый раз, когда IP-адрес может измениться таким образом, чтобы другие Стручки Внутри кластера необходимо постоянно обновлять адреса всех зависенных приложений (открытие услуг). Более того, может быть случай, который находятся более одной экземпляры того же приложения внутри кластера — Услуги Берегите нагрузку, балансируя трафик между тем Стручки Отказ
Вход — Похоже на услуги, вход несет ответственность за сеть, но на другом уровне. Это ворота к кластеру, чтобы кто-то/что-то из внешнего мира может ввести его на основе правил, определенных в Контроллер входа Отказ
Постоянные тома — обеспечить абстрактный способ хранения данных, которые могут потребоваться по Стручки (например, чтобы сохранить некоторые данные постоянно или в кэше).
Configmaps — Они содержат данные ключа, которые могут быть введены в PODS, например, в качестве переменной среды, которая позволяет отделить приложение из его конфигурации.

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

Другие особенности Kubernetes

Я надеюсь, что теперь вы понимаете первичную проблему, что Кубернаны пытается решить. Но это не все, есть больше аспектов программного обеспечения, которую она обращается.

Масштабируемость

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

Это одно из облако фундаментальной концепции, которая в зависимости от того, насколько занят приложение (сколько требует процессора) K8s мог бы решить запустить дополнительные экземпляры того же Стручок предотвратить низкие задержки или даже раздавить.

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

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

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

Высокая доступность

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

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

К счастью Кубернаны имеет механизм, чтобы справиться с такой ситуацией. Например, если приложение ( POD ) раздавит, он попытается автоматически воссоздать его. Или если узел уходит вниз, он автоматически назначает все Стручки которые работают на измельченном узле к новой.

Мониторинг и наблюдаемость

Как было упомянуто до Кубернаны Имеет возможность автонастроительного количества экземпляров приложений на основе использования CPU. Он собирает метрики из каждого приложения о использовании ресурсов через Метрики API Так что это может решить, когда увеличивать/уменьшить количество стручков. Также он может обеспечить информацию о потреблении текущей на приборной панели.

Minikube Dashboard для процессора и использования памяти для всего кластера

По умолчанию Кубернаны Обеспечивает Metrics Server Для предоставления таких метрик, но его можно заменить на заказ. Самый популярный — Прометей .

Другая проблема распределенных систем заключается в том, что ей очень трудно отслеживать полный процесс процесса между несколькими приложениями. В монолитных приложениях довольно просто, есть одно место, где можно проверить журналы процессов, но в подходе Micreervice вам нужно будет проверить каждое приложение индивидуально.

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

Метрики — они дают информацию о состоянии здоровья (частично упомянутым в начале этого раздела),
журналы — представляют описательное событие (обычно в полном тексте) внутри приложения, записанного на стандартный выход; Все журналы каждого приложения могут быть агрегированы до одного места с использованием E.G. Упругий стек — Elasticsearch, Kibana, Beats и logstash С
следы — Чтобы объединить несколько событий/операций по нескольким компонентам, поэтому один след представляет все связи между всеми компонентами (баз данных, HTTP-запросы и т. Д.); Популярный инструмент, используемый для трассировки, это Jaeger Отказ

Различные виды развертывания

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

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

В Кубернеты Это очень легко преодолеть это путем достижения Развертывание нулевого простоя . И это сделано, следуя Синий/зеленый шаблон развертывания Отказ

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

Но есть больше. K8s Позволяет иметь более сложные типы развертываний, таких как Канарское развертывание или A/B Тестирование Отказ В обоих из них две версии сервиса развернуты наряду.

В первом одном трафике направляется только к очень небольшому проценту пользователей, а затем неуклонно увеличивается, если нет проблем.

В A/B Тестирование Мы хотим иметь две разные версии приложения в течение всего времени, чтобы мы могли сравнить, какой из них лучше выполняет (имеет более крупный пользовательский трафик, в котором один пользователь тратит больше денег и т. Д.).

Распределение кубернанов

Если вы или компания решит дать Кубернаны Попробуйте вы можете в конечном итоге с проблемой — как запустить его? Теоретически можно Клон Это исходный код , компилируйте и запустите его, но это требует столько усилий времени и опыта, чтобы вы, вероятно, решите, что K8s не для вас.

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

Миникуба , Кубернаны в Docker Desktop или Minishift обычно используются для местного развития,
K3s или Microk8s Легкие добычи производства, готовые распределения,
Каноническое распределение Кубератесов , ОКД или Openshift тяжелые оружия, производство готово к куберененам,
Amazon Eks , Google Kubernetes Engine и Azure Kubernetes Service доступны только на определенной облачной службе.

K8S не серебряная пуля!

До сих пор я пытался убедить вас Почему Кубернаны отлично, но теперь давайте сделаем обратное. Почему Кубернаны плохо?

Прежде всего, мы должны понять, что как каждый инструмент K8s был разработан для решения задач определенного типа. Да, в наше время это очень популярно, и да, многие компании либо мигрируют на него, либо начинают новые проекты, но не принимаются этим. Это не серебряная пуля.

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

Кроме того, это может увеличить общую сложность инфраструктуры, особенно в начале, когда проект относительно небольшой. Многие вещи могут быть сделаны проще (например, выполнение всех приложений на одном Tomcat Server). И если нет плана запускать множество микросервисов, может быть, просто иметь пару более крупных приложений, это также может быть ненужно использовать этот инструмент.

И, наконец, множество файлов YAML 😜 Это шутка, но я знаю, что некоторые люди не любят факт, что Кубернаны Требуется создать лоты и много файла YAML. Чтобы смягчить эту проблему, есть такие инструменты Хелм или ранее упомянул Кубернаны Оператор шаблон.

Новое светлое будущее

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

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

Еще один момент в том, что благодаря расширяемости Кубернаны (Пользовательские ресурсы) Это позволяет строить все экосистемы на его вершине. Пример этого был бы Кнативы — Инициатива по стандартизации Смертный фреймворк. Также Tekton Создается поверх этого, что является облачным нативным CI/CD-инструментом.

Кроме того, сообщество работает над новыми типами K8s Распределения, которые будут настроены для разных целей, такие как IOT (легкая версия, установленная на краевых устройствах) или машинного обучения. Для последнего, уже есть инструмент под названием Kubeflow Отказ

И наконец Кубернаны Имеет большое влияние на разработку программного обеспечения. Например, в Java Ecosystem новый тип виртуальной машины — Граальвм — что делает запуск времени приложения в кратчайшие сроки (это специально решающее значение в стержневой нагрузке). В результате * Graalvm * новые рамки появились как Quarkus С Микронаут или есть обновления для в настоящее время широко используются как Весна Отказ

Заключение

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

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

Оригинал: «https://dev.to/wkrzywiec/introduction-to-kubernetes-what-problems-does-it-solve-4n3d»