DEV Community: Harshal Jethwa

Introducing AetherKube Beta: A Smarter Approach to Kubernetes Troubleshooting

Harshal Jethwa — Sat, 17 Oct 2026 06:32:07 +0000

Kubernetes gives teams powerful tools for running distributed applications, but troubleshooting cluster issues can still require time-consuming investigation across pod events, logs, resource usage, and workload configuration.

Understanding what went wrong is only part of the challenge. Teams also need to determine an appropriate response and verify whether the issue has actually been resolved.

AetherKube is an AI-powered Kubernetes diagnostics and remediation platform designed to bring these steps into a more cohesive operational workflow.

What is AetherKube?

AetherKube focuses on helping DevOps engineers, Site Reliability Engineers (SREs), and platform engineering teams investigate Kubernetes problems and work through remediation workflows.

The platform is built around three stages:

Diagnose

Investigate cluster issues and surface actionable diagnostic information to help engineers understand what may be causing a problem.

Remediate

Work through remediation workflows with appropriate approval controls. The goal is to make operational actions more deliberate and easier to review.

Verify

Check the outcome after remediation instead of assuming that executing a command automatically means the problem is fixed.

Why this matters

When a Kubernetes workload fails, engineers often need to inspect pod status, review events, examine container logs, check resource constraints, and determine whether a proposed fix is appropriate.

A structured workflow can help make that investigation more consistent and keep the focus on evidence, operational safety, and recovery.

AetherKube aims to support that workflow by bringing diagnostics, remediation, and verification together.

Who is it for?

AetherKube is intended for people working with Kubernetes, including:

DevOps engineers

Site Reliability Engineers

Platform engineering teams

Cloud and infrastructure engineers

Developers responsible for Kubernetes workloads

Explore the beta

The AetherKube beta is now available.

🌐 Website: https://aetherkube.pages.dev/

📥 Beta and downloads: https://aetherkube.pages.dev/download/

Explore the platform, review the available documentation, and evaluate whether its workflow fits your Kubernetes environment.

What's next?

Kubernetes operations continue to evolve, and useful tooling should evolve with them. The focus is on making troubleshooting more understandable, remediation more controlled, and outcomes easier to verify.

AetherKube — Intelligent Kubernetes Operations.

Why Exit Code 137 (OOMKilled) is Still Kubernetes' Biggest Headache — And How We Built an Autonomous Self-Healing Engine to Solve It

Harshal Jethwa — Mon, 07 Sep 2026 09:13:54 +0000

`# Why Exit Code 137 (OOMKilled) is Still Kubernetes' Biggest Headache — And How We Built an Autonomous Self-Healing Engine to Solve It

It is 3:17 AM on a Tuesday. Your PagerDuty alarm sounds.

You open your laptop, squint at a wall of red alerts, and run the ritual commands every SRE has memorized by heart:

bash kubectl get pods -n production kubectl describe pod auth-service-789f5cb68-9vxz2 -n production kubectl logs auth-service-789f5cb68-9vxz2 --previous
And there it is:

Last State: Terminated Reason: OOMKilled Exit Code: 137
For the next 45 minutes, you manually review memory consumption profiles, calculate container headroom, patch deployment specifications, and trigger rolling rollouts—all while production traffic is degraded.

Despite a decade of Kubernetes evolution, Exit Code 137 remains one of the most common, disruptive, and manual incidents in cloud infrastructure.

In this article, we'll examine why traditional Kubernetes monitoring fails at this, how Linux kernel memory pressure triggers eviction cascades, and how we engineered an autonomous, outbound-only control plane to detect and heal these failures automatically in seconds.

Anatomy of an OOMKill: What Actually Happens Under the Hood When a container exceeds its memory ceiling, Kubernetes doesn't kill it directly—the Linux kernel OOM killer (cgroups) does.

Kernel Cgroup Monitoring: The Linux kernel's memory controller monitors memory usage against memory.max (or memory.limit_in_bytes in cgroups v1).
Signal 9 (SIGKILL): When a process breaches its allocation, the kernel immediately dispatches an uncatchable SIGKILL (Signal 9).
Exit Code 137 Calculation: In Unix systems, when a process terminates due to a signal, its exit code is calculated as: $$\text{Exit Code} = 128 + \text{Signal Number} = 128 + 9 = 137$$
CrashLoopBackOff Cascade: Kubelet restarts the container. If memory pressure recurs immediately, restart delays increase exponentially ($10s \to 20s \to 40s \to 300s$), locking the service into a prolonged downtime spiral.

Why Conventional Dashboards Don't Fix the Problem Today’s cloud monitoring landscape is saturated with dashboards: Grafana, Datadog, Lens, New Relic.

While these tools are visually impressive, they suffer from a fundamental architectural limitation: they are purely passive.

They scrape Prometheus metrics.
They plot a red spike on a chart.
They blast a webhook to your Slack channel.
At 3 AM, an alert doesn’t resolve downtime; an engineered remediation does.

Inverting the Paradigm: Autonomous In-Cluster Operations When building AetherKube, we wanted to eliminate the manual troubleshooting loop entirely. Instead of relying on human intervention for predictable failures, the platform operates as an in-cluster autonomous platform engineer.

The Self-Healing Architecture
┌────────────────────────┐ Outbound mTLS ┌────────────────────────┐
│ Target Cluster │ ───────────────────────────► │ AetherKube Hub │
│ (aetherkube-agent) │ ◄─────────────────────────── │ (Control Plane) │
└────────────────────────┘ Autonomous Patch └────────────────────────┘
│ │
▼ ▼

eBPF Event Tap 3. Deterministic Safety
OOMKill Detection & Blast Radius Limit
1. Outbound-Only Mutual-TLS Architecture Traditional remote cluster tooling requires opening inbound firewall ports or configuring public ingress load balancers. AetherKube operates entirely via outbound-only TLS 1.3 WebSocket streams. Your clusters remain isolated behind private VPCs, restrictive enterprise NATs, or egress proxies.
2. Sub-Second Diagnostic Reasoning The engine intercepts kubelet probe events and eBPF socket events. When an Exit Code 137 occurs:

It analyzes peak memory delta (e.g., Memory exceeded by 24MiB beyond 256MiB limit).
It validates that the host node has sufficient capacity without risking node-level eviction.
It dynamically computes the target limit (e.g., 512MiB) with a safe buffer.

Non-Destructive Rolling Patch Under strict configurable safety guardrails (maximum percentage of pods modified, cooldown backoffs, and immutable audit logging), AetherKube applies an automated resource patch and monitors the subsequent healthz probe.

text
[14:02:18] ALERT: CrashLoopBackOff in prod-ingress (Exit Code 137: OOMKilled)
[14:02:19] SCAN: Memory limit exceeded by 24MiB. Host node headroom: 8.4GiB available.
[14:02:20] PATCH: Applied limits.memory = 512MiB. Rolling restart verified.
[14:02:22] RESOLVED: 4/4 Pods RUNNING (0 Restarts). SLA preserved at 99.99%.
The entire cycle finishes in under 5 seconds—before an on-call engineer can even unlock their phone.

Try AetherKube Today We have officially opened our public launchpad and documentation:

👉 Official Website: https://aetherkube.pages.dev
👉 Documentation & Architecture Specs: https://aetherkube.pages.dev/docs/
👉 Follow our engineering updates on LinkedIn: AetherKube on LinkedIn

Hosting Static Website Using AWS S3, ACM, CloudFront and AWS CodePipeline

Harshal Jethwa — Fri, 23 Jun 2023 06:27:53 +0000

10WeeksOfCloudOps

Introduction of AWS Services that we are going to use :

AWS S3 (Simple Storage Service):

AWS S3 is a highly scalable, reliable, and secure object storage service that allows you to store and retrieve any amount of data from anywhere on the web. S3 provides developers with simple API access to the same scalable storage infrastructure that Amazon.com uses to run its global e-commerce network. It is ideal for hosting static websites, storing backups, and archiving data.

AWS ACM (AWS Certificate Manager):

AWS ACM is a service that makes it easy for you to provision, manage, and deploy SSL/TLS certificates for use with AWS services. It removes the time-consuming manual process of purchasing, uploading, and renewing SSL/TLS certificates. ACM provides you with a simple interface for requesting and managing certificates, as well as for configuring SSL/TLS encryption for your web applications running on AWS.

AWS CloudFront:

AWS CloudFront is a content delivery network (CDN) that securely delivers data, videos, applications, and APIs to customers globally, with low latency, high transfer speeds, and no minimum usage commitments. It integrates with other AWS services like S3 and EC2, enabling you to distribute content stored in S3 buckets or EC2 instances to customers worldwide.

AWS CodePipeline:

AWS CodePipeline is a fully managed continuous delivery service that helps you automate your software release process. With CodePipeline, you can model, visualize, and automate the steps required to release your software, such as building, testing, and deploying code changes. It integrates with other AWS services, such as CodeCommit, CodeBuild, and CodeDeploy, allowing you to create continuous delivery pipelines that are scalable, resilient, and easy to manage.

Setup to Host Static Website Using AWS S3, ACM, CloudFront and AWS CodePipeline :

Setup 1 :

Create An AWS S3 Bucket :

Upload the website files to bucket:

Block Public Access of S3 Bucket for Security :

Select an Option of Static Website Hosting and write index file name :

Access the Website using link of Static Website you will not get anything.

Setup 2:

Now, Go to CloudFront and Create distribution:

Create Distribution and select WAF option

Setup 3 :

Then, go to ACM(AWS Certificate Manager) validate CName and CValue of your Domain

Add CName and CValue of your AWS cloudfront to your dmain CName and HostName

Now, copy your distribution domain name and paste it to url. you will see your website

Setup 3 :

Go to AWS CodePipeline

Create Pipeline and name it and connect with the Github

Select Git Repo and Branch

Build it and you will see Done Screen

Now to go to your buckets Invalidation and create invalidation

Now, your Static Website is hosted using AWS S3, ACM, CloudFront and AWS CodePipeline.

Follow me :

Linkedin : https://www.linkedin.com/in/harshaljethwa/

GitHub: https://github.com/HARSHALJETHWA19/

Twitter: https://twitter.com/harshaljethwaa

Thank You!!!