Istio on GKE is an add-on for GKE that lets you quickly create a cluster with all the components you need to create and run an Istio service mesh, in a single step. Once installed, your Istio control plane components are automatically kept up-to-date, with no need for you to worry about upgrading to new versions. You can also use the add-on to install Istio on an existing cluster.
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:
- 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 supporting 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 using a custom
Kubernetes API, either via
kubectl or the Istio command line tool
which provides extra validation.
Should I use Istio on GKE?
Istio on GKE lets you easily manage the installation and upgrade of Istio as part of the GKE cluster lifecycle, automatically upgrading your system to the most recent GKE-supported version of Istio with optimal control plane settings for most needs.
If you need to use a more recent open source 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 the open source version of Istio rather than the Istio on GKE add-on. You can find instructions for installing open source Istio on GKE in Installing Istio on a GKE cluster.
If you no longer want to use our managed functionality for whatever reason, you can uninstall the add-on. You can find out how to do this in Uninstalling Istio on GKE.
When you create or update a cluster with Istio on GKE, the following core Istio components are installed:
- Pilot, which is responsible for service discovery and for configuring the Envoy sidecar proxies in an Istio service mesh.
- The Mixer components Istio-Policy and Istio-Telemetry, which enforce usage policies and gather telemetry data across the service mesh.
- The Istio Ingress gateway, which provides an ingress point for traffic from outside the cluster.
- (Istio 1.0 versions only) The Istio Egress gateway, which allows Istio features like monitoring and routing rules to be applied to traffic exiting the mesh. The Istio Egress gateway is not installed by default in version 1.1 and above.
- Citadel, which automates key and certificate management for Istio.
- Galley, which provides configuration management services for Istio.
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 the add-on and your installation options in Installing Istio on GKE.
For clusters with Stackdriver enabled, the Istio Stackdriver adapter is installed along with the core components described above. The adapter can send metrics, logging, and trace data from your mesh to Stackdriver, providing observability into your services' behavior in the Google Cloud Platform Console and Stackdriver console. Once you've enabled a particular Stackdriver feature for your project and cluster, that data is sent from your mesh by default. You can find more details about working with Stackdriver in its documentation.
If the Stackdriver Monitoring API is enabled in your GCP project, your Istio mesh will automatically send metrics related to your services (such as the number of bytes received by a particular service) to Stackdriver, where they will 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 Stackdriver's built-in metrics to get new insights into your service behavior.
For a full list of Istio metrics, see the Stackdriver Monitoring documentation.
If the Stackdriver Logging API is enabled in your GCP project, your Istio mesh will automatically send logs to Stackdriver, where they will appear in the logs viewer. See the Stackdriver Logging documentation to find out more about what you can do with the log data, such as exporting logs to BigQuery.
If the Stackdriver Trace API is enabled in your GCP project, your Istio mesh will automatically send trace data to Stackdriver, where they will appear in the trace viewer. Note that to get the most from distributed tracing to help find performance bottlenecks, you will 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. Once 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. You can see the default install options in the
manifests for your labelled Istio on GKE version (the manifest that's applied
depends on your chosen mTLS mode and Stackdriver settings). For example, you can find the
install options for version 1.0.3-gke.3 in the console under
Any edits to these options, other than the settings specified below, will be
reverted by the Kubernetes add-on manager.
The settings you can configure while using the add-on (using
your Kubernetes tools of choice) are:
Horizontal pod autoscaling settings for all deployments. We provide default values but you can edit them to suit your needs. For example, here's how you'd specify with
kubectl editthat you want to edit the autoscaler settings for Istio-Telemetry:
kubectl edit -n istio-system HorizontalPodAutoscalers/istio-telemetry
Resource requests for all deployments. By default requests are not set, however for production use we recommend setting these to appropriate values to ensure nodes have enough resources to support the pods. You should set resource requests for each container in the pod, otherwise CPU on HPAs show
unknownand autoscaling will not work.
kubectl edit -n istio-system Deployments/istio-telemetry
If you're not using autoscaling, you can set the number of replicas for each control plane element (with the exception of Citadel, which is always a singleton) for manual horizontal scaling. For example, here's how you'd specify with
kubectlthat you want two instances of Pilot:
kubectl scale -n istio-system --replicas=2 deployment/istio-pilot
In each case the settings you specify are retained when your installation is upgraded by the add-on.
- Find out how to get started with Istio on GKE in Installing Istio on GKE.