I have two applications deployed in different namespace in Google Kontainer engine(GKE). I want to use a single ingress resource (Google Load Balancer) to point to both the application using path based routing. Is it possible to have backend kubernetes services in multiple namespace behind a single ingress resource. If possible, how?
You'll have to setup an nginx ingress controller and deploy ingress resources per each namespace: https://github.com/kubernetes/kubernetes/issues/17088#issuecomment-221393102
Related
I came to know that Nginx Ingress talks directly to pods NOT through a service.
Why endpoints and not services
The NGINX ingress controller does not use Services to route traffic to the pods. Instead it uses the Endpoints API in order to bypass kube-proxy to allow NGINX features like session affinity and custom load balancing algorithms.
Is this specific to this type of ingress or the idea is applicable to all ingresses?
I have questions about my basic understanding about the setup of my k8s cluster.
I have a K8s running on Hetzner-cloud and allocated a "physical" Loadbalancer (which can be controlled via annotations on a Service.)
I use a nginx (or traefik) as my ingress-controller.
Please correct me if I am wrong:
I create the service Loadbalancer with the annotations in the same namespace of my ingress-controller right?
Then I create an ingress with label kubernetes.io/ingress-controller=nginx in my default namespace with the settings to point to my services in the default namespace (one for frontend, one for backend)
Is this the correct way to set this up?
1.- No. Ingress Controller and your workload doesn't have to be in the same namespace. In fact, you will have the Ingress Controller running in a separate namespace than your workload.
2.-Yes. Generally speaking your Ingress rules, meaning your Ingress object, meaning your Ingress yaml and your Service must be in the same namespace. So Ingress can't transpass a namespace.
Note: There is a way to have an Ingress object to send trafffic to a Service in a different namespace.
I create the service Loadbalancer with the annotations in the same
namespace of my ingress-controller right?
No ideally your ingress controller will be running in different namespace in which your workload must not be running.
You should be keeping only the Nginx service with type : Loadbalancer other services of your workload should be ClusterIP.
So all your traffic comes inside the cluster from one point. Your flow will be something like
DNS > LB > Ingress > Service > Pods > Container
Then I create an ingress with label
kubernetes.io/ingress-controller=nginx in my default namespace with
the settings to point to my services in the default namespace (one for
frontend, one for backend)
You mentioned label ideally, it should be an annotation kubernetes.io/ingress-controller=nginx.
Yes, it's perfect. You can create different ingress with different annotation rules as per requirements for different services that you want to expose publicly.
Keep your workload in default namespace for the controller you can use different namespaces like ingress-controller in future also if you have any requirement of setting up the Monitoring tools also you can create namespace and use it for monitoring only.
I am planning to deploy to an AKS cluster and use an NGINX ingress controller, so that my micro-services will be internal to the cluster and the NGINX ingress controller will be the entry point to the micro-services.
One of my micro-services acts as an API gateway using the Ocelot library, and it implements the BFF pattern. So my ingress controller will have only one rule which will route requests made to the path "/(.*)" to the API gateway micro-service.
My question is - is this the conventional way to use an ingress controller and an API gateway micro-service? Somehow it feels redundant, although I could think that both have different responsibilities.
I don't think you would need an Ingress-Controller in this case, we use an API Gateway which is Ambassador and we simply have a public IP assigned to its kubernetes service.
If you don't expect other pods to expose themselves using Ingress objects, and that all traffic will be coming in your API gateway, I would simply drop the Ingress-controller and enable a Service of Type LoadBalancer for your API gateway pods
I have the following applications (deployed with k8s) as helm subcharts:
Prometheus
Grafana
airflow-webserver
custom-application
custom-api
custom-webapp
This is nested under an umbrella chart.
The custom-webapp is the main application and should be routed to at mywebsite.com
I'm wondering how do I set up my ingress so that:
mywebsite.com routes to custom-webapp:5000
mywebsite.com/services/app routes to custom-application:5000
mywebsite.com/api/ routes to custom-api:5000
mywebsite.com/services/airflow routes to airflow:8080
mywebsite.com/services/prometheus routes to prometheus:9090
mywebsite.com/services/grafana routes to grafana:3000
Do I have 1 main ingress at the umbrella chart which routes to services exposed through subcharts? (the one i'm leaning most towards)
OR
Do I have multiple ingresses for each application ? In this case how do I tie them together?
This is hosted on GKE, and I'd kinda prefer to not pay for 1 ingress per application.
You need to configure a collection of rules that will define which connections reach which services.
You can aggregate several Ingress rules into a single Ingress definition.
If you are using Kubernetes 1.6+ you can check out this documentation regarding an nginx-ingress deployment on a Kubernetes cluster using the Helm package manager.
How to balance requests between each pod using proxy-next-upstream setting on Nginx ingress.
Nginx ingress should try all pods available before returning an error to client.
If I understand correctly ingress is going to load balance between services not pods. So if there is one service proxy-next-upstream is useless? Should I create separate service for each pod or there are better solutions?
The ingress in your case will have a service type object as backend.
The service itself then has multiple pods as backends to it.
This way in a micro service architecture one ingress can have multiple services as backends for example for multiple different URL contexts that are served by different applications.
You can read all about the different kind of services that exist here