Application deployment and application-level traffic balancing in Deckhouse Kubernetes Platform (DKP) can be performed using the following tools:

Comparison of ALB options

The following sections describe each ALB option and typical scenarios for using it.

Ingress NGINX

ALB based on the Ingress NGINX Controller uses the nginx web server and is implemented by the ingress-nginx module. This option is suitable for:

  • Basic traffic routing based on domains or URLs.
  • Using SSL/TLS to secure traffic.

Kubernetes Gateway API

ALB is implemented using the Kubernetes Gateway API via the alb module. Gateways run on Envoy Proxy. Reception and routing are described using standard API objects (Gateway, ListenerSet, HTTPRoute, and, if necessary, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy). The controller deploys the ingress infrastructure and validates the configuration to prevent conflicting handlers.

The Gateway API model separates responsibilities between the cluster administrator (ClusterALBInstance), the namespace administrator (ALBInstance and ListenerSet — hostname, TLS, ports), and application developers (HTTPRoute and other route objects).

Use this option for:

  • Publishing applications using the Gateway API model instead of the classic Ingress.
  • A cluster-wide entry point or a separate gateway for an application or team within your namespace.
  • HTTP/HTTPS, gRPC, TCP, UDP, and TLS termination or passthrough.
  • Per-route WAF or an Istio sidecar on the gateway proxy.
  • GeoIP and OpenTelemetry on the gateway (configured by an administrator — “Using GeoIP and GeoLite2” and “Configuring OpenTelemetry tracing”).
  • Route parameters not included in the specification, via HTTPRoute annotations.

For a comparison with ingress-nginx and terminology notes, read “Comparison of the ingress-nginx and alb modules”.

Istio

An ALB based on the istio module supports traffic management in a service mesh. Use an Istio-based ALB for:

  • Routing for canary deployment and similar scenarios.
  • Traffic distribution between application versions and microservices.
  • Mutual TLS (mTLS) for encrypting traffic between Pods.
  • Request tracing.

How to tell what is available in the cluster

Before publishing an application, check which ALB mechanisms are enabled and configured:

  1. Verify that the required module is enabled — the STATE column should show Enabled:

    d8 k get moduleconfig ingress-nginx alb istio

  2. For Ingress NGINX — list IngressNginxController resources and note the IngressClass name:

    d8 k get ingressnginxcontrollers
d8 k get ingressclass

  3. For Gateway API — verify that ClusterALBInstance or ALBInstance exists and is in the Ready state, then find the managed Gateway and ListenerSet objects:

    d8 k get clusteralbinstances,albinstances --all-namespaces
d8 k get gateway,listenerset --all-namespaces

  4. For Istio — check IngressIstioController and the ingress gateway class label provided by the cluster administrator:

    d8 k get ingressistiocontrollers

Ask the cluster administrator for the IngressClass, Gateway name and namespace, or Istio ingress class to use in application manifests.

Next steps

Once the administrator has configured the infrastructure, you can publish the application:

Additional resources