Working with Istio
Istio is a service mesh offering that modifies a cluster to provide, among other things, traffic and network management.
External Networking Requirements
Speedscale pods in the the
speedscale namespace, as well as the
responder pods that are
deployed during traffic replays require external internet access. If your istio installation is configured
with an outbound traffic policy of
REGISTRY_ONLY rather than
ALLOW_ANY, meaning that only whitelisted
services can be accessed from within the cluster (see
you will to configure ServiceEntry
resources that allow the following
These hosts are subject to change and security via TLS is recommended as opposed to IP whitelisting. If you require a list of IPs, they can be programmatically accessed as shown here for AWS and here for GCR.
- name: https
Speedscale Sidecar Configuration
Istio makes use of a proxy known as Envoy, which it adds as a sidecar to
workloads that reside within the mesh. Both the Istio and Speedscale sidecars act as transparent proxies: each
iptables routing rules in order to intercept both ingress and egress traffic. Unfortunately,
they cannot coexist when operating in this mode since both are attempting to intercept and manage workload
Istio is supported by Speedscale despite this conflict, but requires a few extra steps.
Within an Istio mesh, the Speedscale sidecar must operate as a non-transparent proxy; a reverse proxy for inbound traffic and a forward proxy for outbound traffic. This requires two things:
- Envoy must be configured to send ingress traffic to the Speedscale reverse proxy, which is done automatically by the Speedscale Operator via an Istio Sidecar resource.
- Your application must be configured to use an outbound proxy
Add Workload Annotations
Begin by adding the following annotations to your Kubernetes workload along with any other sidecar annotations:
proxy-protocol annotation shown above will operate the outbound, forward proxy as an
HTTP proxy. If your application needs so use a SOCKS4 or SOCKS5 proxy, use
proxy modes for more information.
Also, add annotations to inform the Speedscale sidecar on what host and port your application container is listening. For example, if your application listens to localhost port 8080:
Configure Outbound Proxy Settings
In many instances, configuring your application to use an HTTP or SOCKS proxy for outbound traffic
can be done simply by setting environment variables. Typically these environment variables are
HTTP_PROXY for unencrypted HTTP requests and
HTTPS_PROXY for TLS HTTP requests. See the
Configuring Your Application Proxy Server
documentation more detail and some language specific examples.
Modify your workload to add the necessary proxy configuration to your application container's environment variables. For example:
- name: HTTP_PROXY
- name: HTTPS_PROXY
Note, if you configured the Speedscale proxy to use SOCKS4/5 instead of HTTP for outbound traffic,
change the URL above to
Configure Outbound TLS Support
Outbound TLS support for the Speedscale sidecar can be enabled with the annotation
sidecar.speedscale.com/tls-out: "true". You may be required to perform additional steps if your
application and not Envoy is originating TLS requests. See
Trusting TLS Certificates for more information.
Allow Egress Speedscale Traffic (Optional)
If your Istio installation and sidecar control which subset of egress traffic is allowable, you may
need to add the
speedscale namespace to the sidecar's egress configuration. This step is not
necessary if you do not have custom sidecar configuration. Here is an example from the Istio
Ensure VirtualService Contains Host (Optional)
If your service is accessible both outside and inside the cluster, make sure the Istio
VirtualService contains the same host. See the Istio
documentation for more
Get In Touch
Istio allows for numerous different networking configuration options that can become difficult to navigate. Please be sure to consult the Istio documentation or reach out to Speedscale directly for more information or assistance.