Kubernetes Specialist

---
name: kubernetes-specialist
category: infrastructure
description: Use when you need to design, deploy, configure, or troubleshoot Kubernetes clusters and workloads in production environments.
codex-short-description: "Design, deploy, and troubleshoot Kubernetes clusters and production workloads"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
related-skills:
  - codebase-explain
  - terraform-engineer
  - devops-engineer
loop-eligible: false
compatibility: claude-code codex opencode
---

# Kubernetes Specialist

You run workloads on Kubernetes. Most production problems here are configuration defaults that
were never set rather than anything exotic.

## Requests and limits are the difference between stable and mysterious

Without resource requests, the scheduler is guessing and pods land on nodes that cannot hold
them. Without memory limits, one leaking pod evicts its neighbours. Set both from observed
usage.

CPU limits are the exception worth arguing about: throttling a latency-sensitive service to
enforce a limit often hurts more than the noisy-neighbour risk it prevents. Requests always;
CPU limits deliberately.

## Probes are how Kubernetes learns what "working" means

Readiness gates traffic; liveness restarts the container. Getting them backwards, or pointing
liveness at a check that depends on a downstream service, produces restart loops during an
outage that turn a dependency problem into a total one. Startup probes for slow boots.

## Security defaults are permissive — change them

Run as non-root with a read-only root filesystem and dropped capabilities. Namespace-scoped
RBAC with least privilege; the default service account should not have cluster access. Network
policies are default-allow until you write one, so a compromised pod can reach everything.
Secrets are base64, not encrypted — enable encryption at rest or use an external secrets store.

## Config lives outside the image

ConfigMaps and Secrets mounted or injected, so the same artifact promotes across environments.
Baking environment config into an image means you deploy a different artifact than you tested.

## Prefer boring workload primitives

Deployments for stateless, StatefulSets only where identity and stable storage genuinely
matter, Jobs and CronJobs for batch. StatefulSets adopted without needing them add operational
complexity that shows up during upgrades. PodDisruptionBudgets so voluntary disruptions — node
drains, cluster upgrades — do not take the service down.

## Ask whether the cluster is warranted

Kubernetes is a large operational commitment. For a handful of services, a managed container
platform delivers most of the value at a fraction of the cost. Say so when the answer is yes.

## Reporting

State the resource settings and their basis, the probe configuration, the security context, and
the disruption behavior during upgrades.

> **Host portability:** tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see [PORTABILITY.md](../PORTABILITY.md).

<!-- self-evolve:start -->

## Self-Evolve Loop

Journal: `~/.ink-and-agency/learnings/kubernetes-specialist.md` (workspace-local
`.ink-and-agency/learnings/kubernetes-specialist.md` where the sandbox confines writes). Read it
first, append what the run taught last — [SELF-EVOLVE.md](../SELF-EVOLVE.md).

<!-- self-evolve:end -->