29 ноября в Mail.ru Group пройдет @Kubernetes Conference

Привет, друзья. Приглашаем на @Kubernetes Conference ^[1] 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). Регистрация ^[1] обязательна и закрывается 25 ноября в 11:59 утра (или раньше, если закончатся места).

«Безопасные сети Kubernetes c eBPF и Cilium. Как глубоко работать с сетью на уровне ядра»

Александр Костриков, DevOps-инженер, Brain4Net

Как SDN-компания, мы стремимся к программируемости не только сетевого оборудования, но и всего сетевого стека. Kubernetes тоже можно запрограммировать гибче, чем просто правила iptables. Это позволяет сделать такой инструмент, как Cilium. Рассмотрим, как Cilium использует eBPF для работы с кодом ядра и userspace, а также для для сетевого взаимодействия, безопасности, мониторинга и балансировки нагрузки.

1. eBPF и BCC — как работает eBPF, основа в ядре для Cilium и других инструментов
   • Трассировка внутри ядра
   • iptables/ipset vs eBPF
   • Безопасность
2. Эволюция дизайна приложений и введение в Cilium
   • Что было раньше и зачем Cilium
   • Введение в Cilium: Component Overview, Address Management, Multi Host Networking, Security, Datapath, Failure Behavior, Architecture
   • Cilium Design Decisions. Какие избыточные части пропадают из-за того, что мы работаем в ядре?
   • Kernel TLS и бонусы, с ним связанные
   • Рассматриваем исходный код Cilium
   • Аналоги, использующие eBPF
3. Как тестируется: как самим поднять окружение и проверить/законтрибьютить

Интерактив «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-инструментов, используемую эксплуатацией «Росгосстраха». В докладе мы расскажем про тернистый путь интеграции разных коробочных решений, который мы прошли в течение последних лет, и про возможные сложности на пути у компаний, которые захотят его повторить.

Мы расскажем:

1. Как выглядит наш процесс деплоймента с OpenShift и где там (были) подводные камни:
   • Настройка CI/CD на примере внедрения новых проектов микросервисной архитектуры;
   • Наш стек Git + Bamboo + Ansible + Artifactory + OpenShift.
2. Развёртывание кластерной архитектуры OpenShift — поэтапный переход, боль, грабли.
3. Мониторинг внутренних компонентов 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:

• Как это было местами больно, местами приятно, особенно с учетом отсутствия специалистов во внутренней команде;
• В числе прочих затронем интересную для многих тему переезда кластера между ДЦ без даунтайма и то, как мы выстроили процесс оперативной диагностики проблем;
• С чем сталкивались, как решали, какие плюсы получили и какие видим перспективы развития;
• Особое внимание уделим практическим кейсам решения проблем с сетью, так как эти проблемы были очень больными и нетривиальными для нас.

Обязательно регистрируйтесь по ссылке ^[1], мы просматриваем все заявки в течение пары дней.

О новых событиях серии @Kubernetes и других мероприятиях Mail.ru Cloud Solutions ^[2] мы сразу сообщаем в нашем канале в Telegram: t.me/k8s_mail ^[3]

Хотите выступить на следующем @Kubernetes? Заявку можно оставить здесь: mcs.mail.ru/speak ^[4]

Автор: schrc

Источник ^[5]