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 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.

Managed Ingress Controller

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

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 3^rd 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.

Wizard Ingress Enable

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

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
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.

Wizard Ingress Configuration

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

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:

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