Best practices for Istio in prod
Before you install Istio, review and plan the recommended namespace architecture for your Istio setup.
Recommended Istio namespaces
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.
The recommended namespaces for each Istio component include the following.
istio-operator: Deploy the Istio operator into this namespace. This placement ensures that the Istio operator has the permissions to manage the Istiod and Istio gateway deployments.
istio-system: Deploy only the
istiodcontrol plane infrastructure and configuration into this namespace.
istio-config: Deploy all data plane configuration, such as virtual services and destination rules, to the
istio-confignamespace. You configure these mesh-level settings by creating and applying Gloo Mesh resources. Note that while mesh-level configurations are deployed to this namespace, workload-specific configurations can instead be colocated with the workloads in their namespaces. For more information, see Persona-driven configuration management.
istio-gateways: Deploy gateways into their own namespaces to prevent the potential risk of gateways having access to secrets in the
istiodnamespace. Depending on your security and management requirements, you might use one
istio-gatewaysnamespace, or further isolate individual gateway deployments into their own
- App namespaces: Deploy workloads and deploy Istio configurations that are specific to workloads in the same namespace. These app namespaces might be named for the workloads or for the service teams that run the workloads.
Specifying namespaces during installation
When you deploy Istio with this namespace model, you can specify the namespaces in the
Example Istio operator deployment with multiple gateway namespaces:
helm install istio-operator manifests/charts/istio-operator \ --set operatorNamespace=istio-operator \ --set watchedNamespaces="istio-system\,istio-ingress\,istio-egress\,istio-eastwest"
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.
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.
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:
- Add custom Envoy filters
- Manage global service discovery properties, such as with the following sidecar configuration:
# configures sidecars in all namespaces to allow egress traffic only to other workloads in the same namespace as well as to services in the istio-system namespace. apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: default namespace: istio-config spec: egress: - hosts: - "./*" - "istio-system/*"
- Enable default security policies, such as with the following peer authentication configuration:
# require that all workloads in the mesh only accept mTLS traffic. # This is only recommended once all worklads have been added to the mesh. apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: "default" spec: mtls: mode: STRICT
Gateway namespaces for network owners
The gateway namespaces, such as
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:
- Control cluster ingress traffic
- Set security specifications on ingress traffic (such as HTTPS, authentication, etc.)
- Manage ingress and egress certificates and identities
- Control cluster egress traffic
- Limit which external hosts can be called
- Control which workloads are exposed externally
- Manage gateway lifecycles
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:
- Manage ingress traffic into their applications
- Authenticate and authorize requests
- Scope service discovery
- Manage allowable egress hosts
- Manage application lifecycles