Introducción
Meadow Supply tiene un pequeño catálogo y una función de cálculo de presupuestos de cesta que funciona. Su página pública consulta la disponibilidad a la Shop API. API significa interfaz de programación de aplicaciones: aquí es la interfaz de solicitudes de la aplicación entre la página del cliente y el servicio interno de existencias. Esa API lee las existencias para la página. Actualmente, el proceso del cliente y un visitante independiente también pueden leer directamente las existencias, incluidos detalles de estanterías que el catálogo público no necesita.
Mantén en funcionamiento el recorrido normal del cliente mientras restringes las conexiones a existencias al rol de API aprobado en el espacio de nombres aprobado. Tu resultado reutilizable será una NetworkPolicy guardada y el límite de acceso correspondiente en servicio, respaldado por solicitudes reales en lugar de un diagrama en verde.
Debes conocer ya las rutas básicas del terminal, el formato YAML sencillo, los espacios de nombres, Pods, Deployments, Services y etiquetas. Este laboratorio explica los campos de la política, el comando de diagnóstico proporcionado y los resultados de las solicitudes antes de utilizarlos. Están preparados un clúster real de Kubernetes de un solo nodo con Calico, la aplicación y datos sintéticos. No se requiere instalar el clúster, construir imágenes ni programar la aplicación. El tiempo es una estimación del autor que incluye la lectura y los errores habituales. Estos presupuestos de cesta son de práctica: no se realiza ningún pedido, reserva ni pago.
Mantén las existencias en la ruta aprobada
En este paso, permitirás que la Shop API acceda a existencias e impedirás que los procesos de cliente y visitante la eludan.
Empieza en la pestaña Shop. Meadow Supply debe mostrar Good things for everyday y tres productos. Abre Glass water bottle, observa su precio de $18.00 y Available · 6 in stock, y elige Try a basket quote con Quantity en 1. El resultado debe decir Ready for collection, mostrar $18.00 e indicar explícitamente que no se ha reservado, pedido ni pagado nada. Usa Back to product y después Back to collection.
La ruta real de la solicitud es:
Customer page → Shop API → Stock service
La página del cliente se ejecuta en su propio Pod. Abrir el sitio no convierte tu navegador en un Pod del clúster; las solicitudes a existencias proceden de los procesos de aplicación preparados. La API lee las existencias mediante una nueva conexión de red y las combina con los precios aprobados del catálogo. No tiene una alternativa estática para las existencias. Una pestaña Reference independiente muestra las notas de recogida de Meadow Dispatch. Ábrela, lee P-104 y P-108 y cambia a Workspace. Este servicio independiente debe seguir funcionando.
El terminal comienza en /home/labex/project/stock-policy. pwd muestra el directorio actual; ls enumera sus entradas. Usa el comando cd absoluto si necesitas volver aquí:
pwd
ls
cd /home/labex/project/stock-policy
Espera ver scope.json, starter y tools. cat muestra el archivo de alcance preparado. Usa JSON (JavaScript Object Notation), un formato de texto de valores con nombre y listas. Enumera nombres de recursos y destinos de solicitudes reales, no un estado de topología inventado:
cat scope.json
--context=labex-v135 selecciona el clúster real preparado. --show-labels muestra las etiquetas de los objetos. Un espacio de nombres agrupa objetos, pero no bloquea por sí solo sus conexiones de red. Lee las identidades de los espacios de nombres:
kubectl --context=labex-v135 get namespaces meadow-shop meadow-stock meadow-visitors --show-labels
Cada uno tiene una etiqueta incorporada kubernetes.io/metadata.name igual a su nombre. -n selecciona un espacio de nombres. Lee los Pods y sus etiquetas:
kubectl --context=labex-v135 -n meadow-shop get pods --show-labels
kubectl --context=labex-v135 -n meadow-stock get pods --show-labels
kubectl --context=labex-v135 -n meadow-visitors get pods --show-labels
El proceso del cliente tiene role=customer, la API tiene role=shop-api y existencias tiene role=inventory. El servicio independiente de expedición tiene role=dispatch. El visitante está en meadow-visitors, pero tiene deliberadamente la misma etiqueta role=shop-api que la API real. Por tanto, una etiqueta de rol por sí sola no identifica un espacio de nombres aprobado.
Lee los Services. Un Service selecciona los Pods preparados y proporciona una dirección estable. Un puerto identifica el punto de escucha de una aplicación. TCP (Transmission Control Protocol) proporciona la conexión utilizada por estas solicitudes web; el proceso de existencias escucha en el puerto TCP 8080:
kubectl --context=labex-v135 -n meadow-stock get services
El ./tools/network-test proporcionado ejecuta una solicitud real desde una identidad de aplicación existente mediante kubectl exec. El ./ inicial significa que la herramienta está en el directorio actual. Su primer argumento elige customer, api, visitor, stock o reference; el siguiente elige http, dns o dns-tcp; el último es el destino. Nunca cambia las políticas ni repara la aplicación. Las solicitudes http usan HTTP (Hypertext Transfer Protocol), el protocolo de solicitud y respuesta de estos puntos de acceso web y API. El nombre completo stock.meadow-stock.svc.cluster.local identifica el Service de existencias en su espacio de nombres mediante el DNS del clúster (Domain Name System), que resuelve nombres de Services a direcciones.
Primero establece la conexión y el contenido actuales. Se espera que ambas solicitudes tengan éxito antes del aislamiento:
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Espera ver HTTP_REPLY 200 seguido de los mismos datos de existencias: bottle tiene 6 unidades en la estantería M-03, notebook tiene 4 en M-08 y bag tiene 0 en M-12. El cliente debe obtener la disponibilidad pública mediante la API, no realizar esta lectura interna directa. Esta comprobación inicial demuestra que el destino está activo antes de restringirlo.
Una NetworkPolicy selecciona Pods y permite conexiones específicas para una dirección de tráfico. Ingress significa conexiones que llegan a los Pods seleccionados. Una vez que una política de entrada selecciona existencias, solo permanecen disponibles sus rutas de entrada permitidas, salvo las excepciones documentadas de Kubernetes para tráfico del nodo y del propio Pod. Esto es control de red de Pods, no autenticación de usuarios ni autorización HTTP.
Crea tu directorio de versión. mkdir -p lo crea si es necesario y conserva un directorio existente. El siguiente comando cat escribe la política completa en tu propio archivo de versión: > redirige la salida a ese archivo, y el marcador YAML entre comillas mantiene el texto literal hasta el marcador final en una línea propia. Repetirlo sustituye solo este archivo de política editable.
mkdir -p release
cat > release/stock-ingress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: stock-ingress
namespace: meadow-stock
spec:
podSelector:
matchLabels:
role: inventory
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: meadow-shop
podSelector:
matchLabels:
role: shop-api
ports:
- protocol: TCP
port: 8080
YAML
Lee el archivo guardado antes de aplicarlo:
cat release/stock-ingress.yaml
El podSelector exterior selecciona solo existencias y deja expedición fuera de esta política. Dentro de la única entrada from, namespaceSelector y podSelector deben coincidir ambos: el origen debe estar en meadow-shop y tener role=shop-api. Los dos selectores están alineados bajo el mismo elemento de lista. Añadir otro guion antes del podSelector interior crearía una segunda alternativa, con significado OR, y permitiría otros Pods del espacio de nombres aprobado. El puerto es el puerto TCP de escucha del Pod de existencias. Esta regla no restringe la salida de la API.
apply -f lee tu manifiesto guardado y crea o actualiza la política con ese nombre. No reinicia la aplicación:
kubectl --context=labex-v135 apply -f release/stock-ingress.yaml
describe muestra cómo Kubernetes interpretó la regla:
kubectl --context=labex-v135 -n meadow-stock describe networkpolicy stock-ingress
Lee el rol de existencias seleccionado, el espacio de nombres y rol de API de origen y el puerto TCP. La aplicación efectiva de la política puede tardar unos segundos en converger. Primero confirma que la solicitud original permitida sigue devolviendo los datos completos:
./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Ahora prueba los dos motivos diferentes por los que se debe denegar un origen:
./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test visitor http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
Para estos dos últimos comandos, se esperan NETWORK_TIMEOUT y una salida del comando con código distinto de cero. Customer está en el espacio de nombres aprobado, pero tiene el rol incorrecto; Visitor tiene el rol coincidente, pero está en el espacio de nombres incorrecto. Una conexión rechazada, un error DNS o un destino detenido no demuestran aislamiento. La solicitud correcta de la API a ese mismo destino es el control positivo. Si una solicitud repetida inmediatamente después de aplicar la política sigue teniendo éxito, espera unos segundos y repítela; no declares el aislamiento hasta que las rutas realmente denegadas agoten el tiempo de espera.
Si escribes mal una ruta, usa los pwd, ls y cd absoluto anteriores y repite la operación fallida. Si no se puede analizar el YAML, lee tu archivo de versión y compara la sangría y la posición de los guiones con el ejemplo completo, vuelve a escribir ese archivo editable y aplícalo de nuevo. Si la API también está bloqueada, inspecciona describe y las etiquetas y el puerto ya mostrados, corrige tu política guardada y vuelve a aplicarla. Conserva los espacios de nombres, las etiquetas, las cargas de trabajo, los Pods, los Services, la aplicación, los archivos fuente y la herramienta de diagnóstico originales. No detengas existencias, no cambies etiquetas, no uses reglas de IP de Pod o CIDR, no cambies la red del host ni restablezcas la VM para fabricar una denegación.
Comprueba todo el recorrido del cliente
En este paso, verificarás la experiencia completa del cliente después del aislamiento y mantendrás utilizable el servicio independiente de expedición.
Empieza en Workspace, en /home/labex/project/stock-policy. Una solicitud directa a existencias está bloqueada deliberadamente para Customer, pero Customer debe seguir accediendo a la Shop API. Solicita su catálogo por esa ruta original:
./tools/network-test customer http http://api.meadow-shop.svc.cluster.local:8080/catalogue.json
Espera ver HTTP_REPLY 200 y los tres productos aprobados con sus precios y unidades originales: Glass water bottle 1800 céntimos / 6 unidades, Everyday notebook 1400 / 4, Canvas market bag 2400 / 0. La API también informa de qué Pod original de existencias respondió; la página pública no expone ese detalle de infraestructura. La ruta correcta mediante la API y la ruta directa fallida son compatibles: la API realiza su propia conexión permitida a existencias.
Cambia a Shop y recarga. Abre Glass water bottle, establece Quantity en 2 y selecciona Try a basket quote. Espera ver Ready for collection, Quantity 2, Total $36.00 y Units available 6. Lee el aviso de práctica: no se reservan existencias. Usa Back to product y Back to collection.
Abre Canvas market bag, que está marcado como Back soon, y prueba un presupuesto con Quantity 1. Espera ver Not enough stock, Total $24.00 y Units available 0. Es una respuesta de negocio válida, no un fallo de red; no alteres el inventario para que todos los presupuestos tengan éxito. Usa Back to product y después Back to collection. Abre Our approach, lee la descripción de los presupuestos de práctica y usa Back to collection.
El catálogo terminado tiene los tres productos originales y disponibilidad en vivo; compara su encabezado, precios y disponibilidad con este ejemplo en ejecución:
Cambia a Reference y recarga. P-104 · Ready y P-108 · Packed deben seguir visibles. Selecciona Download notes y abre la descarga real notes.json: contiene los dos registros de expedición sin cambios, no datos de existencias. La descarga del navegador y el espacio de trabajo del terminal son ubicaciones diferentes; esta tarea no pide copiar ese archivo al espacio de trabajo.
Vuelve a Workspace y lee ese mismo Service independiente desde Customer:
./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json
Espera ver HTTP_REPLY 200 y ambas notas originales. La política seleccionó Pods de inventario, no todo el espacio de nombres de existencias. Conserva el proceso, los datos y el Service original de expedición; desactivarlo ocultaría una regla excesivamente amplia.
Tu entrega es release/stock-ingress.yaml y el límite de acceso correspondiente en servicio. El catálogo completo y ambos resultados de presupuesto deben continuar a través de la aplicación original, mientras siguen denegadas las dos rutas que eluden la API para leer directamente las existencias. Conserva todos los archivos fuente preparados, objetos de aplicación y Pods originales. Si una página muestra Live availability unavailable, vuelve a las comprobaciones enseñadas de etiquetas, políticas y solicitudes, corrige solo tu política de versión y vuelve a aplicarla; una página estática de sustitución no es una reparación. Las pruebas de aquí son solicitudes TCP reales finitas en un clúster preparado, no una garantía de seguridad de producción ni de disponibilidad ininterrumpida.
Resumen
Conservaste el recorrido real cliente → API → existencias e impediste las lecturas directas de existencias tanto de un cliente con un rol incorrecto como de un visitante con el rol coincidente en otro espacio de nombres. Tu política de entrada guardada expresa la relación entre espacio de nombres y rol, y el catálogo en servicio, los presupuestos de práctica y el servicio independiente de expedición siguen funcionando.
NetworkPolicy controla rutas de red de los Pods, no la autenticación de clientes. Un tiempo de espera agotado solo es una evidencia útil si el destino y la conexión aprobada siguen funcionando. El siguiente laboratorio independiente considera la otra dirección: la salida de la API, DNS y los permisos aportados por otras políticas.
