5.2. Ingress controller configuration parameters
The ingresscontrollers.operator.openshift.io resource offers the following configuration parameters.
| Parameter | Description |
|---|---|
|
|
The
If empty, the default value is |
|
|
|
|
|
If not set, the default value is based on
The |
|
|
The
The secret must contain the following keys and data: *
If not set, a wildcard certificate is automatically generated and used. The certificate is valid for the Ingress controller The in-use certificate, whether generated or user-specified, is automatically integrated with OpenShift Container Platform built-in OAuth server. |
|
|
|
|
|
|
|
|
If not set, the defaults values are used. 注意
The nodePlacement:
nodeSelector:
matchLabels:
beta.kubernetes.io/os: linux
tolerations:
- effect: NoSchedule
operator: Exists |
|
|
If not set, the default value is based on the
When using the
The minimum TLS version for Ingress controllers is 重要
The HAProxy Ingress controller image does not support TLS
The Ingress Operator also converts the TLS 注意
Ciphers and the minimum TLS version of the configured security profile are reflected in the |
|
|
|
|
|
|
All parameters are optional.
5.2.1. Ingress controller TLS profiles
The tlsSecurityProfile parameter defines the schema for a TLS security profile. This object is used by operators to apply TLS security settings to operands.
There are four TLS security profile types:
-
Old -
Intermediate -
Modern -
Custom
The Old, Intermediate, and Modern profiles are based on recommended configurations. The Custom profile provides the ability to specify individual TLS security profile parameters.
Sample Old profile configuration
spec:
tlsSecurityProfile:
type: Old
Sample Intermediate profile configuration
spec:
tlsSecurityProfile:
type: Intermediate
Sample Modern profile configuration
spec:
tlsSecurityProfile:
type: Modern
The Custom profile is a user-defined TLS security profile.
You must be careful using a Custom profile, because invalid configurations can cause problems.
Sample Custom profile
spec:
tlsSecurityProfile:
type: Custom
custom:
ciphers:
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES128-GCM-SHA256
minTLSVersion: VersionTLS11
5.2.2. Ingress controller endpoint publishing strategy
NodePortService endpoint publishing strategy
The NodePortService endpoint publishing strategy publishes the Ingress Controller using a Kubernetes NodePort service.
In this configuration, the Ingress Controller deployment uses container networking. A NodePortService is created to publish the deployment. The specific node ports are dynamically allocated by OpenShift Container Platform; however, to support static port allocations, your changes to the node port field of the managed NodePortService are preserved.
The Ingress Operator ignores any updates to .spec.ports[].nodePort fields of the service.
By default, ports are allocated automatically and you can access the port allocations for integrations. However, sometimes static port allocations are necessary to integrate with existing infrastructure which may not be easily reconfigured in response to dynamic ports. To achieve integrations with static node ports, you can update the managed service resource directly.
For more information, see the Kubernetes Services documentation on NodePort.
HostNetwork endpoint publishing strategy
The HostNetwork endpoint publishing strategy publishes the Ingress Controller on node ports where the Ingress Controller is deployed.
An Ingress controller with the HostNetwork endpoint publishing strategy can have only one pod replica per node. If you want n replicas, you must use at least n nodes where those replicas can be scheduled. Because each pod replica requests ports 80 and 443 on the node host where it is scheduled, a replica cannot be scheduled to a node if another pod on the same node is using those ports.
