больше года назад уже помню был прекрасный баг, кажется еще в 1.10 с логдрайвером journald, если journald рестартовал по какой-то причине то докер выходил с exit 0 - типа pipe failed но я выйдут с exit 0 ну и до кучи systemd unit был кривой у нас и если docker вышел с 0 то systemd его не рестартовала

вот как такую хрень задебажить? в лог докер пишет что выходит и всё, больше ничего

это был баг в голанге :)

угу до 1.6 нельзя был pipe fail обрабатывать

хипстеры кругом а ты сиди долбись

да стыдоба

из кубернетес багов - например баг с revision history, после какого-то момента она переполняется или я хз но больше нельзя деплоить. Меняешь деплоймент а деплой не идет

огонь

приходится пересоздавать?\

установка revision history лимита в 1.4 была вообще сломана, в 1.5 работает но все равно в какой-то прекрасный момент получаешь такюу же ситуацию

приходится пересоздавать?\

нет, нужно удалить все replication controller

тогда деплоймент отдупляется и начинает работать

а т.к. нет флага удалить все rc кроме текущего активного то приходится удалять все, в результате и поде пересоздаются

ну и вот тут можно огрести что в этот момент идет деплой (у нас CD) и ты получишь по 2 копии некоторых контейнеров

одна нормальная а вторая orphaned (rc удалил куб а под еще нет)

и это надо отслеживать как-то

и тогда нужно удалить все поды чтобы rc их пересоздал...

ну оно видно в kubectl get pods что два контейнера от разных rc бежит

* два пода

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

а волюмы оно тоже монтировало по два раза?

Кстати о вольюмах - баг в 1.8.5 когда нельзя было в AWS монтировать EBS

Так я перелез на 1.9.3 сразу

у нас щас 1.8.4

не советуете обновляться, значит? :)

Кстати о вольюмах - баг в 1.8.5 когда нельзя было в AWS монтировать EBS

о снова сломали? красота

а обновляться по кусочкам так и нельзя? надо сразу весь кластер?

а волюмы оно тоже монтировало по два раза?

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

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

в итоге это был адский треш и можно было в 1.4.х и ранее ебаться 2 часа пытаясь приаттачить EBS вольюм

еще кажется был баг в 1.3 или 1.4 (но плохо уже помню) что он пытался приататчить вольюм из другой AZ

а вот со statefulset с dynamic EBS provisioner до сих пор этот баг есть

вот хочешь ты значит в этом statefulset чтобы был под на 2 контейнера и у каждого свой вольюм (или даже кажется если один контейнер и унего 2 вольюма то та же байда) - а вот не выйдет, никак

потому что dynamic EBS provisioner создает ebs volumes в разных AZ по кругу, и получит твой под два вольюма в разных AZ

когда смотрел последний раз была кажется 1.7 актуальная версия и баг не был пофикшен, подозреваю и в 1.9 он все еще есть

у меня с 1 волюмом в стейтфулсете всё ок

тьфу-тьфу

два не пробовал

Dmytro хочу статью про фейлы кубера %)

да смысл, открываешь их багтрекер - и вот тебе все они

можно писать юмористические романы

ну багтрекер это абстрактные баги

а личный рассказ - совсем другое

привет ребята. Поделитесь опытом, есть у кого CIки в кластере? Как решаете вопрос со сборкой докер-контейнеров? Прокидываете /var/run/docker.sock?

привет ребята. Поделитесь опытом, есть у кого CIки в кластере? Как решаете вопрос со сборкой докер-контейнеров? Прокидываете /var/run/docker.sock?

Отдельный dind и к нему ходят через DOCKER_HOST по сети

по https+сертификату?

по https+сертификату?

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

спасибо!

спасибо!

Сразу смотрите docker build —cache-from , много времени сэкономите

у меня на самом деле есть альтернатива - сделать отдельный инстанс для билда в AWS. Я сначала это попробую.

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

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

Он очень медленный и не работает кеширование при сборке образов. Так-же его нужно запускать в privileged режиме. А сейчас даже systemd можно запускать в контейнере в обычном режиме.

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

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

Он очень медленный и не работает кеширование при сборке образов. Так-же его нужно запускать в privileged режиме. А сейчас даже systemd можно запускать в контейнере в обычном режиме.

--cache-from как писали выше

И сам автор dind не рекомендует его использовать. Он разрабатывался для отладки самого dockerd.

именно поэтому я думал об отдельной ноде, на которой через affinity запущен только один образ jenkins-slave, ну и туда прокинуть /var/run/docker.sock

да слейв-то пофиг где запущен, главное сокет дать

ну и сокет может быть по сети

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

большинство CI умеет стартовать AWS и прочие инстансы через апи и потом их тушить через время - я бы сотрел в эту сторону

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

и для лучшей утилизации его ресурсов, я думаю как бы сделать так, чтобы наоборот, съехать с EC2-slave-plugin

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

большинство CI умеет стартовать AWS и прочие инстансы через апи и потом их тушить через время - я бы сотрел в эту сторону

Когда по секундам тарификация EC2 будет, то имеет смысл, до тех пор это ппц

ну там только х5 инстансы умеют, на сколько я знаю, посекундно, но вроде бы там только Amazon linux

Когда по секундам тарификация EC2 будет, то имеет смысл, до тех пор это ппц

так уже полгода как https://aws.amazon.com/blogs/aws/new-per-second-billing-for-ec2-instances-and-ebs-volumes/

так уже полгода как https://aws.amazon.com/blogs/aws/new-per-second-billing-for-ec2-instances-and-ebs-volumes/

О, проспал

Per-second billing is not currently applicable to instances running Microsoft Windows or Linux distributions that have a separate hourly charge. Marketplace AMIs that do not have a separate hourly charge are eligible for per-second billing.

только такое ограничение

но это я так понимаю для всяких платных AMI

EC2 plugin дженкинса спот инстансы умеет?

да.

но они нам не подходят.

но это я так понимаю для всяких платных AMI

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

хотя, это уже наверное оффтопик. Сорри.

Да, имеет смысл если время старта несопоставимо с временем жобы

в блоге написано что да, а в чем проблема?

это ж не инстанс считает а супервизор

еще как идея вот интересный проект https://www.slideshare.net/majeru/autospoting-an-automated-ec2-spot-market-bidder

это больше для кластера и для продакшена то и для CI почему нет