Use Case: Remote Node Accessibility

To route traffic from one cluster to a service hosted on a worker node in another, configure externalIPs explicitly within the Service definition. This method bypasses standard internal load balancing to target specific physical addresses, enabling direct communication between distributed environments.

Preparation Phase

1. Node Cordon: Prevent the Kubernetes scheduler from placing new pods on the host running the critical workload by marking it as unschedulable.
2. Service Binding: Define the Service manifest including the private IP of the target worker node in the spec.externalIPs array.
3. Network Rules: Insure firewalls or security groups permit ingress traffic from the source cluster CIDR to the destination node IP on the designated port.
4. Endpoint Mapping: In the consuming cluster, manually define an Endpoints object pointing to the remote externalIP rather than relying on label selectors.

Server Configuration

Create a deployment and expose it using a fixed external address.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
spec:
  replicas: 1
  selector:
    matchLabels:
      tier: core-layer
  template:
    metadata:
      labels:
        tier: core-layer
    spec:
      containers:
      - name: web-server
        image: httpd:2.4-alpine
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: remote-edge-service
spec:
  externalIPs:
    - 192.168.10.50
  ports:
  - port: 8443
    targetPort: 8080
    protocol: TCP
  selector:
    tier: core-layer

In this configuration, requests hitting IP 192.168.10.50 on port 8443 are redirected to the pod's port 8080. The selector ensures only pods matching tier: core-layer receive the traffic.

Client-Side Proxy Setup

On the requesting cluster, create a local Service that acts as a proxy to the external endpoint.

apiVersion: v1
kind: Endpoints
metadata:
  name: backend-target-subset
subsets:
  - addresses:
      - ip: 192.168.10.50
    ports:
      - port: 8443
---
apiVersion: v1
kind: Service
metadata:
  name: cross-cluster-gateway
spec:
  ports:
    - port: 3000
      protocol: TCP

The local Service cross-cluster-gateway does not select any pods via labels. Instead, the asssociated Endpoints resource statically points to the remote machine defined in the previous step.

Connectivity Verification

Retrieve the ClusterIP assigned to the gateway service and verify connectivity to the upstream server.

kubectl get endpoints
curl http://<GATEWAY_CLUSTER_IP>:3000

If successful, the response originates from the httpd instance on the remote worker node, confirming the routing path is established.