> готовую платформу для хостинг провайдеровОставьте в покое хостинг провайдеров они используют решения Kubernetes as a Service (k8saas)
Давайте вместо влажных мечт, я объясню, почему это не готово к внедрению именно у хостинг-провайдеров.
1) Kubernetes и изоляция ресурсов
Вопреки бытующему мнению Kubernetes не может из коробки предложить мультитеннантность с жестким разграничением ресурсов. Для хостинг-провайдера нужно создать объект tennant в который входит:
- синхронизация учетных данных пользователей из on-prem инфраструктуры для задач управления. Нужна децентрализированная аутентификация и (желательно) авторизация. Tennant сам должен заводить / синхронизировать пользователей, выдавать себе API-ключи и использовать для этого нужно не только OAuth2, но и SAML2. Причем не только на стороне провайдера / AaaS (Authentication as a Service), но также на стороне tennant-а в гибридном сценарии, когда используется его поставщик утверждений (claims).
- Количество процессорных ресурсов, выраженных в ядрах или других единицах для вычисления жёсткого порога утилизации CPU
- Количество ресурсов оперативной памяти, выраженной в гигабайтах.
- Количество сетевой пропускной способности по направлению север-юг, выраженной в скорости траффика и/или в количестве этого траффика в отчетный период
- Перечень жестких квот на хранилище, выраженное в форме таблицы. На каждый тип (tier) нужно выдать число гигабайт.
Проблема в том, что Kubernetes-кластер не способен жестко отделить ресурсы одного tennant-а от другого. Особенно критично отделить CPU и RAM, потому что остальное можно сделать в другом месте.
2) Kubernetes и ccNUMA
Это на мой взгляд самое удивительное, но почему-то люди не в курсе, что в большинстве своём приложения в пространстве пользователя для POSIX-совместимых ОС не поддерживают NUMA. Вся эта эпическая крутизна вокруг shared memory, fork/clone и прочих CoW на буфер родительского процесса вместо нормальной реализации много поточности так прочно засела в головах, что ни преподы студентам не объясняет, как это всё не работает на современном железе, ни студенты не понимают, потому что задач не видели. Сама идея того, что у вас оверкоммитмент по памяти и есть общие буферы прекрасно работает с многопроцессорными серверами типа SMP, но деградирует на серверах с архитектурой ccNUMA. Бредовые разработчики Linux сопротивлялись реальности, говорили, что NUMA слишком сложна и не взлетит. Сюрприз-сюрприз, в 2024 году вы не купите классический SMP-сервер с северным мостом. Везде NUMA. Причем настолько везде, что у десктопных компьютеров ассиметричные ядра не только по тактовой частоте и электропитанию, но и по скорости доступа к контроллерам DRAM или их полному отсутствию у некоторых ядер. Выходите из анабиоза и погружайтесь в реальность:
- хостинг провайдер использует преимущественно двухпроцессорные сервера
- хостинг провайдер хочет иметь возможность выдать большую виртуальную машину с несколькими узлами NUMA внутри
- хостинг провайдер хочет иметь оверкоммитмент исключительно по CPU, и никак не ниже 6, желательно 10.
- хостинг провайдер хочет запретить любую форму оверкоммитмента по RAM.
Вы понимаете, что планировщик Kubernetes не поддерживает NUMA scheduling в продакшене?! Это барахло можно ставить либо в виртуальную машину, либо на однопроцессорные матери, иначе оно деградирует по производительности. Ну ладно, вроде Red Hat в свежайших версиях OpenShift вывел NUMA-aware scheduling из вечного экспериментального режима, но Kubernetes != OpenShift.
Просто я реально удивляюсь с некоторых админов. Неужели вы не знаете, что PostgreSQL (если считать её за промышленную БД) не поддерживает NUMA. И из-за этого в некоторых конфигурациях она работает быстрее на виртуальной машине, чем на физике. Неверная утилизация NUMA может сократить производительность приложения от 40% - 130% в зависимости от того, что лазит через Interconnect-шину. Если и сеть, и хранилище, то 130%. Не удивительно, что виртуализовав PostgreSQL вы снизите производительность всего на 25%. Или подбирайте однопроцессорное железо, а лучше купить нормальную БД. Опять же себе такое ставить... хостинг провайдер продаст вам виртуализированные PostgreSQL, но контейнеризировать её на Kubernetes - гроб.
3) Kubernetes и сетевой стек
Я давно перестал следить за очередными обновлениями сетевого стека Kubernetes, потому что там 8 лет уже почти всё готово. Хостинг провайдеру нужно иметь...
- Для себя: SR-IOV, RDMA и QoS всенепременно через DCB
- Для клиентов: VXLAN-оверлей с Encapsulated Task Offloading, Large Receive Offload, Large Send Offload, Receive Side Scaling
То есть если драйверы NVIDIA (Mellanox) у вас не работают, то хостинг провайдеру не нужен такой сетевой стек.
Так как там Linux, где вся логика Network Task Offloading, как, впрочем, и NUMA истерически отрицалась с криками "не нужно нам ваше LRO/LSO/RDMA" нужно использовать не стандартное барахло, которое в ядре по ошибке называют сетевым стеком, а драйверы сетевого адаптера и DPDK. Если Cozystack это не оркеструет, то его опять ставить только в виртуальную машину. Особенно интересен Receive Datapath на LRO и его разгрузка (Offloading)
4) Kubernetes и топология сети
Хостинг провайдер имеет несколько PoD-ов в смысле центров обработки данных. Между ними находится зачастую L2VPN, поверх которого должна быть создана транзитная сеть с возможностью растягивать L2-домены. Там либо EVPN-MPLS, либо, что чаще сейчас, EVPN-VXLAN. Учитывая, что у хостинг-провайдера много сервисов никто очередной васянский OVSDB держать не будет. Если мы говорим, что это ставится на физическое оборудование, то хостинг провайдеру нужно:
- контролировать сетевую изоляцию tennant-авторизация
- иметь возможность растянуть его L2-домены между несколькими дата-центрами одного региона (в смысле страны/государства)
- иметь возможность назначить Diffserv QoS на SDN
- иметь возможность мигрировать данные между дата-центрами
Вообще вопрос "конфедерации" (на языке VMware) или "растянутых кластеров" (на языке Microsoft), теоретически можно решить через массовую оркестрацию этого всего в Hashicorp Consul, но как бы можно просто поставить в виртуалку Kubernetes и дать его клиентам так. И PaaS также делать.
5) Kubernetes и хранилище
Это вообще притча во языцех. Про гиперконвергентность давайте сразу забудем, потому что в Linux ей либо не пользуются, либо попробовали и УЖЕ не пользуются. Когда планировщик процессов не способен разделить ресурсы, и работать с NUMA, но зато оверкоммитит память и применятся OOM Killer, то хранилище на тех же узлах кластера держать - это самоубийство. LINSTOR по их медиаресурсам не так плох, но я его не ставил еще пока. В свежих версиях его даже можно использовать совместно с RDMA, и он работает на стороне ядра, а не как Ceph. Классическому Kubernetes хранилище можно иметь внешнее и объектное, но, когда у вас там и виртуалки и недо-БД. А вообще см. п.1. Если оно способно выдать программно-определяемое БЛОЧНОЕ хранилище с разными форматами устройств и разными форматами дисков (mirror/erasure coding), то хорошо. Опять же LINSTOR не имеет никакого отношения к теме новости. Нужно просто понимать, как чинить, когда оно ломается. Как именно оно ломается. Какое можно выдать SLA. Но об этом дальше...
6) Kubernetes, резервное копирование и восстановление после сбоев
Финиш. Нет отчуждаемого решения. Расходимся.
А если серьёзно, см п.4, где я прошу сделать Fault Domains и конфедерации. Теперь давайте сделаем Disaster Recovery для этого решения с возможностью выхода из строя целой локации и возможностью восстановить работоспособность за вменяемое SLA в другом ДЦ. Просто тут еще большой вопрос в цене решения. KVM бесплатен только если его не бекапить. Если нужно решение для Disaster Recovery для хостинг-провайдера с KVM. Ну есть Commvault и с ними можно разговаривать про такие вещи. И если вы думаете, что хостинг провайдеры - это те, кто пишет себе наколенные DR-продукты вы их путаете с админами локалхостов или публичными облаками, которые могут себе это позволить с финансовой стороны. Кроме того, у хостинг-провайдера обычно не только внутренний baclup, но и BaaS-предложение для клиентов с возможностью интегрироваться с on-prem инфраструктурой клиента ("бекап в облако" и прочая маркетинговая фигня). И если этих решений 2, то по деньгам это проблема.
Ну как? Становится душно от реальности хостинг провайдеров? Автор новости, конечно, - фантазёр, предлагать такой PaaS "на железе" хостинг провайдерам. Не работает ваш Kubernetes на современном железе, которое экономически обосновано. А собирать проприетарные блейды специально под тот софт, который там вращается - это надо быть кем-то вроде Google Cloud.
Или подождите... неужели вы все настолько наивные и думаете, что Red Hat просто так взял и выбросил на помойку RHEV/oVirt. Там же с KVM такие же трудности у планировщиков и при работе с хранилищем и сетью, я бы даже сказал еще большие... Не так страшен KVM, как его libvirt поганый. Kubernetes-кластер хотя бы решает проблемы virsh с миграциями, изменением профиля конфигурации и много чем еще, но привносит кучу своих проблем (etcd и производительность API-сервера). Вы же, я надеюсь, тут все понимаете, что нельзя создать один большой и толстый Kubernetes-кластер на 3000 серверов с сотней тысяч виртуалок и контейнеров. Нужно создавать маленькие кластеры, формировать из них гиперкластеры даже в рамках одного дата-центра и учитывать все миграции между ними и между ними настраивать конфедерации с учетом сетевой топологии. А это делать чем? Что приводит к вопросу интеграций с решениями по управляшкам для хостинг-провайдеров. Про OpenStack даже не предлагайте, это нужно штат минимум из 35 питон-разрабов нанимать, чтобы постоянно менеджить свой форк кодовой базы (несколько команд, на разные модули). Из коробки оно не работает. Но даже если это у вендора купить, то почему бы тогда просто не Kubernetes в виртуалки? Или может быть вляпаться в CloudStack... ой всё.
Почитал их github и сайтик... Это наполовину форк OpenShift, который без платного саппорта Red Hat не работоспособен, такова бизнес-стратегия. Лицензия у Cozystack, Apache 2.0... Ну тогда скоро все эти наработки придут в OpenShift. И это при условии, если он взлетит на этом рынке. Red Hat старается, но понятия не имеет что делать. В общем, несмотря на похороны VMware, теперь "by Broadcom" на Bare-Metal OpenShift переходить попахивает экстремизмом. Не то внедрять subj из новости.
