Cel mai bun test Kubernetes pentru angajarea inginerilor SRE și DevOps

De ce eșuează testele Kubernetes standard

Cele mai multe evaluări Kubernetes întreabă: „Ce e un StatefulSet?" sau „explică taints și tolerations". Asta măsoară memoria, nu dacă cineva poate proiecta un cluster care supraviețuiește unei căderi de nod, detecta când o aplicație oscilează sau depana de ce un deployment nu se stabilizează niciodată.

Un inginer SRE sau DevOps cu experiență adâncă în Kubernetes știe că întrebările reale sunt despre stabilitatea operațională, cost și depanarea problemelor de producție sub presiune.

Iată cum arată o evaluare Kubernetes care poartă semnal real.

Competențe-cheie de evaluat

1. Designul și reziliența cluster-ului

Poate proiecta un cluster care supraviețuiește căderilor de zonă?

Întrebare:

„Rulezi o sarcină de producție care trebuie să rămână sus în timpul căderilor de zonă. Ai un cluster cu 3 noduri într-un singur AZ. Ce schimbi? Care sunt compromisurile?"

Răspuns bun:

• Distribuie nodurile pe cel puțin 3 AZ-uri
• Folosește PodDisruptionBudgets pentru a preveni eșecuri în cascadă
• Folosește node affinity ca să eviți concentrarea replicilor într-o zonă
• Configurează health checks pentru noduri
• Înțelege compromisul de cost (3× infrastructura)

Răspuns slab:

• „Mai multe replici" (nu adresează căderea de zonă)
• „Anti-affinity" (fără să înțeleagă pod topology spread constraints)

2. Configurarea și depanarea sarcinilor

Poate configura pentru producție și depana când eșuează?

Întrebare:

„Ai deployat un microserviciu nou. Deployment-ul arată 3 replici rulând, dar doar 2 primesc trafic. Readiness checks trec. De ce s-ar putea întâmpla asta?"

Răspuns bun ia în calcul (în ordine):

• Lipsește endpoint-ul din selector-ul de service? (kubectl get endpoints)
• Blochează network policy-ul traficul?
• E interfața de rețea a pod-ului configurată greșit?
• Health check-ul de load balancer diferă de readiness check?

Asta testează depanare sistematică, nu fapte despre Kubernetes.

3. Stocare și gestiunea stării

Înțelege când să folosească StatefulSet vs. Deployment? Stocare locală pe nod vs. persistentă?

Întrebare:

„Rulăm Elasticsearch pe Kubernetes. StatefulSet sau Deployment? Și stocarea?"

Răspuns bun:

• StatefulSet pentru identitate stabilă și ordine
• Persistent volumes pentru durabilitatea datelor
• Anti-affinity pentru distribuire între noduri
• Strategie atentă de upgrade (rolling restarts pot cauza pierdere de quorum)

Răspuns slab:

• „Folosește Deployment, e mai simplu"
• Fără mențiunea persistenței datelor sau a quorum-ului

4. Scalare și optimizare de cost

Știe când să scaleze vs. când să optimizeze sarcinile?

Întrebare:

„Utilizarea CPU a cluster-ului tău e la 85 %. Costul e 10 k$/lună. Ai două opțiuni: adaugă mai multe noduri sau optimizează request-urile pod-urilor. Ce verifici primul?"

Răspuns bun:

• Verifică dacă pod-urile cer prea multe resurse (requests prea mari)
• Verifică dacă există probleme cu vecini zgomotoși (un pod consumă mult mai mult decât ar trebui)
• Verifică dacă sarcina are vârfuri naturale (s-ar putea muta tipare de trafic)
• Doar apoi adaugă noduri dacă e o constrângere reală

Asta testează discernământul operațional.

5. Observabilitate și depanare în producție

Poate proiecta monitorizare pentru Kubernetes? Poate diagnostica de ce o aplicație e instabilă?

Întrebare:

„Aplicația ta în Kubernetes are un vârf de eroare de 0,1 % care durează 30 de secunde, apoi se recuperează. Se întâmplă o dată pe zi la ore aleatorii. Cum ai investiga?"

Răspuns bun menționează:

• Evenimente de pod restart (verifică logurile de nod și kubelet)
• Epuizare de resurse (verifică memoria și CPU)
• Timeout-uri de rețea (verifică endpoint-urile de service și DNS)
• Retry-uri la nivel de aplicație (se recuperează aplicația din erori tranzitorii?)

Structura evaluării

Partea 1: exercițiu de design take-home (2 ore)

Scenariu:

„Proiectează un cluster Kubernetes de producție pentru o aplicație SaaS cu:

• SLA de 99,9 % uptime
• Frontend stateless și backend cu stare (bază de date)
• 50–500 utilizatori concurenți (sarcină variabilă)
• Constrângere de buget: maximum 5.000 $/lună
• Trebuie să supraviețuiască căderii unei singure zone
• Scalarea trebuie să fie automată"

Candidatul trebuie să livreze:

• Arhitectura nodurilor (câte noduri, tipuri de instanțe, zone)
• Configurația sarcinilor (deployments, request-uri de resurse, politici de scalare)
• Strategie de stocare (persistent volumes, backup-uri)
• Plan de monitorizare și alertare
• Defalcarea costurilor

Asta testează dacă a construit sisteme la scară.

Partea 2: revizuire de configurație (30 de minute)

Dă-i un manifest Kubernetes cu probleme intenționate:

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

Cere-i să identifice toate problemele și să explice corecturile. Un candidat puternic prinde 8+ probleme; unul slab prinde 1–2 evidente.

Partea 3: conversație de troubleshooting (30 de minute)

Scenariu:

„Ai deployat un service nou în Kubernetes. Traficul ajunge la el, dar latența e de 10× normalul. Prometheus arată CPU și memorie normale. Spune-mi cum ai depana".

Candidatul ar trebui să întrebe:

• Endpoint-ul service-ului e la zi? (kubectl get endpoints)
• Pod-urile primesc trafic uniform sau unul e lent?
• Problema e calea de rețea (kube-proxy, CNI)?
• Aplicația se blochează pe ceva (API extern, baza de date)?
• Deploy-ul a inclus o schimbare de cod neoptimizată?

Asta testează gândirea sistematică.

Rubrica de evaluare Kubernetes

Ce să NU testezi

Nu cere candidaților să:

• Scrie un Operator Kubernetes de la zero. (Asta e programare de sisteme, nu SRE.)
• Memoreze versiuni de API. (Vor folosi documentația oricum în producție.)
• Configureze un cluster de la zero în timpul interviului. (E o sarcină de operațiuni, nu o evaluare a discernământului.)

Cere-le să:

• Proiecteze un cluster pentru constrângeri realiste
• Depaneze de ce un deployment eșuează
• Explice compromisuri între opțiuni
• Configureze sarcini pentru producție

Pentru echipele care nu folosesc încă Kubernetes

Dacă angajezi DevOps sau SRE dar nu folosești încă Kubernetes, testează concepte de containerizare și orchestrare fără să ceri expertiză Kubernetes. Multe echipe supra-pondere cunoștințele Kubernetes când au nevoie de fapt de gândire de sisteme.

Pentru echipele care folosesc Kubernetes în producție, folosește această structură de evaluare ca să măsori profunzimea operațională înainte de a angaja. Un candidat care trece această evaluare va fi productiv din prima zi.

În continuare: înțelege cum să interpretezi rezultatele evaluării DevOps.