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.
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.
Review this Page to understand the difference in capabilities between Ingress-Nginx and the other NGINX based Ingress Controllers.
Wizard based Workloads¶
For wizard based workloads, ensure that you enable inbound traffic if you would like to program Ingress.
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
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.
- 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
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