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
Kubernetes	1.19.8 - 1.23.x	1.19.8 - 1.24.x
FortiADC Version	5.4.5 - 7.0.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@master-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