New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API: use cases for kubectl attach? #23335
Comments
cc'ing the relevant people from the historical discussions here: @davidopp @bgrant0607 @vishh @yifan-gu @spotter @dchen1107 |
@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. |
cc @smarterclayton as I believe we use attach as part of |
IIRC |
Yes, that is the flow in the Docker case for |
We definitely need |
We use attach to stream build contents to build pods. On Thu, Mar 24, 2016 at 2:14 PM, Brian Grant notifications@github.com
|
@bgrant0607 run works @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. |
@smarterclayton Are you saying you need to stream contents to the stdin of the running pod? |
@philips I think that the ability to reattach an arbitrary number of times is a limited use case, specific to debugging. I would be fine deprecating and eventually removing this ability. However, it's not currently that simple, because: @yifan-gu yes, we start a pod that waits to receive data via stdin. We then use attach to connect a client to the running process in the pod, and the client streams data to the process's stdin. |
Yes - it's the most reliable way to deliver content to a pod that
requires no additional infrastructure. We have a few job style pods
people are running that stream from STDIN in order to have a shell in
the cluster but that's not a significant workload.
|
We have StdinOnce to control whether it can be reopened. We don't
have a use case with stdinOnce: false today as Andy notes.
|
It cannot attach the pod, but the pod is still running. Besides, if the pod completes quickly after start, run with
|
Looks like we don't have the issue to provide kubectl run -i through rkt run -i. How about kubectl attach? |
@dchen1107 We can do through But I am not sure what if we detach the container after |
Using CTRL-C can detach the container. |
@dchen1107 I tried that after |
Ok, remove the |
^P + ^Q is the escape sequence. We need to document it as part of `kubectl
run` and `kubectl attach`
https://docs.docker.com/engine/quickstart/#running-an-interactive-shell
|
Our exec and attach experience needs some TLC - we probably need to
devote some time to polishing it up and fixing the various terminal
resize / connect / settings bugs that have hung around.
|
@smarterclayton reviewing #16451 is a good start. Once that's in, we can move on to resize, etc. I'd also like to start looking more into deprecating spdy and replacing with http/2. |
FYI, related e2e tests that testing the kubectl attach functionality in the default gce e2e testing suit are:
|
cc @feiskyer |
cc @kubernetes/sig-rktnetes |
@feiskyer what's the plan for this feature. Is there any current PR/discussion going around this that I'm missing? |
OpenShift still needs it to support our image build functionality. @bparees @smarterclayton have we done any design work to replace attach with another mechanism? |
@ncdc @csrwng investigated this for us, resulting in these trello cards: |
I'm going to draw a bit of a higher line - attach is a pretty
important scenario for any platform that runs Linux processes.
I think the bar for taking this feature away is a lot higher than
"it's hard to do", I think it fundamentally limits what a container
platform can do.
Stdin, stdout, and stderr are part of the bedrock of computing. We
need to have very, very good arguments why they are not relevant in
the cloud infrastructure space both from a usability and design
perspective.
|
Just to summarize, we've had a discussion on sig-node slack channel about this feature. IIRC, the conclusion is that we should try implementing this feature and share code between rkt and the oci integration if possible. |
IIUC, containerd uses pipes for stdin & stdout/stderr. Can we avoid that and use pipes just for stdin? That way, there is no necessity for a daemon to drain data from the pipes. |
This is an interesting idea. To be clear, are you suggesting the stdout/stderr come from the log? |
@yifan-gu Yeah. instead of using pipes, would it be possible to use regular files for stdout & stderr? |
OK, so I think we have moved past the point of considering whether we can not implement attach. It is part of the CRI and so we will work to get it implemented there. @lucab and @timstclair are working on that. |
…herry-pick-23332-to-release-3.11 [release-3.11] UPSTREAM: 1679612: kubelet_stats: fix potential e2e crash dereferencing CPU Origin-commit: 01dd9628b3bb0d9f310b5faaab63b36797242585
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
: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
andkubectl exec
which is rather odd. I really don't understand the use case and the k8s issue introducing attach isn't super helpful either: #1521I 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
The text was updated successfully, but these errors were encountered: