Verificando recursos com API Deprecadas em Cluster Kubernetes com Kubent

Sabemos que o Kubernetes recebe um novo update aproximadamente a cada quatro meses, normalmente temos três novas atualizações por ano. Com cada nova versão, várias APIs são promovidas de suas versões beta para estáveis, enquanto outras são removidas (isso é comum em qualquer software), essa que são removidas se tornam deprecadas dependendo da atualização elas nem funcionam mais, não ficam com o warn de aviso. Irei apresentar um pouco sobre o Kubent, mas antes vamos passar por uns pontos…

É crucial manter nossos clusters atualizados com as versões mais recentes do Kubernetes para correção de bugs e falhas de segurança. No entanto o processo de atualização em clusters Kubernetes, especialmente em clusters de produção, podem não ser uma tarefa simples.

Em muitos cenários é importantes termos ambientes idênticos de Desenvolvimento e Produção, justamente para realização de testes rigorosos e também upgrades de versões, uma vez que todos os requisitos sejam cumpridos, podemos avançar para a próxima versão do cluster.

Neste processo de levantamento de requisitos para upgrades em ambientes de Kubernetes e de suas aplicações, pode ser necessário examinar a documentação do Kubernetes e descobrir as API que estão para ser depreciadas e removidas.

Podemos ver por aqui (Deprecated API Migration Guide | Kubernetes) as alterações em API do Kubernetes em cada atualização.

Imagina um cluster com mais de 500 aplicações implementadas em diversos Namespaces, pode ser um trabalho tedioso verificar cada resource utilizado nas aplicações e descobrir quais APIs podem apresentar problemas.

Em uma demanda recentemente, passei por este desafio, e conseguir de uma maneira muito simples de detectar esses recursos que estavam utilizando API deprecadas para a próxima versão do Kubernetes. Em uma breve pesquisa, encontrei o git do projeto kube-no-trouble (em português algo como Kube-sem-problemas), também conhecido como Kubent. Esta ferramenta é utilizada para verificar se você está usando alguma das versões de API que serão removidas na versão atualizada do seu cluster, sem necessidade de instalar nada no seu cluster, podemos utilizar uma conexão com um kubeconfig file.

Laboratório utilizado nesta Doc:

• Cluster AKS v1.23
• Master e Nodes Utilizando Ubuntu 18.04
• Kubent 0.7.1​

Podemos notar que temos te temos disponível neste laboratório upgrade de versão para o Cluster na Azure.

Hands-on:

Criei um yaml para vermos o funcionamento com um projeto de Nginx e um HPA configurado utilizando a api “autoscaling/v2beta1”, atualmente esta api está deprecada e é utilizada “autoscaling/v2”.

1. Para realizar o deploy utilize o comando abaixo.

kubectl apply -f https://raw.githubusercontent.com/bernardolankheet/devops-series-docs/main/kubernetes/tools/kubent/nginx-hpa-deprecated.yaml

Verá uma saída igual a esta:

2) Realize o processo de instalação do kubent:

sh -c "$(curl -sSL https://git.io/install-kubent)"

Obs: Podemos instalar utilizando o Brew

brew install kubent

3) Executando o Kubent

Executar o kubent é bem facil, basta chama-lo no terminal utilizando “kubent”, ele irá conectar ao cluster via kubeconfig e realizar um scanner em todos os namespaces que possui acesso ao cluster.

Na sua saída, será possível verificar a versão do kubent, versão do cluster e por fim uma lista de APIs que serão deprecadas em relação a atual versão do kubernetes disponível.

Podemos notar que nossa aplicação é a primeira a ser mostrada e o autoscaling/v2beta1 está ali listado.

É possível também analisar apenas um arquivo yaml e ignorar o que está atualmente no cluster, utilizando o parâmetro ‘ — file’ e ‘ — cluster=false’

Podemos ver todas as opções disponíveis para utilizar o kubent executando com o parâmetro -h.

A partir deste ponto basta corrigir suas aplicações que estão utilizando as APIs relatadas pelo kubent.

Esta foi uma ferramenta que me apoiou bastante em um projeto, ajudando a identificar possíveis desafios e economizando esforços no momento de upgrade.

Ate a próxima!