iptables это не про решение, а больше про синтаксис.
В наше время можете использоват nftables-api и настраивать netfilter через утилиту конвертер nft-iptables или как-то так называется, которая настраивает netfilter по реализации nftables интерфейсов.
Так что синтаксис и логика iptables с нами еще надолго.
На самом деле очень интересный вопрос, что является ID клиента у МТС. Если использовать номер телефона МТС вроде все прозрачно по идеи должен быть внешний ID пользователя и к нему цепляют телефоны, если использовать внешние ну тут как с почтой даже хуже, если неиспользуется и перешел другому человеку тогда и доступ к ресурсам появится... . В любом случае почта наше все)
Спасибо за статью, но есть пара моментов которые просто режут глазки)
1) Замените мультиарендность на мультитенантность или multi tenancy (на слух просто ужасно) 2) К сожалению в статье описаны базовые принципы которые уже заезжаны и ничего нового не приносят.
Было бы круто послушать о разделение по профилям нагрузки в мультитенантных средах использование разного коммунального оборудования, как выдавать видеокарты разных версий для разных групп и многое другое.
А так базисные правила в мультитенантных окружениях - минимизация соприкасновения.
1) Разделяете на неймспейсы 2) выделяете квоты и лимиты (задумывайтесь о биллинге ресурсов) 3) ингрес в каждый неймспейс (вход должен быть отдельным) 4) никакого оверлея только нейтив сеть или использования egress GW в каждый неймспейс для выхода трафика (выход должен быть отдельным) 5) дефолтные сетевые политики DENY ALL (всегда пишите только разрешающие правила для приклада) 6) Маркируйте приклад по профилю нагрузки CPU, RAM, DISK и маркировка профиля в рамках группы low, medium, high 7) Используйте афинити антиафинити и другие механизмы 8) Не забывайте вешать нод селектор лейбл для неймспейса (То что управляется админом или платформой - не клиентом) 9) Ограничивайте капабилити через PSP, PSS и пишите валидаторы через OPA (конфигурация должна удовлетворять требованиям)
И многое другое....
Многие коммунальные ресурсы к сожалению так и останутся коммунальными такие как coredns, SDN
Ну данная статья обозревательная - указать на внутрянку. Конечно можно описать все любым инструментом от баша, до ансибла или терраформа. Например наш проект https://github.com/fraima/kubernetes/tree/main/k8s-yandex-cluster реализует один из методов установки кластера без потребности использовать инструменты Day2 типа ansible, puppet, saltstack и все на terraform.
Если говорить в рабочих днях два месяцах фултайма, а так пол года крафта после основной работы. Поддерживают два человека, а так можете посмотреть в профиле у меня, недавно писал статьи по опыту проектирования такого рода кластеров.
спасибо за статью очень познавательно. Хотя очень забавно слышать что развертывание обычного кубернетес кластера может достигать дня и что менеджед кластер может подойти для неопытных админов. К сожалению одним из важных атрибутов оказывается стоимость на поддержку кластеров особенно при раздутом рынке кадров. По своему опыту скажу что менеджед куб не подошел из-за жестких ограничений в кастомайзе. Никто из менеджед провайдеров так и не научился включать фичи гейт по требованию. Ограничение на исправление в Яндекс клоуде цилиум конфига вообще добило. Пришлось пилить свой менеджед куб на терраформа который поднимает куб за какие то 3,5 минуты
Спасибо за ваш отзыв. На тему bespoken cluster(s) да вы правы это еще один инструмент для развертования, но т.к ограничен по времени и сил, не могу рассказать всю суть проекта сразу) Наш проект ориентирован на среды, где очень щепетильны к безопасности и на данный момент нету сборщиков кластеров с сертификатами из компанейского УЦ, это основное отличие, дальше повторили опыт фланта, улучшили многие места (в основной реп фланта yandex-cloud-controller, yandex-csi-controller помогли актуализировать их репозитории, добавили чарты, что бы их контроллеры можно было установить в vanila) и расширили кастомизацию за счет запуска напрямую с терраформа, а не через бинарь. (в первую очередь мы пытались сделать коробку но которая не имела бы ограничений на кастомизацию)
Самое главное что хотелось донести этой статьей, это то что есть интересные идеи и для любознательной аудитории они могли бы быть полезны. Популярность приходит не сразу, попробуем доказать пользу на деле)
Спасибо за комментарий - исправим
iptables это не про решение, а больше про синтаксис.
В наше время можете использоват nftables-api и настраивать netfilter через утилиту конвертер nft-iptables или как-то так называется, которая настраивает netfilter по реализации nftables интерфейсов.
Так что синтаксис и логика iptables с нами еще надолго.
послушал бы)
Тут не подскажу, лучше обратиться в поддержку МТС)
На самом деле очень интересный вопрос, что является ID клиента у МТС.
Если использовать номер телефона МТС вроде все прозрачно по идеи должен быть внешний ID пользователя и к нему цепляют телефоны, если использовать внешние ну тут как с почтой даже хуже, если неиспользуется и перешел другому человеку тогда и доступ к ресурсам появится... . В любом случае почта наше все)
Будем очень признательны если опишите в комментариях, что именно понравилось или не понравилось в статье и как бы мы ее могли улучшить.
Спасибо за статью, но есть пара моментов которые просто режут глазки)
1) Замените мультиарендность на мультитенантность или multi tenancy (на слух просто ужасно)
2) К сожалению в статье описаны базовые принципы которые уже заезжаны и ничего нового не приносят.
Было бы круто послушать о разделение по профилям нагрузки в мультитенантных средах использование разного коммунального оборудования, как выдавать видеокарты разных версий для разных групп и многое другое.
А так базисные правила в мультитенантных окружениях - минимизация соприкасновения.
1) Разделяете на неймспейсы
2) выделяете квоты и лимиты (задумывайтесь о биллинге ресурсов)
3) ингрес в каждый неймспейс (вход должен быть отдельным)
4) никакого оверлея только нейтив сеть или использования egress GW в каждый неймспейс для выхода трафика (выход должен быть отдельным)
5) дефолтные сетевые политики DENY ALL (всегда пишите только разрешающие правила для приклада)
6) Маркируйте приклад по профилю нагрузки CPU, RAM, DISK и маркировка профиля в рамках группы low, medium, high
7) Используйте афинити антиафинити и другие механизмы
8) Не забывайте вешать нод селектор лейбл для неймспейса (То что управляется админом или платформой - не клиентом)
9) Ограничивайте капабилити через PSP, PSS и пишите валидаторы через OPA (конфигурация должна удовлетворять требованиям)
И многое другое....
Многие коммунальные ресурсы к сожалению так и останутся коммунальными такие как coredns, SDN
Ну данная статья обозревательная - указать на внутрянку.
Конечно можно описать все любым инструментом от баша, до ансибла или терраформа. Например наш проект https://github.com/fraima/kubernetes/tree/main/k8s-yandex-cluster реализует один из методов установки кластера без потребности использовать инструменты Day2 типа ansible, puppet, saltstack и все на terraform.
Ага еще скажи
sudo snap install microk8s --classic и продакшнНу сбегать от Женя не хотел, но люлей за такой год получил)
Вот что делает забытая запятая)
Если говорить в рабочих днях два месяцах фултайма, а так пол года крафта после основной работы. Поддерживают два человека, а так можете посмотреть в профиле у меня, недавно писал статьи по опыту проектирования такого рода кластеров.
спасибо за статью очень познавательно. Хотя очень забавно слышать что развертывание обычного кубернетес кластера может достигать дня и что менеджед кластер может подойти для неопытных админов. К сожалению одним из важных атрибутов оказывается стоимость на поддержку кластеров особенно при раздутом рынке кадров. По своему опыту скажу что менеджед куб не подошел из-за жестких ограничений в кастомайзе. Никто из менеджед провайдеров так и не научился включать фичи гейт по требованию. Ограничение на исправление в Яндекс клоуде цилиум конфига вообще добило. Пришлось пилить свой менеджед куб на терраформа который поднимает куб за какие то 3,5 минуты
Я с женой без детей. В сбере год работал по 110 часов, вы серьезно, 9 часов в день нереально?)
О, а это баг а не фича))
Да мы последнее время тестировали на 1.23.12 и пропустили момент кастомизации этого куска, чуть позже выпущу фикс.
Тут вопрос как описывать содержимое т.к от версии к версии компоненты надо дружить между собой по версиям.
Версии вот отсюда тянутся там пока хардкод
Спасибо за вашу наблюдательность)
Спасибо за ваш отзыв. На тему bespoken cluster(s) да вы правы это еще один инструмент для развертования, но т.к ограничен по времени и сил, не могу рассказать всю суть проекта сразу) Наш проект ориентирован на среды, где очень щепетильны к безопасности и на данный момент нету сборщиков кластеров с сертификатами из компанейского УЦ, это основное отличие, дальше повторили опыт фланта, улучшили многие места (в основной реп фланта yandex-cloud-controller, yandex-csi-controller помогли актуализировать их репозитории, добавили чарты, что бы их контроллеры можно было установить в vanila) и расширили кастомизацию за счет запуска напрямую с терраформа, а не через бинарь. (в первую очередь мы пытались сделать коробку но которая не имела бы ограничений на кастомизацию)
Самое главное что хотелось донести этой статьей, это то что есть интересные идеи и для любознательной аудитории они могли бы быть полезны. Популярность приходит не сразу, попробуем доказать пользу на деле)
Да уже начали задумываться над единой документацией, https://gitbooks.io/ интересный проект но пока осваиваем https://squidfunk.github.io/mkdocs-material/ .
Спасибо за совет.
Ваш отзыв как бальзам на душу, большое спасибо.
Советы учтем и поправим.
Надо пройти весь путь по кубу с нуля и устроиться в сбер)
Ну мне хотелось бы поделиться своим опытом, вот только не совсем понимаю какие части людям не очень понятны, что бы точечно заострить внимание.