> Где производительность и где inetd запускающий по экземплярую программы на запрос?
> Какой ужос! Не верится даже что это может оказаться не троллингом.Спешу расстроить, это не троллинг. Архитектура UNIX Internet Daemon предполагает наличие суперсервера, который перенаправляет запросы на другие демоны.
На примере реализации в IIS:
1. Запросы поступают по сети, которую обслуживает ядро (драйверы адаптеров и сетевой стек)
2. К каждому IP и порту есть привязка HTTPS, HTTP, HTTP2 или QUIC
3. Если соединение предполагает наличие криптографии, то она обслуживается модулем по работе с TLS опять на стороне ядра
4. Аутентификации (Basic, Kerberos, X.509) обслуживается как ядром, так и юзерспейсом, если требуются особые формы делегирования
5. Далее мы получили запросы по HTTP, которые обслуживает HTTP.sys на стороне ядра (кроме запроса PATCH, он в юзерспейсе)
6. Поступившие запросы попадают на сокет службы согласно правилам привязок и определения пулов приложений.
7. Каждый пул — это запущенный с пониженными привилегиями экземпляр службы публикации, который реализует пайплайн по работе с запросами. Пулы и есть многопоточные рабочие процессы для ряда интерпретаторов (.NET, Node.JS) или связываются с дочерними процессами по CGI
Реализация этой классической UNIX-архитектуры в Linux — это полное фиаско и несмываемый позор. Учитывая, что во времена ядра 2.6 предпринимались попытки реализовать это средствами ядра, как в Windows, но получилось, как всегда. Проект по реализации обработки HTTP тогда появился в ядре и благополучно сдох. А что с TLS на уровне ядра? Зачатки Kernel TLS появились в районе 4.13, а в 5.1 оно только-только стало экспериментально работоспособным. Но мало кто пользуется им еще, все по-прежнему линкуют всё в дистрибутивах к OpenSSL. Я это всё к тому, что реализация inetd убогая, медленная и мёртвая, работает как попало и чисто в юзерспейсе. В Windows реализация inetd есть очень давно, и она называется IIS. Ей полностью меняли реализацию 3 раза (1995-2000, 2001-2005, 2006-наст. время) из-за того, что она размазана по всей ОС и меняется с мажорным апдейтом. Но пользователи видели только 3 инкарнации. И вот она работает очень быстро.
> Поддержка железа кубером = поддержке железа Linux.
Нет не равно! Кубик — это планировщик. У него есть назначение приоритетов, но не ресурсов железа. Вы понимаете, как они работают со своими 0.5 CPU? Это веса планировщика. Чем выше цифра, тем выше приоритет контейнера. Но с реальным железом они не мапятся. Linux с железом работает, а кубик нет. Кубик не может назначить такие-то процессоры и ядра с таким-то уровнем утилизации на такой-то ноде NUMA. Есть вот эта бетка, но она все еще экспериментальная: https://kubernetes.io/docs/tasks/administer-cluster/memory-m.../
А еще там нужно шейпить сеть в ядре и много чего еще делать по фильтрации запросов/пакетов в ядре. Вам (контейнерщикам) для этого годами eBPF разрабатывают, а я всё как не гляну, всё равно узко. Динамическая фильтрация пакетов работает в ядре Windows c года так с 2001-го. Говорить надо или сами узнаете что такое WFP и как он соотносится с NDIS. Оно там всё либо не доделано на стороне Linux, либо на стороне Kubernetes, либо брошено всеми, и все забили.
> Не понял ваш пример железа. Я использую кубиры на обычных виртуалках без каких бы то ни было аппаратных излишеств. И у меня все работает.
Правильно, потому что с физической инфраструктурой не работали. Конечно, у вас все работает на виртуалках. Я же пишу, что оно ТОЛЬКО ТАК работает. А теперь соберите кубик на многопроцессорном железе без грамма виртуализации, я посмотрю на вас. У вас будут несколько проблем:
1. NUMA, её разные формы на разных физических хостах, особенно Xeon Scalable вас удивит своей гибкостью.
Так как кубик всё это не умеет пока, то придётся брать однопроцессорные блейды и игнорировать наличие NUMA. При этом у вас все равно по нескольку контроллеров на проц, которые мапятся к разным ядрам, но там не так страшен вариант расползания разных потоков на разные ядра с разными контроллерами RAM, чем если это расползание одного приложения между разными сокетами.
2. Сеть на стороне хоста. Вам нужен DPDK, пойдите еще поднимите его: https://www.dpdk.org/wp-content/uploads/sites/35/2020/11/DPD...
Причем, чтобы завести всё это так, чтобы у вас там Overlay оффлоадилась на сетевые карты, вам проще поставить сетевки NVIDIA (Mellanox), потому что только они нормально работают в Linux.
А если вам нужен еще и сторадж в контейнерах, то проще перейти на использование S3-образного объектного стораджа, отказавшись от всего остального, потому что там будет тонна проблем либо с производительностью, либо с подбором железа.
Если вы попытаетесь подать в контейнеры локальный сторадж, то вы упретесь в геометрическую проблему серверной платформы. Однопроцессорные блейды имеют мало дырок на диски, может не хватить в зависимости от... и тогда хана.
Если вы попытаетесь подать сетевой сторадж, то запустить его с поддержкой RDMA и оффлоадить сторадж на сетевой карте та еще задачка.
- NFSv4+ в Linux опять частично работает в userspace, Linux вам не Solaris и не FreeBSD, чтобы иметь нормальные драйверы, но кое-как RDMA запустить можно. Вся проблема в NFSv4 ACL, которые в Linux медленные.
- SMB, насколько я знаю пока не вышел в прод и находится в состоянии PDF-презентаций разной степени красивости.
- iSER (iSCSI over RDMA) вроде бы работает и даже с поддержкой Multipath, но менеджить LUN-ы как контейнерный сторадж... уффф.
Ну так вот, когда вы радостно поставили свой Ceph-кластер или купили проприетарную хранилку вам нужно сцепить его с физическими нодами кубика так, чтобы заработал оффлоадинг по RDMA и чтобы сеть была построена так, чтобы multipath работал.
Единственный рецепт для Linux - построить это всё исключительно на L3 и вот почему! В ядре Linux просто омерзительный драйвер бондинга и кошмарный драйвер виртуального свитча. Обоим место в музее. Все современные модули ядра Linux и все новые фишки работают только через мосты (Linux Bridge). Для вас (убежденного в том, что Kubernetes нормально работает на железе и в Linux всё хорошо с железом) придется настроить выделенный сегмент сети в топологии Spine-Leaf в режиме L3, который будет выполнять роль Underlay. Забудьте про MLAG, стеки, фабрики и прочий LACP. Вам придётся построить eBGP CLOS, настроить ECMP и настроить Border-свитчи для стыка сегмента с основной сетью датацентра, пусть даже по OSPF, но в отдельной Area. Если вы любите Linux берите NVIDIA (Cumulus Linux), они работают.
> Реальность такова, что на практике аппаратные сервера настолько мощные (100+ ядер, 500+ RAM), что никто не готов выделять под типичные задачи небольшого проекта 7 аппаратных серверов (3 etcd + 2 control plane + 2 worker). Даже самый маленький сервер который имеет смысл приобретать будет иметь ресурсов на порядок (10 раз) больше чем нужно 1 инстансу. Поэтому с кубиром виртуализация и используется практически всегда.
Ах, эти знаменитые аргументы про "не нужно", какая прелесть =)
То, что у тебя нету больших задач и тебя до них не допустили, совсем не значит, что их нет ни у кого вообще и у меня в частности. Я знаю, что я говорю, потому что я это делал и оно работало на стенде так как надо именно с железом, потом поставил поверх OpenStack. Передо мной стояла задача развернуть Kubernetes as a Service быстрее по производительности, чем у некоторых конкурентов. Как раз на серверах с 96 ядер и 1ТБ RAM. Но без виртуализации оно именно что неюзабельно, от слова "совсем". Всё что там необходимо сделать по мультитеннантности, по изоляции по разграничению ресурсов на данном этапе сыро. Это решает Red Hat в OpenShift, который тоже еще сырой для barebone и не особенно то в фаворе у дурачков, которые докеры крутят, там же root нельзя. А без отжима root никакой изоляции в Linux не добиться. А оборудование нужно изолировать от дурачков, оно от них тупеет. Развертывание железного кубика не сложнее чем OpenStack свой собрать... но и не проще. И вот это всё от вас прячет инфраструктура виртуализации в датацентре. Вы пользуетесь виртуалками, потому что изнутри них не знаете сколько очередной VMware ESXi и VMware NSX делает для таких вот пафосных "знатоков" Kubernetes.
> Он гораздо безопаснее за счет какой-никакой изоляции в namespaces, которую на голом хосте, в сравнении с этим, как правило никто не настраивает.
Во-первых, научись говорить за себя. У меня нет ни одного хоста Linux с выключенным мандатным контролем.
Во-вторых, "какая-никакая изоляция в namespaces" это в тебе говорит культ карго и суеверность. Вся эта чешежопица с namespaces и контекстами SELinux существует исключительно потому, что в ядре Linux исторически:
- нет нормальных ACL. Вместо них POSIX ACL, которые мусор, они опциональны, и применяются только к ограниченному типу объектов, особенно нет ACL для процессов юзерспейса
- нет нормального понимания сессии, вместо этого есть Linux PAM, который ничего ни от кого не изолирует и все запущенные процессы входы в систему считает локальными и равными друг другу
- нет способа динамически менять привилегии процесса без его перезапуска
- Capability в ядре Linux — это вообще шутка очередная.
Вот они годами и правят 1001-у архитектурную ошибку, которая была допущена. Замечаешь, как Linux с каждым годом становится всё больше и больше похож на Windows... хмм... интересно, почему так происходит, не правда ли?
> Примеры будут?
Мой изначальный тезис в том, что высоконагруженные корпоративные приложения, если нужно избежать виртуализации, сейчас применяются только на Windows с IIS и это суровая реальность. Если же компания реально огромная и их не устраивает Windows и её лицензирования, IIS и сложность его оркестрации, то они радостно форкают BSD. Некоторые типы задач настолько чувствительны к той паразитной нагрузке, которую порождает виртуализация, что там просто выбора нет. Почти всё реалтаймовое, всё что имеет высокий параллелизм, все что работает по принципу "ссылка->данные" (такая задача не кэшируется на процессоре), всё с со сложными многопоточными математическими вычислениями - тонна отраслей и задач.
Это ты мне должен привести примеры массового использования докерообразной контейнеризации без грамма виртуалок сразу на железе, раз ты убежден что она активно используется. Сам-то заявляешь, что сидишь с виртуальным кубиком, думая, что те кто покрупнее используют его без виртуалок. А вот нифига!
> А по факту уже давно имеется стабильный qemu-kvm runtime реализующий стандарный интерфейс контейнеров - kata-containers называется.
> Хорошее решение, переспективное, в духе Red Hat.
> Думаю root можно будет открывать по подписке.
Ты окончательно запутался, как мне кажется. Именно Red Hat трудится над запихиванием KVM в Kubernetes. Они строят новый OpenShift с поддержкой KVM внутри контейнеров, с поддержкой мультитеннантности с поддержкой изоляции и с возможностью работать на железе. Всё чем ты перечислил — это куски GPL-кода в апстриме, находящиеся под полным контролем Red Hat и выкинутыми наружу частями OpenShift/OKD. Они закрыли oVirt, чтобы разрабатывать это. Я не знаю, за что ты так ополчился на Red Hat, но именно они пытаются решить проблему, о которой я тут распинаюсь и которую ты не видел в виду собственной ограниченности кругозора. Да KVM это ненастоящий (type2) гипервизор. Его виртуальные машины — это процессы в ОС. И весь юзерспейсный инструментарий управления KVM страдает от того, что в нем нет… барабанная дробь… автоматизаций вроде NUMA Spannig для виртуальных машин и гранулярной работой с SMT. И вместо того, чтобы писать и развивать инфраструктуру виртуализации для type2 гипервизора они решили сделать наоборот, сделать уже наконец-то barebone-контейнеризацию, внутри которой можно пихать виртуалки.
Вот ты мне говоришь, KVM, будто это что-то хорошее… У него проблемы с уровнем оверкоммита CPU, если его виртуалки слишком разношерстны по ресурсам. Сейчас реальность с KVM такова, что на крупном развертывании KVM можно стабильно жить с overommit 2-4 по CPU. Если нужно выше то нужно:
- создавать пресеты виртуалок (понятие flavor в OpenStack)
- создавать привязку flavor к образу ОС (в OpenStack Glance)
- поставить группу кластеров под каждый flavor<->image
- настроить placement api, чтобы оно разносило типы виртуалок по нужным кластерам
- использовать только конвергентный сторадж, гиперконвергентные решения не работают от слова "совсем" (Red Hat, конечно, предлагал раньше ставить oVirt на GlusterFS, но там по подписке и они это все закрыли).
Вот тогда можно добиться стабильного оверкоммита 4-6. Amazon активно занимается решением этих проблем и по-прежнему продолжает заносить бабло в Citrix, потому что Xen просто работает. Равно как и его младшая сетричка Hyper-V, которая держит оверкоммит 6-8 со стандартными настройками и 8-10 если выключить балунинг и использовать процессоры исключительно одинаковых моделей. VMware близка к этим показателям, и у нее своя специфика. Причем KVM еще и памяти требует больше, чем Hyper-V и VMware, но это уже из-за специфики реализации страничного кэширования в ядре Linux. Я это знаю из опыта работы на хостинг-провайдеров и, да, я работал со всеми кластерами, на высоких провайдерских хайлоадах.
Так кот, все эти проблемы на стороне KVM +/- те же самые, что и в кубике, и выражаются они прежде всего в большей степени в косорылых автоматизациях в юзерспейсе, но также и в ущербности самого ядра. KVM-у, как Type2 гипервизору реально место в кубике, потому что нормальную виртуализацию шапка так и не запилила, свой флагманский овирт выкинула. Со стораджем там тоже беда-беда, грозятся новый сторадж писать опять. И всё это опять в OpenShift.
> Дядь, ты что опять таблетки пить перестал? Участковый психиатор заругается!
Он заругается скорее на то, что я пытаюсь научить очередного хамовитого юнца, как пользоваться компьютером, вместо того чтобы послать его на йух.
