Много негативных комментариев, однако изначальная идея адекватная, кмк.
"Проверить QR-код" это тоже, что "проверить штрихкод" или там еще что. Но из-за того, что часть населения с этим встречается впервые, это становится нарицательным. Хорошо это или плохо судить не берусь, но это вводит в заблуждение, когда речь о каком-то другом QR-коде.
Health Pass кмк звучит неплохо, по-русски "паспорт здоровья". Паспорт прививок у нас есть, это людей не смущает.
Но ситуация сама по себе смешная и грустная одновременно, в удивительные времена живем.
Ну как сказать. В поселках обычно такие дороги, где пешком пройти можно, на внедорожнике как-то проедешь, а вот чтобы ровер с малюсеньким просветом там прошел - верится примерно никак.
Да кто "вы" то? Я никому ничего не продаю. И убеждать никого ни в чем не собираюсь. Пожалуйста поберегите подмену тезисов для другого случая.
Аргументы мои выше. Серьезных контраргументов (кроме необъяснимых "88%") я не увидел.
Что же касается облаков - то тут я тоже не понимаю, в чем вопрос. Облака - это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s - есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.
Моя позиция в том, что у 88% организаций условия "тесные" — настолько, что им не по карману перераспределять бюджеты ради приобретения облачных подписок.
У меня нет такой статистики. Если у вас есть - поделитесь.
То есть, вы уже согласились с автором в первом пункте
Нет, не согласился. Для компаний уровня FAANG k8s как раз не очень подходит из-за одной особенности - он слишком "общий". Именно поэтому гугл использует borg, а не k8s - borg умеет работать только с одной OC, только с одним набором библиотек и только с определенным железом. За счет этого достигается большая эффективность.
Куб же хорош там, где нужно запускать гетерогенные нагрузки/разные технологии (привет, микросервисы), при этом хочется уметь хорошо масштабироваться горизонтально, управлять всем из единого места и иметь единый мониторинг.
Под это подходят средние и крупные компании, не подходят мелкие (стартапы) и очень крупные (мегакорпорации).
Но вы зачем-то продолжаете продавать доступ
Кто «вы-то»?! (с)
Я ничего не продаю. А если говорить про публичные облака, то обычно предлагают разные варианты с различным количеством operations - обычно это VM, K8s, какие-нибудь контейнеры, и какие-нибудь функции. Например, у GCP это Compute Engine, GKE, App Runner и Cloud Functions соответственно. При этом уровень operations снижается, а цена повышается (потому что цена operations входит в цену услуги).
Наверное понятно, что если бы k8s подходил для всех, то других услуг не было бы. Вопрос в том, чтобы понять, кому что подходит.
Очень удивляют такие статьи вида "нужно перестать делать Х, и все само собой пройдет".
Человечество (почти 8 млрд на момент написания комментария) нужно чем-то кормить (и не только его). Это могут быть животные (млекопитающие), животные (членистоногие), растения, грибы и т.п. Почему-то раз за разом в подобных статьях опускается момент, что перестав получать питание из источника А, его нужно восполнить из источника Б. То есть если человечество завтра перестанет есть мясо - это же количество нутриентов нужно будет восполнить из, скажем, агрокультуры. Которая также потребляет воду, удобрения, загрязняет и уничтожает места обитания животных и т.п.
Вот данных о том, во что обойдется распределить "мясную" часть рациона на другие отрасли производства пищи, я здесь не увидел, а без этого можно выбрасывать все выводы о пользе для экологии в помойку.
Ну и надо понимать, что "k8s не для бомжей" - это однозначно инструмент для тех, кто выигрывает что-то от его использования, потому что и сам кластер потребляет немало ресурсов, и его обслуживание и настройка чего-то стоят.
Если нагрузки вида "три контейнера, Postgres и API Gateway" - лучше посмотреть в сторону Heroku или GCP App Runner вкупе с managed DB.
У всех свои запросы. Знаю компании, у которых прод. нагрузка бежит на виртуалке с компоузом, знаю компании, где аналогичные нагрузки бегут просто на докере, а им управляет самописное cli приложение.
Вопрос в том, какие требования к инфраструктуре. Если требования "запустить один контейнер", то k8s тут явно лишний, да и k3s - тоже.
У k3s есть четкое и понятное назначение - это локальные окружения и "тесные" условия - эдж, всякие малинки и прочее. Кроме того, k3s идет на большое количество упрощений (как то использование однонодовой неотказоустойчивой ДБ вместо распределенной etcd и вообще минимальная отказоустойчивость. В "отказоустойчивом" варианте k3s мало чем отличается от k8s).
Подходит ли это для ваших нужд - вопрос только к вам. В плане долгосрочного использования k3s сильно проигрывает k8s как по возможностям обслуживания, так по масштабированию, отказоустойчивасти и прочим характеристикам прод. среды. Но возможно, время это исправит, тем более, что появляются интересные проекты вроде Talos - нацеленные на простоту и "изкоробочность".
Да нет там никакого надчеловеческого масштаба. K8s - это не облачная ОС, а платформа виртуализации, по сути, только с человеческим лицом в виде манифестов вместо каких-то сложных api и инструментов вроде vmomi.
Зачем хаять k3s - я не знаю, но k3s - это проект для "игрушечного" запуска куба - локально, в dev окружении или еще где. Он не прод-реди, его задача другая, вот и все, в остальном ничего плохого то нет.
Тем, кто не собирается в клуб - берите managed куб и забудте раз и навсегда про "нечеловеческий масштаб". Нюансы работы знать нужно, но вот нюансы обслуживания (а их реально много) - нет.
Это архитектурная проблема? Кмк, это большой плюс - компании типа FAANG могут дизайнить платформенные продукты вроде k8s с хорошим пониманием разного рода нагрузок и сценарием. Когда этим занимается небольшой стартап, получаем инструмент навроде swarm - слабо расширяемый и ограниченно масштабируемый.
Рынок Kubernetes раздроблен
Ровно наоборот. Любой вендор может сколь угодно перепиливать ванильный k8s и обмазывать его своими плагинами, clusterapi и прочими свистоперделками, но покуда он совместим с требованиями CNCF - кто угодно может запускать на нем что угодно.
В Kubernetes слишком много частей
"Kubernetes - это всего 5 бинарей!" (с). На самом деле частей много, потому что уровней абстракции много - и большинство порождены не k8s, а инфраструктурой. Да, это сложно, но сложно не потому, что k8s, а потому, что виртуализация и оркестрация - в целом сложная тема. K8s упрощает ее достаточно сильно не настолько, чтобы она стала простой.
Управлять Kubernetes вручную сложно
Здесь возразить нечего, это действительно так. Как и управлять кластером БД, или кластером Kafka сложно. Поэтому имеет смысл использовать managed k8s, покуда вам не станет выгоднее держать свой штат девопсов, чем платить облаку. (здесь могла быть нативочка, но ее не будет)
У Kubernetes есть проблемы с мониторингом и оптимизацией производительности
И снова все ровно наоборот. K8s (точнее, Metrics API) предоставляет единый и единообразный мониторинг всего и вся в k8s. Мониторинг же бизнесовых показателей ничем не меняется по сравнению с запуском в другом окружении.
Что касается производительности - и снова нет. K8s наоборот позволяет более полно утилизировать ресурсы за счет шедулера + гибких правил (taints, affinity, вот это все). В итоге простоя ресурсов меньше, чек меньше (если нагрузки вообще есть, конечно. Сам кластер тоже что-то ест).
Kubernetes всё сводит к коду
Да, и это прекрасно. IaC кажется сложным, но решает очень большую проблему - единообразность окружений, а также аудит, возможность отката при неудачном изменении инфры и тиражирование при необходимости. Не буду рекламировать IaC тут, но это благословение, а не наказание.
Kubernetes хочет всё полностью контролировать
Кмк, так говорить - некорректно. K8s хочет контролировать все, что внутри кластера - это логично. При этом интеграция с ресурсами вне кластера очень даже работает - посмотрите у любого облачного провайдера. Для особых энтузиастов есть инструменты вроде Cilium, с которыми эти интеграции еще сильнее упрощаются (ценой дополнительных уровней абстракции, конечно).
По-моему, с ковидом это никак не связано, просто одно из проявлений
Много негативных комментариев, однако изначальная идея адекватная, кмк.
"Проверить QR-код" это тоже, что "проверить штрихкод" или там еще что. Но из-за того, что часть населения с этим встречается впервые, это становится нарицательным. Хорошо это или плохо судить не берусь, но это вводит в заблуждение, когда речь о каком-то другом QR-коде.
Health Pass кмк звучит неплохо, по-русски "паспорт здоровья". Паспорт прививок у нас есть, это людей не смущает.
Но ситуация сама по себе смешная и грустная одновременно, в удивительные времена живем.
Ну как сказать. В поселках обычно такие дороги, где пешком пройти можно, на внедорожнике как-то проедешь, а вот чтобы ровер с малюсеньким просветом там прошел - верится примерно никак.
Ого, сбер на Tanzu сидит. Вот это точно потянет на новость
Эх, где вы были, когда я расшифровку своей кандидатской защиты писал...
Россия - нецелевая аудитория для таких технологий
Китайцами и индусами, видимо
Лол, вот это санта-барбара у них там в коре. Прям как книжку прочитал, спасибо.
Рассеивает туман войны. Известно, что кошки не могут есть, пока рядом враги
Это еще ладно, а вот когда тебя рекрутят в ту компанию, где ты уже работаешь...
...и предлагают на твою позицию зп значительно больше твоей
Расскажите, почему ory?
Тоже на него поглядывал, но интересует взгляд в разрезе системы с большой нагрузкой и/или кубовыми интеграциями.
А что не так с шоколадом, btw?
Да кто "вы" то? Я никому ничего не продаю. И убеждать никого ни в чем не собираюсь. Пожалуйста поберегите подмену тезисов для другого случая.
Аргументы мои выше. Серьезных контраргументов (кроме необъяснимых "88%") я не увидел.
Что же касается облаков - то тут я тоже не понимаю, в чем вопрос. Облака - это не только k8s, но еще очень много всего, так что каждый найдет себе подходящее. А кто не найдет (любители on-prem), среди того же k8s - есть и Tanzu, и Rancher, и Openstack, если хочется большего удобства, чем ванильный k8s.
У меня нет такой статистики. Если у вас есть - поделитесь.
Нет, не согласился. Для компаний уровня FAANG k8s как раз не очень подходит из-за одной особенности - он слишком "общий". Именно поэтому гугл использует borg, а не k8s - borg умеет работать только с одной OC, только с одним набором библиотек и только с определенным железом. За счет этого достигается большая эффективность.
Куб же хорош там, где нужно запускать гетерогенные нагрузки/разные технологии (привет, микросервисы), при этом хочется уметь хорошо масштабироваться горизонтально, управлять всем из единого места и иметь единый мониторинг.
Под это подходят средние и крупные компании, не подходят мелкие (стартапы) и очень крупные (мегакорпорации).
Кто «вы-то»?! (с)
Я ничего не продаю. А если говорить про публичные облака, то обычно предлагают разные варианты с различным количеством operations - обычно это VM, K8s, какие-нибудь контейнеры, и какие-нибудь функции. Например, у GCP это Compute Engine, GKE, App Runner и Cloud Functions соответственно. При этом уровень operations снижается, а цена повышается (потому что цена operations входит в цену услуги).
Наверное понятно, что если бы k8s подходил для всех, то других услуг не было бы. Вопрос в том, чтобы понять, кому что подходит.
Очень удивляют такие статьи вида "нужно перестать делать Х, и все само собой пройдет".
Человечество (почти 8 млрд на момент написания комментария) нужно чем-то кормить (и не только его). Это могут быть животные (млекопитающие), животные (членистоногие), растения, грибы и т.п. Почему-то раз за разом в подобных статьях опускается момент, что перестав получать питание из источника А, его нужно восполнить из источника Б. То есть если человечество завтра перестанет есть мясо - это же количество нутриентов нужно будет восполнить из, скажем, агрокультуры. Которая также потребляет воду, удобрения, загрязняет и уничтожает места обитания животных и т.п.
Вот данных о том, во что обойдется распределить "мясную" часть рациона на другие отрасли производства пищи, я здесь не увидел, а без этого можно выбрасывать все выводы о пользе для экологии в помойку.
Ну и надо понимать, что "k8s не для бомжей" - это однозначно инструмент для тех, кто выигрывает что-то от его использования, потому что и сам кластер потребляет немало ресурсов, и его обслуживание и настройка чего-то стоят.
Если нагрузки вида "три контейнера, Postgres и API Gateway" - лучше посмотреть в сторону Heroku или GCP App Runner вкупе с managed DB.
У всех свои запросы. Знаю компании, у которых прод. нагрузка бежит на виртуалке с компоузом, знаю компании, где аналогичные нагрузки бегут просто на докере, а им управляет самописное cli приложение.
Вопрос в том, какие требования к инфраструктуре. Если требования "запустить один контейнер", то k8s тут явно лишний, да и k3s - тоже.
У k3s есть четкое и понятное назначение - это локальные окружения и "тесные" условия - эдж, всякие малинки и прочее. Кроме того, k3s идет на большое количество упрощений (как то использование однонодовой неотказоустойчивой ДБ вместо распределенной etcd и вообще минимальная отказоустойчивость. В "отказоустойчивом" варианте k3s мало чем отличается от k8s).
Подходит ли это для ваших нужд - вопрос только к вам. В плане долгосрочного использования k3s сильно проигрывает k8s как по возможностям обслуживания, так по масштабированию, отказоустойчивасти и прочим характеристикам прод. среды. Но возможно, время это исправит, тем более, что появляются интересные проекты вроде Talos - нацеленные на простоту и "изкоробочность".
Да нет там никакого надчеловеческого масштаба. K8s - это не облачная ОС, а платформа виртуализации, по сути, только с человеческим лицом в виде манифестов вместо каких-то сложных api и инструментов вроде vmomi.
Зачем хаять k3s - я не знаю, но k3s - это проект для "игрушечного" запуска куба - локально, в dev окружении или еще где. Он не прод-реди, его задача другая, вот и все, в остальном ничего плохого то нет.
Тем, кто не собирается в клуб - берите managed куб и забудте раз и навсегда про "нечеловеческий масштаб". Нюансы работы знать нужно, но вот нюансы обслуживания (а их реально много) - нет.
Я понимаю, что отвечаю в пустоту, но
Это архитектурная проблема? Кмк, это большой плюс - компании типа FAANG могут дизайнить платформенные продукты вроде k8s с хорошим пониманием разного рода нагрузок и сценарием. Когда этим занимается небольшой стартап, получаем инструмент навроде swarm - слабо расширяемый и ограниченно масштабируемый.
Ровно наоборот. Любой вендор может сколь угодно перепиливать ванильный k8s и обмазывать его своими плагинами, clusterapi и прочими свистоперделками, но покуда он совместим с требованиями CNCF - кто угодно может запускать на нем что угодно.
"Kubernetes - это всего 5 бинарей!" (с). На самом деле частей много, потому что уровней абстракции много - и большинство порождены не k8s, а инфраструктурой. Да, это сложно, но сложно не потому, что k8s, а потому, что виртуализация и оркестрация - в целом сложная тема. K8s упрощает ее достаточно сильно не настолько, чтобы она стала простой.
Здесь возразить нечего, это действительно так. Как и управлять кластером БД, или кластером Kafka сложно. Поэтому имеет смысл использовать managed k8s, покуда вам не станет выгоднее держать свой штат девопсов, чем платить облаку. (здесь могла быть нативочка, но ее не будет)
И снова все ровно наоборот. K8s (точнее, Metrics API) предоставляет единый и единообразный мониторинг всего и вся в k8s. Мониторинг же бизнесовых показателей ничем не меняется по сравнению с запуском в другом окружении.
Что касается производительности - и снова нет. K8s наоборот позволяет более полно утилизировать ресурсы за счет шедулера + гибких правил (taints, affinity, вот это все). В итоге простоя ресурсов меньше, чек меньше (если нагрузки вообще есть, конечно. Сам кластер тоже что-то ест).
Да, и это прекрасно. IaC кажется сложным, но решает очень большую проблему - единообразность окружений, а также аудит, возможность отката при неудачном изменении инфры и тиражирование при необходимости. Не буду рекламировать IaC тут, но это благословение, а не наказание.
Кмк, так говорить - некорректно. K8s хочет контролировать все, что внутри кластера - это логично. При этом интеграция с ресурсами вне кластера очень даже работает - посмотрите у любого облачного провайдера. Для особых энтузиастов есть инструменты вроде Cilium, с которыми эти интеграции еще сильнее упрощаются (ценой дополнительных уровней абстракции, конечно).