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 istiod control plane infrastructure and configuration into this namespace.
• istio-config: Deploy all data plane configuration, such as virtual services and destination rules, to the istio-config namespace. 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-ingress, istio-egress, and istio-eastwest or istio-gateways: Deploy gateways into their own namespaces to prevent the potential risk of gateways having access to secrets in the istiod namespace. Depending on your security and management requirements, you might use one istio-gateways namespace, or further isolate individual gateway deployments into their own istio-ingress, istio-egress, and istio-eastwest namespaces.
• 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 operatorNamespace and watchedNamespaces settings.

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.

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:

• 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-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:

• 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