Implantação canário no Kubernetes nº 3: Istio

Usando Istio+Kiali para iniciar e visualizar uma implantação Canary

Artigos desta série

1. Implantação Canary no Kubernetes nº 1: Gitlab CI
2. Implantação Canary no Kubernetes nº 2: lançamentos do Argo
3. (Este artigo)
4. Implantação Canary usando Jenkins-X Istio Flagger

Implantação canário

Esperamos que você leia primeira parte, onde explicamos brevemente o que são implantações Canary e mostramos como implementá-las usando recursos padrão do Kubernetes.

Istio

E presumimos que ao ler este artigo você já sabe o que é Istio. Se não, então você pode ler sobre isso aqui.

Aplicativo para testes

Cada pod contém dois contêineres: nosso aplicativo e istio-proxy.

Usaremos um aplicativo de teste simples com pods frontend-nginx e backend python. O pod nginx simplesmente redirecionará cada solicitação para o pod backend e funcionará como um proxy. Detalhes podem ser encontrados nos seguintes yamls:

• frontend.yaml
• back-end.yaml
• istio.yaml

Executando você mesmo o aplicativo de teste

Se você quiser seguir meu exemplo e usar este aplicativo de teste sozinho, consulte leia-me do projeto.

Implantação inicial

Ao lançarmos o primeiro Deployment, vemos que os pods da nossa aplicação possuem apenas 2 containers, ou seja, o sidecar do Istio está apenas sendo implementado:

E também vemos o Istio Gateway Loadbalancer no namespace istio-system:

Geração de tráfego

Usaremos o seguinte IP para gerar tráfego que será recebido pelos pods frontend e encaminhado para os pods backend:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Também adicionaremos frontend.istio-test para nosso arquivo hosts.

Ver malha via Kiali

Instalamos o aplicativo de teste e o Istio junto com Tracing, Grafana, Prometheus e Kiali (veja detalhes abaixo). leia-me do projeto). Portanto, podemos usar Kiali via:

istioctl dashboard kiali # admin:admin

Kiali visualiza o tráfego atual através do Mesh

Como podemos ver, 100% do tráfego vai para o serviço frontend e depois para os pods frontend com rótulo v1, já que estamos usando um proxy nginx simples que redireciona as solicitações para o serviço backend, que por sua vez as redireciona para os pods backend com rótulo v1.

Kiali funciona muito bem com o Istio e fornece uma solução de renderização de malha in a box. Simplesmente ótimo.

Implantação canário

Nosso backend já possui duas implantações k8s, uma para v1 e outra para v2. Agora só precisamos dizer ao Istio para encaminhar uma certa porcentagem de solicitações para a v2.

Etapa 1: 10%

E tudo o que precisamos fazer é ajustar o peso do VirtualService em istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Vemos que 10% das solicitações são redirecionadas para a v2.

Etapa 2: 50%

E agora basta aumentar para 50%:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Etapa 3: 100%

Agora a implantação Canary pode ser considerada completa e todo o tráfego é redirecionado para v2:

Testando Canary manualmente

Digamos que agora enviamos 2% de todas as solicitações para o backend v10. E se quisermos testar manualmente a v2 para ter certeza de que tudo funciona como esperamos?

Podemos adicionar uma regra de correspondência especial baseada em cabeçalhos HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Agora, usando curl, podemos forçar uma solicitação v2 enviando o cabeçalho:

Solicitações sem cabeçalho ainda serão impulsionadas pela proporção de 1/10:

Canário para duas versões dependentes

Agora consideraremos a opção onde temos a versão v2 tanto para frontend quanto para backend. Para ambos, especificamos que 10% do tráfego deveria ir para v2:

Vemos que o frontend v1 e v2 encaminham o tráfego em uma proporção de 1/10 para o backend v1 e v2.

E se precisássemos encaminhar o tráfego do frontend-v2 apenas para o backend-v2 porque ele não é compatível com a v1? Para fazer isso, definiremos uma proporção de 1/10 para o frontend, que controla qual tráfego chega ao backend-v2 usando negociação sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Como resultado, obtemos o que precisamos:

Diferenças da abordagem manual Canary

В a primeira parte Realizamos a implantação Canary manualmente, também usando duas implantações k8s. Lá controlamos a proporção de solicitações alterando o número de réplicas. Essa abordagem funciona, mas tem sérias desvantagens.

O Istio permite determinar a proporção de solicitações independentemente do número de réplicas. Isso significa, por exemplo, que podemos usar HPAs (Horizontal Pod Autoscalers) e não precisamos ser configurados de acordo com o estado atual da implantação Canary.

Total

O Istio funciona muito bem e usá-lo junto com o Kiali cria uma combinação muito poderosa. O próximo passo na minha lista de interesses é combinar Spinnaker com Istio para automação e análise Canary.

Fonte: habr.com