DEV Community: dasmat

I built kubectl-tripwire to find admission webhook problems before they break a cluster

dasmat — Wed, 29 Jul 2026 11:46:39 +0000

One thing I've noticed while working with Kubernetes is that admission webhooks are easy to forget about... until something goes wrong.

A webhook might look completely fine, but if its Service has no healthy endpoints, or every backend pod is sitting on one node, or the TLS setup is broken, a fail-closed webhook can suddenly start rejecting API requests.

I wanted something that could look at the whole dependency chain instead of making me check everything manually.

So I built kubectl-tripwire.

It analyses admission webhooks and checks things like:

failurePolicy
Service and EndpointSlice health
Backend pods
Node and zone spread
PodDisruptionBudgets
TLS configuration
JSON output for automation

Example:

kubectl tripwire admission

Instead of only listing webhook configs, it tries to answer questions like:

"If this webhook goes down, what actually happens?"

It's still very early (v0.1.0), so there are definitely things I want to improve.

If you have ideas, find bugs, or think there's something useful to add, I'd love to hear it.

Sample Output

══════════════════════════════════════════════════════════════════
  KubeTripwire — Admission Failure-Chain Analysis
  Cluster: production-east · 8 webhooks analyzed (5 mutating, 3 validating)
══════════════════════════════════════════════════════════════════

Webhook: istio-sidecar-injector
────────────────────────────────────────────────────────────
  Type:            MutatingWebhookConfiguration
  failurePolicy:   Fail (fail-closed)
  timeoutSeconds:  10
  matchPolicy:     Equivalent
  sideEffects:     None

  Scope:
    - Ops:       CREATE
      Resources: pods
    - Namespaces: 31 of 34 match selector

  Backend:
    Service:       istio-system/istiod (port 443)
    Endpoints:     1 of 3 ready
    Pods:          3
    Owner:         Deployment/istiod
    Nodes:         1 unique nodes
    Zones:         1 unique zones (us-east-1a)

  Findings:
    [HIGH] Fail-closed webhook with degraded endpoints
      Only 1 of 3 endpoints are ready. If the remaining endpoint(s) become unavailable, matching admission requests will be rejected.
      Evidence:
        • Ready endpoints: 1 of 3
        • failurePolicy: Fail
        • Scope: pods/CREATE in 31 namespaces
      Consideration: Investigate why some endpoints are not ready. Check backend pod status and events.

    [MEDIUM] Fail-closed webhook with all backend pods on a single node
      All backend pods are scheduled on the same node. A node failure or drain will remove all backend pods simultaneously.
      Evidence:
        • Backend pods: 3
        • All on node: worker-2a
        • failurePolicy: Fail
      Consideration: Consider pod anti-affinity rules or topology spread constraints to distribute backend pods across nodes.

══════════════════════════════════════════════════════════════════
  Admission Compound Risks
══════════════════════════════════════════════════════════════════

  ⚠ Fail-closed webhook with endpoint issues affecting wide scope
    Webhook:  istio-sidecar-injector
    Scenario: Matching API requests in 31 namespaces are at risk of rejection. If all endpoints become unavailable, no matching resources can be created or modified.

──────────────────────────────────────────────────────────
Summary:
  Webhooks analyzed: 8
  Critical findings: 0
  High findings:     1
  Medium findings:   1
  Low findings:      0
  Info observations: 0
  Compound risks:    1
  Scan duration:     42ms
──────────────────────────────────────────────────────────

Looking for the best Go (Golang) course on YouTube

dasmat — Mon, 20 Jul 2026 08:00:24 +0000

Hi everyone!

I'm looking for a high-quality Go (Golang) course on YouTube and would love to hear recommendations from the community.

A bit about me:

I already have programming experience.
I contribute to open-source projects, especially in the Kubernetes ecosystem.
I want to improve my Go skills for backend development and cloud-native projects.

I'm looking for a course that covers:

Go fundamentals
Interfaces
Error handling
Goroutines & channels
Concurrency patterns
Context package
Testing
Building REST APIs
Project structure and best practices

If you've learned Go from YouTube, which course would you recommend and why? Are there any channels or playlists that you think stand out?

Thanks in advance!

Chronological K8s Debugging: Merging Logs, Events, and Node Alerts on the Fly

dasmat — Wed, 15 Jul 2026 21:37:03 +0000

Chronological K8s Debugging: Merging Logs, Events, and Node Alerts on the Fly

If you've ever had to debug a failing Kubernetes microservice in real time, you know the "context-shift trap" all too well.

You find yourself with three terminal split panes open:

One running kubectl logs -f pod-xyz (or stern) to tail application output.
A second running kubectl get events -w to see if there are liveness probe failures or scheduling issues.
A third polling kubectl describe node to track resource pressure or disk problems.

The hard part isn't getting the information—it's stitching it together. When your app throws a database connection timeout at 14:02:15.102, did it happen before or after the Kubelet posted a MemoryPressure alert on the node? Did a ConfigMap update trigger a rolling update that caused the database pod to restart?

Answering these questions down to the millisecond requires tedious manual correlation. I wanted a way to see everything in one place, so I built KubeCorrelate.

What is KubeCorrelate?

KubeCorrelate (kubecorrelate) is a lightweight, zero-dependency CLI tool written in Go. It operates purely client-side using your existing kubeconfig context to multiplex container logs, Kubernetes events, configuration changes, and node pressure warnings into a single, chronological, color-coded stream.

Here is what a live debugging session looks like in action:

[23:55:01.002] [LOG] Processing order #98213...
[23:55:02.155] [CONFIG] ConfigMap "app-config" was modified
[23:55:03.441] [LOG] Reloading routing rules...
[23:55:05.801] [EVENT] [WARN] LivenessProbeFailed
[23:55:07.100] [NODE] [WARN] MemoryPressure: System memory usage exceeded 95%
[23:55:07.350] [EVENT] [WARN] Container restarted (Reason: OOMKilled)

Instead of switching tabs, you see the exact sequence of events that led to the crash.

How It Works Under the Hood

KubeCorrelate uses the client-go libraries to spin up lightweight watch goroutines for different telemetry signals:

Log Streams: Pulls real-time container logs with Timestamps: true enabled.
Kubernetes Events: Watches pod-specific warnings and lifecycle state transitions.
Configurations: Monitors ConfigMaps and Secrets referenced by the target pod.
Node Metrics: Listens for resource pressure signals (Memory, Disk, PID pressure) on the specific node hosting the pod.

Solving the Out-of-Order Logging Problem

If you simply print these streams as they arrive, they will be out of order. Network latencies, API aggregation delays, and container runtime flush intervals mean that a log line from a container might reach your client machine after a Kubernetes event that actually occurred later.

To solve this, KubeCorrelate implements a client-side Bounded Slop Sorting Buffer (defaulting to 1.5s, customizable via --buffer-delay):

Telemetry Sources [Logs] [Events] [Configs] [Node Alerts] │ │ │ │ ▼ ▼ ▼ ▼ ┌─────────────────────────────────────────┐ │ Bounded Slop Sorting Buffer │ <-- Queues and sorts client-side └─────────────────────────────────────────┘ │ ▼ Sorted Terminal Output

Incoming events are temporarily queued in the buffer. After the buffer delay passes, the events are flushed in guaranteed chronological order down to the millisecond.

Built for Production Clusters

When writing KubeCorrelate, I focused on making it safe for real-world enterprise environments:

Graceful RBAC Degradation: If you're running in a locked-down namespace where you don't have cluster-wide permissions to watch Nodes or ConfigMaps, KubeCorrelate doesn't crash. It outputs a single warning and keeps monitoring the logs and events you do have access to.
Dynamic Pod Discovery: In a rolling deployment, pods are constantly terminated and replaced. KubeCorrelate automatically detects when a new pod starts, attaches watchers to it, and tears down the old ones cleanly.

* Zero Dependencies: Built entirely with standard Go libraries and official Kubernetes packages. No extra agents or CRDs required in your cluster.

Getting Started

KubeCorrelate is officially accepted in the CNCF Krew index. You can install it directly as a kubectl plugin:


bash
kubectl krew install correlate
Once installed, use it as:

bash
kubectl correlate -l app=order-processor
Alternatively, you can build from source:

bash
go install github.com/Dasmat13/kubecorrelate/cmd/kubecorrelate@latest
Try it out!
Check out the repository on GitHub: Dasmat13/kubecorrelate.

Would love to hear your thoughts, feedback, and feature requests. If you find it useful, feel free to drop a star!

Inside a Kubernetes Bug Fix: Investigating an Integer Overflow in Dynamic Resource Allocation (DRA)

dasmat — Mon, 13 Jul 2026 09:05:55 +0000

Contributing to a project as large as Kubernetes can feel intimidating at first. Millions of lines of code, hundreds of active contributors, and a rigorous review process make every contribution a learning experience.

Recently, while exploring the Dynamic Resource Allocation (DRA) subsystem, I came across an integer overflow issue related to resource range calculations. In this post, I'll walk through how I approached understanding the problem and preparing a fix.

Why This Bug Matters

Overflow bugs don't usually show up during normal usage. They tend to appear only with extreme values, making them difficult to spot and easy to overlook.

Even though these edge cases are rare, production systems should still handle them correctly. That's especially important in a project like Kubernetes, where correctness and predictability are critical.

My Approach

Before making any code changes, I focused on understanding the surrounding implementation.

My workflow looked like this:

Read the implementation carefully.
Follow every helper function it called.
Search for all call sites.
Read the existing unit tests.
Understand the assumptions the code relied on.

Only after understanding the code did I start thinking about a possible fix.

Finding the Root Cause

The issue came from arithmetic performed during resource range alignment.

When values approach the upper limit of a 64-bit integer (math.MaxInt64), intermediate calculations can overflow before the final result is computed.

Rather than producing a predictable value, overflow can lead to incorrect behavior that is difficult to detect.

Designing a Safer Solution

The approach I proposed was to use saturating arithmetic for the calculation.

The basic idea is straightforward:

Perform the calculation normally when it is safe.
If the result would exceed the maximum representable value, clamp it to math.MaxInt64.

This avoids overflow while keeping the behavior deterministic.

Writing Tests

One of the most valuable lessons I've learned from open source is that a fix isn't complete without tests.

I focused on adding edge-case tests that exercised values near the maximum range of a 64-bit integer.

These tests help prevent similar regressions in the future.

What Open Source Has Taught Me

Working on Kubernetes has reinforced several important engineering habits:

Read much more code than you write.
Understand the design before proposing changes.
Keep fixes as small and focused as possible.
Write tests that explain the behavior you're protecting.
Treat code review as an opportunity to learn.

Sometimes the biggest part of a contribution isn't writing code—it's understanding why the existing code works the way it does.

Final Thoughts

Whether you're making your first contribution or your fiftieth, large open-source projects are incredible places to grow as an engineer.

Every bug investigation teaches you something new about system design, testing, and collaborative software development.

I'm looking forward to continuing contributing to Kubernetes and learning from the review process along the way.

If you're interested in contributing to open source, my advice is simple: start small, stay curious, and keep learning.

🚀 I just published GitWorld Engine! It's an open-source GitHub Action that transforms your GitHub contribution graph into an animated pixel-art city. I'd love your feedback on the idea, implementation, and future features. If you enjoy GitHub profile cu

dasmat — Sat, 11 Jul 2026 08:18:27 +0000

dasmat

Jul 11

I Built GitWorld Engine: A GitHub Action That Turns Your Contributions into an Animated City

#showdev #github #opensource #typescript

2 min read

🚀 Just launched GitWorld Engine! An open-source GitHub Action that turns your GitHub contributions into an animated pixel-art city. Looking for feedback and feature ideas! https://github.com/Dasmat13/git-world-action

dasmat — Sat, 11 Jul 2026 08:16:50 +0000

GitHub - Dasmat13/git-world-action · GitHub

Contribute to Dasmat13/git-world-action development by creating an account on GitHub.

github.com

I Built GitWorld Engine: A GitHub Action That Turns Your Contributions into an Animated City

dasmat — Sat, 11 Jul 2026 08:03:40 +0000

I Built GitWorld Engine: A GitHub Action That Turns Your Contributions into an Animated City

GitHub profiles have become more than just a list of repositories—they're a way to showcase your work and personality.

Many developers use the classic GitHub Snake animation to visualize their contribution graph. While I like that idea, I wondered:

What if your contributions built something instead of being eaten?

That question led me to build GitWorld Engine.

🌍 What is GitWorld Engine?

GitWorld Engine is an open-source GitHub Action that transforms your GitHub contribution graph into a living, animated pixel-art world for your profile README.

Instead of displaying a static graph, your GitHub activity becomes part of an evolving world.

🏙️ Repositories become cities
🏗️ Commits grow buildings
👑 Pull requests become bosses
🐛 Issues become roaming monsters
🌳 Your primary programming language determines the world's biome

Every time your GitHub activity changes, the world evolves automatically.

⚙️ How It Works

The GitHub Action runs on a schedule, collects your public GitHub activity, generates an animated SVG, and updates it in your profile repository.

Setup only takes a few minutes.

- uses: Dasmat13/git-world-action@main
  with:
    github_user_name: ${{ github.actor }}
    github_token: ${{ secrets.GITHUB_TOKEN }}
    svg_out_path: dist/gitworld.svg

Then add the generated SVG to your GitHub profile README.

💡 Why I Built It

I wanted to create something that felt more interactive and playful than a traditional contribution graph.

Instead of simply visualizing commits, GitWorld Engine turns your coding activity into a tiny world that grows as you continue building projects.

🚀 What's Next?

I'm planning to add more features, including:

🌙 Day and night cycles
🌧️ Weather effects
🚗 Moving vehicles
🚂 Trains
🏰 Additional biome themes
🎮 More pixel-art animations

Community feedback will help shape future updates.

🔗 Try It

GitHub Repository: https://github.com/Dasmat13/git-world-action
Website: https://dasmat13.github.io/git-world-action/

If you have ideas, suggestions, or feature requests, I'd love to hear them. Contributions are always welcome!