The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"В Debian разрешено встраивание зависимостей в пакет Kubernetes"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"В Debian разрешено встраивание зависимостей в пакет Kubernetes"  +/
Сообщение от opennews (ok), 21-Янв-21, 09:12 
Технический комитет Debian (CTTE) одобрил поставку Kubernetes в форме монолитного пакета, включающего зависимости. Kubernetes требует для своей работы большого числа библиотек на языке Go. В соответствии с правилами Debian каждая библиотека должна сопровождаться в отдельном пакете, что в случае единичного использования нецелесообразно и существенно увеличивает трудозатраты.  Кроме того, для крупных проектов наблюдается привязка к версиям библиотек, с которыми гарантируется стабильная работа. Сопровождающий Kubernetes не стал следовать правилам и встроил в пакет около 200 зависимостей на языке Go...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54444

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +7 +/
Сообщение от mos87 (ok), 21-Янв-21, 09:12 
Вечная борьба между "всё своё ношу с собой" и "у нас тут коммуналка, извольте юзать общее - с пропатченными уязвимостями и вообще работающее в унисон со всем остальным"
И второе проигрывает. Правда суть всех дистрибов именно в этом. Так что вот...
Ответить | Правка | Наверх | Cообщить модератору

27. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от rshadow (ok), 21-Янв-21, 13:08 
Конечно проигрывает. Но в основном для вот таких web-монстров. Культура поставки в дистрибудивах все так же на низком уровне в среде web-программистов. Хуяк-хуяк и в продакшн, ручками разложить.
Для пользователей и адекватного софта все так же лучше библиотеки.
Ответить | Правка | Наверх | Cообщить модератору

37. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от УшныеРаковиныЛинуса (?), 21-Янв-21, 14:19 
Для Java нужно вводить тоже самое. Теже IDE будет проще поддерживать, а то имеем: Debian 8 Eclipse старый, Debian 9 Eclipse той же версии, что и в Debian 8, а это более 4 лет.
Ответить | Правка | Наверх | Cообщить модератору

41. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от mos87 (ok), 21-Янв-21, 15:05 
лучше, когда 1 базовый дистр с циклами смены версий скажем год, 2, 5, 10.
а как сейчас - не лучше.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

2. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –3 +/
Сообщение от FortyTwo (ok), 21-Янв-21, 09:14 
А как не прогнуться?  RH сказала, проголосовали.
Ответить | Правка | Наверх | Cообщить модератору

3. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +3 +/
Сообщение от Леголас (ok), 21-Янв-21, 09:18 
Golang, Rust, JS... Такие особенные, современные, к ним нужен специальный подход. И если какого-нибудь flatpak им недостаточно, то всё равно будут делать по-своему.
Ответить | Правка | Наверх | Cообщить модератору

32. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (32), 21-Янв-21, 13:26 
Вот тут ты прав, именно особенные и именно современные, потому что заточены под нужды современной инфраструктуры и практик. Большие развесистые системы, которые делают своё дело. Ты много систем управления кластерами на Сях написал с таким же количеством фич как Kubernetes ну или хотя бы унылый Swarm? Мне кажется ответ на вопрос - 0.
Ответить | Правка | Наверх | Cообщить модератору

36. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Леголас (ok), 21-Янв-21, 14:07 
> Ты много систем управления кластерами на Сях написал с таким же количеством фич как

ни то что на Сях, а вообще ни на чём, и с любым количеством фич (:

Ответить | Правка | Наверх | Cообщить модератору

38. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +8 +/
Сообщение от Аноним (-), 21-Янв-21, 14:19 
>нужды современной инфраструктуры и практик

Хуяк-хуяк и в продакшн

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

59. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –2 +/
Сообщение от Аноним (59), 21-Янв-21, 20:25 
> Такие особенные, современные, к ним нужен специальный подход
> Golang, Rust, JS

Озвученные тобой платформы уже имеют собственный менеджер зависимостей. А дистрибутивный пригождается там, где у языка нет какого-то центрального единого менеджера (C/C++). И то, что дистры наконец в 2021 стали догадываться, что не стоит дублировать репозитории пакетов у себя, не может не радовать.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

70. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (70), 22-Янв-21, 02:54 
Собственный менеджер пакетов языка пригождается когда нужно возиться в своей маленькой песочнице и за её пределы не вылезать, и при этом не страшно скачать троян или сломанный пакет. А дистрибутивы как раз пакетят модули на раз - и ноду, и rust и даже go. Не говоря даже о всяких там питонах. Потому что конечному пользователю должно быть наплевать на каком языке что написано - ему нужно обновить всё установленное ПО централизовано, и особенно чтобы при этом компоненты на разных языках зависящие друг от друга (типа питоновских биндингов к rust либам) не поломались. Конечно же внутриязычковые инфраструктуры этого не умеют и никогда не сумеют. Но вот развесистые деревья зависимостей - это да, беда, и к великому сожалению единственный выход пока - бандлить.

Но не волнуйтесь, это быстренько запретят как только выстрелит критическая уязвимость в каком-нибудь модульке который успели несколько десятков проектов забандлить. А потом может быть начнут появляться инструменты интеграции язычкопакетов в нормальные репозитории.

Ответить | Правка | Наверх | Cообщить модератору

73. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от J.L. (?), 22-Янв-21, 03:30 
> А потом может быть начнут появляться инструменты интеграции язычкопакетов в нормальные репозитории.

да давно появились
вот например собрать java-приложение в nixpkg
https://discourse.nixos.org/t/help-packaging-a-java-app/3871

Ответить | Правка | Наверх | Cообщить модератору

72. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от user (??), 22-Янв-21, 02:57 
Для этих любителей "curl | sh" нужен специальный мусорный бак.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

4. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от Аноним (4), 21-Янв-21, 09:18 
скатились теперь будет куча дублей пакетов, в разных пакетах
Ответить | Правка | Наверх | Cообщить модератору

5. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Zruslan (ok), 21-Янв-21, 09:39 
Ну да, нынче место на дисках дешёвое
Ответить | Правка | Наверх | Cообщить модератору

31. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Аноним (32), 21-Янв-21, 13:24 
И оперативку на помойке можно найти, да? Разные файлы - разные маппинги в память одного и того же кода.

Это никак не относится к Kubernetes, конечно, т.к. в Go иная структура приложения. Но ваш поинт...

Ответить | Правка | Наверх | Cообщить модератору

34. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от aimemail (ok), 21-Янв-21, 13:41 
вы, конечно, правы. однако вряд ли существенно сократится количество памяти - вряд ли вы на хосте будете с k8s что-то ещё запускать.
Ответить | Правка | Наверх | Cообщить модератору

46. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Ordu (ok), 21-Янв-21, 17:03 
Эксперименты с compile-time полиморфизмом в стиле темплитов C++, показывают что этот полиморфизм не сильно влияет на расход оперативки. В 90-х я помню переживали из-за того, что много копий кода возникает под разные типы. Данные, с которыми код работает, занимают гораздо больше места, чем сам код. И чем дальше, тем больше разрыв. На сильно low-end системах, типа встраиваемых, где оперативка исчисляется килобайтами или метрами ситуация может быть иной, но туда никто в здравом уме не будет ставить дистрибутив общего назначения. -Os ведь практически не используется, куда ни сунься везде -O2 или -O3.

Я подозреваю, что здесь та же ситуация выйдет.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

71. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от J.L. (?), 22-Янв-21, 02:54 
> Эксперименты с compile-time полиморфизмом в стиле темплитов C++, показывают что этот полиморфизм
> не сильно влияет на расход оперативки. В 90-х я помню переживали
> из-за того, что много копий кода возникает под разные типы. Данные,
> с которыми код работает, занимают гораздо больше места, чем сам код.
> И чем дальше, тем больше разрыв. На сильно low-end системах, типа
> встраиваемых, где оперативка исчисляется килобайтами или метрами ситуация может быть иной,
> но туда никто в здравом уме не будет ставить дистрибутив общего
> назначения. -Os ведь практически не используется, куда ни сунься везде -O2
> или -O3.

а кеш проца у вас тоже резиновый? помнится были результаты, что оптимизированый по размеру бинарь обгонял по скорости выполнения оптимизированый по скорости за счёт более частого/полного укладывания кода в кеш

Ответить | Правка | Наверх | Cообщить модератору

83. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Ordu (ok), 22-Янв-21, 11:19 
> а кеш проца у вас тоже резиновый? помнится были результаты, что оптимизированый
> по размеру бинарь обгонял по скорости выполнения оптимизированый по скорости за
> счёт более частого/полного укладывания кода в кеш

Это действительно хорошо работает на тесных циклах, когда тебе за счёт -Os удастся уложить цикл в кеш полностью. Но ты сменишь процессор, там кеша будет чуть меньше или чуть больше, и весь смысл пропадёт.

Плюс если речь идёт о разных программах, то есть о разных процессах, там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо, что эффект если и будет, то минимальным, на уровне статистической погрешности.

Ответить | Правка | Наверх | Cообщить модератору

92. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от J.L. (?), 24-Янв-21, 04:05 
> там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо,
> что эффект если и будет, то минимальным, на уровне статистической погрешности.

на сколько я помню - это были реальные результаты тестов фаерфокса лет 10-15 назад - оптимизированый по памяти работал быстрее чем по скорости

Ответить | Правка | Наверх | Cообщить модератору

93. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Ordu (ok), 24-Янв-21, 10:19 
>> там кеш будет очень хорошо слетать при переключении процессов, настолько хорошо,
>> что эффект если и будет, то минимальным, на уровне статистической погрешности.
> на сколько я помню - это были реальные результаты тестов фаерфокса лет
> 10-15 назад - оптимизированый по памяти работал быстрее чем по скорости

Очень сложно рассуждать о тестах, не видя методики. Любая статистика в отрыве от методики сбора данных и обработки их -- это та самая статистика, которая за пределами лжи.

Ответить | Правка | Наверх | Cообщить модератору

7. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –3 +/
Сообщение от Аноним (7), 21-Янв-21, 09:49 
Чтобы не было дублей, не используйте эти пакеты. Используйте только те, где дублей нет. Перед установкой, каждого пользователя спрашивают: вы согласны установить эти пакеты, которые займут столько места на вашем диске? Когда вы соглашаетесь, вы несёте ответственность за свой выбор и одобряете подход этого продукта. Если же это не так, то вы можете ответить "нет".
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

10. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от пох. (?), 21-Янв-21, 09:55 
Не будут, их для этого надо все пересобрать в ту же секунду, одновременно.
Если пересобрать один на секунду позже - в него притащит новые версии половины зависимостей-зависимостей-от-зависимостей. Модная современная разработка.

С разработчиком, сидящим под б-жественной десяточкой, и слыхом не слыхавшего о том что бывает еще какое-то управление пакетами, кроме встроенного в нескучный язычок, скачивающее весь интернет.

В основном - состоящий из лефтпадов, разумеется.

К тому же, не переживай, модные-современные язычки все равно с трудом умеют в разделяемые библиотеки, и вся эта мусорка в любом случае не будет использована в разделяемом режиме.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +5 +/
Сообщение от Тов Майор (?), 21-Янв-21, 09:42 
Go продукты на столько инклюзивные что требуют монолитной поставки ввиду конфликтов со всеми остальными.
Забавно что ровно токая же проблема тотальной нетерпимости наблюдается у их инклюзивных создателей.
Ответить | Правка | Наверх | Cообщить модератору

20. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от anonymous (??), 21-Янв-21, 11:54 
> требуют монолитной поставки ввиду конфликтов со всеми остальными.

Про что речь? Просто компилятор в Go собирает статически, that's it.

Ответить | Правка | Наверх | Cообщить модератору

33. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +3 +/
Сообщение от Аноним (33), 21-Янв-21, 13:40 
Раньше так было, а теперь может и динамически
Ответить | Правка | Наверх | Cообщить модератору

8. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +4 +/
Сообщение от Аноним (8), 21-Янв-21, 09:54 
Зачем? Кому такое говно нужно - пусть пользуются снапом.
Ответить | Правка | Наверх | Cообщить модератору

11. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от пох. (?), 21-Янв-21, 09:58 
жуто боятся, что донейтов в этом году не будет вообще - "кому он нужен, ваш дерьмиан, там ДАЖЕ k8s нет в поставке дистрибутива, представляете, какя бесполезная хрень!"

Поэтому логичнейшая идея переложить поддержку этой поделки на ее особо одаренных и богатых ресурсами разработчиков, увы, не прокатит.

> пусть пользуются снапом.

ты дистрибутивы перепутал - это к бубунточке, те по другому уже разучились.

Ответить | Правка | Наверх | Cообщить модератору

16. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Иноагент (?), 21-Янв-21, 10:51 
>ты дистрибутивы перепутал - это к бубунточке, те по другому уже разучились.

Ну так по топику выходит, что правильно сделали ))
Нужно обладать талантом предвидения, что космонавт и продемонстрировал.

Ответить | Правка | Наверх | Cообщить модератору

66. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (8), 21-Янв-21, 21:53 
>ты дистрибутивы перепутал - это к бубунточке

А это что такое? https://packages.debian.org/bullseye/snapd

>те по другому уже разучились.

У тех большая часть пакетов - из дебиана.

>жуто боятся, что донейтов в этом году не будет вообще - "кому он нужен, ваш дерьмиан, там ДАЖЕ k8s нет в поставке дистрибутива, представляете, какя бесполезная хрень!"

А в чём проблема при установке апт-пакета для k8s ставить снап и в нём уже ставить говно? Зачем засирать димтр? Ведь снап как раз для таких неосиляторов загон, чтобы дистр не дасирали.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

9. Скрыто модератором  –1 +/
Сообщение от Аноним (9), 21-Янв-21, 09:54 
Ответить | Правка | Наверх | Cообщить модератору

18. Скрыто модератором  –1 +/
Сообщение от Аноним (18), 21-Янв-21, 11:18 
Ответить | Правка | Наверх | Cообщить модератору

12. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Совсем не анонимemail (?), 21-Янв-21, 10:12 
В Убунте давно в snap поставляются части кубера
Ответить | Правка | Наверх | Cообщить модератору

47. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +3 +/
Сообщение от Анонии (?), 21-Янв-21, 17:36 
И как оно? За час успевает запуститься?
Ответить | Правка | Наверх | Cообщить модератору

13. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –2 +/
Сообщение от ryoken (ok), 21-Янв-21, 10:27 
Поясните, а что такое вообще, этот ваш Kubernetes? С целью повышения уровня образованности.
Ответить | Правка | Наверх | Cообщить модератору

15. Скрыто модератором  +/
Сообщение от Аноним (15), 21-Янв-21, 10:44 
Ответить | Правка | Наверх | Cообщить модератору

42. Скрыто модератором  +1 +/
Сообщение от Аноним (42), 21-Янв-21, 15:13 
Ответить | Правка | Наверх | Cообщить модератору

57. Скрыто модератором  +/
Сообщение от InuYasha (??), 21-Янв-21, 20:22 
Ответить | Правка | Наверх | Cообщить модератору

22. Скрыто модератором  +2 +/
Сообщение от Gemorroj (ok), 21-Янв-21, 12:15 
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

58. Скрыто модератором  –1 +/
Сообщение от Аноним (59), 21-Янв-21, 20:24 
Ответить | Правка | Наверх | Cообщить модератору

23. Скрыто модератором  +5 +/
Сообщение от Штыбель (?), 21-Янв-21, 12:26 
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

25. Скрыто модератором  +3 +/
Сообщение от пох. (?), 21-Янв-21, 12:53 
Ответить | Правка | Наверх | Cообщить модератору

26. Скрыто модератором  +/
Сообщение от Ketalar (ok), 21-Янв-21, 13:02 
Ответить | Правка | Наверх | Cообщить модератору

28. Скрыто модератором  +1 +/
Сообщение от пох. (?), 21-Янв-21, 13:12 
Ответить | Правка | Наверх | Cообщить модератору

52. Скрыто модератором  +/
Сообщение от freehckemail (ok), 21-Янв-21, 18:26 
Ответить | Правка | Наверх | Cообщить модератору

78. Скрыто модератором  +/
Сообщение от пох. (?), 22-Янв-21, 09:35 
Ответить | Правка | Наверх | Cообщить модератору

67. Скрыто модератором  +/
Сообщение от Аноним (8), 21-Янв-21, 22:18 
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

35. Скрыто модератором  +1 +/
Сообщение от Аноним (35), 21-Янв-21, 14:01 
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

48. Скрыто модератором  +1 +/
Сообщение от Wilem82 (?), 21-Янв-21, 18:05 
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

50. Скрыто модератором  +2 +/
Сообщение от Аноним (50), 21-Янв-21, 18:21 
Ответить | Правка | Наверх | Cообщить модератору

54. Скрыто модератором  –1 +/
Сообщение от freehckemail (ok), 21-Янв-21, 18:35 
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

55. Скрыто модератором  +2 +/
Сообщение от Аноним (50), 21-Янв-21, 18:55 
Ответить | Правка | Наверх | Cообщить модератору

56. Скрыто модератором  +/
Сообщение от freehckemail (ok), 21-Янв-21, 18:57 
Ответить | Правка | Наверх | Cообщить модератору

74. Скрыто модератором  +1 +/
Сообщение от Wilem82 (?), 22-Янв-21, 03:32 
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

82. Скрыто модератором  +1 +/
Сообщение от freehckemail (ok), 22-Янв-21, 10:43 
Ответить | Правка | Наверх | Cообщить модератору

51. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от freehckemail (ok), 21-Янв-21, 18:22 
> Поясните, а что такое вообще, этот ваш Kubernetes? С целью повышения уровня образованности.

Kubernetes aka k8s -- это система управления кластером для контейнеров. По факту -- это протокол, формализующий процессы, происходящие в датацентре.

Выглядит примерно следующим образом: ты объединяешь несколько машин в кластер куба, а затем начинаешь работать на более высоком уровне, таком как сервисы, дейплойменты, стейтфулсеты, и так далее. Всё, что ты определишь, будет автоматически зашедулено на произвольную ноду (если ты не прибиваешь к конкретным), будет удобно доступно через CNI, и будет мониториться и поддерживаться в этом состоянии, что бы ни произошло с нодами: то есть если одна из нод приляжет по какой-нибудь причине, твоё добро будет автоматом перераспределено.

Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче. Особенно в этом помогают то, что многие общепринятые практики уже включены в кубере по умолчанию.

Что бы там ни говорили, но основной рынок IT и дальнейшее развитие нашей отрасли постепенно уходят именно туда.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

62. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от Аноним (50), 21-Янв-21, 21:02 
> но основной рынок IT и дальнейшее развитие нашей отрасли

Не основной, а лишь один из сегментов рынка массового потребителя IT, вернее, заказчика вычислительных ресурсов. Это большая толпа мелких, поднимающих нжинксы с апачиками в нескольких vds-ках в облачках. Вот для желающих делать деньги на таких, kuber-ы и docker-ы и существуют. Kuber-это инфраструктура облачного провайдера. Не больше, и не меньше. Глючная шо пипец, требующая команды для поддержания работоспособности. Но упомянутый рынок vds-ок, это, мягко говоря, не есть вся "наша отрасль". Это  один из его многочисленных сегментов. Причём, один из таких сегментов, который "на виду", в который зайти может каждый, хоть провайдером, хоть клиентом. Это такой базарчик в мире IT. В IT есть более интересные отрасли, и более денежные, но это для профи, и войти туда сильно сложнее, чем в мир вебок и облачков.

Ответить | Правка | Наверх | Cообщить модератору

77. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от freehckemail (ok), 22-Янв-21, 09:33 
> Это большая толпа мелких, поднимающих нжинксы с апачиками в нескольких vds-ках в облачках.

Ну, что тут сказать. Вы имеете очень превратное представление о том, кто является клиентом этих решений. Именно тем, кого Вы перечислили, куб как собаке третья нога. А используют его рыбы горааааздно крупнее. =)

Ответить | Правка | Наверх | Cообщить модератору

85. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от Аноним (50), 22-Янв-21, 14:03 
Рыбы гораздо крупнее используют собственные вещи, вроде nitro system, или майнфремы юзают. А кубер как раз для мелочи пузатой, вроде redhat-а c его openshift.
Ответить | Правка | Наверх | Cообщить модератору

86. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (50), 22-Янв-21, 14:06 
Бро, поддерживаю. И про небходимость HA логики в самом приложении, и про минимум всякого стороннего дерьма, от которого зависит работа приложения.
Ответить | Правка | Наверх | Cообщить модератору

75. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +5 +/
Сообщение от Wilem82 (?), 22-Янв-21, 03:56 
> Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче.

В реальности это не облегчает HA. 99% всего HA - это логика самого софта, у которого нет единой точки отказа, который сам умеет ходить на несколько адресов, если один из сервисов недоступен, который использует базу данных умеющую собственный кластер. Если софт этого не умеет, то кубер тебе ничем не поможет.

А 1%, про который ты говоришь - это добавление физического сервера или создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов и амазонов. Известна нормальная нагрузка, всегда есть запас на случай багов в софте или в случае публичного сервиса на случай подарков от отдела маркетинга. Ну и если тебе раз в месяц понадобилось добавить виртуалку у тебя есть ансибл, который это сделает одной командой.

А вот вреда от кубера и докера довольно много. Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь, что система должна быть максимально простой - минимум абстракций, прослоек. Чем проще технологический стек, тем проще программистам и поддержке предсказывать возможные ситуации на проде, а также чинить поломки.

Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой. Если что-то случилось, тебе помимо обычной головной боли о самом приложении надо ещё думать - а не докер ли тут виноват?

И такая же ситуация с кубером, только большего масштаба. Это охереть какая сложная система, и каждый раз думать кубер это виноват или докер или проблема где-то ещё лежит - нахера это надо? Кому и зачем?

Плюс всё это говно надо обновлять, поддерживать, находить какие-то костыли для ситуаций, когда кубер только мешает и так далее.

Не, я понимаю что технология интересная, но любое усложнение системы должно быть очень хорошо обосновано, и если ты не облако мирового масштаба, то обосновать ты ничего не сможешь.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

79. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от freehckemail (ok), 22-Янв-21, 09:41 
> Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь...

Хе =)

Ответить | Правка | Наверх | Cообщить модератору

80. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от пох. (?), 22-Янв-21, 09:50 
> А 1%, про который ты говоришь - это добавление физического сервера или
> создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов

В чем проблема-то? Это обычно не автоматизируют сверх меры просто потому что сервер все равно сам в стойку не запрыгивает, и взять его неоткуда. А после кручения двадцати гаек уже можно и пару раз enter нажать, хотя и необязательно.

Вариант "переустановить и перезагрузить" обычно для любителей лепки из г-на, у остальных он случается раз в пятилетку, и опять же незачем тратиться на автоматизацию.

> А вот вреда от кубера и докера довольно много. Ты видимо не
> программист, а админ, и поэтому не знаешь и не понимаешь, что

наоборот. Потому что весь смысл там - уволить нахрен админа, и нанять еще больше программистов-на-нодежс.

> система должна быть максимально простой - минимум абстракций, прослоек. Чем проще

она и есть простая - клик-клик-клик в интуитивно понятненьком междумордии впопеншифта.
Любой менеджер справится.

А "добавлять в кластер" можно хоть вручную, это и программисту доступно.

> Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой.

не нравится, используй модную молодежную btrfs. Удалял я тут с нее нагаженных докер-контейнерами пару гигабайт - уже успел забеспокоиться, оно там повисло или чо. Не, все норм, просто остальные системы были с ext4, там это мгновенно.

Впрочем, согласно талмуду редбиэма, вроде, полагается raw lvm2 (но там, собственно, и от доскера уже ушли в пользу своих наколенных реализаций OCI).

> если ты не облако мирового масштаба, то обосновать ты ничего не сможешь.

смари, смари - у облаков мирового масштаба - во! Срочно внедрить у нас!

this never fails

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

84. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (-), 22-Янв-21, 13:37 
> Ты видимо не программист, а админ

Ожидал такой спич услышать как раз от админа. Прогеры как раз докером обмазываются на раз - насpал в контейнер и готово. А админу потом с этим жить и работать.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

87. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Аноним (50), 22-Янв-21, 14:33 
>Прогеры как раз докером обмазываются

Я бы попросил. В приличном обществе за докер можно и в репу схлопотать. Ну модно-молодёжные любят, да. Но у них там ничего серьёзного и нет, так что и докер прокатит.

Ответить | Правка | Наверх | Cообщить модератору

88. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (50), 22-Янв-21, 14:36 
Бро, поддерживаю. И про небходимость HA логики в самом приложении, и про минимум всякого стороннего дерьма, от которого зависит работа приложения.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

89. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от freehckemail (ok), 22-Янв-21, 18:14 
>> Это позволяет тебе абстрагироваться от лимитов конкретной системы, и строить HA-аппликации гораздо легче.
> В реальности это не облегчает HA. 99% всего HA - это логика
> самого софта, у которого нет единой точки отказа, который сам умеет
> ходить на несколько адресов, если один из сервисов недоступен, который использует
> базу данных умеющую собственный кластер. Если софт этого не умеет, то
> кубер тебе ничем не поможет.

Короче -- софт должен быть интегрирован с service discovery, который вы выбрали при проектировании системы. Ну дык, как будто это какая-то особенная логика. Нынче иначе и не проектируют. Но честное слово, это простая интеграция с zookeeper / etcd (или даже через банальный dns), о каких 99% речь?

> А 1%, про который ты говоришь - это добавление физического сервера или
> создание виртуалки. На практике никто этим постоянно не жонглирует кроме гуглов
> и амазонов. Известна нормальная нагрузка, всегда есть запас на случай багов
> в софте или в случае публичного сервиса на случай подарков от
> отдела маркетинга. Ну и если тебе раз в месяц понадобилось добавить
> виртуалку у тебя есть ансибл, который это сделает одной командой.

Клиент идёт в облака за удобством и дешевизной. Вот взгляни на тот же амазон. Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада. Так что в итоге получается дешевле, чем vds-ки арендовать или же тем более -- чем держать запас, как Вы предлагаете.

> А вот вреда от кубера и докера довольно много. Ты видимо не
> программист, а админ, и поэтому не знаешь и не понимаешь, что
> система должна быть максимально простой - минимум абстракций, прослоек. Чем проще
> технологический стек, тем проще программистам и поддержке предсказывать возможные ситуации
> на проде, а также чинить поломки.

Да, система должна быть максимально простой. Вот только тут важно понимать, что такое "просто". Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации. Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает.

Плюс к тому, тут важен и социальный аспект. Сейчас уже не начало нулевых, сейчас двадцатые пошли. IT стал массовым явлением. Большинство developers -- из разряда "почему это я не могу создать 10 тысяч файлов в одной директории". Большинство operations engineers -- из разряда "я хз, что там случилось, если рестарт не поможет, то напишу в супорт". Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции.

> Докер, к примеру, использует overlayfs, который в свою очередь кривой и косой.
> Если что-то случилось, тебе помимо обычной головной боли о самом приложении
> надо ещё думать - а не докер ли тут виноват?

Да, с overlayfs было много косяков в своё врмя. Но во-первых уже давно сделали overlay2, который более стабилен, и меньше удивляет своим поведением, а во-вторых не одним оверлеем докерные storage driver-ы живы. Я держал на zfs например. Слышал, что некоторые на btrfs-е гоняли. Плюс к тому, некоторые вон просто блочное устройство в контейнер прокидывают, и сервис с ним делает что хочет, безо всяких там прослоек fs. Mount-ы из хост-системы работают по схожему принципу, так что в принципе ничто не мешает вам гонять postgresql или ноду btc таким макаром, вообще не связываясь с оверлеем.

> И такая же ситуация с кубером, только большего масштаба. Это охереть какая
> сложная система, и каждый раз думать кубер это виноват или докер
> или проблема где-то ещё лежит - нахера это надо? Кому и
> зачем?

Ну это тонкий момент, и я с вами даже частично соглашусь. Если нам нужна производительность, то я безусловно за вынос стейтфулов за пределы куба. Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб. Если мы говорим про стейтлесс, спроектированный как twelve factor app, то в куб однозначно.

> Плюс всё это говно надо обновлять, поддерживать, находить какие-то костыли для ситуаций,
> когда кубер только мешает и так далее.

Вы тут заблуждаетесь. Обновления в кубе как раз гораздо проще. Вы просто прописываете новую версию чарта в helmfile и деплоитесь. Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам. Вот давеча мне потребовалось увеличить message.max.size в кафке. Я просто инкрементировал число в конфиге и применил новую конфигурацию кластера. Kafka-operator это дело подхватил, и сам последовательно применил к каждой ноде, причём по очереди, чтобы не было даунтайма. Операторы вообще сейчас повально для всего пишутся и хорошо поддерживаются.

> Не, я понимаю что технология интересная, но любое усложнение системы должно быть
> очень хорошо обосновано, и если ты не облако мирового масштаба, то
> обосновать ты ничего не сможешь.

Я думаю, что мне вполне удалось это сделать. "Не мужчина, а облако в штанах". =)

PS:
> Ты видимо не программист, а админ, и поэтому не знаешь и не понимаешь

1) Не админ, а опс
2) Перешёл в эту сферу аккурат из разработки

=)

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

90. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Wilem82 (?), 23-Янв-21, 06:30 
> Короче -- софт должен быть интегрирован с service discovery

Не обязательно. Что обязательно, так это механизм повторных запросов. SD может выдать нерабочий адрес, а значит повторы на клиенте всё равно должны быть реализованы - это всё надо запрогать.

Кроме того, все компоненты должны иметь избыточность, а значит не могут иметь состояния, влияющего на исход, т.е. должны быть равноправны и взаимозаменяемы - это надо продумывать и прогать наперёд, а то потом устанешь переделывать систему.

Плюс все эти компоненты должны уметь останавливаться или наоброт просыпаться, при failover-е на другой DC к примеру. Переодические процессы, обработка входящего трафика и так далее.  Graceful shutdown, выход из standby - самые слабые места, такие вещи всегда задним числом пытаются прикрутить и делают это криво.

Плюс все эти компоненты должны уметь backpressure и fail-fast, что бы не умирать под нагрузкой. А это тоже надо отдельно прогать и проектировать.

И нет, "все так проектируют" неверный тезис, так проектируют очень немногие, а точнее почти никто. Обычно есть некое говно в котором никогда в жизни не было HA, и вдруг принимают решение HA таки сделать (то есть всё вышеозначенное и больше). Если у тебя приложение уже готово к тому, что все компоненты можно размножить, нет единой точки отказа, работают всевозможные фейловеры - ну, через пару лет, когда ты всё это запрогаешь и протестируешь - вот тогда ты можешь якобы облегчить себе жизнь тем, что деплоить эти компоненты за тебя будет не ансибл, а кубер. И виртуалки он же создавать. Но сначала всё равно придётся перелопатить всю архитектуру продукта, что бы быть к этому готовым.

> Если смотреть на их EC2-инстансы, то они выходят дороже vds-ок. Но они предоставляют возможность легко и непринуждённо скейлиться на лету в зависимости от загрузки ворклоада.

Если приложение уже к этому готово, если оно вообще может скейлиться - да. Но скейлинг != HA. И этот аргумент работает только там, где нагрузка реально сильно скачет. Если мы говорим о внутренних сервисах компании, то там вся нагрузка известна и стабильна. Если о публичных, то обычно тоже стабильна, правда какая-нибудь особо удачная реклама или промо-акция может создать аномальный пик. Но тут надо осторожно - это может быть и ддос, и чей-то кривой скрипт. Ты не хочешь автоматически скейлится под ддос, ддос всё равно победит. Поэтому нужно ли тут мега-быстрое, автоматическое наращивание серверов - спорный момент, от продукта зависит. Да, админ руками это сделает не так быстро, но всё равно через ансибл. То есть речь только про время принятия человеком решения, остальное всё равно автоматика сделает.

> Абстракции данного уровня упрощают понимание архитектуры приложения, что уменьшает количество ошибок при реализации.

Кубер никак не связан с архитектурой приложения вообще. Это такая накрутка сверху которая тебе виртуалку создаст и контейнеры запустит. Он по определению вообще ничего про архитектуру приложения не знает и знать не может. То, что запускается под кубером также запускается и без кубера, при этом вообще без изменений кода. Что бы как намекает.

> Да, добавляется прослойка. Но зато у нас есть чёткое понимание, где что находится, и кто за что отвечает.

У тебя есть продукт, про который ты должен понимать где что находится и кто за что отвечает. От продукта ты избавиться не можешь, эта часть по-любому есть. А потом сверху этого у тебя ещё появляется кубер, который начинает мутить воду с миллионами ресурсов, контроллерами этим ресурсов, кластером etcd, собственными особенностями работы, правилами поведения и так далее. И ещё тебе и сам кубер надо сделать HA.  То есть у тебя будет голова за кластер etcd болеть, за куберовский HA, за все эти манипуляции с сетевым трафиком, за прокси которые сервисы ресолвят и так далее, плюс за весь продукт который внутри этого всего запущен.

> Эти абстракции разделяют их уровни ответственности, чтобы бизнес мог поднять сложные HA-решения даже обладая специалистами такого уровня, ибо каждый из них работает со своим уровнем абстракции.

Эти разделения существуют и без кубера прекрасно. А специалисты "такого уровня" всё равно ничего толком не сделают, хоть с кубером хоть без.  Только с кубером им будет ещё сложнее разобраться в проблемах на продакшене, т.к. технологий становится больше, сложность понимания всё это внутри устроено возрастает. Ну реально, возьми доку на Кубер, прочитай там всё, потом наберись кучу опыта работы с ним и посмоти на эти накопленные знания. Есть наверно разница - всё это себе в голову заливать, или нет?

> Но во-первых уже давно сделали overlay2

Есть у тебя виртуалка - запускай там софт. Докер-то зачем? В тестовом окружении - офигенно удобно. На проде - зачем?

> Но если нам важно удобство эксплуатации и скорость развёртывания -- то за куб

На продакшене в первую очередь всегда стоит надёжность и скорость решения проблем. Чем короче путь от юзера до бизнес-логики и чем он проще, предсказуемее и понятнее - тем быстрее и легче будет решена проблема.  Кубер делает кучу магии - сам меняет правила iptables, например. Админам и программистам точно нужна эта головная боль? Я понимаю ценность виртуальных адресов, и это действительно одно из возможных решений, но далеко не единственное и не лучшее.

Вы, такое ощущение, что рассуждаете о простоте с точки зрения когда всё само собой магически работает. Это-то как раз мало кому интересно - когда всё работает. Вопрос что делать когда оно работать перестало. И именно к такой ситуации продукт должен быть максимально готов.

Это как какой-нибудь Hibernate - херак херак он за тебя миллион селектов сгенерил, во как круто. А потом что-то сломалось. И как это чинить непонятно - устанешь понимать все нюансы его работы, что бы вычислить в чём проблема.

> Обновления в кубе как раз гораздо проще.

Я про обновление самого Кубера. Который зависит от докера. И от каких-то кусков линукса типа iptables. И самого докера. И ядра, от которого зависит докер.

> Обновить конфигурацию синхронно и без даунтайма -- тоже легче, благодаря операторам.

Не знаю что такое операторы, но если сами приложения не поддерживают конфигурирование через кластер, то непонятно как может быть что-то проще, чем запуск одной команды ansible, которая тоже кусками, последовательно запушит конфиги и перезапустит приложения? Что и зачем тут надо упрощать? :)

> Не админ, а опс

Да ладно, хипстерская тема какая-то, все знают что Operations - т.е. служба эксплуатации по-русски - это админы. :)

Ответить | Правка | Наверх | Cообщить модератору

91. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от freehckemail (ok), 23-Янв-21, 13:17 
Окей, меня полностью устраивает Ваша позиция. Желаю Вам удачи. Продолжим это столкновение взглядов, когда/если встретимся на рынке. =)
Ответить | Правка | Наверх | Cообщить модератору

14. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от Аноним (14), 21-Янв-21, 10:42 
Могли бы просто не паковать это, если там такой бардак. Всё равно будут ставить с сайта разработчика.
Ответить | Правка | Наверх | Cообщить модератору

29. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от пох. (?), 21-Янв-21, 13:15 
> Могли бы просто не паковать это, если там такой бардак. Всё равно
> будут ставить с сайта разработчика.

говорят же ж тебе - будет вонь что "дебиан не поддерживает (даже!) модный-современный k8s!", донейт упадет еще ниже.

Ответить | Правка | Наверх | Cообщить модератору

40. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от Аноним (40), 21-Янв-21, 14:54 
Сделать метапакет, который скачал install.sh с сайта кубернетиса и запустит )
Ответить | Правка | Наверх | Cообщить модератору

45. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от пох. (?), 21-Янв-21, 16:34 
дык такой уже есть, wget называетсо.

Ответить | Правка | Наверх | Cообщить модератору

60. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  –1 +/
Сообщение от InuYasha (??), 21-Янв-21, 20:26 
Хотел сперва сказать "да выкиньте этот Пубернетис нахрен", но ваша идея мне очень понравилась. Пусть пубер-клёпщики сами ощутят на себе всю тяжесть своего гомна. )
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

19. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Аноним (19), 21-Янв-21, 11:30 
В чем проблема собрать статичный бинарь вместо 200? В Go одним ключом решается
Ответить | Правка | Наверх | Cообщить модератору

21. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от anonymous (??), 21-Янв-21, 11:59 
В Go и есть статичные бинарии, коих в k8s больше одного. Но как-то сильно сомневаюсь, что их там 200. Возможно речь про пакеты с исходными кодами зависимостей?
Ответить | Правка | Наверх | Cообщить модератору

24. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +2 +/
Сообщение от Анончик (?), 21-Янв-21, 12:43 
Ты зачем такое говоришь? Еще скажи что у разработчиков гугла плохо с зависимостями, на замечательном языке гугла https://github.com/kubernetes/kubernetes/blob/master/go.sum

Плебс совсем от рук отбился, нет у них веры в гугл и царя.

Ответить | Правка | Наверх | Cообщить модератору

53. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от freehckemail (ok), 21-Янв-21, 18:28 
> Но как-то сильно сомневаюсь, что их там 200.

Ты что, не знаешь, что "kubernetes -- это всего пять бинарей"? =)

А по факту, на самом деле достаточно kubeadm, kubectl и kubelet. Остальное один фиг в контейнерах живёт.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

30. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от JL2001 (ok), 21-Янв-21, 13:21 
всё, накрылась концепция пакетов в дебиане?

а был бы nixpkg - мантейнер Kubernetes прописывал бы нужные версии зависимостей для Kubernetes и сами либы были бы в общем репозитории
и каждый мантейнер мог бы для своего пакета указать точные проверенные версии зависимостей, а юзер смог бы легко запустить и с другими версиями

Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 21-Янв-21, 14:34 
Ответить | Правка | Наверх | Cообщить модератору

43. "забавно было бы если бы они отделили зависимости"  +/
Сообщение от Аноним (43), 21-Янв-21, 15:28 
$ ldd /usr/bin/kubelet
        linux-vdso.so.1 (0x00007ffceaaed000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a927c3000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a925bf000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a921ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0a929e2000)
Ответить | Правка | Наверх | Cообщить модератору

64. "забавно было бы если бы они отделили зависимости"  +/
Сообщение от Аноним (64), 21-Янв-21, 21:07 
Что сказать пытался? Все остальные зависимости для сборки, они скорее всего включены в результирующий бинарник целиком.
Ответить | Правка | Наверх | Cообщить модератору

69. "забавно было бы если бы они отделили зависимости"  +1 +/
Сообщение от анончик (?), 22-Янв-21, 01:26 
он хотел намекнуть, что библиотеки на go линкуются статически. их билд-система в виде бинарника с именем go вытаскивает из гита, делает из них .obj, если их ещё нет, и линкует используемые тобой части в твой бинарник. это реально всё так, без преувеличений.

так что вытаскивать эти дев-зависимости из файла `go.mod` и затаскивать в apt -- это реальная дурка.

Ответить | Правка | Наверх | Cообщить модератору

49. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от Ан О Ним (?), 21-Янв-21, 18:19 
Культура на нуле... Люпмен/быдло кодинг.
Ответить | Правка | Наверх | Cообщить модератору

65. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от ano (??), 21-Янв-21, 21:19 
Главное чтоб uninstall сделали , а то с такой кучей говна - явно не осилят .
Ответить | Правка | Наверх | Cообщить модератору

81. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от пох. (?), 22-Янв-21, 09:54 
> Главное чтоб uninstall сделали , а то с такой кучей говна -
> явно не осилят .

uninstall в развернутом кластере делается с помощью бульдозера.

Потому что это означает что либо фирма банкрот, либо DC сгорел к херам.
Других причин нет, это не пакетик который ставят на посмотреть. Это то, под что всю инфраструктуру и все IT в конторе прогинают. Дистрибутив и вообще какие-то потуги дебианщиков при этом становятся, естественно, совершенно вообще не нужны.


Ответить | Правка | Наверх | Cообщить модератору

68. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +1 +/
Сообщение от SubGun (??), 21-Янв-21, 23:38 
"У нас стандарты," - говорили они. "У нас принципы," - говорили они.

Но стоило поднажать, как тут же "продали" все свои принципы.

Ответить | Правка | Наверх | Cообщить модератору

76. "В Debian разрешено встраивание зависимостей в пакет Kubernet..."  +/
Сообщение от abu (?), 22-Янв-21, 04:17 
Ставил скриптами с сайта, админил, даже работало года полтора с Gitlab и CI в свое время именно на Debian. Обновлять надо если не регулярно, то хотя бы раза два в год, проект динамичный, как это будет выглядеть при установке из пакетов - не знаю.

Считаю, что ставить k8s на т.н. bare metal, а потом его настраивать, а потом еще и вменяемо админить, дано не каждому и, как мне кажется, мало кому нужно.

Все это, как по мне, должно торчать в облаках и админиться за деньги теми, кто это все придумал (для того оно, видимо, когда-то и затевалось). Ну а для неосиляторов или на посмотреть - можно вообще Rancher накатить и тоже посметься.

Так что - что из пакетов, что скриптом с сайта - один чорт.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру