Заявки на доклады

Поиск по тегам:

Инфраструктура как код

Способов развёртывания кластера kubernetes насчитывается не один десяток, как на bare-metal, так и на различных облачных платформах. Начинающие администраторы k8s обычно используют одну из известных утилит для сборки кластера и лишь намного позже узнают о подводных камнях того или иного решения. Каждый инсталлятор k8s содержит набор предубеждений его создателя, которые могут помешать настроить и собрать кластер так, как нужно конкретной компании. Когда приходит осознание, что дефолты инсталлятора не подходят для нужд компании, на кластере давным-давно production-нагрузки и пересобирать его уже нельзя. Я расскажу, как неинвазивно переехать на наиболее конфигурируемый kubernetes the hard way и приведу примеры сценариев факапов и как их избежать.

Программный комитет ещё не принял решения по этому докладу

Инфраструктурная платформа

Облака - это модно и молодёжно. Однако, недостаточно просто перевезти свою инфраструктуру в облако, важно сохранить контроль над её состоянием и стоимостью. Мало определиться с принципами построения системы -- нужен ещё и способ проводить выбранную политику в жизнь. Владельцу любого облака важно понимать, что происходит с его ресурсами, запрещать сомнительные и/или дорогие практики, следить за безопасностью, пресекать подозрительную активность и т.п.

Именно это позволяет вам сделать Cloud Custodian - опенсорсный и бесплатный продукт, позволяющий админам настраивать политики контроля за облачными ресурсами в любом из трёх облачных сервисов - GCP, AWS, Azure. Можно задать и действия, которые будут автоматически выполняться по тому или иному интересующему вас событию. Cloud Custodian может отслеживать старт новых виртуальных машин в Compute Engine, развертывание новых кластеров Kubernetes, создание новых ролей в IAM, добавление прав пользователям, появление бесхозных бекапов и т.п.

Подобного рода задачи обычно решаются либо бдительным администратором-одиночкой, либо набором shell-скриптов, однако Cloud Custodian позволяет автоматизировать все эти операции, а также кодифицировать и версионировать ваши политики управления существующей инфраструктурой.

Программный комитет ещё не принял решения по этому докладу

SRE-практики

Основная идея что чатопс может сильно упрощать жизнь RnD, добавляет прозрачности в работу отдела, убирает рутину для тимлида. ChatOps имеет малый порог вхождения и дает быстро попробовать автоматизировать какой-то процесс, причём делать это может практически хоть кто
- Кто мы и почему с нашим процессом нам потребовался ChatOps
- Конкретные примеры использования в дневной рутине, сбору ошибок, быстрых каналов обратной связи, автоматизация действий тимлида
- Плюсы и минусы, кому ChatOps подойдёт а кому нет

Программный комитет ещё не принял решения по этому докладу

DevOps-трансформация

- Что такое Kubernetes и почему он так популярен.
- Почему Kubernetes это не только платформа для запуска контейнеров, а нечто большее.
- Как работает Service Discovery в Kubernetes, что такое headless-сервисы.
- Разберём сущности Kubernetes и почему их так много. Чем отличаются StatefulSet от Deployment и Daemonset.
- Компоненты из которых состоит Kubernetes: etcd, kube-apiserver, kube-controller-manager, какова роль каждого из них.
- Что такое неймспейсы ядра linux и контейнеры как таковые.
- Как работает сеть в Kubernetes, зачем нужны kube-proxy и CNI-плагин.
- Посмотрим как создавать свои приложения и запускать их в Kubernetes.
- Почему нужно применять подход по процессу на контейнер, и нежелательно использовать latest-тэги
- Как собираются логи и метрики с ваших сервисов.
- Что такое CustomResourceDefinition и как их можно использовать.

Программный комитет ещё не принял решения по этому докладу

Архитектура в DevOps, DevOps для CTO

Опять боль и страдания!!! Внедряя NoOps в большой компании я услышал много разного от простых эмоций:
- Да вы теперь просто операторы приватного облака…!
- У нас кончилось админстово в компании!!!
- А что я теперь и в мидлваре должен разбираться...

До вполне интересных вопросов:
- Оптимизацией СУБД кто теперь занимается?
- Кто отвечает за бэкап?
- А кто теперь отвечает за инциденты?

Есть безусловно полезные вещи которые очень трудно оспорить, например автоматизация запросов на обслуживание(любые действия имеющие обкатанный скрипт исполнения) где вы интегрируете свою инфраструктуру с роботами и нет больше лагов и ошибок при исполнение. Все "энтерпрайз вахтёры" (политики и регламенты безопасности) тоже эффективно автоматизируются и самое прикольное тут, что никто вам даже спасибо не скажет, все привыкнут к хорошему через неделю даже не вспомнят что может быть по другому. Самое тонкое место это передача компетенций, как быть Томом Сойером, а не "вертухаем" заставляющим делать «чужую» работу. Все это мы прошли, причём в серьезном масштабе 500 дев на 10 опс.
По классике жанра, мы собрали все возможные "грабли", где то пошлось пойти на компромиссы ибо любая концепция требует обработки напильником под себя, что бы максимально решать свои задачи. У нас есть все и NoOps и DevOps и просто Ops. Хочу рассказать про свой опыт погони за хайпом!

Программный комитет ещё не принял решения по этому докладу

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

Я расскажу о том, что началось в начале 2020 года и ещё будет продолжаться в момент проведения конференции. Как обслужить десятки терабайт данных, создав новое безотказное хранилище параллельно с существующим. И о том, как полностью переосмыслить идею трекинга данных для сбора бигдаты, сменив Percona на Clickhouse, и обвешав всё это вспомогательными инструментами для быстрого и качественного сбора данных статистики.

Программный комитет ещё не принял решения по этому докладу

Мы являемся крупнешим Чешским хостингом и вот уже два года мы используем Kubernetes для запуска stateful-приложений на собственном оборудовании.

Kubernetes является связующим звеном между нашим разработчиками и оборудованием. К примеру чтобы запустить новый сервис, будь то новый web-хостинг, почтовый сервер, база данных или целая система виртуализации, мы просто описываем соответсвующие ресурсы в Kubernetes.

В своём докладе я хочу рассказать вам о проблемах с которыми нам пришлось столкнуться, прежде чем мы научились правильно готовить stateful-приложения для запуска в Kubernetes, а так же о том какой сторадж лучше использовать, как быть с legacy и к чему нужно стремиться чтобы нормально переживать отказ ноды и не бояться потерять важные данные.

В програме:

Обзор стораджей:
- Чем отличется блочное хранилище от файлового или объектного.
- Когда следует использовать каждый из этих типов хранения.
- Поговорим о плюсах и минусах каждого из них.
- Что такое Linstor и чем он лучше Ceph.
- NFS-server-provisioner и неужели создавать RWX-тома можно так просто.

Сеть:
- Что делать если в Kubernetes нельзя назначать статический айпишник подам но нам так хочется

Архитектура Stateful-приложений в Kubernetes:
- Поды это не виртуалки, что общего у stateful-подов с виртуальными машинами, почему это сравнение крайне некорректно.
- Как обеспечить надёжность запуска stateful-приложения в Kubernetes.
- Как работает simple leader election и как просто добавить его к вашему приложению
- Как работает fencing и проблемы которые он решает.

Программный комитет ещё не принял решения по этому докладу