#пятница

Ну почему бы и да

#eks #aks #kubernetes

Апгрейд кластера кубернетис.
С чего начинать?

Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes

У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/

В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster

У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете​ и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster

Это всё облачные куберы и их вендорлок решения.

Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova

Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.

Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.

#costoptimization #newrelic

И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"

"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".

Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц

Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим

Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing

Да, всё так и есть, лицензии и трафик.

Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.

Ingestion. Из чего ты состоишь?
https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.

Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.

На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу

SELECT bytecountestimate()/10e8 FROM `Span`, `SpanEvent` WHERE instrumentation.provider != 'pixie' FACET appName OR service.name OR entity.name LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ ивентов

SELECT bytecountestimate()/10e8 FROM `Transaction`, `TransactionError` FACET appName LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ метрик

SELECT bytecountestimate()/10e8 FROM `Metric` WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie' FACET CASES (WHERE newrelic.source = 'agent' AS 'Metric Time Slices', WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics') SINCE unixtimestamp UNTIL unixtimestamp

Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.

Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее

В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:

newrelic выезжает на дефолтах

Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.

Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование

newrelic.span_events.max_samples_stored       = 200   # was 2000

- в golang, например

NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED=200  # was 1000 (default)
NEW_RELIC_TRANSACTION_EVENTS_MAX_SAMPLES_STORED=2000  # was 10000 (default)
NEW_RELIC_APPLICATION_LOGGING_FORWARDING_ENABLED=false # was true (default)

+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.

Что же я сделал? Я уменьшил количество семплов в минуту.

Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.

Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.

#costoptimization #newrelic

Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.

В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/

Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами

Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.

#kubernetes #devops

Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro

Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.

Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.

Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.

Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.

Зачем? Зачем в наше время вы ещё держитесь за свои ноды и эхи?

Вот так незаметно и тихо прошёл год с основания моего авторского телеграм канала. Поздравляю сам себя и всех, кому это интересно читать.

#costoptimization #aws #cloudwatch #одинденьизжизни

"Алекс, у нас снова траты по амазон, глянь по биллингу, чего можно скостить".

Иду в billing, выбираю последний месяц.
Дааа, много всего опять зачарджило. Чего можно убрать?
О, в топ 10 есть клаудвоч. Начну с него. Почему так много? Почти $2000+.
Смотрю что не так.
Внезапно много идет за графу

$0.01 per 1,000 metrics requested using GetMetricData API - US East (Northern Virginia)

200.000.000+ реквестов.
Читаю что это.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html

Ага. Какой-то сторонний механизм/утилита, которая при помощи кредов/роли подключается к AWS API и вытягивает данные по метрикам из клаудвоч.

Из известного мне есть такие два инструмента:
- https://github.com/prometheus/cloudwatch_exporter
- https://github.com/prometheus-community/yet-another-cloudwatch-exporter

Оба эти категории инструмента подключаются к AWS API, дергают метрики, экспортируют в удобный формат, чтобы можно было в victoria metrics/prometheus/grafana видеть эти новые метрики.
Почему новые? Они берут оригинальное название метрики, добавляют префикс и получается новая метрика в нашем хранилище.

Далее поиском по всем репозиториям(гит, арго, хелм) внутри компании ищу - есть ли они у нас.
Да, есть, у нас YACE.

Как оптимизировать? Мне ничего в голову не приходит, как сделать следующее:
- подключаюсь к service через порт форвард

kubectl port-forward svc/yet-another-cloudwatch-exporter 5000:5000

- вытягиваю все метрики в файл

curl localhost:5000/metrics > metrics.txt

- пишу баш скрипт, который считает количество уникальных метрик и всякое такое

Ага, у нас 54.000+ метрик. Это много.
Иду в конфиг в гите, там нечто типа

config: |-
    apiVersion: v1alpha1
    discovery:
      exportedTagsOnMetrics:
        AWS/NetworkELB:
          - tenant-id
          - type
          - cluster
      jobs:
        - type: AWS/NetworkELB
          regions:
            - us-east-1
...
            - eu-central-1
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveFlowCount
              statistics: [Average, Minimum, Maximum]
            - name: ActiveFlowCount_TLS
              statistics: [Average, Minimum, Maximum]
...
            - name: UnHealthyHostCount
              statistics: [Average, Minimum, Maximum]
            - name: PortAllocationErrorCount
              statistics: [Sum]
...
        - type: AWS/TransitGateway
          regions:
            - us-east-1
...
          period: 300
          length: 300
          metrics:
            - name: BytesIn
              statistics: [Average, Minimum, Maximum, Sum]
            - name: BytesOut
              statistics: [Average, Minimum, Maximum, Sum]
            - name: PacketsIn
              statistics: [Average, Minimum, Maximum, Sum]
...
        - type: AWS/NATGateway
          regions:
            - us-east-1
...
            - eu-central-2
          period: 300
          length: 300
          metrics:
            - name: ActiveConnectionCount
              statistics: [Maximum, Sum]
            - name: BytesInFromDestination
              statistics: [Sum]
...

И такого там много.

По частоте опроса вроде ок - 300 секунд, около бест практис для клаудвоч экспортёров.
А чего подрезать-то тогда?
Нужен ли max? Min? Avg?
Следим ли мы за натгейтвеем?

А всё просто.
- при том же bash скрипте расписываем все уникальные метрики и их итоговое название.
- идём все репозитории с алертингом и мониторингом (alertmanager, grafana irm, vmalert, grafana dashboards etc)
- если метрика нигде в observability не используется - мы её просто убираем из конфига. Где-то только min, где-то max, где-то полностью всю метрику со всеми значениями

Даже если удастся убрать хотя бы 50% неиспользуемых метрик - это минус 50% от биллинга, а это $1000+
Пулл реквест, ревью, аппрув, раскатываем.
Всё, в следующем месяце ждём снижения костов на клаудвоч на 50%+

Итог:
я всего лишь проанализировал куда уходят деньги, нашёл конфиг приложения, который чарджит амазон, собрал все метрики, проверил есть ли они в обсервабилити, удалил неиспользуемое (зачем нам собирать то, что мы не используем?).
Ничего сложного, а у нас экономия на пустом месте.

Адвент-календарь декабря 2025 ❤️

После шикарных подарков от CloudFlare и GitHub, красочно подхватывает эстафету и выдаёт DockerHub.
https://www.dockerstatus.com/

#пятница #всратость

На работе защита везде и всюду:
- рабочий ноутбук без прав администратора, с целым зоопарком антивирусов и систем контроля доступа.
Сам Евгений по утрам приезжает и лично проверяет твою авторизацию.

- вход в кубер через SSO, OIDC, VPN со временем сессии 2 часа, ролевая модель строже и острее, чем шутки в 1937 году, девелоперы могут быть только в UI ArgoCD с read-only, а каждый чих логирует SIEM, и если ты случайно нажал F5 чаще, чем раз в 5 секунд, срабатывает правило "Potential Brute Force" и тебя блочат.

- никакого интернета, только внутренние ресурсы. Везде distroless или SBOM, имаджи сканирует Trivy, депенданси бот обновляет версии. Вайтлист на реджистри, OPA. Три контура container registry, с ручной перекладкой имаджей и immutable тегами. Три контура CICD с разделением доступов по командам и подпись образа через Cosign.

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

- инфобеза угорает по файрволам между immutable Talos нодами и натягивает Istio везде, даже на глобусы. В системе логируется буквально всё: ивенты, ивенты ивентов, даже команды от дебаг контейнеров типа ls. Собственно и kubectl debug не работает, когда ты пытаешься запустить busybox, ведь OPA его блокирует, потому что не в вайтлисте. Все логи не просто собираются, а дублируются в три разных S3-бакета, каждый из которых зашифрован своим KMS-ключом, который ротируется каждые 2 часа

- всё обвешано киверно политиками, от замены пути к имаджам, до принудительного обмазывания капабилитис. Уже оператор Trivy сканирует в рантайме имаджи, пофиг, что в CI/CD уже сканировалось.

- повсеместно селинукс, секьюрити контекст, рутлес, капабилитис.
Всем запрещено монтирование секрета куба, доступ к нему только по заявке и аппрувом Его Самого.

- все коммиты в git проходят через 4 уровня ревью: обычный code review, security review, compliance review и финальный ревью от инфобеза, где они проверяют, не закодировал ли ты в YAML отступах какие-нибудь вредоносные секреты.
Каждый мердж в мастер требует подписи руководителя департамента

- пароль от БД не знает даже дба - оператор сам создает пароль и хранит в волте, доступ только у оператора, пароль инжектится напрямую в апп, даже в секретах не узнать. Все проходят PCI DSS v4, SOC2 и даже DRP в случае нападения казаков.

- всюду SAST, DAST, DU HAST, CIS, SCA, хоть и не все понимают что это и зачем, но покорно используют

- админы опеншифта и кубера общаются между собой исключительно через вебхуки и admission-контроллеры

- каждый месяц проходишь тесты на полиграфе, доказывая, что никаких закладок не делал, ты всего-лишь пилил пайплайны. Вокруг датацентра ров с акулами, колючей проволокой в башкирском мёде, вертолёты и собственная армия с малой авиацией. При выдаче USB-токена при старте работы проходишь квест убегания от служебных собак, тренировка на скорость и выносливость, ведь слабаки нам не нужны.
.
..
...
А в это время в Перми, весело щебеча, словно воробушек, операционистка Валентина делает "клац-клац" фотокамерой с телефона, сливая все данные клиентов на экране монитора её панели оператора, за сумасшедшие 3500 рублей, которые ей пообещали анонимы в телеграме, наплевав на DLP, ведь она об этом даже и не знала.
.
..
...
Инфобеза тратит ещё миллиард денег, чтобы провести расследование и внезапно доказывает, что виноваты девопсы, опять всё сделали не так. Ведь так оно и есть. Во всём везде и всегда виноваты девопсы.