94 lines
4.9 KiB
Markdown
94 lines
4.9 KiB
Markdown
#### Overview
|
|
|
|
|Feature|kubectl port-forward|SSH Tunnel (-L)|VPN (Wireguard/Tailscale)|
|
|
|---|---|---|----|
|
|
|Setup|Zero (if you have kubectl)|Requires SSH access|Requires Client/Driver install|
|
|
|Scope|Single Port/Service|Single Port/Service|Entire Network|
|
|
|Lifetime|Temporary (dies if cmd closes)|Temporary|Persistent/Background|
|
|
|OS Level|User-space (Application)|User-space (Application)|Kernel-space (Network Card)|
|
|
|
|
From a technical point of view, kubectl port-forward is most accurately described as a User-Space Application Proxy or a Layer 7 Tunnel.
|
|
|
|
It is not a full-blown VPN or a network-level tunnel like Wireguard. Instead, it is a "targeted bridge" created specifically for one-way traffic between your local machine and a specific service inside the cluster.
|
|
|
|
|
|
1. Closest Match: SSH Local Port Forwarding (ssh -L)
|
|
This is the "twin brother" of kubectl port-forward.
|
|
|
|
How it's similar: You use an existing encrypted management channel (SSH or the Kubernetes API) to "piggyback" traffic for a specific port. Neither creates a new network interface on your machine; they just listen on a local port and "teleport" data to the other side.
|
|
|
|
The Comparison: Just as ssh -L 5436:localhost:5432 user@server maps a remote DB to your laptop, kubectl does the same for a Pod.
|
|
|
|
2. Cloudflare Tunnel (cloudflared)
|
|
How it's similar: Both allow you to bypass firewalls and NAT without opening public ports. They both rely on an "outbound" connection from the cluster/server to a central controller to establish the path.
|
|
|
|
The Difference: Cloudflare Tunnels are designed for permanent, public-facing access; port-forward is a temporary, private developer tool.
|
|
|
|
3. What it is NOT: VPNs (OpenVPN, Wireguard, Tailscale)
|
|
Why they are different: A VPN creates a Virtual Network Interface (like tun0 or utun). When you use a VPN, your laptop actually "lives" inside the 10.x.x.x network. You could ping any Pod or Service directly by its internal IP.
|
|
|
|
With port-forward: Your laptop doesn't know the db namespace exists. It only knows that localhost:5436 is magically connected to something else.
|
|
|
|
|
|
|
|
#### Where do they live on the OSI Model?
|
|
```
|
|
1. Layer 7 (Application Layer): kubectl port-forward and SSH Tunneling
|
|
Reason: These tools do not understand "IP addresses" or "Routing" in the traditional sense.
|
|
|
|
When you run kubectl port-forward, the kubectl binary on your machine opens a local socket.
|
|
|
|
It takes the data from that socket, wraps it in an HTTP/SPDY or HTTP/2 request, and sends it to the Kubernetes API server.
|
|
|
|
The API server then unwraps that data and sends it to the Pod.
|
|
|
|
Because the "tunneling" happens inside an application protocol (HTTP/SSH), it is a Layer 7 operation.
|
|
|
|
Layer 3 (Network Layer): VPNs (Wireguard, OpenVPN, IPSec)
|
|
Reason: These create a Virtual Network Interface (like utun0).
|
|
|
|
They handle IP Packets.
|
|
|
|
If you send a ping to 10.42.0.5, the VPN intercepts that packet at the Network Layer, encrypts it, and sends it to the other side.
|
|
|
|
It doesn't care if the data inside is Postgres, HTTP, or DNS; it only cares about the IP Header.
|
|
|
|
Layer 2 (Data Link Layer): VXLAN, Tinc, or Bridge-mode VPNs
|
|
Reason: Some advanced VPNs can operate at Layer 2.
|
|
|
|
They transport Ethernet Frames (including MAC addresses).
|
|
|
|
This makes your local computer think it is plugged into the same "virtual switch" as the remote servers.
|
|
|
|
2. Other Technologies to Connect
|
|
If port-forward is too temporary, here are the professional alternatives:
|
|
|
|
A. Ingress Controller (Layer 7)
|
|
How it works: You define a "Route" (e.g., db.example.com). The Ingress (like Nginx or Traefik) receives the traffic and forwards it to your service.
|
|
|
|
Layer: 7 (Application). It looks at the Hostname and Path in the HTTP/TLS header to decide where to send the data.
|
|
|
|
B. LoadBalancer Service (Layer 4)
|
|
How it works: In a cloud environment (AWS/GCP), this gives your Service a real, reachable IP address.
|
|
|
|
Layer: 4 (Transport). It only cares about the Port and Protocol (TCP/UDP). It doesn't look at the data inside the packets.
|
|
|
|
Comparison: This is like a "Permanent Port-Forward" that anyone on the internet (or your VPC) can reach.
|
|
|
|
C. Mesh VPNs / SD-WAN (Layer 3 - Overlay)
|
|
Examples: Tailscale, ZeroTier, Nebula.
|
|
|
|
How it works: You install a small agent on your VM and your laptop. They create a "Peer-to-Peer" encrypted mesh.
|
|
|
|
Layer: 3 (Network). It provides a stable IP address for your database that stays the same even if you move from office to home.
|
|
|
|
Reason to use: This is the most "production-ready" version of what you are doing. It is more secure than a public LoadBalancer but more stable than a port-forward.
|
|
|
|
```
|
|
|
|
|Technology|OSI Layer|Comparison|
|
|
|----|---|---|
|
|
|kubectl port-forward|Layer 7|"A temporary ""straw"" to sip data from one |specific cup.|
|
|
|Ingress|Layer 7|A ""Receptionist"" directing visitors based on the name on the |envelope.|
|
|
|LoadBalancer|Layer 4|"A ""Direct Pipeline"" to a specific door (port).|
|
|
|Tailscale / VPN|Layer 3|"A ""Secret Tunnel"" that puts your whole house next to the office.| |