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

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 segunda de las dos partes de la entrega «Gestionar una flota híbrida con Nutanix Kubernetes Platform y Amazon EKS». En la parte 1 se explica cómo incorporar un clúster de Amazon Elastic Kubernetes Service (Amazon EKS) existente a Nutanix Kubernetes Platform (NKP) y distribuir una política de plataforma.

Cuando la flota de Amazon EKS crece, se necesita algo más que gestionar los clústeres que ya existen. Las aplicaciones necesitan acceder a servicios de AWS con permisos limitados, los clústeres nuevos deben nacer con la misma configuración que el resto y los pods necesitan direcciones IP suficientes para crecer. En esta publicación, le mostramos cómo dar a una aplicación acceso a Amazon Simple Storage Service (Amazon S3) con Amazon EKS Pod Identity, cómo aprovisionar un clúster de Amazon EKS nuevo desde Nutanix NKP con Cluster API y cómo separar las direcciones de pods y nodos con custom networking.

Cada capacidad sigue el mismo método que la parte 1: declarar una decisión en un archivo, seguir su reconciliación y comprobar el resultado en el destino. Por eso, cada sección termina con una prueba que demuestra el comportamiento, no solo la existencia de los objetos.

Información general de la solución

En la parte 1, incorporó un clúster de Amazon EKS existente a NKP con el modelo attached: su herramienta de infraestructura sigue controlando el clúster y NKP distribuye las aplicaciones de plataforma. En esta publicación, se utiliza también el modelo managed, en el que NKP aprovisiona el clúster mediante Cluster API (CAPI) y Cluster API Provider AWS (CAPA).

La figura 1 muestra cómo llega una declaración desde el Management Cluster de NKP, que en esta publicación se denomina hub, hasta las API de AWS.

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

El administrador de plataforma declara los recursos Cluster y MachineDeployment, o utiliza la interfaz de NKP. Los controladores de CAPI reconcilian el estado deseado y CAPA se autentica con la identidad configurada para el controlador. A continuación, CAPA llama a las API de Amazon EKS, Amazon EC2 y Amazon EC2 Auto Scaling para crear el plano de control y los grupos de nodos. Por último, el kubeconfig y el estado reconciliado vuelven al hub.

La figura 1 muestra como ejemplo una identidad estática, AWSClusterStaticIdentity. En esta publicación se utiliza AWSClusterRoleIdentity, que asume un rol de AWS Identity and Access Management (IAM) mediante AWS Security Token Service (AWS STS) y requiere configurar también su identidad de origen.

El recorrido tiene tres partes, cada una con su propia identidad o su propio recurso de red:

• Identidad de aplicación: un rol de IAM asociado a una ServiceAccount de Kubernetes mediante Amazon EKS Pod Identity, separado de las identidades que administran el clúster o crean infraestructura.
• Aprovisionamiento: un clúster de Amazon EKS nuevo, declarado en archivos que puede revisar, guardar en el repositorio y reutilizar, y creado con una identidad de aprovisionamiento limitada.
• Red de pods: subredes dedicadas para los pods mediante custom networking de Amazon VPC CNI.

Requisitos previos

Para seguir esta publicación, necesita lo siguiente:

• Haber completado la parte 1, o disponer de un hub de NKP con un workspace y un clúster de Amazon EKS incorporado. En esta publicación se reutilizan las variables AWS_REGION, EKS_NAME, EKS_CTX, HUB_CTX, HUB_KUBECONFIG y WS_NAMESPACE de la parte 1.
• NKP con los proveedores de Cluster API configurados en el hub, y cluster Amazon EKS. Algunos pasos cambian según la versión de NKP, como se indica en cada sección.
• AWS Command Line Interface (AWS CLI) versión 2, kubectl y la CLI nkp, con permisos para crear roles de IAM y clústeres de Amazon EKS en la cuenta de prueba.
• Un bucket de Amazon S3 de prueba con al menos un objeto bajo el prefijo reports/ y otro fuera de ese prefijo.
• Una imagen de contenedor corporativa con una versión de AWS CLI compatible con Amazon EKS Pod Identity.
• Una nube privada virtual (VPC) de Amazon Virtual Private Cloud (Amazon VPC) con tres subredes privadas en zonas de disponibilidad diferentes de la región eu-south-2, con la conectividad desde el hub que se describe en la parte 1.
• Para custom networking, un CIDR secundario asociado a la VPC y una subred de pods por zona de disponibilidad.

Dar acceso a Amazon S3 a una aplicación con Amazon EKS Pod Identity

En la parte 1, configuró el acceso del operador y el de NKP. Las aplicaciones necesitan su propio acceso a los servicios de AWS que utilizan.

En este ejemplo, una aplicación del namespace demo lee informes almacenados bajo el prefijo reports/ de un bucket de Amazon S3. La aplicación recibe una identidad propia, separada de las que se utilizan para administrar el clúster o crear infraestructura.

Amazon EKS Pod Identity asocia un rol de IAM con una cuenta de servicio de Kubernetes (ServiceAccount). Los pods que utilizan esa cuenta obtienen credenciales temporales con los permisos del rol. Antes de crear la asociación, compruebe que dispone de lo siguiente:

• Nodos Linux de Amazon EC2 compatibles con Amazon EKS Pod Identity.
• El agente de Amazon EKS Pod Identity instalado y operativo.
• Permisos en el rol del nodo para utilizar la API de Amazon EKS Auth, y conectividad con ese servicio.
• Una versión del SDK de AWS o de AWS CLI compatible dentro de la imagen de la aplicación.

Si ha utilizado IAM roles for service accounts (IRSA), la diferencia es que, con Amazon EKS Pod Identity, la asociación se configura mediante la API de Amazon EKS y no necesita añadir la anotación del rol a la ServiceAccount.

Crear el rol y definir sus permisos

Prepare dos políticas: una que indica quién puede asumir el rol y otra que define qué puede hacer la aplicación. La primera, pod-identity-trust.json, permite que el servicio de Amazon EKS Pod Identity asuma el rol y añada etiquetas a la sesión:

{
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": {
         "Service": "pods.eks.amazonaws.com"
       },
       "Action": [
         "sts:AssumeRole",
         "sts:TagSession"
       ]
     }]
   }

Este ejercicio utiliza un rol dedicado. Cuando lo traslade a producción, ajuste las condiciones de la política de confianza para limitar su uso a los clústeres, namespaces y cuentas de servicio previstos.

La segunda política, reports-read.json, concede lectura sobre los objetos cuyo nombre empieza por reports/. Sustituya REEMPLAZAR-BUCKET por el nombre de su bucket de prueba:

{
     {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::/reports/*"
  }]
}

Si los objetos están cifrados con una clave de AWS Key Management Service (AWS KMS) administrada por el cliente, compruebe también los permisos de descifrado y la política de esa clave. Con ambos archivos preparados, cree el rol y añada su política:

aws iam create-role --role-name eks-reports-reader \
  --assume-role-policy-document file://pod-identity-trust.json

aws iam put-role-policy --role-name eks-reports-reader \
  --policy-name ReadReports \
  --policy-document file://reports-read.json

Estos comandos muestran cómo se relacionan los recursos. En su proceso habitual de despliegue, gestione el rol y sus políticas con su herramienta de infraestructura como código (IaC).

Asociar el rol con la cuenta de servicio

Cree la ServiceAccount reports-reader en el namespace demo. Si el namespace ya existe, omita su creación. Después, cree la asociación en Amazon EKS e indique el clúster, el namespace, la ServiceAccount y el rol:

kubectl --context "$EKS_CTX" create namespace demo
kubectl --context "$EKS_CTX" -n demo create serviceaccount reports-reader

aws eks create-pod-identity-association \
--cluster-name "$EKS_NAME" \
--namespace demo \
--service-account reports-reader \
--role-arn arn:aws:iam::111122223333:role/eks-reports-reader

aws eks list-pod-identity-associations \
--cluster-name "$EKS_NAME" \
--namespace demo \
--service-account reports-reader

Kubernetes identifica qué ServiceAccount utiliza el pod y Amazon EKS mantiene su asociación con el rol de IAM. Esa asociación se almacena en AWS, así que no puede verificarla inspeccionando solo la ServiceAccount de Kubernetes. Para validarla, consulte la API de Amazon EKS y compare el clúster, el namespace, la ServiceAccount y el rol.

Comprobar qué identidad recibe el pod

Despliegue un pod que utilice reports-reader y consulte su identidad. Guarde el siguiente manifiesto en identity-check.yaml. Sustituya la imagen por su imagen corporativa con AWS CLI y fije su versión o su digest:

apiVersion: v1
kind: Pod
metadata:
name: identity-check
namespace: demo
spec:
serviceAccountName: reports-reader
restartPolicy: Never
containers:
- name: aws-cli
image: REEMPLAZAR_IMAGEN_AWSCLI
command: ["aws"]
args: ["sts", "get-caller-identity"]

kubectl --context "$EKS_CTX" apply -f identity-check.yaml
kubectl --context "$EKS_CTX" -n demo logs identity-check

El ARN que devuelve el comando debe corresponder a una sesión del rol eks-reports-reader. A continuación, compruebe sus permisos: lea un objeto existente bajo reports/ y repita la operación con otro objeto fuera de ese prefijo. La primera lectura debe funcionar y la segunda debe devolver un error de acceso.

Esta última comprobación es importante. GetCallerIdentity indica quién realiza la petición; la lectura del objeto demuestra qué puede hacer esa identidad. Como solo ha concedido s3:GetObject, pruebe con la ruta de un objeto conocido: listar el bucket requiere un permiso adicional que la política no incluye.

Aprovisionar un clúster de Amazon EKS nuevo desde NKP con Cluster API

El siguiente paso es crear un clúster de Amazon EKS nuevo desde NKP, con su configuración descrita en archivos que puede revisar, guardar en el repositorio y reutilizar. Es el flujo que muestra la figura 1.

Este ejemplo utiliza un workspace de laboratorio y una VPC que ya dispone de subredes privadas. El hub debe tener configurados los proveedores de Cluster API.

Generar la configuración inicial

Consulte las opciones de creación disponibles en su CLI y defina una versión de Kubernetes compatible con su combinación de NKP y Amazon EKS. La opción –dry-run genera los recursos sin crear todavía la infraestructura:

nkp create cluster eks --help

export K8S_VERSION=REEMPLAZAR_VERSION_COMPATIBLE
export NEW_EKS_NAME=prod-eks-01

nkp create cluster eks \
--kubeconfig "$HUB_KUBECONFIG" \
--cluster-name "$NEW_EKS_NAME" \
--region "$AWS_REGION" \
--kubernetes-version "$K8S_VERSION" \
--namespace "$WS_NAMESPACE" \
--dry-run --output yaml > eks-generated.yaml

cp eks-generated.yaml eks-reviewed.yaml

Compruebe que estos parámetros corresponden a la CLI instalada. El archivo generado contiene los recursos y las referencias que necesita esa versión de NKP, incluidos los componentes de inicialización (bootstrap). Trabaje sobre la copia eks-reviewed.yaml para conservar la configuración inicial.

Generar el archivo con la CLI de NKP le proporciona una base alineada con sus proveedores y versiones de API. Si utiliza ejemplos de la documentación de CAPI o de CAPA, compruebe su compatibilidad antes de incorporarlos.

Limitar la identidad que aprovisiona infraestructura

Antes de editar el clúster, defina qué identidad utiliza CAPA para crear recursos en AWS. Con AWSClusterRoleIdentity, el controlador asume un rol en la cuenta de destino. Para ello necesita credenciales válidas, permiso para ejecutar sts:AssumeRole y una política de confianza en el rol de destino que autorice ese acceso.

En la cuenta de destino, la política de confianza capa-trust.json permite asumir el rol desde la identidad del hub. Sustituya la cuenta y el rol de origen por los de su entorno:

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::444455556666:role/nkp-controller-source"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "nkp-prod-fleet"
}
}
}]
}

Cree el rol nkp-capa-provisioner con esa política de confianza y asígnele los permisos de aprovisionamiento que indica la documentación de su versión de NKP y CAPA:

aws iam create-role --role-name nkp-capa-provisioner \
--assume-role-policy-document file://capa-trust.json

El externalID debe coincidir en ambas configuraciones. Es una condición adicional de confianza, no un secreto. El rol de origen necesita permiso para asumir específicamente nkp-capa-provisioner, y este necesita los permisos de aprovisionamiento. Limite también iam:PassRole a los roles del plano de control y de los nodos que CAPA deba pasar a los servicios.

A continuación, guarde la configuración de la identidad en prod-role-identity.yaml. Con allowedNamespaces, limita su uso al namespace de su workspace:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSClusterRoleIdentity
metadata:
name: prod-account-provisioner
spec:
roleARN: arn:aws:iam::111122223333:role/nkp-capa-provisioner
sessionName: nkp-prod
externalID: nkp-prod-fleet
sourceIdentityRef:
kind: AWSClusterControllerIdentity
name: default
allowedNamespaces:
list:
- prod-workspace

Compruebe que el CRD instalado admite v1beta2 y aplique el objeto en el hub:

kubectl --context "$HUB_CTX" explain awsclusterroleidentity.spec --recursive
kubectl --context "$HUB_CTX" apply --dry-run=server -f prod-role-identity.yaml
kubectl --context "$HUB_CTX" apply -f prod-role-identity.yaml

La identidad AWSClusterRoleIdentity también depende de la combinación de versión y flujo de aprovisionamiento. En un clúster basado en ClusterClass, aplique la configuración mediante el recurso y las variables que genere la CLI o la plantilla de NKP, y utilice kubectl explain antes de aplicar un objeto independiente.

Para comprobar el límite, intente una creación desde el namespace autorizado y otra desde un namespace excluido. La primera debe funcionar y la segunda debe quedar bloqueada antes de crear infraestructura. Los eventos de CAPI y AWS CloudTrail le ayudan a verificar ambos resultados.

Configurar la red, la identidad y los logs del plano de control

El recurso AWSManagedControlPlane describe el plano de control de Amazon EKS. En el flujo ClusterClass de NKP 2.18 y posteriores, no lo trate como fuente de verdad para editarlo directamente: siga la documentación de su versión y cambie NKPCluster o las variables de la ClusterClass. El siguiente fragmento es ilustrativo para las versiones y los flujos que exponen estos campos directamente. Contrástelo siempre con el CRD instalado.

# Fragmento de AWSManagedControlPlane en eks-reviewed.yaml
spec:
region: eu-south-2
version: REEMPLAZAR_VERSION_COMPATIBLE
identityRef:
kind: AWSClusterRoleIdentity
name: prod-account-provisioner
network:
vpc:
id: vpc-REEMPLAZAR
subnets:
- id: subnet-REEMPLAZAR_A
- id: subnet-REEMPLAZAR_B
- id: subnet-REEMPLAZAR_C
endpointAccess:
private: true
public: false
logging:
apiServer: true
audit: true
authenticator: true

Con esta configuración, toma varias decisiones:

• Utilizar una VPC existente. Su creación queda integrada en su diseño de red.
• Utilizar una identidad de aprovisionamiento concreta. identityRef hace referencia a prod-account-provisioner, que configuró en el apartado anterior.
• Mantener privado el endpoint de Kubernetes. Los componentes de gestión necesitan resolución DNS y conectividad con ese endpoint, como se comprueba en la parte 1.
• Habilitar los logs del plano de control. Le ayudan a investigar problemas de autenticación, solicitudes al API server y operaciones sobre los recursos de Kubernetes.

Las tres subredes son solo una parte del diseño. Para distribuir las aplicaciones entre zonas de disponibilidad, configure los nodos y la planificación de los pods de forma coherente.

Revise también el modelo de acceso y el cifrado disponibles en su versión. Si el clúster utiliza entradas de acceso de Amazon EKS (access entries), mantenga esa elección alineada con las identidades. Si conserva aws-auth y mapRoles, documente cómo se gestionan y cómo realizar la transición. Si utiliza una clave de AWS KMS administrada por el cliente, configure su referencia y sus permisos, y defina quién la administra y cómo mantiene su disponibilidad.

Configurar el cómputo y su escalado

Con la identidad y el plano de control preparados, configure los nodos. Incorpore el siguiente fragmento al AWSManagedMachinePool generado y conserve las referencias y las réplicas deseadas del objeto MachinePool asociado:

# Fragmento de AWSManagedMachinePool en eks-reviewed.yaml
spec:
instanceType: m7g.xlarge
amiType: AL2023_ARM_64_STANDARD
subnetIDs:
- subnet-REEMPLAZAR_A
- subnet-REEMPLAZAR_B
- subnet-REEMPLAZAR_C
scaling:
minSize: 3
maxSize: 9
updateConfig:
maxUnavailable: 1
labels:
workload-tier: general
additionalTags:
Environment: production
CostCenter: platform

Este ejemplo utiliza instancias basadas en AWS Graviton, así que las imágenes y sus dependencias deben ser compatibles con arm64. Compruebe también que el tipo de instancia está disponible en las zonas de disponibilidad elegidas.

Los valores minSize y maxSize establecen los límites del grupo, pero el escalado según la demanda necesita un controlador que ajuste su tamaño. Defina quién realiza esa función y cómo se coordina con CAPI.

Si incorpora Karpenter, utilice sus NodePools y NodeClaims para gestionar capacidad separada de estos grupos. Así mantiene una base estable para los componentes de plataforma y añade capacidad flexible, incluidas instancias de spot de Amazon EC2 para cargas tolerantes a interrupciones, sin que dos controladores intenten gestionar los mismos nodos.

Validar los cambios antes de crear el clúster

Primero, contraste los ejemplos con el esquema instalado. Después, valide el archivo contra el API server del hub y revise los cambios que se aplicarían:

kubectl --context "$HUB_CTX" explain awsmanagedcontrolplane.spec --recursive
kubectl --context "$HUB_CTX" explain awsmanagedcontrolplane.spec.accessConfig

kubectl --context "$HUB_CTX" apply --dry-run=server -f eks-reviewed.yaml
kubectl --context "$HUB_CTX" diff -f eks-reviewed.yaml

El dry-run comprueba que los recursos cumplen los esquemas y los controles de admisión del hub. El diff muestra las diferencias respecto al estado actual. Si un campo no está disponible, revise la combinación de versiones antes de continuar.

Esta validación todavía no realiza operaciones en AWS. Los permisos efectivos, las cuotas y la capacidad se comprueban durante la creación. Si automatiza este paso, tenga en cuenta que kubectl diff devuelve el código de salida 1 cuando encuentra diferencias, y ese resultado no implica por sí solo un error.

Crear el clúster y seguir el aprovisionamiento

Una vez revisados los cambios, aplique el manifiesto y siga su evolución desde el hub y desde la API de Amazon EKS:

kubectl --context "$HUB_CTX" apply -f eks-reviewed.yaml

kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get clusters
kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get awsmanagedcontrolplanes
kubectl --context "$HUB_CTX" -n "$WS_NAMESPACE" get awsmanagedmachinepools

aws eks describe-cluster --name "$NEW_EKS_NAME" \
--query 'cluster.{status:status,version:version,endpoint:endpoint}'

Durante el proceso, el plano de control puede estar disponible mientras los nodos todavía se están creando. Considere el clúster listo cuando se cumplan todas estas condiciones:

• Amazon EKS indica el estado ACTIVE.
• Los recursos de infraestructura y de plano de control muestran sus condiciones de disponibilidad.
• Los nodos están Ready y los complementos funcionan.
• El clúster nuevo aparece incorporado al workspace mediante el flujo de NKP correspondiente.

En NKP 2.18 y posteriores, además de revisar los recursos de CAPI, compruebe el estado de NKPCluster. Si existe, su estado Ready y sus referencias a CAPI y a KommanderCluster son la evidencia principal de que el flujo actual gestiona el clúster. Inspeccione los objetos AWSManagedControlPlane y AWSManagedMachinePool como recursos reconciliados, no como objetos que deba editar directamente.

Separar las direcciones de pods y nodos

Cuando aumenta el número de pods, también crece el consumo de direcciones IP. Para dar a los pods un espacio propio, configure el custom networking que planificó en la parte 1. En este ejemplo IPv4, los nodos mantienen su interfaz principal en una subred y los pods utilizan interfaces secundarias conectadas a otras subredes de la misma zona de disponibilidad.

Los comandos de esta sección se aplican al clúster definido en EKS_NAME y EKS_CTX. Si quiere aplicar el cambio al clúster que creó desde NKP, actualice las variables o, si CAPA o NKP gestionan el complemento, haga el cambio en su configuración declarativa.

Adapte estos rangos al plan de direccionamiento de su organización y configure las rutas y las reglas de seguridad necesarias. Separar las direcciones de los pods no establece automáticamente la conectividad con otros entornos.

Configurar las subredes de pods

Cree un recurso ENIConfig por cada zona de disponibilidad utilizada. Este recurso indica a Amazon VPC CNI qué subred y qué grupos de seguridad debe utilizar para las interfaces de los pods. Guarde este ejemplo en eniconfig-a.yaml y repítalo para las demás zonas:

apiVersion: crd.k8s.amazonaws.com/v1alpha1
kind: ENIConfig
metadata:
name: eu-south-2a
spec:
subnet: subnet-REEMPLAZAR_PODS_A
securityGroups:
- sg-REEMPLAZAR_PODS

La subred indicada debe pertenecer a eu-south-2a. El nombre del recurso coincide con el de la zona de disponibilidad para que Amazon VPC CNI seleccione la configuración que corresponde a cada nodo.

kubectl --context "$EKS_CTX" apply -f eniconfig-a.yaml

Activar custom networking en Amazon VPC CNI

En vpc-cni-values.json, habilite custom networking, la selección por zona de disponibilidad y la delegación de prefijos:

{
"env": {
"AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG": "true",
"ENI_CONFIG_LABEL_DEF": "topology.kubernetes.io/zone",
"ENABLE_PREFIX_DELEGATION": "true"
}
}

Primero, consulte la versión y la configuración actual del complemento y las opciones que admite. Con las subredes y todos los ENIConfig preparados, actualice el complemento. Incorpore al archivo los ajustes existentes que necesite conservar.

aws eks describe-addon --cluster-name "$EKS_NAME" --addon-name vpc-cni

aws eks describe-addon-configuration \
--addon-name vpc-cni \
--addon-version REEMPLAZAR_VERSION_CNI

aws eks update-addon \
--cluster-name "$EKS_NAME" \
--addon-name vpc-cni \
--configuration-values file://vpc-cni-values.json

Utilice estos comandos solo cuando AWS CLI sea la fuente de configuración del complemento. Si CAPA, NKP, Flux u otra herramienta ya lo gestiona, haga el cambio en su configuración declarativa para mantener una única fuente de configuración.

La delegación de prefijos necesita instancias compatibles y bloques contiguos disponibles en las subredes. Revise también maxPods y, cuando corresponda, sustituya los nodos de forma gradual para aplicar el nuevo diseño.

Comprobar la asignación de direcciones

Después del cambio, revise la configuración por zona de disponibilidad, las IP de los pods y los logs del CNI:

kubectl --context "$EKS_CTX" get eniconfig
kubectl --context "$EKS_CTX" get nodes -L topology.kubernetes.io/zone
kubectl --context "$EKS_CTX" -n demo get pods -o wide
kubectl --context "$EKS_CTX" -n kube-system logs \
daemonset/aws-node -c aws-node --tail=100

Los pods nuevos deben recibir direcciones de las subredes previstas y mantener el acceso a DNS, al API server y a sus dependencias. Si alguno queda en Pending, consulte sus eventos para saber qué impide su asignación a un nodo. Si permanece 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 de esta publicación.

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. Compruebe que cada eliminación se ha completado antes de pasar a la siguiente.

1. Elimine el pod de prueba, la asociación de Amazon EKS Pod Identity y la ServiceAccount. Obtenga el identificador de la asociación con list-pod-identity-associations:

kubectl --context "$EKS_CTX" -n demo delete pod identity-check

aws eks delete-pod-identity-association \
--cluster-name "$EKS_NAME" \
--association-id REEMPLAZAR_ID_ASOCIACION

kubectl --context "$EKS_CTX" -n demo delete serviceaccount reports-reader

2. Elimine el rol eks-reports-reader y su política:

aws iam delete-role-policy --role-name eks-reports-reader --policy-name ReadReports
aws iam delete-role --role-name eks-reports-reader

3. Si aplicó custom networking en un clúster de prueba, restaure la configuración anterior del complemento vpc-cni, sustituya los nodos y elimine los ENIConfig cuando ningún nodo los utilice.
4. Elimine el clúster que creó desde NKP con el procedimiento de su versión, por ejemplo eliminando el recurso NKPCluster o Cluster en el hub. Espere a que CAPA retire los recursos de AWS y compruebe que aws eks describe-cluster ya no encuentra el clúster.
5. Elimine el objeto AWSClusterRoleIdentity del hub y el rol nkp-capa-provisioner. Hágalo después del paso 4: CAPA necesita esa identidad para eliminar la infraestructura del clúster.
6. Elimine el bucket de Amazon S3 de prueba, las subredes de pods y el CIDR secundario si los creó solo para esta publicación.

Conclusión

En esta publicación, ha dado a una aplicación una identidad propia con Amazon EKS Pod Identity, ha aprovisionado un clúster de Amazon EKS nuevo desde NKP con una identidad de aprovisionamiento limitada, nodos AWS Graviton con límites de escalado y logs del plano de control, y ha separado las direcciones de pods y nodos con custom networking.

Una flota híbrida no se administra copiando el mismo manifiesto en todos los clústeres. Primero necesita saber quién es responsable de cada capa y, después, qué acceso permite que el siguiente componente haga su trabajo. Junto con la parte 1, este recorrido aplica en cada paso el mismo principio: declarar una decisión, seguir su reconciliación y comprobar el resultado en el destino.

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. Si todavía no ha incorporado sus clústeres existentes, empiece por la parte 1 de esta publicació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.