IngressGateway service keep changing nodeport whenever a change to the service is applied through istio-operator breaking my upstream CloudLB

1

This was already brought up , in a slightly different scenario and with no comments, in Reconfigured nodePort attributes in ingressgateway service provisioned through istio-operator

Whenever a change to the Service definition of the ingress gateway is done , through the istio operator, this result in a change of nodeport for the service breaking the upstream cloud load balancer and in the case of AWS in a non recoverable way since the TargetGroup port is not an updateable parameter.

In aws you will get an error like :{}]: error creating load balancer target group: "DuplicateTargetGroupName: A target group with the same name 'k8s-istiosys-ingressg-eb3dc24472' exists, but with different settings\n\tstatus code: 400, request id: 4a3320c0-6e45-4d23-b7c5-73bcaca57a3f"

This happens on all versions at least 1.5.10+

Example , create a 1.9.1 istio-operator managed cluster with a mesh config like

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: standard
  namespace: istio-system
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        service:
          ports:
          - name: http
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443
      name: public-ingress
      namespace: istio-system
  profile: default
  • Apply and wait for the service to show up
public-ingress     LoadBalancer   10.96.195.87    <pending>     80:31497/TCP,443:32045/TCP              3m30s
  • change port name from http to http2 and apply istiooperator - watch the nodeports change
public-ingress     LoadBalancer   10.96.195.87    <pending>     80:31748/TCP,443:30293/TCP              4m42s
  • add a new port - apply the istiooperator - watch the nodeports change
public-ingress     LoadBalancer   10.96.195.87    <pending>     80:30834/TCP,443:30052/TCP,15443:30516/TCP   5m5s

For comparison this is the same done to an unmanaged loadbalancer service , the nodeport is immutable and never change

  • create service
zipkin-np    LoadBalancer   10.96.139.8   <pending>     9411:32027/TCP   0s
  • change port name from http to http2
zipkin-np    LoadBalancer   10.96.139.8   <pending>     9411:32027/TCP   13s
  • Change target port
zipkin-np    LoadBalancer   10.96.139.8   <pending>     9411:32027/TCP   21s