How to deploy multiple frontend application on same kubernetes cluster with only one hostname - kubernetes

I've 3 angular applications that are deployed on Kubernetes. I'm trying to run all 3 with just one hostname and different paths. Here is my ingress.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/rewrite-target: /$1
name: test-ingress-deployment
namespace: my-namespace
spec:
tls:
- hosts:
- dns-name.eastus.cloudapp.azure.com
secretName: aks-ingress-tls
rules:
- host: dns-name.eastus.cloudapp.azure.com
http:
paths:
- backend:
serviceName: ui-svc
servicePort: 80
path: /(.*)
- backend:
serviceName: ui-svc-one
servicePort: 80
path: /one/?(.*)
- backend:
serviceName: ui-svc-two
servicePort: 80
path: /two/?(.*)
All these 3 services are in different namespaces. I'm getting 503 for every endpoint I'm trying to hit, after applying ingress.

Documentation around this is scarce, at least I wasn't able to find something except for Github issues shedding a little light into this issue. But as far as I know cross namespace access was intentionally avoided in K8s, it would be a prime source of privilege escalation attacks.
To my knowledge you do have two options:
You can run your ingress and ingress controller inside the kube-system namespace. But this is not recommended as kube-system is meant for K8s components only and it most likely creates security concerns.
You can have the ingress in the namespace your service resides in. But then you need an ingress controller which allows merging of rules which not all support afaik.
There are probably more solutions out there, maybe someone with more in-depth K8s knowledge can shed more light on it.

Related

how to setup yaml ingress in google cloud with redirect

I’m setting up an environment in Google Cloud with an ingress and load balancers.
I know how to setup hosts and paths to it but I can't figure out how to setup when a user goes to a specific site http://example.com/ I want him to redirect to http://example.com/en.
Note:
http => https
/ => /en
UPDATED
I added app-root: /en (but it doesn't do anything).
This is my current yaml:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: gce
kubernetes.io/ingress.global-static-ip-name: our-frontend-static-ip
networking.gke.io/managed-certificates: example-certificate
appgw.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/app-root: /en
name: example-ingress
namespace: default
spec:
rules:
- host: anotherexample.com
http:
paths:
- backend:
serviceName: anotherexample-service
servicePort: 80
- host: example.com
http:
paths:
- path: /nl
backend:
serviceName: example-nl-service
servicePort: 80
- path: /en
backend:
serviceName: example-en-service
servicePort: 80
So, there are 2 hosts in my yaml and I want: when the url is correct for 1 of the hosts: example.com it must go to example.com/en (this is for Multilanguage purposes)
We can change the settings in the loadbalancer ban after the sync from the ingress in changes it back.
Kubernetes supports multiple Ingress Controllers which are different from each other. For example, you are trying to use the Ingress GCE and there is also a popular Nginx Ingress.
The main problem in your use case is that the Ingress GCE is not supporting rewrites. An on-going feature request regarding that can be found here.
To be able to use the rewrites you will need to deploy the Nginx Ingress Controller and switch annotation in your yaml from:
kubernetes.io/ingress.class: "gce"
to:
kubernetes.io/ingress.class: "nginx"
The sources that will help you out with this are as follows:
Installation Guide
Rewrite
An example

Kubernetes POD versions

Does Kubernetes allow multiple versions of same micro service (not Kubernetes service) to be deployed in a Kubernetes cluster at any given point in time?
So, let's say I have a micro-service "MyCalculator". I create a POD to host this service.
this is v1 of the "MyCalculator".
I need that as new versions of the services are created, Kubernetes cluster allows these services to be deployed in the cluster, like so.
"MyCalculatorKubeService"/v1
"MyCalculatorKubeService"/v2
...
"MyCalculatorKubeService"/vn
The idea here is dynamically allow new versions, and allow access to these versions through a convention specified above. In the example above, I am thinking that the "MyCalculatorKubeService" is a kubernetes service.
The unused versions get decommissioned over a period of time through a manual trigger after reviewing which services are not getting any traffic for say x days.
Thanks,
For this scenario you will have to maintain a separate pod for each versions you want to keep alive. Use ingress to create separate virtual paths to each version of your application
- host: example.com
http:
paths:
- backend:
serviceName: app-v1
servicePort: 80
path: /app/v1/
- backend:
serviceName: app-v2
servicePort: 80
path: /app/v2/
Posting this as Community Wiki as its extension of #Charlie's answer.
As it was mentioned in #Charlie's answer you can do it using Ingress.
There are some Ingress Controllers, however Kubernetes officially supports only two.
Kubernetes as a project currently supports and maintains GCE and nginx controllers.
If you would like to use Nginx Ingress on GKE you need to add annotation to your Ingress manifest.
annotations:
kubernetes.io/ingress.class: nginx
You could also use Nginx Ingress Rewrite annotation.
When you are using Ingress, your services can be NodePort or ClusterIP types.
Depends on your needs you can specify which path should redirect to which service but you can also use default backend if you provide some random path like on example below:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: hello-world
servicePort: 60000
rules:
- http:
paths:
- path: /v1
backend:
serviceName: MyCalculatorKubeService/v1
servicePort: 60000
- path: /v2
backend:
serviceName: MyCalculatorKubeService/v2
servicePort: 80
If you would provide path like MyCalculatorKubeService/vasdsadsa it would redirect to default backend which is hello-world service in this case. It might be used in some workarounds.

Prometheus dashboard exposed over ingress controller

I am trying to setup Prometheus in k8 cluster, able to run using helm. Accessing dashboard when i expose prometheus-server as LoadBalancer service using external ip.
Same does not work when I try to configure this service as ClusterIP and making it as backend using ingress controller. Receiving 404 error, any thoughts on how to troubleshoot this?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ops-ingress
annotations:
#nginx.org/server-snippet: "proxy_ssl_verify off;"
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- http:
paths:
- path: /prometheus(/|$)(.*)
backend:
serviceName: prometheus-server
servicePort: 80
with above ingress definition in place, url “http://<>/prometheus/ getting redirected to http://<>/graph/ and then 404 error page getting rendered. When url adjusted to http://<>/prometheus/graph some of webcontrols gets rendered with lots of errors on browser console.
Prometheus might be expecting to have control over the root path (/).
Please change the Ingress to prometheus.example.com and it should work fine. (Changing it to a subdomain)
Please change your Ingress configuration file, add host field:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ops-ingress
annotations:
#nginx.org/server-snippet: "proxy_ssl_verify off;"
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
rules:
- host: prometheus.example.com
http:
paths:
- path: /prometheus(/|$)(.*)
backend:
serviceName: prometheus-server
servicePort: 80
then apply changes executing command:
$ kubectl aply -f your_ingress_congifguration_file.yaml
The host header field in a request provides the host and port
information from the target URI, enabling the origin server to
distinguish among resources while servicing requests for multiple
host names on a single IP address.
Please take a look here: hosts-header.
Ingress definition: ingress.
Useful information: helm-prometheus.
Useful documentation: ingress-path-matching.

One Kubernetes Ingress to front multiple clusters? Scope issues

So I have two clusters at the moment (soon to be a few more, once I get this working), ClusterA and ClusterB.
Is it possible for one ingress to interface with services from both clusters?
ClusterA hosts the front end and the ingress, while ClusterB hosts the back end.
The excerpted ingress is below. Everything bar the back end works.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:{...}
selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/test-frontend-ingress
uid: //
spec:
backend:
serviceName: idu-frontend-XYZ
servicePort: 80
rules:
- http:
paths:
- backend:
serviceName: test-backend-app-service
servicePort: 8080
path: /api/v2/
- backend:
serviceName: idu-frontend-XYZ
servicePort: 80
path: /
tls:
- secretName: tls-cert-name
status:
loadBalancer:
ingress:
- ip: 123.456.789.012
Back end service URL:
https://console.cloud.google.com/kubernetes/service/asia-southeast1-b/test-backend/default/test-backend-app-service...
URL the ingress tries to point to:
https://console.cloud.google.com/kubernetes/service/asia-southeast1-b/standard-cluster-1/default/test-backend-app-service...
So what I've gathered is the ingress can only interface with things in the same cluster as them? test-backend and standard-cluster-1 are the cluster names, and they are both on the default namespace. Isn't that kind of pointless, as you can only deploy one thing to each cluster? Unless your images contain multiple apps, in which case it isn't really microservices anymore.
Connecting two clusters with Kubernetes is hard I guess.
Instead you can deploy both the services on the same cluster. You can create two deployments and expose them as services. And then ingress can redirect traffic between them.
Why do you need a cluster per service though ?
If there is no other alternative you will have to do something like this:
https://appscode.com/products/voyager/7.1.1/guides/ingress/http/external-svc/

kubernetes gke multiple ingresses single global ip

I have multiple MSA on k8s on GKE. Each is on separate subdomain like:
msa1.example.com
msa2.example.com
I have it in single ingress:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: main-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: lalala-ip-1
kubernetes.io/ingress.allow-http: "false"
spec:
tls:
- hosts:
- msa1.example.com
secretName: msa1-tls
backend:
serviceName: sink
servicePort: 80
rules:
- host: msa1.example.com
http:
paths:
- path: /.well-known/*
backend:
serviceName: letsencrypt
servicePort: 80
- path: /*
backend:
serviceName: lalala
servicePort: 80
- host: msa2.example.com
http:
paths:
- path: /*
backend:
serviceName: lalala2
servicePort: 80
... and all is nice.
The thing is, that I want to have each MSA in separate file.
Problem is this kubernetes.io/ingress.global-static-ip-name: lalala-ip-1 line. If I have it in two ingresses only first started is bounded to IP, but other ones no.
Is there a way, to share IP on GKE ingress controller between two ingresses?
A way around it could be to run your own nginx-ingress controller in your cluster and expose it via LoadBalancer service type. Then you would have 1 IP for your ingress and be able to serve all ingresses via nginx controller by adding annotation kubernetes.io/ingress.class: "nginx"
Reference: https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/
Confirmed my comment:
Only one resource at a time can use a static external IP address.
https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address
GKE has recently added support for the new Kubernetes Gateway API. Both the GKE Gateway implementation as well as the Kubernetes Gateway API specification are still in alpha at this point.
The Kubernetes Gateway-API, is intended to support use cases, where you have a central Gateway (with a single IP), but want different Routes (with different hostnames or paths), managed in separate objects or even namespaces.
References:
https://gateway-api.sigs.k8s.io/
https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api