Kubernetes · Orchestration under pressure
How do you work with logs and events in Kubernetes?
Short answer
Container logs are per-pod and ephemeral, while events record scheduling and lifecycle decisions. Production needs centralized log shipping and event retention beyond the API server default.
kubectl logs reads the container runtime's log file for a pod. Logs disappear when the pod is deleted and are not aggregated across replicas. Events are namespaced objects with a default retention of about an hour, so they are useful during live debugging but not as an audit trail.
- Use -c for multi-container pods and --previous after a restart
- Use -f to follow and --since to bound the window
- Events can be sorted by timestamp and filtered by involved object
- Ship logs to a central backend with retention and access control
- Prefer structured JSON logs so queries do not depend on fragile parsing
kubectl logs deployment/api -n production --since=15m
kubectl logs api-7c9d8f6b5-abcde -n production -c api --previous
kubectl get events -n production --sort-by=.lastTimestamp
kubectl get events -n production --field-selector involvedObject.name=api-7c9d8f6b5-abcdeLogs and events answer different questions. Logs tell you what the application did; events tell you what Kubernetes did to the pod. During an incident, correlate timestamps across both, plus metrics, so you can distinguish an application failure from a scheduling or eviction event.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How long do Kubernetes events persist?
- 2How do you collect logs from all replicas?
- 3How would you find why a pod was evicted?
- 4What makes a log useful during an incident?
Say it in the interview
Container logs tell me what the app did, while events tell me what Kubernetes did to the pod. Logs are ephemeral and per-pod, so production needs a central log pipeline with retention. Events are great during live debugging but expire quickly. I use structured logs and correlate them with metrics and event timestamps so I can separate application failures from infrastructure actions.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.