Should I expect
istioctl install to be an idempotent, undisruptive action if I’m not making changes to the IstioOperator? I’m currently finding it to cause consistent disruption of service.
After recently upgrading to Istio 1.6 and migrating from the Helm-based install to Istioctl, I’m having trouble maintaining a stable environment as managed via a CICD pipeline, because of this. Whenever my pipeline runs,
istioctl install takes my service down for a brief outage. I’m able to reproduce the same problem from my local machine, if I authenticate and run the same command as my pipeline.
The command is this (literal values redacted):
istioctl install -r "1-6-4" --set spec.meshConfig.defaultConfig.tracing.custom_tags.workspace.literal.value="foo" --set spec.meshConfig.defaultConfig.tracing.zipkin.address="bar:9411" -f istio-operator.yaml -f istio-operator-nlb-overlay.yaml
Just repeatedly applying the same IstioOperator manifest yields the same result… after running this command I’m unable to access my http service for a couple minutes.
curl in the terminal comes back with
curl: (52) Empty reply from server and Postman says
Error: socket hung up.
Is this normal? I have Istio deployed in EKS and I recently moved from classic load balancers to using NLBs.