Persona-driven configuration management

By spreading resources across several namespaces, you can more easily allow each persona in your organization to manage the configurations that are applicable to the workloads they are responsible for.

For example, cluster admins can set mesh-wide policies that set defaults and limits across the cluster, while still allowing individual microservice owners to create the configurations and policies necessary for their 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
Figure of recommended resource management across multiple 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-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.

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

Certificate management

In a production-level Gloo Mesh Enterprise setup, you might want to automatically generate, store, and manage the required certificates outside of Gloo Mesh, such as by using Amazon Certificate Manager (ACM). For Istio, you must be able to sign intermediate CA certificates in your Gloo Mesh setup so that each Istio deployment can issue certificates to workload pods in its mesh. For more information, see Certificate management.

Deployment

For production, deploy the Istio Helm charts that declare how to set up the istiod control plane and Istio gateways across your clusters. For the full set of steps on how to deploy the control plane and gateways, see Deploy Istio in production.

Upgrading Istio

To manage the complexity of upgrading Istio and to prevent downtime, the deployment profiles for the control plane and gateways in the installation steps include revisions. When you need to upgrade to a newer Istio version, you can deploy separate Helm releases for the newer control plane and gateway revisions in a canary upgrade model.

For more information, see Upgrading Istio.