Опубликован релиз платформы оркестровки контейнеров Kubernetes 1.18, позволяющей как единым целым управлять кластером из изолированных контейнеров и предоставляющей механизмы для развёртывания, сопровождения и масштабирования выполняемых в контейнерах приложений. Проект изначально был создан компанией Google, но затем переведён на независимую площадку, курируемую организацией Linux Foundation. Платформа позиционируется как развиваемое сообществом универсальное решение, не привязанное к отдельным системам и способное работать с любыми приложениями в любых облачных окружениях. Код Kubernetes написан на языке Go и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52635
Планируют добавить создание контейнеров?
А оно пока больше 110 на ноду не умеет (хотя в openshift запилили до 250), уж лет пять даже 500 не могут на ноду предоставить. А вот в самом docker (без k8s) можно и больше, 1000 в лёгкую.
Чем больше с этим кубернетесом ковыряюсь, тем больше офигеваю от того насколько это неинтуитивная хрень
Как OpenStack?
Высокий порог входа? Кто то же понимает...
Nomad от hashicorp получше будет
Resource limits на контейнеры — только за деньги?
Спасибо, идите в задницу.
5 лет полёт нормальный, ЧЯДНТ?
Если не трогать то конечно
Если разворачивать на bare metal, то много чего можно сделать не так, особенно с PVC, особенно, пожалуй, 5 лет назад. Если не на bare metal, то надо платить деньги тем, кто все это дело поддерживает.А так, если позаниматься k8s просто в свое удовольствие, то даже порой затягивает и завораживает.
> Чем больше с этим кубернетесом ковыряюсь, тем больше офигеваю от того насколько это неинтуитивная хреньСкорее наоборот - тупая штука, но гибкая до неинтуитивности.
Как никс системы. В основе "всё файл" и файлов-то всего-то 6, но сколько всего сделано неочевидного.
Современные кубернетесы позволяют решать такие проблемы, которых до изобретения кубернетесов - не существовало.
Это каких? Оно умеет эффективно управлять балансировкой нагрузки между сервисами что позволяет вам смотреть сайтики без тормозов, если они популярные и на них сотни человек. И на сегодня это единственный настолько быстрый и одновременно стабильный инструмент. Т.к. когда разрабатываешь несколько версий приложенок контактирующих с другими и нужно протестить твою новую версию приложенки с НЕСКОЛЬКИМИ наборами РАЗНЫХ старых версий. То я плохо представляю сколько у тебя времени займет сделать это вручную на одной машине. Да и настраивать вручную балансировку нагрузки собирая свой конструктор из разных библиотек то еще удовольствие. Работал я с одной старой системой, до докеровской и даже до микросервисной, нагруженной, оно при парсинге запросов как черепаха, спасают заказчика только быстрые процессоры.
Разговор про докеры-ранчеры-кубернетисы, обычно, сводится к двум руслам.Первое - мне, как обычному админу, админить все это достаточно неприятно. Куча сущностей, которая может быть нагорожена не админом, а программистом, которому ротация логов того же докера, в поднятой наспех виртуалке, как бы не нужна, до тех пор, пока не встанет колом. Также возможны сборки по сценариям, которые год назад написал индус, а потом застрелился. И - хочешь сценарии заново переписывай (и сколько это времени займет - тоже себе потрудитесь представить), а хочешь жди =чудес=.
Второе русло это то, о чем вы тут говорите в чистом виде - да, балансировка, да, удобно разработчикам выкатывать-накатывать. И это - плюс всех этих систем, согласен.
Это не предназначено для админства. Это без админства всегда накатывается из CI\CD (есть код, который без админа делает правильно и умно будет гонять этот код, вместо ковыряний админа и админской широты эрудиции при ремонте поломок). Не администрируется по классике. Дальше вопрос организации и раздачи отвественностей. Чей коммит покрасил в красный - тот и озеленяет. За кадром оставлен инструментарий создания визуализации связей приложений. Без него - труба. В общем, что-то типа AppDynamics должно быть или в виде людей или в виде программном.Плюс системы не в удобстве накатки. Система чтобы во множестве взаимосогласованных сервисов по одному заменять версии, по кнопке откатывать версию, рассаживать сервисы по континентам, хранить конфигурацию в VCS (и видно, чей коммит покрасил в какой цвет).
Но это всё уже после правильной организации. Просто так "взял и воюй" - не, так оно мало пригодно.
Вот-вот, понеслось ((: Не спорю, слова типа =без него - труба=, =коммит покрасил в какой цвет= - это, да, не про админство.=Просто так брал и воевал=, правда, конечно, в рамках небольшого колхоза. Отсюда и вышеприведенное мнение - завораживает и интересно.
Да, кстати, забыл еще об одном факторе. Вот вы попробуйте не поадминить такой вариант - программист ставит ранчер на VDS. О ротации логов в докере не заботится. О настройках ранчера - не заботится. О том, что на старых версиях ранчера сертификаты для кубернетиса - всего на год, он не думает, а волшебную кнопочку =обновить сертификаты= в ранчер завезли совсем недавно, то есть пару лет назад надо было веслами грести.
Он заботится, конечно же, о том, чтобы покрасить коммиты в зеленый или что там еще у него в голове (:
А потом, когда встает все колом, примерно через год, его и след простыл. И хорошо, если он в колхозе один такой мудреный, а не двадцать один.
Вот как сервера World of Warcraft, Aion, Guild Wars2 и прочие MMORPG без кубернетесов в aws я хз.
Какие это просто титанические усилия тратятся на дронов, разносящих пицу, социальные сети гей-знакомств, всякие онлайн казино/пари-матчи, андроид/айос казулки/гриндилки с донатом. Ну хотя да, приколькно на карте видеть, как к тебе едет такси. Но опять, же. Может с архитектурой что то не то?
Да херня этот ваш кубернетес. Для тех кто не изучал в HA. И для тех кто не изучал в админство.
Нафиг мне не сдались все эти лишнии слои где на каждом растёт латенси.
> Да херня этот ваш кубернетес. Для тех кто не изучал в HA. И для тех кто не изучал в админство.Нафиг мне не сдались все эти лишнии слои где на каждом растёт латенси.
админам локалхоста оно и не нужно, просто проходи мимо
оно не нужно всем тем у кого нет микросервисной архитектуры внутрикорпоративного продукта, а такое часто случается, когда нужна высочайшая производительностьЕсли лейтенси для приложения мегаважно и приложение при этом позволяет его нужно просто развивать как огромный монолит и вот тогда да, его HA вы будете уметь сами посредством самых разных сетевых средств.
Самая главная проблема контейнерных систем это сеть. Если бюджет и архитектура позволяет, можно создать лосслесс нетворк фабрику, создать выделенный приоритет для важных обменов (нужен коммутатор с DCB PFC) и загонять это в приоритетный V(X)LAN. Вы посмотрите что с большим и сложным приложением произойдёт если у вас TCP начнёт перезапрашивать часть потерянных фреймов.
На работе больше 50 кластеров. В которых работает больше 300 приложений (супер мощные сервера). В теории все звучит хорошо а на практике, там 1000 костылей и подпорок чтобы все работало. А так же приличные сетевые задержки и проблемы с постоянным дропом tcp соединений. Раньше все делали на OS и проблем не было
OS - openstack
Обратная сторона модности-молодёжности.Оно действительно сырое и чтобы коллектив осилил надо набирать или людей уровня крупнейщих софтверных корпораций или использовать стабильные, отработанные технологии. А так-то, да, людям трудно успевать и за этим весь ожидаемый и предсказуемый _заранее_ негатив от инноваций. Хороша ложка к обеду. Да вот только слышат звон, а где - не осиливают.
А чтобы набрать такую команду, надо поработать... над самим собой, чтобы не допустить: из под палки по принципу "деньги-плачу-вали-работай"+"ну-на-и-отвяжись", коммуникации сломанные, конфигурации костыльные в лучшем случае (в худшем - анекдоты), по вакансиям мало кто согласен на такое.
Вот такие вот инновации.
Полностью согласен (: