Introducing Oracle Cloud Native Ingress controller for Kubernetes

In the world of Kubernetes, an ingress controller is a key component that allows incoming traffic to be routed to the appropriate service within a cluster. It acts as an entry point for HTTP and HTTPs traffic, enabling the exposure of services to the outside world. While Kubernetes in Oracle supports several ingress controllers, such as NGINX Ingress Controller and Traefik, no controller was integrated with Oracle Cloud Infrastructure (OCI) services. 

We’re excited to announce the release of our new OCI native ingress controller for Kubernetes! With our new native ingress controller, you can now easily and efficiently manage your ingress resources directly within Kubernetes, without relying on any external controllers. This cutting-edge solution is designed to empower developers and businesses to harness the true power of cloud native applications, enabling seamless connectivity and advanced routing capabilities leveraging the OCI ecosystem.

What is the Oracle Cloud native ingress controller?

The Oracle Cloud native ingress controller is a robust and scalable solution that simplifies the management of inbound network traffic to your cloud native applications. It provides a centralized control plane for routing and load balancing, making it easier than ever to deliver your services reliably and efficiently. It’s designed to be highly customizable, with support for all the latest ingress features, such as transport layer security (TLS) termination, pod-readiness gate, host, and path-based routing. It’s also built to be highly performant with minimal overhead and latency.

The native ingress controller seamlessly integrates with the OCI Load Balancing service, which acts as a router, and OCI Certificates manage certificates used in establishing TLS/SSL communication.

Benefits

Simplify operations and save costs

The native ingress controller enables you to simplify operations and save costs by sharing an OCI load balancer across multiple applications in your Kubernetes cluster. You can have a single load balancer for multiple services running within the Oracle Kubernetes cluster and configure advanced routing rules, such as path-based routing and host-based routing, and consolidating services to a single entry point for lower cost and centralized configuration.

Instant readiness, flexibility, and high availability with OCI Load Balancing

Oracle Load Balancing is a popular Oracle service that load balances incoming traffic at the application layer (layer 7) across multiple backends, such as Oracle Compute instances, in a region. The native ingress controller seamlessly integrates with the load balancer that acts as a router—a separate entity outside the Oracle Container Engine for Kubernetes (OKE) cluster.

OCI Flexible Load Balancing enables customers to distribute HTTP(s) requests across a fleet of pods or automatically route traffic across fault domains, availability domains, or regions—yielding high availability and fault tolerance for any application or data source. With OCI Flexible Load Balancing, you’re no longer restricted to fixed bandwidth load balancer shapes or scaling based only on general traffic patterns. You can choose a custom minimum bandwidth and an optional maximum bandwidth. The minimum bandwidth is always available and provides instant readiness for your workloads. The optional maximum bandwidth setting can limit bandwidth, even during unexpected peaks, if you need to control costs. Based on incoming traffic patterns, available bandwidth scales up from the minimum as traffic increases.

Automatic certificate management

The native ingress controller also integrates with OCI Certificates, which allow users to create and manage TLS certificates used to enable HTTPs traffic on the load balancer. After creation, the native ingress controller automatically associates it to the load balancer and relies on the Certificates service to automatically rotate the certificates.

Simplified management and monitoring

Efficient management and monitoring of application deployments are essential for maintaining optimal performance and addressing issues promptly. The native ingress controller integrates with Oracle Cloud Load Balancer that has its own monitoring and logging capabilities providing comprehensive visibility into application traffic, performance metrics and logs. With the centralized OCI load balancer’s monitoring and management capabilities, operators can quickly identify and resolve any potential bottlenecks or anomalies, ensuring a smooth and uninterrupted user experience.

Dedicated routing resource outside worker nodes

In the open source and third-party ingress model, the routing component is a pod running inside the worker nodes, which consumes part of the resources dedicated for the applications. For example, all TLS/SSL connections end on the ingress controller pod running within the Kubernetes cluster. With a lot of HTTPs traffic, a significant amount of compute is wasted on encryption and decryption of the traffic. With the native ingress controller, this processing happens at the load balancer level, saving worker node resources.

Faster responses by avoiding extra hops

Previously, Oracle Kubernetes provisioned an OCI Load balancer and kept worker nodes as the backends, eventually routing to your pods. With the native ingress controller, your pods can directly serve as a backend to the OCI load balancer, avoiding the extra hop instead of relying on internal service IPs and kube-proxy.

How does the Oracle Cloud native ingress controller work?

To get started with our native ingress controller, deploy it as a Kubernetes resource and then create your ingress resources as you normally do. Our controller automatically creates an OCI load balancer that handles the routing and load balancing for you, ensuring that your traffic is efficiently and securely routed to your applications.

Configure the prerequisites and required Idenitty and Access Management (IAM) policies.

Create an OKE cluster or use an existing cluster and deploy the ingress controller. You can deploy it using Helm and YAML. For details, see the documentation. You don’t need to mention the namespace. The ingress controller pod runs in the native-ingress-controller-system namespace if not explicitly mentioned.

$ helm install oci-native-ingress-controller helm/oci-native-ingress-controller
NAME: oci-native-ingress-controller
LAST DEPLOYED: Mon May 15 22:40:18 2023
NAMESPACE: native-ingress-controller-system
STATUS: deployed
REVISION: 1
TEST SUITE: None

$ kubectl get pods -n native-ingress-controller-system -o wide -w

NAME                                             READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES

oci-native-ingress-controller-6887f9cb9f-m5rg7   1/1     Running   0          10s   10.0.10.148   10.0.10.197   <none>           <none>

apiVersion: "ingress.oraclecloud.com/v1beta1"
kind: IngressClassParameters
metadata:
     name: ingressparms-prod
     namespace: native -ingress-controller-system
spec: 
     loadBalancerName: "native-ic-lb"
     isPrivate: false
     maxBandwidthMbps: 400
     minBandwidthMbps: 100

3. Create an ingress class, which also creates an OCI load balancer with a shape specified by the IngressClassparameters custom resource. The ingress class instance helps in mapping ingress resources to a controller if you have multiple ingress controller implementations running inside a Kubernetes cluster. It also helps create load balancers with different shapes if ingress resources have those requirements.

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
     name: default -ingress-class
     annotations:
       ingressclass.kubernetes.io/is-default -class :  "true"
spec:
    controller: oci.oraclecloud.com/native -ingress-controller
     parameters:
       scope: Namespace
       namespace: native -ingress-controller-system
       apiGroup: ingress.oraclecloud.com
       kind: ingressclassparameters
       name: ingressparms-prod

4. Create ingress resources to specify the routing rules. The native ingress controller watches for ingress changes from the API server. When it finds that an ingress resource is created or updated, it starts the create and update operations of OCI resources. Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the ingress resource. In the following steps, we create a route in the load balancer to redirect all requests to path ’/app1’ to service B:

apiVersion: networking.k8s.io/v1
kind: Ingress
     metadata:
        name: ingress-tls
        annotations:
          oci-native -ingress.oraclecloud.com/protocol: HTTP   
          oci-native -ingress.oraclecloud.com/policy: "ROUND_ROBIN"
          oci-native -ingress.oraclecloud.com/healthcheck-protocol:  "HTTP"     
          oci-native -ingress.oraclecloud.com/healthcheck-port:  "9090"  
          oci-native -ingress.oraclecloud.com/healthcheck-interval-milliseconds:  "10000" 
          oci-native -ingress.oraclecloud.com/healthcheck-timeout-milliseconds:  "3000" 
          oci-native -ingress.oraclecloud.com/healthcheck-retries:  "3"
          oci-native -ingress.oraclecloud.com/healthcheck-return -code:  "200"  
          oci-native -ingress.oraclecloud.com/healthcheck-response-regex:  ""  
          oci-native -ingress.oraclecloud.com/healthcheck-path:  "/health"  
          oci-native -ingress.oraclecloud.com/healthcheck-force-plaintext:  "true" 
    spec:
        defaultBackend:
          service:
            name: default -backend
            port:
              number: 8080
        tls:
        - hosts:
            - foo.bar.com
          secretName: demo-tls-secret
        rules:
        - host:  "foo.bar.com"
          http:
            paths:
            - pathType: Prefix
              path:  "/app1"
              backend:
                service:
                  name: Service B
                  port:
                    number: 443

1. Create the OCI load balancer backend sets for each backend specified in the ingress resource.

2. Create listeners for every port specified as backend service.

3. Create routing rules for each path specified in your ingress resource, ensuring that traffic to a specific path is routed to the correct backend set created.

4. Create OCI Certificates and CA bundles and associate them with the listener and backend set. Create the Kubernetes secret demo-tls-secret in advance if you want to enable TLS on the load balancer. For details instructions, see the documentation.

5. Create a default backend set. An ingress traffic that matches no rules sends all traffic to a single default backend. Create the service and pass it as default behavior to the ingress.

6. Configure Health Check on the service backend set.

Conclusion

The introduction of the Oracle native ingress controller marks a significant milestone in the evolution of Oracle’s cloud native offerings. By streamlining application deployment, enhancing scalability, and integrating seamlessly with OCI services, this powerful controller empowers developers and operators to deliver robust and performant applications efficiently. With a strong focus on security, compliance and simplified management, the Oracle native ingress controller reinforces Oracle’s commitment to providing comprehensive solutions that enable organizations to thrive in the cloud native era.

The OCI native ingress controller is a production-ready open source project. To learn more about the Oracle native ingress controller and how it can transform your application deployments, check out our documentation. Embrace the power of Oracle’s cloud native ecosystem and unlock the full potential of your applications. If you want to get involved, see the following resources:

• Documentation

• GitHub

• Issues