Istio & Gateway API: Master Service Mesh Integration

Gateway API with Istio: Service Mesh Integration

The world of Kubernetes networking is constantly evolving, driven by the need for more flexible, powerful, and standardized traffic management. For years, Ingress has been the de-facto standard for exposing services to the outside world. However, as applications grow in complexity and microservice architectures become ubiquitous, Ingress often falls short, lacking the expressiveness and role-based access control necessary for modern traffic routing. This is where the Kubernetes Gateway API steps in, offering a more robust and extensible alternative.

When you introduce a service mesh like Istio into the equation, the need for a sophisticated ingress solution becomes even more critical. Istio excels at managing internal service-to-service traffic, providing features like mTLS, traffic splitting, and observability. But how do you bridge the gap between the external world and your Istio-powered mesh? Traditionally, Istio’s Ingress Gateway handled this. Now, with the Gateway API, Istio users can leverage a standardized, future-proof interface that integrates seamlessly with Istio’s powerful traffic management capabilities, offering a more unified and consistent approach to managing both North-South and East-West traffic.

This guide will walk you through the process of integrating the Kubernetes Gateway API with Istio, demonstrating how to set up an Istio-managed Gateway and configure advanced traffic routing rules using Gateway API resources like `HTTPRoute`. By the end, you’ll have a clear understanding of how this powerful combination simplifies complex traffic management scenarios, enhances security, and provides a more declarative and consistent networking experience within your Kubernetes clusters. For a broader perspective on migrating from Ingress, check out our Kubernetes Gateway API vs Ingress: The Complete Migration Guide.

# Install Istio with Gateway API CRDs
istioctl install --set profile=default --set components.ingressGateways[0].enabled=false --set components.clusterGateways[0].enabled=true --set components.clusterGateways[0].name=istio-gateway --set values.gateways.istio-ingressgateway.controllerName=istio.io/gateway-controller --set values.pilot.env.PILOT_ENABLE_GATEWAY_API=true -y

# Deploy a Gateway resource
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/gateway-api/http-gateway.yaml

# Deploy a sample application
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/bookinfo-gateway-api.yaml

# Get Gateway address
export GW_ADDR=$(kubectl get gateway istio-gateway -n istio-system -o jsonpath='{.status.addresses[0].value}')
echo "Gateway IP: $GW_ADDR"

# Test traffic routing
curl -s -o /dev/null -w "%{http_code}" "http://$GW_ADDR/productpage"

Prerequisites

Before diving into the integration, ensure you have the following:

• A Kubernetes cluster (version 1.22+ is recommended for Gateway API, though Istio can backport support for older versions).
• kubectl configured to connect to your cluster.
• istioctl (Istio command-line tool) installed. Refer to the official Istio documentation for installation instructions.
• Basic understanding of Kubernetes concepts (Pods, Services, Deployments) and Istio (ServiceEntry, VirtualService, Gateway). Familiarity with the Gateway API concepts (GatewayClass, Gateway, HTTPRoute) will be beneficial.
• Administrative privileges on your Kubernetes cluster to install CRDs and deploy system components.

Step-by-Step Guide

This section will guide you through setting up Istio to work with the Gateway API, deploying a sample application, and configuring traffic routing.

Step 1: Install Istio with Gateway API Support

First, we need to install Istio, ensuring that it’s configured to manage Gateway API resources. This involves installing the necessary Custom Resource Definitions (CRDs) and configuring Istio’s ingress gateway to act as a Gateway API controller.

Istio’s `istio-ingressgateway` component can be configured to act as a controller for Gateway API `Gateway` resources. By explicitly enabling `PILOT_ENABLE_GATEWAY_API` and configuring the `controllerName`, we instruct Istio to take ownership of `Gateway` resources matching that controller. We’ll disable the default `ingressGateways` component and enable `clusterGateways` to use the Gateway API managed gateway.

# Download Istio (if not already done)
curl -L https://istio.io/downloadIstio | sh -
export PATH="$PWD/istio-1.20.0/bin:$PATH" # Adjust version as needed

# Verify istioctl version
istioctl version --remote

# Install Istio with Gateway API CRDs and controller configuration
# This command disables the traditional Istio IngressGateway and enables a Gateway API managed one.
# It also explicitly enables the Gateway API feature flag in Pilot.
istioctl install --set profile=default \
  --set components.ingressGateways[0].enabled=false \
  --set components.clusterGateways[0].enabled=true \
  --set components.clusterGateways[0].name=istio-gateway \
  --set values.gateways.istio-ingressgateway.controllerName=istio.io/gateway-controller \
  --set values.pilot.env.PILOT_ENABLE_GATEWAY_API=true \
  -y

Explanation:

The istioctl install command is the primary way to deploy Istio. Here’s a breakdown of the key flags used:

• --set profile=default: Installs the default Istio configuration profile, suitable for most use cases.
• --set components.ingressGateways[0].enabled=false: This disables the deployment of the traditional Istio Ingress Gateway (the istio-ingressgateway deployment that uses Istio’s own Gateway CRD). We’re opting for the Gateway API’s Gateway resource instead.
• --set components.clusterGateways[0].enabled=true and --set components.clusterGateways[0].name=istio-gateway: These settings enable a new component that will specifically manage Gateway API Gateway resources. We’re naming it istio-gateway.
• --set values.gateways.istio-ingressgateway.controllerName=istio.io/gateway-controller: This is crucial. It tells Istio’s controller which Gateway resources it should manage. Any Gateway resource that specifies gatewayClassName: istio and is managed by a controller named istio.io/gateway-controller will be picked up by this Istio instance.
• --set values.pilot.env.PILOT_ENABLE_GATEWAY_API=true: This explicitly enables the Gateway API feature flag within Istio’s Pilot component, allowing it to process and translate Gateway API resources into Istio’s internal configuration.
• -y: Automatically confirms the installation.

This setup ensures that Istio is ready to consume and manage the new Gateway API resources.

Verify:

Check that Istio components are running and the Gateway API CRDs are installed.

kubectl get po -n istio-system

Expected Output:

NAME                                    READY   STATUS    RESTARTS   AGE
istio-gateway-55f6974768-2z9x2          1/1     Running   0          2m
istiod-7b98946765-m7j4p                 1/1     Running   0          2m
# ... other Istio components ...

You should see `istio-gateway` and `istiod` pods running. Also, verify the Gateway API CRDs:

kubectl get crd | grep gateway

Expected Output:

gateways.gateway.networking.k8s.io                       2023-10-27T12:00:00Z
gatewayclasses.gateway.networking.k8s.io                 2023-10-27T12:00:00Z
httproutes.gateway.networking.k8s.io                     2023-10-27T12:00:00Z
# ... potentially other gateway-related CRDs ...

Step 2: Deploy a Gateway API Gateway

Now that Istio is ready, we’ll define a `Gateway` resource. This resource represents a load balancer or edge router, similar in concept to Istio’s traditional `Gateway` CRD, but using the standardized Gateway API.

The `Gateway` resource specifies the entry points for traffic (ports, hostnames) and references a `GatewayClass`. The `GatewayClass` links the abstract `Gateway` definition to a specific controller implementation, in our case, Istio.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: istio-gateway
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: istio-ingressgateway-certs # Replace with your actual TLS secret name
    allowedRoutes:
      namespaces:
        from: All
EOF

Explanation:

This YAML defines a `Gateway` named `istio-gateway` in the `istio-system` namespace. Key aspects:

• gatewayClassName: istio: This crucial field tells the Gateway API controller that this `Gateway` should be managed by the controller associated with the `istio` `GatewayClass`. Istio automatically creates a `GatewayClass` named `istio` when installed with Gateway API support.
• listeners: Defines the network ports and protocols the gateway will listen on.
  • `http` listener: Listens on port 80 for HTTP traffic. `allowedRoutes.namespaces.from: All` means any `HTTPRoute` in any namespace can attach to this listener.
  • `https` listener: Listens on port 443 for HTTPS traffic. It’s configured for TLS termination using a Kubernetes `Secret`. You would need to replace `istio-ingressgateway-certs` with the name of a Secret containing your TLS certificate and key (e.g., `kubectl create secret tls istio-ingressgateway-certs –key=privkey.pem –cert=fullchain.pem -n istio-system`).

Upon creation, Istio’s controller will reconcile this `Gateway` resource and provision the underlying `istio-ingressgateway` deployment and service, if not already present, or configure the existing one based on the listener definitions. For more details on Gateway API concepts, refer to the official Gateway API documentation.

Verify:

Check the status of the `Gateway` and retrieve its external IP address.

kubectl get gateway -n istio-system

Expected Output:

NAME            CLASS   ADDRESS         PROGRAMMED   AGE
istio-gateway   istio   192.168.1.100   True         1m

The `ADDRESS` field will show the external IP or hostname assigned to your gateway. The `PROGRAMMED` status should be `True` indicating Istio has successfully configured the gateway.

export GW_ADDR=$(kubectl get gateway istio-gateway -n istio-system -o jsonpath='{.status.addresses[0].value}')
echo "Gateway IP: $GW_ADDR"

Step 3: Deploy a Sample Application

To demonstrate traffic routing, we’ll use Istio’s well-known Bookinfo application. This application consists of several microservices, making it ideal for showcasing advanced traffic management.

We’ll deploy the Bookinfo application and then enable Istio’s sidecar injection for the namespace.

# Create a namespace for the bookinfo app
kubectl create ns bookinfo

# Enable Istio sidecar injection for the bookinfo namespace
kubectl label namespace bookinfo istio-injection=enabled --overwrite

# Deploy the Bookinfo application
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo

Explanation:

First, we create a dedicated namespace `bookinfo` for our application. Then, we label this namespace with `istio-injection=enabled`. This label tells the Istio sidecar injector webhook to automatically inject an Envoy proxy sidecar into every new pod deployed in this namespace. The Envoy proxy handles all network traffic to and from the application pods, allowing Istio to enforce policies and collect telemetry. Finally, we deploy the Bookinfo application’s deployments and services into this namespace.

Verify:

Ensure all Bookinfo pods are running and have 2/2 containers (one for the application, one for the Envoy sidecar).

kubectl get po -n bookinfo

Expected Output:

NAME                              READY   STATUS    RESTARTS   AGE
details-v1-79f774bdb9-k8q7h       2/2     Running   0          1m
productpage-v1-6987487856-t54d2   2/2     Running   0          1m
ratings-v1-7f55b9665-wz7x2        2/2     Running   0          1m
reviews-v1-5456456f96-x7y8z       2/2     Running   0          1m
reviews-v2-774775878-l0m1n        2/2     Running   0          1m
reviews-v3-89c89d989-p1q2r        2/2     Running   0          1m

Step 4: Configure Traffic Routing with HTTPRoute

With the `Gateway` deployed and the application running, we can now define how external traffic reaching the `Gateway` should be routed to our services. The Gateway API uses `HTTPRoute` resources (among others like `TCPRoute`, `TLSRoute`) for this purpose.

The `HTTPRoute` resource specifies hostnames, path matchers, and backend services, similar to an Ingress rule or Istio’s `VirtualService`.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo
  namespace: bookinfo
spec:
  parentRefs:
  - name: istio-gateway
    namespace: istio-system
  hostnames:
  - "www.bookinfo.com"
  rules:
  - matches:
    - path:
        type: Prefix
        value: /productpage
    backendRefs:
    - name: productpage
      port: 9080
  - matches:
    - path:
        type: Prefix
        value: /static
    backendRefs:
    - name: productpage
      port: 9080
  - matches:
    - path:
        type: Prefix
        value: /api/v1/products
    backendRefs:
    - name: productpage
      port: 9080
EOF

Explanation:

This `HTTPRoute` named `bookinfo` in the `bookinfo` namespace defines rules for routing traffic. Let’s break it down:

• parentRefs: This links the `HTTPRoute` to our previously created `Gateway`. It specifies that this route applies to the `istio-gateway` in the `istio-system` namespace. This is how Gateway API establishes the relationship between ingress entry points and routing rules.
• hostnames: Defines the hostnames that this route will match. In this example, it’s `www.bookinfo.com`. Traffic arriving at the gateway with this host header will be evaluated against these rules.
• rules: An array of routing rules. Each rule can have `matches` (conditions for routing) and `backendRefs` (where to send the traffic).
  • The first rule matches requests with paths starting with `/productpage` and directs them to the `productpage` service on port `9080`.
  • Similarly, rules are defined for `/static` and `/api/v1/products`, also routing to the `productpage` service.

Istio’s controller will observe this `HTTPRoute` resource, translate it into its internal configuration (e.g., Envoy routes), and apply it to the `istio-gateway` pods. This declarative approach allows for powerful and flexible traffic management. For more complex traffic splitting scenarios, you can define multiple `backendRefs` with `weight` attributes, similar to how Istio Ambient Mesh uses `VirtualService` for traffic management.

Verify:

Check the status of the `HTTPRoute` to ensure it’s been accepted by the gateway.

kubectl get httproute -n bookinfo

Expected Output:

NAME       HOSTNAMES            AGE
bookinfo   ["www.bookinfo.com"]   1m

You can also inspect the full status:

kubectl get httproute bookinfo -n bookinfo -o yaml

Look for conditions under `status.parents` indicating that the route is `Accepted` and `Programmed` by the `istio-gateway`.

Step 5: Access the Application

Now, let’s test if our routing is working by accessing the Bookinfo application through the `istio-gateway`.

# Ensure the Gateway IP is set from Step 2
export GW_ADDR=$(kubectl get gateway istio-gateway -n istio-system -o jsonpath='{.status.addresses[0].value}')
echo "Gateway IP: $GW_ADDR"

# Access the product page using curl
# We need to set the Host header to match the hostname defined in our HTTPRoute
curl -s -H "Host: www.bookinfo.com" "http://$GW_ADDR/productpage" | grep -o "<title>.*</title>"

Explanation:

We use `curl` to send an HTTP request to the `GW_ADDR` (the external IP of our Istio Gateway). Crucially, we include the `-H “Host: www.bookinfo.com”` header. This `Host` header must match the `hostnames` defined in our `HTTPRoute` (`bookinfo`), otherwise, the gateway won’t know which route to apply. If the request is successful, it should return the HTML title of the Bookinfo product page.

Verify:

A successful request should return the product page title.

<title>Simple Bookstore App</title>

If you see this output, congratulations! You have successfully integrated the Kubernetes Gateway API with Istio and routed traffic to your application.

Production Considerations

Deploying Gateway API with Istio in a production environment requires careful planning and adherence to best practices.

1. TLS Management: For production, you must use proper TLS certificates. Consider integrating with cert-manager to automate certificate issuance and renewal from CAs like Let’s Encrypt. The `Gateway` resource supports `Secret` references for certificates, which cert-manager can populate.
2. GatewayClass Configuration: While Istio automatically creates a `GatewayClass` named `istio`, you might want to define your own with specific parameters if you have multiple Istio deployments or custom configurations. This ensures consistency and proper resource isolation.
3. Observability: Leverage Istio’s rich observability features (metrics, logs, traces) to monitor your gateway and routes. Integrate with Prometheus, Grafana, and Jaeger/OpenTelemetry. For advanced eBPF-based observability, consider tools like Hubble, as detailed in our eBPF Observability with Hubble guide.
4. Security Policies: Implement robust network policies to secure communication to and from your gateway. While Istio provides L7 policies, Kubernetes Network Policies offer L3/L4 firewalling, creating a defense-in-depth strategy. Consider tools like Kyverno for policy enforcement, especially for supply chain security, as discussed in Securing Container Supply Chains with Sigstore and Kyverno.
5. High Availability & Scalability: Ensure your `istio-gateway` deployment is configured for high availability (multiple replicas) and auto-scaling based on traffic load. The underlying `istio-ingressgateway` deployment is a standard Kubernetes deployment that can be scaled using Horizontal Pod Autoscalers (HPAs).
6. Traffic Management: Explore advanced Istio traffic management features through Gateway API. This includes weighted routing for canary deployments, traffic mirroring, fault injection, and circuit breaking. These can often be configured directly within `HTTPRoute` or by chaining `HTTPRoute` with Istio `VirtualService` and `DestinationRule` resources for more granular control.
7. Role-Based Access Control (RBAC): The Gateway API’s design emphasizes role separation. Platform operators can manage `GatewayClass` and `Gateway` resources, while application developers manage `HTTPRoute` (or other Route types) in their respective namespaces. Implement strict RBAC policies to enforce this separation of duties.
8. Cost Optimization: Monitor resource usage of your gateway pods and optimize their resource requests and limits. For node autoscaling and cost management, consider solutions like Karpenter to efficiently provision and scale underlying infrastructure for your gateway and application workloads.
9. External DNS Integration: For production, you’ll need to integrate your `Gateway`’s external IP/hostname with your domain’s DNS records. Tools like ExternalDNS can automate this process by watching Kubernetes `Service` or `Gateway` resources and updating DNS providers.
10. GitOps Practices: Manage all your Gateway API and Istio configurations using GitOps. Store your YAML definitions in a Git repository and use tools like Argo CD or Flux CD to automatically deploy and synchronize them with your cluster.

Troubleshooting

Here are some common issues you might encounter and their solutions when integrating Gateway API with Istio.

1. Issue: `Gateway` status shows `PROGRAMMED: False` or `ADDRESS` is pending.
   
   Solution:

   This typically means Istio’s controller hasn’t fully reconciled the Gateway resource or the underlying load balancer is still provisioning.

   # Check Gateway events for errors
   kubectl describe gateway istio-gateway -n istio-system
   
   # Check Istio Gateway controller logs
   kubectl logs -n istio-system -l app=istiod | grep "gateway.networking.k8s.io/v1, Kind=Gateway"
   kubectl logs -n istio-system -l app=istio-gateway
   

   Ensure the `istio-gateway` deployment (the underlying Envoy proxy) is running and healthy. If you’re on a cloud provider, provisioning a LoadBalancer service can take a few minutes. If it persists, verify your Istio installation and the `GatewayClass` configuration.

2. Issue: `HTTPRoute` status shows `Accepted: False` or `Programmed: False`.
   
   Solution:

   This indicates that the `HTTPRoute` isn’t being correctly processed by the Gateway controller.

   # Check HTTPRoute events for errors
   kubectl describe httproute bookinfo -n bookinfo
   
   # Verify parentRef is correct and Gateway exists
   kubectl get gateway istio-gateway -n istio-system
   
   # Check Istio Pilot logs (where HTTPRoute processing happens)
   kubectl logs -n istio-system -l app=istiod | grep "HTTPRoute"
   

   Ensure the `parentRefs` in your `HTTPRoute` correctly point to the `name` and `namespace` of your `Gateway`. Also, verify the `hostnames` and `backendRefs` are correctly defined and that the backend services exist.

3. Issue: `curl` to the gateway returns 404 or connection refused.
   
   Solution:

   # 1. Verify Gateway IP/hostname is correct and reachable
   export GW_ADDR=$(kubectl get gateway istio-gateway -n istio-system -o jsonpath='{.status.addresses[0].value}')
   echo "Gateway IP: $GW_ADDR"
   ping -c 1 $GW_ADDR # If IP, check reachability
   
   # 2. Ensure Host header matches HTTPRoute
   curl -v -H "Host: www.bookinfo.com" "http://$GW_ADDR/productpage"
   
   # 3. Check for Network Policies blocking traffic to the Gateway
   kubectl get networkpolicy -A # Look for policies affecting istio-system or the gateway pod
   

   A 404 often means the request reached the gateway but no `HTTPRoute` matched the `Host` header or path. Double-check your `HTTPRoute` configuration, especially `hostnames` and `matches`. Connection refused usually points to the gateway service not being exposed correctly or a firewall issue.

4. Issue: Application pods are not getting sidecar injected, or traffic is not being routed through Envoy.
   
   Solution:

   # 1. Check namespace label for injection
   kubectl get ns bookinfo --show-labels
   
   # 2. Check pod status (should be 2/2 ready containers)
   kubectl get po -n bookinfo
   
   # 3. If pods are already running, restart them after labeling the namespace
   kubectl rollout restart deploy -n bookinfo
   
   # 4. Check Istio injector webhook logs
   kubectl logs -n istio-system -l app=istiod | grep "sidecar-injector"
   

   Ensure the namespace is labeled with `istio-injection=enabled`. If pods were deployed before the label was applied, you need to restart them (`kubectl rollout restart deployment -n `) for the sidecar to be injected.

5. Issue: Internal service-to-service communication fails after Istio installation.
   
   Solution:

   # 1. Check Istio proxy status in the pod
   kubectl exec -it <pod-name> -n <namespace> -c istio-proxy -- curl localhost:15000/config_dump > config_dump.json
   # Analyze config_dump.json for routes, listeners, and clusters
   
   # 2. Check application logs for connection errors.
   kubectl logs <pod-name> -n <namespace>
   
   # 3. Verify services are correctly defined and discoverable.
   kubectl get svc -n <namespace>
   

   This often points to issues with Istio’s internal routing. Verify that your services are correctly defined and that there are no conflicting `VirtualService` or `DestinationRule` resources if you are using them for East-West traffic management. Ensure `ServiceEntry` resources are correctly defined for external services.

6. Issue: TLS termination is not working on the Gateway.
   
   Solution:

   # 1. Verify the TLS secret exists in the istio-system namespace
   kubectl get secret istio-ingressgateway-certs -n istio-system
   
   # 2. Check the secret content format (should be 'tls.crt' and 'tls.key')
   kubectl get secret istio-ingressgateway-certs -n istio-system -o yaml
   
   # 3. Ensure the Gateway listener's TLS configuration is correct
   kubectl get gateway istio-gateway -n istio-system -o yaml
   

   Ensure the `Secret` referenced in the `Gateway`’s HTTPS listener exists in the `istio-system` namespace and contains valid `tls.crt` and `tls.key` entries. Also, verify that the `tls.mode` is set to `Terminate`.

FAQ Section

1. Q: What is the main difference between Gateway API and Istio’s traditional Gateway/VirtualService?
   
   A: The main difference lies in standardization and role separation. The Gateway API is a vendor-neutral, Kubernetes-native standard for ingress, whereas Istio’s `Gateway` and `VirtualService` are Istio-specific CRDs. Gateway API aims to provide a more expressive and extensible interface, separating concerns between infrastructure providers (managing `GatewayClass` and `Gateway`) and application developers (managing `HTTPRoute`). Istio now acts as a controller for Gateway API resources, translating them into its internal configuration, offering the best of both worlds.
2. Q: Can I use Gateway API alongside Istio’s traditional Gateway and VirtualService?
   
   A: Yes, it’s possible, but generally not recommended for the same traffic paths to avoid confusion and potential conflicts. Istio supports running both simultaneously. However, for a cleaner and more consistent configuration, it’s best to choose one approach for your ingress traffic. If you’re migrating, you can transition gradually.
3. Q: How does Gateway API handle advanced traffic management features like traffic splitting, retries, and fault injection?
   
   A: The Gateway API `HTTPRoute` resource has fields for basic traffic splitting (`backendRefs` with `weight`). For more advanced features like retries, timeouts, fault injection, and more sophisticated traffic shifts, Istio’s integration allows you to combine `HTTPRoute` with Istio’s `DestinationRule` and `VirtualService` (for East-West traffic) or use Istio-specific extensions to `HTTPRoute` if available. The strength of this integration is using a standard ingress API while still leveraging Istio’s powerful mesh capabilities.
4. Q: What are the benefits of using Gateway API with Istio over just Istio’s Ingress Gateway?
   
   A: The primary benefits are:
   • Standardization: Gateway API is a Kubernetes standard, meaning your ingress configuration is more portable across different controllers (e.g., NGINX, HAProxy, AWS ALB, GCP GCLB).
   • Role-Based Access Control (RBAC): Clear separation of concerns between infrastructure operators and application developers, simplifying access management.
   • Extensibility: Designed to be highly extensible, allowing for custom filters and policies at various stages of the request lifecycle.
   • Future-Proofing: As the official successor to Ingress, it’s the future direction for Kubernetes ingress management.

   Istio integration brings its