Home

The installer provides the ability to run multiple Istio 'a-la-carte' environments, each customized to better match the features and needs of our users. Each instance consists of a set of configurations and deployments, currently each running in a different namespace. Work is in progress to also allow each component to use same namespace.

The namespace is used to isolate components and control plane instances, and allow different teams to operate them.

A workload is visible and reachable by all other workloads, in all 'environments' - as long as the root CA used to configure the client and server certificates is matching. It is recommended that the certificate provider and set of root CAs is common for the entire mesh, and uses 'istio-system' namespace.

Each workload is managed by one specific control plane instance, identified by a name, like 'prod', 'canary', 'testing', '1.3-sds-strict'. The selection of the instance happens at inject time, either by using the namespace label to select a specific injector or by using a different kube-inject configuration, selecting the desired Pilot and inject options.

Install

We support multiple mechanisms to install Istio - helm ( template or tiller ), Kustomize, "kubectl apply -k", operator.

For people looking for an easy to install Istio we recommend "kubect apply -k" or kustomize methods.

The installer will provide a set of base configurations that can be used directly with kubectl, with optional kustomization of common settings:

• Demo - most features enabled, intended for demos or tests
• Small (TODO) - a basic installation with most stable config, for a small cluster. Similar with default install in 1.2
• Micro - smallest install, only Pilot and Ingress, with optional manual kube-injection of sidecars.
• TBD - more configs

For each configuration user can directly use "kubect apply -k github.com/istio/installer/..." or use a local 'kustomize.yaml' file that customizes the settings.

Namespaces

The use of namespaces serves multiple goals:

• better security
• safer upgrade
• divide the management of features across multiple teams if needed
• (short term) work around any use of global state in the code base.

For security we want to minimize the escalations in case one of the components is compromised, and reduce the set of people who have access to critical components. For example a bug in Grafana ( as example) should not allow an attacker to access the root CA. And someone who is granted permissions to manage Grafana should not be able to escalate it and make changes to pilot or use citadel's service account to access its private keys.

For safe upgrades, we want each config change - including upgrade, but also regular configuration changes - to be canaried and tested before it can affect full production. In Istio 1.2 if you make a config change or upgrade, the change will immediately affect all workloads. In 1.3, it is recommended that you make the change in the 'testing' environment first, possibly in a different cluster, and roll it slowly to 'canary' environment and then 'prod'. You can also maintain separate 'prod' environments with different settings and versions - depending on the needs of your workloads.