Skip to content
This repository has been archived by the owner on Oct 7, 2020. It is now read-only.
Ed Snible edited this page Jun 24, 2019 · 7 revisions

In Istio 1.3, we are adding the ability to run multiple Istio 'environments', and install 'a-la-carte'.

This is a different packaging and configuration of the same components we had in 1.2- but users may run run different versions and configurations, each in a different namespace.

All environments share the root CA, Istio CRDs and discovery (with some caveats), but may have different defaults and use different implementations of each component.

A user apps is visible and reachable in all 'environments', but its sidecar is managed by one specific env - could be 'prod', 'canary', 'testing'. Or it can have no sidecar at all.

Namespaces

The use of namespaces serves 2 goals: better security and safer upgrade.

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.

Clone this wiki locally