Istio¶

Learn how and why deployKF uses Istio. Learn how to integrate your existing Istio with deployKF and Kubeflow.

What is Istio?¶

Istio is a service mesh for Kubernetes which is based around the Envoy proxy. A service mesh is a dedicated infrastructure layer for managing service-to-service network communication.

Istio changes Kubernetes Pod definitions (dynamically at runtime) so they have a sidecar container (Envoy proxy) which is configured to intercept all network traffic to and from the Pod. Together, these sidecars form a mesh network that can implement advanced networking features like Traffic Management, Security, and Observability with minimal changes to the application code.

How is Istio configured?¶

The Istio mesh is configured declaratively using Kubernetes Custom Resources (CRDs), so you don't need to configure the Envoy proxies directly. Some of the most important Istio CRDs are: Gateway, VirtualService, DestinationRule, ServiceEntry, PeerAuthentication, AuthorizationPolicy and EnvoyFilter.

How can external traffic access the mesh?¶

Mutual TLS¶

The Envoy sidecar uses Mutual TLS (mTLS) to verify if network traffic destined for the Pod is coming from within the mesh. Based on the PeerAuthentication policy for the Pod, the Envoy sidecar will either allow or deny external traffic (not from within the mesh).

Gateways¶

To expose services in the mesh to external traffic (e.g. from the internet), Istio provides the concept of a "Gateway", which sits at the edge of the mesh and can route external traffic to virtual services defined in the mesh.

The idea of "Gateways" is a common source of confusion for new Istio users because it refers to two different things.

Here are examples of the two different types of "Gateway" in Istio:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-gateway-deployment
  namespace: gateway-namespace
spec:
  selector:
    matchLabels:
      istio: my-gateway-deployment
  template:
    metadata:
      annotations:
        ## this tells istio to inject using the "gateway" template,
        ## rather than the "sidecar" template (which is the default)
        inject.istio.io/templates: "gateway"
      labels:
        ## this ensures that the istio-proxy container is injected
        sidecar.istio.io/inject: "true"

        ## the pod label (same as any normal kubernetes deployment)
        ## but which is also used by Gateway resources to select these pods
        istio: my-gateway-deployment
    spec:
      ## allow binding to all ports (such as 80 and 443)
      securityContext:
        sysctls:
          - name: net.ipv4.ip_unprivileged_port_start
            value: "0"
      containers:
        - name: istio-proxy

          ## the image is automatically replaced by istio
          image: auto

          ## drop all privileges, allowing running as non-root
          securityContext:
            capabilities:
              drop:
                - ALL
            runAsUser: 1337
            runAsGroup: 1337

apiVersion: v1
kind: Service
metadata:
  name: my-gateway-service
  namespace: gateway-namespace
spec:
  type: LoadBalancer
  selector:
    istio: my-gateway-deployment
  ports:
    - port: 80
      name: http
    - port: 443
      name: https

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-namespace
spec:
  ## a selector for Pod labels, which selects the "Gateway Deployment"
  selector:
    istio: my-gateway-deployment
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*"
      tls:
        mode: SIMPLE
        ## the name of the Kubernetes Secret with a TLS certificate
        credentialName: my-gateway-certificate

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-virtual-service
  ## virtual services can be in any namespace, not only the same as the gateway
  namespace: my-service-namespace
spec:
  hosts:
    ## you could replace this with a specific hostname if you want
    ## to do Host-based routing, so multiple services can share the same gateway/port
    - "*"
  gateways:
    ## this selects the gateway defined above
    - some-namespace/my-gateway
  http:
    - route:
        ## this assumes there is a `Service` named `my-service` in `my-service-namespace`
        - destination:
            host: my-service.my-service-namespace.svc.cluster.local
            port:
              number: 80

How does deployKF use Istio?¶

deployKF uses Istio as a service mesh to provide advanced networking features.

Here are some of the ways deployKF itself uses Istio:

Additionally, some tools in deployKF make direct use of Istio:

Can I use my existing Istio?¶

Yes.

By default, deployKF will install Istio and create an ingress gateway deployment. However, you may use your existing Istio installation and/or gateway deployment instead.

As the gateway deployment is separate from Istio itself, there are 3 common combinations of who manages what:

Use an existing istio installation¶

If you already have an Istio installation, you may use it instead of the deployKF-managed one by following these steps. See the version matrix for which versions of Istio are supported by deployKF.

deploykf_core:
  deploykf_istio_gateway:
    charts:
      istioGateway:
        name: gateway
        version: 1.19.6
        repository: https://istio-release.storage.googleapis.com/charts

deploykf_dependencies:
  istio:
    enabled: false

meshConfig:
  defaultConfig:
    holdApplicationUntilProxyStarts: true
    proxyMetadata:
      ISTIO_META_DNS_AUTO_ALLOCATE: "true"
      ISTIO_META_DNS_CAPTURE: "true"

sidecarInjectorWebhook:
  enableNamespacesByDefault: false

Use an existing gateway deployment¶

If you have an existing Istio gateway deployment, you can use it instead of the deployKF-managed one. You may do this even when using the deployKF-managed Istio installation.

deploykf_core:
  deploykf_istio_gateway:

    ## disable the embedded gateway deployment
    charts:
      istioGateway:
        enabled: false

deploykf_core:
  deploykf_istio_gateway:

    ## the namespace where your gateway deployment is running
    namespace: my-gateway-namespace

    gateway:
      ## the label selector for your gateway deployment pods
      selectorLabels:
        app: my-gateway-deployment
        istio: my-gateway-deployment

      ## the ports on your gateway deployment which deployKF should use
      ##  - the "internal" ports which deployKF will use on your gateway deployment
      ##  - they must be different from any existing services on this gateway deployment
      ##  - they may be different to the user-facing ports, as users might connect
      ##    to the gateway through a Service or Ingress (see `gatewayService.ports`)
      ports:
        http: 80
        https: 443

    gatewayDeployment:
      serviceAccount:
        ## the name of the SERVICE ACCOUNT used by the gateway deployment pods
        ##  - deployKF needs to know this so it can trust traffic from the gateway
        ##    check the `serviceAccountName` field in your gateway Pods
        name: my-gateway-service-account

    #gatewayService:
    #
    #  ## the ports which clients are actually using to connect to the gateway
    #  ##  - the "public" ports which clients are expected to connect to
    #  ##  - they can be different to the "internal" ports defined in `gateway.ports`
    #  ##  - these values affect the ports presented in user-facing HTTP links
    #  ##  - if unset, they default to the corresponding value of `gateway.ports`
    #  ports:
    #    http: 80
    #    https: 443

deploykf_core:
  deploykf_istio_gateway:

    gateway:
      tls:
        matchSNI: false

deploykf_core:
  deploykf_istio_gateway:

    ## the ports on your gateway deployment which deployKF should use
    gateway:
      ports:
        http: 18080
        https: 18443

    ## the ports which clients are actually using to connect to the gateway
    gatewayService:
      ports:
        http: 80
        https: 443

Use custom gateway resources¶

You are NOT able to use your own Gateway and VirtualService resources for deployKF.

While you may attach deployKF to an existing Gateway Deployment (Pods + Service), ALL virtual Gateway and VirtualService resources are managed by deployKF, this is a result of how deployKF implements features like authentication.

For reference, here are some gateway resources that deployKF creates: