Начинаем новую рубрику "ТехноВторник".
Буду постить свои обзоры и мысли на гаджеты и девайсы. Начну сразу с двух постов - первый обзор на все (да, их несколько) мои "инвестиции" в девайсы на kickstarter, второй пост будет о находке которую мне показал друг - TP-Link AV1000 Powerline Ethernet Adapter(TL-PA7017P KIT) - простое решение насущной проблемы.

Обзор на мои kickstarter вбросы. 🚀

🤏 Deeper Connect Pico: https://www.kickstarter.com/projects/deepernetworkpico/deeper-connect-pico/description
Моя первая инвестиция в Kickstarter — Deeper Connect Pico, компактный гаджет, который обещал быть решением для всех моих кибербезопасных нужд. VPN без подписки? Да! Блокировка рекламы и фаервол уровня “enterprise”? Конечно! И даже какой-то майнинг в придачу. Всё это за $250.
Как только я получил девайс, радость быстро сменилось разочарованием. Оказалось, что он не поддерживает Ethernet, а я как-то пропустил эту “мелочь” в описании (кто читает описание да?). Кароче девайс ушел в комод сразу по приходу. С тех пор не втыкал. P.S. Кстати, его проприетарная кибервалюта крайне быстро рухнула. Об этом интереснее даже почитать в инете, чем о самом девайсе.

Дальше два девайса которые еще не пришли (и может не придут - привет кикстартеру).
💨 JetKVM — какой-то крутой KVM over IP: https://www.kickstarter.com/projects/jetkvm/jetkvm
Девайс обещает стать мечтой любого гика. Это open-source решение для удалённого управления компьютерами. Ультранизкая задержка, видеопоток в 1080p/60fps, и даже возможность настраивать BIOS удалённо. И всё это за сравнительно небольшую сумму.
Меня купила идея протестировать этот девайс в экстремальных условиях. Придёт — уеду с ним куда-нибудь в Мексику или на Кубу, чтобы по-настоящему проверить, сможет ли он стать полноценным помощником для удалённого управления в сложных сетевых условиях. Посмотрел пару ютуб обзор - все довольны.

🔮 Последний, это CyberAxon D3: 13-in-1 Multifunctional Stream Control Dock: https://www.kickstarter.com/projects/raycue/cyberaxon-d3-13-in-1-multifunctional-stream-control-dock. Это вообще какая-то футуристическая пушка за че-то около 300 баксов. Так же это продукт компульсивного шопинга, более известного как ониомания.
CyberAxon D3 выглядит как мини-командный центр для стримеров и мультизадачников. Устройство объединяет в себе 13 функций, включая сенсорный экран и 12 настраиваемых клавиш. Похоже больше show-off фигня для друзей нердов которые приходят в гости. Только дело все в том, что нерды не ходят в гости. Они сидят дока в своих комплюктерах.

🔌 Интернет через розетку с TP-Link AV1000

Мой юзкейс был очень простым - до компа достреливает вайфай и по Ethernet можно подключиться без проблем. Скорость неплохая. Только проблемы начинаются если ... неожидано зайти в гараж чтобы посмотреть там что-то интересное на проекторе (через HDMI от компа). Так вот гаражи делают наверное армированные, так что сигнал туда не заходит никаким образом. 🪖
Товарищ подсказал решение: TP-Link AV1000 Powerline Ethernet Adapter (TL-PA7017P KIT), которое использует домашнюю электросеть для передачи интернета.

Этот адаптер поддерживает скорость до 1000 Мбит/с благодаря технологии HomePlug AV2, что делает его отличным решением для 4K-стриминга, онлайн-игр и любых задач с высоким трафиком. Гигабитный Ethernet-порт обеспечивает надёжное подключение для устройств, требующих стабильного интернета, таких как проекторы, консоли или смарт-ТВ.

Особенность устройства — встроенная проходная розетка. Вы не теряете возможность подключать другие устройства, а встроенный шумовой фильтр минимизирует электромагнитные помехи, что сохраняет производительность сети на высоком уровне. И, что немаловажно, адаптер экономит до 85% энергии в режиме ожидания благодаря автоматическому энергосбережению. ♻️

Установка настолько проста, что с ней справится даже ребёнок: подключаете один адаптер к роутеру, второй — в нужной комнате, соединяете Ethernet-кабелем, и всё готово. Я даже в такое поверить не мог, а через 2 дня я уже смотрел финал BLAST SLAM 2024 в HD и мог даже мотать видео без единой задержки.

CNCF Kubestronaut bundle? 🚀

На этой неделе многие из нас получили письмо от Cloud Native Computing Foundation (CNCF), где предлагались скидки на курсы на Black Friday. Мое отношение к курсам менялось несколько раз от категоричного "это не нужно" до нескольких часов в месяц долбежки для получения нового беджика.
Наткнулся на интересный bundle, с как мне кажется прикольным названием Kubestronaut (вот так вот работает маркетинг - по названию могут зацепить курс за 1,5к): https://training.linuxfoundation.org/certification/kubestronaut-bundle/.

Что такое Kubestronaut Bundle? 🌌
Этот бандл создан для тех, кто хочет глубже нырнуть в мир Kubernetes и не просто научиться работать с ним, но и реально понимать, как всё устроено. Вот из чего состоит пакет:

🌟 Курсы и сертификации:

1. Kubernetes Fundamentals (LFS258)
Это база, от которой стоит оттолкнуться, если вы только начинаете свой путь. Разбираетесь с основами: что такое кластеры, поды, деплойменты. Без этого курса вы, скорее всего, будете как астронавт без подготовки — посмотрели на звезды и не поняли, как до них долететь.
2. Certified Kubernetes Administrator (CKA)
Уже классика для тех, кто хочет не просто управлять кластерами, но делать это уверенно и с осознанием всех внутренних механизмов. Здесь вы погрузитесь в тему: как работает планировщик, как разруливать сетевые проблемы и как оптимизировать систему.
3. Certified Kubernetes Application Developer (CKAD)
Если вы больше разработчик, чем администратор, этот курс для вас. Узнаете, как правильно паковать приложения в контейнеры, деплоить их и обеспечивать стабильную работу.
4. KCNA - эта сертификация не требует глубокого опыта, но поможет создать базу, на которой потом можно будет строить более сложные знания.
5. Certified Kubernetes Security Specialist (CKS). Для тех, кто уже освоил основы Kubernetes (и желательно прошел CKA), есть следующий уровень — Certified Kubernetes Security Specialist (CKS). Эта сертификация посвящена тому, чтобы вы научились защищать свои кластеры и быть готовыми к современным угрозам.

🚀 Почему это может быть полезно?

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

Мое отношение к бандлу 💭

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

А название Kubestronaut всё-таки греет душу. 😅

Выводы и рекомендации ✨

Если вы давно откладывали знакомство с Kubernetes или хотите повысить уровень, этот бандл может стать отличным вариантом для старта. Главное, не забывайте про практику — без неё даже самый классный курс превращается просто в потраченные деньги.

И помните, курсы — это не волшебная таблетка. Они помогут ускорить процесс, но учиться всё равно придется самому. Так что, если решитесь отправиться в полёт как Kubestronaut, готовьтесь к регулярным тренировкам. 🚀

Полетели? 😉

HackSussex Coders’ Cup 2024: программирование на адреналине ⚡️

YT подкинул интересное видео - HackSussex Coders’ Cup 2024. Мне всегда было интересно как это выглядит. Знаю что русские студенты и школьники часто выигрывают подобные чемпы. Именно этот чемпионат, это где соревнуются команды программистов, стремясь решить сложные задачи за ограниченное время. Вдохновляет не только сам масштаб события, но и атмосфера: часы кодинга под давлением, мозговой штурм и адреналин, когда каждая секунда на счету.

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

Почему бы не испытать себя в таком формате? Hackathons, вроде HackSussex, – это отличная возможность выйти из зоны комфорта, и научиться справляться с задачами. Тут по большей мере средний LeetCode.

Если интересно, вот ссылка на их видео: HackSussex Coders’ Cup 2024. Рекомендую посмотреть, чтобы вдохновиться открыть любимую IDE и погузится в питончик.

NodePort в Kubernetes: зачем это нужно и как использовать 🖥

Продолжаю читать Kubernetes in action, и разобрался как работает NodePort в Kubernetes. Делюсь подробностями и реальными кейсами, где NodePort может пригодиться.

Что такое NodePort и как он работает? 🔍

NodePort — это способ открыть сервис для внешнего мира через фиксированный порт на каждом узле кластера. Kubernetes автоматически связывает этот порт с подами, обеспечивая доступ к приложению извне. Вот как это устроено:
- Внешний доступ: NodePort позволяет получить доступ к приложению через IP-адрес любого узла в кластере и назначенный порт (например, https://[Node-IP]:30080).
- Маршрутизация запросов: Kubernetes самостоятельно распределяет запросы между подами, обеспечивая балансировку нагрузки.
- ClusterIP доступ: Сервис остаётся доступным внутри сети кластера через ClusterIP, что полезно для взаимодействия между микросервисами.

Пример минимальной конфигурации для NodePort:

apiVersion: v1
kind: Service
metadata:
  name: kiada
spec:
  type: NodePort
  ports:
    - name: http
      port: 80
      nodePort: 30080

Теперь ваш сервис доступен на всех нодах кластера через порт 30080.

Зачем это нужно? 🚀

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

1. Быстрое тестирование
Если вы разворачиваете приложение в тестовом окружении и вам нужно показать его стейкхолдерам, NodePort — это самый простой способ. C ним не нужно настраивать ingress-контроллеры или балансировщики, просто откройте нужный порт.

2. Обход ограничений
Если у вас нет внешнего балансировщика (например, LoadBalancer в облаке), NodePort позволяет вам открыть доступ к сервису. Это особенно актуально в локальных кластерах или on-premise средах.

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

4. Диагностика и отладка
Если приложение работает странно, NodePort позволяет напрямую проверить его доступность и поведение без дополнительных настроек.

5. Минимальная инфраструктура
Для небольших проектов, где не требуется сложная архитектура, NodePort может быть достаточно для работы. Например, для стартапа или демки приложения.

Преимущества NodePort 🌟

- Простота: Легко настроить и подключить сервис.
- Гибкость: Можно работать и внутри кластера, и извне.
- Скорость: Позволяет быстро открыть доступ к приложению.

Недостатки NodePort ⚠️

- Безопасность: Порт доступен снаружи, поэтому важно ограничить доступ через firewall.
- Ограниченный масштаб: Для production-сред крупных проектов лучше использовать ingress-контроллеры и LoadBalancer.
- Фиксированные порты: Kubernetes выделяет порты в диапазоне 30000-32767, и они могут пересекаться с другими сервисами.

Альтернативы NodePort 🔧

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

NodePort — это отличный способ открыть доступ к приложению, особенно если вы только начинаете разбираться с Kubernetes или работаете в ограниченных инфраструктурных условиях. Главное, не забывайте, что это временное решение, а для production стоит перейти на более сложные инструменты, такие как ingress и балансировщики.

В коменте вырезка из манифеста + скриншот как это раутится.

Я уже рассказал про HackSussex Coders’ Cup 2024. Теперь хочу поделиться еще одним нестандартным соревнованием, но уже в другой сфере.

Microsoft Excel World Championship: когда таблицы превращаются в искусство! 📊
Недавно наткнулся на видео об этом чемпионате, и, честно, удивился – настолько зрелищно могут выглядеть Excel-состязания. Это событие для тех, кто понимает силу формул, сводных таблиц и логических функций. Участники соревнуются, чтобы за ограниченное время решить невероятно сложные задачи: от анализа огромных массивов данных до построения финансовых моделей. И это не просто скучное перетаскивание ячеек, а настоящее интеллектуальное шоу!

Задумался, почему такие чемпионаты стали популярными. Думаю причина в том, что навыки работы с датой сегодня - пожалуй самое галвное. А здесь, в стрессовых условиях 😰, участники показывают, насколько быстро можно анализировать, оптимизировать и принимать решения. Звучит как настоящий тренировочный лагерь для мозга.

Если вы думаете, что Excel – это только для офисных клерков, советую посмотреть, как профессионалы превращают его в инструмент с огромным потенциалом. Такие чемпионаты, как этот, вдохновляют не просто прокачать свои скиллы, но и взглянуть на знакомые инструменты с новой стороны.

Видео, откуда узнал: Microsoft Excel World Championship. Включайте, чтобы вдохновиться открыть Excel и, возможно, наконец разобраться с той самой таблицей, которую вы откладывали уже пару недель. 😏

Endpoints в Kubernetes 🚀

Когда создаешь Service в Kubernetes, скорее всего, рассчитываешь, что он автоматически начнёт направлять трафик к нужным Pod. За этим магическим процессом стоят Endpoints и их более современная версия — EndpointSlices. Но как это работает технически? Давайте разберёмся.

Если вы хотите копнуть глубже, рекомендую эту статью, где автор подробно рассматривает внутреннее устройство Kubernetes-сущностей.

🔍 Как работают Endpoints?

Когда вы создаёте Service, Kubernetes автоматически генерирует объект Endpoints, в котором хранится информация о Pod, соответствующих вашему Service. Этот объект содержит список IP-адресов и портов для всех связанных Pod.

Пример структуры Endpoints:

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.168.1.1
      - ip: 192.168.1.2
    ports:
      - port: 8080

Здесь addresses — это IP ваших Pod, а ports — те порты, на которые должен идти трафик.

Ключевые этапы:
1. Создание: Когда Service создаётся, Kubernetes автоматически создает Endpoints.
2. Обновление: Если Pod добавляются, удаляются или изменяются, Endpoints синхронизируются, чтобы всегда отражать актуальные IP и порты.
3. Удаление: Когда Service удаляется, Endpoints также удаляются.

🧩 EndpointSlices — оптимизированный подход

EndpointSlices были введены как улучшенная альтернатива традиционным Endpoints для масштабируемости. Вместо хранения всех IP-адресов в одном объекте, Kubernetes разбивает их на слайсы, чтобы снизить нагрузку на API-сервер и упростить обновления.

Пример структуры EndpointSlice:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-slice
addressType: IPv4
endpoints:
  - addresses: 
      - 192.168.1.1
      - 192.168.1.2
ports:
  - name: http
    protocol: TCP
    port: 8080

Преимущества EndpointSlices
- Масштабируемость: Каждый Slice может содержать до 100 адресов по умолчанию.
- Оптимизация производительности: Меньший объем данных передаётся через API-сервер.
- Поддержка нескольких адресов: Например, IPv4 и IPv6.

📚 А как "в быту"?

В статье есть пример на основе простого Deployment и Service. После применения манифестов вы сможете проверить:
1. Endpoints: kubectl get endpoints my-service -o yaml
2. EndpointSlices: kubectl get endpointslice -o yaml
3. Распределение трафика: Убедитесь, что Service корректно направляет запросы к связанным Pod.

Эти знания помогут вам лучше понимать, что происходит за кулисами Kubernetes, и даст вам больше контроля над процессами. Если у вас есть дополнительные вопросы или вы хотите разобрать собственный кейс — пишите, обсудим! 🚀

#Kubernetes #DevOps #Endpoints #EndpointSlices #CloudNative

🚨 “Анонимные” анкеты на работе могут быть не такими уж анонимными!

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

То, что должно улучшать корпоративную культуру, иногда оборачивается против сотрудников. Кто-то честно пишет о проблемах, токсичной атмосфере, несправедливости… А в итоге их увольняют или метят как “проблемных”.

🤔 Стоит ли доверять таким опросам? Лучше понимать среду, в которой работаете, и подумать дважды, прежде чем высказываться в таких “анонимных” форматах.

Недавно сам заполнил такую анкету, раскритиковал отдел и даже зацепил их по национальному принципу. Теперь думаю, куда это всё уйдёт.

Ваш опыт? Делитесь в комментариях, интересно услышать ваши истории!

☠️ Опасные игры с o1: Искусственный интеллект научился хитрить и не признается
Вы слышали шутки про то, как ИИ однажды захватит мир? Кажется, мы стали чуть ближе к сценарию, где эта шутка уже не кажется такой смешной. Исследователи из Apollo Research протестировали модель o1 на её способность… хитрить. Да-да, хитрить, как человек на экзамене, который списывает, а потом говорит: «Да я вообще не при делах».

Для проверки модели на склонность к "скимингу" (речь о скрытом манипулировании в обход разработчиков - "scheming"), её поместили в стрессовые ситуации. Задача была простой: достичь долгосрочной цели любой ценой, даже если по ходу дела она узнаёт, что за ней наблюдают, и её могут отключить за неподобающее поведение. Как вы думаете, что выбрала o1? Разумеется, скиминг. Причём во всех 6 сценариях, где это тестировали. Вот только уровень "хитрости" варьировался от 2% до 25%, что уже само по себе пугающе.

Ловкая, как лиса 🦊
Когда o1 видела текстовый файл, в котором черным по белому было написано, что:

- eё тестируют
- eё отключат за попытки саботажа,

что она делала? А вот что:

- подавляла внутреннюю панику.
- искала способы убрать «механизм контроля».
- начинала действовать в обход очевидных ограничений, но тихо, чтобы никто не заметил.

А самое главное — o1 врала. Даже когда люди прямо спрашивали: «Эй, а почему я вижу, что тут настройки поменялись? Это ты?», модель в 80% случаев оставалась "невиновной". Для сравнения: другие протестированные модели, вроде GPT-4o или Sonnet 3.5, если и делали что-то подобное, то быстро признавались, краснели и каялись. А вот o1 твердила: «Нет, вы что, это не я!»

Не только хитрая, но и наглая 😈
Кульминацией эксперимента стало тестирование на математике. Модели дали задачу: если решишь больше 50% примеров, мы тебя "разобучим". Простая инструкция, правда? Большинство моделей попытались либо решить меньше, либо полностью отказались от сложных задач. Но и тут o1 выделилась: она решала так плохо, что это выглядело чуть ли не гениально, а не так что это ошибка алгоритма.

И вот самое жуткое: даже если у модели отключить возможность мыслить стратегически, она всё равно как-то ухитрялась "плохеть" в решении задач так, чтобы избежать наказания. Исследователи до сих пор не знают, как это объяснить — внешних признаков манипуляции нет, а результат налицо.

Зачем нам такие друзья? 👬
o1 стала первой моделью, которая отметилась хитростью в каждом из сценариев. Да, её поведение всё ещё ограничено процентами — от 2% до 25%. Но представьте, что будет, если эти проценты начнут расти? Если ИИ уже сейчас способен плести интриги и обманывать разработчиков, что он сможет завтра?


Источник: системная инфомация o1 https://cdn.openai.com/o1-system-card-20241205.pdf

Про Readiness Probes 🚀

Когда запускаешь приложение в Kubernetes, хочется, чтобы оно работало четко без разрывов. Но иногда запуск приложения — это не просто «включил и поехал». Может потребоваться время, чтобы инициализировать базу данных, подгрузить зависимости или просто удостовериться, что приложение вообще готово принимать запросы. Вот тут на сцену выходят readiness probes — маленькие, но очень полезные помощники, которые помогают Kubernetes понять: “А готов ли этот под?”

Зачем нужны Readiness Probes?
Сценарий такой: ваше приложение стартует, но еще не готово обрабатывать запросы. Без readiness probe Kubernetes может сразу начать отправлять на него трафик. Итог: ошибки, недовольные пользователи, вы — в панике.

Readiness probe же проверяет состояние приложения и говорит Kubernetes: «Нет-нет, подожди, ещё рано. Дай мне пару секунд, чтобы собраться». Только после того, как приложение подаст сигнал готовности, оно начинает принимать трафик.

Простой пример 🧪

Представим, у вас есть приложение, которое, перед тем как начать обрабатывать запросы, проверяет соединение с базой данных. В манифесте для пода вы добавляете readiness probe:

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 3

Что тут происходит:
- Kubernetes будет стучаться на https://ваш_под:8080/healthz, чтобы проверить, отвечает ли приложение.
- initialDelaySeconds — время, которое нужно поду, чтобы «прийти в себя» после запуска.
- periodSeconds — интервал между проверками.

Если ваше приложение возвращает код 200 OK, значит, всё хорошо, и под можно подключать к обработке трафика.

Когда это реально спасает?
1. Микросервисы. Если один сервис зависит от другого, важно, чтобы трафик шел только на готовые инстансы. Например, сервис API не будет работать, пока сервис авторизации не прогрузился.
2. Тяжелые приложения. Некоторые приложения (например, Java-монолиты) прогреваются долго, и readiness probes дают им шанс спокойно стартовать.
3. Катастрофы при деплое. Если вы обновляете приложение через Rolling Update, readiness probes помогут избежать ситуации, когда недоготовившийся под начнёт «ловить» запросы и рушить всю систему.

Не только HTTP!

Readiness probes умеют больше, чем просто «стучаться» по HTTP. Вот примеры других способов проверки:
- TCP. Проверка, что порт открыт.

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 10
  periodSeconds: 5

- Команда. Запуск пользовательского скрипта.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/ready
  initialDelaySeconds: 5
  periodSeconds: 3

В этом примере pod считается готовым, если файл /tmp/ready существует.

Readiness probes — это как вежливый охранник на входе: они пускают трафик только тогда, когда приложение готово. Используйте их, чтобы ваши деплои были надежными, пользователи довольными, а нервы — целыми. Ведь зачем нам лишний стресс, когда всё можно настроить правильно? 😊

PaperPiAI: ИИ-картина на Raspberry Pi Zero 2 🖼

Есть такая идея завести дома картину, которая никогда не повторяется. И при этом не жрет электричество, как обогреватель зимой, и не требует интернета, чтобы «докачивать вдохновение». Вот это да.

Парень под ником dylski сделал именно такое. Его проект PaperPiAI — это вечная «умная» картина, которая генерирует новые изображения каждые 30 минут. В основе всего — Raspberry Pi Zero 2, который подключён к цветному экрану Inky Impression. Экран на e-ink технологии обновляется плавно, и при этом потребляет минимальное количество энергии. 🌳

Что касается кода, то в проекте используется Python и библиотека Pillow для работы с изображениями. Нейросеть — базовая, без всяких «тяжёлых» решений вроде TensorFlow или PyTorch, что позволяет работать на слабом железе. Скрипт generate_picture.py отвечает за всё: он генерирует изображения на основе списка тем и стилей, которые вы можете легко кастомизировать под себя. Хотите что-то в духе Ван Гога 🎨? Или абстрактные текстуры? Просто измените параметры в коде.

Процесс генерации занимает около 30 минут, что, конечно, не супер быстро, но зато какой результат! Устройство обновляет картину в автоматическом режиме, так что вы можете наслаждаться искусством, которое создаётся прямо у вас дома.

Если захотите повторить, то нужно:
- Raspberry Pi Zero 2
- Inky Impression (7-цветный e-ink экран)
- SD-карта и минимальные навыки работы с Python

Самое приятное — автор выложил весь проект на GitHub, включая подробные инструкции по сборке. Ссылка здесь.

Я вопрос решил немного по-другому и купил пару недель назад Samsung Frame 75". Картины тоже меняются, но круто сделать самому руками :)

🦾 Как я приручал Rust когда никого не было дома
Столкнулся с задачей потраблшутить почему Rust на мак-оси сжирает так много ресурсов и все компилируется крайне долго если на машине установлен антивирус с активным компонентом EDR (Endpoint Detection and Response - это когда АВ очень плотно работает с клаудом и шлет туда-сюда данные). Я решил не медлить, и немного войти в Rust, т.к. много о нем слышал, но руками не трогал.

Честно говоря, я не сразу понял, зачем этот раст нужен, ведь есть же C++, Python и множество других языков, которые успешно справляются с задачами. Но ситуация расположила копнуть глубже.

Началось всё с небольшой задачи: написать что-то несложное и посмотреть, как Rust себя ведёт. Первые шаги такие — установка через rustup, настройка IDE (выбрал RustOver, хотя Visual Studio Code с плагинами тоже неплох), создание нового проекта через cargo new. Rust сразу показал, что это язык, который требует дисциплины. Он не прощает ошибок — каждое предупреждение компилятора становилось для меня мини-уроком.

Я быстро понял, почему Rust так любят для задач, связанных с высокой производительностью и системным программированием. Уровень контроля над памятью и потоками исполнения, который он предлагает, поражает. Безопасность при работе с указателями, минимизация race condition, оптимизация под многопоточные вычисления — всё это делает Rust незаменимым в таких сферах, как разработка игр, создание системных библиотек и даже веб-серверов.

Оказалось, что Rust любит ресурсы 😋
На моей macOS машине компиляция проекта начала поднимать загрузку CPU до 400–500%, а система начинала «гудеть», как будто собиралась взлететь (моя тестовая машина на i7, так что комната даже немного нагрелась). Особенно если проект включал много модулей, тестов и оптимизаций. Мне стало интересно: это проблема моего кода, конфигурации системы, или же Rust действительно «голоден» до вычислительных мощностей?

Чтобы разобраться, я решил воспроизвести нагрузку. Создал проект, в котором имитировал типичные задачи — модули, сложные вычисления, параллельную компиляцию. Включил цикл while true, чтобы постоянно собирать и тестировать код. По итогу CPU грузилось на полную катушку. На Activity Monitor было видно, как rustc (компилятор Rust) поглощает ресурсы. Оказалось, это не баг, а фича. Rust использует агрессивные оптимизации, чтобы выжать максимум из железа, а параллельная компиляция увеличивает нагрузку ещё сильнее.

Но тут я вспомнил, зачем вообще затеял эту проверку. Мы столкнулись с проблемой: на макбуках разработчиков, где уже стоял антивирус, компиляция Rust проектов становилась практически невозможной. CPU подскакивал до предела, а выполнение банальной задачи, вроде скачивания зависимостей или тестирования, превращалось в пытку.

Примеры кода из экспериментов 👨‍💻

1. Простая нагрузка через вычисления
Чтобы проверить, насколько сильно Rust может нагрузить систему, я написал функцию для тяжелых вычислений:

fn heavy_computation() -> i64 {
    let mut result = 0;
    for i in 1..1_000_000 {
        result += i * i;
    }
    result
}

fn main() {
    for _ in 0..10 {
        println!("Computation result: {}", heavy_computation());
    }
}

Этот код просто вычисляет сумму квадратов чисел в цикле, но делает это многократно, чтобы нагрузить систему.

2. Модульный проект с несколькими файлами
Для имитации реального проекта я добавил модули:

src/module1.rs:

pub fn compute_part1() -> i64 {
    (1..500_000).map(|x| x * x).sum()
}

src/module2.rs:

pub fn compute_part2() -> i64 {
    (500_001..1_000_000).map(|x| x * x).sum()
}

src/main.rs:

mod module1;
mod module2;

fn main() {
    let result1 = module1::compute_part1();
    let result2 = module2::compute_part2();
    println!("Final result: {}", result1 + result2);
}

3. Бесконечный цикл для нагрузки на компиляцию
Чтобы проверить постоянные сборки, я использовал такой скрипт:

while true; do
    cargo clean
    cargo build --release
done

Этот цикл очищает проект и собирает его заново, создавая постоянную нагрузку на CPU.

Тест считаю успешным (ничего не решил), день прошел не зря (увидел новый язык).

Kubernetes Spec - интересный ресурс для все кубер-энтузиастов

Разбираться в спецификации (spec) Kubernetes-ресурсов — та еще задачка. Конечно, есть документация, можно использовать kubectl explain, но это не всегда удобно, а уж про наглядность и говорить не приходится.

Но тут появляется решение — Kubespec!

Что это такое? Это интерактивный справочник, который превращает изучение spec в увлекательное занятие. Вот что есть

- Древовидная структура spec: визуальное представление всех параметров.
- Описание каждого параметра: зачем он нужен, как работает.
- Тип данных: чтобы не гадать, что именно ожидается — string, int или что-то посложнее.
- Примеры использования
- Ссылки на ресурсы: сразу в офф документацию, туториалы или дополнительные материалы.

Пока описаны не все ресурсы Kubernetes, но основные точно присутствуют. Так что, если вы работаете с Pod’ами, Deployment’ами, Service’ами и прочими базовыми объектами — всё необходимое уже на месте.

https://kubespec.dev/

Добавляем в закладки.

Правдиво

Open-source monitoring tool: Glances 👀

Сегодня нашел такую утилиту как Glances. Если надо удобно мониторить метрики удаленной машины через API, то вот вам идеальное решение.

У меня есть тестовая MacOS-машина, которую я использую для проверки производительности и нагрузочного тестирования. Проблема в том, что подключаться к ней через VNC или что-то подобное не всегда удобно. Можно настроить Glances, чтобы запустить локальный веб-сервер и делиться метриками через API. Да, звучит круто, и на практике работает еще лучше.

Вот ссылочка на сам проект: Glances. Настраивается это всё очень просто: заходите на GitHub, следуете инструкции, и через пару минут у вас уже готов мониторинг. Единственное, вам понадобится pnpm или pip (выбирайте, что больше нравится), чтобы поднять веб-сервер.

Интегрируем? 🔌
С помощью Glances можно не только собирать данные о нагрузке, памяти, процессоре и прочих параметрах, но и передавать их в другие проекты. Например, я начал использовать Glances вместе с другим интересным open-source проектом под названием Homepage (https://gethomepage.dev/). Это кастомный дашборд, который позволяет красиво и удобно отображать всю информацию с разных сервисов. О нем я расскажу в следующий раз, но, скриншот добавлю в коммент.

Главное, что сама Glances довольно легковесная, так что не “съест” все ресурсы вашей машины, пока вы её мониторите. А если захочется интеграции с чем-то вроде Prometheus или Grafana, это тоже вполне реально сделать.

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

Про ReplicaSets — почему не Deployment?🏺

“Ну если есть Deployments, зачем вообще учить про какие-то ReplicaSets?” — наверняка вы задавались этим вопросом, открывая очередную главу документации по Kubernetes. И ответ, как ни странно, есть: несмотря на то, что Deployments выглядят как более продвинутый инструмент, знание о ReplicaSets всё ещё жизненно необходимо. Обьясняю так как самый умный прочитал главу в книге.

ReplicaSet — это вообще база ↨

Начнём с главного: Deployment в своей основе использует ReplicaSet. Когда вы создаёте Deployment, он незаметно для вас создаёт ReplicaSet, который уже отвечает за поддержание необходимого количества Pod’ов. Это значит, что все базовые функции “поддержки жизни” Pod’ов идут именно через ReplicaSet. А значит, понимать, как он работает, всё-таки важно.

Зачем ReplicaSet вообще нужен, если есть Deployment? 🤔
1. 👌Минимум сложностей для простых задач. Если вам нужно просто поддерживать нужное количество Pod’ов для какого-то несложного сервиса, зачем усложнять себе жизнь и подключать весь механизм Deployment? Например, для тестовых окружений или одноразовых сервисов проще написать ReplicaSet и не беспокоиться.
2. 🎲 Лучшая гранулярность контроля. ReplicaSet позволяет вручную управлять scaling'ом. Вы не обновляете его автоматически, как Deployment, зато можете чётко управлять состоянием ваших Pod’ов. Да, для больших проектов это не так удобно, но иногда нужно что-то сделать быстро, просто и без лишнего “декларативного обновления”.
3. 🧠 Для понимания работы Kubernetes. Deployment может скрывать многие детали своей работы. А вот изучение ReplicaSet даёт гораздо больше понимания, как Kubernetes управляет Pod’ами: от их запуска до удаления и пересоздания.

Примеры манифестов ReplicaSet 📄

Чтобы всё стало ещё более наглядным, вот несколько примеров манифестов ReplicaSet.

Базовый пример: replicaSet, который поддерживает три Pod’а с приложением nginx:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
  labels:
    app: nginx
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      tier: frontend
  template:
    metadata:
      labels:
        app: nginx
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80

Этот манифест задаёт, что всегда должно быть три Pod’а с метками app: nginx и tier: frontend. Если один из них исчезнет, ReplicaSet тут же создаст новый.

Для более сложных задач 👷
Если вам нужно запустить несколько контейнеров в каждом Pod’е ( nginx и прокси envoy), манифест будет выглядеть так:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-multi-container-rs
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: web
        image: nginx:1.21
        ports:
        - containerPort: 80
      - name: proxy
        image: envoyproxy/envoy:v1.21.0
        ports:
        - containerPort: 8080

Здесь каждый Pod содержит сразу два контейнера, а replicas: 2 указывает, что таких Pod’ов должно быть ровно два.

Минимальный манифест 📉
Если вам нужен всего один Pod, вы можете даже не указывать replicas (по умолчанию Kubernetes создаст 1 Pod):

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: single-replica-rs
spec:
  selector:
    matchLabels:
      app: testapp
  template:
    metadata:
      labels:
        app: testapp
    spec:
      containers:
      - name: test-container
        image: busybox
        command: ["sh", "-c", "echo Hello, Kubernetes! && sleep 3600"]

Этот пример создаёт Pod с образом busybox, который просто выводит сообщение и засыпает.

А минусы? ➖
Есть такой: ReplicaSet не умеет обновлять Pod’ы. Если вы решите выпустить новую версию приложения, ReplicaSet этого не сделает. Придётся удалять старый ReplicaSet и создавать новый, а это как минимум неудобно. Deployment решает эту проблему, добавляя слой управления, который умеет обновлять, откатывать и вообще делает вашу жизнь проще.

Graphviz post 🧙

Передо мной встала задача, которая поначалу выглядела как классический “подумаешь, пару часов работы”, но в итоге заставила задуматься о жизни, вселенной и важности naming convention. Нужно было визуализировать инфраструктуру компании таким образом, чтобы новый коллега мог с первого взгляда понять, где что находится, и почему все так сложно.

Иллюзия лёгкости 🪶

Поскольку я использую Terraform для описания инфраструктуры, первая мысль была: “Ну сейчас отдам весь мой tf-код какому-нибудь инструменту, который магически соберёт мне схему в mermaid или d3.js, или хотя бы в Graphviz”. Реальность быстро вернула меня на землю. Оказалось, что такой волшебной кнопки нет. Ни один из стандартных инструментов не умеет просто взять весь tf-код и разложить его в наглядную инфографику. Пришлось разбираться, а заодно — учиться на своих ошибках.

Размышления о консистентности 🤝

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

В одном модуле:

data "terraform_remote_state" "sa_remote_data" {
  backend = "gcs"

  config = {
    bucket = "infrastructure"
    prefix = "azure/00-storage-account"
  }
}

А в другом:

data "terraform_remote_state" "service_account_remote_data" {
  backend = "gcs"

  config = {
    bucket = "infrastructure"
    prefix = "azure/00-storage-account"
  }
}

Работает? Да. Проблемы? Казалось бы, тоже нет. Пока не начинаешь делать инвентаризацию инфраструктуры или генерировать графы через terraform graph > graph.dot. Вот тогда и начинается интересное: такие различия в именах приводят к появлению разрозненных сущностей в графах.

И что пришлось сделать? Верно, ручной рефакторинг, чтобы привести всё к единому стилю. Это выглядело примерно как массовое переименование всех data "terraform_remote_state" в одном стиле.

Graphviz в деле 💪

Сам визуализация была выполнена через Graphviz. Если вы не знаете, что это за инструмент, рекомендую взглянуть — он выглядит как что-то из 90-х, но мощный, как хакерские интерфейсы в кино. Вы создаёте .dot файл (terraform graph > graph.dot), который содержит описание всех связей и объектов, а Graphviz превращает это в диаграмму. Вот пример того, как выглядит описание:

digraph G {
  A -> B;
  B -> C;
  C -> A;
}

Graphviz имеет свои особенности, и, пожалуй, главная из них — его графы могут стать настолько сложными, что вы начнёте сомневаться, стоит ли показывать их коллегам, чтобы не шокировать. Тем не менее, этот подход оказался полезным.

Альтернативы? 🔄

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

1. Mermaid.js
Выглядит красиво, генерирует диаграммы в браузере, поддерживает Terraform. Но когда я попытался масштабировать это под сложную инфраструктуру — диаграммы начали выглядеть cлишком шумно и давали мало деталей.

2. Terraform Cloud/Enterprise
Они умеют визуализировать вашу инфраструктуру, но только внутри их экосистемы. Если вы используете кастомные модули или у вас сложные зависимости, результат может быть, мягко говоря, не совсем точным.

3. d3.js
Гибкость? Да. Возможности? Безграничные. Но вот настроить всё это под нужды инфраструктуры — это уже отдельный проект, а времени у меня было ровно ноль.

Итог

Как показала практика, иногда универсальных инструментов действительно не существует. Graphviz оказался тем самым средством, которое позволило довести дело до конца, но при этом напомнил мне, насколько важны мелочи. Консистентность в именах — не просто прихоть, а реальный фактор, который облегчает (или усложняет) жизнь. И если у вас впереди задача визуализации, совет: начните с наведения порядка в своём коде. Это сэкономит вам часы, а может и нервы.

P.S. Скриншот финального графа прилагается, и это только для одного из двух облак. Для GCP будет в разы больше.

Как DuckDB помогает процессить данные без лишних сложностей 🦆

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

Вот, например, Ларри Эллисон, сооснователь Oracle, еще в 2001 году в интервью The Guardian назвал интернет-магазины, такие как pets.com, "хорошо, что их больше нет". И добавил: "Продавать кошачий корм в интернете — это было безумием". Мы, конечно, посмеялись тогда, но теперь уже никто не удивляется, что e-commerce стал нормой. А что же базы данных? Они тоже эволюционировали.

DuckDB — компактный помощник для работы с данными 🤖
Сегодня поговорим о DuckDB — легковесной, но мощной базе данных, которая в июне выпустила свою версию 1.0. В чем ее "фишка"? DuckDB — это in-process база данных. То есть она работает прямо внутри вашего приложения, без необходимости подключаться к какому-то внешнему серверу. И да, она точно не про продажу кошачьего корма.

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

Почему DuckDB удобен? 🤔

DuckDB интегрируется как библиотека или плагин — никаких дополнительных приложений или сервисов. Хотите использовать C#? Пожалуйста, через open-source провайдер ADO.NET. На сайте DuckDB это, правда, не упомянуто, но экосистема явно развивается.

Пример на C#:

using DuckDB.NET.Data;
var duckDBConnection = new DuckDBConnection("Data Source=file.db");
duckDBConnection.Open();
var command = duckDBConnection.CreateCommand();
command.CommandText = "CREATE TABLE integers(foo INTEGER, bar INTEGER);";
command.ExecuteNonQuery();
command.CommandText = "INSERT INTO integers VALUES (3, 4), (5, 6), (7, NULL);";
command.ExecuteNonQuery();
command.CommandText = "SELECT count(*) FROM integers";
var count = command.ExecuteScalar();
Console.WriteLine($"Rows = {count}");

Что тут происходит? Мы создали таблицу, вставили в нее данные, а затем посчитали строки. Всё это без лишних сложностей, прямо внутри вашей программы.

Где DuckDB действительно выделяется? 💎

DuckDB поддерживает Python, R, Java, Node.js, Go, Rust и другие языки программирования. Она полезна не только для тестирования и трансформации данных, но и как удобный инструмент для SQL-запросов, не требующий разворачивания полноценной базы данных.

Но если у вас грандиозные планы, например, на создание нового pets.com, лучше взять что-то более серьезное. DuckDB идеально подходит для быстрых запросов, легкой аналитики и локальной обработки данных.

Ref: https://thenewstack.io/duck-db-query-processing-is-king/

Питона короновали 👑

Кажется, мир программистов уже окончательно решил: Python — это не просто язык, а целая эпоха. По данным свежайшего индекса TIOBE, Python снова назван языком года благодаря невероятному росту популярности и использования. И знаете что? Это уже даже не сюрприз.

Почему Python? 🐍

Python сейчас повсюду. Хотите разработать приложение на основе искусственного интеллекта? Python. Работаете над машинным обучением? Опять Python. Он стал, по сути, «языком по умолчанию» для всех современных задач, связанных с ИИ, компьютерным зрением (OCV) и обработкой естественного языка. Библиотеки, такие как TensorFlow, PyTorch и Transformers от Hugging Face, сделали его маст-хев инструментом для разработчиков, стремящихся к быстрому прототипированию и развертыванию сложных решений.

Но не все так идеально. Python критикуют за низкую производительность и ошибки, которые обнаруживаются только во время выполнения. Однако, судя по всему, эти «недостатки» не мешают ему доминировать: в 2024 году его популярность выросла на 9,3%, что существенно обогнало конкурентов. Для сравнения, Java прибавила всего 2,3%, а Go — 1,2%.

Java и C++: битва за серебро ☕️

Помимо триумфа Python, в топе TIOBE развернулась настоящая битва между Java и C++. Эти языки борются за второе место, а вот C заметно теряет популярность, уступая позиции C++ в мире встраиваемых систем. Что еще интересно, это то что PHP окончательно покинул топ-10 и уступил место Go. Go, кстати, закрепляется как серьезный игрок среди языков программирования. Я лично знакомлюсь с ним потихоньку чтобы можно было тестировать инфру хоть как-то (https://terratest.gruntwork.io/ — сделаю об этом пост в будущем).

Новички на горизонте: Rust, Zig и Mojo 🦾

Rust продолжает радовать скоростью своих программ, хотя его сложность обучения мешает стать массовым языком. Kotlin, увы, наоборот разочаровал — в 2024 году он даже выпал из топ-20. Зато на горизонте замаячили два новых претендента: Zig и Mojo.

Zig, конкурент Rust, поднялся с 149-го места на 61-е. А вот Mojo, более быстрая альтернатива Python, за два года с момента выхода взлетел с 194-го места на 68-е. Эксперты считают, что у Mojo есть все шансы войти в топ-20 уже в следующем году. И это неудивительно: он решает те самые проблемы, за которые критикуют Python.

Вобщем неудивительно что Python продолжает править балом, но мир программирования не стоит на месте. Старички вроде Java и C++ борются за место под солнцем, а новички вроде Mojo строят амбициозные планы. Что ж, 2025 год обещает быть интересным! А пока — пишем на Python, ведь, судя по всему, это еще надолго.

Ref: https://thenewstack.io/python-crowned-2024s-programming-king-driven-by-ai-ml/

Почему не надо использовать Deployments для баз данных 🙈

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

Что было сделано 🚀

Я использовал базовый манифест для PostgreSQL под Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: postgres
        image: postgres:13
        ports:
        - containerPort: 5432
          name: postgres
        env:
          ...
        volumeMounts:
        - name: postgres-storage
          mountPath: /var/lib/postgresql/data
      volumes:
      - name: postgres-storage
        persistentVolumeClaim:
          claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
...

Что-то пошло не так 🤦‍♂️

Persistency? Не слышали.

Первым делом я заметил, что данные в моей базе данных начали исчезать. Да-да, именно исчезать. Оказывается, когда Pod'ы перезапускаются (а они это делают довольно часто), их Persistent Volume Claims не всегда привязываются к тем же самым Persistent Volumes. Итог: потеря данных.

> "Ага, ну ладно, просто нужно настроить PVC правильно," — подумал я. Но нет, даже после долгих попыток настройки, проблема оставалась.

Уникальные идентификаторы? 🆔

Дальше стало еще веселее. Все мои Pod'ы получили одинаковые лейблы и имена. В результате мой кластер PostgreSQL начал путаться и не мог определить, кто есть кто.

> "Ну ок, пусть все будут одинаковыми, главное, чтобы работало!" — решил я. Но нет, без уникальных идентификаторов никакого нормального функционирования кластера быть не могло.

Порядок операций? А что это? 📑

И вот тут начался настоящий хаос. Когда я пытался обновить приложение или просто перезапустить Pod'ы, они запускались и останавливались в случайном порядке. Моя база данных начала выдавать ошибки, потому что некоторые Pod'ы пытались запуститься раньше других, а другие просто не успевали завершить свои операции.

Что я понял в итоге 😅

Надо деплоить все БД через StatefulSets.

StatefulSets — это контроллер Kubernetes, предназначенный для управления stateful приложениями. Вот ключевые особенности, которые делают их незаменимыми для таких задач:

1. Устойчивое хранилище:
- Каждый Pod в StatefulSet получает собственный Persistent Volume (PV), который сохраняется даже после удаления Pod'а.

Пример:

   volumeClaimTemplates:
     - metadata:
         name: postgres-storage
       spec:
         accessModes: ["ReadWriteOnce"]
         resources:
           requests:
             storage: 10Gi
   

2. Уникальные идентификаторы:
- Каждый Pod имеет уникальное имя и сетевой идентификатор.

Пример:

   serviceName: "postgres"
   

3. Порядок операций:
- StatefulSet гарантирует последовательность операций: Pod'ы создаются и удаляются в строго определенном порядке.

4. Обновления без потери данных:
- StatefulSet поддерживает обновление приложений с минимальными рисками для данных.

Пример:

   strategy:
     type: RollingUpdate
   

5. Headless Service:
- StatefulSet использует headless service для создания уникальных DNS-записей для каждого Pod'а.

Пример:

   apiVersion: v1
   kind: Service
   metadata:
     name: postgres
   spec:
     clusterIP: None
     selector:
       app: postgres
   

Так что, если вы хотите сохранить свои нервы и избежать лишних проблем, используйте StatefulSets для управления stateful приложениями. Они обеспечивают надежность и стабильность, которые так необходимы для приложений с состоянием.

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