Configuring the OCI Native Ingress Controller
Find out how to configure and customize the OCI native ingress controller to load balance and route incoming traffic to service pods running on worker nodes in a Kubernetes cluster.
When you have installed the OCI native ingress controller (either as a standalone program or as a cluster add-on) and created the necessary Kubernetes ingress-related resources to use it, you can configure the OCI native ingress controller by:
Specifying Route Rules for the OCI Native Ingress Controller
To specify how the OCI load balancer created by the OCI native ingress controller (installed either as a standalone program or as a cluster add-on) routes incoming requests, you specify route rules in the Ingress
manifest.
Route requests based on host
You can configure the OCI native ingress controller to route an incoming request based on the domain name in the request's Host header (the host to which the request was originally sent).
To route a request to a particular backend service and port based on the host, create a route rule in the Ingress
manifest. If the host matches the route rule, the OCI native ingress controller routes the request to the associated backend service and port.
For example, you might define the following rule to route requests originally sent to http://foo.bar.com
to a backend service named ServiceA on port 80. All incoming traffic originally sent to http://foo.bar.com
is routed to ServiceA on port 80.
kind: Ingress
...
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: /
backend:
serviceName: ServiceA
servicePort: 80
Route requests to different backend services based on path
You can configure the OCI native ingress controller to route incoming requests to different backend services, based on elements in the path to which the requests were originally sent.
To route a request to a particular backend service and port based on the path, create a route rule in the Ingress
manifest. If the path matches the route rule, the OCI native ingress controller routes the request to the associated backend service and port. You can specify multiple paths in the same rule, to route requests to different backends.
For example, you might define the following rule to route requests based on the path to which the request was originally sent:
- If the path starts with /app1, the OCI native ingress controller routes the request to a backend service named ServiceA on port 80.
- If the path starts with /app2, the OCI native ingress controller routes the request to a backend service named ServiceB on port 443.
Since the rule does not specify a host, the rule applies to all incoming traffic.
kind: Ingress
...
spec:
rules:
- http:
paths:
- pathType: Prefix
path: /app1
backend:
serviceName: ServiceA
servicePort: 80
- pathType: Prefix
path: /app2
backend:
serviceName: ServiceB
servicePort: 443
Route requests based on host and path
You can configure the OCI native ingress controller to route an incoming request based on both the domain name in the request's Host header (the host to which the request was originally sent) and elements in the path to which the original request was sent.
To route a request to a particular backend service and port based on the host and path, create a route rule in the Ingress
manifest. If the host and path match the route rule, the OCI native ingress controller routes the request to the associated backend service and port.
For example, you might define the following rule to route requests originally sent to http://foo.bar.com/app1
to a backend service named foo on port 80:
kind: Ingress
...
spec:
rules:
- host: "foo.bar.com"
http:
paths:
- pathType: Prefix
path: /app1
backend:
serviceName: foo
servicePort: 80
Route requests to a default backend
You can configure the OCI native ingress controller to route incoming requests to a default backend. You might configure a default backend to handle requests that do not match any route rules.
For example, you might define the following defaultBackend
to route requests that do not match other rules in the Ingress
manifest to a backend service named ServiceC on port 8080.
Note that if you do not specify any other rules in an Ingress
manifest, you must specify a defaultBackend
.
kind: Ingress
...
spec:
rules:
- http:
paths:
- pathType: Prefix
path: /app1
backend:
serviceName: ServiceA
servicePort: 80
- pathType: Prefix
path: /app2
backend:
serviceName: ServiceB
servicePort: 443
defaultBackend:
service:
name: ServiceC
port:
number: 8080
Customizing OCI Native Ingress Controller Behavior Using Annotations
You can add annotations to the IngressClass
or the Ingress
resource manifests to customize the behavior of the OCI native ingress controller (installed either as a standalone program or as a cluster add-on).
Customizing general behavior using annotations
You can add annotations to the IngressClass
or the Ingress
resource manifests to customize general behavior of the OCI native ingress controller.
Annotation | Description | Add annotation to this resource manifest | Example |
---|---|---|---|
oci-native-ingress.oraclecloud.com/id |
OCID of an existing OCI load balancer to use, rather than creating a new one. Note that if you do specify an existing load balancer, its properties are updated as necessary to align with values in the IngressClassParameters and Ingress resource manifests. |
IngressClass |
oci-native-ingress.oraclecloud.com/id: ocid1.loadbalancer.oc1.iad.aaaaaaaan___u7a |
oci-native-ingress.oraclecloud.com/waf-policy-ocid |
OCID of an existing web application firewall (WAF) policy. See Web Application Firewall Policies. | IngressClass |
oci-native-ingress.oraclecloud.com/waf-policy-ocid: ocid1.webappfirewallpolicy.oc1.iad.ama___aqq |
oci-native-ingress.oraclecloud.com/protocol |
Protocol to use for listener on the load balancer. One of HTTP2 or TCP. (Note that if you specify HTTP2 as the protocol, a TLS-configured listener is required.) |
Ingress |
oci-native-ingress.oraclecloud.com/protocol: "HTTP2" |
oci-native-ingress.oraclecloud.com/backend-tls-enabled |
Whether backend service pods can receive TLS requests. If set to |
Ingress |
oci-native-ingress.oraclecloud.com/backend-tls-enabled: "false" |
oci-native-ingress.oraclecloud.com/http-listener-port |
Create a single listener port for all HTTP paths under this ingress, rather than creating a listener port for each service port. The routing policies are configured accordingly. |
Ingress |
oci-native-ingress.oraclecloud.com/http-listener-port: "100" |
oci-native-ingress.oraclecloud.com/https-listener-port |
Create a single listener port for all HTTPS paths under this ingress, rather than creating a listener port for each service port. The routing policies are configured accordingly. | Ingress |
oci-native-ingress.oraclecloud.com/https-listener-port: "500" |
oci-native-ingress.oraclecloud.com/policy |
Policy to be used by the load balancer backend set for traffic distribution. | Ingress |
oci-native-ingress.oraclecloud.com/policy: "ROUND_ROBIN" |
Customizing health check behavior using annotations
You can add annotations to the Ingress
resource manifest to customize the health checks performed by the load balancer created by the OCI native ingress controller. For more information about load balancer health checks, see Health Checks for Load Balancers.
Annotation | Description | Add annotation to this resource manifest | Example |
---|---|---|---|
oci-native-ingress.oraclecloud.com/healthcheck-protocol |
Protocol to use for the load balancer backend set health checks. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-protocol: "HTTP" |
oci-native-ingress.oraclecloud.com/healthcheck-port |
Port to use for the load balancer backend set health checks. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-port: "80" |
oci-native-ingress.oraclecloud.com/healthcheck-path |
Path to use for the load balancer backend set health checks. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-path: "/test" |
oci-native-ingress.oraclecloud.com/healthcheck-interval-milliseconds |
Interval between the load balancer backend set health checks. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-interval-milliseconds: "1000" |
oci-native-ingress.oraclecloud.com/healthcheck-timeout-milliseconds |
Period of time after which the load balancer backend set health check is considered to have failed. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-timeout-milliseconds: "750" |
oci-native-ingress.oraclecloud.com/healthcheck-retries |
Number of retries after which the load balancer backend set health check is considered to have failed. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-retries: "5" |
oci-native-ingress.oraclecloud.com/healthcheck-return-code |
Status code the load balancer backend set must return in response to a health check to be considered healthy. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-return-code: "200" |
oci-native-ingress.oraclecloud.com/healthcheck-response-regex |
Regular expression for parsing the response body from the load balancer backend set. You can specify any regex value (such as * or / ), or an empty value. | Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-response-regex: "*" |
oci-native-ingress.oraclecloud.com/healthcheck-force-plaintext |
Whether to send a health check to the load balancer backend without SSL (HTTP only). If not specified, false is the default. |
Ingress |
oci-native-ingress.oraclecloud.com/healthcheck-force-plaintext: "true" |
Setting Up a Pod Readiness Gate
Pod readiness gates are additional conditions included in a pod manifest to indicate that a pod is ready to receive traffic. Pod readiness gates enable you to implement complex custom readiness checks, and can help to achieve zero downtime during rolling deployments. For more information, see pod readiness details in the Kubernetes documentation.
When using the OCI native ingress controller (either as a standalone program or as a cluster add-on) with a cluster that has VCN-native pod networking as the network type, you can specify that the OCI native ingress controller is to inject a pod readiness gate into the pod spec of every pod created in a particular namespace. Note that you cannot use the OCI native ingress controller to inject pod readiness gates into pod specs if the cluster has Flannel overlay as the network type.
Specify that the OCI native ingress controller is to inject a pod readiness gate into the pod spec of every pod created in a particular namespace by entering:
kubectl label ns <namespace> podreadiness.ingress.oraclecloud.com/pod-readiness-gate-inject=enabled
The OCI native ingress controller injects a condition into the pod spec of every pod created in the namespace. For example:
kind: Pod
...
spec:
readinessGates:
- conditionType: podreadiness.ingress.oraclecloud.com/k8s_6b5b1b3a38
kubectl get pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
testecho-7cdcfff87f-b6xt4 1/1 Running 0 35s 10.0.10.242 10.0.10.135 <none> 0/1
testecho-7cdcfff87f-b6xt4 1/1 Running 0 72s 10.0.10.242 10.0.10.135 <none> 1/1
Setting up TCP Listeners
You can use the OCI native ingress controller (either as a standalone program or as a cluster add-on) to set up load balancer listeners as TCP listeners. Each TCP listener simply forwards TCP traffic received on a particular port to the backend service specified for that port in an Ingress
resource manifest, without performing any transport layer 7 routing.
You set the oci-native-ingress.oraclecloud.com/protocol
annotation to specify that the OCI native ingress controller is to create a TCP listener for each unique port that is included in routing rules in an Ingress
resource manifest.
To specify that the OCI native ingress controller is to create TCP listeners:
- Define a new ingress resource in a .yaml file. See Create Ingress resource.
- In the
metadata:
section, add anannotations:
element and set theoci-native-ingress.oraclecloud.com/protocol
annotation toTCP
, in the format:kind: Ingress metadata: name: <i-name> annotations: oci-native-ingress.oraclecloud.com/protocol: TCP spec: ...
where
name: <i-name>
is your choice of name for the ingress resource.For example:
kind: Ingress metadata: name: ingress-pass-through annotations: oci-native-ingress.oraclecloud.com/protocol: TCP spec: ...
- In the
rules:
section of theIngress
resource manifest, add a rule for each listener that is to receive TCP traffic:- (recommended) Set
paths.pathType
toImplementationSpecific
. - Set
paths.backend.service.name
to the name of the backend service. - Set
paths.backend.service.port.number
to the port on which to listen for TCP traffic, and to which to forward the TCP traffic.
For example, if you want a TCP listener listening on port 8080 to forward TCP traffic to
my-first-svc:8080
, and a TCP listener listening on port 8081 to forward TCP traffic tomy-second-svc:8081
, you might set up anIngress
resource manifest as follows:apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-pass-through annotations: oci-native-ingress.oraclecloud.com/protocol: TCP spec: rules: - http: paths: - pathType: ImplementationSpecific backend: service: name: my-first-svc port: number: 8080 - http: paths: - pathType: ImplementationSpecific backend: service: name: my-second-svc port: number: 8081
- (recommended) Set
-
Create the resource by entering
kubectl create -f <filename>.yaml
Adding Support for HTTPS/TLS Requests
You can use the OCI native ingress controller (either as a standalone program or as a cluster add-on) to support secure HTTPS communication. Using the OCI native ingress controller, you can set up OCI load balancer listeners and backend sets to handle traffic encrypted using TLS (formerly SSL).
When using the OCI native ingress controller to support HTTPS communication, you have two options:
- Option 1: OCI Native Ingress Controller obtains certificate from the Certificates service using a Kubernetes secret: You create a Kubernetes secret and specify the name of the secret in an
Ingress
resource manifest. The OCI native ingress controller uses the Kubernetes secret to obtain a certificate and a CA bundle (Certificate Authority bundle) from the OCI Certificates service. The OCI native ingress controller associates the certificate and the CA bundle with the listener and the backend set. - Option 2: You obtain certificate from the Certificates service: You manually create a certificate in the OCI Certificates service yourself. You then specify the certificate's OCID in the
Ingress
resource manifest as an annotation. The OCI native ingress controller associates the certificate with the listener and the backend set.
When handling HTTPS traffic, the OCI load balancer created by the OCI native ingress controller implements end-to-end TLS by default. The load balancer uses certificates to accept a TLS encrypted request from a client, and then uses routing rules to forward the request to the appropriate backend set. The backend set creates a new TLS connection with backends running on the cluster (using the CA bundle as the trust authority for the new connection).
Note the following:
- If you delete an
IngressClass
resource, the OCI native ingress controller deletes the load balancer it created (or deletes the existing load balancer specified by theoci-native-ingress.oraclecloud.com/id
annotation). However, note that the ingress controller does not delete resources created in the OCI Certificates service. You are responsible for deleting any such Certificates service resources. In particular, if you specified a Kubernetes secret in theIngress
resource manifest, note that you are responsible for deleting any Certificates service resources that the OCI native ingress controller has created for you. - Certificates obtained from the OCI Certificates service of type Imported cannot be automatically rotated. If you want certificates rotated automatically, manually obtain a certificate in the OCI Certificates service yourself by specifying that you want the certificate to be issued by a Certificates service internal CA (the certificates are of type Issued by internal CA). You can configure certificates of type Issued by internal CA to be automatically rotated.
- If you specify a Kubernetes secret in the
Ingress
resource manifest, note that certificates the OCI native ingress controller obtains from the Certificates service are of type Imported and therefore not rotated automatically. To manually rotate such Certificates service certificates, first create a new Kubernetes secret using a new TLS public and private key pair and a new certificate. Then, update theIngress
resource with the name of the new secret. The OCI native ingress controller obtains a new certificate and a CA bundle from the Certificates service and associates them with the listener and the backend set (replacing the previous certificate and CA bundle). - A listener can only be associated with one certificate. Therefore, do not create multiple ingress resources that each have rules specifying the same backend service/port combination, but where the ingress resources use different certificates.
- By default, the OCI load balancer created by the OCI native ingress controller implements end-to-end TLS. The load balancer terminates the TLS request on the listener, and a new TLS connection is established between the backend set and backends. However, if the backends are not running an HTTPS server and you therefore want the connection between the backend set and the backends to be in plain text, set the
oci-native-ingress.oraclecloud.com/backend-tls-enabled
annotation to"false"
. When theoci-native-ingress.oraclecloud.com/backend-tls-enabled
annotation is set to"false"
, the load balancer can accept encrypted traffic from a client but traffic between the load balancer and the backends is not encrypted.
Option 1: OCI Native Ingress Controller obtains certificate from the Certificates service using a Kubernetes secret
To configure the OCI native ingress controller to obtain a certificate from the OCI Certificates service:
- Obtain a TLS public and private key pair, and a certificate.
In production environments, you obtain a TLS certificate from your chosen Certificate Authority by submitting a certificate signing request. During the certificate request process, a public key and corresponding private key are generated.
In development and test environments, you can create a self-signed certificate and generate a private key yourself using a tool such as OpenSSL. For example (using OpenSSL 3.0 or later):
-
Generate a public and private key pair by entering the following commands:
openssl genrsa -out rootCA.key 4096
openssl req -x509 -addext basicConstraints=critical,CA:TRUE -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt -subj /CN=RootCA
-
Generate a certificate by entering the following commands:
openssl genrsa -out server.key 4096
openssl req -new -sha256 -key server.key -subj /C=US/ST=CA/O=MyOrg,Inc./CN=my.example.com -out server.csr
openssl x509 -req -in server.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256
In this example:
rootCA.key
contains the key pair for the root CA.rootCA.crt
contains the root CA certificate.server.key
contains the key pair for generating the server certificate.server.csr
contains the certificate signing request for the server certificate.server.crt
contains the generated server certificate.
-
- Create a Kubernetes secret resource in either of the following ways:
-
Using the
kubectl create secret generic
command, by entering:kubectl create secret generic <k8s-secret-name> --type=kubernetes.io/tls --from-file=ca.crt=<path-and-filename>.crt --from-file=tls.crt=<path-and-filename>.crt --from-file=tls.key=<path-and-filename>.key
where:
<k8s-secret-name>
is your choice of name for the Kubernetes secret--from-file=ca.crt=<path-and-filename>.crt
specifies the path to the file containing the root CA certificate. For example,--from-file=ca.crt=rootCA.crt
--from-file=tls.crt=<path-and-filename>.crt
specifies the path to the file containing the generated server certificate. For example,--from-file=tls.crt=server.crt
--from-file=tls.key=<path-and-filename>.key
specifies the path to the file containing the generated private key. For example,--from-file=tls.key=server.key
For example:
kubectl create secret generic example-tls-secret --type=kubernetes.io/tls --from-file=ca.crt=rootCA.crt --from-file=tls.crt=server.crt --from-file=tls.key=server.key
- Using a
Secret
resource manifest file:-
Define the Kubernetes secret in a .yaml file, in the format:
apiVersion: v1 kind: Secret metadata: name: <k8s-secret-name> type: kubernetes.io/tls data: ca.crt: <base64-encoded-certificate-chain> tls.crt: <base64-encoded-server-certificate> tls.key: <base64-encoded-private-key>
where:
name: <k8s-secret-name>
is your choice of name for the Kubernetes secret resource.ca.crt: <base64-encoded-certificate-chain>
is the contents of the file (or files) containing intermediate certificates that form a certificate chain from the leaf certificate back to the Certificate Authority. Note that you can omitca.cert
, provided you include the entire certificate chain as the value oftls.cert
(in which case, start the certificate chain with the contents of the file containing the generated server certificate, followed by the remaining certificates).tls.crt: <base64-encoded-server-certificate>
is the contents of the file containing the generated server certificate.tls.key: <base64-encoded-private-key>
is the contents of the file containing the generated private key.
For example:
apiVersion: v1 kind: Secret metadata: name: example-tls-secret type: kubernetes.io/tls data: ca.crt : MIIFGERTegcDFRTuSDGfghREdE______Jre tls.crt: MIIC2DCCAcCgAwIBAgIBATANBg______kqh tls.key: MIIEpgIBAAKCAQEA7yn3bRHQ5F______HMQ
-
Create the secret resource by entering
kubectl create -f <filename>.yaml
-
-
- Add the Kubernetes secret to an
Ingress
resource manifest:- Define a new ingress resource in a .yaml file. See Create Ingress resource.
- In the
spec:
section of the manifest, add atls:
element that specifies both the host that is to receive HTTPS traffic and the name of the Kubernetes secret, in the format:kind: Ingress ... spec: tls: - hosts: - <host-name> secretName: <k8s-secret-name>
For example:
kind: Ingress ... spec: tls: - hosts: - my.example.com secretName: example-tls-secret
- In the
rules:
section of the manifest, add a rule for the host that is to receive HTTPS traffic, and specify 443 as the port on which to listen for HTTPS traffic.For example:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: acme-tls-secret-ingress spec: tls: - hosts: - my.example.com secretName: example-tls-secret rules: - host: "my.example.com" http: paths: - pathType: Prefix path: "/TLSPath" backend: service: name: tls-test port: number: 443
-
Create the resource by entering
kubectl create -f <filename>.yaml
When you create the ingress resource, the OCI native ingress controller uses the Kubernetes secret to obtain a certificate of type Imported, and a CA bundle (Certificate Authority bundle), from the OCI Certificates service. The OCI native ingress controller associates the certificate with the listener, and the CA bundle with the backend set.
When the listener listening on port 443 receives an HTTPS request to the specified host, the listener uses the certificate for TLS termination. The listener then uses the routing rule to forward the request to the backend set. The backend set creates a new TLS connection with the backends running on the cluster (using the CA bundle as the trust authority for the new connection).
Option 2: You obtain certificate from the Certificates service
To configure the OCI native ingress controller to use a certificate that you have obtained from the OCI Certificates service:
- Create a certificate in the OCI Certificates service in one of the following ways:
- by importing a certificate issued by a third-party CA (the certificate will be of type Imported)
- by issuing the certificate internally from a Certificates service CA (the certificate will be of type Issued by internal CA)
Do not create a certificate to manage externally (of type Issued by internal CA, managed externally). For more information, see Creating a Certificate.
- Make a note of the certificate's OCID.
- Add the certificate's OCID to an
Ingress
resource manifest:- Define a new ingress resource in a .yaml file. See Create Ingress resource.
- In the
metadata:
section, add anannotations:
element that specifies the OCID of the certificate you created in the OCI Certificates service, in the format:kind: Ingress metadata: name: <i-name> annotations: oci-native-ingress.oraclecloud.com/certificate-ocid: <certificate-ocid> spec: ...
where:
name: <i-name>
is your choice of name for the ingress resource.oci-native-ingress.oraclecloud.com/certificate-ocid: <certificate-ocid>
is the OCID of the certificate you created in the OCI Certificates service
For example:
kind: Ingress metadata: name: acme-tls-certificate-ingress annotations: oci-native-ingress.oraclecloud.com/certificate-ocid: ocid1.certificate.oc1.iad.amaaaaaa______gabc spec: ...
- In the
rules:
section of theIngress
resource manifest, add a rule for the host that is to receive HTTPS traffic, and specify 443 as the port on which to listen for HTTPS traffic.For example:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: acme-tls-certificate-ingress annotations: oci-native-ingress.oraclecloud.com/certificate-ocid: ocid1.certificate.oc1.iad.amaaaaaa______gabc spec: rules: - host: "my.example.com" http: paths: - pathType: Prefix path: "/TLSPath" backend: service: name: tls-test port: number: 443
-
Create the resource by entering
kubectl create -f <filename>.yaml
What happens when you create the ingress resource depends on how you created the certificate in the OCI Certificates service:
- If you created the certificate by importing a certificate issued by a third-party CA, the certificate is of type Imported. The OCI native ingress controller associates the certificate with the listener, creates a CA bundle from the certificate chain, and associates the CA bundle with the backend set. Note that you cannot configure certificates of type Imported to be automatically rotated.
- If you created the certificate by issuing the certificate internally from a Certificates service CA, the certificate is of type Issued by internal CA. The OCI native ingress controller associates the certificate with the listener, obtains the OCID of the CA, and associates that OCID with the backend set. Note that you can configure certificates of type Issued by internal CA to be automatically rotated.
When the listener listening on port 443 receives an HTTPS request to the specified host, the listener uses the certificate for TLS termination. The listener then uses the routing rule to forward the request to the backend set. The backend set creates a new TLS connection with the backends running on the cluster (using the CA bundle, or the CA identified by its OCID, as the trust authority for the new connection).
Aggregating HTTP/HTTPS Listener Ports
When using the OCI native ingress controller (either as a standalone program or as a cluster add-on) you can aggregate all HTTP traffic into a single listener port, and similarly you can aggregate all HTTPS traffic into a single port.
By default, the OCI native ingress controller creates an OCI load balancer listener for each backend service port defined in an Ingress
manifest. The OCI native ingress controller also creates a routing policy for each listener port. However, you can use the oci-native-ingress.oraclecloud.com/http-listener-port
annotation and/or the oci-native-ingress.oraclecloud.com/https-listener-port
annotation to create a single listener and routing policy for all HTTP requests, and/or a single listener and routing policy for all HTTPS requests.
For example, you might define an ingress with rules for four backend services, each service listening on a different port, as follows:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: sample-ingress
spec:
tls:
- hosts:
- "foo.bar.com3"
- "foo.bar.com4"
secretName: secret_name
rules:
- host: "foo.bar.com1"
http:
paths:
- pathType: Prefix
path: "/testecho1"
backend:
service:
name: testecho1
port:
number: 80
- host: "foo.bar.com2"
http:
paths:
- pathType: Prefix
path: "/testecho2"
backend:
service:
name: testecho2
port:
number: 81
- host: "foo.bar.com3"
http:
paths:
- pathType: Prefix
path: "/testecho3"
backend:
service:
name: testecho3
port:
number: 443
- host: "foo.bar.com4"
http:
paths:
- pathType: Prefix
path: "/testecho4"
backend:
service:
name: testecho4
port:
number: 444
In this example, the Ingress
manifest defines four services:
- testecho1, listening on port 80 for HTTP traffic
- testecho2, listening on port 81 for HTTP traffic
- testecho3, listening on port 443 for HTTPS traffic
- testecho4, listening on port 444 for HTTPS traffic
By default, the OCI native ingress controller creates:
- Four listeners in the load balancer (two listeners listening on ports 80 and 81 for HTTP traffic, and two listeners listening on ports 443 and 444 for HTTPS traffic).
- Four routing policies (one for each listener port).
To simplify administration, you might decide to have a single listener listening for HTTP traffic, and a single listener listening for HTTPS traffic, by setting annotations as follows:
oci-native-ingress.oraclecloud.com/http-listener-port: "100"
oci-native-ingress.oraclecloud.com/https-listener-port: "500"
With the annotations set as shown, the OCI native ingress controller creates:
- a single listener listening for HTTP traffic on port 100, and a single routing policy for port 100 with paths for backends on ports testecho1:80 and testecho2:81
- a single listener listening for HTTPS traffic on port 500, and a single routing policy for port 500 with paths for backends on ports testecho3:443 and testecho4:444
Note the following:
-
You can set the
oci-native-ingress.oraclecloud.com/http-listener-port
andoci-native-ingress.oraclecloud.com/https-listener-port
annotations independently of each other, so you do not have to set both annotations. -
If the
Ingress
resource manifest includes theoci-native-ingress.oraclecloud.com/certificate-ocid
annotation, the OCI native ingress controller considers all hosts to be configured for TLS. In this case, the OCI native ingress controller:- ignores the
oci-native-ingress.oraclecloud.com/http-listener-port
annotation (if present in theIngress
resource manifest) - applies the
oci-native-ingress.oraclecloud.com/https-listener-port
annotation (if present in theIngress
resource manifest) to create a single listener for all traffic
- ignores the
- Regardless of the
oci-native-ingress.oraclecloud.com/http-listener-port
andoci-native-ingress.oraclecloud.com/https-listener-port
annotations, the OCI native ingress controller only creates HTTP and/or HTTPS listeners (and corresponding routing policies) if required for backend services that are defined in the Ingress resource manifest. For example:- If you include the
oci-native-ingress.oraclecloud.com/http-listener-port
annotation in anIngress
resource manifest that does not define an HTTP backend, then the OCI native ingress controller does not create an HTTP listener. - If you include the
oci-native-ingress.oraclecloud.com/https-listener-port
annotation in anIngress
resource manifest that does not define an HTTPS backend, then the OCI native ingress controller does not create an HTTPS listener. - If you include both
oci-native-ingress.oraclecloud.com/http-listener-port
andoci-native-ingress.oraclecloud.com/https-listener-port
annotations in anIngress
resource manifest that only defines HTTP backends, then the OCI native ingress controller ignores theoci-native-ingress.oraclecloud.com/https-listener-port
annotation and does not create an HTTPS listener. - If you include both
oci-native-ingress.oraclecloud.com/http-listener-port
andoci-native-ingress.oraclecloud.com/https-listener-port
annotations in anIngress
resource manifest that only defines HTTPS backends, then the OCI native ingress controller ignores theoci-native-ingress.oraclecloud.com/http-listener-port
annotation and does not create an HTTP listener.
- If you include the