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:
apiVersion: apps/v1
kind: Deployment
metadata:
name: apple-app-echo
namespace: ingress-nginx-test
spec:
selector:
matchLabels:
app: apple-echo
replicas: 1
template:
metadata:
labels:
app: apple-echo
spec:
containers:
- name: apple-echo
image: svl-artifactory.juniper.net/atom-docker/cn2/http-echo:latest
args:
- "-text=apple-echo"
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:
apiVersion: v1
kind: Service
metadata:
name: envoy
namespace: projectcontour
annotations:
spec:
#externalTrafficPolicy: Local
ports:
- port: 80
name: http
protocol: TCP
nodePort: 30080
targetPort: 8080
- port: 443
name: https
protocol: TCP
targetPort: 8443
nodePort: 30443
selector:
app: envoy
type: NodePort
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 labelapp: 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 SDN (software-defined networking) 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.
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 deploys 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 on 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.