Multicloud com o Skupper

5 minutos de leitura
could • k8s
k8s • skupper • could • Red Hat

Atualizado em 2022-10-08

Referências Link para o cabeçalho

  1. https://skupper.io
  2. https://minikube.sigs.k8s.io
  3. Repositório com os Códigos
  4. Qpid-dispatch
  5. ActiveMQ
  6. Kubectl

Ferramentas Link para o cabeçalho

  • Um computador com o minikube [2] instalado;
  • Um terminal para executar os comandos;
  • kubectl > 1.15 [6] ou mais nova.

Descrição da solução Link para o cabeçalho

O Skupper [1] é uma ferramenta que permite conectar dois ou mais ambientes de cloud de uma maneira não intrusiva e segura. Tais ambientes podem ser de diferentes provedores de serviço em nuvem como: AWS, GCP, AZURE entre outras, e, inclusive, clusters kubernetes nativos.

tl;dr

O skupper é um fork do qpid_dispatch [4] como software para trocar as mensagens entre os namespaces ou clusters. Para isso utiliza uma solução que chamamos de skupper-router que provê interfaces TCP e HTTP para as aplicações, transforma as mensagens em activemq messages [5] e na “outra ponta” reverte tal conversão para que os dados sejam interpretados e processados.

Este exemplo é um aplicativo HTTP multisserviço muito simples implantado em clusters Kubernetes usando o Skupper.

Example image

Contém dois serviços:

  • Um serviço de backend que expõe um endpoint /api/hello. Ele retorna saudações no formato Oi, <seu-nome>. Eu sou <meu-nome> (<nome-pod>).

  • Um serviço de frontend que envia saudações ao back-end e busca novas saudações em resposta.

Com o Skupper, você pode colocar o back-end em um cluster e o front-end em outro e manter a conectividade entre os dois serviços sem expor o back-end à Internet pública.

Detalhes:

  1. Não é necessário ter privilégios de administrador do cluster, já que a solução é no nível do namespace;
  2. Não é intrusivo com a sua aplicação, pois não cria side-cars ou outros containers dentro dos Pods;
  3. É open-source;
  4. Você pode conectar, em seu cluster, serviços externos como: Bancos de dados, aplicações legadas e ainda de alta criticidade;
  5. Criptografado de ponta a ponta usando certificados digitais;
  6. Baixa curva de aprenddizagem.

Agora vamos preparar nosso ambiente de teste, que consiste no seguinte:

  • Um serviço de backend que está rodando em um namespace que vai prover a lógica para outro serviço de frontend que obviamente está e outro namespace*.
    • Nesse caso, cada serviço está rodando em namespaces diferentes, mas o mesmo exemplo pode (e deve) ser testado com provedores diferentes.

Preparando o ambiente Link para o cabeçalho

1. Nesse exemplo vamos utilizar dois namespaces chamados: Link para o cabeçalho

1.1. config_oeste onde ficará o frontend. Lembre-se de abrir uma aba do seu terminal para cada namespace

export KUBECONFIG=~/.kube/config-oeste

1.2. config_leste onde ficará o backend agora, no outro terminal:

export KUBECONFIG=~/.kube/config-leste

2. Configurando cada namespace: Link para o cabeçalho

2.1.config_oeste:

kubectl create namespace oeste
kubectl config set-context --current --namespace oeste

2.2.config_leste:

kubectl create namespace leste
kubectl config set-context --current --namespace leste

3. Instalando o Skupper: Link para o cabeçalho

Você possui algumas maneiras de instalar o skupper, como por exemplo:

4. Instaçação Link para o cabeçalho

  • É bem simples:
    curl https://skupper.io/install.sh | sh

5. Iniciando o skupper nos dois namespaces: Link para o cabeçalho

5.1.config_oeste:

skupper init

5.2.config_leste:

skupper init

6. Conectando os namespaces: Link para o cabeçalho

A criação de um link requer o uso de dois comandos skupper em conjunto: skupper token create e skupper link create.

O comando skupper token create gera um token secreto que significa permissão para criar um link. O token também carrega os detalhes do link. Em seguida, em um namespace remoto, o comando skupper link create usa o token para criar um link para o namespace que o gerou.

Nota: O token de link é realmente um segredo. Qualquer pessoa que tenha o token pode vincular ao seu namespace. Certifique-se de que apenas aqueles em quem você confia tenham acesso a ele.

Primeiro use skupper token create em um namespace para gerar o token. Em seguida, use skupper link create no outro para criar um link. 6.1.config_oeste:

skupper token create ~/secret.token
Token written to ~/secret.token

6.2.config_leste:

skupper link create ~/secret.token

7. Fazendo o deploy do frontend e do backend: Link para o cabeçalho

7.1.config_oeste:

kubectl create deployment frontend --image quay.io/skupper/hello-world-frontend
deployment.apps/frontend created

7.2.config_leste:

kubectl create deployment backend --image quay.io/skupper/hello-world-backend --replicas 3
deployment.apps/backend created

8. Expondo os serviços de backend: Link para o cabeçalho

8.1.config_leste:

skupper expose deployment/backend --port 8080
deployment backend exposed as backend

9. Expondo os serviços de frontend: Link para o cabeçalho

9.1.config_oeste:

skupper expose deployment/backend --port 8080
service/frontend exposed

10. Testando a aplicação: Link para o cabeçalho

10.1.config_oeste:

kubectl get service/frontend
NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)          AGE
frontend   LoadBalancer   10.103.232.28   <external-ip>   8080:30407/TCP   15s

curl http://<external-ip>:8080/api/health
OK

11. Apagando tudo: Link para o cabeçalho

11.1.config_oeste:

skupper delete
kubectl delete service/frontend
kubectl delete deployment/frontend

11.2.config_leste:

skupper delete
kubectl delete deployment/backend

Resumo Link para o cabeçalho

Este exemplo localiza os serviços de front-end e back-end em namespaces diferentes, em clusters diferentes. Normalmente isso significa que eles não tem como se comunicar, a menos que sejam expostos à Internet pública.

A introdução do Skupper em cada namespace nos permite criar uma rede de aplicativos virtuais que pode conectar serviços em diferentes clusters. Qualquer serviço exposto na rede de aplicativos é representado como um serviço local em todos os namespaces vinculados.

O serviço de back-end está localizado no leste, mas o serviço de front-end no oeste pode “vê-lo” como se fosse local. Quando o front-end envia uma solicitação ao back-end, o Skupper encaminha a solicitação para o namespace em que o back-end está sendo executado e roteia a resposta de volta ao front-end.