Use this skill when containerizing applications, writing Dockerfiles, deploying to Kubernetes, creating Helm charts, or configuring service mesh. Triggers on Docker, Kubernetes, k8s, containers, pods, deployments, services, ingress, Helm, Istio, container orchestration, and any task requiring container or cluster management.
Instrucciones de origen · Vista previa de solo lectura
name
docker-kubernetes
version
0.1.0
description
Use this skill when containerizing applications, writing Dockerfiles, deploying to Kubernetes, creating Helm charts, or configuring service mesh. Triggers on Docker, Kubernetes, k8s, containers, pods, deployments, services, ingress, Helm, Istio, container orchestration, and any task requiring container or cluster management.
When this skill is activated, always start your first response with the 🧢 emoji.
Docker & Kubernetes
A practical guide to containerizing applications and running them reliably in
Kubernetes. This skill covers the full lifecycle from writing a production-ready
Dockerfile to deploying with Helm, configuring traffic with Ingress, and debugging
cluster issues. The emphasis is on correctness and operability - containers that
are small, secure, and observable; Kubernetes workloads that self-heal, scale, and
fail gracefully. Designed for engineers who know the basics and need opinionated
guidance on production patterns.
When to use this skill
Trigger this skill when the user:
Writes or reviews a Dockerfile (any language or runtime)
Deploys or configures a Kubernetes workload (Deployment, StatefulSet, DaemonSet)
Sets up Kubernetes networking (Services, Ingress, NetworkPolicy)
Creates or maintains a Helm chart or values file
Configures health probes, resource limits, or autoscaling (HPA/VPA)
Debugs a failing pod (CrashLoopBackOff, OOMKilled, ImagePullBackOff)
Configures a service mesh (Istio, Linkerd) or needs mTLS between services
Do NOT trigger this skill for:
Cloud-provider infrastructure provisioning (use a Terraform/IaC skill instead)
CI/CD pipeline authoring (use a CI/CD skill - container builds are a small part)
Key principles
One process per container - A container should do exactly one thing. Sidecar
patterns (logging agents, proxies) are valid, but the main container must not
run multiple application processes. This preserves independent restartability and
clean signal handling.
Immutable infrastructure - Never patch a running container. Update the image
tag, redeploy. Mutations to running pods are invisible to version control and
create snowflakes. Pin image tags in production; never use latest.
Declarative configuration - All cluster state lives in YAML checked into git.
kubectl apply is the only allowed mutation path. kubectl edit on a live cluster
is a debugging tool, not a deployment method.
Minimal base images - Use alpine, distroless, or language-specific slim
images. Fewer packages = smaller attack surface = faster pulls. Multi-stage builds
eliminate build tooling from the final image.
Health checks always - Every Deployment must define liveness and readiness
probes. Without them, Kubernetes cannot distinguish a booting pod from a hung one,
and will route traffic to pods that cannot serve it.
Core concepts
Docker layers and caching
Each RUN, COPY, and ADD instruction creates a layer. Layers are cached by
content hash. Cache is invalidated at the first changed layer and all layers after
it. Ordering matters: put rarely-changing instructions (installing OS packages) before
frequently-changing ones (copying application source). Copy dependency manifests and
install before copying source code.
Kubernetes object model
Pod -> smallest schedulable unit (one or more containers sharing network/storage)
|
Deployment -> manages ReplicaSets; handles rollouts and rollbacks
|
Service -> stable virtual IP and DNS name that routes to healthy pod IPs
|
Ingress -> HTTP/HTTPS routing rules from outside the cluster into Services
Namespaces provide soft isolation within a cluster. Use them to separate
environments (staging, production) or teams. ResourceQuotas and NetworkPolicies
scope to namespaces.
ConfigMaps and Secrets
ConfigMap: non-sensitive configuration (feature flags, URLs, log levels).
Mount as env vars or volume files.
Secret: sensitive values (passwords, tokens, TLS certs). Stored base64-encoded
in etcd (encrypt etcd at rest in production). Never bake secrets into images.
Common tasks
Write a production Dockerfile (multi-stage, Node.js)
# ---- build stage ----
FROM node:20-alpine AS builder
WORKDIR /app
# Copy manifests first - cached until dependencies change
COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts
COPY . .
RUN npm run build
# ---- runtime stage ----
FROM node:20-alpine AS runtime
ENV NODE_ENV=production
WORKDIR /app
# Non-root user for security
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package.json ./
USER appuser
EXPOSE 3000
# Use exec form to receive signals correctly
CMD ["node", "dist/server.js"]
Key decisions: alpine base, non-root user, npm ci (reproducible installs),
multi-stage to exclude dev dependencies, exec-form CMD for proper PID 1 signal
handling.
Create a Kubernetes Deployment + Service
apiVersion:apps/v1kind:Deploymentmetadata:name:api-servernamespace:productionlabels:app:api-serverspec:replicas:3selector:matchLabels:app:api-serverstrategy:type:RollingUpdaterollingUpdate:maxUnavailable:1maxSurge:1template:metadata:labels:app:api-serverspec:containers:-name:api-serverimage:registry.example.com/api-server:1.4.2# pinned tag, never latestports:-containerPort:3000envFrom:-configMapRef:name:api-config-secretRef:name:api-secretsresources:requests:cpu:"100m"memory:"128Mi"limits:cpu:"500m"memory:"256Mi"readinessProbe:httpGet:path:/healthz/readyport:3000initialDelaySeconds:5periodSeconds:10livenessProbe:httpGet:path:/healthz/liveport:3000initialDelaySeconds:15periodSeconds:20topologySpreadConstraints:-maxSkew:1topologyKey:kubernetes.io/hostnamewhenUnsatisfiable:DoNotSchedulelabelSelector:matchLabels:app:api-server---apiVersion:v1kind:Servicemetadata:name:api-servernamespace:productionspec:selector:app:api-serverports:-port:80targetPort:3000type:ClusterIP
apiVersion:v2name:api-serverdescription:APIserverHelmcharttype:applicationversion:0.1.0# chart versionappVersion:"1.4.2"# application image version
values.yaml
replicaCount:3image:repository:registry.example.com/api-servertag:""# defaults to .Chart.AppVersionpullPolicy:IfNotPresentservice:type:ClusterIPport:80ingress:enabled:truehost:api.example.comtlsSecretName:api-tls-certresources:requests:cpu:100mmemory:128Milimits:cpu:500mmemory:256Miautoscaling:enabled:falseminReplicas:2maxReplicas:10targetCPUUtilizationPercentage:70
Set up health checks (liveness, readiness, startup probes)
startupProbe:httpGet:path:/healthz/startupport:3000failureThreshold:30# allow up to 30 * 10s = 5 min for slow startsperiodSeconds:10readinessProbe:httpGet:path:/healthz/readyport:3000initialDelaySeconds:5periodSeconds:10failureThreshold:3# remove from LB after 3 failureslivenessProbe:httpGet:path:/healthz/liveport:3000initialDelaySeconds:15periodSeconds:20failureThreshold:3# restart after 3 failures
Rules:
startup probe - use for slow-starting containers; disables liveness/readiness until it passes
readiness probe - gates traffic routing; use for dependency checks (DB connected?)
liveness probe - gates pod restart; only check self (not downstream services)
Never use the same endpoint for readiness and liveness if they have different semantics
Configure resource limits and HPA
resources:requests:cpu:"100m"# scheduler uses this for placementmemory:"128Mi"limits:cpu:"500m"# throttled at this ceilingmemory:"256Mi"# OOMKilled if exceeded---apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-server-hpanamespace:productionspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:2maxReplicas:20metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70-type:Resourceresource:name:memorytarget:type:UtilizationaverageUtilization:80
Rule of thumb: set requests based on measured p50 usage, limits at 3-5x requests
for CPU (CPU is compressible), 1.5-2x for memory (memory is not compressible).
Debug a CrashLoopBackOff pod
Follow this sequence in order:
# 1. Get pod status and events
kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace> # read Events section# 2. Check current logs
kubectl logs <pod-name> -n <namespace>
# 3. Check previous container logs (the one that crashed)
kubectl logs <pod-name> -n <namespace> --previous
# 4. Check resource pressure on the node
kubectl top pod <pod-name> -n <namespace>
kubectl top node
# 5. If image issue, check image pull events in describe output# 6. Run interactively with a debug shell
kubectl debug -it <pod-name> -n <namespace> --image=busybox --target=<container-name>
Common causes:
Application crashes on startup - check logs --previous
Missing env var or secret - check describe Events for missing volume mounts
OOMKilled - increase memory limit or fix memory leak
Liveness probe too aggressive - increase initialDelaySeconds
Error handling
Error
Cause
Fix
CrashLoopBackOff
Container exits repeatedly; k8s backs off restart
Check logs --previous, fix application crash or missing config
Increase memory limit or profile and fix memory leak
Pending (pod)
No node satisfies scheduling constraints
Check node resources (kubectl top node), taints/tolerations, node selectors
0/N nodes available
Affinity/anti-affinity or resource pressure
Relax topologySpreadConstraints or add nodes
CreateContainerConfigError
Referenced Secret or ConfigMap does not exist
Create the missing resource or fix the reference name
References
For quick kubectl command reference during live debugging, load:
references/kubectl-cheatsheet.md - essential kubectl commands by resource type
Load the cheatsheet when actively running kubectl commands or diagnosing cluster
state. It is a quick-reference card, not a tutorial - skip it for conceptual questions.
Related skills
When this skill is activated, check if the following companion skills are installed.
For any that are missing, mention them to the user and offer to install before proceeding
with the task. Example: "I notice you don't have [skill] installed yet - it pairs well
with this skill. Want me to install it?"
