About

Practical guides for infrastructure engineers

DevOpsDreams is an independent technical blog about Kubernetes, Amazon EKS, Terraform, GitOps, and platform engineering. It is for engineers learning these technologies and operators comparing ways to build and run infrastructure.

How these guides are produced: DevOpsDreams articles are primarily based on vendor and project documentation. They add technical explanation, trade-offs, diagnostics and reference examples. They do not represent a DevOpsDreams lab or production deployment unless a specific article provides evidence of that work. Example values and illustrative calculations are not measured production results. Any locally verified tool behavior is identified separately from cloud or cluster testing.

The guides focus on the reasoning behind a design: which component owns a resource, what happens when a dependency fails, which permissions an example needs, and how to check the result. Topics include cluster networking, deployment workflows, Terraform state, workload security, reliability, and cost visibility.

Find the guide you need

Use Start Here to choose a reading path based on your current task, such as provisioning an EKS platform, promoting an application, or improving service reliability. Each path suggests a first article, follow-up reading, and a practical outcome to work towards.

If you already know what you need, use the search box in the header or the topic links on the homepage. The homepage also lists recent guides.

Put examples in context

Infrastructure examples need adapting to your environment. Read the assumptions, check upstream documentation for your installed versions, and validate changes in a representative test environment before using them in production. A reference configuration does not establish that it has been tested in your account or cluster.

Independence and corrections

DevOpsDreams is not affiliated with or endorsed by AWS, Google, HashiCorp, the Kubernetes project, or the other projects discussed here. Product names identify the technologies being explained.

The Editorial Policy explains how to interpret sources, examples, and updates. To report an error, suggest a topic, or raise a privacy or copyright concern, use the form on the Contact page.

Comments

Post a Comment

Popular posts from this blog

Argo CD Auto-Sync and Health Checks: An Operator's Guide to Safe GitOps Reconciliation

Image
Argo CD Auto-Sync and Health Checks: An Operator's Guide to Safe GitOps Reconciliation Auto-sync and health are not the same thing in Argo CD. This guide shows how reconciliation, pruning, self-healing, retries, health checks, hooks, and sync waves fit together in real clusters. TL;DR Argo CD auto-sync and health checks solve different problems. Auto-sync decides when the controller reconciles Git with the cluster, while health checks decide whether the resulting resources are ready, degraded, or suspended. In practice, you need both: automated sync with prune and self-heal keeps desired state converged, retry refresh helps failed syncs recover on new revisions, and health checks plus custom Lua logic make readiness visible to operators. Sync waves and hooks add ordering when resources depend on each other. The control loop most teams misunderstand Argo CD has two separate jobs that often get blurred together in day-to-day platform talk. The first is reconciliation. Should Arg...
Read more

Applying SRE Error Budgets to Services Running on EKS: SLIs, Burn Rates, and Release Decisions

Image
Listen to this article AI-narrated article - 28 min 01 sec. Prose is preserved; code and diagram cues refer to the examples below. Your browser does not support audio playback. Open the MP3 . Read the narration transcript - Open audio Applying SRE Error Budgets to Services Running on EKS: SLIs, Burn Rates, and Release Decisions Build error budgets around user requests, not healthy pods. Implement Prometheus burn-rate alerts, diagnose EKS failure modes, and turn reliability evidence into release decisions. TL;DR Error budgets turn a service reliability objective into an explicit allowance for unsuccessful user events. For EKS workloads, measure requests at a defined user boundary, calculate good and total events consistently, and distinguish application failures from load balancer failures and missing telemetry. This guide implements request-based SLIs, rolling budget calculations, and multiwindow burn-rate alerts with Prometheus. It also explains latency budgets, low-traffic edge ca...
Read more

Progressive Delivery with Canary and Blue-Green on Kubernetes: Argo Rollouts, Flagger, and Gateway API

Image
Listen to this article AI-narrated article - 19 min 58 sec. Narration may not include the latest examples. Use the written guide for implementation details. Your browser does not support audio playback. Open the MP3 . Read the narration transcript - Open audio Progressive Delivery with Canary and Blue-Green on Kubernetes: Argo Rollouts, Flagger, and Gateway API Canary and blue-green delivery fail when teams treat them as YAML patterns. This guide shows how rollout controllers, traffic routers, metrics gates, and rollback mechanics work together on Kubernetes. TL;DR Progressive delivery on Kubernetes is safest when rollout control, traffic control, and metric evaluation are separated. Native Deployments provide rolling updates and revision rollback, but canary and blue-green releases need explicit traffic splitting, health gates, and promotion rules. Argo Rollouts gives Kubernetes-native Rollout, AnalysisTemplate, and blue-green/canary strategies; Flagger automates service-mesh or G...
Read more