Gestionar una flota híbrida con Nutanix Kubernetes Platform y Amazon EKS – Parte 1

Por Guillermo Ruiz, Senior Specialist Solutions Architect de Efficient Compute en Amazon Web Services (AWS), y Paul Zerdilas Herrera, EMEA Cloud Native Architect en Nutanix.

Esta publicación es la tercera entrega de la serie «Nutanix y AWS: cargas de trabajo híbridas» y la primera de dos partes sobre Nutanix Kubernetes Platform (NKP) y Amazon Elastic Kubernetes Service (Amazon EKS). En la segunda entrega se explica cómo mover máquinas virtuales entre un entorno local y Nutanix Cloud Clusters (NC2) en AWS.

Si mantiene parte de sus aplicaciones en el centro de datos y despliega nuevos servicios en Amazon EKS, opera Kubernetes en entornos con necesidades diferentes. A medida que crece el número de clústeres, también crece el trabajo de actualizar versiones, renovar certificados y aplicar políticas de seguridad. En esta publicación, le mostramos cómo incorporar un clúster de Amazon EKS existente a Nutanix NKP y distribuir desde NKP una política de plataforma común, para que pueda comprobar que se cumple sin revisar cada clúster por separado.

Que todos los clústeres de una flota híbrida ejecuten Kubernetes no hace que la flota sea operable. La flota es operable cuando usted sabe qué decisiones deben ser comunes, cuáles pertenecen a cada entorno y cómo comprobar que los controladores han aplicado lo que ha declarado.

El recorrido parte de un clúster de Amazon EKS existente y de un clúster Kubernetes sobre Nutanix. Primero, incorpora el clúster de Amazon EKS a NKP. Después, utiliza un workspace para distribuir Gatekeeper y una política que limita los registros de imágenes. La prueba final no consiste en comprobar que existen objetos en el hub: usted intenta una operación permitida y otra que la política debe rechazar.

En la parte 2, el modelo se amplía con identidad de aplicaciones, aprovisionamiento con Cluster API y custom networking.

Información general de la solución

Una aplicación necesita más que un clúster disponible. También necesita certificados, acceso a almacenamiento, métricas, controles de seguridad y un proceso para desplegar cambios. Cuando cada equipo configura esas piezas por su cuenta, mantenerlas alineadas se convierte en otra tarea del equipo de plataforma.

Por ejemplo, puede aplicar a un clúster una política que solo permita imágenes de los registros corporativos. Cuando gestiona veinte clústeres, necesita comprobar que la política se cumple en todos y que cada clúster nuevo la recibe desde el primer día.

Amazon EKS sigue siendo responsable del plano de control gestionado y de las integraciones propias del servicio. Su equipo sigue siendo responsable de seleccionar, configurar y actualizar los complementos que habilite, según el modelo de gestión que elija.

El equipo de plataforma conserva la responsabilidad de definir la configuración, autorizar cambios y comprobar que las aplicaciones funcionan. El catálogo de NKP, las versiones compatibles y el alcance del soporte forman parte de esa decisión.

Esta distinción evita dos errores frecuentes:

• Pensar que una entrada de acceso (access entry) de Amazon EKS registra automáticamente el clúster en NKP. Son dos accesos distintos y se configuran por separado.
• Suponer que una declaración de Cluster API (CAPI) crea por sí sola una red, una identidad o una política de AWS Identity and Access Management (IAM). Hay piezas que debe configurar y comprobar aparte.

Tres piezas con responsabilidades diferentes

NC2 ejecuta infraestructura Nutanix sobre instancias bare metal de Amazon EC2. NKP proporciona la plataforma Kubernetes y sus capacidades de gestión. Amazon EKS proporciona Kubernetes con un plano de control gestionado por AWS. Incorporar un clúster de Amazon EKS a NKP no convierte sus nodos en máquinas virtuales sobre NC2.

El Management Cluster de NKP, que en esta publicación se denomina hub, coordina la gestión. Los clústeres de aplicaciones ejecutan las cargas de trabajo, y los servicios de AWS aportan capacidades como identidad, red, almacenamiento y observabilidad. Esta separación le permite aplicar un proceso común sin exigir que toda la infraestructura sea idéntica.

Dos formas de llevar Amazon EKS a NKP

NKP puede trabajar con clústeres de Amazon EKS que ya existen (attached) o con clústeres que aprovisiona él mismo (managed). La siguiente tabla resume quién se ocupa de cada capa en cada modelo.

Si ya tiene un clúster de Amazon EKS en producción y lo mantiene con Terraform, AWS CloudFormation o eksctl, el modelo attached le permite conservar ese proceso. NKP añade las funciones de plataforma que usted habilite. Empiece con un entorno de prueba: instalar componentes o activar políticas puede afectar a las aplicaciones aunque no recree el clúster.

Para clústeres nuevos, el modelo managed puede ayudarle a integrar el aprovisionamiento y la operación en un flujo común. Antes de decidir cómo realizar actualizaciones, escalado y eliminación, compruebe qué operaciones admite su combinación de versiones de NKP y de sus proveedores.

Ambos modelos pueden convivir. Por ejemplo, puede incorporar los clústeres de producción existentes y aprovisionar desde NKP los entornos nuevos. Evite que dos herramientas reconcilien los mismos recursos: deje por escrito quién controla la infraestructura y quién administra las aplicaciones de plataforma.

Cómo llega una declaración hasta AWS

En el modelo managed, el equipo declara la configuración deseada y los controladores de CAPI coordinan su creación. Cluster API Provider AWS (CAPA) traduce esa configuración en operaciones sobre las API de AWS. La figura 1 muestra este flujo.

Figura 1. Flujo conceptual de aprovisionamiento desde NKP hasta Amazon EKS.

El diagrama sigue siete pasos:

1. El administrador de plataforma declara los recursos Cluster y MachineDeployment (YAML de CAPI) o utiliza la interfaz de NKP. Puede trabajar con la CLI nkp, la consola, kubectl o GitOps.
2. Los controladores de CAPI que incluye Konvoy reconcilian el estado deseado y entregan a CAPA los recursos de AWS.
3. CAPA se autentica con la identidad configurada para el controlador. Con AWSClusterRoleIdentity, esa identidad asume un rol de IAM mediante AWS Security Token Service (AWS STS). Con AWSClusterStaticIdentity, CAPA utiliza credenciales estáticas almacenadas en un Secret.
4. CAPA llama a la API de Amazon EKS para crear, escalar o actualizar el clúster.
5. CAPA define los grupos de nodos mediante las API de Amazon EC2 y Amazon EC2 Auto Scaling (plantillas de lanzamiento y grupos de Auto Scaling).
6. AWS aprovisiona y opera el plano de control en una cuenta gestionada por Amazon EKS. Los nodos se lanzan en subredes privadas de la nube privada virtual (VPC) del cliente en Amazon Virtual Private Cloud (Amazon VPC) y se unen al clúster.
7. El kubeconfig y el estado reconciliado vuelven al Management Cluster.

La figura 1 muestra como ejemplo una identidad estática. En la parte 2 se configura la asunción de un rol de IAM, que requiere configurar también su identidad de origen.

Preste especial atención a los permisos. El controlador que crea infraestructura necesita más privilegios que una aplicación que solo lee objetos de Amazon Simple Storage Service (Amazon S3). Utilice roles y credenciales temporales cuando la integración lo permita, limite las acciones y los recursos autorizados y proteja el acceso al hub. La configuración de la identidad de origen también forma parte de ese diseño.

Por dónde pasa el tráfico de las aplicaciones

Una vez desplegada la aplicación, los usuarios acceden a ella a través de los componentes de red del clúster, por ejemplo un Application Load Balancer (ALB) o un Network Load Balancer (NLB). El hub participa en la gestión, pero no necesita estar en ese recorrido. La figura 2 muestra esta separación.

Figura 2. Separación conceptual entre el tráfico de las aplicaciones en Amazon EKS y el flujo de gestión y despliegue desde NKP.

El diagrama separa tres recorridos:

Gestión (1-2). Kommander y Flux CD leen los manifiestos de aplicaciones y de plataforma desde el repositorio Git. El Management Cluster los aplica al API server del clúster de Amazon EKS.

Tráfico de usuarios (3-4). Los usuarios acceden por HTTPS a través de un ALB o un NLB que crea AWS Load Balancer Controller a partir del recurso Ingress o Service. El balanceador reparte las peticiones entre los pods de los nodos en ambas zonas de disponibilidad.

Comunicación interna de Amazon EKS (5-6). Cada kubelet alcanza el API server a través de las interfaces de red elásticas (ENI) entre cuentas situadas en su VPC. El plano de control utiliza esas mismas ENI para enviar a los nodos las órdenes de planificación y los comandos de kubelet, como exec o logs.

Esta separación ayuda a limitar el impacto de una interrupción del hub. Los clústeres conservan sus planos de control y las aplicaciones no dependen del hub para atender cada petición. Sin embargo, los cambios centralizados y las funciones que dependen del hub sí pueden quedar interrumpidos. Puede comprobarlo con una prueba de interrupción.

Requisitos previos

Para seguir esta publicación, necesita lo siguiente:

• Una cuenta de AWS con permisos para el entorno de prueba y AWS Command Line Interface (AWS CLI) versión 2 configurada.
• Un clúster de Amazon EKS existente. En esta publicación se utiliza Kubernetes en la región eu-south-2.
• Un Management Cluster de NKP con la edición y la licencia adecuadas.
• Un workspace creado en NKP.
• Las herramientas kubectl y nkp instaladas, con acceso a los contextos del hub y del clúster de Amazon EKS.
• Un rol de IAM llamado eks-demo-observer que pueda asumir, para la prueba de acceso de solo lectura.
• Conectividad de red entre el hub y el API server del clúster de Amazon EKS. La sección «Comprobar la red antes de los permisos» explica cómo verificarla.

Inventariar versiones, propietarios y contextos

Empiece por comprobar qué tiene desplegado: la versión de NKP, los proveedores de Cluster API, Kubernetes, sus complementos y las aplicaciones del catálogo que va a utilizar. Estos datos le ayudan a elegir las configuraciones de los pasos siguientes.

Que una capacidad esté disponible en el upstream de CAPA no implica que la versión incluida en NKP la admita. Tome como referencia la definición de recurso personalizado (CRD) instalada y la matriz de soporte del producto, no el ejemplo más reciente que encuentre en Internet.

El recorrido utiliza tres contextos de Kubernetes, para que cada comando indique sobre qué entorno actúa:

• HUB_CTX: el clúster de gestión de NKP.
• EKS_CTX: el clúster de Amazon EKS donde se ejecutan las aplicaciones.
• El clúster de Nutanix, cuando corresponda.

El hub gestiona y los clústeres ejecutan. Esa separación aparece en cada comando. Guarde el namespace del workspace de NKP en la variable WS_NAMESPACE.

export AWS_REGION=eu-south-2
export EKS_NAME=legacy-eks-01
export HUB_CTX=nkp-management
export HUB_KUBECONFIG=/ruta/al/kubeconfig-del-hub
export EKS_CTX=legacy-eks-01
export WS_NAMESPACE=prod-workspace

aws sts get-caller-identity
aws eks describe-cluster --name "$EKS_NAME" \
  --query 'cluster.{version:version,status:status,access:accessConfig,vpc:resourcesVpcConfig}'
aws eks list-addons --cluster-name "$EKS_NAME"

nkp version
kubectl --context "$HUB_CTX" version
kubectl --context "$HUB_CTX" get workspaces
kubectl --context "$HUB_CTX" get namespace "$WS_NAMESPACE"
kubectl --context "$HUB_CTX" api-resources | grep -E "cluster|kommander|appdeployment"
kubectl --context "$HUB_CTX" get deployments -A \
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image'

Guarde este inventario en el repositorio, junto al código de configuración. Así puede relacionar cada cambio con las versiones que utilizaba.

No actualice un proveedor de CAPI por separado para conseguir un campo nuevo. Si algún ejemplo requiere una funcionalidad que su versión no incluye, revise qué actualización de NKP la incorpora y conserve los objetos que genere su CLI.

Comprobar la red antes de los permisos

El primer fallo de una incorporación suele aparecer antes de que Kubernetes pueda autenticar al usuario. El hub necesita resolver y alcanzar el API server del clúster de Amazon EKS para gestionar sus recursos. Si CAPA aprovisiona infraestructura, también necesita llegar a las API de AWS.

Distinga dos endpoints que pueden llevar a confusión. El endpoint de AWS PrivateLink para Amazon EKS permite realizar operaciones del servicio, como consultar la configuración de un clúster mediante DescribeCluster. Para trabajar con los recursos de Kubernetes, como hace con kubectl, se utiliza el endpoint del API server de ese clúster. Un endpoint privado para el servicio Amazon EKS no sustituye al endpoint de Kubernetes.

La siguiente tabla resume las conexiones que debe revisar y los síntomas que le ayudan a identificar dónde está el problema.

Consulte primero el endpoint y la configuración de la VPC. La respuesta indica si el acceso al API server es público, privado o ambos, y qué subredes y grupos de seguridad tiene asociados. Después, revise en qué zona de disponibilidad está cada subred, qué rango utiliza y cuántas direcciones quedan libres.

aws eks describe-cluster --name "$EKS_NAME" \
  --query 'cluster.{endpoint:endpoint,vpc:resourcesVpcConfig}'

aws ec2 describe-subnets --subnet-ids subnet-REEMPLAZAR_A subnet-REEMPLAZAR_B \
  --query 'Subnets[].{id:SubnetId,az:AvailabilityZone,cidr:CidrBlock,free:AvailableIpAddressCount}'

# Desde el recorrido de red del hub
getent hosts <endpoint-eks>
curl --silent --show-error --fail --connect-timeout 5 https://<endpoint-eks>/version

Repita la prueba de DNS y TLS desde una ubicación con el mismo recorrido de red que utilizan los componentes de gestión. Que pueda conectarse desde su portátil no confirma que el hub tenga el mismo acceso.

La respuesta del servidor le ayuda a continuar el diagnóstico:

• Un 401 o un 403 con TLS validado indica que ha alcanzado el API server. En ese caso, investigue la autenticación o los permisos.
• Un tiempo de espera agotado apunta primero a DNS, rutas, grupos de seguridad o listas de control de acceso (ACL) de red.
• No desactive TLS para que la prueba parezca correcta. La validación también comprueba que se conecta al servidor esperado.

Conectar el hub con un endpoint privado

Si utiliza un endpoint privado, necesita una ruta desde el hub hasta la VPC del clúster. Puede establecer conexiones directas entre VPC mediante VPC peering, conectar varias redes a través de AWS Transit Gateway o comunicar el centro de datos con AWS mediante AWS Direct Connect o AWS Site-to-Site VPN.

La opción depende de dónde esté el hub y de las redes que necesite conectar. Revise las rutas de ida y vuelta, las reglas de seguridad y la resolución DNS. Compruebe también que los rangos de direcciones de las redes que va a conectar no se solapan.

Planificar el direccionamiento de los pods

Además de conectar los entornos, necesita espacio para que las aplicaciones crezcan. En su configuración habitual de IPv4, Amazon VPC CNI asigna a los pods direcciones IP de la VPC.

Por eso, al dimensionar las subredes, tenga en cuenta las direcciones que utilizan los nodos, los pods y las interfaces de red que crea Amazon EKS. Puede tener capacidad de cómputo disponible y, aun así, no conseguir arrancar pods nuevos porque la subred se ha quedado sin direcciones.

Para ajustar ese diseño tiene tres opciones, y cada una resuelve una necesidad diferente:

• CIDR secundarios: añaden rangos de direcciones a la VPC.
• Custom networking: asigna a los pods subredes diferentes de las de los nodos.
• Delegación de prefijos: asigna bloques de direcciones a las interfaces de los nodos. Permite alojar más pods por nodo, pero sigue consumiendo direcciones de las subredes.

Si necesita custom networking, reserve los CIDR, las subredes por zona de disponibilidad, las rutas y los grupos de seguridad antes de modificar el complemento. Tenga en cuenta que declarar un rango de pods en un manifiesto de Cluster API no crea por sí solo una red separada en Amazon VPC CNI. La parte 2 explica cómo configurarlo.

Separar la identidad del operador de la identidad de gestión

Con la red verificada, el siguiente paso es configurar quién puede acceder al clúster y qué operaciones puede realizar. Empiece por el acceso de lectura de una persona. Este paso comprueba la autenticación y la autorización, pero no proporciona al controlador de NKP los permisos que necesita para incorporar el clúster. Mantener ambas identidades separadas hace que el resultado sea más fácil de interpretar.

Para ello, utilice las entradas de acceso de Amazon EKS (access entries), que asocian una identidad de IAM con permisos dentro de Kubernetes.

Comprobar el modo de autenticación

Antes de crear la entrada, revise el modo de autenticación que obtuvo en el inventario:

• CONFIG_MAP: los accesos se gestionan mediante el ConfigMap aws-auth.
• API_AND_CONFIG_MAP: mantiene ese mecanismo mientras incorpora entradas de acceso, lo que facilita una transición gradual.

Conserve los accesos existentes hasta comprobar que sus equivalentes funcionan con el nuevo modelo. Esta transición tiene restricciones: una vez habilitado el acceso mediante la API, no puede volver al modo exclusivo CONFIG_MAP. Planifique este cambio con antelación y no lo realice durante el attach.

Crear y probar un acceso de solo lectura

Este ejemplo concede al rol eks-demo-observer acceso de lectura al namespace demo. Primero, cree su entrada de acceso y asocie la política AmazonEKSViewPolicy limitada a ese namespace. Después, añada a su kubeconfig un contexto que utilice el rol. Sustituya el identificador de cuenta por el de su entorno.

export OBSERVER_ROLE_ARN=arn:aws:iam::111122223333:role/eks-demo-observer

aws eks create-access-entry --cluster-name "$EKS_NAME" \
  --principal-arn "$OBSERVER_ROLE_ARN" --type STANDARD

aws eks associate-access-policy --cluster-name "$EKS_NAME" \
  --principal-arn "$OBSERVER_ROLE_ARN" \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=namespace,namespaces=demo

aws eks update-kubeconfig --name "$EKS_NAME" \
  --role-arn "$OBSERVER_ROLE_ARN" --alias eks-demo-observer

kubectl --context eks-demo-observer -n demo get pods
kubectl --context eks-demo-observer -n demo auth can-i delete deployments

Los dos últimos comandos comprueban dos operaciones. El segundo solo consulta la autorización y no elimina ningún recurso.

• La lectura debe estar permitida. Si todavía no ha desplegado ninguna aplicación, una lista vacía de pods sigue siendo una lectura válida.
• La eliminación debe devolver no, porque solo ha concedido permisos de lectura.

Si la segunda comprobación devuelve yes, revise qué otros permisos tiene el rol, tanto en las entradas de acceso como en el control de acceso basado en roles (RBAC) de Kubernetes. Los permisos se acumulan: asociar una política de lectura no retira otras autorizaciones que ya existieran.

Este resultado no equivale a la incorporación a NKP. Para las tareas de instalación, siga utilizando el contexto administrativo guardado en EKS_CTX. Reserve el contexto eks-demo-observer para las comprobaciones de lectura.

Incorporar el clúster de Amazon EKS al workspace

Con la red y el acceso del operador comprobados, el siguiente paso no se puede sustituir por un comando genérico de kubectl: incorpore el clúster de Amazon EKS mediante el procedimiento de NKP que corresponde a su versión.

La incorporación se realiza dentro de un workspace, que permite organizar la gestión de un grupo de clústeres. Puede utilizar workspaces diferentes para desarrollo, preproducción y producción, y añadir etiquetas para identificar el proveedor, la región o el equipo responsable. Esta organización le sirve después para definir qué componentes recibe cada grupo, por ejemplo gestión de certificados, observabilidad o políticas de admisión.

Registrar el clúster

Un kubeconfig que funciona desde su portátil puede depender de herramientas o credenciales que el controlador de NKP no tiene. Por ejemplo, una configuración con exec ejecuta un programa externo para obtener credenciales, y el consumidor debe admitirlo. Si utiliza tokens temporales, también necesita un mecanismo de renovación.

Por eso, no guarde un kubeconfig personal en un Secret suponiendo que cualquier controlador podrá utilizarlo. Prepare el acceso mediante el mecanismo que admite NKP y compruebe que sigue funcionando cuando se renuevan las credenciales.

El procedimiento oficial de la versión puede utilizar un ClusterRoleBinding a cluster-admin para completar el attach. Si su organización exige mínimo privilegio, no reduzca ese permiso de forma experimental. Compruebe primero en la documentación de su versión qué permisos exactos requiere NKP y valide el flujo en un entorno de laboratorio.

Para registrar el clúster, siga estos pasos:

1. Aplique en el clúster de Amazon EKS, con el contexto EKS_CTX, el siguiente manifiesto. Crea la ServiceAccount, su ClusterRoleBinding y el Secret con el token.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kommander-cluster-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kommander-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: kommander-cluster-admin
    namespace: kube-system
---
apiVersion: v1
kind: Secret
metadata:
  name: kommander-cluster-admin-sa-token
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: kommander-cluster-admin
type: kubernetes.io/service-account-token

2. Genere un kubeconfig basado en el token de esa ServiceAccount, según la documentación de su versión de NKP.
3. En la consola de NKP, seleccione el workspace de destino y elija la opción para incorporar un clúster existente (attach).
4. Configure cómo se conecta NKP al API server de Amazon EKS y proporcione el kubeconfig que generó en el paso 2.
5. Espere a que el estado de la incorporación se complete antes de instalar aplicaciones de plataforma.

Comprobar qué registró el hub

La forma exacta del flujo depende de la versión instalada. En las versiones que utilizan el recurso KommanderCluster, este objeto reside en el hub, no en el clúster de Amazon EKS, y NKP mantiene ahí la información de incorporación. El campo kubeconfigRef identifica el Secret con la configuración de acceso remoto, y puede consultar su nombre sin mostrar su contenido. Si quiere automatizar el registro, el último comando muestra la estructura del recurso disponible en su hub.

En NKP 2.18 y posteriores, compruebe primero si el clúster se gestiona mediante NKPCluster y respete ese recurso como fuente de verdad. No asuma que KommanderCluster es el recurso de gestión universal.

kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get kommanderclusters

kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" \
  describe kommandercluster legacy-eks-01

kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" \
  get kommandercluster legacy-eks-01 \
  -o jsonpath='{.spec.kubeconfigRef.name}{"\n"}'

kubectl --context "$HUB_CTX" explain kommandercluster.spec --recursive

El criterio de éxito tiene tres partes:

• El objeto indica que la incorporación ha terminado.
• Los controladores pueden acceder al destino.
• Una operación de plataforma controlada se reconcilia.

Que el nombre del clúster aparezca en la consola solo demuestra que existe una referencia, no que el acceso siga funcionando. Para cubrir la tercera parte, despliegue un primer componente del catálogo, como una herramienta de observabilidad o de gestión de certificados. Antes, revise qué hay instalado en el clúster de Amazon EKS para no duplicar componentes que ya cumplen esa función.

Convertir una decisión común en configuración declarativa

Hasta aquí, ha preparado un clúster existente. Ahora puede expresar una decisión de plataforma que quiere repetir: los clústeres del anillo canary reciben Gatekeeper y una política de imágenes.

Gatekeeper es un ejemplo de aplicación de plataforma, y su disponibilidad depende de la edición, el catálogo y la versión de NKP. Antes de continuar, verifique que aparece como aplicación habilitable para clústeres attached o managed en su entorno.

Mantenga el AppDeployment, que expresa la intención de despliegue, en el repositorio Git que controla su plataforma. NKP AppManagement genera y gestiona las customizaciones y los recursos de aplicación en su repositorio Git interno de gestión. No modifique manualmente ese repositorio generado.

En esta primera validación, aplique el AppDeployment directamente en el hub y la Constraint directamente en el clúster de Amazon EKS, para aislar el comportamiento de Gatekeeper. En una flota, distribuya ambos objetos mediante el flujo GitOps que admite NKP o mediante Flux CD. Los cambios pasan por una revisión y los controladores se encargan de aplicarlos al entorno. Este proceso de comparar lo declarado con lo desplegado y corregir las diferencias se denomina reconciliación.

En NKP, el recurso AppDeployment expresa esa decisión con estos campos:

• appRef: la aplicación versionada del catálogo que quiere desplegar. Para una aplicación normal, no asuma que basta con appID sin name.
• clusterSelector: los clústeres en los que se despliega. El ejemplo oficial utiliza matchExpressions con la clave kommander.d2iq.io/cluster-name.
• configOverrides: los valores comunes del workspace, si la aplicación los necesita. Para valores específicos de cada clúster, utilice clusterConfigOverrides y su selector correspondiente.

Antes de escribir el manifiesto, consulte los recursos disponibles en su versión. Esta comprobación evita copiar un ejemplo con una apiVersion o un kind que no coincidan con el catálogo instalado.

kubectl --context "$HUB_CTX" api-resources --api-group=apps.kommander.d2iq.io
kubectl --context "$HUB_CTX" get clusterapps
kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get appdeployments
kubectl --context "$HUB_CTX" explain appdeployment.spec --recursive

Guarde el siguiente objeto en gatekeeper-app.yaml. Es deliberadamente pequeño. Sustituya el nombre de la aplicación por su identificador versionado en el catálogo y confirme el kind de appRef.

apiVersion: apps.kommander.d2iq.io/v1alpha3
kind: AppDeployment
metadata:
  name: gatekeeper
  namespace: prod-workspace
spec:
  appRef:
    kind: ClusterApp
    name: REEMPLAZAR_APP_GATEKEEPER_VERSIONADA
  clusterSelector:
    matchExpressions:
      - key: kommander.d2iq.io/cluster-name
        operator: In
        values:
          - legacy-eks-01

En esta primera prueba, el selector apunta explícitamente al clúster mediante su nombre registrado en NKP. Así evita depender de cómo se propagan las etiquetas entre KommanderCluster, NKPCluster y el objeto de aplicación en su versión. Si quiere implementar un anillo canary mediante etiquetas propias, compruebe primero en el CRD y en la documentación de su versión que ese selector se evalúa sobre el recurso de clúster que gestiona NKP. Antes de añadir un segundo AppDeployment para Gatekeeper, compruebe que ningún otro lo gestiona ya en esos clústeres.

Aplique primero un dry-run contra el API server del hub. Cuando el esquema y la admisión acepten el objeto, aplíquelo y siga la reconciliación hasta el destino:

kubectl --context "$HUB_CTX" apply --dry-run=server -f gatekeeper-app.yaml
kubectl --context "$HUB_CTX" apply -f gatekeeper-app.yaml
kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get appdeployment gatekeeper -o yaml

kubectl --context "$EKS_CTX" -n gatekeeper-system get pods
kubectl --context "$EKS_CTX" get crd | grep gatekeeper

El estado del AppDeployment indica que el hub aceptó la intención. Los pods, los CRD y los webhooks en el clúster de Amazon EKS indican que la aplicación llegó al destino y está preparada para admitir recursos. Necesita las dos evidencias, porque una no sustituye a la otra.

Para completar la prueba, incorpore un segundo clúster al mismo grupo y compruebe que recibe los componentes y la configuración que le corresponden. Así valida el proceso completo antes de extenderlo al resto de la flota.

Probar la política, no solo su existencia

Con Gatekeeper operativo, puede limitar las imágenes que utilizan los pods del namespace demo a sus registros corporativos. Para ello, utilice el ConstraintTemplate K8sAllowedReposv2 de la biblioteca oficial de Gatekeeper.

Antes de aplicar la Constraint, guarde una revisión fija del ConstraintTemplate en el repositorio, instálela y compruebe que existe el CRD correspondiente:

kubectl --context "$EKS_CTX" apply -f constraint-template-k8sallowedreposv2.yaml
kubectl --context "$EKS_CTX" get crd k8sallowedreposv2.constraints.gatekeeper.sh

Guarde el siguiente contenido en allowed-images.yaml. El valor dryrun de enforcementAction identifica incumplimientos sin bloquear los despliegues.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedReposv2
metadata:
  name: demo-corporate-images
spec:
  enforcementAction: dryrun
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - demo
  parameters:
    allowedImages:
      - "111122223333.dkr.ecr.eu-south-2.amazonaws.com/*"
      - "registry.plataforma.example.com/*"

Sustituya los registros por los de su entorno. La barra (/) antes del comodín evita aceptar un dominio que solo comparta el prefijo. La plantilla comprueba los contenedores normales, initContainers y ephemeralContainers.

Aplique la política y consulte su estado de auditoría:

kubectl --context "$EKS_CTX" apply -f allowed-images.yaml
kubectl --context "$EKS_CTX" get k8sallowedreposv2 demo-corporate-images -o yaml

Cuando haya corregido los incumplimientos, cambie enforcementAction a deny en el repositorio y aplique el cambio. A continuación, pruebe los dos casos. Con –dry-run=server, comprueba la admisión sin crear el pod.

# Debe ser rechazado por el webhook y no crear el pod
kubectl --context "$EKS_CTX" -n demo run policy-negative \
  --image=public.example.net/not-approved:test \
  --restart=Never --dry-run=server -o yaml

# Debe superar la admisión; después, compruebe que la imagen existe
kubectl --context "$EKS_CTX" -n demo run policy-positive \
  --image=111122223333.dkr.ecr.eu-south-2.amazonaws.com/demo/test:stable \
  --restart=Never --dry-run=server -o yaml

La primera prueba debe devolver un error de admisión y la segunda debe superar la política. Guarde las dos respuestas, junto con el estado de la Constraint y del AppDeployment. Esa es la diferencia entre declarar una política y demostrar que actúa.

Tenga en cuenta el alcance de este control. La política comprueba el nombre del registro. La existencia de la imagen y su firma necesitan controles adicionales.

Puede repetir la misma idea en el clúster de Nutanix. El selector y la política pueden ser comunes, mientras que la red, el almacenamiento, las identidades y la imagen disponible siguen siendo decisiones de cada entorno. La configuración común no elimina esas diferencias: las hace visibles y permite comprobarlas.

Investigar si el cambio se detiene

Si el cambio no aparece en el destino, recorra la cadena en orden:

1. Compruebe la revisión del repositorio y el objeto que aceptó Kubernetes.
2. Localice el controlador responsable y revise sus condiciones y logs.
3. Contraste la operación con el estado de AWS.

kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get appdeployment gatekeeper -o yaml
kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get events --sort-by=.lastTimestamp
kubectl --context "$HUB_CTX" get deployments -A

aws eks describe-cluster --name "$EKS_NAME"
aws eks list-updates --name "$EKS_NAME"

Si el recurso expone observedGeneration, compárelo con metadata.generation. Un estado Ready antiguo no demuestra que el controlador haya procesado el último cambio.

Algunos síntomas apuntan a causas concretas:

• El objeto está Ready pero los pods no aparecen: investigue la reconciliación de NKP y el acceso remoto antes de modificar la política.
• CAPA recibe AccessDenied: revise la relación de confianza, el externalID y los permisos efectivos de la identidad de aprovisionamiento. La parte 2 explica cómo configurarla en la sección «Limitar la identidad que aprovisiona infraestructura».
• Un pod queda en ContainerCreating con errores de red: revise Amazon VPC CNI, las subredes y los permisos. Añadir capacidad de cómputo no resuelve un problema de asignación de IP.

Validar el recorrido

La siguiente tabla recoge las evidencias que debe conservar al completar cada paso del recorrido.

Guarde en el repositorio las salidas reales y los tiempos de reconciliación, junto a la combinación de versiones que utilizó.

Limpiar los recursos

Para evitar cargos futuros, elimine los recursos de prueba en orden inverso al de creación. Así evita dejar dependencias huérfanas.

1. Elimine la Constraint y el ConstraintTemplate del clúster de Amazon EKS.
2. Elimine el AppDeployment de Gatekeeper del hub y espere a que los componentes se retiren del clúster.
3. Desincorpore (detach) el clúster de Amazon EKS del workspace de NKP.
4. Elimine la entrada de acceso y la ServiceAccount de prueba.
5. Elimine los recursos de IAM creados para el observador: el rol eks-demo-observer y sus políticas asociadas.

Compruebe que cada eliminación se ha completado antes de pasar a la siguiente. Los controladores de NKP necesitan acceso al clúster para retirar los componentes. Si elimina primero la credencial de acceso, los recursos pueden quedar huérfanos.

Conclusión

En esta publicación, ha separado el acceso del operador del acceso de gestión, ha incorporado un clúster de Amazon EKS existente mediante el flujo de NKP y ha distribuido una aplicación de plataforma con un alcance explícito. La prueba final se limita a lo esencial: una imagen debe entrar y otra debe quedar fuera. Ese resultado conecta la configuración del hub con el comportamiento que observa en el clúster.

Como siguiente paso, pruebe el recorrido con las versiones y una aplicación de su entorno, empezando por un workspace de laboratorio. Guarde las configuraciones y los resultados junto al código de plataforma para repetir lo que funciona y ampliar la flota de forma gradual.

En la parte 2, este modelo se amplía con tres capacidades: dar acceso a servicios de AWS a las aplicaciones mediante Amazon EKS Pod Identity, aprovisionar un clúster de Amazon EKS nuevo desde NKP con Cluster API y separar las direcciones de pods y nodos con custom networking. Si quiere conocer las entregas anteriores de la serie, consulte Cómo mover cargas de trabajo a AWS sin refactorizar con Nutanix NC2.

Recursos

•  Nutanix Kubernetes Platform
• Licenciamiento de NKP (Nutanix Cloud Platform software options)
• Clústeres privados en la Guía del usuario de Amazon EKS
• Entradas de acceso en la Guía del usuario de Amazon EKS
• Actualización de grupos de nodos gestionados en la Guía del usuario de Amazon EKS
• Rollback de versión en la Guía del usuario de Amazon EKS
• Ingestión de métricas desde Prometheus en la Guía del usuario de Amazon Managed Service for Prometheus
• Creating custom applications for NKP, part 3 (AppDeployment y configuración de aplicaciones)
• Gatekeeper Library: Allowed Images (K8sAllowedReposv2)
• Flux: Kustomization y reconciliación remota

Preguntas frecuentes

¿Necesito recrear mis clústeres de Amazon EKS actuales?

No necesariamente. Puede incorporar los clústeres existentes compatibles mediante el modelo attached. En este modelo, NKP gestiona las aplicaciones y las capacidades de plataforma que habilite, pero no asume automáticamente el ciclo de vida completo de la infraestructura de Amazon EKS ni las actualizaciones de Kubernetes del clúster. Antes, compruebe qué componentes tiene instalados, prepare los permisos de acceso y revise las políticas que va a aplicar para evitar conflictos con las aplicaciones.

¿Se detienen las aplicaciones si el hub deja de estar disponible?

En este diseño, el tráfico de las aplicaciones no pasa por el hub (consulte «Por dónde pasa el tráfico de las aplicaciones»), por lo que su caída no implica que las aplicaciones dejen de atender peticiones. Sí pueden verse afectadas las operaciones de gestión, los cambios nuevos y las funciones que dependen de servicios centralizados. Una prueba de interrupción le permite comprobar qué sigue funcionando y qué necesita recuperar la conexión.

¿Puedo seguir utilizando Terraform?

Sí. Con el modelo attached, puede mantener Terraform para la infraestructura y utilizar NKP para los componentes y las políticas de plataforma, siempre que delimite qué recursos controla cada herramienta. Dos controladores que escriben el mismo objeto producen deriva de configuración.

¿Una configuración común permite mover una aplicación?

Facilita el despliegue, pero no mueve automáticamente datos, identidad, red ni almacenamiento. Antes de mover una aplicación, prepare sus dependencias (imágenes compatibles, almacenamiento, permisos, conectividad y datos), compruebe su funcionamiento en el destino y decida cómo trasladar o replicar sus datos.

¿Qué licencia de NKP necesito?

Si el mismo Management Cluster gestiona clústeres NKP y clústeres de Amazon EKS o Azure Kubernetes Service (AKS), valide el uso de NKP Ultimate. Si solo gestiona clústeres de Amazon EKS o AKS, valide el SKU NKP Cloud Kubernetes. Confirme la licencia antes de diseñar el hub, los workspaces y el alcance de la flota, porque las funciones disponibles también dependen de la edición y de la versión.

Acerca de los autores

	Paul Zerdilas Herrera — EMEA Cloud Native Architect, Nutanix Paul trabaja con equipos de plataforma para diseñar y operar entornos Kubernetes híbridos que combinan infraestructura local y servicios en la nube.
	Guillermo Ruiz — Senior Specialist Solutions Architect de Efficient Compute, AWS Guillermo ayuda a equipos de ingeniería a optimizar sus cargas de trabajo y a desplegar soluciones de computación confidencial. Sus áreas de interés incluyen edge computing y observabilidad.