Привет, друзья. Приглашаем на @Kubernetes Conference 29 ноября в Mail.ru Group всех, кто вместе с нами строит экосистему Kubernetes в России — использует, внедряет K8s в Production, создает свои инструменты для работы с ним, ищет пути решения проблем, помогает другим перейти на Kubernetes и работает над распространением знания о нюансах использования технологии.
В программе вас ждут:
- Безопасные сети Kubernetes c eBPF и Cilium. Как глубоко работать с сетью на уровне ядра;
- Интерактив «Helm глазами разработчиков. RollingUpdate Puzzle»;
- Внедрение OpenShift в «Росгосстрахе»: от DevOps до Production-эксплуатации;
- Управление кластером K8s через Cluster API. Как Tinkoff.ru писали свой Infrastructure Provider BareMetal;
- Проект «Платформа». Как мы переводим на Kubernetes сервисы Mail.ru Group;
- Как мы катили K8s в Production eldorado.ru. Наш год американских горок;
- Также вас ждет воркшоп для тех, кто еще только на пути к Kubernetes — «Как запустить ваше приложение в Kubernetes. Деплой, мониторинг, логирование».
Конференция пройдет 29 ноября (пятница) в 14:00 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79). Регистрация обязательна и закрывается 25 ноября в 11:59 утра (или раньше, если закончатся места).
«Безопасные сети Kubernetes c eBPF и Cilium. Как глубоко работать с сетью на уровне ядра»
Александр Костриков, DevOps-инженер, Brain4Net
Как SDN-компания, мы стремимся к программируемости не только сетевого оборудования, но и всего сетевого стека. Kubernetes тоже можно запрограммировать гибче, чем просто правила iptables. Это позволяет сделать такой инструмент, как Cilium. Рассмотрим, как Cilium использует eBPF для работы с кодом ядра и userspace, а также для для сетевого взаимодействия, безопасности, мониторинга и балансировки нагрузки.
- eBPF и BCC — как работает eBPF, основа в ядре для Cilium и других инструментов
- Трассировка внутри ядра
- iptables/ipset vs eBPF
- Безопасность
- Эволюция дизайна приложений и введение в Cilium
- Что было раньше и зачем Cilium
- Введение в Cilium: Component Overview, Address Management, Multi Host Networking, Security, Datapath, Failure Behavior, Architecture
- Cilium Design Decisions. Какие избыточные части пропадают из-за того, что мы работаем в ядре?
- Kernel TLS и бонусы, с ним связанные
- Рассматриваем исходный код Cilium
- Аналоги, использующие eBPF
- Как тестируется: как самим поднять окружение и проверить/законтрибьютить
Интерактив «Helm глазами разработчиков. RollingUpdate Puzzle»
Дмитрий Сугробов, разработчик, «Леруа Мерлен»
Kubernetes — стандарт де-факто. Helm — ещё один выбор по умолчанию, которым начинают пользоваться, когда устают копировать однотипные ямлики. Но вот простой вопрос: что нужно сделать, чтобы обновить версию приложения, запущенного с помощью Helm? Вызвать helm upgrade?
На самом деле, всё не так очевидно — стоит немного выйти за рамки туториала, чтобы тут же столкнуться с большим количеством нюансов. Доклад поможет не наступать на грабли при работе с Helm и улучшит понимание, как он работает.
В интерактивном режиме галопом пробежимся по тому, что вообще такое Helm, посмотрим на его архитектуру и устройство хранилища — и наконец ответим на вопрос, что нужно сделать, чтобы желаемый RollingUpdate всё-таки сработал.
«Внедрение OpenShift в «Росгосстрахе»: от DevOps до Production-эксплуатации»
Александр Крылов, начальник службы DevOps, «Росгосстрах»
Находясь перед стратегической развилкой — Kubernetes или OpenShift, мы выбрали последний, так как нам был важен Time to Market. В итоге нам удалось построить CI/CD с использованием OpenShift, Bamboo и Artifactory и обеспечить работу сервисов на базе OpenShift в Production, а также интегрировать их в существующую экосистему Enterprise-инструментов, используемую эксплуатацией «Росгосстраха». В докладе мы расскажем про тернистый путь интеграции разных коробочных решений, который мы прошли в течение последних лет, и про возможные сложности на пути у компаний, которые захотят его повторить.
Мы расскажем:
- Как выглядит наш процесс деплоймента с OpenShift и где там (были) подводные камни:
- Настройка CI/CD на примере внедрения новых проектов микросервисной архитектуры;
- Наш стек Git + Bamboo + Ansible + Artifactory + OpenShift.
- Развёртывание кластерной архитектуры OpenShift — поэтапный переход, боль, грабли.
- Мониторинг внутренних компонентов OpenShift — от стандартного и прикрученного PerfMon до мониторинга контейнеров различными средствами.
«Управление кластером K8s через Cluster API. Как Tinkoff.ru писали свой Infrastructure Provider BareMetal»
Станислав Халуп, руководитель группы инфраструктуры привлечения, «Тинькофф»
Био: Станислав Халуп уже два года руководит группой инфраструктуры привлечения в Tinkoff.ru и часто рассказывает про Managed K8s и жизнь в публичных облаках, но в этот раз поделится тем, какие технологические вызовы встали перед ним при построении Hyperscale Private-платформы с нуля.
Не так давно мы в «Тинькофф» озаботились вопросом консолидации нашей инфраструктуры, которая состоит почти из всего на свете (VMware, OpenStack, Bare-Metal Kubernetes…). Мы решили, что настал момент создать объединенную облачную платформу — для микросервисов, внутренних *aaS решений, но без Legacy.
В качестве Cloud OS мы выбрали Kubernetes (да, на BareMetal) — и почти сразу встал ряд вопросов:
- Как деплоить и скейлить Undercloud-кластер?
- Как автоматизировать Day 2 Operations?
- Как сделать настоящее AutoDiscovery и Zero-Touch Provisioning для железа? (У нас весьма внушительные объемы закупок железа).
- Как все это сделать без L2 и DHCP? (Почему так — расскажу в докладе).
Посмотрев доклады kvaps и хорошо почесав головы, мы решили, что управлять кластером K8s лучше всего с помощью кластера K8s. ;)
В своем докладе я расскажу:
- Что такое ClusterProvider BareMetal (Metal3) и как он работает;
- Почему он не подходит для Zero Touch Provisioning и как мы писали свое BareMetal Provisioning API;
- Что делать, чтобы грузиться по сети без DHCP, но с фантазией;
- Как вдохновиться RedHat OpenShift 4 и всё равно сделать всё по-своему.
Доклад будет рассчитан на тех, кто уже что-то знает про Cluster API, но еще не погружался в тему BareMetal Providers.
«Проект «Платформа». Как мы переводим на Kubernetes сервисы Mail.ru Group»
Михаил Петров, технический руководитель проекта «Платформа», Mail.ru Group
Био: Михаил возглавляет центр компетенций по Kubernetes в Mail.ru Group и отвечает за процесс перехода на Kubernetes всех сервисов группы.
В силу специфики Mail.ru Group — «экосистемы экосистем» — каждый проект внутри группы делает своё и часто по-своему. Но всем важен Time to Market и любые способы его сократить. Так мы в эксплуатации Mail.ru Group пришли к некоторым общим гайдлайнам и процессам по внедрению Kubernetes и помогаем коллегам в переходе на него.
Сейчас Kubernetes давно и успешно пользуются не только такие большие проекты, как Почта Mail.ru и Медийная реклама, но и стартапы в рамках компании. Например, один из новых проектов взлетел в Kubernetes за 1-2 дня вместо 3 недель.
В докладе я хочу рассказать не только про наш кластер и наш пайплайн, но и навыки, которыми должен обладать человек, который заводит Kubernetes, а также про трансформацию процессов в командах и поиск компромиссов.
- Кто нужен, чтобы кластер взлетел;
- Культура blameless и взаимодействие с разработкой;
- Какой у нас кластер: как разворачиваем, чем разворачиваем, что стоит в кластере от инфраструктуры и для инфраструктуры;
- Как заводим трафик и как живем в гетерогенной среде;
- Как организована безопасность;
- Наш CI/CD-пайплайн.
«Как мы катили K8s в Production eldorado.ru. Наш год американских горок»
Константин Рекунов, руководитель группы эксплуатации ИМ Eldorado.ru; Денис Гуров, ведущий DevOps-инженер, AGIMA
Мы достаточно консервативны в использовании всего нового, но жить без Kubernetes больше не могли. Сейчас это уже мейнстрим, что не отменяет большого количества полезных плюшек от использования K8s.
Мы используем Kubernetes на собственном облаке/железе в относительно небольшом кластере и с небольшим количеством сервисов, но уже успели набить много полезных шишек.
Расскажем о нашем опыте внедрения K8s в Production:
- Как это было местами больно, местами приятно, особенно с учетом отсутствия специалистов во внутренней команде;
- В числе прочих затронем интересную для многих тему переезда кластера между ДЦ без даунтайма и то, как мы выстроили процесс оперативной диагностики проблем;
- С чем сталкивались, как решали, какие плюсы получили и какие видим перспективы развития;
- Особое внимание уделим практическим кейсам решения проблем с сетью, так как эти проблемы были очень больными и нетривиальными для нас.
Обязательно регистрируйтесь по ссылке, мы просматриваем все заявки в течение пары дней.
О новых событиях серии @Kubernetes и других мероприятиях Mail.ru Cloud Solutions мы сразу сообщаем в нашем канале в Telegram: t.me/k8s_mail
Хотите выступить на следующем @Kubernetes? Заявку можно оставить здесь: mcs.mail.ru/speak
Автор: schrc
