Estoy revisando un problema de escalado y sospechamos que tiene algo que ver con la memoria, pero después de ejecutar una prueba de carga en la máquina local, no parece haber pérdida de memoria. Estamos alojando la aplicación .net core en Kubernetes, con recursos que configuran 800mi de memoria de solicitud sin límite. Y según se describe en este artículo
El desencadenante de la recolección de basura ocurre cuando el sistema tiene poca memoria física y recibe una notificación del sistema operativo.
Entonces, ¿eso significa que es poco probable que GC se active hasta que mis nodos tengan poca memoria si no configuramos el límite de memoria, y eventualmente ocupará la mayor parte de la memoria en el nodo?
Sí, eso es exactamente lo que puede suceder, tanto con .NET como con otros pods.
Establezca siempre los límites de memoria y CPU, ya que esto puede tener un impacto en otros pods o Configure las solicitudes y límites de memoria predeterminados para un espacio de nombres
@Martin tiene razón, pero me gustaría brindar más información sobre este tema.
Prácticas recomendadas de Kubernetes: Solicitudes y límites de recursos es una muy buena guía que explica la idea detrás de estos mecanismos con una explicación detallada y ejemplos.
Además, la Gestión de recursos para contenedores le proporcionará los documentos oficiales sobre:
Solicitudes y límites
Tipos de recursos
Solicitudes de recursos y límites de Pod y Container
Unidades de recursos en Kubernetes
Cómo se programan los pods con solicitudes de recursos
Cómo se ejecutan los pods con límites de recursos, etc.
Tenga en cuenta que es muy importante tener una buena estrategia al calcular cuántos recursos necesitaría para cada contenedor. De manera óptima, sus pods deberían usar exactamente la cantidad de recursos que solicitó, pero eso es casi imposible de lograr. Si el uso es inferior a su solicitud, está desperdiciando recursos. Si es más alto, corre el riesgo de tener problemas de rendimiento. Considere un margen del 25% hacia arriba y hacia abajo del valor de la solicitud como un buen punto de partida. En cuanto a los límites, conseguir un buen ajuste dependería de probar y ajustar. No existe un valor óptimo que se ajuste a todos, ya que depende de muchos factores relacionados con la aplicación en sí, el modelo de demanda, la tolerancia a errores, etc.
Y finalmente, puede usar el servidor de métricas para obtener el uso de CPU y memoria de los pods.