**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.
# Capacidades de EKS
**sugerencia**
Introducción: [Creación de una capacidad de ACK](create-ack-capability.md) \$1 [Creación de una capacidad de Argo CD](create-argocd-capability.md) \$1 [Creación de una capacidad de kro](create-kro-capability.md)
Las capacidades de Amazon EKS son un conjunto en capas de características de clúster completamente administradas que ayudan a acelerar la velocidad de los desarrolladores y reducir la complejidad de la creación y el escalado con Kubernetes. Las capacidades de EKS son características nativas de Kubernetes para la implementación continua declarativa, la administración de recursos de AWS y la creación y orquestación de recursos de Kubernetes, todo ello completamente administrado por AWS. Con las capacidades de EKS, puede centrarse más en crear y escalar sus cargas de trabajo, lo que lo libera de la carga operativa que suponen estos servicios fundamentales de la plataforma y que asumirá AWS. Estas capacidades se ejecutan dentro de EKS y no en los clústeres, lo que elimina la necesidad de instalar, mantener y escalar los componentes críticos de la plataforma en los nodos de trabajo.
Para comenzar, puede crear una o más capacidades de EKS en un clúster de EKS nuevo o existente. Para ello, puede utilizar la AWS CLI, la Consola de administración de AWS, las API de EKS, eksctl o las herramientas de infraestructura como código que prefiera. Si bien las capacidades de EKS están diseñadas para funcionar en conjunto, son recursos de nube independientes que puede elegir en función de su caso de uso y sus requisitos.
Todas las versiones de Kubernetes compatibles con EKS son compatibles con las capacidades de EKS.
**nota**
Las capacidades de EKS están disponibles en todas las regiones comerciales de AWS en las que Amazon EKS esté disponible. Para ver una lista de las regiones admitidas, consulte [Puntos de conexión y cuotas de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) en la referencia general de AWS.
## Capacidades disponibles
### Controladores para Kubernetes (ACK) de AWS
ACK permite administrar los recursos de AWS mediante las API de Kubernetes, lo que le permite crear y administrar buckets de S3, bases de datos de RDS, roles de IAM y otros recursos de AWS mediante los recursos personalizados de Kubernetes. ACK concilia continuamente el estado deseado con el estado real en AWS, lo que corrige cualquier desviación a lo largo del tiempo para mantener el sistema en buen estado y los recursos configurados según lo especificado. Puede administrar los recursos de AWS junto con sus cargas de trabajo de Kubernetes con las mismas herramientas y flujos de trabajo, con soporte para más de 50 servicios de AWS, como S3, RDS, DynamoDB y Lambda. ACK admite la administración de recursos entre cuentas y regiones, lo que permite arquitecturas complejas de administración de sistemas de varias cuentas y varios clústeres. ACK admite recursos de solo lectura y adopción de solo lectura, lo que facilita la migración de otras herramientas de infraestructura como código a sus sistemas basados en Kubernetes.
[Más información sobre ACK →](ack.md)
### Argo CD
Argo CD implementa la implementación continua basado en GitOps para sus aplicaciones, con los repositorios de Git como origen de información verdadera para sus cargas de trabajo y el estado del sistema. Argo CD sincroniza automáticamente los recursos de las aplicaciones con sus clústeres desde los repositorios de Git mediante la detección y la corrección de las desviaciones para garantizar que las aplicaciones implementadas coincidan con el estado deseado. Puede implementar y administrar aplicaciones en varios clústeres desde una sola instancia de Argo CD, con una implementación automatizada desde los repositorios de Git siempre que se hagan cambios. El uso conjunto de Argo CD y ACK proporciona un sistema de GitOps fundamental, que simplifica la administración de las dependencias de la carga de trabajo y permite diseñar todo el sistema, lo que incluye la administración de clústeres e infraestructuras a escala. Argo CD se integra con AWS Identity Center para la autenticación y la autorización, y proporciona una interfaz de usuario de Argo alojada para visualizar el estado de la aplicación y de implementación.
[Más información sobre Argo CD →](argocd.md)
### kro (Kube Resource Orchestrator)
kro le permite crear API de Kubernetes personalizadas que agrupan varios recursos en abstracciones de nivel superior, lo que permite a los equipos de plataformas definir patrones reutilizables para componentes de la nube de combinaciones de recursos comunes. Con kro, puede agrupar recursos de AWS y Kubernetes en abstracciones unificadas mediante una sintaxis simple para permitir configuraciones dinámicas y lógica condicional. kro permite a los equipos de plataformas proporcionar capacidades de autoservicio con las barreras de protección adecuadas, lo que permite a los desarrolladores aprovisionar infraestructuras complejas mediante API simples y personalizadas mientras cumplen con los estándares organizativos y las prácticas recomendadas. Los recursos de kro son simplemente recursos de Kubernetes y se especifica en los manifiestos de Kubernetes cuáles se pueden almacenar en Git o insertar en registros compatibles con OCI como Amazon ECR para una amplia distribución organizativa.
[Más información sobre kro →](kro.md)
## Ventajas de las capacidades de EKS
AWS administra completamente las capacidades de EKS, lo que elimina la necesidad de instalar, mantener y escalar los servicios de clúster fundamentales. AWS gestiona los parches de seguridad, las actualizaciones y la administración operativa, lo que permite a sus equipos centrarse en crear con AWS en lugar de operaciones del clúster. A diferencia de los complementos tradicionales de Kubernetes que consumen recursos del clúster, las capacidades se ejecutan en EKS y no en los nodos de trabajo. De este modo, se liberan recursos del clúster y capacidad para las cargas de trabajo y, al mismo tiempo, se minimiza la carga operativa que supone administrar los controladores integrados en el clúster y otros componentes de la plataforma.
Con las capacidades de EKS, puede administrar las implementaciones, los recursos de AWS, los recursos personalizados de Kubernetes y las composiciones mediante herramientas y API de Kubernetes nativas, como `kubectl`. Todas las capacidades operan en el contexto de sus clústeres, lo que hace que se detecten y se corrijan automáticamente las desviaciones de configuración en los recursos de la infraestructura en la nube y de las aplicaciones. Puede implementar y administrar los recursos en varios clústeres, cuentas de AWS y regiones desde un único punto de control, lo que simplifica las operaciones en entornos complejos y distribuidos.
Las capacidades de EKS están diseñadas para los flujos de trabajo de GitOps, lo que proporciona una administración de aplicaciones e infraestructuras declarativa y controlada por versiones. Los cambios fluyen desde Git a través del sistema y proporcionan registros de auditoría, capacidades de reversión y flujos de trabajo de colaboración que se integran con las prácticas de desarrollo existentes. Gracias a este enfoque nativo de Kubernetes, no es necesario utilizar varias herramientas ni administrar sistemas de infraestructura como código externos a los clústeres y, además, hay un único origen de información verdadera al que acudir. El estado deseado, definido en la configuración declarativa de Kubernetes con control de versiones, se aplica continuamente en todo el entorno.
## Precios
Con las capacidades de EKS, no hay cuotas de pago iniciales ni compromisos. Se le cobrará por cada hora que esté activo cada recurso de capacidad en su clúster de Amazon EKS. Los recursos específicos de Kubernetes administrados por las capacidades de EKS también se facturan con una tarifa por hora.
Para obtener información actual acerca de los precios, consulte la [página de precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).
**sugerencia**
Puede usar el Informe de costos y usos y el Explorador de costos de AWS para hacer un seguimiento de los costos de la capacidad por separado en relación con otros cargos de EKS. Puede etiquetar las capacidades con el nombre del clúster, el tipo de capacidad y otros detalles para poder asignar los costos.
## Cómo funcionan las capacidades de EKS
Cada capacidad es un recurso de AWS que se crea en el clúster de EKS. Una vez creada, la capacidad se ejecuta en EKS y AWS la administra completamente.
**nota**
Puede crear un recurso de capacidad de cada tipo (Argo CD, ACK y kro) para un clúster determinado. No puede crear varios recursos de capacidad del mismo tipo en el mismo clúster.
Interactuará con las capacidades del clúster mediante las API y herramientas estándar de Kubernetes:
+ Utilice `kubectl` para aplicar los recursos personalizados de Kubernetes.
+ Utilice los repositorios de Git como origen de información verdadera para los flujos de trabajo de GitOps.
Algunas capacidades incluyen herramientas adicionales compatibles. Por ejemplo:
+ Utilice la CLI de Argo CD para configurar y administrar repositorios y clústeres en la capacidad de Argo CD.
+ Utilice la interfaz de usuario de Argo CD para ver y administrar las aplicaciones administradas por la capacidad de Argo CD.
Las capacidades están diseñadas para funcionar en conjunto, pero son independientes y completamente opcionales. Puede habilitar una, dos o las tres capacidades en función de sus necesidades y actualizar la configuración a medida que evolucionen sus requisitos.
Se admiten todos los tipos de computación de EKS para su uso con las capacidades de EKS. Para obtener más información, consulte [Administración de los recursos de computación mediante nodos](eks-compute.md).
Para obtener información sobre la configuración de seguridad y los detalles sobre los roles de IAM, consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md). Para conocer los patrones de arquitectura de varios clústeres, consulte [Consideraciones sobre las capacidades de EKS](capabilities-considerations.md)-
## Casos de uso común
**GitOps para aplicaciones e infraestructura**
Use Argo CD para implementar aplicaciones y componentes operativos y ACK para administrar las configuraciones de los clústeres y aprovisionar la infraestructura, ambos desde los repositorios de Git. Toda la pila (aplicaciones, bases de datos, almacenamiento y redes) se define como código y se implementa automáticamente.
Ejemplo: un equipo de desarrollo hace cambios en Git. Argo CD implementa la aplicación actualizada y ACK aprovisiona una nueva base de datos de RDS con la configuración correcta. Todos los cambios son auditables, reversibles y coherentes en todos los entornos.
**Ingeniería de plataformas con autoservicio**
Utilice kro para crear API personalizadas que compongan los recursos de ACK y Kubernetes. Los equipos de plataformas definen los patrones aprobados con barreras de protección. Los equipos de aplicaciones utilizan API sencillas y de alto nivel para aprovisionar pilas completas.
Ejemplo: un equipo de plataformas crea una API “WebApplication” que aprovisiona una implementación, un servicio, una entrada y un bucket de S3. Los desarrolladores utilizan esta API sin necesidad de comprender la complejidad subyacente ni los permisos de AWS.
**Administración de aplicaciones de varios clústeres**
Utilice Argo CD para implementar aplicaciones en varios clústeres de EKS en diferentes regiones o cuentas. Administre todas las implementaciones desde una única instancia de Argo CD con políticas y flujos de trabajo coherentes.
Ejemplo: implemente la misma aplicación en clústeres de desarrollo, almacenamiento y producción en varias regiones. Argo CD garantiza que cada entorno se mantenga sincronizado con su rama de Git correspondiente.
**Administración de varios clústeres**
Utilice ACK para definir y aprovisionar los clústeres de EKS, kro para personalizar las configuraciones de los clústeres con los estándares organizativos y Argo CD para administrar el ciclo de vida y la configuración de los clústeres. De este modo, se proporciona una administración integral de los clústeres, desde su creación hasta las operaciones continuas.
Ejemplo: defina los clústeres de EKS mediante ACK y kro para aprovisionar y aprovisionar la infraestructura de los clústeres, lo que define los estándares organizativos para las redes, las políticas de seguridad, los complementos y otras configuraciones. Utilice Argo CD para crear y administrar de forma continua los clústeres, la configuración y las actualizaciones de las versiones de Kubernetes en toda su flota, de modo que aproveche los estándares uniformes y la administración automatizada del ciclo de vida.
**Migraciones y modernización**
Simplifique la migración a EKS con el aprovisionamiento nativo de recursos en la nube y los flujos de trabajo de GitOps. Utilice ACK para adoptar los recursos de AWS existentes sin volver a crearlos y Argo CD para poner en marcha las implementaciones de cargas de trabajo desde Git.
Ejemplo: un equipo que migra de EC2 a EKS adopta sus bases de datos de RDS y buckets de S3 existentes mediante ACK y, a continuación, utiliza Argo CD para implementar aplicaciones en contenedores desde Git. La ruta de migración es clara y las operaciones se estandarizan desde el primer día.
**Arranque de cuentas y regiones**
Automatice la implementación de la infraestructura en todas las cuentas y regiones con Argo CD y ACK a la vez. Defina su infraestructura como código en Git y deje que las capacidades se ocupen de la implementación y la administración.
Ejemplo: un equipo de plataformas mantiene los repositorios de Git que definen las configuraciones de cuentas estándar: VPC, roles de IAM, instancias de RDS y pilas de supervisión. Argo CD implementa estas configuraciones automáticamente en nuevas cuentas y regiones, lo que garantiza la coherencia y reduce el tiempo de configuración manual de días a minutos.
# Uso de recursos de capacidades
En este tema, se describen las operaciones comunes para administrar los recursos de capacidades en todos los tipos de capacidades.
## Recursos de capacidades de EKS
Las capacidades de EKS son recursos de AWS que permiten la funcionalidad administrada de su clúster de Amazon EKS. Las capacidades se ejecutan en EKS, lo que elimina la necesidad de instalar y mantener controladores y otros componentes operativos en los nodos de trabajo. Las capacidades se crean para un clúster de EKS específico y permanecen asociadas a ese clúster durante todo su ciclo de vida.
Cada recurso de capacidad tiene lo siguiente:
+ Un nombre único dentro de su clúster
+ Un tipo de capacidad (ACK, ARGOCD o KRO)
+ Un nombre de recurso de Amazon (ARN), que especifica tanto el nombre como el tipo
+ Un rol de IAM de capacidad
+ Un estado que indica su estado actual
+ Configuración, tanto genérica como específica del tipo de capacidad
## Descripción de los estados de las capacidades
Los recursos de las capacidades tienen un estado que indica su estado actual. Puede ver el 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 **Capacidades** para ver el estado de todas las capacidades.
1. Para obtener información detallada sobre el estado, seleccione la pestaña **Observabilidad**, luego **Supervisar clúster** y, por último, la pestaña **Capacidades**.
** AWS CLI**:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-capability-name
```
### Estados de las capacidades
**CREANDO**: Se está configurando la capacidad. Puede salir de la consola, ya que la capacidad se continuará creando en segundo plano.
**ACTIVA**: la capacidad está en ejecución y lista para usarse. Si los recursos no funcionan según lo esperado, compruebe el estado de los recursos y los permisos de IAM. Para obtener orientación, consulte [Solución de problemas de capacidades de EKS](capabilities-troubleshooting.md).
**ACTUALIZANDO**: se están aplicando cambios en la configuración. Espere a que el estado vuelva a ser `ACTIVE`.
**ELIMINANDO**: se está eliminando la capacidad del clúster.
**CREATE\$1FAILED**: la configuración detectó un error. Entre las causas comunes, se incluyen las siguientes:
+ Falta la política de confianza del rol de IAM o no se encuentra
+ El rol de IAM no existe o no se puede acceder a él
+ Problemas de acceso al clúster
+ Parámetros de configuración no válidos
Consulte la sección de estado de la capacidad para obtener detalles específicos sobre los errores.
**UPDATE\$1FAILED**: no se pudo actualizar la configuración. Consulte la sección de estado de la capacidad para obtener más información y compruebe los permisos de IAM.
**sugerencia**
Para obtener ayuda sobre la solución de problemas, consulte:
[Solución de problemas de capacidades de EKS](capabilities-troubleshooting.md): solución de problemas general de la capacidad
[Solución de problemas con capacidades de ACK](ack-troubleshooting.md): problemas específicos de ACK
[Solución de problemas con capacidades de Argo CD](argocd-troubleshooting.md): problemas específicos de Argo CD
[Solución de problemas con capacidades de kro](kro-troubleshooting.md): problemas específicos de kro
## Creación de capacidades
Para crear una capacidad en el clúster, consulte los temas siguientes:
+ [Creación de una capacidad de ACK](create-ack-capability.md): creación de una capacidad de ACK para administrar los recursos de AWS mediante las API de Kubernetes
+ [Creación de una capacidad de Argo CD](create-argocd-capability.md): creación de una capacidad de Argo CD para la entrega continua de GitOps
+ [Creación de una capacidad de kro](create-kro-capability.md): creación de una capacidad de kro para la composición y orquestación de los recursos
## Enumeración de capacidades
Puede enumerar todos los recursos de capacidades de un clúster.
### 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 para abrir la página de detalles del clúster.
1. Elija la pestaña **Capacidades**.
1. Consulte los recursos de capacidades en **Capacidades administradas**.
### AWS CLI
Use el comando `list-capabilities` para ver todas las capacidades del clúster. 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 list-capabilities \
--region region-code \
--cluster-name my-cluster
```
```
{
"capabilities": [
{
"capabilityName": "my-ack",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"type": "ACK",
"status": "ACTIVE",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-kro",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/kro/my-kro/abc123",
"type": "KRO",
"status": "ACTIVE",
"version": "v0.6.3",
"createdAt": "2025-11-02T10:30:00.000000-07:00",
"modifiedAt": "2025-11-02T10:32:15.000000-07:00",
},
{
"capabilityName": "my-argocd",
"arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/argocd/my-argocd/abc123",
"type": "ARGOCD",
"status": "ACTIVE",
"version": "3.1.8-eks-1",
"createdAt": "2025-11-21T08:22:28.486000-05:00",
"modifiedAt": "2025-11-21T08:22:28.486000-05:00"
}
]
}
```
## Descripción de una capacidad
Obtenga información detallada sobre una capacidad específica, lo que incluye su configuración y estado.
### 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 para abrir la página de detalles del clúster.
1. Elija la pestaña **Capacidades**.
1. Elija la capacidad que desee ver en **Capacidades administradas**.
1. Vea los detalles de la capacidad, lo que incluye el estado, la configuración y la hora de creación.
### AWS CLI
Utilice el comando `describe-capability` para ver información detallada. Sustituya *region-code* por la región de AWS en la que se encuentra el clúster, *my-cluster* por el nombre del clúster y *capability-name* por el nombre de la capacidad (ack, argocd o kro).
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
**Ejemplo de código de salida:**
```
{
"capability": {
"capabilityName": "my-ack",
"capabilityArn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack/abc123",
"clusterName": "my-cluster",
"type": "ACK",
"roleArn": "arn:aws:iam::111122223333:role/AmazonEKSCapabilityACKRole",
"status": "ACTIVE",
"configuration": {},
"tags": {},
"health": {
"issues": []
},
"createdAt": "2025-11-19T17:11:30.242000-05:00",
"modifiedAt": "2025-11-19T17:11:30.242000-05:00",
"deletePropagationPolicy": "RETAIN"
}
}
```
## Actualización de la configuración de una capacidad
Puede actualizar ciertos aspectos de la configuración de una capacidad después de su creación. Las opciones de configuración específicas varían según el tipo de capacidad.
**nota**
Los recursos de capacidades de EKS se administran completamente, lo que incluye las actualizaciones de versiones y los parches. Al actualizar una capacidad, se actualizará la configuración de los recursos y no se actualizarán las versiones de los componentes de la capacidad administrada.
### AWS CLI
Utilice el comando `update-capability` para modificar una capacidad:
```
aws eks update-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name \
--role-arn arn:aws:iam::[.replaceable]111122223333:role/NewCapabilityRole
```
**nota**
No todas las propiedades de capacidades se pueden actualizar después de su creación. Consulte la documentación específica de la capacidad para obtener detalles sobre lo que se puede modificar.
## Eliminación de una capacidad
Cuando ya no necesite una capacidad del clúster, puede eliminar el recurso de la capacidad.
**importante**
**Elimine los recursos del clúster antes de eliminar la capacidad.**
La eliminación de un recurso de la capacidad no elimina automáticamente los recursos creados a través de esa capacidad:
Todas las definiciones de recursos personalizados (CRD) de Kubernetes permanecen instaladas en el clúster.
Los recursos de ACK permanecen en el clúster, mientras que los recursos de AWS correspondientes permanecen en la cuenta.
Las aplicaciones de Argo CD y sus recursos de Kubernetes permanecen en el clúster.
Las instancias y ResourceGraphDefinitions de kro permanecen en el clúster.
Debe eliminar estos recursos antes de eliminar la capacidad para evitar recursos huérfanos.
Si lo desea, puede optar por retener los recursos de AWS asociados a los recursos de Kubernetes de ACK. Consulte [Consideraciones sobre ACK](ack-considerations.md).
### 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 para abrir la página de detalles del clúster.
1. Elija la pestaña **Capacidades**.
1. Seleccione en la lista **Capacidades administradas** la capacidad que desea eliminar.
1. Elija **Eliminar capacidad**.
1. En el cuadro de diálogo de confirmación, ingrese el nombre de la capacidad para confirmar la eliminación.
1. Elija **Eliminar**.
### AWS CLI
Utilice el comando `delete-capability` para eliminar un recurso de la capacidad:
Sustituya *region-code* por la región de AWS en la que se encuentra el clúster, *my-cluster* por el nombre del clúster y *capability-name* por el nombre de la capacidad que desea eliminar.
```
aws eks delete-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name capability-name
```
## Siguientes pasos
+ [Recursos de Kubernetes de las capacidades](capability-kubernetes-resources.md): más información sobre los recursos de Kubernetes que proporciona cada tipo de capacidad
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK y el ciclo de vida de los recursos
+ [Uso de Argo CD](working-with-argocd.md): uso de las capacidades de Argo CD para flujos de trabajo de GitOps
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
# Recursos de Kubernetes de las capacidades
Una vez que active una capacidad en el clúster, por lo general, interactuará con ella mediante la creación y administración de los recursos personalizados de Kubernetes en el clúster. Cada capacidad proporciona su propio conjunto de definiciones de recursos personalizados (CRD) que amplían la API de Kubernetes con funcionalidades específicas de cada capacidad.
## Recursos de Argo CD
Al activar la capacidad de Argo CD, puede crear y administrar los siguientes recursos de Kubernetes:
**Aplicación**
Define una implementación desde un repositorio de Git a un clúster de destino. Los recursos de `Application` especifican el repositorio de origen, el espacio de nombres de destino y la política de sincronización. Puede crear hasta 1000 recursos de `Application` por instancia de capacidad de Argo CD.
**ApplicationSet**
Genera varios recursos de `Application` a partir de plantillas, lo que permite implementaciones en varios clústeres y entornos. Los recursos de `ApplicationSet` utilizan generadores para crear recursos de `Application` de forma dinámica en función de listas de clústeres, directorios de Git u otros orígenes.
**AppProject**
Proporciona agrupamiento lógico y control de acceso a los recursos de `Application`. Los recursos de `AppProject` definen qué repositorios, clústeres y espacios de nombres pueden usar los recursos de `Application`, lo que permite establecer límites de seguridad y de tenencia múltiple.
Ejemplo de recurso de `Application`:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/repo
targetRevision: main
path: manifests
destination:
server: https://kubernetes.default.svc
namespace: production
```
Para obtener más información sobre los conceptos y recursos de Argo CD, consulte [Conceptos de Argo CD](argocd-concepts.md).
## Recursos de kro
Al activar la capacidad de kro, puede crear y administrar los siguientes recursos de Kubernetes:
**ResourceGraphDefinition (RGD)**
Define una API personalizada que compone varios Kubernetes y recursos de AWS en una abstracción de nivel superior. Los equipos de plataformas crean recursos de `ResourceGraphDefinition` para proporcionar patrones reutilizables con barreras de protección.
**Instancias de recursos personalizados**
Tras crear un recurso de `ResourceGraphDefinition`, puede crear instancias de la API personalizada definida por la `ResourceGraphDefinition`. kro crea y administra automáticamente los recursos especificados en la `ResourceGraphDefinition`.
Ejemplo de recurso de `ResourceGraphDefinition`:
```
apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
name: web-application
spec:
schema:
apiVersion: v1alpha1
kind: WebApplication
spec:
name: string
replicas: integer
resources:
- id: deployment
template:
apiVersion: apps/v1
kind: Deployment
# ... deployment spec
- id: service
template:
apiVersion: v1
kind: Service
# ... service spec
```
Ejemplo de instancia de `WebApplication`:
```
apiVersion: v1alpha1
kind: WebApplication
metadata:
name: my-web-app
namespace: default
spec:
name: my-web-app
replicas: 3
```
Al aplicar esta instancia, kro crea automáticamente los recursos de `Deployment` y `Service` definidos en la `ResourceGraphDefinition`.
Para obtener más información sobre los conceptos y recursos de kro, consulte [Conceptos de kro](kro-concepts.md).
## Recursos de ACK
Al activar la capacidad de ACK, puede crear y administrar los recursos de AWS mediante los recursos personalizados de Kubernetes. ACK proporciona más de 200 CRD para más de 50 servicios de AWS, lo que le permite definir los recursos de AWS junto con sus cargas de trabajo de Kubernetes y administrar los recursos de infraestructura de AWS dedicados con Kubernetes.
Ejemplos de recursos de ACK:
**Bucket de S3**
Los recursos de `Bucket` crean y administran buckets de Amazon S3 con políticas de control de versiones, cifrado y ciclo de vida.
**DBInstance de RDS**
Los recursos de `DBInstance` aprovisionan y administran las instancias de bases de datos de Amazon RDS con copias de seguridad automatizadas y plazos de mantenimiento.
**Tabla de DynamoDB**
Los recursos de `Table` crean y administran tablas de DynamoDB con capacidad aprovisionada o bajo demanda.
**Rol de IAM**
Los recursos de `Role` definen los roles de IAM con políticas de confianza y políticas de permisos para el acceso a los servicios de AWS.
**Función Lambda**
Los recursos de `Function` crean y administran funciones de Lambda con configuración de código, tiempo de ejecución y rol de ejecución.
Ejemplo de especificación de un recurso de `Bucket`:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-app-bucket
spec:
name: my-unique-bucket-name-12345
versioning:
status: Enabled
encryption:
rules:
- applyServerSideEncryptionByDefault:
sseAlgorithm: AES256
```
Para obtener más información sobre los conceptos y recursos de ACK, consulte [Conceptos de ACK](ack-concepts.md).
## Límites de recursos
Las capacidades de EKS tienen los siguientes límites de recursos:
**Límites de uso de Argo CD**:
+ Máximo de 1000 recursos de `Application` por instancia de capacidad de Argo CD
+ Máximo de 100 clústeres remotos configurados por instancia de capacidad de Argo CD
**Límites de configuración de recursos**:
+ Máximo 150 recursos de Kubernetes por recurso de `Application` en Argo CD
+ Máximo 64 recursos de Kubernetes por `ResourceGraphDefinition` en kro
**nota**
Estos límites se aplican a la cantidad de recursos administrados por cada instancia de capacidad. Si necesita límites más elevados, puede implementar capacidades en varios clústeres.
## Siguientes pasos
Para obtener información sobre tareas específicas de las capacidades y configuración avanzada, consulte los siguientes temas:
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK y el ciclo de vida de los recursos
+ [Uso de Argo CD](working-with-argocd.md): uso de las capacidades de Argo CD para flujos de trabajo de GitOps
+ [Conceptos de kro](kro-concepts.md): descripción de los conceptos de kro y la composición de recursos
# Consideraciones sobre las capacidades de EKS
En este tema, se tratan aspectos importantes a la hora de utilizar las capacidades de EKS, como el diseño del control de acceso, la elección entre las capacidades de EKS y las soluciones autoadministradas, los patrones de arquitectura para las implementaciones de varios clústeres y las prácticas recomendadas operativas.
## RBAC de Kubernetes y roles de IAM de la capacidad
Cada recurso de la capacidad de EKS tiene un rol de IAM de capacidad configurado. El rol de capacidad se utiliza para otorgar permisos del servicio de AWS para que las capacidades de EKS actúen en su nombre. Por ejemplo, para utilizar la capacidad de EKS para ACK con el fin de administrar buckets de Amazon S3, debe otorgar permisos administrativos al bucket de S3 para la capacidad, lo que le permitirá crear y administrar buckets.
Una vez configurada la capacidad, los recursos de S3 en AWS se pueden crear y administrar con los recursos personalizados de Kubernetes en el clúster. El RBAC de Kubernetes es el mecanismo de control de acceso integrado en el clúster para determinar qué usuarios y grupos pueden crear y administrar esos recursos personalizados. Por ejemplo, otorga permisos específicos a usuarios y grupos del RBAC de Kubernetes para crear y administrar los recursos de `Bucket` en los espacios de nombres que elija.
De este modo, IAM y el RBAC de Kubernetes son dos mitades del sistema de control de acceso integral que regula los permisos relacionados con los recursos y las capacidades de EKS. Es importante diseñar la combinación adecuada de políticas de acceso de RBAC y permisos de IAM para su caso de uso.
Para obtener información adicional sobre los permisos de Kubernetes y los roles de IAM de la capacidad, consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Patrones de arquitectura de varios clústeres
Al implementar capacidades en varios clústeres, tenga en cuenta estos patrones arquitectónicos comunes:
**Radial con administración centralizada**
Ejecute las tres capacidades en un clúster administrado de forma centralizada para organizar las cargas de trabajo y administrar la infraestructura en la nube en varios clústeres de cargas de trabajo.
+ Argo CD en el clúster de administración implementa aplicaciones en clústeres de cargas de trabajo de distintas regiones o cuentas
+ ACK en el clúster de administración aprovisiona los recursos de AWS (RDS, S3, IAM) para todos los clústeres
+ kro en el clúster de administración crea abstracciones de plataforma portátiles que funcionan en todos los clústeres
Este patrón centraliza la administración de la carga de trabajo y la infraestructura en la nube, y puede simplificar las operaciones de las organizaciones que administran muchos clústeres.
**GitOps descentralizadas**
Las cargas de trabajo y la infraestructura en la nube se administran mediante capacidades del mismo clúster en el que se ejecutan las cargas de trabajo.
+ Argo CD administra los recursos de las aplicaciones en el clúster local.
+ Los recursos de ACK se utilizan para las necesidades de los clústeres y las cargas de trabajo.
+ Las abstracciones de la plataforma de kro se instalan y orquestan los recursos locales.
Este patrón descentraliza las operaciones, ya que los equipos administran sus propios servicios dedicados de la plataforma en uno o más clústeres.
**Radial con implementación híbrida de ACK**
Combine modelos centralizados y descentralizados, con implementaciones de aplicaciones centralizadas y administración de recursos en función del ámbito y la propiedad.
+ Clúster de concentrador:
+ Argo CD administra las implementaciones de GitOps en el clúster local y en todos los clústeres de cargas de trabajo remotos.
+ ACK se utiliza en el clúster de administración para los recursos del ámbito administrativo (bases de datos de producción, roles de IAM, VPC).
+ kro se usa en el clúster de administración para abstracciones de plataforma reutilizables.
+ Clúster de radio:
+ Las cargas de trabajo se administran mediante Argo CD en el clúster de concentrador centralizado.
+ ACK se usa localmente para los recursos del ámbito de la carga de trabajo (buckets de S3, instancias de ElastiCache, colas de SQS).
+ kro se usa localmente para la composición de recursos y los patrones de componentes
Este patrón separa las preocupaciones: los equipos de plataformas administran la infraestructura crítica de forma centralizada en clústeres de administración, lo que incluye opcionalmente los clústeres de cargas de trabajo, mientras que los equipos de aplicaciones especifican y administran los recursos de la nube junto con las cargas de trabajo.
**Elección de un patrón**
Tenga en cuenta estos factores al seleccionar una arquitectura:
+ **Estructura organizativa**: los equipos de plataformas centralizadas prefieren los patrones de concentrador, mientras que los equipos descentralizados pueden preferir las capacidades por clúster.
+ **Ámbito de los recursos**: los recursos de ámbito administrativo (bases de datos, IAM) suelen beneficiarse de la administración central, mientras que los recursos de cargas de trabajo (buckets, colas) se pueden administrar de forma local.
+ **Autoservicio**: los equipos de plataformas centralizadas pueden crear y distribuir recursos personalizados prescriptivos para permitir el autoservicio seguro de los recursos de la nube para las necesidades de carga de trabajo comunes.
+ **Administración de flotas del clúster**: los clústeres de administración centralizada proporcionan un plano de control que es propiedad del cliente para la administración de flotas en clústeres de EKS, junto con otros recursos del ámbito administrativo.
+ **Requisitos de cumplimiento**: algunas organizaciones requieren un control centralizado para la auditoría y la gobernanza.
+ **Complejidad operativa**: un número menor de instancias de capacidad simplifica las operaciones, pero puede crear cuellos de botella.
**nota**
Puede comenzar con un patrón y evolucionar hacia otro a medida que la plataforma vaya madurando. Las capacidades son independientes: puede implementarlas de forma diferente en los clústeres en función de sus necesidades.
## Comparación de las capacidades de EKS con las soluciones autoadministradas
Las capacidades de EKS proporcionan experiencias completamente administradas para las herramientas y controladores populares de Kubernetes que se ejecutan en EKS. Difieren de las soluciones auto administradas, que se instalan y se utilizan en el clúster.
### Diferencias clave
**Implementación y administración**
AWS administra completamente las capacidades de EKS sin necesidad de instalar, configurar ni mantener el software de los componentes. AWS instala y administra automáticamente todas las definiciones de recursos personalizados (CRD) de Kubernetes necesarias en el clúster.
Con las soluciones autoadministradas, puede instalar y configurar el software de clústeres mediante gráficos de Helm, kubectl u otros operadores. Tiene el control total sobre el ciclo de vida del software y la configuración del tiempo de ejecución de las soluciones autoadministradas, lo que permite personalizar cualquier capa de la solución.
**Operaciones y mantenimiento**
AWS administra la aplicación de parches y otras operaciones del ciclo de vida del software para las capacidades de EKS, con actualizaciones automáticas y parches de seguridad. Las capacidades de EKS se integran con características de AWS que permiten simplificar las configuraciones, ofrecen alta disponibilidad y tolerancia a errores integradas, y eliminan la solución de problemas de las cargas de trabajo de los controladores dentro del clúster.
Las soluciones autoadministradas requieren que supervise el estado y los registros de los componentes, aplique parches de seguridad y actualizaciones de versiones, configure la alta disponibilidad con varias réplicas y presupuestos para interrupciones de pods, solucione y corrija los problemas de cargas de trabajo de los controladores y administre los lanzamientos y las versiones. Tiene el control total sobre las implementaciones, pero esto suele requerir soluciones personalizadas para el acceso a clústeres privados y otras integraciones que deben ajustarse a los estándares de la organización y a los requisitos de cumplimiento en materia de seguridad.
**Consumo de recursos**
Las capacidades de EKS se ejecutan en EKS y fuera de los clústeres, lo que libera recursos de nodos y clústeres. Las capacidades no utilizan los recursos de cargas de trabajo de clústeres, no consumen CPU ni memoria en los nodos de trabajo, se escalan automáticamente y tienen un impacto mínimo en la planificación de la capacidad del clúster.
Las soluciones autoadministradas ejecutan controladores y otros componentes en los nodos de trabajo, lo que consume directamente los recursos de los nodos de trabajo, las direcciones IP del clúster y otros recursos del clúster. La administración de los servicios del clúster requiere planificar la capacidad de las cargas de trabajo, así como planificar y configurar las solicitudes y los límites de los recursos para administrar los requisitos de escalabilidad y alta disponibilidad.
**Compatibilidad de características**
Al tratarse de características del servicio completamente administradas, las capacidades de EKS son, por naturaleza, obstinadas en comparación con las soluciones autoadministradas. Si bien las capacidades admiten la mayoría de las características y los casos de uso, habrá una diferencia en la cobertura en comparación con las soluciones autoadministradas.
Con las soluciones autoadministradas, controla completamente la configuración, las características opcionales y otros aspectos de la funcionalidad del software. Puede optar por ejecutar sus propias imágenes personalizadas, personalizar todos los aspectos de la configuración y controlar completamente la funcionalidad de la solución autoadministrada.
**Consideraciones sobre costos**
Cada recurso de capacidad de EKS tiene un costo por hora relacionado, que varía según el tipo de capacidad. Los recursos del clúster administrados por la capacidad también tienen un costo por hora asociado con sus propios precios. Para obtener más información, consulte los [precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).
Las soluciones autoadministradas no tienen costos directos relacionados con los cargos de AWS, pero paga por los recursos de computación en clústeres que utilizan los controladores y las cargas de trabajo relacionadas. Además del consumo de recursos de nodos y clústeres, el costo total de la propiedad de las soluciones autoadministradas incluye los gastos operativos y los gastos de mantenimiento, solución de problemas y soporte.
### Elección entre las capacidades de EKS y las soluciones autoadministradas
**Capacidades de EKS**: tenga en cuenta esta opción si desea reducir los gastos operativos y centrarse en el valor diferenciado de su software y sus sistemas, en lugar de centrarse en las operaciones de plataformas del clúster para cumplir con los requisitos fundamentales. Utilice las capacidades de EKS cuando desee minimizar la carga operativa que suponen los parches de seguridad y la administración del ciclo de vida del software, liberar recursos de nodos y clústeres para las cargas de trabajo de las aplicaciones, simplificar la administración de la configuración y la seguridad y beneficiarse de la cobertura de AWS Support. Las capacidades de EKS son ideales para la mayoría de los casos de uso de producción y son el enfoque recomendado para las nuevas implementaciones.
**Soluciones autoadministradas**: tenga en cuenta esta opción cuando necesite versiones específicas de la API de recursos de Kubernetes, personalice compilaciones de controladores, tenga la automatización y las herramientas existentes basadas en implementaciones autoadministradas o necesite una personalización profunda de las configuraciones de tiempo de ejecución de los controladores. Las soluciones autoadministradas ofrecen flexibilidad para casos de uso especializados y tiene el control total sobre la configuración de implementación y tiempo de ejecución.
**nota**
Las capacidades de EKS pueden coexistir en el clúster con soluciones autoadministradas, y es posible llevar a cabo migraciones escalonadas.
### Comparaciones específicas de la capacidad
Para obtener comparaciones detalladas, incluidas las características específicas de la capacidad, las diferencias ascendentes y las rutas de migración, consulte:
+ [Comparación de la capacidad de EKS para ACK con ACK autoadministrados](ack-comparison.md)
+ [Comparación de la capacidad de EKS para Argo CD con Argo CD autoadministrado](argocd-comparison.md)
+ [Comparación de la capacidad de EKS para kro con kro autoadministrado](kro-comparison.md)
# Implementación de recursos de AWS de Kubernetes con Controladores de AWS para Kubernetes (ACK)
Controladores de AWS para Kubernetes (ACK) le permite definir y administrar los recursos de servicios de AWS directamente desde Kubernetes. Con Controladores de AWS para Kubernetes (ACK), puede administrar los recursos de cargas de trabajo y la infraestructura en la nube mediante los recursos personalizados de Kubernetes, junto con las cargas de trabajo de sus aplicaciones, a través de las API y herramientas de Kubernetes que ya conoce.
Con las capacidades de EKS, AWS administra ACK completamente, lo que elimina la necesidad de instalar, mantener y escalar los controladores de ACK en sus clústeres.
## Cómo funciona ACK
ACK traduce las especificaciones de recursos personalizadas de Kubernetes a llamadas a la API de AWS. Cuando crea, actualiza o elimina un recurso personalizado de Kubernetes que represente un recurso de servicio de AWS, ACK hace las llamadas a la API de AWS necesarias para crear, actualizar o eliminar el recurso de AWS.
Cada recurso de AWS compatible con ACK tiene su propia definición de recursos personalizados (CRD) que define el esquema de la API de Kubernetes para especificar su configuración. Por ejemplo, ACK proporciona las CRD para S3, lo que incluye los buckets, las políticas de bucket y otros recursos de S3.
ACK concilia continuamente el estado de sus recursos de AWS con el estado deseado definido en sus recursos personalizados de Kubernetes. Si un recurso se desvía del estado deseado, ACK lo detecta y toma medidas correctivas para volver a alinearlo. Los cambios en los recursos de Kubernetes se reflejan inmediatamente en el estado de los recursos de AWS, mientras que la detección pasiva de las desviaciones y la corrección de los cambios iniciales en los recursos de AWS pueden tardar hasta 10 horas (el periodo de resincronización), pero se suelen producir mucho antes.
**Ejemplo de manifiesto de recursos de buckets de S3**
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-ack-bucket
spec:
name: my-unique-bucket-name
```
Cuando aplique este recurso personalizado a su clúster, ACK crea un bucket de Amazon S3 en su cuenta si aún no existe. Los cambios posteriores en este recurso, como especificar un nivel de almacenamiento no predeterminado o agregar una política, se aplicarán al recurso de S3 en AWS. Cuando se elimina este recurso del clúster, el bucket de S3 de AWS se elimina de forma predeterminada.
## Beneficios de ACK
ACK proporciona una administración de recursos de AWS nativa de Kubernetes, lo que le permite administrar los recursos de AWS con las mismas API y herramientas de Kubernetes que usa para sus aplicaciones. Este enfoque unificado simplifica el flujo de trabajo de administración de infraestructuras al eliminar la necesidad de cambiar de una herramienta a otra o aprender a utilizar sistemas independientes de infraestructura como código. Definirá los recursos de AWS de forma declarativa en 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.
ACK concilia continuamente el estado deseado de sus recursos de AWS con su estado real, lo que corrige la desviación y garantiza la coherencia en toda la infraestructura. Esta conciliación continua significa que los cambios imperativos en los recursos de AWS sin conexión se revierten automáticamente para que coincidan con la configuración declarada, lo que mantiene la integridad de su infraestructura como código. Puede configurar ACK para administrar los recursos en varias regiones y cuentas de AWS, lo que permite arquitecturas complejas de varias cuentas sin herramientas adicionales.
Para las organizaciones que migran desde otras herramientas de administración de infraestructura, ACK admite la adopción de recursos, lo que le permite administrar los recursos de AWS existentes sin tener que volver a crearlos. ACK también proporciona recursos de solo lectura para la observación de los recursos de AWS sin acceso a modificaciones, y anotaciones para retener los recursos de AWS de forma opcional, incluso cuando el recurso de Kubernetes se elimina del clúster.
Para obtener más información y comenzar a utilizar la capacidad de EKS para ACK, consulte [Conceptos de ACK](ack-concepts.md) y [Consideraciones sobre ACK para EKS](ack-considerations.md).
## Servicios de AWS compatibles
ACK admite una amplia gama de servicios de AWS, que incluyen, entre otros, los siguientes:
+ Amazon EC2
+ Amazon S3
+ Amazon RDS
+ Amazon DynamoDB
+ Amazon ElastiCache
+ Amazon EKS
+ Amazon SQS
+ Amazon SNS
+ AWS Lambda
+ AWS IAM
Todos los servicios de AWS que figuran como de disponibilidad general ascendente son compatibles con la capacidad de EKS para ACK. Consulte la [lista completa de servicios de AWS compatibles](https://aws-controllers-k8s.github.io/community/docs/community/services/) para obtener más información.
## Integración con otras capacidades administradas de EKS
ACK se integra con otras capacidades administradas de EKS.
+ **Argo CD**: utilice Argo CD para administrar la implementación de los recursos de ACK en varios clústeres, lo que activa los flujos de trabajo de GitOps para su infraestructura de AWS.
+ ACK amplía los beneficios de GitOps cuando se combina con ArgoCD, pero ACK no requiere la integración con git.
+ **kro (Kube Resource Orchestrator)**: utilice kro para componer recursos complejos a partir de recursos de ACK, lo que crea abstracciones de alto nivel que simplifican la administración de recursos.
+ Puede crear recursos personalizados compuestos con kro que definan tanto los recursos como los de Kubernetes como los de AWS. Los miembros del equipo pueden usar estos recursos personalizados para implementar rápidamente aplicaciones complejas.
## Introducción a ACK
Para comenzar a utilizar la capacidad de EKS para ACK:
1. Cree y configure un rol de capacidad de IAM con los permisos necesarios para que ACK administre los recursos de AWS en su nombre.
1. [Cree un recurso de capacidad de ACK](create-ack-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. Aplique los recursos personalizados de Kubernetes al clúster para comenzar a administrar sus recursos de AWS en Kubernetes.
# Creación de una capacidad de ACK
En este capítulo, se explica cómo crear una capacidad de ACK en un clúster de Amazon EKS.
## Requisitos previos
Antes de crear una capacidad de ACK, asegúrese de que disponga de lo siguiente:
+ Un clúster de Amazon EKS
+ Un rol de capacidad de IAM con permisos para que ACK administre los recursos de AWS
+ Permisos de IAM suficientes para crear recursos de capacidad en los clústeres de EKS
+ La herramienta de la CLI adecuada instalada y configurada o el acceso a la consola de EKS
Para obtener instrucciones sobre cómo crear el rol de capacidad de IAM, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md).
**importante**
ACK es una capacidad de administración de infraestructuras que permite crear, modificar y eliminar recursos de AWS. Se trata de una capacidad de ámbito administrativo que debe controlarse cuidadosamente. Cualquier persona que tenga permiso para crear recursos de Kubernetes en el clúster puede crear recursos de AWS de forma eficaz mediante ACK, siempre que se cumplan los permisos del rol de capacidad de IAM. El rol de capacidad de IAM que proporcione determina qué recursos de AWS puede crear y administrar ACK. Para obtener orientación sobre cómo crear un rol adecuado con los permisos de privilegio mínimo, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Elección de la herramienta
Puede crear una capacidad de ACK mediante la Consola de administración de AWS, la AWS CLI o eksctl:
+ [Creación de una capacidad de ACK mediante la consola](ack-create-console.md): uso de la consola para una experiencia guiada
+ [Creación de una capacidad de ACK mediante la AWS CLI](ack-create-cli.md): uso de la AWS CLI para scripts y automatización
+ [Creación de una capacidad de ACK mediante eksctl](ack-create-eksctl.md): uso de eksctl para una experiencia nativa de Kubernetes
## Qué ocurre cuando se crea una capacidad de ACK
Al crear una capacidad de ACK:
1. EKS crea el servicio de capacidad de ACK 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 políticas de entrada de acceso específicas de la capacidad que conceden permisos básicos de Kubernetes (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.
1. ACK comienza a supervisar sus recursos personalizados en el clúster.
1. El estado de la capacidad cambia de `CREATING` a `ACTIVE`.
Una vez activos, puede crear recursos personalizados de ACK en el clúster para administrar recursos de AWS.
**nota**
La entrada de acceso creada automáticamente incluye la `AmazonEKSACKPolicy`, que concede a ACK permisos para administrar recursos de AWS. Algunos recursos de ACK que hacen referencia a secretos de Kubernetes (como bases de datos RDS con contraseñas) requieren 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 [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Siguientes pasos
Después de crear la capacidad de ACK:
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK e introducción a los recursos de AWS
+ [Conceptos de ACK](ack-concepts.md): más información sobre la conciliación, las exportaciones de campos y los patrones de adopción de recursos
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM y los patrones de varias cuentas
# Creación de una capacidad de ACK mediante la consola
En este tema, se describe cómo crear una capacidad de Controladores de AWS para Kubernetes (ACK) mediante la Consola de administración de AWS.
## Creación de la capacidad de ACK
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 de la izquierda, elija **Controladores de AWS para Kubernetes (ACK)**.
1. Elija **Crear capacidad de Controladores de AWS para Kubernetes**.
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 administrador**.
De este modo, se abre la consola de IAM en una nueva pestaña con la política de confianza rellenada previamente y la política administrada de `AdministratorAccess`. Si lo prefiere, puede anular la selección de esta política y agregar otros permisos.
Después de crear el rol, regrese a la consola de EKS y el rol se seleccionará automáticamente.
**importante**
La política `AdministratorAccess` sugerida otorga amplios permisos y tiene por objeto simplificar el inicio. Para uso en producción, reemplácela por una política personalizada que otorgue solo los permisos necesarios para los servicios de AWS específicos que tiene previsto administrar con ACK. Para obtener orientación sobre la creación de políticas de privilegio mínimo, consulte [Configuración de los permisos de ACK](ack-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
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 ACK.
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).
## Comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de ACK 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ías ver varias CRD en la lista de recursos de AWS.
**Uso de kubectl**
```
kubectl api-resources | grep services.k8s.aws
```
Deberías ver varias API en la lista de recursos de AWS.
**nota**
La capacidad de Controladores de AWS para Kubernetes permite instalar varios CRD para distintos recursos de AWS.
## Siguientes pasos
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK e introducción
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM para otros servicios de AWS
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de ACK
# Creación de una capacidad de ACK mediante la AWS CLI
En este tema, se describe cómo crear una capacidad de Controladores de AWS para Kubernetes (ACK) 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 > ack-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 ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Adjunte la política administrada de `AdministratorAccess` al rol:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**importante**
La política `AdministratorAccess` sugerida otorga amplios permisos y tiene por objeto simplificar el inicio. Para uso en producción, reemplácela por una política personalizada que otorgue solo los permisos necesarios para los servicios de AWS específicos que tiene previsto administrar con ACK. Para obtener orientación sobre la creación de políticas de privilegio mínimo, consulte [Configuración de los permisos de ACK](ack-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Paso 2: creación de la capacidad de ACK
Cree el recurso de la capacidad de ACK en su clúster. 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 create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--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-ack \
--query 'capability.status' \
--output text
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`. No continúe con el paso siguiente hasta que el estado sea `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-ack
```
## Paso 4: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de ACK estén disponibles en el clúster:
```
kubectl api-resources | grep services.k8s.aws
```
Deberías ver varias API en la lista de recursos de AWS.
**nota**
La capacidad de Controladores de AWS para Kubernetes permite instalar varios CRD para distintos recursos de AWS.
## Siguientes pasos
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK e introducción
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM para otros servicios de AWS
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de ACK
# Creación de una capacidad de ACK mediante eksctl
En este tema, se describe cómo crear una capacidad de Controladores de AWS para Kubernetes (ACK) 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 > ack-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 ACKCapabilityRole \
--assume-role-policy-document file://ack-trust-policy.json
```
Adjunte la política administrada de `AdministratorAccess` al rol:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
```
**importante**
La política `AdministratorAccess` sugerida otorga amplios permisos y tiene por objeto simplificar el inicio. Para uso en producción, reemplácela por una política personalizada que otorgue solo los permisos necesarios para los servicios de AWS específicos que tiene previsto administrar con ACK. Para obtener orientación sobre la creación de políticas de privilegio mínimo, consulte [Configuración de los permisos de ACK](ack-permissions.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
**importante**
Esta política otorga permisos para la administración de buckets de S3 con `"Resource": "*"`, lo que permite llevar a cabo operaciones en todos los buckets de S3.
Para uso en producción: \$1 Restrinja el campo `Resource` a patrones de nombres o ARN de buckets específicos. \$1 Use claves de condición de IAM para limitar el acceso por etiquetas de recursos. \$1 Otorgue solo los permisos mínimos necesarios para su caso de uso.
Para otros servicios de AWS, consulte [Configuración de los permisos de ACK](ack-permissions.md).
Asocie la política al rol:
```
aws iam attach-role-policy \
--role-name ACKCapabilityRole \
--policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/ACKS3Policy
```
## Paso 2: creación de la capacidad de ACK
Cree la capacidad de ACK 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 \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack \
--type ACK \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ACKCapabilityRole \
--ack-service-controllers s3
```
**nota**
La etiqueta `--ack-service-controllers` es opcional. Si se omite, ACK activa todos los controladores disponibles. Para mejorar el rendimiento y la seguridad, considere la posibilidad de activar solo los controladores que necesite. Puede especificar varios controladores: `--ack-service-controllers s3,rds,dynamodb`
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:
```
eksctl get capability \
--cluster [.replaceable]`my-cluster` \
--region [.replaceable]`region-code` \
--name ack
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`.
## Paso 4: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de ACK estén disponibles en el clúster:
```
kubectl api-resources | grep services.k8s.aws
```
Deberías ver varias API en la lista de recursos de AWS.
**nota**
La capacidad de Controladores de AWS para Kubernetes permite instalar varios CRD para distintos recursos de AWS.
## Siguientes pasos
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK e introducción
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM para otros servicios de AWS
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de ACK
# Conceptos de ACK
ACK administra los recursos de AWS a través de las API de Kubernetes mediante la conciliación continua del estado deseado de los manifiestos con el estado real en AWS. Al crear o actualizar un recurso personalizado de Kubernetes, ACK hace las llamadas a la API de AWS necesarias para crear o modificar el recurso de AWS correspondiente, lo supervisa para detectar posibles desviaciones y actualiza el estado de Kubernetes para reflejar el estado actual. Este enfoque le permite administrar la infraestructura con herramientas y flujos de trabajo de Kubernetes que ya conoce y, al mismo tiempo, mantener la coherencia entre el clúster y AWS.
En este tema se explican los conceptos fundamentales de cómo ACK administra los recursos de AWS a través de las API de Kubernetes.
## Introducción a ACK
Tras crear la capacidad de ACK (consulte [Creación de una capacidad de ACK](create-ack-capability.md)), puede comenzar a administrar los recursos de AWS mediante los manifiestos de Kubernetes en su clúster.
Por ejemplo, cree este manifiesto de bucket de S3 en `bucket.yaml` y elija su propio nombre de bucket exclusivo.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-test-bucket
namespace: default
spec:
name: my-unique-bucket-name-12345
```
Aplique el manifiesto:
```
kubectl apply -f bucket.yaml
```
Compruebe el estado:
```
kubectl get bucket my-test-bucket
kubectl describe bucket my-test-bucket
```
Verifique que el bucket se haya creado en AWS:
```
aws s3 ls | grep my-unique-bucket-name-12345
```
Elimine el recurso de Kubernetes:
```
kubectl delete bucket my-test-bucket
```
Compruebe que el bucket se haya eliminado de AWS:
```
aws s3 ls | grep my-unique-bucket-name-12345
```
El bucket ya no debería aparecer en la lista, lo que demuestra que ACK administra todo el ciclo de vida de los recursos de AWS.
Para obtener más información sobre cómo comenzar a utilizar Athena, consulte [Introducción a ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/getting-started/).
## Ciclo de vida de los recursos y conciliación
ACK utiliza un ciclo de conciliación continuo para garantizar que sus recursos de AWS coincidan con el estado deseado definido en los manifiestos de Kubernetes.
**Cómo funciona la conciliación**:
1. Cree o actualice un recurso personalizado de Kubernetes (por ejemplo, un bucket de S3).
1. ACK detecta el cambio y compara el estado deseado con el estado real en AWS.
1. Si son diferentes, ACK hace llamadas a la API de AWS para conciliar la diferencia.
1. ACK actualiza el estado del recurso en Kubernetes para reflejar el estado actual.
1. El ciclo se repite de forma continua, normalmente cada pocas horas.
La conciliación se activa cuando se crea un nuevo recurso de Kubernetes, se actualiza la `spec` de un recurso existente o cuando ACK detecta una desviación en AWS debido a cambios manuales hechos fuera de ACK. Además, ACK lleva a cabo una conciliación periódica con un periodo de resincronización de 10 horas. Los cambios en los recursos de Kubernetes activan una conciliación inmediata, mientras que la detección pasiva de los cambios en los recursos de AWS ascendentes se produce durante la resincronización periódica.
Al trabajar en el ejemplo de introducción anterior, ACK lleva a cabo los siguientes pasos:
1. Comprueba si el bucket existe en AWS.
1. Si no, llama a `s3:CreateBucket`.
1. Actualiza el estado de Kubernetes con el ARN y el estado del bucket.
1. Continúa supervisando para detectar desviaciones.
Para obtener más información sobre cómo funciona ACK, consulte [ACK Reconciliation](https://aws-controllers-k8s.github.io/community/docs/user-docs/reconciliation/).
## Condiciones de estado
Los recursos de ACK utilizan las condiciones de estado para comunicar su estado. Comprender estas condiciones lo ayuda a solucionar problemas y entender el estado de los recursos.
+ **Listo**: indica que el recurso está listo para consumirse (condición estandarizada de Kubernetes).
+ **ACK.ResourceSynced**: indica que la especificación del recurso coincide con el estado del recurso de AWS.
+ **ACK.Terminal**: indica que se ha producido un error irrecuperable.
+ **ACK.Adopted**: indica que el recurso se adoptó de un recurso de AWS existente en lugar de crearse.
+ **ACK.Recoverable**: indica un error recuperable que puede resolverse sin actualizar la especificación.
+ **ACK.Advisory**: proporciona información de asesoramiento sobre el recurso.
+ **ACK.LateInitialized**: indica si se ha completado la inicialización tardía de los campos.
+ **ACK.ReferencesResolved**: indica si se han resuelto todos los campos `AWSResourceReference`.
+ **ACK.IAMRoleSelected**: indica si se ha seleccionado un IAMRoleSelector para administrar este recurso.
Compruebe el estado del recurso:
```
# Check if resource is ready
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
# Check for terminal errors
kubectl get bucket my-bucket -o jsonpath='{.status.conditions[?(@.type=="ACK.Terminal")]}'
```
Ejemplo de estado:
```
status:
conditions:
- type: Ready
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.ResourceSynced
status: "True"
lastTransitionTime: "2024-01-15T10:30:00Z"
- type: ACK.Terminal
status: "True"
ackResourceMetadata:
arn: arn:aws:s3:::my-unique-bucket-name
ownerAccountID: "111122223333"
region: us-west-2
```
Para obtener más información sobre los estados y las condiciones de ACK, consulte [ACK Conditions](https://aws-controllers-k8s.github.io/community/docs/user-docs/conditions/).
## Políticas de eliminación
La política de eliminación de ACK controla lo que ocurre con los recursos de AWS cuando se elimina el recurso de Kubernetes.
**Eliminación (opción predeterminada)**
El recurso de AWS se elimina al eliminar el recurso de Kubernetes: este es el comportamiento predeterminado.
```
# No annotation needed - this is the default
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: temp-bucket
spec:
name: temporary-bucket
```
Al eliminar este recurso, se elimina el bucket de S3 en AWS.
**Retain**
El recurso de AWS se conserva al eliminar el recurso de Kubernetes:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: important-bucket
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
name: production-data-bucket
```
Al eliminar este recurso, se elimina de Kubernetes, pero se deja el bucket de S3 en AWS.
La política `retain` es útil para las bases de datos de producción que deberían durar más tiempo que el recurso de Kubernetes, los recursos compartidos utilizados por varias aplicaciones, los recursos con datos importantes que no deberían eliminarse accidentalmente o la administración temporal de ACK donde se adopta un recurso, se configura y, a continuación, se vuelve a administrar manualmente.
Para obtener más información sobre la política de eliminación de ACK, consulte [ACK Deletion Policy](https://aws-controllers-k8s.github.io/community/docs/user-docs/deletion-policy/).
## Adopción de recursos
La adopción le permite administrar los recursos de AWS existentes sin necesidad de volver a crearlos.
Cuándo se utiliza la adopción:
+ Para la migración de la infraestructura existente a la administración de ACK
+ Para la recuperación de recursos de AWS huérfanos en caso de eliminación accidental de recursos en Kubernetes
+ Para la importación de recursos creados por otras herramientas (CloudFormation, Terraform)
Cómo funciona la adopción:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Al crear este recurso:
1. ACK comprueba si existe un bucket con ese nombre en AWS.
1. Si lo encuentra, ACK lo adopta (no es necesario crear llamadas a la API).
1. ACK lee la configuración actual de AWS.
1. ACK actualiza el estado de Kubernetes para reflejar el estado actual,
1. Las actualizaciones futuras concilian el recurso con normalidad.
Una vez adoptados, los recursos se administran como cualquier otro recurso de ACK y, al eliminar el recurso de Kubernetes, se eliminará el recurso de AWS, a menos que utilice la política de eliminación `retain`.
Al adoptar un recurso, el recurso de AWS debe existir previamente y ACK necesita permisos de lectura para detectarlo. La política `adopt-or-create` adopta el recurso si existe o lo crea si no existe. Esto resulta útil cuando se desea un flujo de trabajo declarativo que funcione independientemente de si el recurso existe o no.
Para obtener más información sobre la adopción de recursos de ACK, consulte [ACK Resource Adoption](https://aws-controllers-k8s.github.io/community/docs/user-docs/adopted-resource/).
## Recursos entre cuentas y regiones
ACK puede administrar los recursos en diferentes cuentas y regiones de AWS desde un solo clúster.
**Anotaciones de recursos entre regiones**
Puede especificar la región de un recurso de AWS mediante una anotación:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: eu-bucket
annotations:
services.k8s.aws/region: eu-west-1
spec:
name: my-eu-bucket
```
También puede especificar la región de todos los recursos de AWS creados en un espacio de nombres determinado:
**Anotaciones de espacios de nombres**
Establezca una región predeterminada para todos los recursos de un espacio de nombres:
```
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
services.k8s.aws/default-region: us-west-2
```
Los recursos creados en este espacio de nombres utilizan esta región a menos que se sustituya por una anotación de recurso.
**Entre cuentas**
Utilice los selectores de roles de IAM para asignar roles de IAM específicos a espacios de nombres:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: target-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
Los recursos creados en el espacio de nombres asignado utilizan automáticamente el rol especificado.
Para obtener más información sobre los selectores de roles de IAM, consulte [ACK Cross-Account Resource Management](https://aws-controllers-k8s.github.io/docs/guides/cross-account). Para obtener información sobre la configuración entre cuentas, consulte [Configuración de los permisos de ACK](ack-permissions.md).
## Gestión de errores y comportamiento de los reintentos
ACK gestiona automáticamente los errores transitorios y reintenta las operaciones fallidas.
Estrategia de reintento:
+ Los errores transitorios (limitación de velocidad, problemas temporales del servicio, permisos insuficientes) provocan reintentos automáticos.
+ El retroceso exponencial evita que las API de AWS se sobrecarguen.
+ El número máximo de reintentos varía según el tipo de error.
+ Los errores permanentes (parámetros no válidos, conflictos en el nombre del recurso) no se vuelven a intentar.
Compruebe el estado del recurso para ver los detalles del error mediante `kubectl describe`:
```
kubectl describe bucket my-bucket
```
Busque las condiciones de estado con mensajes de error, los eventos que muestren los intentos de conciliación recientes y el campo `message` en las condiciones de estado que explique los errores. Los errores más comunes son la insuficiencia de permisos de IAM, los conflictos en los nombres de los recursos en AWS, los valores de configuración no válidos en la `spec` y la superación de AWS Service Quotas.
Para solucionar errores comunes, consulte [Solución de problemas con capacidades de ACK](ack-troubleshooting.md).
## Composición de recursos con kro
Para componer y conectar varios recursos de ACK entre sí, utilice la capacidad de EKS para kro (Kube Resource Orchestrator). kro proporciona una forma declarativa de definir grupos de recursos, lo que transfiere la configuración entre recursos para administrar patrones de infraestructura complejos de forma sencilla.
Para ver ejemplos detallados de cómo crear composiciones de recursos personalizados con recursos de ACK, consulte [Conceptos de kro](kro-concepts.md).
## Siguientes pasos
+ [Consideraciones sobre ACK para EKS](ack-considerations.md): patrones y estrategias de integración específicos de EKS
# Configuración de los permisos de ACK
ACK necesita permisos de IAM para crear y administrar recursos de AWS en su nombre. En este tema, se explica cómo funciona IAM con ACK y se proporciona orientación sobre la configuración de los permisos para distintos casos de uso.
## Cómo funciona IAM con ACK
ACK usa roles de IAM para autenticarse con AWS y llevar a cabo acciones en los recursos. Hay dos formas de proporcionar permisos a ACK:
**Rol de capacidad**: el rol de IAM que proporciona al crear la capacidad de ACK. Este rol se utiliza de forma predeterminada para todas las operaciones de ACK.
**Selectores de roles de IAM**: roles de IAM adicionales que se pueden asignar a espacios de nombres o recursos específicos. Estos roles anulan el rol de capacidad para los recursos de su ámbito.
Cuando ACK necesita crear o administrar un recurso, determina qué rol de IAM se utiliza:
1. Compruebe si un IAMRoleSelector coincide con el espacio de nombres del recurso.
1. Si hay una coincidencia, asuma el rol de IAM.
1. De lo contrario, use el rol de capacidad.
Este enfoque permite una administración flexible de los permisos, desde configuraciones simples de un solo rol hasta configuraciones complejas de varias cuentas y varios equipos.
## Introducción: configuración sencilla de permisos
Para el desarrollo, las pruebas o los casos de uso sencillos, puede agregar todos los permisos del servicio necesarios directamente al rol de capacidad.
Este enfoque funciona bien cuando:
+ Comienza a usar ACK.
+ Todos los recursos están en la misma cuenta de AWS.
+ Un solo equipo administra todos los recursos de ACK.
+ Confía en que todos los usuarios de ACK tengan los mismos permisos.
## Práctica recomendada de producción: selectores de roles de IAM
Para los entornos de producción, utilice los selectores de roles de IAM para implementar el acceso con privilegio mínimo y el aislamiento de espacios de nombres.
Al utilizar selectores de roles de IAM, el rol de la capacidad solo necesita los permisos `sts:AssumeRole` y `sts:TagSession` para asumir los roles específicos del servicio. No es necesario agregar ningún permiso de servicio de AWS (como S3 o RDS) al propio rol de capacidad, ya que esos permisos se conceden a los roles de IAM individuales que asume el rol de capacidad.
**Cómo elegir entre los modelos de permisos**:
Utilice los **permisos directos** (adición de permisos de servicio al rol de capacidad) cuando:
+ Esté comenzando y desee la configuración más sencilla.
+ Todos los recursos estén en la misma cuenta que el clúster.
+ Tenga requisitos de permisos administrativos para todo el clúster.
+ Todos los equipos puedan compartir los mismos permisos.
Utilice los **selectores de roles de IAM** cuando:
+ Administre recursos en varias cuentas de AWS.
+ Los diferentes equipos o espacios de nombres necesiten permisos diferentes.
+ Necesite un control de acceso detallado por espacio de nombres.
+ Desee seguir las prácticas de seguridad de privilegio mínimo.
Puede comenzar con permisos directos y migrar a los selectores de roles de IAM más adelante, a medida que aumenten sus necesidades.
**Por qué debería utilizar los selectores de roles de IAM en producción:**
+ **Privilegio mínimo**: cada espacio de nombres obtiene solo los permisos que necesita.
+ **Aislamiento del equipo**: el equipo A no puede usar los permisos del equipo B accidentalmente.
+ **Auditoría más sencilla**: se asigna claramente el espacio de nombres que utiliza cada rol.
+ **Compatibilidad entre cuentas**: es necesario para administrar los recursos en varias cuentas.
+ **Separación de preocupaciones**: los diferentes servicios o entornos utilizan roles diferentes.
### Configuración básica del selector de roles de IAM
**Paso 1: creación de un rol de IAM específico del servicio**
Cree un rol de IAM con permisos para servicios de AWS específicos:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
```
Configure la política de confianza para permitir que el rol de capacidad la asuma:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
**Paso 2: concesión del permiso AssumeRole al rol de capacidad**
Agregue el permiso al rol de capacidad para asumir el rol específico del servicio:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::111122223333:role/ACK-S3-Role"
}
]
}
```
**Paso 3: creación de IAMRoleSelector**
Asigne el rol de IAM a un espacio de nombres:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: s3-namespace-config
spec:
arn: arn:aws:iam::111122223333:role/ACK-S3-Role
namespaceSelector:
names:
- s3-resources
```
**Paso 4: creación de recursos en el espacio de nombres asignado**
Los recursos del espacio de nombres `s3-resources` utilizan automáticamente el rol especificado:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: s3-resources
spec:
name: my-production-bucket
```
## Administración multicuenta
Utilice los selectores de roles de IAM para administrar los recursos de varias cuentas de AWS.
**Paso 1: creación de un rol de IAM entre cuentas**
En la cuenta de destino (444455556666), cree un rol que confíe en el rol de capacidad de la cuenta de origen:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/ACKCapabilityRole"
},
"Action": ["sts:AssumeRole", "sts:TagSession"]
}
]
}
```
Adjunte permisos específicos del servicio a este rol.
**Paso 2: concesión del permiso AssumeRole**
En la cuenta de origen (111122223333), permita que el rol de capacidad asuma el rol de cuenta de destino:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::444455556666:role/ACKTargetAccountRole"
}
]
}
```
**Paso 3: creación de IAMRoleSelector**
Asigne el rol de acceso entre cuentas a un espacio de nombres:
```
apiVersion: services.k8s.aws/v1alpha1
kind: IAMRoleSelector
metadata:
name: production-account-config
spec:
arn: arn:aws:iam::444455556666:role/ACKTargetAccountRole
namespaceSelector:
names:
- production
```
**Paso 4: creación de recursos**
Los recursos del espacio de nombres `production` se crean en la cuenta de destino:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-bucket
namespace: production
spec:
name: my-cross-account-bucket
```
## Etiquetas de sesión
La capacidad ACK de EKS establece automáticamente etiquetas de sesión en todas las solicitudes de la API de AWS. Estas etiquetas permiten un control de acceso detallado y auditoría al identificar el origen de cada solicitud.
### Etiquetas de sesión disponibles
Las siguientes etiquetas de sesión se incluyen en cada llamada a la API de AWS que realiza ACK:
| Clave de etiqueta | Descripción |
| --- | --- |
| `eks:eks-capability-arn` | El ARN de la capacidad de EKS que realiza la solicitud |
| `eks:kubernetes-namespace` | El espacio de nombres de Kubernetes del recurso que se administra |
| `eks:kubernetes-api-group` | El grupo de API de Kubernetes del recurso (por ejemplo, `s3.services.k8s.aws`) |
### Uso de etiquetas de sesión para el control de acceso
Puede utilizar estas etiquetas de sesión en las condiciones de las políticas de IAM para restringir qué recursos puede administrar ACK. Esto proporciona una capa adicional de seguridad más allá de los selectores de roles de IAM basados en el espacio de nombres.
**Ejemplo: restringir por espacio de nombres**
Permita que ACK cree buckets de S3 solo cuando la solicitud se origine en el espacio de nombres `production`:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:kubernetes-namespace": "production"
}
}
}
]
}
```
**Ejemplo: restringir por capacidad**
Permita acciones solo desde una capacidad ACK específica:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks:eks-capability-arn": "arn:aws:eks:us-west-2:111122223333:capability/my-cluster/ack/my-ack"
}
}
}
]
}
```
**nota**
Las etiquetas de sesión constituyen una diferencia con respecto a ACK autoadministrado, que no establece estas etiquetas de forma predeterminada. Esto permite un control de acceso más detallado con la capacidad administrada.
## Patrones avanzados del selector de roles de IAM
Para obtener la configuración avanzada, que incluye selectores de roles, asignación de roles específica del recurso y ejemplos adicionales, consulte la [documentación sobre IRSA de ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/irsa/).
## Siguientes pasos
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK y el ciclo de vida de los recursos
+ [Conceptos de ACK](ack-concepts.md): información sobre las políticas de adopción y eliminación de recursos
+ [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md): descripción de las prácticas recomendadas de seguridad para capacidades
# Consideraciones sobre ACK para EKS
En este tema, se tratan aspectos importantes al utilizar la capacidad de EKS para ACK, como la configuración de IAM, los patrones de varias cuentas y la integración con otras capacidades de EKS.
## Patrones de configuración de IAM
La capacidad de ACK utiliza un rol de capacidad de IAM para autenticarse con AWS. Elija el patrón de IAM adecuado en función de sus requisitos.
### Sencillo: rol de capacidad único
Para el desarrollo, las pruebas o los casos de uso sencillos, conceda todos los permisos necesarios directamente al rol de capacidad.
**Cuándo se debe usar**:
+ Introducción a ACK
+ Implementaciones de una sola cuenta
+ Todos los recursos administrados por un equipo
+ Entornos de desarrollo y pruebas
**Ejemplo**: agregue permisos de S3 y RDS al rol de capacidad con las condiciones de etiquetado de recursos.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
}
}
},
{
"Effect": "Allow",
"Action": ["rds:*"],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": ["us-west-2", "us-east-1"]
},
}
}
]
}
```
Este ejemplo limita las operaciones de S3 y RDS a regiones específicas y requiere que los recursos de RDS tengan una etiqueta `ManagedBy: ACK`.
### Producción: selectores de roles de IAM
Para los entornos de producción, utilice los selectores de roles de IAM para implementar el acceso con privilegio mínimo y el aislamiento de espacios de nombres.
**Cuándo se debe usar**:
+ Entornos de producción
+ Clústeres de varios equipos
+ Administración de recursos con varias cuentas
+ Requisitos de seguridad de privilegio mínimo
+ Diferentes servicios que necesitan diferentes permisos
**Ventajas**:
+ Cada espacio de nombres obtiene solo los permisos que necesita.
+ Aislamiento del equipo: el equipo A no puede usar los permisos del equipo B
+ Auditoría y conformidad más fáciles
+ Necesario para la administración de recursos entre cuentas
Para obtener información sobre la configuración de selectores de roles de IAM, consulte [Configuración de los permisos de ACK](ack-permissions.md).
## Integración con otras capacidades de EKS
### GitOps con Argo CD
Utilice la capacidad de EKS para Argo CD para implementar recursos de ACK desde repositorios de Git, lo que permite usar los flujos de trabajo de GitOps para la administración de infraestructuras.
**Consideraciones**:
+ Almacene recursos de ACK junto con manifiestos de aplicaciones para GitOps integrales.
+ Organice por entorno, servicio o tipo de recurso según la estructura de su equipo.
+ Utilice la sincronización automática de Argo CD para una conciliación continua.
+ Active la poda para eliminar automáticamente los recursos eliminados.
+ Tenga en cuenta los patrones radiales para la administración de infraestructuras de varios clústeres.
GitOps proporciona registros de auditoría, capacidades de reversión y administración declarativa de infraestructuras. Para obtener más información sobre Argo CD, consulte [Uso de Argo CD](working-with-argocd.md).
### Composición de recursos con kro
Utilice la capacidad de EKS para kro (Kube Resource Orchestrator) para componer varios recursos de ACK en abstracciones de nivel superior y API personalizadas.
**Cuándo se usa kro con ACK**:
+ Para la creación de patrones reutilizables para pilas de infraestructura comunes (base de datos \$1 copias de seguridad \$1 supervisión)
+ Para la creación de plataformas de autoservicio con API simplificadas para los equipos de aplicaciones
+ Para la administración de dependencias de los recursos y para la transferencia de valores entre recursos (de ARN de bucket de S3 a función de Lambda)
+ Para la estandarización de las configuraciones de la infraestructura en todos los equipos
+ Para la reducción de la complejidad mediante la ocultación de los detalles de la implementación detrás de recursos personalizados
**Ejemplos de patrones**:
+ Pila de la aplicación: bucket de S3 \$1 cola de SQS \$1 configuración de notificaciones
+ Configuración de la base de datos: instancia de RDS \$1 grupo de parámetros \$1 grupo de seguridad \$1 secretos
+ Redes: VPC \$1 subredes \$1 tablas de enrutamiento \$1 grupos de seguridad
kro gestiona el orden de las dependencias, la propagación de estados y la administración del ciclo de vida de los recursos compuestos. Para obtener más información sobre kro, consulte [Conceptos de kro](kro-concepts.md).
## Organización de los recursos
Organice los recursos de ACK mediante espacios de nombres de Kubernetes y etiquetas de recursos de AWS para mejorar la administración, el control de acceso y el seguimiento de los costos.
### Organización de espacios de nombres
Utilice los espacios de nombres de Kubernetes para separar de forma lógica los recursos de ACK por entorno (producción, prueba, desarrollo), equipo (plataforma, datos, ML) o aplicación.
**Ventajas**:
+ RBAC con ámbito de espacio de nombres para el control de acceso
+ Establecimiento de regiones predeterminadas por espacio de nombres mediante anotaciones
+ Administración y limpieza de recursos más sencillas
+ Separación lógica alineada con la estructura organizativa
### Etiquetado de recursos
La capacidad ACK de EKS aplica automáticamente etiquetas predeterminadas a todos los recursos de AWS que crea. Estas etiquetas difieren de las de ACK autoadministrado y proporcionan una trazabilidad mejorada.
**Etiquetas predeterminadas que aplica la capacidad**:
| Clave de etiqueta | Descripción |
| --- | --- |
| `eks:controller-version` | La versión del controlador de ACK |
| `eks:kubernetes-namespace` | El espacio de nombres de Kubernetes del recurso de ACK |
| `eks:kubernetes-resource-name` | El nombre del recurso de Kubernetes |
| `eks:kubernetes-api-group` | El grupo de API de Kubernetes (por ejemplo, `s3.services.k8s.aws`) |
| `eks:eks-capability-arn` | El ARN de la capacidad ACK de EKS |
**nota**
ACK autoadministrado utiliza etiquetas predeterminadas diferentes: `services.k8s.aws/controller-version` y `services.k8s.aws/namespace`. Las etiquetas de la capacidad utilizan el prefijo `eks:` para mantener la coherencia con otras características de EKS.
**Etiquetas adicionales recomendadas**:
Agregue etiquetas personalizadas para la asignación de costos, el seguimiento de la propiedad y fines organizativos:
+ Entorno (producción, prueba, desarrollo)
+ Propiedad del equipo o departamento
+ Centro de costos para la asignación de la facturación
+ Nombre de la aplicación o del servicio
## Migración desde otras herramientas de infraestructura como código
Muchas organizaciones encuentran valor al estandarizar en Kubernetes más allá de la orquestación de sus cargas de trabajo. Al migrar la administración de la infraestructura y los recursos de AWS a ACK, puede estandarizar la administración de la infraestructura mediante las API de Kubernetes junto con las cargas de trabajo de aplicaciones.
**Ventajas de estandarizar en Kubernetes para la infraestructura**:
+ **Único origen de información verdadera**: administre las aplicaciones y la infraestructura en Kubernetes, lo que posibilita una práctica de GitOps de extremo a extremo.
+ **Herramientas unificadas**: los equipos utilizan los recursos y las herramientas de Kubernetes en lugar de aprender múltiples herramientas y marcos.
+ **Conciliación coherente**: ACK concilia continuamente los recursos de AWS como lo hace Kubernetes con las cargas de trabajo, mediante la detección y la corrección de las desviaciones en comparación con las herramientas imperativas.
+ **Composiciones nativas**: con kro y ACK juntos, hace referencia a los recursos de AWS directamente en los manifiestos de aplicaciones y recursos, al pasar las cadenas de conexión y los ARN entre los recursos.
+ **Operaciones simplificadas**: dispone de un plano de control para las implementaciones, las reversiones y la observabilidad en todo el sistema.
ACK permite adoptar los recursos de AWS existentes sin volver a crearlos, lo que permite una migración sin tiempo de inactividad desde CloudFormation, Terraform o recursos externos al clúster.
**Adopte un recurso existente**:
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Una vez adoptado, ACK administra el recurso y lo puede actualizar mediante los manifiestos de Kubernetes. Puede migrar de forma gradual: se adoptan los recursos según sea necesario y, al mismo tiempo, se mantienen las herramientas de IaC existentes para otros recursos.
ACK también admite recursos de solo lectura. En el caso de los recursos administrados por otros equipos o herramientas a los que quiera hacer referencia, pero no modificar, combine la adopción con la política de eliminación `retain` y otorgue permisos de IAM de solo lectura. De este modo, las aplicaciones pueden detectar la infraestructura compartida (VPC, roles de IAM, claves de KMS) a través de las API de Kubernetes sin correr el riesgo de sufrir modificaciones.
Para obtener más información sobre la adopción de recursos, consulte [Conceptos de ACK](ack-concepts.md).
## Políticas de eliminación
Las políticas de eliminación controlan lo que ocurre con los recursos de AWS cuando se elimina el recurso de Kubernetes correspondiente. Elija la política adecuada en función del ciclo de vida de los recursos y sus requisitos operativos.
### Eliminación (opción predeterminada)
El recurso de AWS se elimina al eliminar el recurso de Kubernetes. De este modo, se mantiene la coherencia entre el clúster y AWS, lo que garantiza que los recursos no se acumulen.
**Cuándo se usa la eliminación**:
+ Entornos de desarrollo y prueba en los que la limpieza es importante
+ Recursos efímeros vinculados al ciclo de vida de la aplicación (bases de datos de prueba, buckets temporales)
+ Recursos que no deberían durar más que la aplicación (colas de SQS, clústeres de ElastiCache)
+ Optimización de costos: limpieza automática de los recursos no utilizados
+ Entornos administrados con GitOps en los que la eliminación de recursos de Git debería eliminar la infraestructura
La política de eliminación predeterminada se ajusta al modelo declarativo de Kubernetes: lo que hay en el clúster coincide con lo que hay en AWS.
### Retener
El recurso de AWS se conserva al eliminar el recurso de Kubernetes. De este modo, se protegen los datos críticos y se permite que los recursos sobrepasen su tiempo de representación de Kubernetes.
**Cuándo se usa la retención**:
+ Bases de datos de producción con datos críticos que deben sobrevivir a los cambios del clúster
+ Buckets de almacenamiento a largo plazo con requisitos de conformidad o auditoría
+ Recursos compartidos que utilizan múltiples aplicaciones o equipos
+ Recursos que se están migrando a diferentes herramientas de administración
+ Escenarios de recuperación ante desastres en los que se desea preservar la infraestructura
+ Recursos con dependencias complejas que requieren un desmantelamiento cuidadoso
```
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
metadata:
name: production-db
annotations:
services.k8s.aws/deletion-policy: "retain"
spec:
dbInstanceIdentifier: prod-db
# ... configuration
```
**importante**
Los recursos retenidos siguen generando costos de AWS y se deben eliminar manualmente de AWS cuando ya no se necesiten. Utilice el etiquetado de recursos a fin de hacer un seguimiento de los recursos retenidos para su limpieza.
Para obtener más información sobre las políticas de eliminación, consulte [Conceptos de ACK](ack-concepts.md).
## Documentación ascendente
Para obtener información detallada sobre el uso de ACK:
+ [Guía de uso de ACK](https://aws-controllers-k8s.github.io/community/docs/user-docs/usage/): creación y administración de recursos
+ [Referencia sobre la API de ACK](https://aws-controllers-k8s.github.io/community/reference/): documentación completa sobre la API para todos los servicios
+ [Documentación de ACK](https://aws-controllers-k8s.github.io/community/docs/): documentación completa para el usuario
## Siguientes pasos
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM y los patrones de varias cuentas
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK y el ciclo de vida de los recursos
+ [Solución de problemas con capacidades de ACK](ack-troubleshooting.md): solución de problemas de ACK
+ [Uso de Argo CD](working-with-argocd.md): implementación de recursos de ACK con GitOps
+ [Conceptos de kro](kro-concepts.md): composición de recursos de ACK en abstracciones de nivel superior
# Solución de problemas con capacidades de ACK
En este tema se proporcionan instrucciones para la solución de problemas de la capacidad de EKS para ACK, como las comprobaciones de estado de la capacidad, la verificación del estado de los recursos y los problemas de permisos de IAM.
**nota**
Las capacidades de EKS son completamente administradas y se ejecutan fuera del clúster. No tiene acceso a los registros ni a los espacios de nombres de los controladores. La solución de problemas se centra en el estado de la capacidad, el estado de los recursos y la configuración de IAM.
## La capacidad está ACTIVA, pero no se crean recursos
Si la capacidad de ACK muestra el estado `ACTIVE`, pero no se están creando recursos en AWS, compruebe el estado de la capacidad, el estado de los recursos y los permisos de IAM.
**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-ack
# Look for issues in the health section
```
**Causas habituales**:
+ **Faltan permisos de IAM**: el rol de capacidad no tiene permisos para el servicio de AWS.
+ **Espacio de nombres incorrecto**: los recursos se crearon en un espacio de nombres sin el IAMRoleSelector adecuado.
+ **Especificación de recurso no válida**: compruebe las condiciones del estado del recurso para ver si hay errores de validación.
+ **Limitación de la API**: se están alcanzando los límites de velocidad de la API de AWS.
+ **Webhooks de admisión**: los webhooks de admisión impiden que el controlador corrija el estado de los recursos.
**Compruebe el estado del recurso**:
```
# Describe the resource to see conditions and events
kubectl describe bucket my-bucket -n default
# Look for status conditions
kubectl get bucket my-bucket -n default -o jsonpath='{.status.conditions}'
# View resource events
kubectl get events --field-selector involvedObject.name=my-bucket -n default
```
**Verifique los permisos de IAM**:
```
# View the Capability Role's policies
aws iam list-attached-role-policies --role-name my-ack-capability-role
aws iam list-role-policies --role-name my-ack-capability-role
# Get specific policy details
aws iam get-role-policy --role-name my-ack-capability-role --policy-name policy-name
```
## Recursos creados en AWS que no se muestran en Kubernetes
ACK solo hace el seguimiento de los recursos que crea a través de los manifiestos de Kubernetes. Para administrar los recursos de AWS existentes con ACK, use la característica de adopción.
```
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: existing-bucket
annotations:
services.k8s.aws/adoption-policy: "adopt-or-create"
spec:
name: my-existing-bucket-name
```
Para obtener más información sobre la adopción de recursos, consulte [Conceptos de ACK](ack-concepts.md).
## No se están creando recursos entre cuentas
Si los recursos no se crean en una cuenta de AWS de destino al utilizar los selectores de roles de IAM, compruebe la relación de confianza y la configuración de IAMRoleSelector.
**Verifique la relación de confianza**:
```
# Check the trust policy in the target account role
aws iam get-role --role-name cross-account-ack-role --query 'Role.AssumeRolePolicyDocument'
```
La política de confianza debe permitir que el rol de capacidad de la cuenta de origen la asuma.
**Confirme la configuración de IAMRoleSelector**:
```
# List IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Describe specific selector
kubectl describe iamroleselector my-selector
```
**Compruebe la alineación del espacio de nombres**:
Los IAMRoleSelectors son recursos de ámbito del clúster, pero tienen como destino espacios de nombres específicos. Asegúrese de que sus recursos de ACK estén en un espacio de nombres que coincida con el selector de espacios de nombres de IAMRoleSelector:
```
# Check resource namespace
kubectl get bucket my-cross-account-bucket -n production
# List all IAMRoleSelectors (cluster-scoped)
kubectl get iamroleselector
# Check which namespace the selector targets
kubectl get iamroleselector my-selector -o jsonpath='{.spec.namespaceSelector}'
```
**Compruebe la condición de IAMRoleSelected**:
Para comprobar que el IAMRoleSelector haya coincidido correctamente con su recurso, compruebe la condición `ACK.IAMRoleSelected`:
```
# Check if IAMRoleSelector was matched
kubectl get bucket my-cross-account-bucket -n production -o jsonpath='{.status.conditions[?(@.type=="ACK.IAMRoleSelected")]}'
```
Si la condición es `False` o falta, el selector de espacios de nombres de IAMRoleSelector no coincide con el espacio de nombres del recurso. Compruebe que el `namespaceSelector` del selector coincida con las etiquetas del espacio de nombres del recurso.
**Compruebe los permisos del rol de capacidad**:
El rol de la capacidad necesita los permisos `sts:AssumeRole` y `sts:TagSession` para el rol de la cuenta de destino:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["sts:AssumeRole", "sts:TagSession"],
"Resource": "arn:aws:iam::[.replaceable]`444455556666`:role/[.replaceable]`cross-account-ack-role`"
}
]
}
```
Para obtener información detallada sobre la configuración entre cuentas, consulte [Configuración de los permisos de ACK](ack-permissions.md).
## Siguientes pasos
+ [Consideraciones sobre ACK para EKS](ack-considerations.md): consideraciones y prácticas recomendadas
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de los permisos de IAM y los patrones de varias cuentas
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK 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 ACK con ACK autoadministrados
La capacidad de EKS para ACK proporciona la misma funcionalidad que los controladores ACK autoadministrados, 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). Este tema se centra en las diferencias específicas de ACK.
## Diferencias con respecto a ACK ascendentes
La capacidad de EKS para ACK se basa en los controladores ACK ascendentes, pero difiere en la integración de IAM.
**Rol de capacidad de IAM**: la capacidad utiliza un rol de IAM dedicado con una política de confianza que permite la entidad principal del servicio de `capabilities.eks.amazonaws.com`, pero no IRSA (roles de IAM para cuentas de servicio). Puede adjuntar las políticas de IAM directamente al rol de capacidad sin necesidad de crear ni anotar cuentas de servicio de Kubernetes ni configurar los proveedores de OIDC. Una práctica recomendada para los casos de uso de producción es configurar los permisos del servicio mediante `IAMRoleSelector`. Consulte [Configuración de los permisos de ACK](ack-permissions.md) para obtener más detalles.
**Etiquetas de sesión**: la capacidad administrada establece automáticamente etiquetas de sesión en todas las solicitudes de API de AWS, lo que permite un control de acceso detallado y auditoría. Las etiquetas incluyen `eks:eks-capability-arn`, `eks:kubernetes-namespace` y `eks:kubernetes-api-group`. Esto difiere de ACK autoadministrado, que no establece estas etiquetas de forma predeterminada. Consulte [Configuración de los permisos de ACK](ack-permissions.md) para obtener más información sobre el uso de etiquetas de sesión en las políticas de IAM.
**Etiquetas de recursos**: la capacidad aplica etiquetas predeterminadas diferentes a los recursos de AWS en comparación con ACK autoadministrado. La capacidad utiliza etiquetas con prefijo `eks:` (como `eks:kubernetes-namespace`, `eks:eks-capability-arn`) en lugar de las etiquetas `services.k8s.aws/` utilizadas por ACK autoadministrado. Consulte [Consideraciones sobre ACK para EKS](ack-considerations.md) para ver la lista completa de etiquetas de recursos predeterminadas.
**Compatibilidad de recursos**: los recursos personalizados de ACK funcionan de forma idéntica a los ACK ascendentes sin que se produzcan cambios en los archivos YAML de los recursos de ACK. La capacidad utiliza las mismas API y CRD de Kubernetes, por lo que herramientas como `kubectl` funcionan de la misma manera. Se admiten todos los controladores y recursos de GA de ACK ascendentes.
Para obtener la documentación completa de ACK y las guías específicas del servicio, consulte la [documentación de ACK.](https://aws-controllers-k8s.github.io/community/)
## Ruta de migración
Puede migrar de ACK autoadministrados a la capacidad administrada sin tiempo de inactividad:
1. Actualice el controlador de ACK autoadministrados para utilizar `kube-system` en las asignaciones de elección de líderes, por ejemplo:
```
helm upgrade --install ack-s3-controller \
oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
--namespace ack-system \
--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 ACK en el clúster (consulte [Creación de una capacidad de ACK](create-ack-capability.md)).
1. La capacidad administrada reconoce los recursos de AWS administrados por ACK existentes y se encarga de la conciliación.
1. Reduzca verticalmente o elimine de forma gradual las implementaciones de controladores autoadministrados:
```
helm uninstall ack-s3-controller --namespace ack-system
```
Este enfoque permite que ambos controladores coexistan de forma segura durante la migración. La capacidad administrada adopta automáticamente los recursos que antes administraban los controladores autoadministrados, lo que garantiza una conciliación continua sin conflictos.
## Siguientes pasos
+ [Creación de una capacidad de ACK](create-ack-capability.md): creación de un recurso con la capacidad de ACK
+ [Conceptos de ACK](ack-concepts.md): descripción de los conceptos de ACK y el ciclo de vida de los recursos
+ [Configuración de los permisos de ACK](ack-permissions.md): configuración de IAM y permisos
# Implementación continua con Argo CD
Argo CD es una herramienta declarativa de entrega continua de GitOps para Kubernetes. Con Argo CD, puede automatizar la implementación y la administración del ciclo de vida de sus aplicaciones en múltiples clústeres y entornos. Argo CD admite varios tipos de orígenes, como los repositorios de Git, los registros de Helm (HTTP y OCI) y las imágenes de OCI, lo que proporciona flexibilidad a las organizaciones con diferentes requisitos de seguridad y cumplimiento.
Con las capacidades de EKS, AWS administra Argo CD completamente, lo que elimina la necesidad de instalar, mantener y escalar los controladores de Argo CD y sus dependencias en sus clústeres.
## Cómo funciona Argo CD
Argo CD sigue el patrón de GitOps, donde el origen de la aplicación (repositorio de Git, registro de Helm o imagen de OCI) es el origen de información verdadera para definir el estado de la aplicación deseado. Al crear un recurso `Application` de Argo CD, especifique un origen que contenga los manifiestos de la aplicación y un espacio de nombres y un clúster de Kubernetes de destino. Argo CD supervisa de forma continua tanto el origen como el estado activo del clúster y sincroniza automáticamente cualquier cambio para garantizar que el estado del clúster coincida con el estado deseado.
**nota**
Con la capacidad de EKS para Argo CD, el software de Argo CD se ejecuta en el plano de control de AWS, no en los nodos de trabajo. Esto significa que sus nodos de trabajo no necesitan acceso directo a los repositorios de Git o a los registros de Helm, ya que la capacidad gestiona el acceso al origen desde la cuenta de AWS.
Argo CD proporciona tres tipos de recursos principales:
+ **Aplicación**: define una implementación desde un repositorio de Git a un clúster de destino.
+ **ApplicationSet**: genera múltiples aplicaciones a partir de plantillas para implementaciones de varios clústeres.
+ **AppProject**: proporciona agrupamiento lógico y control de acceso para las aplicaciones.
**Ejemplo: creación de una aplicación de Argo CD**
En el ejemplo siguiente, se muestra cómo crear un recurso `Application` de Argo CD:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
```
**nota**
Utilice `destination.name` con el nombre del clúster que utilizó al registrar el clúster (como `in-cluster` para el clúster local). El campo `destination.server` también funciona con los ARN de clústeres de EKS, pero se recomienda utilizar los nombres de los clústeres para una mejor legibilidad.
## Ventajas de Argo CD
Argo CD implementa un flujo de trabajo de GitOps en el que define las configuraciones de las aplicaciones en los repositorios de Git y Argo CD sincroniza automáticamente las aplicaciones para que coincidan con el estado deseado. Este enfoque centrado en Git proporciona un registro de auditoría completo de todos los cambios, permite revertirlos fácilmente y se integra de forma natural con sus procesos de revisión y aprobación de código existentes. Argo CD detecta y concilia automáticamente la diferencia entre el estado deseado en Git y el estado real de los clústeres, lo que garantiza que las implementaciones se mantengan coherentes con la configuración declarada.
Con Argo CD, puede implementar y administrar aplicaciones en varios clústeres desde una única instancia de Argo CD, lo que simplifica las operaciones en entornos de varios clústeres y regiones. La interfaz de usuario de Argo CD ofrece capacidades de visualización y supervisión, lo que le permite ver el estado de la implementación, el estado y el historial de sus aplicaciones. La interfaz de usuario se integra con AWS Identity Center (anteriormente AWS SSO) para una autenticación y autorización fluidas, lo que le permite controlar el acceso mediante su infraestructura de administración de identidades existente.
Como parte de las capacidades administradas de EKS, AWS administra completamente Argo CD, lo que elimina la necesidad de instalar, configurar y mantener la infraestructura de Argo CD. AWS administra el escalado, la aplicación de parches y la administración operativa, lo que permite a sus equipos centrarse en la entrega de la aplicación y no en el mantenimiento de la herramienta.
## Integración con AWS Identity Center
Las capacidades administradas de EKS proporcionan una integración directa entre Argo CD y AWS Identity Center, lo que permite una autenticación y autorización fluidas para sus usuarios. Al activar la capacidad de Argo CD, puede configurar la integración de AWS Identity Center para asignar los grupos y usuarios de Identity Center a los roles de RBAC de Argo CD, lo que le permite controlar quién puede acceder a las aplicaciones de Argo CD y administrarlas.
## Integración con otras capacidades administradas de EKS
Argo CD se integra con otras capacidades administradas de EKS.
+ **Controladores de AWS para Kubernetes (ACK)**: utilice Argo CD para administrar la implementación de los recursos de ACK en varios clústeres, lo que activa los flujos de trabajo de GitOps para su infraestructura de AWS.
+ **kro (Kube Resource Orchestrator)**: utilice Argo CD para implementar composiciones de kro en varios clústeres, lo que permite una composición uniforme de los recursos en todo el entorno de Kubernetes.
## Introducción a Argo CD
Para comenzar a utilizar la capacidad de EKS para Argo CD:
1. Cree y configure un rol de capacidad de IAM con los permisos necesarios para que Argo CD acceda a los orígenes y administre aplicaciones.
1. [Cree un recurso de capacidad de Argo CD](create-argocd-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. Configure el acceso al repositorio y registre los clústeres para la implementación de aplicaciones.
1. Cree recursos de aplicación para implementar las aplicaciones desde los orígenes declarativos.
# Creación de una capacidad de Argo CD
En este tema, se explica cómo crear una capacidad de Argo CD en un clúster de Amazon EKS.
## Requisitos previos
Antes de crear una capacidad de Argo CD, 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)
+ **AWS Identity Center configurado**: necesario para la autenticación de Argo CD (no se admiten los usuarios locales)
+ Un rol de capacidad de IAM con permisos para Argo CD
+ Permisos de IAM suficientes para crear recursos de capacidad en los clústeres de EKS
+ `kubectl` configurado para comunicarse con el clúster
+ (Opcional) La CLI de Argo CD instalada para facilitar la administración de clústeres y repositorios
+ (Para la CLI o eksctl) La herramienta de la CLI adecuada instalada y configurada
Para obtener instrucciones sobre cómo crear el rol de capacidad de IAM, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md). Para obtener la configuración de Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html).
**importante**
El rol de capacidad de IAM que proporcione determina a qué recursos de AWS puede acceder Argo CD. Esto incluye el acceso al repositorio de Git a través de CodeConnections y los secretos en Secrets Manager. Para obtener orientación sobre cómo crear un rol adecuado con los permisos de privilegio mínimo, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Elección de la herramienta
Puede crear una capacidad de Argo CD mediante la Consola de administración de AWS, la AWS CLI o eksctl:
+ [Creación de una capacidad de Argo CD mediante la consola](argocd-create-console.md): uso de la consola para una experiencia guiada
+ [Creación de una capacidad de Argo CD mediante la AWS CLI](argocd-create-cli.md): uso de la AWS CLI para scripts y automatización
+ [Creación de una capacidad de Argo CD mediante eksctl](argocd-create-eksctl.md): uso de eksctl para una experiencia nativa de Kubernetes
## Qué ocurre cuando se crea una capacidad de Argo CD
Cuando crea una capacidad de Argo CD:
1. EKS crea el servicio de capacidad de Argo CD en el plano de control de AWS.
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 políticas de entrada de acceso específicas de la capacidad que conceden permisos básicos de Kubernetes (consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md)).
1. Argo CD comienza a supervisar sus recursos personalizados (Aplicaciones, ApplicationSets, AppProjects)
1. El estado de la capacidad cambia de `CREATING` a `ACTIVE`.
1. La interfaz de usuario de Argo CD pasa a estar accesible a través de su URL
Una vez activa, puede crear Aplicaciones de Argo CD en el clúster para implementar desde los orígenes declarativos.
**nota**
La entrada de acceso creada automáticamente no concede permisos para implementar aplicaciones en clústeres. Para implementar aplicaciones, debe configurar permisos adicionales de control de acceso basado en roles de Kubernetes para cada clúster de destino. Consulte [Registro de clústeres de destino](argocd-register-clusters.md) para obtener detalles sobre cómo registrar clústeres y configurar el acceso.
## Siguientes pasos
Después de crear la capacidad de Argo CD:
+ [Conceptos de Argo CD](argocd-concepts.md): más información sobre los principios de GitOps, las políticas de sincronización y los patrones de varios clústeres
+ [Uso de Argo CD](working-with-argocd.md): configuración del acceso a repositorios, registro de clústeres de destino y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): exploración de los patrones de arquitectura de varios clústeres y configuración avanzada
# Creación de una capacidad de Argo CD mediante la consola
En este tema, se describe cómo crear una capacidad de Argo CD mediante la Consola de administración de AWS.
## Requisitos previos
+ ** AWS Identity Center configurado**: Argo CD requiere AWS Identity Center para la autenticación. No se admiten usuarios locales. Si no ha configurado AWS Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para crear una instancia de Identity Center y [Adición de usuarios](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) y [Adición de grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para crear usuarios y grupos a fin de acceder a Argo CD.
## Creación de la capacidad de Argo CD
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 panel de navegación izquierdo, elija **Argo CD**.
1. Elija **Crear capacidad de Argo CD**.
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 Argo CD**.
De este modo, se abre la consola de IAM en una nueva pestaña con la política de confianza rellenada previamente y el acceso completo de lectura a Secrets Manager. No se agrega ningún otro permiso de forma predeterminada, pero puede agregarlos si es necesario. Si tiene previsto usar los repositorios de CodeCommit u otros servicios de AWS, agregue los permisos adecuados antes de crear el rol.
Después de crear el rol, regrese a la consola de EKS y el rol se seleccionará automáticamente.
**nota**
Si tiene previsto usar las integraciones opcionales con AWS Secrets Manager o AWS CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
1. Configure la integración de AWS Identity Center:
1. Seleccione **Habilitar la integración de AWS Identity Center**.
1. Elija su instancia de Identity Center en el menú desplegable.
1. Para configurar las asignaciones de roles para RBAC, asigne usuarios o grupos a los roles de Argo CD (ADMIN, EDITOR o VIEWER)
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 Argo CD.
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).
## Acceso a la interfaz de usuario de Argo CD
Después de que la capacidad esté activa, puede acceder a la interfaz de usuario de Argo CD:
1. En la página de la capacidad de Argo CD, seleccione **Abrir la interfaz de usuario de Argo CD**.
1. La interfaz de usuario de Argo CD se abre en una nueva pestaña del navegador.
1. Ahora puede crear aplicaciones y administrar las implementaciones a través de la interfaz de usuario.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): configuración de repositorios, registro de clústeres y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): arquitectura de varios clústeres y configuración avanzada
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Creación de una capacidad de Argo CD mediante la AWS CLI
En este tema, se describe cómo crear una capacidad de Argo CD 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).
+ ** AWS Identity Center configurado**: Argo CD requiere AWS Identity Center para la autenticación. No se admiten usuarios locales. Si no ha configurado AWS Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para crear una instancia de Identity Center y [Adición de usuarios](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) y [Adición de grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para crear usuarios y grupos a fin de acceder a Argo CD.
## Paso 1: creación de un rol de capacidad de IAM
Cree un archivo de política de confianza:
```
cat > argocd-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 ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Si tiene previsto usar las integraciones opcionales con AWS Secrets Manager o AWS CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
## Paso 2: creación de la capacidad de Argo CD
Cree el recurso de la capacidad de Argo CD en su clúster.
En primer lugar, defina las variables de entorno para la configuración de Identity Center:
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
Cree la capacidad con la integración de Identity Center. Sustituya *region-code* por la región de AWS donde se encuentra el clúster, *my-cluster* por el nombre del clúster e *idc-region-code* por el código de la región donde se ha configurado el IAM Identity Center:
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
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 en la que se encuentra el clúster y *my-cluster* por el nombre del clúster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`. No continúe con el paso siguiente hasta que el estado sea `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-argocd
```
## Paso 4: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de Argo CD estén disponibles en el clúster:
```
kubectl api-resources | grep argoproj.io
```
Debería ver todos los tipos de recursos `Application` y `ApplicationSet` en la lista.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): configuración de repositorios, registro de clústeres y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): arquitectura de varios clústeres y configuración avanzada
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Creación de una capacidad de Argo CD mediante eksctl
En este tema, se describe cómo crear una capacidad de Argo CD 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 > argocd-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 ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Para esta configuración básica, no se necesitan políticas de IAM adicionales. Si tiene previsto usar Secrets Manager para las credenciales del repositorio o CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
## Paso 2: obtención de la configuración de AWS Identity Center
Obtenga el ARN y el ID de usuario de su instancia de Identity Center para la configuración de RBAC:
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
Anote estos valores, ya que los necesitará en el siguiente paso.
## Paso 3: creación de un archivo de configuración de eksctl
Cree un archivo llamado `argocd-capability.yaml` con el siguiente contenido. Sustituya los valores de marcador de posición por el nombre del clúster, la región del clúster, el ARN del rol de IAM, el ARN de la instancia de Identity Center, la región de Identity Center y el ID de usuario:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**nota**
Puede agregar varios usuarios o grupos a las asignaciones de RBAC. Para los grupos, utilice `type: SSO_GROUP` y proporcione el ID del grupo. Los roles disponibles son `ADMIN`, `EDITOR` y `VIEWER`.
## Paso 4: creación de la capacidad de Argo CD
Aplique el archivo de configuración:
```
eksctl create capability -f argocd-capability.yaml
```
El comando vuelve inmediatamente, pero la capacidad tarda algún tiempo en activarse.
## Paso 5: 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-argocd
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`.
## Paso 6: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de Argo CD estén disponibles en el clúster:
```
kubectl api-resources | grep argoproj.io
```
Debería ver todos los tipos de recursos `Application` y `ApplicationSet` en la lista.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): más información sobre cómo crear y administrar aplicaciones de Argo CD
+ [Consideraciones sobre Argo CD](argocd-considerations.md): configuración del SSO y el acceso a varios clústeres
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Conceptos de Argo CD
Para implementar GitOps, Argo CD trata a Git como el único origen de información para las implementaciones de aplicaciones. 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 Argo CD.
## Introducción a Argo CD
Después de crear la capacidad de Argo CD (consulte [Creación de una capacidad de Argo CD](create-argocd-capability.md)), puede comenzar a implementar aplicaciones. En este ejemplo, se explica el registro de un clúster y la creación de una aplicación.
### Paso 1: Configurar
**Registro del clúster** (obligatorio)
Registre el clúster en el que desea implementar las aplicaciones. En este ejemplo, registraremos el mismo clúster en el que se ejecuta Argo CD (puede usar el nombre `in-cluster` por motivos de compatibilidad con la mayoría de los ejemplos de Argo CD):
```
# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
--name my-cluster \
--query 'cluster.arn' \
--output text)
# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
--aws-cluster-name $CLUSTER_ARN \
--name in-cluster \
--project default
```
**nota**
Para obtener información sobre cómo configurar la CLI de Argo CD para que funcione con la capacidad de Argo CD en EKS, consulte [Uso de la CLI de Argo CD con la capacidad administrada](argocd-comparison.md#argocd-cli-configuration).
Como alternativa, registre el clúster mediante un secreto de Kubernetes (consulte [Registro de clústeres de destino](argocd-register-clusters.md) para obtener más información).
**Configuración del acceso al repositorio** (opcional)
En este ejemplo, se usa un repositorio de GitHub público, por lo que no se requiere ninguna configuración del repositorio. Para los repositorios privados, configure el acceso mediante AWS Secrets Manager, CodeConnections o secretos de Kubernetes (consulte [Configuración del acceso al repositorio](argocd-configure-repositories.md) para obtener más información).
Para los servicios de AWS (ECR para gráficos de Helm, CodeConnections y CodeCommit), puede hacer referencia a ellos directamente en los recursos de la aplicación sin necesidad de crear un repositorio. El rol de capacidad debe tener los permisos para llamar a los permisos de IAM necesarios. Para obtener más información, consulte [Configuración del acceso al repositorio](argocd-configure-repositories.md).
### Paso 2: Cree una aplicación
Cree este manifiesto de aplicación en `my-app.yaml`:
```
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
name: in-cluster
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
```
Aplique la aplicación:
```
kubectl apply -f my-app.yaml
```
Después de aplicar esta aplicación, Argo CD: 1. Sincroniza la aplicación de Git con el clúster (implementación inicial). 2. Supervisa el repositorio de Git para detectar cambios. 3. Sincroniza automáticamente los cambios posteriores en el clúster. 4. Detecta y corrige cualquier desviación del estado deseado. 5. Proporciona el estado y el historial de sincronización en la interfaz de usuario.
Consulte el estado de la aplicación:
```
kubectl get application guestbook -n argocd
```
También puede ver la aplicación mediante la CLI de Argo CD o la interfaz de usuario de Argo CD (accesible desde la consola de EKS, en la pestaña Capacidades del clúster).
**nota**
Cuando utilice la CLI de Argo CD con la capacidad administrada, especifique las aplicaciones con el prefijo de espacio de nombres: `argocd app get argocd/guestbook`.
**nota**
Utilice el nombre del clúster en `destination.name` (el nombre que utilizó al registrar el clúster). La capacidad administrada no admite el valor predeterminado local en el clúster (`kubernetes.default.svc`).
## Conceptos clave
### Principios y tipos de orígenes de GitOps
Argo CD implementa GitOps, donde el origen de la aplicación es el único origen de información para las implementaciones:
+ **Declarativo**: el estado deseado se declara mediante manifiestos de YAML, gráficos de Helm o superposiciones de Kustomize.
+ **Con control de versiones**: se hace un seguimiento de cada cambio con un registro de auditoría completo.
+ **Automatizado**: Argo CD supervisa continuamente los orígenes y sincroniza automáticamente los cambios.
+ **Recuperación automática**: detecta y corrige una desviación entre el estado deseado y el real del clúster.
**Tipos de orígenes compatibles**:
+ **Repositorios de Git**: GitHub, GitLab, Bitbucket, CodeCommit (HTTPS, SSH o CodeConnections)
+ **Registros de Helm**: registros HTTP (como `https://aws.github.io/eks-charts`) y registros OCI (como `public.ecr.aws`)
+ **Imágenes OCI**: imágenes de contenedor que incluyen manifiestos o gráficos de Helm (como `oci://registry-1.docker.io/user/my-app`)
Esta flexibilidad permite a las organizaciones elegir orígenes que cumplan con sus requisitos de seguridad y conformidad. Por ejemplo, las organizaciones que restringen el acceso a Git desde clústeres pueden usar ECR para gráficos de Helm o imágenes OCI.
Para obtener más información, consulte [Application Sources](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/) en la documentación de Argo CD.
### Sincronización y conciliación
Argo CD supervisa continuamente sus orígenes y clústeres para detectar y corregir las diferencias:
1. Sondea los orígenes para ver si hay cambios (de forma predeterminada, cada 6 minutos).
1. Compara el estado deseado con el estado del clúster.
1. Marca las aplicaciones como `Synced` o `OutOfSync`.
1. Sincroniza los cambios automáticamente (si se configuró) o espera su aprobación manual.
1. Supervisa el estado de los recursos después de la sincronización.
Las **ondas de sincronización** controlan el orden de creación de los recursos mediante anotaciones:
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
Los recursos se aplican por orden de onda (primero, los números más bajos, incluidos los negativos, como `-1`). La fase `0` es la predeterminada si no se especifica. Esto permite crear dependencias como espacios de nombres (fase `-1`), antes de las implementaciones (fase `0`) y antes de los servicios (fase `1`).
La **recuperación automática** revierte los cambios manuales:
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**nota**
La capacidad administrada utiliza el seguimiento de recursos basado en anotaciones (no en etiquetas) para mejorar la compatibilidad con las convenciones de Kubernetes y otras herramientas.
Para obtener información detallada sobre las fases de la sincronización, los enlaces y los patrones avanzados, consulte la [documentación de sincronización de Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/).
### Estado de la aplicación
Argo CD supervisa el estado de todos los recursos de la aplicación:
**Estados**: \$1 **En buen estado** (todos los recursos se ejecutan según lo esperado) \$1 **En curso** (los recursos se están creando o actualizando) \$1 **Degradado** (algunos recursos no están en buen estado: bloqueo de pods, errores de trabajos) \$1 **Suspendido** (la aplicación se pausó de forma intencionada) \$1 **Falta** (los recursos definidos en Git no están en el clúster)
Argo CD tiene comprobaciones de estado integradas para los recursos comunes de Kubernetes (implementaciones, StatefulSets, trabajos, etc.) y admite comprobaciones de estado personalizadas para CRD.
El estado de la aplicación viene determinado por todos sus recursos: si hay algún recurso `Degraded`, el estado de la aplicación será `Degraded`.
Para obtener más información, consulte [Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) en la documentación de Argo CD.
### Patrones de varios clústeres
Argo CD admite dos patrones de implementación principales:
**Radial**: ejecute Argo CD en un clúster de administración dedicado que se implemente en varios clústeres de cargas de trabajo. \$1 Control y visibilidad centralizados \$1 Políticas coherentes en todos los clústeres \$1 Una instancia de Argo CD que administrar \$1 Separación clara entre el plano de control y las cargas de trabajo
**Por clúster**: ejecute Argo CD en cada clúster y administre solo las aplicaciones de ese clúster. \$1 Separación de clústeres (un error no afecta a los demás) \$1 Redes más sencillas (sin comunicación entre clústeres) \$1 Configuración inicial más sencilla (sin registro de clústeres)
Elija la opción radial para los equipos de plataformas que administran varios clústeres, o la opción por clúster para equipos independientes o cuando los clústeres deban estar completamente aislados.
Para obtener información detallada sobre la configuración de varios clústeres, consulte [Consideraciones sobre Argo CD](argocd-considerations.md).
### Proyectos
Los proyectos proporcionan agrupamiento lógico y control de acceso para las aplicaciones:
+ **Restricciones de origen**: limite los repositorios de Git que se pueden usar.
+ **Restricciones de destino**: limite los clústeres y espacios de nombres que se pueden usar como destino.
+ **Restricciones de recursos**: limite los tipos de recursos de Kubernetes que se pueden implementar.
+ **Integración con RBAC**: asigne proyectos a ID de usuarios y grupos de AWS Identity Center.
Las aplicaciones pertenecen a un único proyecto. Si no se especifica, utilizan el proyecto `default`, que no tiene restricciones de forma predeterminada. Para uso en producción, edite el proyecto `default` para restringir el acceso y cree nuevos proyectos con las restricciones adecuadas.
Para obtener información sobre la configuración de proyectos y los patrones RBAC, consulte [Configuración de los permisos de Argo CD](argocd-permissions.md).
### Opciones de sincronización
Refine el comportamiento de la sincronización con opciones comunes:
+ `CreateNamespace=true`: se crea automáticamente el espacio de nombres de destino.
+ `ServerSideApply=true`: se utiliza la aplicación del servidor para una mejor resolución de conflictos.
+ `SkipDryRunOnMissingResource=true`: se omite la ejecución de prueba cuando las CRD aún no existan (útil para instancias de kro).
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
Para obtener una lista completa de las opciones de sincronización, consulte la [documentación sobre las opciones de sincronización de Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/).
## Siguientes pasos
+ [Configuración del acceso al repositorio](argocd-configure-repositories.md): configuración del acceso al repositorio de Git
+ [Registro de clústeres de destino](argocd-register-clusters.md): registro de los clústeres de destino para la implementación
+ [Creación de aplicaciones](argocd-create-application.md): creación de la primera aplicación
+ [Consideraciones sobre Argo CD](argocd-considerations.md): patrones específicos de EKS, integración con Identity Center y configuración de varios clústeres
+ [Documentación de Argo CD](https://argo-cd.readthedocs.io/en/stable/): documentación completa de Argo CD que incluye enlaces de sincronización, comprobaciones de estado y patrones avanzados
# Configuración de los permisos de Argo CD
La capacidad administrada de Argo CD se integra con AWS Identity Center para la autenticación y utiliza roles de RBAC integrados para la autorización. En este tema, se explica cómo configurar los permisos para los usuarios y los equipos.
## Cómo funcionan los permisos con Argo CD
La capacidad de Argo CD utiliza AWS Identity Center para la autenticación y proporciona tres roles de RBAC integrados para la autorización.
Cuando un usuario accede a Argo CD:
1. Se autentican mediante AWS Identity Center (que puede federarse con su proveedor de identidad corporativa)
1. AWS Identity Center proporciona información sobre los usuarios y grupos a Argo CD
1. Argo CD asigna usuarios y grupos a roles de RBAC en función de su configuración
1. Los usuarios solo ven las aplicaciones y los recursos a los que tienen permiso de acceso
## Roles de RBAC integrados
La capacidad de Argo CD proporciona tres roles integrados que se asignan a los usuarios y grupos de AWS Identity Center. Son **roles con alcance global** que controlan el acceso a recursos de Argo CD, como proyectos, clústeres y repositorios.
**importante**
Los roles globales controlan el acceso a Argo CD en sí, no a recursos con alcance de proyecto, como las aplicaciones. Los usuarios Editor y Visualizador no pueden ver ni administrar aplicaciones de forma predeterminada; necesitan roles de proyecto para acceder a recursos con alcance de proyecto. Consulte [Roles de proyecto y acceso con alcance de proyecto](#project-roles) para obtener más información sobre cómo conceder acceso a las aplicaciones y a otros recursos con alcance de proyecto.
**ADMIN**
Acceso completo a todos los recursos y configuraciones de Argo CD:
+ Crear, actualizar y eliminar aplicaciones y ApplicationSets en cualquier proyecto
+ Administración de la configuración de Argo CD
+ Registro y administración de los clústeres de destino de la implementación
+ Configuración del acceso al repositorio
+ Crear y administrar proyectos
+ Visualización del estado y el historial de todas las aplicaciones
+ Enumerar y acceder a todos los clústeres y repositorios
**EDITOR**
Puede actualizar proyectos y configurar roles de proyecto, pero no puede modificar la configuración global de Argo CD:
+ Actualizar proyectos existentes (no puede crear ni eliminar proyectos)
+ Configurar roles y permisos de proyecto
+ Ver claves GPG y certificados
+ No puede modificar la configuración global de Argo CD
+ No puede administrar clústeres ni repositorios directamente
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**VIEWER**
Acceso de solo lectura a los recursos de Argo CD:
+ Ver configuraciones de proyectos
+ Enumerar todos los proyectos (incluidos los proyectos a los que el usuario no está asignado)
+ Ver claves GPG y certificados
+ No puede enumerar clústeres ni repositorios
+ Imposibilidad de hacer cambios
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**nota**
Para conceder a los usuarios Editor o Visualizador acceso a las aplicaciones, un Administrador o un Editor debe crear roles de proyecto que asignen grupos de Identity Center a permisos específicos dentro de un proyecto.
## Roles de proyecto y acceso con alcance de proyecto
Los roles globales Administrador, Editor y Visualizador controlan el acceso a Argo CD en sí. Los roles de proyecto controlan el acceso a los recursos y las capacidades dentro de un proyecto específico, incluidos:
+ **Recursos**: aplicaciones, ApplicationSets, credenciales de repositorios y credenciales de clústeres
+ **Capacidades**: acceso a registros y acceso de ejecución (exec) a los pods de aplicaciones
**Explicación del modelo de permisos de dos niveles**:
+ **Alcance global**: los roles integrados determinan lo que los usuarios pueden hacer con los proyectos, los clústeres, los repositorios y la configuración de Argo CD
+ **Alcance de proyecto**: los roles de proyecto determinan lo que los usuarios pueden hacer con los recursos y las capacidades dentro de un proyecto específico
Esto significa:
+ Los usuarios Administrador pueden acceder a todos los recursos y capacidades de los proyectos sin configuración adicional
+ Los usuarios Editor y Visualizador deben recibir roles de proyecto para acceder a los recursos y las capacidades del proyecto
+ Los usuarios Editor pueden crear roles de proyecto para concederse a sí mismos y a otros acceso dentro de los proyectos que pueden actualizar
**Flujo de trabajo de ejemplo**:
1. Un Administrador asigna un grupo de Identity Center al rol Editor a nivel global
1. Un Administrador crea un proyecto para un equipo
1. El Editor configura roles de proyecto dentro de ese proyecto para conceder a los miembros del equipo acceso a recursos con alcance de proyecto
1. Los miembros del equipo (que pueden tener el rol global Visualizador) ahora pueden ver y administrar aplicaciones en ese proyecto según los permisos de su rol de proyecto
Para obtener más información sobre la configuración de roles de proyecto, consulte [Control de acceso basado en proyectos](#_project_based_access_control).
## Configuración de las asignaciones de roles
Asigne los usuarios y grupos de AWS Identity Center a los roles de Argo CD al crear o actualizar la capacidad.
**Ejemplo de asignación de roles**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**nota**
Los nombres de los roles distinguen entre mayúsculas y minúsculas y deben estar en mayúsculas (ADMIN, EDITOR, VIEWER).
**importante**
La integración de capacidades de EKS con AWS Identity Center admite hasta 1000 identidades por capacidad de Argo CD. Una identidad puede ser un usuario o un grupo.
**Actualice las asignaciones de roles**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## Uso de la cuenta de administrador
La cuenta de administrador está diseñada para la configuración inicial y las tareas administrativas, como el registro de clústeres y la configuración de repositorios.
**Cuándo es adecuado usar la cuenta de administrador**:
+ Configuración inicial de la capacidad
+ Desarrollo individual o demostraciones rápidas
+ Tareas administrativas (registro de clústeres, configuración de repositorios, creación de proyectos)
**Prácticas recomendadas para la cuenta de administrador**:
+ No asigne tokens de la cuenta al control de versiones.
+ Cambie los tokens inmediatamente si se han expuesto.
+ Limite el uso de los tokens de la cuenta a las tareas administrativas y de configuración.
+ Establezca tiempos de vencimiento cortos (máximo 12 horas).
+ Solo se pueden crear 5 tokens de la cuenta en un momento determinado.
**Cuándo se usa el acceso basado en proyectos**:
+ Entornos de desarrollo compartidos con varios usuarios
+ Cualquier entorno que se asemeje al de producción
+ Cuando necesite registros de auditoría sobre quién llevó a cabo las acciones
+ Cuando necesite aplicar restricciones de recursos o límites de acceso
Para entornos de producción y escenarios de varios usuarios, utilice el control de acceso basado en proyectos con roles de RBAC dedicados asignados a grupos de AWS Identity Center.
## Control de acceso basado en proyectos
Utilice proyectos de Argo CD (AppProject) para proporcionar un control del acceso y un aislamiento de los recursos detallados para los equipos.
**importante**
Antes de asignar usuarios o grupos a roles específicos de proyecto, primero debe asignarlos a un rol global de Argo CD (Administrador, Editor o Visualizador) en la configuración de la capacidad. Los usuarios no pueden acceder a Argo CD sin una asignación a un rol global, incluso si están asignados a roles de proyecto.
Considere asignar a los usuarios el rol Visualizador a nivel global y, posteriormente, conceder permisos adicionales mediante roles específicos de proyecto. Esto proporciona un acceso básico y permite un control detallado a nivel de proyecto.
Los proyectos proporcionan lo siguiente:
+ **Restricciones de origen**: limite los repositorios de Git que se pueden usar.
+ **Restricciones de destino**: limite los clústeres y espacios de nombres que se pueden usar como destino.
+ **Restricciones de recursos**: limite los tipos de recursos de Kubernetes que se pueden implementar.
+ **Integración con RBAC**: asigne los proyectos a grupos de AWS Identity Center o roles de Argo CD.
**Ejemplo de proyecto para el aislamiento de equipos**:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### Espacios de nombres de origen
Cuando se utiliza la capacidad de Argo CD en EKS, el campo `spec.sourceNamespaces` es obligatorio en las definiciones de AppProject. Este campo especifica qué espacio de nombres puede contener aplicaciones o ApplicationSets que hagan referencia a este proyecto.
**importante**
La capacidad de Argo CD en EKS solo admite un único espacio de nombres para las aplicaciones y los ApplicationSets: el espacio de nombres que especificó al crear la capacidad (normalmente, `argocd`). Esto difiere de Argo CD de código abierto, que admite múltiples espacios de nombres.
**Configuración de AppProject**
Todos los AppProjects deben incluir el espacio de nombres configurado de la capacidad en `sourceNamespaces`:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**nota**
Si omite el espacio de nombres de la capacidad en `sourceNamespaces`, las aplicaciones o los ApplicationSets de ese espacio de nombres no podrán hacer referencia a este proyecto, lo que provocará errores en la implementación.
**Asigne usuarios a los proyectos**:
Los roles de proyecto conceden a los usuarios Editor y Visualizador acceso a los recursos del proyecto (aplicaciones, ApplicationSets y credenciales de repositorios y clústeres) y a las capacidades (registros y ejecución [exec]). Sin roles de proyecto, estos usuarios no pueden acceder a estos recursos, incluso si tienen acceso mediante un rol global.
Los usuarios Administrador tienen acceso a todas las aplicaciones sin necesidad de roles de proyecto.
**Ejemplo: concesión de acceso a aplicaciones a los miembros del equipo**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**nota**
Incluya `clusters, get, *, allow` en los roles de proyecto para permitir que los usuarios vean los nombres de los clústeres en la interfaz de usuario. Sin este permiso, el clúster de destino aparece como “desconocido”.
**Explicación sobre las políticas de los roles de proyecto**:
El formato de la política es: `p, proj::, , ,