Skip to main content

Using Istio

If your app is running in an Istio mesh, you can turn on sandbox routing using Istio by setting the istio.enabled helm value to true during the installation of the operator. This will cause the Signadot Operator to manage routes in the Istio VirtualService for each service that is opted into Signadot.

If you don't already have a VirtualService defined, you just need to create a basic one with a default route. For example, here is a basic VirtualService for a Service called my-svc in namespace ns-1:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-svc
  namespace: ns-1
spec:
  hosts:
  - my-svc.ns-1.svc.cluster.local
  http:
  - name: default
    route:
    - destination:
        host: my-svc.ns-1.svc.cluster.local

Signadot will then add and remove routes in the VirtualService as needed to configure sandbox routing.

Considerations​

Matched VirtualServices​

Starting with Operator v0.18.0, istio routing was changed to better accomodate various scenarios. Matching of VirtualServices is done based on the route.destination.host, which allows preserving path rewrites and the HTTPRoute conditions under which routing occurs.

Previously, VirtualService host was used to determine what VirtualServices to modify for Sandbox routing. If there are any matched destinations within a given HTTPRoute, we route all requests matching this route and the sandbox routing key headers to the sandbox.

While this change should bring about improved behavior for most and should continue routing most traffic as before for existing installations, one can revert the behavior to the now deprecated host-based matching by setting istio.enableDeprecatedHostRouting in helm values when installing / upgrading the operator.

CI/CD​

When Istio VirtualServices are managed by some CI/CD tool such as Argo or FluxCD, some care is required to ensure that those systems accept the changes that Signadot applies to VirtualServices. To accomodate this, Signadot's controllers maintain the following contract with VirtualServices:

  1. The name of any HTTPRoute added by Signadot in a VirtualService will have the prefix signadot-operator-.
  2. If the VirtualService contains the annotation istio.signadot.com/ignore: "true", then Signadot will not manipulate that VirtualService (>=v0.14.0).
  3. The helm values istio.additionalLabels and istio.additionalAnnotations will be added to any VirtualService which contains modifications generated by Signadot 1 (>=v0.14.0).

Istio Gateways​

When a Istio VirtualServices that matches a Sandboxed workload has a non-empty gateway in its spec that does not include mesh, the routing associated with that VirtualService will only be effective when serving ingress traffic and will not work for intra-cluster traffic. As a result, when a sandbox refers to such a VirtualService, the status of the sandbox will reflect that the routing is not Ready 2. Checking Gateways was first introduced in v0.14.0.

For more information on VirtualServices gateway field, see the Istio docs.

  1. However, if istio.additionalAnnotations contains istio.signadot.com/ignore, then that particular annotation key is not added. This prevents looping between conditions 2 and 3 of the contract.↩
  2. There is one exception to this, which is that the routing may be considered ready if it is setup with the Signadot sidecar for the relevant workload.↩