Docker & Kubernetes på ditt CV: Så visar du det så att arbetsgivare faktiskt märker det

Docker och Kubernetes har blivit förväntade kompetenser inom ett brett spektrum av ingenjörsroller — backend-utvecklare, plattformsingenjörer, DevOps-ingenjörer, SRE:er och molnarkitekter behöver dem alla. Den utbreddheten skapar samma problem som alla allmänt påstådda kompetenser: att lista "Docker/Kubernetes" på ditt CV är nästan meningslöst utan kontext, eftersom alla kandidater gör det.

Det som får rekryterare att stanna upp är specificitet. Docker-erfarenhet hos en junior ingenjör kan innebära att skriva en Dockerfile och köra docker-compose up. Docker-erfarenhet hos en senior ingenjör innebär multi-stage builds, lageroptimering, säkerhetshärdning av basimages och hantering av image-registries i ett CI/CD-sammanhang. Kubernetes-erfarenhet sträcker sig från "jag körde kubectl get pods i en tutorial" till "jag äger ett produktions-EKS-kluster som serverar 10M förfrågningar per dag." Ditt CV behöver placera dig på det spektrumet otvetydigt.

Vad intervjuare faktiskt undersöker

Tekniska intervjuare som söker container- och orkestreringserfarna kandidater har mentala modeller för vad varje erfarenhetsnivå bör kunna. Att förstå de modellerna hjälper dig skriva CV-punkter som träffar rätt register.

Docker-djupssignaler:

• Multi-stage builds för mindre, säkrare images (inte bara enkellagers-Dockerfiles)
• Val av basimage och säkerhetsskanning (Distroless, Chainguard images, Trivy, Snyk)
• Lager-cachestrategi för snabba CI-byggen
• BuildKit-funktioner (cache mounts, SSH mounts, secrets)
• Compose v2 för lokal utveckling med hälsokontroller och serviceberoenden
• Image registry-hantering (ECR, GCR, DockerHub, Harbor, Artifact Registry)
• Rootless containers och icke-root USER-instruktioner för säkerhetshärdning

Kubernetes-djupssignaler:

• Resource requests/limits och deras påverkan på schemaläggning och Quality of Service-klasser
• Deployment, StatefulSet, DaemonSet — skillnaderna och när du använder varje
• Servicetyper (ClusterIP, NodePort, LoadBalancer, ExternalName) och Ingress-kontroller (nginx, Traefik, AWS ALB)
• ConfigMaps och Secrets-hantering (och deras begränsningar; external-secrets-operator, Sealed Secrets, Vault Agent Injector)
• RBAC: Roles, ClusterRoles, Bindings — least-privilege-konfiguration
• Horizontal Pod Autoscaler (HPA) med CPU och anpassade mätvärden (KEDA för event-driven autoskalning)
• PodDisruptionBudgets för nolltids-rullande uppdateringar
• Network policies för kontroll av pod-till-pod-kommunikation
• Persistent lagring: StorageClasses, PersistentVolumeClaims, CSI-drivrutiner
• Helm chart-skapande (inte bara konsumtion): mallar, values-hierarki, chart-beroenden, hooks

Hur du kvantifierar Docker- och Kubernetes-arbete

Container-arbete är ofta operativt osynligt — värdet ligger i tillförlitlighet och effektivitet snarare än synliga funktioner. Nyckeln är att göra det operativa värdet konkret.

Före: Used Docker to containerise applications.

Efter: Redesigned a 12-service Node.js application's Docker build chain using multi-stage builds and layer caching; reduced average CI image build time from 14 minutes to 3 minutes and cut production image sizes by 70% (average 1.2 GB → 180 MB), significantly reducing ECR storage costs and registry pull latency.

Före: Managed Kubernetes clusters in production.

Efter: Owned a production EKS cluster (150+ pods, 12 services) serving 3M daily API requests; implemented HPA with KEDA for event-driven scaling from Kafka consumer lag metrics, reducing average pod count during off-peak hours by 60% and cutting EC2 compute spend by $3,400/month without degrading p99 latency.

Före: Set up Kubernetes for a new project.

Efter: Architected Kubernetes infrastructure for a healthcare platform using EKS with Fargate profiles; enforced network policies to isolate PHI-handling workloads, implemented IRSA (IAM Roles for Service Accounts) for least-privilege AWS access per pod, and configured OPA Gatekeeper policies to prevent deployments without resource limits — passed a SOC2 Type II infrastructure audit with zero findings against container controls.

Ekosystemets djup: Vad du ska lista

Verktygen kring Docker och Kubernetes är lika viktiga som kärnkompetenserna:

Container-orkestreringsplattformar: AWS EKS, GKE (Standard/Autopilot), Azure AKS, Rancher (RKE2), k3s, OpenShift (företagsmiljöer)

Driftsättning och GitOps: ArgoCD, Flux CD, Helm, Kustomize — notera om du skrivit Helm charts från grunden eller bara driftsatt befintliga. GitOps-erfarenhet (ArgoCD/Flux med flerstegs-miljöfrämjande) är en avsevärd differentieringsfaktor.

Observerbarhet: Prometheus + Grafana-stacken (med ServiceMonitor CRDs, alertmanager-regler), Datadog Kubernetes-integration, Loki för loggaggregering, OpenTelemetry för distribuerad spårning, kube-state-metrics

Klusterhantering och policy: Cluster Autoscaler, Karpenter (nyare, nod-livscykelhantering), Kyverno eller OPA Gatekeeper för admission control, Velero för säkerhetskopiering, cert-manager för TLS

Säkerhet: Falco (runtime-säkerhet), Trivy (image-skanning), Snyk Container, Pod Security Admission, Sealed Secrets, external-secrets-operator, Vault Agent Injector

CI/CD-integration: GitHub Actions med Docker Buildx, GitLab CI container-jobb, Tekton Pipelines, Kaniko för in-kluster image-byggande

Var du placerar Docker/Kubernetes på ditt CV

Kompetenssektionen: Organisera efter kategori snarare än att stoppa in båda verktygen på en rad. Exempel:

• "Container-orkestrering: Kubernetes (EKS/GKE), Helm, ArgoCD, Karpenter, KEDA, OPA Gatekeeper"
• "Containerisering: Docker (multi-stage builds, BuildKit), Docker Compose, Trivy, Harbor"

Det här formatet signalerar omedelbart både bredd (hanterade klusterverktyg) och djup (specifika komponenter du känner till).

Erfarenhetspunkter: Kubernetes och Docker bör dyka upp i punkter där de drev operativa resultat — tillförlitlighetsförbättringar, kostnadsminskningar, ökad driftsättningsfrekvens, minskade incidenter. Undvik att lista dem som konfigurationsarbete utan nedströmsresultat.

Certifieringssektionen: Se nedan — relevanta certifieringar hör hemma tydligt märkta här.

Certifieringar och meriter

Certified Kubernetes Administrator (CKA) — CNCF: Guldstandarden för Kubernetes-driftsrolls. Prestationsbaserat prov (praktisk kubectl och YAML, inte flervalsfrågor). Allmänt respekterat och starkt rekommenderat för plattformsingenjörer och SRE:er.

Certified Kubernetes Application Developer (CKAD) — CNCF: Mer utvecklarfokuserat än CKA — täcker Pod-design, konfiguration, tjänster och observerbarhet. Lämpligt för backend-utvecklare med avsevärt Kubernetes-arbete.

Certified Kubernetes Security Specialist (CKS) — CNCF: Avancerad säkerhetsfokuserad certifiering som kräver en aktiv CKA. Hög signal för säkerhetsmedvetna plattformsroller.

Docker Certified Associate (DCA): Legitim men något mindre respekterad än CNCF-certifieringar i ingenjörskretsar. Värd att lista för roller där Docker är ett primärt kompetensområde.

KCNA (Kubernetes and Cloud Native Associate): Grundläggande CNCF-certifiering. Lämplig för kandidater som övergår till cloud native-arbete, men lägre signal på seniorinivå.

Linux Foundation-certifieringar generellt: LFCS, LFCE — grundläggande men relevanta för plattformsingenjörsroller som kräver djup OS-kunskap vid sidan om container-kompetenser.

Vanliga misstag som försvagar container-CV:n

"Docker and Kubernetes experience" utan specifika uppgifter. Utan kontext berättar det för en intervjuare ingenting om du någonsin rört produktion eller gjort klart en enda tutorial. Specificera klusterstorleken, arbetsbelastningstypen, molnleverantören och minst en operativ utmaning du navigerat.

Listar Kubernetes utan Helm eller GitOps-verktyg. År 2026 är rå kubectl i produktion sällsynt. Alla Kubernetes-roller frågar om dina driftsättningsverktyg. Om du inte har arbetat med Helm eller ArgoCD/Flux är det värt att skaffa den erfarenheten innan du söker seniora roller.

Sammanblandar Docker Compose med Kubernetes. Docker Compose är ett utvecklings- och småskaligt driftsättningsverktyg. Kubernetes är en produktionsorkerstringsplattform. Kandidater som beskriver Docker Compose-arbete i samma termer som Kubernetes-produktionsarbete väcker frågor om deras förståelse av distinktionen.

Ingen omnämning av säkerhetspraxis. Kubernetes säkerhetshygien — icke-root containers, read-only root-filsystem, network policies, RBAC, admission controllers — förväntas på mellan- till seniornivå. Att utelämna det antyder att du aldrig behövt tänka på det, vilket är ett glapp i alla produktionsinfrastruktur-roller.

Behandlar Kubernetes som en svart låda. Plattformsingenjörer som kan beskriva Kubernetes interna — schemaläggaren, etcd, kontrollplanskomponenterna, hur kubelet kommunicerar med API-servern — är avsevärt mer trovärdiga än de som bara känner till de användarvänliga resurserna. Om du har felsökt kluster-nivåproblem (nodtryckavhysningar, API-server-hastighetsbegränsning, etcd-komprimering), nämn det.

Avslutning

Docker och Kubernetes dyker upp på hundratals CV:n för varje öppen plattformsingenjörs- eller DevOps-roll. De kandidater som får samtal är de som rör sig bortom etiketten till specifika detaljer — de klusterkonfigurationsbeslut som fattades, den säkerhetsposition som upprätthölls, de operativa förbättringar som levererades. Varje punkt du skriver om container-arbete bör besvara: vad byggde du, i vilken skala och vad möjliggjorde eller förbättrade det?

NextCV läser DevOps- eller plattformsingenjörs-jobbannonsen du söker och lyfter fram din mest relevanta container- och orkestreringserfarna erfarenhet — Kubernetes-klusterägandeskapet, GitOps-verktygen, kostnads- och tillförlitlighetsresultaten — som stämmer överens med vad det specifika teamet letar efter.