Сколько людей уволится из шапки за следующий год? :)

форк на уровне предприятия, с cyanogen так было

ждем рождения нового redhat'а

Новый Cyanogen жив?

LineageOS - еще как

ownCloud/nextCloud - еще история успеха

форк на уровне предприятия, с cyanogen так было

Масштабы не те :) редхат это не только Линукс, там жирный слой явы был

Компания из 100 человек может перебежать на другую сторону улицы в новый офис, в редхате сколько? Больше тысячи уж точно :)

Около 10

Вово. Интересно, что пишут что покупка через скупку 100% акций, это как? С биржи все тоже скупят? А если кто то не захочет продавать? :)

Останется минорным акционером, делов-то

Тут есть plot twist - антимонопольные законы, например

Ну монополией на клауд рынке пока Амазон назвать можно, никак ни ибм

Ну монополией на клауд рынке пока Амазон назвать можно, никак ни ибм

EU проверяла покупку Гитхаба микрософтом несколько месяцев, а там цена сравнительно мелкая

Ватсапп без стикеров покупали за 19 миллиардов, а лидера опенсорса за 33 . Обидно

(итт я на стадии отрицания)

Ну чего, все сбежали на гитлаб, теперь предлагаю бежать на SuSE

У них zypper приятный и снапшоты rootfs из коробки

У них есть дядя, который занимается rootless containers и кто-то из проекта usernetes

Твитер: "ZERO - The amount of productivity that will happen tomorrow at Red Hat." :)

У них есть дядя, который занимается rootless containers и кто-то из проекта usernetes

Greg Kroah-Hartman из суси

цирк с этими env var. Они никак не могут нормально трекать конфигмапы, потому суют все настройки в env vars? А с приложениями которым файлы требуются что делать?

ну вот смотри. Есть нативный механизм выката deployment, с возможностью отката (kubectl rollout). Если у тебя приложение это deployment+configmap, то при изменении _только_ configmap надо пихать свои костыли, и оркестратор здесь превращается в тыкву, не имеющую право называться оркестратором.

Подсказка: Blue-green можно применять не только к деплойментам

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

идея на самом деле простая. У вас декларативное описание из которого явно можно выцепить зависимость между ресурсами (deployment зависит от configmap), и эту зависимость стоит использовать, а не заставлять придумывать костыли. Так делается, например, в CloudFormation, когда по ссылкам из одного ресурса на другой автоматом вычисляется последовательность выката и применение изменений.

Уже успели посмаковать что там будет теперь с coreos после всей этой череды приобретений и слияний?

технология востребована, покупать будут, развивать будут. В том или ином виде.

чего переживать?

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

Уже успели посмаковать что там будет теперь с coreos после всей этой череды приобретений и слияний?

да господи

А ты молодец

ownCloud/nextCloud - еще история успеха

MySQL / MariaDB

идея на самом деле простая. У вас декларативное описание из которого явно можно выцепить зависимость между ресурсами (deployment зависит от configmap), и эту зависимость стоит использовать, а не заставлять придумывать костыли. Так делается, например, в CloudFormation, когда по ссылкам из одного ресурса на другой автоматом вычисляется последовательность выката и применение изменений.

простое решение - не использовать configmap. Все точно так же как с go, все vendor с собой, только все настройки в env. если вам действительно нужны конфиги общие на кучу приложений, ничего плохого в "etcd/redis/vault/consul+confd в под" не вижу, готовое решение без привязки к kubernetes вовсе.

MySQL / MariaDB

Они тоже всем офисом ушли делать форк?

> redis > ничего плохого 😏😏😏

часто падает с 0 нагрузкой?

Я никогда не видел, чтобы редис без нагрузки падал 😱

как будто нагрузка является единственным мерилом

ладно, но идея ясна. В любом случае делать зависимость подов от configmap - не очень идея. Куча вопросов вроде "а что делать, если configmap попадают плохие данные и все валится?". Не говоря уже просто o deps hell через пару лет.

ну вот смотри. Есть нативный механизм выката deployment, с возможностью отката (kubectl rollout). Если у тебя приложение это deployment+configmap, то при изменении _только_ configmap надо пихать свои костыли, и оркестратор здесь превращается в тыкву, не имеющую право называться оркестратором.

У конфигмапы можно менять не только .data но и имя, создавая новую конфигмапу и все начнет работать гладко

Они тоже всем офисом ушли делать форк?

Когда Oracle купил Sun, разрабы MySQL вышли и начали пилить MariaDB

У конфигмапы можно менять не только .data но и имя, создавая новую конфигмапу и все начнет работать гладко

Вот да, или добавляя новый конфиг внутри того же конфигмапа

У конфигмапы можно менять не только .data но и имя, создавая новую конфигмапу и все начнет работать гладко

а ещё можно деплоить в другой кластер, тоже вариант. Речь не об этом. Речь о том, что это можно сделать на уровне оркестратора.

Зачем делать на уровне оркестра она то, что делается просто на уровне клиента.

ну так-то да. И масштабирование можно без hpa делать. И балансировку внешнюю. И подами можно без deployment и statefulset управлять

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

Нет, это уже нетривиально

ого, а так можно было?

только привелегированным животным и админам чата

только привелегированным животным и админам чата

/ban

:(

Вадим, как там редхат с утра? :)

Твитер: "ZERO - The amount of productivity that will happen tomorrow at Red Hat." :)

9 утра, выбираем в какой бар идти

Зато ваши опционы выросли на 30 или сколько там выше рынка процентов они скупают

Нет, это уже нетривиально

то, что вы предлагаете, тоже нетривиально по сравнению с kubectl edit configmap <name>

на это и собрались в бар, наверное

ладно, а теперь серьезный вопрос: кто-нибудь видел вот такую беду - https://gist.github.com/vrutkovs/6865d6b1f80619b0816f68e2977c8d4b Статик под увидел новый манифест, но имадж его посередине забыл. Это 1.11

Нет, это уже нетривиально

А с чем именно может возникнуть сложность?

это он мне отвечал :)

race condition

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

то, что вы предлагаете, тоже нетривиально по сравнению с kubectl edit configmap <name>

Чтобы это реализовать, потребуется поменять основу основ - ключ уникальности. До этого было apiversion,kind,namespace,name , придется добавлять "generation name" или вроде того. Все это ради не клауд найтив легаси, которые не умеют конфиг перечитывать

ладно, а теперь серьезный вопрос: кто-нибудь видел вот такую беду - https://gist.github.com/vrutkovs/6865d6b1f80619b0816f68e2977c8d4b Статик под увидел новый манифест, но имадж его посередине забыл. Это 1.11

А это точно про Федору? Вроде ж он пауз контейнер запустить не может

А это точно про Федору? Вроде ж он пауз контейнер запустить не может

зачем там пауз контейнер?

Чтобы это реализовать, потребуется поменять основу основ - ключ уникальности. До этого было apiversion,kind,namespace,name , придется добавлять "generation name" или вроде того. Все это ради не клауд найтив легаси, которые не умеют конфиг перечитывать

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

так нужность никто не оспаривает, только решение через env vars странное. Что ж теперь, и секреты в env vars совать?

кто-то пробовал получить CKA? насколько полезно?

решение с env vars спорное, да. Но имеет право на жизнь, просто нужно учитывать все эти моменты, типа секретов.

зачем там пауз контейнер?

Ну у любого пода (под докером) есть инфраструктурный контейнер, образ для него задаётся в опциях kubelet. Другие поды на этом кублете нормально запускаются?

Ну у любого пода (под докером) есть инфраструктурный контейнер, образ для него задаётся в опциях kubelet. Другие поды на этом кублете нормально запускаются?

>есть инфраструктурный контейнер а, хмм, да, он у нас по-другому обзывается. Он не стартует тащемта. >Другие поды на этом кублете нормально запускаются? нет. Причем тот же сетап работает на libvirt, и сломан на GCP

>есть инфраструктурный контейнер а, хмм, да, он у нас по-другому обзывается. Он не стартует тащемта. >Другие поды на этом кублете нормально запускаются? нет. Причем тот же сетап работает на libvirt, и сломан на GCP

Предлагаю сдаться и отдохнуть перед тем как придёт задача написать Тиволи оператор :)

▫️Какой у вас проект или где работаете? Свободный художник работы нет. Неспешно разбираюсь с k8s в надежде потом присоединится к каком либо проекту. ▫️В чём вы специалист? Есть опыт с докер и докер композ. ▫️Чем можете быть интересны или полезны сообществу? Сомневаюсь. ▫️Чем интересно сообщество вам? Изучение средств оркестрации, мониторинг. Делится опытом. Не повторять ошибок. ▫️Откуда вы? Берлин. ▫️Как узнали про группу? Поиск по телеграму. В сообщении нужно указать тэг #whois

ладно, а теперь серьезный вопрос: кто-нибудь видел вот такую беду - https://gist.github.com/vrutkovs/6865d6b1f80619b0816f68e2977c8d4b Статик под увидел новый манифест, но имадж его посередине забыл. Это 1.11

А что в --pod-infra-container-image ?

попробуй вручную запустить через docker/crictl

Всем привет! :)

А что в --pod-infra-container-image ?

теперь уже pause, но это, похоже, ни на что не влияет. Как-то интересно crio поломалось

а можно ли выставлять контейнеру лимит исходя из кол-ва памяти на ноде?

толку от него мало, просто на графике будет линия