Implementación de Canary en Kubernetes #3: Istio

Usando Istio+Kiali para lanzar e visualizar un despregue Canary

Artigos desta serie

1. Implementación de Canary en Kubernetes #1: Gitlab CI
2. Implementación de Canary en Kubernetes #2: Lanzamentos de Argo
3. (Este artigo)
4. Implementación de Canary usando Jenkins-X Istio Flagger

Despliegue Canario

Esperamos que leas primeira parte, onde explicamos brevemente o que son os despregamentos de Canary e mostramos como implementalos mediante os recursos estándar de Kubernetes.

Istio

E supoñemos que ao ler este artigo xa sabes o que é Istio. Se non, podes ler sobre iso aquí.

Solicitude de probas

Cada pod contén dous contedores: a nosa aplicación e istio-proxy.

Usaremos unha aplicación de proba sinxela con frontend-nginx e pods python de backend. O pod nginx simplemente redirixirá cada solicitude ao pod de backend e funcionará como proxy. Os detalles pódense atopar nos seguintes yamls:

• frontend.yaml
• backend.yaml
• istio.yaml

Executar a aplicación de proba vostede mesmo

Se queres seguir o meu exemplo e usar ti mesmo esta aplicación de proba, consulta proxecto readme.

Implementación Inicial

Cando lanzamos a primeira implementación, vemos que os pods da nosa aplicación teñen só 2 contedores, é dicir, o sidecar de Istio está a ser implementado:

E tamén vemos Istio Gateway Loadbalancer no espazo de nomes istio-system:

Xeración de tráfico

Usaremos a seguinte IP para xerar tráfico que será recibido polos pods frontend e reenviado aos pods backend:

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

Tamén engadiremos frontend.istio-test ao noso ficheiro hosts.

Ver Mesh a través de Kiali

Instalamos a aplicación de proba e Istio xunto con Tracing, Grafana, Prometheus e Kiali (consulta a continuación para máis detalles). proxecto readme). Polo tanto, podemos usar Kiali a través de:

istioctl dashboard kiali # admin:admin

Kiali visualiza o tráfico actual a través de Mesh

Como podemos ver, o 100% do tráfico vai ao servizo frontend, despois aos pods frontend coa etiqueta v1, xa que estamos a usar un simple proxy nginx que redirixe as solicitudes ao servizo backend, que á súa vez as redirixe aos pods backend. coa etiqueta v1.

Kiali funciona moi ben con Istio e ofrece unha solución de renderizado de malla en caixa. Simplemente xenial.

Despliegue Canario

O noso backend xa ten dous despregamentos de k8s, un para v1 e outro para v2. Agora só necesitamos dicirlle a Istio que reenvíe unha determinada porcentaxe de solicitudes á versión 2.

Paso 1: 10%

E todo o que temos que facer é axustar o peso do VirtualService 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 o 10 % das solicitudes son redirixidas á versión 2.

Paso 2: 50%

E agora basta con aumentalo ata o 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

Paso 3: 100%

Agora a implementación de Canary pódese considerar completa e todo o tráfico redirixiuse á versión 2:

Probando Canary manualmente

Digamos que agora enviamos o 2 % de todas as solicitudes ao backend v10. E se queremos probar manualmente v2 para asegurarnos de que todo funciona como esperamos?

Podemos engadir unha regra de coincidencia especial baseada en cabeceiras 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 forzar unha solicitude v2 enviando a cabeceira:

As solicitudes sen cabeceira seguirán sendo dirixidas pola proporción de 1/10:

Canary para dúas versións dependentes

Agora consideraremos a opción onde temos a versión v2 tanto para o frontend como para o backend. Para ambos, especificamos que o 10% do tráfico debería ir á v2:

Vemos que o frontend v1 e v2 ambos o tráfico de reenvío nunha proporción de 1/10 ao backend v1 e v2.

E se necesitásemos reenviar o tráfico de frontend-v2 só a backend-v2 porque non é compatible con v1? Para iso, estableceremos unha relación de 1/10 para o frontend, que controla o tráfico que chega ao backend-v2 mediante a negociación. 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 necesitamos:

Diferenzas co enfoque manual canario

В a primeira parte Realizamos o despregamento de Canary manualmente, utilizando tamén dous despregamentos de k8s. Alí controlamos a proporción de solicitudes cambiando o número de réplicas. Este enfoque funciona, pero ten serios inconvenientes.

Istio permite determinar a proporción de solicitudes independentemente do número de réplicas. Isto significa, por exemplo, que podemos usar HPA (Horizontal Pod Autoscalers) e non precisan estar configurados segundo o estado actual do despregamento de Canary.

Total

Istio funciona moi ben e usalo xunto con Kiali fai unha combinación moi poderosa. O seguinte na miña lista de intereses é a combinación de Spinnaker con Istio para automatización e análise de Canary.

Fonte: www.habr.com