Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add apiserver logs to "minikube logs" command #3550

Closed
tstromberg opened this issue Jan 19, 2019 · 6 comments · Fixed by #3673
Closed

Add apiserver logs to "minikube logs" command #3550

tstromberg opened this issue Jan 19, 2019 · 6 comments · Fixed by #3673
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone

Comments

@tstromberg
Copy link
Contributor

This way users can see flag misconfiguration errors.

@tstromberg tstromberg added kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Jan 22, 2019
@tstromberg tstromberg added this to the v1.0.0-candidate milestone Jan 22, 2019
@tstromberg tstromberg self-assigned this Jan 23, 2019
@tstromberg tstromberg modified the milestones: v1.0.0-candidate, v0.34.0-candidate Jan 24, 2019
@tstromberg
Copy link
Contributor Author

tstromberg commented Jan 24, 2019

Here's the command for the docker runtime:

minikube ssh 'docker logs $(docker ps -a -f name=k8s_kube-api --format={{.ID}})'

It's unclear yet how to handle this for containerd and CRIO.

@tstromberg tstromberg modified the milestones: v0.34.0-candidate, v0.34.0 Jan 24, 2019
@aaron-prindle
Copy link
Contributor

There are some open questions about the implementation here:

  • currently minikube logs supports an -f flag to tail logs. If multiple components are being output, is there a sane way to tail them both? Is it reasonable to no longer support tailing logs?
  • does it make sense to add flag options so that you can output only specific pieces, eg: minikube logs --kubelet and minikube logs --apiserver, with minikube logs being all components
  • in the joint output, should there be some kind of delineation so that users know what component the logs refer to, eg: "=====APISERVER_LOGS=====" (is there a more standard way to do this?)

@tstromberg
Copy link
Contributor Author

@aaron-prindle - It's possible to sanely tail multiple logs, though you bring up a good point that we would want to be able to filter different ones in the future for this mode in particular. I actually implemented this in https://github.com/kubernetes/minikube/pull/3551/files - I closed the PR because it added some unrelated changes, but planned to resubmit it for review once I could update it for merge conflicts.

I agree about the delineation. I don't think there is much in the way of standardization, but now that I think about it, the tail command uses this form when called for multiple files:

==> /etc/ttys <==

If you are interested in this issue, you are welcome to assign it to yourself and take the PR to completion. I got blocked trying to figure out how to get pod logs for non-Docker runtimes - but I assume crictl or podman could help out here.

@afbjorklund
Copy link
Collaborator

Should probably be using crictl for this, it is a mandatory requirement (nowadays) and is supposed to know how to talk to different CRI ? However, it doesn't have the --format option available

@afbjorklund
Copy link
Collaborator

sudo crictl logs $(sudo crictl ps -a --name kube-apiserver | tail -n +2 | cut -f1 -d' ')

@afbjorklund
Copy link
Collaborator

@tstromberg : using podman wouldn't really help for docker, just like docker wouldn't help for cri-o

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants