Kubernetes Istio exposure not working with Virtualservice and Gateway

2/3/2021

So we have the following use case running on Istio 1.8.2/Kubernetes 1.18:

Our cluster is exposed via a External Loadbalancer on Azure. When we expose the app the following way, it works:

        ---
    apiVersion: apps/v1
    kind: ReplicaSet
    metadata:
      annotations:
        ...
      name: frontend
      namespace: frontend
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: applicationname
      template:
        metadata:
          labels:
            app: appname
            name: frontend
            customer: customername
        spec:
          imagePullSecrets:
            - name: yadayada
          containers:
          - name: frontend
            image: yadayada
            imagePullPolicy: Always
            ports:
            - name: https
              protocol: TCP
              containerPort: 80
            resources: {}
          dnsPolicy: ClusterFirst
          restartPolicy: Always
          schedulerName: default-scheduler

---
apiVersion: v1
kind: Service
metadata:
  name: frontend-svc
  namespace: frontend
  labels:
    name: frontend-svc
    customer: customername
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    name: frontend
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: frontend
  namespace: frontend
  annotations:
    kubernetes.io/ingress.class: istio
    kubernetes.io/tls-acme: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  rules:
  - host: "customer.domain.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          serviceName: frontend-svc
          servicePort: 80
  tls:
  - hosts:
    - "customer.domain.com"
    secretName: certificate

When we start using a Virtualservice and Gateway, we fail to make it work for some reason. We wanna use VSVC and Gateways cause they offer more flexibility and options (like url rewriting). Other apps dont have this issue running on istio (much simpler as well), we dont have networkpolicy in place (yet). We simply cannot reach the webpage. Anyone has an idea? Virtualservice and Gateway down below. with the other 2 replicasets not mentioned cause they are not the problem:

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  creationTimestamp: null
  name: virtualservice-name
  namespace: frontend
spec:
  gateways:
  - frontend
  hosts:
  - customer.domain.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: frontend
        port:
          number: 80
      weight: 100
  - match:
    - uri:
        prefix: /api/
    route:
    - destination:
        host: backend
        port:
          number: 8080
      weight: 100
  - match:
    - uri:
        prefix: /auth/
    route:
    - destination:
        host: keycloak
        port:
          number: 8080
      weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: frontend
  namespace: frontend
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http2
      protocol: HTTP
    tls:
      httpsRedirect: True
    hosts:
    - "customer.domain.com"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
      credentialName: customer-cert
    hosts:
    - "customer.domain.com"
-- remys89
gateway
istio
kubernetes

2 Answers

2/4/2021

@user140547 Correct, we changed that now. But we still couldn't access the application.

We found out that one of the important services was not receiving gateway traffic, since that one wasn't setup correctly. It is our first time having an istio deployment with multiple services. So we thought each of them needed their own Gateway. Little did we know that 1 gateway was more then enough...

-- remys89
Source: StackOverflow

2/4/2021

Your Gateway specifies PASSTHROUGH, however your VirtualService provides an HttpRoute. This means the TLS connection is not terminated by the Gateway, but the VirtualService expects terminated TLS. See also this somewhat similar question.

https://stackoverflow.com/questions/65836627/how-do-i-properly-https-secure-an-application-when-using-istio/65858513

-- user140547
Source: StackOverflow