{"id":25532,"date":"2022-06-23T11:21:29","date_gmt":"2022-06-23T09:21:29","guid":{"rendered":"https:\/\/www.makingscience.com\/?p=25532"},"modified":"2022-06-23T11:21:29","modified_gmt":"2022-06-23T09:21:29","slug":"por-que-eks-agota-todas-las-ips-de-mi-subred","status":"publish","type":"post","link":"https:\/\/www.makingscience.com\/es\/blog\/por-que-eks-agota-todas-las-ips-de-mi-subred\/","title":{"rendered":"\u00bfPor qu\u00e9 EKS agota todas las IPs de mi subred?"},"content":{"rendered":"

\u00bfTienes tu aplicaci\u00f3n desplegada sobre EKS y parece que te has quedado corto de IPs al asignar los CIDRs en las subredes?<\/strong> Vamos a analizar qu\u00e9 es lo que sucede debajo del servicio gestionado de Kubernetes de AWS.<\/strong><\/span><\/p>\n

Partiendo de una arquitectura de referencia como la siguiente:<\/span><\/p>\n

\"\"<\/span><\/p>\n

Imagen: eks_blog-base.png<\/span><\/p>\n

T\u00edpica arquitectura de referencia \u201ctier 3 webapp\u201d con su balanceador en subred p\u00fablica, control plane de EKS, nodos gestionados por AWS, as\u00ed como RDS y\/o Elasticache todo ello en la subred privada.<\/span><\/p>\n

Por <\/span>dise\u00f1o<\/span><\/a> de AWS y su integraci\u00f3n con el <\/span>CNI<\/span><\/a>, los nodos y los pods de EKS usan IPs de las subredes donde se hayan desplegado, en este caso, las subredes privadas en color azul.\u00a0<\/span><\/p>\n

Hace unos a\u00f1os, cuando se montaban los cl\u00fasters <\/span>the-hard-way<\/span><\/a>, hab\u00eda que definir unas subredes \u201cvirtuales\u201d que iban a usar el apiserver, los pods y los services.\u00a0<\/span><\/p>\n

A d\u00eda de hoy, usando los servicios gestionados de nuestro proveedor cloud, en este caso AWS, \u00e9l se encarga de esta labor y es totalmente transparente para nosotros una vez le facilitamos las subredes para desplegar nuestro cl\u00faster de EKS.<\/span><\/p>\n

 <\/p>\n

Exponiendo el problema<\/b><\/h3>\n

En un primer vistazo, nuestro diagrama tiene buena pinta y la provisi\u00f3n de IPs para nuestra peque\u00f1a aplicaci\u00f3n es m\u00e1s que suficiente, al menos a corto plazo. Como hemos hecho bien los deberes, hemos dado un CIDR lo suficientemente grande, en nuestro caso un par de \/22 lo que son 2048 IPS para nuestra aplicaci\u00f3n que tiene unos pocos de pods y varios nodos para proporcionarnos HA entre zonas.<\/span><\/p>\n

\"\"<\/span><\/p>\n

Imagen: red_eks1.png<\/span><\/p>\n

\u00bfQu\u00e9 sucede cuando tengo un pico de carga?<\/strong> Al haber tenido esto en cuenta, hemos definido un HPA para que nuestros pods escalen y en caso de que sea necesario, el cluster-autoescaler levante m\u00e1s nodos para seguir dando servicio a este aumento puntual de peticiones.<\/span><\/p>\n

Despu\u00e9s de este pico de carga, nos damos cuenta que volvemos a tener niveles normales de pods y nodos, pero observamos que nos hemos quedado sin IPs disponibles en las subredes privadas.<\/span><\/p>\n

\"\"<\/span><\/p>\n

Imagen: red_eks2.png<\/span><\/p>\n

\u00bfY ahora qu\u00e9 hacemos? \u00bfC\u00f3mo recuperamos estas IPs?<\/strong><\/p>\n

 <\/p>\n

Investigaci\u00f3n<\/b><\/h3>\n

Para responder a estas preguntas, debemos entender c\u00f3mo funciona \u201cpor debajo\u201d la provisi\u00f3n de IPs en los ENI de cada nodo y como funciona el AWS VPC CNI.\u00a0<\/span><\/p>\n

1.Provisi\u00f3n de ENIs<\/strong><\/p>\n

Seg\u00fan la <\/span>documentaci\u00f3n<\/span><\/a>, AWS VPC CNI es responsable de asignar direcciones IP de la VPC a los nodos de Kubernetes y realizar la configuraci\u00f3n de la red necesaria para los pods en cada nodo.<\/span><\/p>\n

Si nos fijamos en esta parte: \u201cDaemon L-IPAM: responsable de crear interfaces de red y adjuntar las interfaces de red a las instancias de Amazon EC2, asignar direcciones IP secundarias a las interfaces de red y mantener un grupo activo de direcciones IP en cada nodo para asignarlas a los pods de Kubernetes cuando se programan. Cuando el n\u00famero de pods que se ejecutan en el nodo supera el n\u00famero de direcciones que se pueden asignar a una interfaz de red \u00fanica, el complemento comienza a asignar una interfaz de red nueva, siempre y cuando el n\u00famero m\u00e1ximo de interfaces de red para la instancia no se encuentre conectado.\u201d conseguiremos tener muchas cosas claras.<\/span><\/p>\n

Cada nodo puede ejecutar un <\/span>n\u00famero m\u00e1ximo de pods<\/span><\/a> y esto va ligado al n\u00famero m\u00e1ximo de <\/span>ENIs<\/span><\/a> que puede tener.<\/span><\/p>\n

Si usamos como ejemplo un tipo de instancia m5.xlarge, vemos lo siguiente:<\/span><\/p>\n

\"\"<\/span><\/p>\n

Imagen: eks_m5.png<\/span><\/p>\n

 <\/p>\n

2.Configuraci\u00f3n de AWS VPC CNI<\/strong><\/p>\n

Tratemos de entender ahora c\u00f3mo podemos <\/span>configurar<\/span><\/a> este componente de nuestro cl\u00faster.<\/span><\/p>\n

Este componente se puede configurar para elegir c\u00f3mo se mantienen activas las direcciones IP. El valor predeterminado es WARM_ENI_TARGET=1. Esto significa que EKS intentar\u00e1 mantener un ENI completo disponible en el nodo. Entonces, si un nodo tiene un ENI adjunto y se usa alguna de esas direcciones IP, se adjuntar\u00e1 otro ENI para que se mantenga esta configuraci\u00f3n predeterminada.<\/span><\/p>\n

Esto quiere decir, que cada nodo puede tener 4 ENIs y cada ENI 15 IPs, si hacemos una cuenta r\u00e1pida, vemos que cada nodo puede reservar hasta 60 IPs, por lo que 60 IPs reservadas m\u00e1s 1 IP del propio nodo, estamos consumiendo hasta 61 IPs por nodo.<\/span><\/p>\n

 <\/p>\n

Soluciones<\/b><\/h3>\n

Las IPs no se pueden recuperar hasta que no se rotan los nodos, se pueden rotar a mano o ajustar el node_group size para que AWS lo haga por nosotros.<\/span><\/p>\n

Tenemos dos alternativas para solucionarlo:<\/span><\/p>\n

    \n
  1. Cambiar la variable de entorno que controla esto a: WARM_IP_TARGET=2 del daemonset aws-node<\/strong> de modo que cada nodo s\u00f3lo reservar\u00e1 2 IPs. De esta forma, la cuenta anterior ser\u00eda: 4 ENIs y cada ENI 2 IPs, 8 IPs, m\u00e1s 1 IP del nodo, estar\u00edamos consumiendo 9 IPs respecto a las 61 IPs con la configuraci\u00f3n por defecto.<\/span><\/li>\n
  2. Como buena pr\u00e1ctica, si queremos mantener las WARM IPs<\/strong> puesto que es una buena idea y permite que tu aplicaci\u00f3n escale m\u00e1s r\u00e1pido, se puede ampliar el CIDR de la VPC con un nuevo CIDR s\u00f3lo para los pods, de tal forma que los pods se desplieguen ah\u00ed y no usen nuestras valiosas IPs del CIDR principal.<\/span><\/li>\n<\/ol>\n

    a.<\/strong> Para ello, hay que adjuntar un nuevo CIDR a nuestra VPC y crear las subredes correspondientes que usaremos m\u00e1s adelante.<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Imagen: red_eks3.png<\/span><\/p>\n

    b.<\/strong> Crear la variable AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG con valor true en el daemonset de aws-node.<\/span><\/p>\n

    c.<\/strong> Desplegar una definici\u00f3n crd.k8s.amazonaws.com\/v1alpha1 del tipo ENIConfig en nuestro cl\u00faster, del estilo:<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Imagen: eniconfig.png<\/span><\/p>\n

    d.<\/strong> Rotar los nodos para que usen la nueva configuraci\u00f3n.<\/span><\/p>\n

    Nuestra arquitectura pasar\u00eda a estar definida de la siguiente manera:<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Imagen: eks_blog-extra.png<\/span><\/p>\n

     <\/p>\n

    Si te has encontrado con estos problemas y necesitas que te ayudemos, nuestro equipo de especialistas en Cloud estar\u00e1 encantado de trabajar tu caso concreto.<\/span><\/p><\/blockquote>\n

    Contacta aqu\u00ed<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    \u00bfTienes tu aplicaci\u00f3n desplegada sobre EKS y parece que te has quedado corto de IPs al asignar los CIDRs en las subredes? Vamos a analizar qu\u00e9 es lo que sucede debajo del servicio gestionado de Kubernetes de AWS. Partiendo de una arquitectura de referencia como la siguiente: Imagen: eks_blog-base.png T\u00edpica arquitectura de referencia \u201ctier 3 […]<\/p>\n","protected":false},"author":40,"featured_media":25568,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[34],"tags":[322,302,321,323],"class_list":["post-25532","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology-ai","tag-aws","tag-cloud-es","tag-eks","tag-kubernetes"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/25532","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/comments?post=25532"}],"version-history":[{"count":0,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/25532\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media\/25568"}],"wp:attachment":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media?parent=25532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/categories?post=25532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/tags?post=25532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}