I am deploying a virtual service on Kubernetes using which I want to expose a host. This host will target the elastic search DB and allow read only operations on it. Every other CRUD operation should be blocked.
After blocking I get 404 Not Found HTTP Response but I want to customize it to HTTP 405: Method Not Found.
Any suggestions on achieving this? Attached is the virtual service YAML file used in kubernetes
Tried
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: read-es-vs
spec:
hosts:
- "readonlyelastic.com"
gateways:
- istio-system/default-gateway
http:
- match:
- uri:
prefix: /
method:
exact: GET
route:
- destination:
port:
number: 8080
host: elasticsearch-master-data
fault:
abort:
httpStatus: 405
But it didnot give the expected result
Related
i am new to kubernetes,
i deployed a react front end and a spring boot backend to minikube, and am using the service for the backend to send the request from the front end (i don't want to expose the api outside the cluster)
i get this error inside my mozilla console :
Blocking of a multi-origin request (Cross-Origin Request): the "Same Origin" policy does not allow to consult the remote resource located on http://asserter-back:8081/auth/signup. Reason: failure of the CORS request. Status code: (null).
i am also using ingress that haso ne rule that routes any traffic only to the fron end here isthe ingress config file :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: asserter-ingress
labels:
name: asserter-ingress
spec:
rules:
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: asserter-proj
port:
number: 80
this is my for my end of study project!
please help!
thank you!
allowed all cors from the backend !
tested the backend using port forwarding
I am working on DevOps solution, and try to automate the blue-green deployment solution on kubernetes. However, we are facing the issue that the istio apply the route rules too slow, when removing the virtualservices and take a long time to effective. We tried to wait 60s to wait the rules updated and destroy the old pods. We don't have ideas that 60s is enough to finish the route change, and will have downtime if over 60s to take effective. Would like to get some advises on how to check the route (to green one only ) is updated properly? and how to make the istio apply to execute faster? Thanks.
Here is the yaml file to apply the virtualservice:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
namespace: xxx-d
name: xxx-virtualservice
labels:
microservice: xxx-new
spec:
hosts:
- xxx.com
gateways:
- mesh
- http-gateway.istio-system.svc.cluster.local
- https-gateway.istio-system.svc.cluster.local
http:
- headers:
request:
set:
x-forwarded-port: '443'
x-forwarded-proto: https
route:
- destination:
host: xxx-service.svc.cluster.local
port:
number: 8080
retries:
attempts: 3
retryOn: gateway-error,connect-failure,refused-stream
timeout: 3s
Ingress gateway is located behind AWS ELB(classic) using nodeport and I want to route TCP traffic in Virtual Service based on client ip.
Of course Proxy Protocol of ELB is enabled.
When I use HTTP, it works. The configuration is below.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: app-vservice
namespace: test
spec:
hosts:
- "app-service"
http:
- match:
- headers:
x-forwarded-for:
exact: 123.123.123.123
route:
- destination:
host: app-service
subset: v2
- route:
- destination:
host: app-service
subset: v1
But I can't find headers field of TCP route in official documents.
Is it impossible?
Thank you.
According to docs yes there is no field to pass headers in TCPRoute in Istio. Also to answer your question every header manipulation should be done using envoy filters because Istio, built on envoy supports that and also decreases the complexity.
Using envoy and lua filters as stated in Istio docs. It can be achieved. Please follow envoy docs.
Checkout the Istio Discussion for headers in Virtual Service.
For implementation of the same using Lua. And a blog showing an example how to implement filters on envoy.
i'm trying to reverse proxy using istio virtual service
it is possible forward request in virtual service? (like nginx's proxy_pass)
in result,
http://myservice.com/about/* -> forward request to CDN (external service outside k8s system - aws s3, etc....)
http://myservice.com/* -> my-service-web (internal service includes in istio mesh)
defined serviceentry, but it just "redirect", not forward reqeust.
here is my serviceentry.yaml and virtualservice.yaml
serviceentry.yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: my-service-proxy
namespace: my-service
spec:
hosts:
- CDN_URL
location: MESH_EXTERNAL
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: TLS
resolution: DNS
virtualservice.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-service
namespace: my-service
spec:
hosts:
- myservice.com
gateways:
- myservice
http:
- match:
- uri:
prefix: /about
rewrite:
authority: CDN_URL
uri: /
route:
- destination:
host: CDN_URL
- route:
- destination:
host: my-service-web.svc.cluster.local
port:
number: 80
virtualservice can acts like nginx-igress?
Based on that istio discuss
User #palic asked same question here
Shouldn’t it be possible to let ISTIO do the reverse proxy
thing, so that no one needs a webserver (httpd/nginx/
lighthttpd/…) to do the reverse proxy job?
And the answer provided by #Daniel_Watrous
The job of the Istio control plane is to configure a fleet of reverse proxies. The purpose of the webserver is to serve content, not reverse proxy. The reverse proxy technology at the heart of Istio is Envoy, and Envoy can be use as a replacement for HAProxy, nginx, Apache, F5, or any other component that is being used as a reverse proxy.
it is possible forward request in virtual service
Based on that I would say it's not possible to do in virtual service, it's just rewrite(redirect), which I assume is working for you.
when i need function of reverse proxy, then i have to using nginx ingresscontroller (or other things) instead of istio igress gateway?
If we talk about reverse proxy, then yes, you need to use other technology than istio itself.
As far as I'm concerned, you could use some nginx pod, which would be configured as reverse proxy to the external service, and it will be the host for your virtual service.
So it would look like in below example.
EXAMPLE
ingress gateway -> Virtual Service -> nginx pod ( reverse proxy configured on nginx)
Service entry -> accessibility of URLs outside of the cluster
Let me know if you have any more questions.
I am working on a GKE cluster. I have a simple server running. There are three routes on the server.
route 1 - /
route 2 - /ping
route 3 - /health
These paths return 200 response with generic but different "ok" messages.
This is what my ingress yaml looks like -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: basic-ingress
spec:
tls:
- hosts:
- www.simple.com
secretName: simple-server-tls
rules:
- host: www.simple.com
http:
paths:
- path: /ping
backend:
serviceName: simple-server
servicePort: 8080
I have my server exposed as a load balancer. I can access all three routes using loadbalancer as
https://<loadbalancer_ip>:8080/
https://<loadbalancer_ip>:8080/ping
https://<loadbalancer_ip>:8080/health
However, when trying to use an ingress, I only receive a 200 response on https://www.simple.com/ping
The other two routes i.e. https://www.simple.com/health and https://www.simple.com/ return default backend - 404 error.
I can confirm that the server is running and is serving requests perfectly and I have given ingress enough time(upwards of 30 minutes) to finish setting-up. https://www.simple.com/healthz returns "OK".
I think I am making a mistake in configuring the ingress correctly. Any help/suggestions are appreciated.
I cannot provide the ingress logs as I am noticing that kubectl describe ingress/basic-ingress returns the error Error from server (NotFound): the server could not find the requested resource However, kubectl get ingress returns basic-ingress www.simple.com <ingress_ip> 80, 443 31m
Figured out the issue. You need to add a wild card to the path. I only had / in my path and hence it was rejecting (read throwing 404 error) for all my other urls. I added /* and removed the rewrite-target annotation as #bserdar correctly suggested and it worked. Link to the issue on github that helped a lot - https://github.com/kubernetes/ingress-nginx/issues/1120