{"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\/pt\/blog\/administrirovanie\/devyat-sovetov-po-povysheniyu-proizvoditelnosti-kubernetes","title":{"rendered":"Nove dicas para melhorar o desempenho do Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nove<\/p>\n

Ol\u00e1 a todos! Meu nome \u00e9 Oleg Sidorenkov, sou o l\u00edder da equipe de infraestrutura na empresa DomClick. J\u00e1 utilizamos o \"Cubo\" na produ\u00e7\u00e3o por mais de tr\u00eas anos, e ao longo desse tempo vivenciamos muitos momentos interessantes com ele. Hoje, vou contar como, com a abordagem correta, voc\u00ea pode extrair ainda mais desempenho do Kubernetes \"vanilla\" para o seu cluster. Pronto, vai! <\/p>\n

Todos voc\u00eas sabem que Kubernetes \u00e9 um sistema escal\u00e1vel de c\u00f3digo aberto para orquestra\u00e7\u00e3o de containers; ou melhor, 5 bin\u00e1rios que fazem m\u00e1gica ao gerenciar o ciclo de vida dos seus microsservi\u00e7os no ambiente de servidor. Al\u00e9m disso, \u00e9 uma ferramenta bastante flex\u00edvel, que pode ser montada como um brinquedo de Lego, para m\u00e1xima personaliza\u00e7\u00e3o para diferentes tarefas.<\/p>\n

E parece que est\u00e1 tudo bem: jogue servidores no cluster como lenha na lareira e n\u00e3o se preocupe. Mas se voc\u00ea se preocupa com o meio ambiente, vai pensar: \"Como posso manter o fogo na lareira e ainda preservar a floresta?\" Em outras palavras, como encontrar maneiras de melhorar a infraestrutura e reduzir custos.<\/p>\n

1. Monitore os recursos das equipes e aplica\u00e7\u00f5es<\/h2>\n

\"Nove<\/p>\n

Um dos m\u00e9todos mais simples, mas eficazes, \u00e9 a implementa\u00e7\u00e3o de requests\/limits. Separe as aplica\u00e7\u00f5es por namespaces e os namespaces pelas equipes de desenvolvimento. Defina os valores de consumo de tempo de CPU, mem\u00f3ria e armazenamento ef\u00eamero para cada aplica\u00e7\u00e3o antes do deployment.<\/p>\n

resources:\n   requests:\n     memory: 2Gi\n     cpu: 250m\n   limits:\n     memory: 4Gi\n     cpu: 500m<\/code><\/pre>\n
Por experi\u00eancia, chegamos \u00e0 conclus\u00e3o de que n\u00e3o devemos inflacionar os requests em rela\u00e7\u00e3o aos limits em mais de duas vezes. O volume do cluster \u00e9 calculado com base nos requests, e se voc\u00ea definir para as aplica\u00e7\u00f5es uma diferen\u00e7a de recursos, por exemplo, de 5 a 10 vezes, imagine o que acontecer\u00e1 com o seu n\u00f3 quando ele estiver cheio de pods e de repente receber uma carga. Nada bom. No m\u00ednimo, throttling, e no m\u00e1ximo, voc\u00ea dir\u00e1 adeus ao worker e enfrentar\u00e1 uma carga c\u00edclica nos outros n\u00f3s ap\u00f3s os pods come\u00e7arem a migrar.<\/p>\n
Al\u00e9m disso, com o limitranges<\/code> voc\u00ea pode definir valores de recursos para o container no in\u00edcio \u2014 m\u00ednimos, m\u00e1ximos e padr\u00e3o:<\/p>\n
\u279c  ~ kubectl describe limitranges --namespace ops\nNome:       limit-range\nNamespace:  ops\nTipo        Recurso           M\u00edn   M\u00e1x   Solicita\u00e7\u00e3o Padr\u00e3o  Limite Padr\u00e3o  Raz\u00e3o M\u00e1x Limite\/Solicita\u00e7\u00e3o\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
N\u00e3o se esque\u00e7a de limitar os recursos do namespace para que um \u00fanico time n\u00e3o consuma todos os recursos do cluster:<\/p>\n
\u279c  ~ kubectl describe resourcequotas --namespace ops\nNome:                   resource-quota\nNamespace:              ops\nRecurso                Usado          Limitado\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 pode ser visto na descri\u00e7\u00e3o resourcequotas<\/code>, se o time ops tentar implantar pods que consumir\u00e3o 10 cpu a mais, o agendador n\u00e3o permitir\u00e1 e retornar\u00e1 um erro:<\/p>\n
Error creating: pods \"nginx-proxy-9967d8d78-nh4fs\" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10<\/code><\/pre>\n
Para resolver um problema como esse, voc\u00ea pode escrever uma ferramenta, como este<\/a><\/noindex>, que \u00e9 capaz de armazenar e commitar o estado dos recursos dos times.<\/p>\n
2. Escolha um armazenamento de arquivos ideal<\/h2>\n
\"Nove<\/p>\n
Aqui gostaria de abordar o tema de volumes persistentes e subsistemas de disco nos n\u00f3s worker do Kubernetes. Espero que ningu\u00e9m esteja usando \"Kub\" em HDD em produ\u00e7\u00e3o, mas \u00e0s vezes mesmo um SSD comum j\u00e1 n\u00e3o \u00e9 suficiente. Enfrentamos um problema em que os logs estavam sobrecarregando o disco com opera\u00e7\u00f5es de entrada e sa\u00edda, e aqui as op\u00e7\u00f5es de solu\u00e7\u00e3o s\u00e3o limitadas: <\/p>\n