Learn how easy it is to manage multiple Helm Charts from one deployment project using Kluctl.

In this article we’ll create a two-node cluster with one control-plane node and one worker node as a proof-of-concept. As an extra challenge we’ll also take a look at how to do PCIe passthrough for the worker node.

A collaborative IPv6 book.

The intention is a practical introduction to IPv6 for technical people, kept up to date by active practitioners.

It’s a tale as old as UNIX_MIN_TIMESTAMP. Your team owns a service that you treat like a black box as long as it’s working. Sure, there’s a small maintenance task here and there that the most tenured member of the team almost exclusively picks up. How they fix it might as well be a wizard’s incantation with a sprinkle of fairy dust. But this time around they’re busy on another task, or worse, gone from the company altogether. Here’s my story of such a maintenance task. In this post I go through my journey of migrating one such service from Klaviyo’s legacy kubernetes platform, to our new spiffy, well-managed platform.

Historically, data teams have not been closely involved in the incident management process (at least, not in the traditional “get woken up at 2AM by a SEV0” sense). But with a growing involvement of data (and therefore data teams) in core business processes, decision making, and user-facing products, data-related incidents are increasingly common, and more important than ever.

At incident.io, the Data team works across multiple areas of the business, enabling go-to-market and product teams alike to make data-driven decisions. Given our broad involvement, we’re no stranger to data incidents and are heavy users of our own product to monitor, triage, and respond to them. Here’s a quick run-through of how we’ve set this up.

A Service Level Agreement (SLA) is a formal document that outlines the expectations, responsibilities, and performance metrics between a service provider and a customer.

kubetrim tidies up old and broken cluster and context entries from your kubeconfig file.

The fastest knowledge base for growing teams. Beautiful, realtime collaborative, feature packed, and markdown compatible.

Self-hostable clone of lazydocker for the web. Manage your Docker fleet with ease

wush is a command line tool that lets you easily transfer files and open shells over a peer-to-peer WireGuard connection.

In this blog post we will look at securing an AWS Terraform configuration using Trivy to check for known security issues. We will explore different ways of using Trivy, integrating it into your CI pipelines, practical issues you might face and solutions to those issues to get you started with improving the security of your IaC codebases.

In this article I want to describe how to configure the IAM relationships in a multi-account AWS organization with AWS SSO to allow managing infrastructure as a code with terragrunt/terraform from both CI/CD runner and local PCs.

Add a terraform plan -light flag such that only resources modified in code are targeted for planning.

This would reduce the scope of the pre-plan refresh down to the set of resources we know changed, which reduces overall plan times without the consistency risk of -refresh=false.

For Terraform to know what resources were modified in code, it would store the hash of the serialized sorted attribute map for each resource successfully applied. This would allow diff’ing “last-applied code” vs. “new code”, the result of which is the scope of the next -light plan.

Basically, -light autogenerates the -target list from code changes.

Master Terraform modules for Azure infrastructure management. Learn to create, use, and optimize modules, build a multi-tier application, and implement best practices for large-scale projects. Ideal for DevOps engineers and cloud architects looking to enhance their Infrastructure as Code skills on Azure.

Recently, I was tasked with analyzing cross-AZ traffic in Kubernetes to identify opportunities for reduction, as it is a significant contributor to our AWS bill. The first step was to understand how traffic flows between services and what portion consistently crosses Availability Zones (AZs). To optimize cross-AZ traffic, I considered using topology-aware routing for services. However, before implementing this solution, I needed a method to effectively analyze inter-pod traffic at the AZ level.

To achieve this, monitoring network traffic at the pod level is necessary. I decided to use eBPF (Extended Berkeley Packet Filter) technology, as it allows us to observe network interactions with minimal performance overhead.

In this article, I will explain what eBPF is, explore the tools available for using it, and provide a step-by-step guide on implementing monitoring for inter-pod traffic using Retina, Kube State Metrics, Prometheus, and Grafana.

The CNCF candidate for observability visualisation.

Understanding Terraform Variable Precedence: Which Value Wins?