Рубрика «kubernetes» - 2

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

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

А потом начинается архитектура. Открывается draw.io. Кто-то двигает прямоугольник на восемь пикселей вправо, экспортирует PNG, вставляет его в Confluence и кидает ссылку в чат. Через месяц сервис переименовали, интеграцию переделали, команда-владелец сменилась, а прямоугольник продолжает жить своей жизнью.

Читать полностью »

Разбираемся, что за зверь хранит весь ваш Kubernetes, учимся читать его ошибки и честно отвечаем на вопрос, можно ли ему доверять

Что это вообще

etcd — распределённое key‑value хранилище со строгой консистентностью. Если на пальцах: это место, где Kubernetes хранит авторитетное состояние кластера. Деплойменты, поды, секреты, конфигмапы — всё это записи в etcd. kube‑apiserver — по сути толстый REST‑фасад над ним, а scheduler, controller‑manager и kubelet не являются источниками истины для состояния kubernetes; они получают его через apiserver и имеют собственное локальное состояние

Отсюда первое следствие, которое стоит выжечь на подкорках:

Читать полностью »

Боль

Если вы держите on‑prem кластер на десятки или сотни нод, дальше можно не объяснять. Обновили CNI, или ядро, или драйвер сетевой карты, или просто переехали частью нод в новый сегмент. Проходит какое‑то время, и начинают капать тикеты: «у нас иногда таймаутит между подами», «DNS иногда не резолвится», «health‑check то падает, то нет».

Читать полностью »

Всё чаще встречаю такую схему: берём LLM, даём ей доступ к kubectl или k8s API, в system prompt или подключённом skill‑е пишем что‑то вроде «ты можешь только читать, ничего не удаляй и не изменяй», и считаем вопрос закрытым. Прошёл через это сам и в какой‑то момент понял, что это не граница безопасности, а вежливая просьба.

Читать полностью »

Предисловие

За последние несколько месяцев плотной работы над инфраструктурой для проекта я прошёл путь от первых команд в терминале Linux до настройки полностью отказоустойчивого K3s‑кластера с Zero‑Downtime деплоем. Шишек на этом деле я набил огромное количество, и мне определённо есть чем поделиться.

Сразу оговорюсь: в этой статье не будет монотонных гайдов, слепых копипастов YAML‑манифестов и пересказа официальной документации. С базовой настройкой вы отлично справитесь, прочитав мануалы создателей этих инструментов.

Читать полностью »

Карго-культ DevOps: чек-лист самопроверки

Карго-культ DevOps: чек-лист самопроверки

Читать полностью »

Сначала контекст. Я делаю внутреннего read-only агента для инфраструктурных расследований: он может читать данные, но не изменять production. Инженер пишет ему в Mattermost или резервном web-чате обычный вопрос: «почему сервис отдаёт 502?», «кто выкатил эту версию?» или «что изменилось перед инцидентом?». Агент сам собирает данные из Kubernetes, VictoriaMetrics, Elasticsearch, GitLab, Grafana, GSLB и других эксплуатационных источников, а затем возвращает ответ с доказательствами и явно перечисленными пробелами.

Читать полностью »

Мечта: systemd как execution plane

Все мы знаем старый прикол — заказ пиццы через Kubernetes (это, кстати, реальный проект)… Смешно, потому что показывает, до какой степени создатели Kubernetes оторвались от простого «запустить процесс»: между декларативным состоянием в API-сервере и реальным процессом на хосте у него почти ещё одна целая ОС — CRI, containerd, runc. Но на любом Linux-хосте уже есть менеджер выполнения с cgroups, namespaces, зависимостями, журналом и D-Bus API — systemd… Вас ничего не смущает?

Читать полностью »

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

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

Читать полностью »

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

PII здесь — это personally identifiable information, то есть персонально идентифицируемая информация: email, телефон, адрес, паспортные данные, номера карт, токены доступа и другие значения, которые не должны свободно гулять по логам.

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

x9VdQp2Mz_La77kPq0
sk_live_51Nx...
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Но быстро выяснилось, что одной энтропией нормальный фильтр не собрать.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js