3

I have to get the existing microservices run. They are given as docker images. They talk to each other by configured hostnames and ports. I started to use Istio to view and configure the outgoing calls of each microservice. Now I am at the point that I need to rewrite / redirect the host and the port of a request that goes out of one container. How can I do that with Istio?

I will try to give a minimum example. There are two services, service-a and service-b.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-b
spec:
  selector:
    matchLabels:
      run: service-b
  replicas: 1
  template:
    metadata:
      labels:
        run: service-b
    spec:
      containers:
        - name: service-b
          image: nginx
          ports:
            - containerPort: 80
              name: web
---
apiVersion: v1
kind: Service
metadata:
  name: service-b
  labels:
    run: service-b
spec:
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 80
      name: service-b
  selector:
    run: service-b

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  selector:
    matchLabels:
      run: service-a
  replicas: 1
  template:
    metadata:
      labels:
        run: service-a
    spec:
      containers:
        - name: service-a
          image: nginx
          ports:
            - containerPort: 80
              name: web
---
apiVersion: v1
kind: Service
metadata:
  name: service-a
  labels:
    run: service-a
spec:
  ports:
    - port: 8081
      protocol: TCP
      targetPort: 80
      name: service-a
  selector:
    run: service-a

I can docker exec into service-a and successfully execute:

root@service-a-d44f55d8c-8cp8m:/# curl -v service-b:8080

< HTTP/1.1 200 OK
< server: envoy

Now, to simulate my problem, I want to reach service-b by using another hostname and port. I want to configure Istio the way that this call will also work:

root@service-a-d44f55d8c-8cp8m:/# curl -v service-x:7777

Best regards, Christian

Wytrzymały Wiktor
  • 11,492
  • 5
  • 29
  • 37
Chris D.
  • 53
  • 5
  • For your task you can look at [virtual services](https://istio.io/latest/docs/reference/config/networking/virtual-service/) and [destination rules](https://istio.io/latest/docs/reference/config/networking/destination-rule/). For better help please consider adding [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) in a form of yaml manifests of services, exact task you need to achieve – moonkotte Nov 10 '21 at 14:23
  • Which `istio` version is used? I'd like to replicate the setup and see what can be done – moonkotte Nov 15 '21 at 18:35

1 Answers1

1

There are two solutions which can be used depending on necessity of using istio features.

If no istio features are planned to use, it can be solved using native kubernetes. In turn, if some istio feature are intended to use, it can be solved using istio virtual service. Below are two options:

1. Native kubernetes

Service-x should be pointed to the backend of service-b deployment. Below is selector which points to deployment: service-b:

apiVersion: v1
kind: Service
metadata:
  name: service-x
  labels:
    run: service-x
spec:
  ports:
    - port: 7777
      protocol: TCP
      targetPort: 80
      name: service-x
  selector:
    run: service-b

This way request will go through istio anyway because sidecar containers are injected.

# curl -vI service-b:8080

*   Trying xx.xx.xx.xx:8080...
* Connected to service-b (xx.xx.xx.xx) port 8080 (#0)
> Host: service-b:8080
< HTTP/1.1 200 OK
< server: envoy

and

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy

2. Istio virtual service

In this example virtual service is used. Service service-x still needs to be created, but now we don't specify any selectors:

apiVersion: v1
kind: Service
metadata:
  name: service-x
  labels:
    run: service-x
spec:
  ports:
    - port: 7777
      protocol: TCP
      targetPort: 80
      name: service-x

Test it from another pod:

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 503 Service Unavailable
< server: envoy

503 error which is expected. Now creating virtual service which will route requests to service-b on port: 8080:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: service-x-to-b
spec:
  hosts:
  - service-x
  http:
  - route:
    - destination:
        host: service-b
        port:
          number: 8080

Testing from the pod:

# curl -vI service-x:7777

*   Trying yy.yy.yy.yy:7777...
* Connected to service-x (yy.yy.yy.yy) port 7777 (#0)
> Host: service-x:7777
< HTTP/1.1 200 OK
< server: envoy

See it works as expected.

Useful links:

moonkotte
  • 3,661
  • 2
  • 10
  • 25