How kubectl port-forward works?

kubectl exposes commands that can be used to create a Service for an application and assigns an IP address to access it from internet.

As far as I understand, to access any application within Kubernetes cluster there should be a Service resource created and that should have an IP address which is accessible from an external network.

But in case of port-forward how does kubectl create a connection to the application without an IP address which is accessible externally?

Solution 1:

To start, it's useful to note and remember that in Kubernetes, every pod gets its own ip address from 10.*, that is usable only within the cluster. Now, the port-forward feature of kubectl simply tunnels the traffic from a specified port at your local host machine to the specified port on the specified pod. API server then becomes, in a sense, a temporary gateway between your local port and the Kubernetes cluster.

kubectl port-forward forwards connections to a local port to a port on a pod. Compared to kubectl proxy, kubectl port-forward is more generic as it can forward TCP traffic while kubectl proxy can only forward HTTP traffic.

kubectl port-forward is useful for testing/debugging purposes so you can access your service locally without exposing it.

Below is the name of the pod and it will forward it's port 6379 to localhost:6379.

kubectl port-forward redis-master-765d459796-258hz 6379:6379 

which is the same as

kubectl port-forward pods/redis-master-765d459796-258hz 6379:6379

or

kubectl port-forward deployment/redis-master 6379:6379 

or

kubectl port-forward rs/redis-master 6379:6379 

or

kubectl port-forward svc/redis-master 6379:6379

Solution 2:

kubectl port-forward makes a specific Kubernetes API request. That means the system running it needs access to the API server, and any traffic will get tunneled over a single HTTP connection.

Having this is really useful for debugging (if one specific pod is acting up you can connect to it directly; in a microservice environment you can talk to a back-end service you wouldn't otherwise expose) but it's not an alternative to setting up service objects. When I've worked with kubectl port-forward it's been visibly slower than connecting to a pod via a service, and I've found seen the command just stop after a couple of minutes. Again these aren't big problems for debugging, but they're not what I'd want for a production system.