Здравствуйте, _ABC_, Вы писали:
НС>>Причина простая — заказчик хочет. _AB>Да, это железная причина. Но не всем заказчикам это интересно.
Пока, может, и не всем. Но это пока. Тенденция вполне очевидная, многие с тобой даже разговаривать не будут, если твое решение под кубером не работает.
НС>>Да не особо то и сложно, если не пытаться поднимать с нуля. Локально есть docker desktop, в облаке нативные решения типа AKS, в онпреме OpenShift. _AB>Ну, скажем, я слышал мнения нескольких людей, чья профессия — в том числе поднимать кубернетес как локально, так и в облаках провайдеров.
Ситуация постоянно меняется. То что было несколько лет назад и то что сейчас — большая разница.
_AB>Одна только настройка ингресс контроллера в частной сети AKS — это отдельный квест уровня хардкор.
И при чем тут кубер? Точно так же ты бы трахался с рукопашнеой настройкой RP.
_AB>Настройка правил реверс прокси по документации кубика — это другой захватывающий квест.
Там какое то принципиальное отличие от настройки голого nginx?
_AB>Пока что только один клиент из всех захотел кубик на базе AKS.
Ну то есть даже у тебя один уже есть. ЧТД.
_AB> А потом поменял решение, исходя из того, что у него нет людей, которые могли бы это поддерживать.
Обычно ситуация прямо обратная. Нет людей, которые могут поддерживать что то кроме кубера.
_AB> Несмотря на то, что мы со своей стороны успешно развернули решение на AKS. В итоге для него мы развернём всё тупо внутри одной ВМ.
Ну, решение которое можно развернуть внутри одной ВМ — действительно не особенно нуждается в каком бы то ни было оркестраторе, включая кубер.
Здравствуйте, smeeld, Вы писали:
S>Нужно. Контейнеры нужны в двух случаях S>1) Если свою прикладуху нужно исполнять в облаке и загрузить туда можно только в виде котейнера. S>2) Приложение писал макакин, который собрал его из кучи разношерстных компонентов, скачанных с разных источников и разными менеджерами. Это рабатать будеть только у макакина на локалохосте. Чтоб это заработало где-то ещё, единственный способ-это взять образ этого локалхоста, завернуть в контейнер, и этот контейнер уже таскать на другие машины.
А если ты свое прекрасное приложение писал под один дистрибутив линуха, а у заказчика — другой? Обзовешь его макакиным и пошлешь в жопу, или будешь поддерживать пачку инсталляторов под все потенциально востребованные дистры?
Здравствуйте, _ABC_, Вы писали:
vsb>>А если нужны контейнеры — то выбора 2. Либо колхозные docker-compose-ы, либо кубер. _AB>Либо использовать что-то другое. AWS, Azure и остальные вовсю предлагают serverless applications, например.
serverless не означает отсутствие кубера. ACI вполне себе и куберосовместимо и serverless. Без кубера это только решения для бедных типа aws lambda (и то не удивлюсь если там унутре все тот же кубер).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А если ты свое прекрасное приложение писал под один дистрибутив линуха, а у заказчика — другой? Обзовешь его макакиным и пошлешь в жопу, или будешь поддерживать пачку инсталляторов под все потенциально востребованные дистры?
Нет, посмотри на CI проекта postgres-a. Там все дестрибутивы линукса, BSD, все винды, все благородные юниксы и даже все опенсорсные клоны соляриса. Вот так и надо.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А если ты свое прекрасное приложение писал под один дистрибутив линуха, а у заказчика — другой? Обзовешь его макакиным и пошлешь в жопу, или будешь поддерживать пачку инсталляторов под все потенциально востребованные дистры?
И как же оно раньше-то делалось, во времена Squid, Apache httpd и прочих.
Здравствуйте, smeeld, Вы писали:
S>Нет, посмотри на CI проекта postgres-a. Там все дестрибутивы линукса, BSD, все винды, все благородные юниксы и даже все опенсорсные клоны соляриса.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ситуация постоянно меняется. То что было несколько лет назад и то что сейчас — большая разница.
Ситуация прямо на сейчас, можно сказать. Разговор с несколькими из них был буквально в апреле последний.
НС>И при чем тут кубер? Точно так же ты бы трахался с рукопашнеой настройкой RP.
Да нифига. Реверс прокси на том же самом ngnix, который, вроде как, основа и ингресс контроллера кубика (одна из и мы его использовали) мы подняли за пару-тройку часов в своё время, включая чтение документации.
А тут они придумали идиотские аннотации вроде (забыл как они называются) с масками, забыли сказать, что они будут действовать на всё правило и что редирект по умолчанию тоже будет использовать эту маску, хотя под неё не попадает. И то, что это не работает именно поэтому можно понять исключительно из обрывкой документации (они тупо создали в одном из примеров два правила, никак не объяснив почему), а не как-то ещё.
НС>Там какое то принципиальное отличие от настройки голого nginx?
Да. Голый nginx сильно проще. Не нужны никакие аннотации с никакими регэкс масками внутри них, всё описывается в одном месте максимально просто.
НС>Ну то есть даже у тебя один уже есть. ЧТД.
Как раз уже его нет.
Внутри сисадмины тоже год назад кричали, что всё перейдёт на кубик и мы тоже. Я тогда сказал — ОК, как только, так сразу. Сейчас им послал сообщение — ребята, мы тут сделали PoC, он работает, давайте начнём переход на кубик. Тишина в ответ. Повторный запрос — опять тишина. На третий раз промямлили что-то типа "погоди с кубиком, не к спеху нам переход на него".
НС>Обычно ситуация прямо обратная. Нет людей, которые могут поддерживать что то кроме кубера.
С трудом представляю себе такое. Что это за организация, которая не имеет людей или подрядчика, которые не могут обслужить отдельную машину?
НС>Ну, решение которое можно развернуть внутри одной ВМ — действительно не особенно нуждается в каком бы то ни было оркестраторе, включая кубер.
Ну, это зависит от нагрузки. В общем-то, почти любое решение можно развернуть внутри одной ВМ.
Здравствуйте, Артём, Вы писали:
Аё>С спринг бутом прилагается нетфликсовый стек- eureka service registry и прочее <.>, по видимости, завязанное на жаву. Аё>У Кубернетис свой реестр и он не завязан на жаву. А еще кубернетис выкинул докера в актуальной версии.
Аё>Нужно ли переходить на Ккбернетис, или уходить с кубернетиса? Дискас.
1. Кубернетес хорошо работает для дома. Когда пару нодов и какой-нибудь легковесный Kubernetes. У меня k3S, заметил, что некоторые сервисы уже за 2 года перешли. Телефония, сайты, синхронизация и прочее.
Это non-compliant, не hardened, но, самостоятельно и безгеморно работает. так что, можно все оставить и поехать на Кубу, не боясь что контейнер некому будет перестартовать
2. Кубернетес хорошо работает для больших компаний, где все отлажено. Отдельный тим на CI-CD, отдельный на Ingress, отдельно APM. Все по феншую.
Для случая между, может быть "дешевле" всякие лямбды и прочее. Иначе квест быстро "разворачивается" в длинную линию фронта. И облако, и кластер, CI-CD и все это что между, нужно неожиданно много людей. Для помощи и сопровождения разработчиков, которые каждый месяц разные, требуются тоже люди. И тренирующие тренирующих, тоже, тебуются Если еще требуется SOC 2 / PCI то все, сели.
В общем, учи кубернетесы (а не Еуреку, про которую я не слыхивал) и наслаждайся, пока вся эта вселенная маленькая и есть ощущение что все можно охватить. Потом даже до ближайшей звезды не долетишь, как вся картина раскроется
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>serverless не означает отсутствие кубера. ACI вполне себе и куберосовместимо и serverless. Без кубера это только решения для бедных типа aws lambda (и то не удивлюсь если там унутре все тот же кубер).
Неонка там у них унутре или кубики — это не важно для команды. Важно, что они не мучаются с конфигурационными файлами кубернетеса и используют более простые интерфейсы.
Здравствуйте, _ABC_, Вы писали:
НС>>Обычно ситуация прямо обратная. Нет людей, которые могут поддерживать что то кроме кубера. _AB>С трудом представляю себе такое. Что это за организация, которая не имеет людей или подрядчика, которые не могут обслужить отдельную машину?
Крупные банки, к примеру. Там нельзя вот так просто взять и поставить отдельную машину с непойми чем. Вся инфраструктура должна обслуживаться только сертифицированными спецами. Для кубера такие спецы есть, а вот для непойми что — нету.
НС>>Ну, решение которое можно развернуть внутри одной ВМ — действительно не особенно нуждается в каком бы то ни было оркестраторе, включая кубер. _AB>Ну, это зависит от нагрузки. В общем-то, почти любое решение можно развернуть внутри одной ВМ.
Только если это решение специально изолировали от внешней специфики, что совсем не бесплатно. Как только у тебя появляется, скажем, оператор — все, про работу без оркестратора можно забыть.
Поэтому решение об использовании оркестратора — стратегическое, и принимается обычно на старте проекта. А если у тебя проект изначально на голые ВМ рассчитаны, без использования бенефитов оркестратора — да, поначалу ты от кубера будешь получать только боль.
Здравствуйте, _ABC_, Вы писали:
_AB>Неонка там у них унутре или кубики — это не важно для команды. Важно, что они не мучаются с конфигурационными файлами кубернетеса и используют более простые интерфейсы.
Если тебя так пугают куберовские манифесты (гадость та еще, согласен, усогубленная модно-молодежным yaml, добавляющим еще массу драмы) — есть различные решения поверх. Например cdk8s.
Здравствуйте, _ABC_, Вы писали:
НС>>serverless не означает отсутствие кубера. ACI вполне себе и куберосовместимо и serverless. Без кубера это только решения для бедных типа aws lambda (и то не удивлюсь если там унутре все тот же кубер). _AB>Неонка там у них унутре или кубики — это не важно для команды. Важно, что они не мучаются с конфигурационными файлами кубернетеса и используют более простые интерфейсы.
Мне, кстати, интересно. Со всеми этими простыми интерфейсами не пропадает возможность в пару команд развернуть тестовое окружение со всеми сервисами на другом сервере или у разработчика на локалхосте? А то я немного с яндекс-облаком экспериментировал и не совсем понял, как это делать.
Здравствуйте, Ночной Смотрящий, Вы писали:
С>>И как же оно раньше-то делалось, во времена Squid, Apache httpd и прочих. НС>Хреново делалось, с кучей гемороя при существенно меньшей сложности.
Здравствуйте, Ночной Смотрящий, Вы писали:
V_>>1. Кубернетес хорошо работает для дома.
НС>Для дома кубер архиизбыточен, там композа за глаза.
Я предпочитаю запустить и так, чтобы само работало. Чтобы само перезапускалось, проверялось и т.п.
Композ запускает, а дальше контейнеры по воле волн плавают, чисто на рудиментарной restart policy. Или не плавают а ждут, когда хозяин их перезапустит в требуемой последовательности. А хозяин в это время сам где-нибудь, по воле волн, в отпуске, где нормального интернета нет
Не говоря уже про то, что не хочется возиться с прокси и сертификатами. Отдав это все на откуп CertManager и предпочитаемого Ingress
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Крупные банки, к примеру.
У них есть специалисты.
НС>Там нельзя вот так просто взять и поставить отдельную машину с непойми чем.
Там точно так же нельзя поставить кубик с непойми чем.
НС>Вся инфраструктура должна обслуживаться только сертифицированными спецами. Для кубера такие спецы есть, а вот для непойми что — нету.
"Непойми что" — это виртульная машина с той же осью, что и на нодах с кубиком и с докером. Нет никакой разницы в этом плане.
НС>Только если это решение специально изолировали от внешней специфики, что совсем не бесплатно. Как только у тебя появляется, скажем, оператор — все, про работу без оркестратора можно забыть.
Всё это какие-то громкие слова с нулём смысла. Т.е., может быть есть какой-то контекст, в котором эти слова смысл имеют, но это контекст есть у тебя в голове и его нет у меня.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если тебя так пугают куберовские манифесты
Меня не пугают манифесты, меня раздражает, что они работают не так, как говорит документация.
Здравствуйте, vsb, Вы писали:
vsb>Мне, кстати, интересно. Со всеми этими простыми интерфейсами не пропадает возможность в пару команд развернуть тестовое окружение со всеми сервисами на другом сервере или у разработчика на локалхосте?
Нет, не пропадает. Как только ты составишь манифест, вещи упрощаются.
А на локалке остаются докер композ файлы.
Здравствуйте, _ABC_, Вы писали:
НС>>Там нельзя вот так просто взять и поставить отдельную машину с непойми чем. _AB>Там точно так же нельзя поставить кубик с непойми чем.
Кубер там уже стоит как правило.
НС>>Вся инфраструктура должна обслуживаться только сертифицированными спецами. Для кубера такие спецы есть, а вот для непойми что — нету. _AB>"Непойми что" — это виртульная машина с той же осью, что и на нодах с кубиком и с докером. Нет никакой разницы в этом плане.
Я тебе говорю как по факту происходит. Разница есть и для клиентов принципиальная.
НС>>Только если это решение специально изолировали от внешней специфики, что совсем не бесплатно. Как только у тебя появляется, скажем, оператор — все, про работу без оркестратора можно забыть. _AB>Всё это какие-то громкие слова с нулём смысла.
Вообще не понимаю о чем ты. Я привел конкретный факт.
_AB> Т.е., может быть есть какой-то контекст, в котором эти слова смысл имеют, но это контекст есть у тебя в голове и его нет у меня.