Pregunta y contexto
Un controlador solo necesita nombres de objetos, etiquetas, espacios de nombres y resourceVersion; sin embargo, lee campos grandes de spec y status de Pods. Utiliza la negociación de solo metadatos de Kubernetes para solicitudes de listado y luego explica las APIs agregadas no compatibles, las respuestas 406 y el watch posterior.
Qué está evaluando el entrevistador
- Si construyes los parámetros de
Acceptcorrectamente y distingues las representaciones de un solo objeto de las de una lista. - Si entiendes las respuestas parciales como una representación y no como un parche arbitrario de filtrado de campos.
- Si diseñas el manejo de 406, desajustes de versiones (version-skew) y el fallback a objetos completos sin hacer que el inicio falle o reintente indefinidamente.
- Si
resourceVersionen list/watch y la consistencia de la caché se mantienen correctos.
Preguntas aclaratorias para hacer primero
Límite de recursos y del servidor
¿El objetivo es una API in-tree, un CRD o una API agregada? ¿Todos los apiserver y proxies admiten respuestas de solo metadatos?
Patrón de uso
¿El cliente solo construye índices de existencia y etiquetas, o necesitará más adelante spec? ¿Debe iniciar un watch inmediatamente después del listado?
Política de fallas
¿Puede el cliente leer objetos completos cuando las respuestas parciales no estén disponibles, o debe fallar explícitamente para proteger los presupuestos de ancho de banda y memoria?
Un marco de respuesta de 30 segundos
Preferiría application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1 para un listado y aceptaría solo metadatos más el resourceVersion de la lista. Agregaría application/json de menor calidad como fallback y luego inspeccionaría el tipo de respuesta (kind) para saber qué se devolvió realmente. Sin fallback, trataría el 406 como una funcionalidad no admitida en lugar de una tormenta de reintentos. Iniciaría el watch desde la versión del recurso devuelta y registraría la representación en la caché.
Pasos detallados de la respuesta
1. Distinguir las representaciones
Usa as=PartialObjectMetadata para un objeto y as=PartialObjectMetadataList para una colección. La respuesta omite spec y status y conserva los metadatos; eso reduce el costo de serialización, red y decodificación, pero no puede atender a clientes que necesiten campos de negocio.
2. Construir una solicitud con fallback
GET /api/v1/pods
Accept: application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1, application/json;q=0.9Si la representación preferida no está disponible, el servidor puede elegir JSON normal. El cliente debe inspeccionar kind, apiVersion y Content-Type; el HTTP 200 por sí solo no demuestra que se haya devuelto un objeto parcial.
3. Manejar el modo estricto y el 406
Cuando la solicitud anuncia únicamente una representación parcial que la API de destino no admite, Kubernetes devuelve 406. Registra esto como un resultado de capacidad y cambia a objetos completos, omite el recurso o muestra un error de configuración según la política. No reintentes indefinidamente el mismo encabezado Accept ni clasifiques el 406 como una falla de red transitoria.
4. Manejar APIs agregadas y CRDs
Las APIs integradas generalmente admiten respuestas de solo metadatos, pero una API detrás de agregación podría no hacerlo. Los CRD y las implementaciones de terceros también pueden exponer solo objetos completos. Sondea las capacidades por recurso y servidor, almacena en caché el resultado con expiración y nunca generalices el éxito de un recurso a todos los recursos.
5. Preservar la consistencia de list/watch
El resourceVersion de la lista sigue siendo el punto de partida para el watch. Guárdalo, maneja expiraciones, desconexiones y nuevos listados (relist), y recuerda que el modo de solo metadatos cambia la representación en lugar de la semántica de la versión del recurso. Un fallback a objeto completo debe usar la misma versión para poblar la caché, evitando datos mixtos desactualizados.
6. Diseñar el comportamiento de la caché y de las actualizaciones
Las entradas de la caché deben registrar la representación y la disponibilidad de campos. Una ruta que necesite spec no debe asumir que existe en una entrada de solo metadatos; emite un GET completo controlado por nombre. Vuelve a sondear la capacidad de Accept después de actualizar un servidor o proxy para que no permanezca indefinidamente una ruta innecesaria de objetos completos.
7. Medir el costo y la seguridad
Compara los bytes de la solicitud, la CPU de decodificación, el pico de heap, la latencia del listado, la tasa de reconexión del watch y la proporción de GETs completos. Las etiquetas, anotaciones y referencias de propietarios aún pueden contener datos confidenciales; la autorización no desaparece porque solo se devuelvan metadatos. Evita volcar cada anotación en los registros y métricas.
Una respuesta de ejemplo de alta calidad
Preferiría PartialObjectMetadataList e incluiría JSON normal de menor calidad como fallback. El cliente valida el kind devuelto y realiza un cambio de capacidad ante un 406. Inicia un watch a partir del resourceVersion de la lista y registra la disponibilidad de campos en la caché. Las APIs agregadas, los CRDs y las rutas que necesitan spec obtienen sondeos y lecturas separados, mientras que las métricas de bytes, CPU, memoria y reconexión demuestran el beneficio.
Errores comunes
- Usar el parámetro
PartialObjectMetadatade objeto único para una lista. - Tratar el modo de solo metadatos como un filtrado arbitrario de campos del lado del servidor e ignorar el kind de la respuesta.
- Tratar el 406 como un 5xx reintentable cuando no se ofreció ningún fallback.
- Asumir que la capacidad in-tree se aplica a APIs agregadas o a todos los CRDs.
- Omitir el
resourceVersionde la lista y reiniciar el watch desde un punto incorrecto. - Medir el tamaño de la respuesta sin considerar la CPU de decodificación, el pico de heap o el costo de reconexión.
Preguntas de seguimiento y respuestas
¿Por qué usar PartialObjectMetadataList para una lista?
Una solicitud de colección devuelve una representación de lista, y PartialObjectMetadataList indica explícitamente que cada elemento contiene únicamente metadatos. La forma de objeto único es para un solo GET; el cliente no debe mezclarlas ni asumir.
¿Qué sucede si el servidor no admite respuestas parciales?
Con JSON normal como fallback de menor calidad, inspecciona el kind de la respuesta y utiliza el objeto completo. En modo estricto, registra el 406 como una capacidad no disponible y omite o falla según la política del recurso. No reintentes indefinidamente.
¿El modo de solo metadatos cambia resourceVersion?
No. Cambia la representación, no la semántica de resourceVersion. La versión de la lista sigue anclando el watch y la consistencia de la caché.
¿Todos los CRDs admiten esta solicitud?
No se debe asumir eso. Las APIs agregadas y los CRDs podrían no implementar representaciones parciales; sondea y almacena en caché la capacidad por recurso.
¿Cuándo se debe leer el objeto completo?
Cuando una decisión requiera spec, status u otro campo de negocio. Utiliza los metadatos para construir un índice y luego activa un GET completo y controlado por nombre o evento.