Ingress Nginx Operator

TOC

Overview

The Ingress Nginx Operator is provided to facilitate advanced management of Ingress-Nginx deployments. This Operator streamlines the deployment, configuration, and maintenance processes of Ingress-Nginx instances. The operational architecture functions as follows: The Ingress-Nginx Operator continuously monitors Custom Resource of type ingressnginxes.ingress-nginx.alauda.io (IngressNginx) and automatically provisions corresponding Ingress-Nginx instances for each defined IngressNginx resource. This architecture enables direct manipulation of IngressNginx custom resources to govern Ingress-Nginx functionality and behavior.

Installation

  1. Navigate to Administrator -> Marketplace -> OperatorHub
  2. Locate the Alauda build of Ingress NGINX Controller and click Install

Configuration Via Web Console

We provide basic configuration options through the user interface, which will generate the corresponding YAML for you. For more complex configurations, you can edit the YAML directly.

After completing the Installation of Ingress Nginx Operator:

  1. Navigate to the All Instances tab
  2. Click Create, then in the displayed dialog box, locate the IngressNginx Instance Type section and click Create
FieldDescriptionYAML Path
NameName of the Ingress Nginx instance.metadata.name
NamespaceNamespace of the Ingress Nginx instance.metadata.namespace
ReplicaThe replica count of the Ingress Nginx deployment.spec.controller.replicaCount
ResourcesThe resource requests and limits of the Ingress Nginx deployment.spec.controller.resources
Service TypeThe service type of the Ingress Nginx.spec.controller.service.type
Ingress ScopeControls which namespaces' Ingress resources are processed.spec.controller.scope.namespaceSelector, refer to ingress-sharding

Configuration Via YAML

By default, the Ingress Nginx Operator deploys Ingress Nginx instances within the same namespace as the corresponding IngressNginx custom resource.

Ingress Sharding

By default, Ingress Nginx processes Ingress resources across all namespaces for ingresses that either explicitly specify its IngressClass name or do not specify any IngressClass. You can use .controller.scope.namespaceSelector to restrict an instance to specific namespaces. For example, the following IngressNginx resource demo-scope only processes ingresses in namespaces labeled cpaas.io/project=demo.

Creating IngressNginx Which Processes Ingress In All NS

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo-all
spec:
  controller:
    nodeSelector:
      kubernetes.io/os: linux
    replicaCount: 1

Creating IngressNginx Which Processes Ingress In Specific NS

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo-scope
spec:
  controller:
    scope:
      namespaceSelector: 'cpaas.io/project=demo'
    nodeSelector:
      kubernetes.io/os: linux
    replicaCount: 1
  1. format like $LABLE_KEY=$LABLE_VALUE

Exposing via LoadBalancer

By default, the Ingress Controller is configured with a ClusterIP service type. To expose the Ingress Controller externally using a LoadBalancer service, apply the following configuration:

NOTE

LoadBalancer Services require an external load balancer integration (cloud provider LB or MetalLB) to provision an external IP.

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo
spec:
  controller:
    service:
      type: LoadBalancer

To specify LoadBalancer VIP when using MetalLB:

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo
spec:
  controller:
    service:
      type: LoadBalancer
      annotations:
        metallb.universe.tf/loadBalancerIPs: '192.168.2.2' # Desired VIP
        metallb.universe.tf/address-pool: 'pool-name' # MetalLB address pool

Advanced Controller Deployment Settings

Configure network mode, replicas, resource limits, and node selection:

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo
spec:
  controller:
    hostNetwork: false
    replicaCount: 1
    nodeSelector:
      kubernetes.io/os: linux
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi

SSL Passthrough

Enable SSL passthrough functionality:

CAUTION

With SSL passthrough, TLS terminates on the backend, so L7 features (e.g., request/response header manipulation, WAF, HTTP-to-HTTPS redirect, some auth flows) will not apply to that traffic at the controller.

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo
spec:
  controller:
    extraArgs:
      enable-ssl-passthrough: ''

IPv4 and IPv6 Dual-Stack Support

apiVersion: ingress-nginx.alauda.io/v1
kind: IngressNginx
metadata:
  name: demo
spec:
  controller:
    service:
      ipFamilyPolicy: PreferDualStack

Additional Resources

The .spec field of the IngressNginx resource directly corresponds to the Helm chart values for Ingress Nginx. For additional configuration options, please refer to the official Ingress NGINX documentation.

Default Value Differences Compared to Official Chart

  1. By default, each IngressNginx instance creates an IngressClass with the name $ns-$name and controllerValue ingress-nginx.cpaas.io/$ns-$name. These values can be customized using the .spec.ingressClassResource.name and .spec.ingressClassResource.controllerValue parameters.
  2. By default, the .spec.controller.service.type is set to ClusterIP.
  3. By default, .spec.controller.watchIngressWithoutClass is set to true, which means the controller will process Ingress resources that do not specify an IngressClass.