Note: using config maps as log storage is limited to 1M as that's etcd's biggest document size.  Essentially if we used the in-cluster approach we'd need to have a pod which is alive while we collect, then extract the logs before killing it.  The other option is to upload to s3, but that puts a burden on the customer to start using AWS, so no go.

Not sure this is really 'feature backlog' - this *has to be* table stakes for EKS/AKS/GKE integration otherwise we simply can't support those deployments.

Jobs by default keeps the pods around until the job is deleted so should be easy to get the output file off - https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#job-termination-and-cleanup

Fair cop.  Sounds like you *DEMAND* support for 1.2.0

Actually, once the pod has completed the container is no longer running, so you cannot perform a remote exec, which means cp won't function (it basically works like scp)

With docker directly:

$ docker cp b215f2f5d723:/usr/bin/perl .

$ ls -l 

total 1976

-rwxr-xr-x 1 docker docker 2021960 Jun 10 17:37 perl

With kubectl:

kubectl cp default/pi-with-timeout-jdn29:/usr/bin/perl .

error: usr/bin/perl no such file or directory

What about EKS?

See this here K8S-661 that's where

Sweet!