kbrwn
commented
7 years ago Are there any scheduling failures shown kubectl get events? It is likely that docker is not properly creating symlinks needed for kubectl logs to function properly. This snippet has a comment about why the failure to create this symlink is ignored:
// StartContainer starts the container.
func (ds *dockerService) StartContainer(containerID string) error {
err := ds.client.StartContainer(containerID)
if err != nil {
return fmt.Errorf("failed to start container %q: %v", containerID, err)
}
// Create container log symlink.
if err := ds.createContainerLogSymlink(containerID); err != nil {
// Do not stop the container if we failed to create symlink because:
// 1. This is not a critical failure.
// 2. We don't have enough information to properly stop container here.
// Kubelet will surface this error to user via an event.
return err
}
return nil
}
lwolf
derekperkins
lrepolho
seubert
Issue Report Template
Tectonic Version
Tectonic 1.7.1-tectonic.2 Kubernetes 1.7.1+tectonic.1 coreos - 1506.0.0 channel - Alpha
Environment
Baremetal cluster on multiple esxi boxes
Expected Behavior
kubectl logs -f POD should tail logs
Actual Behavior
After a node reboot, a lot of containers have this problem. Killing the container or rebooting docker itself heels it, until the next reboot.