Всё о DevOps
Для связи - @raz_raz
Заказать рекламу через биржу: https://telega.in/c/devops_memops
Post #7860
1.38K
DE @devops_memops
Showing posts older than #7861 · Back to latest

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go.
Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел.
В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать.
Kubernetes — мощный инструмент, но устранение неполадок в живом кластере может быть мучительным. В сложном развертывании критические предупреждающие знаки часто скрываются в тысячах строк логов и событий. Что, если бы мы могли выявить эти проблемы с надежностью до того, как они приведут к остановке приложений?

Идея простая: вы описываете CRD Kroc, указываете, за какими объектами в Kubernetes нужно следить, и задаёте шаблон ресурса, который должен быть создан на основе найденного объекта.
Например, оператор может смотреть за Deployment, брать из него нужные поля и автоматически создавать связанные Pod, Service, ConfigMap или другие Kubernetes-объекты.
Внутри используется Go и Kubebuilder.
Самое интересное - реактивная модель.
Если исходный объект изменился, производные ресурсы пересоздаются.
Если кто-то вручную удалил созданный объект, оператор создаст его снова, чтобы вернуть кластер в нужное состояние.
По сути, это хороший минимальный пример того, как работает operator pattern в Kubernetes:
наблюдаем за состоянием
сравниваем с желаемым
создаём или пересоздаём ресурсы
держим систему синхронизированной
Архитектура тоже полезная для разбора: проект разделяет логику на несколько контроллеров.
Один отвечает за CRD и конфигурацию, второй наблюдает за внешними Kubernetes-объектами, третий создаёт производные ресурсы из шаблонов.
Для новичков в Kubernetes Operators это намного понятнее, чем сразу лезть в большие production-операторы.
Kroc хорошо показывает базовую механику: CRD, reconcile loop, watch, template rendering и управление жизненным циклом дочерних объектов.

В этой статье в блоге VictoriaMetrics рассказывают про путь записи логов: от приёма и преобразования в единый внутренний формат до размещения в потоках, дневных партициях и неизменяемых частях на диске и объясняют, как VictoriaLogs группирует логи по полям потока, разбивает данные на блоки и хранит каждое поле в отдельной колонке. Также разбирается назначение основных файлов внутри партиций, работа bloom-фильтров, двухуровневых индексов и механизмов слияния небольших частей в более крупные.
Главная идея архитектуры: сначала прочитать небольшой объём метаданных и исключить ненужные данные, а уже затем обращаться к конкретным блокам, колонкам и значениям. За счёт этого запросы не сканируют весь объём логов, а читают только необходимые данные.
ASMLings - это набор из ~32 коротких упражнений на ассемблере Intel 8086, выстроенных по возрастанию сложности: от mov ax, 0x1337 до 32-битного сложения через carry flag, циклов, подпрограмм, работы с памятью и стеком.
Полный русскоязычный гайд по asmlings — интерактивной песочнице для изучения ассемблера Intel 8086, в которой 16-битный x86-эмулятор написан на Rust.
Внутри: что это, как устроено под капотом, как установить, как читать и решать упражнения, разборы реальных задач из репозитория, готовые примеры в examples/ и шпаргалки.

Sveltos Addon Controller позволяет пользователям применять Kubernetes-манифесты к любым кластерам, управляемым Sveltos. Это может быть сделано следующими способами:
- Добавляя YAML-файлы с Kubernetes-ресурсами в ConfigMap или Secret.
- Указывая URL с YAML-ресурсами.
- Указывая Helm-чарт.
Addon Controller – это контроллер Kubernetes, который работает в управляющем кластере (management cluster). Он следит за созданием и обновлением объектов Addon, а также применяет соответствующие манифесты в целевых (managed) кластерах, на которые ссылается Addon.
Возможности
- Поддержка ConfigMap, Secret, URL и Helm-чартов.
- Поддержка переменных через ClusterProfile и ClusterSummary.
- Возможность динамически применять или удалять аддоны при изменении кластера или его свойств.
- Возможность настройки приоритетов применения ресурсов.
- Поддержка зависимостей между ресурсами.
- Поддержка dry-run и прерывания применения при ошибке.
Архитектура
1. Пользователь создает объект ClusterProfile, в котором указывает критерии выбора кластеров.
2. Для каждого подходящего кластера создается объект ClusterSummary, который содержит список Addon объектов.
3. Addon Controller применяет ресурсы, указанные в Addon, к каждому целевому кластеру.
- Зачем нужна блокировка состояния Terraform
- Блокировка состояния с помощью DynamoDB
- Блокировка состояния только с использованием S3, без DynamoDB
- Когда стоит использовать DynamoDB
- Когда можно обойтись только S3
- Лучшие практики хранения state-файлов в S3
Linux ядра: пространства имён, capabilities и bind mounts. Доклад "Know "Con Fu"! Container security techniques and the Canon of eBPF" разбирает эти механизмы с нуля, от базовых принципов до продвинутых техник.Linux работает под капотом. Обязательный материал для всех, кто эксплуатирует Docker или Kubernetes в продакшене.