**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Composición de recursos con kro (Kube Resource Orchestrator)
**kro (Kube Resource Orchestrator)** es un proyecto de código abierto nativo de Kubernetes que le permite definir las API de Kubernetes personalizadas mediante una configuración sencilla y directa. Con kro, puede configurar fácilmente nuevas API personalizadas que crean un grupo de objetos de Kubernetes y las operaciones lógicas entre ellos.
Con las capacidades de EKS, AWS administra kro completamente, lo que elimina la necesidad de instalar, mantener y escalar los controladores de kro en sus clústeres.
## Cómo funciona kro
kro presenta una definición de recursos personalizados (CRD) llamada `ResourceGraphDefinition` (RGD) que permite la creación sencilla y simplificada de API de Kubernetes personalizadas. Al crear una `ResourceGraphDefinition`, kro utiliza extensiones nativas de Kubernetes para crear y administrar nuevas API en el clúster. A partir de esta especificación de recurso único, kro creará y registrará una nueva CRD en función de la especificación y se adaptará para administrar los recursos personalizados recién definidos.
Las RGD pueden incluir varios recursos y kro determinará las interdependencias y el orden de los recursos para que no tenga que hacerlo usted. Puede utilizar una sintaxis sencilla para inyectar la configuración de un recurso a otro, lo que simplifica considerablemente las composiciones y elimina la necesidad de utilizar operadores de “glue” en el clúster. Con kro, los recursos personalizados pueden incluir recursos nativos de Kubernetes, así como cualquier definición de recursos personalizados (CRD) instalada en el clúster.
kro admite un solo tipo de recurso principal:
+ **ResourceGraphDefinition (RGD)**: define un recurso personalizado de Kubernetes y encapsula uno o más recursos de Kubernetes nativos o personalizados subyacentes.
Además de este recurso, kro creará y administrará el ciclo de vida de los recursos personalizados que se creen con él, así como todos los recursos que lo componen.
kro se integra sin problemas con Controladores de AWS para Kubernetes (ACK), lo que le permite componer recursos de carga de trabajo con recursos de AWS para crear abstracciones de alto nivel. Esto le permite crear sus propios componentes básicos en la nube, lo que simplifica la administración de recursos y permite crear patrones reutilizables con valores de configuración predeterminados e inmutables basados en sus estándares organizativos.
## Beneficios de kro
kro permite a los equipos de plataformas crear API de Kubernetes personalizadas que componen varios recursos en abstracciones de nivel superior. Esto simplifica la administración de recursos al permitir a los desarrolladores implementar aplicaciones complejas mediante recursos personalizados sencillos, estandarizados y versionados. Definirá patrones reutilizables para las combinaciones de recursos comunes, lo que permite una creación de recursos coherente en toda la organización.
kro utiliza el [lenguaje de expresión común (CEL) en Kubernetes](https://kubernetes.io/docs/reference/using-api/cel/) para transferir valores entre los recursos e incorporar la lógica condicional, lo que proporciona flexibilidad en la composición de los recursos. Puede componer los recursos de Kubernetes y de AWS administrados por ACK en API personalizadas unificadas, lo que permite definir todas las aplicaciones e infraestructuras.
kro admite la configuración declarativa a través de los manifiestos de Kubernetes, lo que permite que los flujos de trabajo de GitOps y las prácticas de infraestructura como código se integren sin problemas con los procesos de desarrollo existentes. Como parte de las capacidades administradas de EKS, AWS administra kro completamente, lo que elimina la necesidad de instalar, configurar y mantener los controladores kro en sus clústeres.
**Ejemplo: creación de una ResourceGraphDefinition**
En el siguiente ejemplo, se muestra una `ResourceGraphDefinition` sencilla que crea una aplicación web con una implementación y un servicio:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
```
Cuando los usuarios crean instancias del recurso personalizado de `WebApplication`, kro crea automáticamente los recursos de implementación y servicio correspondientes y administra su ciclo de vida junto con el recurso personalizado.
## Integración con otras capacidades administradas de EKS
kro se integra con otras capacidades administradas de EKS.
+ **Controladores de AWS para Kubernetes (ACK)**: utilice kro para componer los recursos de ACK en abstracciones de nivel superior, lo que simplifica la administración de los recursos de AWS.
+ **Argo CD**: utilice Argo CD para administrar la implementación de los recursos personalizados de kro en varios clústeres, lo que activa los flujos de trabajo de GitOps para las pilas de aplicaciones y los componentes básicos de la plataforma.
## Introducción a kro
Para comenzar a utilizar la capacidad de EKS para kro:
1. [Cree un recurso de capacidad de kro](create-kro-capability.md) en su clúster de EKS a través de la consola de AWS, la AWS CLI o su infraestructura preferida como herramienta de código.
1. Cree ResourceGraphDefinitions (RGD) que definan sus composiciones de recursos y API personalizadas.
1. Aplique instancias de los recursos personalizados para aprovisionar y administrar los recursos de AWS y Kubernetes subyacentes.
# Creación de una capacidad de kro
En este tema, se explica cómo crear una capacidad de kro en un clúster de Amazon EKS.
## Requisitos previos
Antes de crear una capacidad de kro, asegúrese de que disponga de lo siguiente:
+ Un clúster de Amazon EKS existente que ejecute una versión de Kubernetes compatible (se admiten todas las versiones con soporte estándar y ampliado)
+ Permisos de IAM suficientes para crear recursos de capacidad en los clústeres de EKS
+ (Para la CLI o eksctl) La herramienta de la CLI adecuada instalada y configurada
**nota**
A diferencia de ACK y Argo CD, kro no necesita permisos de IAM adicionales más allá de la política de confianza. kro opera completamente dentro de su clúster y no hace llamadas a la API de AWS. Sin embargo, debe proporcionar igualmente un rol de capacidad de IAM con la política de confianza adecuada. Para obtener información acerca de la configuración de permisos de RBAC de Kubernetes para kro, consulte [Configuración de permisos de kro](kro-permissions.md).
## Elección de la herramienta
Puede crear una capacidad de kro mediante la Consola de administración de AWS, la AWS CLI o eksctl:
+ [Creación de una capacidad de kro mediante la consola](kro-create-console.md): uso de la consola para una experiencia guiada
+ [Creación de una capacidad de kro mediante la AWS CLI](kro-create-cli.md): uso de la AWS CLI para scripts y automatización
+ [Creación de una capacidad de kro mediante eksctl](kro-create-eksctl.md): uso de eksctl para una experiencia nativa de Kubernetes
## Qué ocurre cuando se crea una capacidad de kro
Al crear una capacidad de kro:
1. EKS crea el servicio de capacidad de kro y lo configura para supervisar y administrar los recursos del clúster.
1. Las definiciones de recursos personalizados (CRD) de Kubernetes se instalan en el clúster.
1. Se crea automáticamente una entrada de acceso para el rol de capacidad de IAM con `AmazonEKSKROPolicy`, que concede permisos para administrar ResourceGraphDefinitions y sus instancias (consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md))
1. La capacidad asume el rol de capacidad de IAM que proporcione (se utiliza solo para la relación de confianza).
1. kro comienza a supervisar los recursos de `ResourceGraphDefinition` y sus instancias.
1. El estado de la capacidad cambia de `CREATING` a `ACTIVE`.
Una vez activo, puede crear ResourceGraphDefinitions para definir las API personalizadas y crear instancias de esas API.
**nota**
La entrada de acceso creada automáticamente incluye `AmazonEKSKROPolicy`, que concede a kro permisos para administrar ResourceGraphDefinitions y sus instancias. Para permitir que kro cree los recursos subyacentes de Kubernetes definidos en las ResourceGraphDefinitions (como Implementaciones, Servicios o recursos de ACK), debe configurar políticas adicionales de entrada de acceso. Para obtener más información sobre las entradas de acceso y cómo configurar permisos adicionales, consulte [Configuración de permisos de kro](kro-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Siguientes pasos
Después de crear la capacidad de kro:
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
+ [Conceptos de kro](kro-concepts.md): más información sobre SimpleSchema, las expresiones de CEL y los patrones de composición de recursos
# Creación de una capacidad de kro mediante la consola
En este tema, se describe cómo crear una capacidad de kro (Kube Resource Orchestrator) mediante la Consola de administración de AWS.
## Creación de la capacidad de kro
1. Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home\$1/clusters.
1. Seleccione el nombre del clúster para abrir la página de detalles del clúster.
1. Elija la pestaña **Capacidades**.
1. En el menú de navegación izquierdo, seleccione **kro (Kube Resource Orchestrator)**.
1. Elija **Crear capacidad de kro**.
1. Para el **rol de capacidad de IAM**:
+ Si ya tiene un rol de capacidad de IAM, selecciónelo en el menú desplegable.
+ Si necesita crear un rol, elija **Crear rol de kro**.
De este modo, se abre la consola de IAM en una nueva pestaña con la política de confianza rellenada previamente. El rol no necesita permisos de IAM adicionales, ya que kro opera completamente dentro del clúster.
Después de crear el rol, regrese a la consola de EKS y el rol se seleccionará automáticamente.
**nota**
A diferencia de ACK y Argo CD, kro no necesita permisos de IAM adicionales más allá de la política de confianza. kro opera completamente dentro de su clúster y no hace llamadas a la API de AWS.
1. Seleccione **Crear**.
Comenzará el proceso de creación de la capacidad.
## Comprobación de la activación de la capacidad
1. En la pestaña **Capacidades**, consulte el estado de la capacidad de kro.
1. Espere a que el estado cambie de `CREATING` a `ACTIVE`.
1. Una vez activa, la capacidad está lista para usarse.
Para obtener información sobre los estados de la capacidad y la solución de problemas, consulte [Uso de recursos de capacidades](working-with-capabilities.md).
## Concesión de permisos para administrar los recursos de Kubernetes
Cuando crea una capacidad de kro, se crea automáticamente una entrada de acceso de EKS con la `AmazonEKSKROPolicy`, lo que permite a kro administrar ResourceGraphDefinitions y sus instancias. Sin embargo, no se conceden permisos de forma predeterminada para crear los recursos subyacentes de Kubernetes (como Implementaciones, Servicios, ConfigMaps, etc.) definidos en las ResourceGraphDefinitions.
Este diseño intencional sigue el principio de privilegio mínimo: diferentes ResourceGraphDefinitions requieren distintos permisos. Debe configurar explícitamente los permisos que kro necesita según los recursos que administrarán las ResourceGraphDefinitions.
Para comenzar rápidamente, realizar pruebas o trabajar en entornos de desarrollo, utilice `AmazonEKSClusterAdminPolicy`:
1. En la consola de EKS, vaya a la pestaña **Acceso** del clúster.
1. En **Entradas de acceso**, busque la entrada para el rol de capacidad de kro (tendrá el ARN del rol que creó anteriormente).
1. Elija la entrada de acceso para abrir sus detalles.
1. En la sección **Políticas de acceso**, elija **Asociar política de acceso**.
1. Seleccione `AmazonEKSClusterAdminPolicy` en la lista de políticas.
1. En **Ámbito de acceso**, seleccione **Clúster**.
1. Elija **Asociar**.
**importante**
Esta `AmazonEKSClusterAdminPolicy` concede amplios permisos para crear y administrar todos los recursos de Kubernetes, incluida la capacidad de crear cualquier tipo de recurso en todos los espacios de nombres. Esto resulta conveniente para desarrollo y pruebas de concepto, pero no se debe utilizar en producción. Para producción, cree políticas de control de acceso basado en roles personalizadas que concedan únicamente los permisos necesarios para los recursos específicos que administrarán las ResourceGraphDefinitions. Para obtener orientación sobre cómo configurar los permisos de privilegio mínimo, consulte [Configuración de permisos de kro](kro-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de kro estén disponibles en el clúster.
**Uso de la consola**
1. Vaya a su clúster en la consola de Amazon EKS.
1. Elija la pestaña **Recursos**.
1. Elija **Extensiones**.
1. Elija **CustomResourceDefinitions**.
Debería ver el tipo de recursos `ResourceGraphDefinition` en la lista.
**Uso de kubectl**
```
kubectl api-resources | grep kro.run
```
Debería ver el tipo de recursos `ResourceGraphDefinition` en la lista.
## Siguientes pasos
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
+ [Conceptos de kro](kro-concepts.md): más información sobre SimpleSchema, las expresiones de CEL y los patrones de composición
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de kro
# Creación de una capacidad de kro mediante la AWS CLI
En este tema, se describe cómo crear una capacidad de kro (Kube Resource Orchestrator) mediante la AWS CLI.
## Requisitos previos
+ **AWS CLI**: versión `2.12.3` o posterior. Para comprobar la versión, ejecute `aws --version`. Para obtener más información, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ ** `kubectl` ** – una herramienta de línea de comandos para trabajar con clústeres de Kubernetes. Para obtener más información, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
## Paso 1: creación de un rol de capacidad de IAM
Cree un archivo de política de confianza:
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Cree el rol de IAM:
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**nota**
A diferencia de ACK y Argo CD, kro no necesita permisos de IAM adicionales. kro opera completamente dentro de su clúster y no hace llamadas a la API de AWS. El rol solo es necesario para establecer una relación de confianza con el servicio de capacidades de EKS.
## Paso 2: creación de la capacidad de kro
Cree el recurso de la capacidad de kro en su clúster. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster (como `us-west-2`) y *my-cluster* por el nombre del clúster.
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--type KRO \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/KROCapabilityRole \
--delete-propagation-policy RETAIN
```
El comando devuelve una respuesta inmediatamente, pero la capacidad tarda algún tiempo en activarse mientras EKS crea la infraestructura y los componentes de la capacidad necesarios. EKS instalará las definiciones de recursos personalizados de Kubernetes relacionadas con esta capacidad en el clúster según se vaya creando.
**nota**
Si recibe un error que indica que el clúster no existe o que no tiene permisos, compruebe lo siguiente:
El nombre del clúster es correcto
La AWS CLI está configurada para la región correcta
Dispone de los permisos de IAM necesarios
## Paso 3: comprobación de la activación de la capacidad
Espere a que se active la capacidad. Reemplace *region-code* por la región de AWS donde creó el clúster y *my-cluster* por el nombre de su clúster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.status' \
--output text
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`.
También puede ver todos los detalles de la capacidad:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
```
## Paso 4: concesión de permisos para administrar los recursos de Kubernetes
Cuando crea una capacidad de kro, se crea automáticamente una entrada de acceso de EKS con la `AmazonEKSKROPolicy`, lo que permite a kro administrar ResourceGraphDefinitions y sus instancias. Sin embargo, no se conceden permisos de forma predeterminada para crear los recursos subyacentes de Kubernetes (como Implementaciones, Servicios, ConfigMaps, etc.) definidos en las ResourceGraphDefinitions.
Este diseño intencional sigue el principio de privilegio mínimo: diferentes ResourceGraphDefinitions requieren distintos permisos. Por ejemplo: \$1 Una ResourceGraphDefinition que solo crea ConfigMaps y Secretos requiere permisos distintos a uno que crea Implementaciones y Servicios. \$1 Una ResourceGraphDefinition que crea recursos de ACK requiere permisos para esos recursos personalizados específicos. \$1 Algunas ResourceGraphDefinitions pueden limitarse a leer recursos existentes sin crear otros nuevos.
Debe configurar explícitamente los permisos que kro necesita según los recursos que administrarán las ResourceGraphDefinitions.
### Configuración rápida
Para comenzar rápidamente, realizar pruebas o trabajar en entornos de desarrollo, utilice `AmazonEKSClusterAdminPolicy`:
Obtenga el ARN del rol de capacidad:
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro \
--query 'capability.roleArn' \
--output text)
```
Asocie la política de administración del clúster:
```
aws eks associate-access-policy \
--region region-code \
--cluster-name my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**importante**
Esta `AmazonEKSClusterAdminPolicy` concede amplios permisos para crear y administrar todos los recursos de Kubernetes, incluida la capacidad de crear cualquier tipo de recurso en todos los espacios de nombres. Esto resulta conveniente para desarrollo y pruebas de concepto, pero no se debe utilizar en producción. Para producción, cree políticas de control de acceso basado en roles personalizadas que concedan únicamente los permisos necesarios para los recursos específicos que administrarán las ResourceGraphDefinitions. Para obtener orientación sobre cómo configurar los permisos de privilegio mínimo, consulte [Configuración de permisos de kro](kro-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Paso 5: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de kro estén disponibles en el clúster:
```
kubectl api-resources | grep kro.run
```
Debería ver el tipo de recursos `ResourceGraphDefinition` en la lista.
## Siguientes pasos
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
+ [Conceptos de kro](kro-concepts.md): más información sobre SimpleSchema, las expresiones de CEL y los patrones de composición
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de kro
# Creación de una capacidad de kro mediante eksctl
En este tema, se describe cómo crear una capacidad de kro (Kube Resource Orchestrator) mediante eksctl.
**nota**
Los siguientes pasos requieren la versión `0.220.0` o posterior de eksctl. Para comprobar la versión, ejecute `eksctl version`.
## Paso 1: creación de un rol de capacidad de IAM
Cree un archivo de política de confianza:
```
cat > kro-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Cree el rol de IAM:
```
aws iam create-role \
--role-name KROCapabilityRole \
--assume-role-policy-document file://kro-trust-policy.json
```
**nota**
A diferencia de ACK y Argo CD, kro no necesita permisos de IAM adicionales más allá de la política de confianza. kro opera completamente dentro de su clúster y no hace llamadas a la API de AWS.
## Paso 2: creación de la capacidad de kro
Cree la capacidad de kro mediante eksctl. Reemplace *region-code* por la región de AWS donde creó el clúster y *my-cluster* por el nombre de su clúster.
```
eksctl create capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--type KRO \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/KROCapabilityRole
```
El comando vuelve inmediatamente, pero la capacidad tarda algún tiempo en activarse.
## Paso 3: comprobación de la activación de la capacidad
Compruebe el estado de la capacidad. Reemplace *region-code* por la región de AWS donde creó el clúster y *my-cluster* por el nombre de su clúster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-kro
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`.
## Paso 4: concesión de permisos para administrar los recursos de Kubernetes
De forma predeterminada, kro solo puede crear y administrar ResourceGraphDefinitions y sus instancias. Para permitir que kro cree y administre los recursos de Kubernetes subyacentes definidos en su ResourceGraphDefinitions, asocie la política de acceso `AmazonEKSClusterAdminPolicy` a la entrada de acceso de la capacidad.
Obtenga el ARN del rol de capacidad:
```
CAPABILITY_ROLE_ARN=$(aws eks describe-capability \
--region region-code \
--cluster my-cluster \
--name my-kro \
--query 'capability.roleArn' \
--output text)
```
Asocie la política de administración del clúster:
```
aws eks associate-access-policy \
--region region-code \
--cluster my-cluster \
--principal-arn $CAPABILITY_ROLE_ARN \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster
```
**importante**
La `AmazonEKSClusterAdminPolicy` otorga amplios permisos para crear y administrar todos los recursos de Kubernetes y su objetivo es simplificar la puesta en marcha. Para su uso en producción, cree políticas de RBAC más restrictivas que otorguen solo los permisos necesarios para los recursos específicos que administrará su ResourceGraphDefinitions. Para obtener orientación sobre cómo configurar los permisos de privilegio mínimo, consulte [Configuración de permisos de kro](kro-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Paso 5: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de kro estén disponibles en el clúster:
```
kubectl api-resources | grep kro.run
```
Debería ver el tipo de recursos `ResourceGraphDefinition` en la lista.
## Siguientes pasos
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
+ [Conceptos de kro](kro-concepts.md): más información sobre SimpleSchema, las expresiones de CEL y los patrones de composición
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de kro
# Conceptos de kro
kro permite a los equipos de plataformas crear API de Kubernetes personalizadas que componen varios recursos en abstracciones de nivel superior. En este tema, se muestra un ejemplo práctico y, a continuación, se explican los conceptos básicos que debe comprender al trabajar con la capacidad de EKS para kro.
## Introducción a kro
Después de crear la capacidad de kro (consulte [Creación de una capacidad de kro](create-kro-capability.md)), puede comenzar a crear API personalizadas con ResourceGraphDefinitions en el clúster.
A continuación se muestra un ejemplo completo que crea una abstracción simple de una aplicación web:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: webapplication
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
group: kro.run
spec:
name: string | required=true
image: string | default="nginx:latest"
replicas: integer | default=3
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: ${schema.spec.name}
spec:
replicas: ${schema.spec.replicas}
selector:
matchLabels:
app: ${schema.spec.name}
template:
metadata:
labels:
app: ${schema.spec.name}
spec:
containers:
- name: app
image: ${schema.spec.image}
ports:
- containerPort: 80
- id: service
template:
apiVersion: v1
kind: Service
metadata:
name: ${schema.spec.name}
spec:
selector:
app: ${schema.spec.name}
ports:
- protocol: TCP
port: 80
targetPort: 80
```
Después de aplicar esta ResourceGraphDefinition, los equipos de aplicaciones pueden crear aplicaciones web mediante su API simplificada:
```
apiVersion: kro.run/v1alpha1
kind: WebApplication
metadata:
name: my-app
spec:
name: my-app
replicas: 5
```
kro crea automáticamente la implementación y el servicio con la configuración adecuada. Como no se ha especificado `image`, utiliza el valor predeterminado `nginx:latest` del esquema.
## Conceptos clave
**importante**
kro valida ResourceGraphDefinitions en el momento de la creación, no en tiempo de ejecución. Al crear una RGD, kro valida la sintaxis de CEL, compara las expresiones con los esquemas reales de Kubernetes, verifica la existencia de los campos y detecta las dependencias circulares. Esto significa que los errores se detectan inmediatamente al crear la RGD, antes de implementar cualquier instancia.
### ResourceGraphDefinition
Una ResourceGraphDefinition (RGD) define una API de Kubernetes personalizada mediante la especificación de lo siguiente:
+ **Esquema**: la estructura de la API con el formato SimpleSchema (nombres de campo, tipos, valores predeterminados, validación)
+ **Recursos**: plantillas para la creación para recursos de AWS o Kubernetes subyacentes
+ **Dependencias**: cómo se relacionan los recursos entre sí (se detectan automáticamente a partir de referencias de campo)
Al aplicar una RGD, kro registra una nueva definición de recursos personalizados (CRD) en el clúster. A continuación, los equipos de aplicaciones pueden crear instancias de la API personalizada y kro se encarga de crear y administrar todos los recursos subyacentes.
Para obtener más información, consulte la sección [ResourceGraphDefinition Overview](https://kro.run/docs/concepts/rgd/overview/) en la documentación de kro.
### Formato SimpleSchema
SimpleSchema proporciona una forma simplificada de definir esquemas de API sin necesidad de conocimientos de OpenAPI:
```
schema:
apiVersion: v1alpha1
kind: Database
spec:
name: string | required=true description="Database name"
size: string | default="small" enum=small,medium,large
replicas: integer | default=1 minimum=1 maximum=5
```
SimpleSchema admite los tipos `string`, `integer`, `boolean` y `number` con restricciones como `required`, `default`, `minimum`/`maximum`, `enum` y `pattern`.
Para obtener más información, consulte [SimpleSchema](https://kro.run/docs/concepts/rgd/schema/) en la documentación de kro.
### Expresiones de CEL
kro utiliza el lenguaje de expresión común (CEL) para hacer referencia a valores de forma dinámica y agregar lógica condicional. Las expresiones de CEL se encapsulan en `${` y `}` y se pueden usar de dos maneras:
**Expresiones independientes**. Todo el valor del campo es una sola expresión:
```
spec:
replicas: ${schema.spec.replicaCount} # Expression returns integer
labels: ${schema.spec.labelMap} # Expression returns object
```
El resultado de la expresión reemplaza todo el valor del campo y debe coincidir con el tipo esperado del campo.
**Plantillas de cadenas**. Una o más expresiones incrustadas en una cadena:
```
metadata:
name: "${schema.spec.prefix}-${schema.spec.name}" # Multiple expressions
annotation: "Created by ${schema.spec.owner}" # Single expression in string
```
Todas las expresiones de las plantillas de cadenas deben devolver cadenas. Utilice `string()` para convertir otros tipos: `"replicas-${string(schema.spec.count)}"`.
**Referencias de campos**. Acceda a los valores de las especificaciones de la instancia mediante `schema.spec`:
```
template:
metadata:
name: ${schema.spec.name}-deployment
namespace: ${schema.metadata.namespace} # Can also reference metadata
spec:
replicas: ${schema.spec.replicas}
```
**Acceso a campos opcionales**. Utilice `?` para campos que podrían no existir:
```
# For ConfigMaps or Secrets with unknown structure
value: ${configmap.data.?DATABASE_URL}
# For optional status fields
ready: ${deployment.status.?readyReplicas > 0}
```
Si el campo no existe, la expresión devuelve `null` en lugar de producir un error.
**Recursos condicionales**. Incluya los recursos solo cuando se cumplan las condiciones:
```
resources:
- id: ingress
includeWhen:
- ${schema.spec.enableIngress == true}
template:
# ... ingress configuration
```
El campo `includeWhen` acepta una lista de expresiones booleanas. Todas las condiciones deben ser verdaderas para que el recurso se cree. Actualmente, `includeWhen` solo puede hacer referencia a campos `schema.spec`.
**Transformaciones**. Transforme valores mediante funciones y operadores ternarios:
```
template:
spec:
resources:
requests:
memory: ${schema.spec.size == "small" ? "512Mi" : "2Gi"}
# String concatenation
image: ${schema.spec.registry + "/" + schema.spec.imageName}
# Type conversion
port: ${string(schema.spec.portNumber)}
```
**Referencias cruzadas entre recursos**. Valores de referencia de otros recursos:
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: configmap
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
```
Al hacer referencia a otro recurso en una expresión de CEL, se crea automáticamente una dependencia. kro garantiza que el recurso al que se hace referencia se cree primero.
Para obtener más información, consulte [CEL Expressions](https://kro.run/docs/concepts/rgd/cel-expressions/) en la documentación de kro.
### Dependencias de recursos
kro infiere automáticamente las dependencias de las expresiones de CEL: no se especifica el orden, se describen las relaciones. Cuando un recurso hace referencia a otro mediante una expresión de CEL, kro crea una dependencia y determina el orden de creación correcto.
```
resources:
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-data
- id: notification
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: BucketNotification
spec:
bucket: ${bucket.spec.name} # Creates dependency: notification depends on bucket
```
La expresión `${bucket.spec.name}` crea una dependencia. kro crea un gráfico acíclico dirigido (DAG) de todos los recursos y sus dependencias y, a continuación, calcula un orden topológico para la creación.
**Orden de creación**: los recursos se crean por orden topológico (primero las dependencias).
**Creación paralela**: los recursos sin dependencias se crean simultáneamente.
**Orden de eliminación**: los recursos se eliminan por orden topológico inverso (primero los dependientes).
**Dependencias circulares**: no se permiten. kro rechaza las ResourceGraphDefinitions con dependencias circulares durante la validación.
Puede ver el orden de creación de computación:
```
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Para obtener más información, consulte [Graph inference](https://kro.run/docs/concepts/rgd/dependencies-ordering/) en la documentación de kro.
## Composición con ACK
kro funciona sin problemas con la capacidad de EKS para ACK para componer recursos de AWS con recursos de Kubernetes:
```
resources:
# Create {aws} S3 bucket with ACK
- id: bucket
template:
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
spec:
name: ${schema.spec.name}-files
# Inject bucket details into Kubernetes ConfigMap
- id: config
template:
apiVersion: v1
kind: ConfigMap
data:
BUCKET_NAME: ${bucket.spec.name}
BUCKET_ARN: ${bucket.status.ackResourceMetadata.arn}
# Use ConfigMap in application deployment
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
envFrom:
- configMapRef:
name: ${config.metadata.name}
```
Este patrón le permite crear recursos de AWS, extraer sus detalles (ARN, URL, puntos de conexión) e inyectarlos en la configuración de la aplicación, todo ello administrado como una sola unidad.
Para obtener más patrones de composición y ejemplos avanzados, consulte [Consideraciones sobre kro para EKS](kro-considerations.md).
## Siguientes pasos
+ [Consideraciones sobre kro para EKS](kro-considerations.md): más información sobre los patrones específicos de EKS, el RBAC y la integración con ACK y Argo CD
+ [Documentación de kro](https://kro.run/docs/overview): documentación exhaustiva de kro que incluye solución de problemas, patrones de validación y expresiones de CEL avanzadas
# Configuración de permisos de kro
A diferencia de ACK y Argo CD, kro no necesita permisos de IAM. kro opera completamente dentro de su clúster de Kubernetes y no hace llamadas a la API de AWS. Controle el acceso a los recursos de kro mediante el RBAC estándar de Kubernetes.
## Cómo funcionan los permisos con kro
kro utiliza dos tipos de recursos de Kubernetes con diferentes ámbitos:
**ResourceGraphDefinitions**: recursos del ámbito del clúster que definen las API personalizadas. Por lo general, los administran los equipos de plataformas que diseñan y mantienen los estándares organizativos.
**Instancias**: recursos personalizados del ámbito del espacio de nombres creados a partir de ResourceGraphDefinitions. Los equipos de aplicaciones pueden crearlos con los permisos de RBAC adecuados.
De forma predeterminada, la capacidad de kro tiene permisos para administrar ResourceGraphDefinitions y sus instancias mediante la política de entrada de acceso `AmazonEKSKROPolicy`. Sin embargo, kro requiere permisos adicionales para crear y administrar los recursos de Kubernetes subyacentes definidos en las ResourceGraphDefinitions (como implementaciones, servicios o recursos de ACK). Debe otorgar estos permisos mediante las políticas de entrada de acceso o el RBAC de Kubernetes. Para obtener más información sobre la concesión de estos permisos, consulte los [permisos de recursos arbitrarios de kro](capabilities-security.md#kro-resource-permissions).
## Permisos del equipo de plataformas
Los equipos de plataformas necesitan permisos para crear y administrar ResourceGraphDefinitions.
**Ejemplo de ClusterRole para equipos de plataformas**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["*"]
```
**Enlace a miembros del equipo de plataformas**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-team-kro-admin
subjects:
- kind: Group
name: platform-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-platform-admin
apiGroup: rbac.authorization.k8s.io
```
## Permisos del equipo de aplicaciones
Los equipos de aplicaciones necesitan permisos para crear instancias de recursos personalizados en sus espacios de nombres.
**Ejemplo de rol para equipos de aplicaciones**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-app-developer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["create", "get", "list", "update", "delete", "patch"]
```
**Enlace a miembros del equipo de aplicaciones**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-kro-developer
namespace: my-app
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: kro-app-developer
apiGroup: rbac.authorization.k8s.io
```
**nota**
El grupo de API del rol (`kro.run` en este ejemplo) debe coincidir con la `apiVersion` definida en el esquema de ResourceGraphDefinition.
## Acceso de solo lectura
Otorgue acceso de solo lectura para ver las ResourceGraphDefinitions e instancias sin permisos de modificación.
**ClusterRole de solo lectura**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-viewer
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["get", "list", "watch"]
```
**Rol de solo lectura para instancias**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: kro-instance-viewer
namespace: my-app
rules:
- apiGroups: ["kro.run"]
resources: ["webapps", "databases"]
verbs: ["get", "list", "watch"]
```
## Acceso a varios espacios de nombres
Otorgue a los equipos de aplicaciones acceso a varios espacios de nombres mediante ClusterRoles con RoleBindings.
**ClusterRole para el acceso a varios espacios de nombres**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: kro-multi-namespace-developer
rules:
- apiGroups: ["kro.run"]
resources: ["webapps"]
verbs: ["create", "get", "list", "update", "delete"]
```
**Enlace a espacios de nombres específicos**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-dev-access
namespace: development
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-team-staging-access
namespace: staging
subjects:
- kind: Group
name: app-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: kro-multi-namespace-developer
apiGroup: rbac.authorization.k8s.io
```
## Prácticas recomendadas
**Principio de privilegio mínimo**: otorgue solo los permisos mínimos necesarios para las responsabilidades de cada equipo.
**Uso de grupos en lugar de usuarios individuales**: enlace roles a grupos en lugar de usuarios individuales para facilitar la administración.
**Preocupaciones de aplicaciones y plataformas independientes**: los equipos de plataformas administran ResourceGraphDefinitions, mientras que los equipos de aplicaciones administran instancias.
**Aislamiento del espacio de nombres**: utilice los espacios de nombres para aislar diferentes equipos o entornos, con RBAC como control de acceso a cada espacio de nombres.
**Acceso de solo lectura para auditoría**: proporcione acceso de solo lectura a los equipos de seguridad y cumplimiento con fines de auditoría.
## Siguientes pasos
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
+ [Conceptos de kro](kro-concepts.md): descripción de SimpleSchema, las expresiones de CEL y los patrones de composición
+ [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md): revisión de las prácticas recomendadas de seguridad para capacidades
# Consideraciones sobre kro para EKS
En este tema, se tratan aspectos importantes al utilizar la capacidad de EKS para kro, lo que incluye cuándo se utilizan la composición de recursos, los patrones de RBAC y la integración con otras capacidades de EKS.
## Cuándo se utiliza kro
kro está diseñado para crear patrones de infraestructura reutilizables y API personalizadas que simplifiquen la administración de recursos complejos.
**Utilice kro cuando en los siguientes casos**:
+ Para la creación de plataformas de autoservicio con API simplificadas para los equipos de aplicaciones
+ Para la estandarización de los patrones de infraestructura en todos los equipos (base de datos \$1 copia de seguridad \$1 supervisión)
+ Para la administración de dependencias de los recursos y para la transferencia de valores entre recursos
+ Para la creación de abstracciones personalizadas que oculten la complejidad de la implementación
+ Para la composición de varios recursos de ACK en componentes de nivel superior
+ Para la activación de flujos de trabajo de GitOps para pilas de infraestructuras complejas
**No utilice kro en los siguientes casos**:
+ Para la administración de recursos simples e independientes (utilice directamente los recursos de ACK o Kubernetes)
+ Para cuando necesite una lógica dinámica en tiempo de ejecución (kro es declarativo, no imperativo)
+ Para cuando los recursos no tengan dependencias ni configuración compartida
kro destaca por crear “rutas pavimentadas”: patrones obstinados y reutilizables que facilitan a los equipos la implementación correcta de infraestructuras complejas.
## Patrones de RBAC
kro permite separar las preocupaciones entre los equipos de plataformas que crean ResourceGraphDefinitions y los equipos de aplicaciones que crean instancias.
### Responsabilidades del equipo de plataformas
Los equipos de plataformas crean y mantienen ResourceGraphDefinitions (RGD) que definen las API personalizadas.
**Permisos necesarios**:
+ Creación, actualización y eliminación de ResourceGraphDefinitions
+ Administración de los tipos de recursos subyacentes (implementaciones, servicios, recursos de ACK)
+ Acceso a todos los espacios de nombres en los que se utilizarán las RGD
**Ejemplo de ClusterRole para el equipo de plataformas**:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: platform-kro-admin
rules:
- apiGroups: ["kro.run"]
resources: ["resourcegraphdefinitions"]
verbs: ["*"]
- apiGroups: ["*"]
resources: ["*"]
verbs: ["get", "list", "watch"]
```
Para obtener una configuración de RBAC detallada, consulte [Configuración de permisos de kro](kro-permissions.md).
### Responsabilidades del equipo de aplicaciones
Los equipos de aplicaciones crean instancias de recursos personalizados definidas por las RGD sin necesidad de comprender la complejidad subyacente.
**Permisos necesarios**:
+ Creación, actualización y eliminación de instancias de recursos personalizados
+ Acceso de lectura a su espacio de nombres
+ Sin acceso a recursos subyacentes o las RGD
**Ventajas**:
+ Uso de API sencillas y de alto nivel por parte de los equipos
+ Control de los detalles de la implementación por parte de los equipos
+ Menor riesgo de errores de configuración
+ Incorporación más rápida de los nuevos miembros del equipo
## Integración con otras capacidades de EKS
### Composición de recursos de ACK
kro es particularmente eficaz cuando se combina con ACK para crear patrones de infraestructura.
**Patrones comunes**:
+ **Aplicación con almacenamiento**: bucket de S3 \$1 cola de SQS \$1 configuración de notificaciones
+ **Pila de base de datos**: instancia de RDS \$1 grupo de parámetros \$1 grupo de seguridad \$1 secreto de Secrets Manager
+ **Redes**: VPC \$1 subredes \$1 tablas de enrutamiento \$1 grupos de seguridad \$1 puertas de enlace de NAT
+ **Computación con almacenamiento**: instancia de EC2 \$1 volúmenes de EBS \$1 perfil de instancia de IAM
kro gestiona el orden de las dependencias, transfiere valores entre los recursos (como los ARN y las cadenas de conexión) y administra todo el ciclo de vida como una sola unidad.
Para ver ejemplos de composición de recursos de ACK, consulte [Conceptos de ACK](ack-concepts.md).
### GitOps con Argo CD
Utilice la capacidad de EKS para Argo CD para implementar tanto las RGD como las instancias de los repositorios de Git.
**Organización de repositorios**:
+ **Repositorio de plataformas**: contiene ResourceGraphDefinitions administradas por el equipo de plataformas
+ **Repositorios de aplicaciones**: contienen instancias de recursos personalizados administradas por los equipos de aplicaciones
+ **Repositorio compartido**: contiene tanto RGD como instancias para organizaciones más pequeñas
**Consideraciones**:
+ Implemente las RGD antes que las instancias (las ondas de sincronización de Argo CD pueden ayudarlo).
+ Utilice proyectos de Argo CD independientes para los equipos de plataformas y aplicaciones.
+ El equipo de plataformas controla el acceso al repositorio de RGD.
+ Los equipos de aplicaciones tienen acceso de solo lectura a las definiciones de RGD.
Para obtener más información sobre Argo CD, consulte [Uso de Argo CD](working-with-argocd.md).
## Organización de ResourceGraphDefinitions
Organice las RGD por propósito, complejidad y propiedad.
**Por propósito**:
+ **Infraestructura**: pilas de bases de datos, redes, almacenamiento
+ **Aplicación**: aplicaciones web, API, trabajos por lotes
+ **Plataforma**: servicios compartidos, supervisión, registro
**Por complejidad**:
+ **Sencilla**: de 2 a 3 recursos con dependencias mínimas
+ **Moderada**: de 5 a 10 recursos con algunas dependencias
+ **Compleja**: más de 10 recursos con dependencias complejas
**Convenciones de nomenclatura**:
+ Utilice nombres descriptivos: `webapp-with-database`, `s3-notification-queue`.
+ Incluya la versión en el nombre para los cambios bruscos: `webapp-v2`.
+ Utilice prefijos coherentes para las RGD relacionadas: `platform- `, `app-`
**Estrategia de espacio de nombres**:
+ Las RGD tienen un ámbito de clúster (no tienen espacios de nombres).
+ Las instancias tienen espacios de nombres.
+ Utilice selectores de espacios de nombres en las RGD para controlar dónde se pueden crear las instancias.
## Control de versiones y actualizaciones
Planifique la evolución de RGD y la migración de instancias.
**Actualizaciones de RGD**:
+ **Cambios no bruscos**: actualice la RGD (agregue campos opcionales y nuevos recursos con includeWhen).
+ **Cambios bruscos**: cree una nueva RGD con un nombre diferente (webapp-v2).
+ **Obsolescencia**: marque las RGD antiguos con anotaciones y comunique la programación de migración.
**Migración de instancias**:
+ Cree nuevas instancias con la RGD actualizada.
+ Valide que las nuevas instancias funcionen correctamente.
+ Elimine las instancias antiguas.
+ kro gestiona automáticamente las actualizaciones de los recursos subyacentes.
**Prácticas recomendadas**:
+ Pruebe antes los cambios de RGD en entornos que no sean de producción.
+ Utilice el control de versiones semántico en los nombres de RGD para cambios importantes.
+ Documente los cambios bruscos y las rutas de migración.
+ Proporcione ejemplos de migración para los equipos de aplicaciones.
## Validación y pruebas
Valide las RGD antes de implementarlas en producción.
**Estrategias de validación**:
+ **Validación de esquema**: kro valida la estructura de RGD automáticamente.
+ **Instancias de prueba**: cree instancias de prueba en los espacios de nombres de desarrollo.
+ **Pruebas de integración**: compruebe que los recursos compuestos funcionen juntos
+ **Aplicación de políticas**: utilice controladores de admisión para hacer cumplir los estándares organizativos
**Problemas comunes que se deben probar**:
+ Dependencias y orden de los recursos
+ Transferencia de valores entre recursos (expresiones de CEL)
+ Inclusión condicional de recursos (includeWhen)
+ Propagación del estado a partir de los recursos subyacentes
+ Permisos de RBAC para la creación de instancias
## Documentación ascendente
Para obtener información detallada sobre el uso de kro:
+ [Introducción a kro](https://kro.run/docs/guides/getting-started): creación de ResourceGraphDefinitions
+ [Expresiones de CEL](https://kro.run/docs/concepts/cel): escritura de expresiones de CEL
+ [Guías de kro](https://kro.run/docs/guides/): patrones de composición avanzados
+ [Solución de problemas](https://kro.run/docs/troubleshooting): solución de problemas y depuración
## Siguientes pasos
+ [Configuración de permisos de kro](kro-permissions.md): configuración del RBAC para los equipos de plataformas y aplicaciones
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y el ciclo de vida de los recursos
+ [Solución de problemas con capacidades de kro](kro-troubleshooting.md): solución de problemas de kro
+ [Conceptos de ACK](ack-concepts.md): más información sobre los recursos de ACK para la composición
+ [Uso de Argo CD](working-with-argocd.md): implementación de instancias y RGD con GitOps
# Solución de problemas con capacidades de kro
En este tema, se proporcionan instrucciones para la solución de problemas de la capacidad de EKS para kro, como las comprobaciones de estado de la capacidad, los permisos de RBAC, los errores de expresión de CEL y los problemas de composición de los recursos.
**nota**
Las capacidades de EKS son completamente administradas y se ejecutan fuera del clúster. No tiene acceso a los registros del controlador ni al espacio de nombres `kro-system`. La solución de problemas se centra en el estado de la capacidad, la configuración de RBAC y el estado de los recursos.
## La capacidad está ACTIVA, pero ResourceGraphDefinitions no funciona
Si la capacidad de kro muestra el estado `ACTIVE`, pero ResourceGraphDefinitions no crea recursos subyacentes, compruebe el estado de la capacidad, los permisos de RBAC y el estado de los recursos.
**Compruebe el estado de la capacidad**:
Puede ver los problemas de estado de la capacidad en la consola de EKS o mediante la AWS CLI.
**Consola**:
1. Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home\$1/clusters.
1. Seleccione el nombre del clúster.
1. Seleccione la pestaña **Observabilidad**.
1. Elija **Supervisar clúster**.
1. Seleccione la pestaña **Capacidades** para ver el estado de todas las capacidades.
** AWS CLI**:
```
# View capability status and health
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-kro
# Look for issues in the health section
```
**Causas habituales**:
+ **Faltan los permisos de RBAC**: kro no tiene permisos para crear los recursos subyacentes de Kubernetes
+ **Expresiones de CEL no válidas**: errores de sintaxis en ResourceGraphDefinition
+ **Dependencias de recursos**: los recursos dependientes no están listos
+ **Validación del esquema**: la instancia no cumple con los requisitos del esquema de RGD
**Compruebe los permisos de RBAC**:
```
# Check if capability has cluster admin policy
kubectl get accessentry -A | grep kro
```
Si la capacidad no tiene los permisos necesarios, asocie la `AmazonEKSClusterAdminPolicy` a la entrada de acceso de la capacidad de kro o cree políticas de RBAC más restrictivas para su uso en producción. Para obtener más información, consulte [Configuración de permisos de kro](kro-permissions.md).
**Compruebe el estado de ResourceGraphDefinition**:
```
# List all RGDs
kubectl get resourcegraphdefinition
# Describe specific RGD
kubectl describe resourcegraphdefinition my-rgd
# Check for validation errors
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions}'
```
Las ResourceGraphDefinitions tienen tres condiciones de estado clave:
+ `ResourceGraphAccepted`: si la RGD ha superado la validación (sintaxis de CEL, comprobación de tipos, existencia de campos)
+ `KindReady`: si la CRD de la API personalizada se generó y registró
+ `ControllerReady`: si kro está supervisando activamente las instancias de la API personalizada
Si `ResourceGraphAccepted` es `False`, compruebe el mensaje de la condición para ver si hay errores de validación, como campos desconocidos, discrepancias de tipos o dependencias circulares.
## Se crearon las instancias, pero los recursos subyacentes no aparecen
Si existen instancias de recursos personalizadas, pero no se crean los recursos de Kubernetes subyacentes (implementaciones, servicios, ConfigMaps), compruebe que kro tenga permisos y si hay errores de composición.
**Compruebe el estado de la instancia**:
```
# Describe the instance (replace with your custom resource kind and name)
kubectl describe custom-kind
my-instance
# View instance events
kubectl get events --field-selector involvedObject.name=my-instance
# Check instance status conditions
kubectl get custom-kind
my-instance -o jsonpath='{.status.conditions}'
# Check instance state
kubectl get custom-kind
my-instance -o jsonpath='{.status.state}'
```
Las instancias tienen un campo `state` que muestra el estado de alto nivel:
+ `ACTIVE`: la instancia se está ejecutando correctamente.
+ `IN_PROGRESS`: la instancia se está procesando o conciliando.
+ `FAILED`: no se pudo conciliar la instancia.
+ `DELETING`: la instancia se está eliminando.
+ `ERROR`: se ha producido un error durante el procesamiento.
Las instancias también tienen cuatro condiciones de estado:
+ `InstanceManaged`: los finalizadores y las etiquetas están configurados correctamente.
+ `GraphResolved`: se creó un gráfico de tiempo de ejecución y se resolvieron los recursos.
+ `ResourcesReady`: todos los recursos están creados y listos.
+ `Ready`: estado general de la instancia (solo pasa a `True` cuando todas las subcondiciones son `True`).
Céntrese en la condición `Ready` para determinar el estado de la instancia. Si `Ready` es `False`, compruebe las subcondiciones para identificar en qué fase se ha producido el error.
**Compruebe los permisos de RBAC**:
La capacidad de kro necesita permisos para crear los recursos de Kubernetes subyacentes definidos en las ResourceGraphDefinitions.
```
# Check if the capability has the AmazonEKSClusterAdminPolicy
kubectl get accessentry -A | grep kro
```
Si faltan los permisos, asocie la `AmazonEKSClusterAdminPolicy` a la entrada de acceso de la capacidad de kro o cree políticas de RBAC más restrictivas para su uso en producción. Para obtener más información, consulte [Configuración de permisos de kro](kro-permissions.md).
## Errores de expresión de CEL
Los errores de expresión de CEL se detectan en el momento de la creación de ResourceGraphDefinition, no cuando se crean las instancias. kro valida toda la sintaxis de CEL, compara las expresiones con los esquemas de Kubernetes y verifica la existencia de los campos al crear la RGD.
**Errores comunes de validación de CEL**:
+ **Referencia de campo no definida**: se hace referencia a un campo que no existe en el esquema o el recurso.
+ **Discrepancia de tipos**: la expresión devuelve un tipo incorrecto (por ejemplo, una cadena cuando se espera un número entero).
+ **Sintaxis no válida**: faltan corchetes, comillas u operadores en la expresión de CEL.
+ **Tipo de recurso desconocido**: se hace referencia a una CRD que no existe en el clúster.
**Compruebe el estado de validación de la RGD**:
```
# Check if RGD was accepted
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.conditions[?(@.type=="ResourceGraphAccepted")]}'
# View detailed validation errors
kubectl describe resourcegraphdefinition my-rgd
```
Si `ResourceGraphAccepted` es `False`, el mensaje de condición contiene el error de validación.
**Ejemplos de expresiones de CEL válidas**:
```
# Reference schema field
${schema.spec.appName}
# Conditional expression
${schema.spec.replicas > 1}
# String template (expressions must return strings)
name: "${schema.spec.appName}-service"
# Standalone expression (can be any type)
replicas: ${schema.spec.replicaCount}
# Resource reference
${deployment.status.availableReplicas}
# Optional field access (returns null if field doesn't exist)
${configmap.data.?DATABASE_URL}
```
## No se resuelven las dependencias de los recursos
kro infiere automáticamente las dependencias a partir de expresiones de CEL y crea los recursos en el orden correcto. Si los recursos no se crean según lo previsto, compruebe el orden de dependencia y la disponibilidad de los recursos.
**Consulte el orden de creación de computación**:
```
# See the order kro will create resources
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.status.topologicalOrder}'
```
Se muestra el orden de computación en función de las referencias de expresiones de CEL entre los recursos.
**Compruebe la preparación de los recursos**:
```
# View instance status to see which resources are ready
kubectl get custom-kind
my-instance -o jsonpath='{.status}'
# Check specific resource status
kubectl get deployment my-deployment -o jsonpath='{.status.conditions}'
```
**Compruebe las condiciones readyWhen (si se utilizan)**:
El campo `readyWhen` es opcional. Si no se especifica, los recursos se consideran listos inmediatamente después de su creación. Si ha definido las condiciones `readyWhen`, verifique que comprueben correctamente si los recursos están listos:
```
resources:
- id: deployment
readyWhen:
- ${deployment.status.availableReplicas == deployment.spec.replicas}
```
**Compruebe los eventos de los recursos**:
```
# View events for the underlying resources
kubectl get events -n namespace --sort-by='.lastTimestamp'
```
## Errores de validación del esquema
Si las instancias no se crean debido a errores de validación del esquema, compruebe que la instancia cumpla con los requisitos del esquema de RGD.
**Compruebe los errores de validación**:
```
# Attempt to create instance and view error
kubectl apply -f instance.yaml
# View existing instance validation status
kubectl describe custom-kind
my-instance | grep -A 5 "Validation"
```
**Problemas de validación comunes**:
+ **Faltan campos obligatorios**: la instancia no proporciona todos los campos del esquema obligatorios.
+ **Discrepancia de tipos**: se proporciona una cadena cuando se espera un entero.
+ **Valor de enumeración no válido**: se utiliza un valor que no está en la lista de permitidos.
+ **Discrepancia de patrones**: la cadena no coincide con el patrón de expresión regular.
**Revise el esquema de RGD**:
```
# View the schema definition
kubectl get resourcegraphdefinition my-rgd -o jsonpath='{.spec.schema}'
```
Asegúrese de que la instancia proporcione todos los campos obligatorios con los tipos correctos.
## Siguientes pasos
+ [Consideraciones sobre kro para EKS](kro-considerations.md): consideraciones y prácticas recomendadas de kro
+ [Configuración de permisos de kro](kro-permissions.md): configuración del RBAC para los equipos de plataformas y aplicaciones
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y el ciclo de vida de los recursos
+ [Solución de problemas de capacidades de EKS](capabilities-troubleshooting.md): orientación general de solución de problemas de la capacidad
# Comparación de la capacidad de EKS para kro con kro autoadministrado
La capacidad de EKS para kro proporciona la misma funcionalidad que kro autoadministrado, pero con importantes ventajas operativas. Para obtener una comparación general entre las capacidades de EKS y las soluciones autoadministradas, consulte [Consideraciones sobre las capacidades de EKS](capabilities-considerations.md).
La capacidad de EKS para kro utiliza los mismos controladores de kro ascendentes y es totalmente compatible con kro ascendente. Las ResourceGraphDefinitions, las expresiones de CEL y la composición de recursos funcionan de la misma forma. [Para ver la documentación completa de kro y ejemplos, consulte la documentación de kro.](https://kro.run/docs/overview)
## Ruta de migración
Puede migrar de kro autoadministrado a la capacidad administrada sin tiempo de inactividad.
**importante**
Antes de migrar, asegúrese de que el controlador de kro autoadministrado ejecute la misma versión que la capacidad de EKS para kro. Compruebe la versión de la capacidad en la consola de EKS o mediante `aws eks describe-capability` y, a continuación, actualice la instalación autoadministrada para que coincida. De este modo, se evitan problemas de compatibilidad durante la migración.
1. Actualice el controlador de kro autoadministrado para utilizar `kube-system` en las asignaciones de elección de líderes:
```
helm upgrade --install kro \
oci://ghcr.io/awslabs/kro/kro-chart \
--namespace kro \
--set leaderElection.namespace=kube-system
```
De este modo, se traslada la asignación del controlador a `kube-system`, lo que permite que la capacidad administrada se coordine con él.
1. Cree la capacidad de kro en el clúster (consulte [Creación de una capacidad de kro](create-kro-capability.md)).
1. La capacidad administrada reconoce las ResourceGraphDefinitions e instancias y se encarga de la conciliación.
1. Reduzca verticalmente o elimine de forma gradual las implementaciones de kro autoadministrado:
```
helm uninstall kro --namespace kro
```
Este enfoque permite que ambos controladores coexistan de forma segura durante la migración. La capacidad administrada adopta automáticamente las ResourceGraphDefinitions e instancias que antes administraba kro autoadministrado, lo que garantiza una conciliación continua sin conflictos.
## Siguientes pasos
+ [Creación de una capacidad de kro](create-kro-capability.md): creación de un recurso con la capacidad de kro
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos