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