DA MASER A MONFUMO | MOTO GUZZI V85TT | PURE SOUND POV 4K

🏍️ Il mio nuovo canale YouTube: giri in moto in POV, solo audio, tra le Dolomiti in 4K. Niente musica, niente parole — solo il motore e le Alpi. Vieni a fare un giro!

▶ Iscriviti

Di recente ho dato un piccolo contributo a Istio, un progetto open-source di service mesh. Il mio contributo ha riguardato l'aggiunta di alcuni test per uno dei comandi della CLI di Istio. Se volete vedere i dettagli, potete trovare la pull request qui. Non è stata una modifica enorme, ma è stata un'ottima esperienza di apprendimento. Lavorare su Istio mi ha aiutato a capire i service mesh a un livello più profondo. Sono entusiasta di contribuire ancora di più. In questo post, spiegherò cos'è Istio, perché è utile e come funziona.

Cos'è Istio?

Nella sua essenza, Istio è un service mesh. Un service mesh gestisce la comunicazione tra microservizi, occupandosi di cose come l'instradamento del traffico, la sicurezza delle comunicazioni e l'osservabilità. Man mano che i microservizi crescono di numero, gestire queste interazioni può diventare complicato. Istio automatizza molte di queste operazioni, in modo che possiate concentrarvi sulla costruzione della vostra applicazione invece di gestire la comunicazione servizio-servizio.

Perché Usare Istio?

Man mano che la vostra architettura diventa più complessa, dovrete affrontare nuove sfide. I servizi devono comunicare in modo affidabile, sicuro ed efficiente. Istio vi aiuta a farlo in tre aree chiave:

  1. Gestione del Traffico: Istio vi dà il controllo su come il traffico fluisce tra i servizi. Potete dividere il traffico tra diverse versioni di un servizio, reindirizzare le richieste durante i deployment, o configurare policy di retry e timeout.

  2. Sicurezza delle Comunicazioni: Istio rende facile abilitare il mutual TLS (mTLS). Questo garantisce che tutte le comunicazioni tra i servizi siano cifrate e autenticate, tenendo fuori i servizi non autorizzati.

  3. Osservabilità: Istio raccoglie automaticamente metriche, log e trace, dandovi visibilità in tempo reale sui vostri servizi. Questo aiuta con il monitoring, il troubleshooting e il tuning delle prestazioni.

Queste tre aree — gestione del traffico, sicurezza e osservabilità — sono fondamentali per gestire una sana architettura a microservizi, e Istio le gestisce con facilità.

Gestire il Traffico con Istio

Una delle funzionalità principali di Istio è la gestione del traffico tra i servizi. In una configurazione a microservizi, potreste avere più versioni di un servizio in esecuzione contemporaneamente. Per esempio, potreste stare testando una nuova versione del vostro servizio di pagamento e voler inviare la maggior parte del traffico alla versione 1, ma instradarne un po' alla versione 2.

Ecco un esempio di come potete usare Istio per dividere il traffico tra due versioni di un servizio:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payments
spec:
  hosts:
  - payments.myapp.com
  http:
  - route:
    - destination:
        host: payments
        subset: v1
      weight: 90
    - destination:
        host: payments
        subset: v2
      weight: 10

In questo esempio:

  • Il 90% del traffico viene inviato alla versione 1 del servizio payments, e il 10% alla versione 2.
  • Il campo hosts specifica il dominio per cui il virtual service è applicabile — in questo caso, payments.myapp.com.
  • Il blocco route definisce come il traffico viene suddiviso tra due subset del servizio: v1 (per la versione 1) e v2 (per la versione 2). Il campo weight controlla la distribuzione del traffico.

Questo è utile per i canary deployment, dove si testano nuove funzionalità con una piccola percentuale di utenti prima di rilasciarle completamente.

Envoy Proxy e Sidecar Container

Il data plane di Istio si basa sul proxy Envoy, un proxy di livello 7 che gestisce tutto il traffico tra i servizi. Ogni servizio nel mesh ha il proprio sidecar proxy, che si trova accanto al servizio e gestisce tutto il suo traffico in entrata e in uscita.

Envoy vi consente di applicare policy di traffico come retry, timeout e circuit breaking, tutto senza modificare il codice dell'applicazione. Raccoglie anche metriche dettagliate sul flusso del traffico, aiutando con il monitoring e il debugging.

Poiché Envoy gira come un sidecar container, può applicare queste regole e raccogliere dati senza interferire con la logica dell'applicazione. In breve, Envoy agisce come il "poliziotto del traffico" per tutte le comunicazioni nel service mesh.

Osservabilità: Vedere Cosa Sta Succedendo nel Sistema

Gestire un sistema con molti microservizi può rendere difficile capire cosa sta succedendo. Le funzionalità di osservabilità integrate di Istio vi aiutano a tracciare metriche, log e trace per tutte le comunicazioni tra i servizi. Questo è vitale per monitorare la salute del sistema, individuare problemi di prestazioni e correggere i bug.

Gli strumenti di osservabilità di Istio vi danno un quadro chiaro di come funziona il sistema. Potete rilevare i problemi in anticipo e far funzionare i vostri servizi in modo più fluido.

Sicurezza: Abilitare mTLS e Controllo degli Accessi

La sicurezza è una grande preoccupazione quando si gestiscono i microservizi. Istio rende facile implementare il mutual TLS (mTLS), che cifra tutte le comunicazioni tra i servizi e garantisce che i servizi si autentichino a vicenda prima di scambiarsi dati.

Istio vi consente anche di configurare policy di controllo degli accessi per specificare quali servizi sono autorizzati a comunicare. Questo aiuta a limitare quali servizi possono interagire, riducendo la superficie di attacco del sistema.

Ecco un esempio di policy Istio che consente solo al servizio billing di comunicare con il servizio payments:

yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-to-billing
spec:
  selector:
    matchLabels:
      app: payments
  rules:
  - from:
    - source:
        principals: ["billing.myapp.com"]

In questa policy:

  • Il selector specifica che questa regola si applica al servizio payments, usando il label app: payments.
  • Il blocco rules consente solo al servizio billing, identificato dal principal "billing.myapp.com", di comunicare con payments. Nessun altro servizio è autorizzato a inviare traffico a payments.

Questa policy limita tutti i servizi eccetto billing dall'accedere a payments, rafforzando la sicurezza dei vostri microservizi.

Cos'è SPIFFE?

Istio usa SPIFFE (Secure Production Identity Framework for Everyone) per gestire le identità dei servizi. SPIFFE fornisce un modo per assegnare identità sicure e verificabili ai servizi. Ogni servizio nel mesh ottiene un SPIFFE Verifiable Identity Document (SVID), che viene usato insieme a mTLS per garantire comunicazioni sicure. Questo sistema di identità è il fondamento del modello di sicurezza di Istio.

Networking in Istio

Il networking nei microservizi può essere difficile, soprattutto quando si tratta di controllare il traffico all'interno e all'esterno del mesh. Istio fornisce diversi strumenti per gestire il traffico di rete:

  1. Service Entry: Consente ai servizi esterni di comunicare con i servizi all'interno del mesh e viceversa.
  2. Virtual Service: Definisce come il traffico viene instradato all'interno del mesh.
  3. Destination Rule: Applica policy di traffico, come il load balancing o mTLS, ai servizi.
  4. Gateway: Gestisce il traffico in entrata e in uscita dal mesh.

Configurazione di Esempio: Gateway, Service Entry, Virtual Service e Destination Rule

Supponiamo di avere un server API all'interno del mesh che riceve traffico da Internet tramite un load balancer. Ecco come potete configurare un Gateway, Service Entry, Virtual Service e Destination Rule per gestire questo traffico.

Configurazione del Gateway

yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: api-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "api.myapp.com"

Cosa sta succedendo qui? Il Gateway ascolta sulla porta 80 per il traffico HTTP diretto al dominio api.myapp.com. Il campo selector collega questo Gateway all'ingress gateway di Istio, che gestisce il traffico in entrata nel mesh.

Configurazione del Service Entry

Supponiamo che il vostro server API debba chiamare un servizio di autenticazione esterno. Ecco come configurereste un Service Entry:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: auth-service-entry
spec:
  hosts:
  - "auth.external-service.com"
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  endpoints:
  - address: 203.0.113.1

Cosa sta succedendo qui? Il Service Entry dice a Istio come instradare il traffico verso un servizio esterno (auth.external-service.com), che gira sulla porta 443 (HTTPS). location: MESH_EXTERNAL indica che questo servizio esiste al di fuori del service mesh Istio. Il campo endpoints include l'indirizzo IP del servizio esterno, consentendo al server API all'interno del mesh di inviare richieste.

Configurazione del Virtual Service

Ecco come potete instradare il traffico all'interno del mesh:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: api-virtualservice
spec:
  hosts:
  - "api.myapp.com"
  gateways:
  - api-gateway
  http:
  - match:
    - uri:
        prefix: "/v1"
    route:
    - destination:
        host: api-service
        subset: stable

Cosa sta succedendo qui? Il Virtual Service definisce le regole di routing del traffico. In questo caso, il traffico che arriva a api.myapp.com/v1 attraverso l'api-gateway viene instradato all'api-service nel mesh. Il subset: stable si riferisce a una versione specifica dell'api-service (potete avere più versioni dello stesso servizio).

Configurazione della Destination Rule

Infine, ecco una Destination Rule per applicare il load balancing e mTLS:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: api-destination-rule
spec:
  host: api-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    tls:
      mode: ISTIO_MUTUAL

Cosa sta succedendo qui? La Destination Rule applica policy al traffico instradato all'api-service. Usa il load balancing round-robin per distribuire le richieste in modo uniforme tra le istanze. mTLS è abilitato con tls.mode: ISTIO_MUTUAL, garantendo comunicazioni cifrate tra i servizi.

Resilienza: Gestire i Fallimenti con Retry, Timeout e Circuit Breaker

Nei sistemi distribuiti, i fallimenti accadono. I servizi potrebbero andare giù, le reti potrebbero rallentare, o gli utenti potrebbero sperimentare ritardi. Istio vi aiuta a gestire questi problemi con retry, timeout e circuit breaker.

  • Retry: Riprova automaticamente le richieste fallite per gestire i fallimenti temporanei senza interrompere l'esperienza utente.
  • Timeout: Definisce quanto a lungo un servizio deve aspettare una risposta prima di rinunciare e andare avanti.
  • Circuit breaker: Se un servizio sta fallendo, Istio può smettere di inviare traffico ad esso, prevenendo i fallimenti a cascata che potrebbero abbattere altre parti del sistema.

Ecco un esempio di come configurare retry e timeout in Istio:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - route:
    - destination:
        host: my-service
    retries:
      attempts: 3
      perTryTimeout: 2s
    timeout: 5s

Cosa sta succedendo qui? Se una richiesta a my-service fallisce, Istio riproverà la richiesta fino a 3 volte. Ogni tentativo ha un limite di 2 secondi. Il tempo totale consentito per una richiesta è 5 secondi. Dopo di ciò, Istio smetterà di aspettare una risposta.

Per il circuit breaking, potete usare una Destination Rule come questa:

yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
    outlierDetection:
      consecutive5xxErrors: 2
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Cosa sta succedendo qui? Se my-service restituisce due errori 5xx consecutivi entro 10 secondi, Istio smetterà di inviare traffico ad esso. Il servizio verrà espulso dal pool di load balancing per 30 secondi prima di essere riconsiderato.

Istio è uno strumento potente che semplifica la gestione del traffico, la sicurezza e l'osservabilità per i microservizi. Contribuire a Istio mi ha dato una visione approfondita di come aiuta a risolvere alcune delle sfide complesse che si presentano nella gestione dei sistemi distribuiti.

Se state gestendo un'architettura a microservizi o pianificate di scalare, Istio può aiutarvi a rendere il sistema più resiliente e più facile da gestire. Se avete domande o volete saperne di più su Istio, non esitate a contattarmi — sarei felice di condividere quello che ho imparato.