Docs

Volcengine Kubernetes Engine

Nginx Ingress

Deploying multiple NGINX Ingress controllers

This topic describes how to deploy multiple independent NGINX Ingress controllers in a Volcengine Kubernetes Engine (VKE) cluster to provide external access to different services.

Background

VKE supports deploying multiple independent NGINX Ingress controllers within a cluster. Each controller operates independently so that you can expose different services externally based on your actual business needs or scenarios. For example:

In scenarios where multiple applications share a cluster, you can configure independent NGINX Ingress controllers for each application to ensure that each application has specific rules applied.

In scenarios where public network and private network services are separated, you can deploy two independent NGINX Ingress controllers. Each controller is bound to a Classic Load Balancer (CLB) instance of a different network type. This solution allows some services in the cluster to be accessible over the public network, while others provide private network access.

Procedure

Step 1: deploy NGINX Ingress controllers

VKE allows you to easily deploy an NGINX Ingress controller by using the application template ingress-nginx.

In the left navigation bar, select Application center > Application template.

On the Application template page, find the ingress-nginx application template, hover over the application template area, and then click Deploy.

On the Deploy application page, configure the parameters.

Parameter	Description
Orchestration template
Application templates	Select an application and its chart version.
Parameter configuration	Select a configuration method for the application. The configuration method varies based on the values.yaml file of each application template. For detailed descriptions, see the annotations in the values.yaml file. Click icon to edit the values.yaml file. After you edit the file, click Confirm. tip For descriptions of the parameters in the values.yaml file, see Parameters for NGINX Ingress controllers.
Name	Specify the name of the application. The name must be unique within the same namespace.
Deployment environment
Cluster type	Select the type of cluster where the application needs to be deployed. Managed version and Registered cluster are supported.
cluster	Select the project where the application needs to be deployed and the target cluster. By default, the default project is selected. For more details, see Project management.
Namespace	Select a namespace for the target cluster.

Click Confirm to start deployment.

After the application is deployed, it can be found on the Helm page. Select the target project, cluster, and namespace, and click the name of the deployed nginx-ingress application to go to the details page. On the details page, view the basic information about the application, workload, service, and other resources.

warning

If the workloads and services associated with a deployed nginx-ingress application are deleted but the Webhook remains, it will impact the creation of Ingress routing rules in the cluster. For details, see FAQ.

Step 2: deploy applications and services

After you deploy a separate NGINX Ingress controller, you can use the controller to expose services. For demonstration, this section shows the steps to expose an NGINX backend application and service through a separate NGINX Ingress controller and verify the result.

You deploy an application and service by using YAML files. Here is an example file named service-demo.yaml:

Create the following YAML files to deploy an NGINX application and service in the cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx # The application name.
namespace: doc-ns
spec:
replicas: 1 # The number of application replicas.
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx # The container name.
image: nginx:latest # The address and version of the container image.
ports:
- containerPort: 80 # Exposed container port number
---
apiVersion: v1
kind: Service
metadata:
name: service-demo # The name of the service.
namespace: doc-ns
spec:
selector:
app: nginx # The selector for binding the service to the pod.
ports:
- name: rule
protocol: TCP
port: 80
targetPort: 80
type: NodePort

Run the following command to deploy the application and service.

kubectl apply -f service-demo.yaml

Step 3: configure an NGINX Ingress

Configure an Ingress to expose the service externally. The spec.ingressClassName field in the file below defines a custom name for the NGINX Ingress controller. The following ingress-demo.yaml file demonstrates how to configure an Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-demo # The name of the Ingress.
namespace: doc-ns # The namespace where the Ingress is located.
spec:
ingressClassName: user-ingress-nginx # The name of the custom NGINX Ingress controller.
rules:
- host: example.com # The domain name for external access.
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: service-demo # The name of the service that the Ingress connects to.
port:
number: 80 # The port number for the Ingress to connect to the service.

tip

The naming format for custom NGINX Ingress controllers is <name>-nginx. For example, the custom name in this example is user-ingress, so the corresponding custom NGINX Ingress controller is user-ingress-nginx.

Execute the following command to create an application and a service.

kubectl apply -f ingress-demo.yaml

Validating results

After the deployment is complete, you can query the IP addresses of the default and custom NGINX Ingress controllers.

To query the IP address of the default NGINX Ingress controller, run the following command:

kubectl -n kube-system get svc

Expected output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

ingress-nginx-controller LoadBalancer 10.xxx.xxx.221 180.xxx.xxx.114 80:30234/TCP,443:30644/TCP 1d

To query the IP address of the custom NGINX Ingress controller, run the following command: You can specify the namespace where the custom NGINX Ingress controller resides by using -n doc-ns.

kubectl -n doc-ns get svc

Expected output:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
user-ingress-ingress-nginx-controller LoadBalancer 10.xxx.xxx.52 180.xxx.xxx.55 80:32697/TCP,443:31180/TCP 5m51s

Run the following command to query the Ingress configuration. You can see that the IP address of the Ingress is the same as the IP address of the custom NGINX Ingress controller.

kubectl -n doc-ns get ingress

Expected output:

NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-demo user-ingress-nginx example.com 180.xxx.xxx.55 80 56s

Access the application using the default NGINX Ingress controller of the cluster and the custom NGINX Ingress controller, respectively.

Using the default NGINX Ingress controller: The expected output is 404, which means that the backend service cannot be accessed.

curl -H "Host: example.com" http://180.xxx.xxx.114

Using the custom NGINX Ingress controller:

curl -H "Host: example.com" http://180.xxx.xxx.55

Expected output:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

The test shows that different NGINX Ingress controllers in a cluster separately expose services. You can configure independent NGINX Ingress controllers for different applications to implement separation of routing rules as well as publicly and privately accessible applications.

Monitoring and maintenance

After you deploy the NGINX Ingress controller in the cluster, you can use the observability capabilities to monitor and maintain NGINX Ingress controller instances. For details, see Best practices for observability of custom NGINX Ingress controllers.

References

NGINX Ingress controller parameters

The following table describes fields in userConfig.

Parameter	default value	Description
networkModel	The same as the network model of the cluster	The Container Network Interface (CNI) of the cluster. Valid values: vpc-cni: the VPC-CNI network model. flannel: the Flannel network model.
ResourceNamePreEnable	true	Whether to automatically add a prefix to NGINX Ingress resource names. Valid values: true: automatically add a prefix. During resource creation, the system automatically adds the .Release.Name prefix for NGINX Ingress resources. This ensures that NGINX Ingress resource names are unique and conflict-free in the cluster. false: does not automatically add a prefix. This setting is recommended for scenarios where resource identification is performed based on resource names to automate subsequent operations. In this case, if you deploy multiple NGINX Ingress instances in the cluster, you need to manually ensure that the following resource names are unique: .Values.controller.electionID .Values.controller.ingressClassResource.name .Values.controller.ingressClassResource.controllerValue .Values.controller.ingressClass
deployNodeType	Node	The type of the node on which the NGINX Ingress is deployed. Valid values: Node: an Elastic Compute Service (ECS) node. VirtualNode: a Volcengine Container Instance (VCI) node.
Public network configuration
PublicNetwork.Isp	"BGP"	The line type of the elastic IP (EIP) address bound to the LoadBalancer instance. The available types include BGP, SingleLine_BGP, Static_BGP, Fusion_BGP, ChinaMobile, ChinaTelecom, ChinaUnicom, ChinaMobile_Value, ChinaUnicom_Value, and ChinaTelecom_Value. For details, see EIP documentation. warning Except for BGP, all the line types are beta features of EIP products. To apply for use of these features, contact your account manager. If the LoadBalancer instance uses a private network, leave this parameter empty and configure the PrivateNetwork.SubnetId parameter.
PublicNetwork.BandWidth	10	The upper limit on the bandwidth (measured in Mbit/s) of the EIP bound to the LoadBalancer instance. In case of PublicNetwork.BillingType=2, the value ranges from 1 to 500 and defaults to 10. In case of PublicNetwork.BillingType=3, the value ranges from 1 to 200 and defaults to 10.
PublicNetwork.IpFamily	"ipv4"	IP version of the LoadBalancer instance. Currently only ipv4 is supported.
PublicNetwork.BillingType	3	The billing type of the EIP bound to the LoadBalancer instance. Valid values: 1: subscription. 2: Pay-as-you-go - subscription-based billing with tiered bandwidth. It charges based on a time period with a specified maximum bandwidth. 3: Pay-as-you-go - usage-based billing. It charges based on the actual outbound Internet traffic, regardless of the duration.
PublicNetwork.SubnetId	No	(Optional) The subnet to which the LoadBalancer instance belongs. A subnet provides a private network IP address for LoadBalancer deployment in a private network.
PublicNetwork.BandwidthPackageId	No	(Optional) The ID of the shared bandwidth plan for the EIP bound to the LoadBalancer instance. tip A shared bandwidth package is a reusable cloud resource for sharing bandwidth. Use one package for multiple public IPs in the same region or IPv6 Internet bandwidth billing to cut your Internet access costs. For details, see What is a shared bandwidth package?
PublicNetwork.MasterZoneID	No	Master availability zone ID of the LoadBalancer instance. The value cannot be the same as the value of the SlaveZoneID parameter. If this parameter is missing or left empty, the availability zone where the subnet is allocated will be assigned as the master availability zone by default. tip For the availability zones supported by LoadBalancer in each region and their IDs, see Regions and Availability Zones.
PublicNetwork.SlaveZoneID	No	Slave availability zone ID of the LoadBalancer instance. The value cannot be the same as the value of the MasterZoneID parameter. If you configure this parameter, you must also configure the MasterZoneID parameter. Otherwise, an error will occur. If you remove this parameter or leave it empty, the following logic will be applied: For a specified region in which there is only a single availability zone, a CLB instance with a single availability zone will be created. For a specified region in which there is only a single availability zone, a CLB instance with availability zones randomly selected from the region will be created by default.
PublicNetwork.ModifyProtection	No	Deletion protection for the LoadBalancer instance. Valid values: NonProtection: It disables modification protection to allow instances to be altered or removed via the console page. ConsoleProtection: It enables modification protection to prevent instances from being altered or removed via the console page. If this parameter is not configured or is left empty, the instance is not protected against modification or deletion operations performed in the console.
PublicNetwork.LoadBalancerBillingType	2	The billing type of the LoadBalancer instance. Valid values: 2: pay-as-you-go - specification-based billing. Select an instance specification and pay based on your actual usage duration. 3: Pay-as-you-go - usage-based billing. No need to specify the instance specification and pay for it according to the actual resource consumed by the instance. warning Pay-as-you-go - usage-based billing is a beta feature of the LoadBalancer product. To apply for this billing model, please contact your customer manager. When the billing model for LoadBalancer is Pay-as-you-go - usage-based billing, you do not need to configure LoadBalancerSpec.
PublicNetwork.LoadBalancerSpec	"small_1"	Instance specification of the LoadBalancer. Available types: small_1: small I small_2: small II medium_1: medium I medium_2: medium II large_1: large I large_2: large II warning For details about specifications and types of LoadBalancer instances, seeProduct types and specifications. The LoadBalancerBillingType parameter set to 3 indicates that the LoadBalancer instance applies the pay-as-you-go - usage-based billing type. This parameter is not configurable.
PublicNetwork.SyncField	No	Whether to detect LoadBalancerSpec field changes and update the Loadbalancer instance accordingly during a values.yaml update. Valid values: spec: detects changes to the LoadBalancerSpec field and updates the specification of the LoadBalancer instance. If this parameter is not configured or is left empty, changes to the LoadBalancerSpec field are not detected, and the LoadBalancer instance specification cannot be updated based on values.yaml.
Private network configuration
PrivateNetwork.SubnetId	No	The subnet to which the LoadBalancer instance belongs. A subnet provides a private network IP address for LoadBalancer deployment in a private network. warning This parameter is required for private network access.
PrivateNetwork.IpFamily	"ipv4"	IP version of the LoadBalancer instance. Currently only ipv4 is supported.
PrivateNetwork.MasterZoneID	No	Master availability zone ID of the LoadBalancer instance. The value cannot be the same as that of the SlaveZoneID parameter. If this parameter is missing or left empty, the availability zone where the subnet is allocated will be assigned as the master availability zone by default. tip For the availability zones supported by LoadBalancer in each region and their IDs, see Regions and Availability Zones.
PrivateNetwork.SlaveZoneID	No	Slave availability zone ID of the LoadBalancer instance. The value cannot be the same as the value of the MasterZoneID parameter. If you configure this parameter, you must also configure the MasterZoneID parameter. Otherwise, an error will occur. If you remove this parameter or leave it empty, the following logic will be applied: For a specified region in which there is only a single availability zone, a CLB instance with a single availability zone will be created. For a specified region in which there is only a single availability zone, a CLB instance with availability zones randomly selected from the region will be created by default.
PrivateNetwork.ModifyProtection	No	Deletion protection for the LoadBalancer instance. Valid values: NonProtection: It disables modification protection to allow instances to be altered or removed via the console page. ConsoleProtection: It enables modification protection to prevent instances from being altered or removed via the console page. If this parameter is not configured or is left empty, the instance is not protected against modification or deletion operations performed in the console.
PrivateNetwork.LoadBalancerBillingType	2	The billing type of the LoadBalancer instance. Valid values: 2: pay-as-you-go - specification-based billing. Select an instance specification and pay based on actual usage time. 3: Pay-as-you-go - usage-based billing. No need to specify the instance specification and pay for it according to the actual resource consumed by the instance. warning Pay-as-you-go - usage-based billing is a beta feature of the LoadBalancer product. To apply for use of the billing model, please contact your customer manager. When the billing model for LoadBalancer is Pay-as-you-go - usage-based billing, you do not need to configure LoadBalancerSpec.
PrivateNetwork.LoadBalancerSpec	"small_1"	Instance specification of the LoadBalancer. Available types: small_1: small I small_2: small II medium_1: medium I medium_2: medium II large_1: large I large_2: large II warning For details about specifications and types of LoadBalancer instances, seeProduct types and specifications. The LoadBalancerBillingType parameter set to 3 indicates that the LoadBalancer instance applies the pay-as-you-go - usage-based billing type. This parameter is not configurable.
PrivateNetwork.SyncField	No	Whether to detect LoadBalancerSpec field changes and update the Loadbalancer instance accordingly during a values.yaml update. Valid values: spec: detects changes to the LoadBalancerSpec field and updates the specification of the LoadBalancer instance. If this parameter is not configured or is left empty, changes to the LoadBalancerSpec field are not detected, and the LoadBalancer instance specification cannot be updated based on values.yaml.

The following table describes fields in Controller.

Parameter	Default value	Description
ingressClassResource.name	nginx	The name of the IngressClass for the Ingress controller. warning This parameter serves as a replacement for the controller.ingressClass parameter in templates for Kubernetes versions earlier than 1.22, and can be used in the kubernetes.io/ingress.class annotation. IngressClass names for different sets of Ingress controllers within the same cluster must be unique and cannot be related to the nginx keyword (nginx is the listening identifier for the default Ingress controller of the cluster).
ingressClassResource.controllerValue	"k8s.io/ingress-nginx"	The Controller Class corresponding to the Ingress controller. warning Controller class names for different sets of Ingress controllers within a cluster must be unique and cannot be related to the k8s.io/ingress-nginx keyword (k8s.io/ingress-nginx is the listening identifier for the default Ingress controller of the cluster).
replicaCount	1	The number of replicas for the Ingress controller Pod.
controller.resources.requests.cpu	100m	The CPU request setting for the Ingress controller pod. Unit: core. When using millicores as the unit, specify the CPU request in the format CPU request+m , e.g., 100m represents 100 millicores.
resources.requests.memory	90Mi	The memory request setting for the Ingress controller pod. The unit is MiB or GiB, and the format is memory request + unit. For example, 90Mi represents 90 MiB, and 2Gi represents 2 GiB.
electionID	ingress-controller-leader	The election ID when a host machine is selected. This is used for updating the Ingress endpoint status. warning If you deploy multiple NGINX Ingress controllers to the same namespace from the Application center, you need to set electionID to a different value for each controller to avoid leader election conflicts.

The following table describes fields in Deployment or Daemonset.

Parameter	Default value	Description
hostNetwork	false	The parameters for deploying NGINX Ingress controllers to a Deployment or DaemonSet. For detailed parameter descriptions, see Kubernetes documentation.
NodeSelector.kubernetes.io	linux
namespace	The same as the namespace where the application belongs.
tolerations	[]
resources.requests.cpu	100m
resources.requests.memory	90Mi
name	controller

Last updated: 2026.07.24 14:51:36