Skip to content

API: use cases for kubectl attach? #23335

Closed
@philips

Description

@philips

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:

  1. Simply not support it in the rkt integration because the use cases are so narrow and the complexity is high to implement it

  2. 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.

  3. 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

Activity

philips

philips commented on Mar 22, 2016

@philips
ContributorAuthor

cc'ing the relevant people from the historical discussions here: @davidopp @bgrant0607 @vishh @yifan-gu @spotter @dchen1107

dchen1107

dchen1107 commented on Mar 22, 2016

@dchen1107
Member

@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.

added
area/apiIndicates an issue on api area.
sig/nodeCategorizes an issue or PR as relevant to SIG Node.
priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.
on Mar 22, 2016
bgrant0607

bgrant0607 commented on Mar 22, 2016

@bgrant0607
Member
ncdc

ncdc commented on Mar 22, 2016

@ncdc
Member

cc @smarterclayton as I believe we use attach as part of kubectl run

yifan-gu

yifan-gu commented on Mar 22, 2016

@yifan-gu
Contributor

cc @smarterclayton as I believe we use attach as part of kubectl run

IIRC kubectl run essentially creates/starts a container then attaches to it.

ncdc

ncdc commented on Mar 22, 2016

@ncdc
Member

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

bgrant0607 commented on Mar 24, 2016

@bgrant0607
Member

We definitely need kubectl run -ti ... to work.

smarterclayton

smarterclayton commented on Mar 24, 2016

@smarterclayton
Contributor

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:

We definitely need kubectl run -ti ... to work.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#23335 (comment)

philips

philips commented on Mar 25, 2016

@philips
ContributorAuthor

@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

yifan-gu commented on Mar 25, 2016

@yifan-gu
Contributor

We use attach to stream build contents to build pods.

@smarterclayton Are you saying you need to stream contents to the stdin of the running pod?

44 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/apiIndicates an issue on api area.area/rktpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.sig/nodeCategorizes an issue or PR as relevant to SIG Node.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ncdc@philips@feiskyer@smarterclayton@resouer

        Issue actions

          API: use cases for kubectl attach? · Issue #23335 · kubernetes/kubernetes