По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Docker и Kubernetes - два ведущих инструмента, используемых в индустрии облачных вычислений. В то время как Docker - это компьютерное приложение, использующее концепцию контейнеризации, а Kubernetes - это система оркестровки контейнеров.
Как правило, Docker и Kubernetes используются совместно друг с другом. Тем не менее, сравнение Kubernetes и Docker является чрезвычайно популярной темой в сообществе облачных вычислений.
Прежде чем сравнивать две наиболее важные технологии облачных вычислений, давайте сначала кратко расскажем о каждой из них.
Kubernetes
Впервые выпущенный в июне 2014 года, Kubernetes был изначально разработан Google. За дальнейшую разработку и обслуживание системы оркестровки контейнеров с открытым исходным кодом отвечает Cloud Native Computing Foundation.
Согласно официальному сайту, Kubernetes является «системой с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризованными приложениями».
Используя технологию контейнеризации, Kubernetes позволяет запускать контейнеры на нескольких вычислительных узлах, которые могут быть простыми серверами или виртуальными машинами. Перед использованием Kubernetes нужно перепроверить несколько вещей. Одним из них является обеспечение того, чтобы все участвующие вычислительные узлы были надежно связаны друг с другом.
Docker
Разработанная Docker, Inc., Docker была впервые выпущена в марте 2013 года. Это компьютерная программа, способная выполнять виртуализацию на уровне операционной системы, широко известную как контейнерная упаковка.
Docker можно рассматривать в двух разных сторон. С первого взгляда контейнеры Docker - это действительно легкие виртуальные машины, а со второй точки зрения Docker - это платформа для упаковки и доставки программного обеспечения.
Последний аспект в первую очередь ответственен за огромную популярность технологии контейнеризации Docker и ее широкое распространение в индустрии облачных вычислений.
Можно ли сравнивать Docker и Kubernetes?
Сравнивать Docker с Kubernetes - все равно что сравнивать Солнце с Луной. Конечно, оба небесных тела, но сравнение между ними не звучит правильно! Это потому, что, хотя оба сияют, один - звезда, а другой - естественный спутник.
Хотя Docker может работать без Kubernetes, а Kubernetes может функционировать в полной мере без Docker, использование обоих в совместной работе улучшает функциональность друг друга. Docker может быть установлен на компьютере для запуска контейнерных приложений. Подход контейнеризации означает запуск приложений в операционной системе таким образом, чтобы они были изолированы от остальной части системы. Приложение будет чувствовать, что оно имеет свою собственную выделенную ОС.
Несколько приложений могут работать в одной ОС, как если бы у каждого из них был свой экземпляр операционной системы. Каждое приложение находится внутри контейнера. Docker позволяет создавать, управлять и запускать контейнеры в одной операционной системе.
Теперь, когда у вас установлен Docker на нескольких хостах, то есть на операционных системах, вы можете воспользоваться Kubernetes. В таком случае мы называем эти хосты узлами или узлами Docker, которые могут быть серверами с открытым исходным кодом или виртуальными машинами. Прелесть использования Kubernetes с Docker заключается в том, что он помогает автоматизировать балансировку нагрузки контейнера, создание сетей, выделение ресурсов, масштабирование и безопасность на всех хостах Docker с помощью отдельной панели мониторинга или интерфейса командной строки.
Повышение масштабируемости приложений и повышение надежности инфраструктуры - две лучшие причины выбора нескольких узлов. Коллекция узлов, управляемых отдельным экземпляром Kubernetes, называется кластером Kubernetes.
Kubernetes vs Docker
Docker Swarm, про настройку которого можно прочитать тут - это платформа оркестрации контейнеров с открытым исходным кодом. Это собственный механизм кластеризации для Docker, и поэтому он использует ту же командную строку, что и Docker. Ниже приведены различные важные различия между Swarm и Kubernetes.
Развертывание приложений
Приложение развертывается в Kubernetes с использованием комбинации модулей и служб (или микросервисов). В Docker Swarm развертывание приложения происходит просто в виде микросервисов или сервисов в кластере Swarm.
Docker Swarm поставляется с Docker Compose, который помогает в установке приложения. Для идентификации нескольких контейнеров в Docker Swarm есть файлы YAML (YAML Ain’t Markup Language).
Настройка контейнера
Хотя Docker Swarm API не поддерживает все команды Docker, он предлагает почти все лучшие функциональные возможности Docker.
Итак, Docker Swarm поддерживает большинство инструментов, доступных для Docker. Однако, если Docker API не способен выполнять некоторые необходимые операции, не существует простого обходного пути для их использования в Docker Swarm.
Как и Docker Swarm, Kubernetes имеет свою собственную версию API, определения клиентов и YAML. Тем не менее, они отличаются от их коллег Docker.
Следовательно, нет возможности использовать Docker CLI или Docker Compose для определения контейнеров в Kubernetes. В случаях, когда необходимо переключить платформу, команды и определения YAML необходимо переписать.
Балансировка нагрузки
Как правило, Ingress используется для балансировки нагрузки в Kubernetes. Тем не менее, есть и другой способ, в котором модуль в Kubernetes выставляется через сервис и его можно использовать в качестве балансировщика нагрузки в кластере, к которому он принадлежит.
Docker Swarm имеет DNS-элемент, который можно использовать для распределения входящих запросов по определенному имени службы. Для балансировки нагрузки службы могут быть назначены автоматически или настроены для работы на указанных пользователем портах.
Сеть
Kubernetes использует плоскую сетевую модель. Таким образом, все модули могут взаимодействовать друг с другом. Как будет происходить взаимодействие между модулями, определяется сетевыми политиками. Обычно модель плоской сети реализована в виде наложения.
Модель плоской сети в Kubernetes требует две CIDR (Classless Inter-Domain Routing): один для сервисов, а другой - от которого модули получают IP-адрес.
В Docker Swarm узел, присоединяющийся к кластеру Swarm, отвечает за генерацию оверлейной сети для сервисов, охватывающей каждый хост в кластере, и сети мостов Docker только для хостов для контейнеров.
Docker Swarm дает пользователям возможность шифровать трафик контейнерных данных при создании оверлейной сети.
Масштабируемость
Kubernetes - это комплексная структура для распределенных систем. Поскольку он предлагает унифицированный набор API и надежные гарантии состояния кластера, Kubernetes является сложной системой. Эти способности отвечают за замедление развертывания и масштабирования контейнера.
По сравнению с Kubernetes, Docker Swarm может развертывать контейнеры на гораздо более высокой скорости. Следовательно, это позволяет быстрее реагировать на масштабирование системы в соответствии с требованиями.
Синергия между Docker и Kubernetes
Kubernetes способен работать в тандеме с любой технологией контейнеризации. RKT и Docker являются двумя наиболее популярными опциями для механизма оркестровки контейнеров с открытым исходным кодом. Однако последний предпочтительнее, чем первый.
Из-за большего предпочтения использования Docker с Kubernetes было приложено много усилий для совершенствования сотрудничества между этими двумя технологиями.
Хотя Docker имеет свой собственный механизм оркестровки контейнеров в форме Docker Swarm, склонность к использованию Kubernetes с Docker нельзя не заметить. Это видно из того факта, что Docker for Desktop поставляется с собственным дистрибутивом Kubernetes.
Следовательно, совершенно очевидно, что обе технологии, Docker и Kubernetes, объединили свои усилия и также извлекли большую пользу из этого сотрудничества.
Сегодня хотелось бы кратко описать команды менеджера пакетов yum - официальная сборка FreePBX основана на CentOS, в котором yum установлен по умолчанию. Он пригодится для установки, удаления, обновления пакетов.
Установка пакета
К примеру, для установки пакета mc нужно ввести команду yum install mc. После ввода команды, система попросит подтверждение. Чтобы подтверждение было одобрено по умолчанию, нужно добавить ключ -y , к примеру yum –y install mc:
[root@localhost asterisk]# yum install mc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.corbina.net
* epel: mirror.datacenter.by
* extras: mirror.corbina.net
* updates: mirror.corbina.net
Resolving Dependencies
--> Running transaction check
---> Package mc.x86_64 1:4.8.7-11.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
mc x86_64 1:4.8.7-11.el7 base 1.7 M
Transaction Summary
================================================================================
Install 1 Package
Total download size: 1.7 M
Installed size: 5.6 M
Is this ok [y/d/N]: y
Downloading packages:
mc-4.8.7-11.el7.x86_64.rpm | 1.7 MB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : 1:mc-4.8.7-11.el7.x86_64 1/1
Verifying : 1:mc-4.8.7-11.el7.x86_64 1/1
Installed:
mc.x86_64 1:4.8.7-11.el7
Complete!
Удаление пакета
Для удаления пакета, соответственно, нужно ввести команду yum remove mc. Точно также можно использовать ключ для подтверждения -y :
[root@localhost asterisk]# yum remove mc
Loaded plugins: fastestmirror
Resolving Dependencies
--> Running transaction check
---> Package mc.x86_64 1:4.8.7-11.el7 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
mc x86_64 1:4.8.7-11.el7 @base 5.6 M
Transaction Summary
================================================================================
Remove 1 Package
Installed size: 5.6 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Erasing : 1:mc-4.8.7-11.el7.x86_64 1/1
Verifying : 1:mc-4.8.7-11.el7.x86_64 1/1
Removed:
mc.x86_64 1:4.8.7-11.el7
Complete!
Обновление пакета
Предположим – у вас старая версия mysql и вам необходимо ее обновить – тут используется команда update. Целиком команда будет выглядеть так: yum update mysql .
Поиск пакета
Если хотите проверить наличие установленного конкретного пакета на сервере и доступные для установки – используйте команду list. Целиком команда будет выглядеть так: yum list mysql. Также можно указать точную версию пакета, если вам требуется более скрупулезный поиск.
Вывод информации о пакете
Если хотите вывести информацию о пакете – используйте команду info. Целиком команда будет выглядеть так: yum info mc .
Вывод информации о всех доступных и установленных пакетах
Для этого используется команда list с модификаторами. Для вывода доступных пакетов: yum list | less, а для вывода всех установленных - yum list installed | less
Проверка доступных обновлений для пакетов и само обновление
Для проверки служит команда check-update, а для обновления - update. Ниже три примера использования команд:
yum check-update mysql - проверка обновлений пакета mysql;
yum list updates - вывод списка обновлений;
yum update mc - обновление Midnight Commander’а;
yum –y update - обновление всех установленных пакетов;
Групповые пакеты и операции с ними
В Линуксе некоторые пакеты собраны в так называемые групповые пакеты – к примеру, DNS Name Server, Editors, Java Development и так далее. С помощью yum можно устанавливать групповые пакеты с помощью команды groupinstall - пример далее yum groupinstall ‘Clustering. Коротко опишу остальные команды для манипуляций с групповыми пакетами:
yum grouplist - вывод всех доступных к установке групповых пакетов;
yum groupupdate ‘Base’ - обновление конкретного группового пакета, в данном случае – Base;
yum groupremove ‘Editors’ - удаление группового пакета;
Репозитории в yum
Поиск пакетов происходит в так называемых репозиториях, ниже приведу несколько команд для работы с ними – принцип тот же, что и с пакетами (команды list, к примеру). Вывод всех активных репозиториев производится с помощью команды yum repolist, вывод также и неактивных репозиториев – с помощью команды yum repolist all
Для установки пакета из конкретного репозитория, неважно, активного или неактивного, используется ключ --enablerepo . Как пример – установка phpmyadmin: yum –enablerepo=epel install phpmyadmin
Терминал в yum и история
Если Вы собираетесь проводить очень много операций с пакетами, то можно сразу зайти в оболочку yum с помощью команды yum shell и с помощью уже известных вам команд (только уже без первых трёх букв, соответственно), Вы можете устанавливатьудалятьобновлятьwhatever пакеты. Также интересной фичей является возможность посмотреть историю установок в yum – с помощью команды yum history.
Третья часть тут
Поскольку трафик в реальном времени начал передаваться по сетям с коммутацией пакетов, QoS стал серьезной проблемой. Передача голоса и видео полагается на то, что сеть способна быстро переносить трафик между хостами (с низкой задержкой) и с небольшими колебаниями межпакетного разнесения (jitter). Дискуссии вокруг QoS фактически начались в первые дни сети с коммутацией пакетов, но достигли высшей точки примерно в то время, когда рассматривался ATM. На самом деле, одним из главных преимуществ ATM была возможность тщательно контролировать способ, которым обрабатывались пакеты, когда они передавались по сети с коммутацией пакетов.
С провалом ATM на рынке, появились два направления идей о приложениях, которые требуют сильного контроля над jitter и delay:
Эти приложения никогда не будут работать в сетях с коммутацией пакетов. Такого рода приложения всегда должны запускаться в отдельной сети.
Это просто поиск правильного набора элементов управления QoS, чтобы позволить таким приложениям работать в сетях с коммутацией пакетов.
Основное, что больше всего волновало большинство провайдеров и инженеров, была голосовая связь, и основной вопрос сводился к следующему: можно ли обеспечить приличную голосовую связь по сети, также передающей большие файлы и другой "nonreal - time" трафик? Были изобретены сложные схемы, позволяющие классифицировать и маркировать пакеты (называемые QoS-маркировкой), чтобы сетевые устройства знали, как правильно их обрабатывать. Картографические системы были разработаны для переноса этих маркировок QoS из одного типа сети в другой, и много времени и усилий было вложено в исследование механизмов массового обслуживания-порядка, в котором пакеты отправляются по интерфейсу. На рис. 1 показана примерная диаграмма одной системы QoS, и сопоставления между приложениями и маркировками QoS будет достаточно, чтобы проиллюстрировать сложность этих систем.
Увеличение скорости связи оказывают двойной эффект на обсуждение QoS:
Более быстрые каналы связи будут (это очевидно) нести больше данных. Поскольку любой отдельный голосовой и видеопоток становится сокращающейся частью общего использования полосы пропускания, необходимость строго сбалансировать использование полосы пропускания между различными приложениями стала менее важной.
Время, необходимое для перемещения пакета из памяти в провод через микросхему, уменьшается с каждым увеличением пропускной способности.
По мере того, как доступная пропускная способность увеличивалась, потребность в сложных стратегиях массового обслуживания для противодействия jitter становилась все менее значимой. Это увеличение скорости было дополнено новыми системами массового обслуживания, которые гораздо эффективнее управляют различными видами трафика, уменьшая необходимость маркировки и обработки трафика детализированным способом.
Такое увеличение пропускной способности часто обеспечивалось переходом от медного волокна к стекловолокну. Оптоволокно не только обеспечивает большую полосу пропускания, но и более надежную передачу данных. Способ построения физических связей также эволюционировал, делая их более устойчивыми к поломкам и другим материальным проблемам. Вторым фактором, увеличивающим доступность полосы пропускания, стал рост Интернета. По мере того, как сети становились все более распространенными и более связанными, отказ одного канала оказывал меньшее влияние на объем доступной полосы пропускания и на потоки трафика по сети.
Поскольку процессоры стали быстрее, появилась возможность разрабатывать системы, в которых отброшенные и задержанные пакеты будут иметь меньшее влияние на качество потока в реальном времени. Увеличение скорости процессора также позволило использовать очень эффективные алгоритмы сжатия, уменьшая размер каждого потока. На стороне сети более быстрые процессоры означали, что control plane могла быстрее вычислять набор loop-free путей через сеть, уменьшая как прямые, так и косвенные последствия сбоев связи и устройств.
В конечном счете, хотя QoS все еще важен, его можно значительно упростить. Четырех-шести очередей часто бывает достаточно для поддержки даже самых сложных приложений. Если требуется больше, некоторые системы теперь могут либо проектировать потоки трафика через сеть, либо активно управлять очередями, чтобы сбалансировать сложность управления очередями и поддержки приложений.
Централизованный Control Plane - есть ли смысл?
В 1990-х годах, чтобы решить многие из предполагаемых проблем с сетями с коммутацией пакетов, таких как сложные плоскости управления и управление QoS, исследователи начали работать над концепцией, называемой активной сетью. Общая идея состояла в том, что плоскость управления для сети с коммутацией пакетов может и должна быть отделена от устройств пересылки, чтобы позволить сети взаимодействовать с приложениями, запущенными поверх нее.
Базовая концепция более четкого разделения плоскостей управления и данных в сетях с коммутацией пакетов была вновь рассмотрена при формировании рабочей группы по переадресации и разделению элементов управления (ForCES) в IETF. Эта рабочая группа в основном занималась созданием интерфейса, который приложения могли бы использовать для установки пересылки информации на сетевые устройства. Рабочая группа была в конечном итоге закрыта в 2015 году, и ее стандарты никогда не применялись широко.
В 2006 году исследователи начали эксперимент с плоскостями управления в сетях с коммутацией пакетов без необходимости кодирования модификаций на самих устройствах- особая проблема, поскольку большинство этих устройств продавались поставщиками как неизменяемые устройства (или black boxes). Конечным результатом стал OpenFlow, стандартный интерфейс, который позволяет приложениям устанавливать записи непосредственно в таблицу пересылки (а не в таблицу маршрутизации). Исследовательский проект был выбран в качестве основной функции несколькими поставщиками, и широкий спектр контроллеров был создан поставщиками и проектами с открытым исходным кодом. Многие инженеры считали, что технология OpenFlow позволила бы реконструировать инженерные сети за счет централизации управления.
В реальности, все будет по-иному-то, что, скорее всего, произойдет в мире сетей передачи данных: лучшие части централизованной control plane будут поглощены существующими системами, а полностью централизованная модель будет выброшена на обочину, оставив на своем пути измененные представления о том, как control plane взаимодействует с приложениями и сетью в целом.