search

knight42 / krelay

A better alternative to `kubectl port-forward` that can forward TCP or UDP traffic to IP/Host which is accessible inside the cluster.
MIT License
248 stars 15 forks source link

Unpredictable behaviour when not specifying a namespace? #15

Closed georgebarbarosie closed 1 year ago

georgebarbarosie commented 1 year ago

I believe that kubectl-relay uses --all-namespaces (when no --namespace flag has been provided) to look up the service to connect to, instead of looking in the context's configured namespace.

I have a service mysvc of type ClusterIP, in a namespace called staging. The current namespace (default) doesn't have a service with that name: kubectl get svc -o name mysvc shows Error from server (NotFound): services "mysvc" not found, whereas kubectl get svc -o name mysvc -n staging shows service/mysvc. However I can execute kubectl relay svc/mysvc 8080 and I can connect to the forwarded port.

This is annoying because it means there is no guarantee that the relay will connect to the service(s) in the current namespace when there are services with the same name in other namespaces. The workaround is to explicitly specify the --namespace, but this is unexpected behaviour. I have bumped into exactly this situation when I discovered this anomaly, where I was expecting krelay to forward to one service but it was forwarding to a service in a different namespace.

knight42 commented 1 year ago

@georgebarbarosie Hi, thanks for reaching out.

I believe that kubectl-relay uses --all-namespaces (when no --namespace flag has been provided) to look up the service to connect to

krelay never searches all namespaces for the Service, let alone this is inefficient. krelay reads the target namespace from kubeconfig(the namespace set in the context) and the --namespace flag https://github.com/knight42/krelay/blob/2dc5ecaf67961ae89c997f023039649c6382bedc/cmd/client/main.go#L65-L68.

I am not sure why krelay will connect to a nonexistent service, could you post the output of kubectl relay svc/mysvc 8080 -v=7?

georgebarbarosie commented 1 year ago

@knight42 shortly after I opened this bug report I realized the problem is not specific to this kubectl plugin, I'm also using cnpg's plugin and the behaviour is similar. This "bug" (I hesitate to call it that, now that I see what's causing it) manifests for a very particular setup. I spread my cluster configs across many files and set $KUBECONFIG appropriately to include them all;

There was a conflict between two of the files, it went unnoticed until now as kubectl was consistent with the merging. The plugins seem to be applying a different merging order. kubectl picks up the configured namespace from the leftmost file, the plugin picks up the configured namespace from the rightmost file.

I have fixed this by eliminating the duplication of the context definition.