Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-6615

Headless service in istio namespace breaks IOR

XMLWordPrintable

    • False
    • None
    • False
    • Hide

      1. deploy SMCP with IOR enabled
      2. deploy a headless service without selectors in the istio-system namespace:

      apiVersion: v1
      kind: Service
      metadata: 
        name: test-headless
      spec: 
        clusterIP: None # headless
        type: ClusterIP
        # no selectors in spec
      

      3. deploy bookinfo
      4. run the following script:

      while ! (kubectl get route -l maistra.io/gateway-name=bookinfo-gateway -o jsonpath='{.items[].spec.to.name}' | grep headless ) ; do
      	kubectl delete pod -l app=istiod
      	sleep 5
      	kubectl rollout status deployment -l app=istiod
      	sleep 5
      done
      

      5. wait until the script stops, then examine the bookinfo route

      Show
      1. deploy SMCP with IOR enabled 2. deploy a headless service without selectors in the istio-system namespace: apiVersion: v 1 kind: Service metadata: name: test-headless spec: clusterIP: None # headless type: ClusterIP # no selectors in spec 3. deploy bookinfo 4. run the following script: while ! (kubectl get route -l maistra.io/gateway-name=bookinfo-gateway -o jsonpath= '{.items[].spec.to.name}' | grep headless ) ; do kubectl delete pod -l app=istiod sleep 5 kubectl rollout status deployment -l app=istiod sleep 5 done 5. wait until the script stops, then examine the bookinfo route

      When a headless service without selectors is present in the namespace where a SMCP is installed, IOR will sometimes update the route to point to that service, instead of the istio-ingressgateway service.

      This is because we find the svc by looking up all ingress gateway pods and then check whether a service's selector matches the pod's labels. The problem is that empty selectors will match any labels, meaning that the headless service will be selected if it is encountered before the actual ingressgateway service.

              mluksa@redhat.com Marko Luksa
              asmigala@redhat.com Andrej Smigala
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: