SRE Hamster

Контейнеры Kubernetes: процессы Linux под капотом 🔍 Ключевая концепция: Контейнеры — не виртуальные машины, а изолированные процессы Linux с ограниченными ресурсами. ▫️ Механизмы изоляции: - Namespaces (PID, сеть, IPC, mount) → виртуализация системных ресурсов - Cgroups → контроль CPU, памяти, дискового I/O - OverlayFS → эффективное управление слоями образов ▫️ Роль Kubernetes: - Абстракция над низкоуровневыми компонентами (containerd, runc) - Оркестрация тысяч процессов на кластере - Обеспечение declarative-модели через API ▫️ Критически важные следствия: 1. Все контейнеры используют общее ядро ОС хоста 2. Инструменты отладки (kubectl exec, kubectl debug) → взаимодействие с PID пространствами 3. OOM Killer применяется к контейнерам как к процессам 4. Сетевые политики работают через Linux netfilter ▫️ Практические преимущества понимания: - Эффективная диагностика инцидентов - Оптимизация потребления ресурсов - Корректная настройка лимитов - Предсказуемое поведение системы Исходная статья #kubernetes #study #deepdive

🔥 SLA vs SLO: Главное, что путают даже профи ❌ Классическая ошибка: «Давайте сделаем SLA между командами!» — фраза, после которой SRE плачут в уголке. 🧩 Чем отличаются: - SLA (Service Level Agreement) — юридический договор с клиентом. Нарушил? Штрафы/компенсации 💸 - SLO (Service Level Objective) — внутренняя цель команды. Превысили? Заморозка релизов, но не суд 🎯 ⚡️ Пример: - *SLA*: «Простой >1 часа → возврат $10 000» - *SLO*: «Цель 99.95% аптайма → чтобы НЕ сработал SLA» 🔍 Ключевое: - SLO всегда строже SLA! (Например: SLO=99.99% vs SLA=99.5%) - Лайфхак: «Что будет при провале?» → Штраф = SLA, процессные изменения = SLO 👉 Итог: SLA = договор с внешним миром (клиенты/деньги) SLO = правила внутри (инженеры/мониторинг) Читать подробнее #study #monitoring #sre

The latest edition of Technology Radar — Volume 30 The themes are: - AI-assisted software development teams - Open-ish source licenses - Dragging pull requests closer to proper continuous integration - Emerging architecture patterns for large language models (LLMs) #study #radar

Defining clear Incident Severity levels is a key component to an efficient Incident Management process that helps Engineering teams quickly respond to outages and mitigate customer impact. Operating an online platform with multiple nines of availability is a complex task, modern websites depend on thousands to hundreds of thousands of individual moving parts all of which need to work correctly in order to provide a satisfactory user experience. When any one of those parts fails then an Incident Management process is needed to coordinate mitigation efforts and resolve the impact as quickly as possible getting the system back into working order. Incident Management starts by answering a seemingly simple question: How bad is the problem? Knowing how big the issue is that we are dealing with is crucial to understanding the appropriate response to that particular problem. When the problem is small we probably don’t need to notify our C-suite level leadership or send a notice to all customers … but if it is really big then we absolutely need a communication strategy that notifies relevant stakeholders. Link #observabilty

With the upcoming deprecation and subsequent removal of Pod Security Policies (PSPs) in Kubernetes, the time is near to find suitable alternatives. Those alternatives, it seems clear at present anyway, will need to be sourced from outside the Kubernetes project itself as there will be no replacement provided (edit: Pod Security Admission is the new, albeit incomplete, successor). The two leading CNCF projects which are prime candidates for PSP replacement are Open Policy Agent (OPA) via Gatekeeper and Kyverno, each with their own strengths and weaknesses. But it is confusing and daunting to compare and contrast them given that no comparisons presently exist. Not only are these projects viable replacements for PSPs, they are vastly more capable than simply acting on Pods alone--they are full Kubernetes policy engines. The goal of this article is to provide a neutral and impartial comparison between Gatekeeper and Kyverno so users may make the most informed selection decision for themselves. It will be an evaluation of each project's merits assuming only the Kubernetes angle. Link #architecture #k8s

Beyla is a vendor agnostic, eBPF-based, OpenTelemetry application auto-instrumentation tool, which lets you easily get started with Application Observability. eBPF is used to automatically inspect application executables and the OS networking layer, allowing us to capture essential application observability events for HTTP/S and gRPC services. From these captured eBPF events, we produce OpenTelemetry web transaction trace spans and Rate-Errors-Duration (RED) metrics. As with most eBPF tools, all data capture and instrumentation occurs without any modifications to your application code or configuration. Link #observabilty #tools

Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance. Link #observabilty #tools

Slow Down! Rate Limiting Deep Dive Now, why should you care about rate limiting? Well, consider a situation where your API is hit with a massive number of requests in a short span. This could be due to a surge in user traffic, a glitch causing repeated requests, or even an attempt to overwhelm your system using DDOS attack. Without rate limiting, your system could get overwhelmed, leading to slow responses or, worse, a complete service disruption. #study #architecture

Best Practices for Java Apps on Kubernetes - Piotr's TechBlog In this article, you will read about the best practices for running Java apps on Kubernetes. Most of these recommendations will also be valid for other languages. However, I’m considering all the rules in the scope of Java characteristics and also showing solutions and tools available for JVM-based apps. Some of these Kubernetes recommendations are forced by design when using the most popular Java frameworks like Spring Boot or Quarkus. I’ll show you how to effectively leverage them to simplify developer life. #java #k8s

Grafana Beyla eBPF-based auto-instrumentation of HTTP/HTTPS/GRPC Go services, as well as HTTP/HTTPS services written in other languages (intercepting Kernel-level socket operations as well as OpenSSL invocations). #tools #beyla #observability

Technology Radar #29 The themes are: - AI-assisted software development - How productive is measuring productivity? - A large number of LLMs - Remote delivery workarounds mature Radar #radar

Technology Radar #28 The themes are: - The meteoric rise of practical AI - Accessible accessibility - Lambda quicksand - Engineering rigor meets analytics and AI - To declare or program? Radar #radar

pg_activity pg_activity is a top like application for PostgreSQL server activity monitoring. Something like k9s Source #tools

DevSecOps Playbook This playbook will help you introduce effective DevSecOps practices in your company, regardless of size. We provide explicit guidance and actionable steps to introduce security controls, measure their effectiveness, and demonstrate value for money to your business leaders. Following this playbook will help teams build materially more secure applications, and that in the end, is the intent. DevSecOps-MaturityModel From a startup to a multinational corporation the software development industry is currently dominated by agile frameworks and product teams and as part of it DevOps strategies. It has been observed that during the implementation, security aspects are usually neglected or are at least not sufficient taken account of. It is often the case that standard safety requirements of the production environment are not utilized or applied to the build pipeline in the continuous integration environment with containerization or concrete docker. Therefore, the docker registry is often not secured which might result in the theft of the entire company’s source code. Minimum Viable Secure Product Minimum Viable Secure Product is a minimalistic security checklist for B2B software and business process outsourcing suppliers. Source #security #study

k8spacket packets traffic visualization for kubernetes #k8s #tools

Zero Trust and BeyondCorp Google Cloud In 2011, Google came up with a new approach for enterprise access management: the BeyondCorp implementation of the zero trust security model. It started as an internal Google initiative to enable every employee to work from untrusted networks without the use of a VPN. BeyondCorp shifts access decisions from the network perimeter to individual users and devices, thereby enabling employees to work more securely from any location and transforming the way they work. #security

Technology Radar An opinionated guide to technology frontiers Volume 27 #radar

Observability Mythbusters: Logs and Metrics Aren’t Enough There are two main points I want to address here specifically: 1. “Ignoring log data in your observability strategy is a major misstep” 2. “There are plenty of advanced users who only use logging and metrics for observability” I will do this by addressing two myths: 1. Logs alone are good enough for debugging 2. The usefulness of metrics #observability

Microservices Observability Design Patterns As service developers, we should implement several patterns that will make service management and troubleshooting easier. The following patterns can help us design observable services #observability

Unpacking Observability Good article for share it with colleagues, who don't understand what observability is and what problems is solves in simple words. #observability