Join Log in
Score:1
Oana avatar Server

VMWare Workstation and Windows 10: can't connect to a server hosted on VM

cn flag
Oana

I have a private 2 nodes Kubernetes cluster configured on VMWare Workstation 15. I'm using MetalLB and Calico. Ingress service and ingress look like:

xxx@c1-cp1:~/Desktop$ kubectl get svc -n ingress-controller-2
NAME                                         TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
wsnginx-ingress-nginx-controller             LoadBalancer   10.109.117.222   192.168.44.136   80:30167/TCP,443:30680/TCP   24h
wsnginx-ingress-nginx-controller-admission   ClusterIP      10.105.103.165   <none>           443/TCP                      24h
xxx@c1-cp1:~/Desktop$ kubectl get ing apollo-ingress
NAME             CLASS     HOSTS                ADDRESS          PORTS   AGE
apollo-ingress   wsnginx   test.xxx.com   192.168.44.136   80      3h17m

I am using Nat Network Adapter and static IPS. I have port forwarding configured as following

enter image description here

curl -D- http://192.168.44.136 -H 'Host: test.xxx.com' from VM, returns 200 status but I cannot manage to access it from host machine Win10 on 127.0.0.1:8080 as I get a 404 NGINX NotFound.

Could you please help me out? what am I doing wrong? How else could I expose it in my private network? Thank you!

UPDATE I am not sure if this is the right way, but I managed to connect from the host machine, by changing a bit the Ingress resource. I put in comments the host parameter, as

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apollo-ingress
spec:
  ingressClassName: wsnginx
  rules:
    #- host: test.xxx.com
    - http:
        paths:
          - backend:
              service:
                name: apollo-service
                port: 
                  number: 80
            path: /
            pathType: Prefix

and now my ingress looks like this

NAMESPACE   NAME                                                   CLASS     HOSTS                        ADDRESS          PORTS     AGE
default     ingress.networking.k8s.io/apollo-ingress               wsnginx   *                            192.168.44.136   80        3h31m

It seems that I can access it now from my host machine as well. I am having a Rest API so I've just opened it from browser http://127.0.0.1:8080

105
0 + 0
in flag
mdaniel
Hi Oana welcome to S.F. You didn't include the actual test command for your Win10 example, but for clarity: Ingress resources are entirely host-header virtual hosted, meaning (just as you did with your `curl`) you _must_ include a `host:` header so the ingress controller knows how to route your request. Good luck
0
Reply
Oana avatar
cn flag
Oana
hi @mdaniel ! thank you :) Well, i was just trying to open it in browser (as there is a REST API) --> 127.0.0.1:8080; but i made it work in the meantime by removing the host value from ingress manifest `rules: #- host: test.xxx.com - http: paths: - backend: service: name: apollo-service port: number: 80` Is this ok?
0
Reply
Score:1
p10l avatar Server
us flag
p10l

This seems like a simple issue of missing HTTP header.

First, short explanaition:
Whenever a Host field is specified in Ingress manifest, only connections from that host will be accepted. This information is extracted form Host HTTP header. If you do not specify Host field in Ingress manifest, requests from all sources will be accepted.

You did sent the request correctly the first time

curl -D- http://192.168.44.136 -H 'Host: test.xxx.com'

But forgot to do this the second time.
Powershell equivalent of the above is

Invoke-WebRequest -Uri http://127.0.0.1 -Headers @{"Host"="test.xxx.com"}

This is all nice and easy when done from command line, but sending request from web browser is a tad harder. Web broswers does not allow you to modify a request, to include proper Host header, by default. However such functionality can be achieved with extensions:

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.