Upgrade Path for AppScan 360°: Ingress to Gateway API

Overview

The migration from a legacy Kubernetes Ingress setup to a Gateway-based model (e.g., Istio Gateway API) offers improved routing flexibility, native support for multi-cluster/multi-protocol traffic, and superior integration with service mesh features.

This document outlines the recommended strategies for migration based on cluster type, load balancer availability, and operational requirements.

1. Upgrade Strategies

Approach A: Clean Upgrade

  • Scenario: Ingress is no longer required for any workloads.

    Process: 1. Remove the existing Ingress controller.

    2. Deploy the Gateway Controller on default ports (80/443) using a load balancer (MetalLB or SLVLB).

    3. Validate that the service is configured with the correct external IPs.

Approach B: Secondary/Coexistence Approach

  • Scenario: Existing workloads still depend on the legacy Ingress controller.

  • Process:
    1. Retain the Ingress controller.
    2. Deploy Gateway Controller on custom ports to avoid conflicts.
    3. Plan for the eventual removal of Ingress once the migration is validated.

2. Deployment Scenarios (Coexistence Approach)

Scenario 1: Gateway with Ingress as Deployment

  • Context: The cluster currently runs an Ingress controller as a standard deployment.

  • Approach: Deploy the Gateway controller (Istio Gateway API) as a separate deployment using MetalLB to provide external IP pools.

  • Pros: Allows coexistence; simplified routing via MetalLB.

  • Cons: Requires careful port management (avoiding 80/443 conflicts).

Scenario 2: Gateway on K3s with SLVLB (Klipper)

  • Context: K3s environment with Service Load Balancer (Klipper) enabled.

  • Approach: Install Gateway Controller and set the service type to LoadBalancer. SLVLB will automatically assign node IPs.

  • Pros: Minimal configuration; works out-of-the-box for K3s.

  • Cons: IP assignment is dynamic; requires firewall rules for node ports.

3. Custom Port Configuration (Coexistence Mode)

When an existing Ingress controller occupies ports 80 and 443, the Gateway created by ASCP must be configured with custom listener ports.

Configuration via singular-singular.clusterkit.yaml

The Gateway listeners can be defined with custom ports within the YAML configuration.

Configuration via singular-singular.clusterkit.properties

The following properties define the custom listener ports:

  • CK_GATEWAY_TLS_PASSTHROUGH_LISTENER_PORT_NUMBER: Customer-designated K8s TLS passthrough port.

    CK_GATEWAY_HTTPS_LISTENER_PORT_NUMBER: Customer-designated K8s HTTPS port.

    CK_GATEWAY_HTTP_LISTENER_PORT_NUMBER: Customer-designated K8s HTTP port.

Note: Once migration is complete and the legacy Ingress is removed, you can reconfigure the Gateway to use default ports (80/443).

4. Strategy Comparison Matrix

Approach Cluster Type Load Balancer Pros Cons
K3s with SLVLB K3s SLVLB Minimal config; Auto IP assignment Dynamic IPs; Node access required
Coexistence Any Any Zero disruption; Gradual migration Requires custom ports
Clean Approach Any Recommended Simplest architecture; Default ports Requires Ingress removal
Gateway + MetalLB Any MetalLB Controlled IP assignment Requires MetalLB setup

5. Required Gateway Properties

Ensure the following variables are set in your properties file:

CK_GATEWAY_CLASS_NAME='<GATEWAY_CLASS_NAME>'
CK_GATEWAY_PRIVATE_HOST_DOMAIN='<AS360_DOMAIN>'
CK_GATEWAY_PRIVATE_HOST_SUBDOMAIN='<AS360_SUBDOMAIN>'

6. Installation Procedure (Istio Gateway)

Note: These steps have been validated specifically for the Istio Gateway flavor.

Step 1: Install Gateway API CRDs

The CRDs must be installed before installing the Gateway Controller implementation. https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.4.0

GATEWAY_API_VERSION="v1.4.0"

kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/standard-install.yaml
kubectl apply -f 
https://github.com/kubernetes-sigs/gateway-api/releases/download/${G
ATEWAY_API_VERSION}/experimental-install.yaml
Verify installation:

kubectl get crds | grep gateway.networking.k8s.io
Step 2: Add Istio Helm Repository

helm repo add istio 
https://istio-release.storage.googleapis.com/charts || true
helm repo update
Step 3: Install Istio Base (CRDs)

kubectl create namespace istio-system --dry-run=client -o yaml | 
kubectl apply -f -
helm install istio-base istio/base -n istio-system
Verify installation:

helm status istio-base -n istio-system

Step 4: Install Istiod (Control Plane)

Create a file named istiod-values.yaml:

global:
 proxy:
   autoInject: disabled

resources:
 requests:
   cpu: 10m
   memory: 64Mi
 limits:
   cpu: 100m
   memory: 256Mi

autoscaleEnabled: false

env:
 PILOT_ENABLE_ALPHA_GATEWAY_API: "true"

telemetry:
 enabled: false
Install using Helm:


helm install istiod istio/istiod \
 -n istio-system \
 -f istiod-values.yaml
Wait for Readiness:

kubectl rollout status deployment/istiod -n istio-system 
--timeout=120s
Step 5: Final Verification

# Check Istio pods
kubectl get pods -n istio-system

# Verify GatewayClass resource
kubectl get gatewayclass

A successful installation will list the Istio GatewayClass as available.