Skupper: fazendo o deploy de aplicações Multicloud

Simulando ambiente Multicloud - Apresentação

Boas-vindas ao curso de Skupper. Meu nome é Rafael Zago.

Audiodescrição: Rafael é uma pessoa branca. Tem olhos castanhos e cabeça raspada. Possui barba escura com fios grisalhos. Está sentado em seu escritório. Ao fundo, há alguma estante com livros de ficção científica e quadros de filmes.

Para quem é este conteúdo?

Este curso é destinado a quem trabalha com deploy de aplicações em nuvem, pessoas desenvolvedoras multicloud ou cloud, que desejam realizar o deploy de uma aplicação distribuída de maneira segura.

Assim, você poderá criar uma aplicação capaz de operar em ambientes que não estão fisicamente conectados, como datacenters em regiões diferentes - ou até conectar uma aplicação legada ao seu cluster Kubernetes.

O que vamos aprender?

Nesta solução que vamos explorar, há alguns aspectos interessantes que devemos conhecer.

Primeiramente, vamos conhecer a aplicação distribuída com a qual vamos trabalhar. A aplicação básica terá três namespaces, os quais possuem diferentes aplicações em execução. Vamos realizar o deploy dessas aplicações em cada um dos namespaces, que simularão datacenters distintos.

Com essas aplicações implantadas, utilizaremos o Skupper para estabelecer a comunicação nativa entre elas de maneira quase nada invasiva. Além disso, conectaremos uma aplicação legada, que não opera no Kubernetes, dentro de um cluster Kubernetes de forma simples e ágil.

No nosso projeto, utilizaremos o Minikube para simular nosso ambiente multicloud. O Minikube terá namespaces para cada parte da nossa solução. Dessa maneira, os namespaces estarão isolados em comunicação. A comunicação entre eles será realizada através do Skupper.

Vamos introduzir um conceito em nossa solução chamada VAN (Virtual Application Network). Dessa forma, seremos capazes de entregar soluções distribuídas e outras geograficamente distintas.

O que já precisamos saber?

Para aproveitar este curso, é interessante ter algumas noções sobre aplicações em nuvem (cloud-ready) e Kubernetes. Embora forneçamos todos os comandos necessários, é útil ter uma compreensão básica do que é o Kubernetes, além de familiaridade com Linux e ferramentas de linha de comando.

Não deixe de aproveitar outros recursos da nossa plataforma, como o fórum para tirar dúvidas e o Discord da Alura para interagir. Vamos estudar?

Simulando ambiente Multicloud - Trabalhando com múltiplos namespaces

Vamos começar entendendo o problema que precisamos resolver. Para isso, é essencial contextualizar a solução que vamos entregar.

Trabalhando com múltiplos namespaces

Vamos apresentar uma imagem retirada do site do Skupper para ilustrar melhor o conceito:

Pensemos em uma aplicação básica, composta por um front-end e um back-end. O back-end segue o padrão REST e é acessado pelo front-end.

Em uma implementação tradicional no Kubernetes, a aplicação é entregue por meio do acesso de pod front-end a um serviço dentro do namespace chamado back-end, utilizando a porta 8080. A aplicação funciona a partir dessa comunicação.

Agora, consideremos cenários mais complexos: um ambiente multicloud, onde não dependemos de um único cloud provider; um único cloud provider em diferentes regiões geográficas; ou um único datacenter, mas com necessidade de segregação entre as aplicações de front-end e back-end.

Dessa forma, o desafio central é:

Como garantir que o front-end continue acessando o serviço do back-end de forma transparente?

Nesse contexto, "transparente" significa que o front-end continuará chamando o serviço Kubernetes como se estivesse no mesmo namespace, e o back-end continuará respondendo às chamadas como se fossem serviços chamados através de aplicações dentro do mesmo namespace.

Existem diferentes abordagens para resolver esse problema. Pensando em datacenters separados, é possível criar uma VPN entre os dois datacenters. Isso envolve um certo trabalho de infraestrutura. Por exemplo, podemos usar serviços do cloud provider, que permitam a comunicação entre os dois datacenters, mas isso envolve um certo custo.

A escolha do Skupper foi baseada nos seguintes fatores:

• É uma ferramenta open source: total transparência sobre seu funcionamento;
• Opera na camada 7 (aplicação): permite o acesso dos serviços do cluster via nome de serviço sem configurações adicionais;
• Não é invasivo: não exige a inserção de sidecars na aplicação, reduzindo a complexidade de configuração e observabilidade;
• Garante segurança via Mutual TLS: estabelece conexões seguras entre os serviços utilizando certificados próprios.

Além disso, o Skupper é leve, escalável e transparente, tornando-se uma excelente opção para essa implementação.

Configurando ambiente

Para resolver os problemas dos exemplos do curso, utilizaremos o Minikube como nosso cluster.

Na atividade de "Preparando o Ambiente", explicamos como instalar todas as ferramentas necessárias para o curso.

Agora, vamos validar as instalações no terminal. Para verificar se o Minikube está instalado, utilizaremos o seguinte comando:

minikube

Confirmamos que o binário está instalado, pois recebemos uma lista dos comandos disponíveis.

Também conferimos se a ferramenta do Kubectl está disponível, pois ele será utilizado para manipular o cluster:

kubectl

Além disso, utilizaremos o Podman para simular os nodes do cluster Kubernates, pois ele é mais leve e adequado para nossa configuração. Nesse caso, estamos usando um Linux com 4 GB de memória e dois núcleos para facilitar a reprodução.

Criando o cluster

Primeiramente, vamos iniciar o nosso cluster. Por enquanto, não vamos nos preocupar com namespaces ou qualquer outra configuração adicional.

Executamos o seguinte comando para iniciar o Minikube com o Podman:

minikube start --driver=podman

Assim que o processo for concluído, o terminal será liberado. Para validar a execução cluster usamos o seguinte comando:

minikube status

• type: Control Plane
• host: Running
• kubelet: Running
• apiserver: Running
• kubeconfig: Configured

Esse comando retorna o status do cluster e confirma que ele está funcional.

Simulando ambiente multicloud

Com isso, podemos avançar para a simulação do ambiente multicloud. O arquivo de configuração pode ser encontrado no diretório:

ls ~/.kube/config

Esse arquivo contém os detalhes e recursos do cluster. Para a simulação do ambiente multicloud, precisaremos de dois arquivos de configuração distintos - independentemente se o cluster está separado por regiões ou não.

A partir de agora, vamos trabalhar com dois terminais — um para cada datacenter ou namespace.

Criando arquivos de configuração

No terminal, faremos uma cópia do KubeConfig para config-west e outro para config-east, que serão o front e back-end, respectivamente.

cp ~/.kube/config ~/.kube/config-west
cp ~/.kube/config ~/.kube/config-east

Dessa maneira, cada terminal vai apontar para um KubeConfig diferente e, assim, simular o multicloud.

Em seguida, configuramos cada terminal para utilizar um dos arquivos. Para isso, precisamos usar a variável KUBECONFIG que o Kubeclt lê por padrão.

No primeiro terminal (west):

export KUBECONFIG=~/.kube/config-west

No segundo terminal (east):

export KUBECONFIG=~/.kube/config-east

Agora, cada terminal opera de forma independente, simulando dois datacenters distintos. Para validar se a configuração está funcionando, podemos usar o comando:

kubectl get nodes

Agora, em cada terminal, vamos criar a infraestrutura correspondente.

Criando namespaces

No primeiro terminal (west), criamos um namespace chamado west.

kubectl create namespace west

namespace/west created

Em seguida, definimos o contexto do Kubectl para que ele use esse namespace por padrão:

kubectl config set-context --current --namespace=west

Context 'minikube' modified

Depois de modificar o contexto, podemos usar um comando para validar a configuração:

kubectl get pods

No resources found in west namespace.

Com isso, o terminal avisa que não encontrou nenhum recurso no namespace west. Isso significa que esse terminou já entendeu qual é o local que ele está trabalhando.

Da mesma maneira, vamos criar um namespace chamado east no segundo terminal, que teoricamente acessa outro cluster.

kubectl create namespace east

namespace/east created

Em seguida, vamos setar o contexto do Kubectl para o east.

kubectl config set-context --current --namespace=east

Context 'minikube' modified

Podemos validar a configuração executando:

kubectl get pods

No resources found in east namespace.

Como esperado, não há recursos rodando ainda no namespace east.

Próximos passos

Com isso, criamos a estrutura de dois datacenters para simular um ambiente multicloud. A seguir, vamos fazer a instalação do Skupper e as demais ferramentas necessárias.

Simulando ambiente Multicloud - Instalando o Skupper

Agora que já temos nosso ambiente configurado, pelo menos inicialmente, vamos entender exatamente o que criamos e o que precisamos evoluir para que o Skupper funcione adequadamente. Ainda há bastante para explorar, então começaremos entendendo nosso ambiente.

Entendendo projeto do curso

Neste diagrama, vamos compreender o que já foi feito. Apesar de ter apenas um cluster rodando com namespaces distintos, vamos considerar o cluster 1 e o cluster 2 para fazer a simulação multicloud.

Logicamente, separamos o namespace west no cluster 1 e o namespace east no cluster 2. Se você for executar este exemplo no dia a dia, você pode usar clusters distintos. O único requisito é que um deles tenha acesso direto à internet. Isso está relacionado a como vamos conectar os dois namespaces.

Com isso, vamos introduzir um conceito que usaremos daqui para frente. Para o Skupper, um cluster dentro de um namespace recebe o nome de site. Não é site de website nem de localização física, embora possa ser localização física, mas não necessariamente. Então, agora temos dois sites: o site west e o site east.

Dentro desses sites, teremos duas aplicações (deployments) em execução. No west, teremos o front-end, ou seja, a aplicação web rodando. Enquanto, no east teremos o back-end. Eles estão como serviços, mas compõem todo um deployment, um componente de configuração comum do Kubernetes.

Para que ambos consigam se comunicar, o Skupper estabelecerá uma comunicação entre esses dois datacenters através da camada 7.

Até agora, criamos cluster 1 (site west) e o cluster 2 (site east). Para evoluir a configuração, antes de fazer o deploy de aplicações ou nos preocuparmos com serviços, vamos instalar o Skupper binário, que chamamos de CLI (Command Line Interface).

Instalando Skupper

Assim como o Kubectl é o CLI para manipular elementos do Kubernetes, o Skupper também possui seu próprio CLI para manipular seus componentes.

Da mesma máquina, manipulemos clusters distintos. Por isso, o CLI só precisa estar instalado em uma máquina.

Para fazer essa instalação, seguiremos as instruções do site do Skupper. No menu "Getting Started", encontramos os requisitos e os passos para começar com o Skupper. Vamos copiar o comando para instalar a linha de comando no nosso ambiente e colá-lo no terminal. Não importa qual lado, desde que a mesma máquina controle ambos.

curl https://skupper.io/install.sh | sh

The Skupper command is now installed.

• Version: 1.8.3
• Path: /home/aluno/.local/bin/skupper

Com isso, fazemos o download CLI na versão 1.8.3 e o movemos para o diretório /home/seu_usuario/.local/bin/skupper. Agora, precisamos acessar o arquivo através de uma linha de exportação para tê-lo disponível no nosso path.

Antes de fazer o export, é importante entender as versões do Skupper. A versão 1.8 é a mais atual disponível para o usuário no site do Skupper Upstream. O Skupper é um produto da Red Hat, mas é open source. Podemos comparar com o Fedora e o Red Hat Enterprise Linux, onde o Fedora é open source e upstream, enquanto o Enterprise Linux é downstream. Não utilizaremos nada pago ou registrado, mas sim a versão 1.8 upstream, que é a última versão.

Podemos conferir que o Skupper está instalado no path com o comando:

skupper version

• client version 1.8.3
• transport version not-found
• controller version not-found
• config-sync version not-found
• flow-collector version not-found

O Skupper não é invasivo, não possui sidecars, mas tem seus componentes. Três deles são importantes: o controller, o config-sync e o flow-collector. Esses três containers são responsáveis por conectar os dois lados da aplicação, sincronizar as configurações dos dois lados quando os serviços forem expostos e coletar estatísticas na rede VAN (Virtual Application Network).

Há uma função que conheceremos mais adiante, um console web para visualizar as conexões e como a configuração foi feita pelo Skupper. No momento, os componentes aparecem como "não encontrado" porque apenas o CLI do Skupper está instalado; os componentes do Kubernetes ainda não foram instalados.

Podemos executar o comando skupper para conferir as várias funções que usaremos em nossos exemplos, que vão nos permitir vincular os dois sites e expor serviços, tornando nosso desenho de solução coerente.

skupper

Available Commands

• completion: output shell completion code for bash
• debug: debug skupper installation
• delete: delete skupper installation
• expose: expose a set of pods through a Skupper address
• gateway: manage skupper gateway definitions
• help: help about any command ...

Vamos revisar o desenho de solução para entender melhor. Entre um site e outro, haverá um sincronizador de configurações, um controller com um router dentro dele. Basicamente, esse router funciona como um roteador de internet, mas roda dentro de um container, e possibilita a comunicação entre os dois lados.

Próximos passos

Agora que o CLI está instalado e nosso ambiente configurado, a próxima etapa é habilitar o Skupper em cada um dos nossos sites. Até breve!

Sobre o curso Skupper: fazendo o deploy de aplicações Multicloud

O curso Skupper: fazendo o deploy de aplicações Multicloud possui 108 minutos de vídeos, em um total de 32 atividades. Gostou? Conheça nossos outros cursos de Google Cloud Platform em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Simulando ambiente Multicloud
• Configurando o Skupper
• Fazendo o deploy da aplicação
• Adicionando um serviço local ao cluster
• Usando o Skupper Web Console