To istioctl or to helm

1

Hi there,

Per the docs, the recommended way to install Istio is using istioctl. The Helm way will be deprecated in the future. However, for upgrade, using istioctl is experimental. And Helm will only upgrade installations that were installed using Helm.

That makes it hard to pick the installation method to use. Seems like I should use Helm as I don’t think I’d want to rely on an experimental feature for upgrade. However,…

  1. For how much longer are you keeping Helm as an installation method?
  2. If/when Helm disappears and I installed mine using istioctl, what would be my options, if any, besides uninstalling my current version and then installing the new version from scratch?

What have others been using for both install and upgrade?

Thanks in advance for your thoughts.
J

(EDIT: Corrected the category)

1 Like
2

For kicks, I tried running:

istioctl manifest apply

and got this error:

Error: unknown command “manifest” for “istioctl”

What could I be missing? I downloaded 1.3.5 (because I want to test upgrading to 1.4.0 later on).

Thanks,
J

3

Hey guys,

It seems like most people are still using helm. Anyone using istioctl for installation? The “manifest” command does not work for me. Are these commands not built into the executable? Do I need something else?

Thanks,
J

4

The istioctl manifest command is new in Istio 1.4. It is not available in earlier versions (edit: Thanks Martin for the correction.) It was experimental in 1.3.

1 Like
5

It’s experimental in 1.3 i.e. use “istioctl x manifest apply”
Jaid, regarding using Helm vs. istioctl, for new installations we do recommend istioctl. Although istioctl upgrade is experimental in 1.4, we plan to move it to beta in 1.5 - so you will be able to use upgrade to go from 1.4 to 1.5 without any issues.
For upgrading patch versions, I don’t think there should be any problem with upgrade; patch versions typically don’t make any API changes and most of upgrade command functionality is around checking for API changes during upgrade. We do plan to test upgrade command for 1.4.x -> 1.4.(x+1) and any errors are likely to be of the flavor of “cannot find this field to validate against the schema”, not something that would actually break your install.

1 Like
6

Thanks. I just tried it. It doesn’t look like the experimental version supports “–set profile”, does it? It doesn’t show up in the help. I tried it anyway but got the same result with and without it.

Btw, if I wanted just the Ingress gateway for now, would “minimal” cut it? I thought I’d read one earlier post recommending that we do a full install anyway. It’d be great to get an updated (and official) answer now. (I actually do not see Ingress gateway checked under minimal. Shouldn’t it be? I thought minimal included Traffic Management, which I take to be Ingress?)

Also, I’m unclear on what you said about patch versions. You had said there should be no problem with upgrade. But were you referring to upgrade via istioctl or via helm? If I install 1.4.0 now using istioctl and you come up with 1.4.1, which upgrade method can/should I use?

Thanks again,
J

7

Hi, that’s correct, upgrade doesn’t support --set because we want to discourage the use of --set in favor of passing in an IstioControlPlane CR YAML for anything except experimenting. --set is a convenience to quickly try something out, but doesn’t seem like a good idea to use it with upgrade because it’s easy to make a mistake once you have more than a couple of customizations.
Having said that, if users really want it we’ll put it in…
For installing a gateway only, minimal is a good starting point. You’d just have to pass --set profile=minimal,gateways.enabled=true to istioctl (or use an ICP YAML file ;-)).
There should be no problem using the upgrade command to go from 1.4.0 to 1.4.x, even though it’s marked experimental. Upgrade mostly just validates that API and default value changes are compatible between source and target versions and it’s very unlikely that there would be such changes in 1.4.0->1.4.x. And even if there are, we will add those into 1.4.x upgrade command and we will be testing that the command works for such patch version changes.

8

Thank you again. Re profiles, I was actually referring to installation. The experimental manifest command in 1.3.5 does not seem to support profiles, does it?

EDIT: There’s actually a set command in the help, but my “–set profile=minimal” did not work. I see the same amount of objects created with and without it.

9

It should - does istioctl x manifest generate --set profile=minimal not work for you?

10

Oops, I keep editing without checking for any reply. No, it didn’t. Let me try again.

11

Ah yes, I recall there was a but in that version specifically with using --set profile.
Could you please try with an ICP CR?

12

This was the issue fyi: https://github.com/istio/istio/issues/17408

13

Thank you for all your help. Not sure what you mean by trying with an ICP CR. Please elaborate only if it’s no trouble at all.

I’m inclined to just go ahead and install 1.4.0. The only reason I’m trying 1.3.5 is so that I can try to upgrade to 1.4.0 afterwards. But seeing how the installation and upgrade have changed between 1.3.x and 1.4.x, I don’t think I should invest any more time on it.

Thanks again,
J

14

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.

15

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

16

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

17

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?

18

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.

19

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.

20

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