Kubernetes *

Вчера с компанией Docker Inc, стоящей за популярнейшим одноимённым решением для контейнеров, произошла череда преобразований. Можно смело сказать, что их уже определённое время ждали. Ведь с массовым распространением Docker, развитием других технологий для контейнеризации, а также стремительным ростом популярности Kubernetes вопросов к продуктам и бизнесу Docker Inc в целом становилось всё больше.



Каким же стал ответ? Как гласил заголовок на одном из информационных ресурсов, «Единорог [компания, оцениваемая в 1+ млрд USD] пал: Docker отказывается от enterprise». И вот что послужило поводом к такому заявлению…

Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.


Схема взята из другого обзора стратегий выката, сделанного в Container Solutions

Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.

Более короткие и частые развертывания имеют следующие преимущества:

• Сокращается время выхода на рынок.
• Новые функции быстрее попадают к пользователям.
• Отклики пользователей быстрее доходят до команды разработчиков. Это означает, что команда может дополнять функции и исправлять проблемы более оперативно.
• Повышается моральный дух разработчиков: с большим количеством функций в разработке интереснее работать.

Всем привет. Меня зовут Александр, я Java-разработчик в группе компаний Tinkoff.

В данной статье хочу поделиться опытом решения проблем, связанных с синхронизацией состояния кэшей в распределенных системах. Мы столкнулись с ними, разбивая наше монолитное приложение на микросервисы. Очевидно, что речь здесь пойдет о кэшировании данных на уровне JVM, поскольку с внешними кэшами проблемы синхронизации решаются вне контекста приложения.

В статье я расскажу про наш опыт перехода на сервис-ориентированную архитектуру, сопровождающуюся переездом в Kubernetes, и про решение сопутствующих проблем. Будет рассмотрен подход к организации системы распределенного кэширования In-Memory Data Grid (IMDG), его преимущества и недостатки, из-за которых мы решили написать собственное решение.

В статье рассматривается проект, бэкэнд которого написан на Java. Поэтому речь также пойдет про стандарты в области временного In-memory-кэширования. Обсудим спецификацию JSR-107, несостоявшуюся спецификацию JSR-347, а также особенности кэширования в Spring. Добро пожаловать под кат!

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



В Red Hat OpenShift Service Mesh мы выходим за рамки традиционной маршрутизации и предлагаем компоненты для трассировки и визуализации таких запросов, чтобы сделать взаимодействие сервисов более простым и надежным. Введение специального логического уровня управления, так называемой сервисной сетки service mesh, помогает упростить подключение, контроль и оперативное управление на уровне каждого отдельного приложения, развернутого на Red Hat OpenShift, ведущей Kubernetes-платформе корпоративного класса.

Полтора года назад, 5 марта 2018, компания Google выпустила первую альфа-версию своего Open Source-проекта для CI/CD под названием Skaffold, целью которого стало создание «простой и воспроизводимой разработки под Kubernetes», чтобы разработчики могли сфокусироваться именно на разработке, а не на администрировании. Чем может быть интересен Skaffold? Как оказалось, у него есть несколько козырей в рукаве, благодаря которым он может стать сильным инструментом для разработчика, а может — и инженера по эксплуатации. Познакомимся с проектом и его возможностями.

Кто сказал, что красивая девушка не сможет в IT? Да ещё и Kubernetes-штурвалом будет крутить так, что мужики позавидуют.

У нас в Southbridge всё возможно. Я уговорил сурового, но красивого админа Елизавету Михно рассказать, почему она променяла три чихуахуа к 40 годам, розовый «поршик», «лиапёрдовый» плащ, лабутены и борщ на k8s, Prometheus, Zabbix и карьеру SRE-инженера.

Привет!

7 декабря мы проводим третью конференцию DevOpsDays Moscow. Это не yet another конференция про DevOps. Это комьюнити-конференция, которую сообщество готовит для сообщества.

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

Мы специально делаем программу всего в один поток, чтобы было больше времени на камерные форматы и активности, подталкивающие к знакомствам и разговорам.

Билет стоит 7000 ₽, но есть лайфхак: если покупать два билета сразу, они станут по 6000 ₽.

Под катом все подробности.

Всем привет! Несколько месяцев назад мы запустили в продакшн наш новый open-source проект — Grafana-плагин для мониторинга kubernetes, который назвали DevOpsProdigy KubeGraf. Исходный код плагина доступен в публичном репозитории на GitHub. А в этой статье мы хотим поделиться с вами историей о том, как мы создавали плагин, какие инструменты использовали и с какими подводными камнями столкнулись в процессе разработки. Погнали!

Компания Rancher Labs, специализирующаяся на решениях и услугах для Kubernetes, объявила о передаче своего Open Source-хранилища для постоянных данных Longhorn в некоммерческую организацию CNCF, ответственную за развитие Kubernetes, Prometheus и ряда других проектов.

О проекте и его статусе

Longhorn был представлен в апреле 2017 года и называется распределённым блочным хранилищем для кластеров Kubernetes. Среди его главных особенностей — отказоустойчивость (нет единой точки отказа) и ориентированность на применение в enterprise, инкрементальные снапшоты, бэкапы на дополнительные хранилища (NFS или совместимые с S3), автоматизированные обновления без простоя в работе, простой в использовании GUI.

«Эйчары» заняты квадриллионом дел — поиск и онбординг новых сотрудников, тесты психологического состояния персонала, регламенты. Им трудно разобраться, какие профильные курсы нужны разработчику, а какие нет. И не всегда доходят руки оценить, какие сотрудники уже доросли до следующего шага.

Руководителю важно, чтобы в отделе всё крутилось, вертелось, стабильно выдавало результат. А ещё KPI постоянно висят дамокловым мечом. Потому поиск новых технологий и курсов уходит на 5-10 место.

Почему мы часто ждём, что путёвку на обучение нам предложат HR или руководитель? Стив Джобс говорил: «Ваше время ограничено. Поэтому не тратьте его на то, чтобы прожить чью-то чужую жизнь. Не попадайте в ловушку догмы, которая учит жить в соответствии с мыслями других людей».

Кубернетес меняет жизнь компании. Это факт.

А давайте посмотрим с другой стороны. K8s меняет в первую очередь жизнь самого администратора. Даёт возможность заработать больше денег, избавляет от многих рутинных задач, делает свободнее и значимее как профессионала, Kubernetes делает работу интересней.

Нам стало интересно, как изменилась профессиональная и личная жизнь ребят, которые прошли базовые Слёрмы. Чтобы обосновать потраченное время, мы предложили скидку на Слёрм Мега — и попросили участников дать ответы на несколько коротких вопросов: что им понравилось в Слёрме, что не понравилось, что бы они хотели улучшить.

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

Всем привет!

Так сложилось, что наша небольшая команда разработки, не сказать, чтобы недавно, и уж точно не внезапно, доросла до переноса некоторых (а в перспективе и всех) продуктов в Kubernetes.

Причин тому было множество, но наша история не про холивар.

Из инфраструктурной основы выбор у нас был небольшой. vCloud Director и vCloud Director. Выбрали версию поновее и решили начать.

В очередной раз полистав «The Hard Way», я очень быстро пришёл к выводу, что инструмент для автоматизации хотя бы базовых процессов, таких как деплой и сайзинг, нужен ещё вчера. Глубокое погружение в Google явило на свет такой продукт как VMware Container Service Extension (CSE) — опенсорсный продукт, позволяющий автоматизировать создание и сайзинг k8s кластеров для тех, кто в vCloud-е.

Введение в Skydive

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

Скриншот обьектов (поды, интерфейсы) в kubernetes

Павел Селиванов, архитектор решений Southbridge и преподаватель Слёрма, выступил с докладом на DevOpsConf 2019. Этот доклад — часть одной из тем углубленного курса по Kubernetes «Слёрм Мега».

Слёрм Базовый: введение в Kubernetes проходит в Москве 18-20 ноября.
Слёрм Мега: заглядываем под капот Kubernetes — Москва, 22-24 ноября.
Слёрм Онлайн: оба курса по Kubernetes доступен всегда.

Под катом — расшифровка доклада.

Прим. перев.: автор статьи — Erkan Erol, инженер из SAP — делится своим изучением механизмов функционирования команды kubectl exec, столь привычной для всех, кто работает с Kubernetes. Весь алгоритм он сопровождает листингами исходного кода Kubernetes (и связанных проектов), которые позволяют разобраться в теме настолько глубоко, насколько это требуется.



В одну из пятниц ко мне подошел коллега и поинтересовался, как выполнить команду в pod'е с помощью client-go. Я не смог ему ответить и внезапно осознал, что ничего не знаю о механизме работы kubectl exec. Да, у меня были определенные представления о его устройстве, однако я не был уверен на 100% в их правильности и потому решил заняться этим вопросом. Проштудировав блоги, документацию и исходный код, узнал много нового, и в этой статье хочу поделиться своими открытиями и пониманием. Если что-то не так, пожалуйста, свяжитесь со мной в Twitter.

Классический вариант вебинара — лектор рассказывает теорию и (в лучшем случае) дает немного практики. Мы решили попробовать альтернативный способ.

Павел Селиванов, архитектор решений в Southbridge и преподаватель Слёрма, будет во время вебинара создавать и настраивать кластер Kubernetes в Облаке КРОК, попутно комментируя свои действия.

После вебинара те, кто регистрировался с корпоративной почты, получат ссылку на использованные в вебинаре скрипты и плейбуки, и бесплатный триал Облака КРОК.

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

Регистрация

Примечание от нашей редакции переводов: в представляемой статье описывается закрытый продукт конкретной компании и, к сожалению, пока нет никаких данных о том, что его когда-либо планируют открывать — в столлмановском понимании этого слова. Тем не менее, нам показалось очень важным и полезным рассмотреть, как вообще люди подходят к вопросам дебага Istio и как оптимизируют свою работу на этом поле. Возможно, кто-то сможет почерпнуть для себя пару интересных идей.

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

В этом посте концепция распределенной трассировки будет рассмотрена через призму микросервисной архитектуры: как это все интегрируется и автоматизируется через Istio, а затем весь процесс упрощается и обрабатывается через Backyards — наш сервисный продукт для Istio.

Добрый день, хочу поделиться с вами своим опытом по настройке и использованию сервиса AWS EKS (Elastic Kubernetes Service) для Windows контейнеров, а точнее о невозможности его использования, и найденном баге в системном контейнере AWS, тем кому интересен этот сервис для Windows контейнеров, просьба под кат.

При построении процесса CI/CD с использованием Kubernetes порой возникает проблема несовместимости требований новой инфраструктуры и переносимого в неё приложения. В частности, на этапе сборки приложения важно получить один образ, который будет использоваться во всех окружениях и кластерах проекта. Такой принцип лежит в основе правильного по мнению Google управления контейнерами (не раз об этом говорил и наш техдир).

Однако никого не удивишь ситуациями, когда в коде сайта используется готовый фреймворк, использование которого накладывает ограничения на его дальнейшую эксплуатацию. И если в «обычной среде» с этим легко справиться, в Kubernetes подобное поведение может стать проблемой, особенно когда вы сталкиваетесь с этим впервые. Хотя изобретательный ум и способен предложить инфраструктурные решения, кажущиеся очевидными и даже неплохими на первый взгляд… важно помнить, что большинство ситуаций могут и должны решаться архитектурно.

Разберем популярные workaround-решения для хранения файлов, которые могут привести к неприятным последствиям при эксплуатации кластера, а также укажем на более правильный путь.

Прим. перев.: Ведущий инженер из компании Zalando — Henning Jacobs — не раз замечал у пользователей Kubernetes проблемы в понимании предназначения liveness (и readiness) probes и их корректного применения. Посему он собрал свои мысли в эту ёмкую заметку, которая со временем станет частью документации K8s.



Проверки состояния, известные в Kubernetes как liveness probes (т.е., дословно, «тесты на жизнеспособность» — прим. перев.), могут быть весьма опасными. Рекомендую по возможности избегать их: исключениями являются только случаи, когда они действительно необходимы и вы полностью осознаете специфику и последствия их использования. В этой публикации речь пойдет о liveness- и readiness-проверках, а также будет рассказано, в каких случаях стоит и не стоит их применять.