Forwarded from DevOps
🎯 Хитрый Kubernetes-совет: используй "Ephemeral Containers" для дебага продовых Pod-ов без рестартов
Обычно, если приложение в Pod’e зависло или ведёт себя странно, — запускают
Но если контейнер крашится на старте или застрял в init-контейнере,
💡 Решение: Ephemeral Containers
Это временный контейнер, который можно «вживить» в работающий Pod без его пересоздания.
Использование:
Что это даёт:
- можно зайти в Pod, даже если основной контейнер не запускается
- можно использовать инструменты, которых нет в образе (curl, tcpdump, bash)
- можно дебажить сеть, файловую систему, процессы, не ломая Pod
- идеальный способ разбирать живые инциденты в проде
Эта техника - спасение, когда логов мало, Pod не рестартится, а exec недоступен.
Обычно, если приложение в Pod’e зависло или ведёт себя странно, — запускают
kubectl exec. Но если контейнер крашится на старте или застрял в init-контейнере,
exec уже не поможет.💡 Решение: Ephemeral Containers
Это временный контейнер, который можно «вживить» в работающий Pod без его пересоздания.
Использование:
kubectl debug pod/<имя> -it --image=busybox
Что это даёт:
- можно зайти в Pod, даже если основной контейнер не запускается
- можно использовать инструменты, которых нет в образе (curl, tcpdump, bash)
- можно дебажить сеть, файловую систему, процессы, не ломая Pod
- идеальный способ разбирать живые инциденты в проде
Эта техника - спасение, когда логов мало, Pod не рестартится, а exec недоступен.
🔥26
Forwarded from /usr/bin
Ключевые различия между Docker и Containerd
Будучи основным компонентом Docker, Containerd стал популярным решением для контейнеризации, постепенно заменяя Docker в архитектуре Kubernetes. Эта статья прольет свет на различия между Docker и Containerd, что позволит лучше понять технологию контейнеризации.
Будучи основным компонентом Docker, Containerd стал популярным решением для контейнеризации, постепенно заменяя Docker в архитектуре Kubernetes. Эта статья прольет свет на различия между Docker и Containerd, что позволит лучше понять технологию контейнеризации.
Teletype
Ключевые различия между Docker и Containerd
Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.
🔥2
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency. Пост №17. Введение в взаимную блокировку (deadlock). Решаем задачу об обедающих философах на Go.
Пора перейти от уровня ОС и низкоуровневых примитивов поближе к реальным задачам и челленджам. Сегодня нестареющая классика - задача о философах.
Задача: разработать алгоритм, при котором ни один из философов не будет голодать, то есть будет вечно чередовать приём пищи и размышления.
🔵 Наивная реализация
Предлагаю сначала ничего не выдумывать, а просто закодировать то что первым приходит в голову.
Go Playground
Не самый сложный код. Но есть загвоздка - он неправильный. Вилок столько же сколько и философов и когда каждый хватает левую то на столе не остается вилок. Программа зависла навсегда. Конец. У этой проблемы даже есть название - взаимная блокировка.
Попробуем не вникая в глубокие теоретические рассуждения и алгоритмы решить задачу так как бы мы ее решали в реальной жизни.
🔵 Просим философов быть менее предсказуемыми
Чтобы устранить голодовую смерть можно изменить порядок взятия вилок со стола. Но не для всех философов одновременно, а например для одного. Этого будет достаточно.
Полный код: Go Playground
🔵Добавляем официанта
Вместо того чтобы вносить хак в программу и делать поведение участников непохожим на остальных можно добавить помощника - официанта.
Это классический пример синхронизации через семафор. Каждый философ перед тем как хвататься за вилки просит разрешения у официанта. Если он принял запрос, значит доступ к вилкам есть у 3х или менее философов, а значит мы не попадем во взаимную блокировку.
Полный код: Go Playground
🔵 Итоги
В несколько этапов мы прошли путь от решения в лоб до двух решений:
- с хаком в коде (у него есть название, кто знает пишите в комментарии)
- c семафором.
При этом не был рассмотрен вопрос - как сделать решение справедливым, чтобы все кушали поровну? Ставьте 🔥, если увижу ваш интерес - обязательно рассмотрим и этот вопрос.
На этом всё, буду рад вашей ОС и реакциям, особенно интересно узнать был ли пост понятен без предварительной теории. Ее могло быть много, но я осознанно сфокусировался на практике😇
Пора перейти от уровня ОС и низкоуровневых примитивов поближе к реальным задачам и челленджам. Сегодня нестареющая классика - задача о философах.
Пять философов сидят вокруг круглого стола, перед каждым стоит тарелка спагетти. На столе между каждой парой ближайших философов лежит по одной вилке.
Каждый философ может либо есть, либо размышлять. Приём пищи не ограничен количеством оставшихся спагетти — подразумевается бесконечный запас. Тем не менее, философ может есть только тогда, когда держит две вилки — взятую справа и слева.
Каждый философ может взять ближайшую вилку (если она доступна) или положить — если он уже держит её. Взятие каждой вилки и возвращение её на стол являются раздельными действиями, которые должны выполняться одно за другим.
Задача: разработать алгоритм, при котором ни один из философов не будет голодать, то есть будет вечно чередовать приём пищи и размышления.
🔵 Наивная реализация
Предлагаю сначала ничего не выдумывать, а просто закодировать то что первым приходит в голову.
Go Playground
package main
import (
"fmt"
"sync"
)
func main() {
const philosophers = 5
forks := make([]sync.Mutex, philosophers)
for p := range philosophers {
go philosopher(p, &forks[p], &forks[(p+1)%philosophers])
}
quit := make(chan struct{})
<-quit
}
func philosopher(p int, left *sync.Mutex, right *sync.Mutex) {
for {
left.Lock()
right.Lock()
fmt.Println("Philosopher", p, "Eating...")
left.Unlock()
right.Unlock()
fmt.Println("Philosopher", p, "ate :)")
}
}
Не самый сложный код. Но есть загвоздка - он неправильный. Вилок столько же сколько и философов и когда каждый хватает левую то на столе не остается вилок. Программа зависла навсегда. Конец. У этой проблемы даже есть название - взаимная блокировка.
Попробуем не вникая в глубокие теоретические рассуждения и алгоритмы решить задачу так как бы мы ее решали в реальной жизни.
🔵 Просим философов быть менее предсказуемыми
Чтобы устранить голодовую смерть можно изменить порядок взятия вилок со стола. Но не для всех философов одновременно, а например для одного. Этого будет достаточно.
Полный код: Go Playground
func philosopher(p int, left *sync.Mutex, right *sync.Mutex) {
for {
if p == 4 {
right.Lock()
left.Lock()
} else {
left.Lock()
right.Lock()
}
fmt.Println("Philosopher", p, "Eating...")
time.Sleep(time.Millisecond)
left.Unlock()
right.Unlock()
fmt.Println("Philosopher", p, "ate :)")
}
}🔵Добавляем официанта
Вместо того чтобы вносить хак в программу и делать поведение участников непохожим на остальных можно добавить помощника - официанта.
Это классический пример синхронизации через семафор. Каждый философ перед тем как хвататься за вилки просит разрешения у официанта. Если он принял запрос, значит доступ к вилкам есть у 3х или менее философов, а значит мы не попадем во взаимную блокировку.
Полный код: Go Playground
steward := make(chan int, philosophers-1)
...
func philosopher(p int, left *sync.Mutex, right *sync.Mutex, steward chan int) {
for {
steward <- p
left.Lock()
right.Lock()
fmt.Println("Philosopher", p, "Eating...")
time.Sleep(time.Millisecond)
left.Unlock()
right.Unlock()
<-steward
fmt.Println("Philosopher", p, "ate :)")
}
}
🔵 Итоги
В несколько этапов мы прошли путь от решения в лоб до двух решений:
- с хаком в коде (у него есть название, кто знает пишите в комментарии)
- c семафором.
При этом не был рассмотрен вопрос - как сделать решение справедливым, чтобы все кушали поровну? Ставьте 🔥, если увижу ваш интерес - обязательно рассмотрим и этот вопрос.
На этом всё, буду рад вашей ОС и реакциям, особенно интересно узнать был ли пост понятен без предварительной теории. Ее могло быть много, но я осознанно сфокусировался на практике😇
❤4🔥2
Forwarded from PythonDigest
Как тестировать конфигурацию Nginx: корректность и информационная безопасность
https://habr.com/ru/articles/966914/
При разработке сложной системы часто приходится сталкиваться с необходимостью использования nginx в качестве reverse proxy. Один из частых сценариев использования это роутинг, список правил, регулирующих путь запроса во внутренние системы или путь между внутренними подсистемами.
https://habr.com/ru/articles/966914/
При разработке сложной системы часто приходится сталкиваться с необходимостью использования nginx в качестве reverse proxy. Один из частых сценариев использования это роутинг, список правил, регулирующих путь запроса во внутренние системы или путь между внутренними подсистемами.
Forwarded from Код и Капуста
Конструктор рейт лимитеров
Обычно рейт лимитеры состоят из кучи правил, которые нужно как-то комбинировать, и всё быстро превращается в бардак. Поэтому автор задумал сделать rate limiter, который легко собирается как конструктор.
Что значит гибкость для рейт лимитера
- Правильные примитивы - базовые кирпичики, из которых можно собрать что угодно
- Чёткая композиция - чтобы сочетания правил не ломали мозг.
Читаем, просвещаемся
#golang
https://kodikapusta.ru/news/27ld-konstruktor-reit-limiterov
Обычно рейт лимитеры состоят из кучи правил, которые нужно как-то комбинировать, и всё быстро превращается в бардак. Поэтому автор задумал сделать rate limiter, который легко собирается как конструктор.
Что значит гибкость для рейт лимитера
- Правильные примитивы - базовые кирпичики, из которых можно собрать что угодно
- Чёткая композиция - чтобы сочетания правил не ломали мозг.
Читаем, просвещаемся
#golang
https://kodikapusta.ru/news/27ld-konstruktor-reit-limiterov
Forwarded from Код и Капуста
Отладка с pprof и k6
Про pprof наверняка все знают. В статье автор еще раз показывает как им пользоваться, но прикольно что он использует k6 для нагрузки своего сервиса. k6 - это тулза от разработчиков графаны, скрипты для нагрузки можно писать на js. А для ограничения ресурсов CPU используется cgroup - это интересный подход для локального нагрузочного тестирования
#golang
https://kodikapusta.ru/news/42i9-otladka-s-pprof-i-k6
Про pprof наверняка все знают. В статье автор еще раз показывает как им пользоваться, но прикольно что он использует k6 для нагрузки своего сервиса. k6 - это тулза от разработчиков графаны, скрипты для нагрузки можно писать на js. А для ограничения ресурсов CPU используется cgroup - это интересный подход для локального нагрузочного тестирования
#golang
https://kodikapusta.ru/news/42i9-otladka-s-pprof-i-k6
Forwarded from Библиотека Go-разработчика | Golang
protoc-gen-crud — это плагин для Protocol Buffers, который генерирует интерфейсы и реализации CRUD-операций.
Он создаёт два файла для каждого proto-файла: общий файл с интерфейсами (.pb.crud.go) и файл с конкретной реализацией для выбранной базы данных.
Поддерживаются основные операции создания, чтения, обновления и удаления как для SQLite, так и для PostgreSQL. Есть возможность работать с уникальными и составными ключами, временными метками, а также частичными обновлениями.
Установка сводится к добавлению плагина в
PATH и запуску protoc с указанием параметра --go-crud_out.🔸 Алгоритмы и структуры данных
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib
#GoToProduction
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevOps Deflope News
ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.
Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.
ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.
Продукт уже работает для пользователей Kubernetes, Helm и GitOps.
Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.
Источник — пост Alexis Richardson на LinkedIn.
Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.
ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.
Продукт уже работает для пользователей Kubernetes, Helm и GitOps.
Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.
Источник — пост Alexis Richardson на LinkedIn.
Linkedin
ConfigHub is now available!
Our doors are ‘open’ and if you want to try ConfigHub then please go to www.confighub.
DevOps Deflope News
ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и…
Confighub
ConfigHub - Take Back Control of DevOps
Configuration as data lets you see what will happen before it happens. Unify and centralize software infrastructure configuration in a way that existing tools do not.
Forwarded from DevOps&SRE Library
The $1,000 AWS mistake
https://www.geocod.io/code-and-coordinates/2025-11-18-the-1000-aws-mistake
A cautionary tale about AWS VPC networking, NAT Gateways, and how a missing VPC Endpoint turned our S3 data transfers into an expensive lesson.
https://www.geocod.io/code-and-coordinates/2025-11-18-the-1000-aws-mistake
Странно, но уже несколько человек за последние несколько дней спросило меня про комментарии к постам. Добавил, посмотрим, что получится
👍2👎1
Коллеги сегодня принесли полезное https://github.com/kellyjonbrazil/jc
GitHub
GitHub - kellyjonbrazil/jc: CLI tool and python library that converts the output of popular command-line tools, file-types, and…
CLI tool and python library that converts the output of popular command-line tools, file-types, and common strings to JSON, YAML, or Dictionaries. This allows piping of output to tools like jq and ...
🔥2
Костя Крамлих рассказал как они в Яндекс Облаке сделали сеть надежнее https://habr.com/ru/companies/yandex/articles/920092/
Я от сети далек, но мне понравился подход к решению reliability проблем и, кажется, что его можно использовать примерно везде
Я от сети далек, но мне понравился подход к решению reliability проблем и, кажется, что его можно использовать примерно везде
Хабр
Что мы изменили в сети, чтобы сделать её устойчивее
Даже сложная и продуманная технологическая система не застрахована от инцидентов — это касается любых инфраструктур, от железнодорожных и коммунальных до IT. Поэтому...
🔥2👎1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
Хабр
Токены доступа и API Gateway: как обеспечить безопасность запросов
Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и...
Forwarded from Безумный кот
Прошло всего два месяца с первого релиза, и мы снова готовы показать, что удалось сделать.
Новое:
• Search — поиск ресурсов
• ResourceBadge — цветные бейджи с CamelCase
• TogglerSegmented — мульти-переключатель
• Toggler — переключатель
• OwnerRefs — список владельцев ресурса
• Events — события ресурса
• SecretBase64Plain — отображение секрета с blur
• UI переведен на list-then-watch
(* если у ресурса есть поддержка watch, будет работать по событийной модели, если нет то поллинг)
• Базовые Actions в каждой таблице
• Секреты: автоматический base64-decrypt в UI
• SBOM-отчёты Pod / RS / Deploy / STS
• YamlEditor: readOnly / watch / reload
• Default-фабрики для всех ресурсов: Details, Breadcrumbs, CustomColumnsOverride
• CustomFormPrefill для массивов объектов
• White Label: Logo, Footer, TenantText
Улучшено:
• Цветовые схемы Badges синхронизированы с поиском
• Labels теперь могут вести на внешние ссылки (в т. ч. Search)
• Убраны мерцания при переходах между страницами
• CustomFormOverride запрещает менять Namespace у уже созданных ресурсов
• Обновлена обработка x-kubernetes-preserve-unknown-fields: true — теперь такие поля открываются во встроенном VSCode-editor с возможностью редактирования
Исправлено:
• PodLogs больше не зависает при старте
Итог:
Единая модель Default Factory: базовая страница, события и консистентная навигация доступны для каждого ресурса.
Интерфейс стал стабильнее, визуальная тема — согласованнее.
Подготовлена основа для пользовательских фабрик и расширенного поиска.
Полезная информация:
- Информация
- Документация
- Демо стенд
- Исходники на GitHub
Лучшая ваша похвала — это:
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub
*демо стенд не оптимизирован под телефоны (будет, но чуть позже)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👎1
Forwarded from HABR FEED + OPENNET
Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше #habr
https://habr.com/ru/companies/flant/articles/970498/
Tags: nelm, helm, werf, open source, devops, kubernetes, cicd
Author: ilya-lesikov (Флант)
https://habr.com/ru/companies/flant/articles/970498/
Tags: nelm, helm, werf, open source, devops, kubernetes, cicd
Author: ilya-lesikov (Флант)
Хабр
Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше
Недавно вышел Helm 4, и это отличный повод снова сравнить его с нашей альтернативой — Nelm . В статье смотрим на новые возможности обоих проектов, детально разбираем их отличия и объясняем, что ждёт...
👍3
Forwarded from запуск завтра
Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?
Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.
Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.
Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.
Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.
Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.
Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.
Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
👍6
Forwarded from GitHub Open Sauce
safedep/vet
vet — это инструмент безопасности цепочки поставок программного обеспечения с открытым исходным кодом, созданный для разработчиков и специалистов по безопасности
#golag
https://github.com/safedep/vet
vet — это инструмент безопасности цепочки поставок программного обеспечения с открытым исходным кодом, созданный для разработчиков и специалистов по безопасности
#golag
https://github.com/safedep/vet
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