{"id":26349,"date":"2022-07-21T13:29:59","date_gmt":"2022-07-21T11:29:59","guid":{"rendered":"https:\/\/www.makingscience.com\/?p=26349"},"modified":"2022-07-21T13:29:59","modified_gmt":"2022-07-21T11:29:59","slug":"pods-cidr-pods-por-nodo-y-su-relacion","status":"publish","type":"post","link":"https:\/\/www.makingscience.com\/es\/blog\/pods-cidr-pods-por-nodo-y-su-relacion\/","title":{"rendered":"Pods CIDR: pods por nodo y su relaci\u00f3n"},"content":{"rendered":"

\u00bfConoces la relaci\u00f3n entre el CIDR de la red de Pods, la opci\u00f3n de pods por nodo en GKE y c\u00f3mo puede causar varios problemas en el futuro? Pues si no lo sabes, qu\u00e9date en este art\u00edculo para descubrirlo.<\/p>\n

Antes de empezar a crear un cluster de GKE, debemos planificar la configuraci\u00f3n con tiempo y esfuerzo para evitar problemas en el futuro. El problema relacionado con el tema del que voy a hablar, puede llevar a tener que recrear todo el cluster, lo cual es una tarea muy tediosa y puede causar muchos problemas (incluyendo tiempos de inactividad).<\/p>\n

Para entender mejor el problema, lo primero que tenemos que saber es c\u00f3mo funciona el cluster de Kubernetes en t\u00e9rminos de red. Me limitar\u00e9 a la informaci\u00f3n relacionada con el tema para mantenerlo simple y condensado.<\/p>\n

 <\/p>\n

Rango de direcciones del cluster pod<\/h3>\n

El rango de direcciones del cluster pod es el CIDR reservado para todos los pods del cluster. Todas las IP de los pods estar\u00e1n ubicadas en este rango, por lo que se puede utilizar para todo lo relacionado con la red, como por ejemplo limitar el acceso en un firewall.<\/p>\n

M\u00e1ximo de pods por nodo<\/h3>\n

Este n\u00famero limitar\u00e1 el n\u00famero de pods en cada nodo del cluster, pero tambi\u00e9n limitar\u00e1 indirectamente el n\u00famero de nodos que se pueden crear en el cluster.<\/p>\n

Relaci\u00f3n entre el rango de direcciones de los pods y los pods por nodo<\/h3>\n

El n\u00famero de pods por nodo definir\u00e1 la configuraci\u00f3n de red utilizada en los nodos, y esto puede hacer que el rango de direcciones de los pods se llene, evitando la creaci\u00f3n de nuevos nodos. Esto sucede porque Kubernetes reserva una subred para cada nodo para ayudar a enrutar los paquetes de red entre los nodos. Con la direcci\u00f3n IP del pod de destino se conoce el CIDRy el nodo donde se encuentra, evitando complejas tareas de enrutamiento.<\/p>\n

La siguiente tabla muestra la relaci\u00f3n entre el n\u00famero de pods por nodo y las direcciones IP reservadas:<\/p>\n

\"\"<\/p>\n

M\u00e1s informaci\u00f3n en \ud83d\udc49 https:\/\/cloud.google.com\/kubernetes-engine\/docs\/how-to\/flexible-pod-cidr<\/p>\n

Como podemos ver, cada pod reservar\u00e1 al menos dos direcciones IP, por lo que el CIDR requerido estar\u00e1 relacionado con su n\u00famero.<\/p>\n

Por ejemplo: Tenemos un cluster con un rango de direcciones de pods de cluster de 10.0.0.0\/24 (256 direcciones IP). Si configuramos el M\u00e1ximo de Pods por Nodo a 20 obtendremos una reserva de 40 IP por nodo. Como no es posible un CIDR con espacio para 40 direcciones, se utilizar\u00e1 el CIDR m\u00e1s cercano con suficientes direcciones. En este caso el CIDR m\u00e1s cercano es el \/36 con 64 direcciones por subred.<\/p>\n

Teniendo en cuenta lo anterior, el cluster estar\u00e1 limitado a 4 nodos (256 \/ 64 = 4):<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Me he equivocado en la configuraci\u00f3n, \u00bfqu\u00e9 puedo hacer?<\/h3>\n

Si tus rangos CIDR pueden ser extendidos entonces est\u00e1s de suerte, para a\u00f1adir m\u00e1s rangos siguiendo esta gu\u00eda\u00a0<\/a><\/p>\n

Si esto no consigue que funcione, o necesitas un CIDR continuo, entonces la \u00fanica forma de proceder ser\u00e1 recrear el cluster completo (lo cual no siempre es posible).
\nEs por eso, que calcular el cluster antes de crearlo es lo mejor que puedes hacer.<\/p>\n","protected":false},"excerpt":{"rendered":"

\u00bfConoces la relaci\u00f3n entre el CIDR de la red de Pods, la opci\u00f3n de pods por nodo en GKE y c\u00f3mo puede causar varios problemas en el futuro? Pues si no lo sabes, qu\u00e9date en este art\u00edculo para descubrirlo. Antes de empezar a crear un cluster de GKE, debemos planificar la configuraci\u00f3n con tiempo y […]<\/p>\n","protected":false},"author":40,"featured_media":26496,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[910],"tags":[302,341,342,340],"class_list":["post-26349","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology-ai-es","tag-cloud-es","tag-gke","tag-google-cloud","tag-kubertnetes"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/26349","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=26349"}],"version-history":[{"count":0,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/posts\/26349\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media\/26496"}],"wp:attachment":[{"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/media?parent=26349"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/categories?post=26349"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.makingscience.com\/es\/wp-json\/wp\/v2\/tags?post=26349"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}