Euripid

Дисклеймер. ELM327 — зарегистрированный продукт компании ELM Electronics. Эта серия описывает самостоятельную реализацию совместимого командного интерфейса в учебных целях и не является оригинальной микросхемой ELM Electronics. Проект не предназначен для коммерческого использования под именем «ELM327».

Вводная статья: зачем читать эту серию и что мы будем строить

OBD-II: главный диагностический разъём современных легковых автомобилей

Если вы когда-нибудь приезжали на техосмотр или к механику, вы, скорее всего, видели, как он достаёт небольшое устройство, вставляет его под торпедо и смотрит в ноутбук. Этот разъём — OBD-II (On-Board Diagnostics, версия II). С 1996 года он обязателен для всех легковых автомобилей, продаваемых в США, с 2001 — для бензиновых, а с 2004 — для дизельных легковых в Европе (стандарт EOBD). Сегодня OBD-II / EOBD присутствует в подавляющем большинстве легковых автомобилей на ключевых рынках. Грузовики, автобусы и спецтехника — отдельная история: у них другие разъёмы (9-pin Deutsch), другие протоколы (J1939), другое напряжение борт-сети (24 В) и другие требования к защите.

Через этот разъём можно прочитать коды ошибок (те самые «check engine»), посмотреть живые данные с датчиков — обороты двигателя, температуру охлаждающей жидкости, давление турбины, лямбда-зонды, скорость — и даже сбросить ошибки после ремонта.

Звучит просто. Но внутри — несколько несовместимых друг с другом протоколов, которые появлялись в разное время у разных производителей. CAN, K-line, J1850, ISO 9141 — каждый требует своего физического уровня, своей процедуры инициализации, своего формата кадров.

Именно поэтому появился ELM327.

Что такое ELM327

ELM327 — это микросхема канадской компании ELM Electronics, выпущенная в начале 2000-х. Внутри — маленький микроконтроллер с прошивкой, которая:

1. Принимает простые текстовые команды через UART — так называемые AT-команды (по аналогии с модемами Hayes)

2. Транслирует их в нужный протокол шины автомобиля

3. Возвращает ответ тоже в виде читаемых ASCII-строк

Диагностическая программа на телефоне или ноутбуке не знает ничего про CAN или K-line. Она просто отправляет строку 0100\r (запрос PID 00, поддерживаемые параметры) и получает обратно что-то вроде 41 00 BE 3E B8 10\r\n>. ELM327 берёт на себя всю грязную работу с шиной.

Команды ELM327 — это отдельный небольшой язык. Несколько примеров:

Команда Смысл ATZ Сброс адаптера ATI Версия прошивки ATSP6 Установить протокол ISO 15765-4 CAN 11-бит 500 кбит/с ATH1 Включить заголовки фреймов 0100 Отправить OBD запрос: поддерживаемые PID 01-20

Всего спецификация ELM327 v2.3 определяет более 100 AT-команд и 13 протоколов шин. Наша реализация охватывает набор команд, достаточный для прохождения ELM Scan Adapter Validator и работы целевых диагностических приложений.

Проблема: значительная часть дешёвых «ELM327» на рынке — клоны с неполной реализацией

Поищите «ELM327 Bluetooth» на любом маркетплейсе. Дешёвые Bluetooth-адаптеры стоят на порядок дешевле профессиональных устройств (OBDLink, Kiwi), но значительная часть из них — клоны на дешёвых микроконтроллерах с частичной реализацией протокола. Это не оригинальная микросхема ELM Electronics.

Типичные проблемы клонов:

• Поддерживают только CAN, на K-line машинах не работают вообще

• Сообщают версию ELM327 v1.5 или v2.1, хотя реализация неполная

• AT-команды возвращают мусор или не работают вовсе

• Теряют соединение по Bluetooth под нагрузкой

• Не сохраняют настройки между сессиями

Профессиональные адаптеры (Kiwi 3, OBDLink MX+) существенно дороже, но содержат нормальную прошивку. Их недостаток: прошивку нельзя изменить под свои нужды.

Зачем писать своё

Причина 1: Понять, как это работает

Диагностика — это не магия. Это конкретные протоколы с конкретными тайм-аутами и процедурами. Написав адаптер с нуля, вы будете точно знать, почему машина не отвечает, почему инициализация занимает 3 секунды, что значит «BUS INIT: ERROR».

Причина 2: Полный контроль

Хотите поддержку нестандартных PID? Особый формат вывода? Логирование на SD-карту? Всё это невозможно в закрытых устройствах, но тривиально, когда прошивка ваша.

Причина 3: Bluetooth-адаптер со своей идентификацией

Если вы разрабатываете диагностическое приложение, вам нужен адаптер с предсказуемым поведением. Свой адаптер = отсутствие сюрпризов от обновлений стороннего firmware.

Причина 4: Учебная задача мирового класса

Реализация ELM327 затрагивает практически все аспекты embedded-разработки: прерывания, UART, CAN, bit-banging, EEPROM, конечные автоматы, тайминги на уровне микросекунд, совместимость протоколов. Лучшей учебной задачи для начинающего embedded-разработчика трудно придумать.

Что мы будем строить

В этой серии мы разберём готовую рабочую ELM327 v2.3-совместимую прошивку, написанную на C для микроконтроллера PIC18F25K80 в среде MPLAB X / XC8.

Прошивка реализует:

• ELM327 v2.3-совместимый набор AT-команд, достаточный для прохождения ELM Scan Adapter Validator и работы целевых приложений

• ISO 15765-4 (CAN OBD) — 11/29-бит, 500/250 кбит/с, включая ISO-TP многофреймовый обмен

• ISO 9141-2 — 5-baud slow init, K-line

• ISO 14230-4 (KWP2000) — fast init и 5-baud init

• SAE J1850 PWM и VPW — логика протокола реализована в коде; требует отдельного физического уровня (MC33390 и аналоги), не входит в базовый BOM

• SAE J1939 — программная поддержка CAN 29-бит кадров; для грузовиков нужна аппаратная версия под 24 В и 9-pin Deutsch разъём

• Bluetooth через модуль HC-05 с автонастройкой (Android/Windows; для iOS нужен BLE или Wi-Fi модуль)

• Полное сохранение настроек в EEPROM

• Диагностические счётчики и отладочные команды

Прошивка проходит тест совместимости ELM Scan Adapter Validator (ELM 2.3). В последней главе подробно разберём результаты тестирования, что именно проверялось и какие незначительные расхождения с оригинальным поведением остаются (они не мешают работе целевых приложений).

Требуемые знания

Серия рассчитана на начинающих embedded-разработчиков. Мы предполагаем, что вы:

• Знаете основы C (указатели, структуры, битовые операции)

• Слышали про микроконтроллеры и регистры периферии

• Имеете общее представление о том, что такое UART и SPI

Знания CAN, K-line, J1850, ISO-TP не требуются — мы объясним каждый протокол с нуля, начиная с физического уровня.

Что вам понадобится для практики

Готовый dev-kit (собранная плата с PIC18F25K80, TJA1050, K-line драйвером и HC-05) доступен для приобретения — подробности в комментариях к статье.

Компонент Примечание PIC18F25K80 Основной МК. Доступен в DIP-28 PIC18F26K80 Альтернатива с большей Flash TJA1050 CAN трансивер Драйвер K-line (LIN) Например, L9637D или TJA1020 HC-05 Bluetooth модуль PICkit 3/4 Программатор MPLAB X + XC8 Бесплатный компилятор OBD-II J1962 male connector или пиг-тейл Для подключения к машине

Структура серии

# Статья Тема 0 Эта статья Обзор серии 1 Глава 1 Выбор железа и конфигурация МК 2 Глава 2 Архитектура прошивки: главный цикл, ISR, структуры 3 Глава 3 UART и Bluetooth: буферизация и автонастройка HC-05 4 Глава 4 Таймеры, EEPROM и системные утилиты 5 Глава 5 CAN шина: инициализация, отправка, приём, фильтры 6 Глава 6 ISO-TP: многофреймовый обмен поверх CAN 7 Глава 7 K-line: ISO 9141 и KWP2000 от физики до протокола 8 Глава 8 J1850 PWM и VPW 9 Глава 9 Диспетчер протоколов и OBD-запросы 10 Глава 10 Парсер AT-команд 11 Глава 11 Тестирование совместимости с ELM327

Полный исходный код со схемами и проектом MPLAB X будет опубликован в последней статье серии.

И вот уже восемь открытых терминалов, в каждом — свой kubectl port-forward. Окна перемешиваются, названия похожи, и найти нужный терминал становится квестом.

Ну да да, можно использовать Tmux, но это не сильно облегчает процесс.

С какими проблемами я столкнулся

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

• Ручная работа при смене контекста — переключил kubectl context на другой кластер, и всё нужно перенастраивать заново. Каждый раз одни и те же команды.

• Отсутствие истории — вернулся после обеда, половина соединений отвалилась. Какие именно порты были нужны? Приходится вспоминать или искать в истории bash.

• Сложность передачи знаний — коллега просит команду для подключения к сервису. Диктуешь по буквам namespace, имя пода, номера портов. Это неэффективно и приводит к ошибкам.

Я решил, что пора автоматизировать этот процесс и написать специализированный инструмент, исходник на GitHub PortFwd

Анализ существующих решений

Прежде чем писать своё, я изучил, что уже есть на рынке. Оказалось, что решения существуют, но каждое имеет свои плюсы и минусы.

kubectl port-forward

Встроенный инструмент, который работает надёжно и стабильно. Но у него принципиальное ограничение: один терминал — одно соединение. При работе с микросервисной архитектурой, где нужно одновременно держать открытыми 5-10 соединений, это превращается в хаос.

kubefwd

Интересный проект, который автоматически форвардит все сервисы из namespace. Звучит удобно, но есть серьёзные проблемы. Во-первых, он требует права sudo, потому что модифицирует /etc/hosts. Во-вторых, это слишком инвазивно — я хочу контролировать, какие именно сервисы форвардить, а не получать всё скопом.

Lens

Красивый графический интерфейс с множеством функций для работы с Kubernetes. Но это Electron-приложение, которое потребляет более 500 МБ оперативной памяти и 2% CPU даже в режиме простоя. Для такой простой задачи, как управление port-forward, это явный overkill. Плюс Lens — это комбайн, а мне нужен специализированный инструмент.

k9s

Отличный TUI для работы с Kubernetes, который я сам активно использую. Но port-forward там — не основная функция. Управлять множеством одновременных соединений неудобно, нет сохранения сессий, нет группировки.

После этого анализа я понял, что нужно писать своё решение. Лёгкое, специализированное, без Electron'а.

kftRay

Отдельно рассмотрю и сравню проект https://kftray.app/

Сравнение этих двух инструментов интересно тем, что они решают одну и ту же задачу — управление пробросом портов (port-forwarding) в Kubernetes — но делают это с совершенно разных позиций.

Характеристика kftray (Rust) portFwd (Go) Язык программирования Rust (фреймворк Tauri) Go Интерфейс Полноценный GUI (графическое окно в трее) CLI (командная строка) + кастомный UI Сложность Высокая (визуальное управление множеством конфигов) Минималистичная (быстрый запуск из терминала) Кроссплатформенность Отличная (Windows, macOS, Linux) Отличная (нативный бинарник) Целевая аудитория Те, кто хочет «настроить и забыть» через интерфейс Те, кто предпочитает терминал и скорость

Почему для такого проекта Go может быть лучше?

Несмотря на то, что kftray на Rust выглядит очень современно, использование Go для portFwd дает несколько фундаментальных преимуществ в контексте Kubernetes:

1. Нативная экосистема Kubernetes: Весь Kubernetes (и kubectl) написан на Go. Используя Go, разработчик portFwd применяет те же самые библиотеки (client-go), которые используют создатели K8s. Это гарантирует 100% совместимость с конфигами kubeconfig, контекстами и методами аутентификации.

2. Стабильность сетевых соединений: В Go работа с сетью и многопоточностью (Goroutines) реализована «из коробки» очень эффективно. Проброс портов — это постоянное ожидание трафика и пересылка пакетов. Горутины позволяют обрабатывать сотни таких соединений с минимальным потреблением памяти и без риска «уронить» поток.

3. Скорость компиляции и деплоя: Если вам нужно быстро внести правку в логику проброса портов, Go скомпилирует бинарник за секунды. Rust (особенно с тяжелым Tauri/GUI) собирается значительно дольше.

4. Размер и простота: Для системной утилиты, которая должна просто «перекидывать байты» из кластера на локальную машину, Go предлагает более простой и читаемый код. В Rust-проекте (как kftray) много времени уходит на управление памятью и согласование типов интерфейса, в то время как в Go-проекте фокус остается на сетевой логике.

Плюсы portFwd (на Go)

• Минимализм: Идеально подходит для автоматизации и скриптов.

• Низкий порог входа: Если вы захотите доработать инструмент под себя, разобраться в коде на Go будет в разы проще, чем в Rust-коде с GUI-обвязкой.

• Работа с контекстами: Go-библиотеки лучше всего справляются с переключением между десятками кластеров и сложными методами SSO-логина в облака (AWS/GCP/Azure).

Плюсы kftray (на Rust)

• Визуальный комфорт: Если у вас 20+ портов, управлять ими через иконку в трее удобнее, чем держать открытыми 5 вкладок терминала.

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

Итог

Если вам нужен инструмент для ежедневной рутины с красивыми кнопками — выбирайте kftray. Если вам нужна надежная, быстрая и легкая утилита, которая работает так же, как сам Kubernetes — portFwd на Go будет более естественным и предсказуемым выбором.

Теория: как работает port-forward в Kubernetes

Прежде чем писать реализацию, важно понять, как port-forward работает под капотом. Без этого понимания легко написать код, который будет падать в неожиданных местах.

Архитектура соединения

Когда вы выполняете kubectl port-forward pod/nginx 8080:80, данные проходят через несколько компонентов (см. рис. 1). Клиент устанавливает соединение с API Server, который проксирует запрос на Kubelet ноды, где запущен под. Kubelet, в свою очередь, использует nsenter для доступа к network namespace контейнера и пересылает данные процессу внутри.

рис. 1: Архитектура port-forward в Kubernetes

Протокол SPDY

Для мультиплексирования потоков Kubernetes использует протокол SPDY — предшественник HTTP/2. Это позволяет передавать несколько потоков данных через одно TCP-соединение. Процесс установки соединения выглядит так:

1. Клиент отправляет HTTP POST запрос на эндпоинт /api/v1/namespaces/{ns}/pods/{pod}/portforward

2. В заголовке указывается Upgrade: SPDY/3.1, что инициирует переключение протокола

3. API Server устанавливает SPDY-соединение и создаёт потоки для данных и ошибок

4. Kubelet получает запрос и проксирует данные в контейнер

Критический нюанс: Service vs Pod

Это один из самых важных моментов, который я понял не сразу. Хотя Kubernetes API формально поддерживает эндпоинт /services/{service}/portforward, на практике kubectl резолвит сервис в под и подключается напрямую к поду.

Почему так? Потому что port-forward работает на уровне конкретного контейнера через Kubelet, а не через механизм балансировки kube-proxy. Это значит, что нам тоже придётся находить backing pod для сервиса и резолвить targetPort.

Архитектура приложения

После изучения теории я спроектировал архитектуру PortFwd. Приложение разделено на несколько слоёв, каждый из которых отвечает за свою область.

Слой Kubernetes (k8s/client.go)

Этот компонент инкапсулирует всю работу с Kubernetes API. Он отвечает за получение списка namespace'ов, подов и сервисов, а также за резолвинг сервисов в поды. Использует официальную библиотеку client-go.

Менеджер соединений (portforward/manager.go)

Центральный компонент, который управляет жизненным циклом всех port-forward соединений. Он создаёт SPDY-транспорт, отслеживает статус каждого соединения, обрабатывает ошибки и уведомляет UI об изменениях через callback.

Слой UI (ui/app.go, views.go, styles.go)

Терминальный интерфейс построен на фреймворке Bubble Tea с использованием библиотеки Lipgloss для стилизации. Bubble Tea реализует Elm Architecture: Model (состояние), Update (обработка событий), View (рендеринг).

Конфигурация (config/state.go)

Компонент для сохранения и восстановления сессий. При выходе из приложения текущие соединения сохраняются в YAML-файл, а при следующем запуске — восстанавливаются.

Реализация: работа с Kubernetes API

Инициализация клиента

Для работы с кластером нужно инициализировать клиент. Я использовал паттерн из официальных примеров client-go: сначала пробуем получить in-cluster конфиг (если приложение запущено внутри пода), а если не получается — читаем kubeconfig файл.

Ключевой момент — использование clientcmd.BuildConfigFromFlags, которая автоматически учитывает текущий context из kubeconfig. Это позволяет приложению работать с тем же кластером, что и kubectl.

Резолвинг Service в Pod

Когда пользователь выбирает сервис для port-forward, нам нужно найти backing pod. Алгоритм следующий:

1. Получаем сервис — делаем GET-запрос к API для получения спецификации сервиса

2. Резолвим targetPort — сервис может иметь port: 80, но контейнер слушает на targetPort: 8000. Нужно использовать именно targetPort

3. Строим label selector — из поля spec.selector сервиса формируем строку для поиска подов

4. Находим Running под — получаем список подов по selector и выбираем первый со статусом Running

Обработка Named Ports

Отдельная сложность — именованные порты. Сервис может указывать targetPort: http вместо числа. В этом случае нужно найти порт с таким именем в спецификации контейнера пода. Без этой обработки приложение будет пытаться подключиться к неправильному порту.

Это была одна из главных граблей в разработке. Я потратил несколько часов, разбираясь, почему соединение отказывает, пока не понял, что приложение стучится в порт 80, а процесс слушает на 8000.

Реализация: SPDY port-forward

Создание транспорта

Для установки port-forward соединения используется несколько компонентов из client-go:

• spdy.RoundTripperFor — создаёт HTTP transport с поддержкой SPDY upgrade

• spdy.NewDialer — создаёт dialer, который умеет устанавливать SPDY-соединения

• portforward.NewOnAddresses — собственно создаёт port-forwarder

Важный момент: я использую NewOnAddresses с параметром []string{"127.0.0.1"}, а не стандартный New. Это заставляет слушать только на IPv4. По умолчанию forwarder слушает и на IPv4, и на IPv6, что на некоторых системах (особенно macOS) вызывает проблемы с dual-stack.

Управление жизненным циклом

Каждое соединение имеет несколько каналов для управления:

• stopChan — сигнал остановки, закрытие этого канала прерывает ForwardPorts

• readyChan — сигнал готовности, сообщает что туннель установлен

• context с cancelFunc — для graceful shutdown

При запуске соединения мы ждём либо сигнала готовности (соединение установлено), либо ошибки, либо таймаута (30 секунд). После установки соединения переходим в режим ожидания завершения.

Реализация: TUI на Bubble Tea

Почему Bubble Tea?

Bubble Tea от Charm — это фреймворк для построения терминальных интерфейсов на Go, вдохновлённый Elm Architecture. Он предоставляет чистую модель программирования:

• Model — иммутабельное состояние приложения (текущий view, список соединений, выбранный элемент)

• Update — чистая функция, которая принимает сообщение и возвращает новое состояние

• View — чистая функция, которая рендерит состояние в строку для терминала

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

Стилизация с Lipgloss

Для визуального оформления я использую Lipgloss — библиотеку для стилизации терминального вывода. Она позволяет задавать цвета, отступы, границы, выравнивание — всё, что нужно для красивого интерфейса.

Я выбрал цветовую схему в стиле киберпанка: неоновый зелёный для активных соединений, красный для ошибок, жёлтый для предупреждений. Это делает статусы соединений мгновенно различимыми.

Связь UI и Manager

Менеджер соединений работает асинхронно — соединения устанавливаются и падают в фоне. Чтобы UI узнавал об изменениях, я использую callback-паттерн. При инициализации UI устанавливает callback в менеджере, и при любом изменении состояния соединения менеджер вызывает этот callback, который отправляет сообщение в Bubble Tea.

Реализация: сохранение состояния

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

Одна из главных фич PortFwd — сохранение сессий между запусками. Вы настроили 5 port-forward соединений, закрыли приложение, а при следующем запуске — все соединения автоматически восстанавливаются.

Формат хранения

Состояние сохраняется в YAML-файл по пути ~/.config/portfwd/state.yaml. Для каждого соединения сохраняются: namespace, тип ресурса (pod или service), имя ресурса, локальный и удалённый порты, и флаг wasActive — было ли соединение активно при сохранении.

Флаг wasActive важен: если пользователь вручную остановил соединение перед выходом, при следующем запуске оно должно остаться остановленным, а не переподключаться автоматически.

Логика восстановления

При запуске приложение читает файл состояния и для каждого сохранённого соединения проверяет:

1. Если wasActive: false — добавляем как остановленное, не подключаемся

2. Если wasActive: true — проверяем доступность ресурса (существует ли под/сервис)

3. Если ресурс доступен — автоматически переподключаемся

4. Если ресурс недоступен — добавляем как остановленное с ошибкой

Грабли, на которые я наступил

Эта секция — самая ценная часть статьи. Здесь собраны реальные проблемы, на которые я потратил часы отладки.

Проблема 1: Зависание при выходе

Симптом: после нажатия q приложение не завершается, висит бесконечно.

Причина: callback onChange вызывает program.Send() в Bubble Tea. После вызова tea.Quit программа закрывает канал сообщений, и Send() блокируется навечно, ожидая возможности отправить сообщение.

Решение: отключать callback до остановки соединений. Сначала делаем m.onChange = nil, потом останавливаем соединения. Тогда при изменении состояния соединения callback не вызывается и deadlock не возникает.

Проблема 2: connection refused при подключении к сервису

Симптом: при port-forward к сервису получаем ошибку connection refused внутри контейнера.

Причина: я использовал port сервиса (например, 80) вместо targetPort (например, 8000). Приложение в контейнере слушало на 8000, а мы стучались в 80.

Решение: полный резолвинг targetPort, включая обработку named ports. Нужно всегда использовать targetPort, а не port сервиса.

Проблема 3: panic при повторном закрытии канала

Симптом: panic: close of closed channel при быстром двойном нажатии на «Stop».

Причина: канал stopChan закрывается дважды. В Go закрытие уже закрытого канала вызывает panic.

Решение: использовать sync.Once для защиты операции закрытия. Once гарантирует, что функция выполнится только один раз, даже при конкурентных вызовах.

Проблема 4: IPv6 connection refused

Симптом: на некоторых системах получаем ошибку IPv6 dial tcp6 [::1]:80: connection refused.

Причина: по умолчанию port-forwarder слушает и на IPv4, и на IPv6. На системах с определёнными сетевыми настройками это вызывает проблемы.

Решение: явно указывать только IPv4 через NewOnAddresses с параметром []string{"127.0.0.1"}.

Проблема 5: соединения не восстанавливаются при рестарте

Симптом: при запуске приложения список соединений пустой, хотя файл состояния существует.

Причина: я вызывал saveSessionState() после StopAll(). К моменту сохранения все соединения уже были удалены из менеджера.

Решение: изменить порядок: сначала сохраняем состояние (когда соединения ещё существуют), потом останавливаем их.

Альтернативы, от которых я отказался

WebSocket вместо SPDY: Kubernetes поддерживает оба протокола, но client-go имеет готовую и протестированную реализацию именно для SPDY. Писать свой WebSocket-клиент — лишняя работа без явных преимуществ.

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

Тестирование и результаты

Производительность

Я измерил потребление ресурсов PortFwd в сравнении с альтернативами при 5 активных соединениях в режиме простоя:

• PortFwd: ~30 МБ RAM, ~0.1% CPU

• Lens: ~500 МБ RAM, ~2% CPU

• 5 отдельных kubectl: ~100 МБ RAM, ~0.5% CPU

PortFwd потребляет в 15 раз меньше памяти, чем Lens, и запускается мгновенно (менее 100 мс против ~5 секунд у Lens).

Функциональность

• ✅ Единое окно для всех соединений

• ✅ Интерактивный выбор: namespace → тип ресурса → pod/service → порты

• ✅ Автоматический резолвинг targetPort для сервисов

• ✅ Сохранение и восстановление сессий между запусками

• ✅ Отдельные логи для каждого соединения

• ✅ Graceful shutdown без zombie-процессов

• ✅ Справка по горячим клавишам

Горячие клавиши

• ↑/↓ или j/k — навигация по списку

• n — создать новое соединение

• d — отключить выбранное соединение

• D — отключить все соединения

• r — переподключить выбранное

• l — показать логи соединения

• x — удалить остановленное соединение

• ? — показать справку

• q — выход

Заключение

Что получилось

Я создал специализированный инструмент, который решает конкретную проблему — управление множеством port-forward соединений в Kubernetes. PortFwd легковесный, быстрый и делает одну вещь хорошо.

Что можно улучшить

• Профили — сохранение наборов соединений для разных окружений (dev, staging, prod) с быстрым переключением

• Multi-cluster — работа с несколькими кластерами одновременно в одном окне

• Auto-reconnect — автоматическое переподключение при потере связи без участия пользователя

• Import — импорт соединений из kubectl команд или YAML-манифестов

Уроки, которые я извлёк

1. Читай исходники kubectl — это лучшая документация по работе с Kubernetes API. Официальная документация не покрывает многие нюансы.

2. Тестируй на разных системах — dual-stack IPv4/IPv6 ведёт себя по-разному на Linux и macOS. То, что работает у тебя, может сломаться у пользователя.

3. sync.Once — твой друг — каналы в Go закрываются только один раз, и это легко забыть при конкурентном доступе.

4. Порядок операций критичен — особенно при graceful shutdown. Сначала сохраняй состояние, потом останавливай процессы.

Полезные ссылки

• GitHub репозиторий PortFwd

• Примеры использования client-go

• Bubble Tea — фреймворк для TUI на Go

• Lipgloss — стилизация терминального вывода

• Kubernetes документация по port-forward

Буду рад звёздам на GitHub, issue с багами и pull request'ам с улучшениями. Спасибо за внимание!

3. Мастер кнопки «Обновить». Когда ИИ выдаёт дичь, я не плачу. Я с загадочной улыбкой жму F5 и говорю: «Давай ещё разок, только с чувством, с толком, с расстановкой».

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

Коллега пытался устроить соревнование: он против ChatGPT в написании скрипта. ИИ сделал за 10 секунд. Коллега — за полчаса, но с тремя чашками кофе и самоутверждением. Победила дружба. И кофе.

Следующий этап карьеры — стать «шаманом промптов». Буду водить курсы: «Как шепнуть нейросети на ушко, чтобы она сделала всё правильно и принесла вам кофе». Дорого беру.

А если серьёзно, я теперь не «программист-кодер». Я — «программист-стратег, дирижёр цифрового оркестра и ловец глюков». Звучит солиднее, да?

В общем, я не умираю. Я эволюционирую. Просто моя эволюция теперь измеряется не в строках кода, а в креативности запросов и скорости удаления дичи из ответов ИИ.

И да, этот пост, конечно же, писал я. А то вдруг подумаете, что я уже делегировал и это машина. Пока не делегировал. Но идея хорошая…

Ща спрошу у ИИ, как он сам к этому относится.

Пауза. Затем стандартная скороговорка:

— Нет, это у нас офис для документов, а склад/мастер/специалист сейчас в [другом конце города]. Может подъехать к вам через три часа. Или у нас есть другой вариант, но дороже.

Копаешь дальше. Из первых 20 объявлений 18 оказываются вот такими «призраками». Их «офисы» на карте — это:

*  Виртуальные адреса в бизнес-центрах (аренда почтового ящика, по сути).

*  Адреса массовой регистрации фирм-однодневок.

*  Просто случайные точки в центре для красоты и привлечения кликов.

2. Великий и ужасный Агрегатор из Ниоткуда

Решаешь докопаться. Начинаешь звонить подряд, спрашиваешь: «А какой у вас точный адрес, куда можно приехать?». В ответ — нервный смешок, заученный скрипт или откровенное: «Мы агрегатор, у нас специалисты по всему региону».

Одна контора из какого-нибудь условного Нефтеюганска натыкала сотни объявлений по всем городам России. У них нет НИ ОДНОГО реального представительства в твоём городе. Они просто берут заявку, а потом в панике ищут в своих чатах какого-нибудь свободного исполнителя, предлагая ему копейки. А ты платишь втридорога.

Что это за зверь? Признаки Агрегатора-Призрака:

1.  «Офис» на карте есть, но на панораме Yandex — жилой дом, пустырь или совсем другая контора.

2.  Один телефон на 100 разных услуг — от услуг мастера до продажи шин и переездов. а Авито это еще и скрыл для пользователей

3.  В профиле 300+ одинаковых объявлений в географии от Калининграда до Владивостока.

4.  На прямой вопрос «Где ваш офис?» начинается путаница и перевод на «менеджера».

5.  Отзывы либо пусто, либо шаблонные, как под копирку.

Акт 3. Почему это не просто «ой, ну что ты придрался»?

1.  Цена. Ты платишь накрутку дяде из другого города, который просто нажал кнопку «разместить».

2.  Качество. Его не существует. Агрегатору всё равно, кого он найдёт. Гарантии, ответственность, репутация — нулевые.

3.  Безопасность. В случае с услугами — ты впускаешь в дом или отдаёшь вещь человеку, о котором посредник знает только номер. Ни тебе договора, ни проверки.

Итог. Что делать? Инструкция по выживанию в эпоху фантомов:

1.  Забудьте про карту на Авито. Она теперь — игровое поле для «найди призрака», а не инструмент поиска.

2.  Ищите в обход. Вбивайте в Yandex или 2ГИС «[Нужная услуга/товар] [Ваш город] отзывы форум». Чаще найдёте нормальных местных специалистов или продавцов на тематических форумах или в пабликах.

3.  Проверяйте профиль. Одна-две услуги, один город, живые фото с объектов или товара, история отзывов — хорошие признаки.

4.  Требуйте чек и документы. Любой мало-мальски серьёзный исполнитель (ИП или ООО) сможет его предоставить. Агрегатор-однодневка — нет.

Это же полный провал идеи? Авито из условной «доски объявлений от соседей» превратился в помойку агрегаторов-паразитов. Они душат честных мастеров и продавцов, которым лень или некогда бороться с этими ботами за первые места в поиске. Я один такой «везучий» ?

Давайте в комментариях:

1.  + если сталкивались.

2. Советуйте, как всё-таки находить реальных людей в 2025 году. Может, есть другие площадки?

Полез в интернеты. Оказалось, есть теория заговора: виновата может быть крышка расширительного бачка. Если она не стравливает давление, система превращается в скороварку и ломает всё, что сделано из пластика. Логично.

Эпизод 3. Экономическая версия.

Решил: меняю радиатор и крышку разом. Выбор пал на радиатор Luzar LRc1858 и на крышку SWAG 40940722

— дёшево, и вроде как отзывы нормальные. Поставил, залил, проверил — сухо!

«Вот оно, счастье!» — подумал я.

Всего на одну неделю.

Потом заметил лёгкое запотевание на том же стыке. «Не может быть! — подумал я. — Это крышка-убийца!». Начитался ужасов, что даже оригинальные крышки — лотерея.

Эпизод 4. Паранойя и наука.

Купил переходник под крышку. Проверил давление срабатывания старой и новой крышки. Обе — в норме.

Моя теория рассыпалась. Значит, дело в радиаторе? В неудачном экземпляре? Могло ли быть такое? Оказалось, запросто.

Эпизод 5. Решение ядерной войны.

Настал момент Истины. Погуглил и понял, что Luzar, Natec и им подобные — это часто просто бренды-упаковщики. Заказывают на разных заводах в Китае/Турции, и качество может плавать.

Для такого монстра как Touareg лучше брать того, кто делает радиаторы для конвейера. Выбор пал на MAHLE/KNECHT CR1183000P

(это OEM-поставщик, а не просто имя на коробке).

Цена вопроса была, конечно, ощутимой. Но что делать — купил, поставил.

Итог: Прошло уже более 3 месяцев — ПОЛНОЕ БЕЗМОЛВИЕ И СУХО. Уровень антифриза не двигается. Я наконец-то сплю спокойно.

А вот качество наглядно это и в других радиаторах встречается наверно до 1.5 бар выдержит и такое соединение

а вот такое выдержит и 6 бар

Мораль этой истории для тех, у кого похожая беда:

1. Первое подозрение при любой течи на VAG — крышка расширительного бачка. Проверьте её, даже если она новая. Бракованных — море.

2. Радиаторы «нонейм» (Luzar и аналоги) — это лотерея. Может повезёт и отъездит 5 лет. А может, как у меня, попадётся косячный. Это не производитель, а перекупщик.

3. На таких машинах иногда лучше сразу переплатить за OEM-уровень (BEHR, Nissens, Mahle), чем менять дважды, теряя время, антифриз и нервы. Дешевле в долгосрочной перспективе.

4. Самый главный вывод: Если вы не готовы к таким квестам — не покупайте сложные немецкие внедорожники б/у. Покупайте Ладу. У неё тоже всё течёт, но вы хотя бы будете знать, куда точно и почему это дешевле.

Всем добра и сухих патрубков!