Descrição e configuração da coleta de lixo do Kubernetes

A coleta de lixo é o processo pelo qual o Kubernetes exclui objetos dependentes após excluir um recurso. Ele também lida com a limpeza automática de elementos redundantes em seu cluster. Os contêineres encerrados e as imagens obsoletas são removidos periodicamente para evitar que uma grande quantidade de recursos desnecessários se acumule ao longo do tempo.

Várias estratégias de coleta de lixo podem ser implementadas dependendo do tipo de objeto que está sendo descartado. A coleta de lixo de lixo pode ser configurada configurando o Kubelet nos nós do trabalhador em seu cluster. Neste artigo, explicaremos as diferentes formas de coleta de lixo e como você pode personalizar as configurações de limpeza.

Coleta de lixo básica

A coleta de lixo do Kubernetes lida com a remoção de objetos dependentes, contêineres antigos e imagens não utilizadas. O Kubelet executa operações de limpeza periodicamente enquanto seu serviço está ativo. Ele removerá contêineres parados, como os de trabalhos concluídos, e removerá imagens não utilizadas quando um determinado limite de utilização de disco for atingido.

A coleta de lixo de recursos de cluster em resposta a exclusões de objetos usa um mecanismo em cascata. Isso garante que os filhos de um objeto sejam removidos junto com ele, evitando elementos órfãos. Você pode controlar esse processo solicitando uma ordem em cascata específica ao iniciar a exclusão.

Referências do proprietário

Os relacionamentos pai-filho são expressos usando referências de proprietário do Kubernetes. Os proprietários são responsáveis ​​pelos objetos aninhados dentro deles. Isso cria um gráfico de dependência que informa o processo de coleta de lixo.

O Kubernetes usa dados de referência do proprietário para estabelecer quais recursos devem ser removidos antes que um destino seja removido. Como exemplo, os pods que fazem parte de um ReplicaSet terão uma referência de proprietário que define essa vinculação. A remoção do ReplicaSet também removerá automaticamente os pods dentro dele.

As referências do proprietário são definidas para os objetos em seus metadata.ownerReference campo manifesto. Normalmente, você não precisa inspecionar ou alterar manualmente esse campo, pois os controladores do Kubernetes lidam automaticamente com as referências do proprietário.

As crianças podem bloquear a exclusão de seus pais definindo o metadata.blockOwnerDeletion campo para valor booleano true. Isso impedirá que o pai no objeto ownerReference a corrente é removida até que o objeto seja removido.

Mecanismos de eliminação em cascata

A cadeia de referência do proprietário significa que existem duas maneiras pelas quais as exclusões de objetos podem ser executadas:

• Remoção de fundo: O objeto de destino é excluído primeiro, depois seus dependentes.
• Remoção do primeiro plano: Os dependentes são removidos primeiro, depois o objeto de destino.

Considere um comando delete como o seguinte:

$ kubectl delete deployment/demo-app

O método de remoção de plano de fundo removerá imediatamente o demo-app Objeto de implantação. Isso deixará seus pods em execução no cluster. Eles serão limpos automaticamente em segundo plano como parte do processo de coleta de lixo.

A remoção do primeiro plano começa verificando a demo-app Implementação como uma “remoção em andamento”. Em seguida, ele remove todos os objetos dependentes que existem dentro dele. a demo-app A implantação permanecerá visível em seu cluster até que seus pods sejam removidos. A implantação será desmarcada assim que os dependentes saírem.

A cascata em segundo plano é o mecanismo padrão. Ele oferece um resultado imediato que remove o objeto de destino do seu cluster sem demora. No entanto, a exclusão de primeiro plano pode ser mais desejável em alguns cenários, como quando você deseja que uma implantação ou conjunto de réplicas seja excluído somente depois que seus pods forem destruídos. Isso evita o breve período em que os pods ficam efetivamente órfãos e seu proprietário, o ReplicaSet, desaparece.

Você pode optar pela exclusão do primeiro plano passando o --cascade=foreground bandeira para o kubectl delete domínio:

$ kubectl delete deployment/demo-app --cascade=foreground

Os Pods serão removidos, então o demo-app implantação.

Desabilitar coleta de lixo dependente

Existe uma terceira opção em cascata: ignore completamente a coleta de lixo dependente. Isso deixará os dependentes do objeto órfãos, deixando-os em seu cluster, mas com a referência de proprietário removida.

$ kubectl delete deployment/demo-app --cascade=orphan

Este comando remove imediatamente o demo-app Implante, mas deixe seus pods intactos. Eles continuarão sendo executados em seu cluster até que sejam removidos separadamente, como parte de outro comando. Embora esse comportamento raramente seja desejável, pode ser útil se você decidir que seus pods não precisam mais estar em um Deployment ou ReplicaSet.

Coleta de lixo e finalizadores

Os finalizadores também afetam o funcionamento da coleta de lixo. Eles impedem a ocorrência de exclusões até que certas condições sejam atendidas.

Muitas exclusões aparentemente “presas” são causadas por finalizadores pendentes. Um finalizador que não esteja marcado como concluído impedirá que o objeto seja removido do cluster. Depois que o trailer for removido, o plano de controle do Kubernetes prosseguirá com a remoção.

Alguns finalizadores estão incluídos no Kubernetes, como o pv-protection proteção contra exclusão de volumes usados ​​ativamente. Outros podem ser adicionados por controladores de terceiros que você adiciona ao seu cluster. A substituição de um finalizador não é recomendada, pois pode criar um estado incorreto que causa um comportamento inesperado.

Coleta de lixo Personalização de recursos não utilizados

A coleta de lixo de contêineres e imagens redundantes ocorre automaticamente nos nós do trabalhador. Há cinco parâmetros disponíveis para ajustar os limites de remoção:

• maximum-dead-containers – O número máximo de contêineres antigos que podem continuar existindo após a execução da coleta de lixo. o valor padrão de -1 remover o limite.
• maximum-dead-containers-per-container – Defina o número máximo de contêineres antigos retidos por contêiner. Isso controla quantas versões anteriores de um contêiner permanecem no cluster, após o início de uma nova substituição.
• minimum-container-ttl-duration – As lixeiras se tornam elegíveis para coleta de lixo alguns minutos depois de paradas. O valor padrão de 0 desabilitar atraso.
• image-gc-high-threshold – Quando o uso do disco atingir essa porcentagem, o Kubelet tentará remover as imagens não utilizadas…
• image-gc-low-threshold -… para diminuir o uso a este nível.

Esses parâmetros são definidos como sinalizadores de inicialização do Kubelet. As bandeiras são normalmente colocadas em /var/lib/kubelet/kubeadm-flags.env:

KUBELET_KUBEADM_ARGS="--image-gc-high-threshold=60 --image-gc-low-threshold=50 --minimum-container-ttl-duration=5"

Essa configuração permitirá a exclusão automática de contêineres redundantes por pelo menos cinco minutos. Cada passagem de coleta de lixo também tentará excluir imagens antigas assim que 60% do uso do disco for atingido, com o objetivo de reduzir o consumo para 50%.

Você deve reiniciar o processo do Kubelet depois de fazer estas alterações:

$ sudo systemctl daemon-reload
$ sudo systemctl restart kubelet

Como a configuração faz parte do Kubelet, você precisará aplicá-la a cada um de seus nós do trabalhador em seu cluster se desejar que a configuração seja consistente em todos eles.

Resumo

Compreender as diferentes formas de coleta de lixo do Kubernetes ajuda você a decidir sobre a estratégia certa ao remover objetos do seu cluster. As cascatas de segundo plano e primeiro plano afetam a ordem em que os recursos dependentes são limpos. Os relacionamentos entre objetos são identificados por suas strings de referência do proprietário. O Kubernetes também limpa contêineres e imagens não utilizados em segundo plano. Os limites para esse comportamento podem ser personalizados por meio da configuração do Kubelet.

Para obter melhores resultados, você deve seguir os mecanismos fornecidos pelo Kubernetes. O projeto adverte contra o uso de ferramentas de coleta de lixo de terceiros, pois elas podem criar inconsistências de estado que causam problemas para seu cluster.