Check out these best practices to consider when running in production with the Istio add-on. 

Istio on IBM Cloud Kubernetes Service provides a seamless installation of Istio, automatic updates and lifecycle management of Istio control plane components, and integration with platform logging and monitoring tools. Today, IBM Cloud is announcing the release of version 1.8 of the Istio add-on. 

Performance

• Scope your EnvoyFilters: Istio’s CRDs (VirtualService, DestinationRule, PeerAuthentication, etc.) provide many options for easily configuring your traffic. For further customization, many users rely on EnvoyFilter to directly configure the Envoy proxies. EnvoyFilter capabilities are very powerful and should be applied with care. Scope down your EnvoyFilter by using the appropriate workloadSelector and match properties to reduce unnecessary overhead.
• Use namespaces and Sidecar: The Istio control plane is responsible for generating the routing configuration and distributing it to all the proxies in the mesh. Without any scoping, the generation and distribution can quickly become bottlenecked. To alleviate this problem, leverage Kubernetes namespaces to distribute your workload and avoid deploying too many services into a single namespace. Then, use Istio’s Sidecar resource to scope down the amount of configuration received by the proxies by defining what namespaces your workload needs access to. 
• Disable logging: You can customize a set of Istio configuration options by editing the managed-istio-custom configmap resource. These settings include extra control over monitoring, logging, and networking in your control plane and service mesh. The istio-global-logging-level option is used to set the scope of logs and the level of log messages for control plane components. Set this to none. 
• Disable tracing and telemetry: The istio-meshConfig-enableTracing option in the managed-istio-custom configmap controls the generation of trace spans and request IDs. If you’re not leveraging the tracing capabilities of Istio, you can disable this option. Furthermore, to remove any performance overhead associated with telemetry metrics and disable all monitoring, set istio-monitoring-telemetry to false.

Availability

• Multizone cluster: Your users are less likely to experience downtime when you distribute your apps across multiple worker nodes and zones. Create a multizone cluster to distribute your workloads across multiple worker nodes and zones, and protect against zone failures with hosts, networks, or apps. If resources in one zone go down, your cluster workloads continue to run in the other zones.
• Enable additional gateways: The Istio add-on comes with a single deployment and service of the Istio ingress gateway. An auto-scaling policy is configured to scale the replicas up and down automatically. If you are using a multizone cluster for maximum availability, it’s recommended that you create additional ingress gateway deployments and services in secondary and tertiary zones. Use the istio-ingressgateway-public-1|2|3-enabled and istio-ingressgateway-zone-1|2|3 options in the managed-istio-custom configmap to achieve this.

Security 

• STRICT mTLS: Istio will automatically use mTLS when it determines it’s possible and fallback to plain text when it cannot. This is useful when some of your services are part of the mesh and others are not. If all your services are Istio-enabled, you can enforce mutual TLS for the entire mesh or namespace by creating a PeerAuthenticationPolicy.
• Edge nodes: Edge worker nodes can improve the security of your IBM Cloud Kubernetes Service cluster by allowing fewer worker nodes to be accessed externally and by isolating the networking workload. When these worker nodes are marked for networking only, other workloads cannot consume the CPU or memory of the worker node and interfere with networking. Add the dedicated=edge label and taint to your edge worker nodes. The ingress gateway pods are pre-configured with the necessary tolerations to allow them to run on the edge nodes. 
• Security updates: IBM Cloud keeps your Istio control plane and the default gateway components up-to-date by automatically rolling out patch updates to the most recent version of Istio that is supported by IBM Cloud Kubernetes Service. Whenever the managed Istio add-on is updated, make sure that you update the Istio sidecars for your app to match the Istio version of the add-on.

Traffic management

• Outbound traffic policy: By default, outbound traffic to external URLs goes thru the sidecar proxy, but is not restricted. To prevent your workloads from making outbound calls to unknown hosts, set the istio-global-outboundTrafficPolicy-mode option in the managed-istio-custom configmap to REGISTRY_ONLY. This configures the sidecars to only allow access to defined services. 

More information

Check out our documentation for more information about the Istio add-on for the IBM Cloud Kubernetes Service. 

If you have any questions or have any feedback to share, please engage our team via Slack by registering here and join the discussion in the #general or #managed_istio_knative channels on our public IBM Cloud Kubernetes Service Slack.