How do I create an internal gateway using Istio?

Question

Currently, we successfully setup Istio to create a couple ingress-gateways like api.example.com and app.example.com, that route traffic to a variety of services with destination rules, etc. In addition to this, we would love to use Istio's features for internal-only APIs, but we are unsure of how to set something like this up. Is it possible to use Istio's Gateway and VirtualServices CRDs to route traffic without exiting the cluster? If so, how would we go about setting that up?

Answer 1

Istio gateways are for traffic coming into the cluster or traffic leaving out the cluster. For traffic inside the cluster you should not use ingress/egress gateways. If you have configured Istio in the cluster to create a service mesh then you get all these benefits because Istio will inject a sidecar envoy for all your services inside the cluster. It's this sidecars which provides all the benefits of the mesh.When you use ingress or egress gateway you are actually using the sidecar deployed as ingress or egress gatway.You can use virtual service, destination rule, service entries, sidecars etc without a gateway because at that point you will using the sidecars deployed alongside your application pods.

Here is an example of virtual service:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

The virtual service hostname can be an IP address, a DNS name, or, depending on the platform, a short name (such as a Kubernetes service short name) that resolves, implicitly or explicitly, to a fully qualified domain name (FQDN). You can also use wildcard (”*”) prefixes, letting you create a single set of routing rules for all matching services. Virtual service hosts don’t actually have to be part of the Istio service registry, they are simply virtual destinations. This lets you model traffic for virtual hosts that don’t have routable entries inside the mesh.

Answer 2

I would add some things to Arghya Sadhu answer.

I think my example in another post is the answer to your question, specifically virtual service gateways and hosts. This example need additional Destination Rule since we have subsets which mark the route to proper subset of nginx here and they're defined in destination rule.

So, as an example, I would call something like internal-gateway/a or internal-gateway/b, and they would get routed to services A or B

I made something like that

2 nginx pods -> 2 services -> virtual service

Deployment1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx1
spec:
  selector:
    matchLabels:
      run: nginx1
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx1
        app: frontend
    spec:
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx1 > /usr/share/nginx/html/index.html"]

Deployment2

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx2
spec:
  selector:
    matchLabels:
      run: nginx2
  replicas: 1
  template:
    metadata:
      labels:
        run: nginx2
        app: frontend2
    spec:
      containers:
      - name: nginx2
        image: nginx
        ports:
        - containerPort: 80
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "echo Hello nginx2 > /usr/share/nginx/html/index.html"]

Service1

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: frontend
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend

Service2

apiVersion: v1
kind: Service
metadata:
  name: nginx2
  labels:
    app: frontend2
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: frontend2

Virtual Service

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginxvirt
spec:
  hosts:
  - nginx.default.svc.cluster.local
  - nginx2.default.svc.cluster.local
  http:
  - name: a
    match:
    - uri:
        prefix: /a
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx.default.svc.cluster.local
        port:
          number: 80
  - name: b
    match:
    - uri:
        prefix: /b
    rewrite:
      uri: /
    route:
    - destination:
        host: nginx2.default.svc.cluster.local
        port:
          number: 80

Above virtual service works only internal in mesh gateway.

You have 2 matches for 2 nginx services.

root@ubu1:/# curl nginx/a
Hello nginx1

root@ubu1:/# curl nginx/b
Hello nginx2

I would recommend to check istio documentation and read about :

• Gateways

• Virtual Services

• Destination Rules

And istio examples:

• bookinfo

• httpbin

So I can make up a DNS name or IP address that doesn't really exist

I think You misunderstood, it must exist, but not in the mesh. For example some database which is not in the mesh but You still can use, for example service entry to connect it to the mesh.

There is example with wikipedia in istio documentation and whole external services documentation.

I hope it will help You. Let me know if You have any more questions.