Administración de servidores de correo electrónico sus protocolos. Administración de contenedores y microservicios.

Índice

1. Por qué este tema son PUERTOS y ÓRDENES
2. La arquitectura del correo: los cuatro agentes
3. SMTP: el protocolo de envío
4. POP3 e IMAP: los protocolos de acceso
5. Los puertos, que es lo que decide la pregunta
6. El mensaje por dentro: cabeceras y MIME
7. Seguridad del correo
8. Administrar un servidor de correo
9. Contenedores: qué son y en qué se apoyan
10. Docker: la tabla de órdenes
11. Imágenes, Dockerfile y composición
12. Kubernetes: arquitectura y objetos
13. Operar Kubernetes: kubectl, configuración y publicación
14. Seguridad de contenedores
15. Arquitectura de microservicios
16. Cuadros para memorizar
17. Los errores que más caen
18. Autoevaluación

1. Por qué este tema son PUERTOS y ÓRDENES

Este es, con 59 preguntas en el corpus, el segundo tema más preguntado del bloque IV, y tiene la particularidad de reunir dos materias que no se parecen en nada: el correo electrónico, que es tecnología de los años ochenta perfectamente estable, y los contenedores con Kubernetes, que es lo más nuevo de todo el programa.

Las dos, sin embargo, se preguntan igual: por el número exacto y por la orden exacta.

• Los puertos del correo han caído cuatro veces, y en tres de ellas la pregunta consistía literalmente en elegir la terna correcta entre cuatro combinaciones de tres cifras: «POP:993 / SMTP:465 / IMAP:995» frente a «POP:995 / SMTP:465 / IMAP:993». Sin la tabla memorizada no hay forma de acertar.
• Las órdenes de Docker han caído seis veces, siempre con la misma construcción: la real y tres verbos inventados que suenan bien. docker pull frente a download, get e images. docker kill frente a end, interrupt y block. docker rm frente a delete, eliminate y excise.
• Kubernetes se pregunta por sus nombres propios: cuáles son los cuatro objetos básicos, qué componente del plano de control decide en qué nodo va un Pod, y en qué campo del manifiesto se identifica el objeto.

Hay además una tercera familia, que aparece en los dos mundos: la pregunta negativa. «¿Cuál de los siguientes NO es un protocolo de correo electrónico?» —y la respuesta es Outlook, que es un cliente— o «¿cuál NO es un beneficio de los microservicios?». Conviene leerlas con cuidado, porque la costumbre lleva a marcar la primera afirmación verdadera.

2. La arquitectura del correo: los cuatro agentes

El error más común al estudiar correo es pensar que SMTP, POP3 e IMAP son tres formas de hacer lo mismo. No lo son: SMTP envía y los otros dos recogen. Para verlo claro hay que separar los papeles.

Agente	Sigla	Qué hace
Agente de usuario	MUA	El programa con el que la persona escribe y lee: Outlook, Thunderbird, la aplicación del móvil, la interfaz web.
Agente de envío	MSA	Recibe el mensaje del cliente, lo valida y lo entrega al agente de transferencia. Es quien escucha en el puerto de envío y exige autenticación.
Agente de transferencia	MTA	Encamina el mensaje entre servidores hasta el dominio de destino. Postfix, Sendmail, Exim, Exchange.
Agente de entrega	MDA	Deposita el mensaje en el buzón del destinatario, aplicando filtros y reglas.

2.1 El recorrido completo de un mensaje

Esta es la pregunta larga del corpus, y merece seguirse paso a paso porque los cuatro distractores son variantes de asignar mal los protocolos:

1. El remitente escribe en su cliente y pulsa enviar. El cliente entrega el mensaje a su servidor de correo usando SMTP.
2. El servidor de origen consulta el registro MX del dominio de destino en el DNS y abre una conexión con el servidor de destino, otra vez por SMTP.
3. El servidor de destino deposita el mensaje en el buzón del destinatario.
4. Cuando el destinatario se conecta, su cliente descarga o consulta el mensaje con POP3 o con IMAP.

La respuesta que da por buena el tribunal, literal: «SMTP se usa desde el ordenador del usuario de origen al servidor de correo en el origen, así como desde el servidor de origen al servidor de destino. POP3 o IMAP se usan desde el servidor de correo en el destino hasta el ordenador del destinatario».

La regla que resume todo y evita fallar: SMTP es de empuje y va hacia delante; POP3 e IMAP son de tirón y solo actúan en el último tramo. Entre servidores nunca viaja POP3 ni IMAP.

2.2 El DNS y los registros del correo

Sin DNS no hay correo, y sus registros se preguntan:

• MX (Mail eXchanger): dice qué servidores reciben el correo de un dominio, con una prioridad numérica en la que el número más bajo se intenta primero.
• A y AAAA: resuelven el nombre del servidor a dirección IPv4 e IPv6.
• PTR: la resolución inversa, de dirección a nombre. Muchos servidores rechazan correo de direcciones sin PTR coherente.
• TXT: donde viven las políticas de autenticación del remitente, que se ven en el apartado 7.

3. SMTP: el protocolo de envío

SMTP (Simple Mail Transfer Protocol) es el protocolo de transferencia, definido originalmente en el RFC 821 y hoy en el RFC 5321. Es un protocolo de texto, de órdenes y respuestas, lo que permite depurarlo a mano con una conexión de terminal.

3.1 El diálogo

Una sesión sigue siempre el mismo guion, y sus órdenes se preguntan:

Orden	Qué hace
HELO / EHLO	Saludo inicial, con el nombre del cliente. EHLO es la versión extendida: el servidor responde con la lista de extensiones que admite.
AUTH	Autenticación del remitente. Es extensión, no estaba en el protocolo original.
MAIL FROM	Declara el remitente del sobre.
RCPT TO	Declara cada destinatario. Se repite una vez por cada uno.
DATA	Anuncia el cuerpo del mensaje, que termina con una línea con un solo punto.
STARTTLS	Pide cifrar la conexión ya establecida.
QUIT	Cierra la sesión.

Las respuestas son códigos de tres cifras cuyo primer dígito manda: 2xx es aceptación, 3xx pide continuar, 4xx es un fallo temporal —el emisor debe reintentar— y 5xx es un fallo permanente, que provoca el rebote. Distinguir el 4xx del 5xx es lo que separa un retraso de una pérdida, y se pregunta.

3.2 El saludo y el nombre que anuncia el servidor

Hay una pregunta del corpus que exige conocer un parámetro concreto de Postfix: cambiar el nombre que el servidor anuncia en el saludo, y que el cambio valga para todos los servidores SMTP, no solo para el que se está tocando. La respuesta es editar $helo_name en /etc/postfix/main.cf y reiniciar.

Los distractores enseñan tres cosas útiles. Que el parámetro no es $client ni smtp_helo. Que main.cf y master.cf no son lo mismo: el primero guarda los parámetros de configuración y el segundo, los procesos y servicios que Postfix arranca; poner un parámetro en el segundo no hace nada. Y que EHLO es una orden del diálogo, no de la consola: no se configura escribiéndola.

3.3 Retransmisión y su abuso

Un servidor que acepta enviar correo de cualquiera hacia cualquiera es un retransmisor abierto (open relay), y acaba en pocas horas convertido en fuente de correo basura y en todas las listas negras. La configuración correcta es aceptar retransmisión solo de las redes propias o de usuarios autenticados, y aceptar del exterior únicamente correo dirigido a los dominios propios. Es una de las decisiones de administración que más se preguntan como consecuencia.

4. POP3 e IMAP: los protocolos de acceso

Los dos sirven para lo mismo —que el cliente llegue al buzón— y se diferencian en dónde vive el correo.

	POP3	IMAP
Modelo	Descarga los mensajes al cliente y, por omisión, los borra del servidor.	Consulta los mensajes en el servidor sin descargarlos.
Dónde está el correo	En el equipo del usuario.	En el servidor.
Varios dispositivos	Mal: cada uno se lleva su parte y no hay estado común.	Bien: todos ven lo mismo y comparten el estado de leído.
Carpetas en servidor	No las gestiona.	Sí, con jerarquía y búsqueda del lado del servidor.
Sin conexión	Funciona: el correo está en local.	Depende de la caché local que mantenga el cliente.
Espacio en el servidor	Poco.	Mucho: exige cuotas y política de retención.

La ventaja de IMAP que da por buena el tribunal, literal: «permite visualizar los correos directamente en el servidor sin descargarlos». Y conviene saber por qué los otros tres distractores son falsos: IMAP no es más sencillo que POP3 —es bastante más complejo—, sí requiere autenticación como cualquier acceso a un buzón, y no descarga los correos automáticamente, que es justamente lo que hace POP3.

4.1 IMAP por dentro

Que el correo viva en el servidor tiene consecuencias que van más allá de poder verlo desde varios dispositivos, y algunas se preguntan:

• Carpetas del lado del servidor, con jerarquía. El cliente las ve y las manipula, pero la estructura es del buzón, no del programa.
• Marcas (flags) por mensaje: leído, respondido, marcado, borrado, borrador. Son las que permiten que el estado sea el mismo en todos los dispositivos.
• Borrado en dos tiempos: marcar como borrado no elimina; hace falta una operación de purga para que desaparezca de verdad. De ahí que un buzón pueda seguir lleno después de vaciar la papelera desde un cliente mal configurado.
• Búsqueda en el servidor: se puede pedir al servidor que busque, en vez de descargar todo para buscar en local. Es lo que hace usable un buzón de decenas de miles de mensajes desde el móvil.
• Descarga parcial: se puede pedir solo las cabeceras, o una parte MIME concreta, y dejar el adjunto de veinte megas sin bajar hasta que alguien lo abra.
• Notificación en espera (IDLE): el cliente deja la conexión abierta y el servidor le avisa cuando llega correo, en vez de preguntar cada pocos minutos. Es lo que da la sensación de correo instantáneo sin castigar la batería.

La contrapartida de administración es doble y hay que tenerla presente: el buzón consume espacio en el servidor indefinidamente, lo que obliga a cuotas y a política de retención, y la copia de seguridad del correo pasa a ser responsabilidad de la organización, porque ya no hay copias repartidas por los equipos de los usuarios. Con POP3 ocurría lo contrario: el servidor quedaba limpio y el riesgo se trasladaba al portátil de cada uno.

5. Los puertos, que es lo que decide la pregunta

Esta tabla hay que sabérsela de memoria y sin dudar. Es la que resuelve cuatro preguntas del corpus.

Protocolo	Puerto en claro	Puerto seguro	Modalidad
SMTP entre servidores	25	—	Con STARTTLS oportunista sobre el mismo 25.
SMTP de envío del cliente	—	587	STARTTLS con autenticación. Es el puerto de envío moderno.
SMTPS	—	465	TLS implícito: cifrado desde el primer byte.
POP3	110	995	El seguro, POP3S, con TLS implícito.
IMAP	143	993	El seguro, IMAPS, con TLS implícito.

Con eso, las preguntas se contestan solas:

• «Los puertos seguros para POP, SMTP e IMAP» → 995 / 465 / 993. El distractor favorito intercambia el 993 y el 995, que son los dos que más se confunden: el 995 es de POP3 y el 993 es de IMAP.
• «Puerto para SMTP autenticado con STARTTLS» → 587. Aquí la clave está en la palabra STARTTLS: si dijera «TLS implícito» sería el 465.
• «Puerto estándar de IMAPS según IANA» → 993.
• «Puerto por defecto de SMTPS» → 465.

5.1 STARTTLS frente a TLS implícito

Es la distinción conceptual que hay detrás de la tabla, y explica por qué el mismo protocolo tiene dos puertos seguros:

• TLS implícito: la conexión se cifra desde el primer byte. El puerto está dedicado a eso: 465, 993, 995. No hay ventana en claro.
• STARTTLS: la conexión empieza en claro y el cliente pide cifrar con una orden. Se usa sobre el puerto de siempre —25, 587, 143, 110—. Su riesgo conocido es el ataque de degradación: alguien en medio suprime el anuncio de la extensión y la sesión sigue sin cifrar; de ahí que los clientes serios exijan TLS en vez de aceptarlo si está disponible.

Y un dato que conviene tener claro para no equivocarse en un supuesto: el puerto 25 sigue siendo el del correo entre servidores, y muchos operadores lo bloquean de salida en las conexiones domésticas precisamente para frenar el correo basura. El envío desde un cliente va por el 587, no por el 25.

6. El mensaje por dentro: cabeceras y MIME

Un mensaje de correo tiene dos partes separadas por una línea en blanco: las cabeceras y el cuerpo. El formato lo fija el RFC 5322.

6.1 Las cabeceras que se preguntan

Cabecera	Qué contiene
From	El remitente que se muestra al destinatario. No tiene por qué coincidir con el del sobre.
To, Cc, Bcc	Destinatarios visibles, en copia y en copia oculta. La copia oculta no viaja en las cabeceras que llegan a los demás.
Subject	El asunto.
Date	Fecha de composición, puesta por el cliente.
Message-ID	Identificador único del mensaje.
In-Reply-To, References	Enlazan el mensaje con aquel al que responde. Es lo que permite agrupar conversaciones.
Received	Una por cada servidor que lo ha tocado, añadida arriba. Leyéndolas de abajo arriba se reconstruye el camino.
Return-Path	Dirección a la que van los rebotes: el remitente del sobre.

6.2 MIME

El correo original solo transportaba texto en caracteres de siete bits. MIME (Multipurpose Internet Mail Extensions) es la extensión que permite acentos, adjuntos, imágenes y mensajes con varias partes. Sus piezas:

• MIME-Version: declara que el mensaje usa la extensión.
• Content-Type: el tipo de contenido, con la forma tipo/subtipo: text/plain, text/html, application/pdf, image/png. Los mensajes con varias partes usan multipart/alternative —la misma información en texto y en HTML, para que el cliente elija— o multipart/mixed, que es el de los adjuntos.
• Content-Transfer-Encoding: cómo se han codificado los bytes para viajar. Los dos habituales son base64, que convierte binario en texto y engorda el mensaje en torno a un tercio, y quoted-printable, para texto con pocos caracteres especiales.
• Content-Disposition: si la parte se muestra incrustada o se ofrece como adjunto, con su nombre de fichero.

De ahí sale un dato práctico que se pregunta: el límite de tamaño de un adjunto no es el del fichero, sino el del mensaje codificado. Un servidor que admite mensajes de 25 MB acepta adjuntos de unos 18 MB, porque base64 añade cerca de un tercio.

7. Seguridad del correo

El correo nació sin autenticación de ninguna clase, y todo lo que hay hoy son capas añadidas encima. Las tres primeras se declaran en registros TXT del DNS y se preguntan juntas.

7.1 SPF, DKIM y DMARC

Mecanismo	Qué comprueba	Cómo
SPF Sender Policy Framework	Que el servidor que envía está autorizado por el dominio.	El dominio publica en el DNS la lista de direcciones que pueden enviar en su nombre. Se comprueba contra el remitente del sobre.
DKIM DomainKeys Identified Mail	Que el mensaje no ha sido alterado y viene del dominio que dice.	El servidor firma cabeceras y cuerpo con una clave privada; la pública está en el DNS.
DMARC	Qué hacer cuando SPF o DKIM fallan, y que el dominio del From concuerde con el verificado.	Publica una política —no hacer nada, poner en cuarentena o rechazar— y pide informes.

La relación entre los tres es la que importa: SPF y DKIM verifican, DMARC decide y alinea. Sin DMARC, un mensaje puede pasar SPF con un dominio del sobre distinto del que ve el usuario en el From, que es exactamente el hueco por donde se cuela la suplantación.

7.2 Cifrado y firma del contenido

TLS protege el transporte entre dos servidores, no el mensaje: en cada salto el correo vuelve a estar en claro dentro del servidor. Para protección de extremo a extremo hay dos familias:

• S/MIME: firma y cifra usando certificados X.509 emitidos por una autoridad de certificación. Es lo habitual en entornos corporativos y en la Administración, donde ya existe una infraestructura de clave pública.
• PGP y su versión libre GnuPG: mismo objetivo con un modelo de confianza distinto, basado en firmas cruzadas entre usuarios en vez de en una autoridad jerárquica.

Los dos aportan confidencialidad si se cifra, e integridad, autenticación y no repudio si se firma. Y los dos comparten el mismo problema práctico: la gestión de claves de los usuarios finales.

7.3 Filtrado

Un servidor de correo de una organización lleva siempre varias capas de filtrado, y sus nombres se preguntan:

• Listas de reputación (DNSBL): rechazan por la dirección de origen antes de aceptar el mensaje, que es lo más barato.
• Comprobación de destinatario: rechazar en la propia sesión los mensajes a buzones que no existen, en vez de aceptarlos y rebotarlos después —el rebote a un remitente falsificado convierte al servidor en emisor de correo basura, lo que se llama backscatter—.
• Análisis de contenido: puntuación por reglas y clasificación estadística.
• Antivirus sobre los adjuntos, y bloqueo por extensión de los tipos ejecutables.
• Espera forzada (greylisting): rechazar temporalmente el primer intento con un 4xx. Un servidor legítimo reintenta; muchos programas de envío masivo no.

La amenaza que más se nombra en los exámenes es el phishing, y su variante dirigida contra una persona concreta, el spear phishing, junto al fraude del director, en el que se suplanta a un cargo para ordenar una transferencia. Contra los tres, la defensa técnica es DMARC en modo de rechazo y el etiquetado visible del correo externo; la defensa organizativa es el procedimiento de verificación por otro canal.

8. Administrar un servidor de correo

8.1 Postfix

Es el agente de transferencia más habitual en Linux, y el que aparece en el corpus. Su configuración vive en dos ficheros que no hay que confundir:

Fichero	Qué contiene
/etc/postfix/main.cf	Los parámetros de configuración: nombre del servidor, dominios que acepta, redes autorizadas, límites, rutas de las tablas. Aquí va myhostname, mydomain, mydestination, mynetworks, relayhost, message_size_limit y helo_name.
/etc/postfix/master.cf	Los servicios y procesos que Postfix arranca y en qué puertos escucha cada uno.

Las órdenes de administración:

Orden	Para qué
postconf -n	Muestra los parámetros que difieren del valor por omisión. Es la forma rápida de ver qué hay configurado de verdad.
postfix check	Comprueba la configuración antes de recargar.
postfix reload	Aplica los cambios sin cortar el servicio.
mailq o postqueue -p	Muestra la cola de mensajes pendientes.
postqueue -f	Fuerza el reintento de la cola entera.
postsuper -d	Elimina mensajes de la cola.
newaliases	Reconstruye la base de alias tras editar /etc/aliases.

La cola merece atención porque es donde se diagnostica: un mensaje que lleva horas ahí con un error 4xx está esperando a un destino que no responde; uno que desaparece con 5xx ha rebotado. Postfix organiza varias colas —entrante, activa, diferida, en espera y de dañados— y reintenta con intervalos crecientes hasta un plazo máximo, tras el cual devuelve el mensaje.

8.2 Buzones, alias y cuotas

• Formato de buzón: mbox guarda todos los mensajes de una carpeta en un solo fichero, lo que provoca bloqueos con muchos accesos; Maildir guarda cada mensaje en un fichero propio, y es lo habitual hoy por concurrencia y por robustez.
• Alias: nombres que redirigen a uno o varios buzones reales. Sirven para direcciones funcionales —«registro», «informatica»— que sobreviven a los cambios de persona.
• Listas de distribución: un alias que expande a muchos destinatarios, con sus problemas propios de moderación y de bucles.
• Cuotas: imprescindibles con IMAP, porque el correo se queda en el servidor. Conviene avisar antes de bloquear, porque un buzón lleno rechaza correo entrante.

8.3 El correo como servicio contratado

Muchas organizaciones han pasado del servidor propio a un servicio en la nube, y el corpus lo refleja con una pregunta sobre Microsoft 365. Lo que cambia en la administración:

• Deja de administrarse el agente de transferencia y pasa a administrarse la configuración del inquilino: dominios verificados, conectores, reglas de flujo de correo, políticas de retención.
• Las aplicaciones internas que envían correo se configuran contra el puerto 587 con STARTTLS y autenticación, que es la pregunta literal del examen.
• La autenticación de los registros SPF, DKIM y DMARC sigue siendo responsabilidad de la organización, porque los registros están en su DNS.
• Aparecen obligaciones nuevas de ubicación y tratamiento de los datos, que en el sector público condicionan la contratación.

En el mundo Microsoft el servidor propio es Exchange, con su consola de administración y sus cmdlets de PowerShell, y sus conceptos propios —buzones, bases de datos de buzones, grupos de disponibilidad, conectores de envío y de recepción—.

8.4 Diagnosticar un problema de correo

El correo es de los pocos servicios que se pueden depurar hablando el protocolo a mano, y el examen valora ese criterio porque distingue a quien ha administrado uno de quien solo ha leído sobre ellos. El orden de comprobación, de fuera adentro:

1. El DNS. Antes que nada, comprobar que el dominio de destino publica registro MX y que resuelve: dig MX dominio.es. Un fallo de entrega masivo hacia un destino concreto suele empezar aquí.
2. La conexión. Abrir el puerto 25 del servidor de destino y ver si contesta con un código 220. Si no hay saludo, el problema es de red o de cortafuegos, no de correo.
3. El diálogo. Ejecutar a mano EHLO, MAIL FROM y RCPT TO y leer el código de respuesta. Es lo que separa «no acepta el destinatario» de «no acepta el remitente» de «no me deja retransmitir».
4. El cifrado. Para probar una conexión con TLS no vale la conexión de terminal simple: se usa un cliente que negocie TLS, con la variante implícita contra el 465 o pidiendo STARTTLS contra el 587.
5. La cola. mailq dice cuántos mensajes esperan y con qué error. Un 4xx repetido apunta a un destino saturado o a una espera forzada; un 5xx, a un rechazo definitivo.
6. Las cabeceras. En un mensaje que llegó tarde o que fue clasificado como basura, las cabeceras Received se leen de abajo arriba y cuentan el camino completo con marcas de tiempo, lo que permite localizar en qué salto se perdió el tiempo. Y los resultados de autenticación dicen si SPF, DKIM y DMARC pasaron.

Los códigos de respuesta que más se ven, y lo que significan de verdad:

Respuesta	Qué está pasando
220	El servicio está listo. Es el saludo.
250	Orden aceptada.
354	Adelante con el cuerpo del mensaje.
421	Servicio no disponible ahora. El emisor reintentará.
450 y 451	Fallo temporal: buzón ocupado, error de proceso, espera forzada.
452	Sin espacio suficiente para aceptarlo.
550	Buzón inexistente o rechazo definitivo por política.
554	Transacción fallida; también el rechazo típico de una lista de reputación.

Las causas más frecuentes de que un correo legítimo acabe rechazado o en la carpeta de no deseados son cuatro, y conviene tenerlas ordenadas porque son las que se plantean en un supuesto: SPF o DKIM mal publicados tras cambiar de proveedor, ausencia de registro PTR coherente para la dirección desde la que se envía, reputación dañada de esa dirección por un envío masivo previo, y contenido que dispara las reglas —enlaces acortados, adjuntos ejecutables, mensajes solo con una imagen—.

8.5 Listas, reenvíos y archivado

Tres asuntos de administración diaria que dan problemas característicos y que conviene reconocer:

• Listas de distribución. Un alias que expande a muchos destinatarios necesita decisiones que no son técnicas: quién puede escribir, si hay moderación y qué pasa con las respuestas. El fallo clásico es la lista abierta en la que alguien responde a todos para pedir que le den de baja, y otros cincuenta responden a todos para quejarse.
• Bucles de reenvío. Dos buzones que se reenvían mutuamente generan un ciclo que multiplica el mensaje hasta saturar la cola. Se ataja con el límite de saltos que cuenta las cabeceras Received, que es precisamente para lo que existe ese contador.
• Reenvío automático al exterior. Es una fuga de información silenciosa y una de las primeras cosas que hace quien roba una cuenta: configurar una regla que le mande copia de todo. Conviene vigilarlo y, en muchos organismos, prohibirlo por política.

El archivado es cosa distinta de la copia de seguridad, y el examen puede jugar con esa diferencia: la copia sirve para restaurar tras una pérdida y tiene una retención corta; el archivo sirve para conservar y buscar durante años, con índice y con garantías de integridad. Un buzón vaciado por el usuario desaparece de la copia en cuanto rota la retención, pero sigue en el archivo si existe una política de archivado.

Y una consideración que en el sector público condiciona el diseño: el correo de un puesto de trabajo puede contener datos personales y documentos que forman parte de un expediente. Eso obliga a fijar plazos de conservación, a controlar quién puede acceder a un buzón ajeno —y con qué autorización— y a documentar el procedimiento, que es lo que se revisa en una auditoría.

9. Contenedores: qué son y en qué se apoyan

La segunda mitad del tema. Un contenedor es un proceso —o un grupo de procesos— que se ejecuta aislado del resto del sistema y que lleva consigo todo lo que necesita para funcionar: bibliotecas, configuración y dependencias.

9.1 La diferencia con una máquina virtual

	Máquina virtual	Contenedor
Qué virtualiza	El hardware	El sistema operativo
Núcleo	Arranca el suyo propio	Comparte el del anfitrión
Tamaño	Gigabytes	Megabytes
Arranque	Minutos	Segundos
Aislamiento	Fuerte, por hardware	Menor: un fallo del núcleo alcanza a todos
Sistemas distintos	Puede ejecutar Windows sobre Linux	Comparte núcleo: no puede

Esa última fila explica un detalle del supuesto del examen que conviene mirar con espíritu crítico: la pregunta plantea «crear un Windows Server 2008 a partir de una imagen» con Docker, y lo que mide es la sintaxis de la orden, no la viabilidad del escenario. Un contenedor Windows necesita un anfitrión Windows compatible, porque comparte núcleo.

9.2 Los dos mecanismos del núcleo

Los contenedores no son una tecnología aparte, sino el uso combinado de dos capacidades del núcleo de Linux:

• Espacios de nombres (namespaces): deciden qué ve cada contenedor. Hay uno por recurso: procesos —el contenedor cree ser el PID 1—, red —con su propia pila e interfaces—, puntos de montaje, usuarios, nombre de máquina y comunicación entre procesos.
• Grupos de control (cgroups): deciden cuánto consume: procesador, memoria, entrada y salida y ancho de banda.

Es la pregunta de definición: espacios de nombres para AISLAR, grupos de control para LIMITAR. Confundir cuál hace cada cosa es el distractor exacto.

A esos dos se les suman las capacidades, que trocean los privilegios de root en permisos finos, y los sistemas de control de acceso obligatorio como SELinux o AppArmor, que acotan lo que el proceso puede hacer aunque escape del aislamiento.

9.3 LXC y los motores de contenedores

LXC (Linux Containers) es la tecnología de contenedores del propio Linux construida sobre esos mecanismos. Su enfoque original es el contenedor de sistema: algo parecido a una máquina ligera con su init y varios procesos dentro. Frente a él, el modelo que se impuso es el contenedor de aplicación: un proceso, una imagen, un cometido.

Las piezas del ecosistema que el corpus nombra:

Pieza	Qué es
Docker	La plataforma que popularizó el modelo: construir imágenes, ejecutarlas y distribuirlas.
containerd y CRI-O	Tiempos de ejecución de contenedores, que es la capa que de verdad los arranca.
Podman	Alternativa sin demonio y con contenedores sin privilegios, muy usada en el mundo Red Hat.
Kubernetes	El orquestador: no ejecuta contenedores, decide dónde y cuántos.
OCI	La iniciativa que normaliza el formato de imagen y el tiempo de ejecución, para que no dependan de un fabricante.

9.4 Qué aportan y qué no resuelven

Conviene tener ordenado por qué se han impuesto, porque el examen pregunta beneficios y también límites:

Aportan	En qué se nota
Reproducibilidad	La aplicación viaja con sus dependencias, así que se ejecuta igual en el portátil del desarrollador y en producción. Es el final del «en mi máquina funciona».
Densidad	Decenas por nodo, frente a unas pocas máquinas virtuales, porque no hay un sistema operativo por instancia.
Velocidad	Arranque en segundos, lo que hace viables el escalado automático y las actualizaciones progresivas.
Inmutabilidad	No se parchea un contenedor: se construye una imagen nueva y se sustituye. Eso elimina la deriva entre servidores que nadie recuerda haber tocado.

Y lo que no resuelven, que es donde se equivoca quien los toma por una solución universal:

• No dan aislamiento de máquina virtual. Comparten núcleo: una vulnerabilidad del núcleo alcanza a todos los contenedores del nodo. Por eso las cargas de distinto nivel de confianza se separan en máquinas distintas.
• No convierten una aplicación mal diseñada en escalable. Si guarda estado en disco local o en la sesión del proceso, replicarla no funciona: hay que sacar el estado fuera.
• No simplifican la operación por sí solos. Al contrario: sustituyen unos pocos servidores conocidos por muchas piezas efímeras, lo que exige registro centralizado, métricas y trazabilidad para poder diagnosticar algo.
• No eliminan el mantenimiento. Una imagen construida hace seis meses acumula vulnerabilidades igual que un servidor sin parchear; la diferencia es que aquí se reconstruye en vez de actualizarse.

10. Docker: la tabla de órdenes

Seis preguntas del corpus son exactamente esta tabla. Todas tienen la misma construcción: el verbo real y tres inventados que suenan plausibles.

Necesidad	Orden	Distractores usados
Descargar una imagen del registro	docker pull ImagenA	download, get, images
Crear e iniciar un contenedor, descargando la imagen si hace falta	docker run	start, exec, play
Arrancar un contenedor que ya existe y está parado	docker start	—
Listar los contenedores incluidos los parados	docker ps -a	ls -a, list -a, list-container -all
Detener un contenedor de inmediato	docker kill 3f7	end, interrupt, block
Eliminar un contenedor	docker rm 3f7	delete, eliminate, excise

Y las que completan el juego, que no han caído todavía pero pertenecen al mismo grupo:

Orden	Qué hace
docker images	Lista las imágenes descargadas. Cuidado: ps lista contenedores, images lista imágenes.
docker rmi	Elimina una imagen. La de contenedor es rm.
docker stop	Detiene ordenadamente: envía la señal de terminar y espera un margen antes de matar.
docker exec -it	Ejecuta una orden dentro de un contenedor que ya corre. Es la forma de abrir una consola en él.
docker logs	Muestra la salida del contenedor.
docker build -t nombre .	Construye una imagen a partir de un Dockerfile.
docker push	Sube una imagen al registro.
docker inspect	Devuelve toda la configuración del objeto en formato JSON.
docker volume / network	Administran volúmenes y redes.

11. Imágenes, Dockerfile y composición

11.1 Imagen y contenedor no son lo mismo

Es la distinción de base: la imagen es una plantilla inmutable, de solo lectura, formada por capas superpuestas; el contenedor es una instancia en ejecución de esa imagen, con una capa de escritura propia encima. De una imagen salen tantos contenedores como se quiera, y lo que se escriba dentro de uno desaparece al eliminarlo, salvo que se haya montado un volumen.

Las capas explican el ahorro: si diez imágenes parten de la misma base, esa base se guarda una sola vez y se comparte. Y explican también una buena práctica que se pregunta: poner al principio del Dockerfile lo que cambia poco, porque al reconstruir se reaprovechan las capas anteriores a la primera modificación.

11.2 El Dockerfile

El fichero de construcción, con las instrucciones que se preguntan:

Instrucción	Qué hace
FROM	Imagen base de la que se parte. Es siempre la primera.
RUN	Ejecuta una orden durante la construcción y crea una capa.
COPY / ADD	Introducen ficheros en la imagen. ADD además descomprime y admite URL, y por eso se prefiere COPY, que hace menos cosas por sorpresa.
WORKDIR	Fija el directorio de trabajo.
ENV	Define variables de entorno.
EXPOSE	Documenta el puerto que la aplicación usa. No lo publica: eso lo hace la opción de publicación al ejecutar.
USER	Cambia el usuario con el que se ejecuta. Ejecutar como root dentro del contenedor es una mala práctica conocida.
CMD	Orden por omisión al arrancar. Se puede sustituir desde la línea de órdenes.
ENTRYPOINT	Ejecutable fijo del contenedor. Lo que se pase por la línea de órdenes se le añade como argumentos.

La pareja CMD y ENTRYPOINT se pregunta por su diferencia: el segundo define qué es el contenedor y el primero, con qué argumentos arranca por omisión.

11.3 Volúmenes y redes

Un contenedor es efímero por diseño. Para que un dato sobreviva hay tres mecanismos:

• Volumen: espacio gestionado por el motor, independiente del ciclo de vida del contenedor. Es la forma recomendada.
• Montaje de enlace (bind mount): un directorio del anfitrión montado dentro. Útil en desarrollo, más frágil en producción.
• Sistema de ficheros en memoria: para datos temporales que no deben tocar disco.

En cuanto a red, los modos que se preguntan: puente, el de omisión, con red privada y traducción de direcciones; anfitrión, en el que el contenedor comparte la pila de red de la máquina y no hay aislamiento; y ninguna, sin red. Publicar un puerto es asociar uno del anfitrión con otro del contenedor.

11.4 Composición y registros

Una aplicación real son varios contenedores —la aplicación, la base de datos, la caché— y para describirlos juntos existe la composición: un fichero declarativo con los servicios, sus imágenes, sus volúmenes y sus redes, que se levanta con una sola orden. Es el paso intermedio entre ejecutar contenedores a mano y orquestarlos con Kubernetes.

El registro es el almacén de imágenes: público como Docker Hub, o privado dentro de la organización, que es lo exigible en un entorno corporativo por dos motivos que se preguntan: no depender de un servicio externo para desplegar y controlar qué imágenes entran, analizándolas en busca de vulnerabilidades antes de aprobarlas.

12. Kubernetes: arquitectura y objetos

Kubernetes es un orquestador de contenedores: no los construye ni los ejecuta él, sino que decide en qué máquina va cada uno, los reinicia si caen, los escala según la carga y les da red, configuración y descubrimiento de servicios. Es la definición que pide el examen.

12.1 Los dos planos

Plano de control	Qué hace
kube-apiserver	La puerta única: todo pasa por él, valida y expone la interfaz de programación.
etcd	El almacén clave-valor donde vive todo el estado del conjunto. Es lo que hay que copiar para poder recuperarlo.
kube-scheduler	Decide en qué nodo se ejecuta cada Pod, según los recursos disponibles y las restricciones declaradas.
kube-controller-manager	Ejecuta los bucles que llevan el estado real hacia el estado declarado.
cloud-controller-manager	Integra con el proveedor de nube subyacente, cuando lo hay.

Nodo de trabajo	Qué hace
kubelet	El agente que vive en cada nodo y se asegura de que los contenedores declarados estén corriendo.
kube-proxy	Mantiene las reglas de red que hacen posible el reparto entre Pods.
Tiempo de ejecución	Quien de verdad arranca los contenedores: containerd, CRI-O.

La pregunta literal del corpus es cuál de los componentes del plano de control decide en qué nodo debe ejecutarse un Pod: el kube-scheduler. Los distractores son los otros tres componentes reales, que valida y expone, guarda el estado y ejecuta bucles de control.

12.2 Los objetos básicos

Otra pregunta literal: cuáles son los objetos básicos. La respuesta del tribunal es Pod, Service, Volume y Namespace. Los distractores metían State, que no es un objeto, y Job y Deployment, que existen pero pertenecen al grupo de los controladores, no al de los básicos.

Objeto	Qué es
Pod	La unidad mínima desplegable: uno o varios contenedores que comparten red y almacenamiento y viven y mueren juntos.
Service	Un punto de acceso estable a un conjunto de Pods, con nombre y dirección fijos y reparto de carga. Existe porque los Pods son efímeros y cambian de dirección.
Volume	Almacenamiento asociado al Pod, para que el dato sobreviva al reinicio del contenedor.
Namespace	Separación lógica dentro del mismo conjunto, para aislar entornos o equipos y aplicarles cuotas.

Y los controladores, que son los que se usan a diario: Deployment, que mantiene un número de réplicas y gestiona las actualizaciones progresivas; ReplicaSet, que garantiza ese número; StatefulSet, para aplicaciones con estado e identidad estable; DaemonSet, que pone una copia en cada nodo; Job y CronJob, para tareas que terminan.

12.3 El manifiesto y sus cuatro campos

Todo objeto se declara en un fichero con la misma estructura, y el examen pregunta por uno de sus campos:

Campo	Qué contiene
apiVersion	La versión de la interfaz que interpreta el objeto.
kind	El tipo de objeto: Pod, Service, Deployment.
metadata	Los valores que identifican unívocamente al objeto: nombre, espacio de nombres, identificador único, etiquetas y anotaciones.
spec	El estado deseado: qué se quiere que exista.

La respuesta de la pregunta es metadata. Y conviene retener la idea que sostiene todo Kubernetes: se declara el estado deseado en spec y el sistema trabaja continuamente para que el estado real coincida. Eso es lo que se llama reconciliación, y es el motivo de que un Pod eliminado a mano vuelva a aparecer si lo gestiona un Deployment.

Las etiquetas merecen mención propia: son pares de clave y valor con los que se marcan los objetos, y el mecanismo con el que un Service localiza los Pods a los que sirve. No son decorativas: son el pegamento del modelo.

13. Operar Kubernetes: kubectl, configuración y publicación

Saber qué es Kubernetes no basta: el enunciado habla de administración, y eso son órdenes y objetos de uso diario.

13.1 kubectl

La herramienta de línea de órdenes, que habla siempre con el apiserver. Su gramática es regular —verbo, tipo de objeto, nombre— igual que la de Docker, y por eso se presta a las mismas preguntas:

Orden	Qué hace
kubectl get pods	Lista los Pods del espacio de nombres actual. Con -A, de todos.
kubectl describe pod nombre	Detalle del objeto y sus sucesos, que es donde se ve por qué no arranca.
kubectl logs nombre	La salida del contenedor. Con -f, en vivo.
kubectl apply -f fichero.yaml	Aplica un manifiesto de forma declarativa: crea lo que falta y actualiza lo que difiere.
kubectl delete -f fichero.yaml	Elimina lo declarado en el manifiesto.
kubectl exec -it nombre -- sh	Abre una consola dentro del contenedor.
kubectl scale deployment x --replicas=5	Cambia el número de réplicas.
kubectl rollout status / undo	Sigue una actualización progresiva o la revierte.
kubectl get events	Los sucesos del conjunto, ordenados en el tiempo.

La distinción que importa es apply frente a create: el primero es declarativo y se puede repetir sobre un objeto existente; el segundo es imperativo y falla si ya existe. Es la misma idea de idempotencia que sostiene las herramientas de gestión de configuración.

13.2 Configuración y secretos

Una imagen debe ser la misma en desarrollo y en producción; lo que cambia es la configuración. Kubernetes la separa en dos objetos:

• ConfigMap: pares de clave y valor con configuración no sensible, que se inyectan como variables de entorno o se montan como ficheros.
• Secret: lo mismo para datos sensibles —contraseñas, claves, certificados—. ⚠ Conviene saber que por omisión van codificados en base64, que NO es cifrado: cualquiera con permiso de lectura los ve en claro. Protegerlos de verdad exige cifrado en reposo en etcd, control de acceso por roles y, con frecuencia, un gestor externo de secretos.

13.3 Sondas de estado

Kubernetes necesita saber si un contenedor está vivo y si puede atender peticiones, y lo pregunta con tres sondas que se confunden entre sí:

Sonda	Qué pregunta	Qué pasa si falla
De vida (liveness)	¿Sigue funcionando?	El contenedor se reinicia.
De disponibilidad (readiness)	¿Puede atender peticiones ya?	Se le deja de enviar tráfico, sin reiniciarlo.
De arranque (startup)	¿Ha terminado de iniciarse?	Aplaza a las otras dos, para aplicaciones que tardan.

El error clásico —y preguntable— es usar una sonda de vida donde correspondía una de disponibilidad: una aplicación que tarda en arrancar acaba en un ciclo de reinicios perpetuo porque se la mata antes de que llegue a estar lista.

13.4 Publicar hacia fuera

Un Service da acceso estable, pero dentro del conjunto. Para salir hay varios tipos, y su escala se pregunta:

Tipo	Alcance
ClusterIP	El de omisión: solo accesible dentro del conjunto.
NodePort	Abre el mismo puerto en todos los nodos.
LoadBalancer	Solicita un balanceador al proveedor de infraestructura.
Ingress	No es un tipo de Service, sino un objeto aparte: enruta HTTP y HTTPS por nombre de máquina y por ruta, y termina el cifrado. Es la puerta de entrada web.

13.5 Escalado y actualizaciones

El escalado automático horizontal añade o quita réplicas según una métrica —uso de procesador, peticiones por segundo—, que es la forma en que se materializa el «escalado flexible» que se atribuye a los microservicios. Junto a él, el escalado del propio conjunto añade nodos cuando no caben más Pods.

Las actualizaciones progresivas son el comportamiento por omisión de un Deployment: se van sustituyendo réplicas de la versión vieja por réplicas de la nueva, respetando cuántas pueden faltar y cuántas pueden sobrar durante el proceso. Si algo va mal, kubectl rollout undo devuelve la versión anterior. Es el equivalente, dentro del conjunto, del despliegue azul-verde y del canario.

14. Seguridad de contenedores

Un contenedor comparte núcleo con el anfitrión, así que su aislamiento es más fino que el de una máquina virtual y la seguridad se construye por capas. Las prácticas que se preguntan:

14.1 La imagen

• Partir de una base mínima: cuanto menos hay dentro, menos superficie de ataque y menos vulnerabilidades que parchear. Una imagen con un sistema completo arrastra decenas de paquetes que nadie usa.
• Fijar la versión de la imagen base por su resumen criptográfico o por una etiqueta concreta, nunca por una etiqueta móvil: lo que se construyó ayer debe poder reconstruirse igual mañana.
• Analizar la imagen en busca de vulnerabilidades conocidas antes de aprobarla, y repetir el análisis periódicamente: una imagen que era segura al construirla deja de serlo cuando aparece un CVE nuevo.
• No meter secretos en la imagen. Las capas son inmutables: una contraseña escrita en un RUN queda ahí aunque se borre después en otra capa.
• Construcción en varias etapas: compilar en una imagen con las herramientas y copiar solo el resultado a la imagen final, que así no lleva compilador ni código fuente.

14.2 La ejecución

• No ejecutar como root dentro del contenedor. Con USER en el Dockerfile y con la política del orquestador.
• Sistema de ficheros de solo lectura siempre que la aplicación lo permita, con volúmenes concretos para lo que necesite escribir.
• Retirar capacidades que no se usen y evitar el modo privilegiado, que prácticamente anula el aislamiento.
• Límites de recursos por contenedor, para que uno que se desmande no ahogue al resto del nodo.
• Políticas de red que restrinjan qué Pods pueden hablar con cuáles: por omisión, en Kubernetes, todos pueden hablar con todos.

14.3 El control de acceso

En Kubernetes, el control de acceso por roles define qué puede hacer cada cuenta sobre qué objetos y en qué espacio de nombres. Las piezas: Role y ClusterRole describen permisos; RoleBinding y ClusterRoleBinding los asignan a usuarios o a cuentas de servicio. Y el criterio es el de siempre: mínimo privilegio, con cuentas de servicio propias por aplicación en vez de la cuenta por omisión.

Por encima está el control de admisión: reglas que el apiserver aplica a cada objeto antes de aceptarlo, y que permiten rechazar lo que incumple la política de la organización —un contenedor privilegiado, una imagen de un registro no aprobado, un Pod sin límites de recursos—. Es donde la política deja de ser un documento y pasa a ser efectiva.

14.4 Qué hay que vigilar

La monitorización de un entorno de contenedores tiene dos caras. La de disponibilidad —Pods reiniciándose en bucle, nodos sin capacidad, sondas fallando— y la de seguridad: procesos inesperados dentro de un contenedor, conexiones salientes que no corresponden, montajes del sistema de ficheros del anfitrión. Los registros, además, hay que sacarlos fuera: cuando un Pod desaparece se lleva consigo lo que tuviera escrito dentro.

15. Arquitectura de microservicios

El enunciado oficial cierra con la administración de contenedores y microservicios, y conviene no confundirlos: los contenedores son una tecnología de empaquetado y los microservicios, un estilo de arquitectura. Se usan juntos casi siempre, pero se puede tener contenedores sin microservicios y microservicios sin contenedores.

15.1 Qué son

Una arquitectura de microservicios descompone la aplicación en servicios pequeños, autónomos y desplegables por separado, cada uno responsable de una capacidad del negocio, con su propio almacén de datos y comunicándose por interfaces bien definidas. Se opone al monolito, en el que todo vive en una sola pieza que se despliega entera.

	Monolito	Microservicios
Despliegue	Todo junto, con una ventana común.	Cada servicio por su cuenta y a su ritmo.
Escalado	Se replica la aplicación entera.	Se replica solo la parte que lo necesita.
Tecnología	Una sola pila para todo.	Cada servicio puede usar la suya.
Datos	Una base compartida.	Una base por servicio.
Fallo	Un error puede tumbar el conjunto.	Se puede degradar una función sin bloquear la aplicación.
Complejidad	Baja al principio, alta al crecer.	Alta desde el primer día, en operación y en red.

15.2 Los beneficios, y el que NO lo es

Esta es la pregunta negativa del corpus, y se contesta reconociendo los beneficios reconocidos:

• Escalado flexible: replicar únicamente el servicio que se satura.
• Integración y entrega continuas: al ser piezas pequeñas e independientes, se despliegan a menudo y con poco riesgo.
• Resistencia a los errores: degradar una funcionalidad sin bloquear toda la aplicación.
• Libertad tecnológica: cada servicio elige el lenguaje y el almacén que mejor le encajan.
• Equipos autónomos: cada uno es dueño de su servicio de principio a fin.

Lo que NO es un beneficio, en las palabras del examen: «el enfoque de diseño único, sin posibilidad de elegir la tecnología». Es justo lo contrario de la libertad tecnológica, que sí es un beneficio. La opción está redactada para que suene a ventaja —«enfoque único» suena a coherencia— cuando describe una limitación.

Y los costes, que también se preguntan porque el examen valora el criterio: la complejidad operativa se dispara —hay que desplegar, vigilar y depurar decenas de piezas—, la red pasa a ser un punto de fallo permanente, la coherencia de los datos deja de ser transaccional y se vuelve eventual, y depurar un problema exige trazabilidad distribuida, porque una petición atraviesa varios servicios.

15.3 Los patrones que acompañan

Patrón	Qué resuelve
Puerta de enlace de API	Punto de entrada único que enruta a cada servicio y concentra lo transversal: autenticación, limitación de peticiones, registro de trazas.
Descubrimiento de servicios	Localizar dónde está cada instancia sin escribir direcciones a mano. En Kubernetes lo resuelven el Service y el DNS interno.
Cortacircuitos	Dejar de llamar a un servicio que falla, para no arrastrar la caída al que llama. Es el mecanismo detrás de la degradación controlada.
Reintento con espera creciente	Volver a intentar espaciando los intentos, para no rematar a un servicio que se está recuperando.
Base de datos por servicio	Evitar el acoplamiento por los datos, que es el que anula la independencia.
Saga	Coordinar una operación que abarca varios servicios sin transacción distribuida, con pasos compensatorios.
Trazabilidad distribuida	Seguir una petición a través de todos los servicios que atraviesa, con un identificador común.

15.4 MicroProfile

La pregunta del corpus busca la especificación de la comunidad alineada con Jakarta EE Core Profile para desarrollar un microservicio: es MicroProfile. Nació precisamente para llevar Java al mundo de los microservicios, y reúne especificaciones que responden a los problemas del apartado anterior: Config para la configuración externa, Health para las sondas de vida y disponibilidad que Kubernetes consulta, Metrics para exponer indicadores, Fault Tolerance para el cortacircuitos y los reintentos, OpenAPI para documentar la interfaz, JWT para la propagación de la identidad y OpenTracing para la trazabilidad.

Los distractores del examen eran especificaciones reales de Jakarta EE —Authentication, Batch, Connectors— que resuelven otras cosas: autenticación, procesos por lotes e integración con sistemas externos.

15.5 Cómo se comunican

Dos familias, y la elección entre ellas se pregunta como criterio:

• Síncrona: el que llama espera respuesta. Es lo natural con REST sobre HTTP y con gRPC, que usa HTTP/2 y un formato binario y rinde mejor entre servicios. Sencilla de entender, pero acopla la disponibilidad: si el llamado no responde, el que llama se queda esperando.
• Asíncrona: el que llama deja un mensaje y sigue. Se apoya en colas y sistemas de mensajería. Desacopla y absorbe picos, a costa de que la coherencia sea eventual y de que depurar sea más difícil.

En cuanto a los protocolos que admite Kubernetes para publicar servicios, la respuesta es que los Service trabajan sobre TCP, UDP y SCTP; lo que va por encima —HTTP, gRPC— es asunto de la aplicación y del controlador de entrada.

15.6 Cuándo NO conviene ir a microservicios

El examen pregunta por los beneficios, pero la administración pública española despliega sobre todo aplicaciones de gestión, y el criterio de cuándo no aplicar el estilo es tan valorable como el de cuándo aplicarlo. Las cuatro señales:

• El dominio todavía no se entiende bien. Trocear mal es peor que no trocear: las fronteras equivocadas obligan a que cada cambio toque varios servicios a la vez, y entonces se paga la complejidad sin cobrar la independencia.
• El equipo es pequeño. La arquitectura pide despliegue automatizado, vigilancia, trazabilidad y guardia. Sin capacidad operativa detrás, cada servicio nuevo es una pieza más que nadie mira.
• La carga no lo exige. El escalado flexible solo aporta cuando hay una parte que se satura de verdad. Si el sistema entero cabe en dos máquinas, replicar el monolito es más barato.
• Las operaciones necesitan transacciones. Cuando el negocio exige que varias cosas ocurran o no ocurra ninguna, una base de datos con transacciones lo resuelve en una línea, y una saga con pasos compensatorios cuesta semanas.

De ahí el término que conviene conocer porque describe el peor resultado posible: el monolito distribuido. Un sistema partido en servicios que, sin embargo, comparten base de datos, se despliegan a la vez y se caen juntos. Tiene todos los costes del modelo distribuido y ninguna de sus ventajas, y suele ser el desenlace de trocear antes de entender el dominio.

La alternativa intermedia que hoy se recomienda es el monolito modular: una sola unidad de despliegue con fronteras internas bien definidas, de la que se van extrayendo servicios solo cuando hay una razón concreta —una parte que escala distinto, un equipo que necesita ritmo propio, una tecnología que no encaja—. Es también la vía habitual de modernización de una aplicación heredada, que se llama estrangulamiento: se va sacando funcionalidad a servicios nuevos mientras el sistema viejo sigue en pie, hasta que queda vacío.

16. Cuadros para memorizar

16.1 Los puertos

Puerto	Protocolo
25	SMTP entre servidores
465	SMTPS, TLS implícito
587	Envío del cliente con STARTTLS y autenticación
110	POP3
995	POP3S
143	IMAP
993	IMAPS

Y la terna que más ha caído: POP 995 · SMTP 465 · IMAP 993.

16.2 Las órdenes de Docker

Necesidad	Orden
Descargar una imagen	docker pull
Crear y arrancar un contenedor	docker run
Arrancar uno que ya existe	docker start
Listar contenedores en marcha	docker ps
Listar TODOS, incluidos los parados	docker ps -a
Listar imágenes	docker images
Detener ordenadamente	docker stop
Interrumpir de inmediato	docker kill
Eliminar un contenedor	docker rm
Eliminar una imagen	docker rmi
Ejecutar algo dentro de uno vivo	docker exec
Construir una imagen	docker build

16.3 Kubernetes

Concepto	Respuesta
Qué es	Un orquestador de contenedores
Objetos básicos	Pod, Service, Volume, Namespace
Unidad mínima desplegable	Pod
Quien decide en qué nodo va un Pod	kube-scheduler
Dónde vive el estado del conjunto	etcd
Puerta única de entrada	kube-apiserver
Agente en cada nodo	kubelet
Campo que identifica el objeto	metadata
Campo con el estado deseado	spec
Protocolos de un Service	TCP, UDP y SCTP

16.4 Parejas que se confunden

Uno	El otro	La diferencia
SMTP	POP3 / IMAP	Envía y va hacia delante / recogen, solo en el último tramo.
POP3	IMAP	Descarga al cliente / consulta en el servidor.
465	587	TLS implícito / STARTTLS con autenticación.
993	995	IMAPS / POP3S. Se intercambian en los distractores.
main.cf	master.cf	Parámetros de Postfix / servicios y procesos.
Sobre	Cabecera From	Lo que ve el servidor / lo que ve el usuario. No tienen por qué coincidir.
SPF	DKIM	Autoriza al servidor emisor / firma el mensaje.
Imagen	Contenedor	Plantilla inmutable por capas / instancia en ejecución.
run	start	Crea uno nuevo / arranca uno existente.
stop	kill	Termina con margen / corta de inmediato.
rm	rmi	Elimina contenedor / elimina imagen.
Espacios de nombres	Grupos de control	Aíslan lo que se ve / limitan lo que se consume.
Docker	Kubernetes	Construye y ejecuta / orquesta y decide dónde.
Contenedor	Microservicio	Tecnología de empaquetado / estilo de arquitectura.
CMD	ENTRYPOINT	Argumentos por omisión / ejecutable fijo.

17. Los errores que más caen

1. Intercambiar el 993 y el 995. El 993 es IMAPS y el 995 es POP3S. Es el distractor más repetido del tema.
2. Dar el 465 cuando la pregunta dice STARTTLS. Con STARTTLS y autenticación es el 587; el 465 es TLS implícito.
3. Creer que POP3 o IMAP viajan entre servidores. Entre servidores solo va SMTP; los otros dos actúan en el último tramo.
4. Tomar Outlook por un protocolo. Es un cliente, un agente de usuario.
5. Decir que IMAP es más sencillo que POP3. Es bastante más complejo; su ventaja es consultar en el servidor sin descargar.
6. Confundir main.cf con master.cf. El parámetro helo_name va en el primero.
7. Olvidar -a en docker ps. Sin la opción no salen los contenedores parados.
8. Usar docker start cuando el contenedor no existe todavía. Crear y arrancar es run.
9. Usar stop cuando el enunciado dice «inmediatamente». Eso es kill.
10. Confundir rm con rmi. El segundo borra imágenes.
11. Meter State o Deployment entre los objetos básicos. Son Pod, Service, Volume y Namespace.
12. Atribuir al apiserver la decisión del nodo. Esa es del scheduler.
13. Buscar el identificador del objeto en spec. Está en metadata; spec guarda el estado deseado.
14. Decir que Kubernetes ejecuta contenedores. Los orquesta; ejecutarlos es cosa del tiempo de ejecución.
15. Tomar el diseño único por un beneficio de los microservicios. El beneficio es justo el contrario: poder elegir la tecnología.
16. Confundir espacios de nombres con grupos de control. Los primeros aíslan, los segundos limitan.
17. Creer que lo escrito dentro de un contenedor persiste. Desaparece al eliminarlo, salvo que haya un volumen.
18. Pensar que EXPOSE publica el puerto. Solo lo documenta.
19. Guardar un secreto en un Secret y darlo por cifrado. Por omisión va en base64, que es codificación y no cifrado: quien pueda leerlo lo ve en claro.
20. Poner una sonda de vida donde tocaba una de disponibilidad. Una aplicación que tarda en arrancar acaba en un ciclo de reinicios porque se la mata antes de estar lista.
21. Escribir un secreto en una capa del Dockerfile y borrarlo después. Las capas son inmutables: sigue ahí, recuperable, aunque no se vea en la imagen final.
22. Confundir el archivado con la copia de seguridad del correo. La copia restaura tras una pérdida y tiene retención corta; el archivo conserva y permite buscar durante años.

18. Autoevaluación

1. Enumera los puertos seguros de POP, SMTP e IMAP en ese orden.
2. ¿Qué puerto se usa para SMTP autenticado con STARTTLS, y en qué se diferencia del 465?
3. Describe el recorrido de un mensaje indicando qué protocolo actúa en cada tramo.
4. ¿Cuál es la ventaja de IMAP frente a POP3, en las palabras del tribunal?
5. ¿Qué registro del DNS indica qué servidores reciben el correo de un dominio, y qué prioridad se intenta primero?
6. Diferencia el remitente del sobre de la cabecera From, y explica qué tiene que ver con la suplantación.
7. ¿Qué comprueba SPF, qué comprueba DKIM y qué añade DMARC?
8. ¿En qué fichero de Postfix va el parámetro del nombre de saludo, y qué guarda el otro fichero?
9. ¿Qué orden muestra la cola de mensajes pendientes, y qué significa que un mensaje lleve horas ahí?
10. ¿En qué se apoyan los contenedores dentro del núcleo, y cuál aísla y cuál limita?
11. Escribe la orden que descarga una imagen, la que crea y arranca un contenedor y la que lista todos incluidos los parados.
12. Diferencia docker stop de docker kill, y docker rm de docker rmi.
13. ¿Qué diferencia hay entre una imagen y un contenedor, y qué pasa con lo que se escribe dentro?
14. Diferencia CMD de ENTRYPOINT, y di qué hace realmente EXPOSE.
15. ¿Qué es Kubernetes y qué NO hace?
16. Nombra los cuatro objetos básicos y di cuál es la unidad mínima desplegable.
17. ¿Qué componente del plano de control decide en qué nodo va un Pod? ¿Y dónde vive el estado del conjunto?
18. ¿En qué campo del manifiesto se identifica unívocamente el objeto, y qué contiene spec?
19. Cita cuatro beneficios de los microservicios y di cuál de estos NO lo es: escalado flexible, entrega continua, diseño único sin elegir tecnología, resistencia a errores.
20. ¿Qué especificación alineada con Jakarta EE Core Profile se usa para microservicios, y qué resuelven tres de sus componentes?
21. ¿Qué diferencia hay entre una sonda de vida y una de disponibilidad, y qué ocurre cuando falla cada una?
22. ¿Qué tipo de Service da acceso solo dentro del conjunto, y qué objeto enruta HTTP por nombre de máquina y por ruta?
23. Cita cuatro señales de que una organización NO debería ir a microservicios, y di qué es un monolito distribuido.

Autonota. Veinte o más de veintitrés, el tema está. Entre catorce y dieciséis, repasa las tablas del apartado 16: son la mitad de lo que cae. Por debajo de catorce, vuelve a los puertos y a las órdenes de Docker, que son lo más preguntado del bloque entero.