Александр Качмашев @DarthCorsair
Делаю инфраструктуру для разработчиков
Информация
- В рейтинге
- Не участвует
- Откуда
- Екатеринбург, Свердловская обл., Россия
- Зарегистрирован
- Активность
Специализация
DevOps, Product Manager
Lead
Делаю инфраструктуру для разработчиков
Не-а, т.е. если реплик больше 1, то вписывается minAvailable: 1 и все. Всем хватает, особенно в свете работы всяких HPA (хотя, конечно, корректнее будет сказать: никто не жаловался 😆)
values.yaml 😅 есть внутренняя дока и примеры как что вписывается и куда (ну и ещё, конечно же, ctrl-c,ctrl-v из соседнего проекта). чтобы выкатить новую версию обычно используют --set и передают imageTag
врать не буду, такое тоже иногда бывает. классический пример: квота на ресурсы CPU кончилась в неймспейсе, а квота на количество деплойментов в порядке. но от такого обычно спасает helm upgrade --wait, которой таску выкатки закончит провалом, и kubectl get events, который такое показывает.
вот с этой штукой мы в чарте подложили себе соломинку - если replicas: 1, то мы не создаем объект pdb 😀
А у нас на этот счет тоже есть "помощник", я про него рассказывал на devoops 2022 - https://youtu.be/HOIkjDIesWs. Если видео не захочется смотреть: мы написали мегачарт, который позволяет деплоить любое из наших приложений (отдельные чарты под разные opensource statefulset у нас тоже есть, но их пишет одна команда, а остальные переиспользуют)
А здесь нас закрывает свои authorization и admission webhook (про них чуть детальнее рассказывал на Highload, как раз 2 декабря :)). В наш общий чарт вписано только то, что точно можно использовать, и то, некоторые из параметров в values закрыты проверками в нашем портале для разработчиков (т.е. только специально обученный человек может выписать для cервиса права на использование какого-нибудь флажочка, например, hostNetwork, для системы мониторинга)
Привет. Прекрасно, что такие истории факапов помогают людям преодолеть себя и вести дискуссию :)
Нет, конечно же, все это автоматизировано, как и написано в статье - пару-тройку дней летит обновление\фикс, который дрейнит ноды и все само переезжает.
Все верно, это болячка, которая есть при остановке. Но, мы блокировали только calico etcd, а не etcd для всего kubernetes, так что теряли по сути только часть которая касается сетевого плагина, это гораздо меньшее из зол, т.к. все пробы, например, продолжают работать.
Да, на него нагрузка сильно увеличивается, но наши API-server даже не поперхнулись в этой части.
Calico с режимом хранения информации прямо в ETCD ходит, как раз и перевозили на kubernetes API (https://docs.tigera.io/calico/latest/operations/datastore-migration)
Конкретно в этом кейсе чистили как раз не ноду целиком, а только сетевые неймспейсы, а вся остальная инфа остается на ноде как и прежде. В большинстве случаев, мы, конечно же, не мелочимся, и если нужно "почистить" ноду, то мы ее просто полностью удаляем и выкатываем совсем новую на ее место.
Я там в начале статьи писал, что у нас несколько разных конфигураций нод (где-то rpm-based, где-то deb, какие-то ноды выделены под общую нагрузку, а какие-то под особенную), поэтому вариант пройтись "руками" ( запускал условный `ansible hostname1,hostname32 -i inv.yml -m shell -a 'systemctl stop kubelet && systemctl stop containerd && sedgrepawk && ip netns delete...'`) все еще подходит чтобы достаточно достоверно провериить что оно работает для всех кейсов, после чего и был за 5 минут написан нормальный плейбук, который потом и полетел по серверам :)
Да, это был container registry. Постараюсь такие моменты в будущем отмечать, потому что внутри привыкли, что registry это всегда про контейнеры, а все остальные registry у нас больше repository
У нас разработчики все выкатывают с помощью helm в котором да, фактически чистые Deployment и STS
Нод столько, как раз чтобы экономить :D. Нагрузка там от разработчиков, тестировщиков и прочих причастных к приложениям. В препроде меньше нод чем в стейдже, потомучто он не пользуется у нас большой популярностью, к сожалению, и это как раз хочется исправить, чтобы однажды наш stage и правда был тем самым dev, который не страшно уложить. Мы потом выключали также кластера k8s в pre и prod, и там не было никаких проблем и тонны вопросов "ну чо, кагда?", потому что pre и prod в нескольких экземплярах в отличии от stage
Объективная критика не может быть резкой. Спасибо за такой объемный и детальный комент, такое всегда полезно 🤜🤛
dragonfly с нами два года уже. отлично себя показывает. но вот на таких проверках наши новые узкие места)
все так, дельный совет. у нас dragonfly пир как раз в каждом слое и вот он немного не справился из-за необходимости скачать почти 5000 образов разом. добавили в них ресурсов
У нас там были базы данных. Просто стейдж у нас всего в одном ДЦ и он выключился весь, а препрод и прод в нескольких и там мы тоже выключали куберы, но уже после замены сети, чтобы не совмещать. Все приложения, в том числе и базы, нормально пережили это приключение)
Да, когда сервисы с ноды на ноду переезжают сами без лишних вмешательств, нужно придумывать новые способы занять руки и свободные вечера 😅