🥣 ☠️ 🚖 Melhores práticas do Kubernetes. Definindo consultas e limites de recursos ❗️ 🦔 🚴🏼

Melhores práticas do Kubernetes. Criando
práticas recomendadas para Kubernetes de contêineres pequenos. Organização Kubernetes com o namespace Kubernetes
Best Practices. Verificando a viabilidade do Kubernetes usando os testes de Prontidão e

Vida Para cada recurso do Kubernetes, você pode configurar dois tipos de requisitos - Solicitações e Limites. O primeiro descreve os requisitos mínimos para a disponibilidade de recursos de nó livre necessários para executar um contêiner ou lareira, o segundo limita estritamente os recursos disponíveis para o contêiner.

Quando o Kubernetes planeja um pod, é muito importante que os contêineres tenham recursos suficientes para a operação normal. Se você planeja implantar um aplicativo grande em um nó com recursos limitados, é bem possível que ele não funcione porque o nó fica sem memória ou com falta de energia do processador. Neste artigo, veremos como você pode resolver os problemas de falta de capacidade do computador usando solicitações e restrições de recursos.

Solicitações e limites são mecanismos que o Kubernetes usa para gerenciar recursos como processador e memória. Solicitações é o resultado do qual o contêiner é garantido para receber o recurso solicitado. Se um contêiner solicitar um recurso, o Kubernetes o agendará apenas no host que pode fornecê-lo. Limites limita o controle de que os recursos solicitados pelo contêiner nunca excederão um determinado valor.

Um contêiner só pode aumentar o poder de computação até um determinado limite, após o qual será limitado. Vamos ver como isso funciona. Portanto, existem dois tipos de recursos - processador e memória. O Kubernetes Scheduler usa dados desses recursos para descobrir onde executar seus pods. Uma especificação típica de recurso de lareira se parece com isso.

Cada contêiner no pod pode definir suas próprias consultas e restrições, todas aditivas. Os recursos do processador são definidos em milímetros. Se seu contêiner de inicialização precisar de dois núcleos completos, defina o valor como 2000m. Se o contêiner precisar de energia apenas 1/4 do núcleo, o valor será 250m. Lembre-se de que, se você atribuir um valor de recurso do processador maior que o número de núcleos do maior nó, o lançamento da sua lareira não será planejado. Uma situação semelhante ocorrerá se você tiver um sub que precise de quatro núcleos, e o cluster Kubernetes consiste em apenas duas máquinas virtuais principais.

A menos que seu aplicativo seja projetado especificamente para tirar proveito de múltiplos núcleos (com programas como sofisticadas operações de computação científica e banco de dados), é recomendável definir solicitações de CPU para 1 ou menos e executar mais réplicas para escalabilidade. Essa solução dará ao sistema maior flexibilidade e confiabilidade.

Quando se trata de limitações do processador, as coisas ficam mais interessantes, pois são consideradas um recurso compressível. Se o seu aplicativo começar a se aproximar do limite de capacidade do processador, o Kubernetes começará a abrandar o contêiner usando a Otimização da CPU - diminuindo a frequência do processador. Isso significa que o processador será artificialmente limitado, fornecendo ao aplicativo um desempenho potencialmente pior, mas o processo não será encerrado ou transmitido.

Os recursos de memória são definidos em bytes. Geralmente, o valor nas configurações é medido em Mib mebytes, mas você pode especificar qualquer valor, de bytes a petabytes. Aqui a situação é a mesma da CPU - se você solicitar uma quantidade de memória que exceda a quantidade de memória em seus nós, a execução desse pod não será agendada. Mas, diferentemente dos recursos do processador, a memória não é compactada, porque não há como limitar seu uso. Portanto, a execução do contêiner será interrompida assim que ultrapassar os limites da memória alocada a ele.

É importante lembrar que você não pode configurar solicitações que excedam o tamanho dos recursos que seus sites podem fornecer. As características dos recursos compartilhados para máquinas virtuais GKE podem ser encontradas nos links localizados neste vídeo.

Em um mundo ideal, as configurações padrão do contêiner serão suficientes para que os fluxos de trabalho ocorram sem problemas. Mas o mundo real não é assim, as pessoas podem esquecer facilmente de configurar o uso de recursos ou os hackers definirão solicitações e restrições que excederão os recursos reais da infraestrutura. Para impedir que esses cenários se desenvolvam, você pode configurar cotas de recursos ResourceQuota e intervalos de restrição LimitRange.

Depois de criar um espaço para nome, você pode bloqueá-lo com cotas. Por exemplo, se você possui namespaces prod e dev, é usado um modelo no qual não há cotas de produção e as cotas de desenvolvimento são muito rígidas. Isso permite que o produto no caso de um salto acentuado no tráfego consiga todo o recurso disponível, bloqueando completamente o desenvolvedor.

Uma cota de recursos pode se parecer com isso. Neste exemplo, existem 4 seções - estas são as 4 linhas inferiores do código.

Vamos olhar para cada um deles. Requests.cpu é o número máximo de solicitações combinadas de energia do processador que podem vir de todos os contêineres de namespace. Neste exemplo, você pode ter 50 contêineres com solicitações de 10m cada, cinco contêineres com solicitações de 100m ou apenas um contêiner com uma solicitação de 500m. Contanto que o número total de orders.cpu desse espaço para nome seja inferior a 500m, tudo ficará bem.

Solicitações de memória solicitada.memória é a quantidade máxima de solicitações de memória combinadas que todos os contêineres no espaço para nome podem ter. Como no caso anterior, você pode ter 50 contêineres de 2 mib cada, cinco contêineres de 20 Mib cada ou um único contêiner com 100 Mib até que a quantidade total de memória solicitada no espaço para nome seja inferior a 100 mebibytes.

Limits.cpu é o valor máximo da potência combinada do processador que todos os contêineres de espaço para nome podem usar. Podemos assumir que esse é o limite de solicitações de energia do processador.

Finalmente, limits.memory é a quantidade máxima de memória compartilhada que todos os contêineres no espaço para nome podem usar. Essa é uma limitação do total de solicitações de memória.
Portanto, por padrão, os contêineres em um cluster Kubernetes funcionam com recursos de computação ilimitados. Usando cotas de recursos, os administradores de cluster podem limitar o consumo de recursos e sua criação com base no espaço para nome. No espaço para nome, o módulo ou contêiner de pod pode consumir tanta CPU e energia de memória quanto a cota dos recursos do espaço para nome determinar. No entanto, existe a preocupação de que um sub ou um contêiner possa monopolizar todos os recursos disponíveis. Para evitar essa situação, o intervalo limite Range Range é usado - a política de restringir a distribuição de recursos (para pods ou contêineres) no namespace.

O intervalo limite fornece limitações que podem:

;
Starage Request PersistentVolumeClaim ;
Request Limit ;
Requests/Limits .

Dessa forma, você pode criar um intervalo limite no seu espaço para nome. Diferente da cota que se aplica a todo o espaço para nome, o Limit Range é usado para contêineres individuais. Isso pode impedir que os usuários criem contêineres gigantes muito pequenos ou vice-versa dentro do espaço para nome. A faixa de limite pode ser assim.

Como no caso anterior, quatro seções podem ser distinguidas aqui. Vamos dar uma olhada em cada um.
Na seção padrão, as restrições padrão são definidas para o contêiner na lareira. Se você especificar esses valores no intervalo limite, todos os contêineres para os quais esses valores não foram explicitamente definidos serão guiados pelos valores padrão.

Na seção de consulta padrão, defaultRequest, as consultas padrão para o contêiner na lareira estão configuradas. Novamente, se você definir esses valores no intervalo limite, todos os contêineres para os quais esses parâmetros não estiverem explicitamente definidos usarão esses valores por padrão.

A seção max indica as restrições máximas que podem ser definidas para o contêiner na lareira. Os valores na seção padrão e as restrições para o contêiner não podem ser definidos acima desse limite. É importante observar que, se max estiver definido e a seção padrão estiver ausente, o valor máximo se tornará o valor padrão.

A seção min indica as consultas mínimas que podem ser definidas para o contêiner na lareira. Ao mesmo tempo, os valores na seção padrão e as solicitações para o contêiner não podem ser definidos abaixo desse limite.

Novamente, é importante observar que, se esse valor for definido, o valor padrão não é, então o valor mínimo se tornará a consulta padrão.

Como resultado, essas solicitações de recursos são usadas pelo planejador Kubernetes para executar suas cargas de trabalho. Para você configurar corretamente seus contêineres, é muito importante entender como isso funciona. Suponha que você queira executar vários módulos no seu cluster. Supondo que as especificações da lareira sejam válidas, o planejamento do Kubernetes usará o balanceamento cíclico para selecionar o nó da carga de trabalho.

O Kubernetes verificará se o nó do Nó 1 possui recursos suficientes para atender às solicitações do contêiner de pod e, se não tiver, passará para o próximo nó. Se nenhum dos nós no sistema puder satisfazer solicitações, os pods irão para o estado Pendente. Com os recursos do mecanismo do Google Kubernetes, como dimensionamento automático de nós, o GKE pode determinar automaticamente o estado de espera e criar mais alguns nós adicionais.

Se, posteriormente, houver um excesso de capacidade de nós, a função de escalonamento automático reduzirá seu número para economizar dinheiro. É por isso que o Kubernetes planeja pods baseados em consulta. No entanto, o limite pode ser maior que as solicitações e, em alguns casos, o nó pode realmente ficar sem recursos. Chamamos esse estado de supercomprometimento.

Como eu disse, se estamos falando de um processador, o Kubernetes começará a limitar os pods. Cada pod receberá o máximo que ele solicitou, mas se, ao mesmo tempo, não atingir o limite, a aceleração começará a ser aplicada.

Quanto aos recursos de memória, aqui o Kubernetes é forçado a tomar decisões sobre quais pods excluir e quais manter até liberar recursos do sistema, caso contrário, todo o sistema falhará.

Vamos imaginar um cenário em que você tenha uma máquina com memória insuficiente - como o Kubernetes fará isso?

O Kubernetes procurará pods que usam mais recursos do que o solicitado. Portanto, se seus contêineres não tiverem solicitações, isso significa que, por padrão, eles usam mais do que solicitaram, simplesmente porque não pediram nada! Esses contêineres se tornam os principais candidatos ao desligamento. Os próximos candidatos são contêineres que atenderam a todas as solicitações, mas ainda estão abaixo do limite máximo.

Portanto, se o Kubernetes encontrar vários pods que excederam os parâmetros de suas consultas, ele os classificará por prioridade e excluirá os módulos de menor prioridade. Se todos os módulos tiverem a mesma prioridade, o Kubernetes interromperá os pods que excederem suas solicitações mais do que o restante dos pods.

Em casos muito raros, o Kubernetes pode interromper os lares que ainda estão dentro do seu escopo. Isso pode acontecer quando componentes críticos do sistema, como o agente Kubelet ou o Docker, começam a consumir mais recursos do que lhes era reservado.
Portanto, nos estágios iniciais das pequenas empresas, o cluster Kubernetes pode funcionar bem sem definir solicitações e restrições de recursos, mas à medida que suas equipes e projetos começam a crescer, você corre o risco de encontrar problemas nessa área. Adicionar consultas e restrições aos seus módulos e espaços de nome requer muito pouco esforço extra e pode economizar muito trabalho.

Melhores práticas do Kubernetes. Desativar finalização correta

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

Melhores práticas do Kubernetes. Definindo consultas e limites de recursos

Um pouco de publicidade :)

More articles: