Description
In the rkt container engine integration we are trying to get full feature parity with the existing k8s API. We are very close.
The most recent snag we hit though is that rkt does not support the concept of "attach". For those who aren't familiar see the help output of kubectl attach:
$ kubectl attach --help
Attach to a process that is already running inside an existing container.
Usage:
kubectl attach POD -c CONTAINER [flags]
Examples:
# Get output from running pod 123456-7890, using the first container by default
$ kubectl attach 123456-7890
# Get output from ruby-container from pod 123456-7890
$ kubectl attach 123456-7890 -c ruby-container
# Switch to raw terminal mode, sends stdin to 'bash' in ruby-container from pod 123456-7890
# and sends stdout/stderr from 'bash' back to the client
$ kubectl attach 123456-7890 -c ruby-container -i -t
The reason rkt doesn't support this is quite practical: for applications that are long running we attach the applications stdout/stdin to a logging daemon without a man-in-the-middle. And the stdin is attached to stdin because this is sort of the accepted default for most long-running processes.
Now, rkt does support interactive applications with kubectl exec. But, you chose to do interactive ahead of time which means we skip attaching stdout/stdin/stderr to the log daemon and attach it to the calling process instead.
So, attach is this weird middle ground between kubectl logs and kubectl exec which is rather odd. I really don't understand the use case and the k8s issue introducing attach isn't super helpful either: #1521
I want to understand what are the use cases for attach and if we can do one of the following things:
-
Simply not support it in the rkt integration because the use cases are so narrow and the complexity is high to implement it
-
Remove attach from the next revision of the API, I feel like nearly all use cases of debugging can be handled with exec or even a proper session inside of the container created with sshd, etc.
-
Enumerate the compelling use cases for attach so we have some concrete use cases to justify the complexity of figuring this out inside of rkt
rkt upstream issue: rkt/rkt#1799
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
philips commentedon Mar 22, 2016
cc'ing the relevant people from the historical discussions here: @davidopp @bgrant0607 @vishh @yifan-gu @spotter @dchen1107
dchen1107 commentedon Mar 22, 2016
@philips, kubectl attach is introduced mainly for debuggability. I agreed with you that most, if not all use cases can be handled through different mechanism(s). I accepted that feature initially without much questions because I treated it as a usability level compatible with docker. :-) cc/ @ncdc who might know the real use cases for this one.
I am ok with 1) for now unless someone can come up a real use case.
bgrant0607 commentedon Mar 22, 2016
cc @brendandburns
ncdc commentedon Mar 22, 2016
cc @smarterclayton as I believe we use attach as part of
kubectl runyifan-gu commentedon Mar 22, 2016
IIRC
kubectl runessentially creates/starts a container then attaches to it.ncdc commentedon Mar 22, 2016
Yes, that is the flow in the Docker case for
kubectl run- create a container, start it, then attach to its process. If you can do that in rkt some other way than "attach", that works for me.bgrant0607 commentedon Mar 24, 2016
We definitely need
kubectl run -ti ...to work.smarterclayton commentedon Mar 24, 2016
We use attach to stream build contents to build pods.
On Thu, Mar 24, 2016 at 2:14 PM, Brian Grant notifications@github.com
wrote:
philips commentedon Mar 25, 2016
@bgrant0607 run works
@smarterclayton why not use logs?
@ncdc It is the ability to "re-attach" and also being able to attach stdin to any arbitrary process ever that is troublesome for us. I just don't get the use case and feel like it is something that is a candidate for removal because implementing it is annoying and incurs cost even when not in use.
yifan-gu commentedon Mar 25, 2016
@smarterclayton Are you saying you need to stream contents to the stdin of the running pod?
44 remaining items