Service mesh options

Istio mode link

Gloo Mesh Core supports Istio service meshes that run either in ambient or sidecar mode. Review the following table to help you choose your Istio mode.

Istio image link

Gloo Mesh Core supports Istio service meshes that run either community Istio images or Solo distributions of Istio. The Solo distribution of Istio is a hardened Istio enterprise image, which maintains n-4 support for CVEs and other security fixes. The image support timeline is longer than the community Istio support timeline, which provides n-1 support with an additional 6 weeks of extended time to upgrade the n-2 version to n-1. For more about the added benefits of Solo distributions of Istio and to review the available image distributions, see Solo distributions of Istio.

Lifecycle management link

Gloo Mesh Core supports full service mesh lifecycle management with the Istio Lifecycle Manager. By using Gloo-managed service meshes, you no longer need to manually install and manage the istiod control plane. Instead, you provide the Istio configuration in a Gloo custom resource (CR), and Gloo translates this configuration into managed istiod control plane and gateways in each workload cluster for you. For more information, see Lifecycle management.

Updates to the Istio lifecycle manager in version 2.6 and later link

In version 2.6 and later of Gloo Mesh Core, the Istio lifecycle manager is automatically updated with the following improvements.

Istio lifecycle agent

The Gloo agent that runs on each registered workload cluster now leverages a feature called the Istio lifecycle agent. This Istio lifecycle agent now deploys and manages the Istio installations in your clusters, instead of the Gloo agent directly.

Values translation

The Istio lifecycle agent now translates the IstioOperator configuration in your IstioLifecycleManager and GatewayLifecycleManager resources into Istio Helm chart values to deploy the installations, instead of deploying installations based on the IstioOperator configuration directly. The agent writes the translated values into internal resources, ClusterIstioInstallation, which represent the state of the Istio installations in each workload cluster.

Important gateway translation differences

By default, upstream Istio translates IstioOperator configuration into values for the deprecated gateways/istio-ingress and gateways/istio-egress Helm charts. The lifecycle agent in Gloo Mesh Core translates configuration into the supported gateway Helm chart instead. If you use GatewayLifecycleManager CRs in version 2.6 and later, note the following differences that are implemented so that your IstioOperator configuration can be translated into supported gateway Helm chart values:

• The same chart is used for both ingress and egress gateways. The only difference is the service type, which defaults to ClusterIP for egress gateways.
• The gateway chart always uses injection of the gateway template, which means that:
  • Deployments always use an injection template, regardless of the IstioOperator setting.
  • Specifying an injection template other than gateway results in an error.
  • The gateway’s namespace, such as gloo-mesh-gateways, must not have annotations to disable injection.
  • The hub and tag values in the IstioOperator determine only the Solo Helm chart to use. The image version in the deployment is always auto, and is injected based on which Istio control plane provides sidecar injection.
• The default target ports for the gateway service are now 80 and 443, as opposed to the default values of 8080 and 8443 in the deprecated Helm charts.
• Review the required changes for specifying Helm values settings directly.
  • Do not specify values.gateways settings. These settings were inherently defined for the deprecated charts only, and are not compatible with the currently-supported gateway chart. The only exception is the values.global.imagePullSecrets field, which is supported.
  • To specify values settings from the currently-supported gateway chart, use the unvalidatedValues field. This is necessary because the values settings are not currently supported by upstream Istio as part of the IstioOperator. For example, the gateway chart supports a kind setting that determines whether the gateway is created as a deployment or a daemonset. To deploy a gateway as a daemonset, you can specify the kind setting in an unvalidatedValues section of your GatewayLifecycleManager:

      
    istioOperatorSpec:
      components:
        ...
      unvalidatedValues:
        gateway:
          kind: DaemonSet
      

• The following k8s settings that you might set in components.ingressgateway.k8s, for example, are either unsupported or supported for certain values:
  • ownerName is not applicable because it is used for an istio-operator-specific annotation.
  • strategy (such as to define rolling update settings) is not available in the gateway chart, but can be specified in an overlay.
  • env only supports explicit values. To specify ValsFrom or EnvFrom, you must use an overlay.

Upgrading to 2.6

• If you use the Istio lifecycle manager in Gloo Mesh Core version 2.5, your Istio installations are unchanged when you upgrade Gloo Mesh Core to 2.6. The new translation system is only implemented when you make a change to your IstioLifecycleManager or GatewayLifecycleManager resources. To preview any changes to how your gateway values might be translated, you can run a canary upgrade to compare two Istio installations.
• Because of the updates to the Istio lifecycle manager in version 2.6, you currently cannot use the lifecycle manager alongside unmanaged Istio service meshes that you install by using Helm, istioctl, or an IstioOperator. To use the Istio lifecycle manager, remove any existing Istio installations, and create managed Istio installations by following the steps in this guide. Note that this limitation will be addressed in future releases.