gateway

gateway copied to clipboard

Currently the create-cluster make target does not expose any host ports. This means the Envoy service LB IP, via metallb load balancer, is unreachable. This target should configure a kind worker node that maps host ports to container ports.

some workaround for MacOS

• skip creating a new cluster and directly use the Kubernetes cluster created by Docker Desktop

kubectl cluster-info
Kubernetes control plane is running at https://kubernetes.docker.internal:6443
CoreDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

kubectl get svc -A
NAMESPACE              NAME                            TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                  AGE
default                httpbin                         ClusterIP      10.103.178.219   <none>        80/TCP                   82s
default                kubernetes                      ClusterIP      10.96.0.1        <none>        443/TCP                  2m39s
envoy-gateway-system   envoy-eg                        LoadBalancer   10.108.163.57    localhost     8080:30219/TCP           57s
envoy-gateway-system   envoy-gateway                   ClusterIP      10.103.173.150   <none>        18000/TCP                86s
envoy-gateway-system   envoy-gateway-metrics-service   ClusterIP      10.102.166.134   <none>        8443/TCP                 86s
gateway-system         gateway-api-admission-server    ClusterIP      10.105.180.95    <none>        443/TCP                  90s
kube-system            kube-dns                        ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP   2m38s

curl --verbose --header "Host: www.example.com" http://$GATEWAY_HOST:8080/get
*   Trying ::1...
* TCP_NODELAY set
* Connected to  (::1) port 8080 (#0)
> GET /get HTTP/1.1
> Host: www.example.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< server: envoy
< date: Thu, 08 Sep 2022 23:52:37 GMT
< content-type: application/json
< content-length: 238
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 3
< 
{
  "args": {}, 
  "headers": {
    "Accept": "*/*", 
    "Host": "www.example.com", 
    "User-Agent": "curl/7.64.1", 
    "X-Envoy-Expected-Rq-Timeout-Ms": "15000"
  }, 
  "origin": "10.1.0.11", 
  "url": "http://www.example.com/get"
}
* Connection #0 to host  left intact
* Closing connection 0

• Or detect the Host OS and setup port forwards before tests start and clean up once it ends

@arkodg @LukeShu @skriss should we add the above workaround to EG dev docs? If so, what approach do you prefer?

Am I understanding correctly that this is all macOS-specific concerns? If so, I don't have a particularly strong opinion, as I don't use macOS.

Plus, I'm used to using telepresence connect as a sort of better kubect port-forward.

I'd suggest taking another look at https://github.com/chipmk/docker-mac-net-connect, I've had success using it before on macOS for this sort of thing and it doesn't require any changes for EG. I can try to find some time to test it out.

@skriss PTAL at https://github.com/envoyproxy/gateway/pull/489. I was able to verify https://github.com/chipmk/docker-mac-net-connect works as expected. Thanks for the pointer.

Note: Comment-out run-kube-local target to avoid dev confusion.