**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.
# 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