Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question about virtual services #7

Open
Karnich opened this issue Mar 20, 2019 · 4 comments
Open

question about virtual services #7

Karnich opened this issue Mar 20, 2019 · 4 comments

Comments

@Karnich
Copy link
Contributor

Karnich commented Mar 20, 2019

Hi Stefan

I hope you could answer my question. It is not directly an issue with your repository, but im following a lot of your guides and need some help >.<

If i have a service in the default namespace that wants to reach a service in another namespace.. i use <name>.<namespace>.svc.cluster.local
but if i wanna split that traffic between two services using weight: i have the following VS in the default namespace:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  hosts:
  - backend
  http:
  - route:
    - destination:
        host: backend.mynamespace.svc.cluster.local
      weight: 50
  - route:
    - destination:
        host: backend-management.mynamespace.svc.cluster.local
      weight: 50

If my service in default tries to use http://backend:portto access it, it fails
I need the full http://backend.namespace.svc.cluster.local:portfor it to work, but then my traffic is not split?

What am i doing wrong?

@stefanprodan
Copy link
Owner

stefanprodan commented Mar 20, 2019

Create a virtual service in the namespace where the backend is to overwrite the ClusterIP service:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: test
spec:
  hosts:
  - backend
  http:
  - route:
    - destination:
        host: backend.test
        port:
          number: 8080
      weight: 50
  - route:
    - destination:
        host: backend-v2.test
        port:
          number: 8080
      weight: 50

Make sure you have two ClusterIP services in the test namespace as in backend and backend-v2.

Now from the default namespace, an app will call backend.test:port and the traffic will be balanced between the 2 backends. Also make sure the default namespace has the sidecar injector enabled.

@Karnich
Copy link
Contributor Author

Karnich commented Mar 21, 2019

is It valid to make the hosts whatever you want as long as the destination is a valid service?

Also i dont know if you know. But 1.1 talks about namespace isolation. But i can find absolutely nothing about how to turn that on or off -.-

@stefanprodan
Copy link
Owner

Namespace isolation can be achieved by limiting the Envoy egress using the new Sidecar CRD. Yes the host can be whatever you want.

@Karnich
Copy link
Contributor Author

Karnich commented Mar 21, 2019

Thanks!
Alright so in 1.1 there is no namespace isolation unless there is a sidecar CRD in the namespace? Cause i thought i had this whole traffic management working yesterday .

Kiali kept telling me that my virtuel service was not valid with two routes. I assume Thats because there where no conditons for either of them. Like URL prefix matching and stuff like that

So instead of having 2 routes in the virtuel service. I had 1 route with 2 destinations. I then made a destinationrule with two subsets and moved from 2 different services to one service. I got traffic splitting working that way but honestly when i think about it. Seems more like the service was just doing roundrobin between the two deployments with the same selector.

Then today nothing worked. I could not access the services in the other namespace. I thought it might have been because i updated to 1.1 and somehow got namespace isolation on..

Man istio is hard -.- Thanks for all the great guides and for helping me out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants