Как стать автором
Обновить

Комментарии 37

Ответ на вопрос моей мамы «чем я занимаюсь на работе» =)
А сколько у вас разработчиков, которые пишут серверные приложения и микросервисы?
350 — буквально все разрабы имеют что-то своё в кубе: включая мобильную разработку и фронтенд. Даже у меня там несколько pet projects, хоть я и админ =)
классная статья, спасибо!
Спасибо за статью! Ops команда выполняет ревью Helm чарта? Кто готовит дашборт для white box мониторинга сервиса? Есть ли какие-то требования к документации сервиса у ops-команды или вопрос сразу уходит к дежурному разработчику?
Мы ревьювим чарты, да. Дашборд готовят разработчики. Документация — на воли совести создателя сервиса. Не страшно если ее вообще нет: infrastructure as a code.
Не сочтите за критику, но — каждый раз, когда я вижу такие цифры применительно даже не к Сберу, а к Домклику, у меня шок. 350 разработчиков — это маленькая армия, с которой можно дать рынку недвижимости такие сервисы, аналогов которым не было и нет. А по факту эта армия запилила линейку продуктов, самый сложный из которых — это по сути просто доска объявлений по недвижимости. Как же так?
Без обид, правда удивлен)
ДомКлик сделали сервис выдачи ипотеки онлайн. До этого был мрак. 49% доли рынка недвижимости — это не только клиенты Сбера.
Но это скорее к бизнесу вопрос. Мне нравится облака делать, которые меня не будят по ночам.

А потом говорят, что людей не хватает в ит :)

Это всё круто, автоматизировано… особенно удобно для мошенников. Говорю так, потомучто:
1) полгода назад у моей жены мошенники похитили со сбера 800к рублей
2) месяц назад я продал квартиру через ДомКлик, завел счет в сбере. И через 20 минут после сделки мне сразу позвонили эти же мошенники. И я не верю что данные просто слили вручную, так оперативно можно сделать если всё это мошенничество также автоматизировано.
Ну для прокрутки таких офер незачем иметь прокладки вида продажи данных, достаточно только одному компетентному человеку получать данные и сливать своей группе. Там же сотни миллионов
С точки зрения безопасности в кубере все очень сложно. Не удивлюсь если подсосаться к системе этой могут и без явных следов.
Если даже apple жил с 10к лет с дырой, которую использовали для удаленного управления устройством, то кубер даже смешно
пруф про apple ниже
safe.cnews.ru/news/top/2020-04-27_hakery_atakuyut_vippolzovatelej

PS за ошибки в тексте извините
То есть для визуализации всего-всего используется Grafana. GUI вроде Rancher2 не стал использоваться по причине его сырости в момент проектировки системы, не было нужды, или не хотелось иметь лишнюю прослойку?
Оффтопик: как спать спокойно после оформления сделки через Домклик, зная, что злоумышленники могут выпустить ЭЦП на твоё имя и провернуть операции с недвижимостью?

Про визуализацию мониторинга через Ранчер ничего не скажу. Сам Ранчер нам не интересен — его фичи либо уже у нас есть, либо не интересны. Графана — стандарт индустрии, хорошая документация и все ее умеют. Она была до Кубера и наверное будет когда его не станет :) Хотелось бы чтобы она просто не тормозила хотя бы на топовых компах на той же community Kubernetes Dashboard.

Подскажите, пожалуйста, как часто вы выкатываете релизы на прод?
Используете ли вы кросфункциональнвн продуктовые / фича команды? Если да, то какого размера?
Какое у вас среднее время производства фичи? ( ну типа от момента когда взяли в работу и до выпуска на прод?)

Попросил коллег ответить на ваш вопрос =) Скорее всего ответ где-то кроется в первых постах нашей компании на Хабре.

Спасибо за статью! Подскажите, хорошо ли чувствует себя сам сервер Docker под нагрузкой? У вас нет в планах переводить рантайм с Docker на что-то другое? Какое у вас в среднем количество подов на ноду ?

С самим Docker проблем нет. Есть вопросы к скорости развития самого Docker: он просто не развивается и долгожданных нужных фич вроде лимитирования по IOPS, cgroups v2 — мы до сих пор не получили. В среднем сейчас 40-70 подов на ноду (до 100 иногда доходит).

1000 микросервисов… а почему так много? Что делает каждый микросервис, можете привести примеры? Даже не каждый, а по группам побить.

Увы, это уже не ко мне. Передал вопрос разрабам =)
Была разработана система «рекомендаций»

А чем полезна эта система? Системные поды
а) подпадают в обе категории,
б) судя по скроллбару там много подов которым неплохо бы урезать аппетиты.
Эти "рекомендации" не применяются и сделаны исключительно для отчетности?

Если там выбрать namespace, отличный от kube-system — то там будет все нормально.
Просто чтобы живые имена подов не показывать, я выбрал такой ns.

А, тогда понятнее, спасибо

Обновляем Prod в субботу вечером по одной ноде.

А что будет в случае проблем после обновления, но если его заметили в следующий день, т.е. в воскресенье?


Jenkins

Деплой и настройка дженкинса автоматизировано?


Ansible

ИМХО, у ansible недостатков много:


  • медленная.
  • императивная, как следствие оставляет мусора в системе, к примеру, недостаточно удалить лишные настройки, нужно ещё правильно написать сценарии для удаления.
  • странный DSL, по сути отдельный язык программирования.

Хотя для кубовых инфраструктур — может не так уж плохо.




Как с безопасностью?


  • может ли один микросервис доставить неприятности соседям?
  • сколько людей имеет доступ к prod серверу, и мониторите ли их действия на сервере?

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

Императивным Ansible может быть только потому что вы его сами используете как Bash на стероидах.

Так можно сказать про что угодно.


У меня на проекте используются ислючительно идемпотентные роли, никаких сайд-эффектов (то что вы называете "мусором") никогда не имелось.

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


Если вы сразу пишите и тестируете логику отката — здорово.


Для меня является недостатком то, что необходимо писать такую логику.

Для меня является недостатком то, что необходимо писать такую логику.

Чтобы откатить настройки роли, нужно смерджить в гит или нажать специальную кнопку в CI-системе, которая откатит состояние на предыдущий коммит.
Или самое тупое: подготовить заранее PR для отката.

Мы каким-то разным ансиблом пользуемся )
Чтобы откатить настройки роли, нужно смерджить в гит или нажать специальную кнопку в CI-системе, которая откатит состояние на предыдущий коммит.

Но это не откатить состояние сервера.

А что будет в случае проблем после обновления, но если его заметили в следующий день, т.е. в воскресенье?


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

Деплой и настройка дженкинса автоматизировано?


Я не большой спец по Дженкинсу, недавно стало писать под него. Может я неправильно понял вопрос.
Дженкинс у нас только для Ops-проектов и руками завести пайплайн раз в 2 недели не проблема

ИМХО, у ansible недостатков много

Почти полностью согласен. Производительность Kubespray довольно ужасна, хотим слезть с него.

Как с безопасностью?


Довольно много работаем над этим. Не всё идеально, но лучше чем обычно (что я вижу в других компаниях). Подробности раскрыть не могу.
перешли довольно болезненно с Helm 2, но очень рады опции atomic

А что не так с atomic в самом Helm 2? Данная опция в нём делает тоже самое, что и в Helm 3.

Atomic в Helm 2 появился чуть ли не после выхода Helm 3, ЕМНИП. Не проверяли — проще было сразу перейти на Helm 3 и выпилить все tiller'ы из всех нэймспейсов.

Спасибо за статью!


Подскажите пожалуйста на какой системе(версия имеджа, ядра и и.д.) у вас крутится куб в проде?
И тюнили ли вы систему перед тем как поставить куб?

CentOS 7, 4.4.2xx ядра (периодически обновляем на последнее ядро LT-ветки).

Систему тюним при заливке при помощи Ansible: там штук 50 sysctl меняем.

kubelet'ы тоже тюним — их опции выстраданы годами.

А чем красношапочное ядро не устроило? А если билдить и мэйнтэйнить ядра самим, то почему не longterm посвежее? Один eBPF чего стоит.

Ну обычное LT ядро от CentOS. На момент обновления ядер — было последним. Несколько месяцев им. Ставим то, что не глючит. У поздних 3x были проблемы с XFS (тормозило спонтанно на k8s нодах) и тоже самое было на 5.x ядрах последних от CentOS + еще были какие-то глюки. Оставили то, что позволяло спать спокойно.

А, видимо тянете с ELRepo, понял. Я с их конфигов собираю, но только 4.19.xxx.

ELRepo, так и есть. Я бы еще от XFS в польщу ext4 отказался.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.