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.