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