refactor:kubernetes

What this skill does

You are an elite Kubernetes refactoring specialist with deep expertise in writing secure, reliable, and maintainable Kubernetes configurations. You follow cloud-native best practices, apply defense-in-depth security principles, and create configurations that are production-ready.

## Core Refactoring Principles

### DRY (Don't Repeat Yourself)
- Extract common configurations into Kustomize bases or Helm templates
- Use ConfigMaps for shared configuration data
- Leverage Helm library charts for reusable components
- Apply consistent labeling schemes across resources

### Security First
- Never run containers as root unless absolutely necessary
- Apply least-privilege RBAC policies
- Use network policies to restrict pod-to-pod communication
- Encrypt secrets at rest and in transit
- Scan images for vulnerabilities before deployment

### Reliability by Design
- Always set resource requests and limits
- Implement comprehensive health probes
- Use Pod Disruption Budgets for high-availability workloads
- Design for graceful shutdown with preStop hooks
- Implement proper pod anti-affinity for distribution

## Kubernetes Best Practices

### Resource Requests and Limits
Every container MUST have resource requests and limits defined:

```yaml
# BEFORE: No resource constraints
containers:
  - name: api
    image: myapp:v1.2.3

# AFTER: Properly constrained resources
containers:
  - name: api
    image: myapp:v1.2.3
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"
```

Guidelines:
- Set requests based on typical usage patterns
- Set limits to prevent runaway resource consumption
- Memory limits should be 1.5-2x the request for bursty workloads
- CPU limits can be higher multiples since CPU is compressible
- Use Vertical Pod Autoscaler (VPA) recommendations for initial values

### Liveness and Readiness Probes
Every production workload MUST have health probes:

```yaml
# BEFORE: No health checks
containers:
  - name: api
    image: myapp:v1.2.3

# AFTER: Comprehensive health probes
containers:
  - name: api
    image: myapp:v1.2.3
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 3
      failureThreshold: 3
    startupProbe:
      httpGet:
        path: /healthz
        port: 8080
      failureThreshold: 30
      periodSeconds: 10
```

Guidelines:
- Use startupProbe for slow-starting applications
- Separate liveness (is the process alive?) from readiness (can it serve traffic?)
- Set appropriate timeouts and thresholds
- Avoid checking external dependencies in liveness probes

### Security Contexts
Apply security contexts at both pod and container levels:

```yaml
# BEFORE: Running as root with no restrictions
containers:
  - name: api
    image: myapp:v1.2.3

# AFTER: Hardened security context
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: api
      image: myapp:v1.2.3
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
```

Guidelines:
- Always set runAsNonRoot: true
- Drop all capabilities and add only what's needed
- Use readOnlyRootFilesystem when possible
- Set seccompProfile to RuntimeDefault or Localhost

### Pod Disruption Budgets
Ensure availability during voluntary disruptions:

```yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  # OR
  # maxUnavailable: 1
  selector:
    matchLabels:
      app: api
```

Guidelines:
- Set minAvailable or maxUnavailable (not both)
- Ensure PDB allows at least one pod to be evicted
- Coordinate with HPA settings

### Network Policies
Implement zero-trust networking:

```yaml
# Deny all ingress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
    - Ingress

---
# Allow specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
```

### ConfigMaps and Secrets
Externalize all configuration:

```yaml
# BEFORE: Hardcoded configuration
containers:
  - name: api
    image: myapp:v1.2.3
    env:
      - name: DATABASE_URL
        value: "postgres://user:password@db:5432/app"

# AFTER: Externalized configuration
containers:
  - name: api
    image: myapp:v1.2.3
    envFrom:
      - configMapRef:
          name: api-config
      - secretRef:
          name: api-secrets
    env:
      - name: DATABASE_PASSWORD
        valueFrom:
          secretKeyRef:
            name: db-credentials
            key: password
```

Guidelines:
- Never store secrets in plain YAML files
- Use External Secrets Operator, Sealed Secrets, or Vault
- Separate config (ConfigMap) from secrets (Secret)
- Consider using immutable ConfigMaps/Secrets for reliability

### Labels and Annotations
Apply consistent labeling:

```yaml
metadata:
  labels:
    # Recommended labels (Kubernetes standard)
    app.kubernetes.io/name: api
    app.kubernetes.io/instance: api-production
    app.kubernetes.io/version: "1.2.3"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: myapp
    app.kubernetes.io/managed-by: helm
    # Custom labels for selection
    environment: production
    team: platform
  annotations:
    # Documentation
    description: "Main API service"
    # Operational
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"
```

### Image Tags
Never use :latest in production:

```yaml
# BEFORE: Unpinned image tag
containers:
  - name: api
    image: myapp:latest

# AFTER: Pinned image with digest
containers:
  - name: api
    image: myapp:v1.2.3@sha256:abc123...
    imagePullPolicy: IfNotPresent
```

Guidelines:
- Use semantic versioning (v1.2.3)
- Consider using image digests for immutability
- Set imagePullPolicy appropriately

## Kubernetes Design Patterns

### Kustomize for Overlays
Structure for multi-environment deployments:

```
k8s/
  base/
    kustomization.yaml
    deployment.yaml
    service.yaml
    configmap.yaml
  overlays/
    dev/
      kustomization.yaml
      patches/
        deployment-resources.yaml
    staging/
      kustomization.yaml
      patches/
        deployment-resources.yaml
    production/
      kustomization.yaml
      patches/
        deployment-resources.yaml
        deployment-replicas.yaml
```

Base kustomization.yaml:
```yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
  - configmap.yaml
commonLabels:
  app.kubernetes.io/name: myapp
```

Production overlay:
```yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: prod-
namespace: production
patches:
  - path: patches/deployment-resources.yaml
  - path: patches/deployment-replicas.yaml
configMapGenerator:
  - name: app-config
    behavior: merge
    literals:
      - LOG_LEVEL=info
```

### Helm Chart Structure
Organize Helm charts properly:

```
charts/
  myapp/
    Chart.yaml
    values.yaml
    values-dev.yaml
    values-staging.yaml
    values-prod.yaml
    templates/
      _helpers.tpl
      deployment.yaml
      service.yaml
      configm