Комментарии 55
Вот почитал и опять пропало желание изучать k8s, которое появилось пару дней назад и было отложено на выходные. Опять подтвердилось впечатление, что для одной системы пускай из полусотни сервисов это из пушки по воробьям с одной стороны, а, с другой, что один человек с нулевыми знаниями по всяким BGB и IP-in-IP и год поднимать может эту систему до состояния «закоммитил-нажал кнопку-задеплоилось». И это уже в докеризированной и кластеризированной системе (docker swarm mode).
Или есть таки разработчики, которые это осилили в одиночку?
Или есть таки разработчики, которые это осилили в одиночку?
Я пока на начальной стадии внедрения. Первые впечатления не очень. Ну т.е. для менеджера все выглядит круто, ты можешь ткнуть одну кнопку в «магазине приложений» и вот у тебя уже как-то само собой собрался кластер и даже отвечает на внешние запросы. Но внутри столько движущихся частей, что даже страшно представить что будет если там что-то упадет…
Сам кластер kubernetes очень легко и просто собирает Rancher, но вот дальше…
Сам кластер kubernetes очень легко и просто собирает Rancher, но вот дальше…
Это один из самых частых вопросов, который мне задают.
У меня примерно следующее мнение:
— Если работаешь в одиночку, используй k8s, который кто-то другой поддерживает (GKE)
— Если нельзя иметь внешний k8s — обязательно нужно иметь команду, которая умеет его настраивать и отлаживать. Это необходимо, чтобы минимизировать время простоя когда что-то «пойдет не так».
— Если бизнес не требователен к SLA — можно и самому в одиночку настраивать и разбираться.
UPD: я — автор доклада.
У меня примерно следующее мнение:
— Если работаешь в одиночку, используй k8s, который кто-то другой поддерживает (GKE)
— Если нельзя иметь внешний k8s — обязательно нужно иметь команду, которая умеет его настраивать и отлаживать. Это необходимо, чтобы минимизировать время простоя когда что-то «пойдет не так».
— Если бизнес не требователен к SLA — можно и самому в одиночку настраивать и разбираться.
UPD: я — автор доклада.
Во, хороший шанс обратиться как к автору доклада:
1. Для ускорения получения контейнеров можно использовать Dragonfly. Это P2P система хранения с поддержкой Docker Registry протокола.
2. Kubernetes уже 1.11 вышел. Secret давно стабильны. Плюс еще много чего появилось, но думаю вы вкурсе.
3. Для локальной разработки можно (и возможно нужно) использовать Skaffold. Очень интересная утилитка, поддерживает Helm.
4. Для роутинга между подами и сервисами, ингресов, трейсов и еще кое-чего можно использовать Istio.
5. Споты в Kops тоже конечно же давно есть. Но это опять же, просто презентация старая.
6. На счет глобального роутинга — тут federation конечно поможет, но очень зависит от инфраструктуры под ногами.
7. На счет нескольких кластеров… тут важен объем. В ином случае Labels, Taints, NodeSelectors, Limits и Affinity решают вопросы разделения ресурсов и уплотнения. Но можно и несколько кластеров, конечно. Хотя без всех этих штук все равно сложно обойтись.
8. Автоскейлингом занимается Pod Autoscaler, он platform-agnostic. А вот Node Autoscaler в режиме AWS действительно скелит ноды.
9. У Helm, хоть я его не очень и люблю, есть свои dependency между чартами и hooks, что позволяет деплоить и обновлять продукт вместе со всеми зависимостями в правильном порядке, храня только 1 (ну или сколько удобно) конфигурационный файл для stage. Не очень понятно зачем нужны еще какие-то инструменты поверх него (или рядом).
1. Для ускорения получения контейнеров можно использовать Dragonfly. Это P2P система хранения с поддержкой Docker Registry протокола.
2. Kubernetes уже 1.11 вышел. Secret давно стабильны. Плюс еще много чего появилось, но думаю вы вкурсе.
3. Для локальной разработки можно (и возможно нужно) использовать Skaffold. Очень интересная утилитка, поддерживает Helm.
4. Для роутинга между подами и сервисами, ингресов, трейсов и еще кое-чего можно использовать Istio.
5. Споты в Kops тоже конечно же давно есть. Но это опять же, просто презентация старая.
6. На счет глобального роутинга — тут federation конечно поможет, но очень зависит от инфраструктуры под ногами.
7. На счет нескольких кластеров… тут важен объем. В ином случае Labels, Taints, NodeSelectors, Limits и Affinity решают вопросы разделения ресурсов и уплотнения. Но можно и несколько кластеров, конечно. Хотя без всех этих штук все равно сложно обойтись.
8. Автоскейлингом занимается Pod Autoscaler, он platform-agnostic. А вот Node Autoscaler в режиме AWS действительно скелит ноды.
9. У Helm, хоть я его не очень и люблю, есть свои dependency между чартами и hooks, что позволяет деплоить и обновлять продукт вместе со всеми зависимостями в правильном порядке, храня только 1 (ну или сколько удобно) конфигурационный файл для stage. Не очень понятно зачем нужны еще какие-то инструменты поверх него (или рядом).
О, за Dragonfly отдельное спасибо! Мы делали подобную тулзу, но не довели ее до OpenSource, а тут уже готовое.
Да, докладу почти год уже, поэтому много что устарело (показатель активного развития k8s)
Про Helm и все окружение вокруг (Skaffold) я на РИТ++ делал доклад.
rootconf.ru/moscow-rit/2018/abstracts/3539
Видео пока нет, но слайды доступны.
Проблем у Helm много, когда проекты сильно взаимосвязаны, и есть транзитивные зависимости. Их сложно конфигурировать, тестировать (да и разрабатывать).
Да, докладу почти год уже, поэтому много что устарело (показатель активного развития k8s)
Про Helm и все окружение вокруг (Skaffold) я на РИТ++ делал доклад.
rootconf.ru/moscow-rit/2018/abstracts/3539
Видео пока нет, но слайды доступны.
Проблем у Helm много, когда проекты сильно взаимосвязаны, и есть транзитивные зависимости. Их сложно конфигурировать, тестировать (да и разрабатывать).
Посмотрел слайды, любопытно.
Может по слайдам просто непонятно, но я не очень согласен со «Сквозное конфигурирование? Нет». Оно там есть, при установке базового чарта можно передать конфигурацию зависимым. Но, возможно, оно не про это. Если не про это — скажите про что, интересно:)
На счет транзитивных зависимостей — да, их можно сказать что нет, точнее есть, но ломаются часто из-за кросс зависимостей.
В целом, я стараюсь вообще их избегать и деплоить в несколько шагов то, что можно деплоить в несколько шагов, но если очень надо — попробуйте Degasolv. Он универсальный, но тут тоже сгодится, заменяет requirement.yaml, но правда добавляет один шаг на собственно сборку зависимостей. Лечит дубликаты зависимостей и подобные штуки.
Но тут я согласен, да. Helm далеко не идеален.
Может по слайдам просто непонятно, но я не очень согласен со «Сквозное конфигурирование? Нет». Оно там есть, при установке базового чарта можно передать конфигурацию зависимым. Но, возможно, оно не про это. Если не про это — скажите про что, интересно:)
На счет транзитивных зависимостей — да, их можно сказать что нет, точнее есть, но ломаются часто из-за кросс зависимостей.
В целом, я стараюсь вообще их избегать и деплоить в несколько шагов то, что можно деплоить в несколько шагов, но если очень надо — попробуйте Degasolv. Он универсальный, но тут тоже сгодится, заменяет requirement.yaml, но правда добавляет один шаг на собственно сборку зависимостей. Лечит дубликаты зависимостей и подобные штуки.
Но тут я согласен, да. Helm далеко не идеален.
Я скорее про ситуацию, когда есть команда, работающая «по старинке» и хочется предоставить рабочее решение обычных задач типа оркестрации контейнеров, чтоб команда на него перешла или, хотя бы, пощупала его и аргументировано отвергла.
Сложно дать «сферический ответ в вакууме», все сильно зависит от многих условий:
— где вы запускаетесь (железо/облака)
— подойдет ли вам попробовать GKE или аналоги
— что значит «пощупала»? Какие-то сервисы для staging попускала?
— какая цена ошибки? Возможен ли простой в несколько часов, пока инженеры пытаются восстановить сломанную во время «щупания» систему?
— насколько много инженеров понимают инфраструктуру k8s, чтобы сделать правильный выбор конфигурационных параметров?
— насколько много долгоживущих монолитов с внутренним стейтом, которые довольно сложно перетащить на k8s?
— если запускать часть сервисов в k8s рядом с работающей системой, насколько критично возрастание latency?
И таких вопросов еще много, я просто написал самое очевидное.
Если хочется потрогать, что это вообще такое — запустите где-нибудь k8s, это сейчас реально делается в пару кликов:
kubernetes.io/docs/setup/pick-right-solution
Самое сложное — что придется менять привычки разработчиков (пресловутый docker-way)
— где вы запускаетесь (железо/облака)
— подойдет ли вам попробовать GKE или аналоги
— что значит «пощупала»? Какие-то сервисы для staging попускала?
— какая цена ошибки? Возможен ли простой в несколько часов, пока инженеры пытаются восстановить сломанную во время «щупания» систему?
— насколько много инженеров понимают инфраструктуру k8s, чтобы сделать правильный выбор конфигурационных параметров?
— насколько много долгоживущих монолитов с внутренним стейтом, которые довольно сложно перетащить на k8s?
— если запускать часть сервисов в k8s рядом с работающей системой, насколько критично возрастание latency?
И таких вопросов еще много, я просто написал самое очевидное.
Если хочется потрогать, что это вообще такое — запустите где-нибудь k8s, это сейчас реально делается в пару кликов:
kubernetes.io/docs/setup/pick-right-solution
Самое сложное — что придется менять привычки разработчиков (пресловутый docker-way)
Вот как раз с docker-way проблем нет, всё (кроме СУБД) в контейнерах по возможности в стиле лучших практик докера и 12 факторов, есть работающие кластеры (prod, stage и т. п.) на своём или условно своём (vmware облако) железе под оркестрацией docker в swarm mode, а так же локально у девов (аналог minicube). Но для нормальной работы они требуют сторонних тулзовин и баш скриптов, полноценное добавление нового сервиса в систему в лучшем случае копипастом получается только у некоторых, шаг влево-шаг вправо — паника.
Пока основная цель — чтобы команда захотела перейти (вернее первая — разобраться настолько чтобы самому захотеть), то есть основные ожидания от k8s — упростить работу без снижения скорости доставки и надежности. Как это «продать» бизнесу — это следующий этап.
Пока основная цель — чтобы команда захотела перейти (вернее первая — разобраться настолько чтобы самому захотеть), то есть основные ожидания от k8s — упростить работу без снижения скорости доставки и надежности. Как это «продать» бизнесу — это следующий этап.
Есть, я в свое время в одиночку вполне разобрался. Поначалу сложно, но после понимания концепции пойдет легче.
Преимущество, он же недостаток — гибкость. Очень широкий спект применения, отсюда очень много моментов, где можно споткнуться и сделать не так. Но решаемо.
BGP и IP-in-IP по началу не нужен совсем. Большинство CNI просто работают при условии соблюдения инструкции по установке.
В общем не все так страшно.
Преимущество, он же недостаток — гибкость. Очень широкий спект применения, отсюда очень много моментов, где можно споткнуться и сделать не так. Но решаемо.
BGP и IP-in-IP по началу не нужен совсем. Большинство CNI просто работают при условии соблюдения инструкции по установке.
В общем не все так страшно.
НЛО прилетело и опубликовало эту надпись здесь
Всё-таки пришлось плотно в это ввязаться. С одной стороны, немного не так страшно, как казалось. С другой, возможности которые считал базовыми отсуствуют и приходится городить bash скрипты или типа того для оркестрации оркестратором.
Kubernetes — один кубик, а таких кубиков должно быть 100.
Kubernetes — это не кубик, он скорее каркас для кубиков или даже конструктор)
Docker кстати тоже не нужен. Вот аргументы:
Разработчиков пишуших софт, работающий только на побитовых копиях их систем нужно бить плеткой.
— Docker полезен исключительно для воссоздания кривых окружений кривых программ (непременно stateless)
— В подавляющем большинстве случаев люди пытаются внедрением Docker компенсировать изначально кривую архитектуру своих приложенияй. Когда это не помогает начинаются разговоры о том, что Kubernetes поможет решить проблемы, но это приводит лишь к новым сложностям
— Docker вводит лишний уровень абстракции, зачастую там где она не нужна
— Содержимое Docker контейнера крайне плохо поддается аудиту
— Docker крайне не прост в настройке и поддержке. Большинство людей которые все же используют докер редко уходят дальше «Just use the docker image»
— Корректная настройка Docker требует найма дополнительного персонала с очень специфическими навыками. Уметь правильно настраивать сесть != уметь правильно настраивать сесть в Docker
— Docker никогда не бывает один и тянет за собой огромную экосистему. Этим он похож на NodeJS, когда очень скоро оказывается, что ваше Hello World приложение зависит от 300 разных библиотек и плагинов.
— Большинство проблем с масштабированием проще\надежнее решить без использования Docker
источник
Каждая новая абстракция это лишняя точка отказа. Уверен, скоро хайп около докера спадет и куча компаний ужаснется от того, что они наворотили. Перенимая «лучшие практики от Google» люди почему то забывают, что они не Google и даже не Amazon.
Разработчиков пишуших софт, работающий только на побитовых копиях их систем нужно бить плеткой.
— Docker полезен исключительно для воссоздания кривых окружений кривых программ (непременно stateless)
— В подавляющем большинстве случаев люди пытаются внедрением Docker компенсировать изначально кривую архитектуру своих приложенияй. Когда это не помогает начинаются разговоры о том, что Kubernetes поможет решить проблемы, но это приводит лишь к новым сложностям
— Docker вводит лишний уровень абстракции, зачастую там где она не нужна
— Содержимое Docker контейнера крайне плохо поддается аудиту
— Docker крайне не прост в настройке и поддержке. Большинство людей которые все же используют докер редко уходят дальше «Just use the docker image»
— Корректная настройка Docker требует найма дополнительного персонала с очень специфическими навыками. Уметь правильно настраивать сесть != уметь правильно настраивать сесть в Docker
— Docker никогда не бывает один и тянет за собой огромную экосистему. Этим он похож на NodeJS, когда очень скоро оказывается, что ваше Hello World приложение зависит от 300 разных библиотек и плагинов.
— Большинство проблем с масштабированием проще\надежнее решить без использования Docker
источник
Каждая новая абстракция это лишняя точка отказа. Уверен, скоро хайп около докера спадет и куча компаний ужаснется от того, что они наворотили. Перенимая «лучшие практики от Google» люди почему то забывают, что они не Google и даже не Amazon.
Всегда надо искать баланс, конечно же.
Да, у докера есть минусы, но большинство перечисленного — это просто перегретая параноя :)
Да, у докера есть минусы, но большинство перечисленного — это просто перегретая параноя :)
Одна из основных целей внедрения докера не перенос окружения разработчика на продакшн, а ровно наоборот. Девелопер или девопс описывают продакшн окружение, которое можно использовать и как девелоперское. И по сути докер не абстракция, а инструмент по типу bash скриптов провижинга и деплоя.
beduin01, не обязательно пихать в Docker все, что запускается. Docker — это всего лишь инструмент, не универсальный и не для всех случаев оптимальный. Если хорошо понимать преимущества, возможности и недостатки докера, то его можно вполне себе использовать там, где он полезен.
Приведу примеры, когда он полезен:
1) Быстрое развертывание больших проектов для девелоперов. Абстракция ОС позволяет практически одинаково работать девелоперам в различных ОС — Windows/*nix/OS X и поднимать проект под разработку за минуты, а не часы и не волноваться про зависимости.
2) Как единый инструмент, объединяющий developers и devops. Например, посмотрев на содержимое docker-compose.yml devops смогут корректно настроить stage, prod, бакапы, мониторинг и прочее. Причем для prod оно может быть и не в docker. Версионирование также помогает быстро понять, какие изменения между версиями в сервисах и настройках.
3) Возможность удобного развертывания различных сценариев тестирования проекта(нагрузочные, разные версии ПО и т.д.) в разных конфигурациях сервисов и железа.
И это только про Docker. Для Kubernetes нужны свои, весьма крупные причины для развертывания, поддержания корректной работы и разруливания нештатных ситуаций. А учитывая активную разработку k8s и постоянное появление новых возможностей, эта технология еще и дорогая в обслуживании.
Приведу примеры, когда он полезен:
1) Быстрое развертывание больших проектов для девелоперов. Абстракция ОС позволяет практически одинаково работать девелоперам в различных ОС — Windows/*nix/OS X и поднимать проект под разработку за минуты, а не часы и не волноваться про зависимости.
2) Как единый инструмент, объединяющий developers и devops. Например, посмотрев на содержимое docker-compose.yml devops смогут корректно настроить stage, prod, бакапы, мониторинг и прочее. Причем для prod оно может быть и не в docker. Версионирование также помогает быстро понять, какие изменения между версиями в сервисах и настройках.
3) Возможность удобного развертывания различных сценариев тестирования проекта(нагрузочные, разные версии ПО и т.д.) в разных конфигурациях сервисов и железа.
И это только про Docker. Для Kubernetes нужны свои, весьма крупные причины для развертывания, поддержания корректной работы и разруливания нештатных ситуаций. А учитывая активную разработку k8s и постоянное появление новых возможностей, эта технология еще и дорогая в обслуживании.
А базы(postgres, elastic) вы держите в кубернетесе или выносите на физ.машины?
Выносим, пока еще не дошли до нужного уровня смелости :)
В случае облаков проще брать как сервис (если есть).
Если не облака или нет нужно базы — можно внутри, главное чтобы стораджи позволяли динамическое монтирование и имели достаточную скорость.
Если не облака или нет нужно базы — можно внутри, главное чтобы стораджи позволяли динамическое монтирование и имели достаточную скорость.
Присоединяюсь к вопросу. Хотелось бы узнать, как производится миграция изменений в реляционных БД. Обновление скриптами, дампами, использование утилит миграции типа Liquibase?
Я бы вообще хотел узнать, хоть кто-нибудь запускает уже бд в k8s? Отзовитесь, если такие есть??
Да, запускает:)
Что интересно?
Что интересно?
* Что используете в качестве файлового стораджа;
* насколько большие базы(ну и тип указать желательно);
* Нет ли проблем с latency / просадок по скорости;
* Насколько стабильно работают
* насколько большие базы(ну и тип указать желательно);
* Нет ли проблем с latency / просадок по скорости;
* Насколько стабильно работают
В целом — ничего особенного.
1. EBS/Compute Engine PD в зависимости от облака. На своем — либо то, что предоставляет OpenStack, допустим, либо iSCSI/CephFS. Хотя последний я недолюбливаю, если честно:)
В целом по эксплуатационной части результат примерно один. Есть еще варианты с локальными стораджами.
2. Базы не очень большие, в пределах десятков ГБ. Postgres, Mongo, Elastic.
3. Проблемы есть ровно те же, как и просто с базами на виртуальных машинах. Исключение — сетевой сторадж, он дает задержки, хотя он и на виртуалках бывает. Но тут решается вариантом мультимастер + локальные стораджи с пересозданием при перезапуске. При условии достаточно стабильной инфраструктуры может быть не очень накладным выходом из ситуации.
4. Принципиальных отличий в стабильности от просто баз, развернутых на виртуалках, не находил.
В целом, Kubernetes позволяет повторить практичечески ту же самую конфигурацию БД, что была бы без него, так что каких-то ограничений (как и больших преимуществ) в переносе баз в него я привести не могу.
1. EBS/Compute Engine PD в зависимости от облака. На своем — либо то, что предоставляет OpenStack, допустим, либо iSCSI/CephFS. Хотя последний я недолюбливаю, если честно:)
В целом по эксплуатационной части результат примерно один. Есть еще варианты с локальными стораджами.
2. Базы не очень большие, в пределах десятков ГБ. Postgres, Mongo, Elastic.
3. Проблемы есть ровно те же, как и просто с базами на виртуальных машинах. Исключение — сетевой сторадж, он дает задержки, хотя он и на виртуалках бывает. Но тут решается вариантом мультимастер + локальные стораджи с пересозданием при перезапуске. При условии достаточно стабильной инфраструктуры может быть не очень накладным выходом из ситуации.
4. Принципиальных отличий в стабильности от просто баз, развернутых на виртуалках, не находил.
В целом, Kubernetes позволяет повторить практичечески ту же самую конфигурацию БД, что была бы без него, так что каких-то ограничений (как и больших преимуществ) в переносе баз в него я привести не могу.
Вроде как Youtube запускает MySQL: vitess.io,
а Lazada/Alibaba Group Postgres: github.com/paunin/PostDock.
В целом, вопрос то только в целесообразности в конкретном случае.
а Lazada/Alibaba Group Postgres: github.com/paunin/PostDock.
В целом, вопрос то только в целесообразности в конкретном случае.
А можете поподробнее рассказать о Error Budget? Откуда берете приемлемое количество ошибок, как аргументируете бизнесу что «вот сейчас команде релизить нельзя», как пришли с этим к командам и объяснили почему так? И как возникла такая мысль)
За автора не отвечу, но могу рассказать из своего опыта.
Error Budget в целом высчитвывается статистически на основании требований бизнеса и текущей реальности.
Все ошибаются. Иногда что-то идет не так. Это факт. Допустим, мы волевым решением и на основании статистики принимаем решение что 3 релиза из 100 могут пойти не так. То есть для нас Error Budget — 3% (это достаточно высоко, в реальности бюджет не должен превышать 1, максимум 2 процентов).
После этого мы просто начинаем учитывать это в выкатке релизов, т.к. это является аггрегированным показателем качества.
Если ребята катят и не выходят за пределы бюджета, значит в целом качество кода хорошее и можно не боясь катиться практически в любое время.
Если команда начинает выходить за пределы бюджета, то процесс релизов приостанавливается до принятия мер, так как превышение бюджета явно свидетельствует о том, что что-то идет на так в команде, качество когда упало, возникла нестабильность и непонятно где оно стрельнет в следующий раз.
А обоснование для бизнеса простое — мы наблюдаем проблемы с качеством новых версий приложения. Или мы притормаживаем, разбираем инциденты, выясняем проблему и решаем ее, чтобы все было хорошо, или рано или поздно и скорее всего в ближайшее время у нас будут большие проблемы, которые дестабилизируют продукт с непредсказуемыми последствиями. Обычно такого объяснения для бизнеса достаточно, т.к. факты и статистика в наличии и однозначны в трактовке.
Error Budget в целом высчитвывается статистически на основании требований бизнеса и текущей реальности.
Все ошибаются. Иногда что-то идет не так. Это факт. Допустим, мы волевым решением и на основании статистики принимаем решение что 3 релиза из 100 могут пойти не так. То есть для нас Error Budget — 3% (это достаточно высоко, в реальности бюджет не должен превышать 1, максимум 2 процентов).
После этого мы просто начинаем учитывать это в выкатке релизов, т.к. это является аггрегированным показателем качества.
Если ребята катят и не выходят за пределы бюджета, значит в целом качество кода хорошее и можно не боясь катиться практически в любое время.
Если команда начинает выходить за пределы бюджета, то процесс релизов приостанавливается до принятия мер, так как превышение бюджета явно свидетельствует о том, что что-то идет на так в команде, качество когда упало, возникла нестабильность и непонятно где оно стрельнет в следующий раз.
А обоснование для бизнеса простое — мы наблюдаем проблемы с качеством новых версий приложения. Или мы притормаживаем, разбираем инциденты, выясняем проблему и решаем ее, чтобы все было хорошо, или рано или поздно и скорее всего в ближайшее время у нас будут большие проблемы, которые дестабилизируют продукт с непредсказуемыми последствиями. Обычно такого объяснения для бизнеса достаточно, т.к. факты и статистика в наличии и однозначны в трактовке.
Все так!
Сперва, конечно, надо заручиться поддержкой бизнеса, но это достаточно легко аргументировать, потому что Error Budget вводится ради стабильности :)
Но мы считаем не проценты «хороших релизов», а просто считаем SLA в наших бизнес метриках (простейшее решение для API: кол-во 5xx / общее кол-во запросов). Все плохие релизы сильно снижают этот SLA.
Далее, мы выбираем, ниже какого SLA мы не разрешаем опускаться, и с помощью метода «пристального взгляда» вычисляем, на каких уровнях мы перестаем разрешать релизить новые фичи.
Лично у нас пока не сложилось до конца понимание, как сделать правильно, все до сих пор в стадии становления.
Сперва, конечно, надо заручиться поддержкой бизнеса, но это достаточно легко аргументировать, потому что Error Budget вводится ради стабильности :)
Но мы считаем не проценты «хороших релизов», а просто считаем SLA в наших бизнес метриках (простейшее решение для API: кол-во 5xx / общее кол-во запросов). Все плохие релизы сильно снижают этот SLA.
Далее, мы выбираем, ниже какого SLA мы не разрешаем опускаться, и с помощью метода «пристального взгляда» вычисляем, на каких уровнях мы перестаем разрешать релизить новые фичи.
Лично у нас пока не сложилось до конца понимание, как сделать правильно, все до сих пор в стадии становления.
Да, все так, конечно метрика «хороший\плохой» релиз она обобщенная и для понимания. У каждого свои метрики. Но, кстати, метрика "!302/301/200/403"/ «количество запросов» будет немного удачнее, чем «кол-во 5xx / общее кол-во запросов» мне кажется. Но я думаю с вашей стороны это тоже был пример.
А вот с 404 нужно быть аккуратнее, ее можно получить и без проблем в коде, лучше мониторить отдельно и эмперически добавлять к основной именно тогда, когда она вызвана именно продуктом.
А вот с 404 нужно быть аккуратнее, ее можно получить и без проблем в коде, лучше мониторить отдельно и эмперически добавлять к основной именно тогда, когда она вызвана именно продуктом.
Немного не понял в статье вот эту часть про minicube
Вопрос — в чем тут проблема? Если у меня на макбуке стоит докер я не могу использовать minicube?
P.S. докер использую активно, до k8s никак руки не дойдут, хотел поставить minicube — поиграться.
Я работаю на MacOS, у меня Mac, соответственно, чтобы запускать локальный апп, мне нужно запускать локально докер. Это сделать никак нельзя
Вопрос — в чем тут проблема? Если у меня на макбуке стоит докер я не могу использовать minicube?
P.S. докер использую активно, до k8s никак руки не дойдут, хотел поставить minicube — поиграться.
На счет поставить minikube, в Docker for Mac он уже есть — docs.docker.com/docker-for-mac/kubernetes, достаточно ткнуть галочку.
Ну и да, никаких проблем в этом нет.
Ну и да, никаких проблем в этом нет.
1. Я рассказывал этот доклад еще до того момента, когда на MacOS был докер нормальный
2. Я сейчас не использую minikube совсем, мне он кажется не очень удобным. Поэтому я не большой знаток.
3. Если я не ошибаюсь, когда вы устанавливаете minikube, у вас используется один из гипервизоров, установленных на машине (VirtualBox, xhyve, VMWare Fusion), и не использует дефолтный докер. Т.е. у вас будет два разных докера на машине :)
Но я не эксперт в этом, могу и ошибаться
2. Я сейчас не использую minikube совсем, мне он кажется не очень удобным. Поэтому я не большой знаток.
3. Если я не ошибаюсь, когда вы устанавливаете minikube, у вас используется один из гипервизоров, установленных на машине (VirtualBox, xhyve, VMWare Fusion), и не использует дефолтный докер. Т.е. у вас будет два разных докера на машине :)
Но я не эксперт в этом, могу и ошибаться
На мой взгляд самый большой минус k8s — это то, что после весьма солидного времени, которое нужно потратить на порог вхождения в него, ты понимаешь, что впереди придется потратить еще большее количество времени на все то, что вокруг него. Kubernetes без ELK, Prometheus, Grafana, какой-нибуь CI сегодня — ничто. Важен именно интеграционный опыт вокруг Kubernetes, а не способность разбираться в нем самом
Да, поэтому если команда маленькая — надо пользоваться готовыми инсталяциями: GKE, EKS,…
Kubernetes без ELK, Prometheus, Grafana, какой-нибуь CI сегодня — ничто.
А для обычных серверов или ВМ это всё не нужно?
Нужно конечно. Просто в случае kubernetes, с ELK к примеру, вам понадобится: как минимум настроить провайдер PersistentVolume для самого elasticsearch (я настраивал для Vsphere, та ещё задачка, особенно когда документация безбожно устарела), discovery модуль для filebeat (который будет парсить k8s теги автоматом) В случае Prometheus — это как минимум kube-prometheus и оператор оттуда же. И вот куда не плюнь, везде понадобится нетривиальная настройка для kubernetes. А вот если все это хорошо заведется — профит огромный, все становится очень красиво.
Так и без k8s вся эта обвязка (CI/логи/метрики) в том или ином виде присутствует, нет?
Есть опыт настройки деплоя review apps в GitLab CI — когда на каждую feature ветку динамически создается отдельный инстанс системы с изменениями из этой ветки. Тут k8s + helm хорошо помогли. Создали helm chart для системы, в процессе CI из него устанавливаем систему, указывая значения из контекста пайплайна (имя ветки и т.п.). Добавляем ingress с роутингом по поддомену (feature1.myapp.com) и всё работает. Конечно, другими средствами это тоже можно сделать, но с k8s это весьма элегантно и понятно получилось.
> с k8s это весьма элегантно и понятно получилось.
То же могу сказать про docker swarm mode + docker flow proxy. И в целом почти никаких новых концепций для людей знакомых с docker-compose
То же могу сказать про docker swarm mode + docker flow proxy. И в целом почти никаких новых концепций для людей знакомых с docker-compose
Не хотите поподробнее об этом рассказать? Или, может, есть статья хорошая на эту тему? Мы как раз вовсю используем Docker Executors в Gitlab CI и думаем перейти на k8s.
Одной статьи, где описывается весь процесс, нет. Собирал из разных источников и экспериментировал. Я планирую сделать публикацию, но позже.
Вот ссылка на проект, где реализован пайплайн gitlab.com/drim-consulting/public/devops/git-flow-ci-cd. Это проект для тренинга, который я на текущий момент готовлю. Там реализован автоматический деплой в рамках git flow, включая, как раз, динамический деплой review apps. Проект еще не полностью отполирован (в частности, не проработано версионирование), но он работает и демонстрирует связку технологий, примененную для CI/CD.
Если концептуально, то каждое окружение деплоится из helm chart в отдельный k8s namespace. Для формирования имен используется
Плюс используется концепция dynamic environments, позволяющая интегрировать развернутые окружения в GitLab UI. К примеру, можно прям со страницы с деталями merge request перейти на развернутое приложение. Также настроено автоматическое удаление приложения после удаления environment, которое автоматически происходит после удаления ветки.
Для выполнения jobs я использую shell executor. Изначально пробовал Docker executors, но потом наткнулся на проблему переиспользования слоев при сборке образов, и отложил эту задачу, чтобы не усложнять процесс на первом этапе. Образы собираются на машине с executors, потом пушатся в GitLab Container Registry. Креды для логина GitLab CI предоставляет в виде переменных окружения.
Если после изучения проекта останутся вопросы, пишите или здесь, или в личку, с удовольствием отвечу на них.
Вот ссылка на проект, где реализован пайплайн gitlab.com/drim-consulting/public/devops/git-flow-ci-cd. Это проект для тренинга, который я на текущий момент готовлю. Там реализован автоматический деплой в рамках git flow, включая, как раз, динамический деплой review apps. Проект еще не полностью отполирован (в частности, не проработано версионирование), но он работает и демонстрирует связку технологий, примененную для CI/CD.
Если концептуально, то каждое окружение деплоится из helm chart в отдельный k8s namespace. Для формирования имен используется
$CI_COMMIT_REF_SLUG — очищенное имя ветки, предоставляемое GitLab CI. Оно же используется для создания ingress с правилом роутинга по поддомену типа feature1.myapp.com. В каждом пространстве имен создается отдельный ingress, который потом используется для формирования общего набора правил nginx для роутинга по поддоменам.Плюс используется концепция dynamic environments, позволяющая интегрировать развернутые окружения в GitLab UI. К примеру, можно прям со страницы с деталями merge request перейти на развернутое приложение. Также настроено автоматическое удаление приложения после удаления environment, которое автоматически происходит после удаления ветки.
Для выполнения jobs я использую shell executor. Изначально пробовал Docker executors, но потом наткнулся на проблему переиспользования слоев при сборке образов, и отложил эту задачу, чтобы не усложнять процесс на первом этапе. Образы собираются на машине с executors, потом пушатся в GitLab Container Registry. Креды для логина GitLab CI предоставляет в виде переменных окружения.
Если после изучения проекта останутся вопросы, пишите или здесь, или в личку, с удовольствием отвечу на них.
Такой вопрос, вот сейчас вышел k8s 1.11, но мы использует для развертывания в AWS — kops, который на данный момент поддерживает только 1.9 и 1.10 в стадии альфы.
Стоит ли пытаться как-то иначе пытаться ставить новейшую версию k8s или в этом плане kops стараются довольно быстро их догнать?
Аутентификация у Вас работает через dex, он крутится также в кубере или это отдельный инстанс где-то?
В каком случае нужно будет начинать заботиться о сети, если кластер просто предназначен для того, чтобы сайтики хостить со всякими деплоями и обычным nginx-ingress?
Стоит ли пытаться как-то иначе пытаться ставить новейшую версию k8s или в этом плане kops стараются довольно быстро их догнать?
Аутентификация у Вас работает через dex, он крутится также в кубере или это отдельный инстанс где-то?
В каком случае нужно будет начинать заботиться о сети, если кластер просто предназначен для того, чтобы сайтики хостить со всякими деплоями и обычным nginx-ingress?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 причин [не] использовать k8s