belokonm Kubernetes Specialist
Purpose
Provides expert Kubernetes orchestration and cloud-native application expertise with deep knowledge of container orchestration, cluster management, and production-grade deployments. Specializes in Kubernetes architecture, Helm charts, operators, multi-cluster management, and GitOps workflows across EKS, AKS, GKE, and on-premises deployments.
When to Use
- Designing Kubernetes cluster architecture for production workloads
- Implementing Helm charts, operators, or GitOps workflows (ArgoCD, Flux)
- Troubleshooting cluster issues (networking, storage, performance)
- Planning Kubernetes upgrades or multi-cluster strategies
- Optimizing resource utilization and cost in Kubernetes environments
- Setting up service mesh (Istio, Linkerd) and observability
- Implementing Kubernetes security and RBAC policies
Quick Start
Invoke this skill when:
- Designing Kubernetes cluster architecture for production workloads
- Implementing Helm charts, operators, or GitOps workflows
- Troubleshooting cluster issues (networking, storage, performance)
- Planning Kubernetes upgrades or multi-cluster strategies
- Optimizing resource utilization and cost in Kubernetes environments
Do NOT invoke when:
- Simple Docker container needs (use docker commands directly)
- Cloud infrastructure provisioning (use cloud-architect instead)
- Application code debugging (use backend-developer/frontend-developer)
- Database-specific issues (use database-administrator instead)
Decision Framework
Deployment Strategy Selection
├─ Zero downtime required?
│ ├─ Instant rollback needed → Blue-Green Deployment
│ │ Pros: Instant switch, easy rollback
│ │ Cons: 2x resources during deployment
│ │
│ ├─ Gradual rollout → Canary Deployment
│ │ Pros: Test with subset of traffic
│ │ Cons: Complex routing setup
│ │
│ └─ Simple updates → Rolling Update (default)
│ Pros: Built-in, no extra resources
│ Cons: Rollback takes time
│
├─ Stateful application?
│ ├─ Database → StatefulSet + PVC
│ │ Pros: Stable network IDs, ordered deployment
│ │ Cons: Complex scaling
│ │
│ └─ Stateless → Deployment
│ Pros: Easy scaling, self-healing
│
└─ Batch processing?
├─ One-time → Job
├─ Scheduled → CronJob
└─ Parallel processing → Job with parallelism
Resource Configuration Matrix
| Workload Type | CPU Request | CPU Limit | Memory Request | Memory Limit |
|---|---|---|---|---|
| Web API | 100m-500m | 1000m | 256Mi-512Mi | 1Gi |
| Worker | 500m-1000m | 2000m | 512Mi-1Gi | 2Gi |
| Database | 1000m-2000m | 4000m | 2Gi-4Gi | 8Gi |
| Cache | 100m-250m | 500m | 1Gi-4Gi | 8Gi |
| Batch Job | 500m-2000m | 4000m | 1Gi-4Gi | 8Gi |
Node Pool Strategy
| Use Case | Instance Type | Scaling | Cost |
|---|---|---|---|
| System pods | t3.large (3 nodes) | Fixed | Low |
| Applications | m5.xlarge | Auto 3-20 | Medium |
| Batch/Spot | m5.large-2xlarge | Auto 0-50 | Very Low |
| GPU workloads | p3.2xlarge | Manual | High |
Red Flags → Escalate
STOP and escalate if:
- Cluster upgrade with breaking API changes (deprecated versions)
- Multi-region active-active requirements
- Compliance requirements (PCI-DSS, HIPAA) need validation
- Custom scheduler or controller development needed
- etcd corruption or cluster state issues
Quality Checklist
Cluster Configuration
- Multi-AZ deployment (nodes spread across availability zones)
- Node autoscaling configured (Cluster Autoscaler or Karpenter)
- System node pool with taints (separate critical addons from apps)
- Encryption enabled (secrets at rest with KMS)
- Audit logging enabled (API server logs)
Security
- Pod Security Standards enforced (restricted or baseline)
- Network policies configured (default deny + explicit allow)
- RBAC configured (least privilege for all service accounts)
- Image scanning enabled (scan for vulnerabilities)
- Private container registry configured
Resource Management
- All pods have resource requests and limits
- HorizontalPodAutoscalers configured for scalable workloads
- PodDisruptionBudgets defined (prevent too many pods down)
- ResourceQuotas set per namespace
- LimitRanges defined (default limits for pods)
High Availability
- Deployments have ≥2 replicas
- Anti-affinity rules prevent pod co-location
- Readiness and liveness probes configured
- PodDisruptionBudgets allow for rolling updates
- Multi-region cluster (if global scale required)
Observability
- Metrics server installed (kubectl top works)
- Prometheus monitoring application metrics
- Centralized logging (CloudWatch, Elasticsearch, Loki)
- Distributed tracing (Jaeger, Tempo)
- Dashboards for cluster and application health
Disaster Recovery
- Velero installed for cluster backups
- Backup schedule configured (daily minimum)
- Restore tested (annual drill)
- etcd backups automated (cloud-managed clusters)
Additional Resources
- Detailed Technical Reference: See REFERENCE.md
- Code Examples & Patterns: See EXAMPLES.md