<\/p>\n
Para cada fase, intentaremos describir los conceptos clave y el mejor enfoque, en funci\u00f3n del proveedor de cloud (principalmente Amazon Web Services y Microsoft Azure) y del entorno del cluster (producci\u00f3n\/no producci\u00f3n).<\/span><\/p>\n En el mundo de Kubernetes y especialmente con los servicios gestionados, <\/span>asignar costes puede ser una aut\u00e9ntica pesadilla porque para hacerlo bien hay que tener en cuenta e identificar m\u00faltiples recursos: por un lado, respecto a Kubernetes como los pods, pero tambi\u00e9n a nivel del proveedor Cloud (y teniendo en cuenta costes como balanceador de carga\/nodo\/almacenamiento\/red\/…)<\/span><\/p>\n La <\/span>asignaci\u00f3n de costes es el proceso de dividir facturas y asociar cada parte a un centro de costes, que podr\u00eda ser una aplicaci\u00f3n\/departamento\/equipo e intentar obtener la mayor precisi\u00f3n posible. De este modo, se obtiene una mayor visibilidad de los costes. En un entorno de nube, esto no es f\u00e1cil porque algunos recursos se comparten entre muchos centros. Por otro lado, tambi\u00e9n hay que gestionar descuentos como reservas, ancho de banda de red y muchos otros elementos.<\/span><\/p>\n Para lograrlo, se utilizan etiquetas para identificar al propietario de los recursos (por ejemplo, aplicaci\u00f3n1) y, a continuaci\u00f3n, es necesario establecer una <\/span>estrategia adicional para asignar los elementos no etiquetados.<\/span><\/p>\n Adem\u00e1s, los proveedores cloud cobran a nivel de host (con la excepci\u00f3n de AWS EKS que se ejecuta en modo Fargate completo y GKE Autopilot), no a nivel de contenedor. Por lo tanto, debe asignar una cantidad determinada de recursos de host (vCPU\/Memoria\/…) a cada contenedor y, a continuaci\u00f3n, resumirla en funci\u00f3n de su estrategia de aplicaci\u00f3n de etiquetas. Tambi\u00e9n debes tener en cuenta los \u00ab<\/span>costes compartidos\u00bb, como el coste primario de Kubernetes, y los \u00ab<\/span>costes ociosos\u00bb (porcentaje de recursos de host no utilizados). No puedes utilizar el servicio de gesti\u00f3n de costes de un proveedor de nube com\u00fan, como AWS Cost Explorer o Azure Cost Management, para crear la distribuci\u00f3n de costes.<\/span><\/p>\n Utilizar una <\/span>herramienta de terceros como Cloudhealth podr\u00eda ser \u00fatil en tu tarea de distribuci\u00f3n de costes, pero la realidad es que tiene un coste elevado, a menos que puedas utilizar herramientas como<\/span> Kubecost<\/span><\/a> para obtener una estimaci\u00f3n de la distribuci\u00f3n de costes (funciona con AWS y GCP).<\/span><\/p>\n No existe una estrategia \u00fanica que funcione en todos los casos, tienes que encontrar la que mejor se adapte a tu caso de uso. Estas son algunas de las pautas:<\/p>\n <\/p>\n La fase de optimizaci\u00f3n se centra en los procesos de <\/span>reducci\u00f3n de costes. Algunos de ellos pueden aplicarse independientemente del proveedor de la nube, pero otros dependen de especificaciones.<\/span><\/p>\n Podemos agrupar las optimizaciones en cuatro categor\u00edas:<\/span><\/p>\n <\/p>\n A modo de gu\u00eda r\u00e1pida, te compartimos el siguiente diagrama, en el que puedes encontrar el orden de las optimizaciones recomendadas en funci\u00f3n del entorno del cluster (producci\u00f3n o no producci\u00f3n):<\/span><\/p>\n <\/p>\n El <\/span>redimensionamiento puede realizarse a nivel de pod\/contenedor y\/o a nivel de host\/nodo.<\/span><\/p>\n Nota: redimensionar significa ajustar las capacidades de los recursos, pero tambi\u00e9n a\u00f1adir\/eliminar recursos id\u00e9nticos.<\/span><\/p>\n En el mundo de los contenedores, existen varias <\/span>estrategias de escalado: Escalado horizontal (HPA)<\/span><\/p>\n Al igual que un grupo de autoescalado de EC2 o Azure VMSS, el escalado horizontal tiene como objetivo a\u00f1adir o eliminar recursos (pods en este caso) para mantenerse al d\u00eda con la carga de trabajo actual.<\/span><\/p>\n Kubernetes Horizontal Pod AutoScaling<\/span><\/a> est\u00e1 dise\u00f1ado para aplicaciones sin estado, que pueden iniciarse r\u00e1pidamente para gestionar picos de uso y detenerse con elegancia.<\/span><\/p>\n A diferencia del escalado horizontal, que a\u00f1ade o elimina pods, el escalado vertical puede <\/span>aumentar o disminuir los recursos de los pods (CPU\/Memoria) tras un periodo de evaluaci\u00f3n.<\/span><\/p>\n El autoescalado vertical de Kubernetes<\/span><\/a> es especialmente \u00fatil para ajustar las demandas de CPU y memoria al consumo real de los contenedores. A menudo, las demandas de los contenedores est\u00e1n sobredimensionadas, desperdiciando recursos.<\/span><\/p>\n VPA puede ajustar autom\u00e1ticamente los recursos de los contenedores. Sin embargo, no\u00a0 es recomendable. T\u00f3malo como consejo y luego ajusta tus definiciones de recursos de Kubernetes.\u00a0<\/span><\/p>\n Tus pods utilizan recursos de nodo, por lo que cuando utiliza HPA o VPA, es obligatorio poder <\/span>ajustar su capacidad.<\/span><\/p>\n El Kubernetes<\/span> Cluster Autoscaler<\/span><\/a> puede a\u00f1adir o eliminar nodos para optimizar la capacidad de los recursos del cluster.<\/span><\/p>\n El<\/span> PodDistruptionBudget<\/span><\/a> es un elemento esencial cuando se activa el cluster Autoscaler para evitar el tiempo de inactividad de la aplicaci\u00f3n.<\/span><\/p>\n Otro concepto importante relativo al escalado de nodos es la <\/span>coherencia con la carga de trabajo. Esto significa que se debe tener en cuenta la relaci\u00f3n CPU\/memoria de su nodo para evitar tener demasiada memoria o CPU sin utilizar. Por ejemplo, tus pods consumen m\u00e1s memoria que CPU, pero la capacidad de los nodos es m\u00e1s o menos igual. En este caso, estar\u00e1s malgastando recursos de CPU y aumentando el coste de tu infraestructura. Para evitarlo, cambia el tipo de instancia de nodo a una instancia optimizada para memoria.<\/span><\/p>\n Para detectar el problema de coherencia con la carga de trabajo, comprueba el \u00ab<\/span>uso solicitado de CPU\u00bb y el \u00ab<\/span>uso solicitado de memoria\u00bb. Por ejemplo, tienes un problema si el \u00abuso de CPU\u00bb es del 100% mientras que la \u00abdemanda de memoria\u00bb es solo del 50%.<\/span><\/p>\n Fuera de hora significa <\/span>detener o reducir la capacidad de los recursos por la noche (y los fines de semana). Para los entornos que no son de producci\u00f3n, deber\u00eda ser la norma.<\/span><\/p>\n Parar los recursos entre las 8 de la tarde y las 7 de la ma\u00f1ana y los fines de semana tiene una ventaja, y es que reduce el coste en un 60%.\u00a0<\/span><\/p>\n kube-downscaler<\/a> es el punto de entrada para clusters de producci\u00f3n y no producci\u00f3n (debe combinarse con Cluster Autoscaler<\/a> para ahorrar dinero).<\/p>\n Este proyecto de c\u00f3digo abierto reducir\u00e1 los despliegues\/clusters est\u00e1ticos\/HPA bas\u00e1ndose en pol\u00edticas definidas (tiempo\/no conforme con condiciones de exclusi\u00f3n como la restricci\u00f3n del espacio de nombres).<\/p>\n En un entorno de producci\u00f3n, debes asegurarte de que, incluso fuera de las horas de trabajo, tu cluster\/aplicaci\u00f3n cliente permanece <\/span>altamente disponible y tolerante a fallos:<\/span><\/p>\n No se trata realmente de horas valle, sino de una reducci\u00f3n de escala cuando disminuye la carga del cluster.<\/span><\/p>\n <\/p>\n Un cluster que no sea de producci\u00f3n deber\u00eda poder escalarse hasta 0 trabajadores, pero con los clusters Kubernetes gestionados, algunos servicios en la nube tienen <\/span>limitaciones (ver m\u00e1s abajo).<\/span><\/p>\n cluster-turndown<\/span><\/a> es un proyecto de c\u00f3digo abierto que facilita la realizaci\u00f3n de operaciones fuera de producci\u00f3n. Actualmente, el proyecto es compatible con GKE, EKS y KOPS en AWS.<\/span><\/p><\/blockquote>\n Puedes reducir el n\u00famero de trabajadores (grupo administrado o no administrado) a 0, pero no olvides que AWS sigue cobrando por la administraci\u00f3n del cluster.<\/span><\/p>\n Azure AKS es diferente a AWS porque Azure <\/span>no cobra por la gesti\u00f3n del cluster (a menos que a\u00f1adas la opci\u00f3n uptime SLA.sta opci\u00f3n no tiene sentido para un cluster que no sea de producci\u00f3n), pero no puedes reducir el grupo de nodos por defecto (sistema) a 0.<\/span><\/p>\n El coste depende del tama\u00f1o de la m\u00e1quina virtual. Para los pools de trabajadores, puedes reducirlos a 0.<\/span><\/p>\n Los Spot Nodes son otra buena forma de reducir el coste de los clusters Kubernetes. En general, las instancias\/m\u00e1quinas virtuales spot son recursos \u00abnormales\u00bb que se benefician de un <\/span>descuento significativo. Pero este descuento tiene un inconveniente: los proveedores de la nube <\/span>no garantizan la disponibilidad de estos recursos. Pueden interrumpirse en cualquier momento.<\/span><\/p>\n Esto significa que las aplicaciones en ejecuci\u00f3n deben ser tolerantes a fallos para un entorno de producci\u00f3n (fuera de producci\u00f3n, esto no es obligatorio, pero debes aceptar el riesgo de tiempo de inactividad hasta que un nuevo nodo est\u00e9 listo).<\/span><\/p>\n Cada proveedor de nube ofrece una forma de recibir una notificaci\u00f3n (API de metadatos local) unos segundos\/minutos antes de que el nodo se apague. Esto mitiga el impacto del apagado del nodo.<\/span><\/p>\n Para utilizar con \u00e9xito los nodos spot, es ideal considerar el uso de:<\/span><\/p>\n AWS anunci\u00f3<\/span> la compatibilidad con instancias spot en un grupo de nodos administrados<\/span><\/a>. Con esta nueva caracter\u00edstica, el drenaje de nodos y la estrategia de instancias spot son gestionados por AWS. Adem\u00e1s, ofrece una<\/span>estrategia de asignaci\u00f3n de capacidad optimizada<\/span><\/a> y<\/span>reequilibrio de capacidad<\/span><\/a>, dos caracter\u00edsticas interesantes para los grupos de Spot AutoScaling.<\/span><\/p><\/blockquote>\n Azure tiene algunas limitaciones\/condiciones para utilizar los nodos spot:<\/span><\/p>\n <\/p>\n El consejo m\u00e1s com\u00fan para utilizar nodos spot en un cluster de producci\u00f3n es <\/span>distribuir la capacidad de nodos entre nodos bajo demanda\/est\u00e1ndar y nodos spot para evitar sufrir un apagado completo si los nodos spot no est\u00e1n disponibles. La distribuci\u00f3n depende principalmente de las aplicaciones alojadas.<\/span><\/p>\n Por ejemplo, la distribuci\u00f3n podr\u00eda ser<\/span><\/p>\n <\/p>\n En un entorno fuera de producci\u00f3n, la <\/span>estrategia de distribuci\u00f3n puntual puede ser mucho m\u00e1s agresiva que en producci\u00f3n, ya que no es necesaria una disponibilidad absoluta. Incluso puede apuntar a la distribuci\u00f3n solo con nodos puntuales. En caso contrario, como en un entorno de producci\u00f3n, elige un equilibrio entre bajo demanda\/est\u00e1ndar y puntual.<\/span><\/p>\n Para un cluster de producci\u00f3n debes<\/span> iniciar el proceso de reserva lo antes posible. Puedes empezar poco a poco reservando solo, por ejemplo, el 10% de tu capacidad e ir reservando m\u00e1s con el tiempo.<\/span><\/p>\n Utilizar AWS Fargate (parcial o totalmente) es una elecci\u00f3n f\u00e1cil, ya que solo los planes de ahorro inform\u00e1tico pueden cubrir tanto EC2 como Fargate.<\/span><\/p>\n Alternativamente, si tienes una <\/span>mezcla de instancias On-Demand y Spot, puedes elegir cubrir el 100% de tu On-Demand y si no tienes una instancia Spot, depende de la carga del cluster.\u00a0<\/span><\/p>\n El punto de partida es comprar m\u00e1quinas virtuales reservadas para el conjunto de nodos por defecto (sistema). Si tienes una mezcla de instancias Standard y Spot, puedes elegir cubrir el 100% de tu instancia Standard y si no tienes una instancia Spot, depende de la carga del cluster.<\/span><\/p>\n Con la funci\u00f3n de cancelaci\u00f3n de reservas, puedes ser realmente agresivo en la cobertura de reservas, ya que el punto de equilibrio se alcanza r\u00e1pidamente (los gastos de cancelaci\u00f3n son s\u00f3lo el 3% de los gastos de reserva restantes). Consulta la<\/span> documentaci\u00f3n de Azure<\/span><\/a> para obtener m\u00e1s informaci\u00f3n.<\/span><\/p><\/blockquote>\n Si no ejecutas tu cluster \u00fanicamente con nodos de subasta y no cambias a grupos de 0 nodos durante las noches o los fines de semana, puedes reservar el <\/span>n\u00famero m\u00ednimo de nodos operativos.<\/span><\/p>\n Como no puedes reducir el pool de nodos por defecto (sistema) a 0, puedes adquirir <\/span>m\u00e1quinas virtuales reservadas para cubrirlos.<\/span><\/p>\n En el caso de los pools de nodos de trabajo, si los reduces a 0 durante las noches\/los fines de semana, no puedes comprar reservas. Como alternativa, puedes reservar el n\u00famero m\u00ednimo de nodos de trabajo.<\/span><\/p>\n Con la funci\u00f3n de cancelaci\u00f3n de reservas, puedes ser muy agresivo en la cobertura de reservas, ya que el punto de equilibrio se alcanza r\u00e1pidamente (los gastos de cancelaci\u00f3n son s\u00f3lo el 3% de los gastos de reserva restantes). Consulta la<\/span>Informar<\/span><\/h2>\n
\n
Optimizar<\/span><\/h2>\n
\n
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2024\/10\/cluster-kubernetes.png\")
<\/p>\nRedimensionar<\/span><\/h3>\n
Contenedor<\/span><\/h3>\n
Escalado vertical (VPA)<\/span><\/h4>\n
Redimensionamiento de nodos<\/span><\/h4>\n
Fuera de horario<\/span><\/h3>\n
Producci\u00f3n<\/span><\/h3>\n
\n
No producci\u00f3n<\/span><\/h3>\n
AWS EKS<\/span><\/h4>\n
AZURE AKS<\/span><\/h4>\n
Nodo spot\u00a0<\/span><\/h4>\n
\n
\n
Producci\u00f3n<\/span><\/h3>\n
\n
Fuera de producci\u00f3n<\/span><\/h3>\n
Producci\u00f3n<\/span><\/h3>\n
AWS<\/span><\/h4>\n
Azure<\/span><\/h4>\n
No producci\u00f3n<\/span><\/h3>\n
AWS<\/span><\/h4>\n
Azure<\/span><\/h4>\n