Вопрос, который часто задают в начале собеса
Представлен вывод команды top. Что означает каждая запись в выводе?
top — 10:44:36 up 91 days, 19:29, 7 users, load average: 0,00, 0,02, 0,05
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 1,5 sy, 0,0 ni, 96,9 id, 0,0 wa, 0,0 hi, 0,0 si, 1,5 st
KiB Mem : 12137392 total, 6227844 free, 1117728 used, 4791820 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 10090148 avail Mem
top — утилита
10:44:36 — время системы
up — сколько система работает с момента последнего запуска
7 user — количество авторизованных юзеров в системе
load average: 0.00, 0.02, 0.05 — параметр средней нагрузки на систему за период времени 1 минута, 5 минут, 15 минут
156 total — всего процессов в системе
1 running — количество процессов в работе
155 sleeping — ожидание процесса или сигнала
0 stopped — количество приостановленных процессов сигналом STOP или выполнение трассировки
0 zombie — количество зомби-процессов, которые завершили своё выполнение, но присутствующие в системе, чтобы дать родительскому процессу считать свой код завершения.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Представлен вывод команды top. Что означает каждая запись в выводе?
top — 10:44:36 up 91 days, 19:29, 7 users, load average: 0,00, 0,02, 0,05
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 1,5 sy, 0,0 ni, 96,9 id, 0,0 wa, 0,0 hi, 0,0 si, 1,5 st
KiB Mem : 12137392 total, 6227844 free, 1117728 used, 4791820 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 10090148 avail Mem
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3❤2
💡 Calico Whisker — безопасные сетевые политики в Kubernetes без простоев
Работая с Kubernetes, вы наверняка сталкивались с риском простоев при внедрении сетевых политик. Ошибки в конфигурации могут случайно заблокировать легитимный трафик, а отладка таких ситуаций — сплошная головная боль.
Теперь есть решение: Calico Whisker — механизм этапных сетевых политик. Суть простая:
🔸 Вы пишете политику, но не применяете её сразу.
🔸 Система "наблюдает", какой трафик она бы заблокировала или пропустила.
🔸 Вы смотрите логи, анализируете поведение.
🔸 И только потом, когда уверены, активируете её без изменений.
Это как staging-режим, только для сетевой безопасности. Без риска. Без простоя.
Идеально для DevSecOps и всех, кто хочет внедрять Zero Trust подход аккуратно и осознанно.
https://www.tigera.io/blog/calico-whisker-staged-network-policies-secure-kubernetes-workloads-without-downtime/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Работая с Kubernetes, вы наверняка сталкивались с риском простоев при внедрении сетевых политик. Ошибки в конфигурации могут случайно заблокировать легитимный трафик, а отладка таких ситуаций — сплошная головная боль.
Теперь есть решение: Calico Whisker — механизм этапных сетевых политик. Суть простая:
🔸 Вы пишете политику, но не применяете её сразу.
🔸 Система "наблюдает", какой трафик она бы заблокировала или пропустила.
🔸 Вы смотрите логи, анализируете поведение.
🔸 И только потом, когда уверены, активируете её без изменений.
Это как staging-режим, только для сетевой безопасности. Без риска. Без простоя.
Идеально для DevSecOps и всех, кто хочет внедрять Zero Trust подход аккуратно и осознанно.
https://www.tigera.io/blog/calico-whisker-staged-network-policies-secure-kubernetes-workloads-without-downtime/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3🔥1
При переходе к продакшен-нагрузкам важно заранее продумать отказоустойчивость, сценарии переключения между узлами и поведение кластера при плановых работах и сбоях.
29 сентября эксперт Cloud․ru проведет вебинар о том, как обеспечить высокую доступность PostgreSQL в облаке.
В программе:
▶️ как устроен отказоустойчивый кластер в Evolution Managed PostgreSQL▶️ где проходит граница между высокой доступностью и аварийным восстановлением▶️ какую роль играет Multi-AZ-архитектура▶️ для каких задач используются реплики PostgreSQL▶️ как работают ручное и автоматическое переключение▶️ что важно учитывать при эксплуатации PostgreSQL в продакшене
Будет интересно всем, кто работает с PostgreSQL и отвечает за доступность баз данных и надежность инфраструктуры.
Зарегистрироваться
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Kagent + Ollama: ИИ-агент для работы с Kubernetes
Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.
1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.
На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.
После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.
Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».
👉 Регистрируйтесь: https://vk.cc/d233Rj
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.
1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.
На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.
После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.
Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».
👉 Регистрируйтесь: https://vk.cc/d233Rj
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
📣 Kubernetes Events — новостная лента вашего кластера
Kubernetes Events — это ресурсы типа Event в Kubernetes, которые информируют вас о том, что происходит в вашем кластере. Это похоже на новостную ленту для компонентов кластера: они фиксируют всё — от запуска Pod'ов до ошибок в работе контроллеров.
Каждое событие в Kubernetes содержит:
*
*
*
*
*
🔎 Как посмотреть события:
Или для конкретного Pod'а:
Kubernetes сам удаляет события через час. Это значит, что они не предназначены для долговременного хранения.
📤 Хранение событий
Если вам нужно сохранить события дольше, можно:
* Настроить аудит в Kubernetes
* Использовать внешние системы логирования (например, Elasticsearch + Fluentd)
* Подключить event exporters
https://decisivedevops.com/kubernetes-events-news-feed-of-your-kubernetes-cluster-826e08892d7a/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Kubernetes Events — это ресурсы типа Event в Kubernetes, которые информируют вас о том, что происходит в вашем кластере. Это похоже на новостную ленту для компонентов кластера: они фиксируют всё — от запуска Pod'ов до ошибок в работе контроллеров.
Каждое событие в Kubernetes содержит:
*
message: краткое описание произошедшего*
reason: код причины события*
type: Normal или Warning*
involvedObject: объект, к которому относится событие (например, Pod или Node)*
firstTimestamp, lastTimestamp, count: время и количество повторений🔎 Как посмотреть события:
kubectl get events
Или для конкретного Pod'а:
kubectl describe pod <pod-name>
Kubernetes сам удаляет события через час. Это значит, что они не предназначены для долговременного хранения.
📤 Хранение событий
Если вам нужно сохранить события дольше, можно:
* Настроить аудит в Kubernetes
* Использовать внешние системы логирования (например, Elasticsearch + Fluentd)
* Подключить event exporters
https://decisivedevops.com/kubernetes-events-news-feed-of-your-kubernetes-cluster-826e08892d7a/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍1
🔥 Elasticsearch или PostgreSQL: зачем платить за сложность?
В DevOps-сообществе тренд «просто используй Postgres» с каждым годом становится всё более актуальным. Команда TigerData выкатили отличную статью, в которой разобрали 10 главных болей при эксплуатации Elasticsearch в продакшене и объяснили, как архитектура PostgreSQL помогает их избежать.
Спойлер: с великой силой (ES) приходит великая операционная боль.
Вот лишь несколько классических проблем, о которых идет речь в материале:
☕ JVM Garbage Collection (GC). Elasticsearch работает на Java, а значит, внезапные паузы "stop-the-world" при сборке мусора - часть вашей жизни. Если нода «подвисает» надолго, кластер считает ее мертвой и начинает панически перераспределять данные. Итог: каскадный отказ на пустом месте. Postgres написан на C, управляет памятью напрямую и не страдает от подобных фризов.
🧩 Математика шардирования. Неправильный сайзинг шардов в ES - это бомба замедленного действия. Слишком маленькие шарды создают оверхед, слишком большие приводят к проблемам с ребалансировкой и восстановлением.
🔄 ETL-пайплайны и синхронизация. Держать основные данные в реляционной БД и постоянно переливать их в ES для поиска - это всегда костыли, риск рассинхрона, задержки (lag) и лишняя точка отказа.
📈 Оверхед на мониторинг. ES требует отдельного зоопарка инструментов и глубокой узконаправленной экспертизы для поддержания кластера в зеленом статусе.
Какой выход предлагают авторы?
Для большинства проектов полномасштабный ES просто не нужен. Современный PostgreSQL (благодаря мощным расширениям вроде
Рекомендуется к прочтению всем, кто устал дебажить кластеры ES по ночам и задумывается о консолидации инфраструктуры.
https://www.tigerdata.com/blog/10-elasticsearch-production-issues-how-postgres-avoids-them
#devops #elasticsearch #postgresql #database #architecture #backend
📲 Мы в MAX
Подпишись 👉@i_DevOps
В DevOps-сообществе тренд «просто используй Postgres» с каждым годом становится всё более актуальным. Команда TigerData выкатили отличную статью, в которой разобрали 10 главных болей при эксплуатации Elasticsearch в продакшене и объяснили, как архитектура PostgreSQL помогает их избежать.
Спойлер: с великой силой (ES) приходит великая операционная боль.
Вот лишь несколько классических проблем, о которых идет речь в материале:
☕ JVM Garbage Collection (GC). Elasticsearch работает на Java, а значит, внезапные паузы "stop-the-world" при сборке мусора - часть вашей жизни. Если нода «подвисает» надолго, кластер считает ее мертвой и начинает панически перераспределять данные. Итог: каскадный отказ на пустом месте. Postgres написан на C, управляет памятью напрямую и не страдает от подобных фризов.
🧩 Математика шардирования. Неправильный сайзинг шардов в ES - это бомба замедленного действия. Слишком маленькие шарды создают оверхед, слишком большие приводят к проблемам с ребалансировкой и восстановлением.
🔄 ETL-пайплайны и синхронизация. Держать основные данные в реляционной БД и постоянно переливать их в ES для поиска - это всегда костыли, риск рассинхрона, задержки (lag) и лишняя точка отказа.
📈 Оверхед на мониторинг. ES требует отдельного зоопарка инструментов и глубокой узконаправленной экспертизы для поддержания кластера в зеленом статусе.
Какой выход предлагают авторы?
Для большинства проектов полномасштабный ES просто не нужен. Современный PostgreSQL (благодаря мощным расширениям вроде
pg_textsearch с поддержкой BM25 и pgvector для векторного поиска) отлично справляется с задачами поиска. Вы получаете полноценные ACID-транзакции, единую точку правды и предсказуемое потребление ресурсов без возни с настройкой JVM.Рекомендуется к прочтению всем, кто устал дебажить кластеры ES по ночам и задумывается о консолидации инфраструктуры.
https://www.tigerdata.com/blog/10-elasticsearch-production-issues-how-postgres-avoids-them
#devops #elasticsearch #postgresql #database #architecture #backend
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3❤1🔥1
22 октября Kubernetes-сообщество встречается офлайн в Москве!
Кому будет интересна конференция:
– DevOps- и SRE-инженерам;
– специалистам по Kubernetes и облачной инфраструктуре;
– платформенным инженерам;
– архитекторам и техническим руководителям;
– всем, кто занимается эксплуатацией и развитием инфраструктуры.
Что будет в течение дня?
🎤 Доклады
Программа продолжает дополняться, но уже сейчас в ней много интересных тем:
– От бизнес-требования к ядру Linux;
– Как дать агенту управление кластером вашей инфраструктуры;
– Как в MWS Cloud Platform доставляют системный софт в managed K8s;
– Как сделать мультитенантность в Kubernetes-платформе;
– LLM-диагностика инцидентов в Kubernetes и OpenStack.
Без острых тем тоже не обойдёмся: обсудим, есть ли сегодня альтернатива Kubernetes и всегда ли стоит строить инфраструктуру вокруг него, и попробуем разобраться, правда ли ИИ однажды оставит нас без работы.
⚡️ Активности партнеров
Дополнительная возможность пообщаться с участниками конференции и включиться в интерактивные форматы от партнеров.
🍻 Афтепати
После основной программы нетворкинг продолжится уже в неформальной обстановке.
👉 Регистрируйтесь и зовите коллег — все подробности по ссылке!
Кому будет интересна конференция:
– DevOps- и SRE-инженерам;
– специалистам по Kubernetes и облачной инфраструктуре;
– платформенным инженерам;
– архитекторам и техническим руководителям;
– всем, кто занимается эксплуатацией и развитием инфраструктуры.
Что будет в течение дня?
🎤 Доклады
Программа продолжает дополняться, но уже сейчас в ней много интересных тем:
– От бизнес-требования к ядру Linux;
– Как дать агенту управление кластером вашей инфраструктуры;
– Как в MWS Cloud Platform доставляют системный софт в managed K8s;
– Как сделать мультитенантность в Kubernetes-платформе;
– LLM-диагностика инцидентов в Kubernetes и OpenStack.
Без острых тем тоже не обойдёмся: обсудим, есть ли сегодня альтернатива Kubernetes и всегда ли стоит строить инфраструктуру вокруг него, и попробуем разобраться, правда ли ИИ однажды оставит нас без работы.
⚡️ Активности партнеров
Дополнительная возможность пообщаться с участниками конференции и включиться в интерактивные форматы от партнеров.
🍻 Афтепати
После основной программы нетворкинг продолжится уже в неформальной обстановке.
👉 Регистрируйтесь и зовите коллег — все подробности по ссылке!
👍1
Kubefirst
Платформа с открытым исходным кодом Kubefirst
Это полностью автоматизированная и операционная платформа с открытым исходным кодом, которая включает в себя некоторые из самых популярных инструментов с открытым исходным кодом, доступных в пространстве Kubernetes, и все они работают вместе из одной команды.
Мы поддерживаем локальные облака, облака AWS и Civo. Запустив наши команды cli в пустой среде, вы получите экосистему облачного управления и доставки приложений GitOps с автоматизированными рабочими процессами Terraform, управлением секретами Vault, интеграцией GitLab или GitHub с Argo, а также демонстрационными приложениями, демонстрирующими, как все это работает вместе.
Документация https://docs.kubefirst.io/
https://github.com/kubefirst/kubefirst
📲 Мы в MAX
Подпишись 👉@i_DevOps
Платформа с открытым исходным кодом Kubefirst
Это полностью автоматизированная и операционная платформа с открытым исходным кодом, которая включает в себя некоторые из самых популярных инструментов с открытым исходным кодом, доступных в пространстве Kubernetes, и все они работают вместе из одной команды.
Мы поддерживаем локальные облака, облака AWS и Civo. Запустив наши команды cli в пустой среде, вы получите экосистему облачного управления и доставки приложений GitOps с автоматизированными рабочими процессами Terraform, управлением секретами Vault, интеграцией GitLab или GitHub с Argo, а также демонстрационными приложениями, демонстрирующими, как все это работает вместе.
Документация https://docs.kubefirst.io/
https://github.com/kubefirst/kubefirst
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍1
GitOps-практики: развёртываем сервис через ArgoCD
Классический CI/CD запускает деплой. Но как сделать так, чтобы состояние Kubernetes после него соответствовало конфигурации в Git? На вебинаре разберём принципы GitOps и посмотрим, как ArgoCD помогает управлять изменениями в кластере.
7 октября в 20:00 МСК на открытом вебинаре OTUS развернём сервис в Kubernetes с помощью ArgoCD и покажет работу подхода на практике.
На практике рассмотрим:
— чем GitOps отличается от классического CI/CD и когда его применять;
— как устроен ArgoCD и какие есть варианты реализации GitOps;
— как развернуть сервис в Kubernetes через ArgoCD;
— что произойдёт при изменении конфигурации напрямую в кластере;
— какие подходы к работе с ArgoCD полезны в проектах.
После вебинара вы поймёте принципы GitOps, познакомитесь с возможностями ArgoCD и увидите полный процесс развёртывания сервиса. Полученные подходы сможете применить при работе со своими Kubernetes-кластерами.
Урок проходит в преддверии старта курса «DevOps. Экспертный уровень».
👉 Регистрируйтесь: https://vk.cc/d2eyjm
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Классический CI/CD запускает деплой. Но как сделать так, чтобы состояние Kubernetes после него соответствовало конфигурации в Git? На вебинаре разберём принципы GitOps и посмотрим, как ArgoCD помогает управлять изменениями в кластере.
7 октября в 20:00 МСК на открытом вебинаре OTUS развернём сервис в Kubernetes с помощью ArgoCD и покажет работу подхода на практике.
На практике рассмотрим:
— чем GitOps отличается от классического CI/CD и когда его применять;
— как устроен ArgoCD и какие есть варианты реализации GitOps;
— как развернуть сервис в Kubernetes через ArgoCD;
— что произойдёт при изменении конфигурации напрямую в кластере;
— какие подходы к работе с ArgoCD полезны в проектах.
После вебинара вы поймёте принципы GitOps, познакомитесь с возможностями ArgoCD и увидите полный процесс развёртывания сервиса. Полученные подходы сможете применить при работе со своими Kubernetes-кластерами.
Урок проходит в преддверии старта курса «DevOps. Экспертный уровень».
👉 Регистрируйтесь: https://vk.cc/d2eyjm
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576