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ó livres necessários para executar um contêiner ou pod, o segundo limita estritamente os recursos disponíveis para o contêiner.
Quando o Kubernetes agenda pods, é muito importante que os contêineres tenham recursos suficientes para funcionar corretamente. Se você estiver planejando implantar um aplicativo grande em um nó com recursos limitados, é possível que ele não seja executado porque o nó está com pouca memória ou sem energia da CPU. Neste artigo, veremos como você pode resolver a escassez de energia computacional usando solicitações e limites de recursos.
Solicitações e Limites são mecanismos que o Kubernetes usa para gerenciar recursos como CPU e memória. As solicitações garantem que o contêiner receba o recurso solicitado. Se um contêiner solicitar um recurso, o Kubernetes apenas o agendará em um nó que possa fornecê-lo. Os limites controlam que os recursos solicitados pelo contêiner nunca excederão um determinado valor.
Um contêiner só pode aumentar seu poder computacional até um certo limite, após o qual será limitado. Vamos ver como isso funciona. Portanto, existem dois tipos de recursos – processador e memória. O agendador do Kubernetes usa dados sobre esses recursos para descobrir onde executar seus pods. Uma especificação de recurso típica para um pod é semelhante a esta.
Cada contêiner em um pod pode definir suas próprias consultas e limites, tudo isso é aditivo. Os recursos do processador são definidos em miliccores. Se o seu contêiner precisar de dois núcleos completos para funcionar, defina o valor como 2000 m. Caso o container necessite apenas da potência de 1/4 do núcleo, o valor será de 250m. Tenha em mente que se você atribuir um valor de recurso de CPU maior que o número de núcleos do maior nó, seu pod não será programado para iniciar. Uma situação semelhante ocorrerá se você tiver um pod que precise de quatro núcleos e o cluster Kubernetes consistir em apenas duas máquinas virtuais principais.
A menos que seu aplicativo seja projetado especificamente para aproveitar vários núcleos (programas como computação científica complexa e operações de banco de dados vêm à mente), a prática recomendada é definir solicitações de CPU como 1 ou menos e, em seguida, executar mais réplicas para escalabilidade. Esta solução dará ao sistema maior flexibilidade e confiabilidade.
Quando se trata de limitações de CPU, as coisas ficam mais interessantes por ser considerado um recurso compressível. Se seu aplicativo começar a se aproximar do limite de potência do processador, o Kubernetes começará a desacelerar seu contêiner usando CPU Throttling - reduzindo a frequência do processador. Isso significa que a CPU será acelerada artificialmente, proporcionando ao aplicativo um desempenho potencialmente pior, mas o processo não será encerrado ou retirado.
Os recursos de memória são definidos em bytes. Normalmente o valor nas configurações é medido em mebibytes Mib, mas você pode definir qualquer valor, de bytes a petabytes. A mesma situação se aplica aqui à CPU - se você fizer uma solicitação para uma quantidade de memória maior que a quantidade de memória em seus nós, esse pod não será agendado para execução. Mas, diferentemente dos recursos da CPU, 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 a memória alocada para ele.
É importante lembrar que não é possível configurar solicitações que excedam os recursos que seus nós podem fornecer. As especificações de recursos compartilhados para máquinas virtuais do GKE podem ser encontradas nos links abaixo deste vídeo.
Num mundo ideal, as configurações padrão do contêiner seriam suficientes para manter os fluxos de trabalho funcionando perfeitamente. Mas o mundo real não é assim, as pessoas podem facilmente esquecer de configurar o uso dos recursos, ou os hackers definirão solicitações e restrições que excedem as capacidades reais da infraestrutura. Para evitar que tais cenários ocorram, você pode configurar cotas de recursos ResourceQuota e LimitRange.
Depois que um namespace for criado, ele poderá ser bloqueado usando cotas. Por exemplo, se você tiver os namespaces prod e dev, o padrão é que não há cotas de produção e sim cotas de desenvolvimento muito rígidas. Isso permite que o prod, no caso de um aumento acentuado no tráfego, assuma todo o recurso disponível, bloqueando completamente o dev.
A cota de recursos pode ser assim. Neste exemplo existem 4 seções - estas são as 4 linhas inferiores do código.
Vejamos cada um deles. Requests.cpu é o número máximo de solicitações de CPU combinadas que podem vir de todos os contêineres no namespace. Neste exemplo, você poderia ter 50 contêineres com solicitações de 10 milhões, cinco contêineres com solicitações de 100 milhões ou apenas um contêiner com solicitações de 500 milhões. Contanto que o número total de requests.cpu de um determinado namespace seja inferior a 500 milhões, tudo ficará bem.
Solicitações solicitadas de memória. memória é a quantidade máxima de solicitações de memória combinadas que todos os contêineres no namespace podem ter. Como no caso anterior, você pode ter 50 contêineres de 2 mib, cinco contêineres de 20 mib ou um único contêiner de 100 mib, desde que a quantidade total de memória solicitada no namespace seja inferior a 100 mebibytes.
Limits.cpu é a quantidade máxima combinada de potência da CPU que todos os contêineres no namespace podem usar. Podemos considerar que este é o limite das solicitações de energia do processador.
Finalmente, limit.memory é a quantidade máxima de memória compartilhada que todos os contêineres no namespace podem usar. Este é um limite no total de solicitações de memória.
Portanto, por padrão, os contêineres em um cluster Kubernetes são executados com recursos computacionais ilimitados. Com cotas de recursos, os administradores de cluster podem limitar o consumo e a criação de recursos com base no namespace. Em um namespace, um pod ou contêiner pode consumir tanta energia de CPU e memória quanto determinado pela cota de recursos do namespace. No entanto, existe a preocupação de que um recipiente ou cápsula possa monopolizar todos os recursos disponíveis. Para evitar esta situação, é utilizado um intervalo limite - uma política para limitar a alocação de recursos (para pods ou contêineres) no namespace.
A faixa limite fornece restrições que podem:
- Garantir o uso mínimo e máximo dos recursos computacionais para cada módulo ou contêiner do namespace;
- impor solicitações de armazenamento mínimas e máximas de Starage Request para cada PersistentVolumeClaim no namespace;
- impor um relacionamento entre uma solicitação e um limite para um recurso em um namespace;
- defina solicitações/limites padrão para recursos de computação no namespace e injete-os automaticamente em contêineres em tempo de execução.
Dessa forma, você pode criar um intervalo limite em seu namespace. Ao contrário de uma cota, que se aplica a todo o namespace, o Limit Range é usado para contêineres individuais. Isso pode impedir que os usuários criem contêineres muito pequenos ou, inversamente, gigantescos dentro do namespace. O intervalo limite pode ser assim.
Como no caso anterior, aqui podem ser distinguidas 4 seções. Vejamos cada um.
A seção padrão define os limites padrão para o contêiner no pod. Se você definir esses valores para o intervalo extremo, todos os contêineres para os quais esses valores não foram definidos explicitamente seguirão os valores padrão.
A seção de solicitação padrão defaultRequest configura as solicitações padrão para o contêiner no pod. Novamente, se você definir esses valores para o intervalo extremo, todos os contêineres que não definirem explicitamente essas opções terão esses valores como padrão.
A seção max especifica os limites máximos que podem ser definidos para um contêiner no pod. Os valores na seção padrão e nos limites do contêiner não podem ser definidos acima desse limite. É importante observar que se o valor for definido como máximo e não houver seção padrão, o valor máximo se tornará o valor padrão.
A seção min especifica as solicitações mínimas que podem ser definidas para um contêiner em um pod. No entanto, os valores na seção padrão e nas consultas do contêiner não podem ser definidos abaixo desse limite.
Novamente, é importante observar que se esse valor for definido, o padrão não for, então o valor mínimo se tornará o prompt padrão.
Essas solicitações de recursos são usadas, em última análise, pelo agendador do Kubernetes para executar suas cargas de trabalho. Para que você configure seus containers corretamente, é muito importante entender como funciona. Digamos que você queira executar vários pods em seu cluster. Supondo que as especificações do pod sejam válidas, o cronograma do Kubernetes usará o balanceamento round robin para selecionar um nó para executar a carga de trabalho.
O Kubernetes verificará se o Nó 1 possui recursos suficientes para atender às solicitações dos contêineres de pod e, caso contrário, passará para o próximo nó. Se nenhum dos nós do sistema for capaz de atender às solicitações, os pods entrarão no estado Pendente. Usando recursos do Google Kubernetes Engine, como escalonamento automático de nós, o GKE pode detectar automaticamente o estado de espera e criar vários outros nós adicionais.
Se posteriormente você ficar sem capacidade de nó, o escalonamento automático reduzirá o número de nós para economizar dinheiro. É por isso que o Kubernetes agenda pods com base em solicitações. No entanto, o limite pode ser superior às solicitações e, em alguns casos, o nó pode ficar sem recursos. Chamamos esse estado de estado de supercomprometimento.
Como eu disse, quando se trata de CPU, o Kubernetes vai começar a limitar os pods. Cada pod receberá o valor solicitado, mas se não atingir o limite, a limitação começará a ser aplicada.
Quando se trata de recursos de memória, o Kubernetes é forçado a tomar decisões sobre quais pods excluir e quais manter até que você libere recursos do sistema ou todo o sistema trave.
Vamos imaginar um cenário em que você tenha uma máquina sem memória. Como o Kubernetes lidaria com isso?
O Kubernetes procurará pods que estejam usando mais recursos do que solicitaram. Portanto, se seus contêineres não tiverem nenhuma solicitação, isso significa que eles estão usando mais do que pediram, simplesmente porque não pediram nada! Esses contêineres tornam-se os principais candidatos ao fechamento. Os próximos candidatos são contêineres que atenderam a todas as suas solicitações, mas ainda estão abaixo do limite máximo.
Portanto, se o Kubernetes encontrar vários pods que excederam seus parâmetros de solicitação, ele os classificará por prioridade e, em seguida, removerá os pods de prioridade mais baixa. Se todos os pods tiverem a mesma prioridade, o Kubernetes encerrará os pods que excederem suas solicitações mais do que outros pods.
Em casos muito raros, o Kubernetes pode abortar pods que ainda estão dentro do escopo de suas solicitações. Isso pode acontecer quando componentes críticos do sistema, como o agente Kubelet ou Docker, começam a consumir mais recursos do que o que foi reservado para eles.
Portanto, nos estágios iniciais de pequenas empresas, um 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 em tamanho, você corre o risco de ter problemas nessa área. Adicionar consultas e restrições aos seus módulos e namespaces requer muito pouco esforço extra e pode evitar muitos problemas.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com