Проходят. Но, во-первых, очень многие конференции именно по Linux закрылись за 2010-ые, во-вторых, те что остались это в основном "kernel developers summits", то есть как раз специфичные мероприятия для конкретного узкого круга специалистов занимающихся разработкой ядра, в-третьих, конференции с более широкой аудиторией концентрируются на продуктах и подходах в Linux, а не на самой ОС.
Очень зависит от задачи. Если вы хотите получить весь функционал ванильного k8s, то вам нужен ванильный k8s. Если ваша задача получить в кратчайшие сроки с минимальными трудозатратами и погружением готовую среду для запуска ваших приложений, то да, смотрите на OS или Rancher.
Ни в коем случае не спорю ни с вами ни со всеми комментариями выше.
Возвращаясь к аналогии с Linux, он так же никак не решал задачу запуска Oracle DB при своем появлении. Но по мере роста его популярности, производителям ПО пришлось адаптировать свои продукты для возможности их запуска на этой ОС.
Я думаю то же самое ждет и Kubernetes. Уже сейчас можно видеть, что во многие продукты добавляется нативная поддержка k8s. Появляются продукты, которые специально написаны для k8s и используют его встроенные возможности.
А что касается
Я могу понять какой смысл в виртуализации ОС для мелкого и среднего бизнеса, а что даст k8s ?
то естественно это вопрос задач. Так же как Linux ничего не даст например условному геймеру для решения его задач. Точно так же, если у вас нет задач, которые нужно решать кластерной операционной системой, то она вам ничего и не даст.
Я кажется нигде не упомянал слово "заменить". Ествественно Kubernetes не может заменить Linux. Так же как Linux не может заменить процессор или оперативную память.
Это вещи работающие совершенно на разных уровнях. И вопрос не про замену, а про то что так же как сегодня подавляющее большинство инфраструктур работает на серверах с Linux, в будущем кажется большинство инфраструктур будут работать в Kubernetes. Но все так же поверх серверов с Linux, в которых все так же будут стоят процессоры и RAM.
Мне кажется тут вопрос не про эмоции, а про то что мы сейчас наблюдаем появление некого стандарта дефакто в нашей области. Такого же, каким когда то стал Linux. Но для решения современных задач при современных подходах к архитектуре.
Как бы там ни было, но все же количество компаний использующих k8s в своих инфраструктурах с момента появления этой технологии только растет, снижения пока еще замечено не было.
Согласен про YAML. Так же как и в Linux на самом деле все не файл, а файловый дескриптор. Но простые аналогии помогают лучше передать суть, как мне кажется.
По microk8s у них прям на сайте написано для чего предназначен этот дистрибутив – "A quick install, easy upgrades and great security make it perfect for micro clouds and edge computing."
То есть все таки сравнивать его с таким комбайном как OS не совсем корректно.
Я вот например готов подписаться под каждым словом вот тут
Серёжа, здесь вообще беспредел. 9 часов утра — и никого нету
на «ты» сразу со мной здороваться
я великий директор по продажам, а ребята со мной так легко неформально общались
Это реальная магия IT мира.
И прям из опыта нашей команды могу сказать, что это всё вообще не тривиальные выводы.
Везет тем для кого это штампы и узкомыслие.
P.S. Особенно музыкантам :)
Не знаю у кого как, а в симфоническом оркестре где я когда то работал, был 80 летний главный дирижер, бывший военный. Очень бы не отказались музыканты оркестра от небольшого количества таких вот штампов.
Именно так. Из готовых решений есть например https://github.com/kubevirt/kubevirt
А так ансибл оператор как вариант в руки, и в принципе из него уже сегодня можно управлять любой виртуализацией.
Повышение привилегий или получение информации, которой ты не должен был по идее обладать осуществляется не всегда со злыми намерениями (хотя и часто как раз с ними, и изнутри это происходит чаще чем хотелось бы).
Например в моей практике случались моменты, когда коллеги пользовались дырками во внутренних инфраструктурах для того чтобы эффективней выполнять свою работу. Зачем писать задачу админам, если ты получил себе доступ куда не нужно было и теперь можешь по-тихому сам выполнять нужные действия.
Правда велика вероятность, что при этом такой сотрудник совершит рано или поздно какую нибудь ошибку (все таки при нормальном стечении обстоятельств изначальные ограничения были не просто так придуманы), которая в итоге может привести к очень плачевным последствиям. Хотя первоначальные цели этого «взлома» были как бы благими.
И обычно тут начинается выяснение кто и куда влез, зачем он так действовал, разборки, выговоры и увольнения. А виновата как бы система, которая предоставляла доступ куда не нужно, кому не следует, а не сотрудник.
А еще см. пример с 11 миллиардами контейнеров из доклада. Там вообще никакого умысла что то взламывать или портить не было. Систему сломал буквально несчастный случай.
Именно так.
Кубернетис в компании это скорее всего отдельно выделенный инженер, а то и не один.
Это постоянная досборка/пересборка конструктора. Это огромная инфраструктура, которая должна сопутствовать кластеру.
Для небольшой компании, особенно исповедующей noops подходы это может стать непосильной задачей. Поэтому люди и выбирают всякие managed решения или Rancher и иже с ним (правда в последствии отгребая какие нибудь неожиданности от этих решений, которые потом не в состоянии никак починить, так как экспертизы то как не было так и нет, развернулось то все одной кнопкой).
Плюсов конечно у Куба много, но это большая сложная система. И что бы там ни писали в англоязычных блогах, как это все просто и как стартапы из двух девелоперов строят кластера на 5000 машин с rps под миллион, это все неправда. И нужно отдавать себе отчет при внедрении таких продуктов как Кубернетис. Что ты хочешь от него получить и чем придется взамен пожертвовать (например большим куском бюджета на ЗП специалисту).
Именно по этим причинам сейчас на рынке есть компании (и мы среди них) которые предлагают взять на себя все заботы по кластеру (да и вообще по инфраструктуре). Потому что такие компании могут потратить уйму времени и денег на хантинг нужных специалистов (которых правда мало). Потом могут выделить оплачиваемое время своих инженеров на чтение документации, эксперименты, написание собственных плагинов и тд. А потом этих инженеров задействовать в разных проектах, для разных клиентов. Таким образом фактически помогая рынку более эффективно использовать ограниченный ресурс в виде хороших специалистов, предоставляя их для разных задач, там где они нужны.
По поводу обезопашивания кластера, я бы выделил н пунктов:
1. Аутентификация компонентов кластера между собой по сертификатам.
2. Наличие понятных механизмов ротации этих самых сертификатов и никаких сертификатов на 100 лет.
3. Включенные аудит логи, настроенный их парсинг и алерты по полученным данным.
4. Наличие понятного и рабочего механизма обновления кластера и его компонентов с возможностью производить это так часто как требуется.
5. Настроенный файрвол для служебных портов кластера.
6. Включенные и настроенные сетевые политики.
7. Авторизация по RBAC, с пониманием и контролем прав в RBAC ролях.
8. Авторизация внешних пользователей в кластер через центральное юзерохранилище компании (аля LDAP) с ролями и тд + какой нибудь OAuth (аля Dex).
8. Включенные и настроенные PSP.
9. Включенные и настроенные LimitRange и ResourceQuota для всех нэймспэйсов.
10. Отдельные кластера для Dev/Stage и Prod.
11. Доступ на запуск новых абстракций только у CI, причем с четким контролем конкретных прав и нэймспэйсов для каждого проекта CI.
Это то что быстро в голову пришло. По идее этого должно хватить, чтобы ваша ИБ перестала прям уж сильно хвататься за голову. Но это все сильно прибавит работы Админам/Devops/SRE командам. Тут работает именно та диаграмма о которой я в докладе в начале говорил. Чем выше безопасность, тем ниже удобство.
А по поводу OpenShift полностью согласен. Как всегда «в опеншифт это их коробки».
Действительно там проведена огромная работа, и Кубернетис под капотом настроен по дефолту у них очень хорошо. Эти ребята читали документацию и занют о встроенных фичах Куба.
Дальше обычно следует вопрос – а почему вы не используете Опеншифт?
– Потому что я тоже читал документацию к Кубернетису и могу собрать под каждую задачу именно тот кластер, который мне нужен, а не тот который за меня преднастроил вендор, впилив сверху еще кучу своих костылей.
Да, ты прав. Действительно в jsonnetе сохранился.
Мы пользуемся helm чартом, я только туда заглянул и не нашел.
Ну тогда все еще проще, можно прям из jsonnet портировать в helm.
Так это же не про хранение стейта, а про его блокировку. Хранить в данном кейсе нужно все так же в S3.
Проходят. Но, во-первых, очень многие конференции именно по Linux закрылись за 2010-ые, во-вторых, те что остались это в основном "kernel developers summits", то есть как раз специфичные мероприятия для конкретного узкого круга специалистов занимающихся разработкой ядра, в-третьих, конференции с более широкой аудиторией концентрируются на продуктах и подходах в Linux, а не на самой ОС.
Очень зависит от задачи. Если вы хотите получить весь функционал ванильного k8s, то вам нужен ванильный k8s. Если ваша задача получить в кратчайшие сроки с минимальными трудозатратами и погружением готовую среду для запуска ваших приложений, то да, смотрите на OS или Rancher.
Ни в коем случае не спорю ни с вами ни со всеми комментариями выше.
Возвращаясь к аналогии с Linux, он так же никак не решал задачу запуска Oracle DB при своем появлении. Но по мере роста его популярности, производителям ПО пришлось адаптировать свои продукты для возможности их запуска на этой ОС.
Я думаю то же самое ждет и Kubernetes. Уже сейчас можно видеть, что во многие продукты добавляется нативная поддержка k8s. Появляются продукты, которые специально написаны для k8s и используют его встроенные возможности.
А что касается
то естественно это вопрос задач. Так же как Linux ничего не даст например условному геймеру для решения его задач. Точно так же, если у вас нет задач, которые нужно решать кластерной операционной системой, то она вам ничего и не даст.
Я кажется нигде не упомянал слово "заменить". Ествественно Kubernetes не может заменить Linux. Так же как Linux не может заменить процессор или оперативную память.
Это вещи работающие совершенно на разных уровнях. И вопрос не про замену, а про то что так же как сегодня подавляющее большинство инфраструктур работает на серверах с Linux, в будущем кажется большинство инфраструктур будут работать в Kubernetes. Но все так же поверх серверов с Linux, в которых все так же будут стоят процессоры и RAM.
Вот в том то и дело, что не "оркестрации контейнеров", а управления инфраструктурой и построения архитектуры.
Запускать контейнеры отлично могут и Nomad и Docker Swarm. Но ни тот ни тот инструмент стандартом как Linux не станут.
Мне кажется тут вопрос не про эмоции, а про то что мы сейчас наблюдаем появление некого стандарта дефакто в нашей области. Такого же, каким когда то стал Linux. Но для решения современных задач при современных подходах к архитектуре.
Как бы там ни было, но все же количество компаний использующих k8s в своих инфраструктурах с момента появления этой технологии только растет, снижения пока еще замечено не было.
Согласен про YAML. Так же как и в Linux на самом деле все не файл, а файловый дескриптор. Но простые аналогии помогают лучше передать суть, как мне кажется.
По microk8s у них прям на сайте написано для чего предназначен этот дистрибутив – "A quick install, easy upgrades and great security make it perfect for micro clouds and edge computing."
То есть все таки сравнивать его с таким комбайном как OS не совсем корректно.
Посмотрите по тексту. Там есть ссылки на многие выступления и статьи Андрея, которые хорошо раскрывают эту тему.
Недавно мой коллега писал статью как раз про сравнение Kubernetes self hosted и aas https://habr.com/ru/company/mailru/blog/559370/
Возможно вам будет интересно
Паш, сори, на самом деле я очень благодарен Домклику и тебе лично за крутой опыт, классные задачи и возможность так быстро вырасти как специалисту :)
Не написал Домклик, потому что мало ли, вы не ожидаете такого упоминания.
Но раз ты одобряешь, то исправили по тексту.
Это реальная магия IT мира.
И прям из опыта нашей команды могу сказать, что это всё вообще не тривиальные выводы.
Везет тем для кого это штампы и узкомыслие.
P.S. Особенно музыкантам :)
Не знаю у кого как, а в симфоническом оркестре где я когда то работал, был 80 летний главный дирижер, бывший военный. Очень бы не отказались музыканты оркестра от небольшого количества таких вот штампов.
Именно так. Из готовых решений есть например https://github.com/kubevirt/kubevirt
А так ансибл оператор как вариант в руки, и в принципе из него уже сегодня можно управлять любой виртуализацией.
Например в моей практике случались моменты, когда коллеги пользовались дырками во внутренних инфраструктурах для того чтобы эффективней выполнять свою работу. Зачем писать задачу админам, если ты получил себе доступ куда не нужно было и теперь можешь по-тихому сам выполнять нужные действия.
Правда велика вероятность, что при этом такой сотрудник совершит рано или поздно какую нибудь ошибку (все таки при нормальном стечении обстоятельств изначальные ограничения были не просто так придуманы), которая в итоге может привести к очень плачевным последствиям. Хотя первоначальные цели этого «взлома» были как бы благими.
И обычно тут начинается выяснение кто и куда влез, зачем он так действовал, разборки, выговоры и увольнения. А виновата как бы система, которая предоставляла доступ куда не нужно, кому не следует, а не сотрудник.
А еще см. пример с 11 миллиардами контейнеров из доклада. Там вообще никакого умысла что то взламывать или портить не было. Систему сломал буквально несчастный случай.
Кубернетис в компании это скорее всего отдельно выделенный инженер, а то и не один.
Это постоянная досборка/пересборка конструктора. Это огромная инфраструктура, которая должна сопутствовать кластеру.
Для небольшой компании, особенно исповедующей noops подходы это может стать непосильной задачей. Поэтому люди и выбирают всякие managed решения или Rancher и иже с ним (правда в последствии отгребая какие нибудь неожиданности от этих решений, которые потом не в состоянии никак починить, так как экспертизы то как не было так и нет, развернулось то все одной кнопкой).
Плюсов конечно у Куба много, но это большая сложная система. И что бы там ни писали в англоязычных блогах, как это все просто и как стартапы из двух девелоперов строят кластера на 5000 машин с rps под миллион, это все неправда. И нужно отдавать себе отчет при внедрении таких продуктов как Кубернетис. Что ты хочешь от него получить и чем придется взамен пожертвовать (например большим куском бюджета на ЗП специалисту).
Именно по этим причинам сейчас на рынке есть компании (и мы среди них) которые предлагают взять на себя все заботы по кластеру (да и вообще по инфраструктуре). Потому что такие компании могут потратить уйму времени и денег на хантинг нужных специалистов (которых правда мало). Потом могут выделить оплачиваемое время своих инженеров на чтение документации, эксперименты, написание собственных плагинов и тд. А потом этих инженеров задействовать в разных проектах, для разных клиентов. Таким образом фактически помогая рынку более эффективно использовать ограниченный ресурс в виде хороших специалистов, предоставляя их для разных задач, там где они нужны.
1. Аутентификация компонентов кластера между собой по сертификатам.
2. Наличие понятных механизмов ротации этих самых сертификатов и никаких сертификатов на 100 лет.
3. Включенные аудит логи, настроенный их парсинг и алерты по полученным данным.
4. Наличие понятного и рабочего механизма обновления кластера и его компонентов с возможностью производить это так часто как требуется.
5. Настроенный файрвол для служебных портов кластера.
6. Включенные и настроенные сетевые политики.
7. Авторизация по RBAC, с пониманием и контролем прав в RBAC ролях.
8. Авторизация внешних пользователей в кластер через центральное юзерохранилище компании (аля LDAP) с ролями и тд + какой нибудь OAuth (аля Dex).
8. Включенные и настроенные PSP.
9. Включенные и настроенные LimitRange и ResourceQuota для всех нэймспэйсов.
10. Отдельные кластера для Dev/Stage и Prod.
11. Доступ на запуск новых абстракций только у CI, причем с четким контролем конкретных прав и нэймспэйсов для каждого проекта CI.
Это то что быстро в голову пришло. По идее этого должно хватить, чтобы ваша ИБ перестала прям уж сильно хвататься за голову. Но это все сильно прибавит работы Админам/Devops/SRE командам. Тут работает именно та диаграмма о которой я в докладе в начале говорил. Чем выше безопасность, тем ниже удобство.
А по поводу OpenShift полностью согласен. Как всегда «в опеншифт это их коробки».
Действительно там проведена огромная работа, и Кубернетис под капотом настроен по дефолту у них очень хорошо. Эти ребята читали документацию и занют о встроенных фичах Куба.
Дальше обычно следует вопрос – а почему вы не используете Опеншифт?
– Потому что я тоже читал документацию к Кубернетису и могу собрать под каждую задачу именно тот кластер, который мне нужен, а не тот который за меня преднастроил вендор, впилив сверху еще кучу своих костылей.
Мы пользуемся helm чартом, я только туда заглянул и не нашел.
Ну тогда все еще проще, можно прям из jsonnet портировать в helm.