| |
| 🔗 Stories, Tutorials & Articles |
| |
|
| |
| How to find unused Prometheus metrics using mimirtool |
| |
| |
The article explains how to analyze and extract the list of used and unused metrics in a Prometheus setup. By using mimirtool, the author demonstrates how to identify metrics used in Grafana dashboards, Prometheus rules, and other sources. This analysis helps optimize resource usage and provides insights for improving dashboard design and alerts. |
|
| |
|
| |
|
| |
| Verifying Container Image Signatures Within CRI Runtimes ✅ |
| |
| |
The Kubernetes community has implemented container image-based artifact signing since release v1.24, and other projects have followed suit. To verify these signatures, manual methods can be used for testing purposes, but for production environments, automation tools like the sigstore policy-controller can be utilized. Additionally, CRI-O, a container runtime, now supports container image signature verification starting from version v1.28, simplifying the validation process. |
|
| |
|
| |
|
| |
| Grafana vs. Prometheus Agent |
| |
| |
The Prom agent is an implementation of the Grafana agent specifically focused on metrics observability. It provides a separate service for scraping metrics and writing them to another system for storage, querying, and alerting, offering a solution for scaling metrics collection in Prometheus while decoupling it from other functionalities. |
|
| |
|
| |
|
| |
| Distributed Tracing — Past, Present and Future ✅ |
| |
| |
Distributed Tracing, once a highly anticipated technology, has seen moderate adoption and faces challenges in implementation, sampling, and limited developer usage. However, the future holds promise with advancements such as auto-instrumentation without code changes, AI-based selection of relevant requests, and the emergence of rich distributed traces that encompass various debugging information, leading to a more comprehensive observability solution for distributed architectures. |
|
| |
|
| |
|
| |
| Demystifying OOM Killer in Kubernetes: Tracking Down Memory Issues |
| |
| |
The OOM killer is a critical component in Kubernetes that terminates pods when they exceed their memory limit, freeing up memory for other important processes and preventing system crashes. By monitoring memory metrics, particularly the `container_memory_working_set_bytes`, the OOM killer identifies the processes or pods responsible for memory overload and ensures the overall stability of the cluster. |
|
| |
|
| |
|
| |
| Confidential Kubernetes: Use Confidential Virtual Machines and Enclaves to improve your cluster security ✅ |
| |
| |
Confidential Computing (CC) introduces hardware-enforced Trusted Execution Environments (TEEs) to protect data in use. TEEs like AMD SEV, Intel SGX, and Intel TDX provide secure environments for computations, while technologies such as ARM TrustZone and AWS Nitro Enclaves offer TEE solutions for specific devices and cloud platforms. These TEEs ensure confidentiality, integrity, attestation, and recoverability of data, with each technology offering different features and limitations. The performance overhead of CC is relatively low, making it suitable for real-world workloads, and it complements other encryption techniques like Fully Homomorphic Encryption (FHE), Zero Knowledge Proofs (ZKP), and Multi-Party Computations (MPC). Use cases include Confidential Containers (CoCo) and secure projects in cloud-native environments. |
|
| |
|
| |
|
| |
| Why and How We Use Prometheus to Monitor Kubernetes |
| |
| |
ZipRecruiter moved from using Icinga to Prometheus for monitoring their Kubernetes environment due to Icinga's server-centric model not aligning well with the fluid nature of Kubernetes nodes. Prometheus's unstructured labels and pull-driven approach for collecting information proved to be more suitable for their monitoring needs. They also faced challenges with high cardinality in Prometheus metrics and the need for longer-term storage capabilities. Additionally, they implemented a serverless cloud meta-monitoring system using AWS Lambda to watch multiple Prometheus instances and detect broader issues. Finally, they shared key insights for a successful migration, emphasizing a gradual transition, educating teams on Prometheus usage, and leveraging auto-discovery features in Kubernetes. |
|
| |
|
| |
|
| |
| Hacking Auto-GPT and escaping its docker container ✅ |
| |
| |
Auto-GPT vulnerability allows arbitrary code execution and docker escape: Researchers discovered an attack that tricks Auto-GPT into executing arbitrary code by injecting malicious prompts during seemingly harmless tasks. The attack also exploits vulnerabilities in self-built versions of the Auto-GPT docker image and non-docker versions, allowing code execution outside of the intended sandboxing. |
|
| |
|
|
| |
|
| |
| GKE (Google Kubernetes Engine) Review |
| |
| |
GKE (Google Kubernetes Engine) is a highly recommended managed Kubernetes service that simplifies the setup and management of Kubernetes clusters. It offers features like automatic detection of outdated APIs, built-in ancillary services (such as DNS and load balancing), easy cluster replication, and backup and restore capabilities. GKE also utilizes Container-Optimized OS, an operating system designed specifically for running containers, which provides security, stability, and hassle-free updates. |
|
| |
|
| |
|
| |
| Service Mesh vs. API Gateway on Kubernetes |
| |
| |
In Kubernetes, a service mesh is a dedicated infrastructure layer that handles communication and observability between services within a distributed system, while an API gateway acts as a centralized entry point for external clients to access services. The service mesh focuses on internal service-to-service communication, traffic management, and observability, while the API gateway handles request routing, protocol transformation, and security enforcement for external clients. Both serve different purposes in a microservices architecture and can complement each other. The K8s Gateway API standardizes the interfaces for both the API gateway and service mesh. |
|
| |
|
| |
|
| |
| Gitlab Runner on Kubernetes |
| |
| |
Outschool uses GitLab SaaS along with self-hosted GitLab Runner to fulfill their CI/CD needs and improve their system's performance and scalability for a wide range of functionality. They utilize a combination of community-provided Terraform modules and Docker Machine executors to enable auto-scaling and experiment with new versions of CI jobs. |
|
| |
|
| |
|
| |
| Don't Migrate to Kubernetes |
| |
| |
Migrating to Kubernetes can be daunting for many organizations. Shifting the goal from “use Kubernetes” to having good operational practices makes for an easier, iterative transition. |
|
| |
|
| |
