FortiADC Ingress Controller Overview
Figure 1 FortiADC Ingress Controller
FortiADC Ingress Controller fulfills the Kubernetes Ingress resources and allows you to manage FortiADC objects from Kubernetes. It is deployed in a container of a pod in a Kubernetes cluster.
The list below outlines the major functionalities of FortiADC Ingress Controller:
-
To list and watch Ingress related resources, such as Ingress, Service, Node and Secret.
-
To convert Ingress related resources to FortiADC objects, such as virtual server, content routing, real server pool, and more.
-
To handle Add/Update/Delete events for watched Ingress resources and automatically implement corresponding actions on FortiADC.
Ingress is a Kubernetes object that manages the external access to services in a Kubernetes cluster (typically HTTP/HTTPS). Ingress may provide load-balancing, SSL termination and name-based virtual hosting.
FortiADC Ingress Controller combines the capabilities of an Ingress resource with the Ingress-managed load-balancer, FortiADC.
FortiADC, as the Ingress-managed load-balancer, not only provides flexibility in load-balancing, but also guarantees more security with features such as the Web Application Firewall (WAF), Antivirus Scanning, and Denial of Service (DoS) prevention to protect the web server resources in the Kubernetes cluster.
Other features such as health check, traffic log management, and FortiView on FortiADC facilitates the management of the Kubernetes ingress resources.
Supported Environments
FortiADC Ingress Controller has been verified to run in the Kubernetes cluster in the below environments:
Environment |
Tools for building |
---|---|
Private cloud | kubeadm, minikube, microk8s |
Public cloud | AWS EKS, Oracle OKE |
Supported Release and Version
Product |
Version |
||
---|---|---|---|
FortiADC Ingress Controller | 1.0.0 |
1.0.1 |
1.0.2 |
Kubernetes | 1.19.8 - 1.23.x |
1.19.8 - 1.24.x |
1.19.8 - 1.27.x |
FortiADC Version |
5.4.5 - 7.2.x
|
The Kubernetes API Version
The Kubernetes API allows you to query and manipulate the state of API objects in Kubernetes (for example, Pods, Nodes, Ingress, and Services).
For the API object, such as the Ingress object you defined in the YAML file, there will be an apiVersion
field for Kubernetes to determine which API version to deploy the object. Different API versions may have different metadata and specification definitions for that object.
For example, for the Ingress API object, the API versions extensions/v1beta1/Ingress and networking.k8s.io/v1/Ingress would have different data structures for FortiADC Ingress Controller to parse. Before extensions/v1beta1/Ingress is entirely deprecated by networking.k8s.io/v1/Ingress in Kubernetes v1.22, you may find both API versions are supported by the Kubernetes API server in some cases, such as when upgrading Kubernetes from a lower version v1.16 to a higher version v1.19.
To ensure you use an API version of Kubernetes objects that FortiADC Ingress Controller supports, you can use the kubectl
command to check the resource API version.
user@control-plane-node:~$ for kind in `kubectl api-resources | tail +2 | awk '{ print $1 }'`; do kubectl explain $kind; done | grep -e "KIND:" -e "VERSION:"
The table below lists the API version of the required API object used for FortiADC Ingress Controller:
API Object |
API Version |
---|---|
Node | v1 |
Pod | v1 |
PodTemplate | v1 |
ServiceAccount | v1 |
Service | v1 |
Deployment | apps/v1 |
ReplicaSet |
apps/v1 |
Event |
v1 |
IngressClass |
networking.k8s.io/v1 |
Ingress |
networking.k8s.io/v1 |
ClusterRoleBinding |
rbac.authorization.k8s.io/v1 |
ClusterRole |
rbac.authorization.k8s.io/v1 |
RoleBinding |
rbac.authorization.k8s.io/v1 |
Role |
rbac.authorization.k8s.io/v1 |