I was Trying out kuberenets in my local with a tutorial and ran into some issues.
I used Docker to build images of few snippets in node js and then used it to deploy in microk8s. Everything is working perfectly without the ingress controller.
The containers are
client - port 3000 (react app)
posts - port 4000
comments - port 4001
moderation ...
I applied this configuration after enabling ingress in microk8s
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-srv
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
rules:
- host: posts.com
http:
paths:
- path: /posts/create
backend:
serviceName: posts-clusterip-srv
servicePort: 4000
- path: /posts
backend:
serviceName: query-clusterip-srv
servicePort: 4002
- path: /posts/?(.*)/comments
backend:
serviceName: comments-clusterip-srv
servicePort: 4001
- path: /?(.*)
backend:
serviceName: client-clusterip-srv
servicePort: 3000
I've ensured to edit the hosts file to set
127.0.0.1 posts.com
When i check the k8s for ingress This is my result
Please guide me on how to troubleshoot this or what's going wrong in my setup.
It worked once and when i tried it again with skaffold,(it deploys pods without any issue, i can still access via NodePort service) Its not working when i goto posts.com in browser. please tell me what went wrong.
PS. When i ping posts.com its pointing to 127.0.0.1 as well
Actually I resolved it by Restarting my PC.
I'm not sure how, as I've also reinstalled microk8s and tried minikube as well.
It was something associated with the OS I suppose, somehow its working after a restart.
Related
Hi I am very new to kubernetes. I have a k3s.io cluster setup (Server version 1.20) and I want to run multiple web apps under the same domain. I use the k3s default ingress controller (traefik).
Depending on the path given, the request should be routed to the configured web app.
dev.xxxxxxx.de/app -> should go to my self developed .net blazor webassembly app
dev.xxxxxxx.de/graf -> should go to the grafana service/pod
Both apps/services are running in the browser and can be reached sucessfully by their service name via NodePort (without ingress). So I suspect the problem in ingress routing.
My ingress.yaml:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
labels:
environment: dev
annotations:
kubernetes.io/ingress.class: "traefik"
spec:
tls:
- hosts:
- dev.xxxxxxx.de
rules:
- host: dev.xxxxxxx.de
http:
paths:
- path: /app
pathType: ImplementationSpecific
backend:
service:
name: iot-app
port:
number: 80
- path: /graf
pathType: ImplementationSpecific
backend:
service:
name: grafana
port:
number: 3000
The problem now is that when browsing to dev.xxxxxxx.de/app or dev.xxxxxxx.de/graf, in both cases the initial request is returned with a 200, but the subsequent requests like assets (css, js) return a 404.
I suspect that the URL
dev.xxxxx.de/app/bootstrap.min.css
is getting transformed to
dev.xxxxx.de/bootstrap.min.css
which leads to a 404.
All hints why I cannot fully browse both of the apps appreciated! Thanks.
As I solved the very same issue right now on my K3s-cluster:
Have you tried to start your master with the --cluster-domain option (see the docs)?
I added that option in the /etc/systemd/system/k3s.service of my master and that did the trick for me.
I have this yaml for an Ingress:
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: app
namespace: ingress-controller
... omitted for brevity ...
spec:
rules:
- host: ifs-alpha-kube-001.example.com
http:
paths:
- path: /
pathType: ImplementationSpecific
backend:
serviceName: service-nodeport
servicePort: 80
- path: /
pathType: ImplementationSpecific
backend:
serviceName: service-nodeport
servicePort: 443
status:
loadBalancer:
ingress:
- {}
In the above I set ...
- host: ifs-alpha-kube-001.example.com
That host just happens to be one of my nodes. I have three nodes. I am pretty certain that this incorrect. The ingress works but if I shutdown ifs-alpha-kube-001 the ingress stops working. What should I set host if I want a high availability cluster?
Thanks
What should I set host if I want a high availability cluster?
The idea behind the Ingress resource is using the brower's host: HTTP header (which is sent for every request HTTP/1.1 and newer) for virtual hosting, so you can create one load balancer, but point all of your DNS records at the one host -- versus having to create a new load balancer for every Service in your cluster
Thus, the host: header would be whatever DNS name you wished for the outside world to be able to reach your Service as; for example, if you have a website and a reporting web-app in your cluster, one host: might be www.example.com and the other host: might be reports.example.com but both would be CNAME records for my-k8s-lb.example.com
I have an ingress controller and two nginx in one Kubernetes namespace. One service has the name nginx-1 and the second name nginx-2.
I need to create a situation where nginx-1 will be default backend, and nginx-2 will be a target for a few IP addresses.
I have tried to do this using a ConfigMap but without results.
Maybe someone had a problem like this?
Never saw on Kubernetes docs something like this, but I would like to purpose another approach. You can configure your ingress to use named based virtual hosting, so that few IP addresses would connect using a different domain.
Here and example:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foo.bar.com
http:
paths:
- backend:
serviceName: service1
servicePort: 80
- host: bar.foo.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
Reference: https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting
I'm trying to automatically provision a loadbalancer on GCP by using the ingress object with our GKE cluster.
I have three GKE deployments and each is available with a service on port 8080 with a unique nodePort.
When using ingress-fanout.yaml, it creates 4 backend services instead of the 3 specified in the yaml. The 4th service defaults to all unmatched routes. I assume the 4th service is because we don't match unmapped routes in the yaml.
How can one map unmatched routes to one of the services? Is that possible?
Here's ingress-fanout.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: fanout-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: "our-static-ip"
ingress.gcp.kubernetes.io/pre-shared-cert: "our-ssl-cert"
kubernetes.io/ingress.allow-http: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
rules:
- host: our-website.com
http:
paths:
- path: /*
backend:
serviceName: li-frontend
servicePort: 8080
- path: /backend/*
backend:
serviceName: li-django
servicePort: 8080
- path: /notifications/*
backend:
serviceName: li-notifications
servicePort: 8080
Update: I removed many of the original questions and narrowed the scope of the question. When health checks started succeeding, that cleared the old issues.
First of all, "backends" have nothing to do with the "paths" you specified. "backends" on GCP Console are pointing to your GKE node pools.
Ingress supports adding a default backend. You could have tried just searching for "ingress default backend". You can find documentation about this here: https://kubernetes.io/docs/concepts/services-networking/ingress/#single-service-ingress
Basically doing this will set a default backend when nothing else is matched:
spec:
backend:
serviceName: testsvc
servicePort: 80
rules:
[...your stuff here...]
I'm attempting to create a cluster on Google Kubernetes Engine that runs nginx, RStudio server and two Shiny apps, following and adapting this guide.
I have 4 workloads that are all green in the UI, deployed via:
kubectl run nginx --image=nginx --port=80
kubectl run rstudio --image gcr.io/gcer-public/persistent-rstudio:latest --port 8787
kubectl run shiny1 --image gcr.io/gcer-public/shiny-googleauthrdemo:latest --port 3838
kubectl run shiny5 --image=flaviobarros/shiny-wordcloud --port=80
They were then all exposed as node ports via:
kubectl expose deployment nginx --target-port=80 --type=NodePort
kubectl expose deployment rstudio --target-port=8787 --type=NodePort
kubectl expose deployment shiny1 --target-port=3838 --type=NodePort
kubectl expose deployment shiny5 --target-port=80 --type=NodePort
..that are all green in the UI.
I then deployed this Ingress backend
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: r-ingress
spec:
rules:
- http:
paths:
- path: /
backend:
serviceName: nginx
servicePort: 80
- path: /rstudio/
backend:
serviceName: rstudio
servicePort: 8787
- path: /shiny1/
backend:
serviceName: shiny1
servicePort: 3838
- path: /shiny5/
backend:
serviceName: shiny5
servicePort: 80
The result is that the nginx routing works great, I can see "Welcome to nginx" webpage from home, but the three other paths I get:
/rstudio/ - Input/output error
/shiny1/ - Page not found (the Shiny 404 page)
/shiny5/ - Page not found (the Shiny 404 page)
The RStudio and Shiny workloads both work when exposing via the single load balancer, mapped to 8787 and 3838 respectively.
Can anyone point to where I'm going wrong?
Qs:
Do the Dockerfiles need to be adapted so they all give a 200 status on port 80 when requesting "/"? Do I need to change the health checker? I tried changing the RStudio login page (that 302 to /auth-sign-in if you are not logged in) but no luck
Both RStudio and Shiny need websockets - does this affect this?
Does session affinity need to be on? I tried adding that with IP but same errors.
As Radek suggested, ingress.kubernetes.io/rewrite-target: / is required to re-write your requests. However, this is not currently supported by the GKE ingress controller and is the reason that you're receiving 404 responses.
Instead, on GKE, you must use an nginx ingress controller.
You will then be able to configure ingress for your rstudio and shiny images that obeys the rewrite rule:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: r-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
paths:
- backend:
serviceName: rstudio
servicePort: 8787
path: /rstudio/*
- backend:
serviceName: shiny1
servicePort: 3838
path: /shiny1/*
- backend:
serviceName: shiny5
servicePort: 80
path: /shiny5/*
the most likely problem you have is that when you go with this ingress you attached your URI is different then with direct accesc ( /shiny1/ vs / ) so your app is lost and has no content for that uri.
With Nginx Ingress Controller you can use ingress.kubernetes.io/rewrite-target: / annotation to mitigate this and make sure that / is accessed even when there is a subfolder in the ingress path.