-
Notifications
You must be signed in to change notification settings - Fork 350
kubectl exec
does not work
#417
Comments
As expected I was wrong here, I missed a sequence in the
Before the eventual |
which versions of runc and cri-containerd? @Random-Liu has been checking in prs to address io issues. |
In the Ubuntu repro setup case:
In the LinuxKit case runc is That's the runc which containerd beta.3 suggests and the latest cri-containerd. |
@ijc It's caused by this change kubernetes/kubernetes#52686. It seems that with this change, Kubernetes <=1.8 won't work with new CRI container runtime. |
@ijc I discussed with @yujuhong about this today. It is a little bit hard to fix the version skew problem because we don't have a complete api machinery for CRI now. Are you only trying out cri-containerd or there is some user need this fix?
In the future their might be some other disruptive change in CRI. That's why we say CRI is still alpha. :) |
A user mentioned it in #linuxkit (on the docker community slack). I understood it to just be something they noticed rather than a critical issue for them. AIUI 1.9 alpha.0 is mid December and I suppose 1.9 proper will be early in the new year, so no need to hack around IMHO, it's not very long to wait (especially once various holidays are subtracted out). Users who want a fully functioning system right now can always use the (non-alpha) Docker runtime. FWIW docker for mac with Kube integrated is using Docker right now, so we don't have a requirement from there yet. |
@ijc Thanks! I'll keep this issue open until we release the beta version. In the release note, we should point that out. |
@czm4514 The new cri-containerd will only work with Kubernetes 1.9 because of some CRI change kubernetes/kubernetes#52686. What cri-containerd and kubernetes version are you using? |
I updated Linuxkit to Kube v1.9.0 and cri-containerd beta.0 and can confirm that |
I've been investigating this for a while on LinuxKit but I have now reproduced on an Ubuntu 16.04 provisioned using the
contrib/ansible
stuff as well, with both the default releases installed and with self built up to date versions ofcontainerd
andcri-containerd
added:The logs below are using the development versions.
I see two different failure modes depending on my use of the
-i/--stdin
flag. I think there are 3 issues here:--tty
errors withcode = InvalidArgument desc = one of stdin, stdout, or stderr must be set
.--tty
doesn't actually return the above error (just logs it).--tty
times out.Without
--tty
Without
-i
I see (with or without-t
):From
journalctl -u cri-containerd
the error (which isn't logged above!) is:With
--tty
After
I1115 15:15:35.146951 26914 round_trippers.go:417]
things apparently go raw and the output is staircased (ie.\n
is no longer interpreted as\r\n
), I've cleaned up the indentation manually.I've traced through a fair bit of this case but still haven't been able to track down the issue. From my tracing the process is being launched and is outputting things to its stdout, but it doesn't seem to go anywhere. I'm not 100% sure that the process's stdio is going to the FIFO rather than to /dev/null -- I had an strace which seemed to show runc dupping fd 9,10 and 11 onto 0,1,2 and observed that what I identified as the parent process appeared to be opening
/dev/null
onto fd 9, 10 and 11. It's possible that I've misidentified the parent though, or been confused by goroutines (which are a bit hard to follow in strace!).About 1 time in 100 this case does actually work, so I suspect a race rather than an incorrect invocation.
Using the docker runtime all works fine.
The text was updated successfully, but these errors were encountered: