Обновляем k8s без слез
Часть 2

Продолжаем говорить про обновление k8s, и сегодня разберём другую проблему, с которой можно столкнуться.

К сожалению в базе правил нет многих сторонних инструментов. Например, правил для istio, где большая часть CRD перешла в стабильную стадию.

Конкретно для istio есть это.

И есть в документации одна замечательная строка

What analyzers are supported today?

We’re still working to documenting the analyzers. In the meantime, you can see all the analyzers in the Istio source.

Прекрасно, разбирайтесь сами, что поддерживается, копаясь в коде 😂

Например, для определения deprecated APIs и полей можно посмотреть это или запустить istioctl analyze на вашем кластере.

По итогу со всей этой гонкой апдейтов получаем большой operational toil: добавляем сотни разных CRD в кластер и затем нужно отслеживать, а не сломаются ли они при релизе новой версии стороннего контроллера/оператора. А сбоку появляются и дополнительные приколы, связанные не просто с deprecation, а с полной миграцией настроек одного API на другой API.

Да, речь про gateway API.

Мы вам создали ресурсы ingress, но поняли, что сделали плохо, поэтому теперь точно сделаем хорошо, пострадайте всего лишь еще один раз, переписывая манифесты под новый формат (и попутно создавая новые баги, с которыми еще не встречались). При этом gateway API, на мой взгляд, очень сильно напоминает ресурсы istio.

На самом деле, конечно же, это не так, ingress обещают поддерживать условно бесконечно.

Про gateway API и почему его создали расскажу в другой раз.

И напоследок: альтернативный инструмент. Он уже, кажется, поддерживает побольше deprecated APIs из коробки. Посмотреть можно здесь.

Ностальгии пост

Развели тут кубернетисы и прочие прометеусы.

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

Эх, где мои патч-корды!

Если вам далеко за 30 и вы давно в IT, то велика вероятность, что вы когда-то (может и сейчас) работали сисадмином (или программистом-админом-эникеем-заправлятелем принтеров).

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

Ключевые слова для олдов: башорг, итхэппенс, лор, ирка, домовые сети.

Я сам начинал админствовать помаленьку с линуксовыми серверами, поднимал IP телефонию поверх openvpn между филиалами одной конторы (о, эти часы копания с tcpdump с поисками, где теряется голосовой трафик), переносил почтовый сервер с полумертвого железа с сохранением всех почтовых ящиков, автоматизировал раскатывание новых машин через PXE boot, внедрял zabbix там, где о мониторинге и не думали, и многое другое.

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

Скажем за все спасибо ETHERNET!

Итак, сегодня, 22 мая, день рождения ethernet. Считается, что технология была изобретена аж в 1973 году.

Все началось с коаксиальных кабелей. У них была куча проблем: малая гибкость, скорость, стоимость.

Все изменилось, когда витая пара пошла в массы. О, сколько кабелей было обжато кримпером.

А схема обжима заучена наизусть. Вот шпаргалка по порядку выбора проводов:

System design interview наоборот

Есть у меня очень большая задача in progress (параллельно с другими не менее важными тасками), срок выполнения которой непонятен ни одному участнику процесса.

Задача, прямо скажем, не для слабонервных, но она довольно важная с точки зрения повышения observability, reliability, maintainability и прочих ***bility. Десятки огромных сервисов, каждый из которых — отдельная вселенная со своими решениями.

Команд, которые владеют всеми этими сервисами, наберется 10+. Сервисов и того больше. Каждая команда знает про свой огород и иногда знает, какая картошка посажена у соседей 🥔

Как только data flow процессов в системе выходит за пределы их зоны ответственности, понимание общей картины сразу тускнеет. Это абсолютно нормальная ситуация в бигтехе. У всех и так навалом задач, и разбираться, что делают соседи, мало кто хочет. Кроме меня 😂

Задача простая, как скейлинг деплоймента: построить граф взаимодействий, архитектурную схему, чтобы хоть примерно понимать, что вообще происходит. System design interview наоборот. И не для гипотетической системы, а для вполне реальной, которую пилят не один год 10+ команд.

Зависимостей у каждого сервиса — вагон и маленькая тележка, асинхронных взаимодействий — и тут и там и еще сверху накинули. Трейсинг? Слышали о таком, но пока на уровне попыток внедрения.

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

Вот только ни один из этих сервисов я не писал 🤷‍♂️

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

Зачем все это? Да чтобы видеть верхнеуровневую картину, как эти сервисы взаимодействуют. Чтобы, когда что-то начинает деградировать, мы не гадали на метриках, а какой data flow ломается. А их много. Очень много. Да и метрики не всегда показывают проблему. А если метрика ошибок в сервисе X выросла на 0.5%, как это скажется на сервисе Y, который напрямую с X не взаимодействует ни по API, ни асинхронно? И прочие подобные вопросы.

С диаграммой довольно легко приходить в команды и спрашивать, а где эта стрелочка в метриках, а покрыта ли она трейсингом (в будущем), а есть ли на нее SLO, а есть ли error budget, а есть ли run book, что делать, если эта стрелочка покажет SLO breach?

Короче, задача — как собеседование в Google, только ни я, ни интервьюер понятия не имеем, что вообще происходит.

Пожелайте мне удачи в этом непростом деле и поделитесь в комментариях, какие задачи вам предстоит затащить в ближайших спринтах — хочу знать, что не один страдаю 😅