To istioctl or to helm

No problem. When you use --set command, the values you can passed to it are determined by the IstioControlPlane schema:
(structured format)


(alphabetical)

You can represent the same values as a YAML file, which you pass to the command with -f (see https://istio.io/docs/setup/install/istioctl/#configure-the-feature-or-component-settings).
So
istioctl manifest apply --set proflile=minimal
would become
istioctl manifest apply -f myfile.yaml
where myfile.yaml is

apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
  profile: minimal

Yes, I recommend just going with 1.4.0 if possible.

I see. Thanks again! One last thing (for now).

Just like someone else in this forum, I need to push the images to our own registry. Is there a better URL than this (i.e. is there a release counterpart)?

https://gcsweb.istio.io/gcs/istio-prerelease/prerelease/1.4.0/docker/?_ga=2.137650288.156249711.1574357423-1490039783.1571161563

Thanks again,
J

Our official release images go to docker.io/istio.

Oh, I cannot pull Docker images from there, unless I guess I do it from a public network. That was the problem I was trying to get around using the tar.gz’s. Do you have tar.gz’s of the release images anywhere, similar to the ones on that prerelease URL?

Also, and I apologize for the incessant (dumb) questions. I tried running:

istioctl manifest apply --set profile=minimal,gateways.enabled=true

It installed ingressgateway and pilot.

Don’t I also need the following?

policy
sidecar-injector

When I was evaluating 1.3.3 using Quick Install, my requests would fail if I brought down policy. And when sidecar-injector wasn’t running, then new pods would not come up.

Please shed some light on this.

The release tar gz’s are on Github: https://github.com/istio/istio/releases/
You don’t need policy or sidecar-injector. Only if policy is originally installed and you bring it down, requests will fail.

Thanks. I’ll try it with just ingress and pilot then.

Re the tar gz’s, I was actually referring to the exported images, just like the ones here (https://gcsweb.istio.io/gcs/istio-prerelease/prerelease/1.4.0/docker/?_ga=2.137650288.156249711.1574357423-1490039783.1571161563). So, instead of pulling from docker.io, I would load those tar gz’s. Are these prerelease images the same as the images from docker.io?

Thanks again,
J

https://gcsweb.istio.io/gcs/istio-release/releases/1.4.0/docker/

2 Likes

I don’t see the ingressgateway image there. I’ve sampled some of the tar.gz’s to see if they had it, but I haven’t found it so far. Is there another location for it by any chance?

EDIT: Oops, nvm… the image for it is actually proxyv2.

Another snag…

Now that I’ve pushed the pilot and proxyv2 images to our own repo, how do I make the istioctl install pull them from there?

I tried updating the hub in default.yaml. It didn’t work. I’m using minimal, but I didn’t find anything in minimal.yaml. (I admittedly have yet to read up on how these profiles work.)

I also tried updating the hub in values.yaml (for helm), just for kicks. It didn’t work.

It should be possible, right? With the Quick Install evaluation I did, I was able to update the demo yaml, and it worked fine.

For this istioctl install, how do I accomplish the same?

Thanks again,
J

K, figured out this much… I simply had to do generate to output the yaml to a file… then, update the resulting yaml before applying it.

Is this sustainable? During upgrades, will I be able to do the same thing?

Anyhow, the next snag is… my ingressgateway is not starting up. Nor does the istio-proxy container in pilot. They’re both looking for cert files (see partial log below). The Quick Install was indeed quick. It spoiled me. I didn’t have to worry about these things. Will do some reading up, but if you or anyone has the quick answer, I’d appreciate it.

|2019-11-26T01:44:59.435745Z|info|Monitored certs: string{"/etc/certs/cert-chain.pem", “/etc/certs/key.pem”, “/etc/certs/root-cert.pem”}|
|2019-11-26T01:44:59.435751Z|info|waiting 2m0s for /etc/certs/cert-chain.pem|
|2019-11-26T01:45:00.437327Z|info|waiting for file|
|2019-11-26T01:45:00.537534Z|info|waiting for file|

I’m still stuck with that same problem. I’ve tried different things to no avail.

I do not want to deal with certs for now. What do I need to change in the generated manifest (or pass as an argument to the manifest generate/apply command) so that my pilot and ingressgateway pods do not look for these certs during start-up? I think it’s a matter of disabling mtls, but I cannot figure out where that can be done in the manifest.

Thanks,
J

Hi Jaid, I think your problems have drifted quite a ways from the thread title - I suggest you create a new thread with an appropriate title and put some of these question there so that other community members will see them.

They have, haven’t they? :slight_smile: Yes, let me do that. Thanks!

Actually, @ostromart, would you mind addressing my question regarding the sustainability of what I just did? I created the manifest and then updated the images to point to my own repo before applying it.

Would I be able to do the same thing during future Istio upgrades? Is there a better way of accomplishing the same thing?

You should definitely not have to edit the output manifest. The hub/tag parameters are part of the API and should work. Could you post the command you ran to change the hub value so I can try to repro?

I actually did not run any command. Is there such a command?

I found “hub” in default.yaml. I didn’t find it anywhere else. So I modified it even when I was going to use the minimal profile, thinking that the default.yaml would still be somehow used (is it?).

(Also in default.yaml, I modified the images for proxyv2 and pilot to have the “istio-” prefix just because that’s how I tagged it.)

Neither change took effect when I ran the manifest apply/generate command.

What is the correct way of updating the hub (and possibly the image names, too) before running the manifest command?

Thanks again!

You should use the IstioControlPlane API (see links above).
So you would do something like istioctl manifest generate --set hub=

1 Like

Thanks. That worked.

I’ve written a post clarifying the future of Helm Support in Istio.