Ahoj! Jsem

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Kontaktujte Mě

O Mně

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Mé Dovednosti

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automatizace Procesů

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Systémy na Míru

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

Mé Poslání

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Demokratizovat Technologie

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Propojení IT a Ekonomiky

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Tvorba Řešení na Míru

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Transformujte Své Podnikání Technologiemi

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Pojďme si Promluvit →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Kontaktujte Mě

Máte projekt na mysli? Pojďme si promluvit! Vyplňte formulář a brzy se ozvu.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

Service Mesh: Istio vs Linkerd, mTLS a Traffic Management

V architektuře mikroslužeb na Kubernetes každá služba komunikuje s desítkami dalších. Kdo zaručuje, že tato komunikace je šifrovaná? Kdo spravuje automatické opakování kdy služba je dočasně nedostupná? Kdo poskytuje metriky latence a rychlosti chyby pro každý pár zdroj-cíl? Odpovězte bez servisní sítě otázky vyžadují vlastní kód v každé službě.

Un servisní síť řeší tyto problémy na úrovni infrastruktury, transparentní pro aplikaci. Dva dominantní hráči v prostředí Kubernetes jsou Istio, nejbohatší na funkce a Linkerd, navrženo pro jednoduchost a minimální režii. Tento článek ukazuje, jak nainstalovat jak konfigurovat automatické mTLS, spravovat provoz s nasazením canary a přerušení obvodu a kdy zvolit jedno nebo druhé.

Co se naučíte

Jak funguje síť služeb: datová rovina (sidecar) a řídicí rovina
Automatické mTLS: co to znamená, jak to zkontrolovat, jak zacházet s výjimkami
Istio: instalace, VirtualService, DestinationRule, canary a blue/green
Linkerd: lehká instalace, SMI TrafficSplit, rozšíření
Přerušení obvodu pomocí Istio OutlierDetection
Opakujte pokus a časový limit na úrovni infrastruktury
Pozorovatelnost: metriky zlatých signálů ze sítě služeb
Istio vs Linkerd: kdy si vybrat který z nich

Jak funguje servisní síť

Servisní síť je založena na automatickém vstřikování a sidecar proxy (Vyslanec pro Istio, Linkerd2-proxy pro Linkerd) v každém modulu. Sajdkára vše zachytí provoz do az aplikačního kontejneru bez nutnosti změn ke kódu.

Il datová rovina a sadu všech proxy postranních vozíků, které obsluhují provoz efektivní. The řídicí rovina (Istiod pro Istio, linkerd-control-plane pro Linkerd) distribuuje konfiguraci serverům proxy, spravuje certifikáty pro mTLS a shromažďuje telemetrii.

Srovnání Istio vs Linkerd

Charakteristický	Istio	Linkerd
Sidecar proxy	Envoy (C++, 50–100 MB)	linkerd2-proxy (Rust, 10-20 MB)
Režie paměti pro Pod	100-200 MB	20-30 MB
Režie latence P99	2-5 ms	0,5-1 ms
Automatické mTLS	Ano (správce certifikátů nebo vestavěný)	Ano (24h automatické otáčení)
Řízení dopravy	Úplné (virtuální služba, DR)	Základní (HTTPRoute, TrafficSplit)
Zásady L7	HTTP, gRPC, TCP	HTTP, gRPC
Vjezd	API Gateway + Istio Gateway	Brána API
Křivka učení	Strmé	Mírný
Výrobní zralost	Vysoká (Google, Airbnb)	Vysoká (Shopify, Microsoft)

Istio: Základní instalace a konfigurace

Instalace pomocí istioctl

# Scarica e installa istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.22.0 sh -
export PATH=$PWD/istio-1.22.0/bin:$PATH

# Installa Istio con profilo di produzione
istioctl install --set profile=production -y

# Il profilo production abilita:
# - HA con multiple repliche del control plane
# - Affinity rules per distribuire su nodi diversi
# - Risorse CPU/memoria adeguate
# - Solo le feature necessarie (no addon come Kiali, Jaeger)

# Abilita l'iniezione automatica del sidecar nel namespace
kubectl label namespace production istio-injection=enabled

# Verifica lo stato del mesh
istioctl proxy-status

# Analizza la configurazione per possibili problemi
istioctl analyze --namespace production

mTLS s Istio: PeerAuthentication and DestinationRule

Istio implementuje automatické mTLS mezi všemi vstřikovanými postranními vozíky. s PeerAuthentication lze provést prostřednictvím mTLS PŘÍSNÝ (vyžadováno) a jmenný prostor nebo celá úroveň sítě:

# mtls-strict.yaml
# Abilita mTLS STRICT per tutto il namespace production
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT  # DISABLE, PERMISSIVE, STRICT
---
# Eccezione: un servizio legacy che non ha sidecar
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: legacy-service-exception
  namespace: production
spec:
  selector:
    matchLabels:
      app: legacy-service
  mtls:
    mode: PERMISSIVE  # accetta anche connessioni plain-text

# Verifica mTLS
kubectl exec -n production frontend-pod -c istio-proxy -- \
  pilot-agent request GET /config_dump | grep -A5 "tls_context"

# Visualizza lo stato mTLS con istioctl
istioctl x describe pod frontend-pod.production

VirtualService: Směrování a rozdělování provozu

VirtualService definuje, jak je směrován provoz do služby, s pravidly založenými na HTTP hlavičkách, vahách, shodě cest:

# virtual-service-canary.yaml
# Canary deployment: 90% traffico a v1, 10% a v2
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-service-vs
  namespace: production
spec:
  hosts:
    - api-service  # nome del Kubernetes Service
  http:
    # Routing per header: dev e QA ricevono sempre v2
    - match:
        - headers:
            x-user-group:
              exact: "beta-testers"
      route:
        - destination:
            host: api-service
            subset: v2
    # Traffico generale: 90/10 split
    - route:
        - destination:
            host: api-service
            subset: v1
          weight: 90
        - destination:
            host: api-service
            subset: v2
          weight: 10
      # Timeout e retry a livello di infrastruttura
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: "5xx,reset,connect-failure,retriable-4xx"
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api-service-dr
  namespace: production
spec:
  host: api-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    loadBalancer:
      simple: LEAST_CONN  # ROUND_ROBIN, RANDOM, LEAST_CONN
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Jistič s OutlierDetection

Jistič dočasně odstraní "nezdravé" hostitele z vyrovnávání zátěže fond, když překročí definované prahové hodnoty chyb:

# destination-rule-circuit-breaker.yaml
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payment-service-circuit-breaker
  namespace: production
spec:
  host: payment-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 50
        connectTimeout: 3s
      http:
        http1MaxPendingRequests: 100
        http2MaxRequests: 500
        maxRetries: 3
    outlierDetection:
      # Rimuovi un host se in 10 secondi riceve 5 errori 5xx
      consecutiveGatewayErrors: 5
      consecutive5xxErrors: 5
      interval: 10s
      # Tienilo fuori per 30 secondi
      baseEjectionTime: 30s
      # Massimo 50% degli host puo essere rimosso
      maxEjectionPercent: 50
      # Analizza solo richieste con 100ms o piu di latenza
      minHealthPercent: 50

Brána Istio pro příchozí provoz

# istio-gateway.yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: wildcard-tls-cert  # Secret con cert TLS
      hosts:
        - "*.federicocalo.dev"
    - port:
        number: 80
        name: http
        protocol: HTTP
      tls:
        httpsRedirect: true  # redirect tutto HTTP a HTTPS
      hosts:
        - "*.federicocalo.dev"
---
# Collega il Gateway al VirtualService
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api-gateway-vs
  namespace: production
spec:
  hosts:
    - "api.federicocalo.dev"
  gateways:
    - istio-system/production-gateway
    - mesh  # anche per traffico interno al mesh
  http:
    - route:
        - destination:
            host: api-service
            port:
              number: 8080

AuthorizationPolicy: Řízení přístupu

# authorization-policy.yaml
# Solo il frontend puo chiamare il backend
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-access-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/frontend-service-account"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/*"]
---
# Blocca tutto il resto (default deny)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: DENY
  # Nessun selector = si applica a tutti i Pod nel namespace
  # Nessuna rule = blocca tutto

Linkerd: Instalace a konfigurace

Linkerd upřednostňuje provozní jednoduchost a výkon. Jeho proxy napsaná v Rustu Má režii ~1ms latence P99 a ~20MB paměti na modul, takže je ideální pro clustery s mnoha mikroslužbami nebo omezeními zdrojů.

Instalace Linkerd

# Installa Linkerd CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH

# Prerequisiti: verifica che il cluster sia compatibile
linkerd check --pre

# Installa il control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Verifica installazione
linkerd check

# Abilita injection sul namespace
kubectl annotate namespace production linkerd.io/inject=enabled

# Installa l'estensione Viz per osservabilita
linkerd viz install | kubectl apply -f -
linkerd viz check
linkerd viz dashboard &

Canary s Linkerd a HTTPRoute (Gateway API)

# linkerd-canary-httproute.yaml
# Linkerd usa la Gateway API per il traffic splitting
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-service-canary
  namespace: production
spec:
  parentRefs:
    - name: api-service
      kind: Service
      group: core
      port: 80
  rules:
    - backendRefs:
        - name: api-service-v1
          port: 80
          weight: 90
        - name: api-service-v2
          port: 80
          weight: 10

# Monitora il canary con linkerd viz
linkerd viz stat httproute/api-service-canary -n production
linkerd viz routes deploy/api-service-v2 -n production

Pozorovatelné pomocí Linkerd

# Visualizza metriche golden signals per tutti i deployment
linkerd viz stat deploy -n production

# Output tipico:
# NAME              MESHED   SUCCESS     RPS   LATENCY_P50   LATENCY_P99   TCP_CONN
# api-service       4/4      99.8%       245   1ms           12ms          42
# backend-service   3/3      98.2%       180   3ms           45ms          28
# payment-service   2/2      100.0%      65    8ms           89ms          12

# Visualizza il traffico per un singolo Pod
linkerd viz tap pod/api-service-xyz -n production

# Genera un report di osservabilita
linkerd viz check --proxy -n production

Telemetrie Istio: Metriky, sledování a protokolování

Istio automaticky vydává zlaté signály (latence, provoz, chyby, saturace) pro každý pár zdroj-cíl. Metriky jsou vystaveny ve formátu Prometheus a viditelné v Grafaně s oficiálními panely Istio.

# telemetry-config.yaml
# Configura il sampling per il distributed tracing
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-tracing
  namespace: istio-system
spec:
  tracing:
    - providers:
        - name: tempo  # o jaeger, zipkin
      randomSamplingPercentage: 1.0  # campiona 1% del traffico in produzione
---
# Metriche custom per un servizio specifico
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: payment-service-metrics
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  metrics:
    - providers:
        - name: prometheus
      overrides:
        - match:
            metric: REQUEST_COUNT
          tagOverrides:
            destination_version:
              value: "request.headers['x-version'] | 'unknown'"

# Importa le dashboard Grafana ufficiali Istio
# Dashboard ID: 7639 (Mesh Overview), 11829 (Service), 12378 (Workload)

Service Mesh vs Cilium eBPF: Kdy je použít

S příchodem Cilium, které nabízí mTLS a L7 politiky bez sidecarů (přes eBPF v jádře), výběr je složitý. Zde je praktický návod:

Scénář	Doporučená volba	Důvod
Mikroslužby s pokročilou správou provozu (kanárek, směrování založené na hlavičkách)	Istio	VirtualService/DestinationRule nenahraditelné
Zabezpečení mTLS s minimální režií	Linkerd nebo Cilium	Rust proxy nebo minimální eBPF
Cluster se stovkami mikroslužeb, omezené zdroje	Linkerd nebo Cilium mTLS	Horní postranní vozík vynásobený každým modulem
Multi-cluster nebo multi-cloud	Istio	Vestavěná síťová federace
Tým nový servisní síť	Linkerd	Výrazně nižší křivka učení

Nejlepší postupy pro Service Mesh

Kontrolní seznam pro Service Mesh ve výrobě

Spusťte v POVOLENÉM režimu: povolit mTLS v POVOLENÉM režimu, než jej zpřísníte, aby bylo možné identifikovat služby, které ještě nemají postranní vozík
Nastavit časový limit pro všechny virtuální služby: bez časového limitu blokuje pomalá závislost celý řetězec volání
Jistič pro každou externí závislost: databáze, externí API, platební služby
Používejte opakování pouze pro idempotentní chyby: neprovádějte automatické opakování POST bez klíče idempotency, jinak vytvoříte duplicitní objednávky
Monitorování postranního vozíku CPU/paměti: ve skupinách s mnoha moduly může být celkový postranní vozík nad hlavou významný
Testovat převzetí služeb při selhání: ručně deaktivujte modul a ověřte, že jistič a opakování fungují podle očekávání
Udržujte síť aktualizovanou: Verze Istio a Linkerd mají krátké životní cykly (6-12 měsíců); plan regular upgrades

Běžné anti-vzory

Nekonečné opakování se zesílením: pokud A odvolá B se 3 opakováními a B odvolá C se 3 opakováními, jediná chyba vygeneruje 9 pokusů směrem k C (bouře opakování)
Příliš velkorysé časové limity: 60sekundový časový limit na kritickém API znamená, že během výpadku jsou všechna aplikační vlákna/goroutíny zablokována na 60s
Ignorování řídicí roviny nad hlavou: Istiod spotřebovává značné množství CPU/paměti pro každý připojený proxy; v clusterech s více než 1000 moduly je potřeba vyhrazený uzel
Selektivní vstřikování bez roviny: pokud mají postranní vozíky pouze některé moduly, mTLS STRICT selže při komunikaci s moduly bez postranních vozíků

Závěry a další kroky

Servisní síť přestala být „příjemnou věcí“ a stala se požadavkem jakákoli seriózní architektura mikroslužeb. Automatické mTLS, granulární pozorovatelnost, přerušení obvodu a deklarativní řízení provozu řeší skutečné problémy bez síť služeb by vyžadovala vlastní kód v každé službě.

Volba mezi Istio a Linkerd závisí na vašich potřebách: Istio pro složité scénáře s pokročilá a multi-clusterová správa provozu, Linkerd pro provozní jednoduchost a režii minimální. V obou případech jde o počáteční investici do učení a nastavení a vyplatilo se to snížením kódu infrastruktury v aplikacích a viditelnosti bezprecedentní dopad na provoz uvnitř klastru.

Připravované články v sérii Kubernetes at Scale

Předchozí články

Související série

Kubernetes Networking: Cilium s eBPF — alternativa k servisní síti pro mTLS
Pozorovatelnost a OpenTelemetry — distribuované sledování integrované s Istio
Platform Engineering — servisní síť jako vnitřní platforma