Node devops course: Istio Chapter

Setup inicial

Minikube

Instale o Minikube no Mac:

brew install minikube

Instalação Linux: https://minikube.sigs.k8s.io/docs/start/

Para listar os contextos em que seu kubectl está conectado faça um:

kubectl config get-contexts

Se necessário mude o contexto para o Minikube:

kubectl config use-context minikube

Istio

Instale o Istio na versão do profile demo segundo a doc: https://istio.io/latest/docs/setup/getting-started/. A última versão disponível no momento dessa escrita é a 1.8.2. Abaixo o tutorial resumido:

Resumindo o link acima;

curl -L https://istio.io/downloadIstio | sh -
cd istio-1.8.2
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y

Obs: No Linux uma alternativa bem interessante ao uso do Minikube é o Microk8s (https://microk8s.io). Entretando alguns dos add-ons utilizados nesse workshop precisarão ser instalados manualmente também. Espero poder atualizar esse material explicando como fazer esse setup em algum momento ;)

Addons

Vamos instalar também alguns addons que irão nos ajudar a entender a estrutura do nosso mesh através de alguns dashboards, os componentes são Kiali, Prometheus, Grafana, e Jaeger.

kubectl apply -f samples/addons

Obs: Caso aconteça algum problema na aplicação desses recursos, tente rodar o comando acima novamente.

Helm

Instale o Helm no Mac:

brew install helm

Instalação Linux: https://helm.sh/docs/intro/install/

Namespace a ser usado nesse workshop

Crie o namespace istio-dev que vamos precisar nos exemplos: Na pasta de nosso projeto execute:

kubectl apply -f temp/istio-namespace.json

Hands-on!

Se familiarizando com o worflow de trabalho desse workshop:

Criação/alteração das aplicações no cluster via helm

Para verificar o que o Helm vai aplicar no cluster:

./utils.sh install yaml

Observe que foi criado o arquivo helm-generated.yaml com o conteúdo a ser aplicado no cluster pelo Helm

Para realmente instalar nossas aplicações no cluster:

./utils.sh install

Você pode alterar os yamls de template do Helm e aplicar as mudanças usando esse passo

Fazendo port forward e chamando cadeia de serviços:

Faça o port forward do ingress para que possamos fazer uma chamada a entrada de nossa aplicação:

./utils.sh pfIngress

Em outra abas faça uns requests para nossa cadeia de serviços (será necessário instalar em seu SO o watch e o json_pp caso já não possua)

./utils.sh callChain

Para fazer uma única chamada à aplicação use:

./utils.sh callChain single

Deixe essas abas rodando as chamadas ao cluster para que possamos ver como a aplicação está respondendo

Acessando o Kiali e Jager para melhor entendimento do que está ocorrendo no cluster:

Em outra aba, verifique como o Kiali identificou a topologia de nossos serviços: (user e senha: admin)

./utils.sh kiali

Em outra aba, veja os tracings no Jaeger

./utils.sh jaeger

Mantenha o Kiali e o Jaeger rodando para que as consequências das alterações no cluster possam ficar visíveis

Emulando uma instabilidade:

Vamos introduzir latência na aplicação para verificar o comportamento dela.

Escolha uma das aplicações (número de 1 a 5) para adicionar o endpoint de aumento de latência. No exemplo abaixo vamos escolher a instância 3 para fazer o port-forward:

./utils.sh pf 3

Obs: esse port-forward é para o Service e não do Pod, mas como só temos uma instância no deployment desse recurso teremos um comportament consistente. Caso fossem 2 instâncias seria introduzido delay em apenas uma delas.

Agora podemos chamar o endpoint de introdução de latência:

./utils.sh callDelay

Observe no navegador o Jaeger e procure pelo tracing das chamadas recentes feitas ao callChain que ainda deve estar rodando em uma aba do terminal

Vamos voltar para a situação instável e vamos fazer o revert do comportament de delay para introduzir um novo conceito no próximo step. Por agora faça uma nova chamada ao endpoint anterior:

./utils.sh callDelay

Observe pelo Jaeger ou Kiali que o sistema voltou a ficar estável. Deixe os terminais preparados para refazermos esse processo, mas antes aba uma nova aba para fazermos uma nova config no passo seguinte!

Ligando o circuit breaker do Istio-Proxy/Sidecar:

Vamos fazer uma mudança na estrutura de nosso chart do helm, antes de aplicá-la vamos ver o atual estado de nossos charts. Repare na revision da saída do comando abaixo:

helm -n istio-dev list

Para ativar a configuração de circuit breaker nos Pods do cluster ligue a flag da seguinte variável de ambiente:

export ISTIO_CIRCUIT_BREAKER_ON=1

Vamos agora habilitar essa config fazendo nesse terminal o comando:

./utils.sh install

Caso esteja curioso com o que foi aplicado, execute o comando abaixo e observe no arquivo healm-generated.yaml nos recursos de DestinationRule principalmente

./utils.sh install yaml

Vamos repetir o processo de introduzir latência. Supondo que ainda existe um terminal rodandno com o ./utils.sh pf 3 onde 3 é um número de 1 a 5 de um dos serviços da cadeia de chamadas. Novamente faça a chamada:

./utils.sh callDelay

Repare o comportamento agora. Depois de algumas tentativas com timeout o nosso circuit breaker abre o circuito e a aplicação começa a retornar o JSON de fallback com uma chamada parcialmente completa.

Canary Deploy:

Vamos agora testar o Canary subindo em uma das aplicações (primeiro argumento: 3) uma versão para a Green (segundo argumento: 0.2) com um certo percentual de tráfego (terceiro argumento: 0) Para observar o que o Helm irá fazer no cluster:

./utils.sh enableGreen 3 0.2 0 yaml