- больше абстракций богу абстракций , Аноним (2), 13:21 , 21-Фев-24 (2) +1
больше абстракций богу абстракций!
- Flant , xxx000111 (?), 14:04 , 21-Фев-24 (3) +1
- У фланта подобная штука называется deckhouse , Аноним (4), 14:13 , 21-Фев-24 (4) +1
- У фланта свой форк кубвирта в энтерпрайз версии декхауза С их слов, они умаялись, Quad Romb (ok), 15:36 , 21-Фев-24 (11) +1
- От бывшего сотрудника фланта, Аноним (22), 16:44 , 21-Фев-24 (22) +2
- когда уже закончится эта истерия с облаками , 12yoexpert (ok), 15:07 , 21-Фев-24 (9) +7 [^]
когда уже закончится эта истерия с "облаками"...
- Нет уже никакой истерии Люди пользуются и втягиваются Не каждый может под свои з, Quad Romb (ok), 15:40 , 21-Фев-24 (12) –4 [V]
- Я видел как минимум 2 проекта при мне, которые провалились в том, чтобы с облака, Всем Анонимам Аноним (?), 16:15 , 21-Фев-24 (19) +2
- Во-во Ну, вот после таких историй народ в облака и переезжает Нет, всё можно и у, Quad Romb (ok), 16:18 , 21-Фев-24 (20) +1
- хранение чего зачем вообще FS, коли их нет нормальных в природе а объектных хр, pelmaniac (?), 20:58 , 21-Фев-24 (36)
- Ну как будто в ооооблачке у тебя не тот же самый ceph и обслуживают его боги Про, нах. (?), 20:59 , 21-Фев-24 (37) +1
- Если тебе надо городить аналог ютуба, конечно имеет смысл только подписочная дря, voiceofreason (?), 12:19 , 22-Фев-24 (115)
- не дешевле, basecamp сэкономили 7 лямов грина уйдя из облаков и всяких говноклас, penetrator (?), 19:48 , 21-Фев-24 (27) +1
- Может ещё этой команде поддержки и все свои коммерческие данные отдашь что, Аноним (14), 15:44 , 21-Фев-24 (14) +3
^^^ Может ещё этой команде "поддержки" и все свои коммерческие данные отдашь чтобы они вдоволь на них анализе заработали оптимизируя качество опусташения твоего кошелька?
- это работает , Sw00p aka Jerom (?), 19:14 , 21-Фев-24 (26)
>DRBD для репликации. это работает?
- Похоже на еще один ненужный проект кубирнетис для домохозяйки Неужели есть те к, Легивон (?), 19:51 , 21-Фев-24 (28) –2
Похоже на еще один ненужный проект: кубирнетис для домохозяйки. Неужели есть те кому сложно 1 раз сделать тераформ шаблон своей инфраструктуры для кубера, а затем множить его сколько угодно и поверх катать kubespray + все необходимые сервисы в том же плейбуке? Всего 2 бинарника надо запускать. Сложна, сложна, "ничего" непонятно! Хочу возюкать мышкой в перерывах когда варю борщ или вяжу носки и получать кубирнетис. Слышал о авторе по его докладам в области хранения в кубере. Полагаю lvm csi поверх shared lun сдулся после его ухода их фланта. Это печально. Были большие надежды на эту технологию.
- еще бы хотелось знать что такое PaaS что это мне это нужно кому нужно а то н, Аноним (39), 21:27 , 21-Фев-24 (39) +1
еще бы хотелось знать что такое PaaS. что это. мне это нужно? кому нужно. а то непонятно.
- Опенстак можно закапывать , Аноним (40), 21:39 , 21-Фев-24 (40)
Опенстак можно закапывать?
- Оставьте в покое хостинг провайдеров они используют решения Kubernetes as a Serv, Аноним (55), 22:13 , 21-Фев-24 (48) +1
> готовую платформу для хостинг провайдеровОставьте в покое хостинг провайдеров они используют решения 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 из новости.
- тут скорее - готовую платформу для продажи ее поштучно самим хостинг провайдером, похъ (?), 22:48 , 21-Фев-24 (53)
- Прямо статью написали И без обсценной лексики Замечательно, без шуток Нет такой , Quad Romb (ok), 22:57 , 21-Фев-24 (56)
- Спасибо за вброс, всё чётко и по делу Всё так, я всегда говорю что Kubernetes не, kvaps (ok), 23:20 , 21-Фев-24 (60) +2
- Да и зачем ему это, если проще каждому тенанту дать свой кластер или даже пятьде, Аноним (58), 00:46 , 22-Фев-24 (73)
- скажи мне вот только одно, а накой этот геморой если за 30-40 евро я могу купить, penetrator (?), 01:07 , 22-Фев-24 (79)
- Click- Next- Next- Next- ProductionЧудеса да и только , OpenEcho (?), 01:26 , 22-Фев-24 (80) +1
Click->Next->Next->Next->ProductionЧудеса да и только...
- Скрыто модератором, Олег (??), 05:28 , 22-Фев-24 (96) +1 [---]
Linstor в связке с zfs.... Дальше можно не читать, это невероятное поделие, под капотом которого вы проведёте не одну неделю.... Это мрак....
- Скрыто модератором, Аноним (130), 00:02 , 24-Фев-24 (130) [---]
Какие-то два ноунейма решили запилить свой велосипед из пачки деталей от других велосипедов. Доверия не вызывает.
- На HN полная тишина, не то что на какую-нибудь очередную запускалку NodeJS kva, Роман (??), 09:13 , 27-Фев-24 (131)
На HN полная тишина, не то что на какую-нибудь очередную запускалку NodeJS .@kvaps, просто любопытно, откуда (с ресурсов каких тематик, если можно имена ресурсов) идут переходы и интерес?
|