CancelRequest not implemented by *gcp.conditionalTransport

[mattysweeps]

What happened:

Attempting to connect to a GKE cluster which no longer exists:

kubectl --request-timeout=5s get pods
E0206 10:05:40.982355  247442 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport
E0206 10:05:45.984693  247442 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport
E0206 10:05:50.985031  247442 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport
E0206 10:05:55.985319  247442 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport
E0206 10:06:00.985688  247442 round_trippers.go:174] CancelRequest not implemented by *gcp.conditionalTransport
Unable to connect to the server: context deadline exceeded (Client.Timeout exceeded while awaiting headers)

What you expected to happen:
It should fail after 5 seconds and exit with a non-zero exit status. Additionally, the error message should clearly state that the command was exited due to the request timeout being reached.

Instead, after every 5 second interval the error message CancelRequest not implemented by *gcp.conditionalTransport is shown. The request always retries 5 times: an option which I cannot find command line configuration for.

How to reproduce it (as minimally and precisely as possible):

• Create GKE cluster
• Connect to it
• Delete GKE cluster
• Run command above

Anything else we need to know?:
I'm posting here because I believe it's a Kubernetes bug, not GKE. However, I have only tested with GKE.

Environment:

• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration: GKE
• OS (e.g. from /etc/os-release): Ubuntu
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[mattysweeps]

/sig cli

[tanner-bruce]

I had this happen today with a GKE cluster that did exist. After some time the connection would go through. We also had a hostError on a GKE node at the same time. Access to the internet was fine at the time so I do not believe it was our network.

[jeremywadsack]

Had this today when the network stopped resolving hostnames. Resolving that recovered things for me, but the message could be improved.

#66013 might be related.

[ahmetb]

Can confirm it happens if GKE cluster existed before but deleted later on.

[liggitt]

@kubernetes/sig-auth-bugs

[mikedanese]

This is probably fixed by #71757

[mml]

Hmmm.. this happened to me today on a 1.13 cluster, using kubectl.1.13.

[mikedanese]

Thanks, I'll push on this then since it's showing up.