Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Kubernetes Ingress Support

SUMMARY Cloud-Native Contrail® Networking supports the Container Network Interface (CNI) for integration with Kubernetes. This topic provides an overview of Kubernetes ingress service implementation in Cloud-Native Contrail Networking. This topic also contains a list of validated Kubernetes ingress controllers and their installation instructions.

Ingress Controller Overview

You must have a Kubernetes ingress controller for an ingress to function properly. An ingress controller receives traffic from outside a Kubernetes cluster and routes and load-balances that traffic to containers within a cluster. Ingress controllers also manage egress traffic between services within a cluster and external services. Controllers automatically route traffic to containers depending on service requirements.

Ingress controllers deploy ingress resources. Ingress resources comprise rules that specify which inbound traffic connections reach which services (pods). Ingress resources, combined with ingress controllers, route Layer 7 traffic to containers in a cluster.

Here's an example of an NGINX ingress resource:

Ingress resources contain spec fields such as type: NodePort and type: LoadBalancer. These service types determine a controller's traffic routing and forwarding behavior. For example, if you enter a NodePort in the type field, the control plane allocates a port from a range (default 30000–32767) of ports to your service.

Consider the following example:

Some highlights from the example above include:

  • selector: The label selector that determines which set of pods this service targets. In this example, this service selects any pod with the label app: envoy.

  • port: The service port (80).

  • targetPort: The actual port used by the application in the container (8080).

  • nodePort: The port on the host of each node in the cluster that your service is exposed to (30080).

Different ingress controllers require different configurations. Review the documentation of your ingress controller for annotation, specification, and configuration information.

Validated Ingress Controllers

Cloud-Native Contrail Networking supports many ingress controllers. We've validated the following three popular third-party controllers for use with Cloud-Native Contrail Networking:

NGINX Ingress Controller

NGINX is an open-source HTTP server that also functions as a reverse proxy, load balancer, and IMAP or POP3 proxy server. The NGINX ingress controller is a Kubernetes controller that deploys an NGINX configuration using a ConfigMap resource. Other than endpoint-only changes, you must reload NGINX after any change to the configuration file occurs. This reload mechanism is powered by a lua-nginx-module. NGINX requires Kubernetes v1.22 or later.

We support the NGINX ingress controller in environments using Cloud-Native Contrail Networking as the software-defined networking (SND) solution starting in Contrail Networking Release 21.4.

See the NGINX Ingress Controller installation guide for installation instructions. This guide contains instructions for installing NGINX using several different methods (Docker, minikube, Helm).

HAProxy Ingress Controller

The HAProxy ingress controller provides TCP and HTTP routing and high availability (HA) load balancing. HAProxy offers features such as Runtime API, Data Plane API, and hitless reloads. These features excel in dynamic, high-traffic environments where users constantly deploy, configure, and terminate pods, services, and microservices. The HAProxy ingress controller v0.13 requires Kubernetes v1.19 or later.

Note: Starting in Contrail Networking Release 21.4, we support the HAProxy ingress controller in environments using Cloud-Native Contrail Networking as the SDN solution.

See the HAProxy Getting Started guide for installation instructions.


You must use Helm to install and to configure the HAProxy ingress controller. See Installing Helm for more information.

Contour Ingress Controller

Contour ingress controller deploys an Envoy proxy as a reverse proxy and load balancer. Envoy is a Layer 7 bus network for proxy services and communication. Envoy is deployed as a self-contained proxy instead of a library. As a result, any application can access Envoy’s load-balancing features. This implementation is suitable for a distributed system such as a Kubernetes cluster. Other benefits of Contour include:

  • Easy installation and integration of Envoy.

  • Stable ingress support in multi-team Kubernetes clusters.

  • Dynamic updates and ingress configuration without interruptions or dropped connections.

Contour requires Kubernetes 1.16 or later. You must enable role-based access control (RBAC) in your cluster for Contour to function properly.


Starting in Contrail Networking Release 21.4, we support the Contour ingress controller in environments using Cloud-Native Contrail Networking as the SDN solution.

See the Getting Started guide for instructions about how to install the Contour ingress controller. This guide contains instructions about how to install and configure Contour with either kind or Docker. Install Contour after installing kind or Docker to run your ingress controller.