| 1.1, Аноним (1), 09:27, 11/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– | |
Сначала думал, что за сложную логистику штука должна делать, потом вижу - кубернетес. Всё, ясно, спасибо.
Я до сих пор не понимаю, почему Kubernetes нужен.
| | |
| |
| 2.6, penetrator (?), 10:21, 11/07/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Я до сих пор не понимаю, почему Kubernetes нужен.
Потому что существует огромное количество разработчиков, выдресированных на облака.
И как только они столкнулись с реальностью, а не с cloud-native маркетингом, у них стало 2 проблемы.
- Огромная стоимость облачных ресурсов.
- Необходимость хоть как-то этот шлак масштабировать с учетом первого пункта.
Смысла без облаков в нем нет, но даже там по своей сути у них получился костыль по всем фронтам.
В качестве плюсов можно выделить автоматический деплоймент из коробки (такое же ущербное решение, но зато можно прикрутить тыц тыц и в продакшен).
Называется это всё вместе с микросервисами (которые не нужны в 80-90% проектов, но которые упорно пытаются распихать по разным инстансам в том числе в k8s) - modern stack, что по сути все равно вертикальное масштабирование, а не горизонтальное. Но на весь этот маразматический прон наяривают модно-молодежные парни. Вот так и живем.
| | |
| |
| 3.7, Аноним (1), 10:37, 11/07/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
Спасибо за развёрнутый ответ. Я только видел пыжашихся и сопящих админов, ненавидщих эту штуку, а пользы - никакой.
| | |
| |
| 4.10, Аноним (10), 12:57, 11/07/2024 [^] [^^] [^^^] [ответить]
| +7 +/– |
Но ведь в этом "развёрнутом ответе" опять только пыжащийся и сопящий админ.
| | |
| 4.15, gvf (??), 13:33, 11/07/2024 [^] [^^] [^^^] [ответить]
| –3 +/– |
Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла.
Гугл это десятки тысяч крайне дешевых компов, растыканных по всему Миру.
Управлением всем этим становится жутким гемром.
Итого.
Кубер нужен тогда когда у вас есть инфраструктура стоимость которой меньше затрат на оплату труда админов которые ее содержат. Любой вклад в уменьшение фонда з\п этой категории лиц становится прибыльным.
Если же инфраструктура стоит больше стоимости труда админов - кубер это зло.
Вот и вся экономика.
--
Следует отметить, что на Западе стоимость труда человеков квалифицированных относительно выше стоимости железа, у нас же ситуация отличается из-за заниженного курса рубля - импорт дороже стоимости рабочей силы внутри страны, а контор которым таки надо масштабировать в таких широких пределах... кроме Платформы Госуслуг и банков..... я даже припомнить не могу.
Но у этих ребят свои датацентры, Селектелом они не пользуются ))).
| | |
| |
| 5.21, Аноним (10), 16:19, 11/07/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла.
И действительно, с чего бы гугл передал его фонду CNCF? Наверное, чтобы усложнить себе жизнь, ведь из-за его возможности влиять на "нужный только гуглу" продукт резко ограничились.
Хотя, если все остальные компании-спонсоры CNCF — виртуалы гугла...
> Кубер нужен тогда когда у вас есть инфраструктура стоимость которой меньше затрат на оплату труда админов которые ее содержат.
Кубер нужен тогда, когда у админов IQ>80. Таким людям становится скучно выполнять руками рутинные операции (обновление, масштабирование, миграции) и т.д., и они начинают размышлять в духе "либо мы это автоматизируем, либо валю нафиг из этого цирка".
| | |
| |
| 6.31, noc101 (ok), 20:32, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
 >Кубер нужен тогда, когда у админов IQ>80. Таким людям становится скучно выполнять руками рутинные операции (обновление, масштабирование, миграции) и т.д., и они начинают размышлять в духе "либо мы это автоматизируем, либо валю нафиг из этого цирка".
Было бы правильно сказать.
Кубер нужен когда у тебя куча серверов, которыми надо управлять в сжатые сроки за минимальное количество деняг.
И для этого нужен админ с айкю любого ренджа.
| | |
| |
| 7.36, Аноним (10), 09:57, 13/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Боюсь, совсем уж табуреткоголовые с кубиком не справятся. Им проще shell-скриптов написать.
| | |
|
|
| 5.32, Аноним (32), 21:26, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Кубер был спроектирован в точности под нужды гугла и мало кому нужен вне самого гугла.
Довольно забавно такое слышать, поскольку в гугле кубер никогда не крутился, весь их прод работает на системе Borg. Какие задачи гугла решает кубер -- неясно
| | |
| |
| 6.33, Аноним (33), 22:24, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Borg это всего лишь mapreduce - не деплой, не оркестрация и не управление ресурсами.
| | |
|
| 5.38, yurikoles (ok), 01:53, 14/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
 > Гугл это десятки тысяч крайне дешевых компов, растыканных по всему Миру.
Привет! Как дела в 99-м?
В самом начале, Google действительно работал на самопальном кластере из дешёвого десктопного железа, которое часто умирало и покупалось оно по принципу: заменить проще, чем чинить.
Но сейчас они имеют тонны кастомного железа в нескольких десятках собственных датацентров по всему миру.
| | |
| |
| 6.39, нах. (?), 19:49, 14/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
и собирают его сами по тому же самому принципу - дешевле выкинуть чем чинить.
кастомное железо гугля - это картонка от обувной коробки и плата на ней на соплях и скотче.
собственные датацентры тоже такие же - склад морских контейнеров (возможно купленных вместе с обанкротившимся складом)
Во всяком случае это - засветилось на видео рабов гугля. А вот рядов современных стоек с современным железом никто никогда не показывал.
(оно может где-то там и есть, в небольших количествах для обслуживания собственных нужд)
| | |
|
|
|
| 3.14, Аноним (14), 13:06, 11/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
все должны быть заняты работой, иначе начнут грабить караваны
| | |
| |
| 4.30, Аноним (10), 19:09, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну, тогда кубик надо запретить. Из-за него то, что раньше делали десять бородатых одминов, теперь непринужденно выполняет один девляпс.
Итого плюс девять корованеров.
| | |
|
|
| 2.8, Видимо (?), 11:19, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
"но в отличие от него не требует наличия Kubernetes"
Та, в тексте это есть...
| | |
| 2.9, Аноним (9), 12:04, 11/07/2024 [^] [^^] [^^^] [ответить]
| +5 +/– | |
>Я до сих пор не понимаю, почему Kubernetes нужен.
Для того чтобы упростить эксплуатацию приложений для которых нужна масштабируемость и отказоустойчивость. Если тебе такие слова неведомы или у тебя одно приложение релиз которого делается раз в месяц - он тебе не нужен, а если ты каждый день релизишь по несколько приложений каждое из которых должно быть запущено в десятке экземлпяров - кубернетес это один из способов упросить себе жизнь.
| | |
| |
| 3.11, penetrator (?), 13:00, 11/07/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> для которых нужна масштабируемость и отказоустойчивость
бла-бла-бла
> Если тебе такие слова неведомы
корону не урони
> если ты каждый день релизишь
автоматизация не требует использования исключительно k8s
вопрос, а если у тебя в каждом релизе есть DDL, а СУБД - это распределенный кластер, ты его деплоймент как собрался автоматизировать? а если неудачно прошло? откатывать как будешь? особенно на успешно обновленных инстансах? а если упадет во время отката? там столько нюансов, что тема точно не для опеннета
а веб приложение может доставить встроенный в гитлаб пайплайн или ансинбл или еще что, и это не требует исключительно кубера
> каждое из которых должно быть запущено в десятке экземлпяров
прям должно? десяток виртуализированных сред с 2-4 vCPU в каждом? а может еще они у тебя все или часть на одном и том же физическом хосте? ))) с единой точкой входа извне (aka балансировщик)?
ОК, в облачной среде ты переложишь балансировщик на плечи гиперскейлера. А если тебе твое решение надо on-premise? Вот это масштабируемость технического решения ))))
не, конечно какую-то часть вертикального и даже горизонтального масштабирования он на себя возьмет, например выделение новых ресурсов под веб приложение, добавив новый инстанс, но как я и говорил, это имеет смысл только в облаках, где всю миграцию на себя берет гиперскейлер за дорого, потому что у него есть огромный пул оборудования, и за эту сомнительную (потому что у нее есть и минусы) "магию" ты 10-ти кратно переплатишь
а что делать с масштабированием СУБД?
если твое приложение не числодробилка, то основная нагрузка это данные, а не веб-сервер,
конечно очень часто код кривой и тормознутый, но тогда проблема точно не в инфраструктуре
в общем кубер может предложить только Chupa Chups в большинстве оговоренных кейсов
| | |
| |
| 4.20, Аноним (10), 16:13, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> масштабируемость и отказоустойчивость
> бла-бла-бла
Вы же понимаете, что только что признали, что делаете проекты уровня сайта-визитки? Раз уж для вас масштабируемость и отказоустойчивость — это "бла-бла-бла".
> автоматизация не требует использования исключительно k8s
Тем не менее, кубик — очень удобный инструмент автоматизации.
> вопрос, а если у тебя в каждом релизе есть DDL, а СУБД - это распределенный кластер, ты его деплоймент как собрался автоматизировать? а если неудачно прошло? откатывать как будешь? особенно на успешно обновленных инстансах? а если упадет во время отката? там столько нюансов, что тема точно не для опеннета
Ой-ой-ой, изнеженные девляпсы точно не справятся с такой задачей! Они, когда услышат про "распределенный кластер", сразу убегут (но кубик — тоже распределённый кластер? wait, oh shi~).
Если серьезно, есть различные методы реализации миграций, от встроенного flyway до k8s native решений типа atlas operator.
> если твое приложение не числодробилка, то основная нагрузка это данные, а не веб-сервер,
> конечно очень часто код кривой и тормознутый, но тогда проблема точно не в инфраструктуре
Ну да, точно. У 50-летних фуллстеков с оленями на свитерах и в голове ещё часто бизнес-логика выносится в хранимки, чтобы СУБД уж точно стала затыком. И уж точно не используются никакие кэширующие хранилища типа редиса, и бигдата не выносится в OLAP.
Тут не только кубик бессилен, но и медицина. Таблеток для повышения IQ пока не придумали.
А уж если версия N+1 накатывает миграцию, которая ломает версию N — тут только одминов в свитерах с оленями и звать :)
| | |
| |
| |
| 6.28, Аноним (10), 18:56, 11/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> у тебя проблемы с логикой, никде не написано что масштабируемость и отказоустойчивость — это "бла-бла-бла"
Вы оправдываетесь. Это мне нравится :)
> это словесный понос, который показывает что тебе сказать по сути нечего
Да, адаптируюсь под ваш стиль общения.
> это всего лишь улучшенная версия обычного апдейт скрипта аналогичного вручному написанному для единичного(!) инстанса, притом точно также твой Atlas не решит проблему
Ну да, действительно, мигратор схем БД не решает проблемы миграции схем БД. Как же никто ещё не догадался до столь очевидного вывода!
> заметь все решения что ты привел платные и стоят дополнительных денег
https://github.com/flyway/flyway
https://github.com/ariga/atlas-operator
С вам 100500 миллионов за эти секретные ссылки.
> просто твоя серверная логика безбожно тупит поэтому, от этого попытки обмазаться in-memory кешами, которые не всегда актуальны и когерентны, а еще добавляют свои ограничения и открывают новый вектор аттак, как любой дополнительный продукт в стеке технологий, но пжлста кушайте, если очень нужно
Да и про эти ваши компьютеры можно то же самое сказать. Одни сложности от них, а толку ноль. Лучше на бумажке писать и считать. В общем, типичные "аргументы" неосилятора.
> очередное твое бла бла, сказать по делу нечего, понтов два мешка, а в реальности полный 0
Это ответ на вопрос, что делать, если миграция новой версии ломает работу старой. Переформулирую — уволить разработчиков, пусть получат шанс начать карьеру в качестве дворников.
| | |
| |
| |
| 8.37, Аноним (10), 10:12, 13/07/2024 [^] [^^] [^^^] [ответить] | –1 +/– | Продолжайте оправдываться А с этими серверными линуксами, например, разве не ... большой текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.18, Аноним (18), 15:21, 11/07/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
Попробуй на него посмотреть как на стандтизованый апи от инфрасктуры
| | |
|
| 1.3, Аноним ww (?), 09:52, 11/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 А зачем оно нужно на практике? Сможет ли оно, к примеру, решить проблему, когда нужно запустить сервис-шедулер отказоустойчиво? Чтобы суммарно они отрабатывали не чаще раз в N времени, в независимости от того, упал ли кто-то или нет
| | |
|
