Подскажите, какая главная причина большого количества логов? Сколько по времени вы храните логи? Используете ли APM? Строите ли метрики на основе логов?
Продолжая подход Service Mesh, для сборки логов и метрик можно установить на инстанс приложения агент мониторинга (Telegraf, Fluentbit, Node Exporter и другие).
Продолжая подход Service Mesh, для сборки логов (Fluentbit) и метрик можно установить на инстанс приложения агент мониторинга (Telegraf, Node Exporter и другие).
Стартовым можно считать использование инструментов вроде Ansible, Puppet, Chef, Saltstack и др. Стоит помнить, что, как и в остальных инструментах Immutable, хранилище стейта должно быть отделено от виртуальной машины
У Ansible, Puppet, Chef, Saltstack нет state, а у terraform есть. Но в пункте ничего про terraform не написано.
1. Более медленный деплой новых версий по сравнению с Mutable-инфраструктурой, так как поднимаются новые машины.
Наоборот, более быстрый деплой по сравнению с Mutable инфраструктурой. Вы просто указываете новый образ, в котором уже был деплой приложений и библиотек когда вы его паковали, например, с помощью packer.
3. Упрощение конфигурации. Не нужно помнить, что и на какой машине установлено, если есть готовый образ, из которого она создана, со своим описанием в виде файла конфигурации.
4. Благодаря согласованной конфигурации машин проще выкатывать обновления и тестировать новые версии.
5. Инстансы с одним и тем же приложением одинаковы.
Если использовать практики infrastructure as a code и идемпотентность, то эти пункты можно реализовать на изменяемой инфраструктуре.
Спасибо за пост. Как связано понимание этих концепции и что любой инструмент может перестать быть опенсорсом? Скорее эти фразу стоило разделить на 2 предложения.
Встроенный в Cilium механизм BGP не поддерживает BFD.
Не делали issue?
Для реализации выбрали Kyverno. Дополнительно написали GUI.
Планируете ли выложить в open source?
При развёртывании Deployment, StatefulSet и подобных ресурсов "автоматом" создаём для них VPA-ресурс в режиме рекомендаций. Для удобной визуализации разработали GUI.
Планируете ли выложить в open source?
Через DaemonSet запускаем Core Dump Handler на всех нодах. Он собирает дампы и закидывает их в S3-хранилище, а триггер уведомляет об этом эксплуатацию. Его мы немного пропатчили.
Пишут что в https://launchpad.net/ubuntu/+source/linux/6.2.0-25.25 это исправлено: "drm/amdgpu: Fix desktop freezed after gpu-reset". Я как выставил параметры ядра в Grub, так и не убирал их, поэтому не знаю исправили ли они проблему или нет.
А можете подробнее рассказать про "Этот плагин обнаруживает проблемы и потенциальные уязвимости в вашем конфигурационном файле Kubernetes и предлагает рекомендации по исправлению." у kubepug?
В первом раунде Miami и Victoria Metrics работали с одинаковой нагрузкой и на одном и том же оборудовании. Контрольными результатами были следующие:
VictoriaMetrics использует на 1,7 процессора меньше при той же рабочей нагрузке;
VictoriaMetrics использует в 5 раз меньше оперативной памяти для того же количества активных серий;
VictoriaMetrics использует в 3 раза меньше места для хранения данных, собранных в течение 24 часов во время тестирования.
Во втором раунде нагрузка была увеличена в 5 раз с использованием того же оборудования. У Mimir было недостаточно ресурсов, чтобы справиться с нагрузкой, поэтому была доступна только статистика VictoriaMetrics.
Подскажите, какая главная причина большого количества логов? Сколько по времени вы храните логи? Используете ли APM? Строите ли метрики на основе логов?
Продолжая подход Service Mesh, для сборки логов (Fluentbit) и метрик можно установить на инстанс приложения агент мониторинга (Telegraf, Node Exporter и другие).
Pulumi
Собираем образ с помощью packer, проставляем метаданные в зависимости от приложения
У Ansible, Puppet, Chef, Saltstack нет state, а у terraform есть. Но в пункте ничего про terraform не написано.
Наоборот. Ansible, Puppet, Chef, Saltstack это инструменты для mutable инфраструктуры. Они подключаются к серверу и настраивают его.
Только в связке с packer это инструменты immutable инфраструктуры. Но в этом пункте вы это не упомянули.
Наоборот, более быстрый деплой по сравнению с Mutable инфраструктурой. Вы просто указываете новый образ, в котором уже был деплой приложений и библиотек когда вы его паковали, например, с помощью packer.
Если использовать практики infrastructure as a code и идемпотентность, то эти пункты можно реализовать на изменяемой инфраструктуре.
Вы это можете делать и с изменяемой инфраструктурой.
Отсутствие документации версий инфраструктуры, трудно отследить проблемы, которые могли возникнуть из-за выкатки новой версии.
Это применимо как изменяемой так и к неизменяемой инфраструктуре.
Спасибо за пост. Как связано понимание этих концепции и что любой инструмент может перестать быть опенсорсом? Скорее эти фразу стоило разделить на 2 предложения.
Спасибо за интересный пост.
Не делали issue?
Планируете ли выложить в open source?
Планируете ли выложить в open source?
Планируете ли отправить PR с исправлением?
В https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5 и в https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13 можно найти коммит с названием "drm/amdgpu: Fix desktop freezed after gpu-reset"
Пишут что в https://launchpad.net/ubuntu/+source/linux/6.2.0-25.25 это исправлено: "drm/amdgpu: Fix desktop freezed after gpu-reset". Я как выставил параметры ядра в Grub, так и не убирал их, поэтому не знаю исправили ли они проблему или нет.
Попробуйте добавить
amdgpu.dcdebugmask=0x10in/etc/default/grub:Возможно вам помогут другие параметры ядра. Мои параметры:
Обсуждение issue здесь: https://gitlab.freedesktop.org/drm/amd/-/issues/2443
Исправлено в Linux Kernel 6.5-rc1
А можете подробнее рассказать про "Этот плагин обнаруживает проблемы и потенциальные уязвимости в вашем конфигурационном файле Kubernetes и предлагает рекомендации по исправлению." у kubepug?
Я не нашел этого у них https://github.com/rikatz/kubepug
Да, вы правы. Kubernetes auth позволяет использовать short-lived token, что выглядит безопаснее. Мое мнение что app-role проще, чем Kubernetes auth.
В pod можно использовать секрет вот так
Источник примера https://kubernetes.io/docs/concepts/configuration/secret/
Есть сравнение Mimir и Victoriametrics - https://victoriametrics.com/blog/mimir-benchmark/
Резюме
В этом бенчмарке было два раунда тестов.
В первом раунде Miami и Victoria Metrics работали с одинаковой нагрузкой и на одном и том же оборудовании. Контрольными результатами были следующие:
VictoriaMetrics использует на 1,7 процессора меньше при той же рабочей нагрузке;
VictoriaMetrics использует в 5 раз меньше оперативной памяти для того же количества активных серий;
VictoriaMetrics использует в 3 раза меньше места для хранения данных, собранных в течение 24 часов во время тестирования.
Во втором раунде нагрузка была увеличена в 5 раз с использованием того же оборудования. У Mimir было недостаточно ресурсов, чтобы справиться с нагрузкой, поэтому была доступна только статистика VictoriaMetrics.
Вышел первый релиз VictoriaLogs - https://github.com/VictoriaMetrics/VictoriaMetrics/releases/tag/v0.1.0-victorialogs
Docs: https://docs.victoriametrics.com/VictoriaLogs/
Helm Chart: https://github.com/VictoriaMetrics/helm-charts/tree/master/charts/victoria-logs-single
Так же подготовили Benchmark for VictoriaLogs, взять можно из https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/deployment/logs-benchmark
Bug report + feature request ждём в https://github.com/VictoriaMetrics/VictoriaMetrics/issues/new
Спасибо за пост. Жаль, что в статье довольно мало технических деталей.