**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.
# Más información sobre los modos y la configuración de CNI de VPC
El complemento CNI de Amazon VPC para Kubernetes proporciona redes para pods. Utilice la siguiente tabla para obtener más información sobre las características de red disponibles.
| Características de red | Más información |
| --- | --- |
| Configuración del clúster para asignar direcciones IPv6 a los clústeres, pods y servicios | [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md) |
| Uso de la traducción de direcciones de red de origen IPv4 para pods | [Habilitación del acceso a Internet saliente para pods](external-snat.md) |
| Restricción del tráfico de red de entrada y salida de pods | [Restricción del tráfico de red de pods con políticas de red de Kubernetes](cni-network-policy-configure.md) |
| Personalización de la interfaz de red secundaria en los nodos | [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md) |
| Aumento de las direcciones IP para nodos | [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md) |
| Uso de grupos de seguridad para el tráfico de red del pod | [Asignación de los grupos de seguridad a pods individuales](security-groups-for-pods.md) |
| Uso de varias interfaces de red para pods | [Conexión de múltiples interfaces de red a pods](pod-multiple-network-interfaces.md) |
# Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios
**Aplicación**: pods con instancias de Amazon EC2 y pods de Fargate
De forma predeterminada, Kubernetes asigna direcciones `IPv4` a sus pods y servicios. En lugar de asignar direcciones `IPv4` a sus pods y servicios, puede configurar el clúster para que les asigne direcciones `IPv6`. Amazon EKS no admite servicios o pods de doble pila, aunque Kubernetes sí lo hace. Como resultado, no puede asignar ambos tipos de direcciones, `IPv4` e `IPv6`, a sus pods y servicios.
Selecciona qué familia IP desea utilizar para su clúster cuando lo cree. Una vez creado el clúster, no se puede cambiar la familia.
Para ver un tutorial sobre cómo implementar un clúster `IPv6` de Amazon EKS, consulte [Implementación de un clúster `IPv6` de Amazon EKS y nodos administrados de Amazon Linux](deploy-ipv6-cluster.md).
A continuación, se detallan consideraciones que se deben tener a la hora de utilizar esta característica:
## Compatibilidad de características de `IPv6`
+ **Incompatibilidad con Windows**: los pods y los servicios de Windows no son compatibles.
+ **Se requieren nodos EC2 basados en Nitro**: solo puede utilizar `IPv6` con nodos de Amazon EC2 o Fargate de AWS basados en Nitro.
+ **Compatible con nodos EC2 y Fargate**: se puede utilizar `IPv6` con [Asignación de los grupos de seguridad a pods individuales](security-groups-for-pods.md) y nodos de Amazon EC2 y Fargate.
+ **Outposts no compatibles**: no se puede utilizar `IPv6` con [Implementación de Amazon EKS en las instalaciones con AWS Outposts](eks-outposts.md).
+ **FSx for Lustre no es compatible**: [Uso del almacenamiento de aplicaciones de alto rendimiento con Amazon FSx para Lustre](fsx-csi.md) no es compatible.
+ **Redes personalizadas no compatibles**: si anteriormente utilizó [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md) para ayudar a aliviar el agotamiento de la dirección IP, puede utilizar `IPv6` en su lugar. No puede utilizar redes personalizadas con `IPv6`. Si utiliza redes personalizadas para el aislamiento de red, es posible que deba continuar utilizando redes personalizadas y la familia `IPv4` para sus clústeres.
## Asignaciones de dirección IP
+ **Servicios de Kubernetes**: a los servicios de Kubernetes solo se les asigna una dirección `IPv6`. No se les asigna direcciones IPv4.
+ **Pods**: a los pods se les asigna una dirección IPv6 y una dirección IPv4 local del host. La dirección IPv4 local del host se asigna mediante un complemento de la CNI local del host encadenado con la CNI de la VPC y la dirección no se informa al plano de control de Kubernetes. Solo se usa cuando un pod necesita comunicarse con un recurso IPv4 externo en otra Amazon VPC o en Internet. La dirección IPv4 local del host se asigna (mediante la CNI de la VPC) a la dirección IPv4 principal del ENI principal del nodo de trabajo.
+ **Pods y servicios**: los pods y servicios reciben solo direcciones `IPv6`, no direcciones `IPv4`. Cuando los pods necesitan comunicarse con puntos de conexión `IPv4` externos, utilizan la NAT en el propio nodo. Esta función NAT integrada elimina la necesidad de [DNS64 y NAT64](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-nat64-dns64). Para el tráfico que requiere acceso a Internet público, el tráfico del pod se convierte mediante la dirección de red de origen a una dirección IP pública.
+ **Direcciones de enrutamiento**: cuando un pod se comunica fuera de la VPC, se conserva su dirección `IPv6` original (no se traduce a la dirección `IPv6` del nodo). Este tráfico se enruta directamente a través de una puerta de enlace de Internet o una puerta de enlace de Internet de solo salida.
+ **Nodos**: a todos los nodos se les asignan una dirección `IPv4` e `IPv6`.
+ **Pods de Fargate**: cada pod de Fargate recibe una dirección `IPv6` de CIDR que se especifica para la subred en la que se implementa. La unidad de hardware subyacente que ejecuta pods de Fargate obtiene una dirección `IPv4` e `IPv6` única de los CIDR asignados a la subred en la que se implementa la unidad de hardware.
## Cómo utilizar `IPv6` con EKS
+ **Crear un nuevo clúster**: debe crear un nuevo clúster y especificar que desea utilizar la familia `IPv6` para ese clúster. No puede habilitar la familia `IPv6` para un clúster que haya actualizado desde una versión anterior. Para obtener instrucciones sobre cómo crear un clúster nuevo, consulte Consideraciones.
+ **Utilice la CNI de VPC reciente**: implemente la versión `1.10.1` de la CNI de Amazon VPC o posterior. Esta versión o una posterior se implementa de forma predeterminada. Una vez que implemente el complemento, no podrá revertir la versión del complemento CNI de Amazon VPC a una versión inferior a `1.10.1` sin eliminar primero todos los nodos de todos los grupos de nodos del clúster.
+ **Configurar CNI de la VPC para `IPv6`**: si utiliza nodos de Amazon EC2, debe configurar el complemento CNI de Amazon VPC con la delegación de prefijos IP e `IPv6`. Si elige la familia `IPv6` cuando cree el clúster, la versión `1.10.1` del complemento tendrá esta configuración como predeterminada. Este es el caso de un complemento autoadministrado o de Amazon EKS. Para obtener más información acerca de la delegación de prefijos IP, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md).
+ **Configurar las direcciones `IPv4` e `IPv6`**: cuando crea un clúster, la VPC y las subredes que especifique deben tener un bloque de CIDR `IPv6` asignado a la VPC y las subredes que especifica. También deben tener un bloque de CIDR `IPv4` asignado. Esto se debe a que, incluso si solo desea utilizar `IPv6`, una VPC necesita un bloque de CIDR `IPv4` para funcionar. Para obtener más información, consulte [Asociar un bloque de CIDR IPv6 a su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#vpc-associate-ipv6-cidr) en la Guía del usuario de Amazon VPC.
+ **Asignar de forma automática direcciones IPv6 a nodos:** cuando crea los nodos, debe especificar subredes que estén configuradas para asignar direcciones `IPv6` de forma automática. De lo contrario, no podrá implementar los nodos. Esta configuración está desactivada de forma predeterminada. Para obtener más información, consulte [Modificar el atributo de direccionamiento IPv6 de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-ipv6) en la Guía del usuario de Amazon VPC.
+ **Establecer las tablas de enrutamiento para que utilicen `IPv6`**: las tablas de enrutamiento que se asignen a las subredes deben tener rutas para direcciones `IPv6`. Para obtener más información, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la Guía del usuario de Amazon VPC.
+ **Establecer grupos de seguridad para `IPv6`**: sus grupos de seguridad deben permitir direcciones `IPv6`. Para obtener más información, consulte [Migración a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la Guía del usuario de Amazon VPC.
+ **Configure el equilibrador de carga**: utilice la versión `2.3.1` o posterior del Controlador del equilibrador de carga de AWS para equilibrar la carga de las aplicaciones HTTP mediante el [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) o el tráfico de red mediante el [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md) a pods `IPv6` a través de ambos equilibradores de carga en el modo IP, pero no en el modo de instancia. Para obtener más información, consulte [Enrutamiento del tráfico de internet con el controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md).
+ **Añadir política de IAM de `IPv6`**: debe adjuntar una política de IAM de `IPv6` al IAM de su rol de IAM de CNI o nodo de IAM. Entre los dos, le recomendamos que lo adjunte a un rol de IAM de CNI. Para obtener más información, consulte [Cree una política de IAM para clústeres que utilizan la familia `IPv6`](cni-iam-role.md#cni-iam-role-create-ipv6-policy) y [Paso 1: creación del rol de IAM del complemento CNI de Amazon VPC para Kubernetes](cni-iam-role.md#cni-iam-role-create-role).
+ **Evaluar todos los componentes**: realice una evaluación exhaustiva de las aplicaciones, los complementos de Amazon EKS y los servicios de AWS con los que se integra antes de implementar clústeres `IPv6`. Esto es para garantizar que todo funcione según lo esperado con `IPv6`.
# Implementación de un clúster `IPv6` de Amazon EKS y nodos administrados de Amazon Linux
En este tutorial, implementa una nube de Amazon VPC `IPv6`, un clúster de Amazon EKS con la familia `IPv6` y un grupo de nodos administrado con nodos de Amazon Linux de Amazon EC2. No se pueden implementar nodos de Windows de Amazon EC2 en un clúster `IPv6`. También puede implementar nodos de Fargate en su clúster, aunque esas instrucciones no se proporcionarán en este tema por motivos de simplicidad.
## Requisitos previos
Realice los siguientes pasos antes de comenzar el tutorial:
Instale y configure las siguientes herramientas y recursos que necesitará para crear y administrar un clúster de Amazon EKS.
+ Recomendamos que conozca toda la configuración e implemente un clúster con la configuración que satisfaga sus requisitos. Para obtener más información, consulte [Creación de un clúster de Amazon EKS](create-cluster.md), [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md) y las [Consideraciones](cni-ipv6.md) sobre este tema. Solo puede habilitar algunos ajustes de la configuración cuando cree su clúster.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es `1.29`, puede usar la versión `1.28`, `1.29` o `1.30` de `kubectl` con él. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ La entidad principal de seguridad de IAM que está utilizando debe contar con permisos para trabajar con los roles de IAM de Amazon EKS y los roles vinculados al servicio, AWS CloudFormation, además de una VPC y recursos relacionados. Para obtener más información, consulte [Acciones](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) y Uso de roles vinculados a servicios en la [Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html).
+ Si usa eksctl, instale la versión `0.215.0` o posterior en su equipo. Para instalar o actualizar esta versión, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*. Si utiliza AWS CloudShell, es posible que deba [instalar la versión 2.12.3 o posterior, o bien, la versión 1.27.160 o posterior de la CLI de AWS](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), ya que la versión predeterminada de la CLI de AWS instalada en AWS CloudShell puede ser una versión anterior.
Puede utilizar eksctl o la CLI para implementar un clúster `IPv6`.
## Implementación de un clúster IPv6 con eksctl
1. Creación del archivo `ipv6-cluster.yaml`. Copie el comando que sigue en su dispositivo. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:
+ Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
+ Reemplace *region-code* por cualquier región de AWS en la que se admita Amazon EKS. Para ver una lista de las regiones de AWS, consulte [Puntos de conexión y cuotas de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) en la Guía de referencia general de AWS.
+ El valor de `version` con la versión de su clúster. Para obtener más información, consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Reemplace *my-nodegroup* con un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales.
+ Reemplace *t3.medium* por cualquier [tipo de instancia de AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
cat >ipv6-cluster.yaml <
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confirme que a los servicios predeterminados se les asignan direcciones `IPv6`.
```
kubectl get services -n kube-system -o wide
```
Un ejemplo de salida sería el siguiente.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opcional) [Implemente una aplicación de muestra](sample-deployment.md) o implemente el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y una aplicación de muestra para equilibrar la carga de aplicaciones HTTP con [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) o el tráfico de red con [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md) en pods de `IPv6`.
1. Cuando haya terminado con el clúster y los nodos que creó para este tutorial, debería limpiar los recursos que creó con el siguiente comando.
```
eksctl delete cluster my-cluster
```
## Implementación de un clúster IPv6 con la CLI de AWS
**importante**
Debe completar todos los pasos de este procedimiento como el mismo usuario. Ejecute el siguiente comando para comprobar el usuario actual:
```
aws sts get-caller-identity
```
Debe completar todos los pasos de este procedimiento en el mismo intérprete de comandos. Varios pasos utilizan variables establecidas en pasos anteriores. Los pasos que utilizan variables no funcionarán de forma adecuada si los valores de las variables se establecen en un intérprete de comandos diferente. Si utiliza [AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html) para completar el siguiente procedimiento, recuerde que, si no interactúa con él a través del teclado o el puntero durante 20 o 30 minutos aproximadamente, se cerrará la sesión del intérprete de comandos. Los procesos en ejecución no cuentan como interacciones.
Las instrucciones están escritas para el intérprete de comandos Bash y es posible que deban ajustarse para otros intérpretes de comandos.
Reemplace todos los valores de ejemplo en los pasos de este procedimiento por sus propios valores.
1. Ejecute los siguientes comandos para establecer algunas variables utilizadas en pasos posteriores. Reemplace *region-code* por la región de AWS en la que desea implementar sus recursos. El valor puede ser cualquier región de AWS que sea compatible con Amazon EKS. Para ver una lista de las regiones de AWS, consulte [Puntos de conexión y cuotas de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) en la Guía de referencia general de AWS. Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Reemplace *my-nodegroup* con un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Reemplace *111122223333* por el ID de su cuenta.
```
export region_code=region-code
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
```
1. Cree una Amazon VPC con subredes privadas y públicas que cumplan con los requisitos de Amazon EKS y `IPv6`.
1. Ejecute el siguiente comando para establecer una variable para el nombre de su pila de AWS CloudFormation. Puede reemplazar *my-eks-ipv6-vpc* por el nombre que elija.
```
export vpc_stack_name=my-eks-ipv6-vpc
```
1. Creación de una VPC `IPv6` a partir de una plantilla de AWS CloudFormation.
```
aws cloudformation create-stack --region $region_code --stack-name $vpc_stack_name \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-ipv6-vpc-public-private-subnets.yaml
```
La pila tarda unos minutos en crearse. Ejecute el siguiente comando. No continúe con el siguiente paso hasta que la salida del comando sea `CREATE_COMPLETE`.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name --query Stacks[].StackStatus --output text
```
1. Recupere los ID de las subredes públicas que se crearon.
```
aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text
```
Un ejemplo de salida sería el siguiente.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE
```
1. Habilite la opción de asignación automática de direcciones `IPv6` para las subredes públicas que se crearon.
```
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-0a1a56c486EXAMPLE --assign-ipv6-address-on-creation
aws ec2 modify-subnet-attribute --region $region_code --subnet-id subnet-099e6ca77aEXAMPLE --assign-ipv6-address-on-creation
```
1. Recupere los nombres de las subredes y los grupos de seguridad creados mediante la plantilla desde la pila de AWS implementada y almacénelos en variables para utilizarlos en un paso posterior.
```
security_groups=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SecurityGroups`].OutputValue' --output text)
public_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPublic`].OutputValue' --output text)
private_subnets=$(aws cloudformation describe-stacks --region $region_code --stack-name $vpc_stack_name \
--query='Stacks[].Outputs[?OutputKey==`SubnetsPrivate`].OutputValue' --output text)
subnets=${public_subnets},${private_subnets}
```
1. Cree un rol de IAM de clúster y adjúntelo a la política administrada de IAM de Amazon EKS. Los clústeres de Kubernetes administrados por Amazon EKS realizan llamadas a otros servicios de AWS en su nombre para administrar los recursos que utiliza con el servicio.
1. Ejecute el siguiente comando para crear un archivo `eks-cluster-role-trust-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Ejecute el siguiente comando para establecer una variable para el nombre de su rol. Puede reemplazar *myAmazonEKSClusterRole* por cualquier nombre que elija.
```
export cluster_role_name=myAmazonEKSClusterRole
```
1. Creación del rol.
```
aws iam create-role --role-name $cluster_role_name --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Recupere el ARN del rol de IAM y almacénelo en una variable para un paso posterior.
```
CLUSTER_IAM_ROLE=$(aws iam get-role --role-name $cluster_role_name --query="Role.Arn" --output text)
```
1. Adjunte la política administrada de IAM por Amazon EKS requerida al rol.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name $cluster_role_name
```
1. Creación de su clúster.
```
aws eks create-cluster --region $region_code --name $cluster_name --kubernetes-version 1.XX \
--role-arn $CLUSTER_IAM_ROLE --resources-vpc-config subnetIds=$subnets,securityGroupIds=$security_groups \
--kubernetes-network-config ipFamily=ipv6
```
1. NOTA: Es posible que reciba un error que indique que una de las zonas de disponibilidad de su solicitud no tiene capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
El clúster tarda varios minutos en crearse. Ejecute el siguiente comando. No continúe con el siguiente paso hasta que la salida del comando sea `ACTIVE`.
```
aws eks describe-cluster --region $region_code --name $cluster_name --query cluster.status
```
1. Creación o actualización de un archivo `kubeconfig` para su clúster para que pueda comunicarse con él.
```
aws eks update-kubeconfig --region $region_code --name $cluster_name
```
De forma predeterminada, el archivo de `config` se crea en `~/.kube` o la configuración del clúster nuevo se agrega a un archivo de `config` existente en `~/.kube`.
1. Creación de un rol de IAM de nodo.
1. Ejecute el siguiente comando para crear un archivo `vpc-cni-ipv6-policy.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. Creación de la política de IAM.
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. Ejecute el siguiente comando para crear un archivo `node-role-trust-relationship.json`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Ejecute el siguiente comando para establecer una variable para el nombre de su rol. Puede reemplazar *AmazonEKSNodeRole* por el nombre que elija.
```
export node_role_name=AmazonEKSNodeRole
```
1. Creación del rol de IAM.
```
aws iam create-role --role-name $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. Adjunte la política de IAM al rol de IAM.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name $node_role_name
```
**importante**
Para simplificar este tutorial, la política se adjunta a este rol de IAM. Sin embargo, en un clúster de producción, recomendamos adjuntar la política a un rol de IAM independiente. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
1. Adjunte al rol de IAM las dos políticas administradas por IAM necesarias.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name $node_role_name
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name $node_role_name
```
1. Recupere el ARN del rol de IAM y almacénelo en una variable para un paso posterior.
```
node_iam_role=$(aws iam get-role --role-name $node_role_name --query="Role.Arn" --output text)
```
1. Creación de un grupo de nodos administrados.
1. Visualización de los ID de las subredes que creó en un paso anterior.
```
echo $subnets
```
Un ejemplo de salida sería el siguiente.
```
subnet-0a1a56c486EXAMPLE,subnet-099e6ca77aEXAMPLE,subnet-0377963d69EXAMPLE,subnet-0c05f819d5EXAMPLE
```
1. Creación de grupo de nodos. Sustituya *0a1a56c486EXAMPLE*, *099e6ca77aEXAMPLE*, *0377963d69EXAMPLE* y *0c05f819d5EXAMPLE* por los valores devueltos en la salida del paso anterior. Asegúrese de eliminar las comas entre los ID de subredes de la salida anterior en el siguiente comando. Puede reemplazar *t3.medium* por cualquier [tipo de instancia de AWS Nitro System](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
```
aws eks create-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--subnets subnet-0a1a56c486EXAMPLE subnet-099e6ca77aEXAMPLE subnet-0377963d69EXAMPLE subnet-0c05f819d5EXAMPLE \
--instance-types t3.medium --node-role $node_iam_role
```
El grupo de nodos tarda unos minutos en crearse. Ejecute el siguiente comando. No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.
```
aws eks describe-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name \
--query nodegroup.status --output text
```
1. Confirme que a los pods predeterminados se les asignen direcciones `IPv6` en la columna `IP`.
```
kubectl get pods -n kube-system -o wide
```
Un ejemplo de salida sería el siguiente.
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
aws-node-rslts 1/1 Running 1 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
aws-node-t74jh 1/1 Running 0 5m32s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-cw7w2 1/1 Running 0 56m 2600:1f13:b66:8203:34e5:: ip-192-168-253-70.region-code.compute.internal
coredns-85d5b4454c-tx6n8 1/1 Running 0 56m 2600:1f13:b66:8203:34e5::1 ip-192-168-253-70.region-code.compute.internal
kube-proxy-btpbk 1/1 Running 0 5m36s 2600:1f13:b66:8200:11a5:ade0:c590:6ac8 ip-192-168-34-75.region-code.compute.internal
kube-proxy-jjk2g 1/1 Running 0 5m33s 2600:1f13:b66:8203:4516:2080:8ced:1ca9 ip-192-168-253-70.region-code.compute.internal
```
1. Confirme que a los servicios predeterminados se les asignen direcciones `IPv6` en la columna `IP`.
```
kubectl get services -n kube-system -o wide
```
Un ejemplo de salida sería el siguiente.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
kube-dns ClusterIP fd30:3087:b6c2::a 53/UDP,53/TCP 57m k8s-app=kube-dns
```
1. (Opcional) [Implemente una aplicación de muestra](sample-deployment.md) o implemente el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y una aplicación de muestra para equilibrar la carga de aplicaciones HTTP con [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) o el tráfico de red con [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md) en pods de `IPv6`.
1. Cuando haya terminado con el clúster y los nodos que creó para este tutorial, debería limpiar los recursos que creó con los siguientes comandos. Asegúrese de no estar utilizando ninguno de los recursos fuera de este tutorial antes de eliminarlos.
1. Si realiza este paso en un intérprete de comandos diferente al que utilizó para completar los pasos anteriores, establezca los valores de todas las variables utilizadas previamente y reemplace los valores de ejemplo por los que especificó en los pasos anteriores. Si está completando este paso en el mismo intérprete de comandos en el que completó los pasos anteriores, vaya al siguiente paso.
```
export region_code=region-code
export vpc_stack_name=my-eks-ipv6-vpc
export cluster_name=my-cluster
export nodegroup_name=my-nodegroup
export account_id=111122223333
export node_role_name=AmazonEKSNodeRole
export cluster_role_name=myAmazonEKSClusterRole
```
1. Eliminación de su grupo de nodos.
```
aws eks delete-nodegroup --region $region_code --cluster-name $cluster_name --nodegroup-name $nodegroup_name
```
La eliminación tarda unos minutos. Ejecute el siguiente comando. No continúe con el siguiente paso si se devuelve alguna salida.
```
aws eks list-nodegroups --region $region_code --cluster-name $cluster_name --query nodegroups --output text
```
1. Elimine el clúster.
```
aws eks delete-cluster --region $region_code --name $cluster_name
```
El clúster tarda unos minutos en eliminarse. Antes de continuar, asegúrese de que el clúster se elimine con el siguiente comando.
```
aws eks describe-cluster --region $region_code --name $cluster_name
```
No continúe con el siguiente paso hasta que la salida sea similar a la siguiente.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-cluster.
```
1. Eliminación de los resultados de IAM que creó. Reemplace *AmazonEKS\$1CNI\$1IPv6\$1Policy* por el nombre que eligió si eligió un nombre diferente al que utilizó en los pasos anteriores.
```
aws iam detach-role-policy --role-name $cluster_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name $node_role_name --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-policy --policy-arn arn:aws:iam::$account_id:policy/AmazonEKS_CNI_IPv6_Policy
aws iam delete-role --role-name $cluster_role_name
aws iam delete-role --role-name $node_role_name
```
1. Eliminación de la pila de AWS CloudFormation que creó la VPC.
```
aws cloudformation delete-stack --region $region_code --stack-name $vpc_stack_name
```
# Habilitación del acceso a Internet saliente para pods
**Aplicación**: en nodos de `IPv4` de Linux de Fargate, y nodos de Linux con instancias de Amazon EC2
Si ha implementado el clúster mediante la familia `IPv6`, la información de este tema no se aplica a su clúster, porque las direcciones `IPv6` no están traducidas en red. Para obtener más información acerca del uso de `IPv6` con su clúster, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
De forma predeterminada, a cada pod del clúster se le asigna una dirección `IPv4` [privada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses) de un bloque de enrutamiento entre dominios sin clases (CIDR) asociado a la VPC en la que se implementa el pod. Los pods en la misma VPC se comunican entre sí utilizando estas direcciones IP privadas como puntos de conexión. Cuando un pod se comunica con cualquier dirección `IPv4` que no se encuentra dentro de un bloque de CIDR asociado a la VPC, el complemento CNI de Amazon VPC (para [Linux](https://github.com/aws/amazon-vpc-cni-k8s#amazon-vpc-cni-k8s) o [Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge)) traduce la dirección `IPv4` del pod a la dirección `IPv4` privada principal de la [interfaz de red elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) principal del nodo en el que se está ejecutando el pod, que es [\$1](#snat-exception) de forma predeterminada.
**nota**
En el caso de los nodos de Windows, hay detalles adicionales que se deben tener en cuenta. De forma predeterminada, el [complemento CNI de Amazon VPC para Windows](https://github.com/aws/amazon-vpc-cni-plugins/tree/master/plugins/vpc-bridge) se define con una configuración de red en la que se excluye el tráfico a un destino dentro de la misma VPC para SNAT. Esto significa que la comunicación interna de la VPC tiene la SNAT desactivada y la dirección IP asignada a un pod se puede enrutar dentro de la VPC. Sin embargo, el tráfico a un destino fuera de la VPC tiene la IP del pod de origen vinculada mediante la SNAT a la dirección IP principal de la ENI de la instancia. Esta configuración predeterminada de Windows garantiza que el pod pueda acceder a redes fuera de la VPC de la misma manera que a la instancia del host.
Debido a este comportamiento:
+ Los pods pueden comunicarse con recursos de Internet solo si el nodo en el que se están ejecutando tiene una dirección IP [pública](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-public-addresses) o [elástica](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html) asignada y se encuentra en una [subred pública](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics). Una subred pública es una subred asociada a la [tabla de enrutamiento](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) que tiene una ruta a la puerta de enlace de internet. Recomendamos implementar nodos en subredes privadas, siempre que sea posible.
+ Para versiones del complemento anteriores a `1.8.0`, los recursos que se encuentran en redes o VPC que están conectadas a la VPC del clúster mediante un [emparejamiento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), una [VPC de tránsito](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) no pueden iniciar la comunicación con sus pods detrás de interfaces de redes elásticas secundarias. Sin embargo, sus pods pueden iniciar la comunicación con esos recursos y recibir respuestas de ellos.
Si alguna de las siguientes afirmaciones es verdadera en su entorno, cambie la configuración predeterminada con el comando siguiente.
+ Tiene recursos en redes o VPC que están conectados a la VPC de su clúster mediante [emparejamiento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html), una [VPC de tránsito](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) o [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) que deben iniciar la comunicación con sus pods mediante una dirección `IPv4` y la versión del complemento es anterior a la `1.8.0`.
+ Sus pods se encuentran en una [subred privada](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-basics) y necesitan comunicación saliente a Internet. La subred tiene una ruta hacia una [puerta de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
```
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
```
**nota**
Las variables de configuración de CNI `AWS_VPC_K8S_CNI_EXTERNALSNAT` y `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` no se aplican a los nodos de Windows. No se admite la desactivación de SNAT para Windows. En cuanto a la exclusión de una lista de CIDR `IPv4` de SNAT, puede especificar el parámetro `ExcludedSnatCIDRs` en el script de arranque de Windows para definirla. Para obtener más información acerca del uso de este parámetro, consulte [Parámetros de configuración del script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Red del host
\$1 Si las especificaciones del pod contienen `hostNetwork=true` (el valor predeterminado es `false`), su dirección IP no se traduce a otra dirección. Este es el caso de `kube-proxy` y el complemento CNI de Amazon VPC para Kubernetes, que se ejecutan en el clúster, de forma predeterminada. Para estos pods, la dirección IP es la misma que la dirección IP principal del nodo, por lo que la dirección IP del pod no está traducida. Para obtener más información acerca de la configuración de `hostNetwork` del pod, consulte [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) en la referencia de API de Kubernetes.
# Limitación del tráfico de un pod con políticas de red de Kubernetes
## Descripción general
De forma predeterminada, no hay restricciones en Kubernetes para las direcciones IP, puertos o conexiones entre cualquier pod de su clúster o entre sus pods y recursos en cualquier otra red. Puede usar una *política de red* de Kubernetes para restringir el tráfico de red que entra y sale de sus pods. Para obtener más información, consulte [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) en la documentación de Kubernetes.
## Política de red estándar
Puede usar la `NetworkPolicy` estándar para segmentar el tráfico de pod a pod en el clúster. Estas políticas de red permiten operar en las capas 3 y 4 del modelo de red OSI, lo que le permite controlar el flujo de tráfico en la dirección IP o el puerto dentro del clúster de Amazon EKS. El ámbito de las políticas de red estándar es el espacio de nombres.
### Casos de uso
+ Segmente el tráfico de red entre las cargas de trabajo para garantizar que solo las aplicaciones relacionadas puedan comunicarse entre sí.
+ Aísle los inquilinos del espacio de nombres mediante políticas que impongan la separación de la red.
### Ejemplo
En la política siguiente, se restringe el tráfico de salida de los pods *webapp* en el espacio de nombres *sun*.
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: webapp-egress-policy
namespace: sun
spec:
podSelector:
matchLabels:
role: webapp
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
name: moon
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
name: stars
podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
```
La política se aplica a los pods con la etiqueta `role: webapp` en el espacio de nombres `sun`.
+ Tráfico permitido: pods con la etiqueta `role: frontend` en el espacio de nombres `moon` del puerto TCP `8080`
+ Tráfico permitido: pods con la etiqueta de rol de frontend en el espacio de nombres `stars` del puerto TCP `8080`
+ Tráfico bloqueado: se deniega implícitamente el resto del tráfico saliente de los pods `webapp`
## Política de red de administración (o del clúster)
![\[Ilustración del orden de evaluación de las políticas de red en EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/evaluation-order.png)
Puede usar la `ClusterNetworkPolicy` para aplicar un estándar de seguridad de red a todo el clúster. En lugar de definir y mantener de forma repetitiva una política distinta para cada espacio de nombres, puede usar una política única para administrar de forma centralizada los controles de acceso a la red para las diferentes cargas de trabajo del clúster, independientemente de su espacio de nombres.
### Casos de uso
+ Administre de forma centralizada los controles de acceso a la red para todas las cargas de trabajo (o un subconjunto de ellas) del clúster de EKS.
+ Defina una posición de seguridad de red predeterminada en todo el clúster.
+ Amplíe los estándares de seguridad de la organización al ámbito del clúster de una manera más eficiente desde el punto de vista operativo.
### Ejemplo
En la política siguiente, puede bloquear de forma explícita el tráfico del clúster desde otros espacios de nombres para impedir el acceso de la red al espacio de nombres confidencial de la carga de trabajo.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Notas importantes
Las políticas de red del complemento CNI de Amazon VPC para Kubernetes se admiten en las configuraciones que se enumeran a continuación.
+ Versión 1.21.0 (o posterior) del complemento CNI de Amazon VPC para políticas de red estándar y de administración.
+ Clúster configurado para las direcciones `IPv4` o `IPv6`.
+ Puede utilizar las políticas de red con los [grupos de seguridad para pods](security-groups-for-pods.md). Con las políticas de red, puede controlar todas las comunicaciones dentro del clúster. Con los grupos de seguridad para pods, puede controlar el acceso a servicios de AWS desde aplicaciones dentro de un pod.
+ Puede utilizar las políticas de red con las *redes personalizadas* y la *delegación de prefijos*.
## Consideraciones
**Arquitectura**
+ Cuando se aplican las políticas de red del complemento CNI de Amazon VPC para Kubernetes a su clúster con el complemento CNI de Amazon VPC para Kubernetes, se pueden aplicar las políticas únicamente a los nodos de Linux de Amazon EC2. No se pueden aplicar las políticas a los nodos de Fargate o Windows.
+ Las políticas de red solo aplican direcciones `IPv4` o `IPv6`, pero no ambas. En un clúster `IPv4`, la CNI de VPC asigna direcciones `IPv4` a los pods y aplica políticas `IPv4`. En un clúster `IPv6`, la CNI de VPC asigna direcciones `IPv6` a los pods y aplica políticas `IPv6`. Se ignora cualquier regla de política de red `IPv4` aplicada a un clúster `IPv6`. Se ignora cualquier regla de política de red `IPv6` aplicada a un clúster `IPv4`.
**Políticas de red**
+ Las políticas de red solo se aplican a los pods que forman parte de una implementación. No se pueden aplicar políticas de red a los pods independientes que no tengan un conjunto de `metadata.ownerReferences`.
+ Puede aplicar varias políticas de red al mismo pod. Cuando se han configurado dos o más políticas que seleccionan el mismo pod, todas las políticas se aplican al pod.
+ La cantidad máxima de combinaciones de puertos y protocolos para un único rango de direcciones IP (CIDR) es de 24 en todas las políticas de red. Los selectores, como `namespaceSelector`, se resuelven en uno o más CIDR. Si varios selectores se resuelven en un único CIDR o si especifica el mismo CIDR directo varias veces en la misma o en diferentes políticas de red, todos estos cuentan para este límite.
+ Para cualquiera de sus servicios de Kubernetes, el puerto de servicio debe ser el mismo que el puerto del contenedor. Si utiliza puertos con nombre, utilice también el mismo nombre en la especificación del servicio.
**Políticas de red de administración**
1. **Políticas del nivel de administración (se evalúan primero)**: todas las ClusterNetworkPolicies del nivel de administración se evalúan antes que cualquier otra política. En el nivel de administración, las políticas se procesan por orden de prioridad (se comienza por el número de prioridad más baja). El tipo de acción determina lo que sucede a continuación.
+ **Acción de denegación (máxima prioridad)**: cuando una política de administración con una acción de denegación coincide con el tráfico, ese tráfico se bloquea inmediatamente, independientemente de cualquier otra política. No se procesan más reglas de ClusterNetworkPolicy ni NetworkPolicy. Esto garantiza que las políticas del espacio de nombres no puedan anular los controles de seguridad de toda la organización.
+ **Acción de permiso**: una vez evaluadas las reglas de denegación, las políticas de administración que incluyen acciones de permiso se procesan por orden de prioridad (se comienza por el número de prioridad más baja). Cuando una acción de permiso coincide, se acepta el tráfico y no se lleva a cabo ninguna otra evaluación de la política. Estas políticas pueden conceder el acceso a varios espacios de nombres en función de los selectores de etiquetas, lo que proporciona un control centralizado sobre qué cargas de trabajo pueden acceder a recursos específicos.
+ **Acción de transferencia**: las acciones de transferencia en las políticas del nivel de administración delegan la toma de decisiones a los niveles inferiores. Cuando el tráfico coincide con una regla de transferencia, la evaluación omite todas las reglas del nivel de administración restantes para ese tráfico y continúa directamente con el nivel de la NetworkPolicy. Esto permite a los administradores delegar explícitamente el control de determinados patrones de tráfico a los equipos de aplicaciones. Por ejemplo, puede usar reglas de transferencia para delegar la administración del tráfico dentro del espacio de nombres a los administradores del espacio de nombres y, al mismo tiempo, mantener controles estrictos sobre el acceso externo.
1. **Nivel de política de red**: si ninguna política de administración coincide con ninguna acción de denegación o permiso, o si coincide con una acción de transferencia, se evalúan a continuación los recursos de la NetworkPolicy del ámbito del espacio de nombres. Estas políticas proporcionan un control detallado dentro de los espacios de nombres individuales y las administran los equipos de aplicaciones. Las políticas relacionadas con el espacio de nombres solo pueden ser más restrictivas que las políticas de administración. No pueden anular ninguna decisión de denegación de una política de administración, pero pueden restringir aún más el tráfico permitido o transferido por las políticas de administración.
1. **Políticas de administración del nivel de línea de base**: si ninguna política de administración o del ámbito del espacio de nombres coincide con el tráfico, se evalúan las ClusterNetworkPolicies del nivel de línea de base. Proporcionan posiciones de seguridad predeterminadas que pueden ser anuladas por políticas del ámbito del espacio de nombres, lo que permite a los administradores establecer valores predeterminados para toda la organización y, al mismo tiempo, ofrecer a los equipos la flexibilidad necesaria para personalizarlas según sea necesario. Las políticas de referencia se evalúan por orden de prioridad (se comienza por el número de prioridad más baja).
1. **Denegación de forma predeterminada (si ninguna política coincide)**: este comportamiento de denegación de forma predeterminada garantiza que solo se permitan las conexiones explícitamente permitidas, lo que mantiene una posición de seguridad sólida.
**Migración**
+ Si su clúster utiliza actualmente una solución de terceros para la administración de políticas de red de Kubernetes, puede usar esas mismas políticas con el complemento CNI de Amazon VPC para Kubernetes. Sin embargo, debe eliminar la solución existente para que no administre las mismas políticas.
**aviso**
Se recomienda que, después de eliminar una solución de política de red, reemplace todos los nodos a los que se haya aplicado la solución de política de red. Esto se debe a que las reglas de tráfico podrían quedar desfasadas si un pod de la solución se cierra repentinamente.
**Instalación**
+ La característica de política de red crea y requiere una definición de recurso personalizada (CRD) de `PolicyEndpoint` llamada `policyendpoints.networking.k8s.aws`. Amazon EKS administra los objetos `PolicyEndpoint` del recurso personalizado. No se deben modificar ni eliminar estos recursos.
+ Si ejecuta pods que utilizan las credenciales de IAM del rol de instancia o se conectan al IMDS de EC2, compruebe si hay políticas de red que puedan bloquear el acceso al IMDS de EC2. Puede que tenga que añadir una política de red para permitir el acceso al IMDS de EC2. Para obtener más información, consulte [Metadatos de instancia y datos de usuario](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) en la guía del usuario de Amazon EC2.
Los pods que utilizan los *roles de IAM para cuentas de servicio* o *Pod Identity de EKS* no acceden al IMDS de EC2.
+ El complemento CNI de Amazon VPC para Kubernetes no aplica políticas de red a las interfaces de red adicionales de cada pod, solo a la interfaz principal de cada pod (`eth0`). Esta característica afecta a las siguientes arquitecturas:
+ Pods `IPv6` con la variable `ENABLE_V4_EGRESS` establecida en `true`. Esta variable habilita la característica de salida `IPv4` para conectar los pods IPv6 a puntos de conexión `IPv4`, como aquellos fuera del clúster. La característica de salida `IPv4` funciona mediante la creación de una interfaz de red adicional con una dirección IPv4 de bucle invertido local.
+ Cuando se utilizan complementos de red encadenados, como Multus. Debido a que estos complementos añaden interfaces de red a cada pod, las políticas de red no se aplican a los complementos de red encadenados.
# Restricción del tráfico de red de pods con políticas de red de Kubernetes
Puede usar la política de red de Kubernetes para restringir el tráfico de red que entra y sale de pods. Para obtener más información, consulte [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) en la documentación de Kubernetes.
Debe configurar lo siguiente para poder utilizar esta característica:
1. Configure la aplicación de políticas al inicio del pod. Esto se hace en el de contenedor `aws-node` del `DaemonSet` de la CNI de la VPC.
1. Habilite el parámetro de política de red para el complemento.
1. Configuración del clúster para que use la política de red de Kubernetes
Antes de empezar, revise las consideraciones. Para obtener más información, consulte [Consideraciones](cni-network-policy.md#cni-network-policy-considerations).
## Requisitos previos
A continuación se indican los requisitos previos de esta característica:
### Versión mínima del clúster
Un clúster existente de Amazon EKS. Para implementar uno, consulte [Introducción a Amazon EKS](getting-started.md). El clúster debe estar ejecutando una de las versiones de Kubernetes y versiones de la plataforma que se enumeran en la tabla siguiente. Tenga en cuenta que también se admite cualquier versión de Kubernetes y de la plataforma posterior a las enumeradas. Para comprobar la versión actual de Kubernetes, reemplace *my-cluster* en el siguiente comando por el nombre del clúster y, a continuación, ejecute el comando modificado:
```
aws eks describe-cluster --name my-cluster --query cluster.version --output text
```
| Versión de Kubernetes | Versión de la plataforma |
| --- | --- |
| `1.27.4` | `eks.5` |
| `1.26.7` | `eks.6` |
### Versión mínima de CNI de VPC
Para crear políticas de red de administración y políticas de red de Kubernetes estándar, debe ejecutar la versión `1.21` del complemento CNI de VPC. Puede comprobar qué versión utiliza actualmente con el siguiente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Si su versión es anterior a la `1.21`, actualice [Cómo actualizar la CNI de Amazon VPC (complemento de Amazon EKS)](vpc-add-on-update.md) a la versión `1.21` o posterior.
### Versión mínima del kernel de Linux
Sus nodos deben tener la versión del núcleo de Linux `5.10` o posterior. Puede comprobar la versión del núcleo con `uname -r`. Si utiliza las versiones más recientes de las AMI optimizadas para Amazon EKS de Amazon Linux, las AMI optimizadas para Amazon EKS de Amazon Linux acelerado y las AMI de Bottlerocket, estas ya tienen la versión de kernel necesaria.
La versión `v20231116` de la AMI de Amazon Linux acelerada y optimizada de Amazon EKS o posterior tiene una versión `5.10` de núcleo.
## Paso 1: configuración de la aplicación de políticas al inicio del pod
El complemento CNI de Amazon VPC para Kubernetes configura las políticas de red para los pods en paralelo con el aprovisionamiento de los pods. A menos que se hayan configurado todas las políticas para el nuevo pod, los contenedores del nuevo pod se iniciarán con una *política de permisos predeterminada*. Esto se denomina *modo estándar*. Una política de permisos predeterminada significa que se permite todo el tráfico de entrada y salida desde y hacia los nuevos pods. Por ejemplo, no se aplicará ninguna regla de firewall a los pods (se permite todo el tráfico) hasta que el nuevo pod se actualice con las políticas activas.
Con la variable `NETWORK_POLICY_ENFORCING_MODE` configurada en `strict`, los pods que utilizan la CNI de la VPC se inician con una *política de denegación predeterminada* y, a continuación, se configuran las políticas. Esto se denomina *modo estricto*. En el modo estricto, debe tener una política de red para cada punto de conexión del clúster al que los pods necesiten acceder. Tenga en cuenta que este requisito se aplica a los pods de CoreDNS. La política de denegación predeterminada no está configurada para los pods con redes de Host.
Para cambiar la política de red predeterminada, debe configurar la variable de entorno `NETWORK_POLICY_ENFORCING_MODE` como `strict` en el contenedor `aws-node` del `DaemonSet` de la CNI de la VPC.
```
env:
- name: NETWORK_POLICY_ENFORCING_MODE
value: "strict"
```
## Paso 2: habilite el parámetro de política de red para el complemento
La característica de la política de red utiliza el puerto `8162` del nodo para las métricas de manera predeterminada. Además, la característica utiliza el puerto `8163` para las sondas de estado. Si ejecuta otra aplicación en los nodos o dentro de pods que necesite utilizar estos puertos, la aplicación no se puede ejecutar. En la versión de CNI de VPC `v1.14.1` o posterior, puede cambiar estos puertos.
Use el siguiente procedimiento para habilitar el parámetro de política de red para el complemento.
### Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
1. Elija la pestaña **Complementos**.
1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar).
1. En la página **Configuración de `Amazon VPC CNI` **, haga lo siguiente:
1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista **Versión**.
1. Seleccione **Ajustes de configuración opcionales**.
1. Introduzca la clave JSON `"enableNetworkPolicy":` y el valor `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. Si esta clave y este valor son los únicos datos del cuadro de texto, rodee la clave y el valor entre corchetes `{ }`.
El siguiente ejemplo tiene activada la característica de la política de red y las métricas y sondas de estado están configuradas con los números de puertos predeterminados:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"healthProbeBindAddr": "8163",
"metricsBindAddr": "8162"
}
}
```
### Helm
Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede actualizar la configuración para cambiar los puertos.
1. Ejecute el siguiente comando para cambiar los puertos. Establezca el número de puerto en el valor para la clave `nodeAgent.metricsBindAddr` o `nodeAgent.healthProbeBindAddr`, respectivamente.
```
helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
### kubectl
1. Abra el `DaemonSet` de `aws-node` en el editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Reemplace los números de puertos en los siguientes argumentos de comando de `args:` del contenedor `aws-network-policy-agent` del manifiesto del daemonset de `aws-node` de CNI de VPC.
```
- args:
- --metrics-bind-addr=:8162
- --health-probe-bind-addr=:8163
```
## Paso 3: configuración del clúster para que use las políticas de red de Kubernetes
Esta configuración se puede usar para un complemento de Amazon EKS o para un complemento autoadministrado.
### Complemento de Amazon EKS
Con la AWS CLI, puede configurar el clúster para que utilice las políticas de red de Kubernetes mediante la ejecución del siguiente comando. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
```
Para configurarlo mediante la Consola de administración de AWS, siga los pasos que se indican a continuación:
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
1. Elija la pestaña **Complementos**.
1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar).
1. En la página **Configuración de `Amazon VPC CNI` **, haga lo siguiente:
1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista **Versión**.
1. Seleccione **Ajustes de configuración opcionales**.
1. Introduzca la clave JSON `"enableNetworkPolicy":` y el valor `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. Si esta clave y este valor son los únicos datos del cuadro de texto, rodee la clave y el valor entre corchetes `{ }`. En el siguiente ejemplo se muestra que la política de red está habilitada:
```
{ "enableNetworkPolicy": "true" }
```
En la siguiente captura de pantalla se muestra un ejemplo de este escenario.
![\[Con se muestra el complemento de CNI de VPC con la política de red en la configuración opcional.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/console-cni-config-network-policy.png)
### Complemento autoadministrado
Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede actualizar la configuración para permitir la política de red.
1. Ejecute el siguiente comando para habilitar la política de red.
```
helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
1. Abra el `ConfigMap` de `amazon-vpc-cni` en el editor.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Añada la línea siguiente al `data` de `ConfigMap`.
```
enable-network-policy-controller: "true"
```
Una vez que haya añadido la línea, su `ConfigMap` debería tener un aspecto similar al siguiente ejemplo.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Abra el `DaemonSet` de `aws-node` en el editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sustituya el `false` por `true` en el argumento del comando `--enable-network-policy=false` en el `args:` del contenedor `aws-network-policy-agent` en el manifiesto del daemonset de `aws-node` del CNI de VPC.
```
- args:
- --enable-network-policy=true
```
## Paso 4. Siguientes pasos
Después de completar la configuración, confirme que los pods `aws-node` se estén ejecutando en el clúster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Un ejemplo de salida sería el siguiente.
```
aws-node-gmqp7 2/2 Running 1 (24h ago) 24h
aws-node-prnsh 2/2 Running 1 (24h ago) 24h
```
Hay 2 contenedores en los pods `aws-node` en las versiones `1.14` y posteriores. En versiones anteriores, y si la política de red está deshabilitada, solo hay un contenedor en los pods de `aws-node`.
Ahora puede implementar políticas de red de Kubernetes en su clúster.
Para implementar políticas de red de Kubernetes, puede crear objetos `NetworkPolicy` o `ClusterNetworkPolicy` de Kubernetes e implementarlos en su clúster. Los objetos `NetworkPolicy` están limitados a un espacio de nombres, mientras que los objetos `ClusterNetworkPolicy` se pueden limitar a todo el clúster o varios espacios de nombres. Implemente políticas para permitir o denegar el tráfico entre pods en función de los selectores de etiquetas, los espacios de nombres y los rangos de direcciones IP. Para obtener más información sobre cómo crear objetos `NetworkPolicy`, consulte [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) en la documentación de Kubernetes.
La aplicación de objetos `NetworkPolicy` de Kubernetes se implementa con Extended Berkeley Packet Filter (eBPF). En relación con las implementaciones basadas en `iptables`, ofrece características de rendimiento y latencia más bajas, que incluyen una menor utilización de la CPU y evitan las búsquedas secuenciales. Además, las sondas de eBPF proporcionan acceso a datos en contexto que ayudan a depurar problemas complejos a nivel del núcleo y a mejorar la observabilidad. Amazon EKS es compatible con un exportador basado en eBPF que aprovecha las sondas para registrar los resultados de las políticas en cada nodo y exportar los datos a recopiladores de registros externos para facilitar la depuración. Para obtener más información, consulte la [documentación de eBPF](https://ebpf.io/what-is-ebpf/#what-is-ebpf).
# Cómo deshabilitar las políticas de red de Kubernetes para el tráfico de red del pod de Amazon EKS
Cómo deshabilitar las políticas de red de Kubernetes para dejar de restringir el tráfico de red del pod de Amazon EKS
1. Enumere todas las políticas de red de Kubernetes.
```
kubectl get netpol -A
```
1. Elimine cada política de red de Kubernetes. Debe eliminar todas las políticas de red antes de desactivarlas.
```
kubectl delete netpol
```
1. Abra el DaemonSet aws-node en el editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sustituya el `true` por `false` en el argumento del comando `--enable-network-policy=true` en el `args:` del contenedor `aws-network-policy-agent` en el manifiesto del daemonset de `aws-node` del CNI de VPC.
```
- args:
- --enable-network-policy=true
```
# Resolución de problemas de políticas de red de Kubernetes para Amazon EKS
Esta es la guía de solución de problemas para la característica de la política de red de la CNI de Amazon VPC.
Esta guía aborda los siguientes temas:
+ Información de instalación, CRD y permisos [Nuevos permisos y CRD `policyendpoints`](#network-policies-troubleshooting-permissions) de RBAC
+ Registros que se deben examinar durante el diagnóstico de problemas [Registros de políticas de red](#network-policies-troubleshooting-flowlogs) en la política de la red
+ Ejecución de la colección de herramientas del SDK de eBPF para solucionar problemas
+ Problemas conocidos y soluciones [Problemas conocidos y soluciones](#network-policies-troubleshooting-known-issues)
**nota**
Tenga en cuenta que las políticas de red solo se aplican a los pods creados por Kubernetes *Deployments*. Para obtener más información sobre las limitaciones de las políticas de red en la CNI de la VPC, consulte [Consideraciones](cni-network-policy.md#cni-network-policy-considerations).
Puede solucionar problemas e investigar las conexiones de red que utilizan políticas de red leyendo los [registros de políticas de red](#network-policies-troubleshooting-flowlogs) y ejecutando las herramientas del [eBPF SDK](#network-policies-ebpf-sdk).
## Nuevos permisos y CRD `policyendpoints`
+ CRD: `policyendpoints.networking.k8s.aws`
+ Kubernetes API: `apiservice` denominado `v1.networking.k8s.io`
+ Recurso de Kubernetes: `Kind: NetworkPolicy`
+ RBAC: `ClusterRole` denominado `aws-node` (CNI de la VPC), `ClusterRole` llamó a `eks:network-policy-controller` (controlador de políticas de red en el plano de control del clúster de EKS)
Para la política de red, la CNI de la VPC crea una nueva `CustomResourceDefinition` (CRD) llamada `policyendpoints.networking.k8s.aws`. La CNI de la VPC debe tener permisos para crear la CRD y crear CustomResources (CR) de esta y de las otras CRD instaladas por la CNI de la VPC (`eniconfigs.crd.k8s.amazonaws.com`). Ambas CRD están disponibles en el [archivo `crds.yaml`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/charts/aws-vpc-cni/crds/customresourcedefinition.yaml) de GitHub. En concreto, la CNI de la VPC debe tener los permisos verbales “get”, “list” y “watch” para `policyendpoints`.
La *política de red* de Kubernetes forma parte del `apiservice` denominado `v1.networking.k8s.io`, que es `apiversion: networking.k8s.io/v1` en los archivos YAML de la política. La CNI de la VPC `DaemonSet` debe tener permisos para usar esta parte de la API de Kubernetes.
Los permisos de la CNI de la VPC están en un `ClusterRole` denominado `aws-node`. Tenga en cuenta que los objetos `ClusterRole` no se agrupan en los espacios de nombres. A continuación se muestra el `aws-node` de un clúster:
```
kubectl get clusterrole aws-node -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/instance: aws-vpc-cni
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: aws-node
app.kubernetes.io/version: v1.19.4
helm.sh/chart: aws-vpc-cni-1.19.4
k8s-app: aws-node
name: aws-node
rules:
- apiGroups:
- crd.k8s.amazonaws.com
resources:
- eniconfigs
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- namespaces
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- pods
verbs:
- list
- watch
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- get
- apiGroups:
- ""
- events.k8s.io
resources:
- events
verbs:
- create
- patch
- list
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- apiGroups:
- vpcresources.k8s.aws
resources:
- cninodes
verbs:
- get
- list
- watch
- patch
```
Además, se ejecuta un nuevo controlador en el plano de control de cada clúster de EKS. El controlador usa los permisos del `ClusterRole` denominado `eks:network-policy-controller`. A continuación se muestra el `eks:network-policy-controller` de un clúster:
```
kubectl get clusterrole eks:network-policy-controller -o yaml
```
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
app.kubernetes.io/name: amazon-network-policy-controller-k8s
name: eks:network-policy-controller
rules:
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- services
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints
verbs:
- create
- delete
- get
- list
- patch
- update
- watch
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/finalizers
verbs:
- update
- apiGroups:
- networking.k8s.aws
resources:
- policyendpoints/status
verbs:
- get
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- networkpolicies
verbs:
- get
- list
- patch
- update
- watch
```
## Registros de políticas de red
Cada decisión que la CNI de la VPC toma con respecto a si las políticas de red permiten o deniegan las conexiones se registra en los *registros de flujo*. Los registros de políticas de red de cada nodo incluyen los registros de flujo de cada pod que tiene una política de red. Los registros de políticas de red se almacenan en `/var/log/aws-routed-eni/network-policy-agent.log`. A continuación se muestra un ejemplo de un archivo `network-policy-agent.log`:
```
{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}
```
Los registros de políticas de red está deshabilitados de manera predeterminada. Para habilitar los registros de políticas de red, siga estos pasos:
**nota**
Los registros de políticas de red requieren 1 vCPU adicional para el contenedor `aws-network-policy-agent` del manifiesto `aws-node` `DaemonSet` de la CNI de la VPC.
### Complemento de Amazon EKS
** Consola de administración de AWS **
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
1. Elija la pestaña **Complementos**.
1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar).
1. En la página **Configurar *CNI de Amazon VPC***:
1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista desplegable **Versión**.
1. Seleccione **Ajustes de configuración opcionales**.
1. Introduzca la clave de JSON de nivel superior `"nodeAgent":` y el valor en un objeto con una clave `"enablePolicyEventLogs":` y un valor de `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true"
}
}
```
En la siguiente captura de pantalla se muestra un ejemplo de este escenario.
![\[ mostrando el complemento CNI de VPC con la política de red y los Registros de CloudWatch en la configuración opcional.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/console-cni-config-network-policy-logs.png)
AWS CLI
1. Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'
```
### Complemento autoadministrado
Helm
Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede actualizar la configuración para escribir los registros de la política de red.
1. Ejecute el siguiente comando para habilitar la política de red.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
kubectl
Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `kubectl`, puede actualizar la configuración para escribir los registros de la política de red.
1. Abra el `DaemonSet` de `aws-node` en el editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sustituya el `false` por `true` en el argumento del comando `--enable-policy-event-logs=false` en el `args:` del contenedor `aws-network-policy-agent` en el manifiesto `aws-node` `DaemonSet` de la CNI de la VPC.
```
- args:
- --enable-policy-event-logs=true
```
### Enviar los registros de políticas de red a los Registros de Amazon CloudWatch
Puede supervisar los registros de políticas de red mediante servicios como los Registros de Amazon CloudWatch. Puede usar los siguientes métodos para enviar los registros de políticas de red a los Registros de CloudWatch.
En el caso de los clústeres de EKS, los registros de políticas se ubicarán en `/aws/eks/cluster-name/cluster/` y, en el caso de los clústeres K8S autoadministrados, los registros se colocarán en `/aws/k8s-cluster/cluster/`.
#### Envío de registros de la política de red con el complemento CNI de Amazon VPC para Kubernetes
Si habilita la política de red, se añade un segundo contenedor a los pods de `aws-node` para un *agente de nodos*. Este agente de nodos puede enviar los registros de políticas de red a los Registros de CloudWatch.
**nota**
El agente de nodos solo envía los registros de políticas de red. No se incluyen otros registros creados por el CNI de VPC.
##### Requisitos previos
+ Añada los siguientes permisos como una política individual o independiente al rol de IAM que está utilizando para el CNI de VPC.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
##### Complemento de Amazon EKS
** Consola de administración de AWS **
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
1. Elija la pestaña **Complementos**.
1. Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija **Edit** (Editar).
1. En la página **Configurar *CNI de Amazon VPC***:
1. Seleccione la versión `v1.14.0-eksbuild.3` o posterior en la lista desplegable **Versión**.
1. Seleccione **Ajustes de configuración opcionales**.
1. Introduzca la clave de JSON de nivel superior `"nodeAgent":` y el valor en un objeto con una clave `"enableCloudWatchLogs":` y un valor de `"true"` en **Valores de configuración**. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch:
```
{
"enableNetworkPolicy": "true",
"nodeAgent": {
"enablePolicyEventLogs": "true",
"enableCloudWatchLogs": "true",
}
}
```
En la siguiente captura de pantalla se muestra un ejemplo de este escenario.
![\[ mostrando el complemento CNI de VPC con la política de red y los Registros de CloudWatch en la configuración opcional.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/console-cni-config-network-policy-logs-cwl.png)
** AWS CLI**
1. Ejecute el siguiente comando de AWS CLI. Reemplace `my-cluster` por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.
```
aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
--service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
--resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'
```
##### Complemento autoadministrado
**Helm**
Si ha instalado el complemento CNI de Amazon VPC para Kubernetes mediante `helm`, puede enviar la configuración para enviar registros de la política de red a Registros de CloudWatch.
1. Ejecute el siguiente comando para habilitar los registros de políticas de red y enviarlos a los Registros de CloudWatch.
```
helm upgrade --set nodeAgent.enablePolicyEventLogs=true --set nodeAgent.enableCloudWatchLogs=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
```
**kubectl**
1. Abra el `DaemonSet` de `aws-node` en el editor.
```
kubectl edit daemonset -n kube-system aws-node
```
1. Sustituya `false` por `true` en los dos argumentos de comando `--enable-policy-event-logs=false` y `--enable-cloudwatch-logs=false` de `args:` del contenedor `aws-network-policy-agent` en el manifiesto `aws-node` `DaemonSet` de la CNI de la VPC.
```
- args:
- --enable-policy-event-logs=true
- --enable-cloudwatch-logs=true
```
#### Envío de registros de políticas de red con un `DaemonSet` de Fluent Bit
Si utiliza Fluent Bit en un `DaemonSet` para enviar registros desde sus nodos, puede agregar una configuración para incluir los registros de políticas de red de las políticas de red. Puede utilizar la siguiente configuración de ejemplo:
```
[INPUT]
Name tail
Tag eksnp.*
Path /var/log/aws-routed-eni/network-policy-agent*.log
Parser json
DB /var/log/aws-routed-eni/flb_npagent.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Refresh_Interval 10
```
## SDK de eBPF incluido
El complemento CNI de Amazon VPC para Kubernetes instala el conjunto de herramientas del SDK de eBPF en los nodos. Puede utilizar las herramientas del SDK de eBPF para identificar problemas con las políticas de red. Por ejemplo, el siguiente comando muestra los programas que se ejecutan en el nodo.
```
sudo /opt/cni/bin/aws-eks-na-cli ebpf progs
```
Para ejecutar este comando, puede utilizar cualquier método para conectarse al nodo.
## Problemas conocidos y soluciones
En las siguientes secciones se describen los problemas conocidos con la característica de la política de red de la CNI de Amazon VPC y sus soluciones.
### Los registros de políticas de red se generan a pesar de que enable-policy-event-logs esté establecido en false
**Problema**: la CNI de VPC de EKS genera registros de políticas de red incluso cuando la configuración `enable-policy-event-logs` está establecida en `false`.
**Solución**: la configuración `enable-policy-event-logs` solo deshabilita los registros de “decisiones” de las políticas, pero no deshabilita todos los registros del agente de políticas de red. Este comportamiento se documenta en el archivo [README aws-network-policy-agent](https://github.com/aws/aws-network-policy-agent/) de GitHub. Para deshabilitar por completo el registro, es posible que tenga que ajustar otras configuraciones de registro.
### Problemas de limpieza de asignación de políticas de red
**Problema**: los problemas con la red `policyendpoint` siguen existiendo y no se están limpiando después de eliminar los pods.
**Solución**: Esto se debe a un problema con la versión 1.19.3-eksbuild.1 del complemento CNI de VPC. Actualice el complemento CNI de VPC a una versión más reciente para resolver este problema.
### No se aplican políticas de red
**Problema**: la característica de políticas de red está habilitada en el complemento CNI de Amazon VPC, pero las políticas de red no se aplican correctamente.
Si crea una política de red `kind: NetworkPolicy` y no impacta en el pod, compruebe que el objeto policyendpoint se haya creado en el mismo espacio de nombres que el pod. Si no hay objetos `policyendpoint` en los espacios de nombres, el controlador de políticas de red (parte del clúster de EKS) no pudo crear reglas de políticas de red para que las aplicara el agente de políticas de red (parte de la CNI de la VPC).
**Solución**: la solución consiste en corregir los permisos de la CNI de la VPC (`ClusterRole` - `aws-node`) y del controlador de políticas de red (`ClusterRole` - `eks:network-policy-controller`) y permitir estas acciones en cualquier herramienta de aplicación de políticas, como Kyverno. Asegúrese de que las políticas de Kyverno no bloqueen la creación de objetos `policyendpoint`. Consulte la sección anterior para conocer los permisos necesarios en [Nuevos permisos y CRD `policyendpoints`](#network-policies-troubleshooting-permissions).
### Los pods no vuelven al estado de denegación predeterminado después de eliminar la política en modo estricto
**Problema**: cuando las políticas de red están habilitadas en modo estricto, los pods comienzan con una política de denegación predeterminada. Una vez aplicadas las políticas, se permite el tráfico a los puntos de conexión especificados. Sin embargo, cuando se eliminan las políticas, el pod no vuelve al estado de denegación predeterminado, sino que pasa a un estado de permiso predeterminado.
**Solución**: este problema se solucionó en la versión 1.19.3 de la CNI de la VPC, que incluía la versión 1.2.0 del agente de políticas de red. Tras la corrección, con el modo estricto habilitado, una vez eliminadas las políticas, el pod vuelve al estado de denegación predeterminado, tal y como se esperaba.
### Latencia de inicio de los grupos de seguridad para los pods
**Problema**: cuando se utiliza la característica Grupos de seguridad para los pods en EKS, aumenta la latencia de inicio de los pods.
**Solución**: la latencia se debe a la limitación de velocidad del controlador de recursos debido a la limitación de la API de `CreateNetworkInterface`, que el controlador de recursos de la VPC utiliza para crear ENI de rama para los pods. Compruebe los límites de la API de su cuenta para esta operación y considere la posibilidad de solicitar un aumento del límite si es necesario.
### FailedScheduling debido a una cantidad insuficiente de vpc.amazonaws.com/pod-eni
**Problema**: los pods no se programan y se produce el error `FailedScheduling 2m53s (x28 over 137m) default-scheduler 0/5 nodes are available: 5 Insufficient vpc.amazonaws.com/pod-eni. preemption: 0/5 nodes are available: 5 No preemption victims found for incoming pod.`
**Solución**: al igual que en el problema anterior, la asignación de grupos de seguridad a los pods aumenta la latencia de programación de los pods y puede sobrepasar el umbral de la CNI para añadir cada ENI, lo que provoca errores al iniciar los pods. Este es el comportamiento previsto cuando se utilizan grupos de seguridad para los pods. Considere las implicaciones de la programación al momento de diseñar la arquitectura de su carga de trabajo.
### Problemas de conectividad de IPAM y errores de segmentación
**Problema**: se producen varios errores, incluidos problemas de conectividad de IPAM, solicitudes de limitación y errores de segmentación.
+ `Checking for IPAM connectivity …`
+ `Throttling request took 1.047064274s`
+ `Retrying waiting for IPAM-D`
+ `panic: runtime error: invalid memory address or nil pointer dereference`
**Solución**: este problema se produce si se instala `systemd-udev` en AL2023, ya que el archivo se reescribe con una política de interrupción. Esto puede ocurrir cuando se actualiza a un `releasever` diferente que tiene un paquete actualizado o cuando se actualiza manualmente el paquete en sí. Evite instalar o actualizar `systemd-udev` en los nodos AL2023.
### Error al buscar el dispositivo por su nombre
**Problema**: mensaje de error `{"level":"error","ts":"2025-02-05T20:27:18.669Z","caller":"ebpf/bpf_client.go:578","msg":"failed to find device by name eni9ea69618bf0: %!w(netlink.LinkNotFoundError={0xc000115310})"}`
**Solución**: este problema se ha identificado y corregido en las versiones más recientes del agente de políticas de red CNI de Amazon VPC (v1.2.0). Actualice a la última versión de la CNI de VPC para resolver este problema.
### Vulnerabilidades de CVE en la imagen CNI de Multus
**Problema**: el informe CVE mejorado de EKS ImageScan identifica vulnerabilidades en la versión v4.1.4-eksbuild.2\$1thick de la imagen CNI de Multus.
**Solución**: actualice a la nueva versión de la imagen CNI de Multus y a la nueva imagen del Controlador de políticas de red, que no tienen vulnerabilidades. El escáner se puede actualizar para corregir las vulnerabilidades encontradas en la versión anterior.
### Veredictos de denegación del flujo de información en los registros
**Problema**: los registros de políticas de red muestran veredictos de denegación `{"level":"info","ts":"2024-11-25T13:34:24.808Z","logger":"ebpf-client","caller":"events/events.go:193","msg":"Flow Info: ","Src IP":"","Src Port":9096,"Dest IP":"","Dest Port":56830,"Proto":"TCP","Verdict":"DENY"}`
**Solución**: este problema se ha resuelto en la nueva versión del Controlador de políticas de red. Actualice a la versión más reciente de la plataforma de EKS para resolver los problemas de registro.
### Problemas de comunicación entre pods después de migrar desde Calico
**Problema**: tras actualizar un clúster de EKS a la versión 1.30 y cambiar de Calico a la CNI de Amazon VPC para la política de red, la comunicación entre pods falla cuando se aplican las políticas de red. La comunicación se restablece cuando se eliminan las políticas de red.
**Solución**: el agente de políticas de red de la CNI de la VPC no puede tener tantos puertos especificados como Calico. En su lugar, utilice rangos de puertos en las políticas de red. El número máximo de combinaciones únicas de puertos para cada protocolo en cada selector de `ingress:` o `egress:` en una política de red es 24. Utilice rangos de puertos para reducir la cantidad de puertos únicos y evitar esta limitación.
### El agente de políticas de red no admite pods independientes
**Problema**: las políticas de red aplicadas a los pods independientes pueden tener un comportamiento inconsistente.
**Solución**: actualmente, el agente de políticas de red solo admite los pods que se implementan como parte de un conjunto de réplicas/implementación. Si las políticas de red se aplican a los pods independientes, es posible que se produzcan algunas inconsistencias en el comportamiento. Esto se documenta en la parte superior de esta página, en [Consideraciones](cni-network-policy.md#cni-network-policy-considerations), y en [aws-network-policy-agent GitHub issue \$1327](https://github.com/aws/aws-network-policy-agent/issues/327) en GitHub. Implemente los pods como parte de un conjunto de réplicas o implementación para lograr un comportamiento consistente de las políticas de red.
# Demostración de Stars de política de red para Amazon EKS
Esta demostración crea un frontend, un backend y un servicio cliente en el clúster de Amazon EKS. La demostración también crea una interfaz gráfica de usuario de administración que muestra las rutas de entrada y salida disponibles entre los servicios. Le recomendamos que complete la demostración en un clúster en el que no ejecute cargas de trabajo de producción.
Cuando aún no se ha creado ninguna política de red, todos los servicios pueden comunicarse en ambas direcciones. Después de aplicar las políticas de red, puede ver que el cliente solo puede comunicarse con el servicio frontend y el backend solo puede aceptar tráfico del frontend.
1. Aplique los servicios de frontend, backend, cliente e interfaz de usuario de administración:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
```
1. Visualice todos los pods en el clúster.
```
kubectl get pods -A
```
Un ejemplo de salida sería el siguiente.
En la salida, debería ver pods en los espacios de nombres que se muestran en la siguiente salida. Los valores de *NAMES* y el número de pods de la columna `READY` son diferentes de los de la siguiente salida. No continúe hasta que vea pods con nombres similares y todos tengan `Running` en la columna `STATUS`.
```
NAMESPACE NAME READY STATUS RESTARTS AGE
[...]
client client-xlffc 1/1 Running 0 5m19s
[...]
management-ui management-ui-qrb2g 1/1 Running 0 5m24s
stars backend-sz87q 1/1 Running 0 5m23s
stars frontend-cscnf 1/1 Running 0 5m21s
[...]
```
1. Para conectarse a la interfaz de usuario de administración, conéctese a la `EXTERNAL-IP` del servicio que se ejecuta en el clúster:
```
kubectl get service/management-ui -n management-ui
```
1. Abra el navegador en la ubicación del paso anterior. Debería ver la interfaz de usuario de administración. El nodo **C** es el servicio cliente, el nodo **F** es el servicio frontend y el nodo **B** es el servicio backend. Cada nodo tiene acceso de comunicación completo a todos los demás nodos, como indican las líneas gruesas de colores.
![\[Abra la política de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/stars-default.png)
1. Aplique la siguiente política de red en los espacios de nombres de `stars` y `client` para aislar los servicios entre sí:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: default-deny
spec:
podSelector:
matchLabels: {}
```
Puede usar los siguientes comandos para aplicar la política a ambos espacios de nombres:
```
kubectl apply -n stars -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
```
1. Actualice su navegador. Verá que la interfaz de usuario de administración ya no tiene acceso a los nodos, que dejan de aparecer en la interfaz de usuario.
1. Aplique las siguientes políticas de red distintas para permitir el acceso de la interfaz de usuario de administración a los servicios. Aplique esta política para permitir la interfaz de usuario:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Aplique esta política para permitir el cliente:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: client
name: allow-ui
spec:
podSelector:
matchLabels: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
role: management-ui
```
Puede usar los siguientes comandos para aplicar ambas políticas:
```
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml
```
1. Actualice su navegador. Verá que la interfaz de usuario de administración tiene de nuevo acceso a los nodos, pero los nodos no pueden comunicarse entre sí.
![\[Política de red para el acceso de la interfaz de usuario\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/stars-no-traffic.png)
1. Aplique la siguiente política de red para permitir el tráfico desde el servicio frontend hacia el servicio backend:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: backend-policy
spec:
podSelector:
matchLabels:
role: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
```
1. Actualice su navegador. Puede ver que el frontend puede comunicarse con el backend.
![\[Política de frontend a backend\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/stars-front-end-back-end.png)
1. Aplique la siguiente política de red para permitir el tráfico desde el cliente hacia el servicio frontend:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
namespace: stars
name: frontend-policy
spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
role: client
ports:
- protocol: TCP
port: 80
```
1. Actualice su navegador. Verá que el cliente puede comunicarse con el servicio frontend. El servicio frontend puede seguir comunicándose con el servicio backend.
![\[Política de red final\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/stars-final.png)
1. (Opcional) Cuando haya terminado con la demostración, puede eliminar sus recursos.
```
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://raw.githubusercontent.com/aws-samples/eks-workshop/2f9d29ed3f82ed6b083649e975a0e574fb8a4058/content/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
```
Incluso después de eliminar los recursos, todavía puede haber puntos de conexión de las políticas de red en los nodos que podrían interferir de manera inesperada con las redes en el clúster. La única forma segura de eliminar estas reglas es reiniciar los nodos o terminar todos los nodos y reciclarlos. Para terminar todos los nodos, establezca el recuento deseado del grupo de Auto Scaling en 0 y, a continuación, realice una copia de seguridad en el número deseado o simplemente termine los nodos.
# Implementación de pods en subredes alternativas con redes personalizadas
**Aplicación**: en nodos de `IPv4` de Linux de Fargate, y nodos de Linux con instancias de Amazon EC2
![\[Diagrama de un nodo con múltiples interfaces de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/cn-image.png)
De forma predeterminada, cuando el complemento CNI de Amazon VPC para Kubernetes crea [interfaces de red elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) secundarias (interfaces de red) para el nodo de Amazon EC2, las crea en la misma subred que la interfaz de red principal del nodo. También asocia los mismos grupos de seguridad a la interfaz de red secundaria asociada a la interfaz de red principal. Por uno o varios de los siguientes motivos, es posible que desee que el complemento cree interfaces de red secundarias en una subred diferente o desee asociar distintos grupos de seguridad a las interfaces de red secundarias, o ambas:
+ Hay un número limitado de direcciones `IPv4` que están disponibles en la subred en la que se encuentra la interfaz de red principal. Esto podría limitar el número de pods que puede crear en la subred. Si utiliza una subred diferente para las interfaces de red secundarias, puede aumentar el número de direcciones `IPv4` disponibles para pods.
+ Por motivos de seguridad, sus pods podrían tener que utilizar distintos grupos de seguridad o subredes que la interfaz de red principal del nodo.
+ Los nodos se encuentran configurados en subredes públicas y debe ubicar los pods en subredes privadas. La tabla de enrutamiento asociada a una subred pública incluye una puerta de enlace de Internet. La tabla de enrutamiento asociada a una subred privada no incluye ninguna puerta de enlace de Internet.
**sugerencia**
También puede agregar una subred nueva o existente directamente al clúster de Amazon EKS, sin necesidad de utilizar redes personalizadas. Para obtener más información, consulte [Cómo agregar una subred de VPC existente a un clúster de Amazon EKS desde la consola de administración](eks-networking.md#add-existing-subnet).
## Consideraciones
A continuación, se detallan consideraciones que se deben tener a la hora de utilizar esta característica.
+ Con las redes personalizadas habilitadas, no se asignan direcciones IP asignadas a la interfaz de red principal a los pods. Solo se asignan direcciones IP de interfaces de red secundarias a pods.
+ Si el clúster utiliza la familia `IPv6`, no puede utilizar redes personalizadas.
+ Si planea utilizar redes personalizadas solo para ayudar a aliviar el agotamiento de direcciones `IPv4`, puede crear un clúster mediante la familia `IPv6` en su lugar. Para obtener más información, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
+ Si bien los pods implementados en las subredes especificadas para interfaces de red secundarias pueden utilizar subredes y grupos de seguridad diferentes a los de la interfaz de la red principal del nodo, las subredes y los grupos de seguridad deben estar en la misma VPC que el nodo.
+ En el caso de Fargate, las subredes se controlan mediante el perfil de Fargate. Para obtener más información, consulte [Cómo definir los pods que deben lanzarse en AWS Fargate](fargate-profile.md).
# Personalización de la interfaz de red secundaria en los nodos de Amazon EKS
Antes de comenzar este tutorial, complete lo siguiente:
+ Revisión de las consideraciones
+ Haberse familiarizado con cómo el complemento CNI de Amazon VPC para Kubernetes crea interfaces de red secundarias y asigna direcciones IP a los pods. Para obtener más información, consulte [Asignación de ENI](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) en GitHub.
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ Le recomendamos que siga los pasos de este tema en un intérprete de comandos Bash. Si no está utilizando un intérprete de comandos Bash, algunos comandos de script, como los caracteres de continuación de línea y la forma en que se establecen y utilizan las variables, requieren ajustes para su intérprete de comandos. Además, las reglas de entrecomillado y escape de su intérprete de comandos pueden ser diferentes. Para obtener más información, consulte [Uso de la AWS CLI con Amazon SNS](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) en la Guía del usuario de la interfaz de línea de comandos de AWS.
Para este tutorial, le recomendamos utilizar los valores de ejemplo, excepto en los casos en que se indique que se los debe reemplazar. Puede reemplazar cualquier ejemplo de valor al completar los pasos de un clúster de producción. Recomendamos completar todos los pasos en la misma terminal. Esto se debe a que las variables se establecen y utilizan a lo largo de los pasos y no existirán en terminales diferentes.
Los comandos de este tema se formatean según las convenciones que se indican en [Uso de los ejemplos de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Si ejecuta comandos desde la línea de comandos con recursos que se encuentran en una región de AWS diferente a la región de AWS predeterminada definida en el [perfil](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) de la AWS CLI que está utilizando, tendrá que agregar `--region us-west-2` a los comandos, después de sustituir `us-west-2` por la región de AWS.
Cuando desee implementar redes personalizadas en su clúster de producción, vaya a [Paso 2: Configurar la VPC](#custom-networking-configure-vpc).
## Paso 1: crear una VPC de prueba y un clúster
Los siguientes procedimientos le ayudan a crear una VPC de prueba y un clúster, y a configurar redes personalizadas para ese clúster. No recomendamos utilizar el clúster de pruebas para cargas de trabajo de producción porque en este tema no se cubren varias características no relacionadas que podría utilizar en el clúster de producción. Para obtener más información, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).
1. Ejecute el siguiente comando para definir la variable `account_id`.
```
account_id=$(aws sts get-caller-identity --query Account --output text)
```
1. Cree una VPC.
1. Si va a realizar la implementación en un sistema de prueba, cree una VPC con una plantilla AWS CloudFormation de Amazon EKS.
```
aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
--template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
--parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
```
1. La pila de AWS CloudFormation tarda unos minutos en crearse. Para verificar el estado de implementación de la pila, ejecute el siguiente comando.
```
aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus --output text
```
No continúe con el siguiente paso hasta que la salida del comando sea `CREATE_COMPLETE`.
1. Defina variables con los valores de los ID de subred privada creados por la plantilla.
```
subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
--query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
```
1. Defina variables con las zonas de disponibilidad de las subredes recuperadas en el paso anterior.
```
az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
```
1. Cree un rol de IAM de clúster.
1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Cree el rol de IAM del clúster de Amazon EKS. Si es necesario, prefacio `eks-cluster-role-trust-policy.json` con la ruta del equipo en la que escribió el archivo en el paso anterior. El comando asocia la política de confianza creada en el paso anterior al rol. Para crear un rol de IAM, a la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que está creando el rol se le debe asignar la acción `iam:CreateRole` (permiso).
```
aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Adjunte la política administrada de Amazon EKS llamada [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) al rol. Para adjuntar una política de IAM a una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), se debe asignar una de las siguientes acciones de IAM (permisos) a la entidad principal que adjunta la política: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Cree un clúster de Amazon EKS y configure su dispositivo para que se comunique con él.
1. Cree un clúster.
```
aws eks create-cluster --name my-custom-networking-cluster \
--role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
--resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
```
**nota**
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
1. El clúster tarda varios minutos en crearse. Ejecute el siguiente comando para verificar el estado de implementación del clúster.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
```
No continúe con el siguiente paso hasta que la salida del comando sea `"ACTIVE"`.
1. Configure `kubectl` para comunicarse con el clúster.
```
aws eks update-kubeconfig --name my-custom-networking-cluster
```
## Paso 2: Configurar la VPC
Este tutorial requiere una VPC creada en [Paso 1: crear una VPC de prueba y un clúster](#custom-networking-create-cluster). En el caso de un clúster de producción, ajuste los pasos correspondientes a su VPC sustituyendo todos los valores de ejemplo con los suyos propios.
1. Confirme que el complemento CNI de Amazon VPC para Kubernetes instalado actualmente es la última versión. Para determinar la versión más reciente del tipo de complemento de Amazon EKS y actualizar su versión a ella, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md). Para determinar la versión más reciente del tipo de complemento autoadministrado y actualizar su versión a ella, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).
1. Recupere el ID de la VPC de su clúster y guárdelo en una variable para utilizarlo en un paso posterior.
```
vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
```
1. Asocie un bloque de enrutamiento entre dominios sin clases (CIDR) con la VPC de su clúster. El bloque CIDR no se puede solapar con ningún bloque CIDR asociado existente.
1. Vea los bloques CIDR actuales asociados a la VPC.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id \
--query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Un ejemplo de salida sería el siguiente.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
+-----------------+--------------+
```
1. Asocie un bloque CIDR adicional a su VPC. Sustituya el valor del bloque de CIDR en el siguiente comando. Para obtener más información, consulte [Asociar un bloque adicional de CIDR IPv4 a su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) en la Guía del usuario de Amazon VPC.
```
aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
```
1. Confirme que el nuevo bloque está asociado.
```
aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
```
Un ejemplo de salida sería el siguiente.
```
----------------------------------
| DescribeVpcs |
+-----------------+--------------+
| CIDRBlock | State |
+-----------------+--------------+
| 192.168.0.0/24 | associated |
| 192.168.1.0/24 | associated |
+-----------------+--------------+
```
No continúe con el siguiente paso hasta que el `State` del nuevo bloque CIDR sea `associated`.
1. Cree tantas subredes como desee utilizar en cada zona de disponibilidad en la que se encuentran las subredes existentes. Especifique un bloque CIDR que se encuentra dentro del bloque CIDR que asoció a la VPC en un paso anterior.
1. Crea nuevas subredes. Sustituya los valores del bloque de CIDR en el siguiente comando. Las subredes deben crearse en un bloque CIDR de VPC diferente al que están las subredes existentes, pero en las mismas zonas de disponibilidad que las subredes existentes. En este ejemplo, se crea una subred en el nuevo bloque CIDR de cada zona de disponibilidad en la que existen las subredes privadas actuales. Los ID de las subredes creadas se almacenan en variables para usarlas en los pasos posteriores. Los valores `Name` coinciden con los valores asignados a las subredes creadas mediante la plantilla de Amazon EKS VPC en un paso anterior. No se requieren nombres. Puede utilizar diferentes nombres.
```
new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
--query Subnet.SubnetId --output text)
```
**importante**
De forma predeterminada, las nuevas subredes están asociadas implícitamente con su [tabla de enrutamiento principal](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) de VPC. Esta tabla de enrutamiento permite la comunicación entre todos los recursos que se implementan en la VPC. Sin embargo, no permite la comunicación con recursos que tienen direcciones IP que están fuera de los bloques CIDR asociados a la VPC. Puede asociar su propia tabla de enrutamiento a las subredes para cambiar este comportamiento. Para obtener más información, consulte [Tablas de enrutamiento de subredes](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) en la Guía del usuario de Amazon VPC.
1. Para ver las subredes actuales en su VPC.
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
--query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
--output table
```
Un ejemplo de salida sería el siguiente.
```
----------------------------------------------------------------------
| DescribeSubnets |
+------------------+--------------------+----------------------------+
| AvailabilityZone | CidrBlock | SubnetId |
+------------------+--------------------+----------------------------+
| us-west-2d | 192.168.0.0/27 | subnet-example1 |
| us-west-2a | 192.168.0.32/27 | subnet-example2 |
| us-west-2a | 192.168.0.64/27 | subnet-example3 |
| us-west-2d | 192.168.0.96/27 | subnet-example4 |
| us-west-2a | 192.168.1.0/27 | subnet-example5 |
| us-west-2d | 192.168.1.32/27 | subnet-example6 |
+------------------+--------------------+----------------------------+
```
Puede ver que las subredes en el bloque CIDR `192.168.1.0` que ha creado se encuentran en las mismas zonas de disponibilidad que las subredes del bloque CIDR `192.168.0.0`.
## Paso 3: Configurar los recursos de Kubernetes
1. Establezca la variable de entorno de `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` a `true` en el DaemonSet de `aws-node`.
```
kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
```
1. Recupere el ID del [grupo de seguridad del clúster](sec-group-reqs.md) y guárdelo en una variable para utilizarlo en un paso posterior. Amazon EKS crea automáticamente este grupo de seguridad cuando crea el clúster.
```
cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
```
1. Cree un recurso personalizado `ENIConfig` para cada subred en la que desee programar pods.
1. Cree un archivo único para cada configuración de interfaz de red.
Los siguientes comandos crean archivos `ENIConfig` por separado de las dos subredes que se han creado en un paso anterior. El valor de `name` debe ser único. El nombre es el mismo que la zona de disponibilidad en la que se encuentra la subred. El grupo de seguridad del clúster está asignado al `ENIConfig`.
```
cat >$az_1.yaml <$az_2.yaml <
1. Creación de un rol de IAM de nodo.
1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Cree un rol de IAM y almacene el nombre de recurso de Amazon (ARN) devuelto en una variable para usarla en un paso posterior.
```
node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
--query Role.Arn --output text)
```
1. Adjunte al rol de IAM las tres políticas administradas por IAM necesarias.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name myCustomNetworkingNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name myCustomNetworkingNodeRole
```
**importante**
Para simplificar este tutorial, la política [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) se adjunta al rol de IAM de nodo. Sin embargo, en un clúster de producción, recomendamos adjuntar la política a un rol de IAM independiente que se usa solo con el complemento CNI de Amazon VPC para Kubernetes. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
1. Cree uno de los siguientes tipos de grupos de nodos. Para determinar el tipo de instancia que desea implementar, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Para este tutorial, complete la opción **Administrado**, **Sin plantilla de lanzamiento o con plantilla de lanzamiento sin un ID de AMI especificado**. Si planea utilizar el grupo de nodos para cargas de trabajo en entornos de producción, se recomienda familiarizarse con todas las opciones disponibles para grupos de nodos [administrados](create-managed-node-group.md) y [autoadministrados](worker.md) antes de proceder con su implementación.
+ **Administrado**: implemente el grupo de nodos mediante una de las siguientes opciones:
+ **Sin plantilla de lanzamiento o con plantilla de lanzamiento sin un ID de AMI especificado**: complete el procedimiento indicado. Para este tutorial, utilice los valores de ejemplo. Para un grupo de nodos de producción, reemplace todos los valores de ejemplo con sus propios valores. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales.
```
aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
--subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
```
+ **Con una plantilla de lanzamiento con un ID de AMI especificado**
1. Determine el número máximo de pods que recomienda Amazon EKS para sus nodos. Siga las instrucciones que aparecen en , con la adición de `--cni-custom-networking-enabled` al paso 3 de ese tema. Observe la salida de su uso en el siguiente paso.
1. En la plantilla de lanzamiento, especifique un ID de AMI optimizado para Amazon EKS o una AMI personalizada creada a partir de la AMI optimizada para Amazon EKS y, luego, [implemente el grupo de nodos mediante una plantilla de lanzamiento](launch-templates.md) y proporcione los siguientes datos de usuario en la plantilla de lanzamiento. Estos datos de usuario pasan los argumentos a la especificación `NodeConfig`. Para obtener más información sobre NodeConfig, consulte la [referencia de la API de NodeConfig](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Puede sustituir `20` por el valor del paso anterior (recomendado) o por un valor propio.
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
...
kubelet:
config:
maxPods: 20
```
Si ha creado una AMI personalizada, pero no a partir de la AMI optimizada de Amazon EKS, debe crear personalmente la configuración.
+ **Autoadministrado**
1. Determine el número máximo de pods que recomienda Amazon EKS para sus nodos. Siga las instrucciones de , agregando `--cni-custom-networking-enabled` al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.
1. Implemente el grupo de nodos con las instrucciones en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md).
**nota**
Si desea que los nodos de un clúster de producción admitan un número significativamente mayor de pods, ejecute el script en de nuevo. Además, agregue la opción `--cni-prefix-delegation-enabled` al siguiente comando. Por ejemplo, se devuelve `110` para un tipo de instancia `m5.large`. Para obtener instrucciones sobre cómo habilitar esta capacidad, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md). Puede utilizar esta capacidad con redes personalizadas.
1. La creación de grupos de nodos tarda varios minutos. Puede comprobar el estado de la creación de un grupo de nodos administrados con el siguiente comando.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.
1. Para ver el tutorial, puede omitir este paso.
En caso de un clúster de producción, si no ha nombrado su `ENIConfigs` con el mismo nombre que la zona de disponibilidad para la que la utiliza, entonces debe anotar sus nodos con el nombre de `ENIConfig` que debe utilizarse con el nodo. Este paso no es necesario si tiene solo una subred en cada zona de disponibilidad y ha nombrado sus `ENIConfigs` con los mismos nombres que dichas zonas. Esto se debe a que el complemento CNI de Amazon VPC para Kubernetes asocia automáticamente la `ENIConfig` correcta con el nodo cuando lo habilitó para esto en un [paso anterior](#custom-networking-automatically-apply-eniconfig).
1. Obtenga la lista de nodos del clúster.
```
kubectl get nodes
```
Un ejemplo de salida sería el siguiente.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-0-126.us-west-2.compute.internal Ready 8m49s v1.22.9-eks-810597c
ip-192-168-0-92.us-west-2.compute.internal Ready 8m34s v1.22.9-eks-810597c
```
1. Determine en qué zona de disponibilidad se encuentra cada nodo. Ejecute el siguiente comando para cada nodo que se devolvió en el paso anterior y reemplace las direcciones IP en función del resultado anterior.
```
aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
--query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
```
Un ejemplo de salida sería el siguiente.
```
[
{
"AvailabilityZone": "us-west-2d",
"SubnetId": "subnet-Example5"
}
]
```
1. Anote cada nodo con la `ENIConfig` que creó para el ID de subred y la zona de disponibilidad. Solo puede anotar un nodo con una `ENIConfig`, aunque se pueden anotar varios nodos con la misma `ENIConfig`. Sustituya los valores de ejemplo por sus propios valores.
```
kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
```
1. Si tenía nodos en un clúster de producción con pods en ejecución antes de comenzar a utilizar la característica de redes personalizadas, lleve a cabo las siguientes tareas:
1. Asegúrese de tener nodos disponibles que utilizan la característica de red personalizada.
1. Acordone y drene los nodos para apagar correctamente los pods. Para obtener más información, consulte [Drene un nodo de manera segura](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes.
1. Termine los nodos. Si los nodos se encuentran en un grupo de nodos administrado existente, puede eliminar el grupo de nodos. Ejecute el siguiente comando.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
Solo los nodos nuevos que se registran con la etiqueta `k8s.amazonaws.com/eniConfig` utilizan la característica de redes personalizadas.
1. Confirme que los pods estén asignados en una dirección IP de un bloque de CIDR asociado a una de las subredes que creó en un paso anterior.
```
kubectl get pods -A -o wide
```
Un ejemplo de salida sería el siguiente.
```
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
kube-system aws-node-2rkn4 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system aws-node-k96wp 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
kube-system coredns-657694c6f4-smcgr 1/1 Running 0 56m 192.168.1.23 ip-192-168-0-92.us-west-2.compute.internal
kube-system coredns-657694c6f4-stwv9 1/1 Running 0 56m 192.168.1.28 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-jgshq 1/1 Running 0 7m19s 192.168.0.92 ip-192-168-0-92.us-west-2.compute.internal
kube-system kube-proxy-wx9vk 1/1 Running 0 7m15s 192.168.0.126 ip-192-168-0-126.us-west-2.compute.internal
```
Puede ver que a los pods de CoreDNS se les asignan direcciones IP desde el bloque de CIDR `192.168.1.0` que ha agregado a la VPC. Sin redes personalizadas, se les habrían asignado direcciones desde el bloque CIDR `192.168.0.0`, porque era el único bloque CIDR asociado originalmente a la VPC.
Si la `spec` de un pod contiene `hostNetwork=true`, se le asigna la dirección IP principal del nodo. No se le asigna una dirección de las subredes que ha agregado. De forma predeterminada, este valor se establece en `false`. Este valor se establece en `true` para `kube-proxy` y los pods del complemento CNI de Amazon VPC para Kubernetes (`aws-node`) que se ejecutan en su clúster. Esta es la razón por la que a `kube-proxy` y a los pods de `aws-node` del complemento no se les asignan direcciones 192.168.1.x en la salida anterior. Para obtener más información acerca de la configuración de `hostNetwork` del pod, consulte [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) en la referencia de API de Kubernetes.
## Paso 5: eliminar recursos del tutorial
Una vez completado el tutorial, le recomendamos que elimine los recursos que creó. Puede ajustar los pasos para habilitar las redes personalizadas para un clúster de producción.
1. Si el grupo de nodos que creó fue solo para pruebas, bórrelo.
```
aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
```
1. Incluso después de que la salida de la AWS CLI indica que el clúster se ha eliminado, es posible que el proceso de eliminación no esté completo. El proceso de eliminación tarda unos minutos. Confirme que se ha completado al ejecutar el siguiente comando.
```
aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
```
No continúe hasta que la salida devuelta sea similar a la siguiente.
```
An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
```
1. Si el grupo de nodos que creó fue solo para pruebas, elimine el rol de IAM de nodo.
1. Separe la política del rol.
```
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
```
1. Elimine el rol.
```
aws iam delete-role --role-name myCustomNetworkingNodeRole
```
1. Elimine el clúster.
```
aws eks delete-cluster --name my-custom-networking-cluster
```
Confirme que el clúster se elimine con el siguiente comando.
```
aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
```
Cuando se devuelve un resultado similar al siguiente, el clúster se eliminará correctamente.
```
An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
```
1. Elimine el rol de IAM del clúster.
1. Separe la política del rol.
```
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
1. Elimine el rol.
```
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
```
1. Elimine las subredes que creó en un paso anterior.
```
aws ec2 delete-subnet --subnet-id $new_subnet_id_1
aws ec2 delete-subnet --subnet-id $new_subnet_id_2
```
1. Elimine la VPC que ha creado.
```
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
```
# Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos
**Aplicación**: en nodos de Linux y Windows con instancias de Amazon EC2
**Aplicación**: en subredes públicas y privadas
Cada instancia de Amazon EC2 admite una cantidad máxima de interfaces de red elásticas y una cantidad máxima de direcciones IP que se pueden asignar a cada interfaz de red. Cada nodo requiere una dirección IP para cada interfaz de red. Se pueden asignar todas las demás direcciones IP disponibles a `Pods`. Cada uno `Pod` requiere su propia dirección IP. Como resultado, es posible que tenga nodos que tengan recursos informáticos y de memoria disponibles, pero que no puedan acomodar `Pods` adicionales porque el nodo se quedó sin direcciones IP para asignar a `Pods`.
Puede aumentar la cantidad de direcciones IP que los nodos pueden asignar a `Pods` mediante la asignación de prefijos de IP, en lugar de asignar direcciones IP secundarias individuales a sus nodos. Cada prefijo incluye varias direcciones IP. Si no configura su clúster para la asignación de prefijos IP, deberá hacer más llamadas desde su clúster a la interfaz de programación de aplicaciones (API) de Amazon EC2 para configurar las interfaces de red y las direcciones IP necesarias para la conectividad de los pods. A medida que los clústeres crecen a tamaños más grandes, la frecuencia de estas llamadas a la API puede generar tiempos de lanzamiento de instancias y pods más prolongados. Esto causa retrasos en el escalado para satisfacer la demanda de cargas de trabajo grandes y exigentes, y agrega costos y gastos generales de administración, ya que necesita aprovisionar clústeres y VPC adicionales para cumplir con los requisitos de escalado. Para obtener más información, consulte [Umbrales de escalabilidad de Kubernetes](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) en GitHub.
## Compatibilidad con las características del complemento CNI de Amazon VPC para Kubernetes
Puede utilizar prefijos de IP con las siguientes características:
+ Traducción de direcciones de red de origen IPv4 (para obtener más información, consulte [Habilitación del acceso a Internet saliente para pods](external-snat.md)).
+ Direcciones IPv6 para clústeres, pods y servicios (para obtener más información, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md)).
+ Restricción del tráfico con políticas de red de Kubernetes. Para obtener más información, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md).
La siguiente lista proporciona información sobre la configuración del complemento de CNI de Amazon VPC que se aplica. Para obtener más información acerca de cada configuración, consulte [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) en GitHub.
+ `WARM_IP_TARGET`
+ `MINIMUM_IP_TARGET`
+ `WARM_PREFIX_TARGET`
## Consideraciones
Cuando utilice esta característica, tenga en cuenta lo siguiente:
+ Cada tipo de instancia de Amazon EC2 admite una cantidad máxima de pods. Si el grupo de nodos administrado consta de varios tipos de instancias, el número de pods máximo menor de una instancia del clúster se aplica a todos los nodos del clúster.
+ De forma predeterminada, el número máximo de `Pods` que puede ejecutar en un nodo es 110, pero puede cambiar ese número. Si cambia el número y tiene un grupo de nodos administrado existente, la siguiente AMI o la actualización de la plantilla de lanzamiento de su grupo de nodos generará nuevos nodos con el valor modificado.
+ Al pasar de la asignación de direcciones IP a la asignación de prefijos de IP, le recomendamos que cree nuevos grupos de nodos para aumentar la cantidad de direcciones IP disponibles, en lugar de realizar un reemplazo gradual de los nodos existentes. La ejecución de pods en un nodo que tiene direcciones IP y prefijos asignados puede generar incoherencias en la capacidad de direcciones IP anunciada, lo que afecta a las futuras cargas de trabajo en el nodo. Para conocer la forma recomendada de efectuar la transición, consulte [Prefix Delegation mode for Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) en la *Guía de prácticas recomendadas de Amazon EKS*.
+ El alcance del grupo de seguridad se encuentra en el nivel del nodo. Para obtener más información, consulte [Grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
+ Los prefijos de IP asignados a una interfaz de red admiten una alta densidad de pods por nodo y tienen el mejor tiempo de lanzamiento.
+ Los prefijos IP y las direcciones IP están asociados a las interfaces de red elásticas estándar de Amazon EC2. A los pods que requieren grupos de seguridad específicos se les asigna la dirección IP principal de una interfaz de red de ramificación. Puede mezclar pods que obtengan direcciones IP o direcciones IP de prefijos IP con pods que obtengan interfaces de red de ramificación en el mismo nodo.
+ Solo para clústeres con nodos Linux.
+ Luego de configurar el complemento para asignar prefijos a las interfaces de red, no podrá degradar el complemento CNI de Amazon VPC para Kubernetes a una versión anterior a `1.9.0` (o `1.10.1`) sin eliminar todos los nodos de todos los grupos de nodos en el clúster.
+ Si también utiliza grupos de seguridad para pods, con `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard` y `AWS_VPC_K8S_CNI_EXTERNALSNAT`=`false`, cuando los pods se comunican con los puntos de conexión fuera de su VPC, se utilizan los grupos de seguridad del nodo, en lugar de cualquier grupo de seguridad que haya asignado a sus pods.
Si también utiliza [grupos de seguridad para pods](security-groups-for-pods.md), con `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, cuando los `Pods` se comunican con los puntos de conexión fuera de la VPC, se utilizan los grupos de seguridad de `Pod’s`.
# Aumento de las direcciones IP disponibles para su nodo de Amazon EKS
Puede aumentar la cantidad de direcciones IP que los nodos pueden asignar a pods mediante la asignación de prefijos de IP, en lugar de asignar direcciones IP secundarias individuales a sus nodos.
## Requisitos previos
+ Necesita un clúster existente. Para implementar uno, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).
+ Las subredes en las que se encuentran sus nodos de Amazon EKS deben tener suficientes bloques contiguos `/28` (para clústeres `IPv4`) o `/80` (para clústeres `IPv6`) enrutamiento entre dominios sin clases (CIDR). Solo puede tener nodos Linux en un clúster `IPv6`. El uso de prefijos IP puede fallar si las direcciones IP están dispersas por toda la subred de CIDR. Le recomendamos lo siguiente:
+ Utilizar una reserva de CIDR de subred para que, aunque se siga utilizando alguna dirección IP dentro del rango reservado, una vez publicada, no se reasignen las direcciones IP. Esto garantiza que los prefijos estén disponibles para su asignación sin segmentación.
+ Utilice nuevas subredes que se usen específicamente para ejecutar las cargas de trabajo a las que se asignan los prefijos IP. Tanto las cargas de trabajo de Windows como las de Linux pueden ejecutarse en la misma subred cuando se asignan prefijos de IP.
+ Para asignar prefijos de IP a sus nodos, sus nodos deben estar basados en AWS Nitro. Las instancias que no se basan en Nitro continúan asignando direcciones IP secundarias individuales, pero tienen un número significativamente menor de direcciones IP para asignar a los pods que las instancias basadas en Nitro.
+ **Solo para clústeres con nodos de Linux**: si su clúster está configurado para la familia `IPv4`, debe tener instalada la versión `1.9.0` o posterior del complemento CNI de Amazon VPC para Kubernetes. Puede comprobar su versión actual con el siguiente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
```
Si su clúster está configurado para la familia `IPv6`, debe tener instalada la versión `1.10.1` o del complemento. Si la versión de su complemento es anterior a las versiones requeridas, debe actualizarlo. Para obtener más información, consulte las secciones de actualización del artículo [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).
+ **Solo para clústeres con nodos de Linux**
+ Debe tener la compatibilidad con Windows habilitada para el clúster. Para obtener más información, consulte [Implementación de nodos de Windows en clústeres de EKS](windows-support.md).
## Asignación de prefijos de direcciones IP a los nodos
Configure el clúster para asignar prefijos de direcciones IP a los nodos. Complete el procedimiento que coincida con el sistema operativo de su nodo.
### Linux
1. Habilite el parámetro a fin de asignar prefijos a las interfaces de red para el DaemonSet de CNI de Amazon VPC. Cuando implementa un clúster, la versión `1.10.1` o posterior del complemento CNI de Amazon VPC para Kubernetes se implementa con él. Si ha creado el clúster con la familia `IPv6`, este ajuste se configuró en `true` de forma predeterminada. Si ha creado el clúster con la familia `IPv4`, este ajuste se configuró en `false` de forma predeterminada.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
```
**importante**
Incluso si la subred tiene direcciones IP disponibles, si la subred no tiene disponible ningún bloque `/28` contiguo, verá el siguiente error en los registros del complemento CNI de Amazon VPC para Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Esto puede ocurrir debido a la fragmentación de las direcciones IP secundarias existentes distribuidas por una subred. Para resolver este error, cree una nueva subred y lance pods allí, o utilice una reserva de CIDR de subred de Amazon EC2 para reservar espacio dentro de una subred para utilizarla con la asignación de prefijos. Para obtener más información, consulte [Reservas de la subred de CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) en la Guía del usuario de Amazon VPC.
1. Si planea implementar un grupo de nodos administrado sin una plantilla de lanzamiento o con una plantilla de lanzamiento en la que no ha especificado un ID de AMI, y utiliza una versión del complemento CNI de Amazon VPC para Kubernetes igual o posterior a las versiones enumeradas en los requisitos previos, continúe con el siguiente paso. Los grupos de nodos administrados calculan automáticamente el número máximo de pods.
Si va a implementar un grupo de nodos autoadministrado o un grupo de nodos administrado con una plantilla de lanzamiento en la que ha especificado un ID de AMI, debe determinar el número máximo de pods recomendados por Amazon EKS para los nodos. Siga las instrucciones que aparecen en , y con la adición de `--cni-prefix-delegation-enabled` al paso 3. Observe la salida de su uso en un paso posterior.
**importante**
Los grupos de nodos administrados aplican un número máximo en el valor `maxPods`. Para las instancias con menos de 30 vCPU, el número máximo es 110 y para todas las demás instancias el número máximo es 250. Este número máximo se aplica independientemente de si la delegación de prefijos está habilitada o no.
1. Si utiliza un clúster configurado para `IPv6`, continúe con el siguiente paso.
Especifique los parámetros en una de las siguientes opciones. Para determinar qué opción es la adecuada y qué valor debe proporcionarle, consulte [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md) em GitHub.
Puede reemplazar example values por un valor mayor a cero.
+ `WARM_PREFIX_TARGET`
```
kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1
```
+ `WARM_IP_TARGET` o `MINIMUM_IP_TARGET`: si se establece este valor, sustituye a cualquier valor establecido para `WARM_PREFIX_TARGET`.
```
kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5
```
```
kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2
```
1. Cree uno de los siguientes tipos de grupos de nodos con al menos un tipo de instancia Nitro de Amazon Linux 2023 de Amazon EC2. A fin de obtener una lista de los tipos de instancias de Nitro, consulte [Instancias integradas en el sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) en la Guía del usuario de Amazon EC2. Esta capacidad no es compatible con Windows. En el caso de las opciones que incluyen *110*, reemplácelo por el valor del paso tres (recomendado) o un valor propio.
+ **Autoadministrado**: implementa el grupo de nodos según las instrucciones que aparecen en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md). Antes de crear la pila de CloudFormation, abra el archivo de plantilla y ajuste `UserData` en la `NodeLaunchTemplate` para que sea como se muestra a continuación.
```
...
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: ${ClusterName}
apiServerEndpoint: ${ApiServerEndpoint}
certificateAuthority: ${CertificateAuthorityData}
cidr: ${ServiceCidr}
kubelet:
config:
maxPods: 110
...
```
Si utiliza `eksctl` para crear el grupo de nodos, utilice el siguiente comando.
```
eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110
```
+ **Administrado**: implemente el grupo de nodos mediante una de las siguientes opciones:
+ **Sin una plantilla de lanzamiento o con una plantilla de lanzamiento sin un ID de AMI especificado**: complete el procedimiento indicado en [Creación de un grupo de nodos administrados para un clúster](create-managed-node-group.md). Los grupos de nodos administrados calculan automáticamente el valor `max-pods` recomendados por Amazon EKS.
+ **Con una plantilla de lanzamiento con un ID de AMI especificado**: en la plantilla de lanzamiento, especifique un ID de AMI optimizada para Amazon EKS o una AMI personalizada creada a partir de la AMI optimizada para Amazon EKS y, a continuación, [implemente el grupo de nodos mediante una plantilla de lanzamiento](launch-templates.md) y proporcione los siguientes datos de usuario en la plantilla de lanzamiento. Estos datos de usuario se transfieren a un objeto `NodeConfig` para que la herramienta `nodeadm` los lea en el nodo. Para obtener más información acerca de `nodeadm`, consulte la [documentación de nodeadm](https://awslabs.github.io/amazon-eks-ami/nodeadm).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="//"
--//
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
apiServerEndpoint: [.replaceable]`my-cluster`
certificateAuthority: [.replaceable]`LS0t...`
cidr: [.replaceable]`10.100.0.0/16`
name: [.replaceable]`my-cluster
kubelet:
config:
maxPods: [.replaceable]`110`
--//--
```
Si utiliza `eksctl` para crear el grupo de nodos, utilice el siguiente comando.
```
eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110
```
Si ha creado una AMI personalizada, pero no a partir de la AMI optimizada de Amazon EKS, debe crear personalmente la configuración.
**nota**
Si también desea asignar direcciones IP a pods de una subred diferente a la de la instancia, debe habilitar la capacidad en este paso. Para obtener más información, consulte [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md).
### Windows
1. Habilite la asignación de prefijos IP.
1. Abra el `ConfigMap` de `amazon-vpc-cni` para editar.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Añada la siguiente línea a la sección `data`:
```
enable-windows-prefix-delegation: "true"
```
1. Guarde el archivo y cierre el editor.
1. Confirme que la línea se agregó a `ConfigMap`.
```
kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"
```
Si la salida devuelta no es `true`, es posible que haya ocurrido un error. Intente completar el paso de nuevo.
**importante**
Incluso si la subred tiene direcciones IP disponibles, si la subred no tiene disponible ningún bloque `/28` contiguo, verá el siguiente error en los registros del complemento CNI de Amazon VPC para Kubernetes.
```
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
```
Esto puede ocurrir debido a la fragmentación de las direcciones IP secundarias existentes distribuidas por una subred. Para resolver este error, cree una nueva subred y lance pods allí, o utilice una reserva de CIDR de subred de Amazon EC2 para reservar espacio dentro de una subred para utilizarla con la asignación de prefijos. Para obtener más información, consulte [Reservas de la subred de CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) en la Guía del usuario de Amazon VPC.
1. (Opcional) Especifique una configuración adicional para controlar el comportamiento de escalado previo y dinámico del clúster. Para obtener más información, consulte [Opciones de configuración con modo de delegación de prefijo en Windows](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) en GitHub.
1. Abra el `ConfigMap` de `amazon-vpc-cni` para editar.
```
kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
```
1. Sustituya los valores de ejemplo por un valor superior a cero y agregue las entradas que necesite a la sección `data` de `ConfigMap`. Si establece un valor para `warm-ip-target` o `minimum-ip-target`, el valor anula cualquier valor establecido para `warm-prefix-target`.
```
warm-prefix-target: "1"
warm-ip-target: "5"
minimum-ip-target: "2"
```
1. Guarde el archivo y cierre el editor.
1. Cree grupos de nodos de Windows con al menos un tipo de instancia Nitro de Amazon EC2. A fin de obtener una lista de los tipos de instancias de Nitro, consulte [Instancias integradas en el sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) en la Guía del usuario de Amazon EC2. De forma predeterminada, la cantidad máxima de pods que puede implementar en un nodo es 110. Si desea aumentar o disminuir ese número, especifique lo siguiente en los datos de usuario para la configuración de arranque. Reemplace *max-pods-quantity* con su valor máximo de pods.
```
-KubeletExtraArgs '--max-pods=max-pods-quantity'
```
Si está implementando grupos de nodos administrados, esta configuración debe agregarse en la plantilla de lanzamiento. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md). Para obtener más información sobre los parámetros de configuración para el script de arranque de Windows, consulte [Parámetros de configuración del script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
## Cómo determinar el número máximo de pods y las direcciones IP disponibles
1. Una vez que se implementan los nodos, consulte los nodos del clúster.
```
kubectl get nodes
```
Un ejemplo de salida sería el siguiente.
```
NAME STATUS ROLES AGE VERSION
ip-192-168-22-103.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464
```
1. Describa uno de los nodos para determinar el valor de `max-pods` para el nodo y el número de direcciones IP disponibles. Reemplace *192.168.30.193* con la dirección `IPv4` en el nombre de uno de sus nodos devueltos en la salida anterior.
```
kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'
```
Un ejemplo de salida sería el siguiente.
```
pods: 110
vpc.amazonaws.com/PrivateIPv4Address: 144
```
En el resultado anterior, `110` es el número máximo de pods que Kubernetes implementará en el nodo, aunque haya *144* direcciones IP disponibles.
# Asignación de los grupos de seguridad a pods individuales
**Aplicación**: en nodos de Linux con instancias de Amazon EC2
**Aplicación**: en subredes privadas
Los grupos de seguridad para pods integran los grupos de seguridad de Amazon EC2 con los pods de Kubernetes. Puede utilizar grupos de seguridad de Amazon EC2 para definir reglas que permitan el tráfico de red entrante y saliente hacia y desde los pods que implemente en nodos que se ejecutan en muchos tipos de instancias de Amazon EC2 y Fargate. Para obtener una explicación más detallada de esta capacidad, consulte la publicación de blog [Presentación de los grupos de seguridad de pods](https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods).
## Compatibilidad con las características del complemento CNI de Amazon VPC para Kubernetes
Puede usar grupos de seguridad para pods con las siguientes características:
+ Traducción de direcciones de red de origen IPv4 (para obtener más información, consulte ) [Habilitación del acceso a Internet saliente para pods](external-snat.md).
+ Direcciones IPv6 para clústeres, pods y servicios (para obtener más información, consulte ) [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
+ Restricción del tráfico con políticas de red de Kubernetes. Para obtener más información, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md).
## Consideraciones
Antes de implementar grupos de seguridad para pods, tenga en cuenta las siguientes limitaciones y condiciones:
+ Los grupos de seguridad de pods no se pueden utilizar con nodos de Windows ni el modo automático de EKS.
+ Los grupos de seguridad para pods pueden utilizarse en clústeres configurados para la familia `IPv6` que contengan nodos de Amazon EC2 mediante la versión 1.16.0 o posterior del complemento CNI de Amazon VPC. Puede usar grupos de seguridad para pods con clústeres configurados para la familia `IPv6` que contengan solo nodos de Fargate mediante la versión 1.7.7 o posterior del complemento CNI de Amazon VPC. Para obtener más información, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md)
+ Los grupos de seguridad para pods son compatibles con la mayoría de las familias de instancias de Amazon EC2 [basadas en Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances), aunque no en todas las generaciones de una familia. Por ejemplo, las generaciones y familia de instancias `m5`, `c5`, `r5`, `m6g`, `c6g` y `r6g` son compatibles. No se admite ningún tipo de instancia de la familia `t`. Para obtener una lista completa de los tipos de instancias compatibles, consulte el archivo [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/v1.5.0/pkg/aws/vpc/limits.go) en GitHub. Sus nodos deben ser uno de los tipos de instancias enumerados que tienen `IsTrunkingCompatible: true` en ese archivo.
+ Si utiliza conjuntamente redes personalizadas y grupos de seguridad de pods, se utiliza el grupo de seguridad especificado por los grupos de seguridad de pods en lugar del grupo de seguridad especificado en `ENIConfig`.
+ Si utiliza la versión `1.10.2` o anterior del complemento CNI de Amazon VPC e incluye la configuración de `terminationGracePeriodSeconds` en la especificación del pod, el valor de la configuración no puede ser cero.
+ Si utiliza la versión `1.10` o anterior del complemento CNI de Amazon VPC o la versión `1.11` con `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, que es la configuración predeterminada, entonces los servicios de Kubernetes de tipo `NodePort` y `LoadBalancer` con destinos de instancia con un conjunto `externalTrafficPolicy` establecido en `Local` no son compatibles con los pods a los que asigna grupos de seguridad. Para obtener más información sobre el uso de un equilibrador de carga con destinos de instancia, consulte [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md).
+ Si utiliza la versión `1.10` o anterior del complemento CNI de Amazon VPC o la versión `1.11` con `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, que es la configuración predeterminada, el NAT de origen está deshabilitado para el tráfico saliente de pods con grupos de seguridad asignados a fin de que se apliquen las reglas de grupo de seguridad salientes. Para acceder a Internet, los pods con grupos de seguridad asignados deben lanzarse en nodos que se implementen en una subred privada configurada con una instancia o puerta de enlace de NAT. Los pods con grupos de seguridad asignados implementados en subredes públicas no pueden acceder a Internet.
Si utiliza la versión `1.11` o posterior del plugin con `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, el tráfico del pod destinado para salir de la VPC se traduce a la dirección IP de la interfaz de red principal de la instancia. Para este tráfico, se utilizan las reglas de los grupos de seguridad de la interfaz de red principal, en lugar de las reglas de los grupos de seguridad de los pods.
+ Para utilizar la política de red de Calico con pods que tienen grupos de seguridad asociados, debe utilizar la versión `1.11.0` o posterior del complemento CNI de Amazon VPC y establecerla en `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. De otro modo, el flujo de tráfico hacia y desde los pods con grupos de seguridad asociados no están sujetos al cumplimiento de la política de red de Calico y solo se limitan a la aplicación de grupos de seguridad de Amazon EC2. Para actualizar la versión del CNI de Amazon VPC, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md)
+ Los pods que funcionan en nodos de Amazon EC2 y que utilizan grupos de seguridad en clústeres y [NodeLocal DNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) solo se admiten con la versión `1.11.0` o posterior del complemento CNI de Amazon VPC y con `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`. Para actualizar la versión del complemento CNI de Amazon VPC, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md)
+ Los grupos de seguridad para pods pueden generar un aumento en la latencia de inicio de un pod en el caso de los pods con alta pérdida. Esto se debe a la limitación de velocidad en el controlador de recursos.
+ El alcance del grupo de seguridad de EC2 se encuentra en el pod. Para obtener más información, consulte [Grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
Si configuró `POD_SECURITY_GROUP_ENFORCING_MODE=standard` y `AWS_VPC_K8S_CNI_EXTERNALSNAT=false`, el tráfico destinado a puntos de conexión fuera de la VPC utiliza los grupos de seguridad del nodo, no los grupos de seguridad del pod.
# Configuración del complemento CNI de Amazon VPC para Kubernetes para grupos de seguridad de pods de Amazon EKS
Si utiliza pods con instancias de Amazon EC2, debe configurar el complemento CNI de Amazon VPC con los grupos de seguridad.
Si solo utiliza pods de Fargate y no tiene nodos de Amazon EC2 en su clúster, consulte [Uso de una política de grupo de seguridad para un pod de Amazon EKS](sg-pods-example-deployment.md).
1. Verifique su versión actual del complemento CNI de Amazon VPC para Kubernetes con el siguiente comando:
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Un ejemplo de salida sería el siguiente.
```
v1.7.6
```
Si su versión del complemento CNI de Amazon VPC para Kubernetes es anterior a la `1.7.7`, actualice el complemento a la versión `1.7.7` o posterior. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md)
1. Agregue la política de IAM administrada [AmazonEKSVPCResourceController](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonEKSVPCResourceController) al [rol de clúster](cluster-iam-role.md#create-service-role) asociado al clúster de Amazon EKS. La política permite que el rol administre las interfaces de red, sus direcciones IP privadas y su vinculación y desvinculación desde y hacia las instancias de red.
1. Recupere el nombre del rol de IAM de su clúster y guárdelo en una variable. Reemplace *my-cluster* por el nombre de su clúster.
```
cluster_role=$(aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2)
```
1. Asocie la política de al rol.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController --role-name $cluster_role
```
1. Habilitación del complemento CNI de Amazon VPC para administrar las interfaces de red de los pods al establecer la variable `ENABLE_POD_ENI` en `true` en el DaemonSet `aws-node`. Una vez que esta configuración se establece en `true`, el complemento crea un recurso personalizado `cninode` para cada nodo del clúster. El controlador de recursos de VPC crea y adjunta una interfaz de red especial denominada *interfaz de red troncal* con la descripción `aws-k8s-trunk-eni`.
```
kubectl set env daemonset aws-node -n kube-system ENABLE_POD_ENI=true
```
**nota**
La interfaz de red troncal se incluye en el número máximo de interfaces de red que admite el tipo de instancia. A fin de obtener una lista del número máximo de interfaces de red que admite cada tipo de instancia, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) en la *Guía del usuario de Amazon EC2*. Si su nodo ya cuenta con el número máximo de interfaces de red estándar adjuntas, el controlador de recursos de VPC reservará un espacio. Tendrá que reducir verticalmente los pods en ejecución lo suficiente para que el controlador desconecte y elimine una interfaz de red estándar, cree la interfaz de red troncal y la adjunte a la instancia.
1. Si desea ver cuál de sus nodos tiene un recurso personalizado `CNINode` establecido, utilice el siguiente comando. Si se devuelve `No resources found`, espere varios segundos e inténtelo de nuevo. El paso anterior requiere reiniciar los pods del complemento CNI de Amazon VPC para Kubernetes, lo cual tarda varios segundos.
```
kubectl get cninode -A
NAME FEATURES
ip-192-168-64-141.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
ip-192-168-7-203.us-west-2.compute.internal [{"name":"SecurityGroupsForPods"}]
```
Si utiliza versiones de CNI de VPC anteriores a `1.15`, se utilizaron etiquetas de nodo en lugar del recurso personalizado `CNINode`. Si desea ver cuál de sus nodos tienen la etiqueta de nodo `aws-k8s-trunk-eni` establecida en `true`, utilice el siguiente comando. Si se devuelve `No resources found`, espere varios segundos e inténtelo de nuevo. El paso anterior requiere reiniciar los pods del complemento CNI de Amazon VPC para Kubernetes, lo cual tarda varios segundos.
```
kubectl get nodes -o wide -l vpc.amazonaws.com/has-trunk-attached=true
```
Una vez que se crea la interfaz de red troncal, se pueden asignar direcciones IP secundarias a los pods desde las interfaces de red troncales o estándar. La interfaz troncal se elimina de forma automática si se elimina el nodo.
Cuando implementa un grupo de seguridad para un pod en un paso posterior, el controlador de recursos de VPC crea una interfaz de red especial denominada *interfaz de red de ramificación* con una descripción de `aws-k8s-branch-eni` y les asocia los grupos de seguridad. Se crean las interfaces de red de ramificación además de las interfaces de red estándar y troncal adjuntas al nodo.
Si utiliza sondeos de estado o preparación, también necesita desactivar el *demux temprano de TCP*, de modo que el `kubelet` pueda conectarse a los pods en las interfaces de red de ramificación a través de TCP. Para desactivar el *demux temprano de TCP*, ejecute el siguiente comando:
```
kubectl patch daemonset aws-node -n kube-system \
-p '{"spec": {"template": {"spec": {"initContainers": [{"env":[{"name":"DISABLE_TCP_EARLY_DEMUX","value":"true"}],"name":"aws-vpc-cni-init"}]}}}}'
```
**nota**
Si utiliza la versión `1.11.0` o posterior del complemento CNI de Amazon VPC para Kubernetes y lo establece en `POD_SECURITY_GROUP_ENFORCING_MODE`=`standard`, como se describe en el siguiente paso, no es necesario ejecutar el comando anterior.
1. Si su clúster usa `NodeLocal DNSCache` o desea usar la política de red de Calico con los pods que tienen sus propios grupos de seguridad, o si tiene servicios de Kubernetes de tipo `NodePort` y `LoadBalancer` mediante los destinos de instancia con una `externalTrafficPolicy` establecida en `Local` para pods a los que desea asignar grupos de seguridad, debe usar la versión `1.11.0` o posterior del complemento CNI de Amazon VPC para Kubernetes y habilitar la siguiente configuración:
```
kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
```
IMPORTANTE: **Las reglas del grupo de seguridad del pod no se aplican al tráfico entre pods o entre pods y servicios, como `kubelet` o `nodeLocalDNS`, que se encuentran en el mismo nodo. Los pods que utilizan diferentes grupos de seguridad en el mismo nodo no pueden comunicarse porque están configurados en diferentes subredes y el enrutamiento está deshabilitado entre estas subredes.** El tráfico saliente de los pods a direcciones fuera de la VPC es la dirección de red traducida a la dirección IP de la interfaz de red principal de la instancia (a menos que también haya configurado `AWS_VPC_K8S_CNI_EXTERNALSNAT=true`). Para este tráfico, se utilizan las reglas de los grupos de seguridad de la interfaz de red principal, en lugar de las reglas de los grupos de seguridad de los pods. \$1\$1 Para que esta configuración se aplique a los pods existentes, debe reiniciar los pods o los nodos en que se están ejecutando los pods.
1. Para ver cómo utilizar una política de grupo de seguridad para su pods, consulte [Uso de una política de grupo de seguridad para un pod de Amazon EKS](sg-pods-example-deployment.md).
# Uso de una política de grupo de seguridad para un pod de Amazon EKS
Para usar grupos de seguridad con pods, debe tener un grupo de seguridad existente. En los siguientes pasos se muestra cómo utilizar la política de grupo de seguridad para un pod. A menos que se indique lo contrario, complete todos los pasos del mismo terminal ya que en los siguientes pasos se utilizan variables que no persisten en los terminales.
Si tiene un pod con instancias de Amazon EC2, debe configurar el complemento antes de utilizar este procedimiento. Para obtener más información, consulte [Configuración del complemento CNI de Amazon VPC para Kubernetes para grupos de seguridad de pods de Amazon EKS](security-groups-pods-deployment.md).
1. Cree un espacio de nombres de Kubernetes en el que implementar los recursos de . Puede reemplazar *my-namespace* por el nombre del espacio de nombres que desee usar.
```
kubectl create namespace my-namespace
```
1. Implemente una `SecurityGroupPolicy` de Amazon EKS a su clúster.
1. Copie los siguientes contenidos en su dispositivo. Puede reemplazar *podSelector* por `serviceAccountSelector` si prefiere seleccionar pods en función de las etiquetas de cuenta de servicio. Debe especificar un selector o el otro. Un `podSelector` vacío (ejemplo: `podSelector: {}`) selecciona todos los pods del espacio de nombres. Puede cambiar *my-role* por el nombre de su rol. Un `serviceAccountSelector` vacío selecciona todas las cuentas de servicio del espacio de nombres. Puede reemplazar *my-security-group-policy* por un nombre para su `SecurityGroupPolicy` y *my-namespace* por el espacio de nombres en el que desea crear la `SecurityGroupPolicy`.
Debe reemplazar *my\$1pod\$1security\$1group\$1id* por el ID de un grupo de seguridad existente. Si no dispone de un grupo de seguridad existente, debe crear uno. Para obtener más información, consulte [Grupos de seguridad de Amazon EC2 para instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) en la [Guía del usuario de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/). Puede especificar de uno a cinco ID de grupo de seguridad. Si especifica más de un ID, la combinación de todas las reglas de todos los grupos de seguridad será efectiva para los pods seleccionados.
```
cat >my-security-group-policy.yaml <sample-application.yaml <
my-deployment-5df6f7687b-j9fl4 1/1 Running 0 7m51s 192.168.70.145 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-rjxcz 1/1 Running 0 7m51s 192.168.73.207 ip-192-168-92-33.region-code.compute.internal
my-deployment-5df6f7687b-zmb42 1/1 Running 0 7m51s 192.168.63.27 ip-192-168-33-28.region-code.compute.internal
```
**nota**
Pruebe estos consejos si hay pods atascados.
Si hay pods atascados en estado `Waiting`, ejecute `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace `. Si ve `Insufficient permissions: Unable to create Elastic Network Interface.`, confirme que agregó la política de IAM al rol de clúster de IAM en un paso anterior.
Si algún pod se encuentra atascado en estado `Pending`, confirme que el tipo de instancia del nodo aparece en [limits.go](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/pkg/aws/vpc/limits.go) y que el producto del número máximo de interfaces de red de ramificación admitidas por el tipo de instancia multiplicado por el número de nodos del grupo de nodos aún no se ha alcanzado. Por ejemplo, una instancia `m5.large` admite nueve interfaces de red de ramificación. Si el grupo de nodos tiene cinco nodos, se puede crear un máximo de 45 interfaces de red de ramificación para el grupo de nodos. El pod 46 que intente implementar se establecerá en el estado `Pending` hasta que se elimine otro pod que tenga grupos de seguridad asociados.
Si ejecuta `kubectl describe pod my-deployment-xxxxxxxxxx-xxxxx -n my-namespace ` y ve un mensaje similar al siguiente mensaje, puede ignorarlo de forma segura. Este mensaje puede aparecer cuando el complemento CNI de Amazon VPC para Kubernetes intenta configurar las redes de host y falla mientras se crea la interfaz de red. El complemento registra este evento hasta que se crea la interfaz de red.
```
Failed to create Pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "e24268322e55c8185721f52df6493684f6c2c3bf4fd59c9c121fd4cdc894579f" network for Pod "my-deployment-5df6f7687b-4fbjm": networkPlugin
cni failed to set up Pod "my-deployment-5df6f7687b-4fbjm-c89wx_my-namespace" network: add cmd: failed to assign an IP address to container
```
No puede exceder el número máximo de pods que se pueden ejecutar en el tipo de instancia. Para obtener una lista del número máximo de pods que puede ejecutar en cada tipo de instancia, consulte [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) en GitHub. Cuando elimina un pod que tiene grupos de seguridad asociados o elimina el nodo en el que se ejecuta el pod, el controlador de recursos de VPC elimina la interfaz de red de ramificación. Si elimina un clúster con pods mediante pods para grupos de seguridad, el controlador no elimina las interfaces de red de ramificación, por lo que deberá eliminarlas por su cuenta. A fin de obtener más información sobre las interfaces de red, consulte [Eliminar una interfaz de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#delete_eni) en la Guía del usuario de Amazon EC2.
1. En un terminal separado, se inserta en uno de los pods. En el resto de este tema, se hace referencia a este terminal como `TerminalB`. Reemplace *5df6f7687b-4fbjm* por el ID de uno de los pods devueltos en la salida del paso anterior.
```
kubectl exec -it -n my-namespace my-deployment-5df6f7687b-4fbjm -- /bin/bash
```
1. Desde el intérprete de comandos de `TerminalB`, confirme que la aplicación de ejemplo funciona.
```
curl my-app
```
Un ejemplo de salida sería el siguiente.
```
Welcome to nginx!
[...]
```
Recibió el resultado porque todos los pods que se ejecutan en la aplicación están asociados al grupo de seguridad que creó. Ese grupo contiene una regla que permite todo el tráfico entre todos los pods al que está asociado el grupo de seguridad. Se permite el tráfico DNS saliente de ese grupo de seguridad al grupo de seguridad del clúster, lo que está asociado a los nodos. Los nodos ejecutan los pods de CoreDNS, en los que sus pods hicieron una búsqueda de nombre.
1. Desde `TerminalA`, elimine las reglas del grupo de seguridad que permita la comunicación DNS al grupo de seguridad del clúster del grupo de seguridad. Si no agregó las reglas DNS al grupo de seguridad del clúster en un paso anterior, sustituya *\$1my\$1cluster\$1security\$1group\$1id* con el ID del grupo de seguridad en el que creó las reglas.
```
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_tcp_rule_id
aws ec2 revoke-security-group-ingress --group-id $my_cluster_security_group_id --security-group-rule-ids $my_udp_rule_id
```
1. Desde `TerminalB`, intente acceder de nuevo a la aplicación.
```
curl my-app
```
Un ejemplo de salida sería el siguiente.
```
curl: (6) Could not resolve host: my-app
```
El intento falla porque el pod ya no puede acceder a los pods de CoreDNS, que tienen asociado el grupo de seguridad del clúster. El grupo de seguridad del clúster ya no tiene las reglas del grupo de seguridad que permiten la comunicación de DNS desde el grupo de seguridad asociado a su pod.
Si intenta acceder a la aplicación con las direcciones IP devueltas para uno de los pods en un paso anterior, sigue recibiendo una respuesta dado que todos los puertos están permitidos entre pods que tienen el grupo de seguridad asociado a ellos y no es necesaria una búsqueda de nombres.
1. Una vez que haya terminado de experimentar, puede eliminar la política de grupo de seguridad, la aplicación y el grupo de seguridad de ejemplo que creó. Ejecute los siguientes comandos desde la `TerminalA`.
```
kubectl delete namespace my-namespace
aws ec2 revoke-security-group-ingress --group-id $my_pod_security_group_id --security-group-rule-ids $my_inbound_self_rule_id
wait
sleep 45s
aws ec2 delete-security-group --group-id $my_pod_security_group_id
```
# Conexión de múltiples interfaces de red a pods
De forma predeterminada, el complemento de la CNI de Amazon VPC asigna una dirección IP a cada pod. Esta dirección IP está conectada a una *interfaz de red elástica* que gestiona todo el tráfico entrante y saliente del pod. Para aumentar el ancho de banda y el rendimiento de la tasa de paquetes por segundo, puede utilizar la *característica de NIC múltiple* de la CNI de la VPC para configurar un pod con varios hosts. Un pod con múltiples hosts es un único pod de Kubernetes que utiliza varias interfaces de red (y varias direcciones IP). Al ejecutar un pod con varios hosts, puede distribuir el tráfico de sus aplicaciones entre varias interfaces de red mediante conexiones simultáneas. Esto resulta especialmente útil para los casos de uso de inteligencia artificial (IA), machine learning (ML) y computación de alto rendimiento (HPC).
En el siguiente diagrama, se muestra un pod con varios hosts que se ejecuta en un nodo de trabajo con varias tarjetas de interfaz de red (NIC) en uso.
![\[Un pod con varios hosts con dos interfaces de red conectadas: una interfaz de red con ENA y otra interfaz de red con ENA y EFA\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/multi-homed-pod.png)
## Introducción
En Amazon EC2, una *interfaz de red elástica* es un componente de red lógico en una VPC que representa una tarjeta de red virtual. Para muchos tipos de instancias de EC2, las interfaces de red comparten una única tarjeta de interfaz de red (NIC) en el hardware. Esta NIC única tiene un ancho de banda máximo y una tasa máxima de paquetes por segundo.
Si la característica de NIC múltiple está habilitada, la CNI de la VPC no asigna direcciones IP en bloque, lo que hace de forma predeterminada. En su lugar, la CNI de la VPC asigna una dirección IP a una interfaz de red en cada tarjeta de red bajo demanda cuando se inicia un nuevo pod. Este comportamiento reduce la tasa de agotamiento de las direcciones IP, que aumenta con el uso de pods con varios hosts. Debido a que la CNI de la VPC asigna direcciones IP bajo demanda, los pods podrían tardar más en iniciarse en las instancias con la característica de NIC múltiple habilitada.
## Consideraciones
+ Asegúrese de que su clúster de Kubernetes esté ejecutando la versión `1.20.0`, o posterior, de la CNI de la VPC. La característica de NIC múltiple solo está disponible en la versión `1.20.0` de la CNI de la VPC o posterior.
+ Habilite la variable de entorno `ENABLE_MULTI_NIC` en el complemento de la CNI de la VPC. Puede ejecutar el siguiente comando para establecer la variable e iniciar la implementación del DaemonSet.
+ `kubectl set env daemonset aws-node -n kube-system ENABLE_MULTI_NIC=true`
+ Asegúrese de crear nodos de trabajo que tengan varias tarjetas de interfaz de red (NIC). Para obtener una lista de las instancias de EC2 que tienen varias tarjetas de interfaz de red, consulte [Tarjetas de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) en la **Guía del usuario de Amazon EC2**.
+ Si la característica de NIC múltiple está habilitada, la CNI de la VPC no asigna direcciones IP en bloque, lo que hace de forma predeterminada. Debido a que la CNI de la VPC asigna direcciones IP bajo demanda, los pods podrían tardar más en iniciarse en las instancias con la característica de NIC múltiple habilitada. Para obtener más información, consulte la sección anterior [Introducción](#pod-multi-nic-background).
+ Con la característica de NIC múltiple habilitada, los pods no tienen varias interfaces de red de forma predeterminada. Debe configurar cada carga de trabajo para usar varias NIC. Agregue la anotación `k8s.amazonaws.com/nicConfig: multi-nic-attachment` a las cargas de trabajo que deben tener varias interfaces de red.
### `IPv6`Consideraciones de
+ **Política de IAM personalizada**: en el caso de los clústeres de `IPv6`, cree y utilice la siguiente política de IAM personalizada para la CNI de la VPC. Esta política es específica de NIC múltiple. Para obtener más información general sobre el uso de la CNI de la VPC con clústeres de `IPv6`, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonEKSCNIPolicyIPv6MultiNIC",
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DescribeInstances",
"ec2:AssignIpv6Addresses",
"ec2:DetachNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeTags",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstanceTypes",
"ec2:UnassignIpv6Addresses",
"ec2:AttachNetworkInterface",
"ec2:DescribeSubnets"
],
"Resource": "*"
},
{
"Sid": "AmazonEKSCNIPolicyENITagIPv6MultiNIC",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:network-interface/*"
}
]
}
```
+ **Mecanismo de transición de `IPv6` no disponible**: si utiliza la característica de NIC múltiple, la CNI de la VPC no asigna una dirección `IPv4` a los pods de un clúster de `IPv6`. De lo contrario, la CNI de la VPC asigna una dirección `IPv4` local de host a cada pod para que puedan comunicarse con recursos de `IPv4` externos en otra Amazon VPC o en Internet.
## Uso
Una vez que la característica de NIC múltiple esté habilitada en la CNI de la VPC y se hayan reiniciado los pods de `aws-node`, puede configurar cada carga de trabajo para que tenga varios hosts. El siguiente es un ejemplo de una configuración de YAML con la anotación requerida:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders-deployment
namespace: ecommerce
labels:
app: orders
spec:
replicas: 3
selector:
matchLabels:
app: orders
template:
metadata:
annotations:
k8s.amazonaws.com/nicConfig: multi-nic-attachment
labels:
app: orders
spec:
...
```
## Preguntas frecuentes
### **1. ¿Qué es una tarjeta de interfaz de red (NIC)?**
Una tarjeta de interfaz de red (NIC), también denominada simplemente tarjeta de red, es un dispositivo físico que permite la conectividad de red para el hardware de computación en la nube subyacente. En los servidores de EC2 modernos, se refiere a la tarjeta de red Nitro. Una interfaz de red elástica (ENI) es una representación virtual de esta tarjeta de red subyacente.
Algunos tipos de instancias de EC2 tienen varias NIC para mayor ancho de banda y rendimiento de tasa de paquetes. Para tales instancias, puede asignar ENI secundarias a las tarjetas de red adicionales. Por ejemplo, la ENI n.° 1 puede funcionar como interfaz para la NIC conectada al índice de tarjeta de red 0, mientras que la ENI n.° 2 puede funcionar como interfaz para la NIC conectada a un índice de tarjeta de red separado.
### **2. ¿Qué es un pod con múltiples hosts?**
Un pod con múltiples hosts es un único pod de Kubernetes que utiliza varias interfaces de red (y, en consecuencia, varias direcciones IP). Cada interfaz de red del pod está asociada a una [interfaz de red elástica (ENI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)), y estas ENI son representaciones lógicas de NIC independientes en el nodo de trabajo subyacente. Con varias interfaces de red, un pod con varios hosts tiene una capacidad de transferencia de datos adicional, lo que también aumenta su tasa de transferencia de datos.
**importante**
La CNI de la VPC solo puede configurar pods con varios hosts en tipos de instancias que tengan varias NIC.
### **3. Por qué debo utilizar esta característica?**
Si necesita escalar el rendimiento de la red en sus cargas de trabajo basadas en Kubernetes, puede utilizar la característica de NIC múltiple para ejecutar pods con varios hosts que interactúen con todas las NIC subyacentes que tengan un dispositivo ENA conectado. El uso de tarjetas de red adicionales aumenta la capacidad de ancho de banda y el rendimiento de la velocidad de paquetes de sus aplicaciones al distribuir el tráfico de las aplicaciones entre varias conexiones simultáneas. Esto resulta especialmente útil para los casos de uso de inteligencia artificial (IA), machine learning (ML) y computación de alto rendimiento (HPC).
### **4. ¿Cómo utilizo esta característica?**
1. En primer lugar, debe asegurarse de que su clúster de Kubernetes utilice la versión 1.20 o posterior de la CNI de la VPC. Para conocer los pasos para actualizar la CNI de la VPC como un complemento de EKS, consulte [Cómo actualizar la CNI de Amazon VPC (complemento de Amazon EKS)](vpc-add-on-update.md).
1. A continuación, debe habilitar la compatibilidad con varias NIC en la CNI de la VPC mediante la variable de entorno `ENABLE_MULTI_NIC`.
1. A continuación, debe asegurarse de crear y unir nodos que tengan varias tarjetas de red. Para obtener una lista de los tipos de instancias de EC2 que tienen varias tarjetas de red, consulte [Tarjetas de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#network-cards) en la *Guía del usuario de Amazon EC2*.
1. Por último, debe configurar cada carga de trabajo para que utilice varias interfaces de red (pods con varios hosts) o una única interfaz de red.
### **5. ¿Cómo configuro mis cargas de trabajo para usar varias NIC en un nodo de trabajo compatible?**
Para usar pods con varios hosts, debe agregar la siguiente anotación: `k8s.amazonaws.com/nicConfig: multi-nic-attachment`. Esto conectará una ENI de cada NIC de la instancia subyacente al pod (mapeo de uno a varios entre un pod y las NIC).
Si falta esta anotación, la CNI de la VPC asume que el pod solo requiere una interfaz de red y le asigna una IP desde una ENI en cualquier NIC disponible.
### **6. ¿Qué adaptadores de interfaz de red son compatibles con esta característica?**
Puede utilizar cualquier adaptador de interfaz de red si tiene al menos un ENA conectado a la tarjeta de red subyacente para el tráfico IP. Para obtener más información sobre los ENA, consulte [Elastic Network Adapter (ENA)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html) en la *Guía del usuario de Amazon EC2*.
Configuraciones de dispositivos de red compatibles:
+ Las interfaces **ENA** proporcionan todas las características de enrutamiento y redes IP tradicionales que se requieren para admitir las redes IP de una VPC. Para obtener más información, consulte [Habilitar redes mejoradas con ENA en las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html).
+ Las interfaces **EFA** **(EFA** **con ENA)** proporcionan tanto el dispositivo de ENA para redes IP como el dispositivo EFA para comunicaciones de baja latencia y alto rendimiento.
**importante**
Si una tarjeta de red solo tiene conectado un adaptador **exclusivo de EFA**, la CNI de la VPC lo omitirá al aprovisionar la conectividad de red para un pod con varios hosts. Sin embargo, si combina un adaptador **exclusivo de EFA** con un adaptador para **ENA** en una tarjeta de red, la CNI de la VPC también administrará las ENI de este dispositivo. Para utilizar interfaces exclusivas de EFA con clústeres de EKS, consulte [Impartición de formación en machine learning en Amazon EKS con Elastic Fabric Adapter](node-efa.md).
### **7. ¿Puedo ver si un nodo de mi clúster es compatible con ENA?**
Sí, puede usar la CLI de AWS o la API de EC2 para recuperar información de red sobre una instancia de EC2 de su clúster. Esto proporciona detalles sobre si la instancia es compatible con ENA o no. En el siguiente comando, sustituya `` por el ID de la instancia de EC2 de un nodo.
AWSEjemplo de la CLI de :
```
aws ec2 describe-instances --instance-ids --query "Reservations[].Instances[].EnaSupport"
```
Ejemplo de código de salida:
```
[ true ]
```
### **8. ¿Puedo ver las distintas direcciones IP asociadas a un pod?**
No, no es fácil. Sin embargo, puede utilizar `nsenter` desde el nodo para ejecutar herramientas de red comunes, como `ip route show`, y ver las direcciones IP e interfaces adicionales.
### **9. ¿Puedo controlar el número de interfaces de red de mis pods?**
No. Cuando la carga de trabajo está configurada para usar varias NIC en una instancia compatible, un único pod recibe automáticamente una dirección IP de cada tarjeta de red de la instancia. Como alternativa, los pods con un solo host tendrán una interfaz de red conectada a una NIC de la instancia.
**importante**
La CNI de la VPC omite las tarjetas de red que *solo* tienen conectado un dispositivo **exclusivo de EFA**.
### **10. ¿Puedo configurar mis pods para que usen una NIC específica?**
No, no se puede. Si un pod tiene la anotación correspondiente, la CNI de la VPC lo configura automáticamente para usar todas las NIC con un adaptador de ENA en el nodo de trabajo.
### **11. ¿Esta característica funciona con las demás características de red de la CNI de la VPC?**
Sí, la característica de NIC múltiple de la CNI de la VPC funciona tanto con *redes personalizadas* como con *detección de subredes mejorada*. Sin embargo, los pods con varios hosts no utilizan las subredes ni los grupos de seguridad personalizados. En su lugar, la CNI de la VPC asigna direcciones IP e interfaces de red a los pods de múltiples hosts con la misma configuración de subred y grupo de seguridad que el nodo. Para obtener más información sobre las redes personalizadas, consulte [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md).
La característica de NIC múltiple de la CNI de la VPC no funciona con los *grupos de seguridad para los pods* ni se puede combinar con ellos.
### **12. ¿Puedo usar políticas de red con esta característica?**
Sí, puede usar las políticas de red de Kubernetes con varias NIC. Las políticas de red de Kubernetes restringen el tráfico de red que entra y sale de sus pods. Para obtener más información sobre cómo aplicar políticas de red con la CNI de la VPC, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md).
### **13. ¿Está habilitada la compatibilidad con múltiples NIC en el modo automático de EKS?**
La configuración de múltiples NIC no es compatible con los clústeres del modo automático de EKS.