Beste Kubernetes-test voor wervingSRE en DevOps-engineers

Waarom standaard Kubernetes-tests falen

De meeste Kubernetes-assessments vragen: 'Wat is een StatefulSet?' of 'Leg taints en tolerations uit.' Deze meten memorisatie, niet of iemand een cluster kan ontwerpen dat knoopfouten overleeft, kan detecteren wanneer je app oscilleert of kan debuggen waarom een implementatie nooit stabiliseert.

Een SRE of DevOps-engineer met diepe Kubernetes-ervaring weet dat de echte vragen gaan over operationele stabiliteit, kosten en productieprobleemdiagnose onder druk.

Dit is wat een signaalvergend Kubernetes-assessment eruit ziet.

Kernvaardigheden om te beoordelen

1. Clusterontwerp en veerkracht

Kunnen zij een cluster ontwerpen dat zonetalen overleeft?

Beoordelingsvraag:

'Je voert een productieworkload uit die actief moet blijven tijdens zonetallen. Je hebt een 3-knoopcluster in een enkele AZ. Wat wijzig je? Wat zijn de afwegingen?'

Goed antwoord:

• Verspreidt knooppunten over minstens 3 AZ's
• Gebruikt PodDisruptionBudgets om cascade-mislukkingen te voorkomen
• Gebruikt knoopaffiniteit om alle replica's in één zone te voorkomen
• Configureert gezondheidscontroles voor je knooppunten
• Begrijpt de kostenafweging (3x de infrastructuur)

Zwak antwoord:

• 'Voer meer replica's uit' (lost zonetalling niet op)
• 'Gebruik anti-affiniteit' (zonder pod topology spread constraints te begrijpen)

2. Workload-configuratie en debugging

Kunnen zij een workload voor productie configureren en debuggen wanneer het mislukt?

Beoordelingsvraag:

'Je hebt een nieuwe microservice geïmplementeerd. De implementatie toont 3 replica's die draaien, maar slechts 2 verwerken verkeer. Gereedheidschecks slagen. Waarom zou dit kunnen gebeuren?'

Goed antwoord overweegt (in volgorde):

• Ontbreekt het eindpunt in de serviceelector? (kubectl get endpoints)
• Blokkeert het pod-netwerkbeleid verkeer?
• Is de pod-netwerkinterface onjuist geconfigureerd?
• Verschilt de load balancer-gezondheidscontrole van de gereedheidscheque?

Dit test systematische debugging, geen Kubernetes-feiten.

3. Opslag en staatsbeheer

Begrijpen zij wanneer StatefulSets versus Implementaties te gebruiken? Wanneer node-lokale versus blijvende opslag?

Beoordelingsvraag:

'We voeren Elasticsearch uit op Kubernetes. Gebruiken we StatefulSet of Implementatie? Wat met opslag?'

Goed antwoord:

• StatefulSet voor stabiele identiteit en volgorde
• Persistente volumes voor gegevensduurzaamheid
• Anti-affiniteit om over knooppunten te verspreiden
• Voorzichtige upgrade-strategie (rollende restarts kunnen kworum verliezen)

Zwak antwoord:

• 'Implementatie gebruiken, het is eenvoudiger'
• Geen vermelding van gegevenspersistentie of kworum

4. Schaling en kostenoptimalisatie

Weten zij wanneer omhoog schalen versus wanneer workloads optimaliseren?

Beoordelingsvraag:

'Je cluster CPU-gebruik ligt op 85%. Kosten zijn $10k/maand. Je hebt twee opties: meer knooppunten toevoegen of pod-verzoeken optimaliseren. Wat controleer je eerst?'

Goed antwoord:

• Controleer of pods resources overanvragen (verzoeken te hoog ingesteld)
• Controleer op luidruchtige buurman-problemen (één pod gebruikt veel meer dan verwacht)
• Controleer of de workload natuurlijk piekt (kan verkeersmunsters verschuiven)
• Voeg knooppunten alleen toe als het werkelijke beperkingen zijn

Dit test operationeel oordeel.

5. Observeerbaarheid en productiedebugging

Kunnen zij monitoring voor Kubernetes ontwerpen? Kunnen zij diagnosticeren waarom een app instabiel is?

Beoordelingsvraag:

'Je applicatie in Kubernetes heeft een 0,1%-foutpercentagespike die 30 seconden duurt en dan herstelt. Het gebeurt eenmaal per dag op willekeurige momenten. Hoe zou je dit onderzoeken?'

Goed antwoord vermeldt:

• Pod herstart evenementen (controleer knooplogboeken en kubelet)
• Resourceuitputting (controleer geheugen en CPU)
• Netwerktimeouts (controleer service-eindpunten en DNS)
• Toepassingsniveau-herintentaties (herstelt de app van voorbijgaande fouten?)

Assessmentstructuur

Deel 1: Take-home designoefening (2 uur)

Scenario:

'Ontwerp een productie-Kubernetes-cluster voor een SaaS-applicatie met de volgende beperkingen:

• 99,9% uptime SLA
• Staatsloos frontend en stateful backend (database)
• 50-500 gelijktijdige gebruikers (variabel belasting)
• Budgetbeperking: maximaal $5.000/maand
• Moet enkele zonetalling overleven
• Schaling moet automatisch zijn'

De kandidaat dient in:

• Knooparchitectuur (hoeveel knooppunten, instantietypes, zones)
• Workload-configuratie (implementaties, resourceverzoeken, schalingsbeleid)
• Opslagstrategie (persistente volumes, back-ups)
• Monitorings- en alerteringsplan
• Kostenaufbau

Dit test of zij systemen op schaal hebben gebouwd.

Deel 2: Configuratiebeoordeling (30 minuten)

Geef ze een Kubernetes-manifest met opzettelijke problemen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # Probleem: moet 3 zijn voor HA
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # Probleem: moet semantische versioning gebruiken
        resources:
          requests:
            cpu: 100m  # Probleem: te laag; app zal CPU-gethrotteld zijn
            memory: 64Mi  # Probleem: te laag; zal OOM hebben
      # Probleem: geen readiness probe, geen liveness probe
      # Probleem: geen knoopaffiniteit; kan op dezelfde knooppunt draaien
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080
  # Probleem: geen headless service voor volgorde; gebruikt geen StatefulSet voor volgorde

Vraag hen alle problemen te identificeren en fixes uit te leggen. Een sterke kandidaat pikt 8+ problemen op; een zwakke 1–2 voor de hand liggende.

Deel 3: Troubleshooting-gesprek (30 minuten)

Scenario:

'Je hebt een nieuwe service in Kubernetes geïmplementeerd. Verkeer raakt het, maar latentie is 10x normaal. Prometheus toont normaal CPU en geheugengebruik. Loop me door hoe je dit zou debuggen.'

De kandidaat moet vragen:

• Is het service-eindpunt bijgewerkt? (kubectl get endpoints)
• Ontvangen pods evenveel verkeer of is één pod traag?
• Is het netwerkpad het probleem (kube-proxy, CNI)?
• Blokkeert de toepassing iets (externe API, database)?
• Bevatte de implementatie een codewijziging die niet-geoptimaliseerd is?

Dit test of zij systematisch denken.

Kubernetes-beoordeling rubric

Wat NIET testen

Vraag kandidaten niet:

• Schrijf vanaf nul een Kubernetes Operator. (Dat is systeemprogrammering, geen SRE.)
• Memoriseer API-versies. (Ze gebruiken de docs in productie toch.)
• Stel een cluster vanaf nul in tijdens het interview. (Dat is een operationele taak, niet een beoordelingvan oordeel.)

Vraag wel:

• Ontwerp een cluster voor realistische beperkingen
• Debug waarom een implementatie mislukt
• Leg afwegingen tussen opties uit
• Configureer workloads voor productie

Voor teams die Kubernetes nog niet gebruiken

Als je werft voor DevOps of SRE maar geen Kubernetes gebruikt, test containerisatie- en orkestratie-concepten zonder Kubernetes-expertise te vereisen. Veel teams geven Kubernetes-kennis te veel gewicht wanneer zij echt systeemdenken nodig hebben.

Voor teams die Kubernetes in productie gebruiken, gebruik deze assessmentstructuur om operationele diepte te evalueren vóór aanstelling. Een kandidaat die dit assessment haalt, is op dag één productief.

Volgende: begrijp hoe je DevOps-beoordelingsresultaten interpreteert.