Опубликован (https://cilium.io/blog/2018/04/24/cilium-10/) первый значительный релиз проекта Cilium (https://cilium.io), в рамках которого подготовлена система для обеспечения сетевого взаимодействия и применения политик безопасности для изолированных контейнеров и процессов. Ключевой особенностью Cilium является применение для контейнерной изоляции новых технологий ядра Linux - еBPF (https://en.wikipedia.org/wiki/Berkeley_Packet_Filter#Extensi... (Berkeley Packet Filter) и XDP (https://www.iovisor.org/technology/xdp) (eXpress Data Path). Исходные тексты компонентов, работающих на уровне пользователя, написаны на языке Go и распространяются (https://github.com/cilium/cilium) под лицензией Apache 2.0. Загружаемые в ядро Linux сценарии BPF доступны под лицензией GPLv2.
Изначально Cilium был разработан компанией Google, но затем преобразован в независимый проект, развиваемый сообществом. Помимо Google в разработке Cilium принимают участие такие компании, как Facebook, Netflix и Red Hat. Выпуск Cilium 1.0 обусловлен полной стабилизацией API (http://docs.cilium.io/en/doc-1.0/api/#compatibility-guarante... обеспечением длительной поддержки (LTS) и признанием проекта готовым для промышленного применения.
Основу Cilium составляет фоновый процесс, который работает в пространстве пользователя и выполняет работу по генерированию и компилированию BPF-программ, а также взаимодействует с runtime, обеспечивающим работу контейнеров. В форме BPF-программ реализованы системы обеспечения связности контейнеров, интеграции с сетевой подсистемой (физические и виртуальные сети, VXLAN, Geneve) и балансировки нагрузки. Фоновый процесс дополняют управляющий cli-интерфейс, расширяющие функциональность плагины, система мониторинга и модули интеграции CNI (http://docs.cilium.io/en/doc-1.0/kubernetes/) и CMM (http://docs.cilium.io/en/doc-1.0/docker/) с поддержкой Kubernetes, Mesos и Docker.
Особенности Cilium:- Упрощённая сетевая модель: каждому контейнеру назначается адрес IPv6 (опционально IPv4), все контейнеры соединены с одним общим виртуальным сетевым пространством с изоляцией через систему меток, привязанных к контейнерам. На базе меток могут выделяться сегменты сети и вводиться дополнительные правила доступа. IPv6 выбран в качестве основной модели адресации с поддержкой IPv4 для обеспечения обратной совместимости. Сеть может быть настроена в двух режимах: Overlay/VXLAN и Direct Routing.
- Расширяемость: пользователи могут дополнить или адаптировать для своих нужд любой аспект работы BPF-программ. Возможности перенаправления и фильтрации пакетов не ограничиваются версией ядра и могут расширяться добавлением новых типов статистики, не поддерживаемых ядром, новыми обработчиками протоколов, внесением изменений в методы отслеживания соединений, реализацией дополнительной логики перенаправления пакетов;
- Высокая производительность: JIT-компилятор позволяет добиться эффективного выполнения BPF-программ. Для каждого контейнера генерируются отдельные программы BPF, обеспечивающие только необходимую функциональность, что позволяет уменьшить размер выполняемого кода;
- Возможность внесения изменений и исправлений в компоненты, отвечающие за обработку и перенаправление пакетов, без перезагрузки ядра, без разрыва установленных соединений и без остановки работающих контейнеров;
- Интеграция эффективной системы мониторинга, которая может включаться по необходимости во время работы и позволяет отслеживать сетевую активность контейнеров в условиях высокой сетевой нагрузки без внесения задержек при обработке соединений. Кроме IP-адресов отображаются дополнительные метаданные, такие как метки контейнеров и имена сервисов. Система также позволяет производить инспектирования на уровне вызовов API. Постоянно отслеживается связность между узлами кластера и величина задержек при выполнении сетевых операций, что позволяет оперативно выявлять сбои узлов и сетевые проблемы. Также собираются метрики, имеющие отношение к производительности и состоянию сервисов;- Все компоненты Cilium могут применяться в полностью распределённом окружении, формируя общую виртуальную сеть для кластера. Демон, управляющие прослойки и генерируемые BPF-приложения могут выполняться на разных узлах. В будущем планируется предоставить средства для объединения разных кластеров без применения сложных прокси-сервисов;
- Обеспечение сетевой безопасности как на уровне пакетов, так и на уровне API: возможности по фильтрации трафика комбинируются с авторизацией на уровне API, что позволяет обеспечить защиту и для традиционных внедрений и для систем на базе архитектуры микросервисов (микросервисы взаимодействуют через API с идентификацией не по IP, а по именам сервисов, Cilium позволяет (http://docs.cilium.io/en/doc-1.0/intro/#functionality-overview) избавиться от дополнительных прокси для трансляции имён в IP);- Применение идентификации: вместо разграничения на основе исходных IP-адресов в Cilium применяется система меток, точно идентифицирующих каждый сетевой пакет (позволяет отследить привязку к контейнеру и сервису). Дополнительно поддерживается и традиционная система контроля доступа на основе правил, отталкивающихся от IP-адресов и подсетей. Но по возможности в Cilium используется дополнительный уровень абстракции, позволяющий избежать привязки к жестко заданным IP в пользу использования имён сервисов в правилах доступа;
- Распределённая и масштабируемая система балансировки нагрузки, использующая BPF для организации связи между сервисами. Поддерживается балансировка round-robin с учётом весов и возможности хэширования потоков. Эффективность работы балансировщика не зависит от числа сервисов (O(1)). Балансировщик может быть настроек в форме Kubernetes Service Implementation (альтернатива kube-proxy, все сервисы Kubernetes ClusterIP автоматически реализуются в форме BPF) и с управлением через API (возможность прямой настройки параметров балансировщика);
- Высокая производительность. При организации перенаправления трафика между большим числом сервисов iptables становится узким местом в производительности (при 5000 сервисов производительность падает на 30%, а при 10000 - на 80%, обновление правил для 5000 сервисов занимает 11 минут). В Cilium сводит обновление правил к уровню O(1), при котором производительность не зависит от числа записей. Благодаря хэшированию время поиска и применения правила всегда постоянно и не зависит от числа сервисов. Замена традиционного IPVS в балансировщике нагрузки Facebook на решение на базе BPF и XDP позволило поднять производительность в 10 раз. Применение механизма Sockmap в BPF также позволяет ускорить выполнение операций редиректа запросов, которые в среднем по сравнению с iptables выполняются в 2 раза быстрее.
eBPF представляет собой встроенный в ядро Linux интерпретатор байткода, позволяющий создавать обработчики сетевых операций, контролировать доступ и отслеживать работу систем, в том числе BPF-программы могут применяться для низкоуровневой обработки входящих/исходящих пакетов, принятия решений о перенаправлении пакетов, перехвата системных вызовов, контроля доступа и использования kprobes (https://www.kernel.org/doc/Documentation/kprobes.txt). XDP предоставляет средства для запуска BPF-программ на уровне сетевого драйвера, с возможностью прямого доступа к DMA-буферу пакетов, что позволяет создавать высокопроизводительные обработчики для работы в условиях большой сетевой нагрузки.
Программы для eBPF могут определяться на подмножестве языка C, компилироваться при помощи специального бэкенда LLVM и загружаться в ядро. Перед выполнением интерпретатор eBPF проверяет байткод на предмет применения разрешённых инструкций и налагает определённые правила на код (например, отсутствие циклов). Благодаря применению JIT-компиляции, байткод на лету транслируется в машинные инструкции и выполняется с производительностью нативного кода. При помощи...URL: https://cilium.io/blog/2018/04/24/cilium-10/
Новость: https://www.opennet.me/opennews/art.shtml?num=48556
ждем в докере из коробки
Контейнеры из коробок -- вот оно, современное ИТ :)
Зато когда вопрос встает ребром, девопсы Пашеньки рубят лулзы с церберов вовочки, так что их даже зобанить толком не могут: гаденыши разворачивают новые серваки быстрее чем жандарм банхаммером успевает махать. А мягкотелые ветеран юникс админы получили бы пару раз банхаммером в табло и угомонились бы, потому что неделю окучивать новый серв взамен зобаненого им видите ли тяжко.
Прикинь, ветераны юникс администрирования новые сервера разворачивали за пару минут за очень много лет до появления всяких докеров и девопсов. Эти ветераны вообще очень многое умели и умеют такого, о чем девопсы не имеет понятия.
> Прикинь, ветераны юникс администрирования новые сервера разворачивали за пару минут за
> очень много лет до появления всяких докеров и девопсов.Прям BBC на DOS или что там было в доконтейнеровую эпоху?
Да врети вы фсе!(с)
Потому что я точно слышал, что разворот рабочей станции полностью с нуля (федора, сузя или ХР) через PXT в 2005 году длился целых десять или даже 15 минут! Воть!
> (федора, сузя или ХР) через PXT в 2005 году длился целыхs/PXT/PXE/
Ага, за 5 минут. Что раньше что сейчас сервак 10-20 минут наливается в зависимости чем наливать.
Так что не рассказывайте мне про 5 минут.
Есть серверное железо, которое за 10 минут только биос проходит. Есть, которое это делает за секунды. Есть задачи, для которых надо поместить на диск нового сервера десятки гигабайт, а есть те, где хватает нескольких сотен метров, которые за полминуты будут переданы по сети и останутся в памяти. Так что запуск нового сервера может занять как больше 5 минут, так и меньше. Но в любом случае речь идет о минутах, а не неделях.
Что за "Orchestration systems" на картинке?
та, к которой ты, Анон, напишешь плагин для управления этой хренью.
Админы локалхоста не палятся.
Хватит этих контейнеров. Хоть один до конца допилите лучше.
> до концанет у контейнеров начала, нет у контейнеров конца
и дна тоже нет
Там кругом дно пока что
Очередная оверлейная сеть? Чем она лучше, чем Weave или Flannel?
> Очередная оверлейная сеть? Чем она лучше, чем Weave или Flannel?тем что держит
3,000,000 req/s
(впрочем, тут нигде не написано что это в overlay mode и что там была включена хоть какая-то фильтрация ;)
Как насчет 12Mpps (million packets per)?
req - это не один пакет, это полноценная сессия.
да просто нужно отказаться от IP-адресов в локальной сети и всё сразу станет намного лучше, эти ребята сделали первый шаг к этому отказу
вот оно: "микросервисы взаимодействуют через API с идентификацией не по IP, а по именам сервисов, Cilium позволяет избавиться от дополнительных прокси"
А в чем принципиальное отличие от имен контейнеров в докере?
В локалке нужно по IPX работать, как уже когда-то было.
Нескучный аналог Open vSwitch?
Calico выглядит как-то более безопасным на уровне L2.
Не понимаю. BPF ведь только-только выкатили, а тут уже продукты на его основе? Далее... Какой ipv6?? Kubernetes и близко про ipv6 не слышал
Facebook внутри работает на нативном ipv6, про Гугл все верно...
> Facebook внутри работает на нативном ipv6, про Гугл все верно...Так, блин, IPv4, натурально, заканчивается. Поэтому тысячи внутренних серверов на нем - становится все более и более проблематично.
>> Facebook внутри работает на нативном ipv6, про Гугл все верно...
> Так, блин, IPv4, натурально, заканчивается. Поэтому тысячи внутренних серверов на нем -Шо, прям тыщи мульёнов? Вот прям в 10.0.0.0/8 не вмещается?
Гига-а-ант! То ли индустрии, то ли падежа на букву π.
> становится все более и более проблематично.
Ожидаем Neo Cilium 1.1