agentsclimarketplace
Sign in

Kubernetes workloads

Skill Amey-Thakur/AI-SKILLS/skills/cloud/kubernetes-workloads

Configure Kubernetes workloads with correct requests, probes, disruption budgets, and workload types. Use when deploying services to Kubernetes or debugging evictions, OOMKills, and rollout failures.From its SKILL.md

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill kubernetes-workloads

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 22 days oldThe repository was created 22 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, 702 tokens by cl100k_base, as published. Nobody here has run it

Kubernetes workloads

The scheduler and the kubelet only know what you declare. Most production pain (evictions, OOMKills, dropped requests during deploys) is a missing or dishonest declaration.

Method

  1. Pick the controller for the lifecycle. Deployment for stateless services; StatefulSet only for stable identity/storage (databases, ordered clusters); DaemonSet for per-node agents; Job/CronJob for run-to-completion (with backoffLimit, activeDeadlineSeconds, and idempotent work; see background-jobs). Wrong controller choices surface as workarounds everywhere else.
  2. Set requests from measurement; cap memory, not CPU. Requests are the scheduling contract: set them at observed p95 (see get-available-resources thinking: measure, then declare). Memory limit = request (Guaranteed-ish, avoids surprise OOM from overcommit); CPU limit usually omitted, since throttling a bursty service hurts more than sharing. OOMKilled pods mean the limit lies or the app leaks (see memory-leaks).
  3. Wire all three probes honestly. Liveness = process health only; readiness = can serve (dependencies); startup covers slow boots so liveness can stay tight; full reasoning in health-checks. Probe mistakes convert dependency blips into restart storms.
  4. Make deploys and evictions dropless. preStop sleep a few seconds + SIGTERM handling (see graceful-shutdown), terminationGracePeriodSeconds above request timeout; PodDisruptionBudget (maxUnavailable: 1 or a floor) so node drains and cluster upgrades cannot take the whole service; spread across zones with topologySpreadConstraints, and 2+ replicas or the PDB is fiction.
  5. Autoscale on the right signal. HPA on CPU works for CPU-bound services; queue-driven workers scale on queue depth/age (external metrics, KEDA-style); latency-critical paths scale on concurrency or RPS. Set sensible min (cold-start floor) and max (protects downstream; see backpressure), and never HPA+VPA on the same metric.
  6. Declare the security posture per pod. runAsNonRoot, readOnlyRootFilesystem, drop all capabilities, no default ServiceAccount token unless the pod calls the API; resource-scoped RBAC when it does (container hardening detail in container-security).
  7. Config and secrets flow in declaratively. ConfigMaps/Secrets mounted or injected, rotated by rollout (checksum annotations trigger it); no config fetched at boot from wikis or hand-edited in place (see config-management).

Boundaries

  • This covers workload manifests; cluster architecture (node pools, CNI, ingress controllers, upgrade cadence) is platform work with its own review.
  • If every service copies the same 200 lines of YAML, the fix is a shared chart/kustomize base owned by platform, not more copying.
  • Local dev parity via mini-clusters has limits; test the manifests in a real staging cluster before trusting probes and budgets.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most containers cloud skills give in 702 tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • match controller type to workload lifecycle
  • set resource requests from measured p95 values
  • omit CPU limits for bursty services
  • configure graceful shutdowns and termination grace periods
  • spread replicas across topology zones
  • autoscale using queue depth or request concurrency metrics

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.