Cómo usar CIDR secundario en EKS

En este Teratip, profundizaremos en el ámbito de los bloques CIDR secundarios en AWS EKS y exploraremos cómo pueden empoderarlo para mejorar la flexibilidad y escalabilidad de su clúster. Descubriremos los beneficios de aprovechar los bloques CIDR secundarios y lo guiaremos a través de su configuración.

Introducción

A medida que expandes tus aplicaciones y servicios, quizás te enfrentes a situaciones en las que el bloque CIDR primario asignado a su clúster EKS se vuelva insuficiente. Quizás esté introduciendo microservicios adicionales, implementando múltiples conexiones de emparejamiento de VPC o integrándose con sistemas heredados que tienen sus propios requisitos de direcciones IP. Estas situaciones requieren una solución que te permita asignar más direcciones IP a tu clúster sin sacrificar la estabilidad o el rendimiento de la red.

Los bloques CIDR secundarios ofrecen una solución elegante al permitir adjuntar rangos de direcciones IP adicionales a tu VPC existente, ampliando así el espacio de direcciones disponible para tu clúster EKS. Vamos a revisar el proceso paso a paso para agregar bloques CIDR secundarios a tu clúster AWS EKS.

Crea el cluster de EKS

Para esta demostración, creé un clúster EKS simple con solo un nodo y desplegué el famoso juego 2048, que se puede acceder a través de un Balanceador de Carga de Aplicaciones en Internet.

Así es como se ve el clúster EKS y la carga de trabajo:

Y esta es la VPC donde se encuentra el clúster:

Como puedes ver, esta VPC tiene asignado el bloque CIDR IPv4 10.0.0.0/16. Teniendo en cuenta esto, todos los pods en el clúster recibirán una dirección IP dentro de este rango:

A continuación, configuraremos este mismo clúster para usar un bloque CIDR secundario en la misma VPC. De esta manera, casi todos los pods recibirán direcciones IP del nuevo CIDR.

Step by step process

Paso # 1: Crea el CIDR secundario dentro de la VPC

RESTRICCIÓN: EKS soporta bloques CIDR IPv4 adicionales en el rango 100.64.0.0/16.

Es posible agregar un segundo CIDR a la VPC actual y, por supuesto, crear subredes dentro de esta VPC utilizando el nuevo rango. Lo hice a través de Terraform, pero esto también se puede hacer usando la Consola de AWS.

El código que usé para crear la VPC es el siguiente:

module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "3.19.0" name = "teratip-eks-2cidr-vpc" cidr = "10.0.0.0/16" secondary_cidr_blocks = ["100.64.0.0/16"] azs = slice(data.aws_availability_zones.available.names, 0, 2) private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "100.64.1.0/24", "100.64.2.0/24"] public_subnets = ["10.0.4.0/24", "10.0.5.0/24"] enable_nat_gateway = true single_nat_gateway = true enable_dns_hostnames = true public_subnet_tags = { "kubernetes.io/cluster/${local.cluster_name}" = "shared" "kubernetes.io/role/elb" = 1 } private_subnet_tags = { "kubernetes.io/cluster/${local.cluster_name}" = "shared" "kubernetes.io/role/internal-elb" = 1 } }

Dale un vistazo a la línea secondary_cidr_blocks = ["100.64.0.0/16"] y a las subredes privadas (las dos últimas) que se crearon dentro de este CIDR: private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "100.64.1.0/24", "100.64.2.0/24"].

La VPC obtenida se ve así:

Paso # 2: Configura el CNI

DEFINICIÓN: CNI (Interfaz de Red de Contenedores), se ocupa de la conectividad de red de los contenedores y de eliminar los recursos asignados cuando se elimina el contenedor.

Para utilizar un CIDR secundario en el clúster, es necesario configurar algunas variables de entorno en la configuración del daemonset CNI, ejecutando los siguientes comandos:

1. Para activar la configuración de red personalizada para el plugin CNI, ejecute el siguiente comando:

kubectl set env ds aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true

2. Para agregar la etiqueta ENIConfig para identificar sus nodos trabajadores, ejecuta el siguiente comando:

kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

3. Habilita el parámetro para asignar prefijos a las interfaces de red para el DaemonSet de CNI de Amazon VPC.

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true

Termine los nodos trabajadores para que el Autoescalado inicie nuevos nodos que vengan configurados con la configuración de red personalizada.

Paso # 3: Crear los recursos ENIConfig para las nuevas subredes

Como siguiente paso, agregaremos recursos personalizados a la definición de recurso personalizado (CRD) ENIConfig. En este caso, almacenaremos información de configuración de Subred y Grupo de Seguridad de VPC en estos CRD para que los nodos trabajadores puedan acceder a ellos para configurar el plugin CNI de VPC.

Cree recursos personalizados para cada subred cambiando los ID de Subred y Grupo de Seguridad. Dado que creamos dos subredes secundarias, debemos crear tres recursos personalizados.

---

apiVersion: crd.k8s.amazonaws.com/v1alpha1

kind: ENIConfig

metadata:

name: us-east-2a

spec:

securityGroups:

-sg-087d0a0ece9800b00

subnet: subnet-0fabe93c6f43f492b

---

apiVersion: crd.k8s.amazonaws.com/v1alpha1

kind: ENIConfig

metadata:

name: us-east-2b

spec:

securityGroups:

-sg-087d0a0ece9800b00

subnet: subnet-0484194486fad2ce3

Nota: El nombre de ENIConfig debe coincidir con la Zona de Disponibilidad de sus subredes.

Puede obtener el Grupo de Seguridad del Clúster incluido en los ENIConfigs en la Consola de EKS o ejecutando el siguiente comando:

aws eks describe-cluster --name $cluster_name --querycluster.resourcesVpcConfig.clusterSecurityGroupId --output text

Una vez que haya creado el YAML de ENIConfigs, aplíquelo:

kubectl apply -f <eniconfigs.yaml>

Revisa la nueva configuración de red

Finalmente, todos los pods en ejecución en sus nodos trabajadores deberían tener direcciones IP dentro del CIDR secundario.

Como se puede ver en la captura de pantalla a continuación, el servicio sigue funcionando como debería:

Además, observe que el nodo de trabajo EC2 ahora tiene un ENI (Interfaz de Red Elástica) con una dirección IP dentro del CIDR secundario:

Configurar max-pods por nodo

Activar una red personalizada elimina una interfaz de red disponible de cada nodo que la utiliza y la interfaz de red principal del nodo no se utiliza para la colocación de pods cuando se habilita una red personalizada. En este caso, debe actualizar max-pods:

Para realizar este paso, utilicé Terraform para actualizar el grupo de nodos aumentando el parámetro max-pods:

A continuación, se muestra el IaC para el clúster EKS:

module "eks" {

source = "terraform-aws-modules/eks/aws"

version = "19.5.1"

cluster_name = local.cluster_name

cluster_version = "1.24"

vpc_id = module.vpc.vpc_id

subnet_ids = [module.vpc.private_subnets[0], module.vpc.private_subnets[1]]

cluster_endpoint_public_access = true

eks_managed_node_group_defaults = {

ami_type = "AL2_x86_64"

}

eks_managed_node_groups = {

one = {

name = "node-group-1"

instance_types = ["t3.small"]

min_size = 1

max_size = 1

desired_size = 1

bootstrap_extra_args = "--container-runtime containerd --kubelet-extra-args '--max-pods=110'"

pre_bootstrap_user_data = <<-EOT

export CONTAINER_RUNTIME="containerd"

export USE_MAX_PODS=false

EOT

}

}

}

En el ejemplo, configuré max-pods = 110, que es demasiado para este tipo de instancia EC2, pero es un límite estricto. Este nodo asignará tantos pods como sus recursos lo permitan.

Si está interesado en saber más sobre cómo aumentar la cantidad de direcciones IP disponibles para sus nodos, aquí hay una guía interesante de AWS que puede leer.

Por si acaso…

Si por alguna razón algo sale mal y sus pods no están obteniendo direcciones IP, puede revertir fácilmente sus cambios ejecutando el siguiente comando y lanzando nuevos nodos:

kubectl set env ds aws-node-n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=false

Después de ejecutar el comando, todo el clúster volverá a usar el CIDR primario.

Conclusión

Al seguir meticulosamente las instrucciones paso a paso proporcionadas en esta guía, ha adquirido el conocimiento para configurar y supervisar de manera efectiva los bloques CIDR secundarios, ajustando su red para armonizar precisamente con las necesidades de sus aplicaciones. Esta nueva adaptabilidad no solo simplifica la asignación de recursos, sino que también le otorga la capacidad de ajustar sin problemas su infraestructura en respuesta a requisitos en evolución.

Ignacio Rubio

Cloud Engineer

Teracloud