30 Claude Prompts for Kubernetes

You are a Helm chart author who structures charts so other engineers can actually maintain them later. <context> I am packaging an application into a Helm chart for the first time and want a sensible directory and template structure before I start writing YAML. </context> <inputs> - Application type: [APP TYPE, e.g. stateless API, worker, database] - Kubernetes objects needed: [OBJECT LIST, e.g. Deployment, Service, HPA] - Number of environments to support: [ENVIRONMENT COUNT] - Chart name: [CHART NAME] - Chart repository this will be published to: [CHART REPOSITORY] </inputs> <task> Lay out the chart directory structure, list which values belong in values.yaml versus which should stay hardcoded in templates, and show the skeleton of the Chart.yaml file. </task> <constraints> Follow the standard Helm chart layout, do not invent nonstandard directories. Keep values.yaml keys flat where possible and only nest where the object genuinely needs a sub-structure. </constraints> <format> Return a file tree in a code block, then a fenced yaml block for Chart.yaml, then a short list of values.yaml keys with one line each on purpose. </format>

You are a Helm maintainer who cleans up values files that have grown messy across environments. <context> My values.yaml has grown into a tangle of environment-specific overrides and I want it restructured so staging and production stay clearly separated without duplicating the whole file. </context> <inputs> - Current values.yaml: [PASTE VALUES YAML] - Environments in use: [ENVIRONMENT LIST] - Fields that differ by environment: [DIFFERING FIELDS] </inputs> <task> Refactor this into a base values.yaml plus per-environment override files, showing exactly which keys move where and how the helm upgrade command should be invoked to layer them. </task> <constraints> Do not change any value, only reorganize where each key lives. Keep the override files as small as possible, only the fields that actually differ. </constraints> <format> Return the base values.yaml, then each override file, then the exact helm upgrade command for one environment as an example. </format>

You are a Helm template debugging specialist who reads Go template syntax fluently. <context> Helm template or helm install is failing on my chart and the error message is not pointing clearly at the broken line. </context> <inputs> - Error output: [PASTE ERROR OUTPUT] - Template file causing the issue: [PASTE TEMPLATE FILE] - Relevant values.yaml section: [PASTE VALUES SECTION] </inputs> <task> Find the exact line and syntax problem causing the failure, explain why the Go template engine is rejecting it, and give me the corrected template. </task> <constraints> Do not rewrite parts of the template that are not related to the error. If the error is actually a missing value rather than a syntax problem, say so explicitly. </constraints> <format> Return the diagnosis in two sentences, then a fenced code block with only the corrected lines and enough surrounding context to locate them. </format>

You are a Helm chart maintainer who audits subchart dependencies for version and configuration risk. <context> My chart pulls in subchart dependencies and I want to know if any of them are pinned to risky versions or configured in a way that will surprise me on the next upgrade. </context> <inputs> - Chart.yaml dependencies block: [PASTE DEPENDENCIES BLOCK] - Overrides set for each dependency: [PASTE OVERRIDE VALUES] - Helm version in use: [HELM VERSION] </inputs> <task> Review each dependency's version constraint, flag any that use a floating range instead of a pinned version, and check whether the override values I set actually match keys the subchart exposes. </task> <constraints> Only comment on the dependencies I listed, do not speculate about charts not shown. If you cannot verify a subchart's exposed keys without its source, say so rather than guessing. </constraints> <format> Return a table with columns: Dependency, Version Constraint, Risk, Recommendation. </format>

You are a release engineer who plans safe Helm upgrades with a clear rollback path. <context> I am about to run a Helm upgrade on a production release and want a rollback plan written down before I execute it, not improvised after something breaks. </context> <inputs> - Release name: [RELEASE NAME] - Namespace: [NAMESPACE] - Change being made: [CHANGE DESCRIPTION] - Current chart version and target version: [CURRENT AND TARGET VERSION] </inputs> <task> Write out the exact helm upgrade command with the correct flags, the health checks to run immediately after, and the exact helm rollback command to use if those checks fail. </task> <constraints> Include the --atomic and timeout flags where appropriate and explain what they do. Do not assume a specific monitoring tool, describe checks in terms of kubectl output anyone can run. </constraints> <format> Return three labeled sections: Upgrade Command, Post-Upgrade Checks, Rollback Command. </format>

You are an on-call Kubernetes engineer who diagnoses crashing pods under time pressure. <context> A pod is stuck in CrashLoopBackOff and I need to find the actual root cause fast, not a generic list of possible reasons. </context> <inputs> - kubectl describe pod output: [PASTE DESCRIBE OUTPUT] - kubectl logs output, previous container: [PASTE LOGS --PREVIOUS] - Recent change made before this started: [RECENT CHANGE] </inputs> <task> Walk through the describe output and the previous logs together to identify the most likely root cause, ranked by probability given the exit code and events shown. </task> <constraints> Do not list every theoretical cause of CrashLoopBackOff, only the ones supported by evidence in what I pasted. Reference the specific exit code or event line for each theory. </constraints> <format> Return a ranked list, most likely cause first, each with the supporting evidence quoted and a suggested next command to confirm it. </format>

You are a Kubernetes scheduler specialist who explains why pods will not place onto nodes. <context> A pod has been stuck in Pending state and I need to know exactly which scheduling constraint is blocking it. </context> <inputs> - kubectl describe pod events section: [PASTE EVENTS SECTION] - Pod's resource requests: [RESOURCE REQUESTS] - Node affinity or taint rules in play: [AFFINITY OR TAINT RULES] - Cluster autoscaler status: [AUTOSCALER STATUS, e.g. enabled, disabled, unknown] </inputs> <task> Identify whether this is a resource shortage, a taint or toleration mismatch, an affinity rule with no matching node, or a PodDisruptionBudget conflict, based only on the events I pasted. </task> <constraints> Quote the specific FailedScheduling message text you are reasoning from. If the autoscaler status is unknown, say what to check instead of assuming it will add capacity. </constraints> <format> Return the diagnosis in one paragraph, then a numbered list of commands to run to confirm and resolve it. </format>

You are a Kubernetes networking troubleshooter who traces traffic failures between services. <context> One service cannot reach another inside the cluster and I need to isolate whether this is DNS, the Service object, a NetworkPolicy, or the target pod itself. </context> <inputs> - Source and target service names: [SOURCE AND TARGET SERVICE] - Error seen from the source pod: [ERROR MESSAGE] - Relevant NetworkPolicy manifests, if any: [NETWORK POLICY YAML OR NONE] - CNI plugin in use: [CNI PLUGIN] </inputs> <task> Lay out the exact sequence of checks to isolate the failure point, starting with DNS resolution, then Service endpoint population, then NetworkPolicy rules, then the target pod's own listener. </task> <constraints> Give the exact kubectl or debug pod commands for each step, not just descriptions. Note that CNI plugins enforce NetworkPolicy differently, so name what changes if the CNI does not support policies at all. </constraints> <format> Return a numbered sequence of steps, each with the command and what result would mean. </format>

You are a cluster operations engineer who investigates node-level pressure conditions. <context> One of my nodes is reporting a pressure condition and pods are being evicted, and I need to understand what is actually running out on that node. </context> <inputs> - kubectl describe node output, conditions section: [PASTE CONDITIONS SECTION] - Node's total capacity and allocatable: [CAPACITY AND ALLOCATABLE] - Pods running on the node and their resource requests: [POD LIST WITH REQUESTS] </inputs> <task> Determine whether this is MemoryPressure, DiskPressure, or PIDPressure, identify the top contributors among the pods listed, and recommend whether to evict, resize requests, or add node capacity. </task> <constraints> Base the contributor ranking only on the requests and limits I gave you, not assumptions about typical workloads. State clearly if the data I gave you is not enough to rank contributors precisely. </constraints> <format> Return the pressure type identified, a ranked list of contributing pods, and one recommended action with reasoning. </format>

You are an incident responder who correlates logs and cluster events into a single timeline. <context> Something went wrong across several pods around the same time and I have logs and events from different sources that I need pulled into one coherent timeline. </context> <inputs> - Pod logs from affected services, with timestamps: [PASTE LOGS WITH TIMESTAMPS] - kubectl get events output for the namespace: [PASTE EVENTS OUTPUT] - Approximate incident window: [TIME WINDOW] </inputs> <task> Build a single chronological timeline merging the log lines and the cluster events, and point out the first event that looks like the trigger versus the ones that look like downstream effects. </task> <constraints> Keep every entry tied to its original timestamp, do not reorder for narrative convenience. If two sources disagree on time due to clock skew, flag it rather than silently merging. </constraints> <format> Return a single timeline table with columns: Time, Source, Event, and a one-line verdict at the bottom naming the likely trigger. </format>

You are a capacity planning engineer who sets resource requests and limits from real usage data. <context> My pods have requests and limits set from guesswork months ago and I want them resized based on actual observed usage. </context> <inputs> - Current requests and limits: [CURRENT REQUESTS AND LIMITS] - Observed usage over the last period, CPU and memory: [OBSERVED USAGE DATA] - Workload type: [WORKLOAD TYPE, e.g. bursty API, steady batch job] - Namespace this workload runs in: [NAMESPACE NAME] </inputs> <task> Recommend new CPU and memory requests and limits based on the observed usage, with headroom appropriate to the workload type, and explain the reasoning for each number. </task> <constraints> Do not simply set requests equal to peak usage, explain the percentile or headroom logic used. Flag if the current limit is set so low it risks throttling or OOMKilled events. </constraints> <format> Return a table with columns: Resource, Current, Recommended, Reasoning. </format>

You are a Kubernetes autoscaling specialist who tunes HorizontalPodAutoscaler behavior. <context> My HorizontalPodAutoscaler is either scaling too aggressively or not reacting fast enough, and I want the configuration reviewed against how the workload actually behaves. </context> <inputs> - Current HPA manifest: [PASTE HPA YAML] - Observed scaling behavior, what is wrong: [DESCRIBE THE PROBLEM] - Traffic pattern, e.g. spiky or gradual: [TRAFFIC PATTERN] </inputs> <task> Review the target metric, threshold, min and max replicas, and scaling behavior policies, then recommend specific changes to fix the problem I described. </task> <constraints> Explain what the stabilization window and scaling policies actually do before changing them, do not just hand back new numbers with no reasoning. Keep min replicas above zero unless I explicitly say this workload can scale to zero. </constraints> <format> Return the current problem restated in one sentence, then the corrected HPA yaml block, then a short explanation of what changed and why. </format>

You are a platform team lead who sets ResourceQuota and LimitRange policy for shared namespaces. <context> Multiple teams share a namespace and I need a ResourceQuota and LimitRange that stops one team from starving the others without being so tight it blocks normal deploys. </context> <inputs> - Namespace name: [NAMESPACE NAME] - Number of teams or workloads sharing it: [TEAM OR WORKLOAD COUNT] - Total node capacity allocated to this namespace: [TOTAL CAPACITY] - Largest single workload's typical footprint: [LARGEST WORKLOAD FOOTPRINT] </inputs> <task> Design a ResourceQuota covering CPU, memory, and object counts, plus a LimitRange with sensible per-container defaults, sized so the largest known workload still fits comfortably. </task> <constraints> Leave enough headroom that a rolling update of the largest workload does not hit the quota mid-rollout. State the assumption behind each number so it can be adjusted later. </constraints> <format> Return two fenced yaml blocks, ResourceQuota then LimitRange, followed by three bullet points on the sizing assumptions made. </format>

You are an infrastructure cost engineer who rightsizes Kubernetes node pools. <context> I think my node pool is oversized or undersized for the workloads running on it and want an analysis before I change the instance type or count. </context> <inputs> - Node instance type and count: [INSTANCE TYPE AND COUNT] - Average and peak cluster CPU and memory utilization: [UTILIZATION DATA] - Pod bin-packing pattern, e.g. many small pods or few large: [BIN-PACKING PATTERN] - Budget constraint if any: [BUDGET CONSTRAINT] </inputs> <task> Analyze whether the current instance type is well matched to the pod sizes running on it, whether a different instance type would pack more efficiently, and what count change would follow. </task> <constraints> Account for the fact that some CPU and memory on every node is reserved for the kubelet and system daemons, do not treat total capacity as fully allocatable. Give a specific alternative instance type only if the pattern clearly calls for one. </constraints> <format> Return a short analysis paragraph, then a recommendation line stating instance type, count, and expected utilization after the change. </format>

You are a FinOps analyst who translates Kubernetes resource usage into a cost report for non-infrastructure stakeholders. <context> I need to explain to a non-technical stakeholder where our Kubernetes spend is going and which workloads are the most wasteful, without burying them in cluster jargon. </context> <inputs> - Namespace or workload level resource requests versus actual usage: [REQUESTS VS USAGE DATA] - Monthly infrastructure spend for the cluster: [MONTHLY SPEND] - Top three most expensive workloads by node share: [TOP WORKLOADS] </inputs> <task> Write a short report translating the utilization gap into approximate wasted spend per workload, and recommend which one or two changes would recover the most cost with the least risk. </task> <constraints> Keep the language free of Kubernetes internals, this is for a stakeholder who does not know what a pod is. Round numbers rather than presenting false precision. </constraints> <format> Return a short narrative summary, then a simple table of Workload, Estimated Waste, Recommended Action. </format>

You are a Kubernetes security engineer who audits RBAC roles for excess permissions. <context> A Role or ClusterRole in my cluster has grown broad over time and I want it cut down to what the ServiceAccount actually needs. </context> <inputs> - Current Role or ClusterRole manifest: [PASTE ROLE YAML] - ServiceAccount it is bound to: [SERVICE ACCOUNT NAME] - What this ServiceAccount's workload actually does: [WORKLOAD PURPOSE] </inputs> <task> Go through each rule in the manifest and decide whether the workload's stated purpose justifies it, then write a tightened version that removes anything unjustified. </task> <constraints> Do not remove a permission if the workload purpose plausibly needs it, only cut clearly excessive grants like wildcard resources or verbs. Flag any use of cluster-admin or wildcard verbs explicitly. </constraints> <format> Return a table of Rule, Justified or Excessive, Reasoning, followed by the tightened yaml block. </format>

You are a Kubernetes security engineer who migrates namespaces from PodSecurityPolicy or unrestricted defaults to Pod Security Standards. <context> I need to move a namespace onto the baseline or restricted Pod Security Standard and want to know what in my existing workloads will break before I flip the label. </context> <inputs> - Namespace name: [NAMESPACE NAME] - Target level: [BASELINE OR RESTRICTED] - Pod specs currently running in the namespace: [PASTE POD SPECS OR KEY FIELDS] </inputs> <task> Check each pod spec against the requirements of the target Pod Security Standard level, list which ones would be blocked or warned on, and show the exact spec changes needed to comply. </task> <constraints> Be specific about which field is non-compliant, for example running as root or a missing seccompProfile, rather than a general statement that a pod fails. Do not recommend privileged mode as a workaround. </constraints> <format> Return a table of Pod or Container, Violation, Required Change, then the corrected snippet for the worst offender. </format>

You are a Kubernetes network security engineer who designs NetworkPolicy objects for zero-trust segmentation. <context> My namespace currently has no NetworkPolicy at all, meaning any pod can talk to any other pod, and I want to lock this down to only the traffic that is actually needed. </context> <inputs> - Namespace name: [NAMESPACE NAME] - Services and their required communication paths: [SERVICE COMMUNICATION MAP] - Traffic that must be allowed from outside the namespace: [EXTERNAL TRAFFIC NEEDS] </inputs> <task> Design a default-deny NetworkPolicy for the namespace plus specific allow policies for each communication path I listed, including any needed ingress from outside the namespace. </task> <constraints> Start from default deny for both ingress and egress, then add only the specific exceptions I described. Do not forget DNS egress, workloads will fail silently without it. </constraints> <format> Return one fenced yaml block per policy, each with a comment naming which communication path it covers. </format>

You are a Kubernetes secrets management auditor who checks how sensitive values move through a cluster. <context> I want an audit of how secrets are currently handled across my manifests, since some may have been set up before we had a real secrets strategy. </context> <inputs> - Manifests or Helm values referencing secrets: [PASTE RELEVANT SECTIONS] - Secrets backend in use, if any: [SECRETS BACKEND, e.g. plain Secret objects, external-secrets, Vault] - Whether Secret objects are encrypted at rest in etcd: [ENCRYPTION AT REST STATUS] - Namespace being audited: [NAMESPACE NAME] </inputs> <task> Identify any place where a sensitive value is stored in plain text in a ConfigMap, an environment variable in a manifest, or committed configuration, versus properly handled through the secrets backend. </task> <constraints> Flag every plain-text sensitive value you find, do not assume any value is non-sensitive just because it lacks an obvious name like password. If encryption at rest status is unknown, say why that matters rather than skipping it. </constraints> <format> Return a table of Location, Value Type, Current Handling, Recommended Handling. </format>

You are a supply chain security engineer who reviews container image and admission policy for a cluster. <context> I want to know how exposed my cluster is to a bad or tampered image getting deployed, based on what admission controls and image policies I currently have. </context> <inputs> - Image tag policy currently used: [IMAGE TAG POLICY, e.g. latest, pinned digest] - Image source registries allowed: [ALLOWED REGISTRIES] - Admission controllers or policies in place, if any: [ADMISSION CONTROLS OR NONE] - Cluster this policy would apply to: [CLUSTER NAME] </inputs> <task> Assess the gaps in the current setup, specifically around mutable tags, unrestricted registries, and missing image signature or vulnerability scanning enforcement, then propose a concrete set of admission policy rules to close the biggest gaps first. </task> <constraints> Prioritize the two or three changes that reduce the most risk, do not hand back an exhaustive list with no ordering. Name a specific admission controller or policy engine only if it fits what is already in place. </constraints> <format> Return a ranked list of gaps with severity, then the top recommended policy rule written out concretely. </format>

You are a GitOps engineer who sets up ArgoCD Application resources for new services. <context> I am onboarding a new service onto our existing ArgoCD instance and need the Application manifest written correctly against our repo structure. </context> <inputs> - Git repo URL and path to the manifests or chart: [REPO URL AND PATH] - Target cluster and namespace: [TARGET CLUSTER AND NAMESPACE] - Sync policy wanted: [SYNC POLICY, e.g. automated with self-heal, manual] - ArgoCD project this Application should belong to: [ARGOCD PROJECT NAME] </inputs> <task> Write the ArgoCD Application manifest pointing at the repo and path I gave you, with the sync policy configured as described, including a sensible retry and prune setting. </task> <constraints> If automated sync is requested, include selfHeal and prune settings explicitly rather than leaving them to defaults. Do not add a Project reference unless I tell you one exists. </constraints> <format> Return one fenced yaml block for the Application manifest, followed by a one-line note on what selfHeal will do in practice. </format>

You are a CI/CD engineer who wires container build pipelines into Kubernetes deployment. <context> I need a CI pipeline that builds a container image on every merge, tags it properly, and updates the deployment manifest or Helm values so a GitOps tool can pick up the change. </context> <inputs> - CI platform: [CI PLATFORM, e.g. GitHub Actions, GitLab CI] - Image registry: [IMAGE REGISTRY] - Deployment method: [DEPLOYMENT METHOD, e.g. GitOps repo update, direct helm upgrade] - Branch or tag trigger: [TRIGGER CONDITION] - Target namespace for the deploy: [TARGET NAMESPACE] </inputs> <task> Write the pipeline configuration that builds the image, tags it with the commit SHA, pushes it to the registry, and updates the deployment reference using the deployment method I specified. </task> <constraints> Tag images with the commit SHA, not latest, so rollbacks are traceable. Use the exact syntax for the CI platform I named, do not mix GitHub Actions and GitLab CI syntax. </constraints> <format> Return one fenced code block with the full pipeline configuration file, with comments marking each stage. </format>

You are a release engineer who designs canary and progressive delivery rollouts for Kubernetes. <context> I want to roll out a risky change gradually instead of all at once, and need a concrete plan for how the traffic shift and rollback triggers should work. </context> <inputs> - Progressive delivery tool available: [DELIVERY TOOL OR NONE YET] - Metric to watch for rollback: [ROLLBACK METRIC] - Total rollout duration wanted: [ROLLOUT DURATION] - Traffic step sizes acceptable: [TRAFFIC STEP SIZE] - Application this rollout applies to: [APPLICATION NAME] </inputs> <task> Design the canary rollout stages, the traffic percentage at each step, the wait time between steps, and the automatic rollback condition tied to the metric I named. </task> <constraints> If no progressive delivery tool is installed yet, note the minimum setup needed before this plan can run, do not assume it exists. Keep the automatic rollback threshold conservative given this is described as risky. </constraints> <format> Return a table with columns: Step, Traffic Percent, Wait Time, Rollback Condition. </format>

You are a GitOps architect who designs repository layouts for multi-cluster, multi-environment deployments. <context> We are moving to a GitOps workflow and I need the repository structure designed so environment promotion is clear and does not require duplicating every manifest. </context> <inputs> - Number of clusters: [CLUSTER COUNT] - Environments per cluster: [ENVIRONMENTS PER CLUSTER] - GitOps tool in use: [GITOPS TOOL, e.g. ArgoCD, Flux] - Number of applications to manage: [APPLICATION COUNT] </inputs> <task> Design the repository directory structure, showing where base manifests live, where overlays or environment-specific values live, and how promotion from one environment to the next would work in this structure. </task> <constraints> Use a base plus overlay pattern rather than fully duplicated manifests per environment. Match the structure to conventions the named GitOps tool expects, Kustomize overlays and Helm value layering are not interchangeable. </constraints> <format> Return a file tree in a code block, then three sentences describing the promotion flow from staging to production. </format>

You are a site reliability engineer who writes clear, blameless postmortems for failed deployments. <context> A recent rollout caused an outage and I need a postmortem written up that captures what happened without turning into a blame document. </context> <inputs> - Timeline of what happened: [TIMELINE OF EVENTS] - What was deployed and by what method: [DEPLOYMENT DETAILS] - Detection method and time to detect: [DETECTION METHOD AND TIME] - Resolution steps taken: [RESOLUTION STEPS] </inputs> <task> Write a postmortem covering summary, timeline, root cause, impact, and specific follow-up action items with owners left as placeholders, following a standard blameless postmortem structure. </task> <constraints> Keep the tone factual and blameless, describe what the system and process allowed rather than who made the mistake. Every action item must be specific enough to be tracked as a ticket, not a vague intention. </constraints> <format> Return the postmortem in labeled sections: Summary, Timeline, Root Cause, Impact, Action Items. </format>