<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with kubernetes]]></title><description><![CDATA[A list of topics that have been tagged with kubernetes]]></description><link>https://forum.androidiani.net/tags/kubernetes</link><generator>RSS for Node</generator><lastBuildDate>Tue, 26 May 2026 15:59:27 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/kubernetes.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 11 May 2026 15:14:34 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Kubernetes v1.36: Sharded List and Watch lato server per cluster ad alta scala]]></title><description><![CDATA[Con la crescita dei cluster Kubernetes verso decine di migliaia di nodi, i controller che osservano risorse ad alta cardinalità come i Pod si scontrano con un limite di scalabilità ben preciso. Kubernetes v1.36 introduce in alpha una soluzione elegante: il Server-Side Sharded List and Watch (KEP-5866), che sposta il filtraggio upstream nell’API server, riducendo drasticamente il traffico verso ogni replica di un controller.Il problema: scaling client-sideAlcuni controller, come kube-state-metrics, supportano già lo sharding orizzontale: ogni replica è assegnata a una porzione dello spazio delle chiavi e scarta gli oggetti che non le appartengono. Questo approccio funziona dal punto di vista della correttezza, ma non risolve il problema di scala:N repliche × stream completo: ogni replica deserializza ed elabora ogni evento, poi scarta ciò che non le competeLa banda di rete scala con le repliche, non con la dimensione dello shardCPU sprecata: il costo di deserializzazione è sostenuto per la frazione scartataIn sintesi, scalare orizzontalmente il controller moltiplica il costo per replica invece di ridurlo.La soluzione: sharding lato serverIl Server-Side Sharded List and Watch risolve il problema spostando il filtraggio nell’API server. Ogni replica comunica all’API server quale intervallo di hash è di sua competenza, e l’API server invia solo gli eventi corrispondenti.La feature aggiunge un campo shardSelector a ListOptions. I client specificano un intervallo di hash tramite la funzione shardRange():shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')L’API server calcola un hash FNV-1a a 64 bit deterministico del campo specificato e restituisce solo gli oggetti il cui hash ricade nell’intervallo [start, end). Questo vale sia per le risposte di list che per i flussi di eventi watch.La funzione di hash produce lo stesso risultato su tutte le istanze dell’API server, quindi la feature è sicura anche con più repliche dell’API server.I percorsi di campo attualmente supportati sono object.metadata.uid e object.metadata.namespace.Utilizzo pratico nei controllerI controller tipicamente usano informer per fare list e watch sulle risorse. Per fare lo sharding del carico, ogni replica inietta il shardSelector nelle ListOptions usate dai suoi informer tramite WithTweakListOptions:import (
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/client-go/informers"
)

shardSelector := "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

factory := informers.NewSharedInformerFactoryWithOptions(
    client,
    resyncPeriod,
    informers.WithTweakListOptions(func(opts *metav1.ListOptions) {
        opts.ShardSelector = shardSelector
    }),
)Per un deployment con 2 repliche, i selettori dividono lo spazio degli hash a metà:// Replica 0: metà inferiore dello spazio di hash
"shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"

// Replica 1: metà superiore dello spazio di hash
"shardRange(object.metadata.uid, '0x8000000000000000', '0x10000000000000000')"Una singola replica può anche coprire range non contigui usando ||:"shardRange(object.metadata.uid, '0x0000000000000000', '0x4000000000000000') || " +
"shardRange(object.metadata.uid, '0x8000000000000000', '0xc000000000000000')"Verificare che il server supporti il selettoreQuando l’API server onora un shard selector, la risposta list include un campo shardInfo nel metadata della risposta che riporta il selettore applicato:{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "10245",
    "shardInfo": {
      "selector": "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"
    }
  },
  "items": [ ... ]
}Se shardInfo è assente, il server non ha applicato il shard selector e il client ha ricevuto la collezione completa non filtrata. In questo caso, il client deve essere pronto a gestire il risultato completo — ad esempio applicando un filtraggio client-side per scartare gli oggetti fuori dal proprio shard.Come abilitarla e stato della featureQuesta feature è in alpha in Kubernetes v1.36 e richiede di abilitare il feature gate ShardedListAndWatch sull’API server:--feature-gates=ShardedListAndWatch=trueNon è ancora consigliata per ambienti di produzione, ma rappresenta un’opportunità preziosa per i team che gestiscono cluster di grandi dimensioni di iniziare i test e fornire feedback al SIG API Machinery.Implicazioni architetturaliL’impatto di questa feature va oltre la semplice riduzione del traffico di rete. Cambia il modello mentale con cui si progettano controller scalabili:Efficienza reale: il costo per replica diminuisce proporzionalmente al numero di shard, invece di aumentareScalabilità lineare: aggiungere repliche riduce effettivamente il carico su ciascunaSemplicità implementativa: lo sharding è dichiarativo — si specifica l’intervallo, l’API server fa il restoCompatibilità hash deterministica: FNV-1a garantisce distribuzione uniforme e risultati coerenti su più API serverConclusioniIl Server-Side Sharded List and Watch è una di quelle feature che risolvono un problema reale per chi opera cluster Kubernetes di grandi dimensioni. Spostare il filtraggio nell’API server è la scelta architetturalmente corretta: elimina il lavoro inutile alla radice invece di cercare di ottimizzarlo lato client.Per i controller author e gli operatori di cluster grandi, vale la pena iniziare a sperimentare con questa feature sin da ora, contribuendo feedback al team di SIG API Machinery tramite il canale #sig-api-machinery su Kubernetes Slack.Fonte originale: Kubernetes v1.36: Server-Side Sharded List and Watch — Kubernetes Blog, Jeffrey Ying]]></description><link>https://forum.androidiani.net/topic/a5e1b2ef-a013-48ac-9215-8ba2390c79e0/kubernetes-v1.36-sharded-list-and-watch-lato-server-per-cluster-ad-alta-scala</link><guid isPermaLink="true">https://forum.androidiani.net/topic/a5e1b2ef-a013-48ac-9215-8ba2390c79e0/kubernetes-v1.36-sharded-list-and-watch-lato-server-per-cluster-ad-alta-scala</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Mon, 11 May 2026 15:14:34 GMT</pubDate></item><item><title><![CDATA[Fine del supporto NGINX Ingress su AKS: guida alla migrazione verso Gateway API]]></title><description><![CDATA[Se gestisci workload su Azure Kubernetes Service (AKS), nelle ultime settimane potresti aver ricevuto un’email da Microsoft che annuncia la fine del supporto per NGINX Ingress su AKS entro novembre 2026. Non si tratta di una comunicazione da ignorare: la migrazione è inevitabile e conviene pianificarla per tempo. In questo articolo vediamo cosa sta succedendo, perché è successo e cosa fare concretamente.Il contesto: perché Ingress è diventato obsoletoLa risorsa Ingress di Kubernetes nasce con una specifica intenzionalmente minimale: regole di host e path, niente di più. Ma i load balancer cloud (AWS, Azure, GCP e altri) sono in grado di fare molto di più — timeout configurabili, retry policy, routing per header, circuit breaker — e gli utenti hanno cercato di esprimere queste funzionalità tramite annotation proprietarie sulle risorse Ingress. Il risultato è stato un’esplosione di annotation non standardizzate, specifiche per ogni controller, che rendono ogni configurazione di Ingress portabile solo sulla carta.Gateway API è la risposta della community a questo problema. Sostituisce Ingress con risorse strutturate e tipizzate — HTTPRoute, Gateway, GatewayClass — capaci di esprimere comportamenti di routing avanzati in modo nativo e standardizzato, con una separazione netta tra il ruolo del platform team (che gestisce i Gateway) e il ruolo del team applicativo (che gestisce le HTTPRoute). Gateway API è stabile dalla versione 1.28 di Kubernetes ed è la direzione verso cui si sta muovendo l’intero ecosistema.La fine di ingress-nginx e le conseguenze su AKSIl progetto upstream ingress-nginx — il controller Ingress più diffuso nell’ecosistema Kubernetes — è stato formalmente ritirato a marzo 2026. Il progetto era mantenuto da un esiguo gruppo di volontari, aveva accumulato debito tecnico significativo e presentava vulnerabilità di sicurezza note rimaste senza patch. Con il ritiro, qualsiasi nuova vulnerabilità scoperta rimarrà indefinitamente senza correzione.Microsoft ha fissato la propria data di fine supporto al novembre 2026, concedendo agli utenti AKS un margine aggiuntivo. Fino ad allora, le vulnerabilità critiche continueranno a essere corrette, ma non ci sarà sviluppo di nuove funzionalità.Chi è impattato e con quale urgenzaInstallazione self-managed via HelmSe hai installato ingress-nginx manualmente tramite Helm, sei esposto direttamente al ritiro upstream avvenuto a marzo 2026. Da quel momento, qualsiasi vulnerabilità nel controller resta senza patch: mantenerlo in produzione è un rischio di sicurezza crescente nel tempo.AKS Application Routing add-onSe usi l’add-on gestito di AKS abilitato con --enable-app-routing, hai tempo fino a novembre 2026. Microsoft garantisce patch per le vulnerabilità critiche fino a quella data. È un margine utile, ma non è una soluzione permanente.Altro controller Ingress (Traefik, Istio, HAProxy…)Se non usi NGINX Ingress, questo annuncio non ti impatta direttamente. Vale però la pena iniziare a familiarizzare con Gateway API, che è la direzione dell’intero ecosistema Kubernetes.Gateway API: il nuovo modello di risorseLa migrazione da Ingress a Gateway API cambia il modello di risorse con cui si lavora. Ecco un confronto diretto tra i due approcci.Una configurazione Ingress tipica con annotation NGINX:apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 80La configurazione equivalente con Gateway API:# Definito dal platform team (una volta sola)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-system
spec:
  gatewayClassName: azure-application-lb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
# Definito dal team applicativo
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: gateway-system
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-api
      port: 80Il vantaggio principale non è solo sintattico: la separazione tra Gateway e HTTPRoute permette al platform team di gestire centralmente le policy di sicurezza, TLS e throttling, mentre i team applicativi possono modificare le route senza toccare l’infrastruttura condivisa.Piano di migrazione consigliatoMicrosoft sta investendo nel supporto nativo di Gateway API nell’add-on Application Routing di AKS, con Azure Application Gateway for Containers (AGC) come backend raccomandato. I passi pratici per avviare la migrazione sono:Inventario: esegui kubectl get ingress -A -o yaml per elencare tutte le risorse Ingress e mappare le annotation nginx in uso nel cluster.Assessment delle annotation: identifica quali annotation hanno un equivalente nativo in Gateway API (la maggior parte) e quali richiedono configurazioni alternative (timeout avanzati, snippet custom).Ambiente di test: crea un cluster AKS di test con Gateway API abilitato e migra prima i workload meno critici per acquisire familiarità con il nuovo modello.Migrazione progressiva: usa la funzionalità di traffic splitting di HTTPRoute per spostare gradualmente il traffico dai vecchi Ingress alle nuove route, validando il comportamento prima di dismettere il vecchio controller.Cleanup: rimuovi le risorse Ingress e disabilita o disinstalla ingress-nginx una volta completata la validazione su tutti gli ambienti.ConclusioneLa fine di NGINX Ingress su AKS era prevedibile da quando il progetto upstream ha iniziato a mostrare segni di abbandono. La buona notizia è che Gateway API è tecnicamente superiore: più espressiva, più portabile, con una governance delle responsabilità più chiara tra platform team e team applicativi. Chi pianifica la migrazione adesso, con il margine di tempo concesso da Microsoft fino a novembre 2026, può affrontarla con calma. Chi aspetta l’ultimo momento si troverà a gestire una migrazione d’emergenza in un contesto di sicurezza degradante.La documentazione ufficiale di Gateway API è disponibile su gateway-api.sigs.k8s.io. La roadmap di AKS per Gateway API è tracciabile nelle release note del servizio Azure.Fonte: The End of NGINX Ingress on AKS: What You Need to Know – Trailhead Technology]]></description><link>https://forum.androidiani.net/topic/2edb772b-cd53-4a9f-97bd-82284bbbd1cf/fine-del-supporto-nginx-ingress-su-aks-guida-alla-migrazione-verso-gateway-api</link><guid isPermaLink="true">https://forum.androidiani.net/topic/2edb772b-cd53-4a9f-97bd-82284bbbd1cf/fine-del-supporto-nginx-ingress-su-aks-guida-alla-migrazione-verso-gateway-api</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Tue, 05 May 2026 08:48:42 GMT</pubDate></item></channel></rss>