Skip to content

Managed Ingress

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. This is a heavily used and well tested Ingress Controller for Kubernetes that is based on NGINX as a reverse proxy and load balancer.


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.

Kubernetes Ingress

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

  • Navigate to the Cluster Dashboard and click on Resources
  • Select "Managed" for Namespace Group
  • Select "rafay-system" for Namespace
  • Search for "ingress"

You should see the pods for the nginx ingress controller here

Managed Ingress Controller


Disable Managed Ingress Controller

If you do not require the Managed Ingress Controller,

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

Custom Blueprint No Ingress


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.

Review this Page to understand the difference in capabilities between "Ingress-Nginx" and the other NGINX based Ingress Controllers.


Wizard based Workloads

Ingress Configuration

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

Wizard Ingress Enable

Ingress Mode The "Managed" Ingress Controller supports two modes

  • https: The ingress controller terminates https and sends the requests upstream to configured routes

  • tcp: The ingress controller uses SNI based on TLS 1.2 to identify the pods and routes the requests appropriately. In this case, the customer's workload is responsible to terminate TLS.

Wizard Ingress Modes

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
  • Optionally, enable DNS based GSLB
  • Provide URL Paths if you need to send traffic to different services in your workload or optionally an external service.

Wizard Ingress Configuration

Checking Ingress

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

This will display configured Ingress for the workload or namespace

Wizard Active Ingress Resources


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:

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