Forwarded from DevOps
⚡️ Kubernetes Namespaces: базовое разделение ресурсов в кластере
Namespaces в Kubernetes используются для логического разбиения кластера и изоляции ресурсов между командами, проектами и средами.
Что такое Namespaces
- Представляют собой «виртуальные кластеры» внутри одного физического.
- Группируют Pods, Services, Deployments, ConfigMaps и другие объекты.
- Полезны для multi-team, multi-project и multi-environment конфигураций.
Зачем они нужны
- Упорядочивают ресурсы и уменьшают хаос в большом кластере.
- Исключают конфликты имён — одинаковые ресурсы могут существовать в разных пространствах.
- Обеспечивают изоляцию команд и повышают безопасность.
- Позволяют держать dev/staging/prod в одном кластере без пересечений.
Стандартные Namespaces
- default — используется, если не указан другой; размещает обычные рабочие нагрузки.
- kube-system — системные компоненты (CoreDNS, kube-proxy).
- kube-public — доступен всем, включая неаутентифицированных пользователей; хранит публичную информацию.
- kube-node-lease — хранит heartbeat-объекты для узлов, повышая производительность контроля состояния.
Работа с Namespaces
- Создание — через YAML или
- Переключение контекста — позволяет работать в нужном namespace без постоянного указания
- Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.
Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.
Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.
Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.
Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в
- Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.
📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls
Namespaces в Kubernetes используются для логического разбиения кластера и изоляции ресурсов между командами, проектами и средами.
Что такое Namespaces
- Представляют собой «виртуальные кластеры» внутри одного физического.
- Группируют Pods, Services, Deployments, ConfigMaps и другие объекты.
- Полезны для multi-team, multi-project и multi-environment конфигураций.
Зачем они нужны
- Упорядочивают ресурсы и уменьшают хаос в большом кластере.
- Исключают конфликты имён — одинаковые ресурсы могут существовать в разных пространствах.
- Обеспечивают изоляцию команд и повышают безопасность.
- Позволяют держать dev/staging/prod в одном кластере без пересечений.
Стандартные Namespaces
- default — используется, если не указан другой; размещает обычные рабочие нагрузки.
- kube-system — системные компоненты (CoreDNS, kube-proxy).
- kube-public — доступен всем, включая неаутентифицированных пользователей; хранит публичную информацию.
- kube-node-lease — хранит heartbeat-объекты для узлов, повышая производительность контроля состояния.
Работа с Namespaces
- Создание — через YAML или
kubectl, используется для группировки и изоляции ресурсов. - Переключение контекста — позволяет работать в нужном namespace без постоянного указания
-n. - Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.
Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.
Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.
Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.
Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в
kube-system. - Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.
📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls
👎7👍2❤1
Forwarded from Мониторим ИТ
Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
👍7🔥2❤1👎1
🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных
🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);
Запуск через Docker:
📌 GitHub
🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);
Запуск через Docker:
docker run -d
--name postgresus
-p 4005:4005
-v ./postgresus-data:/postgresus-data
--restart unless-stopped
rostislavdugin/postgresus:latest
📌 GitHub
👍10🔥1
Forwarded from linkmeup
Екатерина Истошина из Т-Банка и её история о том, как за год дежурные команды перешли от нервного тика и бесконечных инциндентов к контролю хаоса. Причём всё в цифрах, с конкретными тулами и без воды.
https://youtu.be/ccTMT2zgBtg
https://youtu.be/ccTMT2zgBtg
YouTube
Безнадежная надежность. Истошина Екатерина. Т-Банк
Год назад наши дежурные команды днем и ночью героически тушили бесконечные инциденты, ребята боялись дежурств, выгорали.
Расскажу о том, что нам помогло за год перейти от хаоса к контролю: инструменты и процессы, провалы и победы.
Цифры, инсайты и готовые…
Расскажу о том, что нам помогло за год перейти от хаоса к контролю: инструменты и процессы, провалы и победы.
Цифры, инсайты и готовые…
Forwarded from DevOps
Что умеет:
- следит за локальными и удалёнными Docker-хостами в одном окне
- умно перезапускает контейнеры с настраиваемой логикой повторов
- шлёт алерты в Telegram, Slack, Discord, Gotify и почту
- обновляет контейнеры по расписанию
- позволяет разворачивать Docker Run и Compose-пресеты прямо из UI
- показывает health-чеки и события в реальном времени
Github: https://github.com/darthnorse/dockmon
@pythonl
Please open Telegram to view this post
VIEW IN TELEGRAM
👎6👍2
Forwarded from Находки в опенсорсе
git-lfs: храним большие файлы в репозитории правильно
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо). Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
YouTube
Находки в опенсорсе: git-lfs, не засоряй репозиторий большими файлами зря! #git
GigaCode – AI-ассистент разработчика c агентным режимом. Это полноценный помощник разработчика, способный понимать контекст проекта и выполнять задачи от анализа до готового решения. Ассистент сам открывает нужные файлы, вносит изменения, запускает тесты…
🔥3👍1
Forwarded from The After Times
Кроме воровства мемов я ещё иногда занимаюсь айти. Со временем эта история переросла в собственную книгу. Релиз во второй половине января.
Проверить доступность можно по ссылке
Проверить доступность можно по ссылке
👍8👎2
InfraDev Community приглашает на Cloud Fail ((Over)): специальный новогодний выпуск InfraDev Meetup.
Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом.
Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются.
Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.
Подробнее о докладах читайте на странице мероприятия.
Когда: 18 декабря, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом.
Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются.
Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.
Подробнее о докладах читайте на странице мероприятия.
Когда: 18 декабря, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
👎2❤1👍1🔥1
Forwarded from Кубернетичек
https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs/
Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта cpu weight для cgroupv2, которую хотят дополнительно разжевать https://github.com/kubernetes/website/pull/52793/files.
Но есть нюанс (не в претензию к статье, она отличная)
Это не совсем так. cpu manager обеспечивает изоляцию только между pod'ами kubernetes, а не между всеми процессами в ОС. Служебные процессы могут и будут селиться на данные cpu.
https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy
Вообще непонятно, зачем так сложно писать в доке. Я сам пропустил это, пока на практике не столкнулся, что "эксклюзивность" не эксклюзивная в рамках всей ноды. И даже не всех контейнеров, а только которые контролирует kubernetes. Лишь когда перечитывал доку с какого-то раза, обратил внимание на shared pool.
У Datadog это упомянули, кстати, тоже можно почитать, но на мой вкус она не так интересно читается https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/
Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта cpu weight для cgroupv2, которую хотят дополнительно разжевать https://github.com/kubernetes/website/pull/52793/files.
Но есть нюанс (не в претензию к статье, она отличная)
What's this static policy about?
With static, Kubernetes can give certain containers exclusive access to CPU cores ... Nothing else would be allowed to run on those cores. That's really useful for apps that don't play well with CPU sharing or need strong cache locality
Это не совсем так. cpu manager обеспечивает изоляцию только между pod'ами kubernetes, а не между всеми процессами в ОС. Служебные процессы могут и будут селиться на данные cpu.
https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy
This policy manages a shared pool of CPUs that initially contains all CPUs in the node.... This
shared pool is the set of CPUs on which any containers in BestEffort and Burstable pods run. Containers in Guaranteed pods with fractional CPU requests also run on CPUs in the shared pool.
Вообще непонятно, зачем так сложно писать в доке. Я сам пропустил это, пока на практике не столкнулся, что "эксклюзивность" не эксклюзивная в рамках всей ноды. И даже не всех контейнеров, а только которые контролирует kubernetes. Лишь когда перечитывал доку с какого-то раза, обратил внимание на shared pool.
У Datadog это упомянули, кстати, тоже можно почитать, но на мой вкус она не так интересно читается https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/
VictoriaMetrics
Container CPU Requests & Limits Explained with GOMAXPROCS Tuning
When running Go apps in Kubernetes, default CPU thread scheduling can conflict with cgroup CPU limits. The runtime sees all host CPUs, but the container may only be allowed a fraction of one. This often leads to early throttling. Properly configuring GOMAXPROCS…
❤2👍2👎1
Forwarded from Kubernetes и кот Лихачева
Как и зачем мониторить внешний трафик в K8s 🥵 ?
Обычно внешний трафик зашифрован, и сложно понимать, что происходит внутри
Как? Ответ —
Но что делать с сертификатами? Смотрим дальше↘️
Для рецепта нам понадобится ещё и
☝️ Disclaimer: пример является упрощённым и не учитывает все возможные детали, а скорее является идеей, как вы можете реализовать подобное у себя
Итак, у нас есть внешний сервис, взаимодействия с которым мы хотим отслеживать, и работает он только по
🔸 сначала его опишем, чтобы
Создадим свой доверенный
🔸
🔸 дальше
🔸 и
🔸 создадим ещё сам сертификат на целевой хост:
Дальше используем в
Теперь нужно заставить приложения доверять сертификату. Для этого нужно будет в сервисы добавить этот
Например, в файл
Например:
Как это делать для каждого конкретного сервиса — каждый решает сам. Базово можно скриптом пробежаться по нужным репозиториям и в
И когда это будет сделано и сервисы задеплоены, опишем
И
В итоге получим метрики общения с внешней системой без дополнительной инструментации сервисов👍
Конечно же Istio может помимо этого добавить больше интересных механик:
Обычно внешний трафик зашифрован, и сложно понимать, что происходит внутри
HTTPS-соединений. Инструментировать все сервисы нормальной телеметрией может быть долго и накладно, а видеть внешние зависимости хочется...Как? Ответ —
IstioНо что делать с сертификатами? Смотрим дальше
Для рецепта нам понадобится ещё и
cert-manager, установленный в кластерИтак, у нас есть внешний сервис, взаимодействия с которым мы хотим отслеживать, и работает он только по
HTTPS🔸 сначала его опишем, чтобы
Istio знал про него:apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: example.com
namespace: istio-system
spec:
hosts:
- example.com
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS
Создадим свой доверенный
certificate authority🔸
ClusterIssuer для подписи:apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: selfsigned
spec:
selfSigned: {}
🔸 дальше
certificate с isCA=trueapiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ca
namespace: cert-manager
spec:
isCA: true
commonName: ca
secretName: ca-secret
duration: 175200h
privateKey:
algorithm: RSA
size: 2048
issuerRef:
name: selfsigned
kind: ClusterIssuer
group: cert-manager.io
🔸 и
ClusterIssuer для выдачи сертификатов уже на целевые хосты:apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: server-issuer
spec:
ca:
secretName: ca-secret
🔸 создадим ещё сам сертификат на целевой хост:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: egress-server-cert
namespace: istio-egress
spec:
commonName: egress-server-cert
secretName: egress-server-cert-secret
duration: 8760h
privateKey:
algorithm: RSA
size: 2048
dnsNames:
- example.com
issuerRef:
name: server-issuer
kind: ClusterIssuer
group: cert-manager.io
Дальше используем в
egress gateway:apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: gateway
namespace: istio-egress
spec:
selector:
app: istio-egressgateway
istio: egressgateway
servers:
- hosts:
- '*'
port:
name: https-port
number: 443
protocol: HTTPS
tls:
credentialName: egress-server-cert-secret # здесь будет сертификат для tls
mode: SIMPLE
Теперь нужно заставить приложения доверять сертификату. Для этого нужно будет в сервисы добавить этот
CA как доверенныйНапример, в файл
/etc/ssl/certs/ca-certificates.crtНапример:
RUN curl 'https://my.internal.storage/CA.crt' -o '/usr/local/share/ca-certificates/CA.crt'
RUN /usr/sbin/update-ca-certificates
Как это делать для каждого конкретного сервиса — каждый решает сам. Базово можно скриптом пробежаться по нужным репозиториям и в
Dockerfile добавить скачивание нужного CAИ когда это будет сделано и сервисы задеплоены, опишем
VirtualService, чтобы ходить на внешний хост через egress gateway:apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: example.com
namespace: default
spec:
hosts:
- example.com
tls:
- match:
- port: 443
sniHosts:
- example.com
route:
- destination:
host: istio-egressgateway.istio-egress.svc.cluster.local
И
DestinationRule не забыть описать:apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: example.com
namespace: istio-system
spec:
host: example.com
trafficPolicy:
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE
В итоге получим метрики общения с внешней системой без дополнительной инструментации сервисов
Конечно же Istio может помимо этого добавить больше интересных механик:
retry, circuit breaker, rate limiter и так далееPlease open Telegram to view this post
VIEW IN TELEGRAM
👍1
Telco Cloud: дискуссия об облачной инфраструктуре, которая отвечает строгим требованиям телекоммуникационного сектора.
Компания «Инфосистемы Джет» приглашает на дискуссию о Telco Cloud — облачной платформе, созданной по стандартам телеком-индустрии. Эти отработанные технологии могут использоваться не только для операторов, но и для других отраслей: финтеха, ритейла, логистики и промышленности.
На дискуссии эксперты обсудят:
• Технологические особенности телеком-облака, которые отличают его от частных облаков;
• Use-cases на базе Telco Cloud: IoT, Edge Computing, AI/ML, Private 5G и SD-WAN;
• Применимость архитектурные паттернов телекома для задач из других отраслей;
• «Идеальное облако» по мнению экспертов и различные подходы.
Мероприятие будет полезно техническим директорам, руководителям ИТ-отделов и бизнес-направлений, архитекторам облачных платформ, а также DevOps-инженерам.
Записаться на дискуссию можно по ссылке.
Компания «Инфосистемы Джет» приглашает на дискуссию о Telco Cloud — облачной платформе, созданной по стандартам телеком-индустрии. Эти отработанные технологии могут использоваться не только для операторов, но и для других отраслей: финтеха, ритейла, логистики и промышленности.
На дискуссии эксперты обсудят:
• Технологические особенности телеком-облака, которые отличают его от частных облаков;
• Use-cases на базе Telco Cloud: IoT, Edge Computing, AI/ML, Private 5G и SD-WAN;
• Применимость архитектурные паттернов телекома для задач из других отраслей;
• «Идеальное облако» по мнению экспертов и различные подходы.
Мероприятие будет полезно техническим директорам, руководителям ИТ-отделов и бизнес-направлений, архитекторам облачных платформ, а также DevOps-инженерам.
Записаться на дискуссию можно по ссылке.
👎1
Forwarded from лес, горы и кубернетис
CF снова пал. Не хотел бы я быть тем инженером что за него отвечает
👍8🔥3
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency. Пост №18. Golang sync.Mutex internals
В прошлом посте мы решали практическую задачку и использовали язык Go. Его основная особенность - наличие собственного рантайма в рамках которого происходит управление и планирование горутин - потоков исполнения не связанных явно 1к1 с потоками ОС.
А если у языка собственный рантайм и "собственные" потоки, то и должны быть "собственные" примитивы синхронизации, умеющие работать с горутинами. И они действительно есть. Основным примитивом синхронизации в Go является
У ребят из VictoriaMetrics получился великолепный разбор внутреннего устройства
Поэтому советую освежить в памяти предыдущие посты цикла. Увидите, что многие идеи и оптимизации придуманные для ОС были использованы в рантайме Go. Уровень абстракции выше, а проблемы и вызовы такие же😊
Внутри вас ждёт:
- Внутреннее представление
- Как выглядят
- Как
- Как происходит
https://victoriametrics.com/blog/go-sync-mutex/
-----
Если вам понравился пост, поддержите его реакциями и комментариями. Мне важно увидеть вашу обратную связь. Спасибо!
P.S. Следующая публикация вероятнее всего будет на Хабре, выпуск намечен на следующую неделю. Будем как в прошлый раз писать свои велосипеды в погоне повторить эталонные реализации, оценивать результаты бенчмарками и профилями😊
В прошлом посте мы решали практическую задачку и использовали язык Go. Его основная особенность - наличие собственного рантайма в рамках которого происходит управление и планирование горутин - потоков исполнения не связанных явно 1к1 с потоками ОС.
А если у языка собственный рантайм и "собственные" потоки, то и должны быть "собственные" примитивы синхронизации, умеющие работать с горутинами. И они действительно есть. Основным примитивом синхронизации в Go является
sync.Mutex.У ребят из VictoriaMetrics получился великолепный разбор внутреннего устройства
sync.Mutex c красивыми иллюстрациями и кодом. Я бы не смог рассказать лучше, а пересказывать копируя материал не хочется. Тем более, что многие приемы и детали упоминал ранее, только в контексте POSIX. Поэтому советую освежить в памяти предыдущие посты цикла. Увидите, что многие идеи и оптимизации придуманные для ОС были использованы в рантайме Go. Уровень абстракции выше, а проблемы и вызовы такие же😊
Внутри вас ждёт:
- Внутреннее представление
sync.Mutex.- Как выглядят
Fast path и Slow path в sync.Mutex (в том числе в ассемблере).- Как
sync.Mutex пытается обеспечить справедливость и избегать голодания.- Как происходит
Unlock.https://victoriametrics.com/blog/go-sync-mutex/
-----
Если вам понравился пост, поддержите его реакциями и комментариями. Мне важно увидеть вашу обратную связь. Спасибо!
P.S. Следующая публикация вероятнее всего будет на Хабре, выпуск намечен на следующую неделю. Будем как в прошлый раз писать свои велосипеды в погоне повторить эталонные реализации, оценивать результаты бенчмарками и профилями😊
VictoriaMetrics
Go sync.Mutex: Normal and Starvation Mode
Mutex in Go has two main flows: Lock and Unlock and 2 modes: Normal and Starvation Mode. The state field of mutex is a 32-bit integer that represents the current state, it’s divided into multiple bits that encode various pieces of information about the mutex.
🔥2👍1
Forwarded from Технологический Болт Генона
Cloudflare выложили разбор вчерашнего инцидента
Cloudflare outage on December 5, 2025
https://blog.cloudflare.com/5-december-2025-outage/
Попробую кратко описать чо там у них случилось, если где-то неправильно понял, то поправьте в комментариях
Как и писал CTO (https://xn--r1a.website/tech_b0lt_Genona/5926), они катили изменения для того, что бы закрыть свежую и нашумевшую уязвимость React'а (https://xn--r1a.website/tech_b0lt_Genona/5918, https://xn--r1a.website/tech_b0lt_Genona/5923)
Для этого они провели два действия:
- Они обнаружили что балалайка, котрая тестирует их WAF не поддерживает нужный размер буфера тела HTTP-запроса, поэтому они её отключили (нужен был 1 MB, а умела только 128 KB)
- Выкатили практически моментально на все сервера изменения. Если я понял правильно, то они так настроили/сделали систему конфигурации после прошлого отвала - https://xn--r1a.website/tech_b0lt_Genona/5885
Как и в прошлый раз, сейчас тоже упоминаются две реализации их прокси - FL1 (старая, я не помню на чём, но там есть Lua) и FL2 (новая на Rust)
FL1 стало плохо после отключения балалайки, которая тестировала WAF и его правила, и начала "пятисотить". Происходило это из-за того, что поломался кусок, который отвечал за правила (Lua часть)
И это объясняет почему у части работало всё нормально, а у части нет. Проблем не было у тех чей трафик шёл через FL2
> Customers that have their web assets served by our older FL1 proxy AND had the Cloudflare Managed Ruleset deployed were impacted
> Customers that did not have the configuration above applied were not impacted. Customer traffic served by our China network was also not impacted.
Когда CF увидели, что всё посыпалось, то вообще должна была отработать система "отката". Но что-то пошло не так 🌝
Правила, когда отрабатывают, то выполняются определённые действия (в том числе и к трафику)
> Typical actions are “block”, “log”, or “skip”. Another type of action is “execute”, which is used to trigger evaluation of another ruleset.
Но как выяснилось они никогда не откатывали аварийно правила с типом execute и при откате сломавшего всё нового правила возникла ошибка в логике
> This code expects that, if the ruleset has action=”execute”, the “rule_result.execute” object will exist. However, because the rule had been skipped, the rule_result.execute object did not exist, and Lua returned an error due to attempting to look up a value in a nil value.
В FL2 проблемы не существовало такой, потому что, цитирую
> This is a straightforward error in the code, which had existed undetected for many years. This type of code error is prevented by languages with strong type systems.
Как утверждается в посте, что они извлекли уроки от прошлого масштабного падения и начали вносить изменения, но не успели за две недели доделать.
Короче, растпобеда случилась 🗿
Cloudflare outage on December 5, 2025
https://blog.cloudflare.com/5-december-2025-outage/
Попробую кратко описать чо там у них случилось, если где-то неправильно понял, то поправьте в комментариях
Как и писал CTO (https://xn--r1a.website/tech_b0lt_Genona/5926), они катили изменения для того, что бы закрыть свежую и нашумевшую уязвимость React'а (https://xn--r1a.website/tech_b0lt_Genona/5918, https://xn--r1a.website/tech_b0lt_Genona/5923)
Для этого они провели два действия:
- Они обнаружили что балалайка, котрая тестирует их WAF не поддерживает нужный размер буфера тела HTTP-запроса, поэтому они её отключили (нужен был 1 MB, а умела только 128 KB)
- Выкатили практически моментально на все сервера изменения. Если я понял правильно, то они так настроили/сделали систему конфигурации после прошлого отвала - https://xn--r1a.website/tech_b0lt_Genona/5885
Как и в прошлый раз, сейчас тоже упоминаются две реализации их прокси - FL1 (старая, я не помню на чём, но там есть Lua) и FL2 (новая на Rust)
FL1 стало плохо после отключения балалайки, которая тестировала WAF и его правила, и начала "пятисотить". Происходило это из-за того, что поломался кусок, который отвечал за правила (Lua часть)
[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)
И это объясняет почему у части работало всё нормально, а у части нет. Проблем не было у тех чей трафик шёл через FL2
> Customers that have their web assets served by our older FL1 proxy AND had the Cloudflare Managed Ruleset deployed were impacted
> Customers that did not have the configuration above applied were not impacted. Customer traffic served by our China network was also not impacted.
Когда CF увидели, что всё посыпалось, то вообще должна была отработать система "отката". Но что-то пошло не так 🌝
Правила, когда отрабатывают, то выполняются определённые действия (в том числе и к трафику)
> Typical actions are “block”, “log”, or “skip”. Another type of action is “execute”, which is used to trigger evaluation of another ruleset.
Но как выяснилось они никогда не откатывали аварийно правила с типом execute и при откате сломавшего всё нового правила возникла ошибка в логике
if rule_result.action == "execute" then
rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end
> This code expects that, if the ruleset has action=”execute”, the “rule_result.execute” object will exist. However, because the rule had been skipped, the rule_result.execute object did not exist, and Lua returned an error due to attempting to look up a value in a nil value.
В FL2 проблемы не существовало такой, потому что, цитирую
> This is a straightforward error in the code, which had existed undetected for many years. This type of code error is prevented by languages with strong type systems.
Как утверждается в посте, что они извлекли уроки от прошлого масштабного падения и начали вносить изменения, но не успели за две недели доделать.
Короче, растпобеда случилась 🗿
🔥7
Forwarded from DevOps&SRE Library
Container CPU Requests & Limits Explained with GOMAXPROCS Tuning
https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs
In this article, we’re going to cover a few things that might’ve puzzled you if you’ve been running your applications, especially Go applications, in Kubernetes:
- How Kubernetes and the Linux kernel handle CPU stuff for containers
- What the Go runtime does with CPU, and whether you should bother setting GOMAXPROCS
- Which metrics are actually worth paying attention to
Maybe you’ve seen some of these metrics before while keeping an eye on your applications, but didn’t fully know what to make of them. This should help clear that up.
https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs
👍1
Forwarded from /usr/bin
zerobyte
Zerobyte — это инструмент автоматизации резервного копирования, который помогает сохранять данные в нескольких хранилищах. Он создан на основе Restic и имеет веб-интерфейс для планирования, управления и мониторинга зашифрованного резервного копирования вашего удаленного хранилища.
Репыч на Гитхаб
Zerobyte — это инструмент автоматизации резервного копирования, который помогает сохранять данные в нескольких хранилищах. Он создан на основе Restic и имеет веб-интерфейс для планирования, управления и мониторинга зашифрованного резервного копирования вашего удаленного хранилища.
Репыч на Гитхаб
🔥3
Forwarded from /usr/bin
Балансировка нагрузки: проблемы, решения, практические рекомендации
В этой статье на Хабре разобрана матчасть по возможным вариантам балансировки нагрузки.
@usr_bin_linux
Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.
Но это не тупая раздача запросов по очереди. Хороший балансировщик — это мозг. Он должен чувствовать пульс системы: какой сервер отвечает быстро, а какой начал тормозить. Он должен понимать, что запросы одного пользователя лучше отправлять в одно и то же место. Ошибка в этой логике — и вся система превращается в хаос из ошибок и потерянных сессий.
В этой статье на Хабре разобрана матчасть по возможным вариантам балансировки нагрузки.
@usr_bin_linux
Forwarded from DevOps
Кэширование хранит часто используемые данные в быстром слое, обычно в памяти.
Это снижает нагрузку на базу данных и ускоряет ответы системы.
Один из самых эффективных способов улучшить производительность, масштабируемость и сократить расходы.
ПОЧЕМУ КЭШИРОВАНИЕ ВАЖНО
Экономит запросы к базе
Уменьшает задержку
Справляется с высоким количеством чтений
Укрепляет стабильность при нагрузках
Снижает стоимость инфраструктуры
1) CLIENT-SIDE CACHING
Хранение данных в браузере пользователя.
Используются cookies, localStorage, service workers.
Меньше повторных загрузок статических ресурсов.
2) CDN CACHING
Статические файлы лежат на глобальных edge-серверах.
CSS, JS, изображения, видео, шрифты.
Меньше задержка у глобальных пользователей и разгрузка основного сервера.
3) APPLICATION-LEVEL CACHING
Кэш внутри приложения.
Например, структуры в памяти вроде LRU cache.
Очень быстро, но работает в рамках одного сервера.
4) DISTRIBUTED CACHING
Общий кэш для множества серверов.
Инструменты: Redis, Memcached.
Подходит для горизонтального масштабирования и устраняет дублирование кэша.
5) DATABASE QUERY CACHING
Базы хранят результаты частых запросов.
MySQL Query Cache, Postgres внутренний кэш, MongoDB WiredTiger.
Ускоряет повторные чтения.
6) WRITE-BEHIND
Запись идет в кэш, а в базу — асинхронно.
Снижает задержку записи.
Подходит для систем с высокой нагрузкой на запись.
7) WRITE-THROUGH
Записи попадают в кэш и базу одновременно.
Гарантирует консистентность.
Немного медленнее из-за двойной записи.
8) CACHE-ASIDE
Приложение сначала проверяет кэш.
Если промах — идет в базу, затем помещает результат в кэш.
Гибкий и самый популярный вариант.
9) READ-THROUGH
Приложение всегда читает из кэша.
При промахе сам кэш получает данные из базы.
Кэш всегда остается обновленным.
10) TTL И ПОЛИТИКИ ИСТЕЧЕНИЯ
Каждая запись имеет срок жизни.
TTL, LRU, LFU, FIFO — разные режимы очистки данных.
11) INVALDATION
Ручное удаление ключей, удаление по шаблону, автоматическое истечение по TTL или лимиту памяти.
12) MULTI-LAYERED CACHING
Несколько уровней сразу: браузер, CDN, распределенный кэш, кэш приложения.
Полезно для глобальных систем с большим трафиком.
Совет
Кэширование помогает добиться высокой скорости, низкой нагрузки на базу и хорошей масштабируемости.
Стратегию нужно подбирать исходя из размеров системы, интенсивности запросов и требований к консистентности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1