По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Kubernetes и Red Hat OpenShift сегодня являются двумя ведущими инструментами оркестрации контейнеров на рынке. В этой статье мы обсудим эти инструменты и различия между ними.
Большинство производственных сред начали использовать контейнеры, поскольку они легко масштабируемы, экономичны, лучше, чем виртуальные машины, и быстрее развертываются. Конечно, проще работать с 10-20 контейнерами, но представьте, если ваша производственная среда кластера Kubernetes имеет сотни контейнеров. Управление жизненным циклом контейнера с параллельным запуском нескольких контейнеров становится сложной задачей. Поэтому для управления всем автоматизированным развертыванием, масштабированием, организацией и управлением контейнерами необходима платформа/инструмент для управления контейнерами.
Сравнение Kubernetes с OpenShift было бы несправедливым, поскольку эти инструменты оркестровки контейнеров представляют собой два разных проекта. Kubernetes - проект с открытым исходным кодом, в то время как OpenShift - продукт предлагаемый Red Hat. Сравнивать Kubernetes с OpenShift - все равно что сравнивать двигатель автомобиля с автомобилем. Это связано с тем, что сам Kubernetes является основной частью общей архитектуры OpenShift.
Сначала кратко разберемся, что такое Kubernetes и OpenShift.
Что такое Kubernetes?
В настоящее время Kubernetes является наиболее популярным инструментом оркестровки контейнеров с открытым исходным кодом и широко используется для автоматического развертывания и масштабирования контейнеров. Этот инструмент с открытым исходным кодом был создан в 2014 году компанией Google и разработан облачным вычислительным фондом с использованием языка программирования Go.
Kubernetes имеет архитектуру master-slave, в кластере Kubernetes есть главный узел и множество рабочих узлов. Внутри каждого рабочего узла будет работать несколько деталей, которые представляют собой не что иное, как группу контейнеров, объединенных как рабочая единица. Kubernetes использует YAML для определения ресурсов, отправляемых на сервер API для создания самого приложения.
Преимущества Kubernetes
Поскольку Kubernetes имеет открытый исходный код, он может свободно использоваться для любой платформы
Имеет огромное активное сообщество разработчиков и инженеров, что помогает непрерывно разрабатывать новые функции
Для избегания простоев вы можете легко выполнить откат или новое развертывание
Для распределения сетевого трафика он предлагает возможности балансировки нагрузки
Он поддерживает различные языки и структуры программирования, что обеспечивает гибкость для разработчиков и администраторов
Kubernetes помогает очень эффективно использовать ресурсы инфраструктуры и сокращать общие затраты
Она поставляется с панелью мониторинга по умолчанию, которая предлагает кучу информации, достаточной, чтобы следить за состоянием кластера.
Red Hat OpenShift
OpenShift - контейнерная платформа корпоративного уровня, разработанная Red Hat. Написан на языках программирования Go и AngularJS, а первоначальный релиз вышел в 2011 году. Red Hat OpenShift можно использовать как для облачных, так и для традиционных приложений.
За кулисами Red Hat OpenShift работает Kubernetes, что позволяет запускать приложения внутри контейнеров. OpenShift поставляется с панелью веб-интерфейса и CLI, которая помогает разработчикам и программистам создавать свои коды приложений. Это также позволяет инженерам DevOps управлять и контролировать кластер Kubernetes.
Преимущества Red Hat OpenShift:
Поддерживает инициативу открытых контейнеров (OCI - open container initiative) для размещения контейнеров и среды выполнения
Содержит множество исправлений проблем безопасности, дефектов и производительности
Может быстро и гибко создавать и развертывать приложения
Легко интегрировать со многими другими инструментами DevOps
Проверяет несколько подключаемых модулей сторонних производителей для каждой версии
Использование унифицированной консоли на Red Hat позволяет быстро внедрять и применять политики
Поддерживает Prometheus и Grafana, что помогает в мониторинге кластера
Его можно легко использовать с любым поставщиком облачных технологий или в локальной среде.
OpenShift против Kubernetes
1. Открытый исходный код по сравнению с коммерческим
Наиболее фундаментальное отличие Kubernetes от OpenShift заключается в том, что Kubernetes - проект с открытым исходным кодом, а OpenShift - коммерческий продукт корпоративного уровня. Это означает, что Kubernetes является самоподдерживаемым инструментом. В случае, если в этом инструменте выявлена какая-либо проблема или ошибка, люди обращаются к сообществу Kubernetes, которое состоит из многих разработчиков, администраторов, архитекторов и т. д.
В то время как в OpenShift вы получаете хороший платный вариант поддержки для устранения любой проблемы с этой подпиской на продукт Red Hat. Подписка OpenShift позволяет управлять общедоступной, частной и виртуальной инфраструктурой с помощью Red Hat CloudForms.
2. Развертывание
Развертывание приложения в производственной среде является решающим этапом процесса DevOps, и OpenShift делает его очень простым. Он автоматически выполняет каждый шаг от разработки до развертывания, поэтому вам не нужно беспокоиться о каждом шаге в конвейере CI/CD, чтобы сделать все вручную. Даже будучи новичком, вы будете чувствовать себя очень комфортно, используя OpenShift при конвеерном развертывания приложений. В OpenShift развертывание выполняется с помощью команды DeploymentConfig.
С другой стороны, развертывание в Kubernetes сложнее и часто выполняется только экспертом. Необходимо настроить каждый шаг конвейера для развертывания приложения вручную. В случае развертывания приложений в Kubernetes используются объекты развертывания и могут обрабатывать несколько параллельных обновлений.
3. Управление
В Kubernetes можно управлять кластером с помощью панели мониторинга по умолчанию. Но из-за его ограниченных возможностей и базового пользовательского интерфейса, по мере роста размера кластера, чтобы легко управлять кластером вам придется добавить более расширенные инструменты, такие как Istio, Prometheus, Grafana.
Red Hat OpenShift предоставляет удобную панель управления кластером. Веб-консоль OpenShift предоставляет возможности для выполнения некоторых расширенных операций в кластере для улучшения управления. OpenShift также предлагает интегрировать кластер со стеком EFK и Istio. И, наконец, доступные в OpenShift плейбуки Ansible и установщик помогают плавно управлять кластером.
4. Масштабируемость
Независимо от того, является ли кластер виртуализированным или он развернут на голом железе, в нем будет несколько виртуальных машин. В Kubernetes добавление виртуальных машин занимает много времени. Он требует от разработчиков создания для него сценариев YAML.
Тогда как в OpenShift масштабирование выполняется без особых усилий. OpenShift позволяет быстрее выводить виртуальные машины в кластер с помощью доступных установщиков и плейбуков Ansible. Кроме того, процесс масштабирования в OpenShift тоже прост.
5. Гибкость
Kubernetes поставляется с большой гибкостью, так как нет фиксированного способа работы с ним. Для запуска Kubernetes можно использовать любую операционную систему с большими ограничениями. Kubernetes помогла многим организациям выйти из устаревших архитектур, поскольку они не отвечали текущим потребностям рынка.
При работе с OpenShift нельзя использовать все операционные системы. В OpenShift можно использовать только дистрибутивы Red Hat, FedoraOS и CentOS.
6. Безопасность
Политики безопасности в OpenShift строже по сравнению с Kubernetes. Например, OpenShift не позволяет запускать контейнеры как корневые. Это также ограничивает использование пользователями многих официальных образов, представленных на DockerHub. Итак, во время работы с OpenShift сначала нужно будет узнать о его политиках безопасности. Но из-за этих ограничений, возможности аутентификации и авторизации в OpenShift более надежны, чем Kubernetes.
В то время как в Kubernetes настройка надлежащей возможности аутентификации и авторизации потребует много усилий. В отличие от OpenShift, кластеры Kubernetes могут иметь много уязвимых образов, если в кластер не интегрированы средства сканирования контейнеров. Kubernetes предлагает функции управления доступом на основе ролей (RBAC - role-based access control), но этого недостаточно для расширенного уровня безопасности, необходимого в производственных средах. Так, по сравнению с OpenShift, в Kubernetes ещё предстоит сделать много улучшений в плане безопасности.
7. Веб-интерфейс
Для выполнения всей работы по администрированию кластера необходим подходящий и простой в использовании веб-интерфейс, что и предлагает OpenShift. У него есть простая форма аутентификации для каждого пользователя. После входа пользователь получает полную визуализацию кластера, которую очень легко прочитать и понять. OpenShift имеет удобную веб-консоль, которая позволяет инженерам DevOps выполнять задачи Kubernetes, а операционным группам - комфортно контролировать приложение. Элемент управления имеет несколько возможностей типа построения, развертывания, обновления, масштабирования, раскрытия и т.д., которые могут быть реализованы одним нажатием кнопки.
Kubernetes поставляется с базовой панелью управления, которая может помочь только с основными задачами. Кроме того, панель мониторинга не очень удобна для пользователей по сравнению с другими панелями мониторинга, доступными на рынке. Именно поэтому инженеры DevOps предпочли бы интегрировать инструментальную панель Kubernetes по умолчанию с другими инструментами визуализации, такими как Prometheus и Grafana.
Подводя итог, приведем таблицу различий между Red Hat OpenShift и Kubernetes:
ОтличияKubernetesOpenShiftРазработчикCloud-Native Computing FoundationRed Hat SoftwareДата первого релиза7 июня 20144 мая 2011Язык программированияGoGo, Angular, JSУправлениеСложное управления контейнерамиИспользование ImageStreams для упрощения управления несколькими контейнерамиРазвертываниеПоддерживает все облачные и Linux платформыПоддерживает только дистрибутивы на базе RedHat: CentOS и FedoraГибкостьС открытым исходным кодом, соответственно гибкийОграниченная гибкостьБезопасностьМожно легко управлять уровнем безопасностиСтрогие политики безопасностиСетевая поддержкаЕму не хватает хорошего сетевого решения, но он позволяет добавлять сетевые плагины сторонних производителей.Поставляется с собственным сетевым решениемОбучениеСложен для начинающих, больше подходит для профессиональных DevOpsПодходит для начинающих
Заключение
Все дело было в Kubernetes, OpenShift и их различиях. Обе платформы оркестрации контейнеров востребованы в ИТ-отрасли. Таким образом, в зависимости от ваших требований, вы можете выбрать наиболее подходящую платформу оркестрации контейнеров для вашей организации.
Если вам нужна гибкость с вашими проектами, то скорее всего должны выбрать Kubernetes. Но если вы можете следовать определенному подходу и хотите использовать платформу оркестрации контейнеров с простотой развертывания и управления, OpenShift - лучший выбор. Так же если вы уже опытный DevOps и хотите попробовать что-то новое, то можно попытаться перейти на Kubernetes. Если же делаете первые шаги на поприще DevOps, выберите OpenShift, так как он сделает большую часть дел за вас.
VirtualBox - это кроссплатформенное программное обеспечение для виртуализации с открытым исходным кодом, которое может быть установлено в любой операционной системе и позволяет устанавливать и запускать несколько гостевых операционных систем на одном компьютере.
Например, если вы установите его в своей системе Linux, вы можете запустить операционную систему Windows XP в качестве гостевой ОС или запустить ОС Linux в вашей системе Windows и так далее. Таким образом, вы можете установить и запустить столько гостевых операционных систем, сколько вам нужно, единственным ограничением является дисковое пространство и память.
Недавно Oracle выпустила последнюю стабильную версию Virtualbox 6.0.0,и новейшая версия Virtual Box включает в себя много значительных изменений и новые функции.
Про Linux за 5 минут?
Перед началом, советуем почитать материал про плоскость управления.
Топология - это набор связей (или ребер) и узлов, которые описывают всю сеть. Обычно топология описывается и рисуется как граф, но она также может быть представлена в структуре данных, предназначенной для использования машинами, или в дереве, которое обычно предназначено для использования людьми.
Топологическую информацию можно обобщить, просто сделав так, чтобы пункты назначения, которые физически (или виртуально) соединены на расстоянии нескольких прыжков, казались непосредственно присоединенными к локальному узлу, а затем удалив информацию о связях и узлах в любой маршрутной информации, переносимой в плоскости управления, с точки суммирования. Рисунок 4 иллюстрирует эту концепцию.
Изучение топологии
Казалось бы, достаточно просто узнать о топологии сети: изучить подключенные каналы передачи данных. Однако то, что кажется простым в сетях, часто оказывается сложным. Изучение локального интерфейса может рассказать вам о канале, но не о других сетевых устройствах, подключенных к этому каналу. Кроме того, даже если вы можете обнаружить другое сетевое устройство, работающее с той же плоскостью управления по определенному каналу, это не означает, что другое устройство может вас обнаружить. Таким образом, необходимо изучить несколько вопросов.
Обнаружение других сетевых устройств
Если маршрутизаторы A, B и C подключены к одному каналу, как показано на рисунке 5, какие механизмы они могут использовать для обнаружения друг друга, а также для обмена информацией о своих возможностях?
Первое, что следует отметить в отношении сети, показанной в левой части рисунка 5, - это то, что интерфейсы не соответствуют соседям. Фактические отношения соседей показаны в правой части рисунка 5. У каждого маршрутизатора в этой сети есть два соседа, но только один интерфейс. Это показывает, что плоскость управления не может использовать информацию об интерфейсе для обнаружения соседей. Должен быть какой-то другой механизм, который плоскость управления может использовать для поиска соседей.
Ручная настройка - одно из широко распространенных решений этой проблемы. В частности, в плоскостях управления, предназначенных для перекрытия другой плоскости управления, или плоскостях управления, предназначенных для построения отношений соседства через несколько маршрутизируемых переходов по сети, ручная настройка часто является самым простым доступным механизмом. С точки зрения сложности, ручная настройка очень мало добавляет к самому протоколу. Например, нет необходимости в какой-либо форме многоадресного объявления соседей. С другой стороны, ручная настройка соседей требует настройки информации о соседях, что увеличивает сложность с точки зрения конфигурации. В сети, показанной на рисунке 5, маршрутизатор A должен иметь отношения соседства, настроенные с помощью B и C, маршрутизатор B должен иметь отношения соседства, настроенные с помощью A и C, а маршрутизатор C должен иметь отношения соседства, настроенные с помощью A и B. Даже если настройка соседей автоматизирована, ручная настройка углубляет и расширяет поверхности взаимодействия между плоскостями управления и контроля.
Определение соседей из маршрутных объявлений - это решение, которое когда-то было широко распространено, но стало менее распространенным. В этой схеме каждое устройство периодически объявляет информацию о доступности и / или топологии. Когда маршрутизатор впервые получает информацию о маршрутизации от другого устройства, он добавляет удаленное устройство в локальную таблицу соседей. Пока соседнее устройство продолжает отправлять информацию о маршрутизации на регулярной основе, отношения между соседями будут считаться активными или активными.
При выводе соседей из объявлений о маршрутизации важно иметь возможность определить, когда сосед вышел из строя (чтобы информация о достижимости и топологии, полученная от соседа, могла быть удалена из любых локальных таблиц). Наиболее распространенный способ решения этой проблемы - использование пары таймеров: таймера задержки или отключения и таймера обновления или объявления. Пока сосед отправляет обновление или объявление в пределах таймера отключения или задержки, он считается включенным или активным. Если весь "мертвый" период проходит без получения каких-либо обновлений, сосед считается "мертвым", и предпринимаются некоторые действия, чтобы либо проверить информацию о топологии и доступности, полученную от соседа, либо он просто удаляется из таблицы.
Нормальная взаимосвязь между таймером отключения и таймером обновления составляет 3× - таймер отключения установлен на трехкратное значение таймера обновления. Следовательно, если сосед не отправляет три подряд обновления или объявления, таймер бездействия активируется и начинает обработку неработающего соседа.
Явные приветствия являются наиболее распространенным механизмом обнаружения соседей. Пакеты приветствия передаются на основе таймера приветствия, и сосед считается "мертвым", если приветствие не получено в течение интервала таймера ожидания или объявления. Это похоже на таймеры dead и update, используемые для вывода соседей из объявлений маршрутизации. Приветствия обычно содержат информацию о соседней системе, такую как поддерживаемые возможности, идентификаторы уровня устройства и т. д.
Централизованная регистрация - это еще один механизм, который иногда используется для обнаружения и распространения информации о соседних устройствах. Каждое устройство, подключенное к сети, будет отправлять информацию о себе в какую-либо службу и, в свою очередь, узнавать о других устройствах, подключенных к сети, из этой централизованной службы. Конечно, эту централизованную службу нужно каким-то образом обнаружить, что обычно осуществляется с помощью одного из других упомянутых механизмов.
Обнаружение двусторонней связи
В плоскостях управления с более сложными процессами формирования смежности - особенно протоколами, которые полагаются на приветствия для формирования отношений соседства - важно определить, могут ли два маршрутизатора видеть друг друга (осуществлять двустороннюю связь), прежде чем формировать отношения. Обеспечение двусторонней связи не только предотвращает проникновение однонаправленных каналов в таблицу пересылки, но также предотвращает постоянный цикл формирования соседей - обнаружение нового соседа, построение правильных локальных таблиц, объявление о доступности новому соседу, тайм-аут ожидания hello или другую информацию, удаление соседа или поиск нового соседа. Существует три основных варианта управления двусторонним подключением между сетевыми устройствами.
Не утруждайте себя проверкой двусторонней связи. Некоторые протоколы не пытаются определить, существует ли двусторонняя связь между сетевыми устройствами в плоскости управления, а скорее предполагают, что сосед, от которого принимаются пакеты, также должен быть доступен.
Перенос списка доступных соседей, услышанных на линии связи. Для протоколов, которые используют приветствия для обнаружения соседей и поддержания работоспособности, перенос списка доступных соседей по одному и тому же каналу является распространенным методом обеспечения двусторонней связи. Рисунок 6 иллюстрирует это.
На рисунке 6 предположим, что маршрутизатор A включен раньше B. В этом случае:
A отправит приветствия с пустым списком соседей, поскольку он не получил приветствия от любого другого сетевого устройства по каналу.
Когда B включен, он получит приветствие A и, следовательно, включит A в список соседей, которые он слышал в своих hello пакетах.
Когда A получает приветствие B, он, в свою очередь, включает B в свой список "услышанных" соседей в своих пакетах приветствия.
Когда и A, и B сообщают друг о друге в своих списках соседей, которые "слышно от", оба маршрутизатора могут быть уверены, что двустороннее соединение установлено.
Этот процесс часто называют трехсторонним рукопожатием, состоящим из трех шагов:
A должен послать привет B, чтобы B мог включить A в свой список соседей.
B должен получить приветствие A и включить A в свой список соседей.
A должен получить приветствие B с самим собой (A) в списке соседей B.
Положитесь на базовый транспортный протокол. Наконец, плоскости управления могут полагаться на базовый транспортный механизм для обеспечения двусторонней связи. Это необычное решение, но есть некоторые широко распространенные решения. Например, протокол Border Gateway Protocol (BGP), опирается на протокол управления передачей (TCP), чтобы обеспечить двустороннюю связь между спикерами BGP.
Определение максимального размера передаваемого блока (MTU)
Для плоскости управления часто бывает полезно выйти за рамки простой проверки двусторонней связи. Многие плоскости управления также проверяют, чтобы максимальный размер передаваемого блока (MTU) на обоих интерфейсах канала был настроен с одинаковым значением MTU. На рисунке 7 показана проблема, решаемая с помощью проверки MTU на уровне канала в плоскости управления.
В ситуации, когда MTU не совпадает между двумя интерфейсами на одном канале, возможно, что соседние отношения сформируются, но маршрутизация и другая информация не будут передаваться между сетевыми устройствами. Хотя многие протоколы имеют некоторый механизм для предотвращения использования информации о результирующих однонаправленных каналах при вычислении путей без петель в сети, все же полезно обнаруживать эту ситуацию, чтобы о ней можно было явным образом сообщить и исправить. Протоколы плоскости управления обычно используют несколько методов, чтобы либо явно обнаружить это условие, либо, по крайней мере, предотвратить начальные этапы формирования соседей.
Протокол плоскости управления может включать локально настроенный MTU в поле в пакетах приветствия. Вместо того чтобы просто проверять наличие соседа во время трехстороннего рукопожатия, каждый маршрутизатор может также проверить, чтобы убедиться, что MTU на обоих концах линии связи совпадает, прежде чем добавлять новое обнаруженное сетевое устройство в качестве соседа.
Другой вариант - добавить пакеты приветствия к MTU локального интерфейса. Если дополненный пакет приветствия максимального размера не получен каким-либо другим устройством в канале связи, начальные этапы отношений соседства не будут завершены. Трехстороннее рукопожатие не может быть выполнено, если оба устройства не получают пакеты приветствия друг друга.
Наконец, протокол плоскости управления может полагаться на базовый транспорт для регулирования размеров пакетов, чтобы коммуникационные устройства могли их принимать. Этот механизм в основном используется в плоскостях управления, предназначенных для наложения какой-либо другой плоскости управления, особенно в случае междоменной маршрутизации и виртуализации сети. Плоскости управления наложением часто полагаются на обнаружение MTU пути (Path MTU) для обеспечения точного MTU между двумя устройствами, подключенными через несколько переходов.
Сам размер MTU может оказать большое влияние на производительность плоскости управления с точки зрения ее скорости сходимости. Например, предположим, что протокол должен передавать информацию, описывающую 500 000 пунктов назначения по многопоточному каналу с задержкой 500 мс, и для описания каждого пункта назначения требуется 512 бит:
Если MTU меньше 1000 бит, для плоскости управления потребуется 500 000 циклов туда и обратно для обмена всей базой данных доступных пунктов назначения, или около 500 000 × 500 мс, что составляет 250 000 секунд или около 70 часов.
Если MTU составляет 1500 октетов или 12000 битов, плоскости управления потребуется около 21000 циклов туда и обратно для описания всей базы данных доступных пунктов назначения, или около 21000 × 500 мс, что составляет около 175 минут.
Важность сжатия такой базы данных с использованием какого-либо оконного механизма для сокращения числа полных обходов, необходимых для обмена информацией о достижимости, и увеличения MTU вполне очевидна.
Далее почитайте материал о том, как происходит обнаружение соседей в сетях.