Istio on GKE overview

What is Istio?

Istio is an open service mesh that provides a uniform way to connect, manage, and secure microservices. It supports managing traffic flows between services, enforcing access policies, and aggregating telemetry data, all without requiring changes to the microservice code.

Istio gives you the following benefits:

  • Automatic load balancing for HTTP, gRPC, WebSocket, MongoDB, and TCP traffic.
  • Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
  • A configurable policy layer and API that supports access controls, rate limits, and quotas.
  • Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
  • Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

You configure Istio access control, routing rules, and so on by using a custom Kubernetes API, either via kubectl or the Istio command-line tool istioctl, which provides extra validation.

You can find out more about Istio in the open source documentation set at istio.io.

What is Anthos Service Mesh?

We recommend that Google Cloud customers use Anthos Service Mesh, Google's fully-supported distribution of Istio. Because Anthos Service Mesh is compatible with the Istio APIs, it provides all the benefits of the Istio service mesh and more:

Anthos Service Mesh

You can install Anthos Service Mesh on Google Kubernetes Engine (GKE) as a standalone service, which doesn't require an Anthos subscription. To get started exploring Anthos Service Mesh features, see the Anthos Service Mesh quickstart for GKE.

What is Istio on GKE?

Istio on Google Kubernetes Engine is a tool that provides automated installation and upgrade of Istio in your GKE cluster. When you upgrade GKE, Istio on GKE is automatically upgraded to the most recent GKE-supported version of Istio. This lets you easily manage the installation and upgrade of Istio as part of the GKE cluster lifecycle.

It is important to note that, when using Istio on GKE, Istio runs inside your cluster. There is no service level agreement (SLA) on the Istio components running in your cluster.

Should I use Istio on GKE?

While Istio on GKE manages installation and upgrades, it uses default installation options for the control plane that limit configuration options. Due to these limitations and the product's beta status, customers should not use Istio on GKE in production. Anthos Service Mesh is a better option for production workloads.

Limitations of Istio on GKE include the following:

  • The version of Istio installed is tied to the GKE version, and you are not able to update them independently.

  • There are strong limitations over the configuration of the control plane. Because of these limitations, we recommend that you don't use Istio on GKE in production.

  • While this add-on installer is part of GKE, the resulting installation of Istio is not a Google-supported product. For those who want a supported product, Anthos Service Mesh is a better option.

If you need to use a more recent version of Istio, or want greater control over your Istio control plane configuration (which may happen in some production use cases), we recommend that you use Anthos Service Mesh.

If you no longer want to use our automatic installation functionality for whatever reason, you can uninstall Istio on GKE. You can find out how to do this in Uninstalling Istio on GKE.

What's installed?

When you create or update a cluster with Istio on GKE, the following core Istio components are installed:

The installation also lets you add the Istio sidecar proxy to your service workloads, allowing them to communicate with the control plane and join the Istio mesh.

You can find out more about installing and uninstalling Istio on GKE and your installation options in Installing Istio on GKE.

Cloud Monitoring support

For clusters with Google Kubernetes Engine Monitoring enabled, the Istio Stackdriver adapter is installed along with the core components described previously. The adapter can send metrics, logging, and trace data from your mesh to Cloud Monitoring, Cloud Logging, or Cloud Trace, providing observability into your services' behavior in the Google Cloud Console. After you've enabled a particular Monitoring, Logging, or Trace feature for your project and cluster, that data is sent from your mesh by default. Istio on GKE automatically sets the access scopes in the cluster's node pool for Monitoring, Logging, and Trace.

Monitoring

If the Cloud Monitoring API is enabled in your Google Cloud project, your Istio mesh automatically sends metrics related to your services (such as the number of bytes received by a particular service) to Monitoring, where they appear in the Metrics Explorer. You can use these metrics to create custom dashboards and alerts, letting you monitor your services over time and receive alerts when, for example, a service is nearing a specified number of requests. You can also combine these metrics using filters and aggregations with Monitoring's built-in metrics to get new insights into your service behavior.

To view the metrics for a monitored resource using Metrics Explorer, do the following:

  1. In the Google Cloud Console, go to Monitoring or use the following button:
    Go to Monitoring
  2. In the Monitoring navigation pane, click Metrics Explorer.
  3. Select the Configuration tab, and then enter or select a Resource type and a Metric.

For a full list of Istio metrics, see the Cloud Monitoring documentation.

Logging

If the Cloud Logging API is enabled in your Google Cloud project, your Istio mesh automatically sends logs to Logging, where they appear in the Logs Viewer. See the Cloud Logging documentation to find out more about what you can do with the log data, such as exporting logs to BigQuery.

Tracing

You can enable Cloud Trace so that your Istio mesh automatically sends trace data to Trace, where it appears in the trace viewer. To get the most from distributed tracing to help find performance bottlenecks, you need to change your workloads to instrument tracing headers. You can find out how to do this in the Istio Distributed Tracing guide.

How does the upgrade process work?

The Istio lifecycle is managed as a part of the GKE upgrade process. In GKE, there are two upgrade processes:

  • Master upgrade: The master upgrade process is automatic and updates the Kubernetes control plane components (API server, scheduler, controller manager, and so on) on the master node as well as the add-ons. The Istio control plane components upgrade is managed as a part of this process.
  • Node upgrade: The node upgrade process can be either automatic (opt-in; recommended) or manual, which updates the Kubernetes components on the worker nodes to sync with the same version of the master node. The Istio sidecar upgrade is managed as a part of this process.

Istio on GKE automatically upgrades the control plane to a recent (not necessarily latest) stable version. The version is selected based on observed stability and performance in open source deployments over a period of time. Version upgrades are announced in advance on the istio-gke-announce group. In general, version upgrades are rolled out gradually to all GKE versions over a period of two or more weeks, starting with the most recent version.

Control plane versions are tested for backwards compatibility with the last two prior data plane (sidecar proxy) versions. After you have upgraded your GKE cluster, we recommend that you update the sidecars to the current control plane version as soon as possible, either by restarting Pods (with auto-inject enabled) or manually re-injecting the appropriate version.

Istio on GKE does not allow user control of the control plane version.

Modifying control plane settings

Because Istio on GKE controls how your control plane is installed and upgraded, it does not let you edit most of the control plane configuration settings provided in our installation. Any changes to the configuration, other than the following specified settings, are reverted by the Kubernetes add-on manager. Non-editable options are reverted every minute.

The settings you can configure while using Istio on GKE are as follows:

  • Horizontal scaling for control plane components, either using autoscaling or by manually setting the number of replicas.
  • Resource requests for control plane containers.
  • Pod disruption budgets for deployments that you need to remain available during upgrades, such as the provided Istio ingress gateway.

You can find out how to configure these settings in Configuring your control plane.

In each case the settings that you specify are retained when your installation is upgraded by Istio on GKE.

What's next?