I'm setting up an Istio service mesh with two services inside both running a Graphql engine. I'm planning to set them on two different subpaths. How would you set up redirection on VirtualService?
I already tried using this VirtualService config
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: hasura-1
spec:
hosts:
- "*"
gateways:
- hasura-gateway
http:
- match:
- uri:
prefix: /hasura1
route:
- destination:
host: hasura-1
port:
number: 80
- match:
- uri:
prefix: /hasura2
route:
- destination:
host: hasura-2
port:
number: 80
but I keep on having error 404 whenever I try accessing these prefixes.
EDIT: I've updated my virtual service to incorporate rewrite.uri. Whenever I try accessing either prefixes I get redirected to / and it gives out an error 404. Here is my updated Gateway and VirtualService manifest.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: hasura-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: hasura-1
spec:
hosts:
- "*"
gateways:
- hasura-gateway
http:
- match:
- uri:
exact: /hasura1
rewrite:
uri: /
route:
- destination:
host: hasura-1
port:
number: 80
- match:
- uri:
exact: /hasura2
rewrite:
uri: /
route:
- destination:
host: hasura-2
port:
number: 80
---
On what path your Hasura's GraphQL endpoint is configured?
The way your VirtualService is configured, a request to your gateway will behave like this:
my.host.com/hasura1 --> hasura-1/hasura1
my.host.com/hasura1/anotherpath --> hasura-1/hasura1/anotherpath
my.host.com/hasura2 --> hasura-2/hasura2
Maybe you are missing a rewrite.uri rule to strip the path from the request.
e.g.: With this rule:
http:
- match:
- uri:
prefix: /hasura1
rewrite:
uri: /
route:
- destination:
host: hasura-1
port:
number: 80
your Hasura container should receive the requests on the root path:
my.host.com/hasura1 --> hasura-1/
my.host.com/hasura1/anotherpath --> hasura-1/anotherpath
Related
I am new to Istio and I am trying to communicate 2 spring boot applications with Istio: component with requirement.
I have installed Istio 1.13.2 on a GKE cluster with the demo profile:
istioctl install --set profile=demo -y
I have automatically injected the sidecar proxy to the default namespace with:
kubectl label namespace default istio-injection=enabled
I have defined istio ingress gateway as entry point and a virtual service that points to the component service.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-gateway-vs
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /component
route:
- destination:
host: component
port:
number: 8080
---
component app only has an enpoint: /component that returns a string, So far everything works fine.
The flow is as follows
my-gateway----->component
My question is how I can communicate component with requirement directly without going through istio-ingress-gateway.
my-gateway----->component ---->requirement
Is it possible?
Note: I have tried adding requirements in the virtual service but it seems to go through the istio-ingress-gateway and not directly from component to requirement.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-gateway-vs
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: /component
route:
- destination:
host: component
port:
number: 8080
- match:
- uri:
prefix: /requirement
route:
- destination:
host: requirement
port:
number: 8080
---
i am not sure why istio ingress controller coming inbetween for you.
You should checkout this nice simple example : https://istio.io/latest/docs/examples/bookinfo/#deploying-the-application
In istio example, you can see review service sending the request to rating service.
So for connection or service to service communication, you can use the just service name.
So if you check the review service source you will get an idea of how services calling other services.
Java example :
https://github.com/istio/istio/blob/master/samples/bookinfo/src/reviews/reviews-application/src/main/java/application/rest/LibertyRestEndpoint.java#L42
Python example :
https://github.com/istio/istio/blob/master/samples/bookinfo/src/productpage/productpage.py#L61
So for you end flow will be something like
istio-ingress-gateway----->service-1----->service-2
I'm trying to set at my GKE a deployment which works with HTTPS load balancer on istio.
I installed istio when the istio-ingresss is defined as NodePort and created an Ingress on gke with following:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: istio-ingress
namespace: istio-system
annotations:
# If the class annotation is not specified it defaults to "gce".
# kubernetes.io/ingress.class: "gce"
networking.gke.io/v1beta1.FrontendConfig: "ingress-frontend-config"
ingress.kubernetes.io/default-backend: istio-ingressgateway
nginx.ingress.kubernetes.io/default-backend: istio-ingressgateway
# Enable use of manually pre-defined global static IP
kubernetes.io/ingress.global-static-ip-name: test-ip-address # A gcp ip address constantly set
kubernetes.io/ingress.allow-http: "true"
# Enable use of a GCP-managed certificate through a ManagedCertificate resource
networking.gke.io/managed-certificates: global-test-dev-cert # A gcp manged certificate for the host
spec:
rules:
- http:
paths:
- path: /*
backend:
# In this case we don't go directly to app-specific services,
# but first to the Istio ingress-gateway
# We use port 80 because it is the "ingress-like" port of the ingress-gateway
serviceName: istio-ingressgateway
servicePort: 80
After deploying the basic httpbin of istio I try to acces it with the following gateway and virtual service
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: httpbin-gateway
namespace: svc
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "httpbin.test.com" # DNS set to the Ingress IP
# - "*"
- hosts:
- "httpbin.test.com" # DNS set to the Ingress IP
# - "*"
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: PASSTHROUGH
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-vs
namespace: svc
spec:
hosts:
- "httpbin.test.com" # DNS set to the Ingress IP
gateways:
- httpbin-gateway
http:
- route:
- destination:
host: httpbin
port:
number: 8000
And when I access it through the browser I get a 502 Error. In the istio-ingressgateway logs I get a 404 error route not found.
But when I switch the hosts to
hosts:
- "*"
The wildcards gives me access to the httpbin app.
I also tried changings the virtual service to
tls:
- match:
- port: 443
sniHosts:
- httpbin.test.com
route:
- destination:
host: httpbin
port:
number: 8000
The same problem occurs.
I am trying to learn .NET Microservice. I have been following a great tutorial on Youtube (Time: 4:44:55, Adding An API Gateway). Everything worked well until NGINX Ingress came into the picture. I pasted the same YAML file from the GitHub account of the trainer I doubled checked all the things but couldn't find anything:
I can see all the pods and services are working fine:
I updated my host file.
What did I miss?
URL, I am using: http://acme.com/api/platforms/
Error: HTTP Error 404. The requested resource is not found.
The output of the Ingress YAML:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx","nginx.ingress.kubernetes.io/use-regex":"true"},"name":"ingress-srv","namespace":"default"},"spec":{"rules":[{"host":"acme.com","http":{"paths":[{"backend":{"service":{"name":"platforms-clusterip-srv","port":{"number":80}}},"path":"/api/platforms","pathType":"Prefix"},{"backend":{"service":{"name":"commands-clusterip-srv","port":{"number":80}}},"path":"/api/c/platforms","pathType":"Prefix"}]}}]}}
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: "true"
creationTimestamp: "2021-09-18T00:12:41Z"
generation: 1
name: ingress-srv
namespace: default
resourceVersion: "2274742"
uid: a7376202-8b1b-4f1a-a42f-08de5f602192
spec:
rules:
- host: acme.com
http:
paths:
- backend:
service:
name: platforms-clusterip-srv
port:
number: 80
path: /api/platforms
pathType: Prefix
- backend:
service:
name: commands-clusterip-srv
port:
number: 80
path: /api/c/platforms
pathType: Prefix
status:
loadBalancer:
ingress:
- hostname: localhost
Services:
UPDATE: Tried below commands and got some new information:
UPDATE: Result of
Kubectl get pods --namespace=ingress-nginx
Try removing the regex annotation from th ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
name: ingress-srv
namespace: default
spec:
rules:
- host: acme.com
http:
paths:
- backend:
service:
name: platforms-clusterip-srv
port:
number: 80
path: /api/platforms
pathType: Prefix
- backend:
service:
name: commands-clusterip-srv
port:
number: 80
path: /api/c/platforms
pathType: Prefix
or just try this nginx.ingress.kubernetes.io/rewrite-target: /
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: acme.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: commands-clusterip-srv
port:
number: 80
in above ingress, all requests will go to service commands-clusterip-srv so from browser side you pass anything either /api or /api/c ingress will route the traffic to that service if your host is acme.com
Error 404 clearly means there is some issue with your Nginx configuration path is not matching or host issue, Nginx not able to find upstream or target so it throws 404.
Update
Try adding IP and entry into the host file for
192.168.1.28 acme.com
i am not sure you have used the IP POD to curl ideally you should me using the acme.com as you can to access the data.
also hope you service, deployment and ingress are in same namespace.
First of all, Thank you Harsh for your precious time. I tried all the things but no error was found.
It was really a miracle that I am able to resolve it issue on HTTPS. I am able to access "https://acme.com/api/platforms". But still, HTTP is giving me the same error. However, I am fine with HTTPS
I am not able to access the domain to running ingress service in the Kubernetes, below is the YAML configuration for the ingress service, I am not able to access ticketing.dev in the browser
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-service
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: "true"
spec:
rules:
- host: ticketing.dev
http:
paths:
- path: /api/users/?(.*)
pathType: Prefix
backend:
service:
name: auth-srv
port:
number: 3000
- path: /?(.*)
pathType: Prefix
backend:
service:
name: client-srv
port:
number: 3000
I have added the domain name to the windows host files
driver \etc\host
127.0.0.1 ticketing.dev
Jenkins installed through helm chart with a custom installation path.
helm install argo-jenkins -f jenkins-volume.yaml jenkinsci/jenkins -n jenkins --set controller.jenkinsUriPrefix='/jenkinsargo'
We have a front-end Istio-ingress gateway from all the browser requests.
GW.Yaml:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: jenkins-gw
namespace: jenkins
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
VS.Yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: jenkins-vs
namespace: jenkins
spec:
gateways:
- jenkins-gw.jenkins
hosts:
- '*'
http:
- match:
- uri:
prefix: /jenkinsargo
route:
- destination:
host: argojenkins.jenkins.svc.cluster.local
port:
number: 8080
Able to access jenkins home page, when trying to configure the jenkins security seeing above error.
PFA for the initial home page and error page.
Error page after redirecting
Jenkins home page
This error means that an HTTPS request reaches to a HTTP (plaintext) listener. Check the listeners, some of your services may have an incorrect name (i.e. http) which is not following the naming convention: https://istio.io/latest/docs/reference/config/analysis/ist0118/
I suggest to use $ istioctl pc listeners --address
#Arnau Senserrich,
If it's a http naming issue, in the place it shouldn't even open jenkins login page.
If you see the above image when accessed jenkins through LB, I'm able to enter credentails and able to login. But when I clicked manage jenkins-> Configure Security
I'm seeing above error.
Also tried GW with both http and https:
GW.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: jenkins-gw
namespace: jenkins
spec:
selector:
custom: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: PASSTHROUGH
hosts:
- "*"
VS1.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: jenkins-vs
namespace: jenkins
spec:
gateways:
- jenkins-gw.jenkins
hosts:
- '*'
http:
- match:
- uri:
prefix: /jenkinsargo
route:
- destination:
host: argojenkins.jenkins.svc.cluster.local
port:
number: 8080
VS2.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: jenkins-vs1
namespace: jenkins
spec:
gateways:
- jenkins-gw.jenkins
hosts:
- '*'
tls:
- match:
- port: 443
sniHosts:
- "oitat.xyz.com"
route:
- destination:
host: argojenkins.jenkins.svc.cluster.local
port:
number: 8080
No luck, same issue.