I'm working to recreate the SmartHotel360 demo in Azure Kubernetes Service but it seems like the ingress controller isn't working.
Here's what a working example should look like (redirect hotels service to /hotels-api): http://sh360production.2c3abf6edd44497688b2.westus.aksapp.io/hotels-api/
But when I deploy my website, it redirects /hotels-api to a blank webpage, which is how I suspected that something was breaking in the Ingress Controller. http://23.96.16.121/hotels-api.
From the docs that I was reading about the ingress controller, I deployed the service using kubectl apply -f ingress.yaml. I can see in the Ingresses page in the K8s UI that all of the services have the same external IP address and the ingress service is under Services, but I don't see anything else. I deployed all of the backend services using helm and it looks like they also show up in the UI.
The ingress.yaml file looks like:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
labels:
app: sh360
component: frontend
name: sh360-ingress
annotations:
kubernetes.io/ingress.class: addon-http-application-routing
ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
rules:
- host: swsmarthotel360-409bbcc0.hcp.eastus.azmk8s.io
http:
paths:
- path: /hotels-api
backend:
serviceName: helm-test2-hotels-sh360-hotels
servicePort: 80
- path: /bookings-api
backend:
serviceName: bookings
servicePort: 80
- path: /suggestions-api
backend:
serviceName: suggestions
servicePort: 80Since I'm new to AKS and Kubernetes, is there something missing in the ingress.yaml file that will redirect to services?
(full reference: https://github.com/Microsoft/SmartHotel360-AKS-DevSpaces-Demo)
Reading over your question again: - host: swsmarthotel360-409bbcc0.hcp.eastus.azmk8s.io http: paths: - path: /hotels-api
so your ingress might be working fine. I believe your testing methodology of http://23.96.16.121/hotels-api is the problem.
What I think you want to do is edit your hostfile to have an entry like: swsmarthotel360-409bbcc0.hcp.eastus.azmk8s.io 23.96.16.121
Then when you go to swsmarthotel360-409bbcc0.hcp.eastus.azmk8s.io/hotels-api It'll go to your Cluster.
Ingress can only be reached by L7 addresses. If that hostfile hack works, then you'd just need to modify DNS to make it work without a hostfile t-shoot hack.
\=================================
(Original Answer)
I also use AKS (Azure's Kbuernetes as a Service) The answer depends on the options you specify when you deploy your cluster.
There's a flag to enable RBAC yes or no (I don't see RBAC statements in your YAML) There's also a [HTTP application routing yes or no] flag. (It's on by default, but we turn it off so we can use our own DNS and our own Ingress)
Anyways I hope this points you in the right direction:
I recommend you create a test cluster to learn more and on that test cluster:
1.) specify RBAC on and HTTP routing off
2.) Go here https://kubernetes.github.io/ingress-nginx/deploy/ apply the mandatory command and the cloud generic ingress controller command.
The cloud generic ingress controller will Spawn a L4 load balancer VM in Azure, automap it to a nodeports service, that will forward it to L7 Nginx LB service that exists inside your cluster thanks to the kubectl apply commands mentioned above. That L7 Nginx Service's pods are is controlled by ingress controller pod and is managed/configuring using ingress objects.
To test it you can look up the L4 LB's IP address (kubectl get svc --all-namespaces -o wide) should show you it's IP. One of your ingress rules might be mywebsite.com/homepage. so to test you could edit your hostfile with an entry like mywebsite.com