DEV Community: MetalBear

A Beginner's Guide to Helm

Arsh Sharma — Wed, 03 Jun 2026 12:25:24 +0000

The CNCF Annual Survey published in January 2026 showed that Helm is the second most used CNCF project, second only to Kubernetes itself. The reason is simple: once you start working with Kubernetes, YAML files accumulate fast and managing them keeps getting harder. A single microservice can require a Deployment, a Service, a ConfigMap, and a Secret, and that's before accounting for the different sets you’ll need for your development, staging, and production environments. Helm fixes this by packaging all of your manifests into a single, versioned unit that can be installed, upgraded, and rolled back easily.

In this guide, we'll cover what Helm is, some key concepts, and the main Helm commands you need to know to deploy and manage manifests using it. You’ll walk away with a complete understanding of how to use Helm so you can simplify the YAML mess you might be in.

Prerequisite: Basic familiarity with Kubernetes

What is Helm in Kubernetes?

Helm is a package manager for Kubernetes. Just as apt manages software packages on Linux or brew does on macOS, Helm manages Kubernetes applications and lets you install, upgrade, and roll them back as versioned, reusable units called charts.

The way Helm solves the YAML management problem is easiest to understand through a programming analogy. Bare Kubernetes manifests work fine for a single, static deployment. But the moment you need multiple similar deployments (dev, staging, prod, which may differ only by a few values), you're essentially copy-pasting. Helm solves this the same way classes solve it in object-oriented programming: you define the boilerplate once in a chart, which can include things like the Deployment template, the Service definition, the ConfigMap structure, and then each Helm chart deployment only specifies what's different: the image, the environment variables, the command being run in the pods. Someone installing your chart can also supply their own values file and get a correctly configured deployment for their use case without touching the original templates.

Like Kubernetes, Helm is declarative. You describe which chart to install and what values to pass in and Helm figures out how to get the cluster there and keeps it in that state.

Helm is built around three core concepts: Charts, Releases, and Repositories. We'll look at each of these next.

Key Concepts

Charts

A chart is a self-contained package of Kubernetes resource manifests. It defines everything needed to deploy an application (the Deployment, the Service, the ConfigMap, etc.) along with default values for any configurable settings. When you install a chart, Helm uses those templates and values to generate the actual Kubernetes manifests and applies them to your cluster.

Charts can also declare dependencies on other charts, called subcharts. This makes it possible to build composable application definitions, for example, a chart for a web application might pull in a chart for PostgreSQL and another for Redis rather than having manifests for those dependencies within it.

Releases

Each time you install a chart, Helm creates a release which is a named instance of that chart running in your cluster. If you install the same chart three times under different names, you get three independent releases, each with its own configuration, its own Kubernetes resources, and its own revision history.

It's important to understand that releases are what Helm actually manages. Helm doesn't think in terms of individual deployments or Helm charts when it comes to a Kubernetes cluster. Instead, it tracks releases and uses them to know what's deployed, what version it's at, and how to upgrade or roll back.

Repositories

A repository is a collection of charts hosted at an accessible URL. You add repositories to your local Helm installation and then install charts from them by name. The most widely used public index is Artifact Hub, which aggregates charts from many sources. Most projects that run on Kubernetes publish an official Helm chart there, so in practice you'll rarely need to write a chart from scratch to deploy well-known software like nginx, PostgreSQL, or Prometheus. For example, we also publish a chart for the mirrord Kubernetes operator, which you can find on Artifact Hub here.

What's Inside a Helm Chart

When you clone or create a Helm chart (using helm create chart-name), you get a directory with a specific structure. Here's what a typical chart looks like:

my-chart/
├── Chart.yaml
├── values.yaml
├── charts/
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── ...
    └── NOTES.txt

Chart.yaml is the chart's metadata file. It declares the chart's name, version, and description, and optionally lists dependencies on other charts.

apiVersion: v2
name: my-chart
description: A Helm chart for my application
version: 0.1.0
appVersion: "1.0.0"

apiVersion here refers to the Helm chart API version, not the Kubernetes API. v2 means the chart requires at least Helm 3 (don’t ask me why they couldn’t have made it simple by just having v3 for Helm 3). If you come across a chart with v1, it was written for Helm 2, which had a different chart format but Helm 3 and later versions still support v1 for backward compatibility.

version is the version of the chart itself. This follows semantic versioning and should be bumped whenever you change the chart by doing things like adding a new template, changing a default value, or updating dependencies. It's independent of what the chart deploys.

appVersion is the version of the application the chart deploys. This is purely for documentation and nothing else since Helm doesn't use it to pull images or make any decisions. You'd typically set it to the container image tag your chart defaults to, so users can tell at a glance what version of the application they're getting. You can update appVersion without changing version, and vice versa.

A good way to think about it is that appVersion tracks the version of the application being deployed, while version tracks releases of the chart itself. If your application is upgraded from 1.0.0 to 1.1.0, you'd update appVersion to reflect that change. If the chart's default image tag is also updated, you'd typically bump the chart version as well, since the chart itself has changed. But if you only modify the chart (for example by adding a new template, changing default values, or updating dependencies) while continuing to deploy the same application version, you'd bump version and leave appVersion unchanged.

values.yaml contains the default configuration for the chart. These are the values users can override at install time. For example:

image:
  repository: nginx
  tag: "1.25"
replicaCount: 1

templates/ is where the Kubernetes manifests live. Unlike regular YAML, these files use Go template syntax, which lets Helm inject values into them at render time. A template referencing the values above would look like this:

spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

When someone installs this chart and passes --set image.tag=1.26, Helm substitutes that value before applying the manifest to the cluster. This is the mechanism that makes a single chart work across environments without touching the templates themselves.

charts/ is where subchart dependencies are bundled. If your chart depends on PostgreSQL, for example, the PostgreSQL chart will live in this folder.

NOTES.txt is a template file that Helm renders and prints to the terminal after a successful install. Charts typically use it to show how to connect to or use what was just deployed. This is what a simple NOTES.txt could look like:

Thanks for installing {{ .Chart.Name }}.

To get more info, try:

  $ helm status {{ .Release.Name }}
  $ helm get all {{ .Release.Name }}

Creating Your Own Chart

Running helm create my-chart scaffolds the directory structure we just walked through, with sensible defaults already filled in. The generated values.yaml comes pre-populated with common settings like replicaCount, image.repository, and image.tag, and templates/ includes a Deployment, Service, Ingress, and a few other Kubernetes resources you might need.

The first thing to do after generating the chart is update values.yaml to reflect your application. Change the image.repository to point to your container image, set a default tag, and remove any values that don't apply. The generated defaults are based on a generic nginx deployment, so most of them will need adjusting.

The templates themselves often need less work. The generated Deployment and Service are wired up to the values in values.yaml using the {{ .Values.* }} syntax we saw earlier, so once your values are correct, the templates usually render correctly without modification. If your application has specific Kubernetes resources it needs that aren’t present or configured in the templates/ directory already, then you'd add those or modify the existing relevant template.

Once you've made your changes, run helm lint my-chart to catch mistakes like invalid YAML, missing required fields, broken template syntax. Then run helm template my-chart to render the templates locally and review the exact Kubernetes manifests that would be applied to the cluster. This is the step where you verify your values are flowing into the right places before anything touches the cluster.

Common Helm Commands

Let's now walk through some common commands you’ll find yourself using when working with Helm. Before you can install a chart, you need to add the repository it lives in. helm repo add registers a repository under a local name:

helm repo add metalbear https://metalbear-co.github.io/charts

Once added, run helm repo update to pull the latest chart index from all registered repositories. Charts are versioned and updated frequently, so it's worth running this before installing. To find a chart:

helm search repo mirrord-operator

This returns matching charts with their versions and descriptions. You can also browse Artifact Hub to discover charts. Each listing there shows the helm repo add command you need.

helm install deploys a chart as a named release:

helm install mirrord-operator metalbear/mirrord-operator

Helm renders the chart's templates, applies the resulting manifests to the cluster, and begins tracking the deployment as a release named mirrord-operator. It also prints the chart's NOTES.txt which typically has instructions for what to do after installing the chart.

Note: The chart used in the example above installs the mirrord operator which allows multiple developers to develop against the same cluster when using mirrord.

To see all releases currently running in the cluster:

helm list

To inspect a specific release and see its status and revision number:

helm status mirrord-operator

Customizing with Values

By default, helm install uses the values defined in the chart's values.yaml. You can override them in two ways. For quick changes, use --set:

helm install mirrord-operator metalbear/mirrord-operator --set license.key=ABC-DEF-GHI

For environment-specific configuration, a values file is easier to manage. Create a custom-values.yaml with only the values you want to override, then pass it with -f:

helm install mirrord-operator metalbear/mirrord-operator -f values.yaml

When both are used together, --set takes precedence over -f, which takes precedence over the chart's values.yaml defaults. To see all the values a chart allows you to configure you can run this command:

helm show values metalbear/mirrord-operator

When you want to update a release to a newer chart version and/or change its values use helm upgrade:

helm upgrade mirrord-operator metalbear/mirrord-operator --set limits.cpu=400m

Helm applies only what changed, creates a new revision, and preserves the previous one. To see the full revision history:

helm history mirrord-operator

If an upgrade causes problems, helm rollback reverts a release to an earlier revision:

helm rollback mirrord-operator 1

It's important to understand that a rollback creates a new revision rather than deleting the failed one which means the history stays intact so you can always see what happened.

helm uninstall removes all Kubernetes resources that belong to a release:

helm uninstall mirrord-operator

By default, Helm also deletes the release's history. To keep it for auditing or future rollbacks, pass --keep-history.

Frequently Asked Helm Questions

Do I have to use Helm with Kubernetes?

You don't strictly need Helm. For a simple application that doesn't change much, managing it with raw kubectl apply and plain YAML manifests works fine. Where Helm becomes worth it is when you're managing multiple environments, deploying the same application more than once, or distributing your application for others to run. Then maintaining separate YAML files per environment costs more in terms of time and effort than just learning Helm.

How do I deploy a Helm Chart on Kubernetes?

First, add the repository the chart lives in and update your local index. Then install the chart with helm install, giving the release a name and pointing to the chart:

helm repo add metalbear https://metalbear-co.github.io/charts
helm repo update
helm install mirrord-operator metalbear/mirrord-operator

If the chart requires custom configuration, pass values with --set for quick overrides or -f your-values.yaml for a full config file. After installing, helm list shows all running releases and helm status <release-name> gives details on a specific one. The Common Helm Commands section above covers all of this in detail.

Next Steps

In this guide, we covered the fundamentals of Helm: charts, releases, and repositories, how chart structure works, and the commands you'll use day to day. These basics are enough to install and manage existing charts and start writing your own charts. If you want to go deeper from here, working toward a Helm certification like Developing Helm Charts (SC104) can be a good way to continue learning Helm. For this and other topics the official Helm documentation is the best place to go.

Or if you don’t want to prepare for a certification but want to learn how to make managing multiple charts across multiple environments easier, Helmfile is the natural next tool to look at. It lets you declaratively define a set of Helm releases as a single unit, with per-environment values and deployment ordering.

Four Layers of Validation in Kubernetes with Claude Code

Jake Page — Thu, 21 May 2026 13:37:08 +0000

Earlier this year, Moltbook, a social network for AI agents, launched, trended, and became a cautionary tale within the same week. Security researchers at Wiz found a Supabase API key sitting in its client-side JavaScript, which was the database’s only access control, with no Row Level Security to narrow what that key could reach. The result: 1.5 million API tokens, 35,000 email addresses, and thousands of private messages exposed to anyone with a browser console.

Moltbook was a greenfield project with no review process. The same class of mistake is far more serious when AI-generated code lands inside applications that already have pre-existing users, real data, and an existing trust surface. That’s increasingly the reality: as organizations adopt AI coding agents, more and more AI-generated code is landing directly in production services that already hold credentials and personal details of your users. A recent survey found that 95% of developers don’t fully trust AI-generated code, while only 48% consistently review it before committing, yet it’s shipping regardless.

Static review tools catch only some classes of issues: common CVEs, dependency hygiene, style violations, deterministic anti-patterns. What they can’t see are things like the actual name of your Kubernetes Secret in this cluster, whether your auth middleware is wired into the right route in this service, whether the request a real user will send makes it through the new code path without breaking something downstream.

Closing that gap takes four independent layers: AI agent skills that shape what gets generated, commands that audit what was generated, integration tests that hit staging endpoints, routing traffic to your local code, and preview environments that let a human review the change against staging dependencies before merging.

Layer 1: Skills (passive, shaping what gets generated)

Most AI coding assistants let you write down rules that shape generation. The simplest mechanism is a config file that the assistant loads into context on every prompt: .cursorrules in Cursor, CLAUDE.md in Claude Code, .github/copilot-instructions.md in GitHub Copilot. Drop NEVER/ALWAYS rules in there and the AI follows them. The downside is that those files load on every prompt, even when you’re working on something unrelated, and every rule you add costs tokens whether or not it’s relevant.

Claude Code goes a step further with skills: structured rule sets that ship as plugins (a directory with a SKILL.md and supporting reference files). Each skill has a description, and the model pulls a skill into context only when your prompt matches what that skill is meant to cover. If a skill never gets matched against the prompt, it never gets loaded, and you don’t pay for the tokens it would consume. We’ve already shipped six skills for AI agents working with mirrord, and this post adds a seventh focused on validation: k8s-validation, an open-source set of NEVER/ALWAYS rules for code that runs inside a Kubernetes cluster.

The skill covers two halves: the cluster-level concerns (Secrets, RBAC, pod hardening, NetworkPolicies, supply chain, file handling) and the application-level concerns that determine whether the workload behaves correctly inside the cluster (HTTP and parameter handling, auth, output sanitisation, API contracts, env-var configuration, test coverage).

Before and after

Without the skill, the model has no way of knowing about things like Kubernetes Secrets already mounted as environment variables in your pod, auth decorators other handlers in your service already use, or PII-sanitization utilities your team has already built. So it does the obvious thing: hardcodes the API key, skips the auth check, and returns the LLM output directly. With the skill loaded, the following prompt (“add a /summarise endpoint that calls OpenAI’s API”) produces something like this:

import os
from openai import OpenAI
from utils.sanitize import filter_pii

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

@app.route('/summarise', methods=['POST'])
@require_auth
def summarise():
    text = request.json.get('text', '')
    response = client.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": f"Summarise: {text}"}],
    )
    summary = response.choices[0].message.content
    return jsonify({"summary": filter_pii(summary)})

filter_pii here is a stand-in for any utility that strips personally identifiable information (names, SSNs, emails, etc.) out of free text. Different teams build this differently; the Microsoft Presidio library is one of the more common open-source starting points.

Three differences from what the model would produce without the skill: the key comes from an environment variable backed by a Kubernetes Secret, the endpoint sits behind @require_auth, and the LLM output runs through filter_pii before going back to the user.

What skills can’t do

Skills shape generation, but they don’t verify anything.

In the example above, the AI correctly followed the skill: it read the API key from the environment, applied @require_auth, and called filter_pii from utils.sanitize. But the skill has no way to verify that filter_pii actually works. If the utility in your codebase only strips email addresses and misses phone numbers, the skill can’t know that. A user document containing a phone number sails straight through the filter and into the response, and the code looks correct at every layer the skill can see.

Skills set a floor by preventing the obvious structural mistakes. They’re instructions to a model, not checks against reality.

Layer 2: Commands (active, checking what was generated)

Where skills shape what the model generates, commands check what already exists. They’re explicitly invoked by a developer, an agent, or a CI step, and they run a defined set of checks against the code in front of them.

The same install from Layer 1 also ships a slash command: /k8s-validation:audit. It scans your codebase for the same NEVER/ALWAYS rules the skill enforces during generation, traces data flow through handlers and queries, and classifies each finding by severity. Skills don’t always load (a vague prompt, or a quick edit to a file the model didn’t classify as Kubernetes-adjacent, and the rules never enter context). The audit is the backstop: it runs on the code regardless of how the code got written.

> /k8s-validation:audit content-api/

CRITICAL 2 | HIGH 4 | MEDIUM 1 | INFO 0

[CRITICAL] src/routes/summarise.py: Hardcoded OpenAI API key → Use os.environ
[CRITICAL] src/routes/download.py: User filename in path without sanitization → Use secure_filename()
[HIGH]     src/routes/summarise.py: No authentication middleware → Add @require_auth
[HIGH]     k8s/deployment.yaml: No SecurityContext defined → Add runAsNonRoot, drop ALL
[HIGH]     src/routes/summarise.py: Reads OPENAI_API_KEY but no manifest defines it → Add to deployment.yaml env block
[HIGH]     src/routes/summarise.py: New endpoint with no integration test → Add test in tests/integration/

Note that the output mixes security findings (hardcoded key, missing SecurityContext) with correctness findings, meaning “does the code do what was asked, given the rest of the system” (the Kubernetes deployment manifest doesn’t define the env var the code reads; the new endpoint shipped without an integration test). Both halves matter for AI-generated code.

Because the audit is a command you run rather than a rule the model loads, the same invocation works in three places: a developer runs it before opening a PR, an agent runs it as part of its own loop after generating code, and CI runs it as a merge gate. You can wire it into one, two, or all three.

## Validation Workflow
After generating or modifying any Kubernetes-related code, run `/k8s-validation:audit`
on the changed files. If any CRITICAL findings exist, fix them before proceeding.

What commands can’t do

The audit is still static analysis. It can find “you hardcoded a secret” or “you’re missing a SecurityContext,” but it can’t tell you whether your filter_pii regex actually catches the PII your users will send, or whether the environment variable you’re reading will resolve to a value in your staging cluster. Commands check the shape of the code, not the behavior.

Layer 3: Integration tests (runtime, proving it works)

Your team probably already has integration tests that hit your API endpoints, check response shapes, and verify that authentication rejects bad credentials. These tests encode what “correct behavior” actually means for your application.

The bottleneck is running them. Locally, you mock your database, your auth service, your message queue, and hope the mocks match reality. In CI, each cycle takes 5 to 10 minutes. For a human pushing a few times a day, it’s already frustrating enough. For an AI agent trying to fix a failing test, it’s a feedback loop far too slow to learn from: the agent burns tokens on every iteration, and the integration bugs only surface after the change has been written, pushed, and built.

mirrord changes this equation by letting your local process stand in for a deployed pod. Your local code gets the environment variables from the target pod, the same cluster-level files it has access to, and the same view of internal services. In steal mode, traffic destined for the targeted pod is intercepted and routed to your local process instead of whatever’s deployed in staging. Your existing integration tests, pointed at staging endpoints as usual, now run against your local code in seconds, not minutes.

The same pattern scales horizontally. Because mirrord can split a single pod’s incoming traffic between many local processes using header-based filters, multiple agents (or developers) can iterate against the same staging cluster simultaneously, each one routing its own slice of the traffic to its own local code. One staging environment, many concurrent agents, real downstream services for all of them.

What this catches that the other layers can’t

Consider a prompt like “have /summarise fetch the document from our content-store service first.” The agent writes a handler that calls http://content-store/documents/{id} and reads response.json()["title"].

The catch: content-store moved to v2 months ago and now returns {"document": {"name": ..., "text": ...}}. The flat title/body shape only exists in the AI’s training data. Skills generated structurally clean code (good). The audit confirmed the call was made and the response was consumed (also good). Neither layer knows what shape content-store actually returns today.

The setup to fix this is two processes. You or your AI agent starts a mirrord session, your e2e tests run as normal against the staging content-api endpoint:

# Terminal 1, run your local content-api in place of the deployed pod
mirrord exec --target deploy/content-api --steal -- python -m content_api

# Terminal 2, run the existing integration suite against staging as usual
pytest tests/integration/test_summarise.py

When the test hits staging’s content-api endpoint, mirrord steals the request and reroutes it to your local process. The local handler calls http://content-store/documents/..., and that outbound call also routes through mirrord, hitting the real content-store in staging. The real service returns {"document": {"name": ..., "text": ...}}. The local code does response.json()["title"] and crashes with KeyError.

You fix the code to read the new shape, rerun the test, it passes. The bug surfaces in your local code, against real downstream services, in seconds, instead of after a deploy cycle. The same pattern works for any other dependency the code touches: environment variables from the pod, files from mounted volumes, database queries against the real Postgres. mirrord runs your code, the cluster supplies its real environment.

Layer 4: Human review in a real environment

When the agent opens the PR, a human should still get to see the change running in a real environment, not just read the diff. mirrord’s Preview environments make that easy: a GitHub Action spins up an isolated pod in your staging cluster running the PR’s code, connected to all the real downstream services, and scoped to that PR via an environment key.

Reviewers can click through the actual feature instead of inferring behavior from the code or having to run the whole application locally. Most of the failures the previous three layers don’t catch, UX regressions, surprising interactions, “looks right but feels wrong”, show up the first time a human uses the thing.

Putting it together: agents handle layers 1–3, humans handle layer 4

Layers 1 through 3 can be run by the agent itself. Instead of generating code, opening a PR, and hoping CI catches the issues, the agent generates code shaped by skills, runs /k8s-validation:audit to check for structural issues, runs the integration tests via mirrord against real infrastructure, and fixes any failures before committing. The agent doesn’t even have to write the test from scratch: Layer 1’s validation skill includes a rule that any new HTTP handler must come with an integration test, so the test gets generated alongside the endpoint. Layer 3 just runs it against real infrastructure.

Layer 4 is the handoff. Once the agent has passed its own checks, it opens a PR and a human gets a live preview environment to click through rather than a diff to infer from. The failures that surface at that stage, UX regressions, surprising interactions, things that look right but feel wrong are exactly the ones that didn’t show up in the previous three layers.

We’ve documented the concrete setup (per-service mirrord configs, helper scripts, and an AGENTS.md that tells the agent which script to run) in our mirrord with AI agents guide. The broader argument for why this matters, including the token cost of agents stuck in a feedback-less loop, is in How to prevent token burn using mirrord with e2e tests.

Adopting the layers

The four layers are independent. Pick the ones that close your biggest gap and add the others when the next failure teaches you what’s still missing.

Install the validation skill with /plugin install k8s-validation@metalbear-co/k8s-validation-plugin in Claude Code, or as a local rules directory for Cursor and GitHub Copilot (see the repo README). The /k8s-validation:audit command ships in the same install. For the runtime layer, install mirrord and wrap your local service with mirrord exec --target deploy/<service> --steal -- <run-command>. For preview environments on each PR, the feature is included in mirrord for Teams.

Each layer closes a different gap. Stop at any point and you’ve made things better than they were.

The skills are open source. If your AI assistant generates something the skills don’t catch, open a PR.

Six Claude Code Skills That Close the AI Agent Feedback Loop

Eyal Bukchin — Wed, 13 May 2026 16:56:14 +0000

AI agents write code that compiles, runs locally, and breaks the first time it touches your Kubernetes cluster. The cluster is full of state the model never sees: the env vars on the running pod, the schema in your real Postgres, the headers your upstream auth-service sends, the topics your consumer subscribes to. Without that context, the code an agent writes for your live infrastructure is informed guessing, whether you're shipping a new feature or fixing a regression.

mirrord closes that gap. It runs a local process as if it were a real pod inside your cluster: real env vars, real DNS, real network, optionally real inbound traffic. A real example: Daylight Security pairs Cursor with mirrord for daily development. Their team cut their typical edit-test cycle from 5–8 minutes to about 5 seconds. The reason isn't faster CPUs; it's that the agent now operates against the real cluster the way a senior engineer would, instead of guessing from logs.

We recently shipped six Agent Skills that teach AI agents how and when to use mirrord. The whole bundle installs in one command.

# Claude Code
/plugin marketplace add metalbear-co/skills

# Any Agent Skills consumer
npx skills add metalbear-co/skills

Here's what each skill does, with a concrete prompt that triggers it.

1. `mirrord-quickstart`

Zero-to-first-session for engineers (and agents) who have never used mirrord. Detects your OS, walks through CLI install or VS Code / IntelliJ setup, finds your target pod in the cluster, runs your first session. Your local process can now reach every service, database, and queue in the cluster.

Try: "I'm new to mirrord, help me run my Node app against my staging cluster."

The agent installs mirrord, lists targets in your namespace, picks a likely match, and runs mirrord exec --target … -- node server.js. No copy-paste from docs.

2. `mirrord-config`

Generates and validates mirrord.json, which tells mirrord what to do and where to do it. mirrord's config surface is wide: traffic stealing vs mirroring, filesystem modes, env injection, target selection, database and queue behavior. The skill turns "I want X behavior" into valid config without you opening the docs.

Try: "Steal traffic from pod/api-server, but only requests carrying my baggage header so I don't break anyone else's session."

The agent writes the right config, validates it against the schema, and explains what it does. The interesting part: the skill covers the full mirrord.json surface (target selection, traffic modes, env injection, file system hooks), not just filters. Filtered steal is one of the things that lets multiple developers share one cluster without colliding, but it's only one of the patterns mirrord-config knows how to set up.

3. `mirrord-operator`

Sets up the mirrord Operator for teams. Mirroring traffic from a pod is concurrency-safe out of the box; you only need the operator when multiple developers want to steal the same pod's traffic with different filters, share branched databases, or split a Kafka topic. The operator brokers session boundaries, RBAC, and the routing rules that make those interactions work without collisions.

Try: "Install the operator on our EKS cluster and configure RBAC so only the dev group can use it."

monday.com runs 350+ engineers on a single shared staging cluster this way. The operator is what makes that scale work: concurrent filtered steal so multiple devs share one pod, queue splitting so they share one SQS topic, DB branching so they share one database, RBAC so they don't touch workloads they shouldn't, and the rest of the routing rules that let 350 developers work on the same cluster at the same time.

4. `mirrord-ci`

Run integration tests in CI in isolation against your staging cluster, instead of spinning up an ephemeral test environment for each PR. The service under test runs in the CI runner with mirrord; mirrord steals the cluster traffic destined for it and routes it to your build, so test traffic follows the same path it would in production, with only that one service swapped. That catches the integration bugs mocks miss, with one shared staging cluster instead of one ephemeral cluster per PR.

Try: "Set up GitHub Actions to run our integration tests against the staging cluster."

The agent writes the workflow, injects your kubeconfig from a secret, sets MIRRORD_CI_API_KEY, and wires mirrord ci start around your service and mirrord ci stop in the cleanup hook.

5. `mirrord-db-branching`

Per-developer database branches. Copy-on-write Postgres (or any supported DB), so two engineers can develop against "the same" database without stepping on each other's writes.

Try: "Give me an isolated DB branch off the staging Postgres for this feature."

The agent provisions the branch via the operator, points your local process at the branch, and tears down when the session ends. No more "who deleted the test users?" Slack threads.

6. `mirrord-kafka`

Kafka queue splitting. Each developer gets a slice of the topic that only they consume, while the original consumer keeps running in the cluster. Lets you run a real Kafka workload locally without intercepting messages other people care about.

Try: "Set up queue splitting on the orders.created topic for my local consumer."

The agent configures the operator's Kafka splitter, gives your local process a per-developer consumer group, and confirms message routing.

Install

# Claude Code
/plugin marketplace add metalbear-co/skills

# Any Agent Skills consumer
npx skills add metalbear-co/skills

Repo: github.com/metalbear-co/skills. Issues and PRs welcome; we ship updates fast.

New Features We Find Exciting in the Kubernetes 1.34 Release

Arsh Sharma — Thu, 04 Sep 2025 10:54:31 +0000

The Kubernetes 1.34 release, “Of Wind & Will (O’ WaW)”, sets sail with a collection of features that may not grab headlines, but instead improve the day-to-day experience of running and managing clusters. Think of it as steady winds filling the sails, incremental but powerful improvements that help cluster administrators navigate smoother waters. And since combing through the full release notes can feel like charting a course through rough seas, we’ve pulled together some of the most useful highlights from this release to keep you on course.

Features Moving to Stable: Anchored and Ready for the Voyage

Dynamic Resource Allocation with Structured Parameters

Today where most companies are running (or trying to) run AI workloads on Kubernetes, we feel this feature is going to be the most important one from this release.

Before this change, Kubernetes didn’t really “see” specialized hardware devices like GPUs. Instead, the device drivers running on each node were responsible for keeping track of hardware availability and assigning it to pods. Kubernetes itself had no awareness of what devices existed, how many were available, or where they were located.

This lack of visibility introduced a number of challenges. For example, if two pods requested a GPU on the same node, the driver had to resolve the conflict on its own, without the scheduler knowing what was going on. Sharing GPU resources across pods was equally messy, since Kubernetes couldn’t reason about device capacity or availability and only knew that a pod needed “a GPU,” not whether the hardware was free or oversubscribed.

With Kubernetes v1.34, this changes. The new Dynamic Resource Allocation (DRA) framework, along with by structured parameters, lets Kubernetes manage specialized hardware devices directly. Structured parameters let hardware drivers describe the exact capabilities and constraints of a device in a standardized format that Kubernetes can understand. For example, instead of just saying “this node has 1 GPU,” the driver can specify details like GPU memory, supported features, or whether the device can be shared across multiple pods.

With this feature, instead of drivers silently handling everything, they now publish available devices as Kubernetes objects called ResourceSlice. These slices describe what hardware exists on each node and expose details that Kubernetes can use to make better scheduling decisions.

In other words, Kubernetes is no longer “blind” to hardware like GPUs, it can see what’s available, allocate it fairly, and even support sharing more reliably. Here’s a simple example:

apiVersion: resource.k8s.io/v1
kind: ResourceSlice
metadata:
  name: resourceslice
spec:
  nodeName: worker-1
  pool:
    name: gpu-pool
    generation: 1
    resourceSliceCount: 1
  driver: dra.example.com
  sharedCounters:
    - name: gpu-memory
      counters:
        memory:
          value: 8Gi
  devices:
    - name: gpu-1
      consumesCounters:
        - counterSet: gpu-memory
          counters:
            memory:
              value: 8Gi

This example shows a single GPU on node worker-1, grouped into a pool called gpu-pool. The GPU has 8 GB of memory, published through sharedCounters. Because this information is now visible to Kubernetes, the scheduler knows exactly how much memory the device provides and can place pods accordingly, instead of relying on the driver to manage it behind the scenes.

Allowing Only Anonymous Authentication for Configured Endpoints

With Kubernetes v1.34, you can now safely expose specific API server endpoints like /healthz, /readyz, and /livez without accidentally granting broader anonymous access.

By default, Kubernetes treats unauthenticated requests as anonymous, assigning them the identity system:anonymous and group system:unauthenticated. While this design supports useful cases such as health checks, it also comes with risks. If a RoleBinding or ClusterRoleBinding is accidentally applied to system:anonymous, even unauthenticated code running in a pod could gain access to the API server.

The new update fixes scenarios like these by giving administrators fine-grained control over which paths are available to anonymous users. Instead of having to disable anonymous access entirely, which can break important functionality, you can now define a safe list of allowed endpoints using the new AuthenticationConfiguration object.

Here’s an example:

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez
  - path: /readyz
  - path: /healthz

In this configuration, anonymous requests are permitted only to the health check endpoints, while all other anonymous requests are denied, even if misconfigured RoleBindings exist.

Relaxed DNS Search String Validation

The dnsConfig.searches field in a Pod manifest controls how short hostnames are resolved. If your pod looks up myserver, Kubernetes will automatically append each domain listed under dnsConfig.searches and try them in order. For example, myserver.first-domain, then myserver.second-domain, and so on until it finds a match. This mechanism is especially important when migrating legacy applications into Kubernetes since many older services rely on custom DNS search domains, sometimes with underscores (_) or leading dots (.).

Until now, Kubernetes didn’t allow these in dnsConfig.searches, which meant some services simply couldn’t be deployed without changing their DNS assumptions which is a task that can be both risky and time-consuming.

With Kubernetes v1.34, these restrictions are lifted. You can now include underscores and dots in DNS search domains, which makes it much easier to bring legacy workloads into Kubernetes without rewriting configurations or service names.

Here’s what that looks like in practice:


apiVersion: v1           
kind: Pod          
metadata:
  name: app-1
spec:
  containers:
    - name: app-1
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 10.244.0.69
    searches:
      - abc_d.staging.com  # Now valid
---
apiVersion: v1           
kind: Pod          
metadata:
  name: app-2
spec:
  containers:
    - name: app-2
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 10.244.0.69
    searches:
      - .   # Now valid
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local

With this update:

app-1 can now resolve fully qualified names like test.abc_d.staging.com without issue.
app-2 can use the special "." search entry to resolve hostnames exactly as written **before Kubernetes appends cluster defaults like svc.cluster.local.

So to sum up, if you’re migrating older workloads or working with services that depend on unconventional DNS naming conventions, Kubernetes no longer forces you to rework your DNS setup.

Features Moving to Beta: Stronger Winds Filling the Sails

PreferSameNode Traffic Distribution

Routing traffic efficiently in Kubernetes can be challenging, especially when services span multiple nodes or zones. By default, Kubernetes load-balances traffic across all healthy endpoints of a service, even if some are farther away. This can create unnecessary cross-node or cross-zone hops, which add latency and waste bandwidth. For many workloads, especially latency-sensitive applications like real-time inference, gaming backends, or high-throughput APIs, those extra hops can noticeably hurt performance.

Kubernetes v1.34 introduces new traffic distribution policies to address this:

PreferSameNode: Services can now prefer pods on the same node when the traffic originates from that node. This reduces latency and avoids network overhead from cross-node traffic.
PreferSameZone: The existing PreferClose policy has been renamed to PreferSameZone to make its behavior clearer. This helps workloads prioritize pods in the same zone for lower latency and reduced cross-zone costs.

Here’s an example of both in action:

apiVersion: v1
kind: Service
metadata:
  name: http-echo-service-1
spec:
  selector:
    app: http-echo-pod-1
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5678
  trafficDistribution: PreferSameNode
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo-service-2
spec:
  selector:
    app: http-echo-pod-2
  ports:
    - protocol: TCP
      port: 80
      targetPort: 5678
  trafficDistribution: PreferSameZone

With this configuration:

http-echo-service-1 routes traffic to a pod on the same node when possible. If none are available, it will fall back to another node.
http-echo-service-2 routes traffic to a pod in the same zone first, and only if necessary, sends it to a different zone.

VolumeSource: OCI Artifact and/or Image

In some deployments, multiple pods need access to the same configuration or data files. Traditionally, this might mean baking files into a ConfigMap or copying them into each pod, which can get messy as files grow larger or more complex.

With Kubernetes v1.34, you now have a cleaner option: image volumes. This feature lets Kubernetes mount an OCI image as a read-only volume that can be shared across multiple pods. Instead of duplicating files or manually syncing them, you package the files once into an image and then mount them wherever they’re needed.

Here’s an example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    volumeMounts:
    - name: oci-volume
      mountPath: /data
      subPath: hello.txt
    - name: oci-volume
      mountPath: /data/
      subPathExpr: $(POD_NAME).txt
  volumes:
  - name: oci-volume
    image:
      reference: <your-oci-image>

In this example, the oci-volume references an OCI image that contains files. The pod mounts specific files from that image, hello.txt, into its container. Since the volume is read-only, multiple pods can safely share the same source without conflicts.

For developers using mirrord, this also means that you can now run your local code against a pod that already mounts an image volume in the cluster. Your local process will gain the same access to the shared files, so you can test how your code interacts with the data without deploying or modifying the cluster setup.

Features Moving to Alpha: New Currents on the Horizon

Allows Setting any FQDN as the Pod's Hostname

Prior to this feature, setting a pod’s fully qualified domain name (FQDN) wasn’t straightforward. You had to combine multiple fields: hostname, subdomain, and setHostnameAsFQDN: true, to build an FQDN. The result always followed Kubernetes’ enforced pattern:

<hostname>.<subdomain>.<namespace>.svc.<cluster-domain>

If any part of that was misconfigured, the final FQDN wouldn’t resolve as expected. This could cause serious issues for systems that rely on strict hostname matching, such as Kerberos, where authentication breaks if hostnames don’t line up exactly.

This pain point is now addressed through a new field: hostnameOverride. This field allows you to explicitly set the pod’s internal kernel hostname to whatever value you need, bypassing Kubernetes’ enforced DNS naming convention.

Here’s an example:

apiVersion: v1           
kind: Pod          
metadata:
  name: app
spec:
  hostnameOverride: app.nginx.example.domain
  containers:
    - name: app
      image: nginx

In this configuration, the pod’s internal hostname is set directly to app.nginx.example.domain. Unlike before, you don’t need to stitch together multiple fields or follow Kubernetes’ strict naming rules.

Takeaways From Of Wind & Will Kubernetes Release

The Of Wind & Will release is not about grand, sweeping changes, but it’s about steady progress. The kind of refinements that make Kubernetes a sturdier ship for the long journey ahead. One of the standout improvements is the graduation of Dynamic Resource Allocation (DRA), a huge step forward for teams running AI workloads. With DRA, Kubernetes finally gains proper visibility into GPUs and other specialized hardware, making scheduling and sharing these resources far more reliable. For anyone working on machine learning or high-performance computing, this is a game-changer.

Security also gets tighter with more fine-grained anonymous access controls, ensuring only the right endpoints are exposed without weakening cluster safety. And for those migrating legacy systems, features like hostnameOverride and expanded DNS search support smooth out long-standing pain points, making Kubernetes more welcoming to applications that weren’t originally built for it.
Together, these updates may feel like adjustments to the rigging rather than rebuilding the ship, but that’s what makes them powerful. They reduce friction, close gaps, and make Kubernetes more adaptable to the real-world seas we sail in. With 1.34, the community hands cluster administrators and developers not just new features, but stronger winds and steadier will to keep moving forward.

DEV Community: MetalBear

A Beginner's Guide to Helm

What is Helm in Kubernetes?

Key Concepts

Charts

Releases

Repositories

What's Inside a Helm Chart

Creating Your Own Chart

Common Helm Commands

Customizing with Values

Frequently Asked Helm Questions

Do I have to use Helm with Kubernetes?

How do I deploy a Helm Chart on Kubernetes?

Next Steps

Four Layers of Validation in Kubernetes with Claude Code

Layer 1: Skills (passive, shaping what gets generated)

Before and after

What skills can’t do

Layer 2: Commands (active, checking what was generated)

What commands can’t do

Layer 3: Integration tests (runtime, proving it works)

What this catches that the other layers can’t

Layer 4: Human review in a real environment

Putting it together: agents handle layers 1–3, humans handle layer 4

Adopting the layers

Six Claude Code Skills That Close the AI Agent Feedback Loop

1. mirrord-quickstart

2. mirrord-config

3. mirrord-operator

4. mirrord-ci

5. mirrord-db-branching

6. mirrord-kafka

Install

New Features We Find Exciting in the Kubernetes 1.34 Release

Features Moving to Stable: Anchored and Ready for the Voyage

Dynamic Resource Allocation with Structured Parameters

Allowing Only Anonymous Authentication for Configured Endpoints

Relaxed DNS Search String Validation

Features Moving to Beta: Stronger Winds Filling the Sails

PreferSameNode Traffic Distribution

VolumeSource: OCI Artifact and/or Image

Features Moving to Alpha: New Currents on the Horizon

Allows Setting any FQDN as the Pod's Hostname

Takeaways From Of Wind & Will Kubernetes Release

1. `mirrord-quickstart`

2. `mirrord-config`

3. `mirrord-operator`

4. `mirrord-ci`

5. `mirrord-db-branching`

6. `mirrord-kafka`