DEV Community: Alexei Ledenev

cc-thingz v6: portable skills and hooks for AI coding agents

Alexei Ledenev — Sun, 28 Jun 2026 05:01:02 +0000

I released v6 of cc-thingz.

Short version: battle-tested skills and hooks for AI coding agents.

Longer version: I wanted the same developer workflow available in whichever coding agent and LLM model I use today.

Claude Code for some tasks
Codex CLI for others
Gemini CLI sometimes
Pi when I want the harness and subagents

The annoying part: skills are almost portable but work better when written as agent-specific and model-specific.

Each tool has its own plugin format, lifecycle events, hook model, permissions, and model behavior. Copy-pasting prompts between tools works for a few minutes, then turns into balagan.

So cc-thingz keeps one source of truth and compiles it into each agent's native setup.

What it is

cc-thingz is not a coding agent.

It is a portable workflow layer for coding agents:

skills
hooks
small role agents
guardrails
language references
generated per-agent exports

The repo source lives under src/. The build emits target-specific output for:

Claude Code plugins
Codex CLI skill exports
Gemini CLI extensions
Pi skills, agents, and hooks

Same workflow ideas. Native shape per agent.

What developers get

The project covers the boring, useful parts around coding with agents:

code review with severity/confidence rubrics
bug fixing with reproduce-first loops
refactoring with behavior-preserving checks
tests based on behavior seams
documentation updates grounded in code facts
git hygiene and worktrees
infra ops
browser automation
docs lookup and web research
lightweight spec-driven work

This is the stuff that keeps an AI coding session from becoming one giant chat window with vibes.

Why hooks matter

Prompts can ask the agent to behave.

Hooks can put friction in the right place.

cc-thingz includes hooks for things like:

suggesting relevant skills from the user's prompt
blocking protected paths and secrets
formatting and linting after edits
running focused tests after code changes
printing repo/session context on start
git guardrails

That is the practical difference between a prompt pack and a workflow.

A prompt says: "please run tests".

A hook runs the focused tests when the edit is done.

What is new in v6

v6 adds first-class workflows for:

Rust
C#/.NET
Java/Kotlin

That brings the language set to:

C#/.NET
Go
Java/Kotlin
Python
Rust
TypeScript
shell
web

The language work is not just writing-rust or writing-java-kotlin prompts.

The hooks understand the stacks too:

focused lint/format on changed files
nearest test target per build system
project detection on session start
skill routing by file extension, toolchain, and framework terms

So if the agent edits a Rust file, a .csproj, or a Gradle module, the workflow can choose a scoped feedback loop instead of running the universe.

Why these skills are better than random prompts

Not magic. Just boring engineering hygiene.

1. They come from daily use

The skills were written and refined while using agents on real code, not generated as a weekend prompt dump.

2. They are agent-native

Each target gets its own native format. Claude Code gets plugins. Gemini gets extensions. Pi gets skills, agents, and extensions. Codex gets skill exports.

3. They include hooks

The workflow is not only instructions. It also includes runnable checks and guardrails.

4. They compose

The agent model was simplified from 39 agents to 3 roles:

engineer — can edit and verify code
reviewer — read-only, adversarial, finds bugs
advisor — verdict, risks, next actions

Languages live in references. One reviewer can work across 8 languages instead of maintaining one reviewer per language.

5. The source of truth is shared

The same workflow logic is authored once, then compiled into the target output. Less drift. Less "why is this broken only in tool X?"

Should you try it?

Try it if:

you use Claude Code, Codex CLI, Gemini CLI, or Pi
you switch between more than one agent or model
you work in polyglot repos
you want focused lint/test hooks around agent edits
you want review/fix/test/refactor workflows that are more specific than "be careful"

Maybe skip it if:

you only use one tool and already have a setup you love
you want a fully generic, unopinionated prompt pack
you do not want hooks touching your workflow

cc-thingz is opinionated on purpose. Neutral agent workflows become mush.

Install

Claude Code:

/plugin marketplace add alexei-led/cc-thingz
/plugin install dev-flow@cc-thingz
/plugin install programming@cc-thingz

Gemini CLI:

gemini extensions install https://github.com/alexei-led/cc-thingz

Pi:

pi install npm:pi-subagents
pi install git:github.com/alexei-led/cc-thingz

Codex CLI:

git clone https://github.com/alexei-led/cc-thingz.git ~/src/cc-thingz
cd ~/src/cc-thingz
make build
codex
# inside Codex: /plugins

Repo: https://github.com/alexei-led/cc-thingz

Built from daily use. Practical, opinionated, and hopefully less balagan.

CCGram v4: Control AI Coding Agents from Telegram — Now with herdr Support

Alexei Ledenev — Mon, 22 Jun 2026 18:01:53 +0000

CCGram is a Telegram bridge for AI coding agents. Each Telegram Forum topic binds 1:1 to a terminal multiplexer window running Claude Code, Codex, Gemini, Pi, or a plain shell session. You monitor output, respond to interactive prompts via inline keyboards, and manage sessions — all from your phone while the agent runs on your machine.

The agent process stays in your local terminal session. Walk away from your desk, keep working from Telegram. Come back, attach to your terminal, and you have full scrollback exactly where the session left off.

v4.0.0 brings full herdr backend support.

What is herdr?

herdr is a modern terminal multiplexer with a workspace/tab model — like tmux, but organized around named workspaces and tabs rather than sessions and windows. It has a socket-based control API and native agent-status reporting built in.

If you use herdr and want ccgram to work with it: set one environment variable.

CCGRAM_MULTIPLEXER=herdr

Everything else — topics, providers, Claude hooks, session recovery, voice messages, screenshots, live view — works identically. The multiplexer is behind a Protocol seam in the codebase; callers never see which backend is active.

What changes when you use the herdr backend

Adaptive topic labels

On tmux, topics inherit the window name. On herdr, topics are labeled
"workspace ▸ tab" — e.g. "api ▸ auth-rewrite". The tab name is primary so two tabs in the same workspace still get distinct titles. If either part is missing, the label degrades gracefully to just the tab name or just the workspace name.

Workspace picker in `/new`

When you create a new session from Telegram, the flow gains an extra step on herdr: a workspace picker that lets you pin the new tab inside an existing workspace. If no workspaces exist yet, the step is skipped and ccgram creates a new one automatically.

Only agent tabs surface as topics

On tmux, every window is eligible to become a Telegram topic. On herdr, only tabs actively running an agent CLI (Claude Code, Codex, Gemini, Pi) are surfaced. A bare shell tab doesn't become a topic. This uses herdr's native agent-status capability — no terminal scraping required.

Native agent status

herdr reports what's running in a pane directly via pane process-info. ccgram doesn't need to scrape terminal output to figure out the active agent; it reads the structured data the multiplexer already provides.

Session re-resolution after restart

herdr re-mints tab IDs when its server restarts. ccgram handles this by re-mapping stale tab IDs to new ones via the shared session ID written by the Claude hook. Telegram topic bindings survive a herdr restart.

Protocol version pinning

ccgram pins the herdr socket protocol version it was built against and refuses to start on a mismatch, rather than silently misparsing changed JSON shapes.
If you upgrade herdr and see a protocol error, the ccgram build needs updating to match.

Same Claude Code hook

The hook that tracks sessions and fires events (SessionStart, Stop, interactive UI prompts) resolves which window fired from $HERDR_PANE_ID on herdr vs $TMUX_PANE on tmux. No herdr-specific hook setup is required.

Architecture: the multiplexer seam

The multiplexer access lives behind a Multiplexer Protocol in
multiplexer/base.py — a pure, I/O-free module with no backend imports.
Both tmux (multiplexer/tmux.py) and herdr (multiplexer/herdr.py) implement the same protocol and return the same neutral value types:

WindowRef — a window/tab reference
PaneInfo — pane metadata
CaptureResult — scrollback capture with a truncation flag
ForegroundInfo — the foreground process (pid, argv, cwd)

Callers import the module-level multiplexer proxy and type against the protocol — never a concrete backend. An architectural fitness test (tests/ccgram/test_multiplexer_boundary.py) enforces the boundary.

Quick start with herdr

# Install ccgram
uv tool install ccgram

# Set the backend
echo "CCGRAM_MULTIPLEXER=herdr" >> ~/.ccgram/.env

# Install Claude Code hooks (same as tmux)
ccgram hook --install

# Verify everything looks good
ccgram doctor

# Run
ccgram

Open your Telegram group, create a new topic, send a message — the directory browser appears. Pick a project directory, pick your agent, pick a workspace, and you're connected.

Install

uv tool install ccgram          # recommended
brew install alexei-led/tap/ccgram  # Homebrew (macOS)
pipx install ccgram             # pipx

Release notes: https://github.com/alexei-led/ccgram/releases/tag/v4.0.0
Source: https://github.com/alexei-led/ccgram

cc-thingz v4: portable AI coding workflows, now properly multi-agent

Alexei Ledenev — Wed, 13 May 2026 11:01:44 +0000

I released v4 of cc-thingz.

It is my open-source toolbox for AI coding agents: skills, agents, hooks, and safety rails for real coding workflows.

It works across:

Claude Code
OpenAI Codex CLI
Google Gemini CLI
Pi

Tachles: this is not another pile of prompts.

It is the same workflow logic, authored once, then compiled into each tool’s native shape.

Why v4 exists

Before v4, the project was still too Claude-shaped.

Other tools were supported, but the setup had too much duplication and too much:

why is this different here?

Classic balagan.

Now everything is authored once under src/ and compiled into platform-specific output.

What that buys you

shared workflow logic lives once
each tool gets instructions in its own shape
hooks and manifests are generated, not hand-juggled
tests catch drift before users do

Not glamorous. Very useful.

The infra got more serious too

One thing I ended up caring about more than expected: the prompts are not managed like random markdown blobs.

Skills live in canonical SKILL.md files, then get small per-tool overlays where behavior really differs. The build strips vendor-specific bits out of the shared base, validates that the base stays vendor-neutral, and snapshot-tests generated outputs so drift gets caught early.

There are also paid skill eval fixtures for regression testing behavior, because “seems fine” is not much of a test strategy when you are shipping instructions to models.

That part is not the headline, but it is why the portability claim is real instead of decorative.

The part I care about most: multi-agent support

The bigger value is multi-agent work that does not depend on one vendor UI.

cc-thingz now ships a larger shared agent set for:

review
implementation
testing
docs
language work
infra
planning
exploration

Claude Code and Pi can both use that shared set.

In Pi, this works through the @tintinweb/pi-subagents runtime instead of some separate Pi-only agent universe.

Pi also gets four pipeline agents:

scout
planner
reviewer
worker

Those are there to decompose work instead of stuffing everything into one heroic context window and pretending it is an engineering team.

Small specialized agents. Bounded jobs. Clear handoffs.

Less magic. More plumbing. Plumbing wins.

Hooks got properly portable too

Hooks are part of the point.

v4 keeps pushing safety into automatic checks:

linting
test running
git guardrails
session context
protected-path handling

And this bit matters more than it sounds:

Pi now bridges its own lifecycle and tool events to the same hook scripts and exit-code semantics.

That means existing hook logic can run there too, and user-defined hooks can be layered on top instead of rebuilding the whole thing from scratch.

Same guardrails. More than one agent. Much better.

Recent v4 work also made the file-protection hook understand Codex patch-based edits, not just simple file writes.

If an agent can edit multiple files in one patch, your guardrails need to understand patches.

Otherwise it is not a guardrail.

It is decoration.

What it is for

Use it if you work with coding agents and want reusable workflows for:

code review and fixes
Go, Python, TypeScript, web, infra
docs, tests, research, worktrees
spec-driven development
multi-agent planning and review
boring safety checks before expensive mistakes

Repo

GitHub: https://github.com/alexei-led/cc-thingz

It is opinionated because neutral tools become mush.

Built from daily use, not from a weekend prompt dump with a logo.

Pumba v1.1.0: Native Podman Support, and What "Docker-Compatible API" Actually Means

Alexei Ledenev — Fri, 24 Apr 2026 14:56:40 +0000

Pumba — a container chaos CLI I've maintained since 2016 — just shipped v1.1.0 with native Podman runtime support alongside Docker and containerd.

I'd expected this to be the quiet release. Podman advertises a Docker-compatible API. The Docker SDK connects to its socket and most calls work unchanged. That part turned out to be true.

What I didn't expect: the 10% where it doesn't match are exactly the calls a chaos tool lives on.

The landmines

1. `ContainerExecStart` with empty options

Docker accepts ExecStartOptions{} — no AttachStdout, no AttachStderr, no Detach. Podman rejects it outright: "must provide at least one stream to attach to." Four callsites in pumba (tc exec, iptables exec, exec-on-container, command-existence check) had to switch from ContainerExecStart to ContainerExecAttach + drain + ContainerExecInspect. About sixty test mocks needed updating for flags Docker didn't require.

2. Cgroup path divergence

Docker: docker-<id>.scope
Podman: libpod-<id>.scope
Podman + systemd: often nests a libpod-<id>.scope/container/ leaf as libpod's init sub-cgroup
cgroup v2 forbids processes in internal nodes, so stress-ng sidecars must target the nested leaf when it exists
Podman's default cgroupns=private means /proc/self/cgroup inside the target is 0::/ — ancestry hidden

Pumba now reads /proc/<pid>/cgroup host-side. Which means pumba must run on the same kernel as the targets. On macOS: inside the podman machine VM. Same pattern we already used for containerd-in-Colima.

3. Sidecar reap

tc sidecars run tail -f /dev/null as PID 1. PID 1 ignores SIGTERM. Podman's DELETE-with-force sends SIGTERM, waits StopTimeout (default 10s), then SIGKILLs. Every netem call was paying 10s per cleanup. Fix: StopSignal: "SIGKILL" on the sidecar. Immediate reap.

4. Cleanup vs. caller cancellation

If pumba itself is SIGTERM'd between tc exec and sidecar removal, the cleanup defer never runs — sidecar leaks and the netem qdisc persists on the target's netns. Cleanup now uses context.WithoutCancel(ctx) with a 15s budget so the defer actually survives cancellation.

What's not in the release (honestly)

Rootless Podman support. Detected at client init from Info.SecurityOptions; netem/iptables/stress fail fast with guidance (podman machine set --rootful or the rootful systemd unit). Doing rootless correctly needs slirp4netns/pasta netns handling and user-namespace cgroup math — that's a release of its own, not a marketing-shaped hack.

The broader lesson

"Compatible API" is usually harder to integrate against than "completely different API." With a different API you build a fresh mental model and check every call. With a compatible one you assume parity and discover the exceptions empirically.

CCGram - Control AI Coding Agents from Your Phone via Telegram and tmux

Alexei Ledenev — Mon, 16 Mar 2026 12:27:11 +0000

AI coding agents — Claude Code, Codex CLI, Gemini CLI — run in your terminal. When you step away from your desk, the session keeps working, but you lose visibility and control. Especially when the agent hits a permission prompt or needs your input.

CCGram fixes this. It bridges Telegram to tmux so you can monitor and control your agents from your phone.

The key insight: operate on tmux, not on SDKs

Your agent runs in a tmux window on your machine. CCGram reads its transcript output and forwards it to a Telegram Forum topic. You type in Telegram — keystrokes go to the agent's tmux pane. Walk away from your laptop, keep the conversation going. Come back, tmux attach, full scrollback. Nothing lost.

Other Telegram bots wrap agent SDKs to create isolated API sessions that can't be resumed in your terminal. CCGram is different — it's a thin control layer over tmux.

One topic, one window, one agent

Each Telegram Forum topic binds to one tmux window running one agent session. You can run Claude Code, Codex CLI, and Gemini CLI in parallel across different topics.

Creating a session: open a Telegram topic, send any message. A directory browser appears — pick your project directory, choose the agent (Claude, Codex, or Gemini), choose the mode (Standard or YOLO), and you're connected.

Or create a tmux window manually, start an agent — CCGram auto-detects the provider and creates a matching topic.

Interactive prompts as inline keyboards

When your agent asks for permission, approval, or input, CCGram renders the prompt as Telegram inline keyboard buttons. Tap to approve — no typing "yes" or copying options.

This works across providers:

Claude Code: AskUserQuestion, ExitPlanMode, permissions
Codex: edit approvals (reformatted with compact summary + diff preview), selection prompts
Gemini: action-required prompts from @inquirer/select

Claude Code: deepest integration

Claude Code gets 7 hook event types — SessionStart, Notification, Stop, SubagentStart, SubagentStop, TeammateIdle, TaskCompleted. These provide instant session tracking and notifications rather than polling.

Multi-pane support for agent teams: blocked panes in non-active panes are auto-surfaced as inline keyboard alerts. /panes command shows all panes with status and per-pane screenshot buttons.

Session management

Recovery: when a session dies, the bot offers Fresh (new session), Continue (last conversation), or Resume (pick from past sessions). Buttons adapt to provider capabilities.
Sessions dashboard (/sessions): overview of all active sessions with status and kill buttons.
Message history (/history): paginated browsing of past messages.
Terminal screenshots: capture the current pane as a PNG image — useful for visual context.
Auto-close: done topics close after 30 minutes, dead sessions after 10. Configurable or disabled.
Provider commands: /commands shows all slash commands available for that topic's agent. Menus auto-switch per provider context.

Operations

Multi-instance: run separate bots per Telegram group on the same machine, sharing a single bot token. Each instance has its own tmux session, config, and state.
tmux auto-detection: start ccgram inside an existing tmux session — it discovers all agent windows, no creation needed.
Emdash integration: auto-discovers emdash-managed tmux sessions with zero configuration.
Diagnostics: ccgram doctor validates setup, checks hooks, finds orphan processes. ccgram doctor --fix auto-fixes.
Persistent state: thread bindings, read offsets, window states survive restarts.
Run as service: systemd unit, launchd plist, or detached tmux.

Install

  uv tool install ccgram

Alternatives: pipx install ccgram, brew install alexei-led/tap/ccgram

Configure a Telegram bot token via BotFather, enable Topics, add to a group, set your user ID in ~/.ccgram/.env, run ccgram.

For Claude Code, install hooks for best experience: ccgram hook --install

Links

GitHub: https://github.com/alexei-led/ccgram
PyPI: https://pypi.org/project/ccgram
Documentation: https://github.com/alexei-led/ccgram/blob/main/docs/guides.md

MIT licensed, Python. If you run AI coding agents and want mobile access without losing your terminal workflow — give it a try. Contributions and feedback welcome.

Hope you find this useful.

Kubernetes 1.33: Resizing Pods Without the Drama (Finally!) 🎉

Alexei Ledenev — Fri, 16 May 2025 13:32:12 +0000

Ever found yourself in that classic Kubernetes predicament? You meticulously set up your pod resources, patted yourself on the back, deployed to production... and then reality hits. Your application is either gasping for resources like a marathon runner at mile 25, or it's hoarding CPU like it's preparing for the computing apocalypse.

What happens next? In the dark ages of pre-1.33 Kubernetes, you'd have to restart the poor pod! It was like performing open-heart surgery just to adjust someone's diet.

But rejoice, fellow Kubernetes wranglers! Version 1.33 has arrived bearing gifts, and the showstopper is in-place pod vertical scaling in beta and enabled by default! 🎁

What Is This Sorcery? 🧙‍♂️

In-place pod resizing allows you to change the CPU and memory allocations of running pods without restarting them. Let that sink in for a second.

No restarts. No connection drops. No disruption. Just smooth resource adjustment while your application keeps humming along.

It works by making the resources.requests and resources.limits in your pod spec mutable - they can be changed on the fly without triggering a pod recreation. This is made possible through the new resize subresource feature and kubelet's ability to dynamically reconfigure container cgroups.

Why Should You Care? 🤔

If you're thinking "neat trick, but why does it matter?", consider these scenarios:

Stateful Applications - Your database pod suddenly needs more memory during a heavy analytics query. Previously: restart required, connections dropped, cache flushed. Now: bump the memory, carry on!
Cost Optimization - Over-provisioning "just in case" becomes unnecessary. Start conservative, scale up only when needed, scale down when the traffic subsides.
Performance Tuning - Experiment with different resource allocations to find the sweet spot, without annoying your users or operation teams.
Spiky Workloads - That batch job that needs tons of resources for 5 minutes every hour? No more choosing between wasting resources or constant restarts.

Under the Hood: How It Works 🔧

When you resize a pod, here's what happens:

You update the pod's resource specification using the new resize subresource
Kubelet validates the request against node capacity
If approved, kubelet instructs the container runtime to adjust cgroups
Container runtime updates the limits without restarting
The pod status is updated to reflect the new allocations

The pod can report its resize status through conditions:

PodResizePending - Can't resize right now (reasons include Infeasible or Deferred)
PodResizeInProgress - Changes are being applied

Show Me the Code! 💻

Here's a simple example that demonstrates this feature in action:

# Create a resource-monitoring pod
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  containers:
  - name: resource-watcher
    image: ubuntu:22.04
    command:
    - "/bin/bash"
    - "-c"
    - |
      apt-get update && apt-get install -y procps bc
      echo "=== Pod Started: $(date) ==="

      # Functions to read container resource limits
      get_cpu_limit() {
        if [ -f /sys/fs/cgroup/cpu.max ]; then
          # cgroup v2
          local cpu_data=$(cat /sys/fs/cgroup/cpu.max)
          local quota=$(echo $cpu_data | awk '{print $1}')
          local period=$(echo $cpu_data | awk '{print $2}')

          if [ "$quota" = "max" ]; then
            echo "unlimited"
          else
            echo "$(echo "scale=3; $quota / $period" | bc) cores"
          fi
        else
          # cgroup v1
          local quota=$(cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us)
          local period=$(cat /sys/fs/cgroup/cpu/cpu.cfs_period_us)

          if [ "$quota" = "-1" ]; then
            echo "unlimited"
          else
            echo "$(echo "scale=3; $quota / $period" | bc) cores"
          fi
        fi
      }

      get_memory_limit() {
        if [ -f /sys/fs/cgroup/memory.max ]; then
          # cgroup v2
          local mem=$(cat /sys/fs/cgroup/memory.max)
          if [ "$mem" = "max" ]; then
            echo "unlimited"
          else
            echo "$((mem / 1048576)) MiB"
          fi
        else
          # cgroup v1
          local mem=$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes)
          echo "$((mem / 1048576)) MiB"
        fi
      }

      # Print resource info every 5 seconds
      while true; do
        echo "---------- Resource Check: $(date) ----------"
        echo "CPU limit: $(get_cpu_limit)"
        echo "Memory limit: $(get_memory_limit)"
        echo "Available memory: $(free -h | grep Mem | awk '{print $7}')"
        sleep 5
      done
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "100m"
EOF

After your pod is running, double the CPU:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"resource-watcher", "resources":{"requests":{"cpu":"200m"}, "limits":{"cpu":"200m"}}}]}}'

Check the pod logs, and you'll see the CPU limit magically change from 0.100 cores to 0.200 cores without any restart!

Control the Resize Behavior with resizePolicy ⚙️

Sometimes you do want a restart when changing certain resources. For example, many applications can't dynamically adjust to memory changes without restarting. That's where resizePolicy comes in:

resizePolicy:
- resourceName: cpu
  restartPolicy: NotRequired     # Live CPU tweaks!
- resourceName: memory
  restartPolicy: RestartContainer  # Safer memory changes

With this configuration, CPU changes happen in-place, but memory changes trigger a container restart.

The Fine Print: Limitations 📜

While this feature is cooler than a penguin in sunglasses, it does have some limitations:

Windows Support: None yet, only Linux containers
Resource Types: Only CPU and memory can be resized in-place
QoS Class Immutability: You can't change a pod's QoS class through resizing
Memory Decrease: You can't decrease memory limits without a restart (unless using RestartContainer policy)
Special Pods: Pods with static CPU/memory management policies can't use this feature
Cluster Requirements: Requires Kubernetes 1.33+ with a compatible container runtime

What This Means for VPA 🤖

The Vertical Pod Autoscaler has long been the awkward cousin at the Kubernetes scaling family reunion. Its main limitation? It had to recreate pods to adjust resources.

While VPA doesn't yet support in-place resizing in Kubernetes 1.33, this feature lays the groundwork for future integration. Soon, we might see VPA attempting in-place resizes first, falling back to recreation only when necessary.

Until then, you can use VPA in "Off" mode to get recommendations, then apply them manually via in-place resizing.

Conclusion: A Smoother Vertical Scaling Future 🚀

In-place pod resizing in Kubernetes 1.33 is a game-changer for vertical scaling workflows. It removes one of the most significant barriers to efficient resource management - the disruption caused by pod recreation.

Whether you're fine-tuning performance, responding to traffic spikes, or optimizing cloud costs, the ability to adjust resources without service interruption opens up new possibilities for Kubernetes-based applications.

Give it a try in your non-production clusters, and prepare to say goodbye to the "restart to resize" era of Kubernetes!

For the full blog post including more details, examples, and the future of vertical scaling in Kubernetes, check out my article on Medium.

KubeIP v2: Assigning Static Public IPs to Kubernetes Nodes Across Cloud Providers

Alexei Ledenev — Thu, 23 May 2024 14:55:38 +0000

Kubernetes nodes can benefit from having dedicated static public IP addresses in certain scenarios. KubeIP, an open-source utility, fulfills this need by assigning static public IPs to Kubernetes nodes. The latest version, KubeIP v2, extends support from Google Cloud's GKE to Amazon's EKS, with a design ready to accommodate other cloud providers. It operates as a DaemonSet, offering improved reliability, configuration flexibility, and user-friendliness over the previous Kubernetes controller method. KubeIP v2 supports assigning both IPv4 and IPv6 addresses.

Use Cases

Gaming Applications

In gaming scenarios, a console may need to connect directly to a cloud VM to minimize network hops and latency. Assigning a dedicated public IP to the gaming server's node allows the console to connect directly, improving the gaming experience by reducing latency and packet loss.

Whitelisting Agent IPs

If you have multiple agents or services running on Kubernetes that require direct connections to an external server and that server needs to whitelist the agents' IP addresses, using KubeIP to assign stable public IPs to the nodes makes this easier to manage than allowing broader CIDR ranges. This is particularly useful when the external server has strict IP-based access controls.

Avoiding SNAT for Select Pods

By default, pods are assigned private IPs from the VPC CIDR range. When they communicate with external IPv4 addresses, the Amazon VPC CNI plugin translates the pod's IP to the primary private IP of the node's network interface using SNAT (source network address translation). Sometimes, you may want to avoid SNAT for certain pods so that external services see the actual pod IPs. Assigning public IPs to nodes with KubeIP and setting hostNetwork: true on the pod spec achieves this. The pod can communicate directly with external services using the node's public IP.

Direct Inbound Connections and Custom Networking Scenarios

Assigning public IPs to nodes with KubeIP enables a variety of networking scenarios. For instance, you can forward traffic directly to pods running on those nodes, which is useful when you need to expose services on the node to the internet without using a traditional load balancer. An example would be running a web server on a pod and forwarding traffic to it using the node's public IP.

In addition, KubeIP can be used to implement custom networking scenarios that require public IPs on nodes. For example, you could create a custom load balancer that forwards traffic to specific nodes based on the public IP. This flexibility makes KubeIP a powerful tool for testing or deploying custom networking solutions in Kubernetes.

IPv6 Support

KubeIP extends its functionality beyond IPv4 by supporting the assignment of static public IPv6 addresses to nodes. This feature is increasingly important as the internet continues transitioning towards IPv6 due to the exhaustion of IPv4 addresses. With KubeIP's IPv6 support, you can assign static public IPv6 addresses to your Kubernetes nodes, enabling them to communicate directly with external services over IPv6. This is particularly beneficial for applications that require IPv6 connectivity.

Conclusion

KubeIP v2 is a powerful tool for assigning static public IPs to Kubernetes nodes across cloud providers. It enables a wide range of use cases, from gaming applications to custom networking scenarios, and supports both IPv4 and IPv6 addresses. The extensible design and simplified DaemonSet model make it easy to deploy and manage in your environment.

Get Involved

As an open-source project, we welcome contributions! Submit pull requests, open issues, help with documentation, or spread the word.

For more details, check out the original Medium post.

spotinfo - cli for exploring AWS Spot instances

Alexei Ledenev — Sun, 16 May 2021 15:17:23 +0000

The spotinfo is an open-source command-line tool you can use for exploring AWS Spot instances across multiple AWS regions.

Under the hood, the tool uses the same data feeds as AWS Spot Advisor and AWS Spot Pricing.

Compared with the AWS Spot Advisor, the spotinfo supports advanced filtering and sorting (also with regex), in-place spot prices, cross-region comparison, and multiple output formats (plain text, JSON, table, csv).

A short overview is available on DoiT blogs here

DEV Community: Alexei Ledenev

cc-thingz v6: portable skills and hooks for AI coding agents

What it is

What developers get

Why hooks matter

What is new in v6

Why these skills are better than random prompts

1. They come from daily use

2. They are agent-native

3. They include hooks

4. They compose

5. The source of truth is shared

Should you try it?

Install

CCGram v4: Control AI Coding Agents from Telegram — Now with herdr Support

What is herdr?

What changes when you use the herdr backend

Adaptive topic labels

Workspace picker in /new

Only agent tabs surface as topics

Native agent status

Session re-resolution after restart

Protocol version pinning

Same Claude Code hook

Architecture: the multiplexer seam

Quick start with herdr

Install

cc-thingz v4: portable AI coding workflows, now properly multi-agent

Why v4 exists

What that buys you

The infra got more serious too

The part I care about most: multi-agent support

Hooks got properly portable too

What it is for

Repo

Pumba v1.1.0: Native Podman Support, and What "Docker-Compatible API" Actually Means

The landmines

1. ContainerExecStart with empty options

2. Cgroup path divergence

3. Sidecar reap

4. Cleanup vs. caller cancellation

What's not in the release (honestly)

The broader lesson

Links

CCGram - Control AI Coding Agents from Your Phone via Telegram and tmux

The key insight: operate on tmux, not on SDKs

One topic, one window, one agent

Interactive prompts as inline keyboards

Claude Code: deepest integration

Session management

Operations

Install

Kubernetes 1.33: Resizing Pods Without the Drama (Finally!) 🎉

What Is This Sorcery? 🧙‍♂️

Why Should You Care? 🤔

Under the Hood: How It Works 🔧

Show Me the Code! 💻

Control the Resize Behavior with resizePolicy ⚙️

The Fine Print: Limitations 📜

What This Means for VPA 🤖

Conclusion: A Smoother Vertical Scaling Future 🚀

KubeIP v2: Assigning Static Public IPs to Kubernetes Nodes Across Cloud Providers

Use Cases

Gaming Applications

Whitelisting Agent IPs

Avoiding SNAT for Select Pods

Direct Inbound Connections and Custom Networking Scenarios

IPv6 Support

Conclusion

Get Involved

spotinfo - cli for exploring AWS Spot instances

Workspace picker in `/new`

1. `ContainerExecStart` with empty options