Orquestração de containers na Nuvem com o Azure Kubernetes Service (AKS)


Inúmeras são as vantagens obtidas ao empregar containers Docker em projetos de software. Isolamento de aplicações, uma utilização mais racional de recursos computacionais, velocidade no deployment e uma menor dependência em relação aos ambientes operacionais estão entre os fatores que contribuem para o crescimento no uso dessa tecnologia.

Por mais que as vantagens trazidas pelo Docker sejam inegáveis, existem também dificuldades decorrentes de sua adoção:

  • Como escalar containers?
  • Como garantir o trabalho coordenado entre os diferentes containers de uma aplicação?
  • Como detectar containers com falhas e corrigir isso automaticamente?

As respostas a tais questões estão em soluções voltadas ao gerenciamento e uso orquestrado de containers Docker. Entre as alternativas mais populares nesse segmento, tem-se o Kubernetes, um projeto open source hoje considerado padrão no mercado para a orquestração de containers.

O próprio Microsoft Azure não ficou alheio a esse tipo de demanda, contando com uma opção voltada ao uso de Kubernetes na Nuvem: trata-se do Azure Kubernetes Service (AKS), solução que visa simplificar o gerenciamento e a operação de ambientes baseados nesse orquestrador.

Este artigo é um tutorial no qual abordarei a utilização combinada do Microsoft Azure e do Kubernetes (por meio do serviço AKS) para a implementação de projetos que dependam da orquestração de containers.

 

Kubernetes: uma visão geral

Também conhecido como K8s ou kube, o Kubernetes é um projeto open source escrito na linguagem Go e desenvolvido originalmente pela Google. Mantido atualmente pela Cloud Native Computing Foundation, o Kubernetes conta com recursos de gerenciamento que viabilizam a orquestração, a autorrecuperação, o reinício, a replicação e o escalonamento de containers Docker.

Assim como acontece com outras tecnologias populares na atualidade, o Kubernetes tem também uma ferramenta de linha de comando: o kubectl, utilitário que permite a execução de instruções voltadas ao gerenciamento de clusters e containers.

As diferentes estruturas controladas via Kubernetes serão criadas a partir de arquivos no formato YAML e por meio da execução de comandos via kubectl. Um ambiente para testes pode ser disponibilizado com a instalação do Minikube (software que possibilita a criação de um cluster local para uso do Kubernetes).

Dentro da arquitetura adotada pelo Kubernetes merecem destaque os seguintes elementos:

  • Master;
  • Nodes;
  • Pod;
  • Deployment;
  • Service;
  • Replication Controller;
  • Kubelet.

Um cluster no Kubernetes está dividido em:

  • Master, máquina que controla e tem por responsabilidade a atribuição de tarefas aos diferentes Nodes;
  • Nodes (nós), uma ou mais máquinas que realizam as tarefas atribuídas pelo Master.

Já um Pod é uma estrutura que agrupa um ou mais containers. A implantação desse elemento (Pod) acontece em algum dos Nodes disponíveis. A figura a seguir traz a representação esquemática de um Pod:

Um objeto Deployment é uma abstração de um Pod, contando ainda com recursos adicionais:

  • Essa estrutura está associada a um mecanismo de gerenciamento de estados controlado pelo Kubernetes, o qual permitirá a recuperação automática de um objeto deste tipo (Deployment) quando ele se encontrar em um estado de falha;
  • Ao se falar da criação de um Pod, do ponto de vista prático, na verdade, está se definindo a geração de um novo objeto do tipo Deployment.

Na próxima imagem, tem-se a representação de um objeto Deployment:

Um objeto do tipo Service é uma estrutura que funciona como um Load Balancer, cuidando, assim, do acesso aos diferentes Pods de uma aplicação. Trata-se de um elemento mais estável, até porque Pods são criados ou removidos continuamente ao se escalar uma aplicação.

Dentro da arquitetura do Kubernetes, o elemento conhecido como Replication Controller determinará quantas cópias idênticas de um Pod serão executadas e em quais locais (Nodes) do cluster. Já o Kubelet é o serviço que garante a inicialização e execução dos containers nos diferentes Nodes.

A imagem a seguir traz mais uma representação do Kubernetes, com Pods distribuídos entre os diferentes Nodes de um cluster:

 

Detalhes sobre a aplicação de testes

Para os testes envolvendo o uso do Kubernetes, a partir do Microsoft Azure, será empregada uma API REST baseada no ASP.NET Core 2.2. Essa aplicação produzirá como retorno a quantidade de acessos a API, além de exibir o nome do host/máquina e o kernel do sistema operacional utilizado pelo container Docker. A API em questão foi disponibilizada como uma imagem Linux no Docker Hub, tendo por nome renatogroffe/apicontagem-sdk-2-2:

Os fontes deste projeto, bem como os arquivos YAML correspondentes aos objetos, também estão no GitHub:

https://github.com/renatogroffe/ASPNETCore2.2_Kubernetes/

 

Criando um cluster no Azure Kubernetes Service (AKS)

Para a criação do cluster que servirá de base para testes com o Azure Kubernetes Service (AKS), será necessário instalar o Azure Command Line Interface (CLI). Os testes descritos neste artigo foram realizados a partir de uma máquina virtual com o Ubuntu Desktop 18.04 instalado (seria possível repetir tais testes sem dificuldades em Windows e Mac também).

O Azure CLI é um utilitário de linha de comando para gerenciamento e administração de recursos do Microsoft Azure. Multiplataforma, há a possibilidade de uso dessa ferramenta em ambientes Windows, Linux e macOS. Informações sobre como instalar o Azure CLI podem ser encontradas no seguinte link:

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

Com a instrução az login, será efetuado o login a uma conta do Azure para permitir a interação com a nuvem via Bash (também é possível por meio do PowerShell), com esse procedimento envolvendo a abertura de uma janela no browser e o fornecimento das credenciais de acesso.

A instrução a seguir utiliza o Azure CLI para registrar o provider, que permitirá a criação e o gerenciamento de recursos do AKS via linha de comando:

az provider register -n Microsoft.ContainerService

Um grupo de recursos chamado TesteKubernetes deverá ser criado, com ele estando vinculado à região Leste dos EUA (East US):

az group create –name TesteKubernetes –location eastus

Já o próximo comando gerará um novo recurso do AKS (ContagemService) com um cluster contando com dois nodes, sendo que estará vinculado ao grupo TesteKubernetes:

az aks create –resource-group TesteKubernetes –name ContagemService –node-count 2 –generate-ssh-keys

Concluída essa primeira sequência de tarefas, será possível notar a existência de dois novos grupos de recursos no portal do Azure: TesteKubernetes e MC_TesteKubernetes_ContagemService_eastus:

O recurso ContagemService aparecerá dentro do grupo TesteKubernetes:

Ao acessar este recurso (ContagemService), o status dele constará como Succeeded (o que indica sucesso em sua criação); na seção Node pools, está especificado o número de Nodes (dois, em NODE COUNT) e o uso de Linux em tais nós (OS TYPE):

 

No caso do grupo MC_TesteKubernetes_ContagemService_eastus, serão criados aqui todos os recursos relacionados à infraestrutura alocada para o cluster do Kubernetes na Nuvem Microsoft:

Deployment no Kubernetes

Para a criação de objetos no cluster, será empregado o kubectl, utilitário de linha de comando para o gerenciamento de recursos do Kubernetes. O link a seguir contém instruções para a instalação dessa ferramenta:

https://kubernetes.io/docs/tasks/tools/install-kubectl/

No próximo comando, o Azure CLI será utilizado com o intuito de liberar o acesso do kubectl ao cluster do AKS:

az aks get-credentials –resource-group TesteKubernetes –name ContagemService –overwrite-existing

As definições do objeto Deployment que será criado ficarão em um arquivo YAML (contagem.yaml0), cujo conteúdo foi disponibilizado na listagem seguinte:

  • A propriedade réplicas foi preenchida com o valor 5, indicando a criação de 5 Pods em um primeiro momento;
  • Foram indicados ainda o uso da porta 80 (propriedade containerPort) e da imagem renatogroffe/apicontagem-sdk-2-2 (propriedade image).
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: contagem-deployment
spec:
  replicas: 5
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: contagem
    spec:
      containers:
      - name: contagem
        image: renatogroffe/apicontagem-sdk-2-2
        ports:
        - containerPort: 80

 

Executar via Bash o comando kubectl create -f contagem.yaml procederá com a criação do objeto Deployment e dos Pods/réplicas especificados.

Concluído esse procedimento, deve-se executar no Bash as instruções:

kubectl get deployment, que retornará informações sobre o objeto Deployment;

kubectl get pods, que exibirá os cinco Pods por meio dos quais a API REST de testes está sendo executada.

Já o objeto Service funcionará como um Load Balancer, disponibilizando um endereço de IP para acesso à aplicação e distribuindo o processamento entre os diferentes Pods que vierem a existir para . A listagem a seguir (arquivo service.yaml) contém as definições necessárias para a geração desta estrutura:

apiVersion: v1
kind: Service
metadata:
  name: contagem-service
  labels:
    version: test
spec:
  selector:
    app: contagem
  ports:
  - port: 80
  type: LoadBalancer

 

Ao executar a instrução kubectl create -f service.yaml via Bash, será criado, então, esse novo recurso. Já o comando kubectl get services indicará que o Load Balancer foi criado corretamente, com o IP (EXTERNAL-IP) de acesso à aplicação destacado em vermelho:

Essas mesmas instruções para consulta ao Deployment, Pods e Load Balancer podem ser acionadas via PowerShell em um ambiente Windows (desde que executados previamente os comandos az login e az aks get-credentials):

 

Testando a aplicação publicada no Kubernetes

Testes no Bash com a instrução curl http://40.76.90.74/api/contador w “\n” mostrarão que a cada requisição pode ser direcionado um Pod diferente (entre as cinco réplicas criadas); o nome de um Pod está representado no retorno JSON pela propriedade machineName:

Acessando via browser em outra máquina este mesmo endereço (baseado no IP externo associado ao Load Balancer), têm-se resultados similares aos seguintes:

 

 

Testando o mecanismo de autorrecuperação do Kubernetes

Com o comando kubectl delete pod <NOME DO POD>, pode-se excluir um dos Pods existentes, a fim de testar o mecanismo de autorrecuperação do Kubernetes.

Em poucos segundos, uma checagem via instruções kubectl get deployment e kubectl get pods mostrará que um novo Pod foi criado, de forma a atender a quantidade de réplicas especificada no objeto Deployment:

Escalando a aplicação via linha de comando

O kubectl será empregado agora para escalar a aplicação via linha de comando, com a instrução a seguir definindo o uso de 20 Pods para processamento das solicitações enviadas à aplicação de testes:

kubectl scale deployment contagem-deployment –replicas=20

Com a execução dos comandos kubectl get deployment e kubectl get pods, serão exibidos agora 20 Pods (contemplando os cinco já existentes + 15 novos):

Utilizando o Kubernetes Dashboard

O Kubernetes conta também com uma aplicação Web/dashboard para monitoramento e gerenciamento de um cluster. Com essa funcionalidade, é possível monitorar o estado de um cluster e seus diferentes objetos, bem como executar, a partir de uma interface gráfica, diversas tarefas equivalentes ao uso do kubectl via linha de comando.

A instrução a seguir permitirá que se libere o acesso ao Dashboard do Kubernetes:

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

Já o próximo comando (referenciando o recurso do AKS e seu grupo correspondente) carregará o Kubernetes Dashboard:

 

Referências

Azure Container Service (AKS). Disponível em:

https://azure.microsoft.com/en-us/services/kubernetes-service/

Kubernetes - Site Oficial. Disponível em:
https://kubernetes.io/


Autor:

Consultor em atividades voltadas ao desenvolvimento de sistemas há mais de 15 anos. Microsoft MVP (Most Valuable Professional) e participante do programa MTAC (Multi-Plataform Technical Audience Contributor). Bacharel em Sistemas de Informação, com Especialização em Engenharia de Software e MBA em Business Intelligence. Também é palestrante e autor técnico em portais e revistas especializadas, com foco em tecnologias Microsoft e boas práticas na área de software.