### What happened?

When running a command with `kubectl exec`, the output (data written to stdout) can be truncated without the command returning an error. This results in ambiguity around the command failing or network being torn down with an error (non-zero exit code) versus the command completing successfully and returning complete output (exit code 0).

Unsure what causes variation here, but probably related to network I/O speed and/or latency. Here's an example of drastic failures and inconsistencies on my machine:

```
% for i in 1 2 3 4 5; do kubectl exec "${POD:?}" -- sh -c 'seq 1 2000000' | tail -n1; done
1788552
1994888
809911
1862792
1214600
```

If it doesn't reproduce for you, try adding some network latency or bandwidth restrictions, or increasing the amount of data that goes across the pipe. Visiting fast.com in a browser while running the tests, running more tests, and transferring more output (larger second value in the `seq` command) will help reproduce.

### What did you expect to happen?

I _either_:

- Get all of the commands output, OR
- Get truncated output and a non-zero exit code

### How can we reproduce it (as minimally and precisely as possible)?

Run a command against a POD a number of times, see that the output always matches (it should):

```
for i in 1 2 3 4 5; do kubectl exec ${POD:?} -- sh -c 'seq 1 2000000' | tail -n1; done
```

If this doesn't reproduce try:
* using a larger value for the upper bounds to `seq`
* adding latency and/or bandwidth restrictions to the network link
* (wouldn't reproduce for a colleague, had him visit fast.com in a browser while testing, which trigged it right away)

### Anything else we need to know?

This appears to have been a problem for a long time:

[Kubectl appears to be discarding standard output](https://stackoverflow.com/questions/74710112/kubectl-appears-to-be-discarding-standard-output)
["kubectl exec" sometimes incorrectly returns empty string causing tests to flake](https://github.com/kubernetes/kubernetes/issues/34256)
#34256] (closed w/ only workaround)

### Kubernetes version

Also reproduces with (all permuatations of) client version 1.29, server version v1.27.11-eks-b9c9ed7:

```
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.11-gke.1062000
```

Also reproed with:

```
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.11-eks-b9c9ed7
```

### Cloud provider

Reproduces against both AWS and GCP managed k8s.

### OS version

I am on OS X.

```
Darwin hostname 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64
```

Didn't have anyone handy not on OS X to try to repro.

### Install tools

_No response_

### Container runtime (CRI) and version (if applicable)

_No response_

### Related plugins (CNI, CSI, ...) and versions (if applicable)

_No response_
kubectl exec truncates stdout without reporting error
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : kubectl exec truncates stdout without reporting error
Issue date:

--- start body ---
### What happened?

When running a command with `kubectl exec`, the output (data written to stdout) can be truncated without the command returning an error. This results in ambiguity around the command failing or network being torn down with an error (non-zero exit code) versus the command completing successfully and returning complete output (exit code 0).

Unsure what causes variation here, but probably related to network I/O speed and/or latency. Here's an example of drastic failures and inconsistencies on my machine:

```
% for i in 1 2 3 4 5; do kubectl exec "${POD:?}" -- sh -c 'seq 1 2000000' | tail -n1; done
1788552
1994888
809911
1862792
1214600
```

If it doesn't reproduce for you, try adding some network latency or bandwidth restrictions, or increasing the amount of data that goes across the pipe. Visiting fast.com in a browser while running the tests, running more tests, and transferring more output (larger second value in the `seq` command) will help reproduce.

### What did you expect to happen?

I _either_:

- Get all of the commands output, OR
- Get truncated output and a non-zero exit code

### How can we reproduce it (as minimally and precisely as possible)?

Run a command against a POD a number of times, see that the output always matches (it should):

```
for i in 1 2 3 4 5; do kubectl exec ${POD:?} -- sh -c 'seq 1 2000000' | tail -n1; done
```

If this doesn't reproduce try:
* using a larger value for the upper bounds to `seq`
* adding latency and/or bandwidth restrictions to the network link
* (wouldn't reproduce for a colleague, had him visit fast.com in a browser while testing, which trigged it right away)

### Anything else we need to know?

This appears to have been a problem for a long time:

[Kubectl appears to be discarding standard output](https://stackoverflow.com/questions/74710112/kubectl-appears-to-be-discarding-standard-output)
["kubectl exec" sometimes incorrectly returns empty string causing tests to flake](https://github.com/kubernetes/kubernetes/issues/34256)
#34256] (closed w/ only workaround)

### Kubernetes version

Also reproduces with (all permuatations of) client version 1.29, server version v1.27.11-eks-b9c9ed7:

```
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.11-gke.1062000
```

Also reproed with:

```
Client Version: v1.29.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.11-eks-b9c9ed7
```

### Cloud provider

Reproduces against both AWS and GCP managed k8s.

### OS version

I am on OS X.

```
Darwin hostname 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000 arm64
```

Didn't have anyone handy not on OS X to try to repro.

### Install tools

_No response_

### Container runtime (CRI) and version (if applicable)

_No response_

### Related plugins (CNI, CSI, ...) and versions (if applicable)

_No response_
--- end body ---
