Consideraciones sobre ACK para EKS - Amazon EKS
Patrones de configuración de IAMIntegración con otras capacidades de EKSOrganización de los recursosMigración desde otras herramientas de infraestructura como códigoPolíticas de eliminaciónDocumentación ascendenteSiguientes pasos

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.

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.

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.

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 + copias de seguridad + 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 + cola de SQS + configuración de notificaciones

  • Configuración de la base de datos: instancia de RDS + grupo de parámetros + grupo de seguridad + secretos

  • Redes: VPC + subredes + tablas de enrutamiento + 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.

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

EKS aplica automáticamente etiquetas a los recursos de AWS administrados por ACK, lo que incluye el ARN del recurso de la capacidad. Agregue etiquetas adicionales para la asignación de costos, el seguimiento de la propiedad y fines organizativos.

Etiquetas recomendadas:

  • 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

  • ManagedBy: ACK (para identificar los recursos administrados por ACK)

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.

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.

Documentación ascendente

Para obtener información detallada sobre el uso de ACK:

Siguientes pasos