apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway-overprovisioned
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
    spec:
      containers:
      - name: gateway
        image: mycompany/api-gateway:v2.1.0
        resources:
          # ❌ PROBLEMA: Requests muy altos obligan a Kubernetes
          # a reservar 3 cores y 6GB RAM por pod (9 cores y 18GB total para 3 réplicas)
          requests:
            memory: "2Gi"  # La app usa 400MB en promedio
            cpu: "1000m"   # La app usa 150m en promedio
          limits:
            memory: "4Gi"  # Nunca llega ni cerca de esto
            cpu: "2000m"   # CPU throttling nunca ocurre
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-gateway-rightsized
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-gateway
  template:
    metadata:
      labels:
        app: api-gateway
    spec:
      containers:
      - name: gateway
        image: mycompany/api-gateway:v2.1.0
        resources:
          # ✅ SOLUCIÓN: Requests basados en consumo real observado
          # durante 30 días + margen 20% para picos
          requests:
            memory: "500Mi"  # 400MB promedio + 20% margen = 480Mi ≈ 500Mi
            cpu: "200m"      # 150m promedio + 20% margen = 180m ≈ 200m
          limits:
            # ✅ Memory limit 2x requests permite bursts sin OOMKill
            memory: "1Gi"
            # ✅ CPU sin limit (best practice para evitar throttling innecesario)
            # Kubernetes permite usar CPU disponible sin restricción
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

# Usar imagen base con Java 17+ (soporte container excelente)
FROM eclipse-temurin:17-jre-alpine

# Variables de entorno para configuración JVM
ENV JAVA_OPTS="-XX:+UseContainerSupport \
    -XX:MaxRAMPercentage=75.0 \
    -XX:InitialRAMPercentage=50.0 \
    -XX:+UseG1GC \
    -XX:MaxGCPauseMillis=100 \
    -XX:+UseStringDeduplication \
    -Djava.security.egd=file:/dev/./urandom"

# Crear usuario no-root para seguridad
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring

# Copiar JAR de aplicación
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar

# Exponer puerto
EXPOSE 8080

# Comando de inicio con JAVA_OPTS dinámicos
ENTRYPOINT ["sh", "-c", "java ${JAVA_OPTS} -jar /app.jar"]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-boot-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: spring-boot-api
  template:
    metadata:
      labels:
        app: spring-boot-api
    spec:
      containers:
      - name: api
        image: mycompany/spring-boot-api:v1.5.0
        resources:
          requests:
            # ✅ Basado en observación real: app usa ~600MB en P95
            # Margen 20% = 720MB ≈ 750Mi
            memory: "750Mi"
            cpu: "300m"
          limits:
            # ✅ 2x requests permite bursts sin OOMKill
            # Con MaxRAMPercentage=75%, JVM usará ~1.125GB heap
            # dejando ~375MB para non-heap/metaspace/threads
            memory: "1500Mi"
            # ✅ Sin CPU limit para evitar throttling
        ports:
        - containerPort: 8080
        env:
        # ✅ JAVA_OPTS ya está en Dockerfile, pero puedes override aquí si necesario
        - name: SPRING_PROFILES_ACTIVE
          value: "production"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 60  # Dar tiempo a JVM para warming up
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 45
          periodSeconds: 5
          timeoutSeconds: 3
          failureThreshold: 3

---
# CronJob para escalar a 0 réplicas todos los Deployments en namespaces dev/staging
# Se ejecuta de lunes a viernes a las 22:00 (10PM)
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-down-dev-environments
  namespace: automation
spec:
  schedule: "0 22 * * 1-5"  # Lunes a viernes a las 22:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-manager
          containers:
          - name: kubectl-scaler
            image: bitnami/kubectl:latest
            command:
            - /bin/bash
            - -c
            - |
              # Lista de namespaces a escalar (ajusta según tus namespaces)
              NAMESPACES="dev-team-a dev-team-b staging-env qa-automation"

              for ns in $NAMESPACES; do
                echo "Escalando deployments en namespace $ns a 0 réplicas..."

                # Escalar todos los Deployments a 0
                kubectl scale deployment --all --replicas=0 -n $ns

                # Escalar todos los StatefulSets a 0
                kubectl scale statefulset --all --replicas=0 -n $ns

                # Añadir annotation para tracking
                kubectl annotate namespace $ns \
                  "bcloud.consulting/scaled-down-at=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
                  --overwrite

                echo "✓ Namespace $ns escalado a 0 réplicas"
              done
          restartPolicy: OnFailure

---
# CronJob para restaurar réplicas originales
# Se ejecuta de lunes a viernes a las 08:00 (8AM)
apiVersion: batch/v1
kind: CronJob
metadata:
  name: scale-up-dev-environments
  namespace: automation
spec:
  schedule: "0 8 * * 1-5"  # Lunes a viernes a las 08:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: namespace-manager
          containers:
          - name: kubectl-scaler
            image: bitnami/kubectl:latest
            command:
            - /bin/bash
            - -c
            - |
              # IMPORTANTE: Necesitas mantener un ConfigMap con las réplicas originales
              # o usar annotations en los Deployments para recordar el estado previo

              NAMESPACES="dev-team-a dev-team-b staging-env qa-automation"

              for ns in $NAMESPACES; do
                echo "Restaurando deployments en namespace $ns..."

                # Leer réplicas originales de ConfigMap
                # (debes crear este ConfigMap previamente con kubectl)
                ORIGINAL_REPLICAS=$(kubectl get configmap replica-config -n $ns \
                  -o jsonpath='{.data.replicas}' 2>/dev/null || echo "2")

                # Escalar Deployments a réplicas originales
                kubectl scale deployment --all --replicas=$ORIGINAL_REPLICAS -n $ns

                # Escalar StatefulSets a réplicas originales
                kubectl scale statefulset --all --replicas=$ORIGINAL_REPLICAS -n $ns

                echo "✓ Namespace $ns restaurado a $ORIGINAL_REPLICAS réplicas"
              done
          restartPolicy: OnFailure

---
# ServiceAccount con permisos para escalar workloads
apiVersion: v1
kind: ServiceAccount
metadata:
  name: namespace-manager
  namespace: automation

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-scaler
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "deployments/scale", "statefulsets/scale"]
  verbs: ["get", "list", "patch", "update"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "patch"]
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: namespace-scaler-binding
subjects:
- kind: ServiceAccount
  name: namespace-manager
  namespace: automation
roleRef:
  kind: ClusterRole
  name: namespace-scaler
  apiGroup: rbac.authorization.k8s.io

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-namespace-quota
  namespace: dev-team-a
spec:
  hard:
    # Límites de compute resources
    requests.cpu: "10"        # Máximo 10 cores CPU total en namespace
    requests.memory: "20Gi"   # Máximo 20GB RAM total en namespace
    limits.cpu: "20"          # Máximo 20 cores CPU limits total
    limits.memory: "40Gi"     # Máximo 40GB RAM limits total

    # Límites de object counts (prevenir proliferación)
    pods: "50"                       # Máximo 50 pods en namespace
    services: "20"                   # Máximo 20 services
    persistentvolumeclaims: "10"     # Máximo 10 PVCs

    # Límites de storage
    requests.storage: "100Gi"  # Máximo 100GB storage total

---
# LimitRange para auto-inyectar defaults y prevenir pods sin limits
apiVersion: v1
kind: LimitRange
metadata:
  name: dev-namespace-limits
  namespace: dev-team-a
spec:
  limits:
  # Defaults para containers sin requests/limits definidos
  - default:
      memory: "512Mi"
      cpu: "500m"
    defaultRequest:
      memory: "256Mi"
      cpu: "250m"
    max:
      memory: "2Gi"    # Ningún container puede pedir más de 2GB
      cpu: "2000m"     # Ningún container puede pedir más de 2 cores
    min:
      memory: "128Mi"  # Mínimo razonable
      cpu: "100m"
    type: Container

  # Límites para pods completos
  - max:
      memory: "4Gi"
      cpu: "4000m"
    type: Pod

  # Configuración global Istio con sidecars optimizados
  apiVersion: install.istio.io/v1alpha1
  kind: IstioOperator
  metadata:
    name: istio-production-optimized
  spec:
    values:
      global:
        proxy:
          # ✅ Rightsizing resources Istio Envoy proxy
          resources:
            requests:
              cpu: 50m      # Reducido de default 100m
              memory: 128Mi # Reducido de default 256Mi
            limits:
              cpu: 200m     # Permite bursts pero previene runaway
              memory: 256Mi # 2x requests

          # ✅ Optimizaciones de configuración
          concurrency: 2  # Threads Envoy (default 0 = auto-detect cores)
          holdApplicationUntilProxyStarts: true  # Prevenir race conditions

          # ✅ Logging level reducido en production
          logLevel: warning  # Default es info (muy verbose)

# Usar Fluent Bit en lugar de Fluentd (90% menos memoria)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  selector:
    matchLabels:
      app: fluent-bit
  template:
    metadata:
      labels:
        app: fluent-bit
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:2.1
        resources:
          requests:
            cpu: 30m     # Fluent Bit es muy eficiente
            memory: 50Mi # vs 400-600Mi de Fluentd
          limits:
            cpu: 100m
            memory: 100Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

#!/bin/bash

# Script para detectar y limpiar pods en error states hace más de 24 horas

echo "🔍 Detectando pods en ImagePullBackOff..."
kubectl get pods --all-namespaces \
  --field-selector=status.phase!=Running,status.phase!=Succeeded \
  -o json | jq -r '
    .items[] |
    select(.status.containerStatuses[]?.state.waiting?.reason == "ImagePullBackOff") |
    select((now - (.metadata.creationTimestamp | fromdateiso8601)) > 86400) |
    "\(.metadata.namespace)/\(.metadata.name) - Age: \((now - (.metadata.creationTimestamp | fromdateiso8601)) / 86400 | floor) days"
  '

echo ""
echo "🔍 Detectando pods en CrashLoopBackOff..."
kubectl get pods --all-namespaces \
  --field-selector=status.phase!=Running,status.phase!=Succeeded \
  -o json | jq -r '
    .items[] |
    select(.status.containerStatuses[]?.state.waiting?.reason == "CrashLoopBackOff") |
    select((now - (.metadata.creationTimestamp | fromdateiso8601)) > 86400) |
    "\(.metadata.namespace)/\(.metadata.name) - Restarts: \(.status.containerStatuses[0].restartCount)"
  '

echo ""
echo "⚠️  ¿Eliminar estos pods? (y/n)"
read -r response

if [[ "$response" == "y" ]]; then
  echo "🗑️  Eliminando pods en ImagePullBackOff > 24h..."
  kubectl get pods --all-namespaces \
    --field-selector=status.phase!=Running,status.phase!=Succeeded \
    -o json | jq -r '
      .items[] |
      select(.status.containerStatuses[]?.state.waiting?.reason == "ImagePullBackOff") |
      select((now - (.metadata.creationTimestamp | fromdateiso8601)) > 86400) |
      "kubectl delete pod \(.metadata.name) -n \(.metadata.namespace)"
    ' | bash

  echo "🗑️  Eliminando pods en CrashLoopBackOff > 24h con >50 restarts..."
  kubectl get pods --all-namespaces \
    --field-selector=status.phase!=Running,status.phase!=Succeeded \
    -o json | jq -r '
      .items[] |
      select(.status.containerStatuses[]?.state.waiting?.reason == "CrashLoopBackOff") |
      select(.status.containerStatuses[0].restartCount > 50) |
      "kubectl delete pod \(.metadata.name) -n \(.metadata.namespace)"
    ' | bash

  echo "✅ Cleanup completado"
else
  echo "❌ Operación cancelada"
fi

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cleanup-failed-pods
  namespace: automation
spec:
  schedule: "0 2 * * *"  # Cada día a las 2AM
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: pod-cleaner
          containers:
          - name: kubectl-cleanup
            image: bitnami/kubectl:latest
            command:
            - /bin/bash
            - -c
            - |
              echo "🔍 Buscando pods en error states > 24 horas..."

              # Eliminar ImagePullBackOff > 24h
              kubectl get pods --all-namespaces \
                -o json | jq -r '
                  .items[] |
                  select(.status.phase != "Running" and .status.phase != "Succeeded") |
                  select(.status.containerStatuses[]?.state.waiting?.reason == "ImagePullBackOff") |
                  select((now - (.metadata.creationTimestamp | fromdateiso8601)) > 86400) |
                  "\(.metadata.namespace) \(.metadata.name)"
                ' | while read ns name; do
                  echo "Eliminando pod $name en namespace $ns (ImagePullBackOff)"
                  kubectl delete pod "$name" -n "$ns" --grace-period=0 --force
                done

              # Eliminar CrashLoopBackOff con >100 restarts
              kubectl get pods --all-namespaces \
                -o json | jq -r '
                  .items[] |
                  select(.status.containerStatuses[]?.state.waiting?.reason == "CrashLoopBackOff") |
                  select(.status.containerStatuses[0].restartCount > 100) |
                  "\(.metadata.namespace) \(.metadata.name)"
                ' | while read ns name; do
                  echo "Eliminando pod $name en namespace $ns (CrashLoopBackOff >100 restarts)"
                  kubectl delete pod "$name" -n "$ns" --grace-period=0 --force
                done

              echo "✅ Cleanup completado"
          restartPolicy: OnFailure

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-cleaner
  namespace: automation

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-cleanup-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-cleanup-binding
subjects:
- kind: ServiceAccount
  name: pod-cleaner
  namespace: automation
roleRef:
  kind: ClusterRole
  name: pod-cleanup-role
  apiGroup: rbac.authorization.k8s.io