Día 29 de 30 Fase 8: Contenedores, Kubernetes / OpenShift y Observabilidad LKA / LGTM

Contenedores y Kubernetes / OpenShift para Java Spring Boot

Docker multi-stage, JRE headless, Pods, Deployments, Services, ConfigMaps, Secrets, Ingress/Routes y Probes

Visión de conjunto. Sales entendiendo cómo funciona y cuándo usarlo; dominarlo pide más práctica en un proyecto real.

4.5h de estudio
6 conceptos
3 preguntas
1 katas

DockerKubernetesOpenShiftJVM FlagsLivenessReadinessConfigMapsSeguridad de imágenes

Al terminar este día sabrás 4

Construir imágenes de contenedor para Spring Boot rápidas de arrancar y de desplegar.
Configurar memoria y CPU de un pod Java sin provocar OOMKilled ni throttling.
Desplegar un servicio con Deployment, Service, ConfigMap y Secret.
Configurar probes con Actuator y desplegar sin cortes, también en OpenShift.

Concepto 1 de 6

Dockerfile Multi-Stage optimizado para Spring Boot y JVM

Una imagen de contenedor para Java nunca debe incluir Maven ni el código fuente en la imagen final. Se usa una fase de build (con Maven/Gradle y JDK completo) y una fase de ejecución (con JRE mínimo tipo Eclipse Temurin / BellSoft Liberica Alpine/Distroless). Se extraen las capas del jar con layertools (java -Djarmode=layertools -jar app.jar extract) para aprovechar la caché de capas de Docker.

En una línea FROM eclipse-temurin:21-jre-alpine WORKDIR /app COPY --from=builder /app/dependencies/ ./ COPY --from=builder /app/application/ ./ ENTRYPOINT ["java", "-XX:+UseContainerSupport", "-XX:MaxRAMPercentage=75.0", "org.springframework.boot.loader.launch.JarLauncher"]

Buildpacks y arranque con CDS bash

# Imagen OCI sin Dockerfile (requiere Docker en local)
./mvnw spring-boot:build-image -Dspring-boot.build-image.imageName=registry.acme.com/taskflow:1.4.0

# Con Jib: construye y publica sin demonio de Docker
./mvnw com.google.cloud.tools:jib-maven-plugin:build -Dimage=registry.acme.com/taskflow:1.4.0

# CDS con Spring Boot 3.3+ (en el Dockerfile, tras extraer el JAR)
java -XX:ArchiveClassesAtExit=app.jsa -Dspring.context.exit=onRefresh -jar app.jar   # entrenamiento
java -XX:SharedArchiveFile=app.jsa -jar app.jar                                       # arranques posteriores

# Inspeccionar capas y vulnerabilidades
dive registry.acme.com/taskflow:1.4.0
trivy image registry.acme.com/taskflow:1.4.0

Cómo funciona por dentro

Además del Dockerfile multi-etapa escrito a mano (día 15), hay dos alternativas sin Dockerfile. Cloud Native Buildpacks, integrados en Spring Boot con ./mvnw spring-boot:build-image, detectan la aplicación, eligen un JRE, crean capas optimizadas, configuran la memoria de la JVM y generan una imagen reproducible con usuario sin privilegios. Jib, de Google, construye y sube la imagen directamente desde Maven sin necesitar Docker.

Para el arranque, Spring Boot 3.3 facilita usar CDS (Class Data Sharing): en un primer arranque de entrenamiento la JVM vuelca un archivo con las clases ya analizadas, y los siguientes arranques lo reutilizan, recortando el tiempo de arranque de forma notable. Las imágenes nativas con GraalVM arrancan en milisegundos a cambio de un build mucho más lento y algunas restricciones de reflexión.

Sea cual sea la vía, comprueba el resultado: tamaño, usuario, capas (con la herramienta dive) y vulnerabilidades (Trivy, Grype).

Reduce la imagen de ~800MB a menos de 150MB, acelera los despliegues en CI/CD y minimiza vectores de vulnerabilidad (CVEs).

Copiar todo el proyecto y ejecutar mvn spring-boot:run dentro del contenedor en producción, dejando el JDK y herramientas de compilación expuestas.

Se conecta con Docker LayersAlpine / DistrolessSpring Boot Layertools

Memoria JVM en Contenedores: MaxRAMPercentage y Cgroups v2

Dentro de un Pod de Kubernetes con límites (e.g. resources.limits.memory: 1Gi), la JVM debe ser consciente de ese límite. La flag -XX:MaxRAMPercentage=75.0 indica a la JVM que reserve como máximo el 75% del límite de memoria del Pod para el Heap, dejando el 25% restante para Metaspace, hilos (stack), buffers I/O nativos y Garbage Collector.

En una línea -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0

Recursos del contenedor y opciones de la JVM yaml

containers:
  - name: taskflow
    image: registry.acme.com/taskflow:1.4.0
    resources:
      requests:
        cpu: "500m"
        memory: "1Gi"
      limits:
        memory: "1Gi"                 # igual que el request: memoria garantizada
        # sin límite de CPU: evita throttling en el arranque y en picos de GC
    env:
      - name: JAVA_TOOL_OPTIONS       # la JVM lo lee siempre, sin tocar el ENTRYPOINT
        value: >-
          -XX:MaxRAMPercentage=70.0
          -XX:ActiveProcessorCount=2
          -XX:+ExitOnOutOfMemoryError
          -Xlog:gc:stdout:time

Cómo funciona por dentro

En Kubernetes cada contenedor declara requests (lo que el planificador le garantiza y usa para elegir nodo) y limits (lo máximo que puede usar). Para la memoria, el límite es duro: si el proceso lo supera, el kernel lo mata (OOMKilled, código 137). La JVM lee ese límite a través de cgroups v2 y calcula el heap con MaxRAMPercentage.

Para memoria, la recomendación habitual es requests igual a limits: el pod tiene memoria garantizada y no compite con otros en un nodo saturado. Para CPU es más delicado: un límite de CPU bajo provoca throttling (el proceso se pausa durante cada periodo de 100 ms al agotar su cuota), muy dañino durante el arranque de una aplicación Spring y para el GC. Muchos equipos fijan solo requests de CPU, sin límite.

La JVM también usa la CPU disponible para dimensionar hilos del GC y del ForkJoinPool. Con límites fraccionarios (500m) puede ver un solo procesador y elegir el recolector Serial; puedes ajustarlo con -XX:ActiveProcessorCount.

Evita que el kernel de Linux mate el proceso Java por exceso de memoria (OOMKilled - Exit Code 137).

Fijar -Xmx1g cuando el límite del Pod en Kubernetes es exactamente 1Gi. Los hilos y el Metaspace desbordan el límite y Kubernetes ejecuta OOMKill instantáneo.

Se conecta con Kubernetes Resource LimitsOOMKilledMetaspace

Primitivas de Kubernetes: Pods, Deployments, Services y ConfigMaps/Secrets

Un Pod es la unidad mínima ejecutable. Un Deployment gestiona el ciclo de vida de réplicas de Pods (rolling updates, auto-recuperación). Un Service (ClusterIP) provee una IP y DNS interno estable que balancea peticiones entre Pods. ConfigMaps inyectan variables no sensibles y Secrets inyectan credenciales cifradas en base64 montadas como variables de entorno o ficheros.

En una línea env: - name: SPRING_DATASOURCE_URL valueFrom: configMapKeyRef: name: app-config key: db_url

Deployment, Service, ConfigMap y Secret yaml

apiVersion: v1
kind: ConfigMap
metadata: { name: taskflow-config }
data:
  SPRING_PROFILES_ACTIVE: "prod"
  SPRING_DATASOURCE_URL: "jdbc:postgresql://postgres:5432/taskflow"
---
apiVersion: v1
kind: Secret
metadata: { name: taskflow-db }
type: Opaque
stringData:                           # Kubernetes lo guarda en Base64 (no es cifrado)
  SPRING_DATASOURCE_USERNAME: taskflow
  SPRING_DATASOURCE_PASSWORD: cambiar-en-el-gestor-de-secretos
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: taskflow }
spec:
  replicas: 3
  selector: { matchLabels: { app: taskflow } }
  template:
    metadata: { labels: { app: taskflow } }
    spec:
      containers:
        - name: taskflow
          image: registry.acme.com/taskflow:1.4.0
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: taskflow-config }
            - secretRef: { name: taskflow-db }
---
apiVersion: v1
kind: Service
metadata: { name: taskflow }
spec:
  selector: { app: taskflow }
  ports: [{ port: 80, targetPort: 8080 }]

Cómo funciona por dentro

Un Pod es la unidad mínima de despliegue: uno o varios contenedores que comparten red y volúmenes. No se crean a mano. Un Deployment declara cuántas réplicas quieres y de qué imagen, y mantiene ese estado: si un pod muere, crea otro; si cambias la imagen, hace una actualización gradual.

Los pods son efímeros y su IP cambia, así que un Service les da un nombre DNS estable (taskflow.mi-namespace.svc) y reparte el tráfico entre los pods que estén listos. Un Ingress (o una Route en OpenShift) expone el Service fuera del clúster con un dominio y TLS.

La configuración se separa de la imagen: un ConfigMap para valores no sensibles y un Secret para credenciales, inyectados como variables de entorno o ficheros. Ojo: un Secret solo está codificado en Base64, no cifrado; hay que restringir el acceso con RBAC, activar el cifrado en reposo de etcd o usar un gestor externo (Vault, External Secrets).

Permite desacoplar el artefacto binario (imagen inmutable) de la configuración específica del entorno (Dev, QA, Prod).

Hardcodear cadenas de conexión a base de datos en el application.yml empaquetado en la imagen Docker.

Se conecta con 12-Factor AppDNS interno K8sRolling Updates

Health Probes: Liveness, Readiness y Startup Probes con Spring Boot Actuator

Startup Probe: Verifica si la aplicación ha terminado de iniciar (evita matar apps lentas al arrancar). Readiness Probe: Verifica si el Pod está listo para recibir tráfico de red (si la BD está conectada); si falla, el Service deja de enviarle peticiones. Liveness Probe: Verifica si el contenedor sigue vivo (no en deadlock); si falla, Kubernetes destruye el Pod y crea uno nuevo.

En una línea livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080

Las tres sondas con Actuator yaml

containers:
  - name: taskflow
    ports:
      - { name: http, containerPort: 8080 }
      - { name: management, containerPort: 8081 }
    startupProbe:
      httpGet: { path: /actuator/health/liveness, port: management }
      periodSeconds: 5
      failureThreshold: 30            # hasta 150 s para arrancar
    livenessProbe:
      httpGet: { path: /actuator/health/liveness, port: management }
      periodSeconds: 10
      failureThreshold: 3
    readinessProbe:
      httpGet: { path: /actuator/health/readiness, port: management }
      periodSeconds: 5
      failureThreshold: 2

Cómo funciona por dentro

Kubernetes usa tres sondas con propósitos distintos. La de liveness responde a «¿está el proceso vivo o bloqueado sin remedio?»: si falla varias veces, Kubernetes reinicia el contenedor. La de readiness responde a «¿puede atender tráfico ahora?»: si falla, el pod se retira del Service pero no se reinicia. La de startup protege el arranque: mientras no tenga éxito, las otras dos no se evalúan, lo que evita que una aplicación lenta en arrancar se reinicie en bucle.

Spring Boot expone las dos primeras con Actuator: /actuator/health/liveness refleja el LivenessState (roto solo ante errores internos irrecuperables) y /actuator/health/readiness el ReadinessState, que pasa a REFUSING_TRAFFIC durante el arranque y al iniciar el apagado.

El error más grave es incluir la base de datos en liveness: si PostgreSQL cae, todos los pods fallan liveness, se reinician a la vez en bucle y la recuperación se complica. Las dependencias externas, en todo caso, en readiness.

Garantiza despliegues sin caída (Zero-Downtime Deployments) y auto-recuperación ante fallos críticos.

Se conecta con Spring Boot ActuatorZero-DowntimeTraffic Routing

OpenShift vs Kubernetes Vanilla: SecurityContextConstraints, Routes y BuildConfig

Red Hat OpenShift es una plataforma empresarial basada en Kubernetes con capas añadidas de seguridad y productividad. Diferencias clave: (1) Routes en lugar de Ingress (TLS termination nativa); (2) Security Context Constraints (SCC): OpenShift prohíbe por defecto que los contenedores corran como root o con UID fijo (asigna un UID arbitrario aleatorio); (3) DeploymentConfig / ImageStreams.

En una línea RUN chgrp -R 0 /app && chmod -R g=u /app && USER 1001

Imagen compatible con OpenShift y una Route yaml

# Dockerfile: escribible por el grupo 0, sea cual sea el UID asignado
#   FROM eclipse-temurin:21-jre
#   WORKDIR /app
#   COPY --from=build /workspace/extracted/ ./
#   RUN chgrp -R 0 /app && chmod -R g=u /app
#   USER 1001                      # OpenShift lo sustituirá por un UID aleatorio del rango

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: taskflow
spec:
  host: taskflow.apps.acme.com
  to:
    kind: Service
    name: taskflow
  port:
    targetPort: 8080
  tls:
    termination: edge                # TLS termina en el router de OpenShift
    insecureEdgeTerminationPolicy: Redirect

# oc new-app registry.acme.com/taskflow:1.4.0 --name taskflow
# oc get scc ; oc describe pod taskflow-xxx | grep scc   (qué SCC se aplicó)

Cómo funciona por dentro

OpenShift es una distribución de Kubernetes de Red Hat con capas adicionales y opciones de seguridad más estrictas. La diferencia que más sorprende: por defecto, la SecurityContextConstraint restricted-v2 ejecuta cada contenedor con un UID aleatorio de un rango asignado al proyecto, ignorando el USER de la imagen, y siempre con el grupo 0 (root group, sin privilegios de root).

Consecuencia práctica: los ficheros y directorios en los que la aplicación necesita escribir deben pertenecer al grupo 0 y tener permisos de grupo iguales a los del propietario (chgrp -R 0 y chmod -R g=u). Las imágenes oficiales de Red Hat (UBI) ya siguen este convenio.

Otras diferencias: las Routes (anteriores a Ingress) exponen servicios con TLS de forma nativa, los ImageStreams versionan imágenes dentro del clúster y disparan despliegues, y BuildConfig con Source-to-Image (S2I) construye imágenes a partir del código fuente dentro del propio clúster. La CLI oc es un superconjunto de kubectl.

Común en banca, seguros y grandes corporaciones donde la seguridad estricta y cumplimiento normativo son obligatorios.

Crear una imagen Docker que asume usuario root o escribe en directorios protegidos como /root o /etc. En OpenShift fallará con Permission denied. Siempre se debe dar permisos al grupo root (GID 0) en el directorio de trabajo: chgrp -R 0 /app && chmod -R g=u /app.

Se conecta con Red Hat EnterpriseSCCIngress vs RouteRootless Containers

Seguridad del Contenedor y Caché de Capas

Una imagen de producción se ejecuta con un usuario sin privilegios (USER), parte de una imagen base mínima sin herramientas de compilación y ordena el Dockerfile para que lo que cambia poco (las dependencias) quede en capas que Docker reutiliza entre builds.

En una línea COPY pom.xml . y RUN ./mvnw dependency:go-offline antes de COPY src ./src; USER 1001 antes del ENTRYPOINT.

Dockerfile ordenado, sin root y con las capas de Spring Boot dockerfile

# Etapa 1: compilar. Las dependencias se descargan en una capa propia
FROM eclipse-temurin:21-jdk AS build
WORKDIR /src
COPY mvnw pom.xml ./
COPY .mvn .mvn
RUN ./mvnw -B dependency:go-offline           # se reutiliza mientras no cambie el pom
COPY src ./src
RUN ./mvnw -B package -DskipTests && \
    java -Djarmode=tools -jar target/*.jar extract --layers --launcher --destination extracted

# Etapa 2: ejecutar con JRE y un usuario sin privilegios
FROM eclipse-temurin:21-jre
RUN groupadd --system app && useradd --system --gid app --uid 1001 app
WORKDIR /app
COPY --from=build /src/extracted/dependencies/ ./
COPY --from=build /src/extracted/spring-boot-loader/ ./
COPY --from=build /src/extracted/snapshot-dependencies/ ./
COPY --from=build /src/extracted/application/ ./
USER 1001
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "org.springframework.boot.loader.launch.JarLauncher"]

Cómo funciona por dentro

Un contenedor no es una máquina virtual: comparte el kernel con el host. Si el proceso corre como root dentro del contenedor y alguien explota una vulnerabilidad de la aplicación, una mala configuración (volúmenes montados, capacidades extra) puede darle acceso al host. Por eso la imagen crea un usuario sin privilegios y lo activa con USER antes del ENTRYPOINT; Kubernetes lo puede exigir con runAsNonRoot: true, y OpenShift lo impone por defecto asignando un UID arbitrario.

La superficie de ataque también se reduce con imágenes base mínimas: un JRE en lugar de un JDK, sin compiladores, gestores de paquetes ni shell cuando es posible (imágenes distroless). Menos paquetes significa menos vulnerabilidades que parchear, y los escáneres de imágenes (Trivy, Grype) las detectan en el pipeline.

Cada instrucción del Dockerfile crea una capa, y Docker reutiliza una capa si ni ella ni las anteriores han cambiado. Por eso el orden importa: primero lo que cambia poco (el pom.xml y la descarga de dependencias) y al final lo que cambia en cada commit (el código). Spring Boot puede además partir el JAR en capas (dependencias, cargador, snapshots y aplicación) para que, al cambiar el código, solo se reconstruya y se suba la última.

Si alguien compromete la aplicación, un contenedor como root le da mucho más margen. Y un buen orden de capas convierte builds de varios minutos en segundos.

Copiar todo el proyecto (COPY . .) antes de descargar las dependencias: cualquier cambio en el código invalida la caché y vuelve a descargarlo todo.

Igual en Java 17 y 21; las imágenes base con JRE 21 (por ejemplo eclipse-temurin:21-jre) siguen el mismo patrón.

Se conecta con Dockerfile multi-stageEscaneo de imágenesSpring Boot layertools

Cuatro bloques cronometrados. No pases al siguiente sin tener el resultado esperado.

Bloque 1: Dockerfile Multi-Stage y JVM Flags en Contenedores (0 - 25 min)

Qué estudiar. Eclipse Temurin JRE, layertools de Spring Boot, MaxRAMPercentage.

Pregunta a responder. ¿Por qué layertools optimiza la velocidad del CI/CD?

Resultado esperado. Dockerfile multi-stage completo y testeado localmente.
Bloque 2: Manifiestos de Kubernetes (Deployment, Service, ConfigMap) (25 - 50 min)

Qué estudiar. Estructura YAML de Deployment, Service ClusterIP, variables desde ConfigMap/Secret.

Pregunta a responder. ¿Cómo conectar un microservicio Java con PostgreSQL usando Services internos?

Resultado esperado. Fichero deployment.yaml con health probes configuradas.
Bloque 3: Sondas de Salud y Despliegue en OpenShift (50 - 80 min)

Qué estudiar. Actuator liveness/readiness groups, permisos OpenShift GID 0, Route vs Ingress.

Pregunta a responder. ¿Qué diferencia hay entre una Route de OpenShift y un Ingress de K8s?

Resultado esperado. Configuración de Graceful Shutdown y probes en application.yml.
Cierre y Consolidación (80 - 90 min)

Qué estudiar. Checklist de producción para contenedores Java.

Pregunta a responder. ¿Qué 3 errores causan el 90% de los fallos de pods Java en producción?

Resultado esperado. Notas de mejores prácticas guardadas.

Tres formas de comprobar si lo has entendido, de menos a más exigente: explicarlo con tus palabras, responder preguntas trampa y resolver el reto del tutor.

Explícalo desde cero

Lee cada ficha y explícala en voz alta antes de seguir: si puedes contárselo a alguien que empieza, lo has entendido.

Por qué Liveness y Readiness deben ser endpoints separados

Lo que debes entender

Readiness decide si el Pod recibe tráfico. Liveness decide si el Pod debe ser asesinado y reiniciado. Si apuntas Liveness a una base de datos externa y la base de datos se ralentiza, Kubernetes matará todos tus Pods a la vez, creando una caída generalizada del sistema.

Analogía para contarlo

Readiness es como un médico diciéndole al recepcionista: "Estoy atendiendo a un paciente complejo, no me envíes más gente a la sala de espera por 5 minutos". Liveness es comprobar si el médico tiene pulso; si no tiene pulso, llamas a emergencias (reinicio).

Lo que suele explicarse mal

Usar un único endpoint /actuator/health genérico para ambas sondas.

Señal de que aún no lo dominas

Si la sonda de liveness comprueba la conexión a Kafka o a PostgreSQL.

Preguntas trampa

Responde de memoria, en voz alta o por escrito, y después abre la respuesta razonada: lo importante es el porqué, no la palabra exacta.

Nivel 1 (Básico) ¿Por qué ocurre el error OOMKilled (Exit Code 137) en un Pod Java de Kubernetes si configuraste -Xmx512m y el Pod tiene 512Mi de límite? Ver respuesta

Respuesta razonada

Porque -Xmx512m solo limita el heap, y el proceso Java consume bastante más memoria: metaspace con las clases cargadas, la caché de código del JIT, una pila por cada hilo, buffers directos, estructuras del recolector y memoria nativa de librerías. En una aplicación Spring Boot eso suma fácilmente 200-300 MB. Con 512 MB de heap más ese extra, el proceso supera los 512 Mi del límite y el kernel lo mata: OOMKilled con código 137, sin rastro de OutOfMemoryError en los logs.

La solución es dejar margen: no fijar -Xmx igual al límite sino usar -XX:MaxRAMPercentage (60-75 % según el tamaño), subir el límite del pod, reducir hilos de plataforma (los hilos virtuales ayudan) y medir el consumo real con Native Memory Tracking (-XX:NativeMemoryTracking=summary y jcmd <pid> VM.native_memory summary).

Qué está evaluando la pregunta

La JVM consume más memoria que solo el Heap: necesita espacio para Metaspace, threads stack (1MB por hilo), buffers I/O nativos y compilador JIT. 512m de heap + 150m de memoria no-heap supera los 512Mi del límite de Kubernetes, activando el OOM Killer del kernel.

Nivel 2 (Intermedio) ¿Por qué un contenedor Docker que funciona en Kubernetes Vanilla puede fallar con Permission Denied al desplegarse en OpenShift? Ver respuesta

Respuesta razonada

Porque OpenShift, con su SCC restricted-v2, no ejecuta el contenedor con el usuario declarado en la imagen sino con un UID aleatorio (por ejemplo, 1000680000) y el grupo 0. Si los ficheros de la imagen pertenecen a root o a un usuario concreto como spring:spring con permisos solo para el propietario, ese UID aleatorio no puede escribir en ellos, y cualquier escritura (logs, ficheros temporales, caché) falla con Permission denied. En Kubernetes estándar funcionaba porque usaba el UID de la imagen.

La solución es preparar la imagen para el grupo 0: chgrp -R 0 /app && chmod -R g=u /app, escribir en directorios montados como volúmenes emptyDir (/tmp) y no depender de un UID fijo ni de entradas en /etc/passwd. No se debe resolver dando a la aplicación la SCC anyuid, que relaja la seguridad.

Qué está evaluando la pregunta

OpenShift aplica SCC (Security Context Constraints) por defecto, ejecutando el contenedor con un UID aleatorio y sin permisos de root. Si la aplicación intenta escribir en directorios sin permisos del GID 0 o asume ser root, fallará.

Nivel 3 (Entrevista Senior) ¿Cómo diseñarías una estrategia de Zero-Downtime Deployment para un microservicio Spring Boot con conexiones de base de datos activas en Kubernetes? Ver respuesta

Respuesta razonada

Combinando varias piezas. En el Deployment, estrategia RollingUpdate con maxUnavailable: 0 y maxSurge: 1, para que siempre haya capacidad completa. Una readiness probe que solo dé éxito cuando la aplicación puede atender, de modo que el nuevo pod no recibe tráfico antes de tiempo. Un PodDisruptionBudget para que mantenimientos del clúster no tiren demasiados pods a la vez.

En el apagado: server.shutdown=graceful y spring.lifecycle.timeout-per-shutdown-phase para terminar las peticiones en curso; un preStop con una breve espera (sleep 5) porque los endpoints del Service tardan unos segundos en dejar de enviar tráfico tras la señal; y terminationGracePeriodSeconds mayor que la suma. HikariCP cierra sus conexiones limpiamente al cerrar el contexto. Por último, las migraciones de base de datos deben ser compatibles con la versión anterior (patrón expand/contract), porque durante el despliegue conviven ambas versiones.

Qué está evaluando la pregunta

Usa terminationGracePeriodSeconds (e.g. 30-60s) en el Pod spec, habilita Graceful Shutdown en Spring Boot (server.shutdown=graceful), configura un preStop hook con sleep 5 para dar tiempo a que los Services y endpoints actualicen su tabla de enrutamiento iptables/ipvs antes de que el proceso reciba SIGTERM, y asegura que la sonda de readiness marque al Pod como no listo inmediatamente.

Reto del tutor

Un Pod de Spring Boot tarda 45 segundos en arrancar por la inicialización de cachés y beans. Kubernetes lo mata repetidamente a los 30 segundos porque la sonda de Liveness falla con timeout. ¿Cómo lo resuelves de forma profesional?

Tu respuesta (se guarda en este navegador)

Lo que una respuesta suele tener bien

Menciona ajustar tiempos de espera o usar Startup Probe.

Lo que suele quedarse en la superficie

Decir que aumente el initialDelaySeconds de la livenessProbe a 100 segundos.

El concepto de fondo que suele faltar

Aumentar simplemente el initialDelaySeconds de la liveness retrasa la detección de cuelgues reales en pods que ya estaban vivos. El patrón moderno de Kubernetes es añadir una startupProbe dedicada.

Cómo lo respondería alguien senior en una entrevista

La solución arquitectónica correcta es implementar una startupProbe de Kubernetes que apunte a /actuator/health/liveness con failureThreshold: 30 y periodSeconds: 2 (dándole hasta 60 segundos para arrancar). Mientras la startupProbe esté evaluándose, Kubernetes deshabilita por completo las sondas de liveness y readiness. Una vez que la startup probe pasa con éxito por primera vez, se activan las comprobaciones de liveness y readiness con intervalos estándar (e.g. periodSeconds: 5).

Proyecto «Pedidos» · paso 29 de 30

Contenedores y Kubernetes

Empaquetar los servicios y desplegarlos en un clúster local.

De qué va el proyecto

El backend de una tienda online: clientes, catálogo de productos y pedidos con sus líneas, pagos y envíos. Empieza como un proyecto Maven con records y termina como un sistema con API REST, seguridad, mensajería, contenedores y observabilidad. Cada paso construye sobre el anterior, así que trabaja siempre en el mismo repositorio.

Qué hacer

Escribe un Dockerfile multi-etapa para pedidos, con usuario sin privilegios y las capas de Spring Boot.
Despliega pedidos y PostgreSQL en kind o minikube con Deployment, Service y ConfigMap.
Configura las probes de liveness y readiness con Actuator y -XX:MaxRAMPercentage.

Está listo cuando

Cambiar solo el código reconstruye la imagen en segundos gracias a la caché de capas.
Si la base de datos cae, el pod deja de recibir tráfico pero no se reinicia en bucle.

He terminado este paso Llevas 0 de 30 pasos del proyecto.

Katas: ejercicios cortos

Kata 29.1: Dockerfile Multi-Stage con Spring Boot Layertools Escribe un Dockerfile multi-stage que en la etapa 1 compile el jar, en la etapa 2 extraiga las capas con java -Djarmode=layertools -jar app.jar extract, y en la etapa final use eclipse-temurin:21-jre-alpine copiando dependencias y aplicación por separado.

Reglas de oro

Usa siempre -XX:MaxRAMPercentage=75.0 en lugar de -Xmx fijo dentro de contenedores.
Separa la Startup Probe de la Liveness Probe para aplicaciones con arranque pesado.
La Liveness Probe NUNCA debe comprobar bases de datos o servicios externos.
En OpenShift, da permisos de escritura al GID 0 para compatibilidad con SCC.
Usa layertools de Spring Boot para crear imágenes Docker con capas cacheadas eficientes.
Ejecuta el contenedor con un usuario sin privilegios (USER), nunca como root.

Notas del día 29 Se guarda automáticamente

Fuentes oficiales

Revisado el 29 de octubre de 2026. Este día en Markdown

Bloque 1: Dockerfile Multi-Stage y JVM Flags en Contenedores (0 - 25 min)

Bloque 2: Manifiestos de Kubernetes (Deployment, Service, ConfigMap) (25 - 50 min)

Bloque 3: Sondas de Salud y Despliegue en OpenShift (50 - 80 min)

Cierre y Consolidación (80 - 90 min)

Explícalo desde cero

Por qué Liveness y Readiness deben ser endpoints separados

Lo que debes entender

Analogía para contarlo

Lo que suele explicarse mal

Señal de que aún no lo dominas

Preguntas trampa

Respuesta razonada

Qué está evaluando la pregunta

Respuesta razonada

Qué está evaluando la pregunta

Respuesta razonada

Qué está evaluando la pregunta

Reto del tutor

Lo que una respuesta suele tener bien

Lo que suele quedarse en la superficie

El concepto de fondo que suele faltar

Cómo lo respondería alguien senior en una entrevista

Contenedores y Kubernetes

Qué hacer

Está listo cuando

Katas: ejercicios cortos

Reglas de oro

Fuentes oficiales