ProHoster > Blog > Administración > Despliegues automáticos de canarias con Flagger e Istio

Despliegues automáticos de canarias con Flagger e Istio

Despliegues automáticos de canarias con Flagger e Istio

O CD é recoñecido como unha práctica de software empresarial e é o resultado dunha evolución natural dos principios establecidos de CI. Non obstante, o CD aínda é bastante raro, quizais debido á complexidade da xestión e ao medo a que as implantacións fallidas afecten á dispoñibilidade do sistema.

Flager é un operador de Kubernetes de código aberto que pretende eliminar relacións confusas. Automatiza a promoción dos despregamentos canarios mediante a compensación de tráfico de Istio e as métricas de Prometheus para analizar o comportamento das aplicacións durante un lanzamento xestionado.

A continuación móstrase unha guía paso a paso para configurar e usar Flagger en Google Kubernetes Engine (GKE).

Configurando un clúster de Kubernetes

Comeza por crear un clúster de GKE co complemento Istio (se non tes unha conta de GCP, podes rexistrarte aquí - para conseguir créditos gratis).

Inicia sesión en Google Cloud, crea un proxecto e activa a facturación. Instala a utilidade de liña de comandos gcloud e configura o teu proxecto con gcloud init.

Establece o proxecto predeterminado, a área de cálculo e a zona (substituír PROJECT_ID para o teu proxecto):

gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

Activa o servizo GKE e crea un clúster con complementos HPA e Istio:

gcloud services enable container.googleapis.com
K8S_VERSION=$(gcloud beta container get-server-config --format=json | jq -r '.validMasterVersions[0]')
gcloud beta container clusters create istio 
--cluster-version=${K8S_VERSION} 
--zone=us-central1-a 
--num-nodes=2 
--machine-type=n1-standard-2 
--disk-size=30 
--enable-autorepair 
--no-enable-cloud-logging 
--no-enable-cloud-monitoring 
--addons=HorizontalPodAutoscaling,Istio 
--istio-config=auth=MTLS_PERMISSIVE

O comando anterior creará un grupo de nodos predeterminado que inclúe dúas máquinas virtuales n1-standard-2 (vCPU: 2, RAM 7,5 GB, disco: 30 GB). Idealmente, debería illar os compoñentes de Istio das súas cargas de traballo, pero non hai un xeito sinxelo de executar Istio Pods nun grupo dedicado de nós. Os manifestos de Istio considéranse de só lectura e GKE desfará calquera cambio, como a ligazón a un nodo ou a separación dun pod.

Configura as credenciais para kubectl:

gcloud container clusters get-credentials istio

Crear un enlace de rol de administrador de clúster:

kubectl create clusterrolebinding "cluster-admin-$(whoami)" 
--clusterrole=cluster-admin 
--user="$(gcloud config get-value core/account)"

Instala a ferramenta de liña de comandos Leme:

brew install kubernetes-helm

Homebrew 2.0 agora tamén está dispoñible para Linux.

Crea unha conta de servizo e unha ligazón de rol de clúster para Tiller:

kubectl -n kube-system create sa tiller && 
kubectl create clusterrolebinding tiller-cluster-rule 
--clusterrole=cluster-admin 
--serviceaccount=kube-system:tiller

Expande Tiller no espazo de nomes kube-system:

helm init --service-account tiller

Deberías considerar usar SSL entre Helm e Tiller. Para obter máis información sobre como protexer a súa instalación de Helm, consulte docs.helm.sh

Confirmar a configuración:

kubectl -n istio-system get svc

Despois duns segundos, GCP debería asignar un enderezo IP externo para o servizo istio-ingressgateway.

Configuración do Istio Ingress Gateway

Crea un enderezo IP estático cun nome istio-gatewayusando o enderezo IP da pasarela de Istio:

export GATEWAY_IP=$(kubectl -n istio-system get svc/istio-ingressgateway -ojson | jq -r .status.loadBalancer.ingress[0].ip)
gcloud compute addresses create istio-gateway --addresses ${GATEWAY_IP} --region us-central1

Agora necesitas un dominio de internet e acceso ao teu rexistrador de DNS. Engade dous rexistros A (substituír example.com ao teu dominio):

istio.example.com   A ${GATEWAY_IP}
*.istio.example.com A ${GATEWAY_IP}

Verifique que o comodín DNS funciona:

watch host test.istio.example.com

Cree unha pasarela de Istio xenérica para proporcionar servizos fóra da malla de servizos a través de HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"

Garda o recurso anterior como public-gateway.yaml e despois aplícao:

kubectl apply -f ./public-gateway.yaml

Ningún sistema de produción debería ofrecer servizos en Internet sen SSL. Para protexer a pasarela de entrada de Istio con cert-manager, CloudDNS e Let's Encrypt, lea documentación Bandeira G.K.E.

Instalación de indicadores

O complemento de GKE Istio non inclúe unha instancia de Prometheus que limpe o servizo de telemetría de Istio. Dado que Flagger usa as métricas HTTP de Istio para realizar análises canarias, cómpre implementar a seguinte configuración de Prometheus, similar á que inclúe o esquema oficial de Istio Helm.

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/gke/istio-prometheus.yaml

Engade o repositorio de Flagger Helm:

helm repo add flagger [https://flagger.app](https://flagger.app/)

Expande o indicador ao espazo de nomes istio-systemactivando as notificacións de Slack:

helm upgrade -i flagger flagger/flagger 
--namespace=istio-system 
--set metricsServer=http://prometheus.istio-system:9090 
--set slack.url=https://hooks.slack.com/services/YOUR-WEBHOOK-ID 
--set slack.channel=general 
--set slack.user=flagger

Podes instalar Flagger en calquera espazo de nomes sempre que poida comunicarse co servizo Istio Prometheus no porto 9090.

Flagger ten un panel de control de Grafana para a análise de canarias. Instala Grafana no espazo de nomes istio-system:

helm upgrade -i flagger-grafana flagger/grafana 
--namespace=istio-system 
--set url=http://prometheus.istio-system:9090 
--set user=admin 
--set password=change-me

Expón Grafana a través dunha pasarela aberta creando un servizo virtual (substituír example.com ao teu dominio):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grafana
  namespace: istio-system
spec:
  hosts:
    - "grafana.istio.example.com"
  gateways:
    - public-gateway.istio-system.svc.cluster.local
  http:
    - route:
        - destination:
            host: flagger-grafana

Garda o recurso anterior como grafana-virtual-service.yaml e despois aplícao:

kubectl apply -f ./grafana-virtual-service.yaml

Ao mudarse a http://grafana.istio.example.com no navegador, deberías dirixirte á páxina de inicio de sesión de Grafana.

Implantación de aplicacións web con Flagger

Flagger implementa Kubernetes e, opcionalmente, escala automaticamente (HPA) e despois crea unha serie de obxectos (implementacións de Kubernetes, servizos ClusterIP e servizos virtuais Istio). Estes obxectos expoñen a aplicación á malla de servizo e controlan a análise e o progreso canario.

Despliegues automáticos de canarias con Flagger e Istio

Cree un espazo de nomes de proba coa inxección Istio Sidecar activada:

REPO=https://raw.githubusercontent.com/stefanprodan/flagger/master
kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml

Crea unha implementación e unha ferramenta de escala automática do pod:

kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml
kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml

Implementa un servizo de carga de proba para xerar tráfico durante a análise canaria:

helm upgrade -i flagger-loadtester flagger/loadtester 
--namepace=test

Crear un recurso canario personalizado (substituír example.com ao teu dominio):

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
  canaryAnalysis:
    interval: 30s
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: istio_requests_total
      threshold: 99
      interval: 30s
    - name: istio_request_duration_seconds_bucket
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

Garda o recurso anterior como podinfo-canary.yaml e despois aplícao:

kubectl apply -f ./podinfo-canary.yaml

A análise anterior, se ten éxito, executarase durante cinco minutos, comprobando as métricas HTTP cada medio minuto. Podes determinar o tempo mínimo necesario para validar e promover un despregamento canario mediante a seguinte fórmula: interval * (maxWeight / stepWeight). Os campos CRD de Canary están documentados aquí.

Despois dun par de segundos, Flagger creará obxectos canarios:

# applied 
deployment.apps/podinfo
horizontalpodautoscaler.autoscaling/podinfo
canary.flagger.app/podinfo
# generated 
deployment.apps/podinfo-primary
horizontalpodautoscaler.autoscaling/podinfo-primary
service/podinfo
service/podinfo-canary
service/podinfo-primary
virtualservice.networking.istio.io/podinfo

Abre un navegador e vai a app.istio.example.com, deberías ver o número de versión aplicacións de demostración.

Análise e promoción automática de canarios

Flagger implementa un bucle de control que move gradualmente o tráfico ao canario mentres mide as métricas clave de rendemento, como a taxa de éxito das solicitudes HTTP, a duración media das solicitudes e a saúde do pod. En base á análise de KPI, o canario é promovido ou interrompido e os resultados da análise publícanse en Slack.

Despliegues automáticos de canarias con Flagger e Istio

O despregamento de Canary desenvólvese cando cambia un dos seguintes obxectos:

  • Implementar PodSpec (imaxe do contedor, comando, portos, env, etc.)
  • Os ConfigMaps son montados como volumes ou mapeados con variables de ambiente
  • Os segredos son montados como volumes ou convértense en variables de ambiente

Executa canary deploy ao actualizar unha imaxe de contedor:

kubectl -n test set image deployment/podinfo 
podinfod=quay.io/stefanprodan/podinfo:1.4.1

Flagger detecta que a versión de implementación cambiou e comeza a analizala:

kubectl -n test describe canary/podinfo

Events:

New revision detected podinfo.test
Scaling up podinfo.test
Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Advance podinfo.test canary weight 20
Advance podinfo.test canary weight 25
Advance podinfo.test canary weight 30
Advance podinfo.test canary weight 35
Advance podinfo.test canary weight 40
Advance podinfo.test canary weight 45
Advance podinfo.test canary weight 50
Copying podinfo.test template spec to podinfo-primary.test
Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
Promotion completed! Scaling down podinfo.test

Durante a análise, pódense rastrexar os resultados de Canary usando Grafana:

Despliegues automáticos de canarias con Flagger e Istio

Ten en conta que se se aplican novos cambios a unha implantación durante a análise canaria, Flagger reiniciará a fase de análise.

Fai unha lista de todos os canarios do teu grupo:

watch kubectl get canaries --all-namespaces
NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
test        podinfo   Progressing   15       2019-01-16T14:05:07Z
prod        frontend  Succeeded     0        2019-01-15T16:15:07Z
prod        backend   Failed        0        2019-01-14T17:05:07Z

Se activaches as notificacións de Slack, recibirás as seguintes mensaxes:

Despliegues automáticos de canarias con Flagger e Istio

Reversión automática

Durante a análise canaria, pode xerar erros HTTP 500 sintéticos e unha alta latencia de resposta para ver se Flagger deterá a implantación.

Crea un pod de proba e fai o seguinte nel:

kubectl -n test run tester 
--image=quay.io/stefanprodan/podinfo:1.2.1 
-- ./podinfo --port=9898
kubectl -n test exec -it tester-xx-xx sh

Xerando erros HTTP 500:

watch curl http://podinfo-canary:9898/status/500

Xeración atrasada:

watch curl http://podinfo-canary:9898/delay/1

Cando o número de comprobacións erradas alcanza o limiar, o tráfico envíase de volta á canle principal, o canario escalase a cero e a implantación márcase como fallida.

Os erros canarios e os picos de latencia rexistrados como eventos de Kubernetes e Flagger rexistrados en formato JSON:

kubectl -n istio-system logs deployment/flagger -f | jq .msg

Starting canary deployment for podinfo.test
Advance podinfo.test canary weight 5
Advance podinfo.test canary weight 10
Advance podinfo.test canary weight 15
Halt podinfo.test advancement success rate 69.17% < 99%
Halt podinfo.test advancement success rate 61.39% < 99%
Halt podinfo.test advancement success rate 55.06% < 99%
Halt podinfo.test advancement success rate 47.00% < 99%
Halt podinfo.test advancement success rate 37.00% < 99%
Halt podinfo.test advancement request duration 1.515s > 500ms
Halt podinfo.test advancement request duration 1.600s > 500ms
Halt podinfo.test advancement request duration 1.915s > 500ms
Halt podinfo.test advancement request duration 2.050s > 500ms
Halt podinfo.test advancement request duration 2.515s > 500ms
Rolling back podinfo.test failed checks threshold reached 10
Canary failed! Scaling down podinfo.test

Se activaches as notificacións de Slack, recibirás unha mensaxe cando se supere o prazo ou se alcance o número máximo de comprobacións erradas na análise:

Despliegues automáticos de canarias con Flagger e Istio

En conclusión

A execución dunha malla de servizo como Istio ademais de Kubernetes proporcionará métricas, rexistros e protocolos automáticos, pero a implantación da carga de traballo aínda depende de ferramentas externas. Flagger pretende cambiar isto engadindo as capacidades de Istio entrega progresiva.

Flagger é compatible con calquera solución de CI/CD de Kubernetes, e a análise Canary pódese ampliar facilmente webhooks para realizar probas de integración/aceptación do sistema, probas de carga ou calquera outra comprobación personalizada. Dado que Flagger é declarativo e responde aos eventos de Kubernetes, pódese usar en canalizacións de GitOps xunto con Tecido Fluxo ou Jenkins X. Se está a usar JenkinsX, pode instalar Flagger con complementos jx.

Marcador compatible Tecidos e ofrece despregamentos canarios en Weave Cloud. O proxecto estase probando en GKE, EKS e bare metal con kubeadm.

Se tes suxestións para mellorar Flagger, envía un problema ou PR en GitHub en stefanprodan/flagger. As contribucións son máis que benvidas!

Grazas Ray Tsang.

Fonte: www.habr.com

Engadir un comentario