I am facing the same issue. In my case, the js code running this library is my local system and the target pod is on minikube. I have not tested this when both the js code running this library is also on k8s. Anyway, an observation I have made is that cpToPod has a last line as

When I test locally by adding an await (to make it await this.execInstance.exec(...), then cpToPod just hangs as noted by the OP.

@vip30 kindly suggest any changes?

@w3ichen I think I have figured out a reason why this could happen. After much trial and error, I noticed that the copy was actually working if I wait for the pod to get into the Running phase before I call the cp.cpToPod function. I have made a PoC that shows how this works at https://github.com/SayakMukhopadhyay/k8s-cp-test.

Maybe the maintainers would be able to confirm if my observations are correct.

EDIT: Upon further debugging the above project, I see that the items are not copied until the program exits. I have put a breakpoint in console.log('Done') and have waited for varying amounts of time but don't see the copied items. I see them as soon as the program exits. I am not sure what is happening here. Some insight would be great!

I think I have found out why the program wants to exit before the copying is completed. I created the above PR to fix that. @w3ichen maybe you can check that PR and see if that works for you.

@SayakMukhopadhyay I tested your PR and it works for me. The way you're doing it by listening to when the websocket closes seems like the only way right now because the exec will resolve once the websocket is established and it doesn't call any callback functions.

I'm closing this issue now because the cpToPod does work but only in certain conditionals that were not clear at first.

In order for cpToPod to work:

1. The pod must be "running".
2. tgtPath must be a directory and not a filename. This was causing it to silently fail on me before.
3. The statusCallback is never called (ie. async ({ status }) => { ... }). This led me to think that it was hanging but it does resolve eventually.

Improvements:

1. cpToPod will resolve without waiting for the copying to complete. This can be fixed by using a Promise as @SayakMukhopadhyay suggested.
2. The current function makes use of temporary files and requires actual files to exist. For me, I wanted to avoid reading/writing to files for speedup and I needed to use strings. So I extended the Cp class with cpFromPodToString and cpStringToPod as follows:

import * as k8s from "@kubernetes/client-node";
import { Cp } from "@kubernetes/client-node";
import { WritableStreamBuffer } from "stream-buffers";
import { Callback, Headers, pack } from "tar-stream";

export type TarEntry = [Headers, string, Callback?];

export class CustomCp extends Cp {
  public async cpFromPodToString(namespace: string, podName: string, containerName: string, srcPath: string): Promise<string> {
    return new Promise((resolve, reject) => {
      const command = ["cat", srcPath];
      const writerStream = new WritableStreamBuffer();
      const errStream = new WritableStreamBuffer();
      this.execInstance.exec(
        namespace,
        podName,
        containerName,
        command,
        writerStream,
        errStream,
        null,
        false,
        async ({ status }) => {
          if (status === "Failure" || errStream.size())
            reject(`Error from cpFromPodToString - details: \n ${errStream.getContentsAsString()}`);
          resolve(writerStream.getContentsAsString() || "");
        }
      );
    });
  }

  public async cpStringToPod(
    namespace: string,
    podName: string,
    containerName: string,
    srcFiles: TarEntry[],
    tgtPath: string
  ): Promise<void> {
    const readStream = pack();
    srcFiles.forEach((tarEntry) => {
      readStream.entry(...tarEntry);
    });
    readStream.finalize();

    const command = ["tar", "xf", "-", "-C", tgtPath];

    const errStream = new WritableStreamBuffer();
    const conn = await this.execInstance.exec(
      namespace,
      podName,
      containerName,
      command,
      null,
      errStream,
      readStream,
      false,
      async ({ status }) => {
        // Does not reach here for unknown reasons
        if (status === "Failure" || errStream.size()) {
          throw new Error(`Error from cpStringToPod - details: \n ${errStream.getContentsAsString()}`);
        }
      }
    );

    return new Promise((resolve) => {
      conn.onclose = (event) => {
        resolve();
      };
    });
  }
}

const kc = new k8s.KubeConfig();
kc.loadFromDefault();
const exec = new k8s.Exec(kc);

export const cp = new CustomCp(kc, exec);

@w3ichen Could you please keep the issue opened since I have the same issue and I want to ensure that the maintainers see this as an open item and not something that has been "fixed".

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten