Mostrando entradas con la etiqueta Kubernetes. Mostrar todas las entradas
Mostrando entradas con la etiqueta Kubernetes. Mostrar todas las entradas

lunes, 16 de febrero de 2026

VMware Cloud Foundation 9.0 - vSphere Kubernetes Service (VKS) 3V0-24.25: mi evaluacion del exámen

Aprovechando que acabo de pasar el examen 3V0-24.25 (Advanced VMware Cloud Foundation 9.0 vSphere Kubernetes Service), aprovecharé para plasmar en este post mis impresiones tanto del examen como de la necesidad del mismo ya que, tras el estudio, me reafirmo en una idea: la nube no es un lugar, es un modelo operativo. Y para muchas empresas, ese modelo debe empezar "en casa" para mantener la soberanía y el control del dato.

A diferencia de un Kubernetes estándar, VKS en VMware Cloud Foundation (VCF) integra la agilidad del desarrollo moderno con el rigor de la infraestructura empresarial. Durante el examen, la dificultad radica en entender cómo interactúan los componentes internos para ofrecer este servicio:


Arquitectura de Supervisor: Es el corazón de la solución. He aprendido que la resiliencia es crítica: un Supervisor de zona única está ligado a un clúster de vSphere específico , mientras que un Multi-Zone Supervisor requiere al menos tres zonas para distribuir las VMs del plano de control y garantizar la alta disponibilidad. Esta configuración debe definirse en el despliegue inicial, ya que no existe una migración simple "in-place" posterior. Machacan mucho con esto.

Componentes Internos del Clúster VKS: Para que Kubernetes funcione sobre vSphere, el clúster ejecuta tres piezas fundamentales:
  • Cloud Provider Implementation: Para gestionar servicios de balanceo de carga.
  • Container Storage Interface (CSI): Un plugin paravirtual que se integra con CNS para el almacenamiento persistente.
  • Container Network Interface (CNI): Encargado de la conectividad de los pods.
Gestión de Datos y Ciclo de Vida: La protección no es opcional. El examen profundiza en el uso de Velero Plugin for vSphere, la única herramienta válida para respaldar vSphere Pods. Además, el uso de Cluster API es lo que permite que el ciclo de vida de los clústeres sea automatizado y declarativo, al puro estilo Kubernetes.

No es un examen que me haya parecido especialmente complicado, aunque es más difícil que los VCP. La dificultad reside en la precisión de los procedimientos "Day-2". No basta con saber qué es un Namespace; debes conocer el orden exacto para "zonalizarlo": desde crear el Namespace, asignar zonas y configurar redes, hasta definir cuotas y permisos RBAC. Y lo mismo que este, otros tantos ejemplos, como la ejecución de Velero, o qué permite exactamente proteger esta solucion.

También hay varias cuestiones sobre la capacidad de automatizar la seguridad con cert-manager, convirtiendo los certificados TLS en objetos nativos de Kubernetes que se renuevan solos, eliminando el error humano.

No he tenido la sensacion de que, y a diferencia con el examen de Administrador de VCF, hagan demasiado hincapié en NSX, pero como componente utilizado en entornos multicluster, las preguntas que caen hacen referencia a esta situacion sobre todo.

Conclusión: aprobar el VMware Advanced Certified Professional (VKS) valida que puedes construir una infraestructura donde los desarrolladores consumen recursos de forma autoservicio, pero donde el administrador de IT mantiene el gobierno total a través de políticas de almacenamiento (CNS) y límites de recursos. Porque, no lo olvidemos, el examen es a nivel administrador de plataforma, no saldrá absolutamente nada relacionado con la creación de un pod, mas allá de entender qué es un pod o los requerimientos que estos puedan tener a nivel de provisión de recursos para su correcto funcionamiento.

Para finalizar, os dejo el ENLACE al blueprint. Aunque recomiendo pasarse por los Techdocs de Broadcom, concretamente AQUI, y utilizar esto como referencia de estudio.

miércoles, 7 de enero de 2026

Guía NKP: Simplificando Kubernetes en la Nube Híbrida

Si estás metido en el mundo de los contenedores, ya sabes que gestionar Kubernetes puede pasar de ser un sueño a una pesadilla en cuestión de segundos. NKP es básicamente el "cerebro" centralizado que Nutanix diseñó para que puedas desplegar y escalar tus aplicaciones en cualquier lugar sin volverte loco.

Nutanix no te obliga a comprar todo de golpe; lo divide en tres niveles según lo que necesites hoy:


1. NKP Starter: Para empezar sin líos

Si ya usas Nutanix en tu centro de datos (AHV), esta es tu puerta de entrada.
  • Es "gratis": Si ya tienes licencias NCI Pro o Ultimate, ya lo tienes incluido.
  • El truco: Solo funciona en Nutanix y estás limitado a usar Rocky Linux.
  • Ideal para: Equipos que están dando sus primeros pasos y no quieren complicarse con configuraciones externas. Es como el sistema operativo básico que viene en tu móvil.

2. NKP Pro: Para los que ya van "en serio"

Este nivel es para empresas que tienen aplicaciones críticas y necesitan moverse entre diferentes nubes o servidores físicos.
  • Libertad total: Puedes instalarlo en AWS, Azure, Google Cloud o incluso en servidores físicos (bare metal).
  • Tus reglas: Puedes usar el Linux que prefieras (Ubuntu, RHEL, etc.).
  • Control total: Viene con un kit de herramientas para ver qué pasa en tus clústeres (Prometheus y Grafana) y automatiza el despliegue con FluxCD. Es como ese mismo móvil, pero ya con todas las apps profesionales instaladas.

3. NKP Ultimate: El "Modo Dios" de los clústeres

Si tu empresa es enorme y tienes clústeres por todos lados (nube, local, diferentes países), el nivel Ultimate es para ti.
  • Panel único: Gestionas todo desde un solo sitio, incluso si usas los servicios de Amazon (EKS) o Azure (AKS).
  • IA al rescate: Incluye un asistente inteligente (AI Navigator) que te ayuda a encontrar fallos antes de que algo se rompa.
  • Cuida tu bolsillo: Trae Kubecost para que sepas exactamente cuántos dólares te está costando cada contenedor en la nube. Es la centralita que controla todos los móviles de la empresa a la vez.

CaracterísticaNKP StarterNKP ProNKP Ultimate
Dónde se ejecutaSolo Nutanix AHVNutanix, vSphere, Cloud, Bare MetalNutanix, vSphere, Cloud, Bare Metal
Sistemas OperativosSolo Rocky LinuxMultidistribución (BYOOS)Multidistribución (BYOOS)
ObservabilidadBásicaStack CompletoStack Completo Centralizado
Multiclúster / FlotasNoNoSí (incluye EKS/AKS)
Gestión de CostesNoNoIncluida (Kubecost)
IA y InsightsNoNoAI Navigator e Insights

Tres dudas que te van a surgir (y sus respuestas)

¿Cómo se paga? Es flexible. Si usas máquinas virtuales, pagas por vCPU. Si vas directo al hardware, por núcleos físicos. Lo mejor es que si hoy estás en AWS y mañana te vas a Azure, te llevas tu licencia contigo sin pagar extra.

¿Y el almacenamiento? Ya viene incluido. NKP usa un conector nativo (CSI) para que tus contenedores se enganchen al almacenamiento de Nutanix sin configurar nada raro.

¿Qué es un clúster "Attached"? Es una función de la versión Ultimate que te permite "conectar" tus clústeres de Amazon o Microsoft a la consola de Nutanix para aplicarles las mismas reglas de seguridad que a tus servidores locales.

Mi recomendación:
  • Si solo quieres probar Kubernetes en tus servidores actuales, usa Starter.
  • Si vas a producción real en la nube, salta a Pro.
  • Si tienes un caos de nubes y el presupuesto se te está escapando de las manos, Ultimate es tu salvación.
Ah, ya de paso, dejo LINK a la biblia de Kubernetes, 1300 páginas de lectura ligera  ;) pero muy útil para ver los comandos de montaje de la infra.

martes, 23 de diciembre de 2025

Nutanix Konnector: Poniendo orden a Kubernetes en Prism Central

Si eres de los que ha estado un poco mareado con la transición de Karbon (NKE) hacia NKP (Nutanix Kubernetes Platform), hoy vamos a ver una pieza del puzzle que por fin hace que todo tenga sentido: Nutanix Konnector (NK).
Vamos a desgranar qué es este servicio y por qué es fundamental si quieres tener tus clústeres de Kubernetes bajo control desde un único sitio.


¿Qué es Nutanix Konnector?

A veces las herramientas más útiles no son las que crean cosas nuevas, sino las que organizan lo que ya tenemos. Nutanix Konnector no es una plataforma para desplegar clusters; es un puente de observabilidad.
Su función es simple: permitir que Prism Central "vea" y monitorice clusters de Kubernetes, ya sean nativos de Nutanix o de terceros (como OpenShift o EKS Anywhere), tratándolos como ciudadanos de primera clase dentro de nuestra infraestructura.

La arquitectura: Cómo funciona el "invento"

Nutanix ha optado por un modelo muy limpio de Servicio + Agente:
El Servicio (en Prism Central): A partir de Prism Central 7.5, el servicio de Konnector ya viene integrado y habilitado por defecto. Es el encargado de recibir toda la información.
El Agente (en el Cluster K8s): Aquí es donde entramos nosotros. Instalamos un pequeño agente mediante Helm en el cluster que queremos monitorizar. Este agente envía métricas, inventario y estado hacia Prism Central.
Importante: Prism Central no se conecta directamente a la API de Kubernetes. Es el agente el que envía los datos, lo que facilita mucho la gestión a nivel de seguridad y firewalls.

El "truco" del bundle: No te asustes por el nombre
Si vas al portal de descargas para configurar esto, verás que te piden subir un archivo llamado lcm_karbon_3.0.tgz.

Sé lo que estás pensando: "¿Pero Karbon no se había muerto?". No exactamente. Nutanix utiliza este bundle para registrar metadatos de ciclo de vida que Konnector todavía necesita para funcionar internamente. Al subirlo, no estás resucitando a Karbon, simplemente estás habilitando las dependencias para que Konnector pueda "hablar" con Prism Central.

Distribuciones soportadas (Versión 1.0)
Una de las cosas que más me gustan de este enfoque es que es agnóstico. En esta primera fase, podemos conectar:
  • NKP (Nutanix Kubernetes Platform): Versiones 2.16.1 en adelante.
  • Red Hat OpenShift: Versión 4.16.
  • Amazon EKS Anywhere: Versión 1.33.1.

En resumen: Nutanix Konnector es la respuesta a una necesidad clara: la visibilidad. Ya no importa si tus clusters están en tu CPD o en la nube, ahora puedes tener un inventario unificado en tu consola de siempre. Es un paso adelante para dejar de gestionar "islas" de Kubernetes y empezar a gestionarlos como parte real de nuestra nube híbrida.
¿Habéis probado ya a conectar vuestros clusters externos?