K
Q

Internal service requests in Istio

8/12/2019

I have managed to get going with Istio. I've been testing a lot of the fundamentals and have a basic cluster working nicely with HTTP and gRPC. I have a Service that however needs to make an internal request to another service that isn't externally exposed.

So take this example:

  1. Request comes in from an Istio gateway as HTTP
  2. My custom grpc-gateway handler proxies the request to a gRPC service
  3. The gateway responds to the user via HTTP

I have a Gateway and a VirtualService declared:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-ingress
spec:
  hosts:
  - "*"
  gateways:
  - my-gateway
  http:
  - match:
    - port: 80
    route:
    - destination:
        host: my-grpc-gateway.default.svc.cluster.local
    corsPolicy:
      allowOrigin:
      - "*"
      allowMethods:
      - POST
      - GET
      - DELETE
      - PUT
      - OPTIONS
      allowCredentials: false
      allowHeaders:
      - Authorization
      maxAge: "24h"
  - match:
    - port: 30051
    route:
    - destination:
        host: api.default.svc.cluster.local
        port:
          number: 8443

And here's my gateway:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      name: http
      number: 80
      protocol: HTTP
    tls:
      mode: PASSTHROUGH
    hosts:
    - "*"
  - port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
    hosts:
    - "*"
  - port:
      name: grpc
      number: 30051
      protocol: GRPC
    tls:
      mode: PASSTHROUGH
    hosts:
    - "*"

My proxy service is being provided with the coordinates of the gRPC server:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rest-proxy
  labels:
    app: prox
spec:
  replicas: 1
  selector:
    matchLabels:
      app: rest-proxy
  template:
    metadata:
      labels:
        app: rest-proxy
    spec:
      containers:
        - image: redacted/rest-proxy:latest
          name: rest-proxy
          ports:
            - containerPort: 80
          command: ["./rest-proxy"]
          args: ["-host", "0.0.0.0", "-port", "80", "-apipath", "$(API_SERVICE_HOST):$(API_SERVICE_PORT)"]
      imagePullSecrets:
      - name: regcred
---
apiVersion: v1
kind: Service
metadata:
  name: rest-proxy
  labels:
    app: rest-proxy
spec:
  ports:
  - name: http
    port: 80
  - name: grpc-port
    port: 8444
  selector:
   app: rest-proxy

Is this where a ServiceEntry resource comes into play? For now I just want to make sure my internal services can talk to each other, eventually I'll create a load balancer to handle proxying from the gateway to the API (as I scale out).

Any suggestions/guidance would be helpful!

-- ddibiase
istio
kubernetes

Similar Questions

Failed to pull image - unauthorized: authentication required (ImagePullBackOff )
How to get list of pods that are not linked to any service
How is Kubernetes port forwarding working on Amazon EKS
How are Kuberenetes secrets stored on Amazon EKS

2 Answers

8/13/2019

After much more digging I realized that my proxy service was binding to the port: API_SERVICE_PORT which was set to 8080. The gRPC service existed at 8443, so the connection was never made.

All internal services within the mesh should naturally talk to each other. It's only the ingress that needs explicit rules to come into the mesh.

-- ddibiase
Source: StackOverflow
8/13/2019

Virtual service is a layer above the standard k8s service which enables us to apply more rules and policies.

Service entry is mainly used to add services which are outside mesh to istio's internal service registry like database, message queues, etc (though we can add mesh internal service also if required)

If both services are in the same mesh the should talk with each other over virtual service

If one service is outside and one is inside you have to have a service entry for the service which is outside.

-- yogesh kunjir
Source: StackOverflow