Setting boolean environment variable with --set during "istioctl install" operation

Config
1

I want to enable DNS proxying during Istio installation, but I can’t find figure out a working istioctl install command using my current --set approach to configuration.

The CLI help tries to provide guidance:

$ istioctl install --help
...
  # For setting boolean-string option, it should be enclosed quotes and escaped with a backslash (\).
  istioctl install --set meshConfig.defaultConfig.proxyMetadata.PROXY_XDS_VIA_AGENT=\"false\"
...

That’s great! It almost exactly matches what I want here. Here’s my command, with the last two lines being new:

istioctl install -y \
--set values.gateways.istio-ingressgateway.type=NodePort \
--set components.egressGateways[0].enabled=true \
--set components.egressGateways[0].name=istio-egressgateway \
--set hub=gcr.io/istio-release \
--set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_CAPTURE=\"true\" \
--set meshConfig.defaultConfig.proxyMetadata.ISTIO_META_DNS_AUTO_ALLOCATE=\"true\"

This fails to install with a timeout on ingress/egress gateway setup:

✘ Ingress gateways encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition
✘ Egress gateways encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition

Sure enough, the gateways are in CrashLoopBackoff mode, with (filtered) log messages like so:

proxyMetadata:
ISTIO_META_DNS_AUTO_ALLOCATE: \"true\"
ISTIO_META_DNS_CAPTURE: \"true\"
warn Invalid environment variable value `"true"`, expecting true/false, defaulting to false
Error: failed to start envoy agent: failed to generate bootstrap metadata: strconv.ParseBool: parsing "\"true\"": invalid syntax

I think what’s going on here is a series of failed conversions between YAML and Go based on true being a magic string in YAML. Given that the help message even attempts to address this exact issue, I assume it’s not just me. Is there a better way to fix this?

I’m not confident that I can convert from my current --set installation to an explicit IstioOperator resource, because I don’t know what my current one even looks like. Maybe I can dig one out of one of my existing clusters, but I’m hoping there’s a simpler solution.

2

I highly recommend not doing your customization via a series of “–set” commands… You want a more infrastructure-as-code approach, i.e: something you can put under source control.

You want a file that contains your customizations, it will start out something like this:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  profile: default

  # You may override parts of meshconfig by uncommenting the following lines.
  meshConfig:
    defaultConfig:
      proxyMetadata: {}
    enablePrometheusMerge: true
3

My --set selections are absolutely under source control, although I’d be happy to make my setup more declarative if I can. I tend to rely on shell scripts too much sometimes.

If I understand your suggestion, this bit implies that I’d start with the contents of {istio-dir}/manifests/profiles/default.yaml and then apply customizations on top of that?

spec:
  profile: default

I’ll do some experiments when I get a chance and see if that seems to work as expected. I’d be concerned about exactly how the merge operation happens. I wouldn’t want to replace the entire istio-ingressgateway config simply by trying to specify a type of NodePort, for example.

Thanks!

4

Kinda/sorta… The example I gave will automatically use settings from the ‘default’ profile (which I think Isto recommends for most non-trivial implementations) with this line:

spec:
  profile: default

then the subsequent lines in the example can be used to change only the settings that you want to customize… such as settings for “meshConfig:”… I think I started that block for you… just figure out where the settings you want to tweak fit in, and place them correctly…

If perhaps you called your custumization file my-customizations.yaml, you could use:

istioctl manifest generate -f my-customizations.yaml

to view the generated manifest & verify that your changes are working properly

5

Hmm, yeah. I guess I should generate that manifest with and without mods and see what changes.

Thanks, I don’t know why I didn’t spot istioctl manifest generate before.