Managed Ingress

Important

The Kubernetes community has officially begun the process of retiring Ingress NGINX. This feature is now deprecated and will be removed in a future release. For more details, refer to this blog post: https://docs.rafay.co/blog/2025/12/05/goodbye-to-ingress-nginx--what-happens-next/

A "managed" Kubernetes Ingress Controller is available as part of the default cluster blueprint so that customers do not have to deal with the operational complexity with installation, tuning etc. The "Managed" Ingress Controller is Ingress Nginx.

Kubernetes Ingress

An Ingress is an object that allows access to your Kubernetes services from outside the Kubernetes cluster. You configure access by creating a collection of rules that define which inbound connections reach which services.

Unlike a NodePort or LoadBalancer, an Ingress is a completely independent resource to your service. You declare, create and destroy it separately to your services.

This makes it decoupled and isolated from the services you want to expose. It also helps you to consolidate routing rules into one place.

In order to configure and use an Ingress, you have to deploy and manage an Ingress Controller for the cluster. The controller provides users with a built-in, managed Ingress Controller option.

Ingress Controller Resources

Infrastructure administrators can view the Kubernetes resources associated with the ingress

• Navigate to the Cluster Dashboard and click Resources tab
• Select rafay-system for Namespace drop-down and search for ingress

The pods for the nginx ingress controller appears.

Click the ellipsis icon against each pod to perform a few actions. Refer Actions section in K8s Resources to know the actions availability for each resource.

Disable Managed Ingress Controller

If you do not require the Managed Ingress Controller,

• Create a custom blueprint and disable the Ingress Controller addon
• Apply this blueprint to your cluster

Bring Your Ingress Controller

There are a number of open source and commercial Ingress Controller options. Different ingress controllers have extended the ingress specification in different ways to support additional use cases. Customers can easily bring their own preferred Ingress Controller and disable the "managed" Ingress Controller using a "Custom Blueprint".

The Official Kubernetes Ingress Controller Page is a good source for the list of 3rd party Ingress Controllers.

The Kubernetes documentation page contains information about different Ingress Controllers, including Ingress-Nginx and other NGINX-based controllers.

Wizard based Workloads

Ingress Configuration

For wizard based workloads, ensure that you enable inbound traffic if you would like to program Ingress.

Ingress Mode

The Managed Controller supports the HTTP mode as shown below.

HTTP/S: The ingress controller terminates https and sends the requests upstream to configured routes

Hostname

For testing purposes, users can optionally leverage a domain hosted by the controller (i.e. System Domain). This option automatically programs DNS once the workload is successfully published on your clusters.

For custom domain (i.e. a domain you manage),

• Provide the hostname and FQDN where your users will access this workload
• For https workloads, provide the Server Certificate that will be used by the Ingress Controlle to terminate TLS connections
• DNS based load balancing is enabled by default
• Provide URL Paths if you need to send traffic to different services in your workload or optionally an external service.

Checking Ingress

• In the cluster dashboard, navigate to the Resources tab
• Select your workload or namespace
• Select Ingress under Load Balancers

This will display configured Ingress for the workload or namespace

YAML and Helm Workloads

Users can use the "Managed" Ingress just like they would use standard Kubernetes Ingress. For example, a definition that defines an Ingress to handle requests for www.example.com and forums.example.com and routes them to the Kubernetes services named website and forums respectively would look like:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - backend:
              serviceName: website
              servicePort: 80
    - host: forums.example.com
      http:
        paths:
          - path:
            backend:
              serviceName: forums
              servicePort: 80

Annotations

In addition to leveraging the "managed" Ingress Controller on your clusters, you can also leverage the provided annotations for additional automation for:

• DNS Programming
• DNS based GSLB

Shown below is an illustrative example for Ingress with annotations for DNS Programming Automation.

• For testing purposes, users can optionally also leverage the controller managed domains/hosts "*.run.rafay-edge.net" for their workloads.
• Ensure that you use a Cert-Manager addon for automation related to TLS certificates for your workload's hostname.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: km-nginx4
  annotations:
    rafay.dev/dns: "true"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
    - hosts:
        - km-nginx4.run.rafay-edge.net
      secretName: km-tls
  rules:
    - host: km-nginx4.run.rafay-edge.net
      http:
        paths:
          - backend:
              serviceName: km-nginx4
              servicePort: 80