Если вы ищете более легкий способ, вы можете развернуть Кубернетес на облачном провайдере
А вы это говорите потому, что сами пробовали, пользуетесь, и сравнивали, или просто на основе рекламы из интернета? ;) Т.к. я, несколько лет работая с k8s кластерами, не стал бы вот так с ходу утверждать, что k8s в облаке - "более легкий способ".
Так вот, когда неплохо знаешь ansible - запилить свой ansible для kubeadm чуть ли не быстрее, чем разобраться в kubespray. Мы, потратив немало времени на подпиливание kubespray в итоге плюнули, переписали с нуля и это вышло быстро, и работает оно быстро и стабильно. Очень быстро!
а последний официальный kubespray использует под собой kubeadm
Ага, но с костылями, "исторически сложившимися". В общем, как человек, закопавший в kubespray достаточно времени, говорю, что не стоит другим закапывать в него своё время. Если ты понимаешь примерно, как обвязать ансиблом kubeadm - стоит просто это сделать и всё.
Да разобраться в kubespray сложнее, чем в том, как самому kubeadm в ансибл загнать. Ну, прям вот с ходу kubespray конечно поставит кластер, но как только захочется его кастомизировать...
Один вопрос: почему вы считаете, что так будет лучше, и что инженеры Intel до этого не додумались и уже не проверили это всё? Насколько я знаю, передовые инженеры в разработке процессоров знают или английский, или китайский, даже если их неродной язык ;)
Если бы их был миллион - не было бы полупроводникового кризиса после ковида. Там как раз "внезапно" стало всплывать, что на всякие мелкие, дешевые, но нужные чипы не так уж много поставщиков, встал один - пострадали все дальше по цепочке.
И зачем 2.5G, бытовых роутеров с такими портами для локалки пара оверпрайснутых моделей.
Ну так это сегодня, а завтра их станет больше. Стандарт ж свежий, потихоньку набирает популярность. В принципе удобно: если у тебя дома всё на гигабите - окей, вот как раз 2 порта тебе. А если у тебя уже есть (ну или купишь в будущем) свитч с 2.5Гб - одним кабелем можно будет подключится.
Вы просто смотрите на это не под тем углом. Я прекрасно понимаю, о чем говорит автор в статье, потому что я прошел через подобный опыт. И я бы описал первый уровень так: это когда вы, зная слова своего родного языка, можете выстроить их грамматически правильно по правилам иностранного языка. Чтобы дальше если другой человек, которы не знает оба этих языка, просто перевел по словарю каждое - получилась фраза, которую носитель поймёт. И когда ты оказываешся в другой стране внезапно, ты делаешь наоборот - слова учатся легко, но не зная грамматики ты их увязываешь просто как перевод, ты не можешь построить фразу.
С этой позиции контейнеры вообще дома не нужны. Дома на то и дома, что собираешь как хочешь. Я много работаю с k8s, и мне удобнее запустить k3s на таком сервачке, чтобы было привычно и удобно. Ты вот ниже пишешь, что тебе удобнее через Ansible - ну вот, оно же - излишнее для одной машины, но тебе удобнее вот так.
нет конечно он запустится, но съест львиную долю ресурсов
Если k8s использовать как продвинутый Portainer, то ничего он практически не жрет. etcd сам по себе легкий, данных в нем в таком маленьком кластере мало, контейнеры будут редко перезапускаться - значит и api вызовов будет не так уж и много. Это если кластер обвешать всякими istio да мониторингами... Но так это и будет нагрузка от этих приложений, а не от k8s как такового, опять же.
Так под андроид свои планировщики и существуют с самого его начала. Во время повального увлечения перепрошивками народ даже сам планировщики писал.
Или они на «большой» Linux не портировались?
Всё так. Ну точнее, не портировались, потому что условный "большой линукс" никто не запускает на условном Qualcomm'овском проце, под который кто-то написал планировщик на андроид (до недавнего времени, да и даже сейчас ноутбуков на ARM, которые не Apple, практически нет на рынке).
потому что если нужно ручным управлением выжимать 4%
Ну оно ручное, когда это 1 комп, и тот дома. А если таки серверов закупить хотя бы стойку, а руками-то надо 1 раз залезть, а потом на все серверы раскатать - получить 4% прироста на всю стойку это уже достаточно выгодно, когда серверы и так на последнем поколении процессоров и "просто апгрейдом" уже не решается.
Ну, это ж не у всех танцоров, не обобщайте! :) Есть много "естественных" танцев, которые выросли из народных, а есть балет - придуманный, и потому работающий как экстремальная нагрузка, а не как приятная.
Там вынужденно появится админ или разработчики научатся админить.
А вы это говорите потому, что сами пробовали, пользуетесь, и сравнивали, или просто на основе рекламы из интернета? ;) Т.к. я, несколько лет работая с k8s кластерами, не стал бы вот так с ходу утверждать, что k8s в облаке - "более легкий способ".
Так вот, когда неплохо знаешь ansible - запилить свой ansible для kubeadm чуть ли не быстрее, чем разобраться в kubespray. Мы, потратив немало времени на подпиливание kubespray в итоге плюнули, переписали с нуля и это вышло быстро, и работает оно быстро и стабильно. Очень быстро!
Ага, но с костылями, "исторически сложившимися". В общем, как человек, закопавший в kubespray достаточно времени, говорю, что не стоит другим закапывать в него своё время. Если ты понимаешь примерно, как обвязать ансиблом kubeadm - стоит просто это сделать и всё.
А смотреть потом из сислога чем? ;)
Да разобраться в kubespray сложнее, чем в том, как самому kubeadm в ансибл загнать. Ну, прям вот с ходу kubespray конечно поставит кластер, но как только захочется его кастомизировать...
Ну так конкретнее, какие монстры? Loki ресурсов меньше эластика потребляет, к примеру.
Раз у вас свои железки, то на чем вы делали мастера и воркеры? Прям на железе, или на виртуалках?
Эм, k8s тут ничего не изобретал, это best practices для контейнеров в принципе, k8s просто его поддержал.
В чем у вас проблема с логами?
Из последних двух вариантов велик шанс не вернутся
Один вопрос: почему вы считаете, что так будет лучше, и что инженеры Intel до этого не додумались и уже не проверили это всё? Насколько я знаю, передовые инженеры в разработке процессоров знают или английский, или китайский, даже если их неродной язык ;)
Если бы их был миллион - не было бы полупроводникового кризиса после ковида. Там как раз "внезапно" стало всплывать, что на всякие мелкие, дешевые, но нужные чипы не так уж много поставщиков, встал один - пострадали все дальше по цепочке.
Ну так это сегодня, а завтра их станет больше. Стандарт ж свежий, потихоньку набирает популярность. В принципе удобно: если у тебя дома всё на гигабите - окей, вот как раз 2 порта тебе. А если у тебя уже есть (ну или купишь в будущем) свитч с 2.5Гб - одним кабелем можно будет подключится.
Я не предлагаю, я пытался на примере объяснить.
Всё верно, мы ведь и родной язык в детстве так учим - слушаем родителей, ну и читаем, когда научат.
Вы просто смотрите на это не под тем углом. Я прекрасно понимаю, о чем говорит автор в статье, потому что я прошел через подобный опыт. И я бы описал первый уровень так: это когда вы, зная слова своего родного языка, можете выстроить их грамматически правильно по правилам иностранного языка. Чтобы дальше если другой человек, которы не знает оба этих языка, просто перевел по словарю каждое - получилась фраза, которую носитель поймёт. И когда ты оказываешся в другой стране внезапно, ты делаешь наоборот - слова учатся легко, но не зная грамматики ты их увязываешь просто как перевод, ты не можешь построить фразу.
С этой позиции контейнеры вообще дома не нужны. Дома на то и дома, что собираешь как хочешь. Я много работаю с k8s, и мне удобнее запустить k3s на таком сервачке, чтобы было привычно и удобно. Ты вот ниже пишешь, что тебе удобнее через Ansible - ну вот, оно же - излишнее для одной машины, но тебе удобнее вот так.
Если k8s использовать как продвинутый Portainer, то ничего он практически не жрет. etcd сам по себе легкий, данных в нем в таком маленьком кластере мало, контейнеры будут редко перезапускаться - значит и api вызовов будет не так уж и много. Это если кластер обвешать всякими istio да мониторингами... Но так это и будет нагрузка от этих приложений, а не от k8s как такового, опять же.
Так под андроид свои планировщики и существуют с самого его начала. Во время повального увлечения перепрошивками народ даже сам планировщики писал.
Всё так. Ну точнее, не портировались, потому что условный "большой линукс" никто не запускает на условном Qualcomm'овском проце, под который кто-то написал планировщик на андроид (до недавнего времени, да и даже сейчас ноутбуков на ARM, которые не Apple, практически нет на рынке).
Ну оно ручное, когда это 1 комп, и тот дома. А если таки серверов закупить хотя бы стойку, а руками-то надо 1 раз залезть, а потом на все серверы раскатать - получить 4% прироста на всю стойку это уже достаточно выгодно, когда серверы и так на последнем поколении процессоров и "просто апгрейдом" уже не решается.
Ну, это ж не у всех танцоров, не обобщайте! :) Есть много "естественных" танцев, которые выросли из народных, а есть балет - придуманный, и потому работающий как экстремальная нагрузка, а не как приятная.