{"id":82920,"date":"2020-05-26T13:42:37","date_gmt":"2020-05-26T11:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov"},"modified":"2020-05-26T13:42:37","modified_gmt":"2020-05-26T11:42:37","slug":"luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-nastrojka-zaprosov-i-limitov-resursov","title":{"rendered":"Melhores pr\u00e1ticas de Kubernetes. Configura\u00e7\u00e3o de solicita\u00e7\u00f5es e limites de recursos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Melhores pr\u00e1ticas Kubernetes. Criando pequenos cont\u00eaineres<\/a><\/noindex>
\nAs melhores pr\u00e1ticas do Kubernetes. Organiza\u00e7\u00e3o do Kubernetes com namespaces<\/a><\/noindex>
\nAs melhores pr\u00e1ticas do Kubernetes. Verifica\u00e7\u00e3o de viabilidade do Kubernetes com testes de Readiness e Liveness<\/a><\/noindex><\/p>\n

Para cada recurso do Kubernetes, \u00e9 poss\u00edvel configurar dois tipos de requisitos \u2014 Requests e Limits. O primeiro descreve os requisitos m\u00ednimos para a disponibilidade de recursos do n\u00f3, necess\u00e1rios para iniciar um cont\u00eainer ou pod; o segundo limita rigidamente os recursos dispon\u00edveis para o cont\u00eainer. <\/p>\n

Quando o Kubernetes agenda um pod, \u00e9 muito importante que os cont\u00eaineres tenham recursos suficientes para funcionar corretamente. Se voc\u00ea planeja implantar um grande aplicativo em um n\u00f3 com recursos limitados, \u00e9 bem prov\u00e1vel que ele n\u00e3o funcione devido \u00e0 falta de mem\u00f3ria ou capacidade do processador. Neste artigo, discutiremos como resolver problemas de escassez de recursos computacionais por meio de solicita\u00e7\u00f5es de recursos e limites.<\/p>\n

Requests e Limits s\u00e3o mecanismos que o Kubernetes usa para gerenciar recursos como CPU e mem\u00f3ria. Requests garantem que o cont\u00eainer receba o recurso solicitado. Se um cont\u00eainer solicitar um recurso, o Kubernetes o agendar\u00e1 apenas em um n\u00f3 que pode fornec\u00ea-lo. Os limites Limits controlam que os recursos solicitados pelo cont\u00eainer nunca excedam um determinado valor.<\/p>\n

\"Melhores<\/a><\/noindex><\/p>\n

Um cont\u00eainer pode aumentar a capacidade computacional apenas at\u00e9 um certo limite, ap\u00f3s o qual ser\u00e1 restrito. Vamos ver como isso funciona. Existem dois tipos de recursos \u2014 CPU e mem\u00f3ria. O agendador do Kubernetes usa dados sobre esses recursos para determinar onde executar seus pods. Uma especifica\u00e7\u00e3o t\u00edpica de recursos para um pod se parece assim.<\/p>\n

\"Melhores
\n
\nCada cont\u00eainer em um pod pode definir suas pr\u00f3prias solicita\u00e7\u00f5es e limites de recursos, sendo tudo isso aditivo. Os recursos de CPU s\u00e3o definidos em milicore. Se seu cont\u00eainer precisa de dois n\u00facleos completos para funcionar, voc\u00ea define o valor como 2000m. Se o cont\u00eainer precisa apenas de 1\/4 de n\u00facleo, o valor ser\u00e1 250m. Tenha em mente que, se voc\u00ea alocar um valor de recursos de CPU maior do que a quantidade de n\u00facleos do maior n\u00f3, o agendamento do seu pod n\u00e3o ser\u00e1 realizado. Uma situa\u00e7\u00e3o semelhante ocorrer\u00e1 se voc\u00ea tiver um pod que precisa de quatro n\u00facleos, enquanto o cluster Kubernetes consiste em apenas duas m\u00e1quinas virtuais principais.<\/p>\n

A menos que seu aplicativo tenha sido projetado especificamente para tirar proveito de m\u00faltiplos n\u00facleos (como ocorre com programas de c\u00e1lculos cient\u00edficos complexos e opera\u00e7\u00f5es com bancos de dados), a melhor pr\u00e1tica \u00e9 definir as Solicita\u00e7\u00f5es de CPU para 1 ou menos, com o subsequente aumento do n\u00famero de r\u00e9plicas para escalabilidade. Essa abordagem proporcionar\u00e1 maior flexibilidade e confiabilidade ao sistema.<\/p>\n

Quando se trata de limites de CPU, fica mais interessante, pois esse recurso \u00e9 considerado comprim\u00edvel. Se seu aplicativo come\u00e7ar a se aproximar do limite de capacidade de processamento, o Kubernetes come\u00e7ar\u00e1 a desacelerar seu cont\u00eainer, usando o CPU Throttling \u2014 a redu\u00e7\u00e3o da frequ\u00eancia do processador. Isso significa que a CPU ser\u00e1 artificialmente limitada, proporcionando potencialmente um desempenho inferior ao aplicativo, no entanto, o processo n\u00e3o ser\u00e1 interrompido nem finalizado. <\/p>\n

Os recursos de mem\u00f3ria s\u00e3o definidos em bytes. Normalmente, o valor nas configura\u00e7\u00f5es \u00e9 medido em mebibytes (Mib), mas voc\u00ea pode definir qualquer valor, desde bytes at\u00e9 petabytes. Aqui, a mesma situa\u00e7\u00e3o ocorre com a CPU \u2014 se voc\u00ea solicitar uma quantidade de mem\u00f3ria que exceda a mem\u00f3ria dispon\u00edvel em seus n\u00f3s, a execu\u00e7\u00e3o desse pod n\u00e3o ser\u00e1 agendada. Mas, ao contr\u00e1rio dos recursos de CPU, a mem\u00f3ria n\u00e3o \u00e9 comprim\u00edvel, pois n\u00e3o existe uma maneira de limitar seu uso. Portanto, a execu\u00e7\u00e3o do cont\u00eainer ser\u00e1 interrompida assim que ele ultrapassar os limites de mem\u00f3ria alocados.<\/p>\n

\"Melhores
\n
\n\u00c9 importante lembrar que voc\u00ea n\u00e3o pode configurar solicita\u00e7\u00f5es que excedam a capacidade dos recursos que seus n\u00f3s podem fornecer. As caracter\u00edsticas dos recursos compartilhados para m\u00e1quinas virtuais GKE podem ser encontradas nos links colocados abaixo deste v\u00eddeo.<\/p>\n

Em um mundo ideal, as configura\u00e7\u00f5es padr\u00e3o do cont\u00eainer seriam mais do que suficientes para que os fluxos de trabalho flu\u00edssem suavemente. Mas o mundo real n\u00e3o \u00e9 assim, as pessoas facilmente podem esquecer de configurar o uso de recursos ou hackers podem definir solicita\u00e7\u00f5es e limites que superem as capacidades reais da infraestrutura. Para evitar o desenvolvimento de cen\u00e1rios semelhantes, \u00e9 poss\u00edvel configurar as quotas de recursos ResourceQuota e os limites de range LimitRange.<\/p>\n

Ap\u00f3s a cria\u00e7\u00e3o dos namespaces, eles podem ser bloqueados com quotas. Por exemplo, se voc\u00ea tem namespaces de produ\u00e7\u00e3o e desenvolvimento, utiliza um padr\u00e3o onde n\u00e3o h\u00e1 quotas para produ\u00e7\u00e3o, enquanto as quotas para desenvolvimento s\u00e3o extremamente rigorosas. Isso permite que a produ\u00e7\u00e3o, em caso de um aumento repentino de tr\u00e1fego, possa usar todos os recursos dispon\u00edveis, bloqueando completamente o desenvolvimento.<\/p>\n

Uma quota de recursos pode parecer assim. Neste exemplo, existem 4 se\u00e7\u00f5es \u2013 s\u00e3o as 4 linhas de c\u00f3digo abaixo.<\/p>\n

\"Melhores
\n
\nVamos analisar cada uma delas. requests.cpu \u00e9 a quantidade m\u00e1xima combinada de solicita\u00e7\u00f5es de capacidade de CPU que podem ser feitas por todos os cont\u00eaineres no namespace. Neste exemplo, voc\u00ea pode ter 50 cont\u00eaineres com solicita\u00e7\u00f5es de 10m, cinco cont\u00eaineres com solicita\u00e7\u00f5es de 100m ou simplesmente um cont\u00eainer com uma solicita\u00e7\u00e3o de 500m. Enquanto o total de requests.cpu desse namespace for inferior a 500m, tudo estar\u00e1 bem.<\/p>\n

A mem\u00f3ria solicitada requests.memory \u00e9 a quantidade m\u00e1xima combinada de solicita\u00e7\u00f5es de mem\u00f3ria que todos os cont\u00eaineres podem ter no namespace. Assim como no caso anterior, voc\u00ea pode ter 50 cont\u00eaineres com 2 MiB, cinco cont\u00eaineres com 20 MiB ou um \u00fanico cont\u00eainer com 100 MiB, contanto que o total de mem\u00f3ria solicitada no namespace seja inferior a 100 mebibytes.<\/p>\n

Limits.cpu \u00e9 o valor m\u00e1ximo combinado de capacidade de CPU que todos os cont\u00eaineres podem usar no namespace. Pode-se considerar que este \u00e9 o limite das solicita\u00e7\u00f5es de capacidade de CPU.<\/p>\n

Finalmente, limits.memory \u2013 o volume m\u00e1ximo de mem\u00f3ria total que todos os cont\u00eaineres em um espa\u00e7o de nome podem usar. Esta \u00e9 uma limita\u00e7\u00e3o de solicita\u00e7\u00f5es de mem\u00f3ria somadas.
\nAssim, por padr\u00e3o, os cont\u00eaineres em um cluster Kubernetes operam com recursos computacionais ilimitados. Com as quotas de recursos, os administradores do cluster podem limitar o consumo de recursos e sua cria\u00e7\u00e3o com base no espa\u00e7o de nome. Dentro do espa\u00e7o de nome, um m\u00f3dulo pod ou cont\u00eainer pode consumir tanta CPU e mem\u00f3ria quanto definido pela quota de recursos do espa\u00e7o de nome. No entanto, h\u00e1 preocupa\u00e7\u00e3o de que um pod ou cont\u00eainer possa monopolizar todos os recursos dispon\u00edveis. Para evitar essa situa\u00e7\u00e3o, utiliza-se o limite de faixa limit Range \u2013 uma pol\u00edtica de limita\u00e7\u00e3o da distribui\u00e7\u00e3o de recursos (para pods ou cont\u00eaineres) dentro do espa\u00e7o de nome.<\/p>\n

O limite de faixa fornece limita\u00e7\u00f5es que podem:<\/p>\n