deploy-to-kubernetes
정보
이 스킬은 kubectl 매니페스트와 Helm 차트를 사용하여 프로덕션 환경에 적합한 구성으로 애플리케이션을 Kubernetes 클러스터에 배포합니다. 배포, 서비스, 설정을 처리하며 헬스 체크, 리소스 제한, 롤링 업데이트를 구현합니다. 클라우드 Kubernetes 서비스에 배포하거나 Docker Compose에서 마이그레이션하거나 다중 환경 배포를 설정할 때 사용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/deploy-to-kubernetesClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Deploy to Kubernetes
Ship container apps to Kubernetes. Prod-ready config: health checks, resource limits, rolling updates.
When Use
- Ship new app to K8s cluster (EKS, GKE, AKS, self-hosted)
- Migrate from Docker Compose or VM to container orchestration
- Zero-downtime rolling update + rollback
- Manage app config and secrets in K8s
- Multi-env deploy (dev, staging, prod)
- Build reusable Helm chart for distribution
Inputs
- Required: K8s cluster access (
kubectl cluster-info) - Required: Container images in registry (Docker Hub, ECR, GCR, Harbor)
- Required: App needs (ports, env vars, volumes)
- Optional: TLS certs for HTTPS ingress
- Optional: Persistent storage (StatefulSets, PVCs)
- Optional: Helm CLI for chart deploy
Steps
See Extended Examples for complete configuration files and templates.
Step 1: Make Namespace + Resource Quotas
Split apps into namespaces. Set resource limits, RBAC.
# Create namespace
kubectl create namespace myapp-prod
# Apply resource quota
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: myapp-prod
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
persistentvolumeclaims: "5"
services.loadbalancers: "2"
---
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: myapp-prod
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "100m"
memory: "128Mi"
type: Container
EOF
# Create service account
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
name: myapp
namespace: myapp-prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: myapp-role
namespace: myapp-prod
rules:
- apiGroups: [""]
resources: ["configmaps", "secrets"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: myapp-rolebinding
namespace: myapp-prod
subjects:
- kind: ServiceAccount
name: myapp
namespace: myapp-prod
roleRef:
kind: Role
name: myapp-role
apiGroup: rbac.authorization.k8s.io
EOF
# Verify namespace setup
kubectl get resourcequota -n myapp-prod
kubectl get limitrange -n myapp-prod
kubectl get sa -n myapp-prod
Got: Namespace made. Quotas cap compute + storage. LimitRange sets default CPU/memory. ServiceAccount has least-privilege RBAC.
If fail: Quota err? Check cluster resources: kubectl describe nodes. RBAC err? Check admin perms: kubectl auth can-i create role --namespace myapp-prod. Rejected resource? kubectl describe shows quota/limit violations.
Step 2: Config App Secrets + ConfigMaps
Put config and secrets outside pod. Use ConfigMaps, Secrets.
# Create ConfigMap from literal values
kubectl create configmap myapp-config \
--namespace=myapp-prod \
--from-literal=LOG_LEVEL=info \
--from-literal=API_TIMEOUT=30s \
--from-literal=FEATURE_FLAGS='{"newUI":true,"betaAPI":false}'
# Create ConfigMap from file
cat > app.properties <<EOF
database.pool.size=20
cache.ttl=3600
retry.attempts=3
EOF
kubectl create configmap myapp-properties \
--namespace=myapp-prod \
--from-file=app.properties
# Create Secret for database credentials
kubectl create secret generic myapp-db-secret \
--namespace=myapp-prod \
--from-literal=username=appuser \
--from-literal=password='sup3rs3cr3t!' \
--from-literal=connection-string='postgresql://db.example.com:5432/myapp'
# Create TLS secret for ingress
kubectl create secret tls myapp-tls \
--namespace=myapp-prod \
--cert=path/to/tls.crt \
--key=path/to/tls.key
# Verify secrets/configmaps
kubectl get configmap -n myapp-prod
kubectl get secret -n myapp-prod
kubectl describe configmap myapp-config -n myapp-prod
Complex config? Use YAML manifests:
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myapp-config
namespace: myapp-prod
data:
nginx.conf: |
server {
listen 8080;
location / {
proxy_pass http://backend:3000;
proxy_set_header Host $host;
}
}
app-config.json: |
{
"logLevel": "info",
"features": {
"authentication": true,
"metrics": true
}
}
---
# secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: myapp-secret
namespace: myapp-prod
type: Opaque
stringData: # Automatically base64 encoded
api-key: "sk-1234567890abcdef"
jwt-secret: "my-jwt-signing-key"
Got: ConfigMap holds non-sensitive config. Secret holds creds/keys. Pod reads via env var or mount. TLS secret ready for Ingress.
If fail: Encode issue? Use stringData not data in YAML. TLS err? Check cert/key: openssl x509 -in tls.crt -text -noout. Access err? Check ServiceAccount RBAC. Decode secret: kubectl get secret myapp-secret -o jsonpath='{.data.api-key}' | base64 -d.
Step 3: Make Deployment with Health Checks + Limits
Deploy app. Prod-ready: probes, resource limits.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: myapp-prod
labels:
app: myapp
version: v1.0.0
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0 # Zero-downtime updates
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
version: v1.0.0
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
prometheus.io/path: "/metrics"
spec:
serviceAccountName: myapp
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
containers:
- name: myapp
image: myregistry.io/myapp:v1.0.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
protocol: TCP
env:
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: myapp-config
key: LOG_LEVEL
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: myapp-db-secret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: myapp-db-secret
key: password
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
startupProbe:
httpGet:
path: /healthz
port: http
initialDelaySeconds: 0
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 30 # 5 minutes for slow startup
volumeMounts:
- name: config
mountPath: /etc/myapp
readOnly: true
- name: cache
mountPath: /var/cache/myapp
volumes:
- name: config
configMap:
name: myapp-properties
- name: cache
emptyDir: {}
imagePullSecrets:
- name: registry-credentials
Apply and watch:
# Apply deployment
kubectl apply -f deployment.yaml
# Watch rollout status
kubectl rollout status deployment/myapp -n myapp-prod
# Check pod status
kubectl get pods -n myapp-prod -l app=myapp
# View pod logs
kubectl logs -n myapp-prod -l app=myapp --tail=50 -f
# Describe deployment for events
kubectl describe deployment myapp -n myapp-prod
# Check resource usage
kubectl top pods -n myapp-prod -l app=myapp
Got: Deployment makes 3 replicas, rolling strategy. Pods pass readiness before traffic. Liveness restarts sick pods. Resource limits block OOM. Logs show clean startup.
If fail: ImagePullBackOff? Check image exists + imagePullSecret valid: kubectl get secret registry-credentials -o yaml. CrashLoopBackOff? Check logs: kubectl logs pod-name --previous. Probe fail? Test manually: kubectl port-forward + curl localhost:8080/healthz. OOMKilled? Raise memory or find leak.
Step 4: Expose App via Services + Load Balancers
Make Service resources. Expose app inside + outside.
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: myapp-prod
# ... (see EXAMPLES.md for complete configuration)
Apply and test:
# Apply services
kubectl apply -f service.yaml
# Get service details
kubectl get svc -n myapp-prod
# ... (see EXAMPLES.md for complete configuration)
Got: LoadBalancer gets public IP/host. ClusterIP gives stable internal DNS. Endpoints show healthy Pod IPs. Curl works.
If fail: LoadBalancer pending? Check cloud provider + quotas. No endpoints? Pod labels must match Service selector: kubectl get pods --show-labels. Connection refused? Check targetPort matches container port. Debug: kubectl port-forward bypasses Service.
Step 5: Config Horizontal Pod Autoscaling
Auto-scale on CPU/memory or custom metrics.
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
namespace: myapp-prod
# ... (see EXAMPLES.md for complete configuration)
Need metrics-server:
# Install metrics-server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# Verify metrics-server
kubectl get deployment metrics-server -n kube-system
kubectl top nodes
# ... (see EXAMPLES.md for complete configuration)
Got: HPA watches CPU/memory. Over threshold → scale up to maxReplicas. Load drops → scale down slow (stabilization stops flapping). kubectl top shows metrics.
If fail: "unknown" metrics? Check metrics-server running + Pods have resource requests. No scaling? Check utilization exceeds target: kubectl top pods. Flapping? Raise stabilizationWindowSeconds. Slow scale-up? Lower periodSeconds in scaleUp policies.
Step 6: Package App with Helm Chart
Reusable Helm chart for multi-env deploy.
# Create Helm chart structure
helm create myapp-chart
cd myapp-chart
# Edit Chart.yaml
cat > Chart.yaml <<EOF
# ... (see EXAMPLES.md for complete configuration)
Got: Helm chart bundles all K8s resources with templated values. Dry-run shows rendered manifests. Install deploys in order. Upgrades = rolling update. Rollback reverts.
If fail: Template err? Render local: helm template .. Dep issue? helm dependency update. Value override fail? Check YAML path exists in values.yaml. Inspect deployed: helm get manifest myapp -n myapp-prod.
Checks
- Pods Running, all containers ready
- Readiness probe pass before Pod gets Service endpoint
- Liveness probe restarts sick containers auto
- Resource requests + limits block OOM + node overcommit
- Secrets + ConfigMaps mounted right
- Services resolve via DNS (cluster.local) from other Pods
- LoadBalancer/Ingress reachable outside
- HPA scales up under load, down when idle
- Rolling update = zero downtime
- Logs collected via kubectl logs or central log
Pitfalls
-
No readiness probe: Pod gets traffic before ready. Always add readiness probe that checks app deps.
-
Not enough startup time: Fast liveness probe kills slow-start app. Use startupProbe with big failureThreshold.
-
No resource limits: Pod eats unlimited CPU/memory, node unstable. Always set requests + limits.
-
Hardcoded config: Env-specific values in manifest block reuse. Use ConfigMap, Secret, Helm values.
-
Default service account: Pod has too many perms. Make dedicated ServiceAccount, minimal RBAC.
-
No rolling strategy: Deployment recreates all Pods at once = downtime. Use RollingUpdate, maxUnavailable: 0.
-
Secrets in git: Sensitive data leaks. Use sealed-secrets, external-secrets-operator, vault.
-
No pod disruption budget: Cluster maintenance drains nodes, breaks service. Make PodDisruptionBudget, keep min replicas.
See Also
setup-docker-compose- Container orchestration basics before K8scontainerize-mcp-server- Build container imageswrite-helm-chart- Deep Helm chart workmanage-kubernetes-secrets- SealedSecrets + external-secrets-operatorconfigure-ingress-networking- NGINX Ingress + cert-managerimplement-gitops-workflow- ArgoCD/Flux for declarative deploysetup-container-registry- Image registry integration
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
