I’ve noticed a weird behaviour of the operator when doing an upgrade from v1.6.2 to v1.6.6 which I was also able to reproduce by re-running the istoctl upgrade command again even after the upgrade.
It seems that during the upgrade process the istio-ingressgateway service provisioned by the operator ends up reconfiguring the nodePort attributes for all the port definitions which, if using an AWS NLB, will cause the service controller to re-create the target groups associated with each of the NLB listeners and leads to an interruption of service during initial target group health check init.
Is there any explanation for this behaviour? I wasn’t able to figure it out so far and I would like to avoid relying on predefined nodePort values if possible, which is something I’d assume would solve the problem.
Kubernetes: 1.16 (EKS)