Спасибо за вброс, всё чётко и по делу)> Вопреки бытующему мнению Kubernetes не может из коробки предложить мультитеннантность с жестким разграничением ресурсов
Всё так, я всегда говорю что Kubernetes не мультитенантная система. Именно с учётом этого и разрабатывался Cozystack. Касательно тенантов, то конечные пользователи никогда не имеют доступа к management-кластеру. То есть Cozystack выступает в роли бэкенда для сервисов и благодаря декларативному Kubernetes API умеет легко интегрироваться в любую систему.
Пользователь может получить в свой tenant Kubernetes-кластер, в отличие от management-кластера tenant-кластера запускаются в виртуальных машинах, которые уже можно жёстко лимитировать.
> Kubernetes и ccNUMA
На данный момент и Kubernetes и KubeVirt умеет учитывать топологию NUMA. Хотя scheduler на данный момент действительно не умеет, но подвижки в эту сторону есть. В конце-концов, Kubernetes - это свободный проект, если будет спрос, не вижу проблем сформирвать SIG, подготовить пропозал и заимплементить, тем более что опыт и понимание в этом есть.
По факту мы только начали, есть много чего дорабатывать, начнём с малого и постепенно будем дорабатывать проект под нужды клиентов. В конце концов тот же OpenShift очень приветсвует когда их решения дорабатывают и адаптируют под ванилу сторонние контрибьютеры.
> Kubernetes и сетевой стек
> Kubernetes и топология сети
SR-IOV в KubeVirt работает из коробки. Мы затащили Kube-OVN, в отличие от других CNI он как раз позволяет делать жесткую изоляцию между тенантами, даже в пределах одного кластера. Можно создавать виртуальные сети и навешивать их на неймспейсы, очень удобно. QoS можно настраивать как на уровне подов, так и на уровне ВМ. Есть поддержка DPDK + можно оффлоадить OVS с разными карточками. Возможность мульти-кластера у OVN тоже есть, но пока что не тестировалась ввиду отсутствия пока такой необходимости.
> Kubernetes и хранилище
Да, как показывает практика LINSTOR в гиперконвергентной среде работает весьма неплохо. Проблемы начинаются на медленной сети и при геораспределённой репликации. На данный момент мы стараемся не использовать репликацию DRBD, где это возможно и использовать нативные способы репликации для баз данных и стейтфул сервисов.
> Kubernetes, резервное копирование и восстановление после сбоев
Velero - это стандартное решение для бэкапов в Kubernetes. Но вы правы, для каждого сервиса обычно есть отдельный набор ресурсов который нужно как-то унифицировать. На данный момент есть понимание как это можно улучшить, есть руки, но по прежнему нужны спонсоры :)
> Вы же, я надеюсь, тут все понимаете, что нельзя создать один большой и толстый Kubernetes-кластер на 3000 серверов с сотней тысяч виртуалок и контейнеров. Нужно создавать маленькие кластеры, формировать из них гиперкластеры даже в рамках одного дата-центра и учитывать все миграции между ними и между ними настраивать конфедерации с учетом сетевой топологии. А это делать чем? Что приводит к вопросу интеграций с решениями по управляшкам для хостинг-провайдеров.
Всё так, у нас есть понимание как делать федерацию. Благо Kubernetes со своей stateless-природой позволяет это сделать достаточно легко. Таким образом каждый кластер становится отдельной зоной, поверх этого напиливается система которая всем этим управляет, умеет умно шедулить сервисы между кластерами.
> Это наполовину форк OpenShift, который без платного саппорта Red Hat не работоспособен
От OpenShift'а у нас почти ничего нет, мы базируемся на ваниле, все компоненты платформы максимально отчуждаемые и заменяемые. Мы стараемся использовать наиболее стандартный и успешный в индустрии стек технологий.
