{"id":97982,"date":"2020-10-23T14:42:15","date_gmt":"2020-10-23T12:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes"},"modified":"2020-11-18T00:58:47","modified_gmt":"2020-11-17T22:58:47","slug":"devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"Nueve consejos para mejorar el rendimiento de Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nueve<\/p>\n

\u00a1Hola a todos! Me llamo Oleg Sidorenkov, trabajo en la empresa DomKlik como l\u00edder del equipo de infraestructura. Hemos estado utilizando \"Cubo\" en producci\u00f3n durante m\u00e1s de tres a\u00f1os, y durante este tiempo hemos vivido muchos momentos interesantes con \u00e9l. Hoy les contar\u00e9 c\u00f3mo, con el enfoque correcto, se puede extraer a\u00fan m\u00e1s rendimiento de un Kubernetes \"vanilla\" para su cl\u00faster. \u00a1Listos, listos, ya! <\/p>\n

Todos ustedes saben muy bien que Kubernetes es un sistema escalable de c\u00f3digo abierto para la orquestaci\u00f3n de contenedores; bien, o 5 binarios que hacen magia, gestionando el ciclo de vida de sus microservicios en un entorno de servidor. Adem\u00e1s, es una herramienta bastante flexible, que se puede ensamblar como un juguete de Lego, para una m\u00e1xima personalizaci\u00f3n para diferentes tareas.<\/p>\n

Y, aparentemente, todo est\u00e1 bien: simplemente a\u00f1ade servidores al cl\u00faster como si fueran le\u00f1a a la chimenea y no habr\u00e1 problemas. Pero si te preocupas por el medio ambiente, te preguntar\u00e1s: \"\u00bfC\u00f3mo puedo mantener el fuego en la estufa y cuidar el bosque?\". En otras palabras, \u00bfc\u00f3mo encontrar formas de mejorar la infraestructura y reducir costos?<\/p>\n

1. Supervise los recursos de los equipos y aplicaciones.<\/h2>\n

\"Nueve<\/p>\n

Uno de los m\u00e9todos m\u00e1s simples, pero efectivos, es implementar requests\/limits. Separa las aplicaciones por namespaces, y los namespaces por equipos de desarrollo. Establece valores de consumo de tiempo de CPU, memoria, y almacenamiento ef\u00edmero antes de desplegar la aplicaci\u00f3n.<\/p>\n

resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n
Por experiencia, hemos llegado a la conclusi\u00f3n: no se deben inflar los requests por encima de los l\u00edmites m\u00e1s de dos veces. El tama\u00f1o del cl\u00faster se calcula a partir de los requests, y si estableces diferencias de recursos en las aplicaciones, por ejemplo, de 5 a 10 veces, imagina qu\u00e9 pasar\u00e1 con tu nodo cuando se llene de pods y de repente reciba carga. Nada bueno. Como m\u00ednimo, tendr\u00e1s throttling, y como m\u00e1ximo, dir\u00e1s adi\u00f3s a un worker y tendr\u00e1s carga c\u00edclica en los dem\u00e1s nodos una vez que los pods empiecen a migrar.<\/p>\n
Adem\u00e1s, con limitranges<\/code> puedes establecer inicialmente los valores de recursos para el contenedor \u2014 m\u00ednimos, m\u00e1ximos y por defecto:<\/p>\n
\u279c  ~ kubectl describe limitranges --namespace ops\nName:       limit-range\nNamespace:  ops\nType        Resource           Min   Max   Default Request  Default Limit  Max Limit\/Request Ratio\n----        --------           ---   ---   ---------------  -------------  -----------------------\nContainer   cpu                50m   10    100m             100m           2\nContainer   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -\nContainer   memory             64Mi  40Gi  128Mi            128Mi          2<\/code><\/pre>\n
No olvides limitar los recursos del namespace para que un equipo no pueda acaparar todos los recursos del cl\u00faster:<\/p>\n
\u279c  ~ kubectl describe resourcequotas --namespace ops\nName:                   resource-quota\nNamespace:              ops\nResource                Used          Hard\n--------                ----          ----\nlimits.cpu              77250m        80\nlimits.memory           124814367488  150Gi\npods                    31            45\nrequests.cpu            53850m        80\nrequests.memory         75613234944   150Gi\nservices                26            50\nservices.loadbalancers  0             0\nservices.nodeports      0             0<\/code><\/pre>\n
Como se observa en la descripci\u00f3n resourcequotas<\/code>, si el equipo ops quiere desplegar pods que consumir\u00e1n otros 10 cpu, el programador no permitir\u00e1 que esto suceda y generar\u00e1 un error:<\/p>\n
Error creando: pods \"nginx-proxy-9967d8d78-nh4fs\" est\u00e1 prohibido: cuota excedida: resource-quota, solicitado: limits.cpu=5, requests.cpu=5, usado: limits.cpu=77250m, requests.cpu=53850m, limitado: limits.cpu=10, requests.cpu=10<\/code><\/pre>\n
Para resolver este tipo de problemas, se puede escribir una herramienta, como este<\/a><\/noindex>, que pueda almacenar y confirmar el estado de los recursos de los equipos.<\/p>\n
2. Selecciona un almacenamiento de archivos \u00f3ptimo<\/h2>\n
\"Nueve<\/p>\n
Aqu\u00ed quisiera tocar el tema de vol\u00famenes persistentes y el subsistema de disco de los nodos worker de Kubernetes. Espero que nadie est\u00e9 usando \u00abCube\u00bb en HDD en producci\u00f3n, pero a veces un SSD convencional ya no es suficiente. Nos hemos encontrado con el problema de que los registros mataban el disco debido a las operaciones de E\/S, y aqu\u00ed no hay muchas opciones disponibles: <\/p>\n