Kubernetes: dicas e truques na orquestração de containers - Parte 2

Neste novo artigo retomo a série com dicas e truques envolvendo a orquestração de containers com Kubernetes.

A seguir está o link do primeiro post que publiquei, caso não tenha consultado o mesmo ou deseje revê-lo:

Kubernetes: dicas e truques na orquestração de containers - Parte 1

Kubernetes Dashboard: gerenciando um cluster via interface Web

Muito do trabalho envolvendo o gerenciamento de um cluster Kubernetes está associado ao uso do kubectl, que nada mais é do que um utilitário de linha de comando multiplataforma (compatível com Windows, Linux e macOS). Contudo, dispomos de uma outra opção que possui inclusive com recursos de monitoramento: trata-se do Kubernetes Dashboard.

Na imagem a seguir podemos observar a tela inicial do Kubernetes Dashboard, incluindo o status de diversos workloads em um cluster (Deployments, Pods, Replica Sets):

Ao utilizar o Azure Kubernetes Service (AKS) precisamos liberar o acesso ao Dashboard através da seguinte instrução:

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Já para acessar o Dashboard executar o seguinte comando (empregando o Azure CLI - az, utilitário de linha de comando do Microsoft Azure). Essa instrução fará com que se abra no browser default o Kubernetes Dashboard, considerando para isto o grupo de recursos (parâmetro -g) e o nome do recurso do AKS (parâmetro -n):

az aks browse -g TesteKubernetes -n ContagemService

Utilizando variáveis de ambiente

Ao criar containers Docker é prática comum o uso do parâmetro -e para o preenchimento de variáveis de ambiente. Ao especificar o valor de uma estrutura deste tipo estamos, por sua vez, fornecendo diretrizes que determinarão como ocorrerá a execução de um container.

E como realizar o mesmo tipo de ajuste se nossos containers estarão num cluster Kubernetes?

Isto pode ser conseguindo na declaração de um container através da utilização do elemento env, em conjunto com os parâmetros name e value (esse par de informações pode estar presente múltiplas vezes, correspondendo a diferentes itens de configuração). É o que demonstra o exemplo a seguir, com as configurações de um objeto Deployment e seus Pods empregando uma imagem de uma API REST:

O resultado ao configurar a variável TesteAmbiente pode ser observado na próxima imagem:

Criando Secrets com --from-literal

O Kubernetes também conta com objetos conhecidos como Secrets para o armazenamento de informações sensíveis como tokens, strings de conexão e outros valores de configuração.

Na listagem a seguir temos a criação de um Secret chamado blog-groffe, utilizando o parâmetro --from-literal (especificando um valor para a configuração VlTesteAmbiente) em conjunto com o utilitário kubectl:

kubectl create secret generic blog-groffe --from-literal=VlTesteAmbiente='Teste utilizando secret from-literal no Kubernetes'

Já o comando:

kubectl describe secret blog-groffe

Trará os informações sobre o Secret que geramos com o comando anterior. Podemos utilizar --from-literal múltiplas vezes durante a criação de um segredo, definindo assim valores para diferentes itens de configuração:

Retomando o exemplo da API REST da seção anterior, como poderíamos então vincular o valor de VlTesteAmbiente à variável de ambiente TesteAmbiente?

As alterações acontecerão no arquivo YAML do objeto Deployment. Dentro de env ao invés de value será utilizado o elemento valueFrom e, em seguida, secretKeyRef; em name indicar o nome do Secret (blog-groffe), ao passo que key irá referenciar a chave VlTesteAmbiente:

Um teste de acesso à API REST retonará agora o valor associado ao Secret aqui detalhado:

Referências

Docker - Guia de Referência Gratuito

Azure Kubernetes Service (AKS)