UNIX/Linux system administrators the world over regularly use log files to get to the bottom of outages and malfunctions. An indispensable tool in that regard is , particularly its flag ( ). When we're in a Kubernetes world, we'd love to use something similar. tail(1) follow mode -f We're in luck. The command has two flags that are most helpful for watching live log streams: the aptly-named flag and the context-limiting . logs --tail -n kubectl logs -pod- my name --tail -n10 This one-two combo is super helpful for tracing ongoing issues on a running system. Limiting the context with prevents us from fixating on old problems that may have since been resolved. Streaming the log as it happens gives us the opportunity to poke and prod at the system, seeing new log entries appear as we do things in the application or service under scrutiny. -n While tailing, you can hit <Enter> a few times to insert lots of blank lines, thus demarcating the stretches of time between trying things in the front-end. Pro Tip: When Pods Crash $ kubectl logs crashing-pod
[Mon Feb : : UTC ] starting up...
[Mon Feb : : UTC ] startup complete; initializing.
[Mon Feb : : UTC ] - frobbing the data cache...
[Mon Feb : : UTC ] - allocating grokbase fooblers...
[Mon Feb : : UTC ] - reticulating splines...
[Mon Feb : : UTC ] - reclaiming unused memory...
[Mon Feb : : UTC ] - checking on friends family...
[Mon Feb : : UTC ] initialization complete; entering main loop. 10 16 29 19 2020 10 16 29 34 2020 10 16 29 34 2020 10 16 29 34 2020 10 16 29 34 2020 10 16 29 34 2020 10 16 29 34 2020 in and 10 16 29 34 2020 What I really need is the end of the log buffer from the failed / crash instance: $ kubectl logs -p crashing-pod
[M Feb : : UTC ] starting up...
[M Feb : : UTC ] startup complete; initializing.
[M Feb : : UTC ] - frobbing the data cache...
[M Feb : : UTC ] - allocating grokbase fooblers...
[M Feb : : UTC ] - reticulating splines...
[M Feb : : UTC ] - reclaiming unused memory...
[M Feb : : UTC ] - checking friends and family...
[M Feb : : UTC ] initialization complete; entering main loop.
[M Feb : : UTC ] ...
[M Feb : : UTC ] ...
[M Feb : : UTC ] ...
[M Feb : : UTC ] ...
[M Feb : : UTC ] UNMITIGATED DISASTER!
[M Feb : : UTC ] THREAD PANIC detected; no assurances given.
[M Feb : : UTC ] IT'S A BAD SCENE, MAN!
[M Feb : : UTC ] on 10 7 18 20 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 in on on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 on 10 7 18 35 2020 <crashed> With information in hand, I can continue my diagnostic efforts and hopefully resolve this early morning nuisance. that Previously published at https://starkandwayne.com/blog/silly-kubectl-trick-4-getting-at-those-logs/

Super

Kubernetes Explained Simply: Waiting For Kubernetes [Part 5]

Kubernetes Explained Simply: #3 What Do I Have Permissions For?

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Kubernetes Explained Simply: Getting At Those Logs [Part 4]

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Kubernetes Explained Simply: #1 Kubectl Hack

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Kubernetes Explained Simply: #1 Kubectl Hack

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps