Service Mesh (Beta)

This topic describes service mesh for Cloud Foundry.

To deploy service mesh, see Deploying Service Mesh (Beta).

Overview

Cloud Foundry includes an optional, beta routing plane that uses a service mesh. The service mesh provides traffic management and security for microservices. For more information, see What is a service mesh? in the Istio documentation.

The service mesh in Cloud Foundry uses Istio Pilot and Envoy. The Cloud Foundry istio-release packages these components into a BOSH release. For more information, see the following:

Service mesh is deployed with an additional router and runs as a parallel routing plane as illustrated in the following diagram:

A load balancer receives requests at *.YOUR-APPS-DOMAIN and forwards them to the Gorouter. The Gorouter then forwards them to an app. A separate load balancer receives requests at *.mesh.YOUR-APPS-DOMAIN and forwards them to the istio-router. The istio-router then forwards them to an app

Features

This section describes the features provided by the service mesh for Cloud Foundry.

Weighted Routing

The service mesh enables configuring weighted routing for ingress routes. For more information, see Using Weighted Routing (Beta).

Container-to-Container Networking

The service mesh supports container-to-container networking. With the service mesh, traffic between two apps passes through the Envoy sidecar of the source app. Without the service mesh, container-to-container networking does not use the sidecar. See the following diagram for an illustration:

An app using the internal service mesh domain will communicate through its sidecar proxy to reach the destination app.

Container-to-container networking provides load balancing, retries, and timeouts.

See the following table for details:

Feature Description Default
Load Balancing The sidecar uses the load balancing policy to determine which app instance to send traffic to. Evenly distributed routing between app instances mapped to one service mesh internal route.
Retries The sidecar automatically attempts to retry requests upon certain responses. 3 retries on 5xx status code responses.
Timeouts The sidecar automatically terminates connections if there are no responses in a specified amount of time. 15 second timeout.

Limitations

Consider the following when deploying service mesh:

  • The Istio Router does not have feature parity with the existing routing plane in Cloud Foundry.
  • Service mesh features do not work when strict (mTLS) route integrity is also enabled.
  • The Istio Router is for deployments with fewer than 20,000 ingress routes. At greater scale, it may impact core platform functions.
  • The control plane is not HA and registration of new routes may be delayed during upgrade.
  • Mapping a service mesh external or internal route can take up to 1 minute to take effect.
  • The service mesh container-to-container networking data plane does not support UDP or ICMP traffic.
  • The service mesh container-to-container networking data plane can only support up to 300 internal routes for the entire foundation.
  • The service mesh container-to-container networking data plane is only supported on Linux Diego cells.
  • Mapping a service mesh internal route can take up to 1 minute to take effect.
  • The domains for service mesh external routes must be provided at deploy time on the cloud_controller_ng job of the copilot.temporary_istio_domains property.

Component VMs

The following table describes each component VM deployed as part of service mesh in Cloud Foundry, along with their function.

VM Processes Function
istio-router envoy A reverse proxy to forward HTTP/HTTPS requests external to the platform to applications on the platform.
istio-control copilot, pilot-discovery Propagates Cloud Foundry external routes to all service mesh routers.
route-syncer cc-route-syncer Syncs routes created through the Cloud Controller API to the service mesh control plane.
Create a pull request or raise an issue on the source for this page in GitHub