Como Instalar e Utilizar o Linkerd com o Kubernetes

O autor selecionou a Tech Education Fund para receber uma doação como parte do programa Write for DOnations.

Introdução

Um service mesh é uma camada de infraestrutura dedicada que ajuda os administradores a lidar com a comunicação serviço-para-serviço. Oferecendo muitas ferramentas poderosas, esses service meshes podem tornar seu sistema mais seguro, mais confiável e mais visível também.

Um service mesh como o Linkerd, por exemplo, pode criptografar conexões automaticamente, lidar com tentativas de requisições e timeouts fornecer informações de telemetria como taxas de sucesso e latências, e muito mais.

Neste tutorial, você instalará o service mesh Linkerd em seu cluster Kubernetes, fazer o deploy de uma aplicação de exemplo e, em seguida, explorará o painel do Linkerd. Após familiarizar-se com algumas informações deste painel, você configurará o Linkerd para forçar as políticas de timeout e retry para um pode específico do Kubernetes.

Alternativamente, considere explorar a opção de instalação one-click do Linkerd/Kubernetes.da DigitalOcean.

Pré-requisitos

• Um cluster Kubernetes 1.12+. Neste tutorial, a configuração utilizará um cluster Kubernetes da DigitalOcean com três nodes, mas você está livre para criar um cluster usando outro método.

• A ferramenta de linha de comando kubectl instalada em um servidor de desenvolvimento e configurada para conectar-se ao seu cluster. Você pode ler mais sobre como instalar o kubectl em sua documentação oficial.

Passo 1 — Fazendo o Deploy de uma Aplicação

Para ver o Linkerd em ação, você precisa ter uma aplicação executando em seu cluster. Neste passo, você fará a implantação de uma aplicação chamada emojivoto que a equipe do Linkerd criou para este propósito.

Neste repositório, você pode ver o código para os quatro serviços que compõem a aplicação, bem como o arquivo manisfest que você utilizará para fazer o deploy desses serviços em seu cluster Kubernetes.

Primeiro, salve este arquivo manifest localmente:

curl https://run.linkerd.io/emojivoto.yml --output manifest.yaml

Você está usando o curl para obter o arquivo, e depois passando a opção --output para dizer a ele onde você deseja que o arquivo seja salvo. Neste caso, você está criando um arquivo chamado manifest.yaml.

Para entender melhor o que este arquivo realizará, inspecione o conteúdo com o cat ou abra-o com seu editor favorito:

cat manifest.yaml | less

Pressione SPACE para paginar através das diretivas. Você verá que o manifest.yaml está criando um namespace do Kubernetes chamado emojivoto onde tudo o que está relacionado a esta aplicação será executado e alguns Deployments e Services do Kubernetes.

Em seguida, aplique este manifest em seu cluster Kubernetes:

kubectl apply -f manifest.yaml

Novamente, você está usando o kubectl apply com a flag -f para atribuir um arquivo que você deseja aplicar.

Este comando gerará uma lista de todos os recursos que foram criados:

Output
namespace/emojivoto created
serviceaccount/emoji created
serviceaccount/voting created
serviceaccount/web created
service/emoji-svc created
service/voting-svc created
service/web-svc created
deployment.apps/emoji created
deployment.apps/vote-bot created
deployment.apps/voting created
deployment.apps/web created

Agora, verifique se os serviços estão em execução:

kubectl -n emojivoto get pods

Você está usando o kubectl para listar todos os pods que você está executando em seu cluster e, depois, passando a flag -n para indicar quais namespaces você deseja usar. Você está passando o namespace emojivoto, pois é aqui que você está executando todos esses serviços.

Quando você vir todos os pods no estado Running, você pode continuar:

Output
NAME                        READY   STATUS    RESTARTS   AGE
emoji-566954596f-cw75b      1/1     Running   0          24s
vote-bot-85c5f5699f-7dw5c   1/1     Running   0          24s
voting-756995b6fc-czf8z     1/1     Running   0          24s
web-7f7b69d467-2546n        1/1     Running   0          23s

Por fim, para ver a aplicação executando em seu navegador, você utilizará a funcionalidade kubectl integrada de encaminhamento das solicitações locais para seu cluster remoto:

kubectl -n emojivoto port-forward svc/web-svc 8080:80

Aqui você está usando o kubectl novamente nos namespaces do emojivoto, mas agora chamando o sub-comando port-forward e o direcionando para encaminhar todas as solicitações locais na porta 8080 para o serviço Kubernetes web-svc na porta 80. Esta é apenas uma maneira conveniente para você acessar sua aplicação sem precisar ter um balanceador de carga adequado.

Agora, visite http://localhost:8080 e você a aplicação emojivoto.

Pressione CTRL + C em seu terminal. Com uma aplicação executando em seu cluster, você agora está pronto para instalar o Linkerd e ver como ele funciona.

Passo 2 — Instalando o Linkerd

Agora que você tem uma aplicação em execução, vamos instalar o Linkerd. Para instalá-lo em seu cluster Kubernetes, você primeiro precisa do Linkerd CLI. Você utilizará esta interface de linha de comando para interagir com o Linkerd de sua máquina local. Após isso, você pode instalar o Linkerd em seu cluster.

Primeiro, vamos instalar a CLI com o script fornecido pela equipe do Linkerd:

curl https://run.linkerd.io/install | sh

Aqui, você está usando o curl para baixar o script de instalação e, em seguida você está passando a saída para o sh, que executa automaticamente o script. Alternativamente, você pode baixar a CLI diretamente da página de release do Linkerd.

Se você usar o script, ele instalará o Linkerd em ~/.linkerd2/bin. Agora, confirme que a CLI está funcionando corretamente:

~/.linkerd2/bin/linkerd version

O comando gerará algo parecido com isto:

Output
Client version: stable-2.7.1
Server version: unavailable

Em seguida, para facilitar a execução da CLI, adicione este diretório ao seu $PATH:

export PATH=$PATH:$HOME/.linkerd2/bin

Agora, você pode executar mais diretamente os comandos, como os anteriores:

linkerd version

Por fim, vamos instalar o Linkerd em seu cluster Kubernetes. O comando linkerd install é usado para gerar todos os manifests yaml necessários para executar o Linkerd, mas ele não aplicará esses manifests em seu cluster. Execute este comando para inspecionar sua saída:

linkerd install

Você verá uma saída longa listando todos os manifests yaml para os recursos que o Linkerd precisa executar. Para aplicar esses manifests em seu cluster, execute:

linkerd install | kubectl apply -f -

A execução do linkerd install gerará todos os manifests que você viu anteriormente.O | passa essa saída diretamente para o kubectl apply, que os aplicará.

Após executar este comando, o kubectl apply gerará uma lista de todos os recursos que foram criados.

Para confirmar que tudo está em execução em seu cluster, execute o linkerd check:

linkerd check

Isso executará várias verificações em seu cluster para confirmar que todos os componentes necessários estão em execução:

Output
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

[...]

control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match

Status check results are √

Finalmente, execute este comando para abrir o painel integrado do Linkerd em seu navegador (Lembre-se de fornecer a flag --address 0.0.0 0 caso você não esteja executando isso de sua máquina local):

linkerd dashboard

A maioria das informações que você vê no painel de controle, você pode obter usando a CLI do Linkerd. Por exemplo, execute este comando para ver estatísticas de alto nível das implantações:

linkerd stat deployments -n linkerd

Aqui, você está dizendo que você deseja as estatísticas para os deployments em execução no namespace do linkerd. Estes são os próprios componentes do Linkerd, e, de maneira interessante, você pode usar o próprio Linkerd para monitorá-los. Você pode ver estatísticas tais como solicitações por segundo (RPS), taxa de sucesso, latência, e outras. Você também pode ver uma coluna do Meshed, que indica quantos pods o Linkerd injetou:

Output
NAME                     MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
linkerd-controller          1/1   100.00%   0.4rps           1ms          87ms          98ms          5
linkerd-destination         1/1   100.00%   0.3rps           1ms           2ms           2ms         13
linkerd-grafana             1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-identity            1/1   100.00%   0.3rps           1ms           2ms           2ms         10
linkerd-prometheus          1/1   100.00%   0.7rps          35ms         155ms         191ms          9
linkerd-proxy-injector      1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-sp-validator        1/1   100.00%   0.3rps           1ms           5ms           5ms          2
linkerd-tap                 1/1   100.00%   0.3rps           1ms           4ms           4ms          6
linkerd-web                 1/1   100.00%   0.3rps           1ms           2ms           2ms          2

Agora, tente este comando em seu namespace emojivoto:

linkerd stat deployments -n emojivoto

Embora você possa ver seus quatro serviços, nenhuma das estatísticas que você viu antes estão disponíveis para esses deployments, e na coluna “Meshed” você pode ver que ela diz 0/1:

Output
NAME       MESHED   SUCCESS   RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         0/1         -     -             -             -             -          -
vote-bot      0/1         -     -             -             -             -          -
voting        0/1         -     -             -             -             -          -
web           0/1         -     -             -             -             -          -

A saída aqui significa que você ainda não injetou o Linkerd na aplicação. Este será seu próximo passo.

Passo 3 — Injetando o Linkerd em sua Aplicação

Agora que você tem o Linkerd em execução em seu cluster, você está pronto para injetá-lo em sua aplicação emojivoto.

O Linkerd funciona executando um contêiner sidecar em seus pods do Kubernetes. Ou seja, você injetará um contêiner proxy do linkerd em cada pod que você tiver em execução. Cada solicitação que seus pods enviam ou recebem passarão por este proxy muito leve que reúne métricas (como a taxa de sucesso, solicitações por segundo, e latência) e força políticas (como timeouts e retries).

Você pode injetar manualmente o proxy do Linkerd com este comando:

kubectl get deployments -n emojivoto -o yaml | linkerd inject - | kubectl apply -f -

Neste comando, você está usando primeiramente o kubectl get para obter todos os deployments do Kubernetes que você tem em execução no namespace emojivoto, e, em seguida, especificando que você deseja a saída no formato yaml. Em seguida, você está enviando a saída para o comando inject linkerd. Este comando lerá o arquivo yaml com os manifests atuais que você tem em execução e o modificará para incluir o proxy linkerd, juntamente com todo deployment (implantação).

Por último, você está recebendo este manifest modificado e aplicando-o em seu cluster com o kubectl apply.

Após executar este comando, você verá uma mensagem dizendo que todos os quatro serviços emojivoto (emoji, vote-bot, voting e web) foram injetados com sucesso.

Agora, se você recuperar estatísticas para emojivoto, você verá que todos os seus deployments estão combinados,e após alguns segundos você começará a ver as mesmas estatísticas que você viu para o namespace linkerd:

linkerd stat deployments -n emojivoto

Aqui, você pode ver as estatísticas para todos os quatro serviços que compõem a aplicação emojivoto, com sua respectiva taxa de sucesso, solicitações por segundo e latência, sem ter que escrever ou alterar qualquer código de aplicação.

Output
NAME       MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         1/1   100.00%   1.9rps           1ms           2ms           2ms          2
vote-bot      1/1         -        -             -             -             -          -
voting        1/1    85.96%   0.9rps           1ms           1ms           1ms          2
web           1/1    93.04%   1.9rps           8ms          27ms          29ms          2

O serviço vote-bot não mostra nenhuma estatística, pois ele é apenas um bot que envia solicitações para outros serviços e, portanto, não está recebendo nenhum tráfego, o que é em si uma informação valiosa.

Agora, vamos ver como você pode fornecer algumas informações extras para o Linkerd sobre seus serviços para personalizar seu comportamento.

Passo 4 — Definindo um Perfil de Serviço

Agora que você injetou o Linkerd em sua aplicação, você pode começar a recuperar informações valiosas sobre como cada um de seus serviços está se comportando. Além disso, você realizou isso sem precisar escrever qualquer configuração personalizada ou alterar o código de sua aplicação. No entanto, se você fornecer ao Linkerd algumas informações adicionais, ele pode, em seguida, forçar várias políticas, como o timeout e retries. Ele também pode fornecer, em seguida, métricas por rotas.

Essas informações são fornecidas através de um Perfil de Serviço, que é um recurso personalizado do Linkerd onde você pode descrever as rotas em suas aplicações e como cada um se comportará.

Aqui está um exemplo de como um manifest de Perfil de Serviço se parece:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.my-namespace.svc.cluster.local
spec:
  routes:
  - name: My Route Name
    isRetryable: true # Define it's safe to retry this route
    timeout: 100ms # Define a timeout for this route
    condition:
      method: GET
      pathRegex: /my/route/path

O Perfil de Serviço descreve uma lista de rotas e, em seguida, define como as solicitações que correspondem à condition especificada se comportarão. Neste exemplo, você está dizendo que cada solicitação GET enviada para /my/route/path expirará depois de 100ms e, se elas falharem, elas podem ser tentadas novamente.

Vamos agora criar um Perfil de Serviço para um de seus serviços. Tomando o voting-svc como um exemplo, utilize primeiro a CLI do Linkerd para verificar as rotas que você definiu para este serviço:

linkerd routes svc/voting-svc -n emojivoto

Aqui, você está usando o comando linkerd routes para listar todas as rotas para o serviço voting-svc, no namespace emojivoto

Output
ROUTE          SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
[DEFAULT]   voting-svc    83.05%   1.0rps           1ms           1ms           2ms

Você encontrará apenas uma rota, [DEFAULT]. É aqui que todas as solicitações estão agrupadas até você definir seu Perfil de Serviço.

Agora, abra o nano ou seu editor favorito para criar um arquivo service-profile.yaml:

nano service-profile.yaml

Adicione a seguinte definição de Perfil de Serviço neste arquivo:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: voting-svc.emojivoto.svc.cluster.local
  namespace: emojivoto
spec:
  routes:
  - name: VoteDoughnut
    isRetryable: true
    timeout: 100ms
    condition:
      method: POST
      pathRegex: /emojivoto.v1.VotingService/VoteDoughnut

Agora, salve o arquivo e feche seu editor.

Aqui, você está declarando um Perfil de Serviço para o serviço voting-svc no namespace emojivoto. Você definiu uma rota, chamada VoteDoughnut, que corresponderá a qualquer solicitação POST ao /emojivoto.v1. Caminho VotingService/VoteDoughnut. Se uma solicitação que corresponda a esse critério levar mais do que 100ms, o Linkerd a cancelará e o cliente receberá uma resposta 504. Você também está dizendo ao Linkerd que se esta solicitação falhar, ela pode ser realizada novamente.

Agora, aplique este arquivo em seu cluster:

kubectl apply -f service-profile.yaml

Após alguns segundos, verifique novamente as rotas para este serviço:

linkerd routes svc/voting-svc -n emojivoto

Agora, você verá sua nova rota VoteDoughnut definida:

Output
ROUTE             SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
VoteDoughnut   voting-svc     0.00%   0.2rps           1ms           1ms           1ms
[DEFAULT]      voting-svc   100.00%   0.8rps           1ms           4ms           4ms

Você pode ver várias métricas personalizadas, como a taxa de sucesso, solicitações por segundo e latência para esta rota específica. Observe que o endpoint VoteDoughnut está configurado intencionalmente para sempre retornar um erro e que ele está produzindo uma taxa de sucesso de 0%, enquanto a rota [DEFAULT] está produzindo 100%.

Então agora, após dar ao Linkerd um pouco de informações sobre seu serviço, você tem métricas personalizadas por rota, bem como duas políticas impostas: o timeout e as retries.

Conclusão

Neste artigo, você instalou o Linkerd em seu cluster Kubernetes e o usou para monitorar uma aplicação de exemplo. Você extraiu informações úteis de telemetria, como a taxa de sucesso, taxa de transferência e latência. Você também configurou um Perfil de Serviço Linkerd para coletar métricas por rota e forçar duas políticas na aplicação emojivoto.

Se você estiver interessado em aprender mais sobre o Linkerd, você pode navegar por sua ótima página de documentação, onde eles mostram como proteger seus serviços, configurar o de rastreamento distribuído, automatização de canary releases e muito mais.

A partir daqui, você também pode considerar verificar o Istio, que é outro Service Mesh com um conjunto diferente de recursos e trade-offs.