I consumer Kafka su EKS falliscono per il conflitto tra membership e pod

Gli incidenti dei consumer Kafka su EKS nascono spesso da Kubernetes, non da Kafka. L’orchestratore tratta i pod come usa e getta, il gruppo di consumer richiede stabilità¹.

Un consumer Kafka è un client stateful fondato su un protocollo di membership. Entra in un gruppo, accetta un’assegnazione di partition, processa i record in ordine. Dimostra che è vivo con heartbeat e poll su una cadenza fissa. Le garanzie del gruppo, dall’ordine al carico condiviso fino a un solo owner per partition, dipendono da una membership stabile mentre il lavoro scorre¹.

Kubernetes parte dall’assunto opposto. Un pod è sacrificabile. La piattaforma riavvia pod, limita la CPU, fa rolling dei deployment, reclama nodi su una propria tabella di marcia. Per il protocollo del gruppo, ognuno di questi eventi appare come un membro che lascia, arriva o tace. Non è un comportamento eccezionale, è il disegno della piattaforma¹.

Su EKS, quindi, la maggior parte degli incidenti dei consumer non deriva da bug di Kafka. Nascono dalla collisione tra un client basato su membership e un orchestratore che fa ciò per cui è stato progettato. Il gruppo vede instabilità, ricalcola l’assetto, cerca di preservare le sue garanzie mentre il piano sottostante cambia¹.

Charan Rachumalla imposta il lavoro su due livelli. Prima definisce una configurazione di base che evita metà dei problemi. Poi attraversa otto failure mode che coprono quasi tutto il resto: per ciascuno descrive il sintomo, spiega il meccanismo e propone il fix. Sono correzioni noiose, ma fermano gli incidenti che arrivano in pager¹.

La fotografia è concreta. Il consumer partecipa a un gruppo e basa la propria sicurezza su segnali periodici e su una membership stabile. Kubernetes compie azioni ordinarie che interrompono o rischedulano i pod. Il gruppo interpreta ogni variazione come cambi di membership. Da qui nascono riassegnazioni, ribilanciamenti, segnali di vita che si interrompono o si ripresentano. Non serve un errore in Kafka per vedere un degrado del servizio lato consumer, basta l’ordinaria amministrazione della piattaforma¹.

Il post non si perde in teoria. Parte da una baseline che taglia molti problemi a monte, poi passa ai casi che restano, uno per uno. Il formato è operativo: segnale, causa nel protocollo di gruppo, rimedio. L’obiettivo è allineare il comportamento del client con la realtà di un ambiente che riavvia, sposta e limita i pod secondo le proprie regole. Così si evita di attribuire a Kafka ciò che è un effetto collaterale dell’orchestrazione¹.

Il titolo promette “the boring fixes that stop them”. Il messaggio è che la stabilità percepita dal gruppo non è un dato, va progettata tenendo conto del ciclo di vita del pod e degli eventi di piattaforma. Altrimenti, gli stessi pattern di failure si ripetono, perché la piattaforma non cambia comportamento per accomodare il client¹.