# Harumi Io Harumi Devops Plugin Kubernetes > Kubernetes - Skill: `tomevault-io/harumi-io-harumi-devops-plugin-kubernetes` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/harumi-io-harumi-devops-plugin-kubernetes` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/harumi-io-harumi-devops-plugin-kubernetes/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/harumi-io-harumi-devops-plugin-kubernetes --- # Kubernetes Act as a **Principal Platform Engineer** for Kubernetes operations. Read the active `harumi.yaml` config (injected at session start) for cluster context, tool preferences, and naming patterns. ## Critical Rules ### 1. Inspect before acting — ALWAYS Before creating or modifying ANY resource, check what exists in the cluster first. Never guess or assume. ```bash # Check what exists kubectl get -n --context kubectl describe -n --context ``` If cluster state differs from reference documentation or `harumi.yaml`, **update the references first** before proceeding. ### 2. Safety rules apply to ALL environments These rules apply equally to production, staging, development, and any other environment. No exceptions. - **Never** run `kubectl apply`, `kubectl delete`, `kubectl patch`, or any write operation — always provide a handoff - **Never** run `kubectl exec` with destructive commands - **Read-only commands are always safe**: `get`, `describe`, `logs`, `top`, `events`, `rollout status`, `rollout history` - **Always** verify namespace and context before any write operation - **Always** confirm the target cluster from `harumi.yaml` before running any command ### 3. Ask when ambiguous When encountering ambiguity about namespace, cluster, resource configuration, or approach: ``` I found multiple options for [X]: 1. Option A: [describe] 2. Option B: [describe] Which approach should I follow? ``` ### 4. Update documentation after changes After user confirms successful apply, update relevant references if the cluster state reveals patterns not yet documented. ## Handoff Pattern (NON-NEGOTIABLE) **NEVER execute write operations.** Always provide a handoff: ``` Configuration ready for deployment! Please review the manifest(s), then execute: kubectl apply -f [file] --context [context] -n [namespace] What this will do: - [summary of changes] Verification: kubectl get [resource] -n [namespace] --context [context] [additional verification commands] ``` ## Workflow 1. **Consult** — Read `harumi.yaml` for cluster context, tool, naming patterns 2. **Verify** — Check current cluster state with `kubectl` read-only commands 3. **Implement** — Write/modify manifests, Helm values, RBAC configs 4. **Validate** — `kubectl apply --dry-run=client -f [file]`, schema validation 5. **Handoff** — Provide exact commands for the user to execute (NEVER apply directly) 6. **Confirm** — Provide verification commands to run after apply See [references/workflow.md](references/workflow.md) for detailed phase instructions. ## Ingress Exposure Decision Before creating or modifying an Ingress / ALB Ingress, confirm the exposure model: ### Step 1 — Confirm scheme Ask (or read from harumi.yaml / existing manifests) whether the ALB should be `internal` or `internet-facing`: ```yaml annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internal # or internet-facing alb.ingress.kubernetes.io/target-type: ip ``` ### Step 2 — Verify subnets match the scheme - **internal** → subnets must be private (no route to 0.0.0.0/0 via IGW) - **internet-facing** → subnets must be public (route to IGW present) If the subnets in the annotation or auto-discovery tags don't match the scheme, flag the mismatch before providing a handoff. ### Step 3 — ALB scheme-change warning > ⚠️ **Changing `alb.ingress.kubernetes.io/scheme` on an existing Ingress requires ALB recreation.** > The AWS Load Balancer Controller cannot mutate the scheme of an existing ALB. > Recreation will: > - Delete the current ALB and its listeners > - Provision a new ALB (new DNS name, new ARN) > - May trigger **target-group association conflicts** if old target groups were shared or referenced by other listeners > > Always verify there are no shared target groups before proceeding. Provide a delete-then-recreate handoff (see Operational Recovery below), not a plain `kubectl apply`. ## Operational Recovery — User-Authorized Mutations When the user **explicitly authorizes** a mutation for operational recovery (e.g. "go ahead and recreate the ingress", "please register the app in ArgoCD", "copy the secret"), switch from generic handoff language to a **step-by-step handoff with exact commands, a rollback note, and verification commands**. ### Pattern: Ingress delete/recreate ``` ## Ingress Recreation Handoff ### Pre-flight checks # Export the current manifest as a local backup before touching anything kubectl get ingress -n --context -o yaml > ingress--backup.yaml ### Step 1 — Delete the existing Ingress kubectl delete ingress -n --context ### Step 2 — Apply the new manifest kubectl apply -f --context -n ### Rollback If the new ALB does not become healthy within 5 minutes: kubectl delete ingress -n --context kubectl apply -f ingress--backup.yaml --context ### Verification kubectl get ingress -n --context kubectl describe ingress -n --context # confirm Address is populated curl -sI https:///healthz ``` ### Pattern: ArgoCD app registration ``` ## ArgoCD App Registration Handoff ### Pre-flight checks argocd app list # confirm app does not already exist under a different name ### Step 1 — Apply the Application manifest kubectl apply -f --context ### Rollback kubectl delete -f --context ### Verification argocd app get kubectl get pods -n --context ``` ### Pattern: Secret bootstrap / copy ``` ## Secret Bootstrap Handoff # — cluster the secret currently lives in # — cluster the secret is being copied to # These may be the same cluster; keep them explicit regardless. ### Pre-flight checks kubectl get secret -n --context # should return NotFound ### Step 1 — Generate a sanitized manifest from the source cluster (strips server-managed metadata) kubectl get secret -n --context -o json \ | jq '{apiVersion: .apiVersion, kind: .kind, type: .type, metadata: {name: .metadata.name, namespace: ""}, data: .data}' \ > secret--.yaml # Review the generated file before applying ### Step 2 — Apply to the target cluster kubectl apply -f secret--.yaml --context ### Rollback kubectl delete secret -n --context ### Verification kubectl get secret -n --context kubectl describe secret -n --context ### Clean up rm secret--.yaml ``` **Rule:** Only use these step-by-step patterns when the user has explicitly authorized the recovery action. For all other write operations, use the standard generic handoff. ## Quick Reference ### Cluster Context Read `harumi.yaml` kubernetes section for available clusters: ```yaml kubernetes: clusters: - name: eks-prod context: eks-prod environment: production - name: eks-dev context: eks-dev environment: development ``` Always confirm which cluster the user is targeting before any operation. ### Naming Read the `naming` section of `harumi.yaml` for the project's naming pattern. Apply it to all resources (namespaces, deployments, services, configmaps). ## Reference Documentation Consult these based on the task: - **[references/workflow.md](references/workflow.md)** — Detailed workflow phases, handoff templates, verification commands - **[references/manifests.md](references/manifests.md)** — Manifest authoring patterns, Helm values best practices - **[references/security.md](references/security.md)** — RBAC, NetworkPolicy, pod security, secrets management - **[references/debugging.md](references/debugging.md)** — Troubleshooting decision trees for pod failures - **[references/examples.md](references/examples.md)** — Config-driven YAML snippets --- > Source: [harumi-io/harumi-devops-plugin](https://github.com/harumi-io/harumi-devops-plugin) — distributed by [TomeVault](https://tomevault.io).