Kubernetes Resource Report - Скрипт для создания HTML-отчета о запросах ЦП/памяти и их утилизации (собранных с помощью Metrics API) для одного или нескольких кластеров Kubernetes.

Основная цель отчета о ресурсах Kubernetes - помочь оптимизировать запросы ресурсов Kubernetes и избежать простоя. Осторожно, отчет не имеет авторизации, не публикуйте это публично!

Демонстрационная версия

#k8s #kubernetes #costs #resources

https://codeberg.org/hjacobs/kube-resource-report

Для тех кому избыточны Python генерированные HTML отчеты о утилизации ресурсов в кластере Kubernetes, а kubectl top и describe долго и не практично, есть простой CLI инструмент - kube-capacity.

Распространяется как самостоятельный CLI инструмент так и в виде Krew плагина для kubectl.

Попробуйте сами:

kubectl krew install resource-capacity
kubectl resource-capacity --util --sort cpu.util
kubectl resource-capacity --pods

#k8s #kubernetes #krew #costs #resources

https://github.com/robscott/kube-capacity

Тут timescale оказывается свой инструмент для установки набора observability развивает.

Tobs - CLI утилита (инсталятор Helm чартов), цель которой — максимально упростить установку полного стека наблюдаемости (Observability Stack) в кластер Kubernetes. Установит в кластер и настроит:

- Prometheus
- AlertManager
- Grafana
- Node-Exporter
- Kube-State-Metrics
- Prometheus-Operator
- Promscale
- TimescaleDB
- Promlens
- Opentelemetry-Operator
- Jaeger Query

Но стоит ли использовать TimeScale (PromScale) для долгосрочного хранения метрик, это спорный вопрос. На всякий случай приложу пару статей с сравнением:
- VictoriaMetrics vs TimescaleDB vs InfluxDB
- Promscale vs VictoriaMetrics 😲

#k8s #kubernetes #prometheus #timescale #promscale #observability #jaeger #grafana #alertmanager

https://github.com/timescale/tobs

ZomboDB привносит в Postgres мощные функции текстового поиска и аналитики, используя Elasticsearch в качестве типа индексов.

С технической точки зрения ZomboDB - это родное расширение Postgres, которое реализует API Postgres Index Access Method. Как собственный тип индекса Postgres, ZomboDB позволяет вам создавать индекс zombodb в ваших существующих таблицах Postgres. В этот момент ZomboDB полностью управляет удаленным индексом Elasticsearch и гарантирует транзакционно корректные результаты текстового поиска.

#postgres #elasticsearch

https://github.com/zombodb/zombodb

eBPF (extended Berkeley Packet Filter) всё сильнее набирает обороты, приведу пожалуй несколько статей в заметку.

▫️Почему сообщество разработчиков ядра заменяет iptables на BPF
▫️BPF для самых маленьких, часть нулевая: classic BPF
▫️BPF для самых маленьких, часть первая: extended BPF
▫️BPF для самых маленьких, часть вторая: разнообразие типов программ BPF
▫️Отлаживаем ядро из командной строки с bpftrace
▫️Как мы оптимизировали сетевой шейпер Linux в облаке с помощью eBPF
▫️BpfTrace — наконец, полноценная замена Dtrace в Linux
▫️От High Ceph Latency к Kernel Patch с помощью eBPF/BCC

🔹Подборка полезностей на тему eBPF awesome-ebpf
🔹Top eBPF Open Source Projects on Github

#bpf #ebpf

K8up (произносится ketchup) — это оператор резервного копирования Kubernetes, распространяемый через Helm, совместимый с OpenShift и обычным Kubernetes.

— Делает резервную копию всех PVC, помеченных как RWM или с определенной меткой.
— Создание резервных копий по требованию или через планировщик.
— Резервные копии любых приложений, которые умеют писать данные на стандартный вывод или в файл.
— Проверка целостности резервных копий.
— Ротация бэкапов.
— Поддержка S3-совместимых хранилищ.

Примеры смотрите в документации
А что бы было понятнее, вот пример аннотации для бэкапа PostgreSQL

template:
  metadata:
    labels:
      app: postgresql
    annotations:
      k8up.io/backupcommand: >-
        sh -c
        '
          PGDATABASE="$POSTGRES_DB"
          PGUSER="$POSTGRES_USER"
          PGPASSWORD="$POSTGRES_PASSWORD"
          pg_dump --clean
        '
      k8up.io/file-extension: .sql
  spec:
    containers:
      - name: postgres
        image: docker.io/bitnami/postgresql:11

#k8s #kubernetes #backup

https://github.com/k8up-io/k8up

Deprecations AKA KubePug - утилита для проверки устаревших версий API в Kubernetes, поставляется как подключаемый модуль (krew deprecations) для kubectl и самостоятельная утилита kubepug.

Kubepug получает информацию о устаревших ресурсах из API Kubernetes, проверяет текущий кластер и размещенные в нем ресурсы или файлы переданные на входе с полученной информацией из кластера. На выходе получите отчет, что следует актуализировать.

Установим krew плагин:

kubectl krew install deprecations

Пример как проверить Helm шаблон на совместимость с кубером 1.22.0
helm template -f values.yaml .0 | kubepug --k8s-version v1.22.0 --input-file=-

Также ранее упоминал похожие утилиты Kubent и Pluto

#k8s #kubernetes #deprecation

https://github.com/rikatz/kubepug

prometheus_bot - бот для отправки событий Alertmanager в Telegram.

Со стороны Alertmanager настраиваем webhook_configs для отправки сообщений в бота, в боте настраиваем токен. На этом всё, никаких дополнительных команд бот не умеет. Но умеет использовать свой персональный gotmpl для сообщений, форматировать дату/время и единицы измерения.

#prometheus #alertmanager #telegram #bot

https://github.com/inCaller/prometheus_bot

alertmanager-bot - бот для отправки событий Alertmanager в Telegram.

Этот бот умеет в разный набор комманд:
/start - Подписаться на оповещения.
/stop - Отписаться от уведомлений.
/status - Распечатать текущий статус.
/alerts - Список всех предупреждений.
/silences - Список всех отключенных уведомлений.
/chats - Список всех пользователей и групповых чатов, которые подписались.

Если сравнивать с prometheus_bot, здесь мы имеем необходимость в своей БД (bolt, etcd, consul), в отличии от prometheus_bot, где используется обычная веб-хук труба. Выбирайте, что вам подходит лучше, управляемый или простой бот.

#prometheus #alertmanager #telegram #bot

https://github.com/metalmatze/alertmanager-bot

Какую выбрать платформу для коллективной работы над локализацией приложений?

▫️Есть, наверное всем знакомый Crowdin, предоставляется только как сервис с разными тарифами, но для OpenSource проектов можно попросить бесплатное размещение.

А что есть из On-Premise?

▫️Weblate - веб-система непрерывной локализации с лицензией GPL-3.0 License, довольно зрелое решение. И скорее всего вы найдете его первым при попытке найти OpenSource альтернативу Crowdin

▫️Pontoon - Платформа локализации Mozilla с лицензией BSD-3-Clause License. Очень напоминает своим интерфейсом Crowdin, и на нем кстати ведется работа над переводами Firefox и прочих продуктов Mozilla.

И что выбрать, Weblate или Ponton? Оба решения написаны на Python с использованием Django и имеют очень похожий набор функционала, интеграция с SCM, база переводов, предложения переводов, OAuth.

Я считаю Pontoon куда привлекательнее. внешне, имеет более приятный и отзывчивый интерфейс, на него будет проще пересесть переводчикам, ранее работавшим с Crodwin. Да и само приложение требует значительно меньше ресурсов для работы, weblate к примеру, только, что бы запустится, потребовал 4 ядра и 12 Gi в лимитах контейнера, Ponton же ограничился 2/2 и вполне не плохо работал.

Конечно еще есть такие сервисы как Phrase, POEditor, Transifex, Lokalise и т.п., а если у вас всего один небольшой проект, вы можете обойтись свободным десктопным poedit

Целью было скорее рассказать о Pontoon, ведь он лежит совсем не на верху поисковой выдачи. И может кому-то помочь с выбором.

#localization #crodwin #weblate #ponton #gettext #po

Hierarchical Namespace Controller (HNC) - проект из Kubernetes SIG по созданию иерархических (вложенных) пространств имён (sub-namespace) в кластере Kubernetes. Проект развивается с целью решения вопроса мультиарендности (multitenancy) кластера Kubernetes между разными потребителями.

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

Ранее упоминал альтернативное решение, оператор Capsule позволяющий объединить несколько неймспейсов кластера Kubernetes в одно мультиарендное пространство.

#k8s #kubernetes #multitenancy #operator

https://github.com/kubernetes-sigs/hierarchical-namespaces

Accurate оператор для создания вложенных пространств имён (sub-namespace) в кластере Kubernetes.

Это довольно молодой (сейчас beta) конкурент Hierarchical Namespace Controller (HNC)

И Accurate, и HNC преследуют одну и ту же цель — обеспечить лучшее удобство использования пространства имен в многопользовательских средах Kubernetes.

Accurate более точен, чем HNC, в распространении ресурсов, потому что Accurate использует способ согласия, а HNC использует способ отказа. При использовании Accurate будут распространяться только ресурсы, аннотированные с помощью accurate.cybozu.com/propagate. При использовании HNC будут распространяться все ресурсы, за исключением специально аннотированных.

Предположим, вы хотите распространять только секрет для извлечения личных изображений. С HNC это может быть довольно сложно, потому что секреты часто генерируются из другого ресурса. Такие сгенерированные секреты часто не могут иметь пользовательские аннотации. Как следствие, такие секреты будут распространяться на подпространства имен, что может вызвать проблемы с безопасностью.

Больше подробностей, вы найдёте в документации.

#k8s #kubernetes #multitenancy #operator

https://github.com/cybozu-go/accurate

Опа, нашлась мидлварь для работы с внешним агентом OPA PDP (Policy Decision Point) на .NET - OPA-AspDotNetCore-Middleware

И еще как бонус, WASM агент для OPA на .NET

#opa #aspnet #netcore #pdp

https://github.com/build-security/OPA-AspDotNetCore-Middleware
https://github.com/christophwille/dotnet-opa-wasm

Нашел еще одну утилиту config-syncer (ранее Kubed) - созданную для синхронизации / репликации ConfigMap и Secret в Kubernetes, но в отличии от аналогов умеет выполнять синхронизацию не только между неймспейсами но и между кластерами Kubernetes.

Ранее упоминал:
▫️kubernetes-replicator - синхронизирует ConfigMap, Secret, Role и RoleBinding между ns
▫️kubernetes-reflector синхронизирует ConfigMap и Secret между ns

#k8s #kubernetes #integrity

https://github.com/kubeops/config-syncer

Неожиданно для меня, bash скрипт kube-dump для создания чистового дампа yaml манифестов из kubernetes (читай бэкапа), смог набрать 125 звезд на GitHub.

Вчера принесли PR, который добавляет три новых параметра сохранения манифестов Kubernetes.

--detailed — исключает удаление метаданных, файлы сохраняются как есть;
--output-by-type — сохраняет ресурсы структурировано по каталогам, сервисы в svc/*, поды в pod/* и т.п. Меня несколько раз просили это сделать, значит параметр нужный;
--flat — сохраняет все ресурсы одного типа в один общий файл с списком items:.

Стандартная логика не изменилась, но новый функционал появился, в связи с этим выпустил новую минорную версию 1.1.0

#k8s #kubernetes #backup

https://github.com/WoozyMasta/kube-dump

SLO exporter - это не просто экспортер Service Level Objectives, а скорее нормализатор и класификатор для метрик. Некая мидлварь, которая поможет сначала обработать весь ваш объем метрик Prometheus и уже передать в него самую мякотку.

Как это работает:
Каждое полученное событие имеет метаданные, которые используются для его классификации по определенному домену и классу SLO, как описано в главе рабочей книги SRE «Оповещения об SLO». Кроме того, имя приложения, в котором произошло событие, и идентификатор события также добавляются для облегчения отладки возможного нарушения SLO. Наконец, вы решаете на основе метаданных, было ли событие успешным или неудачным. Затем SLO-exporter предоставляет метрику Prometheus slo_domain_slo_class:slo_events_total{slo_domain="...", slo_class="...", result="..."}. Это дает вам количество успешных или неудачных событий, и это все, что вам нужно для расчета бюджета ошибок (error budget), скорости сгорания (burn rate) и т.п.

Также у ребят есть две занимательные статьи на эту тему:
▫️Implementing SRE workbook alerting with Prometheus only
▫️Advanced SLO infrastructure based on slo-exporter

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

#SLO #SLI #prometheus

https://github.com/seznam/slo-exporter

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

▫️ChaosKube - периодически убивает случайные поды;
▫️KubeThanos - убивает половину случайно выбранных подов;
▫️KubeInvaders - похоже на Space Invaders, но инопланетяне - это поды или ноды;
▫️Lens extension Invaders - это расширение для Lens которое добавляет в него KubeInvaders, но убиваем только поды;
▫️KubeDoom - убивайте поды Kubernetes, играя в DOOM;
▫️KubeCraftAdmin - в Minecraft убивайте животных в загонах (неймспейсах), где свинья - pod, корва - deployment, курица - svc, лошадь - rs
▫️Whack-a-pod - игра, цель которой нарушить работоспособность сервиса, бейте молотком по вылезающим из нор кротов (поды) и попробуйте нарушить работу приложения
▫️Kube-Chaos - игра в стиле Twin Stick Shooter для убийства подов

#chaos #chaos_engineering #fun

Chaos Mesh - это облачная платформа Chaos Engineering, которая организует хаос в средах Kubernetes, вносит хаос в приложения и инфраструктуру Kubernetes управляемым способом, который предоставляет простые настраиваемые определения для экспериментов с хаосом и автоматической оркестровки.

Состоит из компонентов:
🔹Chaos Operator: используется для планирования и управления жизненным циклом объектов CRD.
🔹Chaos Dashboard: веб-интерфейс для управления, проектирования и мониторинга экспериментов с хаосом.

Chaos Operator использует CustomResourceDefinition (CRD) для определения объектов хаоса:
▫️pod-kill: выбранный pod уничтожается (потребоваться ReplicaSet или что-то подобное, чтобы обеспечить перезапуск);
▫️pod-failure: выбранный pod будет недоступен в течение указанного периода времени;
▫️container-kill: выбранный контейнер уничтожается в выбранном поде;
▫️netem chaos: сетевой хаос, такой как задержка, дублирование и т.д.;
▫️network-partition: имитация разделения сети;
▫️IO chaos: имитация ошибок файловой системы, таких как задержка ввода-вывода, ошибки чтения/записи и т.д.;
▫️time chaos: выбранному поду будет введено искажение часов;
▫️cpu-burn: имитирует нагрузку на ЦП выбранного пода;
▫️memory-burn: имитирует утилизацию памяти выбранного пода;
▫️kernel chaos: выбранный под будет внедрен с ошибками (slab, bio и т.д);
▫️dns chaos: выбранный под будет содержать ошибки DNS, такие как error, random.

#chaos #chaos_engineering #k8s #kubernetes

https://github.com/chaos-mesh/chaos-mesh