Используйте эту команду kubectl, чтобы мгновенно найти pod’ы с утечками ресурсов или чрезмерным потреблением по всему кластеру Kubernetes
MemOps🤨
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24🌚3
Hands-on comparison against a deliberately broken cluster, with real outputs and failure-mode differences. Practical for deciding where AI Kubernetes tools fit: scanner, agent framework, or natural-language kubectl layer.
📌 Подробнее: https://decodeops.substack.com/p/k8sgpt-vs-kagent-vs-kubectl-ai-what
MemOps🤨
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Substack
K8sGPT vs Kagent vs Kubectl-AI: What Each Actually Does
Install K8sGPT, Kagent, and kubectl-ai. Run all three against a broken Kubernetes cluster. Real output, real comparison, honest verdict on which one to keep.
lessfilter-pygmentize - подсветка синтаксиса на основе Pygments для less
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - CoeJoder/lessfilter-pygmentize: A pygments-based syntax highlighter for less.
A pygments-based syntax highlighter for less. Contribute to CoeJoder/lessfilter-pygmentize development by creating an account on GitHub.
Разработке время — безопасной разработке еще больше времени
В новом выпуске техно-дискуссий К2 Кибербезопасность разберем:
✅ стоит ли платить за коммерческие решения или можно жить на open source
✅ как выбрать между SAST, SCA и DAST и не утонуть в количестве инструментов
✅ Security Champions VS AppSec-команда: какой подход продуктивнее?
Когда: 16 июля, 19:00 (мск)
Где: онлайн
Регистрируйтесь по ссылке и присоединяйтесь к трансляции
В новом выпуске техно-дискуссий К2 Кибербезопасность разберем:
Гости выпуска:
🎙 Максим Князев, старший системный инженер, К2 Кибербезопасность
🎙 Андрей Кулешов, руководитель разработки SourceCraft Security Яндекс.
Ведущая — Анна Старшинова, ведущий менеджер по развитию практики защиты данных и приложений К2 Кибербезопасность.
Когда: 16 июля, 19:00 (мск)
Где: онлайн
Регистрируйтесь по ссылке и присоединяйтесь к трансляции
Please open Telegram to view this post
VIEW IN TELEGRAM
Cilium стал дефолтным CNI в EKS: что делать с eBPF
В 2026 году eBPF окончательно перешёл из категории «попробовать в лабе» в инфраструктурный стандарт: AWS выбрала Cilium дефолтным CNI для EKS, проект вышел из инкубационной стадии CNCF, а ядро 6.x стабилизировало основные возможности. Cilium на eBPF обгоняет iptables по throughput на 30–40% и умеет L7-политики, пишет автор.
Что делать сейчас. На новых кластерах оцените Cilium вместо flannel/calico+iptables. На нодах проверьте ядро —
📌 Подробнее: https://dev.to/linou518/ebpf-in-2026-the-kernel-revolution-powering-cloud-native-security-and-observability-22jd
MemOps🤨
В 2026 году eBPF окончательно перешёл из категории «попробовать в лабе» в инфраструктурный стандарт: AWS выбрала Cilium дефолтным CNI для EKS, проект вышел из инкубационной стадии CNCF, а ядро 6.x стабилизировало основные возможности. Cilium на eBPF обгоняет iptables по throughput на 30–40% и умеет L7-политики, пишет автор.
Что делать сейчас. На новых кластерах оцените Cilium вместо flannel/calico+iptables. На нодах проверьте ядро —
uname -r не ниже 5.8, иначе часть функций недоступна, а CentOS 7/RHEL 7 не поддерживаются. Для безопасности разверните Tetragon: он ловит аномалии на уровне ядра и убивает процесс раньше, чем среагирует userspace.MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
DEV Community
eBPF in 2026: The Kernel Revolution Powering Cloud-Native Security and Observability
eBPF in 2026: The Kernel Revolution Powering Cloud-Native Security and...
❤9
10 ошибок в CI/CD, которые замедляют работу инженеров
Процессы непрерывной поставки непрерывно связаны с эффективной работой пайплайнов. По мере роста числа репозиториев и циклов тестирования процессы СI/CD, которые работали на старте проекта, требуют инфраструктурных изменений.
В статье автор собрал 10 типичных ошибок в организации CI/CD. Вы узнаете, почему монолитные пайплайны приводят к росту времени сборок и как неправильная стратегия тестирования зависимостей и окружений влияет на стабильность доставки.
📌 Подробнее: https://devops.com/these-are-10-ci-cd-pipeline-mistakes-that-slow-down-engineering-teams/
MemOps🤨
Процессы непрерывной поставки непрерывно связаны с эффективной работой пайплайнов. По мере роста числа репозиториев и циклов тестирования процессы СI/CD, которые работали на старте проекта, требуют инфраструктурных изменений.
В статье автор собрал 10 типичных ошибок в организации CI/CD. Вы узнаете, почему монолитные пайплайны приводят к росту времени сборок и как неправильная стратегия тестирования зависимостей и окружений влияет на стабильность доставки.
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
DevOps.com
These are 10 CI/CD Pipeline Mistakes That Slow Down Engineering Teams
Continuous software delivery depends on CI/CD pipelines enabling teams to rapidly develop, test, and deploy code across environments.
👍2❤1
HPA, VPA или KEDA: что выбрать?
📌 Подробнее: https://dev.to/muskan_8abedcc7e12/kubernetes-vpa-vs-hpa-vs-keda-which-autoscaler-actually-cuts-your-bill-4f4p
MemOps🤨
Среднестатистический кластер Kubernetes утилизирует 13% CPU и 20% RAM (согласно данным отчёта CNCF 2024 Kubernetes Benchmark Report). 87% остаются «простаивать».
Чтобы устранить этот «недостаток» есть 3 autoscaler'a: HPA, VPA и KEDA. Каждый из них решает свою задачу или делает это чуть иначе, чем «сосед».
И тут встаёт вопрос: а какой из них выбрать? Как сделать потребление ресурсов максимально эффективным?
Чтобы найти свой ответ на этот вопрос можно обратиться к статье.
В ней Автор рассматривает:
— Общие принципы работы каждого из представленных autoscaler’ов
— Проводит небольшой сравнительный анализ
— Приводит рекомендации о том, когда можно/нельзя их комбинировать
— Предлагает алгоритм того, как выбрать то, что в большей степени подойдет вам
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
DEV Community
Kubernetes VPA vs HPA vs KEDA: Which Autoscaler Actually Cuts Your Bill
The average Kubernetes cluster runs at 13% CPU utilization and 20% memory utilization. That means 87%...
Kubernetes дома? Ты не в себе? Как с Cursor и без DevOps-опыта поднять приватный кластер для личных проектов
📌 Подробнее: https://habr.com/ru/companies/flant/articles/1043430/
MemOps🤨
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🦄1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁33
Как снизить Latency в Kubernetes?
Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!
1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:
Установите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.
2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:
3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:
Это уменьшит нагрузку на CoreDNS и ускорит обработку запросов.
4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:
Эти параметры помогут лучше обрабатывать соединения и снижать задержку.
5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.
MemOps🤨
Высокая задержка (latency) в Kubernetes может стать настоящей головной болью для DevOps-инженера. Давайте разберем, какие ключевые настройки помогут снизить задержку и ускорить ваш кластер!
1. Настройка Kube-Proxy
Если используете iptables-режим, попробуйте переключиться на IPVS:
kubectl edit configmap -n kube-system kube-proxyУстановите mode: "ipvs". Это значительно улучшает балансировку нагрузки и снижает задержку при обработке запросов.
2. Подключение eBPF (Cilium)
Классические iptables могут быть узким местом. Попробуйте Cilium с eBPF, который обеспечивает более быструю маршрутизацию:
helm install cilium cilium/cilium --namespace kube-system3. Использование NodeLocal DNSCache
DNS-запросы — частая причина высокой задержки. Включите локальный кэш:
kubectl apply -f https://k8s.io/examples/admin/dns/nodelocaldns.yamlЭто уменьшит нагрузку на CoreDNS и ускорит обработку запросов.
4. Tuning TCP (sysctl)
Настройте TCP-параметры для более быстрой передачи данных:
sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
Эти параметры помогут лучше обрабатывать соединения и снижать задержку.
5. Использование Multi-NIC и CNI-плагинов
Если у вас высокий сетевой трафик, попробуйте Multus CNI для распределения нагрузки между несколькими сетевыми интерфейсами.
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1
⚙️ Производительная инфраструктура
Если сервис по каким-либо причинам вам не подойдёт, мы оформим возврат средств.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🌚1
chainloop — хранилище доказательств с открытым исходным кодом для аттестаций цепочки поставок программного обеспечения, спецификаций материалов программного обеспечения (SBOM), VEX, отчетов SARIF, отчетов QA и многого другого. С помощью Chainloop команды по безопасности, соответствию требованиям и управлению рисками могут определять политики безопасности и соответствия, какие доказательства и артефакты они хотят получать и где их хранить. С другой стороны, разработчики защищены от всей этой сложности, получая простые инструкции о том, что предоставлять при внедрении их конвейеров CI/CD.
📌 Подробнее: https://github.com/chainloop-dev/chainloop
MemOps🤨
MemOps
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - chainloop-dev/chainloop: SDLC evidence store and policy engine for your Software Supply Chain attestations, SBOMs, VEX…
SDLC evidence store and policy engine for your Software Supply Chain attestations, SBOMs, VEX, SARIF, QA reports, and more - chainloop-dev/chainloop