Il miglior test Kubernetes per assumere engineer SRE e DevOps

Perché i test Kubernetes standard falliscono

La maggior parte delle valutazioni Kubernetes chiede: «Cos'è uno StatefulSet?» o «spiega taint e toleration». Misurano memorizzazione, non se qualcuna sa progettare un cluster che sopravvive a un guasto di nodo, rilevare quando una app oscilla o capire perché un deployment non si stabilizza mai.

Un'engineer SRE o DevOps con esperienza profonda di Kubernetes sa che le vere domande riguardano stabilità operativa, costi e debug di problemi di produzione sotto pressione.

Ecco come si presenta una valutazione Kubernetes che porta segnale.

Competenze chiave da valutare

1. Design e resilienza del cluster

Sa progettare un cluster che sopravvive a guasti di zona?

Domanda:

«Stai eseguendo un workload di produzione che deve restare attivo durante guasti di zona. Hai un cluster a 3 nodi in una singola AZ. Cosa cambi? Quali sono i trade-off?»

Buona risposta:

• Distribuire i nodi su almeno 3 AZ
• Usare PodDisruptionBudgets per prevenire guasti a cascata
• Usare node affinity per evitare di mettere tutte le repliche in una zona
• Configurare health check per i nodi
• Capisce il trade-off di costo (3× l'infrastruttura)

Risposta debole:

• «Aggiungi più repliche» (non risolve il guasto di zona)
• «Usa anti-affinity» (senza capire i pod topology spread constraint)

2. Configurazione e debug dei workload

Sa configurare un workload per la produzione e fare il debug quando si rompe?

Domanda:

«Hai distribuito un nuovo microservizio. Il deployment mostra 3 repliche in esecuzione, ma solo 2 ricevono traffico. I readiness check passano. Perché può succedere?»

Buona risposta considera (in ordine):

• L'endpoint manca dal selector del service? (kubectl get endpoints)
• La network policy sta bloccando il traffico?
• L'interfaccia di rete del pod è mal configurata?
• L'health check del load balancer è diverso dal readiness check?

Questo verifica il debug sistematico, non i fatti su Kubernetes.

3. Storage e gestione dello stato

Capisce quando usare StatefulSet vs. Deployment? Quando storage locale vs. persistente?

Domanda:

«Eseguiamo Elasticsearch su Kubernetes. StatefulSet o Deployment? E lo storage?»

Buona risposta:

• StatefulSet per identità stabile e ordinamento
• Volumi persistenti per la durabilità dei dati
• Anti-affinity per distribuire tra nodi
• Strategia di upgrade attenta (i rolling restart possono causare perdita di quorum)

Risposta debole:

• «Usa Deployment, è più semplice»
• Nessuna menzione di persistenza dei dati o quorum

4. Scaling e ottimizzazione costi

Sa quando scalare vs. quando ottimizzare i workload?

Domanda:

«L'utilizzo CPU del tuo cluster è all'85 %. Il costo è 10 k$/mese. Hai due opzioni: aggiungere più nodi o ottimizzare i request dei pod. Cosa controlli per primo?»

Buona risposta:

• Controllare se i pod richiedono troppe risorse (request troppo alti)
• Controllare se ci sono problemi di noisy neighbor (un pod che usa molto più del previsto)
• Controllare se il workload ha picchi naturali (potresti spostare pattern di traffico)
• Solo allora aggiungi nodi se è un vero vincolo di risorse

Questo verifica il giudizio operativo.

5. Observability e debug in produzione

Sa progettare monitoraggio per Kubernetes? Sa diagnosticare perché un'app è instabile?

Domanda:

«La tua app in Kubernetes ha picchi di errore dello 0,1 % che durano 30 secondi, poi si recupera. Succede una volta al giorno a orari casuali. Come faresti l'investigation?»

Buona risposta menziona:

• Eventi di pod restart (controlla i log dei nodi e di kubelet)
• Esaurimento risorse (controlla memoria e CPU)
• Timeout di rete (controlla service endpoint e DNS)
• Retry a livello applicativo (l'app si recupera da errori transitori?)

Struttura della valutazione

Parte 1: esercizio di design take-home (2 ore)

Scenario:

«Progetta un cluster Kubernetes di produzione per un'applicazione SaaS con:

• SLA di uptime 99,9 %
• Frontend stateless e backend stateful (database)
• 50–500 utenti concorrenti (carico variabile)
• Vincolo di budget: massimo 5.000 $/mese
• Deve sopravvivere al guasto di una singola zona
• Lo scaling deve essere automatico»

La candidata deve fornire:

• Architettura dei nodi (quanti nodi, tipi di istanze, zone)
• Configurazione del workload (deployment, resource request, policy di scaling)
• Strategia di storage (volumi persistenti, backup)
• Piano di monitoring e alerting
• Suddivisione dei costi

Questo verifica se ha già costruito sistemi a scala.

Parte 2: review della configurazione (30 minuti)

Dalle un manifest Kubernetes con problemi intenzionali:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # Issue: should be 3 for HA
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # Issue: should use semantic versioning
        resources:
          requests:
            cpu: 100m  # Issue: too low; app will be CPU throttled
            memory: 64Mi  # Issue: too low; will OOM
      # Issue: no readiness probe, no liveness probe
      # Issue: no node affinity; could run on same node
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080

Chiedile di identificare tutti i problemi e spiegare le correzioni. Una candidata forte ne trova 8+; una debole ne trova 1–2 evidenti.

Parte 3: conversazione di troubleshooting (30 minuti)

Scenario:

«Hai distribuito un nuovo servizio in Kubernetes. Il traffico arriva, ma la latenza è 10× il normale. Prometheus mostra CPU e memoria normali. Spiegami come faresti il debug.»

La candidata dovrebbe chiedere:

• L'endpoint del service è aggiornato? (kubectl get endpoints)
• I pod ricevono traffico in modo uniforme o uno è lento?
• È un problema di percorso di rete (kube-proxy, CNI)?
• L'applicazione si blocca su qualcosa (API esterna, database)?
• Il deploy includeva una modifica al codice non ottimizzata?

Questo verifica il pensiero sistematico.

Rubrica di valutazione Kubernetes

Cosa NON testare

Non chiedere alle candidate di:

• Scrivere un Kubernetes Operator da zero. (È programmazione di sistema, non SRE.)
• Memorizzare le versioni delle API. (Useranno comunque la documentazione in produzione.)
• Configurare un cluster da zero durante il colloquio. (È un task operativo, non una valutazione di giudizio.)

Chiedi loro di:

• Progettare un cluster con vincoli realistici
• Fare il debug del perché un deployment fallisce
• Spiegare i trade-off tra opzioni
• Configurare workload per la produzione

Per i team che non usano ancora Kubernetes

Se assumi DevOps o SRE ma non usi ancora Kubernetes, testa concetti di containerizzazione e orchestrazione senza richiedere expertise Kubernetes. Molti team sovrappesano la conoscenza di Kubernetes quando in realtà serve pensiero di sistema.

Per i team che usano Kubernetes in produzione, usa questa struttura di valutazione per misurare la profondità operativa prima di assumere. Una candidata che supera questa valutazione sarà produttiva dal primo giorno.

Prossimo: capisci come interpretare i risultati della tua valutazione DevOps.