Unable to get pod logs
See original GitHub issueI have just installed a fresh snap of Microk8s on the 1.14/stable channel. I am completely unable to get logs.
On the host machine, I am trying to run this command:
microk8s.kubectl logs -n kube-system pod/hostpath-provisioner-6d744c4f7c-m9swk
However the same result is true for any pod I wish to inspect. The result is that I immediately receive this error message:
F0507 11:53:00.594460 1 hostpath-provisioner.go:162] Error getting server version: Get https://10.152.183.1:443/version: dial tcp 10.152.183.1:443: i/o timeout
This error is very strange to me. The IP of my machine is NOT 10.152.183.1. It’s actually 192.168.1.217. I don’t use the 10.x.x.x scheme on my network at all, so I have no idea where it’s getting that number from. Moreover, I’m doing this from the host machine itself, so I would have expected it to try 127.0.0.1. Why don’t logs work?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Can't get the application logs from pods Kubernetes
If you can't see you apps logs when using kubectl logs command it most likely means that your app is not writing logs...
Read more >Unable to get pod logs · Issue #461 · canonical/microk8s
I am completely unable to get logs. On the host machine, I am trying to run this command: microk8s.kubectl logs -n kube-system pod/hostpath- ......
Read more >Determine the Reason for Pod Failure - Kubernetes
In the YAML file, in the command and args fields, you can see that the container sleeps for 10 seconds and then writes...
Read more >How to Fix CreateContainerError & CreateContainerConfigError
CreateContainerConfigError and CreateContainerError are two errors that occur when a Kubernetes tries to create a container in a pod, but fails before the ......
Read more >Troubleshooting - MicroK8s
If a pod is not behaving as expected, the first port of call should be the logs. First determine the resource identifier for...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I believe @haphan was correct and that it was indeed firewall settings. Applying the suggested
ufw
changes seems to have fixed the problem. I also had to runsudo iptables -P FORWARD ACCEPT
on the host machine. I’ll close this issue now as I’ve got it working.@ktsakalozos I was facing the same issue recently;
pod/hostpath-provisioner
is in CrashLoopBackOff state and getting logs throwing a similar error.After pulling my hair off, I figured out it has something to do with the local firewall settings. Enabling ip forwarding fixed the issue in my case (I am using
firewalld
instead ofufw
)Alternatively, for those who use ufw, this shall work as well as already mentioned in the official doc