Best practices for Istio in prod

Before you install Istio, review and plan the recommended namespace architecture for your Istio setup.

For a production-level Istio setup, separate your Istio resources across different namespaces for the different personas that need access to the Istio resources. The following diagram depicts the suggested setup for the namespaces and Istio resources.

Figure of a production-level Istio architecture

The recommended namespaces for each Istio component include the following.

Persona-driven configuration management

Istio recommends a persona-driven configuration paradigm to help you manage which resources your teams can access and change. For example, if many of your teams share Kubernetes clusters, you can set mesh-wide defaults and prevent teams from impacting one another as much as possible. Individual workload configurations are managed by the teams that support the workloads. The following sections show you how to use Istio to allow each user persona to manage the appropriate Istio namespaces and configurations.

Figure of recommended resource management across multiple namespaces

Istio-config namespace for cluster admins

The Istio root namespace, istio-config, allows cluster admins to define defaults across the entire service mesh for the rest of the teams to use. For example, the cluster admin might set a default security policy or tune the mesh's performance in this namespace.

Additionally, the istio-config namespace is the only recommended namespace for the EnvoyFilter resource. Envoy filters are considered an advanced configuration which can impact the overall health of the mesh. If cluster users want to utilize Envoy filter for their workloads, label each workload to match the selector of the Envoy filter. For example, if you have an external authorization Envoy filter, match the selector to the external-auth: enabled label for any workloads that you want to apply the filter to.

Cluster admins can use this namespace to:

Gateway namespaces for network owners

The gateway namespaces, such as istio-ingress, istio-egress, and istio-eastwest, control all ingress traffic to and egress traffic from the cluster. These namespaces allow network owners to configure and manage how traffic is routed. For example, in a large organization, service owners might ask the network owner to expose their workloads externally so that clients outside of the cluster can send requests to the workloads.

Network owners can use these namespaces to:

App namespaces for service owners

App namespaces allow service owners to run their workloads and deploy Istio configurations that are specific to workloads in the same namespace. These app namespaces might be named for the workloads that run in the namespaces, or for the service teams that use the namespaces. By colocating the configurations and the workloads to which the configurations apply, you can isolate the scope of the configurations.

For example, a team might own a few namespaces in which they can deploy their applications. The team is not given access to shared namespaces in the cluster to prevent them from impacting other teams. However, the team can still apply Istio configurations to their own applications in their app namespaces. If the team needs to expose their applications via an Istio ingress gateway, they might ask the network owners to create a virtual service in the istio-ingress namespace that points to their app namespace.

Service owners can use these namespaces to: