AKS Istio

9 min readAug 10, 2023

O Istio é uma malha de serviço de código aberto que se encaixa de forma transparente em aplicativos distribuídos existentes. Com ele podemos proteger, conectar e monitorar serviços.

Comunicação segura de serviço a serviço em um cluster com criptografia TLS, autenticação e autorização fortes baseadas em identidade
Balanceamento de carga automático para tráfego HTTP, gRPC, WebSocket e TCP
Controle refinado do comportamento do tráfego com regras de roteamento avançadas, tentativas, failovers e injeção de falhas
Uma camada de política conectável e API de configuração que oferece suporte a controles de acesso, limites de taxa e cotas
Métricas, logs e rastreamentos automáticos para todo o tráfego em um cluster, incluindo entrada e saída do cluster

Nesse artigo vamos explorar estratégia de deploy com o istio para o AKS, estratégias ccomo canary e Blue green e para isso vamos usar dois artigos para configurar o ambiente da POC.

OBS: cuidado ao rodar o comando az aks mesh enable-ingress-gateway, se o serviço não estiver disponível pelo comando kubectl get svc aks-istio-ingressgateway-external -n aks-istio-ingress, provavelmente o cluster ainda está habilitando o istio. rode novamente os comandos de verificação do primeiro artigo e preste atenção na siada do comando.

Sidecar

O Sidecar é um padrão arquitetural que consiste em um processo separado (um “lado” ou “sidecar”) que é executado ao lado de um ou mais micro serviços. O Sidecar é responsável por fornecer funcionalidades adicionais, tais como comunicação de rede, segurança, monitoramento, logging e outras funcionalidades relacionadas, sem modificar diretamente o código do microserviço principal.

Em geral, um Sidecar é implantado como um contêiner dentro de um cluster de contêineres, como o Kubernetes. Ele se comunica com o micro serviço principal usando uma interface padronizada (geralmente um API REST ou gRPC) e pode ser facilmente adicionado ou removido do cluster sem afetar o funcionamento do micro serviço principal.

O Envoy Proxy implementa o padrão Sidecar ao injetar automaticamente um contêiner Envoy em cada Pod em um namespace.

Verificando istio no Cluster

az aks show --resource-group akshpapoc --name akshpaws01  --query 'serviceMeshProfile.mode'
The behavior of this command has been altered by the following extension: aks-preview
"Istio"

podemos ver o nome do service mesh instalado.

Verificar ingress

kubectl get svc aks-istio-ingressgateway-external -n aks-istio-ingress
NAME                                TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
aks-istio-ingressgateway-external   LoadBalancer   10.0.78.239   4.157.66.193   15021:30561/TCP,80:31822/TCP,443:30841/TCP   17h

Aqui vemos um serviço to tipo LoadBalancer com o IP público que vamos usar para entrar no cluster.

Istio primeiro teste, Split apontando para serviços separados aplicação de exemplo httpbin

01-) Criar namespace

kubectl create namespace httpbin

02-) Habilitar Sidecar

kubectl label namespace httpbin istio.io/rev=asm-1-19

03-) vamos fazer o deploy de um serviço raiz para o httpbin usando esse manifesto deploy httpbin

kubectl apply -f  https://raw.githubusercontent.com/openservicemesh/osm-docs/release-v1.0/manifests/samples/canary/httpbin.yaml -n httpbin

04-) deploy httpbin-v1

Aqui temos o Serviço e o deployment de versão 1

kubectl apply -f  https://raw.githubusercontent.com/openservicemesh/osm-docs/release-v1.0/manifests/samples/canary/httpbin-v1.yaml -n httpbin

05-) deploy httpbin-v2

Aqui temos o Serviço e o deployment de versão 2

kubectl apply -f  https://raw.githubusercontent.com/openservicemesh/osm-docs/release-v1.0/manifests/samples/canary/httpbin-v2.yaml -n httpbin

Objetos do ISTIO para o primeiro teste

Vamos criar um manifesto como o abaixo ele vai dividir o trafego entre o serviço httpbin-v1 e httpbin-v2 com pesos diferentes para cada serviço.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway-external
spec:
  selector:
    istio: aks-istio-ingressgateway-external
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin-route
spec:
  hosts:
  - "*"
  gateways:
  - httpbin-gateway-external
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host:  httpbin-v1
        port:
          number: 14001
      weight: 10
    - destination:
        host:  httpbin-v2
        port:
          number: 14001
      weight: 90

06-) save o manifesto acima com o nome istio-split-httpbin-2S.yml e rode o comando abaixo para implantar o Gateway e o VirtualService:

Você usa um gateway para gerenciar o tráfego de entrada e saída de sua malha, permitindo especificar qual tráfego deseja entrar ou sair da malha.

Virtual services, juntamente com as destination rules, são os principais blocos de construção da funcionalidade de roteamento de tráfego do Istio.

saiba mais

kubectl apply -f .\istio-split-httpbin-2S.yml -n httpbin

07-) Rewrite pode ser usado para reescrever partes específicas de uma solicitação HTTP antes de encaminhar a solicitação ao destino.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name:  httpbin-route
spec:
  hosts:
  - "*"
  gateways:
  - httpbin-gateway-external
  http:
  - match:
    - uri:
        prefix: /httpbin
    rewrite:
      uri: "/"
    route:
    - destination:
        host:  httpbin-v1
        port:
          number: 14001
      weight: 10
    - destination:
        host:  httpbin-v2
        port:
          number: 14001
      weight: 90

verificar objetos implantados

kubectl get all -n httpbin

verificar gateway

kubectl get gateway -n httpbin

verificar VirtualService

kubectl get VirtualService -n httpbin

agora basta acessar o endereço do seu geatway externo. no casso desse exemplo é http://4.157.66.193, no podemos verificar isso com o comando

kubectl get svc aks-istio-ingressgateway-external -n aks-istio-ingress

e caso você tenha experimentado o rewrite terá que adicionar o sufixo httpbin na url http://4.157.66.193/httpbin

pelo postman podemos observar no header de response chamado pod qual foi a versão que o istio roteou

Devido as especificações de pesos na propriedade weight 90% do tráfego vai ser direcionado para a versão v2.

Istio segundo teste, aplicação bookinfo

Nesse exemplo vamos usar apenas um serviço e configurar um novo objeto do istio chamado DestinationRule para nos ajudar a diferenciar uma versão da outra.

01-) criar namespace

kubectl create namespace bookinfo

02-) habilitar sidecar

kubectl label namespace bookinfo istio.io/rev=asm-1-19

03-) vamos criar o deploy da aplicação bookinfo

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.19/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo

esse deploy ja implanta tudo que precisamos para testar o split, serviços deployments etc

verifique as implantações com o comando

kubectl get all -n bookinfo

Objetos Istio para o segundo teste

Vamos criar um manifesto como o abaixo ele vai dividir o tráfego entre os serviços de reviews sem especificar pesos

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: reviews-gateway-external-lb
spec:
  selector:
    istio: aks-istio-ingressgateway-external
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - "*"
  gateways:
  - reviews-gateway-external-lb
  http:
  - name: "reviews-lb-routes"
    route:
    - destination:
        host: reviews
        port:
          number: 9080

05-) save o manifesto acima com o nome istio-bookinfo-balance.yml e rode o comando abaixo para implantar o Gateway e o VirtualService:

kubectl apply -f istio-bookinfo-balance.yml -n bookinfo

Essa aplicação tem duas rotas um heath check /health e o /reviews/{id}, podemos observar ao acessar o reviews que existe um comportamento de Round-robin distribuindo a carga entre os três serviços de reviews.

Caso não esteja conseguindo acessar provavelmente você não rodou o rewrite da aplicação httpbin.

Estratégia de Deploy com Istio

Você pode usar estratégias avançadas de implantação combinando várias versões de um deployment.

Blue Green

Consiste em implantar a nova versão (verde) ao lado da versão atual (azul) com o mesmo número de instâncias. Após testar que a nova versão atende a todos os requisitos, o tráfego é alternado da versão antiga para a nova .

Para isso vamos criar um manifesto como o abaixo que vai dividir o tráfego entre os serviços de reviews sem especificar pesos, e vai permitir que um cabeçalho http nos ajude a direcionar o tráfego para versão v1 ou versão v2

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: reviews-gateway-external-bg
spec:
  selector:
    istio: aks-istio-ingressgateway-external
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - "*"
  gateways:
  - reviews-gateway-external-bg
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        port:
          number: 9080        
        subset: v2
  - match:
    - headers:
        end-user:
          exact: ws
    route:
    - destination:
        host: reviews
        port:
          number: 9080        
        subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

nesse manifesto temos um novo objeto do Istio o DestinationRule que através do metadados label/version consegue diferenciar as implantações leia o manifesto bookinfo para perceber a amarração dos deplyments com o DestinationRule.

06-) save o manifesto acima com o nome istio-bookinfo-bg-match-header.yaml e rode o comando abaixo para implantar o Gateway e o VirtualService e o DestinationRule

kubectl apply -f istio-bookinfo-bg-match-header.yaml -n bookinfo

Para fazer o teste na mão e criar seu proprio deploy cuidado com o metadado label que precisa ser uma string, começar e terminar com um character alfa numérico, saiba mais em Labels and Selectors | Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: details-v1
  labels:
    app: details
    version: v1

alem disso precisamos lembra que esse campo é um campo imutavel usado para controlar as mudanças de cada deploy, o que impede o uso de valore dinamicos.

Canary

Consiste em transferir gradualmente o tráfego de produção da versão antiga para a nova. Normalmente, o tráfego é dividido com base em pesos.

Para isso vamos criar um manifesto como o abaixo ele vai dividir o tráfego entre os serviços de reviews mas especificando pesos para cada serviço, assim o algoritimo do balanceador vai direcionar a carga de acordo com a propriedade weight de cada roteamento.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: reviews-gateway-external-split
spec:
  selector:
    istio: aks-istio-ingressgateway-external
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - "*"
  gateways:
  - reviews-gateway-external-split
  http:
  - name: "reviews-split-routes"
    route:
    - destination:
        host: reviews
        port:
          number: 9080
        subset: v2
      weight: 10
    - destination:
        host: reviews
        port:
          number: 9080
        subset: v1
      weight: 90
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

06-) save o manifesto acima com o nome istio-bookinfo-cy.yaml e rode o comando abaixo para implantar o Gateway e o VirtualService e o DestinationRule

kubectl apply -f istio-bookinfo-cy.yaml -n bookinfo

Conclusão

O Istio aborda os desafios que os desenvolvedores e operadores enfrentam com uma arquitetura distribuída ou de microsserviços. O complemento de malha de serviço baseado em Istio fornece uma integração oficialmente suportada e testada para o Serviço de Kubernetes do Azure (AKS) e pode nos ajudar a resolver problemas com esse acima com baixo acoplamento nas aplicações.

Mas isso é só o começo temos muitas outas funcionalidade que podemos explorar com Istio, para saber mais acesse Istio / Documentation

HPA Istio

Listar tudo da namespace aks-istio-ingress

kubectl get all -n aks-istio-ingress

Criar arquivo manifesto de HPA

kubectl autoscale deployment aks-istio-ingressgateway-external-asm-1-19 --cpu-percent=60 --min=1 --max=5 --dry-run=client -o yaml > aks-istio-ingressgateway-hpa-01.yaml -n aks-istio-ingress

Arquivo de manifesto gerado

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  creationTimestamp: null
  name: aks-istio-ingressgateway-external-asm-1-19
spec:
  maxReplicas: 5
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: aks-istio-ingressgateway-external-asm-1-19
  targetCPUUtilizationPercentage: 60
status:
  currentReplicas: 0
  desiredReplicas: 0

Aplicar

kubectl apply -f aks-istio-ingressgateway-hpa-01.yaml -n aks-istio-ingress

Verificando

kubectl get hpa -n aks-istio-ingress