Skip to main content
Star us on GitHub Star

Tunneling Kubernetes Workloads

This guide will help you discover the best strategy and tool for connecting a Kubernetes workload. This overview page links to child pages for each strategy and tool, and a summary of each is provided in the sections below. Click on the chart's outcomes to see the corresponding documentation.

Strategies and Solutions​

In the chart above, there are several strategies and solutions for connecting a Kubernetes workload. The following sections describe each strategy and solution in more detail. These are organized into two main categories: ingress to cluster services, and intercepting pod egress.

Intercepting Pod Egress​

An tunneler can be used to intercept pod egress. One important thing to know is that the tunneler that is used in this way may also be used to "host" services in order to provide ingress to cluster services.

Transparent Proxy Sidecar​

You can deploy a transparent proxy sidecar to intercept pod egress. The sidecar provides a DNS nameserver that is used by the workload application to resolve service addresses. The sidecar container runs ziti tunnel tproxy to create IPTables TPROXY rules in the pod. For more information, see the transparent proxy sidecar quickstart.

TCP Proxy Sidecar​

You can deploy a loopback proxy sidecar for pod egress to services. The sidecar binds services to a local port on the pod's loopback interface, e.g., 127.0.0.1:8443. The workload application must be configured to connect to the local port. This mode of operation has a few differences in comparison to the transparent proxy sidecar quickstart.

  1. The sidecar container runs ziti tunnel proxy instead of ziti tunnel tproxy.
  2. The sidecar container does not need the CAP_NET_ADMIN capability.
  3. The sidecar container does not need a dnsPolicy or explicit nameserver.

TCP Proxy Cluster Service​

The router can be deployed to provide a cluster-wide proxy for services, optionally exposing the services' proxy ports with an Ingress or LoadBalancer. This is accomplished by first creating the router with tunnel mode enabled, then deploying the router Helm chart with input values specifying each service for which the router's tunnel identity is authorized by a Dial Service Policy. For more information, see the router page.

Ingress to Cluster Services​

Any tunneler can be used to "host" a service. This hosting begins a few moments after a service becomes authorized for the identity in use by the SDK. This section is about different ways to deploy a tunneler to provide ingress to cluster services.

Reverse Proxy Router Pod​

The router's built-in tunneler can reverse-proxy cluster services for Ziti clients. This is accomplished by creating the router with tunneler mode enabled, and then installing the router Helm chart with the tunneler mode set to host (the default). For more information, see the router page.

NGINX Proxy Module​

The NGINX Proxy Module can be used to provide ingress to cluster services. The module binds services to an NGINX stream context and forward requests to the configured upstreams. Unlike the rest of these solutions, the NGINX module is not a full tunneler. The main difference for writing configurations for the module is that it will honor the upstreams that are set in the NGINX configuration, ignoring the host.v1 addresses set in the config. For more information, see the NGINX Proxy Module guide.

Reverse Proxy Tunnel Pod​

The ziti-host Helm chart deploys a headless service and can be used to provide ingress cluster services. The pod runs ziti-edge-tunnel run-host to bind services and forwards requests arriving via Ziti to their configured host addresses inside the cluster. For more information, see the ziti-host page.